From nobody Fri Apr 1 09:00:24 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A6A12D6C0 for ; Fri, 1 Apr 2016 09:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOLRp1vMrYd3 for ; Fri, 1 Apr 2016 09:00:19 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5135E12D70A for ; Fri, 1 Apr 2016 09:00:12 -0700 (PDT) Received: from [192.168.10.140] ([200.27.220.46]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MLNeQ-1alTGE1wLC-000ZXa for ; Fri, 01 Apr 2016 18:00:09 +0200 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56FE9B0D.9050005@gmx.net> Date: Fri, 1 Apr 2016 18:00:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uJWRgeWDG38IRTwFnhG8kO6V2usEjOxup" X-Provags-ID: V03:K0:vJCANw3WX2ryLWLQ1u9TdXqpFNXiEitrh09/AoSKHviPRhk8BC8 BBCUYNaWZ5DpPCS0HRprW+obpzBBjjvNmnRSaxLRKBJX2ZYwsTpcMUaSov4D3wMVxAcfnuE /laQpljW7ohYF/XpTtacHsYTGlyUt1xIpNijWXZ00pLWcIjcYnmZShXjx9p9VUrT+RckVHM cnFfYW05Noh1sQYr/IA2g== X-UI-Out-Filterresults: notjunk:1;V01:K0:qiitIOklfz8=:8HfXZDy7eOLtzOOViFSxtm XIOCZwKg6GyJAwnTha+T4FwgvppvXbl4ajj76fZKRNe2aRVjDLcZW+1ItGXiH6kupmUyPwm3M YBgcqE9NsGcPS54rtKaKTN//gsaf0Pi21D5qy21cMwilt+WNYl34QG63B9lqn0scBGrI1JZIH 1CpzfzhL3yrfGIlaAldUqWLuQ8Kl2munJ6AXYjXpcnA3R1E/qSSZ/ngbFylL3OVEsyay5yUS6 LrGlGVeLOCdswNUR/hCyS/W6rST9KYm1+l2bczaAbnN2PSGStH1/dI/xrNQGrWd9VAt+bcpBl KNcK2KKI/wjQ8iqIJ7xD3yMXJJfvzdx1O1kGu82BejNzb18KbQJ4MQWqfezbGHmJTHa+J85XI 7QNvjcjgFKKtb9aKVIguBq1PbSBUxedwLJVq55c921FIFICQotDbCbbYlJSsjqjMAgSkIeMpb UA1gVch3Jzk5Ov4ltqFQ3nUQvxZyFEM7BGcfc0GFfRIoOqtMeHU4fnb4bQUb4FzED2gcjQPf8 nUAMDkEa2NmQ1Irqrkhn3k9IDWZHRF1LUs2A6m5AWPw+aPVFLyLXE15vJAhqeivaUOpQlPtiy JrQfaAqNBBRuh83O3oX5JYM3ag1gGQ/ZnwjhU0kkMNelhCcb8vPxssZCV7sfD8rWdGOHnH+0s I3cKyGbhd6TCT+Ia67B2o+gylEHszXNicPxE1rhWW6qm6DT8oVTL5TjKvnEQ9LOF/+rSFFLdO rcZu6xybBjFOxrrGZu+rVqfnp5yJgOl9ntKsdEUvi+suhV2xXc1P1yg5y9g= Archived-At: Subject: [OAUTH-WG] Updated OAuth Meeting Agenda X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 16:00:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uJWRgeWDG38IRTwFnhG8kO6V2usEjOxup Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, based on the feedback I have updated the meeting agenda. Here is the new proposal: https://www.ietf.org/proceedings/95/agenda/agenda-95-oauth Ciao Hannes --------------------- IETF 95 OAuth Meeting Agenda Wednesday, 10:00-12:30 Chairs: Hannes Tschofenig/Derek Atkins - Status Update (Hannes, 5 min) (a) Informal OAuth Security Workshop (December 2015) (b) OAuth Security Workshop (July 2016) (c) Re-chartering (d) "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" as RF= C *** WG Documents *** - OAuth 2.0 Mix-Up Mitigation (Hannes, 45 min) https://datatracker.ietf.org/doc/draft-ietf-oauth-mix-up-mitigation/ Presentation about the problems/threats we are solving: (a) OAuth Mix-Up (John) (b) Cut-and-paste Attack (Nat) Move cut-and-paste threat to a different document? - OAuth Discovery (45min) What are the use cases the discovery document is solving? OAuth 2.0 Authorization Server Discovery Metadata (Mike, 15 min) https://datatracker.ietf.org/doc/draft-ietf-oauth-discovery/ OAuth Response Metadata (Nat, 15min) https://datatracker.ietf.org/doc/draft-sakimura-oauth-meta/ OAuth 2.0 Bound Configuration Lookup (Phil, 15min) https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00 - Token Exchange (Brian, 15 min) https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ What has been done and discuss open issues? Implementation status? Interoperability? - OAuth 2.0 for Native Apps (William, 15 min) http://datatracker.ietf.org/doc/draft-ietf-oauth-native-apps/ Presentation of availability of code. Moving the document to WGLC as soon as enough people did interop tests. *** Non-WG Documents *** - Resource Indicators for OAuth 2.0 (Brian/John, 15 min) https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators= / *** Not Discussed *** - Authentication Method Reference Values document published. https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/ - Proof-of-Possession http://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/ http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/ https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/ - OAuth 2.0 JWT Authorization Request (JAR) https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ Why is the document important? (related to mix-up attack) After the WGLC is the document ready? - OAuth 2.0 Security: Closing Open Redirectors in OAuth https://datatracker.ietf.org/doc/draft-ietf-oauth-closing-redirectors/ Haven't received more feedback. WGLC? - OAuth 2.0 Device Flow https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ Compare the document with current deployment and provide feedback. Mike to send feedback from the Microsoft team. - Conclusion (Hannes, 10 min) --uJWRgeWDG38IRTwFnhG8kO6V2usEjOxup 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 iQEcBAEBCgAGBQJW/psNAAoJEGhJURNOOiAt/iEH/0WC87evAoyi2hZuylH1NoNj VWGa77beyKHRgIJIxwv1uXDdzb1G0zm4UKtHL3KaqHEtiwT1DvHTFz1p3Qm3bFGr HF0qbIhQqyuVxd5dwbGdKvRfYVm6y7exJ2A8R0Q0MZCPkT0wOUTC2ZPTxtUXSUm+ 7Xw2Qr5ZfP9sYnKH2lAPTi8N1ybaxP34C7lexDqRjKlOlJxfmC6VZ6fk6s9xmrWl FBhCUZEnDBoX5JRq3wJDV7yL6O3yOcCm5BCMxv8R7bQss+n5o8QuxwXfs2IVtDFb fRz4ZvObkhdQ5l1rdQ5EVcXp9J2lCgW+gSiQqgs0FVk0SCPM5DYbjeCTABt1ZAc= =r7tq -----END PGP SIGNATURE----- --uJWRgeWDG38IRTwFnhG8kO6V2usEjOxup-- From nobody Fri Apr 1 18:39:43 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BC012D15C for ; Fri, 1 Apr 2016 18:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvpyzS-wIYox for ; Fri, 1 Apr 2016 18:39:40 -0700 (PDT) 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 5C99212D13F for ; Fri, 1 Apr 2016 18:39:40 -0700 (PDT) Received: by mail-ig0-x230.google.com with SMTP id l20so9240273igf.0 for ; Fri, 01 Apr 2016 18:39:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=DHuF8igBI7g3tDQ3sdMB+inWn06RxcUqOTmz4CsJuuY=; b=X/lEB/VEHIfsTcfvIo1lE/S3XgdMEJw4SfpTwkRTs/3Nd32mn1YUbXMOFsQ9HexipR u1RDxSQ7LrQC9Ils17koBtRLDSLylu+3ch8JYXM74a9Sz7hhkHi8JC55gat5zoTAOqIP 0YGP8XIqOzzug4Uwe0s72M8A8waXeCeTMXQ/PwGKm649LrOvLnQsrD7ubMBqDVgd2+0d /ZfbyhUivo7n8K7qGhu2fxpMJLNBowswgBHEzunlF+FH1x5rkJ1xQ0TLR5Aoav03L0NN 2UHpmqgeSTvBKs5IaHfjleNvFQtksiQ10xTSxQ5QPcAJrK52s2ZZopsgl14SjbNMa+kg a21w== 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; bh=DHuF8igBI7g3tDQ3sdMB+inWn06RxcUqOTmz4CsJuuY=; b=PK9xzF0oMb0FexfA2OYHNoSeMBRd1TJNBipBMwfZ7CK6FPoIf8IFKU9hRSrC4MBL9l V8l3aCazWgWmEYGMfBM8/EKNXK+PkaQk1Dl15BBqQipmxzGJOIuRyLkWm0YInvrObglm aKD4G9osj34oOtsdd3dFgqLSbPut1V9GWyylIeIMG/rqwDPze2ctBD7aM7sXfnKj31Km noUv+2vlatF7cwsvnse0pcqxDoyijOKIUG0htese76EW7msHGq0XxLz79kkGMWDyHrfO f51ri915/GdcbHMT7e4N21F5m5dxMl7sifNBRrBy60CPUoNObf4dkzEULGKM1jzCr8hX LaMA== X-Gm-Message-State: AD7BkJIgbWV3WRRsFGolFlh8AzvL5AN+1A4Cw3nzDcUphXG6ymK1cLrGobn2uH3+86M3t/3PYF48jpwYLhV7i3rl MIME-Version: 1.0 X-Received: by 10.107.6.40 with SMTP id 40mr11444590iog.176.1459561179492; Fri, 01 Apr 2016 18:39:39 -0700 (PDT) Received: by 10.107.182.8 with HTTP; Fri, 1 Apr 2016 18:39:39 -0700 (PDT) Date: Fri, 1 Apr 2016 18:39:39 -0700 Message-ID: From: Andy Zmolek To: oauth@ietf.org Content-Type: multipart/alternative; boundary=001a113f8ed2a204c9052f769172 Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 for Native Apps: open source client libraries X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 01:39:42 -0000 --001a113f8ed2a204c9052f769172 Content-Type: text/plain; charset=UTF-8 > Any plan to bring the libraries to more ?young? languages like Swift in iOS and Kotlin in Android? Are you volunteering? --001a113f8ed2a204c9052f769172 Content-Type: text/html; charset=UTF-8
> Any plan to bring the libraries to more ?young? languages like Swift in iOS and Kotlin in Android?

Are you volunteering?
--001a113f8ed2a204c9052f769172-- From nobody Sat Apr 2 04:04:40 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1017312D0EA for ; Sat, 2 Apr 2016 04:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RvzUbgRuT-n for ; Sat, 2 Apr 2016 04:04:35 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.29]) (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 7AA7412D0FC for ; Sat, 2 Apr 2016 04:04:35 -0700 (PDT) Received: from [79.218.78.53] (helo=[192.168.71.101]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84) (envelope-from ) id 1amJM0-0006Mf-M5; Sat, 02 Apr 2016 13:04:32 +0200 Content-Type: multipart/alternative; boundary=Apple-Mail-8CE97F47-3456-4F4A-B65C-544E58451EB4 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPad Mail (13E233) In-Reply-To: Date: Sat, 2 Apr 2016 13:04:31 +0200 Content-Transfer-Encoding: 7bit Message-Id: <7CDE7D76-4E6C-4060-A0AB-C7D0FE8C9246@lodderstedt.net> References: <20160321173103.31961.76817.idtracker@ietfa.amsl.com> To: Brian Campbell X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-resource-indicators-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 11:04:39 -0000 --Apple-Mail-8CE97F47-3456-4F4A-B65C-544E58451EB4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Brian, did you intentionally omit scope values in your example requests? I would li= ke to know what you envision to be the relationshop between scope and resour= ce. As you draft says, we today use scope values to indicate to the AS, which re= ssource servers the clients wants to access. I think we nearly exclusively u= se it for that purpose and only seldomly to request certain access rights. O= ne of the advantages is, we can request access to multiple resource servers s= imple by putting multiple scope values into the scope parameter. Will this b= e possible with the extension you are proposing? Best regards, Torsten. > Am 21.03.2016 um 18:41 schrieb Brian Campbell = : >=20 > Very minor update to this draft before the deadline that moves Hannes from= Acknowledgements to Authors in acknowledgment of his similar work a few yea= rs ago. Also fleshed out the IANA section with the formal registration reque= sts.=20 >=20 >=20 > ---------- Forwarded message ---------- > From: > Date: Mon, Mar 21, 2016 at 11:31 AM > Subject: New Version Notification for draft-campbell-oauth-resource-indica= tors-01.txt > To: Hannes Tschofenig , Hannes Tschofenig , Brian Campbell , John Br= adley >=20 >=20 >=20 > A new version of I-D, draft-campbell-oauth-resource-indicators-01.txt > has been successfully submitted by Brian Campbell and posted to the > IETF repository. >=20 > Name: draft-campbell-oauth-resource-indicators > Revision: 01 > Title: Resource Indicators for OAuth 2.0 > Document date: 2016-03-21 > Group: Individual Submission > Pages: 8 > URL: https://www.ietf.org/internet-drafts/draft-campbell-oauth-= resource-indicators-01.txt > Status: https://datatracker.ietf.org/doc/draft-campbell-oauth-reso= urce-indicators/ > Htmlized: https://tools.ietf.org/html/draft-campbell-oauth-resource-= indicators-01 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-campbell-oauth-r= esource-indicators-01 >=20 > Abstract: > This straw-man specification defines an extension to The OAuth 2.0 > Authorization Framework that enables the client and authorization > server to more explicitly to communicate about the protected > resource(s) to be accessed. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submissi= on > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-8CE97F47-3456-4F4A-B65C-544E58451EB4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Brian,

did you intentionally omit scope values in your example requests? I w= ould like to know what you envision to be the relationshop between scope and= resource.

As you draft says, we today use scope va= lues to indicate to the AS, which ressource servers the clients wants to acc= ess. I think we nearly exclusively use it for that purpose and only seldomly= to request certain access rights. One of the advantages is, we can request a= ccess to multiple resource servers simple by putting multiple scope values i= nto the scope parameter. Will this be possible with the extension you are pr= oposing?

Best regards,
Torsten.

Am 21.03.2016 um 18:41 schrieb Brian Campbell <bcampbell@pingidentity.com>:

Very minor update to this draf= t before the deadline that moves Hannes from Acknowledgements to Authors in a= cknowledgment of his similar work a few years ago. Also fleshed out the IANA= section with the formal registration requests.


---------- Forwa= rded message ----------
From: <= internet-drafts@ietf.org>
Date: Mon, Mar 21, 2016 at 11:31 A= M
Subject: New Version Notification for draft-campbell-oauth-resource-ind= icators-01.txt
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>, Hannes Tsc= hofenig <H= annes.Tschofenig@gmx.net>, Brian Campbell <brian.d.campbell@gmail.com>,= John Bradley <ve7= jtb@ve7jtb.com>



A new version of I-D, draft-campbell-oauth-resource-indicators-01.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name:           draft-campbell-oauth-resource-= indicators
Revision:       01
Title:          Resource Indicators for OAuth 2.0 Document date:  2016-03-21
Group:          Individual Submission
Pages:          8
URL:            https://www.ietf.org/internet-drafts/draft-campb= ell-oauth-resource-indicators-01.txt
Status:         https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-= indicators/
Htmlized:       https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01=
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-campbell-oa= uth-resource-indicators-01

Abstract:
   This straw-man specification defines an extension to The OAuth 2= .0
   Authorization Framework that enables the client and authorizati= on
   server to more explicitly to communicate about the protected    resource(s) to be accessed.




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

The IETF Secretariat



____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-8CE97F47-3456-4F4A-B65C-544E58451EB4-- From nobody Sat Apr 2 05:45:01 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B7912D58A for ; Sat, 2 Apr 2016 05:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZW49SCYmLwHk for ; Sat, 2 Apr 2016 05:44:57 -0700 (PDT) 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 31DA812D587 for ; Sat, 2 Apr 2016 05:44:57 -0700 (PDT) Received: by mail-qg0-x234.google.com with SMTP id y89so116906185qge.2 for ; Sat, 02 Apr 2016 05:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GYm06L33kIj3vo8gf+RI/z6GH5O5xkHzONhV7rqhvRE=; b=a8F4tDME5RYE0uZx8KcqlISwjgV5QHD8NOYTZ+F+X/igR4GBpBVlR6s7swQCtx2rpi a4A4LzElTmOSNTiRPpUwbO3zirACOZgz54vmdx+RrZX8t8n3c8uYbVoDkbm1mA3S//PU aOnsZIg70fyGnEowPWSCckT/Wm2sA2hWR40FN0BoViyc8lALhCOxOvjAN+ArH/KI+SK/ Si/A7N6s6VRsvv99uXlkYcCnwyS1chNlxctl4c7h/qZM0XAqu9bRwQa8Xrc7alQxARVP UyKNAyLfEhrL7Gwy/NRXzZnskx+N3/Z9jtb2xwoNyGJ3XfqdmkoN3L0Lkhewm9IlGsWi C1/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:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GYm06L33kIj3vo8gf+RI/z6GH5O5xkHzONhV7rqhvRE=; b=WrGnJZX4+Kf5ysv2c9YGe/cR9JJNnAKaOQBDRAjxt4+clSpx6H1L/gDZw/2XnpdmgQ skdjdduV31V1QNaIZogQFqVqVOi0aDzG/12jQ75LG2MakqOro8Zip4HHJhQ6ZeMDx3Iz RYcwTNujYNxzX2vEXhuv0fd0gZn2vClfGZ47DIVlf5znQ18Wk5YY4epJfm5833h7GOX/ EXBFNa2jR62f/ksCaJ5hFD65e3b3faiWjBDF7xq3+O6tFO7htA0/cHApkM+v4F11uFtO wfXvA3+Gopz5HXsMeKUSjqA2xdID7Lle0eIoVqevIyp+dYGcicbgvvqwLEdqFe3FSxc6 XvBQ== X-Gm-Message-State: AD7BkJLkfYznRABEO6n+hKSYUkguGbopZDLAgp7LJbHc1pf/tT9GpxaU+lNH9PjEZdkKjQ== X-Received: by 10.140.163.66 with SMTP id j63mr5776045qhj.68.1459601096194; Sat, 02 Apr 2016 05:44:56 -0700 (PDT) Received: from [192.168.1.68] ([191.115.97.192]) by smtp.gmail.com with ESMTPSA id d6sm8266124qkb.13.2016.04.02.05.44.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 02 Apr 2016 05:44:55 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: Date: Sat, 2 Apr 2016 09:44:48 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Andy Zmolek X-Mailer: Apple Mail (2.3124) Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 for Native Apps: open source client libraries X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 12:44:59 -0000 The current iOS version works just fine with apps written in Swift. I don=E2=80=99t know that there is a compelling reason to support two = code bases on the same platform as long as the SDK supports all the = development tools. Other than as an example, do you have a reason for needing it in Swift? At the moment the focus is more on expanding the functionality. Adding options for creating and validating JWT/id_tokens, JWE = encryption support , Token binding for refresh tokens that can use the = TPM for security, Application Configuration via a EMM (AppConfig) , = Alignment with the the GSMA Mobile Connect SDK so that developers = don=E2=80=99t wind up needing one SDK for Azure and another to support = the Mobile Network Operator openID service. Let us know what directions are important to you. Regards John B. > On Apr 1, 2016, at 10:39 PM, Andy Zmolek wrote: >=20 > > Any plan to bring the libraries to more ?young? languages like Swift = in iOS and Kotlin in Android? >=20 > Are you volunteering? > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Sat Apr 2 19:38:35 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C5C12D508 for ; Sat, 2 Apr 2016 19:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMFZg4KrIhPZ for ; Sat, 2 Apr 2016 19:38:32 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6740512D505 for ; Sat, 2 Apr 2016 19:38:32 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id t10so27961111ywa.0 for ; Sat, 02 Apr 2016 19:38:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=cP7QpTbNyGXXfNyAvoh9PgScDr1u11PU2gqXiZjaAFY=; b=rk8rNzKkjW9xzg4FmGtTVZTwkW7Qn+OiW+5qNhSRjvyenwX0aDq1eOsk9KehkP0Awi k83QRT3AGYStwpHhupQUIi2+8yNs3Z+6CapJmK7AR3mEcvKLzKUI+SW+3GDEYY7/HOmD YtLICwb6y09PxFHpfr3ZBHNrCmmNoFfJ/grQzkoWnB81SQOrnZHjMJb91h3iVP9krkDa 2GDKmHJp4XeGr9mpGeRIiYEzUptHzmJrvcXkcET1N+CaniIAiSB62B93snjpF7bQLcbL pxylnZ4TZCA2cR1KRdsdBkwX3mrWVGwk5QHk+HAPwexUCsido3JUvvAj/No35MAO2Fxh gxXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=cP7QpTbNyGXXfNyAvoh9PgScDr1u11PU2gqXiZjaAFY=; b=nHp3yUvz1MFBw4hxDou5O1hfUYQAmW4KW/VyKIl6qZ0+3p5bIjJcWOxbo8gdh7yMcv Cft1Nyqn8PuvjrVCdwBmTIvBdr1IM6ELQ3pG9L3tON758pXSGFyJIxwpy0Ir3YRDvjDR fAxOMVy8jPfH88NxtRAB1Nqa44Fd7Kkr+rRCMVVBdKCBveC5y7P2FE0bQcO0muZx9NqT Fel3AGmYpbC9qc1MTaFBtfdU70h/2/eVYJan+vcJR7cfUX/tj5fAZd11nuwOYCurckmx sPe7eIdBnBWaWwWic6W1CovsoL6Xzv86ycMXnwRhMtyN9Xx3Ias9wP7MeOMoIy9d4ksp SErA== X-Gm-Message-State: AD7BkJLNaNM9y6lc3TdVwilBrQa/SoczuSmpSxwQOZ69sCaW9sgcTPBlSehA4kDfTff5woT9Akhx1+m7Id3Usw== X-Received: by 10.37.231.11 with SMTP id e11mr2151552ybh.145.1459651111553; Sat, 02 Apr 2016 19:38:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.83.201 with HTTP; Sat, 2 Apr 2016 19:38:12 -0700 (PDT) From: Josh Mandel Date: Sat, 2 Apr 2016 22:38:12 -0400 Message-ID: To: "oauth@ietf.org WG" Content-Type: multipart/alternative; boundary=94eb2c0b12ae002a2b052f8b82c7 Archived-At: Subject: [OAUTH-WG] OAuth server with a static web frontend? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 02:38:34 -0000 --94eb2c0b12ae002a2b052f8b82c7 Content-Type: text/plain; charset=UTF-8 Hi all, I'm exploring the idea of an OAuth server comprising two separate components: * Static *frontend* web app that handles all UI functionality * Headless *backend* that never returns HTML These two components would communicate via some well-defined internal protocol. For example, the frontend would be responsible for hosting the "/authorize" endpoint, which it might accomplish by steps like: 1. ask the user to sign in, perhaps via an internal Resource Owner Password Credentials Flow to the backend 2. call a special "/code" endpoint on the backend, which generates an authorization code for the client that's attempting to authorize 3. return this code to the client via in-browser redirect And the backend would host the "/token" endpoint, responding directly to an authorized client. All this could happen without cookies, and without tight coupling between the two components. Does something like this exist? Are there obvious security show-stoppers? Is anyone aware an effort to standardize what the "well-defined protocol" between these components would look like? Thanks for your help! -Josh --94eb2c0b12ae002a2b052f8b82c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

I'm exploring the idea of a= n OAuth server comprising two separate components:

=C2=A0* Static=C2=A0frontend=C2=A0web app that handles all UI funct= ionality=C2=A0
=C2=A0* Headless backend that never returns= HTML

These two components would communicate via s= ome well-defined internal protocol. For example, the frontend would be resp= onsible for hosting the "/authorize" endpoint, which it might acc= omplish by steps like:

=C2=A01. ask the user to si= gn in, perhaps via an internal Resource Owner Password Credentials Flow to = the backend

=C2=A02. call a special "/code&qu= ot; endpoint on the backend, which generates an authorization code for the = client that's attempting to authorize

=C2=A03.= return this code to the client via in-browser redirect

And the backend would host the "/token" endpoint, respondin= g directly to an authorized client. All this could happen without cookies, = and without tight coupling between the two components.

=
Does something like this exist? Are there obvious security show-stoppe= rs? Is anyone aware an effort to standardize what the "well-defined pr= otocol" between these components would look like?

=
Thanks for your help!

=C2=A0 -Josh
--94eb2c0b12ae002a2b052f8b82c7-- From nobody Mon Apr 4 10:09:41 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B71E412D605 for ; Mon, 4 Apr 2016 10:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=herberg.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cporWrMHPrVa for ; Mon, 4 Apr 2016 10:09:39 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6993212D0F5 for ; Mon, 4 Apr 2016 10:09:39 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id e185so188253619vkb.1 for ; Mon, 04 Apr 2016 10:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:date:message-id:subject:from:to; bh=rVcYqST7+m1wzPxvrdlypv6WvSphufdrayvhC1OkFH4=; b=wsJSEYIx32cM1u/FX94jKQLiq+gpcMp1yGexmqsjbYOAy9prPHbryzySufCTdi2Dvl vtmZaLmlHib8qui1JNKxxJQo4FI8HY0k3rmg1eSCwyY8+nHML8Rm9wPJhIb62Oe0QytL wBMjjexkQbSUO0vzffJZk4wYH50gvH8Vt6aLI= 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; bh=rVcYqST7+m1wzPxvrdlypv6WvSphufdrayvhC1OkFH4=; b=QGRZVT/1OdfYWN0SoiezG4CwZ25JC8dRV6vfrKGzAQ1JRAXuJGRERQ1EFbDzm/35YM JvoBBABojYLKJHyiuyEsORB4VLPuWpVv+Qbq7zPq5Zer7j0CC2moTdqARh9REN9PtHmL p8gmOYxe1CglkBgHO/GGtJPtOvAQTacDH+Ysp141o8RkVpEiOevmSYDcoNykPbFXO2ge zXnpmONXSKLYW9UAmlKEQbcAlspqpSWqdyRUpz7El6hIo2N42b2mOos8FTjhWfljjsV9 BvpVDNRt3M3ImX0QeMP6vTIYOki8MmAG3oH7b8tVlsvGEwAyvbFpaRdu9FoNan1ElvC5 yXlg== X-Gm-Message-State: AD7BkJJin0AvyUYBu6SNDXxb4G+RrFwSJv54CZfDe83avUKorxwouIhv1Ty+cpx6FiGqLd/y+kaFvFlH8C9zJw== MIME-Version: 1.0 X-Received: by 10.159.37.234 with SMTP id 97mr8509749uaf.99.1459789778404; Mon, 04 Apr 2016 10:09:38 -0700 (PDT) Received: by 10.31.87.66 with HTTP; Mon, 4 Apr 2016 10:09:38 -0700 (PDT) Date: Mon, 4 Apr 2016 10:09:38 -0700 Message-ID: From: Ulrich Herberg To: oauth@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [OAUTH-WG] draft-ietf-oauth-native-apps-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 17:09:40 -0000 Hi, I have read draft-ietf-oauth-native-apps-01 and I generally agree with the overall recommendations in the draft, and it is well written (I haven't participated in this WG before, so I don't know what to what level it has already been discussed). Some comments: - Section 2, last paragraph: I agree with the general recommendation to not use an external user agent because of complexity. However, there are cases when a tablet is sold as a closed system and under full control of the vendor. In these cases, the vendor can preinstall the AS user agent into the operating system and provide APIs for other apps to use it. - Section 5.1 (Embedded User-agents): "Authorization servers SHOULD consider taking steps to detect and block logins via embedded user-agents that are not their own, where possible." Do you have any recommendation how to do that, other than reading the (easily modifiable) User-Agent HTTP header? Maybe you could add a sentence for providing some guidance here. - Section 5.3 (Phishing): This is indeed concerning; it's very easy to fake the in-app browser. The draft says: "If all native apps use the techniques described in this best practice, users will not need to sign-in frequently and thus should be suspicious of any sign-in request when they should have already been signed-in." That is true, in theory, but sounds like a big "if" to me. Most users are not savvy enough to be suspicious if a login screen appears and it looks the same as the one they know. I admit that I don't have any suggestion how to do it better, but this part seems to be the most problematic to me for using OAuth on native devices. Best regards Ulrich From nobody Mon Apr 4 12:16:37 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D34112D830 for ; Mon, 4 Apr 2016 12:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IUTgjWmHKor for ; Mon, 4 Apr 2016 12:16:25 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::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 AF08912D82E for ; Mon, 4 Apr 2016 12:16:18 -0700 (PDT) Received: by mail-ob0-x233.google.com with SMTP id fp4so103774960obb.2 for ; Mon, 04 Apr 2016 12:16:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=cD+UDhJmPPXbrHjY3OSc5BrWDVjGl56Jy1yAPCmYVWM=; b=TI8DT+R7+tEdAszuhnxSeSKyQGiKsnjDqVPlbq8j309FGMmYkYsIj0fZ0+KmWpcCS2 TYAlnFUWqelTDpMH1VLAZmuJv0IbzugnGKafkUKY4NjpvrsIDXBYPJkJzOKt4gmyW8I8 5GuYAAPz2s40NyG00lXVvtxAH57iS1pXfnjGygk7HMTf7zYo9GLcs64ClRRHlv2nMnv3 OUW5cbDx9VNrnbts3qYNMXh+gu0Pa7ZH5Ul1XeS1DIGjG9Pp5sl/YXZYxN9pIpAcLZ1Y l+CrkW566p5nRzF/a1MrCkjNnbNcHXvWDX+8cuPSlq5EUCKYa2nQQSwU7pMb+C3E6PdI d0Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=cD+UDhJmPPXbrHjY3OSc5BrWDVjGl56Jy1yAPCmYVWM=; b=dzE9SmjJKaJ/KEuwL+ZbyUE+yF4pWnjc6g62XQSzo8BFb3MXJZRGvn9k5/uYS7AsMu IrtEH+InctjCaLdr2x0IbJvmMg6Qv2vfV3RypC6DIT+H6btjqqVYgftu7iQLsLoDTqOf 100DMuoZisd3Cf30+oflnugmZgLkO8E+6u2l+XMnB9UMLFnFW+DMQNQYs6P6kHrbkG3g b9oOqH2UjjCTLAQNXHGr7elst6jq1pR1ihnQeR7ii3eUmPTuItrHphlwyoJirdXWRsba YqMPYVEqlcR7/EGiNyAizwspxUTHddLYFu30dGuv3TnrY/BXqYpirA7sHmWwyFOlFDKl uWFA== X-Gm-Message-State: AD7BkJJH9EqdF5tSkQyk/T3g7N0wSamtXLMJ8PvaPjb57QUccv6i0Cpo/gR9IO1wg5Bkkhrnuiqput/R3vOUD8s1 X-Received: by 10.60.35.201 with SMTP id k9mr11968909oej.3.1459797377956; Mon, 04 Apr 2016 12:16:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.79.233 with HTTP; Mon, 4 Apr 2016 12:15:58 -0700 (PDT) From: William Denniss Date: Mon, 4 Apr 2016 16:15:58 -0300 Message-ID: To: "oauth@ietf.org" , unbearable@ietf.org Content-Type: multipart/alternative; boundary=089e011613bc2884b4052fad907e Archived-At: Subject: [OAUTH-WG] OAuth + Token Binding IETF95 F2F Meetup [April 5, 2pm~4pm] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 19:16:27 -0000 --089e011613bc2884b4052fad907e Content-Type: text/plain; charset=UTF-8 As we heard today in the Token Binding WG meeting, we need to do some work on the Federation use-case. With that in mind, we have an informal gathering of interested people from the OAuth and Token Binding work groups during IETF95, on the topic of adding token binding to OAuth. When: Tuesday, April 5 from 2pm to 4pm Where: Alerce Room at the Hilton (Level 5, near Quebracho B) If you're interested, please feel free to join us. --089e011613bc2884b4052fad907e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As we heard today in the Token Binding WG meeting, we need= to do some work on the Federation use-case.

With that i= n mind, we have an informal gathering of interested people from the OAuth a= nd Token Binding work groups during IETF95, on the topic of adding token bi= nding to OAuth.

When: Tuesday, April 5 from 2pm to= 4pm
Where: Alerce Room at the Hilton (Level 5, near Quebracho B)=

If you're interested, please feel free to joi= n us.

--089e011613bc2884b4052fad907e-- From nobody Mon Apr 4 12:35:32 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E2112D839 for ; Mon, 4 Apr 2016 12:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=herberg.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUqDmAiEnoWk for ; Mon, 4 Apr 2016 12:35:29 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E580D12D835 for ; Mon, 4 Apr 2016 12:35:28 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id e185so193615056vkb.1 for ; Mon, 04 Apr 2016 12:35:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=3N509ePy6040R4ZU/R5cDxK5SSSo3wDalQ5CY8RmK5Y=; b=BSyTPYvvQL7bXteq0zgSkMOpm2ZRJHF/IA4Q/OACn00wX1C1w571QhZmSZoWgoTZuo urYfdOjBJzqZWwGIo3qkZ71rBhIjWtj5MG5Izr/X9T/7zrbwlV9VPGy6qMv0UaVw73d1 UJU7AGmUNxI05IbTjfrWME52/jxWVn6ndtW9o= 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-transfer-encoding; bh=3N509ePy6040R4ZU/R5cDxK5SSSo3wDalQ5CY8RmK5Y=; b=GguwU9UJNy4z/pF3jQgsvgnMFLFiMZqYmU37/pDl4vdG71h8fE/0MlZSjuOZm2vWhr i+G1utyH4qc9mSB0j+4OyKfFvYg5Q1TJm8S54dBW8HrCRw8r5/pLp1zklGc+Wf3PhY/M YYWkxdsqcEwTouKt3BUnqr4GY2cNwm/L8ODz6sAV2igC8r0YpB7/fEOL1h5iFuvjrISE Oo1VLggg5LwiPiyzHEeIVjyMXOzzkd4Y9bhoSzSgtQPkR6EI+vquf1tEynsQGRimkutX i+RRX4uF4qOmJGsPZHqBmrgJB3umngl0IHz8K5b2wnIhjV9bLYYoPGg6+0vOXwvG5GDM eUPw== X-Gm-Message-State: AD7BkJJg7ZraHzR2uA8Fy0EhBoTjZpvGtjMgDlS8S999NG27WWkjjlrSNhmseWaTYKR7e+RtzsGGMqkVxw/68g== MIME-Version: 1.0 X-Received: by 10.176.64.227 with SMTP id i90mr4213600uad.62.1459798527940; Mon, 04 Apr 2016 12:35:27 -0700 (PDT) Received: by 10.31.87.66 with HTTP; Mon, 4 Apr 2016 12:35:27 -0700 (PDT) In-Reply-To: References: Date: Mon, 4 Apr 2016 12:35:27 -0700 Message-ID: From: Ulrich Herberg To: John Bradley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: oauth@ietf.org, Andy Zmolek Subject: Re: [OAUTH-WG] OAuth 2.0 for Native Apps: open source client libraries X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 19:35:31 -0000 Thanks for providing the open source libraries. I tested them (on Android), and it works nicely. Best regards Ulrich On Sat, Apr 2, 2016 at 5:44 AM, John Bradley wrote: > The current iOS version works just fine with apps written in Swift. > > I don=E2=80=99t know that there is a compelling reason to support two cod= e bases on the same platform as long as the SDK supports all the developmen= t tools. > > Other than as an example, do you have a reason for needing it in Swift? > > At the moment the focus is more on expanding the functionality. > > Adding options for creating and validating JWT/id_tokens, JWE encryption= support , Token binding for refresh tokens that can use the TPM for secur= ity, Application Configuration via a EMM (AppConfig) , Alignment with the= the GSMA Mobile Connect SDK so that developers don=E2=80=99t wind up needi= ng one SDK for Azure and another to support the Mobile Network Operator ope= nID service. > > Let us know what directions are important to you. > > Regards > John B. > >> On Apr 1, 2016, at 10:39 PM, Andy Zmolek wrote: >> >> > Any plan to bring the libraries to more ?young? languages like Swift i= n iOS and Kotlin in Android? >> >> Are you volunteering? >> _______________________________________________ >> OAuth mailing 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 Mon Apr 4 19:15:28 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4E212D60A; Mon, 4 Apr 2016 19:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfyLqiteIycA; Mon, 4 Apr 2016 19:15:22 -0700 (PDT) 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 EAED112D5A9; Mon, 4 Apr 2016 19:15:21 -0700 (PDT) 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 u352FKZZ012557 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 5 Apr 2016 02:15:21 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 u352FJX5011038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Apr 2016 02:15:20 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u352FJcX000566; Tue, 5 Apr 2016 02:15:19 GMT Received: from dhcp-896a.meeting.ietf.org (/31.133.138.106) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 04 Apr 2016 19:15:19 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_8A22F07C-487E-4CB1-BB28-E9280F05E240" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Date: Mon, 4 Apr 2016 23:15:15 -0300 References: <20160405021126.13977.45272.idtracker@ietfa.amsl.com> To: "scim@ietf.org WG" , id-event@ietf.org, "" , openid-general@lists.openid.net X-Mailer: Apple Mail (2.3112) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: [OAUTH-WG] New Version Notification for draft-hunt-idevent-distribution-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 02:15:24 -0000 --Apple-Mail=_8A22F07C-487E-4CB1-BB28-E9280F05E240 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 FYI=E2=80=A6 I previously announced this draft as available in github. I=E2=80=99ve = published it tonight in advance of tomorrows discussion. Note that this is very preliminary and I=E2=80=99ve already had some = excellent feedback on improvements.=20 Looking forward to a good discussion tomorrow. Cheers, Phil @independentid www.independentid.com = phil.hunt@oracle.com = > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-hunt-idevent-distribution-00.txt > Date: April 4, 2016 at 11:11:26 PM GMT-3 > To: "Phil Hunt" , "Morteza Ansari" = >=20 >=20 > A new version of I-D, draft-hunt-idevent-distribution-00.txt > has been successfully submitted by Phil Hunt and posted to the > IETF repository. >=20 > Name: draft-hunt-idevent-distribution > Revision: 00 > Title: Identity Event Subscription Protocol > Document date: 2016-04-04 > Group: Individual Submission > Pages: 22 > URL: = https://www.ietf.org/internet-drafts/draft-hunt-idevent-distribution-00.tx= t > Status: = https://datatracker.ietf.org/doc/draft-hunt-idevent-distribution/ > Htmlized: = https://tools.ietf.org/html/draft-hunt-idevent-distribution-00 >=20 >=20 > Abstract: > This specification defines a registry to define methods to = distribute > identity events to subscribers. It includes a definition for > publishers to use HTTP POST to push events to clients via web > callback, and a method for subscribers to use HTTP GET to retrieve > events in a feed queue. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_8A22F07C-487E-4CB1-BB28-E9280F05E240 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 FYI=E2=80=A6

I previously announced this draft as available in github. = I=E2=80=99ve published it tonight in advance of tomorrows = discussion.

Note= that this is very preliminary and I=E2=80=99ve already had some = excellent feedback on improvements. 

Looking forward to a good discussion = tomorrow.

Cheers,




Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-hunt-idevent-distribution-00.txt
Date: = April 4, 2016 at 11:11:26 PM = GMT-3
To: = "Phil Hunt" <phil.hunt@yahoo.com>, "Morteza Ansari" <morteza.ansari@cisco.com>

A new version = of I-D, draft-hunt-idevent-distribution-00.txt
has been = successfully submitted by Phil Hunt and posted to the
IETF = repository.

Name: = draft-hunt-idevent-distribution
Revision: 00
Title:= = Identity Event Subscription Protocol
Document = date: = 2016-04-04
Group: Individual Submission
Pages:= = 22
URL: =            https://www.ietf.org/internet-drafts/draft-hunt-idevent-distrib= ution-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-hunt-idevent-distributio= n/
Htmlized:       https://tools.ietf.org/html/draft-hunt-idevent-distribution-00<= /a>


Abstract:
=   This specification defines a registry to define methods to = distribute
  identity events to subscribers. =  It includes a definition for
  publishers = to use HTTP POST to push events to clients via web
=   callback, and a method for subscribers to use HTTP GET to = retrieve
  events in a feed queue.




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

The IETF = Secretariat


= --Apple-Mail=_8A22F07C-487E-4CB1-BB28-E9280F05E240-- From nobody Tue Apr 5 07:52:17 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4D812D110 for ; Tue, 5 Apr 2016 07:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PP4mY6cLNnF2 for ; Tue, 5 Apr 2016 07:52:14 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7A4B12D0E0 for ; Tue, 5 Apr 2016 07:52:13 -0700 (PDT) Received: by mail-ig0-x22b.google.com with SMTP id gy3so56537797igb.0 for ; Tue, 05 Apr 2016 07:52:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BXSlQiHxwqcjGMM5OgqA/7wh3W9FvxaMO4jDF57ltDk=; b=VcuWwdKeLgfYBuSlywqK2CO4RCCPnMiI3dh75pUkrYdE4MUybpFiPow8ngA70cL1mL 5/WubFdlfOV1WoZlHejMLnREFFM43DTuut0+TGPmuIp/h3QEJ9ao5CpXxrB1pxQ9Xw42 TCzJccdX7zJjaaGLqJptAgw+/3lUL56LXBsi0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BXSlQiHxwqcjGMM5OgqA/7wh3W9FvxaMO4jDF57ltDk=; b=ktNc/jhqg71lfk7MMXlgAr2Jpv4Hzz1IbXTsWLznom0vq2XcnDzklCvW6s6t5DZTIZ KSdwHio66gB8iwQUFaWrjPE0idKQ4Px8X1qzKbArl4xewCBbrw4HWCCDGhadtHuJI/N/ k/gz3rViFxLch/B3XeMK4Hu6QzQOJ0INitDRn5QyXvE6DPirokFI9B2wJEeuwaiEJvAk M86X5gw+OHswniY8bc4ET9Zyp8pPacA/eHU+ZGdri4/hV2WPzARfJGj/NJ2WpCUTAjtF vhS/gQFj9wug57RuqKvLI3uNIBhUaQ7uA5gEWdNiiQq0pSA4teNxtYd4BRULLBnVNbfy UToA== X-Gm-Message-State: AD7BkJLGoMg25ahHsVHllTTat2LiwmVS+m8rXUzroE8apTXAWKFNpj9AAAgkpTvQkJZ1QYXkudxTyPxRXBzcTXKZ X-Received: by 10.50.108.108 with SMTP id hj12mr15984875igb.57.1459867932486; Tue, 05 Apr 2016 07:52:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.74.162 with HTTP; Tue, 5 Apr 2016 07:51:42 -0700 (PDT) In-Reply-To: <7CDE7D76-4E6C-4060-A0AB-C7D0FE8C9246@lodderstedt.net> References: <20160321173103.31961.76817.idtracker@ietfa.amsl.com> <7CDE7D76-4E6C-4060-A0AB-C7D0FE8C9246@lodderstedt.net> From: Brian Campbell Date: Tue, 5 Apr 2016 11:51:42 -0300 Message-ID: To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=089e0149392a8901d7052fbdfd21 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-resource-indicators-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 14:52:16 -0000 --089e0149392a8901d7052fbdfd21 Content-Type: text/plain; charset=UTF-8 Sorry for the slow response, Torsten, I was on vacation last week with my family. The omission of scope values in the example requests wasn't really intentional so much as just an initial desire to have a minimal amount of stuff in the examples. Adding a scope parameter to the example authorization request (Figure 1) would probably be a good thing to do. I'll make a note to do so. As far as the relationship between scope and resource. Scope is *what* access is being requested/granted. And resource is about *where* a particular access token will be used. I envision resource as allowing for scope to Note that, as currently written anyway, resource is unlike scope in that it's not something that the end-user approves or denies access to and it's not something that is persisted with the grant. It only informs the access token being requested at the time. So it'd be used at the token endpoint when getting an access token. And only at the authorization endpoint when an access token will come back directly in the authorization response (implicit flows). Currently, yes, multiple resources are allowed by the draft to indicate multiple RSs. Though there's a note in there questioning it because it complicates things in some situations where different token content or encryption is needed for different RSs that are asked for in the same request. On Sat, Apr 2, 2016 at 8:04 AM, Torsten Lodderstedt wrote: > Hi Brian, > > did you intentionally omit scope values in your example requests? I would > like to know what you envision to be the relationshop between scope and > resource. > > As you draft says, we today use scope values to indicate to the AS, which > ressource servers the clients wants to access. I think we nearly > exclusively use it for that purpose and only seldomly to request certain > access rights. One of the advantages is, we can request access to multiple > resource servers simple by putting multiple scope values into the scope > parameter. Will this be possible with the extension you are proposing? > > Best regards, > Torsten. > > Am 21.03.2016 um 18:41 schrieb Brian Campbell >: > > Very minor update to this draft before the deadline that moves Hannes from > Acknowledgements to Authors in acknowledgment of his similar work a few > years ago. Also fleshed out the IANA section with the formal registration > requests. > > > ---------- Forwarded message ---------- > From: > Date: Mon, Mar 21, 2016 at 11:31 AM > Subject: New Version Notification for > draft-campbell-oauth-resource-indicators-01.txt > To: Hannes Tschofenig , Hannes Tschofenig < > Hannes.Tschofenig@gmx.net>, Brian Campbell , > John Bradley > > > > A new version of I-D, draft-campbell-oauth-resource-indicators-01.txt > has been successfully submitted by Brian Campbell and posted to the > IETF repository. > > Name: draft-campbell-oauth-resource-indicators > Revision: 01 > Title: Resource Indicators for OAuth 2.0 > Document date: 2016-03-21 > Group: Individual Submission > Pages: 8 > URL: > https://www.ietf.org/internet-drafts/draft-campbell-oauth-resource-indicators-01.txt > Status: > https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/ > Htmlized: > https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01 > Diff: > https://www.ietf.org/rfcdiff?url2=draft-campbell-oauth-resource-indicators-01 > > Abstract: > This straw-man specification defines an extension to The OAuth 2.0 > Authorization Framework that enables the client and authorization > server to more explicitly to communicate about the protected > resource(s) to be accessed. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --089e0149392a8901d7052fbdfd21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry for the slow response, Torsten, I was= on vacation last week with my family.

The omission of s= cope values in the example requests wasn't really intentional so much a= s just an initial desire to have a minimal amount of stuff in the examples.= Adding a scope parameter to the example authorization request (Figure 1) w= ould probably be a good thing to do. I'll make a note to do so.

=
As far as the relationship between scope and resource. Scope is *what= * access is being requested/granted. And resource is about *where* a partic= ular access token will be used. I envision resource as allowing for scope t= o

Note that, as currently written anyway, resource is unlike = scope in that it's not something that the end-user approves or denies a= ccess to and it's not something that is persisted with the grant. It on= ly informs the access token being requested at the time. So it'd be use= d at the token endpoint when getting an access token. And only at the autho= rization endpoint when an access token will come back directly in the autho= rization response (implicit flows).

Currently, yes, multiple r= esources are allowed by the draft to indicate multiple RSs.=C2=A0 Though th= ere's a note in there questioning it because it complicates things in s= ome situations where different token content or encryption is needed for di= fferent RSs that are asked for in the same request.=C2=A0


=

O= n Sat, Apr 2, 2016 at 8:04 AM, Torsten Lodderstedt <torsten@lodderst= edt.net> wrote:
Hi Brian,

did you intentionally omit scope values in your example requests? I would= like to know what you envision to be the relationshop between scope and re= source.

As you draft says, we today use scope valu= es to indicate to the AS, which ressource servers the clients wants to acce= ss. I think we nearly exclusively use it for that purpose and only seldomly= to request certain access rights. One of the advantages is, we can request= access to multiple resource servers simple by putting multiple scope value= s into the scope parameter. Will this be possible with the extension you ar= e proposing?

Best regards,
Torsten.

Am 21.03.2016 um 18:41 schrieb Brian Campbell <bcampbell@pingid= entity.com>:

Very minor update to this draft before the deadline that moves Hannes= from Acknowledgements to Authors in acknowledgment of his similar work a f= ew years ago. Also fleshed out the IANA section with the formal registratio= n requests.


---------- Forwarded message ----------
From: <= b class=3D"gmail_sendername"> <internet-drafts@ietf.org>=
Date: Mon, Mar 21, 2016 at 11:31 AM
Subject: New Version Noti= fication for draft-campbell-oauth-resource-indicators-01.txt
To: Hannes = Tschofenig <hannes.tschofenig@gmx.net>, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, Brian Campbell <brian.d.campbell@gmail.com>, John Bradley <ve7jtb@ve7jtb.com><= br>


A new version of I-D, draft-campbell-oauth-resource-indicators-01.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-campbell-oauth-resource= -indicators
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Resource Indicators for OAuth 2.0<= br> Document date:=C2=A0 2016-03-21
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 8
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ca= mpbell-oauth-resource-indicators-01.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-campbell-oauth-resour= ce-indicators/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators= -01
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-campbell= -oauth-resource-indicators-01

Abstract:
=C2=A0 =C2=A0This straw-man specification defines an extension to The OAuth= 2.0
=C2=A0 =C2=A0Authorization Framework that enables the client and authorizat= ion
=C2=A0 =C2=A0server to more explicitly to communicate about the protected =C2=A0 =C2=A0resource(s) to be accessed.




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

The IETF Secretariat



_= ______________________________________________
OAuth mailin= g list
= OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oau= th

--089e0149392a8901d7052fbdfd21-- From nobody Tue Apr 5 08:42:19 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FB912D6C8 for ; Tue, 5 Apr 2016 08:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4Gwa3Z1mWmf for ; Tue, 5 Apr 2016 08:42:15 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DE2412D67C for ; Tue, 5 Apr 2016 08:42:00 -0700 (PDT) Received: from [80.187.80.144] (helo=[10.133.89.241]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1anT76-00059V-QK; Tue, 05 Apr 2016 17:41:57 +0200 Date: Tue, 05 Apr 2016 12:41:51 -0300 Message-ID: In-Reply-To: References: <20160321173103.31961.76817.idtracker@ietfa.amsl.com> <7CDE7D76-4E6C-4060-A0AB-C7D0FE8C9246@lodderstedt.net> From: "torsten@lodderstedt.net" To: bcampbell@pingidentity.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.syntomo.email_1639641050344420" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-resource-indicators-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 15:42:18 -0000 ----_com.syntomo.email_1639641050344420 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGkgQnJpYW4sCgpJIGFzc3VtZSByZXNvdXJjZSBzZXJ2ZXIgaWRzIG9yIFVSSXMgdG8gYmUgYSBu YW1lcyBuYW1lc3BhY2UgZm9yIHNjb3BlIHZhbHVlcyBvciB0aGF0IHNjb3BlIHZhbHVlcyBhcmUg YmUgYm91bmQgdG8gY2VydGFpbiByZXNvdXJjZSBzZXJ2ZXJzLiBJdCBzZWVtcyB5b3UgaGF2ZSBs ZXNzIGNvdXBsaW5nIGluIG1pbmQ/CgpCZXN0IHJlZ2FyZHMsClRvcnN0ZW4uCgpTZW50IGJ5IE1h aWxXaXNlIOKAkyBTZWUgeW91ciBlbWFpbHMgYXMgY2xlYW4sIHNob3J0IGNoYXRzLgoKLS0tLS0t LS0gT3JpZ2luYWxuYWNocmljaHQgLS0tLS0tLS0KQmV0cmVmZjogUmU6IFtPQVVUSC1XR10gRndk OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWNhbXBiZWxsLW9hdXRoLXJlc291 cmNlLWluZGljYXRvcnMtMDEudHh0ClZvbjogQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5n aWRlbnRpdHkuY29tPgpBbjogVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVk dC5uZXQ+CkNjOiBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+Cgo+U29ycnkgZm9yIHRoZSBzbG93IHJl c3BvbnNlLCBUb3JzdGVuLCBJIHdhcyBvbiB2YWNhdGlvbiBsYXN0IHdlZWsgd2l0aCBteQo+ZmFt aWx5Lgo+Cj5UaGUgb21pc3Npb24gb2Ygc2NvcGUgdmFsdWVzIGluIHRoZSBleGFtcGxlIHJlcXVl c3RzIHdhc24ndCByZWFsbHkKPmludGVudGlvbmFsIHNvIG11Y2ggYXMganVzdCBhbiBpbml0aWFs IGRlc2lyZSB0byBoYXZlIGEgbWluaW1hbCBhbW91bnQgb2YKPnN0dWZmIGluIHRoZSBleGFtcGxl cy4gQWRkaW5nIGEgc2NvcGUgcGFyYW1ldGVyIHRvIHRoZSBleGFtcGxlCj5hdXRob3JpemF0aW9u IHJlcXVlc3QgKEZpZ3VyZSAxKSB3b3VsZCBwcm9iYWJseSBiZSBhIGdvb2QgdGhpbmcgdG8gZG8u IEknbGwKPm1ha2UgYSBub3RlIHRvIGRvIHNvLgo+Cj5BcyBmYXIgYXMgdGhlIHJlbGF0aW9uc2hp cCBiZXR3ZWVuIHNjb3BlIGFuZCByZXNvdXJjZS4gU2NvcGUgaXMgKndoYXQqCj5hY2Nlc3MgaXMg YmVpbmcgcmVxdWVzdGVkL2dyYW50ZWQuIEFuZCByZXNvdXJjZSBpcyBhYm91dCAqd2hlcmUqIGEK PnBhcnRpY3VsYXIgYWNjZXNzIHRva2VuIHdpbGwgYmUgdXNlZC4gSSBlbnZpc2lvbiByZXNvdXJj ZSBhcyBhbGxvd2luZyBmb3IKPnNjb3BlIHRvCj4KPk5vdGUgdGhhdCwgYXMgY3VycmVudGx5IHdy aXR0ZW4gYW55d2F5LCByZXNvdXJjZSBpcyB1bmxpa2Ugc2NvcGUgaW4gdGhhdAo+aXQncyBub3Qg c29tZXRoaW5nIHRoYXQgdGhlIGVuZC11c2VyIGFwcHJvdmVzIG9yIGRlbmllcyBhY2Nlc3MgdG8g YW5kIGl0J3MKPm5vdCBzb21ldGhpbmcgdGhhdCBpcyBwZXJzaXN0ZWQgd2l0aCB0aGUgZ3JhbnQu IEl0IG9ubHkgaW5mb3JtcyB0aGUgYWNjZXNzCj50b2tlbiBiZWluZyByZXF1ZXN0ZWQgYXQgdGhl IHRpbWUuIFNvIGl0J2QgYmUgdXNlZCBhdCB0aGUgdG9rZW4gZW5kcG9pbnQKPndoZW4gZ2V0dGlu ZyBhbiBhY2Nlc3MgdG9rZW4uIEFuZCBvbmx5IGF0IHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50 IHdoZW4KPmFuIGFjY2VzcyB0b2tlbiB3aWxsIGNvbWUgYmFjayBkaXJlY3RseSBpbiB0aGUgYXV0 aG9yaXphdGlvbiByZXNwb25zZQo+KGltcGxpY2l0IGZsb3dzKS4KPgo+Q3VycmVudGx5LCB5ZXMs IG11bHRpcGxlIHJlc291cmNlcyBhcmUgYWxsb3dlZCBieSB0aGUgZHJhZnQgdG8gaW5kaWNhdGUK Pm11bHRpcGxlIFJTcy4gIFRob3VnaCB0aGVyZSdzIGEgbm90ZSBpbiB0aGVyZSBxdWVzdGlvbmlu ZyBpdCBiZWNhdXNlIGl0Cj5jb21wbGljYXRlcyB0aGluZ3MgaW4gc29tZSBzaXR1YXRpb25zIHdo ZXJlIGRpZmZlcmVudCB0b2tlbiBjb250ZW50IG9yCj5lbmNyeXB0aW9uIGlzIG5lZWRlZCBmb3Ig ZGlmZmVyZW50IFJTcyB0aGF0IGFyZSBhc2tlZCBmb3IgaW4gdGhlIHNhbWUKPnJlcXVlc3QuCj4K Pgo+Cj5PbiBTYXQsIEFwciAyLCAyMDE2IGF0IDg6MDQgQU0sIFRvcnN0ZW4gTG9kZGVyc3RlZHQg PHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Cj4+IHdyb3RlOgo+Cj4+IEhpIEJyaWFuLAo+Pgo+PiBk aWQgeW91IGludGVudGlvbmFsbHkgb21pdCBzY29wZSB2YWx1ZXMgaW4geW91ciBleGFtcGxlIHJl cXVlc3RzPyBJIHdvdWxkCj4+IGxpa2UgdG8ga25vdyB3aGF0IHlvdSBlbnZpc2lvbiB0byBiZSB0 aGUgcmVsYXRpb25zaG9wIGJldHdlZW4gc2NvcGUgYW5kCj4+IHJlc291cmNlLgo+Pgo+PiBBcyB5 b3UgZHJhZnQgc2F5cywgd2UgdG9kYXkgdXNlIHNjb3BlIHZhbHVlcyB0byBpbmRpY2F0ZSB0byB0 aGUgQVMsIHdoaWNoCj4+IHJlc3NvdXJjZSBzZXJ2ZXJzIHRoZSBjbGllbnRzIHdhbnRzIHRvIGFj Y2Vzcy4gSSB0aGluayB3ZSBuZWFybHkKPj4gZXhjbHVzaXZlbHkgdXNlIGl0IGZvciB0aGF0IHB1 cnBvc2UgYW5kIG9ubHkgc2VsZG9tbHkgdG8gcmVxdWVzdCBjZXJ0YWluCj4+IGFjY2VzcyByaWdo dHMuIE9uZSBvZiB0aGUgYWR2YW50YWdlcyBpcywgd2UgY2FuIHJlcXVlc3QgYWNjZXNzIHRvIG11 bHRpcGxlCj4+IHJlc291cmNlIHNlcnZlcnMgc2ltcGxlIGJ5IHB1dHRpbmcgbXVsdGlwbGUgc2Nv cGUgdmFsdWVzIGludG8gdGhlIHNjb3BlCj4+IHBhcmFtZXRlci4gV2lsbCB0aGlzIGJlIHBvc3Np YmxlIHdpdGggdGhlIGV4dGVuc2lvbiB5b3UgYXJlIHByb3Bvc2luZz8KPj4KPj4gQmVzdCByZWdh cmRzLAo+PiBUb3JzdGVuLgo+Pgo+PiBBbSAyMS4wMy4yMDE2IHVtIDE4OjQxIHNjaHJpZWIgQnJp YW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tCj4+ID46Cj4+Cj4+IFZlcnkg bWlub3IgdXBkYXRlIHRvIHRoaXMgZHJhZnQgYmVmb3JlIHRoZSBkZWFkbGluZSB0aGF0IG1vdmVz IEhhbm5lcyBmcm9tCj4+IEFja25vd2xlZGdlbWVudHMgdG8gQXV0aG9ycyBpbiBhY2tub3dsZWRn bWVudCBvZiBoaXMgc2ltaWxhciB3b3JrIGEgZmV3Cj4+IHllYXJzIGFnby4gQWxzbyBmbGVzaGVk IG91dCB0aGUgSUFOQSBzZWN0aW9uIHdpdGggdGhlIGZvcm1hbCByZWdpc3RyYXRpb24KPj4gcmVx dWVzdHMuCj4+Cj4+Cj4+IC0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLQo+ PiBGcm9tOiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPgo+PiBEYXRlOiBNb24sIE1hciAyMSwg MjAxNiBhdCAxMTozMSBBTQo+PiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y Cj4+IGRyYWZ0LWNhbXBiZWxsLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMtMDEudHh0Cj4+IFRv OiBIYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4sIEhhbm5lcyBU c2Nob2ZlbmlnIDwKPj4gSGFubmVzLlRzY2hvZmVuaWdAZ214Lm5ldD4sIEJyaWFuIENhbXBiZWxs IDxicmlhbi5kLmNhbXBiZWxsQGdtYWlsLmNvbT4sCj4+IEpvaG4gQnJhZGxleSA8dmU3anRiQHZl N2p0Yi5jb20+Cj4+Cj4+Cj4+Cj4+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1jYW1wYmVs bC1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAxLnR4dAo+PiBoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IEJyaWFuIENhbXBiZWxsIGFuZCBwb3N0ZWQgdG8gdGhlCj4+IElFVEYg cmVwb3NpdG9yeS4KPj4KPj4gTmFtZTogICAgICAgICAgIGRyYWZ0LWNhbXBiZWxsLW9hdXRoLXJl c291cmNlLWluZGljYXRvcnMKPj4gUmV2aXNpb246ICAgICAgIDAxCj4+IFRpdGxlOiAgICAgICAg ICBSZXNvdXJjZSBJbmRpY2F0b3JzIGZvciBPQXV0aCAyLjAKPj4gRG9jdW1lbnQgZGF0ZTogIDIw MTYtMDMtMjEKPj4gR3JvdXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbgo+PiBQYWdl czogICAgICAgICAgOAo+PiBVUkw6Cj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1jYW1wYmVsbC1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAxLnR4dAo+PiBT dGF0dXM6Cj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNhbXBiZWxs LW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMvCj4+IEh0bWxpemVkOgo+PiBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtY2FtcGJlbGwtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0w MQo+PiBEaWZmOgo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtY2Ft cGJlbGwtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wMQo+Pgo+PiBBYnN0cmFjdDoKPj4gICAg VGhpcyBzdHJhdy1tYW4gc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGFuIGV4dGVuc2lvbiB0byBUaGUg T0F1dGggMi4wCj4+ICAgIEF1dGhvcml6YXRpb24gRnJhbWV3b3JrIHRoYXQgZW5hYmxlcyB0aGUg Y2xpZW50IGFuZCBhdXRob3JpemF0aW9uCj4+ICAgIHNlcnZlciB0byBtb3JlIGV4cGxpY2l0bHkg dG8gY29tbXVuaWNhdGUgYWJvdXQgdGhlIHByb3RlY3RlZAo+PiAgICByZXNvdXJjZShzKSB0byBi ZSBhY2Nlc3NlZC4KPj4KPj4KPj4KPj4KPj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBh IGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YKPj4gc3VibWlzc2lvbgo+PiB1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmll dGYub3JnLgo+Pgo+PiBUaGUgSUVURiBTZWNyZXRhcmlhdAo+Pgo+Pgo+Pgo+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+PiBPQXV0aCBtYWlsaW5nIGxp c3QKPj4gT0F1dGhAaWV0Zi5vcmcKPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aAo+Pgo+Pgo= ----_com.syntomo.email_1639641050344420 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PHAgZGlyPSJsdHIiPkhpIEJyaWFuLDwvcD4KPHAgZGlyPSJsdHIiPkkgYXNzdW1lIHJlc291cmNl IHNlcnZlciBpZHMgb3IgVVJJcyB0byBiZSBhIG5hbWVzIG5hbWVzcGFjZSBmb3Igc2NvcGUgdmFs dWVzIG9yIHRoYXQgc2NvcGUgdmFsdWVzIGFyZSBiZSBib3VuZCB0byBjZXJ0YWluIHJlc291cmNl IHNlcnZlcnMuIEl0IHNlZW1zIHlvdSBoYXZlIGxlc3MgY291cGxpbmcgaW4gbWluZD88L3A+Cjxw IGRpcj0ibHRyIj5CZXN0IHJlZ2FyZHMsPGJyPgpUb3JzdGVuLjwvcD4KPHAgZGlyPSJsdHIiPlNl bnQgYnkgPGEgaHJlZj1odHRwOi8vd3d3Lm1haWwtd2lzZS5jb20vaW5zdGFsbGF0aW9uLzI+TWFp bFdpc2U8L2E+ICYjODIxMTsgU2VlIHlvdXIgZW1haWxzIGFzIGNsZWFuLCBzaG9ydCBjaGF0cy48 L3A+Cjxicj48YnI+LS0tLS0tLS0gT3JpZ2luYWxuYWNocmljaHQgLS0tLS0tLS08YnI+QmV0cmVm ZjogUmU6IFtPQVVUSC1XR10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LWNhbXBiZWxsLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMtMDEudHh0PGJyPlZvbjogQnJpYW4g Q2FtcGJlbGwgJmx0O2JjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tJmd0Ozxicj5BbjogVG9yc3Rl biBMb2RkZXJzdGVkdCAmbHQ7dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQmZ3Q7PGJyPkNjOiBvYXV0 aCAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPjxicj48ZGl2IGRpcj0ibHRyIj48ZGl2PjxkaXY+ PGRpdj5Tb3JyeSBmb3IgdGhlIHNsb3cgcmVzcG9uc2UsIFRvcnN0ZW4sIEkgd2FzIG9uIHZhY2F0 aW9uIGxhc3Qgd2VlayB3aXRoIG15IGZhbWlseS4gPGJyPjwvZGl2PjxkaXY+PGJyPlRoZSBvbWlz c2lvbiBvZiBzY29wZSB2YWx1ZXMgaW4gdGhlIGV4YW1wbGUgcmVxdWVzdHMgd2FzbiYjMzk7dCBy ZWFsbHkgaW50ZW50aW9uYWwgc28gbXVjaCBhcyBqdXN0IGFuIGluaXRpYWwgZGVzaXJlIHRvIGhh dmUgYSBtaW5pbWFsIGFtb3VudCBvZiBzdHVmZiBpbiB0aGUgZXhhbXBsZXMuIEFkZGluZyBhIHNj b3BlIHBhcmFtZXRlciB0byB0aGUgZXhhbXBsZSBhdXRob3JpemF0aW9uIHJlcXVlc3QgKEZpZ3Vy ZSAxKSB3b3VsZCBwcm9iYWJseSBiZSBhIGdvb2QgdGhpbmcgdG8gZG8uIEkmIzM5O2xsIG1ha2Ug YSBub3RlIHRvIGRvIHNvLjxicj48YnI+PC9kaXY+QXMgZmFyIGFzIHRoZSByZWxhdGlvbnNoaXAg YmV0d2VlbiBzY29wZSBhbmQgcmVzb3VyY2UuIFNjb3BlIGlzICp3aGF0KiBhY2Nlc3MgaXMgYmVp bmcgcmVxdWVzdGVkL2dyYW50ZWQuIEFuZCByZXNvdXJjZSBpcyBhYm91dCAqd2hlcmUqIGEgcGFy dGljdWxhciBhY2Nlc3MgdG9rZW4gd2lsbCBiZSB1c2VkLiBJIGVudmlzaW9uIHJlc291cmNlIGFz IGFsbG93aW5nIGZvciBzY29wZSB0byA8YnI+PGJyPjwvZGl2Pk5vdGUgdGhhdCwgYXMgY3VycmVu dGx5IHdyaXR0ZW4gYW55d2F5LCByZXNvdXJjZSBpcyB1bmxpa2Ugc2NvcGUgaW4gdGhhdCBpdCYj Mzk7cyBub3Qgc29tZXRoaW5nIHRoYXQgdGhlIGVuZC11c2VyIGFwcHJvdmVzIG9yIGRlbmllcyBh Y2Nlc3MgdG8gYW5kIGl0JiMzOTtzIG5vdCBzb21ldGhpbmcgdGhhdCBpcyBwZXJzaXN0ZWQgd2l0 aCB0aGUgZ3JhbnQuIEl0IG9ubHkgaW5mb3JtcyB0aGUgYWNjZXNzIHRva2VuIGJlaW5nIHJlcXVl c3RlZCBhdCB0aGUgdGltZS4gU28gaXQmIzM5O2QgYmUgdXNlZCBhdCB0aGUgdG9rZW4gZW5kcG9p bnQgd2hlbiBnZXR0aW5nIGFuIGFjY2VzcyB0b2tlbi4gQW5kIG9ubHkgYXQgdGhlIGF1dGhvcml6 YXRpb24gZW5kcG9pbnQgd2hlbiBhbiBhY2Nlc3MgdG9rZW4gd2lsbCBjb21lIGJhY2sgZGlyZWN0 bHkgaW4gdGhlIGF1dGhvcml6YXRpb24gcmVzcG9uc2UgKGltcGxpY2l0IGZsb3dzKS48YnI+PGJy PjwvZGl2PkN1cnJlbnRseSwgeWVzLCBtdWx0aXBsZSByZXNvdXJjZXMgYXJlIGFsbG93ZWQgYnkg dGhlIGRyYWZ0IHRvIGluZGljYXRlIG11bHRpcGxlIFJTcy7CoCBUaG91Z2ggdGhlcmUmIzM5O3Mg YSBub3RlIGluIHRoZXJlIHF1ZXN0aW9uaW5nIGl0IGJlY2F1c2UgaXQgY29tcGxpY2F0ZXMgdGhp bmdzIGluIHNvbWUgc2l0dWF0aW9ucyB3aGVyZSBkaWZmZXJlbnQgdG9rZW4gY29udGVudCBvciBl bmNyeXB0aW9uIGlzIG5lZWRlZCBmb3IgZGlmZmVyZW50IFJTcyB0aGF0IGFyZSBhc2tlZCBmb3Ig aW4gdGhlIHNhbWUgcmVxdWVzdC7CoCA8YnI+PGRpdj48YnI+PGJyPjxkaXY+IDxkaXY+PGRpdj48 ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBT YXQsIEFwciAyLCAyMDE2IGF0IDg6MDQgQU0sIFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHNwYW4gZGly PSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiIHRhcmdl dD0iX2JsYW5rIj50b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8 YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHgg MHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmct bGVmdDoxZXgiPjxkaXYgZGlyPSJhdXRvIj48ZGl2PjwvZGl2PjxkaXY+SGkgQnJpYW4sPC9kaXY+ PGRpdj48YnI+PC9kaXY+PGRpdj5kaWQgeW91IGludGVudGlvbmFsbHkgb21pdCBzY29wZSB2YWx1 ZXMgaW4geW91ciBleGFtcGxlIHJlcXVlc3RzPyBJIHdvdWxkIGxpa2UgdG8ga25vdyB3aGF0IHlv dSBlbnZpc2lvbiB0byBiZSB0aGUgcmVsYXRpb25zaG9wIGJldHdlZW4gc2NvcGUgYW5kIHJlc291 cmNlLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+QXMgeW91IGRyYWZ0IHNheXMsIHdlIHRvZGF5 IHVzZSBzY29wZSB2YWx1ZXMgdG8gaW5kaWNhdGUgdG8gdGhlIEFTLCB3aGljaCByZXNzb3VyY2Ug c2VydmVycyB0aGUgY2xpZW50cyB3YW50cyB0byBhY2Nlc3MuIEkgdGhpbmsgd2UgbmVhcmx5IGV4 Y2x1c2l2ZWx5IHVzZSBpdCBmb3IgdGhhdCBwdXJwb3NlIGFuZCBvbmx5IHNlbGRvbWx5IHRvIHJl cXVlc3QgY2VydGFpbiBhY2Nlc3MgcmlnaHRzLiBPbmUgb2YgdGhlIGFkdmFudGFnZXMgaXMsIHdl IGNhbiByZXF1ZXN0IGFjY2VzcyB0byBtdWx0aXBsZSByZXNvdXJjZSBzZXJ2ZXJzIHNpbXBsZSBi eSBwdXR0aW5nIG11bHRpcGxlIHNjb3BlIHZhbHVlcyBpbnRvIHRoZSBzY29wZSBwYXJhbWV0ZXIu IFdpbGwgdGhpcyBiZSBwb3NzaWJsZSB3aXRoIHRoZSBleHRlbnNpb24geW91IGFyZSBwcm9wb3Np bmc/PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5CZXN0IHJlZ2FyZHMsPC9kaXY+PGRpdj5Ub3Jz dGVuLjwvZGl2PjxkaXY+PGRpdj48ZGl2Pjxicj5BbSAyMS4wMy4yMDE2IHVtIDE4OjQxIHNjaHJp ZWIgQnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50 aXR5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiZn dDs6PGJyPjxicj48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2PjxkaXYgZGlyPSJs dHIiPlZlcnkgbWlub3IgdXBkYXRlIHRvIHRoaXMgZHJhZnQgYmVmb3JlIHRoZSBkZWFkbGluZSB0 aGF0IG1vdmVzIEhhbm5lcyBmcm9tIEFja25vd2xlZGdlbWVudHMgdG8gQXV0aG9ycyBpbiBhY2tu b3dsZWRnbWVudCBvZiBoaXMgc2ltaWxhciB3b3JrIGEgZmV3IHllYXJzIGFnby4gQWxzbyBmbGVz aGVkIG91dCB0aGUgSUFOQSBzZWN0aW9uIHdpdGggdGhlIGZvcm1hbCByZWdpc3RyYXRpb24gcmVx dWVzdHMuIDxicj48ZGl2Pjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+PGRpdiBkaXI9Imx0 ciI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4tLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNz YWdlIC0tLS0tLS0tLS08YnI+RnJvbTogPGIgY2xhc3M9ImdtYWlsX3NlbmRlcm5hbWUiPjwvYj4g PHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiZndDs8L3Nw YW4+PGJyPkRhdGU6IE1vbiwgTWFyIDIxLCAyMDE2IGF0IDExOjMxIEFNPGJyPlN1YmplY3Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtY2FtcGJlbGwtb2F1dGgtcmVzb3VyY2Ut aW5kaWNhdG9ycy0wMS50eHQ8YnI+VG86IEhhbm5lcyBUc2Nob2ZlbmlnICZsdDs8YSBocmVmPSJt YWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmhhbm5lcy50 c2Nob2ZlbmlnQGdteC5uZXQ8L2E+Jmd0OywgSGFubmVzIFRzY2hvZmVuaWcgJmx0OzxhIGhyZWY9 Im1haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0BnbXgubmV0IiB0YXJnZXQ9Il9ibGFuayI+SGFubmVz LlRzY2hvZmVuaWdAZ214Lm5ldDwvYT4mZ3Q7LCBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0i bWFpbHRvOmJyaWFuLmQuY2FtcGJlbGxAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+YnJpYW4u ZC5jYW1wYmVsbEBnbWFpbC5jb208L2E+Jmd0OywgSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJt YWlsdG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0iX2JsYW5rIj52ZTdqdGJAdmU3anRiLmNv bTwvYT4mZ3Q7PGJyPjxicj48YnI+PGJyPg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWNh bXBiZWxsLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMtMDEudHh0PGJyPg0KaGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBCcmlhbiBDYW1wYmVsbCBhbmQgcG9zdGVkIHRvIHRoZTxi cj4NCklFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpOYW1lOsKgIMKgIMKgIMKgIMKgIMKgZHJh ZnQtY2FtcGJlbGwtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9yczxicj4NClJldmlzaW9uOsKgIMKg IMKgIMKgMDE8YnI+DQpUaXRsZTrCoCDCoCDCoCDCoCDCoCBSZXNvdXJjZSBJbmRpY2F0b3JzIGZv ciBPQXV0aCAyLjA8YnI+DQpEb2N1bWVudCBkYXRlOsKgIDIwMTYtMDMtMjE8YnI+DQpHcm91cDrC oCDCoCDCoCDCoCDCoCBJbmRpdmlkdWFsIFN1Ym1pc3Npb248YnI+DQpQYWdlczrCoCDCoCDCoCDC oCDCoCA4PGJyPg0KVVJMOsKgIMKgIMKgIMKgIMKgIMKgIDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1jYW1wYmVsbC1vYXV0aC1yZXNvdXJjZS1pbmRp Y2F0b3JzLTAxLnR4dCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWNhbXBiZWxsLW9hdXRoLXJlc291cmNl LWluZGljYXRvcnMtMDEudHh0PC9hPjxicj4NClN0YXR1czrCoCDCoCDCoCDCoCDCoDxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNhbXBiZWxsLW9hdXRoLXJl c291cmNlLWluZGljYXRvcnMvIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jYW1wYmVsbC1vYXV0aC1yZXNvdXJj ZS1pbmRpY2F0b3JzLzwvYT48YnI+DQpIdG1saXplZDrCoCDCoCDCoCDCoDxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW1wYmVsbC1vYXV0aC1yZXNvdXJjZS1pbmRp Y2F0b3JzLTAxIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtY2FtcGJlbGwtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0w MTwvYT48YnI+DQpEaWZmOsKgIMKgIMKgIMKgIMKgIMKgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWNhbXBiZWxsLW9hdXRoLXJlc291cmNlLWluZGljYXRv cnMtMDEiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1jYW1wYmVsbC1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3Jz LTAxPC9hPjxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCsKgIMKgVGhpcyBzdHJhdy1tYW4gc3Bl Y2lmaWNhdGlvbiBkZWZpbmVzIGFuIGV4dGVuc2lvbiB0byBUaGUgT0F1dGggMi4wPGJyPg0KwqAg wqBBdXRob3JpemF0aW9uIEZyYW1ld29yayB0aGF0IGVuYWJsZXMgdGhlIGNsaWVudCBhbmQgYXV0 aG9yaXphdGlvbjxicj4NCsKgIMKgc2VydmVyIHRvIG1vcmUgZXhwbGljaXRseSB0byBjb21tdW5p Y2F0ZSBhYm91dCB0aGUgcHJvdGVjdGVkPGJyPg0KwqAgwqByZXNvdXJjZShzKSB0byBiZSBhY2Nl c3NlZC48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1h eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJy Pg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCA8 YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJf YmxhbmsiPnRvb2xzLmlldGYub3JnPC9hPi48YnI+DQo8YnI+DQpUaGUgSUVURiBTZWNyZXRhcmlh dDxicj4NCjxicj4NCjwvZGl2Pjxicj48L2Rpdj4NCjwvZGl2Pjxicj48L2Rpdj48L2Rpdj4NCjwv ZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48L2Rpdj48c3Bhbj48YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij48ZGl2PjxzcGFuPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPC9zcGFuPjxicj48c3Bhbj5PQXV0aCBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPjxzcGFuPjxh IGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYu b3JnPC9hPjwvc3Bhbj48YnI+PHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PC9zcGFuPjxicj48L2Rpdj48L2Jsb2NrcXVvdGU+ PC9zcGFuPjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+PC9kaXY+PC9kaXY+PC9k aXY+PC9kaXY+PC9kaXY+DQo= ----_com.syntomo.email_1639641050344420-- From nobody Tue Apr 5 12:42:28 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F5112D7E0 for ; Tue, 5 Apr 2016 12:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJ8ke5CqkUzi for ; Tue, 5 Apr 2016 12:42:23 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FD0F12D642 for ; Tue, 5 Apr 2016 12:42:21 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id k135so5715152qke.0 for ; Tue, 05 Apr 2016 12:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=hJ99k/gl77SWAJwd7dA8Vm7mS/oe357FunHlgpkFjhM=; b=Cnfd6vs7keBm1nJIsFVj9hXhRfVuB/qGxbdnATiFhUJB0bgr2hFx3rqTU1j8sYc3bc TBBjMhLscVBKX/pn9QS1RTaZlrv3njKxseDoNMzY0Jrl+xtczc3LN0NTE5Au7CLcAv96 oG9CpQfKTQgIyjIz0tTfYmMV/iJqKLZCAbODsDrNEX64nn03AzTvR2AVgLFUifGFICqu LelSSjMNbwtLmcd/CC4dmgsFufFs1+Pt6ph1oEzV2coAzbds/suyeMcacD5y+i7hjGwR 0Qo6q2KQ2205Mr73UusoVL0TG/SXo9qerbeQSAm7SXs9HijUJ8RRdAVMGXYNjpoDWm0Y plgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=hJ99k/gl77SWAJwd7dA8Vm7mS/oe357FunHlgpkFjhM=; b=And9cjtSSek5TyqGNNc1T9aeHgIXBoFjCy+S0VElEHWhFwbMKUz8qXF8P7K8/CMk0a Xubb+173mDsi1r+sbPV1b0F5n789oyNwxNiYBRrycPsigU/SFIqB9KRsaH1PRdNm9d+b RjmxPorAS8vv2MeLtJVNnNbiFTvfaZkx+iXYiato6eOru6D/67JV6nabPB5/qiBSuvWc if5jqcFsk1jNn9Kr5Uuqrw3yp81INtw1xq2MwvE3d+2c7D1Xun0jesYYyvoFfbT+hGZb QHcKQqMGcdIlrTtzpt5A3rwrkIwpDoE6L5f1I1a9mL3lQcKKoMIFGNDMmjYvKiIy2lg9 KYMg== X-Gm-Message-State: AD7BkJIWEWAUyx7zsxDlG1hRjt8C/KZH4VjjZhoDCPvSi5axIVziuwk2CpGQZQC+UUZAyA== X-Received: by 10.55.73.85 with SMTP id w82mr43307145qka.52.1459885329688; Tue, 05 Apr 2016 12:42:09 -0700 (PDT) Received: from ?IPv6:2001:67c:370:144:e0dc:dc4e:a1c9:7cb6? ([2001:67c:370:144:e0dc:dc4e:a1c9:7cb6]) by smtp.gmail.com with ESMTPSA id v74sm15245626qkl.36.2016.04.05.12.42.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 05 Apr 2016 12:42:08 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_BAE08089-6EBE-4A4E-A8B5-76F8978D0BFF" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: Date: Tue, 5 Apr 2016 16:42:06 -0300 Message-Id: <2EC38A43-5E21-4A5A-ACEF-7BA8E2233981@ve7jtb.com> References: <20160321173103.31961.76817.idtracker@ietfa.amsl.com> <7CDE7D76-4E6C-4060-A0AB-C7D0FE8C9246@lodderstedt.net> To: "torsten@lodderstedt.net" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-resource-indicators-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 19:42:27 -0000 --Apple-Mail=_BAE08089-6EBE-4A4E-A8B5-76F8978D0BFF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 At this point we are not considering changing the vague nature of = scopes. A scope might still grant permission at the API level or finer grained. With things like the FIRE health record API there are standard scopes so = I am assuming that if the client wants scope x, y ,z for health provider = A & B it would ask for 3 scopes and two resources in the authorization = request. The user might not grant all scopes doe all endpoints. When the client asks for a AT for RS A that might have different scopes = than the one for RS B. If the client wants to ask for different scopes for different resources = then it would need to do two authorization requests. Creating a request that could say give me x & y for A and z for B is = probably farther than we want to go. It is a interesting point for the WG to consider. John B. > On Apr 5, 2016, at 12:41 PM, torsten@lodderstedt.net wrote: >=20 > Hi Brian, >=20 > I assume resource server ids or URIs to be a names namespace for scope = values or that scope values are be bound to certain resource servers. It = seems you have less coupling in mind? >=20 > Best regards, > Torsten. >=20 > Sent by MailWise =E2=80=93 = See your emails as clean, short chats. >=20 >=20 >=20 > -------- Originalnachricht -------- > Betreff: Re: [OAUTH-WG] Fwd: New Version Notification for = draft-campbell-oauth-resource-indicators-01.txt > Von: Brian Campbell > An: Torsten Lodderstedt > Cc: oauth >=20 > Sorry for the slow response, Torsten, I was on vacation last week with = my family.=20 >=20 > The omission of scope values in the example requests wasn't really = intentional so much as just an initial desire to have a minimal amount = of stuff in the examples. Adding a scope parameter to the example = authorization request (Figure 1) would probably be a good thing to do. = I'll make a note to do so. >=20 > As far as the relationship between scope and resource. Scope is *what* = access is being requested/granted. And resource is about *where* a = particular access token will be used. I envision resource as allowing = for scope to=20 >=20 > Note that, as currently written anyway, resource is unlike scope in = that it's not something that the end-user approves or denies access to = and it's not something that is persisted with the grant. It only informs = the access token being requested at the time. So it'd be used at the = token endpoint when getting an access token. And only at the = authorization endpoint when an access token will come back directly in = the authorization response (implicit flows). >=20 > Currently, yes, multiple resources are allowed by the draft to = indicate multiple RSs. Though there's a note in there questioning it = because it complicates things in some situations where different token = content or encryption is needed for different RSs that are asked for in = the same request. =20 >=20 >=20 >=20 > On Sat, Apr 2, 2016 at 8:04 AM, Torsten Lodderstedt = > wrote: > Hi Brian, >=20 > did you intentionally omit scope values in your example requests? I = would like to know what you envision to be the relationshop between = scope and resource. >=20 > As you draft says, we today use scope values to indicate to the AS, = which ressource servers the clients wants to access. I think we nearly = exclusively use it for that purpose and only seldomly to request certain = access rights. One of the advantages is, we can request access to = multiple resource servers simple by putting multiple scope values into = the scope parameter. Will this be possible with the extension you are = proposing? >=20 > Best regards, > Torsten. >=20 > Am 21.03.2016 um 18:41 schrieb Brian Campbell = >: >=20 >> Very minor update to this draft before the deadline that moves Hannes = from Acknowledgements to Authors in acknowledgment of his similar work a = few years ago. Also fleshed out the IANA section with the formal = registration requests.=20 >>=20 >>=20 >> ---------- Forwarded message ---------- >> From: > >> Date: Mon, Mar 21, 2016 at 11:31 AM >> Subject: New Version Notification for = draft-campbell-oauth-resource-indicators-01.txt >> To: Hannes Tschofenig >, Hannes Tschofenig = >, Brian = Campbell >, John Bradley > >>=20 >>=20 >>=20 >> A new version of I-D, draft-campbell-oauth-resource-indicators-01.txt >> has been successfully submitted by Brian Campbell and posted to the >> IETF repository. >>=20 >> Name: draft-campbell-oauth-resource-indicators >> Revision: 01 >> Title: Resource Indicators for OAuth 2.0 >> Document date: 2016-03-21 >> Group: Individual Submission >> Pages: 8 >> URL: = https://www.ietf.org/internet-drafts/draft-campbell-oauth-resource-indicat= ors-01.txt = >> Status: = https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/= = >> Htmlized: = https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01 = >> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-campbell-oauth-resource-indicato= rs-01 = >>=20 >> Abstract: >> This straw-man specification defines an extension to The OAuth 2.0 >> Authorization Framework that enables the client and authorization >> server to more explicitly to communicate about the protected >> resource(s) to be accessed. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org = . >>=20 >> The IETF Secretariat >>=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=_BAE08089-6EBE-4A4E-A8B5-76F8978D0BFF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 At this point we are not considering changing the vague = nature of scopes.

A = scope might still grant permission at the API level or finer = grained.

With = things like the FIRE health record API there are standard scopes so I am = assuming that if the client wants scope x, y ,z for health provider A = & B it would ask for 3 scopes and two resources in the authorization = request.    The user might not grant all scopes doe all = endpoints.

When = the client asks for a AT for RS A that might have different scopes than = the one for RS B.

If the client wants to ask for different scopes for different = resources then it would need to do two authorization requests.

Creating a request that = could say give me x & y for A and z for B is probably farther than = we want to go.

It is a interesting point for the WG to consider.

John B.

On Apr 5, 2016, at 12:41 PM, torsten@lodderstedt.net wrote:

Hi Brian,

I assume resource = server ids or URIs to be a names namespace for scope values or that = scope values are be bound to certain resource servers. It seems you have = less coupling in mind?

Best regards,
Torsten.

Sent by MailWise = =E2=80=93 See your emails as clean, short chats.



-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] Fwd: New Version Notification for = draft-campbell-oauth-resource-indicators-01.txt
Von: Brian = Campbell <bcampbell@pingidentity.com>
An: Torsten = Lodderstedt <torsten@lodderstedt.net>
Cc: oauth = <oauth@ietf.org>
Sorry for the slow response, = Torsten, I was on vacation last week with my family.

The omission of scope = values in the example requests wasn't really intentional so much as just = an initial desire to have a minimal amount of stuff in the examples. = Adding a scope parameter to the example authorization request (Figure 1) = would probably be a good thing to do. I'll make a note to do so.

As far as the relationship between scope = and resource. Scope is *what* access is being requested/granted. And = resource is about *where* a particular access token will be used. I = envision resource as allowing for scope to

Note that, as currently written anyway, resource is = unlike scope in that it's not something that the end-user approves or = denies access to and it's not something that is persisted with the = grant. It only informs the access token being requested at the time. So = it'd be used at the token endpoint when getting an access token. And = only at the authorization endpoint when an access token will come back = directly in the authorization response (implicit flows).
Currently, yes, multiple resources are allowed by the = draft to indicate multiple RSs.  Though there's a note in there = questioning it because it complicates things in some situations where = different token content or encryption is needed for different RSs that = are asked for in the same request. 



On Sat, Apr 2, 2016 at 8:04 AM, Torsten = Lodderstedt <torsten@lodderstedt.net> wrote:
Hi = Brian,

did you = intentionally omit scope values in your example requests? I would like = to know what you envision to be the relationshop between scope and = resource.

As = you draft says, we today use scope values to indicate to the AS, which = ressource servers the clients wants to access. I think we nearly = exclusively use it for that purpose and only seldomly to request certain = access rights. One of the advantages is, we can request access to = multiple resource servers simple by putting multiple scope values into = the scope parameter. Will this be possible with the extension you are = proposing?

Best = regards,
Torsten.

Am 21.03.2016 um 18:41 schrieb = Brian Campbell <bcampbell@pingidentity.com>:

Very minor update to this draft = before the deadline that moves Hannes from Acknowledgements to Authors = in acknowledgment of his similar work a few years ago. Also fleshed out = the IANA section with the formal registration requests.


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, Mar 21, 2016 at 11:31 AM
Subject: = New Version Notification for = draft-campbell-oauth-resource-indicators-01.txt
To: Hannes = Tschofenig <hannes.tschofenig@gmx.net>, Hannes = Tschofenig <Hannes.Tschofenig@gmx.net>, Brian = Campbell <brian.d.campbell@gmail.com>, John = Bradley <ve7jtb@ve7jtb.com>



A new version of I-D, draft-campbell-oauth-resource-indicators-01.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name:          =  draft-campbell-oauth-resource-indicators
Revision:       01
Title:          Resource Indicators for OAuth = 2.0
Document date:  2016-03-21
Group:          Individual Submission
Pages:          8
URL:            https://www.ietf.org/internet-drafts/draft-campbell-oauth-resou= rce-indicators-01.txt
Status:         https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-= indicators/
Htmlized:       https://tools.ietf.org/html/draft-campbell-oauth-resource-indic= ators-01
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-campbell-oauth-resour= ce-indicators-01

Abstract:
   This straw-man specification defines an extension to The = OAuth 2.0
   Authorization Framework that enables the client and = authorization
   server to more explicitly to communicate about the = protected
   resource(s) to be accessed.




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

The IETF Secretariat



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

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

= --Apple-Mail=_BAE08089-6EBE-4A4E-A8B5-76F8978D0BFF-- From nobody Tue Apr 5 14:59:41 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F3E12D1F0; Tue, 5 Apr 2016 14:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbC_o41gzxGH; Tue, 5 Apr 2016 14:59:39 -0700 (PDT) Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72B3A12D192; Tue, 5 Apr 2016 14:59:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1459893579; x=1491429579; h=from:to:subject:date:message-id:mime-version; bh=gAftxoS5BnKmuraUVq7cCiLsKxxSH5jtpedelAS+lnI=; b=oXCztm3rrucAwb6CY8fT3E5FUqPu3PXNiZ0URo/tx8tkaZQkuJiFJglN OgtE7OOGRL6Ea+bUGW/saddcHd89eKE/Kt0IWURZVzw0V9xpW3cJVAcNV I3ZUiyinymEGmomlzL7OYOg6M2aKrT94A/xYZgwetAUdQcdf4lnWFzjhc M=; X-IronPort-AV: E=Sophos;i="5.24,445,1454976000"; d="scan'208,217";a="483233609" Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-71005.iad55.amazon.com) ([10.43.8.2]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Apr 2016 21:59:37 +0000 Received: from ex10-hub-7002.ant.amazon.com (iad1-ws-svc-lb91-vlan2.amazon.com [10.0.103.146]) by email-inbound-relay-71005.iad55.amazon.com (8.14.7/8.14.7) with ESMTP id u35Lwl6F003619 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Apr 2016 21:59:36 GMT Received: from EX13D03UWA001.ant.amazon.com (10.43.160.141) by ex10-hub-7002.ant.amazon.com (10.43.110.153) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 5 Apr 2016 14:59:24 -0700 Received: from EX13D03UWA001.ant.amazon.com (10.43.160.141) by EX13D03UWA001.ant.amazon.com (10.43.160.141) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 5 Apr 2016 21:59:22 +0000 Received: from EX13D03UWA001.ant.amazon.com ([10.43.160.141]) by EX13D03UWA001.ant.amazon.com ([10.43.160.141]) with mapi id 15.00.1104.000; Tue, 5 Apr 2016 21:59:22 +0000 From: "Hardt, Dick" To: "scim@ietf.org" , "oauth@ietf.org" Thread-Topic: Simple Federation Deployment Thread-Index: AQHRj4ZpF7B+0HEfvEK1Conjtst8Ig== Date: Tue, 5 Apr 2016 21:59:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.161.78] Content-Type: multipart/alternative; boundary="_000_F5394E82327845D087AE42FC8742F252amazoncom_" MIME-Version: 1.0 Precedence: Bulk Archived-At: Subject: [OAUTH-WG] Simple Federation Deployment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 21:59:41 -0000 --_000_F5394E82327845D087AE42FC8742F252amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VXNlIGNhc2U6IEFuIGFkbWluIGZvciBhbiBvcmdhbml6YXRpb24gd291bGQgbGlrZSB0byBlbmFi bGUgaGVyIHVzZXJzIHRvIGFjY2VzcyBhIFNhYVMgYXBwbGljYXRpb24gYXQgaGVyIElkUC4NCg0K VXNlciBleHBlcmllbmNlOg0KDQogIDEuICBBZG1pbiBhdXRoZW50aWNhdGVzIHRvIElkUCBpbiBi cm93c2VyDQogIDIuICBBZG1pbiBzZWxlY3RzIFNhYVMgYXBwIHRvIGZlZGVyYXRlIHdpdGggZnJv bSBsaXN0IGF0IElkUA0KICAzLiAgSWRQIG9wdGlvbmFsbHkgcHJlc2VudHMgY29uZmlnIG9wdGlv bnMNCiAgNC4gIElkUCByZWRpcmVjdHMgQWRtaW4gdG8gU2FhUyBhcHANCiAgNS4gIEFkbWluIGF1 dGhlbnRpY2F0ZXMgdG8gU2FhUyBhcHANCiAgNi4gIFNhYVMgYXBwIG9wdGlvbmFsbHkgZ2F0aGVy cyBjb25maWcgb3B0aW9ucw0KICA3LiAgU2FhUyBhcHAgcmVkaXJlY3RzIGFkbWluIHRvIElkUA0K ICA4LiAgSWRQIGNvbmZpcm1zIHN1Y2Nlc3NmdWwgZmVkZXJhdGlvbiA9PiBPSURDIC8gU0FNTCBh bmQgU0NJTSBhcmUgbm93IGNvbmZpZ3VyZWQgYW5kIHdvcmtpbmcgYmV0d2VlbiBJZFAgYW5kIFNh YVMgQXBwDQoNCldobyBlbHNlIGlzIGludGVyZXN0ZWQgaW4gc29sdmluZyB0aGlzPw0KDQpJcyB0 aGVyZSBpbnRlcmVzdCBpbiB3b3JraW5nIG9uIHRoaXMgaW4gZWl0aGVyIFNDSU0gb3IgT0FVVEgg V2dzPw0KDQpBbnkgb25lIGluIEJBIGludGVyZXN0ZWQgaW4gbWVldGluZyBvbiB0aGlzIHRvcGlj IHRoaXMgd2Vlaz8NCg0K4oCUIERpY2sNCg== --_000_F5394E82327845D087AE42FC8742F252amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5Vc2UgY2FzZTog QW4gYWRtaW4gZm9yIGFuIG9yZ2FuaXphdGlvbiB3b3VsZCBsaWtlIHRvIGVuYWJsZSBoZXIgdXNl cnMgdG8gYWNjZXNzIGEgU2FhUyBhcHBsaWNhdGlvbiBhdCBoZXIgSWRQLiZuYnNwOzwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VXNlciBleHBlcmllbmNlOiZuYnNwOzwvZGl2Pg0KPG9s Pg0KPGxpPkFkbWluIGF1dGhlbnRpY2F0ZXMgdG8gSWRQIGluIGJyb3dzZXI8L2xpPjxsaT5BZG1p biBzZWxlY3RzIFNhYVMgYXBwIHRvIGZlZGVyYXRlIHdpdGggZnJvbSBsaXN0IGF0IElkUDwvbGk+ PGxpPklkUCBvcHRpb25hbGx5IHByZXNlbnRzIGNvbmZpZyBvcHRpb25zPC9saT48bGk+SWRQIHJl ZGlyZWN0cyBBZG1pbiB0byBTYWFTIGFwcDwvbGk+PGxpPkFkbWluIGF1dGhlbnRpY2F0ZXMgdG8g U2FhUyBhcHA8L2xpPjxsaT5TYWFTIGFwcCBvcHRpb25hbGx5IGdhdGhlcnMgY29uZmlnIG9wdGlv bnM8L2xpPjxsaT5TYWFTIGFwcCByZWRpcmVjdHMgYWRtaW4gdG8gSWRQPC9saT48bGk+SWRQIGNv bmZpcm1zIHN1Y2Nlc3NmdWwgZmVkZXJhdGlvbiA9Jmd0OyBPSURDIC8gU0FNTCBhbmQgU0NJTSBh cmUgbm93IGNvbmZpZ3VyZWQgYW5kIHdvcmtpbmcgYmV0d2VlbiBJZFAgYW5kIFNhYVMgQXBwPC9s aT48L29sPg0KPGRpdj5XaG8gZWxzZSBpcyBpbnRlcmVzdGVkIGluIHNvbHZpbmcgdGhpcz88L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PklzIHRoZXJlIGludGVyZXN0IGluIHdvcmtpbmcg b24gdGhpcyBpbiBlaXRoZXIgU0NJTSBvciBPQVVUSCBXZ3M/PC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5Bbnkgb25lIGluIEJBIGludGVyZXN0ZWQgaW4gbWVldGluZyBvbiB0aGlzIHRv cGljIHRoaXMgd2Vlaz88L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PuKAlCBEaWNrPC9k aXY+DQo8ZGl2Pg0KPGRpdiBpZD0iTUFDX09VVExPT0tfU0lHTkFUVVJFIj48L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F5394E82327845D087AE42FC8742F252amazoncom_-- From nobody Tue Apr 5 15:11:27 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D41012D877; Tue, 5 Apr 2016 15:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uv_GMKBlUW6O; Tue, 5 Apr 2016 15:11:22 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0FBB12D0F4; Tue, 5 Apr 2016 15:11:22 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u35MBKIR006526 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Apr 2016 22:11:20 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u35MBJwC009533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Apr 2016 22:11:20 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u35MBJ2I018720; Tue, 5 Apr 2016 22:11:19 GMT Received: from [31.133.161.104] (/31.133.161.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 05 Apr 2016 15:11:19 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-F1D45B87-372B-4321-A798-33B7273126BC Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13E238) In-Reply-To: Date: Tue, 5 Apr 2016 19:11:16 -0300 Content-Transfer-Encoding: 7bit Message-Id: <086477E4-5F4E-4C52-AC91-E26824A9FA7A@oracle.com> References: To: "Hardt, Dick" X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: "scim@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 22:11:24 -0000 --Apple-Mail-F1D45B87-372B-4321-A798-33B7273126BC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Is the idp the center of all things for these users? Usually you have a provisioning system that coordinates state and uses thing= s like scim connectors to do this.=20 Another approach from today would be to pass a scim event to the remote prov= ider which then decides what needs to be done to facilitate the thingd you d= escribe.=20 Iow. Either the idp (sender) or the sp (receiver) have a provisioning system= to do this.=20 The solution and the simplicity depends on where the control needs to be.=20= Phil > On Apr 5, 2016, at 18:59, Hardt, Dick wrote: >=20 > Use case: An admin for an organization would like to enable her users to a= ccess a SaaS application at her IdP.=20 >=20 > User experience:=20 > Admin authenticates to IdP in browser > Admin selects SaaS app to federate with from list at IdP > IdP optionally presents config options > IdP redirects Admin to SaaS app > Admin authenticates to SaaS app > SaaS app optionally gathers config options > SaaS app redirects admin to IdP > IdP confirms successful federation =3D> OIDC / SAML and SCIM are now confi= gured and working between IdP and SaaS App > Who else is interested in solving this? >=20 > Is there interest in working on this in either SCIM or OAUTH Wgs? >=20 > Any one in BA interested in meeting on this topic this week? >=20 > =E2=80=94 Dick > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-F1D45B87-372B-4321-A798-33B7273126BC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Is the idp the center of all things fo= r these users?

Usually you have a provisioning system that coordinates stat= e and uses things like scim connectors to do this. 

Another approach f= rom today would be to pass a scim event to the remote provider which then de= cides what needs to be done to facilitate the thingd you describe. 

Io= w. Either the idp (sender) or the sp (receiver) have a provisioning system t= o do this. 

The solution and the simplicity depends on where the contr= ol needs to be. 

Phil

On Apr 5, 2016, at 18:59, Ha= rdt, Dick <dick@amazon.com> wro= te:

Use case: An admin for an organization would like to enable her users t= o access a SaaS application at her IdP. 

User experience: 
  1. Admin authenticates to IdP in browser
  2. Admin selects SaaS app to f= ederate with from list at IdP
  3. IdP optionally presents config options=
  4. IdP redirects Admin to SaaS app
  5. Admin authenticates to SaaS= app
  6. SaaS app optionally gathers config options
  7. SaaS app red= irects admin to IdP
  8. IdP confirms successful federation =3D> OIDC /= SAML and SCIM are now configured and working between IdP and SaaS App
    9. <= /ol>
    Who else is interested in solving this?

    Is there interest in working on this in either SCIM or OAUTH Wgs?
    =

    Any one in BA interested in meeting on this topic this week?

    =E2=80=94 Dick
____________________= ___________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman= /listinfo/scim
= --Apple-Mail-F1D45B87-372B-4321-A798-33B7273126BC-- From nobody Tue Apr 5 15:29:07 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA0512D654; Tue, 5 Apr 2016 15:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpiCIle3mYVp; Tue, 5 Apr 2016 15:29:03 -0700 (PDT) Received: from smtp-fw-9102.amazon.com (smtp-fw-9102.amazon.com [207.171.184.29]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30BC912D14D; Tue, 5 Apr 2016 15:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1459895343; x=1491431343; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VKJs/DMZq3+sizJR62+pmJtFLX2oxplT/eFRj8qCNTQ=; b=ced/LyQpc43YguMqIs1xDp76c+Q5fQbMpCXKT0pNhg94DQoSlQWt5iYr xCRyzL6TWG9qHTGkCilcNr8b199A2Vx4i+1mnoldjSCNWdl/GTXw5Fuo5 B4k19CDs1v7ZyGWklDDKkZ1Khcm8mpvVoQ/LcHCOD+lqvh4iqaX+rb7Mf 4=; X-IronPort-AV: E=Sophos;i="5.24,445,1454976000"; d="scan'208,217";a="416207516" Received: from sea19-co-svc-lb5-vlan2.sea.amazon.com (HELO email-inbound-relay-25001.iad12.amazon.com) ([10.47.22.162]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Apr 2016 22:26:16 +0000 Received: from ex10-hub-7001.ant.amazon.com (iad1-ws-svc-lb91-vlan2.amazon.com [10.0.103.146]) by email-inbound-relay-25001.iad12.amazon.com (8.14.7/8.14.7) with ESMTP id u35MQ0x9006927 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Apr 2016 22:26:14 GMT Received: from EX13D03UWA003.ant.amazon.com (10.43.160.39) by ex10-hub-7001.ant.amazon.com (10.43.103.49) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 5 Apr 2016 15:25:56 -0700 Received: from EX13D03UWA001.ant.amazon.com (10.43.160.141) by EX13D03UWA003.ant.amazon.com (10.43.160.39) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 5 Apr 2016 22:25:55 +0000 Received: from EX13D03UWA001.ant.amazon.com ([10.43.160.141]) by EX13D03UWA001.ant.amazon.com ([10.43.160.141]) with mapi id 15.00.1104.000; Tue, 5 Apr 2016 22:25:55 +0000 From: "Hardt, Dick" To: "Phil Hunt (IDM)" Thread-Topic: [scim] Simple Federation Deployment Thread-Index: AQHRj4ZpF7B+0HEfvEK1Conjtst8Ip978RgA///R1QA= Date: Tue, 5 Apr 2016 22:25:54 +0000 Message-ID: <78D87E6B-DBFE-46D9-B7FA-15201924DA12@amazon.com> References: <086477E4-5F4E-4C52-AC91-E26824A9FA7A@oracle.com> In-Reply-To: <086477E4-5F4E-4C52-AC91-E26824A9FA7A@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.160.131] Content-Type: multipart/alternative; boundary="_000_78D87E6BDBFE46D9B7FA15201924DA12amazoncom_" MIME-Version: 1.0 Archived-At: Cc: "scim@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 22:29:05 -0000 --_000_78D87E6BDBFE46D9B7FA15201924DA12amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gdGFsa2luZyBhYm91dCByZW1vdmluZyBtYW51YWwgc3RlcHMgaW4gd2hhdCBoYXBwZW5z IHRvZGF5IHdoZXJlIGNvbmZpZ3VyaW5nIGEgU2FhUyBhcHAgYXQgYW4gSWRQIChzdWNoIGFzIEdv b2dsZSwgQXp1cmUsIFBpbmcsIE9jdGEpIHJlcXVpcmVzIGlzIGEgYnVuY2ggb2YgY3V0dGluZyBh bmQgcGFzdGluZyBvZiBhY2Nlc3MgdG9rZW5zIC8ga2V5cyAvIGNlcnRzIGFuZCBkb2luZyBhIGJ1 bmNoIG9mICBjb25maWcgdGhhdCBpcyBlcnJvciBwcm9uZSBhbmQgdW5pcXVlIGZvciBlYWNoIHJl bGF0aW9uc2hpcC4NCg0KRG9u4oCZdCB3YW50IHRvIHNvbHZlIG9uIHRoZSB0aHJlYWQg4oCmIGxv b2tpbmcgdG8gc2VlIGlmIHRoZXJlIGlzIGludGVyZXN0IQ0KDQpPbiA0LzUvMTYsIDc6MTEgUE0s IHNvbWVvbmUgY2xhaW1pbmcgdG8gYmUgInNjaW0gb24gYmVoYWxmIG9mIFBoaWwgSHVudCAoSURN KSIgPHNjaW0tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnPiBv biBiZWhhbGYgb2YgcGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUu Y29tPj4gd3JvdGU6DQoNCklzIHRoZSBpZHAgdGhlIGNlbnRlciBvZiBhbGwgdGhpbmdzIGZvciB0 aGVzZSB1c2Vycz8NCg0KVXN1YWxseSB5b3UgaGF2ZSBhIHByb3Zpc2lvbmluZyBzeXN0ZW0gdGhh dCBjb29yZGluYXRlcyBzdGF0ZSBhbmQgdXNlcyB0aGluZ3MgbGlrZSBzY2ltIGNvbm5lY3RvcnMg dG8gZG8gdGhpcy4NCg0KQW5vdGhlciBhcHByb2FjaCBmcm9tIHRvZGF5IHdvdWxkIGJlIHRvIHBh c3MgYSBzY2ltIGV2ZW50IHRvIHRoZSByZW1vdGUgcHJvdmlkZXIgd2hpY2ggdGhlbiBkZWNpZGVz IHdoYXQgbmVlZHMgdG8gYmUgZG9uZSB0byBmYWNpbGl0YXRlIHRoZSB0aGluZ2QgeW91IGRlc2Ny aWJlLg0KDQpJb3cuIEVpdGhlciB0aGUgaWRwIChzZW5kZXIpIG9yIHRoZSBzcCAocmVjZWl2ZXIp IGhhdmUgYSBwcm92aXNpb25pbmcgc3lzdGVtIHRvIGRvIHRoaXMuDQoNClRoZSBzb2x1dGlvbiBh bmQgdGhlIHNpbXBsaWNpdHkgZGVwZW5kcyBvbiB3aGVyZSB0aGUgY29udHJvbCBuZWVkcyB0byBi ZS4NCg0KUGhpbA0KDQpPbiBBcHIgNSwgMjAxNiwgYXQgMTg6NTksIEhhcmR0LCBEaWNrIDxkaWNr QGFtYXpvbi5jb208bWFpbHRvOmRpY2tAYW1hem9uLmNvbT4+IHdyb3RlOg0KDQpVc2UgY2FzZTog QW4gYWRtaW4gZm9yIGFuIG9yZ2FuaXphdGlvbiB3b3VsZCBsaWtlIHRvIGVuYWJsZSBoZXIgdXNl cnMgdG8gYWNjZXNzIGEgU2FhUyBhcHBsaWNhdGlvbiBhdCBoZXIgSWRQLg0KDQpVc2VyIGV4cGVy aWVuY2U6DQoNCiAgMS4gIEFkbWluIGF1dGhlbnRpY2F0ZXMgdG8gSWRQIGluIGJyb3dzZXINCiAg Mi4gIEFkbWluIHNlbGVjdHMgU2FhUyBhcHAgdG8gZmVkZXJhdGUgd2l0aCBmcm9tIGxpc3QgYXQg SWRQDQogIDMuICBJZFAgb3B0aW9uYWxseSBwcmVzZW50cyBjb25maWcgb3B0aW9ucw0KICA0LiAg SWRQIHJlZGlyZWN0cyBBZG1pbiB0byBTYWFTIGFwcA0KICA1LiAgQWRtaW4gYXV0aGVudGljYXRl cyB0byBTYWFTIGFwcA0KICA2LiAgU2FhUyBhcHAgb3B0aW9uYWxseSBnYXRoZXJzIGNvbmZpZyBv cHRpb25zDQogIDcuICBTYWFTIGFwcCByZWRpcmVjdHMgYWRtaW4gdG8gSWRQDQogIDguICBJZFAg Y29uZmlybXMgc3VjY2Vzc2Z1bCBmZWRlcmF0aW9uID0+IE9JREMgLyBTQU1MIGFuZCBTQ0lNIGFy ZSBub3cgY29uZmlndXJlZCBhbmQgd29ya2luZyBiZXR3ZWVuIElkUCBhbmQgU2FhUyBBcHANCg0K V2hvIGVsc2UgaXMgaW50ZXJlc3RlZCBpbiBzb2x2aW5nIHRoaXM/DQoNCklzIHRoZXJlIGludGVy ZXN0IGluIHdvcmtpbmcgb24gdGhpcyBpbiBlaXRoZXIgU0NJTSBvciBPQVVUSCBXZ3M/DQoNCkFu eSBvbmUgaW4gQkEgaW50ZXJlc3RlZCBpbiBtZWV0aW5nIG9uIHRoaXMgdG9waWMgdGhpcyB3ZWVr Pw0KDQrigJQgRGljaw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCnNjaW0gbWFpbGluZyBsaXN0DQpzY2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltDQo= --_000_78D87E6BDBFE46D9B7FA15201924DA12amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <99678ED67605434DA60D2B06666A3FAD@ant.amazon.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+SeKA mW0gdGFsa2luZyBhYm91dCByZW1vdmluZyBtYW51YWwgc3RlcHMgaW4gd2hhdCBoYXBwZW5zIHRv ZGF5IHdoZXJlIGNvbmZpZ3VyaW5nIGEgU2FhUyBhcHAgYXQgYW4gSWRQIChzdWNoIGFzIEdvb2ds ZSwgQXp1cmUsIFBpbmcsIE9jdGEpIHJlcXVpcmVzIGlzIGEgYnVuY2ggb2YgY3V0dGluZyBhbmQg cGFzdGluZyBvZiBhY2Nlc3MgdG9rZW5zIC8ga2V5cyAvIGNlcnRzIGFuZCBkb2luZyBhIGJ1bmNo IG9mICZuYnNwO2NvbmZpZyB0aGF0IGlzIGVycm9yDQogcHJvbmUgYW5kIHVuaXF1ZSBmb3IgZWFj aCByZWxhdGlvbnNoaXAuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Eb27igJl0IHdh bnQgdG8gc29sdmUgb24gdGhlIHRocmVhZCDigKYgbG9va2luZyB0byBzZWUgaWYgdGhlcmUgaXMg aW50ZXJlc3QhPC9kaXY+DQo8ZGl2Pg0KPGRpdiBpZD0iTUFDX09VVExPT0tfU0lHTkFUVVJFIj48 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19T UkNfQk9EWV9TRUNUSU9OIj4NCjxkaXY+DQo8ZGl2Pk9uIDQvNS8xNiwgNzoxMSBQTSwgc29tZW9u ZSBjbGFpbWluZyB0byBiZSAmcXVvdDtzY2ltIG9uIGJlaGFsZiBvZiBQaGlsIEh1bnQgKElETSkm cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmciPnNjaW0tYm91 bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVoYWxmIG9mDQo8YSBocmVmPSJtYWlsdG86cGhpbC5odW50 QG9yYWNsZS5jb20iPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRU UklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7 IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2IGRpcj0iYXV0 byI+DQo8ZGl2PklzIHRoZSBpZHAgdGhlIGNlbnRlciBvZiBhbGwgdGhpbmdzIGZvciB0aGVzZSB1 c2Vycz88L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+PGJyPg0KPC9kaXY+DQo8 ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPlVzdWFsbHkgeW91IGhhdmUgYSBwcm92aXNpb25p bmcgc3lzdGVtIHRoYXQgY29vcmRpbmF0ZXMgc3RhdGUgYW5kIHVzZXMgdGhpbmdzIGxpa2Ugc2Np bSBjb25uZWN0b3JzIHRvIGRvIHRoaXMuJm5ic3A7PC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxT aWduYXR1cmUiPjxicj4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj5Bbm90 aGVyIGFwcHJvYWNoIGZyb20gdG9kYXkgd291bGQgYmUgdG8gcGFzcyBhIHNjaW0gZXZlbnQgdG8g dGhlIHJlbW90ZSBwcm92aWRlciB3aGljaCB0aGVuIGRlY2lkZXMgd2hhdCBuZWVkcyB0byBiZSBk b25lIHRvIGZhY2lsaXRhdGUgdGhlIHRoaW5nZCB5b3UgZGVzY3JpYmUuJm5ic3A7PC9kaXY+DQo8 ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPjxicj4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVN YWlsU2lnbmF0dXJlIj5Jb3cuIEVpdGhlciB0aGUgaWRwIChzZW5kZXIpIG9yIHRoZSBzcCAocmVj ZWl2ZXIpIGhhdmUgYSBwcm92aXNpb25pbmcgc3lzdGVtIHRvIGRvIHRoaXMuJm5ic3A7PC9kaXY+ DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPjxicj4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBw bGVNYWlsU2lnbmF0dXJlIj5UaGUgc29sdXRpb24gYW5kIHRoZSBzaW1wbGljaXR5IGRlcGVuZHMg b24gd2hlcmUgdGhlIGNvbnRyb2wgbmVlZHMgdG8gYmUuJm5ic3A7PGJyPg0KPGJyPg0KUGhpbDwv ZGl2Pg0KPGRpdj48YnI+DQpPbiBBcHIgNSwgMjAxNiwgYXQgMTg6NTksIEhhcmR0LCBEaWNrICZs dDs8YSBocmVmPSJtYWlsdG86ZGlja0BhbWF6b24uY29tIj5kaWNrQGFtYXpvbi5jb208L2E+Jmd0 OyB3cm90ZTo8YnI+DQo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRp dj4NCjxkaXY+VXNlIGNhc2U6IEFuIGFkbWluIGZvciBhbiBvcmdhbml6YXRpb24gd291bGQgbGlr ZSB0byBlbmFibGUgaGVyIHVzZXJzIHRvIGFjY2VzcyBhIFNhYVMgYXBwbGljYXRpb24gYXQgaGVy IElkUC4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlVzZXIgZXhwZXJpZW5j ZTombmJzcDs8L2Rpdj4NCjxvbD4NCjxsaT5BZG1pbiBhdXRoZW50aWNhdGVzIHRvIElkUCBpbiBi cm93c2VyPC9saT48bGk+QWRtaW4gc2VsZWN0cyBTYWFTIGFwcCB0byBmZWRlcmF0ZSB3aXRoIGZy b20gbGlzdCBhdCBJZFA8L2xpPjxsaT5JZFAgb3B0aW9uYWxseSBwcmVzZW50cyBjb25maWcgb3B0 aW9uczwvbGk+PGxpPklkUCByZWRpcmVjdHMgQWRtaW4gdG8gU2FhUyBhcHA8L2xpPjxsaT5BZG1p biBhdXRoZW50aWNhdGVzIHRvIFNhYVMgYXBwPC9saT48bGk+U2FhUyBhcHAgb3B0aW9uYWxseSBn YXRoZXJzIGNvbmZpZyBvcHRpb25zPC9saT48bGk+U2FhUyBhcHAgcmVkaXJlY3RzIGFkbWluIHRv IElkUDwvbGk+PGxpPklkUCBjb25maXJtcyBzdWNjZXNzZnVsIGZlZGVyYXRpb24gPSZndDsgT0lE QyAvIFNBTUwgYW5kIFNDSU0gYXJlIG5vdyBjb25maWd1cmVkIGFuZCB3b3JraW5nIGJldHdlZW4g SWRQIGFuZCBTYWFTIEFwcDwvbGk+PC9vbD4NCjxkaXY+V2hvIGVsc2UgaXMgaW50ZXJlc3RlZCBp biBzb2x2aW5nIHRoaXM/PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JcyB0aGVyZSBp bnRlcmVzdCBpbiB3b3JraW5nIG9uIHRoaXMgaW4gZWl0aGVyIFNDSU0gb3IgT0FVVEggV2dzPzwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QW55IG9uZSBpbiBCQSBpbnRlcmVzdGVkIGlu IG1lZXRpbmcgb24gdGhpcyB0b3BpYyB0aGlzIHdlZWs/PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj7igJQgRGljazwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9IiI+PC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2Pjxz cGFuPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFu Pjxicj4NCjxzcGFuPnNjaW0gbWFpbGluZyBsaXN0PC9zcGFuPjxicj4NCjxzcGFuPjxhIGhyZWY9 Im1haWx0bzpzY2ltQGlldGYub3JnIj5zY2ltQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+DQo8c3Bh bj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0iPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2NpbTwvYT48L3NwYW4+PGJyPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9z cGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_78D87E6BDBFE46D9B7FA15201924DA12amazoncom_-- From nobody Tue Apr 5 22:08:16 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E8412D7E5; Tue, 5 Apr 2016 22:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id du_d_3GEvwmc; Tue, 5 Apr 2016 22:08:08 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFFB812D09F; Tue, 5 Apr 2016 22:08:08 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u36585wP024049 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Apr 2016 05:08:06 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 u36585cm026703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Apr 2016 05:08:05 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 u36585UZ015383; Wed, 6 Apr 2016 05:08:05 GMT Received: from [31.133.137.184] (/31.133.137.184) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 05 Apr 2016 22:08:05 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-D33862B2-62E3-4F18-8326-EA43E5B2769B Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13E238) In-Reply-To: <78D87E6B-DBFE-46D9-B7FA-15201924DA12@amazon.com> Date: Wed, 6 Apr 2016 02:07:58 -0300 Content-Transfer-Encoding: 7bit Message-Id: <9F821551-7B5D-4450-BCCC-6FD889E40267@oracle.com> References: <086477E4-5F4E-4C52-AC91-E26824A9FA7A@oracle.com> <78D87E6B-DBFE-46D9-B7FA-15201924DA12@amazon.com> To: "Hardt, Dick" X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "scim@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 05:08:11 -0000 --Apple-Mail-D33862B2-62E3-4F18-8326-EA43E5B2769B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable There may be some similar concerns on our side. Lets talk more this week.=20= Phil > On Apr 5, 2016, at 19:25, Hardt, Dick wrote: >=20 > I=E2=80=99m talking about removing manual steps in what happens today wher= e configuring a SaaS app at an IdP (such as Google, Azure, Ping, Octa) requi= res is a bunch of cutting and pasting of access tokens / keys / certs and do= ing a bunch of config that is error prone and unique for each relationship.= >=20 > Don=E2=80=99t want to solve on the thread =E2=80=A6 looking to see if ther= e is interest! >=20 > On 4/5/16, 7:11 PM, someone claiming to be "scim on behalf of Phil Hunt (I= DM)" wrote: >=20 > Is the idp the center of all things for these users? >=20 > Usually you have a provisioning system that coordinates state and uses thi= ngs like scim connectors to do this.=20 >=20 > Another approach from today would be to pass a scim event to the remote pr= ovider which then decides what needs to be done to facilitate the thingd you= describe.=20 >=20 > Iow. Either the idp (sender) or the sp (receiver) have a provisioning syst= em to do this.=20 >=20 > The solution and the simplicity depends on where the control needs to be.=20= >=20 > Phil >=20 > On Apr 5, 2016, at 18:59, Hardt, Dick wrote: >=20 >> Use case: An admin for an organization would like to enable her users to a= ccess a SaaS application at her IdP.=20 >>=20 >> User experience:=20 >> Admin authenticates to IdP in browser >> Admin selects SaaS app to federate with from list at IdP >> IdP optionally presents config options >> IdP redirects Admin to SaaS app >> Admin authenticates to SaaS app >> SaaS app optionally gathers config options >> SaaS app redirects admin to IdP >> IdP confirms successful federation =3D> OIDC / SAML and SCIM are now conf= igured and working between IdP and SaaS App >> Who else is interested in solving this? >>=20 >> Is there interest in working on this in either SCIM or OAUTH Wgs? >>=20 >> Any one in BA interested in meeting on this topic this week? >>=20 >> =E2=80=94 Dick >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-D33862B2-62E3-4F18-8326-EA43E5B2769B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
There may be some similar concerns on o= ur side. Lets talk more this week. 

Phil

On Apr 5, 2016, at 19:25, Hardt, Dick <dick@amazon.com> wrote:

I=E2=80=99m talking about removing manual steps in what happens today w= here configuring a SaaS app at an IdP (such as Google, Azure, Ping, Octa) re= quires is a bunch of cutting and pasting of access tokens / keys / certs and= doing a bunch of  config that is error prone and unique for each relationship.

Don=E2=80=99t want to solve on the thread =E2=80=A6 looking to see if t= here is interest!

On 4/5/16, 7:11 PM, someone claiming to be "scim on behalf of Phil Hunt= (IDM)" <scim-bounces@ietf.org on behalf of phil.hunt@oracle.com> wrote:<= /div>

Is the idp the center of all things for these users?

Usually you have a provisioning system that c= oordinates state and uses things like scim connectors to do this. 

Another approach from today would be to pass a= scim event to the remote provider which then decides what needs to be done t= o facilitate the thingd you describe. 

Iow. Either the idp (sender) or the sp (recei= ver) have a provisioning system to do this. 

The solution and the simplicity depends on wh= ere the control needs to be. 

Phil

On Apr 5, 2016, at 18:59, Hardt, Dick <dick@amazon.com> wrote:

Use case: An admin for an organization would like to enable her users t= o access a SaaS application at her IdP. 

User experience: 
  1. Admin authenticates to IdP in browser
  2. Admin selects SaaS app to f= ederate with from list at IdP
  3. IdP optionally presents config options=
  4. IdP redirects Admin to SaaS app
  5. Admin authenticates to SaaS= app
  6. SaaS app optionally gathers config options
  7. SaaS app red= irects admin to IdP
  8. IdP confirms successful federation =3D> OIDC /= SAML and SCIM are now configured and working between IdP and SaaS App
    9. <= /ol>
    Who else is interested in solving this?

    Is there interest in working on this in either SCIM or OAUTH Wgs?
    =

    Any one in BA interested in meeting on this topic this week?

    =E2=80=94 Dick
_______________________________________________
scim mailing list
scim@ietf.org
https://www.iet= f.org/mailman/listinfo/scim
____________________= ___________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman= /listinfo/scim
= --Apple-Mail-D33862B2-62E3-4F18-8326-EA43E5B2769B-- From nobody Tue Apr 5 23:57:09 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CD712D136; Tue, 5 Apr 2016 23:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okpZVq8YhMOg; Tue, 5 Apr 2016 23:57:03 -0700 (PDT) Received: from nrifs03.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id D915B12D114; Tue, 5 Apr 2016 23:57:02 -0700 (PDT) Received: from nriea03.index.or.jp (unknown [172.19.246.38]) by nrifs03.index.or.jp (Postfix) with SMTP id 7C61917EA46; Wed, 6 Apr 2016 15:57:01 +0900 (JST) Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea03.index.or.jp (unknown) with ESMTP id u366v17M008332; Wed, 6 Apr 2016 15:57:01 +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 u366v0hD045807; Wed, 6 Apr 2016 15:57:00 +0900 Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id u366v0mR045806; Wed, 6 Apr 2016 15:57:00 +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 u366v027045803; Wed, 6 Apr 2016 15:57:00 +0900 Received: from NatRZ4 (unknown [172.21.163.96]) by nrivpnfs01.index.or.jp (Postfix) with ESMTP id 3605EBF94D; Wed, 6 Apr 2016 15:56:56 +0900 (JST) From: "Nat Sakimura" To: "'Hardt, Dick'" , "'Phil Hunt \(IDM\)'" References: <086477E4-5F4E-4C52-AC91-E26824A9FA7A@oracle.com> <78D87E6B-DBFE-46D9-B7FA-15201924DA12@amazon.com> In-Reply-To: <78D87E6B-DBFE-46D9-B7FA-15201924DA12@amazon.com> Date: Wed, 6 Apr 2016 15:56:56 +0900 Message-ID: <015501d18fd1$84935540$8db9ffc0$@nri.co.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0156_01D1901C.F4800650" X-Mailer: Microsoft Outlook 15.0 X-MailAdviser: 20141126 Thread-Index: AQJtGwW8oLtP+WMa70Ssdqh7/dtyYQKOPHBiAglzs3eeIK9LsA== Content-Language: ja Archived-At: Cc: scim@ietf.org, oauth@ietf.org Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 06:57:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0156_01D1901C.F4800650 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 for removing the manual cut-n-pastes! =20 Nat =20 -- PLEASE READ :This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail. =20 From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Hardt, Dick Sent: Wednesday, April 6, 2016 7:26 AM To: Phil Hunt (IDM) Cc: scim@ietf.org; oauth@ietf.org Subject: Re: [scim] Simple Federation Deployment =20 I=E2=80=99m talking about removing manual steps in what happens today = where configuring a SaaS app at an IdP (such as Google, Azure, Ping, = Octa) requires is a bunch of cutting and pasting of access tokens / keys = / certs and doing a bunch of config that is error prone and unique for = each relationship. =20 Don=E2=80=99t want to solve on the thread =E2=80=A6 looking to see if = there is interest! =20 On 4/5/16, 7:11 PM, someone claiming to be "scim on behalf of Phil Hunt = (IDM)" on behalf = of phil.hunt@oracle.com > wrote: =20 Is the idp the center of all things for these users? =20 Usually you have a provisioning system that coordinates state and uses = things like scim connectors to do this.=20 =20 Another approach from today would be to pass a scim event to the remote = provider which then decides what needs to be done to facilitate the = thingd you describe.=20 =20 Iow. Either the idp (sender) or the sp (receiver) have a provisioning = system to do this.=20 =20 The solution and the simplicity depends on where the control needs to = be.=20 Phil On Apr 5, 2016, at 18:59, Hardt, Dick > wrote: Use case: An admin for an organization would like to enable her users to = access a SaaS application at her IdP.=20 =20 User experience:=20 1. Admin authenticates to IdP in browser 2. Admin selects SaaS app to federate with from list at IdP 3. IdP optionally presents config options 4. IdP redirects Admin to SaaS app 5. Admin authenticates to SaaS app 6. SaaS app optionally gathers config options 7. SaaS app redirects admin to IdP 8. IdP confirms successful federation =3D> OIDC / SAML and SCIM are now = configured and working between IdP and SaaS App Who else is interested in solving this? =20 Is there interest in working on this in either SCIM or OAUTH Wgs? =20 Any one in BA interested in meeting on this topic this week? =20 =E2=80=94 Dick _______________________________________________ scim mailing list scim@ietf.org =20 https://www.ietf.org/mailman/listinfo/scim ------=_NextPart_000_0156_01D1901C.F4800650 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

+= 1 for removing the manual cut-n-pastes!

<= o:p> 

N= at

<= o:p> 

--=

PLEASE READ :This = e-mail is confidential and intended for the

named recipient = only. If you are not an intended recipient,

please notify the = sender=C2=A0 and delete this e-mail.

<= o:p> 

From:<= /b> scim = [mailto:scim-bounces@ietf.org] On Behalf Of Hardt, = Dick
Sent: Wednesday, April 6, 2016 7:26 AM
To: Phil = Hunt (IDM) <phil.hunt@oracle.com>
Cc: scim@ietf.org; = oauth@ietf.org
Subject: Re: [scim] Simple Federation = Deployment

 

I= =E2=80=99m talking about removing manual steps in what happens today = where configuring a SaaS app at an IdP (such as Google, Azure, Ping, = Octa) requires is a bunch of cutting and pasting of access tokens / keys = / certs and doing a bunch of  config that is error prone and unique = for each relationship.

<= o:p> 

D= on=E2=80=99t want to solve on the thread =E2=80=A6 looking to see if = there is interest!

<= o:p> 

O= n 4/5/16, 7:11 PM, someone claiming to be "scim on behalf of Phil = Hunt (IDM)" <scim-bounces@ietf.org on = behalf of phil.hunt@oracle.com> = wrote:

<= o:p> 

I= s the idp the center of all things for these = users?

<= o:p> 

U= sually you have a provisioning system that coordinates state and uses = things like scim connectors to do = this. 

<= o:p> 

A= nother approach from today would be to pass a scim event to the remote = provider which then decides what needs to be done to facilitate the = thingd you describe. 

<= o:p> 

I= ow. Either the idp (sender) or the sp (receiver) have a provisioning = system to do this. 

<= o:p> 

T= he solution and the simplicity depends on where the control needs to = be. 

Phil

<= br>On Apr 5, 2016, at 18:59, Hardt, Dick <dick@amazon.com> = wrote:

U= se case: An admin for an organization would like to enable her users to = access a SaaS application at her = IdP. 

<= o:p> 

U= ser experience: 

  1. Admin = authenticates to IdP in browser
  2. Admin = selects SaaS app to federate with from list at = IdP
  3. IdP = optionally presents config options
  4. IdP = redirects Admin to SaaS app
  5. Admin = authenticates to SaaS app
  6. SaaS app = optionally gathers config options
  7. SaaS app = redirects admin to IdP
  8. IdP confirms = successful federation =3D> OIDC / SAML and SCIM are now configured = and working between IdP and SaaS App

W= ho else is interested in solving = this?

<= o:p> 

I= s there interest in working on this in either SCIM or OAUTH = Wgs?

<= o:p> 

A= ny one in BA interested in meeting on this topic this = week?

<= o:p> 

=E2= =80=94 Dick

_= ______________________________________________
scim mailing = list
scim@ietf.org
https://www.ietf.org/= mailman/listinfo/scim

<= /div>
------=_NextPart_000_0156_01D1901C.F4800650-- From nobody Wed Apr 6 00:16:40 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D8D12D0B6 for ; Wed, 6 Apr 2016 00:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=viewds-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7c0wOJolX9fM for ; Wed, 6 Apr 2016 00:16:29 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::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 9E89512D57F for ; Wed, 6 Apr 2016 00:16:29 -0700 (PDT) Received: by mail-pa0-x22f.google.com with SMTP id zm5so27475169pac.0 for ; Wed, 06 Apr 2016 00:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=viewds-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=q9FQRgSTY/iQCf6lAOMUKM7gV9YYvozpbVeBjHpWvD4=; b=y2SsB6wGt4cZ7/d3hrnprT/2SUss3h19OWUFUs8KdCW1RCBQKK1TRS7h1fU0HSVAID yc1F3MPRbcrWfnzkvntTOGNW02+cNuLMOkpjyrGty+Rz8F3aBitqTyceaYdSL9qNYpXK PVS9J1QpNB/I/xnN75L1rZMBpIwSyFyaiOESacrKHwTH0sg2ULzAoXl3axbcQD5FFyJH goA4dBS2vjLJ/H+9LDBCpsXJYWR7uXbt4l3os91Q8Wrs1PGEoD/pOhEGsiS32aH0RGPs jB5qurLcpxfeIlQPhneBln8P0YegLWX1x85kl6VpFOxUQdPNxbnpythE3TbdchGjToDv 5FLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=q9FQRgSTY/iQCf6lAOMUKM7gV9YYvozpbVeBjHpWvD4=; b=GIvoyYBfHiw8qesHS+dvrRc+QEZHPbmfZoQlvrrxzB1PaeDG/MMQQ3Qu3OxuxFMoQq z8Lr9x6Fm54XbSiYrqtP5+87iXYaYqXQS2NO+WsGxYSkScuB0k1CtkSTea4Cpcs1kp1X 0AktaDs0hlbJlyBGL/LegHAz1KXk9h5ycebgglsORCrFfhPX5nCx1TWNs6Dq6Eifvyxy MrCihFzk2x9pdSz666tdTP4tUFGFe4MrRVutOWaWFcVlOqdtVsjA2KVphJyyWW5e+q2h AxXnka1UiTVyvVRTG3sazUqoqt+PdlYQpLYwsqPcDW24kSJ28SoUo1qzSfAdmuAO7B9i jywA== X-Gm-Message-State: AD7BkJLmKhNGgH6fbrGwK883hDPwd4RXsqGKZQc+Y6p/MhZIK0SRCArL0/dBLRYD8LjYCg== X-Received: by 10.66.255.65 with SMTP id ao1mr45220833pad.38.1459926989090; Wed, 06 Apr 2016 00:16:29 -0700 (PDT) Received: from WINH57TOAH3443 (2.101.96.58.static.exetel.com.au. [58.96.101.2]) by smtp.gmail.com with ESMTPSA id u21sm2318731pfa.60.2016.04.06.00.16.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Apr 2016 00:16:27 -0700 (PDT) From: "Gil Kirkpatrick" To: "'Nat Sakimura'" , "'Hardt, Dick'" , "'Phil Hunt \(IDM\)'" References: <086477E4-5F4E-4C52-AC91-E26824A9FA7A@oracle.com> <78D87E6B-DBFE-46D9-B7FA-15201924DA12@amazon.com> <015501d18fd1$84935540$8db9ffc0$@nri.co.jp> In-Reply-To: <015501d18fd1$84935540$8db9ffc0$@nri.co.jp> Date: Wed, 6 Apr 2016 17:16:16 +1000 Message-ID: <003501d18fd4$3a199990$ae4cccb0$@viewds.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0036_01D19028.0BC73030" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJtGwW8oLtP+WMa70Ssdqh7/dtyYQKOPHBiAglzs3cA3629NZ4ZtwJQ Content-Language: en-us Archived-At: Cc: scim@ietf.org, oauth@ietf.org Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 07:16:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0036_01D19028.0BC73030 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable That=E2=80=99s an issue we=E2=80=99re facing as well. Definitely = interested. =20 -gil =20 From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura Sent: Wednesday, April 6, 2016 4:57 PM To: 'Hardt, Dick' ; 'Phil Hunt (IDM)' = Cc: scim@ietf.org; oauth@ietf.org Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment =20 +1 for removing the manual cut-n-pastes! =20 Nat =20 -- PLEASE READ :This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail. =20 From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Hardt, Dick Sent: Wednesday, April 6, 2016 7:26 AM To: Phil Hunt (IDM) = > Cc: scim@ietf.org ; oauth@ietf.org = =20 Subject: Re: [scim] Simple Federation Deployment =20 I=E2=80=99m talking about removing manual steps in what happens today = where configuring a SaaS app at an IdP (such as Google, Azure, Ping, = Octa) requires is a bunch of cutting and pasting of access tokens / keys = / certs and doing a bunch of config that is error prone and unique for = each relationship. =20 Don=E2=80=99t want to solve on the thread =E2=80=A6 looking to see if = there is interest! =20 On 4/5/16, 7:11 PM, someone claiming to be "scim on behalf of Phil Hunt = (IDM)" on behalf = of phil.hunt@oracle.com > wrote: =20 Is the idp the center of all things for these users? =20 Usually you have a provisioning system that coordinates state and uses = things like scim connectors to do this.=20 =20 Another approach from today would be to pass a scim event to the remote = provider which then decides what needs to be done to facilitate the = thingd you describe.=20 =20 Iow. Either the idp (sender) or the sp (receiver) have a provisioning = system to do this.=20 =20 The solution and the simplicity depends on where the control needs to = be.=20 Phil On Apr 5, 2016, at 18:59, Hardt, Dick > wrote: Use case: An admin for an organization would like to enable her users to = access a SaaS application at her IdP.=20 =20 User experience:=20 1. Admin authenticates to IdP in browser 2. Admin selects SaaS app to federate with from list at IdP 3. IdP optionally presents config options 4. IdP redirects Admin to SaaS app 5. Admin authenticates to SaaS app 6. SaaS app optionally gathers config options 7. SaaS app redirects admin to IdP 8. IdP confirms successful federation =3D> OIDC / SAML and SCIM are now = configured and working between IdP and SaaS App Who else is interested in solving this? =20 Is there interest in working on this in either SCIM or OAUTH Wgs? =20 Any one in BA interested in meeting on this topic this week? =20 =E2=80=94 Dick _______________________________________________ scim mailing list scim@ietf.org =20 https://www.ietf.org/mailman/listinfo/scim ------=_NextPart_000_0036_01D19028.0BC73030 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

That=E2=80=99s an issue we=E2=80=99re facing = as well. Definitely interested.

 

-gil

 

From:<= /b> OAuth = [mailto:oauth-bounces@ietf.org] On Behalf Of Nat = Sakimura
Sent: Wednesday, April 6, 2016 4:57 PM
To: = 'Hardt, Dick' <dick@amazon.com>; 'Phil Hunt (IDM)' = <phil.hunt@oracle.com>
Cc: scim@ietf.org; = oauth@ietf.org
Subject: Re: [OAUTH-WG] [scim] Simple = Federation Deployment

 

+1 for removing the manual = cut-n-pastes!

 

Nat

 

--

PLEASE READ :This e-mail = is confidential and intended for the

named recipient only. If = you are not an intended recipient,

please notify the = sender  and delete this e-mail.

 

From: scim [mailto:scim-bounces@ietf.org] = On Behalf Of Hardt, Dick
Sent: Wednesday, April 6, 2016 = 7:26 AM
To: Phil Hunt (IDM) <phil.hunt@oracle.com>
C= c: scim@ietf.org; oauth@ietf.org
Subject: Re: = [scim] Simple Federation Deployment

 

<= p class=3DMsoNormal>I=E2=80=99m talking about removing manual steps = in what happens today where configuring a SaaS app at an IdP (such as = Google, Azure, Ping, Octa) requires is a bunch of cutting and pasting of = access tokens / keys / certs and doing a bunch of  config that is = error prone and unique for each = relationship.

 

Don=E2=80=99t want to solve on the thread = =E2=80=A6 looking to see if there is = interest!

 

On 4/5/16, 7:11 PM, someone claiming to be = "scim on behalf of Phil Hunt (IDM)" <scim-bounces@ietf.org on = behalf of phil.hunt@oracle.com> = wrote:

 

Is the idp the center of all things for these = users?

 

Usually you have a provisioning system that = coordinates state and uses things like scim connectors to do = this. 

 

Another approach from today would be to pass a = scim event to the remote provider which then decides what needs to be = done to facilitate the thingd you = describe. 

 

Iow. Either the idp (sender) or the sp (receiver) = have a provisioning system to do = this. 

 

The solution and the simplicity depends on where = the control needs to = be. 

Phil


On Apr 5, 2016, at 18:59, Hardt, Dick <dick@amazon.com> = wrote:

Use case: An admin for an organization would like = to enable her users to access a SaaS application at her = IdP. 

 

User = experience: 

  1. Admin authenticates to IdP in = browser
  2. Admin selects SaaS app to federate with from list at = IdP
  3. IdP optionally presents config = options
  4. IdP redirects Admin to SaaS app
  5. Admin authenticates to SaaS app
  6. SaaS app optionally gathers config = options
  7. SaaS app redirects admin to IdP
  8. IdP confirms successful federation =3D> OIDC / SAML and = SCIM are now configured and working between IdP and SaaS = App

Who else is interested in solving = this?

 

Is there interest in working on this in either = SCIM or OAUTH Wgs?

 

Any one in BA interested in meeting on this topic = this week?

 

=E2=80=94 = Dick

_______________________________________________scim mailing list
scim@ietf.org
https://www.ietf.org/= mailman/listinfo/scim

<= /div>
------=_NextPart_000_0036_01D19028.0BC73030-- From nobody Wed Apr 6 04:57:52 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6736112D9B3; Wed, 6 Apr 2016 04:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.013 X-Spam-Level: X-Spam-Status: No, score=-0.013 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id as4mZqfsjGg9; Wed, 6 Apr 2016 04:57:46 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0131.outbound.protection.outlook.com [65.55.169.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7FCC12D9AE; Wed, 6 Apr 2016 04:57:44 -0700 (PDT) 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=mxFp689hcViSh9Tu47qqS1wCFSYg877QgoUwOTb3cCY=; b=NcKGIRGBolbqv0rqnjtWyn7tNprm3OCc2FZVBq4NvllPUmBd5/nEGFxmq7GBacCX/4g+EaKx4Y4ZVHNdmdEc6ObsnoSRxSIBtDXCkOqr30nLAoLXCqeMSZZrjV6isQAihg217b5ykobj/7K0YX+ittsHNZiwSMsE76/sbfhQmIQ= 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.447.15; Wed, 6 Apr 2016 11:57:42 +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.0447.028; Wed, 6 Apr 2016 11:57:42 +0000 From: Anthony Nadalin To: Gil Kirkpatrick , 'Nat Sakimura' , "'Hardt, Dick'" , "'Phil Hunt (IDM)'" Thread-Topic: [scim] [OAUTH-WG] Simple Federation Deployment Thread-Index: AQHRj9RFOWfh1gvNgUKJY07K1Qps459812SH Date: Wed, 6 Apr 2016 11:57:42 +0000 Message-ID: References: <086477E4-5F4E-4C52-AC91-E26824A9FA7A@oracle.com> <78D87E6B-DBFE-46D9-B7FA-15201924DA12@amazon.com> <015501d18fd1$84935540$8db9ffc0$@nri.co.jp>, <003501d18fd4$3a199990$ae4cccb0$@viewds.com> In-Reply-To: <003501d18fd4$3a199990$ae4cccb0$@viewds.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: viewds.com; dkim=none (message not signed) header.d=none;viewds.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [166.173.250.3] x-ms-office365-filtering-correlation-id: b3d9fc6e-abb3-4195-4254-08d35e12a918 x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1236; 5:9e/MBfww4NN4g494MQdDtbZbnANfAMhz8dOi5m7lA1H7/koMoappqwoljxdmQursdvIRwBLZHpO+Cg/yxH6qJWrNOT8Mnxj1XqtKqAVBXI7OmS8s/7HD5aaLxKKi8sHFjPhgTGffZV7atgtHFpUsRg==; 24:HtUNKR3XZjGE03xKW6luQnHFWHSGpxIAqBBeWt0xRfLW//Dpf0uv9tO8Ez1VKzbnC7Y3hiWQ2Ny0XsAcXUP3hXoRU9FwPjBvpXcD91c+ZBk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1236; 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)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BN3PR0301MB1236; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1236; x-forefront-prvs: 0904004ECB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(11100500001)(50986999)(189998001)(10290500002)(19625215002)(3900700001)(76176999)(122556002)(9886003)(81166005)(86362001)(93886004)(10400500002)(54356999)(86612001)(66066001)(5005710100001)(3846002)(586003)(1096002)(1220700001)(5001770100001)(102836003)(5004730100002)(3660700001)(6116002)(74316001)(33656002)(3280700002)(19580395003)(19617315012)(5003600100002)(19580405001)(4326007)(5008740100001)(106116001)(2906002)(5002640100001)(92566002)(99286002)(8990500004)(2900100001)(15975445007)(10090500001)(16236675004)(76576001)(87936001)(2950100001)(77096005)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1236; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1234F430620D534738AA233AA69F0BN3PR0301MB1234_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2016 11:57:42.6389 (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: "scim@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 11:57:49 -0000 --_000_BN3PR0301MB1234F430620D534738AA233AA69F0BN3PR0301MB1234_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would be interested also Sent from my Windows 10 phone From: Gil Kirkpatrick Sent: Wednesday, April 6, 2016 4:16 AM To: 'Nat Sakimura'; 'Hardt, Dick'; 'Phil Hunt (IDM)' Cc: scim@ietf.org; oauth@ietf.org Subject: Re: [scim] [OAUTH-WG] Simple Federation Deployment That's an issue we're facing as well. Definitely interested. -gil From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura Sent: Wednesday, April 6, 2016 4:57 PM To: 'Hardt, Dick' ; 'Phil Hunt (IDM)' Cc: scim@ietf.org; oauth@ietf.org Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment +1 for removing the manual cut-n-pastes! Nat -- PLEASE READ :This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail. From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Hardt, Dick Sent: Wednesday, April 6, 2016 7:26 AM To: Phil Hunt (IDM) > Cc: scim@ietf.org; oauth@ietf.org Subject: Re: [scim] Simple Federation Deployment I'm talking about removing manual steps in what happens today where configu= ring a SaaS app at an IdP (such as Google, Azure, Ping, Octa) requires is a= bunch of cutting and pasting of access tokens / keys / certs and doing a b= unch of config that is error prone and unique for each relationship. Don't want to solve on the thread ... looking to see if there is interest! On 4/5/16, 7:11 PM, someone claiming to be "scim on behalf of Phil Hunt (ID= M)" on behalf of phil.= hunt@oracle.com> wrote: Is the idp the center of all things for these users? Usually you have a provisioning system that coordinates state and uses thin= gs like scim connectors to do this. Another approach from today would be to pass a scim event to the remote pro= vider which then decides what needs to be done to facilitate the thingd you= describe. Iow. Either the idp (sender) or the sp (receiver) have a provisioning syste= m to do this. The solution and the simplicity depends on where the control needs to be. Phil On Apr 5, 2016, at 18:59, Hardt, Dick > wrote: Use case: An admin for an organization would like to enable her users to ac= cess a SaaS application at her IdP. User experience: 1. Admin authenticates to IdP in browser 2. Admin selects SaaS app to federate with from list at IdP 3. IdP optionally presents config options 4. IdP redirects Admin to SaaS app 5. Admin authenticates to SaaS app 6. SaaS app optionally gathers config options 7. SaaS app redirects admin to IdP 8. IdP confirms successful federation =3D> OIDC / SAML and SCIM are now = configured and working between IdP and SaaS App Who else is interested in solving this? Is there interest in working on this in either SCIM or OAUTH Wgs? Any one in BA interested in meeting on this topic this week? - Dick _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_BN3PR0301MB1234F430620D534738AA233AA69F0BN3PR0301MB1234_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would be interested also

 

Sent from my Windows 10 phone

 

From: Gil Kirkpatrick
Sent: Wednesday, April 6, 2016 4:16 AM
To: 'Nat Sakimura'; 'Hardt, Dick'; 'Phil Hunt (IDM)= '
Cc: scim@ietf.org; oauth@ietf.org
Subject: Re: [scim] [OAUTH-WG] Simple Federation Deployment

 

That’s an issue we’re f= acing as well. Definitely interested.

 

-gil

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura
Sent: Wednesday, April 6, 2016 4:57 PM
To: 'Hardt, Dick' <dick@amazon.com>; 'Phil Hunt (IDM)' <phi= l.hunt@oracle.com>
Cc: scim@ietf.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment

 

+1 for removing the manual cut-n-pastes!

 

Nat

 

--

PLEASE READ :This e-mail is c= onfidential and intended for the

named recipient only. If you = are not an intended recipient,

please notify the sender = ; and delete this e-mail.

 

From: scim [mailto:scim-bounces@ietf.o= rg] On Behalf Of Hardt, Dick
Sent: Wednesday, April 6, 2016 7:26 AM
To: Phil Hunt (IDM) <phil= .hunt@oracle.com>
Cc: scim@ietf.org; oauth@ietf.org
Subject: Re: [scim] Simple Federation Deployment

 

I’m talking abou= t removing manual steps in what happens today where configuring a SaaS app = at an IdP (such as Google, Azure, Ping, Octa) requires is a bunch of cutting and pasting of access tokens / keys / certs and doin= g a bunch of  config that is error prone and unique for each relations= hip.

 

Don’t want to so= lve on the thread … looking to see if there is interest!

 

On 4/5/16, 7:11 PM, so= meone claiming to be "scim on behalf of Phil Hunt (IDM)" <scim-bounces@ietf.org on behalf of phil.hunt@oracle.com<= /a>> wrote:

 

Is the idp the center = of all things for these users?

 

Usually you have a pro= visioning system that coordinates state and uses things like scim connector= s to do this. 

 

Another approach from = today would be to pass a scim event to the remote provider which then decid= es what needs to be done to facilitate the thingd you describe. 

 

Iow. Either the idp (s= ender) or the sp (receiver) have a provisioning system to do this. 

 

The solution and the s= implicity depends on where the control needs to be. 

Phil

Use case: An admin for= an organization would like to enable her users to access a SaaS applicatio= n at her IdP. 

 

User experience: =

  1. Admin authen= ticates to IdP in browser
  2. Admin selects SaaS app to federate with from list = at IdP
  3. IdP optionally presents config options
  4. IdP redirects Admin to SaaS ap= p
  5. Admin authenticates to SaaS app
  6. SaaS app optionally gathers config option= s
  7. SaaS app redirects admin to IdP
  8. IdP confirms successful federation =3D>= ; OIDC / SAML and SCIM are now configured and working between IdP and SaaS = App

Who else is interested= in solving this?

 

Is there interest in w= orking on this in either SCIM or OAUTH Wgs?

 

Any one in BA interest= ed in meeting on this topic this week?

 

— Dick

______________________= _________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim

--_000_BN3PR0301MB1234F430620D534738AA233AA69F0BN3PR0301MB1234_-- From nobody Wed Apr 6 05:52:42 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA70A12D0B5; Wed, 6 Apr 2016 05:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.841 X-Spam-Level: X-Spam-Status: No, score=-9.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTjO1hh8ZA4j; Wed, 6 Apr 2016 05:52:38 -0700 (PDT) Received: from smtp-fw-6001.amazon.com (smtp-fw-6001.amazon.com [52.95.48.154]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0420B12D0AF; Wed, 6 Apr 2016 05:52:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1459947158; x=1491483158; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=A7HBODfRk59enhPLr3+Qlp8VXS3ihuVC8eCIcGkgWfY=; b=MpZLHRvfSXhn2J291tRjwNbNgLYc/DzJEwiG4VyKi9HfXD40ZFka5cdp gKahyIPsnMWwyuvspfozNNuXomAFK30Rwc+EYhyLPkQOQMBLk/52+RLTY mE6KSNZlZFSlwjZHfU/sfjUay0odZOvxCJXV4xrkxmGZxj3zNITsL3e0D k=; X-IronPort-AV: E=Sophos; i="5.24,447,1454976000"; d="scan'208,217"; a="80842596" Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-64014.pdx4.amazon.com) ([10.43.8.2]) by smtp-border-fw-out-6001.iad6.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Apr 2016 12:52:35 +0000 Received: from ex10-hub-7001.ant.amazon.com (pdx1-ws-svc-lb16-vlan3.amazon.com [10.239.138.214]) by email-inbound-relay-64014.pdx4.amazon.com (8.14.7/8.14.7) with ESMTP id u36CqVl5001805 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Apr 2016 12:52:34 GMT Received: from EX13D03UWA002.ant.amazon.com (10.43.160.144) by ex10-hub-7001.ant.amazon.com (10.43.103.49) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 6 Apr 2016 05:52:17 -0700 Received: from EX13D03UWA001.ant.amazon.com (10.43.160.141) by EX13D03UWA002.ant.amazon.com (10.43.160.144) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 6 Apr 2016 12:52:16 +0000 Received: from EX13D03UWA001.ant.amazon.com ([10.43.160.141]) by EX13D03UWA001.ant.amazon.com ([10.43.160.141]) with mapi id 15.00.1104.000; Wed, 6 Apr 2016 12:52:16 +0000 From: "Hardt, Dick" To: Anthony Nadalin Thread-Topic: [scim] [OAUTH-WG] Simple Federation Deployment Thread-Index: AQHRj/uJ5IZw0jcyTEuPMNzkcwLe5p985lMG Date: Wed, 6 Apr 2016 12:52:15 +0000 Message-ID: <9FD402E5-023E-408E-8DE4-BD8E86A7269F@amazon.com> References: <086477E4-5F4E-4C52-AC91-E26824A9FA7A@oracle.com> <78D87E6B-DBFE-46D9-B7FA-15201924DA12@amazon.com> <015501d18fd1$84935540$8db9ffc0$@nri.co.jp>, <003501d18fd4$3a199990$ae4cccb0$@viewds.com>, 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_9FD402E5023E408E8DE4BD8E86A7269Famazoncom_" MIME-Version: 1.0 Archived-At: Cc: "scim@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 12:52:41 -0000 --_000_9FD402E5023E408E8DE4BD8E86A7269Famazoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sounds like there is interest. SCIM or OAUTH? -- Dick On Apr 6, 2016, at 8:57 AM, Anthony Nadalin > wrote: I would be interested also Sent from my Windows 10 phone From: Gil Kirkpatrick Sent: Wednesday, April 6, 2016 4:16 AM To: 'Nat Sakimura'; 'Hardt, Dick'; 'Phil Hunt (IDM)' Cc: scim@ietf.org; oauth@ietf.org Subject: Re: [scim] [OAUTH-WG] Simple Federation Deployment That's an issue we're facing as well. Definitely interested. -gil From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura Sent: Wednesday, April 6, 2016 4:57 PM To: 'Hardt, Dick' >; 'Phil Hunt (ID= M)' > Cc: scim@ietf.org; oauth@ietf.org Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment +1 for removing the manual cut-n-pastes! Nat -- PLEASE READ :This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail. From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Hardt, Dick Sent: Wednesday, April 6, 2016 7:26 AM To: Phil Hunt (IDM) > Cc: scim@ietf.org; oauth@ietf.org Subject: Re: [scim] Simple Federation Deployment I'm talking about removing manual steps in what happens today where configu= ring a SaaS app at an IdP (such as Google, Azure, Ping, Octa) requires is a= bunch of cutting and pasting of access tokens / keys / certs and doing a b= unch of config that is error prone and unique for each relationship. Don't want to solve on the thread ... looking to see if there is interest! On 4/5/16, 7:11 PM, someone claiming to be "scim on behalf of Phil Hunt (ID= M)" on behalf of phil.= hunt@oracle.com> wrote: Is the idp the center of all things for these users? Usually you have a provisioning system that coordinates state and uses thin= gs like scim connectors to do this. Another approach from today would be to pass a scim event to the remote pro= vider which then decides what needs to be done to facilitate the thingd you= describe. Iow. Either the idp (sender) or the sp (receiver) have a provisioning syste= m to do this. The solution and the simplicity depends on where the control needs to be. Phil On Apr 5, 2016, at 18:59, Hardt, Dick > wrote: Use case: An admin for an organization would like to enable her users to ac= cess a SaaS application at her IdP. User experience: 1. Admin authenticates to IdP in browser 2. Admin selects SaaS app to federate with from list at IdP 3. IdP optionally presents config options 4. IdP redirects Admin to SaaS app 5. Admin authenticates to SaaS app 6. SaaS app optionally gathers config options 7. SaaS app redirects admin to IdP 8. IdP confirms successful federation =3D> OIDC / SAML and SCIM are now = configured and working between IdP and SaaS App Who else is interested in solving this? Is there interest in working on this in either SCIM or OAUTH Wgs? Any one in BA interested in meeting on this topic this week? - Dick _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_9FD402E5023E408E8DE4BD8E86A7269Famazoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Sounds like there is interest.

SCIM or OAUTH?

-- Dick

On Apr 6, 2016, at 8:57 AM, Anthony Nadalin <tonynad@microsoft.com> wrote:

I would be interested also

 

Sent from my Windows 10 phone

 

From: Gil Kirkpatrick
Sent: Wednesday, April 6, 2016 4:16 AM
To: 'Nat Sakimura'; 'Hardt, Dick'; 'Phil Hunt (IDM)= '
Cc: scim@ietf.org; oauth@ietf.org
Subject: Re: [scim] [OAUTH-WG] Simple Federation Deployment

 

That’s an issue we’re f= acing as well. Definitely interested.

 

-gil

 

From: OAuth [mailto:oauth-bounces@iet= f.org] On Behalf Of Nat Sakimura
Sent: Wednesday, April 6, 2016 4:57 PM
To: 'Hardt, Dick' <dick@amazon= .com>; 'Phil Hunt (IDM)' <phil.hunt@oracle.com>
Cc: scim@ietf.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment

 

+1 for removing the manual cut-n-pastes!

 

Nat

 

--

PLEASE READ :This e-mail is c= onfidential and intended for the

named recipient only. If you = are not an intended recipient,

please notify the sender = ; and delete this e-mail.

 

From: scim [mailto:scim-bounces@ietf.o= rg] On Behalf Of Hardt, Dick
Sent: Wednesday, April 6, 2016 7:26 AM
To: Phil Hunt (IDM) <phil= .hunt@oracle.com>
Cc: scim@ietf.org; oauth@ietf.org
Subject: Re: [scim] Simple Federation Deployment

 

I’m talking abou= t removing manual steps in what happens today where configuring a SaaS app = at an IdP (such as Google, Azure, Ping, Octa) requires is a bunch of cutting and pasting of access tokens / keys / certs and doin= g a bunch of  config that is error prone and unique for each relations= hip.

 

Don’t want to so= lve on the thread … looking to see if there is interest!

 

On 4/5/16, 7:11 PM, so= meone claiming to be "scim on behalf of Phil Hunt (IDM)" <scim-bounces@ietf.org on behalf of phil.hunt@oracle.com<= /a>> wrote:

 

Is the idp the center = of all things for these users?

 

Usually you have a pro= visioning system that coordinates state and uses things like scim connector= s to do this. 

 

Another approach from = today would be to pass a scim event to the remote provider which then decid= es what needs to be done to facilitate the thingd you describe. 

 

Iow. Either the idp (s= ender) or the sp (receiver) have a provisioning system to do this. 

 

The solution and the s= implicity depends on where the control needs to be. 

Phil

Use case: An admin for= an organization would like to enable her users to access a SaaS applicatio= n at her IdP. 

 

User experience: =

  1. Admin authen= ticates to IdP in browser
  2. Admin selects SaaS app to federate with from list = at IdP
  3. IdP optionally presents config options
  4. IdP redirects Admin to SaaS ap= p
  5. Admin authenticates to SaaS app
  6. SaaS app optionally gathers config option= s
  7. SaaS app redirects admin to IdP
  8. IdP confirms successful federation =3D>= ; OIDC / SAML and SCIM are now configured and working between IdP and SaaS = App

Who else is interested= in solving this?

 

Is there interest in w= orking on this in either SCIM or OAUTH Wgs?

 

Any one in BA interest= ed in meeting on this topic this week?

 

— Dick

______________________= _________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim

--_000_9FD402E5023E408E8DE4BD8E86A7269Famazoncom_-- From nobody Wed Apr 6 05:59:55 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1EC12D1A2; Wed, 6 Apr 2016 05:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.758 X-Spam-Level: X-Spam-Status: No, score=0.758 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bd-q0PE35TiV; Wed, 6 Apr 2016 05:59:51 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0730.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:730]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0D2112D167; Wed, 6 Apr 2016 05:59:50 -0700 (PDT) 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=HSCYcZA7F8EIO1c5UUs2E+lR6WET1DYwPUVObkyo6ts=; b=bMFL2flwrSX3JG45HKg5cwRzNKFmIuJjLJQHdcl4M5SinGkjmoywUz266eOg6hK96YUqBqyxLi7zazR9Mq0RUBki5efHPAdGPYO/Qvl12vB9JCGKKfad7Ip2eH5GHuFHhQx94P7LPqRIS+dIBE5WVLpDHHg4cEfB9TnB9jBxmec= 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.447.15; Wed, 6 Apr 2016 12:59:29 +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.0447.028; Wed, 6 Apr 2016 12:59:29 +0000 From: Anthony Nadalin To: "Hardt, Dick" Thread-Topic: [scim] [OAUTH-WG] Simple Federation Deployment server to server Thread-Index: AdGQBBeiw/sZG2O0RIq93JZJe7cKvw== Date: Wed, 6 Apr 2016 12:59:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: amazon.com; dkim=none (message not signed) header.d=none;amazon.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [200.127.148.163] x-ms-office365-filtering-correlation-id: d18e0383-77f6-4350-3218-08d35e1b4a5b x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1236; 5:4yOHmJeMmDBtXKoLe902UZQhhc7/bn+/M23cDPsR4EOzfrBSQh7QLYvtaAwXl4dCrv6DwTJJ8j9K9MMXlDr3upOgXQmKX5XwWaWcRHpNY6dXsSZMFf5yojgL5QvX2EBxE8mVF+NaOyLu11hFigV5mA==; 24:l4pex4yp9/ZhvhJqhgfy70CJ3xVhQdVp1CyxfOTcB5KcV96vX8awg0DvkQlpjEMuU6wJon+gVFoe7iNHiivsmFYk+PGZWBnWvzgoqE7x0gU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1236; 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)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BN3PR0301MB1236; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1236; x-forefront-prvs: 0904004ECB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(11100500001)(50986999)(3900700001)(10290500002)(189998001)(19625215002)(122556002)(81166005)(10400500002)(54356999)(86362001)(86612001)(66066001)(5005710100001)(3846002)(586003)(1096002)(1220700001)(5004730100002)(19300405004)(790700001)(3660700001)(6116002)(102836003)(74316001)(33656002)(110136002)(3280700002)(19580395003)(19617315012)(5003600100002)(19580405001)(4326007)(5008740100001)(5002640100001)(2906002)(92566002)(99286002)(8990500004)(2900100001)(15975445007)(10090500001)(16236675004)(76576001)(87936001)(77096005)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1236; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1234A5846EE0DAC385493563A69F0BN3PR0301MB1234_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2016 12:59:29.2115 (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: "scim@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment server to server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 12:59:55 -0000 --_000_BN3PR0301MB1234A5846EE0DAC385493563A69F0BN3PR0301MB1234_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Good question, since SCIM does not really provide an authorization model an= d Oauth does not do provisioning this is sort of caught in the middle, so i= f I had to pick I would pick Oauth as this is a generic server to server is= sue From: Hardt, Dick [mailto:dick@amazon.com] Sent: Wednesday, April 6, 2016 5:52 AM To: Anthony Nadalin Cc: Gil Kirkpatrick ; Nat Sakimura ; Phil Hunt (IDM) ; scim@ietf.org; oauth@ie= tf.org Subject: Re: [scim] [OAUTH-WG] Simple Federation Deployment Sounds like there is interest. SCIM or OAUTH? -- Dick On Apr 6, 2016, at 8:57 AM, Anthony Nadalin > wrote: I would be interested also Sent from my Windows 10 phone From: Gil Kirkpatrick Sent: Wednesday, April 6, 2016 4:16 AM To: 'Nat Sakimura'; 'Hardt, Dick'; 'Phil Hunt (IDM)' Cc: scim@ietf.org; oauth@ietf.org Subject: Re: [scim] [OAUTH-WG] Simple Federation Deployment That's an issue we're facing as well. Definitely interested. -gil From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura Sent: Wednesday, April 6, 2016 4:57 PM To: 'Hardt, Dick' >; 'Phil Hunt (ID= M)' > Cc: scim@ietf.org; oauth@ietf.org Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment +1 for removing the manual cut-n-pastes! Nat -- PLEASE READ :This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail. From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Hardt, Dick Sent: Wednesday, April 6, 2016 7:26 AM To: Phil Hunt (IDM) > Cc: scim@ietf.org; oauth@ietf.org Subject: Re: [scim] Simple Federation Deployment I'm talking about removing manual steps in what happens today where configu= ring a SaaS app at an IdP (such as Google, Azure, Ping, Octa) requires is a= bunch of cutting and pasting of access tokens / keys / certs and doing a b= unch of config that is error prone and unique for each relationship. Don't want to solve on the thread ... looking to see if there is interest! On 4/5/16, 7:11 PM, someone claiming to be "scim on behalf of Phil Hunt (ID= M)" on behalf of phil.= hunt@oracle.com> wrote: Is the idp the center of all things for these users? Usually you have a provisioning system that coordinates state and uses thin= gs like scim connectors to do this. Another approach from today would be to pass a scim event to the remote pro= vider which then decides what needs to be done to facilitate the thingd you= describe. Iow. Either the idp (sender) or the sp (receiver) have a provisioning syste= m to do this. The solution and the simplicity depends on where the control needs to be. Phil On Apr 5, 2016, at 18:59, Hardt, Dick > wrote: Use case: An admin for an organization would like to enable her users to ac= cess a SaaS application at her IdP. User experience: 1. Admin authenticates to IdP in browser 2. Admin selects SaaS app to federate with from list at IdP 3. IdP optionally presents config options 4. IdP redirects Admin to SaaS app 5. Admin authenticates to SaaS app 6. SaaS app optionally gathers config options 7. SaaS app redirects admin to IdP 8. IdP confirms successful federation =3D> OIDC / SAML and SCIM are now = configured and working between IdP and SaaS App Who else is interested in solving this? Is there interest in working on this in either SCIM or OAUTH Wgs? Any one in BA interested in meeting on this topic this week? - Dick _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_BN3PR0301MB1234A5846EE0DAC385493563A69F0BN3PR0301MB1234_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Good question, since SCIM does not really provide an= authorization model and Oauth does not do provisioning this is sort of cau= ght in the middle, so if I had to pick I would pick Oauth as this is a gene= ric server to server issue

 

From: Hardt, Dick [mailto:dick@amazon.com] Sent: Wednesday, April 6, 2016 5:52 AM
To: Anthony Nadalin <tonynad@microsoft.com>
Cc: Gil Kirkpatrick <gil.kirkpatrick@viewds.com>; Nat Sakimura= <n-sakimura@nri.co.jp>; Phil Hunt (IDM) <phil.hunt@oracle.com>= ; scim@ietf.org; oauth@ietf.org
Subject: Re: [scim] [OAUTH-WG] Simple Federation Deployment

 

Sounds like there is interest.

 

SCIM or OAUTH?

-- Dick


On Apr 6, 2016, at 8:57 AM, Anthony Nadalin <tonynad@microsoft.com> wrote:

I would be interested also

 

Sent from my Windows 10 phone

 

From: Gil Kirkpatrick
Sent: Wednesday, April 6, 2016 4:16 AM
To: 'Nat Sakimura'; 'Hardt, Dick'; 'Phil Hunt (IDM)= '
Cc: scim@ietf.org; oauth@ietf.org
Subject: Re: [scim] [OAUTH-WG] Simple Federation Deployment

 

That’s an issue = we’re facing as well. Definitely interested.

 

-gil=

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura
Sent: Wednesday, April 6, 2016 4:57 PM
To: 'Hardt, Dick' <dick@amazon= .com>; 'Phil Hunt (IDM)' <phil.hunt@oracle.com>
Cc: scim@ietf.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment

 

+1 for removing the manual cut-n-pa= stes!

 

Nat

 

--

PLEASE READ :This e-mail is confidential and i= ntended for the

named recipient only. If you are not an intend= ed recipient,

please notify the sender  and delete this= e-mail.

 

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Hardt, Dick
Sent: Wednesday, April 6, 2016 7:26 AM
To: Phil Hunt (IDM) <phil= .hunt@oracle.com>
Cc: scim@ietf.org; oauth@ietf.org
Subject: Re: [scim] Simple Federation Deployment

 

I’= ;m talking about removing manual steps in what happens today where configur= ing a SaaS app at an IdP (such as Google, Azure, Ping, Octa) requires is a = bunch of cutting and pasting of access tokens / keys / certs and doing a bunch of  config that is error prone and u= nique for each relationship.

 <= /span>

DonR= 17;t want to solve on the thread … looking to see if there is interes= t!

 <= /span>

On 4/5/= 16, 7:11 PM, someone claiming to be "scim on behalf of Phil Hunt (IDM)= " <scim-bounces@ietf.org on behalf of phil.hunt@oracle.com> wrote:=

 <= /span>

Is the = idp the center of all things for these users?

 <= /span>

Usually= you have a provisioning system that coordinates state and uses things like= scim connectors to do this. 

 <= /span>

Another= approach from today would be to pass a scim event to the remote provider w= hich then decides what needs to be done to facilitate the thingd you descri= be. 

 <= /span>

Iow. Ei= ther the idp (sender) or the sp (receiver) have a provisioning system to do= this. 

 <= /span>

The sol= ution and the simplicity depends on where the control needs to be. 
Phil


On Apr 5, 2016, at 18:59, Hardt, Dick <dick@amazon.com> wrote:

Use cas= e: An admin for an organization would like to enable her users to access a = SaaS application at her IdP. 

 <= /span>

User ex= perience: 

  1. Admin authenticates to IdP in browser
  2. Admin selects SaaS app to federate= with from list at IdP
  3. I= dP optionally presents config options
  4. IdP redirects Admin to SaaS app
  5. Admin authenticates to SaaS app
  6. SaaS app optionally gathers config options
  7. SaaS app redirects admin to = IdP
  8. IdP confirms successf= ul federation =3D> OIDC / SAML and SCIM are now configured and working b= etween IdP and SaaS App

Who els= e is interested in solving this?

 <= /span>

Is ther= e interest in working on this in either SCIM or OAUTH Wgs?

 <= /span>

Any one= in BA interested in meeting on this topic this week?

 <= /span>

—= Dick

_______= ________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim

--_000_BN3PR0301MB1234A5846EE0DAC385493563A69F0BN3PR0301MB1234_-- From nobody Wed Apr 6 06:02:03 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4F6127058; Wed, 6 Apr 2016 06:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNi5NDywULpy; Wed, 6 Apr 2016 06:01:56 -0700 (PDT) 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 34A1812D0C7; Wed, 6 Apr 2016 06:01:56 -0700 (PDT) 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 u36D1rgs001370 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Apr 2016 13:01:54 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u36D1rUB025251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Apr 2016 13:01:53 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u36D1reU027201; Wed, 6 Apr 2016 13:01:53 GMT Received: from dhcp-a0b5.meeting.ietf.org (/31.133.160.181) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 06 Apr 2016 06:01:51 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_6F784970-221A-49B5-B21B-6C0A3490A0AA" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Phil Hunt In-Reply-To: <9FD402E5-023E-408E-8DE4-BD8E86A7269F@amazon.com> Date: Wed, 6 Apr 2016 10:01:48 -0300 Message-Id: <5E96CC5B-1336-4A38-85A2-89D579A34442@oracle.com> References: <086477E4-5F4E-4C52-AC91-E26824A9FA7A@oracle.com> <78D87E6B-DBFE-46D9-B7FA-15201924DA12@amazon.com> <015501d18fd1$84935540$8db9ffc0$@nri.co.jp> <003501d18fd4$3a199990$ae4cccb0$@viewds.com> <9FD402E5-023E-408E-8DE4-BD8E86A7269F@amazon.com> To: "Hardt, Dick" X-Mailer: Apple Mail (2.3112) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: "oauth@ietf.org" , "scim@ietf.org" Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 13:02:00 -0000 --Apple-Mail=_6F784970-221A-49B5-B21B-6C0A3490A0AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think it is worth discussing in oauth wg. While SCIM has issues, I think it represents a broader use case that = other applications have that are deployed widely. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Apr 6, 2016, at 9:52 AM, Hardt, Dick wrote: >=20 > Sounds like there is interest. >=20 > SCIM or OAUTH? >=20 > -- Dick >=20 > On Apr 6, 2016, at 8:57 AM, Anthony Nadalin > wrote: >=20 >> I would be interested also >> =20 >> Sent from my Windows 10 phone >> =20 >> From: Gil Kirkpatrick >> Sent: Wednesday, April 6, 2016 4:16 AM >> To: 'Nat Sakimura' ; 'Hardt, Dick' = ; 'Phil Hunt (IDM)' = >> Cc: scim@ietf.org ; oauth@ietf.org = >> Subject: Re: [scim] [OAUTH-WG] Simple Federation Deployment >> =20 >> That=E2=80=99s an issue we=E2=80=99re facing as well. Definitely = interested. >> =20 >> -gil >> =20 >> From: OAuth [mailto:oauth-bounces@ietf.org = ] On Behalf Of Nat Sakimura >> Sent: Wednesday, April 6, 2016 4:57 PM >> To: 'Hardt, Dick' >; 'Phil = Hunt (IDM)' > >> Cc: scim@ietf.org ; oauth@ietf.org = >> Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment >> =20 >> +1 for removing the manual cut-n-pastes! <> >> =20 >> Nat >> =20 >> -- >> PLEASE READ :This e-mail is confidential and intended for the >> named recipient only. If you are not an intended recipient, >> please notify the sender and delete this e-mail. >> =20 >> From: scim [mailto:scim-bounces@ietf.org = ] On Behalf Of Hardt, Dick >> Sent: Wednesday, April 6, 2016 7:26 AM >> To: Phil Hunt (IDM) > >> Cc: scim@ietf.org ; oauth@ietf.org = >> Subject: Re: [scim] Simple Federation Deployment >> =20 >> I=E2=80=99m talking about removing manual steps in what happens today = where configuring a SaaS app at an IdP (such as Google, Azure, Ping, = Octa) requires is a bunch of cutting and pasting of access tokens / keys = / certs and doing a bunch of config that is error prone and unique for = each relationship. >> =20 >> Don=E2=80=99t want to solve on the thread =E2=80=A6 looking to see if = there is interest! >> =20 >> On 4/5/16, 7:11 PM, someone claiming to be "scim on behalf of Phil = Hunt (IDM)" on = behalf of phil.hunt@oracle.com > wrote: >> =20 >> Is the idp the center of all things for these users? >> =20 >> Usually you have a provisioning system that coordinates state and = uses things like scim connectors to do this.=20 >> =20 >> Another approach from today would be to pass a scim event to the = remote provider which then decides what needs to be done to facilitate = the thingd you describe.=20 >> =20 >> Iow. Either the idp (sender) or the sp (receiver) have a provisioning = system to do this.=20 >> =20 >> The solution and the simplicity depends on where the control needs to = be.=20 >>=20 >> Phil >>=20 >> On Apr 5, 2016, at 18:59, Hardt, Dick > wrote: >>=20 >> Use case: An admin for an organization would like to enable her users = to access a SaaS application at her IdP.=20 >> =20 >> User experience:=20 >> Admin authenticates to IdP in browser >> Admin selects SaaS app to federate with from list at IdP >> IdP optionally presents config options >> IdP redirects Admin to SaaS app >> Admin authenticates to SaaS app >> SaaS app optionally gathers config options >> SaaS app redirects admin to IdP >> IdP confirms successful federation =3D> OIDC / SAML and SCIM are now = configured and working between IdP and SaaS App >> Who else is interested in solving this? >> =20 >> Is there interest in working on this in either SCIM or OAUTH Wgs? >> =20 >> Any one in BA interested in meeting on this topic this week? >> =20 >> =E2=80=94 Dick >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim = --Apple-Mail=_6F784970-221A-49B5-B21B-6C0A3490A0AA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I think it is worth discussing in oauth wg.

While = SCIM has issues, I think it represents a broader use case that other = applications have that are deployed widely.

Phil



On Apr 6, 2016, at 9:52 AM, Hardt, Dick <dick@amazon.com> = wrote:

Sounds like there is = interest.

SCIM or = OAUTH?

-- Dick

On Apr 6, = 2016, at 8:57 AM, Anthony Nadalin <tonynad@microsoft.com> = wrote:

I would = be interested also

 

Sent from = my Windows 10 phone

 

From: Gil Kirkpatrick
Sent: Wednesday, April 6, = 2016 4:16 AM
To: 'Nat Sakimura'; 'Hardt, Dick'; 'Phil Hunt (IDM)'
Cc: scim@ietf.org; oauth@ietf.org
Subject: Re: [scim] [OAUTH-WG] = Simple Federation Deployment

 

That=E2=80=99s an issue = we=E2=80=99re facing as well. Definitely interested.

 

-gil

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf = Of Nat Sakimura
Sent: Wednesday, April 6, 2016 = 4:57 PM
To: 'Hardt, Dick' <dick@amazon.com>; 'Phil = Hunt (IDM)' <phil.hunt@oracle.com>
Cc: scim@ietf.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] [scim] = Simple Federation Deployment

 

 

Nat

 

--
PLEASE READ :This e-mail is = confidential and intended for the
named recipient only. = If you are not an intended recipient,
please notify the = sender  and delete this e-mail.

 

From: scim [mailto:scim-bounces@ietf.org] On Behalf = Of Hardt, Dick
Sent: Wednesday, April 6, 2016 = 7:26 AM
To: Phil Hunt (IDM) <phil.hunt@oracle.com>
Cc: scim@ietf.org; oauth@ietf.org
Subject: Re: [scim] Simple = Federation Deployment

 

I=E2=80=99m = talking about removing manual steps in what happens today where = configuring a SaaS app at an IdP (such as Google, Azure, Ping, Octa) = requires is a bunch of cutting and pasting of access tokens / keys / = certs and doing a bunch of  config that is error prone and unique = for each relationship.

 

Don=E2=80=99t want to solve on the = thread =E2=80=A6 looking to see if there is = interest!

 

On 4/5/16, 7:11 PM, someone claiming to be "scim = on behalf of Phil Hunt (IDM)" <scim-bounces@ietf.org on behalf of phil.hunt@oracle.com> = wrote:

 

Is the idp the = center of all things for these users?
 

Usually you have a provisioning system = that coordinates state and uses things like scim connectors to do = this. 

 

Another approach from today would be to pass a scim event to = the remote provider which then decides what needs to be done to = facilitate the thingd you describe. 

 

Iow. Either the idp (sender) or the sp = (receiver) have a provisioning system to do = this. 

 

The solution and the simplicity depends on where the control = needs to be. 

Phil


On Apr 5, = 2016, at 18:59, Hardt, Dick <dick@amazon.com> wrote:

Use case: An admin for an organization would = like to enable her users to access a SaaS application at her = IdP. 

 

User experience: 
  1. Admin authenticates to IdP in browser
  2. Admin selects SaaS app to federate with from list at = IdP
  3. IdP optionally presents config = options
  4. IdP redirects Admin to SaaS app
  5. Admin authenticates to SaaS app
  6. SaaS app optionally gathers config options
  7. SaaS app redirects admin to IdP
  8. IdP confirms successful federation =3D> OIDC / SAML and = SCIM are now configured and working between IdP and SaaS = App
Who else is interested in solving = this?

 

Is there interest in working on this in either SCIM or OAUTH = Wgs?

 

Any one in BA interested in meeting on this topic this = week?

 

=E2=80=94 = Dick
_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim

= --Apple-Mail=_6F784970-221A-49B5-B21B-6C0A3490A0AA-- From nobody Wed Apr 6 06:06:54 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C2712D1B2 for ; Wed, 6 Apr 2016 06:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VxlOcANh6t3 for ; Wed, 6 Apr 2016 06:06:42 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9B3612D506 for ; Wed, 6 Apr 2016 06:05:55 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id q128so54885560iof.3 for ; Wed, 06 Apr 2016 06:05:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5EoJG6lqVr/7q5hM8iN0V8Qjh4+mtTCz5ECGWPRcB4Q=; b=G+trvPveyRYz5O73qD70stRMB4z2ArXlrizdRvEyiVCX7wK1g5/zSvT84yQCrsdM9f IXr9NYU6Qhz5cDYWAijWvbHiC3PdDb4NG07Z0ZmVNY4rWCYj0WfcR875m27LtqKUW3wT d5zcRwAa5tcYXR/Gf1erDe2Rnw1p3JtXWVIuA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5EoJG6lqVr/7q5hM8iN0V8Qjh4+mtTCz5ECGWPRcB4Q=; b=gSMqhYGPf+bqA3WaTdtdRqqltokFvh2fyvJOZUrU7Mf6xGMc2HT0ot1zbyrenL5+P3 bR4vl7RU5SV1u+zwkB2zGfFVzyXtJAMfV/29QnCwOl8WE5g4tVeNaHdZ2taqyisJcqcH OQpTh6OazRHVymNyRuTzpaeFtHWlMeButP+fMfxXMbIW50y85N1ma91+hG1o8qyaQ2gJ PFdeYN7baFEFQAf17GfXMTgpQDG/kbKe4zmrp0kxgsK1AB1NVA2VShiCux6fIB2I9nFy 4rlXv9U30gA1mpsUIHMOlzMZKma6U1ZAogDSseMMkSTO+zTt0hwbYi0VYJmMl1FHIO/I PxNQ== X-Gm-Message-State: AD7BkJIx+gSllNElTDkEu5V6MaGCKKCkagtlm8hxaft1Pb4qm4LLlRlOM/t4VqG53H7AHlOW75+ywbqevvCk9lvD X-Received: by 10.107.13.133 with SMTP id 127mr25712945ion.129.1459947955193; Wed, 06 Apr 2016 06:05:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.74.162 with HTTP; Wed, 6 Apr 2016 06:05:25 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Wed, 6 Apr 2016 10:05:25 -0300 Message-ID: To: Anthony Nadalin Content-Type: multipart/alternative; boundary=001a113ffc7042c4f2052fd09fe4 Archived-At: Cc: "scim@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment server to server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 13:06:52 -0000 --001a113ffc7042c4f2052fd09fe4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable OpenID ... ? On Wed, Apr 6, 2016 at 9:59 AM, Anthony Nadalin wrote: > Good question, since SCIM does not really provide an authorization model > and Oauth does not do provisioning this is sort of caught in the middle, = so > if I had to pick I would pick Oauth as this is a generic server to server > issue > > > > *From:* Hardt, Dick [mailto:dick@amazon.com] > *Sent:* Wednesday, April 6, 2016 5:52 AM > *To:* Anthony Nadalin > *Cc:* Gil Kirkpatrick ; Nat Sakimura < > n-sakimura@nri.co.jp>; Phil Hunt (IDM) ; > scim@ietf.org; oauth@ietf.org > *Subject:* Re: [scim] [OAUTH-WG] Simple Federation Deployment > > > > Sounds like there is interest. > > > > SCIM or OAUTH? > > -- Dick > > > On Apr 6, 2016, at 8:57 AM, Anthony Nadalin wrote= : > > I would be interested also > > > > Sent from my Windows 10 phone > > > > *From: *Gil Kirkpatrick > *Sent: *Wednesday, April 6, 2016 4:16 AM > *To: *'Nat Sakimura' ; 'Hardt, Dick' > ; 'Phil Hunt (IDM)' > *Cc: *scim@ietf.org; oauth@ietf.org > *Subject: *Re: [scim] [OAUTH-WG] Simple Federation Deployment > > > > That=E2=80=99s an issue we=E2=80=99re facing as well. Definitely interest= ed. > > > > -gil > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org ] *O= n > Behalf Of *Nat Sakimura > *Sent:* Wednesday, April 6, 2016 4:57 PM > *To:* 'Hardt, Dick' ; 'Phil Hunt (IDM)' < > phil.hunt@oracle.com> > *Cc:* scim@ietf.org; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] [scim] Simple Federation Deployment > > > > +1 for removing the manual cut-n-pastes! > > > > Nat > > > > -- > > PLEASE READ :This e-mail is confidential and intended for the > > named recipient only. If you are not an intended recipient, > > please notify the sender and delete this e-mail. > > > > *From:* scim [mailto:scim-bounces@ietf.org ] *On > Behalf Of *Hardt, Dick > *Sent:* Wednesday, April 6, 2016 7:26 AM > *To:* Phil Hunt (IDM) > *Cc:* scim@ietf.org; oauth@ietf.org > *Subject:* Re: [scim] Simple Federation Deployment > > > > I=E2=80=99m talking about removing manual steps in what happens today whe= re > configuring a SaaS app at an IdP (such as Google, Azure, Ping, Octa) > requires is a bunch of cutting and pasting of access tokens / keys / cert= s > and doing a bunch of config that is error prone and unique for each > relationship. > > > > Don=E2=80=99t want to solve on the thread =E2=80=A6 looking to see if the= re is interest! > > > > On 4/5/16, 7:11 PM, someone claiming to be "scim on behalf of Phil Hunt > (IDM)" wrote: > > > > Is the idp the center of all things for these users? > > > > Usually you have a provisioning system that coordinates state and uses > things like scim connectors to do this. > > > > Another approach from today would be to pass a scim event to the remote > provider which then decides what needs to be done to facilitate the thing= d > you describe. > > > > Iow. Either the idp (sender) or the sp (receiver) have a provisioning > system to do this. > > > > The solution and the simplicity depends on where the control needs to be. > > Phil > > > On Apr 5, 2016, at 18:59, Hardt, Dick wrote: > > Use case: An admin for an organization would like to enable her users to > access a SaaS application at her IdP. > > > > User experience: > > 1. Admin authenticates to IdP in browser > 2. Admin selects SaaS app to federate with from list at IdP > 3. IdP optionally presents config options > 4. IdP redirects Admin to SaaS app > 5. Admin authenticates to SaaS app > 6. SaaS app optionally gathers config options > 7. SaaS app redirects admin to IdP > 8. IdP confirms successful federation =3D> OIDC / SAML and SCIM are no= w > configured and working between IdP and SaaS App > > Who else is interested in solving this? > > > > Is there interest in working on this in either SCIM or OAUTH Wgs? > > > > Any one in BA interested in meeting on this topic this week? > > > > =E2=80=94 Dick > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a113ffc7042c4f2052fd09fe4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OpenID ... ?

On Wed, Apr 6, 2016 at 9:59 AM, Anthony Nadalin <tonynad@microsoft.com> wrote:

Good question, since SCIM does not really provide an= authorization model and Oauth does not do provisioning this is sort of cau= ght in the middle, so if I had to pick I would pick Oauth as this is a gene= ric server to server issue

<= u>=C2=A0

From: Hardt, Dick [mailto:dick@amazon.com]
Sent: Wednesday, April 6, 2016 5:52 AM
To: Anthony Nadalin <tonynad@microsoft.com>
Cc: Gil Kirkpatrick <gil.kirkpatrick@viewds.com>; Nat Sakimura <n-sakimura@nri.co.j= p>; Phil Hunt (IDM) <phil.hunt@oracle.com>; scim@ietf.org; oauth@ietf.org
Subject: Re: [scim] [OAUTH-WG] Simple Federation Deployment

=C2=A0

Sounds like there is interest.

=C2=A0

SCIM or OAUTH?

-- Dick


On Apr 6, 2016, at 8:57 AM, Anthony Nadalin <tonynad@microsoft.com> wrote:=

I would be interested also

=C2=A0

Sent from my Windows 10 phone

=C2=A0

From: Gil Kirkpatrick
Sent: Wednesday, April 6, 2016 4:16 AM
To: 'N= at Sakimura'; 'Hardt, Dick'; 'Phil Hunt (IDM)'
Cc: scim@ietf.org= ; oauth@ietf.org
Subject: Re: [scim] [OAUTH-WG] Simple Federation Deployment

=C2=A0

That=E2=80=99s an issu= e we=E2=80=99re facing as well. Definitely interested.=

=C2=A0

-gil<= /u>

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura
Sent: Wednesday, April 6, 2016 4:57 PM
To: 'Hardt, Dick' <dick@amazon.com>; 'Phil Hunt (IDM)' <phil.hunt@oracle.com>
Cc: scim@ietf.org= ; oauth@ietf.org
Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment

=C2=A0

+1 for removing the manual cut-n-pastes= !

=C2=A0

Nat

=C2=A0

--

PLEASE READ :This e-mail is confidential and i= ntended for the

named recipient only. If you are not an intend= ed recipient,

please notify the sender=C2=A0 and delete this= e-mail.

=C2=A0

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Hardt, Dick
Sent: Wednesday, April 6, 2016 7:26 AM
To: Phil Hunt (IDM) <phil.hunt@oracle.com>
Cc: scim@ietf.org= ; oauth@ietf.org
Subject: Re: [scim] Simple Federation Deployment

=C2=A0

I=E2=80= =99m talking about removing manual steps in what happens today where config= uring a SaaS app at an IdP (such as Google, Azure, Ping, Octa) requires is = a bunch of cutting and pasting of access tokens / keys / certs and doing a bunch of =C2=A0config that is error prone and u= nique for each relationship.

=C2=A0<= /span>

Don=E2= =80=99t want to solve on the thread =E2=80=A6 looking to see if there is in= terest!

=C2=A0<= /span>

On 4/5/= 16, 7:11 PM, someone claiming to be "scim on behalf of Phil Hunt (IDM)= " <scim-= bounces@ietf.org on behalf of phil.hunt@oracle.= com> wrote:

=C2=A0<= /span>

Is the = idp the center of all things for these users?

=C2=A0<= /span>

Usually= you have a provisioning system that coordinates state and uses things like= scim connectors to do this.=C2=A0

=C2=A0<= /span>

Another= approach from today would be to pass a scim event to the remote provider w= hich then decides what needs to be done to facilitate the thingd you descri= be.=C2=A0

=C2=A0<= /span>

Iow. Ei= ther the idp (sender) or the sp (receiver) have a provisioning system to do= this.=C2=A0

=C2=A0<= /span>

The sol= ution and the simplicity depends on where the control needs to be.=C2=A0
Phil


On Apr 5, 2016, at 18:59, Hardt, Dick <dick@amazon.com> wrote:

Use cas= e: An admin for an organization would like to enable her users to access a = SaaS application at her IdP.=C2=A0

=C2=A0<= /span>

User ex= perience:=C2=A0

  1. Admin authenticates to IdP in browser
  2. Admi= n selects SaaS app to federate with from list at IdP
  3. IdP optionally presents config options
  4. = IdP redirects Admin to SaaS app
  5. Admin authenti= cates to SaaS app
  6. SaaS app optionally gathers = config options
  7. SaaS app redirects admin to IdP=
  8. IdP confirms successful federation =3D> OI= DC / SAML and SCIM are now configured and working between IdP and SaaS App<= /span>

Who els= e is interested in solving this?

=C2=A0<= /span>

Is ther= e interest in working on this in either SCIM or OAUTH Wgs?=

=C2=A0<= /span>

Any one= in BA interested in meeting on this topic this week?<= /p>

=C2=A0<= /span>

=E2=80= =94 Dick

_______= ________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim=


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


--001a113ffc7042c4f2052fd09fe4-- From nobody Wed Apr 6 07:45:30 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C494012D5F9; Wed, 6 Apr 2016 07:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.541 X-Spam-Level: X-Spam-Status: No, score=-12.541 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaLiZ1LWH5pe; Wed, 6 Apr 2016 07:45:15 -0700 (PDT) Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.189.228]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 093D712D67F; Wed, 6 Apr 2016 07:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1459953883; x=1491489883; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=19DyrjfzGv8ASl9wfRoXpTM2tZa77H2EgDl2txS/BdQ=; b=mvbuCgf4cPCZOrvR/UwCAcAbeB/z91bSOnguqnyC5UwueB8ZkRP158xM p+YMybb9WTTS8R9DVbyl1NhpOqEWla0INOjYkpM0S7k0x5umGLdy/38+Z zH4uG0BW5wQ6qkO5FoD2JaaNDf0KYVF1TmN4LfIhrtX+iE9ZlMyyjw2Jw s=; X-IronPort-AV: E=Sophos;i="5.24,447,1454976000"; d="scan'208,217";a="471551500" Received: from sea19-co-svc-lb5-vlan2.sea.amazon.com (HELO email-inbound-relay-64017.pdx4.amazon.com) ([10.47.22.162]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Apr 2016 14:44:38 +0000 Received: from ex10-hub-7002.ant.amazon.com (pdx1-ws-svc-lb16-vlan2.amazon.com [10.239.138.210]) by email-inbound-relay-64017.pdx4.amazon.com (8.14.7/8.14.7) with ESMTP id u36EiWOI012425 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Apr 2016 14:44:37 GMT Received: from EX13D03UWA004.ant.amazon.com (10.43.160.250) by ex10-hub-7002.ant.amazon.com (10.43.110.153) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 6 Apr 2016 07:44:10 -0700 Received: from EX13D03UWA001.ant.amazon.com (10.43.160.141) by EX13D03UWA004.ant.amazon.com (10.43.160.250) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 6 Apr 2016 14:44:09 +0000 Received: from EX13D03UWA001.ant.amazon.com ([10.43.160.141]) by EX13D03UWA001.ant.amazon.com ([10.43.160.141]) with mapi id 15.00.1104.000; Wed, 6 Apr 2016 14:44:09 +0000 From: "Hardt, Dick" To: Brian Campbell Thread-Topic: [OAUTH-WG] [scim] Simple Federation Deployment server to server Thread-Index: AQHRkAUV47DkspjcTE29bhDf8xdvHp99BYNG Date: Wed, 6 Apr 2016 14:44:08 +0000 Message-ID: <5AF80C71-D0E2-4B49-B135-42969B95D851@amazon.com> References: , 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_5AF80C71D0E24B49B13542969B95D851amazoncom_" MIME-Version: 1.0 Precedence: Bulk Archived-At: Cc: "oauth@ietf.org" , "scim@ietf.org" Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment server to server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 14:45:27 -0000 --_000_5AF80C71D0E24B49B13542969B95D851amazoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Given this is authorization and configuration, both of which are being done= in OAuth, it makes sense to me to do it there. I brought SCIM into the dis= cussion as this type of work may be were that WG wants to go. -- Dick On Apr 6, 2016, at 10:06 AM, Brian Campbell > wrote: OpenID ... ? On Wed, Apr 6, 2016 at 9:59 AM, Anthony Nadalin > wrote: Good question, since SCIM does not really provide an authorization model an= d Oauth does not do provisioning this is sort of caught in the middle, so i= f I had to pick I would pick Oauth as this is a generic server to server is= sue From: Hardt, Dick [mailto:dick@amazon.com] Sent: Wednesday, April 6, 2016 5:52 AM To: Anthony Nadalin > Cc: Gil Kirkpatrick >; Nat Sakimura >;= Phil Hunt (IDM) >; scim@= ietf.org; oauth@ietf.org Subject: Re: [scim] [OAUTH-WG] Simple Federation Deployment Sounds like there is interest. SCIM or OAUTH? -- Dick On Apr 6, 2016, at 8:57 AM, Anthony Nadalin > wrote: I would be interested also Sent from my Windows 10 phone From: Gil Kirkpatrick Sent: Wednesday, April 6, 2016 4:16 AM To: 'Nat Sakimura'; 'Hardt, Dick'; 'Phil Hunt (IDM)' Cc: scim@ietf.org; oauth@ietf.org Subject: Re: [scim] [OAUTH-WG] Simple Federation Deployment That's an issue we're facing as well. Definitely interested. -gil From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura Sent: Wednesday, April 6, 2016 4:57 PM To: 'Hardt, Dick' >; 'Phil Hunt (ID= M)' > Cc: scim@ietf.org; oauth@ietf.org Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment +1 for removing the manual cut-n-pastes! Nat -- PLEASE READ :This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail. From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Hardt, Dick Sent: Wednesday, April 6, 2016 7:26 AM To: Phil Hunt (IDM) > Cc: scim@ietf.org; oauth@ietf.org Subject: Re: [scim] Simple Federation Deployment I'm talking about removing manual steps in what happens today where configu= ring a SaaS app at an IdP (such as Google, Azure, Ping, Octa) requires is a= bunch of cutting and pasting of access tokens / keys / certs and doing a b= unch of config that is error prone and unique for each relationship. Don't want to solve on the thread ... looking to see if there is interest! On 4/5/16, 7:11 PM, someone claiming to be "scim on behalf of Phil Hunt (ID= M)" on behalf of phil.= hunt@oracle.com> wrote: Is the idp the center of all things for these users? Usually you have a provisioning system that coordinates state and uses thin= gs like scim connectors to do this. Another approach from today would be to pass a scim event to the remote pro= vider which then decides what needs to be done to facilitate the thingd you= describe. Iow. Either the idp (sender) or the sp (receiver) have a provisioning syste= m to do this. The solution and the simplicity depends on where the control needs to be. Phil On Apr 5, 2016, at 18:59, Hardt, Dick > wrote: Use case: An admin for an organization would like to enable her users to ac= cess a SaaS application at her IdP. User experience: 1. Admin authenticates to IdP in browser 2. Admin selects SaaS app to federate with from list at IdP 3. IdP optionally presents config options 4. IdP redirects Admin to SaaS app 5. Admin authenticates to SaaS app 6. SaaS app optionally gathers config options 7. SaaS app redirects admin to IdP 8. IdP confirms successful federation =3D> OIDC / SAML and SCIM are now = configured and working between IdP and SaaS App Who else is interested in solving this? Is there interest in working on this in either SCIM or OAUTH Wgs? Any one in BA interested in meeting on this topic this week? - Dick _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_5AF80C71D0E24B49B13542969B95D851amazoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Given this is authorization and configuration, both of which are being= done in OAuth, it makes sense to me to do it there. I brought SCIM into th= e discussion as this type of work may be were that WG wants to go.

-- Dick

On Apr 6, 2016, at 10:06 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

OpenID ... ?

On Wed, Apr 6, 2016 at 9:59 AM, Anthony Nadalin = <tonynad@micr= osoft.com> wrote:

Good question, since SCIM does not really provide an= authorization model and Oauth does not do provisioning this is sort of cau= ght in the middle, so if I had to pick I would pick Oauth as this is a gene= ric server to server issue

<= u> 

From: Hardt, Dick [mailto:dick@amazon.com]
Sent: Wednesday, April 6, 2016 5:52 AM
To: Anthony Nadalin <tonynad@microsoft.com>
Cc: Gil Kirkpatrick <gil.kirkpatrick@viewds.com>; Nat Sakimura <n-sakimura@nri.co.j= p>; Phil Hunt (IDM) <phil.hunt@oracle.com>; scim@ietf.org; oauth@ietf.org
Subject: Re: [scim] [OAUTH-WG] Simple Federation Deployment

 

Sounds like there is interest.

 

SCIM or OAUTH?

-- Dick


On Apr 6, 2016, at 8:57 AM, Anthony Nadalin <tonynad@microsoft.com> wrote:=

I would be interested also

 

Sent from my Windows 10 phone

 

From: Gil Kirkpatrick
Sent: Wednesday, April 6, 2016 4:16 AM
To: 'Nat S= akimura'; 'Hardt, Dick'; 'Phil Hunt (IDM)'
Cc: scim@ietf.org= ; oauth@ietf.org
Subject: Re: [scim] [OAUTH-WG] Simple Federation Deployment

 

That’s an issue = we’re facing as well. Definitely interested.

 

-gil<= /u>

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura
Sent: Wednesday, April 6, 2016 4:57 PM
To: 'Hardt, Dick' <dick@amazon.com>; 'Phil Hunt (IDM)' <phil.hunt@oracle.com>
Cc: scim@ietf.org= ; oauth@ietf.org
Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment

 

+1 for removing the manual cut-n-pa= stes!

 

Nat

 

--

PLEASE READ :This e-mail is confidential and i= ntended for the

named recipient only. If you are not an intend= ed recipient,

please notify the sender  and delete this= e-mail.

 

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Hardt, Dick
Sent: Wednesday, April 6, 2016 7:26 AM
To: Phil Hunt (IDM) <phil.hunt@oracle.com>
Cc: scim@ietf.org= ; oauth@ietf.org
Subject: Re: [scim] Simple Federation Deployment

 

I’= ;m talking about removing manual steps in what happens today where configur= ing a SaaS app at an IdP (such as Google, Azure, Ping, Octa) requires is a = bunch of cutting and pasting of access tokens / keys / certs and doing a bunch of  config that is error prone and u= nique for each relationship.

 <= /span>

DonR= 17;t want to solve on the thread … looking to see if there is interes= t!

 <= /span>

On 4/5/= 16, 7:11 PM, someone claiming to be "scim on behalf of Phil Hunt (IDM)= " <scim-= bounces@ietf.org on behalf of phil.hunt@oracle.= com> wrote:

 <= /span>

Is the = idp the center of all things for these users?

 <= /span>

Usually= you have a provisioning system that coordinates state and uses things like= scim connectors to do this. 

 <= /span>

Another= approach from today would be to pass a scim event to the remote provider w= hich then decides what needs to be done to facilitate the thingd you descri= be. 

 <= /span>

Iow. Ei= ther the idp (sender) or the sp (receiver) have a provisioning system to do= this. 

 <= /span>

The sol= ution and the simplicity depends on where the control needs to be. 
Phil


On Apr 5, 2016, at 18:59, Hardt, Dick <dick@amazon.com> wrote:

Use cas= e: An admin for an organization would like to enable her users to access a = SaaS application at her IdP. 

 <= /span>

User ex= perience: 

  1. Admin authenticates to IdP in browser
  2. Admi= n selects SaaS app to federate with from list at IdP
  3. IdP optionally presents config options
  4. = IdP redirects Admin to SaaS app
  5. Admin authenti= cates to SaaS app
  6. SaaS app optionally gathers = config options
  7. SaaS app redirects admin to IdP=
  8. IdP confirms successful federation =3D> OI= DC / SAML and SCIM are now configured and working between IdP and SaaS App<= /span>

Who els= e is interested in solving this?

 <= /span>

Is ther= e interest in working on this in either SCIM or OAUTH Wgs?=

 <= /span>

Any one= in BA interested in meeting on this topic this week?<= /p>

 <= /span>

—= Dick

_______= ________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim=


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


--_000_5AF80C71D0E24B49B13542969B95D851amazoncom_-- From nobody Wed Apr 6 10:16:04 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B8A12D5F8 for ; Wed, 6 Apr 2016 10:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mitre.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6zlXu8gFDHO for ; Wed, 6 Apr 2016 10:15:53 -0700 (PDT) Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD4B12D5F0 for ; Wed, 6 Apr 2016 10:15:53 -0700 (PDT) Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EDB2F6C086A for ; Wed, 6 Apr 2016 13:15:52 -0400 (EDT) Received: from imshyb02.MITRE.ORG (imshyb02.mitre.org [129.83.29.3]) by smtpvmsrv1.mitre.org (Postfix) with ESMTP id DDD236C0861 for ; Wed, 6 Apr 2016 13:15:52 -0400 (EDT) Received: from imshyb02.MITRE.ORG (129.83.29.3) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 6 Apr 2016 13:15:52 -0400 Received: from gcc01-dm2-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1130.7 via Frontend Transport; Wed, 6 Apr 2016 13:15:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.onmicrosoft.com; s=selector1-mitre-org; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Zk6AkptvQUqAuOzM5mAur/kDlCbouMVDCz+LOriF7H8=; b=W5MkNxaoaZx18B5VWAbec9gB80QUYkomUuXAuU7RAXQLdmuLxv8YZtuyNoMEp0ioWdAZ5gldOZowvevIqJulG2sEqO8+Z6+ncATi8Z1HLjwvPVaKBUb79g2q1Zp7k0itJyDIQT450zwVQAx0tqeG7XWy6Y3ocpv9tuoy7nGAQ2E= Received: from BY2PR09MB0280.namprd09.prod.outlook.com (10.160.65.23) by BY2PR09MB0278.namprd09.prod.outlook.com (10.160.65.21) with Microsoft SMTP Server (TLS) id 15.1.447.15; Wed, 6 Apr 2016 17:15:46 +0000 Received: from BY2PR09MB0280.namprd09.prod.outlook.com ([10.160.65.23]) by BY2PR09MB0280.namprd09.prod.outlook.com ([10.160.65.23]) with mapi id 15.01.0447.028; Wed, 6 Apr 2016 17:15:46 +0000 From: "Kim, William G" To: "oauth@ietf.org" Thread-Topic: afternoon oauth ietf meeting Thread-Index: AQHRkCf1iWsTzZBH9U+D8xMI+9sWHQ== Date: Wed, 6 Apr 2016 17:15:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=mitre.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [192.160.51.87] x-ms-office365-filtering-correlation-id: 7948d094-4092-441e-f8cb-08d35e3f180f x-microsoft-exchange-diagnostics: 1; BY2PR09MB0278; 5:KryQmfabsCKU0PKSj72RZTJAbA5slO8zqOXAaSY29vascNXbcI96SPe/edqo7r7067/HEjoWvPmT/6MDQd/q7pL7My+kkDggadWp+76vLaEKM8hACMrMXrZlVhNFblUk5T+uR4RaocVaznhODGsBCQ==; 24:d1wsWw66s2Sl3sF01bQV8BGtPLSlhPk1qETrjfLEXeoeRBj7Vkd07c/ABrm89gh/4+2rfdq4CyOCBRf61HxPaTeml5q7Z/TD2BLMfISyurI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR09MB0278; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BY2PR09MB0278; BCL:0; PCL:0; RULEID:; SRVR:BY2PR09MB0278; x-forefront-prvs: 0904004ECB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(92566002)(50986999)(3480700003)(83506001)(77096005)(54356999)(5002640100001)(3660700001)(2900100001)(11100500001)(86362001)(4001350100001)(102836003)(3846002)(82746002)(122556002)(99286002)(10400500002)(6116002)(110136002)(2351001)(107886002)(229853001)(106116001)(81166005)(16236675004)(36756003)(450100001)(1220700001)(1096002)(83716003)(3280700002)(5640700001)(87936001)(33656002)(189998001)(2906002)(1730700002)(2501003)(586003)(558084003)(5008740100001)(66066001)(5004730100002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR09MB0278; H:BY2PR09MB0280.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_EB973BE4B0A9423E87AB8D8D46850563mitreorg_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2016 17:15:46.6834 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR09MB0278 X-OriginatorOrg: mitre.org Archived-At: Subject: [OAUTH-WG] afternoon oauth ietf meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 17:16:04 -0000 --_000_EB973BE4B0A9423E87AB8D8D46850563mitreorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2lsbCB0aGUgMm5kIE9BdXRoIG1lZXRpbmcgdGhpcyBhZnRlcm5vb24gaGFwcGVuIGluIGEgcm9v bSB3aXRoIHJlbW90ZSBzdXBwb3J0PyBBcmUgdGhlcmUgYW55IG9wdGlvbnMgdG8gYmUgYWJsZSB0 byByZW1vdGVseSBsaXN0ZW4gaW4gdG8gdGhpcyBkaXNjdXNzaW9uPw0KDQotV2lsbGlhbQ0KDQo= --_000_EB973BE4B0A9423E87AB8D8D46850563mitreorg_ Content-Type: text/html; charset="utf-8" Content-ID: <730B6BCC55A87141BF5277CD81012345@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5XaWxsIHRoZSAy bmQgT0F1dGggbWVldGluZyB0aGlzIGFmdGVybm9vbiBoYXBwZW4gaW4gYSByb29tIHdpdGggcmVt b3RlIHN1cHBvcnQ/IEFyZSB0aGVyZSBhbnkgb3B0aW9ucyB0byBiZSBhYmxlIHRvIHJlbW90ZWx5 IGxpc3RlbiBpbiB0byB0aGlzIGRpc2N1c3Npb24/PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj4tV2lsbGlhbTwvZGl2Pg0KPGJyPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_EB973BE4B0A9423E87AB8D8D46850563mitreorg_-- From nobody Wed Apr 6 10:22:50 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F42712D6BC for ; Wed, 6 Apr 2016 10:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOJveLm5xSuc for ; Wed, 6 Apr 2016 10:22:47 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2FF012D6B0 for ; Wed, 6 Apr 2016 10:22:46 -0700 (PDT) Received: from [192.168.10.140] ([31.133.155.135]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LzXTy-1bsWXI3OqI-014nTs for ; Wed, 06 Apr 2016 19:22:43 +0200 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <570545EB.3070803@gmx.net> Date: Wed, 6 Apr 2016 19:22:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="D6nk5uxurKn50e2ORXWDHTkFToALrGRor" X-Provags-ID: V03:K0:3Sk6spIUrIM/O8LrMmRFFPwEPpOG3/a69uWR/3/WRb/osgWRgOb VatOLc+GpAG3he/Zcd1vrD7yFdGdtyhFFwaiuOW1WFW2zXtENHvIAcSiDgFd+j8ylU/kkpK lgZm8SO+7JCOmsy63WRTlYdnp9WioVFi7nNaL2KC/r0e2kSX9nZJdXtjZfjyQwcz1kUDZeE Sf2ob1pK06qvbq6az1Gdw== X-UI-Out-Filterresults: notjunk:1;V01:K0:lfc8Z9jvsXg=:p8Ase41d9R2hsvQbmi2W/b WVb3JNdTMiSiPFOLaBLLgamsYt9J6FR8jzafwQGN6sGVOSlq76wj9mBkKqiKpwLTFu2WjUOSn d4fxDxkQlOWhTQzkW6St/ZIgRsfF1RDT0iJ4cCnyt5g8OKJE+UOwRZ7m9iR5ilz9gpHm8om4/ x3ROusxGobtEKWH9iRqoDkiLtCrbf1YBr0CYCQZBxO9S8HEs366y92saGTujC0qBZSko/bW0k 4bvXFc5tzofE6dQmh54Z0yclk7ZuUitR8NvUly/ltObclM9Hidb7Vq8aDVq/EvEdGkwK4eogs ex+GsWLvEuzxfIibjWtnlgJvI2TThm5vuDsiNxpQfkmnDLyI7lQedYbbpZHhsJKWX0v55TxHd p+PmZFM2eKO8OcfNr0K8UdEb5cjIiYgIaAQnf7i6lF7UeyUDoXYOiIl/xPJJkW9WPTYMRdm3z 9pB5RCsFNWzPwzlIzp1wNZYi3maLDahIAjV2GSrPG6Y/R1PCBJaqJ8ZPx77Q1GJ+Pdj5svdxA lCNvTuyP9QrzhU/xf/UqBI1PQeyE5qpivliGaJP3oMmm2XGCfeDavinICjBAnOb8grkuAotIg jP/qOeH8Xen2r0Kw9Oy1UH+nDEZkfsF7k5+wUhCX0zEA2vrb96/9khCI6XFjlp1VKaQ7/MXBo 6vXqoT89apZy2D7ukzFnreqMCNAfRnu/2k4uodSON4y8evjVGy3hPYyxfXhNu+ofSjaPC0XhF /MfRi8AGLccO45NIWahIErVS/WuXAm9chaVGs4vZwuGWJn9YI53f9oEAsuk= Archived-At: Subject: [OAUTH-WG] Design Team on "OAuth Discovery" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 17:22:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --D6nk5uxurKn50e2ORXWDHTkFToALrGRor Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, today at the face-to-face meeting we decided to create a design team to work on the OAuth discovery spec. This is a short term design team that will report back to the group at the virtual interim meeting end of May/beginning of June. There are three input documents: -------- - OAuth 2.0 Authorization Server Discovery Metadata https://datatracker.ietf.org/doc/draft-ietf-oauth-discovery/ - OAuth Response Metadata https://datatracker.ietf.org/doc/draft-sakimura-oauth-meta/ - OAuth 2.0 Bound Configuration Lookup https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00 -------- The following persons volunteered to be part of this design team: * Phil, Mike, Nat, John, Brian, Dick, Tony We will schedule conference calls to progress the work. If you are interested to join as well let me/us know. Ciao Hannes & Derek --D6nk5uxurKn50e2ORXWDHTkFToALrGRor 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 iQEcBAEBCgAGBQJXBUXrAAoJEGhJURNOOiAtIwYH/i+9jiOza2Vpq/bArywAgyob dezyln5wNQWqWjIzS/eX+04KJtDMZ+OUBgA7po45F5lJSRG+F3kxBczar7cfeDsI KnXgfPrbe6PZ5P2OKOajGLgebHzJZD8R8zME5QRuBhsHT4blu1zc408iV9VVU3bu 1ocOjilU1IjGOYSW8AmvFv2VGX0umoNpUxZwlT+6kWugdfnu87TUfi1KWtVjLKWK A3GdO5YO7ledrsYo/jyjNGbncAM0jyBTjw1QBzbFLsEDr2gXh3aRL7FvuZ60mfH1 H+fGw9zvxRT3eXEaQPfeKP0xhVm0ADT4W8eEZCnLhxZnODE+9tvh6lGu8bgcnuY= =ge4J -----END PGP SIGNATURE----- --D6nk5uxurKn50e2ORXWDHTkFToALrGRor-- From nobody Wed Apr 6 10:26:08 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B5E12D6BB for ; Wed, 6 Apr 2016 10:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62MyRi-GfZU9 for ; Wed, 6 Apr 2016 10:25:58 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E65E12D6DB for ; Wed, 6 Apr 2016 10:25:48 -0700 (PDT) Received: from [192.168.10.140] ([31.133.155.135]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MC3zg-1awgun2t5U-008r4W for ; Wed, 06 Apr 2016 19:25:46 +0200 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <570546A1.8040509@gmx.net> Date: Wed, 6 Apr 2016 19:25:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="OfUTkI660QTd9IJ8wmqOGphURnVav295I" X-Provags-ID: V03:K0:3lbUDaMON/6rIL2OJj/hMYNeKGI/iTyzB0QzCIOnE9tGP+FE8d+ jQN44G+P84WzFbTPbN1mddA0I4mahd+KHA63pBmuulc0V2wP0qwhFi5eof5irtFrC0kWFdu S3GKL1pRnOq6U53pImbGGWjyYBNb2jw4+w0W5uZQljNXCUPZRcX686YnX0UP9gRK4jwu2UA vzYEGFwGrwXNDxo2OoSjQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:owoRSsbGLaQ=:NTMG1BfzjenGnlBr6DXiNe rey4ou1RRpdD1cFh8M5OZfa9t+0laguYnct9JZ74UQqXYrEMCmgySvUp48NQNExH2xLlboin+ u1EsvwmDfC3arYYPiiAse6IhM0kxvGxdLFlrtN1O6tazMNZHGK3x24/2yueMynqPScoKCmjX6 J3rUxMmjMz56rd/GTvXvvxhr2ABqRRFkUPPlVqi49Ftg19QQXnJ5j3I9f7+d00iyRnY3Lm9KC pqiFKpGW4FseYBZ+EvyUbO5QNQ7+lrhHfihDn3tFbveJfYn1jUZ6E6rWSiapAbD0Cbbl2oAPc O3yW8Zg41iQ5cpz0K0YEdEazvnfAdfdFgVzMrqMoEobhJH5gSCq09CGbFua4usR/C/xY2NKU1 7i9vHaW9JKOORtHuZe1gt7ZjqibDy+DAA7PIAvXxkBQgEmURVCO/sYGeuX0HH+2yvmPjFi01w +B0pnJVwmGt1TU5EbezIwK2srbyz0MPgswiBQfADJMpmemEC4HfdytBK7gjwD8QcYuWXIopwc 0orbvKN2X+RwWvqQshIyXxirqsp0Iz0W/dpRzoV++JdDWmNH0YVN5mkRvVMVW8tDl9kAy2QUw ft43nziqc4pfaaxUhqzW/FNlbCzC5ez4jqaPwezxC6ca70ASw4U1oTkWuIscaD8FVcsbeTk+p nBgAHk3HjwWArczmI+UTXyCoV4uxFQdXxnK2rvpfSgMRcwzz52QoEMife5btTFT6kaDKF6G9m uCCmzr9Y1BauCie3eWmJGOwQC8uX6nS3cM2sOTRSRihXsv8rQX14giCoCk0= Archived-At: Subject: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 17:25:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OfUTkI660QTd9IJ8wmqOGphURnVav295I Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, this is the call for adoption of 'Resource Indicators for OAuth 2.0', see= http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/= Please let us know by April 20th 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 Buenos Aires then you don't need to re-state your opinion, if you want. The feedback at the BA IETF meeting was the following: ~10 persons for accepting the document and 0 persons against. Ciao Hannes & Derek --OfUTkI660QTd9IJ8wmqOGphURnVav295I 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 iQEcBAEBCgAGBQJXBUaiAAoJEGhJURNOOiAt64gH/3gD5J/Yr582hFmlfad+xICb yvYrZNs2kIyExQ+xpdb2eb9su2cYZRAUOPwcZqGGKwF62fxTnnV0ONLcxXnk8dBv mrrQqt5g9GGCNZdo930un9H8A+ZbMsX/NDv1Io0DAOrWR9hWzkOUjeSCNo4GTj6r 5wIJpVYMs8KLSTNODKoG8L1ZRUqOj9v8vIJZIDfqs4mywUb+4CSkOFw8viBfDVGh cr8q/LZqCNQHVngUt+a+XV3CBF4eVQYJcVth1b4AhL8GnvKOMk/LNyWmWs6PcJeD IXX22YPdUYxzd9JngDSQJFgfQdcvUQiA+namowjJMm0QrkAdtxqo9mnZMKkqWzU= =Hvzk -----END PGP SIGNATURE----- --OfUTkI660QTd9IJ8wmqOGphURnVav295I-- From nobody Wed Apr 6 10:31:32 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15CB12D6EA for ; Wed, 6 Apr 2016 10:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUvsQDL91o7J for ; Wed, 6 Apr 2016 10:31:28 -0700 (PDT) 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 C441712D623 for ; Wed, 6 Apr 2016 10:31:28 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id y204so67142374oie.3 for ; Wed, 06 Apr 2016 10:31:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=tZ51hrhjt2ENAkrHHBWNOf42TR/3f2DxFwEJZ6awarI=; b=br3nG3JAS6hCOfMDW/tyTsJTfjr26kqU82QnnvySUkDkJX7NaQ0XuNUeE895uniyzI DT9zB41vhzmb4KRjKui4Gzkl4/nZg/fWL5rNn0kgf7PmsnJcsBp39bK4QckDkUBs+kxz ULBg92/ogg106AkkQoBnKqDglaIK9POiDeHFVHUJVuD5d3mklY7kwywjiA/2pgKtwhgF kfBS16y2RWn/KPf7e82Aeiq63YiCeTUIQPXajqmEANJP/VRXM9+biEvQ7TMVEKe6GYv2 fFBKBJTbk0Vf9zuP12lQ8QLL+D7zp9nvB5K6QCXABD21bl+svadXDVz9cu0wmNtdKPvV YwXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=tZ51hrhjt2ENAkrHHBWNOf42TR/3f2DxFwEJZ6awarI=; b=TwhGEZ6rnSy5trtmzOxABQE2/WHJVD3nVkyMGTQozJGijl5dOLPtxNq1boiIAAul+R vhFGDeHGtxPCyZs7Qo7CbA6nMZ84N/0+AyhuxDmjiuZl2dq6EmTL9znwiVjCafaTfPr3 OJlcITBkU1ZwWX+c3klkZuiiR9dSoRRbBovMEmfmNbmI/4+q9SxiuenUArUkmS9vBMfc +hylrLMrk4Uv5H/kRBF0Asewi6j9PfU8hMqXPwiNNQczRMrTXTJLAdoWMZr1lKJXOfag L7c9t7M3jf4zqTwL3BES8O+1US7KoSPenwEesTSr4KZIoMEhYcU7Kw9+boJ4uFCDnAsv DUXw== X-Gm-Message-State: AD7BkJLc5Aq0RX8eZtPDvhRyHbOcecUwOhp9MWI/5dAuwx4eyOvEBYazLq7x3zkGfHpLh9uHJ3HrpiQQEeqGQxqi X-Received: by 10.202.69.134 with SMTP id s128mr5703880oia.97.1459963888007; Wed, 06 Apr 2016 10:31:28 -0700 (PDT) MIME-Version: 1.0 References: <570546A1.8040509@gmx.net> In-Reply-To: <570546A1.8040509@gmx.net> From: William Denniss Date: Wed, 06 Apr 2016 17:31:17 +0000 Message-ID: To: Hannes Tschofenig , "oauth@ietf.org" Content-Type: multipart/alternative; boundary=001a113dc9a2ee4cfd052fd454fc Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 17:31:30 -0000 --001a113dc9a2ee4cfd052fd454fc Content-Type: text/plain; charset=UTF-8 I support the adoption of this draft by the working group. We have an immediate use-case with the Token Binding for OAuth efforts. On Wed, Apr 6, 2016 at 2:26 PM Hannes Tschofenig wrote: > Hi all, > > this is the call for adoption of 'Resource Indicators for OAuth 2.0', see > http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/ > > Please let us know by April 20th 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 Buenos > Aires then you don't need to re-state your opinion, if you want. > > The feedback at the BA IETF meeting was the following: ~10 persons > for accepting the document and 0 persons against. > > Ciao > Hannes & Derek > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a113dc9a2ee4cfd052fd454fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I support the adoption of this draft by the working group.

We have = an immediate use-case with the Token Binding for OAuth efforts.
On Wed, Apr 6, 2016 at 2:26 PM Hannes = Tschofenig <hannes.tschofen= ig@gmx.net> wrote:
Hi all,<= br>
this is the call for adoption of 'Resource Indicators for OAuth 2.0'= ;, see
http://datatracker.ietf.org= /doc/draft-campbell-oauth-resource-indicators/

Please let us know by April 20th 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 Buenos
Aires then you don't need to re-state your opinion, if you want.

The feedback at the BA IETF meeting was the following: ~10 persons
for accepting the document and 0 persons against.

Ciao
Hannes & Derek

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--001a113dc9a2ee4cfd052fd454fc-- From nobody Wed Apr 6 10:35:43 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A364F12D6E4 for ; Wed, 6 Apr 2016 10:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Va_0aaIfbQJW for ; Wed, 6 Apr 2016 10:35:35 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60B6812D1DF for ; Wed, 6 Apr 2016 10:35:13 -0700 (PDT) Received: from [192.168.10.140] ([31.133.155.135]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M0PdN-1bfXu70vvR-00ubOB for ; Wed, 06 Apr 2016 19:35:11 +0200 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <570548D6.8010605@gmx.net> Date: Wed, 6 Apr 2016 19:35:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WXvqak44Cv2eDCAeCVvUs2estah3hl59J" X-Provags-ID: V03:K0:2+dfnDXE+sB77oAPZ12gFGxyhvGg0Il+/MFrR0icJcf9SkudUBP YkYyTCPvJ9OIds4NahyozxtFY/ZYMw0k2lxGDk5isAUrjaqUMWfg2juzVFYF3gdC2GNBHyz Nf9YDFQswG8IP5Ak3lFscBxfkz8LKPsALvBjuOWFmRw0hJfgDh74GdZSkyfBOGhLyk9jNLP u8kyybMgY+I/4YAYv4mrQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:E+75HNJrZN0=:MbQOU2iE06+VEnggGP1Y+e zC+jD6zy5mGOcz4pKTPPL3NYZAR3OF42YxB7pv/E99hKcAmIBSPgFobCtFs7wPEvEWKTIIDlC m2h6v1O3eo+00UgGvUFxbmpBYqAkWXMHwyps0veca+d/150xW1dLBafJlNPFrBQzHtH/qIv0B PUDVCjGNdHxHqiapyx75wc/OVLeyYUMTiNBEF8fsNS2A4jc6dVehXlhjWT7x0cPrLQNwy7d/M rKQFhIQdBsC4HOmQWAr7GzZwFf3JWwX1E02FA8EzsrlIcyMxmD8zE0ruHHE6Puv9I0L+Qg9sn nZiI9ojnFrAYzodc6ZvlR6zlr+AwPoicIsaEQksu21rQuBTiHBcEIBHT7R6e/3XeHEzxpgqbQ 1LwHao6MBLwkDMo05lI5xAMQ8Rk21+yiX3FSfpwqrzjVfAIObAqgvjqSYE1ypebSmMo9eopUK tg2UMGYwfXKFPl5GfMHz2xy72mu2QZymbQZ7P3mHzZCAEReoULXLLtNEz0urWhUAFaZmjIlZC WghWi2q7Kr33kI1c9eUy7AEJLSyZP2DVPzLU3fwZgsY2ZnZgMJrf4izAOouYxr3dKSqUJAWX8 ETJgOdP4EMAFHkk3/Hutjl5rapd9j78dPH8kMYjc5EuuUhDydyPLXkchTMVoMDm1mMSjLbdD7 36d7TDxplfUdOgIznDYh/NhM1iZPKhelIi9GFAW6h1DC3n2g4uj/3Wgj6m0y0WRrtJUHEi4/M NDZaYOAAFqy5p24hA6j5DkIG4vKKhKCZArjdVh/YAPO0r789eV0WrvyPkQw= Archived-At: Subject: [OAUTH-WG] OAuth 2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 17:35:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WXvqak44Cv2eDCAeCVvUs2estah3hl59J Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, today we discussed the OAuth Authorization Server Mixup draft. We were wondering what types of threats the document should find solutions for. We discussed various document handling approaches including * OAuth Mix-Up and Cut-and-Paste attacks documented in separate solution documents * combined solution document covering the OAuth Mix-Up and the Cut-and-Paste attacks. Barry pointed out that these documents could update the OAuth base specification. As a more radical change it was also suggested to revise RFC 6749 "OAuth 2.0 Authorization Framework" and RFC 6819 "OAuth 2.0 Threat Model and Security Considerations". Opening up the OAuth base specification obviously raises various other questions about cleaning up parts that go far beyond the AS mix-up and the cut-and-paste attacks. Other specifications, such as the Open Redirector, could be folded into such a new specification. Derek and I would appreciate your input on this topic before we make a decision since it has significant impact on our work. Ciao Hannes & Derek --WXvqak44Cv2eDCAeCVvUs2estah3hl59J 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 iQEcBAEBCgAGBQJXBUjWAAoJEGhJURNOOiAtYBAH/j6FxCHsbHtuPAzEbHCaxphI QISaIE1EOdUMDAqslu7z0jYhSDT0mg3FDLW6xdvxiRFiZCIS83fTVI8NFVRjHNRZ yDZIlGV4g/PTviAPpyopDwkgARJEj/Jq067kH8CHGgojf21yet0VFEeWjL07uY3O 7kxCPKyup4Qcpvp1ZxTeIbhrh184OSZomJWKfbaWwpGcrqPZcgsy6c1y0cZ5VRvz rUE6mVDRWI3B5J37e/1p1IGe6+fmNW7KErXuvAvSsKFmZ+zPOuUsDxwrj5OcUjQJ G3XLlnxl+KGLJFjirgdED6ZbVxEhUONP4et7LqRxECuEyKxtiwW1n6KnegIgfJ4= =ju/g -----END PGP SIGNATURE----- --WXvqak44Cv2eDCAeCVvUs2estah3hl59J-- From nobody Wed Apr 6 10:44:02 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640C812D164 for ; Wed, 6 Apr 2016 10:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6NDbW3j_Py6 for ; Wed, 6 Apr 2016 10:43:56 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA6E712D5CC for ; Wed, 6 Apr 2016 10:43:53 -0700 (PDT) Received: from [192.168.10.140] ([31.133.155.135]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LeMWL-1bbGjz3akX-00q9bz for ; Wed, 06 Apr 2016 19:43:51 +0200 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <57054ADF.3010109@gmx.net> Date: Wed, 6 Apr 2016 19:43:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FVQMpkiQpf91C2UQh2qBfubQSfdfXJ7XP" X-Provags-ID: V03:K0:Juqc9V5YukG4MFXFiwX88OAPplY8ANK8AN5YFd3taBVXIfRoS0Y nciu5AcbKtpHye5iXx+vVFMyyJjTKlZxKZt0NSqb9MejyZxylL+N5dKKRkemUET35rejMVh 6t5iDC/t0yzBnvmR9l53nTlfrVPRQGnZf/vaNI6g+4PnNCUESOrTRr7RAXwpD8MD6pzluDu qjG+WyZOlS3xIt/lUavHQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:GhdwZDVNn/A=:58zHPLNax/59FdqJagxJN5 0jTk2F8vgAQj0akhQKxU2OzFMx0bU2gq6txWnioYLc9l2WsuQhak/JRpz9VOEbOj+9WiF2uO5 ujgBiVuTPy+iziFPszHzNtCTCEpEeUiOo9rnAla2kf80dU1VWC3stEWQI5Hoy8VvZ0PzNG8+b PNMVVhWCRqfTuBfujeulKJ9V3iyc5QgU2IfVE3DoUKmBn/qPs7Bq6IvXcK9+t+LLDCZDAl66V f/MDT61wNmNN70xjOE1CRKxNDN6es87SLLUbw1qtrodxfNcCOBoL+/+PXqnnYSwSkUNFxPuw4 hKG8t5tKcEuoAlZPnuCeXJNYbOigtX8IH2gAM+40Y/z6zt1qYow7undsFVkGVHLjT++3hv0iR WLQzLoG6WPTqGwpjVIB3hOqaFTvslAAyMa2SzRIZqL0F8x0rJ/xF2FgMGp9Zi1xBUtARpPWh9 qqbCS7QtPFXcH34SNvQMh1z1LemiMo6jArP3/2pyZYshhSl2schUdz7pQVVcoNAo2Bng9ChC6 fnUe3p9mWuNCbD4mvQPFUbMuPSHCKjHetsMUtgi9tfa4s7szEZI1N4r6FKwwDAa/0RDAIBP44 1UzwOPx0+VDgwPlfXNaWu8WUHTVUL76ovVHMnDd9itxx1wdh9hF8Osui8FvQZsr3LoUdaFprX HOvm/QVqB2QnKhRaI75zoN18E5Fe/AvzS0yp0OECdG4oyT22vxBG+hZ3eIsoWZ3zfLPz4JSXE LsTi8GR7FDK/2z/GVvkkdde+ue4VU+e2op0fWmI+5KJ+LkiQAoGug6ZA0oQ= Archived-At: Subject: [OAUTH-WG] Meeting Minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 17:43:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FVQMpkiQpf91C2UQh2qBfubQSfdfXJ7XP Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Leif was so nice to take meeting notes during the OAuth meeting today and they have been uploaded to: https://www.ietf.org/proceedings/95/minutes/minutes-95-oauth Please take a look at them and let me know if they are incorrect or need to be extended. Ciao Hannes --FVQMpkiQpf91C2UQh2qBfubQSfdfXJ7XP 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 iQEcBAEBCgAGBQJXBUrgAAoJEGhJURNOOiAtIwwIAIoGBpbTRbsfvUOR5Np8vh2z QAaDqJr1MrXsPnGJnL8oR2vu9H141xnRpKbqdPnoRGNb7KY8tFpSlJlqzYsPzO7d /EMiaTPCWqLeVO1a5SPhInceApsGXjLlZwe1TsUIi7ZSl1+XFuD3YJ4PN9J+cPVs sTCajqCaztCBg/tp++ufqtx5JOXO4dfVzVLFa2T0Ri+aqv+JKAKU74W6N8mtdeq2 eGXj8c8U9hpJBWaviOElPUzKtv9V7GvQzryG5Rvuwjh4Rhi6ojJ++TocnBPU9WeJ pRZQ/PSlFBtXhMy78bEPsVdoS25CHZIbMdEAe/A8BaUBxK/MiTq7Td8oUIB5a20= =LaTt -----END PGP SIGNATURE----- --FVQMpkiQpf91C2UQh2qBfubQSfdfXJ7XP-- From nobody Wed Apr 6 10:47:40 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBBBF12D6DC for ; Wed, 6 Apr 2016 10:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxuWpqHp5_PG for ; Wed, 6 Apr 2016 10:47:37 -0700 (PDT) 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 2A52712D6E8 for ; Wed, 6 Apr 2016 10:47:36 -0700 (PDT) Received: from [192.168.10.140] ([31.133.155.135]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LeiJ8-1bc5jH1SYQ-00qQUI for ; Wed, 06 Apr 2016 19:47:34 +0200 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <57054BBE.7000506@gmx.net> Date: Wed, 6 Apr 2016 19:47:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qbe4iTh5SSdAvqDV1sFBwhRAc5biim9Xb" X-Provags-ID: V03:K0:bY9P96ryJ/mmULjlIe4QqBAKRbnjRA/t7WyjoYAbz8YW25J/6Tk TuHppm585mkH1cvra4TXF/IQfe17sBJs/wt1VYSvCLxfRV4sjGE9O+XMqjJvYRuZnvUWqs/ 7KxoL0GSiYMATzdJcB5L4LHVN5KNWNOWNH0XQkuES3GkUqqETH5grawT2JBTZP0MbzheMcu oRSfplUum33LAq6eSMZNQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:XKJd4Nm7UVQ=:uDt49AJEX2AQTJ/VwEaX0o THYeOmQDK/Y86QRF1k3fdHCWJwH9/J3xu6CvSqGA4xwYLZnnFBJwf7HQQzdh+kYUCOX4jEjYu w6nGIuh5Apa8vTmiIU3Dzi3JyGUh3Wq4ZDpNzsDAqYuD6a6q4WlvI+3WT+IEwRCshbK9XCfYn 56+MYWz8+Jq7Ttd8n3Aaj1xeyRBxRatavkPYH5is9UVAGUX3w+X8o6FU7mdI1/KjNkAPk31i9 yDHtmirbaZST9/Hol33Pl8xsA5/obQcjoRhtRKm+seI1oRuL01iXkg5I8ASLiR3CoaeSxnpwJ DFzBluIGa9mDnDhxpNY6OWi5Q8QZio+voc56fEDXcVETxAVY+mau8AS8+HCU+eJeybwcRk2yc 9CrvAmqGRUBM9hG7OW+GkEgXWePNlRAx9EHau0dZHjECkyxYu6AgCfUV8U3ZYI3+mlZLuIXEM 1hDekweZFSMFq+r0MygdTFYgzlXT2z1XhhUTbg2tLLld3JkUycAOd+FBngquewgWc4/evXxHc W8gOFnWXl2MVbjjhSqYkCjNbvhQC0iZo04n/KtJz77sX+opXFama0Trn66tNWTuxQDo/5qDeS juxwUcux+6dC7cEfCoXE+bvfn45x3PidNTWcma12GVJEjYH13lcuOkY7sZeUEXEItBknnY12B RIRLAEi9p7yKoeNW/hnyegOxvQtNdVPLD9Hc0tjdkjZ8nUwTdv+DRuJW6b4NQLXTloChZr3pF eKPGP7BUwHH740jJBVcXuzQ/6RRX1bLrxZ3yl4uO5KhvTjRNkrtZbIYNRfI= Archived-At: Subject: [OAUTH-WG] Informal Discussion about Discovery Today at 16:20 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 17:47:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qbe4iTh5SSdAvqDV1sFBwhRAc5biim9Xb Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, during the f2f meeting today the suggestion was made to have another informal discussion about OAuth discovery. We are going to meet at 16:20 today at the **IETF registration desk**. William is trying to find a meeting room for us. Please respond to me privately about this event, if you have feedback. Ciao Hannes --qbe4iTh5SSdAvqDV1sFBwhRAc5biim9Xb 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 iQEcBAEBCgAGBQJXBUu+AAoJEGhJURNOOiAtXMQIAJ9FFlvlJtHoiji+n7O6nbF8 K2li1hZt1C0d4/UzfMwS2EpdT5FyHT2QdfKkw/DzYBUi1He5IjztSGaInrLgQqYE g0rt9inUNZ6mL3Awq2FLPUVEmA2amAsYLq7TsekRo/FqyDR5CfFn+leg3dSuF0eB pxfG3jahuuI68C5b2fLWaU9zgaCx+o6SY0BbcUMctH/f+d5r61KIS1npr99w3wd6 wwLzfpc4AWPZaksZvefL7k3tQrWZ3tpru/yVQo+tqQAols6rg/3qnPEb5I8NRp/E guECMtv64XjHKA5ydcEXFbDJQG7+74FCYj557HV038x03d5UwzpvuMLw9VLiAN0= =a0lE -----END PGP SIGNATURE----- --qbe4iTh5SSdAvqDV1sFBwhRAc5biim9Xb-- From nobody Wed Apr 6 10:49:36 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F12512D1DF for ; Wed, 6 Apr 2016 10:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8zBlwtfvJ21 for ; Wed, 6 Apr 2016 10:49:33 -0700 (PDT) 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 B9DAF12D6EA for ; Wed, 6 Apr 2016 10:49:33 -0700 (PDT) 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=XkdVkfiHBpn6oW1vUE4usD72ryUBbqK9Nzaf3b9FZYs=; b=X5blG/veIUOwBtvN1HJ1sZyEQm9p4eM7lfm/f5tEzRODZCYzHqgBewUM81dCkdrplfUTA0idhkX9K2dQl90m4uu1LDbt/lNH5sxHBq4Ob8TixghZxiROY/HPLGE5fW0vsLq+HXrZwR/6fnwZtb0j3r1Fs3E8O6dk++pZo4txlzI= 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.447.15; Wed, 6 Apr 2016 17:49:33 +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.0447.028; Wed, 6 Apr 2016 17:49:33 +0000 From: Anthony Nadalin To: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Informal Discussion about Discovery Today at 16:20 Thread-Index: AQHRkCxtKj6w8+zrQE6NN88+qYxqt599OOdg Date: Wed, 6 Apr 2016 17:49:32 +0000 Message-ID: References: <57054BBE.7000506@gmx.net> In-Reply-To: <57054BBE.7000506@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmx.net; dkim=none (message not signed) header.d=none;gmx.net; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [31.133.140.226] x-ms-office365-filtering-correlation-id: 80e03338-1956-4d97-9681-08d35e43cfc1 x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1234; 5:i31zoEMNGtkuLiH5wv7wbIk34FYtfMUadD30Aj9ytN5VNeZ/qHXwTnTfn2Gq22rHHv89OISXvTiGKJYG4x7uLoiZ5rIe3/1WAiMm4WEsEdll601cEva5uARsNTtp6vP933sx3i1mqqWby6+nmeb4Pg==; 24:7SV5DuZvxHyLWtRzNJpZaeUO1rR6UlPYA/Q/LmEzvEABltQGf4UqkkSUEMNck2/98WUqOmikABU8bwffeR1KfACklnY5f1yNjPXBUFYll84= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1234; 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)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BN3PR0301MB1234; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1234; x-forefront-prvs: 0904004ECB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(53754006)(66066001)(5004730100002)(86612001)(106116001)(107886002)(189998001)(5003600100002)(10400500002)(5005710100001)(10290500002)(76576001)(5008740100001)(10090500001)(3846002)(102836003)(6116002)(586003)(2900100001)(1220700001)(99286002)(1096002)(87936001)(2950100001)(11100500001)(81166005)(5001770100001)(77096005)(5002640100001)(92566002)(74316001)(3660700001)(76176999)(50986999)(54356999)(19580395003)(86362001)(3280700002)(33656002)(122556002)(19580405001)(2501003)(2906002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1234; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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: 06 Apr 2016 17:49:32.8887 (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] Informal Discussion about Discovery Today at 16:20 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 17:49:35 -0000 V2Fzbid0IHRoaXMgdGhlIHRhc2sgb2YgdGhlIGRlc2lnbiB0ZWFtID8NCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEhhbm5lcyBUc2Nob2ZlbmlnDQpTZW50OiBXZWRuZXNkYXksIEFwcmls IDYsIDIwMTYgMTA6NDggQU0NClRvOiBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogW09BVVRILVdH XSBJbmZvcm1hbCBEaXNjdXNzaW9uIGFib3V0IERpc2NvdmVyeSBUb2RheSBhdCAxNjoyMA0KDQpI aSBhbGwsDQoNCmR1cmluZyB0aGUgZjJmIG1lZXRpbmcgdG9kYXkgdGhlIHN1Z2dlc3Rpb24gd2Fz IG1hZGUgdG8gaGF2ZSBhbm90aGVyIGluZm9ybWFsIGRpc2N1c3Npb24gYWJvdXQgT0F1dGggZGlz Y292ZXJ5Lg0KDQpXZSBhcmUgZ29pbmcgdG8gbWVldCBhdCAxNjoyMCB0b2RheSBhdCB0aGUgKipJ RVRGIHJlZ2lzdHJhdGlvbiBkZXNrKiouDQpXaWxsaWFtIGlzIHRyeWluZyB0byBmaW5kIGEgbWVl dGluZyByb29tIGZvciB1cy4NCg0KUGxlYXNlIHJlc3BvbmQgdG8gbWUgcHJpdmF0ZWx5IGFib3V0 IHRoaXMgZXZlbnQsIGlmIHlvdSBoYXZlIGZlZWRiYWNrLg0KDQpDaWFvDQpIYW5uZXMNCg0K From nobody Wed Apr 6 10:53:30 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B2912D692 for ; Wed, 6 Apr 2016 10:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgxLibGMzhbv for ; Wed, 6 Apr 2016 10:53:27 -0700 (PDT) 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 8787012D1BF for ; Wed, 6 Apr 2016 10:53:26 -0700 (PDT) Received: from [192.168.10.140] ([31.133.155.135]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MTvUT-1bDx7B3kJd-00Qnhe; Wed, 06 Apr 2016 19:53:21 +0200 To: Anthony Nadalin , "oauth@ietf.org" References: <57054BBE.7000506@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <57054D19.6050107@gmx.net> Date: Wed, 6 Apr 2016 19:53:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ae45U21onxH6aRVCokfAbinLskt4l9woA" X-Provags-ID: V03:K0:UTlorCMxRExjBDOStMNsNPtO+56iCdUX+HAtUOB+D8/DOgNMsrR OqfIyNIFwpeyHVlLW7/u8MBdymlHArkjfBJnBDYpT4hUOlXI4kTwoASUKMdJ7S50GUqJOJ2 Bx3ef/4WTyqk9oe0q1oDDwSa8qVU9yOK9N/Fktl0hf5vcuChtDky6XbyrnOxHPxtlks1S+/ OAQ+qnoRX8FA1sOmgPHrw== X-UI-Out-Filterresults: notjunk:1;V01:K0:FMQTm/Ij0ok=:sxt4QZOEdvHd6tTV6OcI+M e0A1OZf4snDk0QycbN/09PhSYirxTZUbJA3RzH1Nf9+zfjt1ALSCXLkVBzrQswexwDlj52jhj MU1BsAk3l0FO3mb+6oP2lnnix633A0UD7sFfGgmrn3YhUsm4z7puHiJy6OtANB8OmupUHRhX0 eGXgvlDfptehlSgS+mekDbyifb+/wttJ/OtTUcPaySZ7KFWesOLJylN3xDJ6jnLvQx46domFl sXIFRJybDPghRsNvXFqPnfsL2nUGc/seYbacrIv13mww4dTecuHTqJ1S5E6FMCWMkvR3RthBG /GXKrR7EualeraMM7V9UgLBAGqzekY1PU/pAg2d3s0dDPnvyVV/MLmaJRk7Ne4seK/JNACe2A vjjNjyRWmT09dQX5oHggufjhewAFK0QR6cZRTLc9UvGUOWWYaKNDWXqF0/IcDEXJy4de+qoz3 pmQcrI6w3S4T+xiYjXOtaHADyR4rr+KMsaG5NikzyRdLsLTV08jhfl3Z/xNbmLWcEKSmyffyx Um2CAz59uY7HS9nzHE6yN9Yg11v1R3J47Cuo2qdgYDFRrVVddFziefgZi2Jw0EoLVn4P/G52z fCg9ZomAl2mK2r5018DZ3NAC8TdyBx5Q/YzkFr3RvAipHCzlUgdY1hs8HfK2BgJmr6JhwQdKM isdSW3RQUOsTMrJzX9GKoLrZXS/NkV4+onvCJOZlGHX1Jhtif7Br2fZqPHZhv/kw0jWnMOpCp d9kCMlum3Q6p9WhzWmriR57VjLw+dVwbpgvGZfZ6JJ+LwC+jAZ6Mtrw/Xic= Archived-At: Subject: Re: [OAUTH-WG] Informal Discussion about Discovery Today at 16:20 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 17:53:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ae45U21onxH6aRVCokfAbinLskt4l9woA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Tony, we use face-to-face time efficiently to get things moving forward faster.= I am sure the design team will still have enough issues to solve. Ciao Hannes On 04/06/2016 07:49 PM, Anthony Nadalin wrote: > Wasn't this the task of the design team ? >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofe= nig > Sent: Wednesday, April 6, 2016 10:48 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Informal Discussion about Discovery Today at 16:20 >=20 > Hi all, >=20 > during the f2f meeting today the suggestion was made to have another in= formal discussion about OAuth discovery. >=20 > We are going to meet at 16:20 today at the **IETF registration desk**. > William is trying to find a meeting room for us. >=20 > Please respond to me privately about this event, if you have feedback. >=20 > Ciao > Hannes >=20 --ae45U21onxH6aRVCokfAbinLskt4l9woA 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 iQEcBAEBCgAGBQJXBU0ZAAoJEGhJURNOOiAtEn4H/jbt9rv1F+6X4Uxxu90H+fBQ /0Gz+BA0BH7wXQs+yoWCegM15glq6c2ctuIBYgUDfhFgU3kS3atAzBOs0Hn0YHlR QJ8Q37vq6ACcDi/iJSPgnJ0ClWp8NdC3ltzJe9d3uknm4HDUtmRjEMkzF7RDBD5y szOhraVrEuiqcYGIfLnammbMxnuWkWCDZU3aaQUTME7LzqnXL3Sqj7AIIN01nmR7 VgFmEBUyDis3rybqTbF7ba0T2xg0wVmToxaf2JqWhQicA0rL/yld6f2bPamBT8IX ywnRH8TKxFCMMNX/kfetP9CD3cE0Wa+bdoe2sJ/k59Q9cQ0T8DPc0vYOqX8FMbI= =xmAF -----END PGP SIGNATURE----- --ae45U21onxH6aRVCokfAbinLskt4l9woA-- From nobody Wed Apr 6 11:07:08 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D19E12D0E1 for ; Wed, 6 Apr 2016 11:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHgg6ZH6dNj4 for ; Wed, 6 Apr 2016 11:07:05 -0700 (PDT) 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 4DA2712D0E7 for ; Wed, 6 Apr 2016 11:07:05 -0700 (PDT) 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 u36I70h5025739 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 6 Apr 2016 18:07:00 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 u36I6x43013861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Apr 2016 18:07:00 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u36I6xVL012568; Wed, 6 Apr 2016 18:06:59 GMT Received: from [31.133.137.184] (/31.133.137.184) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 06 Apr 2016 11:06:59 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13E238) In-Reply-To: <570548D6.8010605@gmx.net> Date: Wed, 6 Apr 2016 15:06:30 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <570548D6.8010605@gmx.net> To: Hannes Tschofenig X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 18:07:07 -0000 =20 Existing implementations are for the large part ok and do not need these mit= igations.=20 Only the new use cases we have been discussing (configure on the fly and mul= ti-as, etc) really need mitigation.=20 The updated by approach seems like a good way to address the new cases.=20 Phil > On Apr 6, 2016, at 14:35, Hannes Tschofenig wr= ote: >=20 > Hi all, >=20 > today we discussed the OAuth Authorization Server Mixup draft. We were > wondering what types of threats the document should find solutions for. >=20 > We discussed various document handling approaches including > * OAuth Mix-Up and Cut-and-Paste attacks documented in separate > solution documents > * combined solution document covering the OAuth Mix-Up and the > Cut-and-Paste attacks. >=20 > Barry pointed out that these documents could update the OAuth base > specification. >=20 > As a more radical change it was also suggested to revise RFC 6749 "OAuth > 2.0 Authorization Framework" and RFC 6819 "OAuth 2.0 Threat Model and > Security Considerations". >=20 > Opening up the OAuth base specification obviously raises various other > questions about cleaning up parts that go far beyond the AS mix-up and > the cut-and-paste attacks. Other specifications, such as the Open > Redirector, could be folded into such a new specification. >=20 > Derek and I would appreciate your input on this topic before we make a > decision since it has significant impact on our work. >=20 > Ciao > Hannes & Derek >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Apr 6 11:07:36 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE89412D1BF for ; Wed, 6 Apr 2016 11:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYOzxFFB8eSQ for ; Wed, 6 Apr 2016 11:07:33 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6963612D0E7 for ; Wed, 6 Apr 2016 11:07:33 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u36I7Ub0001765 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Apr 2016 18:07:31 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u36I7Uvg031918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Apr 2016 18:07:30 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u36I7TOG017224; Wed, 6 Apr 2016 18:07:30 GMT Received: from [31.133.137.184] (/31.133.137.184) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 06 Apr 2016 11:07:29 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13E238) In-Reply-To: <570546A1.8040509@gmx.net> Date: Wed, 6 Apr 2016 15:07:25 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <570546A1.8040509@gmx.net> To: Hannes Tschofenig X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 18:07:34 -0000 I would like to have more discussion before wg adoption.=20 I support the work and am willing to help.=20 Phil > On Apr 6, 2016, at 14:25, Hannes Tschofenig wr= ote: >=20 > Hi all, >=20 > this is the call for adoption of 'Resource Indicators for OAuth 2.0', see > http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/ >=20 > Please let us know by April 20th 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 Buenos > Aires then you don't need to re-state your opinion, if you want. >=20 > The feedback at the BA IETF meeting was the following: ~10 persons > for accepting the document and 0 persons against. >=20 > Ciao > Hannes & Derek >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Apr 6 12:02:47 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F392412D1F0 for ; Wed, 6 Apr 2016 12:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGRB1ckMAu3H for ; Wed, 6 Apr 2016 12:02:44 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 543CB12D18B for ; Wed, 6 Apr 2016 12:02:04 -0700 (PDT) Received: from [192.168.10.140] ([31.133.155.135]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LguAU-1bZshv2GZC-00oDuS; Wed, 06 Apr 2016 21:01:58 +0200 To: "Phil Hunt (IDM)" References: <570546A1.8040509@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <57055D2D.9000600@gmx.net> Date: Wed, 6 Apr 2016 21:02:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DlBODuNsgFUOhiHHp1h58UT3BN3L6fcDk" X-Provags-ID: V03:K0:76ZlVkF26zWSFCv+ItrdQEn71J40TnjNzbOZSGgyH7Mw50dcZff kx51uQmXVezkCbbMdkFxZ2Iy/Ts5f/+yFP9QzeEMx52kfZPArT8ju3GPBHNO43hEEcA7uyn 20Nir6amOTPZSs+InTpf66h0Ycwu7tkux43a99KEWfKbk6QcCQYhBMo87ICzIi/NeYx7bIz CySkVmLmBmH+ZYEwr6ntw== X-UI-Out-Filterresults: notjunk:1;V01:K0:JQ5euXJ9Hv8=:DFZcYCoBq094QDBVMTZlEV tmuK1z2FbqsM74zpiAxz3EC5XJ7lI9Co9cuSBNR7nUJE+8dGLCyuAXC+g8niUWdPQu4s7AdHu l5TeXKSycrxudYnot7156nJ1mdkI+MmqXWCfMIyOockFtY03gl4HJUc1NQruzvZyG9ornal9b JDzF+pYBi3yv5Tu802Z7F7jV/OJueiFVq+BJO2uKvbb9r+SSMTOJamdjr52fq5iK2e8HLTB8o +adYUntrVVr3ovPRF6X0JLQqTBwv1+PdqvfwoVamOuq3960Xf9Aj9rLtHdTLZuErOJaJSJazX oXaSoohmtKlqW7PWsZXd9trvkzIaY5/0TiQFfL68xuo4mWSANa6K99ccuhjAkwNAIuq5ahkwW oThwf1s2oAIxB5WZ2uUSMWIMw+Xika+Aq7tS/tYW5vUlIcQZdGQbh3e71PoyII5j7dWB+wwAD 2+o6cXaA/VyniRqF2iKwA6N/Nhkv/1S/r9Ndv6KTol1tYGoy5ii/8OmfftBixzgtrJdNJIb+v a4cNZRvHReQ5mtW059GknodvVS5ffXSVCu/MG8QMzWaBe408XJeGVjEghkNBl3z6xxs7qsWa2 I5+TMoNw01D5Dh4Y36Qx/I8toWJM/+A7e5V8+B3Pn+RgY3kJ2zeQaIwaRHEQ/y3yjuAlBtHlF zPAR6uKJ9hRGyuI7S7YWMAvHIxAd4Jubtdbq+ZnY2dHmOk2xEhyE0lt2IyOJR1QwhNlpDGjir GdJucLXNMReaUGkGcOxQQxcu4GTgkSVMzrfpo6ipnN76zkwRv0HrXTI/sLM= Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 19:02:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DlBODuNsgFUOhiHHp1h58UT3BN3L6fcDk Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Phil, we have discussed this concept already for years. In fact, it dates back to the days of the OAuth base specification and the security consideration section even talks about it. We have had the content of this in the PoP key distribution draft and we are now moving it into a separate document. I am not sure how much longer you want to discuss it. Ciao Hannes On 04/06/2016 08:07 PM, Phil Hunt (IDM) wrote: > I would like to have more discussion before wg adoption.=20 >=20 > I support the work and am willing to help.=20 >=20 > Phil >=20 >> On Apr 6, 2016, at 14:25, Hannes Tschofenig wrote: >> >> Hi all, >> >> this is the call for adoption of 'Resource Indicators for OAuth 2.0', = see >> http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicato= rs/ >> >> Please let us know by April 20th 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 Buenos= >> Aires then you don't need to re-state your opinion, if you want. >> >> The feedback at the BA IETF meeting was the following: ~10 persons >> for accepting the document and 0 persons against. >> >> Ciao >> Hannes & Derek >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --DlBODuNsgFUOhiHHp1h58UT3BN3L6fcDk 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 iQEcBAEBCgAGBQJXBV0uAAoJEGhJURNOOiAt4x8IAJJ5ZJBZv8QA06UmIrJcQvkk +/SUN18sZWglZ0uQza81PiaQudQBIuknoc1idD/IVKJeCBQpAZwlTHOF5BoSUvDz IMTVLHMjkXjJ3onZy/UVW19DpFCYPl+lydUmU9Z0bT1oKhht8IrsWWZLtv8m3f0W ecJFssaC+TotMX8n0wyg+UaAhnvY5ilSahcrIG0fiPf/vphzeHaB+5EqxX4X66mG 2P8yXYiYie+QoFaCkUa29ba406/k7eC7trTyAan6W0s/RQLKJYlclaA3dp5Favj1 Oi2G8fV/pqmcAiX4Ds2txlODrpxhI1AqOT3OJ81SVd33C+7PD2hpb7auPVwJhYc= =kZzU -----END PGP SIGNATURE----- --DlBODuNsgFUOhiHHp1h58UT3BN3L6fcDk-- From nobody Wed Apr 6 12:05:11 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3987612D739 for ; Wed, 6 Apr 2016 12:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mx.aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnNFZQJtfYLr for ; Wed, 6 Apr 2016 12:05:08 -0700 (PDT) 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 6D6B212D702 for ; Wed, 6 Apr 2016 12:05:08 -0700 (PDT) Received: from mtaout-aae01.mx.aol.com (mtaout-aae01.mx.aol.com [172.27.1.97]) by omr-m014e.mx.aol.com (Outbound Mail Relay) with ESMTP id A371A380008E; Wed, 6 Apr 2016 15:05:07 -0400 (EDT) Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aae01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 9AB8238000088; Wed, 6 Apr 2016 15:05:06 -0400 (EDT) To: Hannes Tschofenig References: <570548D6.8010605@gmx.net> From: George Fletcher Organization: AOL LLC Message-ID: <57055DE2.50201@aol.com> Date: Wed, 6 Apr 2016 15:05:06 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1459969507; bh=G/UfCCIzUQgRpJ+m0jyY2cf38z3eCq/EKnoPxQwNtuA=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=miKbledetG7z0n7a3WoWY0dYpZXWyKgr9kgAW355UNLuHEg9bUrje8zLI5Sj3UqLD PasjCcyN2+U4accDsNCc2769LsC1S/jMpi9peYvjHc75IMfxXgZRHfVWl26gKhLVI7 6Oo64aX0bPbJRlyqi4hhls+18w9KVbYo+S/X8o5Y= x-aol-sid: 3039ac1b016157055de2733f X-AOL-IP: 10.172.102.179 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 19:05:10 -0000 I'd definitely prefer a single solution document to many little ones that have to be combined to actually build a secure solution. It's already getting complex with the additional specs that have been added. Additionally, I'm not against working on OAuth 2.1. Thanks, George On 4/6/16 2:06 PM, Phil Hunt (IDM) wrote: > > > Existing implementations are for the large part ok and do not need these mitigations. > > Only the new use cases we have been discussing (configure on the fly and multi-as, etc) really need mitigation. > > The updated by approach seems like a good way to address the new cases. > > Phil > >> On Apr 6, 2016, at 14:35, Hannes Tschofenig wrote: >> >> Hi all, >> >> today we discussed the OAuth Authorization Server Mixup draft. We were >> wondering what types of threats the document should find solutions for. >> >> We discussed various document handling approaches including >> * OAuth Mix-Up and Cut-and-Paste attacks documented in separate >> solution documents >> * combined solution document covering the OAuth Mix-Up and the >> Cut-and-Paste attacks. >> >> Barry pointed out that these documents could update the OAuth base >> specification. >> >> As a more radical change it was also suggested to revise RFC 6749 "OAuth >> 2.0 Authorization Framework" and RFC 6819 "OAuth 2.0 Threat Model and >> Security Considerations". >> >> Opening up the OAuth base specification obviously raises various other >> questions about cleaning up parts that go far beyond the AS mix-up and >> the cut-and-paste attacks. Other specifications, such as the Open >> Redirector, could be folded into such a new specification. >> >> Derek and I would appreciate your input on this topic before we make a >> decision since it has significant impact on our work. >> >> 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 > From nobody Wed Apr 6 12:06:44 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED1112D7A2 for ; Wed, 6 Apr 2016 12:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQwX5-u9uIAa for ; Wed, 6 Apr 2016 12:06:41 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A177412D753 for ; Wed, 6 Apr 2016 12:06:41 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u36J6dUp016360 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Apr 2016 19:06:40 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u36J6cIU004503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Apr 2016 19:06:39 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u36J6cKa017889; Wed, 6 Apr 2016 19:06:38 GMT Received: from [31.133.137.184] (/31.133.137.184) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 06 Apr 2016 12:06:38 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13E238) In-Reply-To: <57055D2D.9000600@gmx.net> Date: Wed, 6 Apr 2016 16:06:31 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5AD9C0D6-C3BA-421D-99F6-B98FA509ADC6@oracle.com> References: <570546A1.8040509@gmx.net> <57055D2D.9000600@gmx.net> To: Hannes Tschofenig X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 19:06:43 -0000 With the process of immediate wglc I think we should review all documents mo= re thoroughly before adoption.=20 As I said I support the work.=20 Phil > On Apr 6, 2016, at 16:02, Hannes Tschofenig wr= ote: >=20 > Phil, >=20 > we have discussed this concept already for years. In fact, it dates back > to the days of the OAuth base specification and the security > consideration section even talks about it. >=20 > We have had the content of this in the PoP key distribution draft and we > are now moving it into a separate document. >=20 > I am not sure how much longer you want to discuss it. >=20 > Ciao > Hannes >=20 >=20 >> On 04/06/2016 08:07 PM, Phil Hunt (IDM) wrote: >> I would like to have more discussion before wg adoption.=20 >>=20 >> I support the work and am willing to help.=20 >>=20 >> Phil >>=20 >>> On Apr 6, 2016, at 14:25, Hannes Tschofenig w= rote: >>>=20 >>> Hi all, >>>=20 >>> this is the call for adoption of 'Resource Indicators for OAuth 2.0', se= e >>> http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators= / >>>=20 >>> Please let us know by April 20th 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 Buenos >>> Aires then you don't need to re-state your opinion, if you want. >>>=20 >>> The feedback at the BA IETF meeting was the following: ~10 persons >>> for accepting the document and 0 persons against. >>>=20 >>> Ciao >>> Hannes & Derek >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 From nobody Wed Apr 6 12:41:39 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6327012D791 for ; Wed, 6 Apr 2016 12:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zozPuu-BDLNW for ; Wed, 6 Apr 2016 12:41:35 -0700 (PDT) Received: from mail-oi0-x264.google.com (mail-oi0-x264.google.com [IPv6:2607:f8b0:4003:c06::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 57C7212D769 for ; Wed, 6 Apr 2016 12:41:35 -0700 (PDT) Received: by mail-oi0-x264.google.com with SMTP id c134so3531847oig.0 for ; Wed, 06 Apr 2016 12:41:35 -0700 (PDT) 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-transfer-encoding:mime-version; bh=iTEEEk3cGxDjjlEXs8ohtBRRUc4/T8WYAoTx63BdX3g=; b=QIT3PGxnMacBd00AgrJh/Q0Di+wbMK8ZjdB7YJvYv1w9gtFcV8Cw30siYi7th7xNRS KyL2Aa2nJ4E9CZ28ypsB456oHFhmWgz2khCX+smzZ1x+qWCNYOJ6Hvw/P8TwBt6Kx20j cyPpQ6bboh3BYgwF8ozqdw7TjhUbY2EtjdwvZPLluV9a4B9Q+aSsTTnJQf5dnc41xySz JlrhKv9CWFaPNrofNAPjhqSX0lsHlms4bq3EkkOFrm62jT6PvB3sd3XL1A/M/pOqy7pL nAa5u2w68u/kv+PTTYjmVeg0akmt++YOfguwXi+JQ5R/f8lEjGhKDBZXdHRVqbdlWGDp ueeQ== 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-transfer-encoding:mime-version; bh=iTEEEk3cGxDjjlEXs8ohtBRRUc4/T8WYAoTx63BdX3g=; b=fHXFDwGiJOx88IQqnzkAGlhNWuUJF/im1dnsRVC2SXKkGfRdA7NN2lWuEB4qnDadnT WVQdST5Bqx7qWMXS30MQieriji5uvCJnnMXT1o+XP+jjIs05n3ExkUFgFWFFVYmqg62Q SsHPmJHQWIwXJ4y3UduePcQfaNJh/HJHoi6lWCLxCqFIXtx0oS+2RoiHQf3tc+makN7N 1Oq39R/n00X2Vk3mtemIbgCWKD25ML8zE3MOAMzyg2xcIljr71OHxJLrBr8j046zbbyY grDcn5KcNAiTPEt2ayJaKM3S7XZbd+Je2vBWex7X9zpFS9Q8V4AUJuMaiHR4TgIjTByF hZaQ== X-Gm-Message-State: AD7BkJIvyO3kk4nd2puZLvCUK6T4x26p8crCzMubnZ8x6GPxUWwRbQdzjllFb4s/8o5Fz2vqObgSBEncGLjx2TaP8QKV4sOx X-Received: by 10.140.160.214 with SMTP id g205mr7833143qhg.88.1459971694693; Wed, 06 Apr 2016 12:41:34 -0700 (PDT) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id x77sm630695qka.5.2016.04.06.12.41.34 for (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 06 Apr 2016 12:41:34 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id u36JfYpe021445 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 6 Apr 2016 15:41:34 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 6 Apr 2016 15:41:33 -0400 From: "Hollenbeck, Scott" To: "'OAuth@ietf.org'" Thread-Topic: Cross-Area Review Request for RDAP Authentication Thread-Index: AdFMdFIjlomRE03AR0yFxWcnxij5bwGUrPpQD105X8A= Date: Wed, 6 Apr 2016 19:41:32 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4A3B5A7D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F4A129732@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F4A130B17@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4A130B17@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.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 19:41:37 -0000 Folks, this is the sequence of list messages that I mentioned at the end of= today's meeting. Nat did reply on January 20th with "It is on my todo list= but ...". I really could use affirmation or correction from clueful people= ... Scott > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hollenbeck, > Scott > Sent: Tuesday, January 19, 2016 9:40 AM > To: 'OAuth@ietf.org' > Subject: Re: [OAUTH-WG] Cross-Area Review Request for RDAP > Authentication >=20 > > -----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. >=20 > Can anyone help with this? >=20 > Scott >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Apr 6 12:52:34 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174FE12D7A0 for ; Wed, 6 Apr 2016 12:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdPNMAjjmErg for ; Wed, 6 Apr 2016 12:52:29 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3556B12D782 for ; Wed, 6 Apr 2016 12:52:29 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id 2so69231097ioy.1 for ; Wed, 06 Apr 2016 12:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IeMudqKOCpll56XRcVak3B53Q+740KEqnETR0MXRDjU=; b=o+AbLT5VR6dTcTqUPK4ER1mfeyGj9R1mmrAsaUnJ9v6JuYu3TmXmn7EF22kQy0w0u5 OdGZgp4FoirMb4KiuWriCtD5BaQokNKxXT1wacm9z5Rjlobi3IhIXHBHfVxvdVwvzIkh D6eCoxjyQ9aov8+TfkVGCCQ7+E3LiyCrnBz98= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IeMudqKOCpll56XRcVak3B53Q+740KEqnETR0MXRDjU=; b=IXEohkDDGpd+UpMWCa6N2hmwJvwQg3QvvBR/AtSz45X4gS7OZfLphKR0JRAQ5hiWLx DCxNquDH5/JOdIlc4Ie8tsFVCqc8Bl/R3I+CLcig1MuzUzoDFz3a/Gx4UlTIVsKa+mRl /YkLGT7H0IOYStoyVmk0Qns+N4Svk/z0VrDC7D7mSfRl+6x/gle0eYbpkforVZG38KJO BFRsZo283voxtHVyEkAcJotssLKZZZh+yGsojLnpQ/MkB1JTw+5HNKkHCX1VETJZPZMg FoHdaz2eIc95PROlMJMYa8FVWcEEqC8SIVnrjVPBIE2Bl6m37lm7SnzomMs9ipdyvToE 3cwg== X-Gm-Message-State: AD7BkJLXY6GsxSkBTJ6Av3LFmzk2GvSua3iGAfUznc0Mj86y1qJnxswmNZAljCSPdr3vmbVVBdAad+fMqix289Jx X-Received: by 10.107.13.133 with SMTP id 127mr28177715ion.129.1459972348477; Wed, 06 Apr 2016 12:52:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.74.162 with HTTP; Wed, 6 Apr 2016 12:51:59 -0700 (PDT) In-Reply-To: <5AD9C0D6-C3BA-421D-99F6-B98FA509ADC6@oracle.com> References: <570546A1.8040509@gmx.net> <57055D2D.9000600@gmx.net> <5AD9C0D6-C3BA-421D-99F6-B98FA509ADC6@oracle.com> From: Brian Campbell Date: Wed, 6 Apr 2016 16:51:59 -0300 Message-ID: To: "Phil Hunt (IDM)" Content-Type: multipart/alternative; boundary=001a113ffc70369596052fd64dfa Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 19:52:31 -0000 --001a113ffc70369596052fd64dfa Content-Type: text/plain; charset=UTF-8 I support the adoption of this draft by the working group. I don't think an immediate WGLC was expected here. On Wed, Apr 6, 2016 at 4:06 PM, Phil Hunt (IDM) wrote: > With the process of immediate wglc I think we should review all documents > more thoroughly before adoption. > > As I said I support the work. > > Phil > > > On Apr 6, 2016, at 16:02, Hannes Tschofenig > wrote: > > > > Phil, > > > > we have discussed this concept already for years. In fact, it dates back > > to the days of the OAuth base specification and the security > > consideration section even talks about it. > > > > We have had the content of this in the PoP key distribution draft and we > > are now moving it into a separate document. > > > > I am not sure how much longer you want to discuss it. > > > > Ciao > > Hannes > > > > > >> On 04/06/2016 08:07 PM, Phil Hunt (IDM) wrote: > >> I would like to have more discussion before wg adoption. > >> > >> I support the work and am willing to help. > >> > >> Phil > >> > >>> On Apr 6, 2016, at 14:25, Hannes Tschofenig > wrote: > >>> > >>> Hi all, > >>> > >>> this is the call for adoption of 'Resource Indicators for OAuth 2.0', > see > >>> > http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/ > >>> > >>> Please let us know by April 20th 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 Buenos > >>> Aires then you don't need to re-state your opinion, if you want. > >>> > >>> The feedback at the BA IETF meeting was the following: ~10 persons > >>> for accepting the document and 0 persons against. > >>> > >>> 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 > --001a113ffc70369596052fd64dfa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support the adoption of this draft by the working g= roup.

I don't think an immediate WGLC was expected here. =

On Wed,= Apr 6, 2016 at 4:06 PM, Phil Hunt (IDM) <phil.hunt@oracle.com><= /span> wrote:
With the process of immedia= te wglc I think we should review all documents more thoroughly before adopt= ion.

As I said I support the work.

Phil

> On Apr 6, 2016, at 16:02, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>
> Phil,
>
> we have discussed this concept already for years. In fact, it dates ba= ck
> to the days of the OAuth base specification and the security
> consideration section even talks about it.
>
> We have had the content of this in the PoP key distribution draft and = we
> are now moving it into a separate document.
>
> I am not sure how much longer you want to discuss it.
>
> Ciao
> Hannes
>
>
>> On 04/06/2016 08:07 PM, Phil Hunt (IDM) wrote:
>> I would like to have more discussion before wg adoption.
>>
>> I support the work and am willing to help.
>>
>> Phil
>>
>>> On Apr 6, 2016, at 14:25, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>>>
>>> Hi all,
>>>
>>> this is the call for adoption of 'Resource Indicators for = OAuth 2.0', see
>>> http://datatra= cker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
>>>
>>> Please let us know by April 20th whether you accept / object t= o 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 i= n Buenos
>>> Aires then you don't need to re-state your opinion, if you= want.
>>>
>>> The feedback at the BA IETF meeting was the following: ~10 per= sons
>>> for accepting the document and 0 persons against.
>>>
>>> Ciao
>>> Hannes & Derek
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth<= /a>
>

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

--001a113ffc70369596052fd64dfa-- From nobody Wed Apr 6 13:05:21 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC1D12D782 for ; Wed, 6 Apr 2016 13:05:20 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQKVo9lilwMV for ; Wed, 6 Apr 2016 13:05:15 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0738.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::738]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EED912D709 for ; Wed, 6 Apr 2016 13:05:15 -0700 (PDT) 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=X3WQVXI73UBQpxETsPkJv5G3h5eO0pdmvmhnwdmQPwA=; b=VD9Zy2U1p92EQ0ZMsUv/b5F467mi7vxdrOyGqdhoV08SZgKqzxm48kz+usPS+f8TnyVoh8wijRiwiXOTDtBLepRF0eWTDOF+4fyiac5zAk8ZB8PhFthgVvh3ouOsuIukM3FYdh4yUK2u0GDbu0tws3Nu81zxcbkQMFiVi5GoCh4= 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.447.15; Wed, 6 Apr 2016 20:04:54 +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.0447.028; Wed, 6 Apr 2016 20:04:54 +0000 From: Anthony Nadalin To: Brian Campbell , "Phil Hunt (IDM)" Thread-Topic: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0 Thread-Index: AQHRkCmB9ToVpiQsqkic7QI3EfNCup99PgWAgAAPRoCAAAE9gIAADLSAgAACpgA= Date: Wed, 6 Apr 2016 20:04:54 +0000 Message-ID: References: <570546A1.8040509@gmx.net> <57055D2D.9000600@gmx.net> <5AD9C0D6-C3BA-421D-99F6-B98FA509ADC6@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: pingidentity.com; dkim=none (message not signed) header.d=none;pingidentity.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [31.133.163.127] x-ms-office365-filtering-correlation-id: 84ba782d-3c44-423f-9dd8-08d35e56b879 x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1234; 5:BLylJAApbsc02LiBDChcodqP7/lNDsg0yeK2VxsbZ0owUvYq/zfCf9AXM6Wj9UHXge5/QShlQxFmdBriCGj27SbgYo8umXxuXH4eg5/B/h2HKMflCQkoN69ffCYzZ2PmBrCyfZnTqx3tacFfuyNmxQ==; 24:/7ntTpm1e1bQSbk0xevU7ofr3JKHWb0uqESA3u/WmpQFs9N1ry7v8A1S/HR0ZWCdpwdhXv8L6IN2SINLd9YGoIQA26dvAO/xtZM9nkFmbPk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1234; 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)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BN3PR0301MB1234; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1234; x-forefront-prvs: 0904004ECB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(53754006)(377454003)(99286002)(1220700001)(81166005)(11100500001)(5001770100001)(87936001)(2950100001)(1096002)(102836003)(3846002)(2900100001)(790700001)(586003)(6116002)(10090500001)(5008740100001)(19580395003)(33656002)(122556002)(19580405001)(2906002)(4326007)(86362001)(3280700002)(5002640100001)(92566002)(77096005)(50986999)(54356999)(3660700001)(74316001)(76176999)(86612001)(189998001)(15975445007)(5003600100002)(19609705001)(106116001)(19617315012)(5004730100002)(66066001)(8990500004)(93886004)(16236675004)(19625215002)(76576001)(19300405004)(10400500002)(5005710100001)(10290500002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1234; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB12340B653C16BDC50001A887A69F0BN3PR0301MB1234_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2016 20:04:54.2829 (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: Resource Indicators for OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 20:05:20 -0000 --_000_BN3PR0301MB12340B653C16BDC50001A887A69F0BN3PR0301MB1234_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3b3VsZCBsaWtlIHRvIHNlZSB0aGUgbXVsdGlwbGUgcmVzb3VyY2VzIHNlcnZlcnMsIGludGVy YWN0aW9uIHdpdGggVG9rZW4gRXhjaGFuZ2UgcmVzb2x2ZWQgYmVmb3JlIHRoaXMgaXMgYWRvcHRl ZCB0byBzZWUgaWYgdGhpcyB3aWxsIGFjdHVhbGx5IHNvbHZlIHRoZSBwcm9ibGVtcw0KDQpGcm9t OiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlh biBDYW1wYmVsbA0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCA2LCAyMDE2IDEyOjUyIFBNDQpUbzog UGhpbCBIdW50IChJRE0pIDxwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCkNjOiBvYXV0aEBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQ2FsbCBmb3IgQWRvcHRpb246IFJlc291cmNlIElu ZGljYXRvcnMgZm9yIE9BdXRoIDIuMA0KDQpJIHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHRoaXMg ZHJhZnQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAuDQpJIGRvbid0IHRoaW5rIGFuIGltbWVkaWF0ZSBX R0xDIHdhcyBleHBlY3RlZCBoZXJlLg0KDQpPbiBXZWQsIEFwciA2LCAyMDE2IGF0IDQ6MDYgUE0s IFBoaWwgSHVudCAoSURNKSA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBv cmFjbGUuY29tPj4gd3JvdGU6DQpXaXRoIHRoZSBwcm9jZXNzIG9mIGltbWVkaWF0ZSB3Z2xjIEkg dGhpbmsgd2Ugc2hvdWxkIHJldmlldyBhbGwgZG9jdW1lbnRzIG1vcmUgdGhvcm91Z2hseSBiZWZv cmUgYWRvcHRpb24uDQoNCkFzIEkgc2FpZCBJIHN1cHBvcnQgdGhlIHdvcmsuDQoNClBoaWwNCg0K PiBPbiBBcHIgNiwgMjAxNiwgYXQgMTY6MDIsIEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNj aG9mZW5pZ0BnbXgubmV0PG1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Pj4gd3JvdGU6 DQo+DQo+IFBoaWwsDQo+DQo+IHdlIGhhdmUgZGlzY3Vzc2VkIHRoaXMgY29uY2VwdCBhbHJlYWR5 IGZvciB5ZWFycy4gSW4gZmFjdCwgaXQgZGF0ZXMgYmFjaw0KPiB0byB0aGUgZGF5cyBvZiB0aGUg T0F1dGggYmFzZSBzcGVjaWZpY2F0aW9uIGFuZCB0aGUgc2VjdXJpdHkNCj4gY29uc2lkZXJhdGlv biBzZWN0aW9uIGV2ZW4gdGFsa3MgYWJvdXQgaXQuDQo+DQo+IFdlIGhhdmUgaGFkIHRoZSBjb250 ZW50IG9mIHRoaXMgaW4gdGhlIFBvUCBrZXkgZGlzdHJpYnV0aW9uIGRyYWZ0IGFuZCB3ZQ0KPiBh cmUgbm93IG1vdmluZyBpdCBpbnRvIGEgc2VwYXJhdGUgZG9jdW1lbnQuDQo+DQo+IEkgYW0gbm90 IHN1cmUgaG93IG11Y2ggbG9uZ2VyIHlvdSB3YW50IHRvIGRpc2N1c3MgaXQuDQo+DQo+IENpYW8N Cj4gSGFubmVzDQo+DQo+DQo+PiBPbiAwNC8wNi8yMDE2IDA4OjA3IFBNLCBQaGlsIEh1bnQgKElE TSkgd3JvdGU6DQo+PiBJIHdvdWxkIGxpa2UgdG8gaGF2ZSBtb3JlIGRpc2N1c3Npb24gYmVmb3Jl IHdnIGFkb3B0aW9uLg0KPj4NCj4+IEkgc3VwcG9ydCB0aGUgd29yayBhbmQgYW0gd2lsbGluZyB0 byBoZWxwLg0KPj4NCj4+IFBoaWwNCj4+DQo+Pj4gT24gQXByIDYsIDIwMTYsIGF0IDE0OjI1LCBI YW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDxtYWlsdG86aGFubmVz LnRzY2hvZmVuaWdAZ214Lm5ldD4+IHdyb3RlOg0KPj4+DQo+Pj4gSGkgYWxsLA0KPj4+DQo+Pj4g dGhpcyBpcyB0aGUgY2FsbCBmb3IgYWRvcHRpb24gb2YgJ1Jlc291cmNlIEluZGljYXRvcnMgZm9y IE9BdXRoIDIuMCcsIHNlZQ0KPj4+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtY2FtcGJlbGwtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy88aHR0cHM6Ly9uYTAxLnNhZmVs aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZmRhdGF0cmFja2Vy LmlldGYub3JnJTJmZG9jJTJmZHJhZnQtY2FtcGJlbGwtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9y cyUyZiZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzBkYjhkOTNkZjE2 YzQ0NjJhNTQ1MDhkMzVlNTUwMDIwJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDcl N2MxJnNkYXRhPWJ5TTNMT1hvUlRWaGdUOHBFQ3dyMThmSDhtcGk2OWJSZVdHRml1T0ViTUElM2Q+ DQo+Pj4NCj4+PiBQbGVhc2UgbGV0IHVzIGtub3cgYnkgQXByaWwgMjB0aCB3aGV0aGVyIHlvdSBh Y2NlcHQgLyBvYmplY3QgdG8gdGhlDQo+Pj4gYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCBhcyBh IHN0YXJ0aW5nIHBvaW50IGZvciB3b3JrIGluIHRoZSBPQXV0aA0KPj4+IHdvcmtpbmcgZ3JvdXAu DQo+Pj4NCj4+PiBOb3RlOiBJZiB5b3UgYWxyZWFkeSBzdGF0ZWQgeW91ciBvcGluaW9uIGF0IHRo ZSBJRVRGIG1lZXRpbmcgaW4gQnVlbm9zDQo+Pj4gQWlyZXMgdGhlbiB5b3UgZG9uJ3QgbmVlZCB0 byByZS1zdGF0ZSB5b3VyIG9waW5pb24sIGlmIHlvdSB3YW50Lg0KPj4+DQo+Pj4gVGhlIGZlZWRi YWNrIGF0IHRoZSBCQSBJRVRGIG1lZXRpbmcgd2FzIHRoZSBmb2xsb3dpbmc6IH4xMCBwZXJzb25z DQo+Pj4gZm9yIGFjY2VwdGluZyB0aGUgZG9jdW1lbnQgYW5kIDAgcGVyc29ucyBhZ2FpbnN0Lg0K Pj4+DQo+Pj4gQ2lhbw0KPj4+IEhhbm5lcyAmIERlcmVrDQo+Pj4NCj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IE9BdXRoIG1haWxpbmcgbGlz dA0KPj4+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0dHBzOi8vbmEwMS5zYWZlbGlu a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3Jn JTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1p Y3Jvc29mdC5jb20lN2MwZGI4ZDkzZGYxNmM0NDYyYTU0NTA4ZDM1ZTU1MDAyMCU3YzcyZjk4OGJm ODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1JVEhUNHhiMkQlMmJzcTRhdXZFdU92 MVZVd3FGbDlsUk9ONWFPTDZvT3N0OFUlM2Q+DQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYu b3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGg8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8l MmZvYXV0aCZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzBkYjhkOTNk ZjE2YzQ0NjJhNTQ1MDhkMzVlNTUwMDIwJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRi NDclN2MxJnNkYXRhPUlUSFQ0eGIyRCUyYnNxNGF1dkV1T3YxVlV3cUZsOWxST041YU9MNm9Pc3Q4 VSUzZD4NCg0K --_000_BN3PR0301MB12340B653C16BDC50001A887A69F0BN3PR0301MB1234_ 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 CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21z by1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5JIHdvdWxkIGxpa2UgdG8gc2VlIHRoZSBtdWx0aXBsZSByZXNvdXJjZXMgc2VydmVycywg aW50ZXJhY3Rpb24gd2l0aCBUb2tlbiBFeGNoYW5nZSByZXNvbHZlZCBiZWZvcmUgdGhpcyBpcyBh ZG9wdGVkIHRvIHNlZSBpZiB0aGlzIHdpbGwgYWN0dWFsbHkgc29sdmUgdGhlIHByb2JsZW1zPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxF bmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48 L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4gT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5CcmlhbiBDYW1wYmVsbDxicj4NCjxiPlNlbnQ6PC9iPiBXZWRu ZXNkYXksIEFwcmlsIDYsIDIwMTYgMTI6NTIgUE08YnI+DQo8Yj5Ubzo8L2I+IFBoaWwgSHVudCAo SURNKSAmbHQ7cGhpbC5odW50QG9yYWNsZS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBvYXV0aEBp ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBDYWxsIGZvciBBZG9w dGlvbjogUmVzb3VyY2UgSW5kaWNhdG9ycyBmb3IgT0F1dGggMi4wPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ SSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0IGJ5IHRoZSB3b3JraW5nIGdyb3Vw Lg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3Qg dGhpbmsgYW4gaW1tZWRpYXRlIFdHTEMgd2FzIGV4cGVjdGVkIGhlcmUuIDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBBcHIgNiwgMjAxNiBhdCA0 OjA2IFBNLCBQaGlsIEh1bnQgKElETSkgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3Jh Y2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2l0 aCB0aGUgcHJvY2VzcyBvZiBpbW1lZGlhdGUgd2dsYyBJIHRoaW5rIHdlIHNob3VsZCByZXZpZXcg YWxsIGRvY3VtZW50cyBtb3JlIHRob3JvdWdobHkgYmVmb3JlIGFkb3B0aW9uLjxicj4NCjxicj4N CkFzIEkgc2FpZCBJIHN1cHBvcnQgdGhlIHdvcmsuPGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM4 ODg4ODgiPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPlBoaWw8L3NwYW4+PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQomZ3Q7 IE9uIEFwciA2LCAyMDE2LCBhdCAxNjowMiwgSGFubmVzIFRzY2hvZmVuaWcgJmx0OzxhIGhyZWY9 Im1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Ij5oYW5uZXMudHNjaG9mZW5pZ0BnbXgu bmV0PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgUGhpbCw8YnI+DQomZ3Q7PGJy Pg0KJmd0OyB3ZSBoYXZlIGRpc2N1c3NlZCB0aGlzIGNvbmNlcHQgYWxyZWFkeSBmb3IgeWVhcnMu IEluIGZhY3QsIGl0IGRhdGVzIGJhY2s8YnI+DQomZ3Q7IHRvIHRoZSBkYXlzIG9mIHRoZSBPQXV0 aCBiYXNlIHNwZWNpZmljYXRpb24gYW5kIHRoZSBzZWN1cml0eTxicj4NCiZndDsgY29uc2lkZXJh dGlvbiBzZWN0aW9uIGV2ZW4gdGFsa3MgYWJvdXQgaXQuPGJyPg0KJmd0Ozxicj4NCiZndDsgV2Ug aGF2ZSBoYWQgdGhlIGNvbnRlbnQgb2YgdGhpcyBpbiB0aGUgUG9QIGtleSBkaXN0cmlidXRpb24g ZHJhZnQgYW5kIHdlPGJyPg0KJmd0OyBhcmUgbm93IG1vdmluZyBpdCBpbnRvIGEgc2VwYXJhdGUg ZG9jdW1lbnQuPGJyPg0KJmd0Ozxicj4NCiZndDsgSSBhbSBub3Qgc3VyZSBob3cgbXVjaCBsb25n ZXIgeW91IHdhbnQgdG8gZGlzY3VzcyBpdC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBDaWFvPGJyPg0K Jmd0OyBIYW5uZXM8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7IE9uIDA0LzA2LzIw MTYgMDg6MDcgUE0sIFBoaWwgSHVudCAoSURNKSB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyBJIHdvdWxk IGxpa2UgdG8gaGF2ZSBtb3JlIGRpc2N1c3Npb24gYmVmb3JlIHdnIGFkb3B0aW9uLjxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgSSBzdXBwb3J0IHRoZSB3b3JrIGFuZCBhbSB3aWxsaW5nIHRv IGhlbHAuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBQaGlsPGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsgT24gQXByIDYsIDIwMTYsIGF0IDE0OjI1LCBIYW5uZXMgVHNjaG9mZW5p ZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQiPmhhbm5lcy50 c2Nob2ZlbmlnQGdteC5uZXQ8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDsgSGkgYWxsLDxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyB0 aGlzIGlzIHRoZSBjYWxsIGZvciBhZG9wdGlvbiBvZiAnUmVzb3VyY2UgSW5kaWNhdG9ycyBmb3Ig T0F1dGggMi4wJywgc2VlPGJyPg0KJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vbmEwMS5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZkYXRhdHJh Y2tlci5pZXRmLm9yZyUyZmRvYyUyZmRyYWZ0LWNhbXBiZWxsLW9hdXRoLXJlc291cmNlLWluZGlj YXRvcnMlMmYmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjMGRi OGQ5M2RmMTZjNDQ2MmE1NDUwOGQzNWU1NTAwMjAlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2Nk MDExZGI0NyU3YzEmYW1wO3NkYXRhPWJ5TTNMT1hvUlRWaGdUOHBFQ3dyMThmSDhtcGk2OWJSZVdH Rml1T0ViTUElM2QiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtY2FtcGJlbGwtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy88L2E+PGJyPg0K Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IFBsZWFzZSBsZXQgdXMga25vdyBieSBBcHJp bCAyMHRoIHdoZXRoZXIgeW91IGFjY2VwdCAvIG9iamVjdCB0byB0aGU8YnI+DQomZ3Q7Jmd0OyZn dDsgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCBhcyBhIHN0YXJ0aW5nIHBvaW50IGZvciB3b3Jr IGluIHRoZSBPQXV0aDxicj4NCiZndDsmZ3Q7Jmd0OyB3b3JraW5nIGdyb3VwLjxicj4NCiZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBOb3RlOiBJZiB5b3UgYWxyZWFkeSBzdGF0ZWQgeW91 ciBvcGluaW9uIGF0IHRoZSBJRVRGIG1lZXRpbmcgaW4gQnVlbm9zPGJyPg0KJmd0OyZndDsmZ3Q7 IEFpcmVzIHRoZW4geW91IGRvbid0IG5lZWQgdG8gcmUtc3RhdGUgeW91ciBvcGluaW9uLCBpZiB5 b3Ugd2FudC48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgVGhlIGZlZWRiYWNr IGF0IHRoZSBCQSBJRVRGIG1lZXRpbmcgd2FzIHRoZSBmb2xsb3dpbmc6IH4xMCBwZXJzb25zPGJy Pg0KJmd0OyZndDsmZ3Q7IGZvciBhY2NlcHRpbmcgdGhlIGRvY3VtZW50IGFuZCAwIHBlcnNvbnMg YWdhaW5zdC48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgQ2lhbzxicj4NCiZn dDsmZ3Q7Jmd0OyBIYW5uZXMgJmFtcDsgRGVyZWs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQomZ3Q7Jmd0OyZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsmZ3Q7IDxh IGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0 OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3Rp bmZvJTJmb2F1dGgmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdj MGRiOGQ5M2RmMTZjNDQ2MmE1NDUwOGQzNWU1NTAwMjAlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk N2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPUlUSFQ0eGIyRCUyYnNxNGF1dkV1T3YxVlV3cUZsOWxS T041YU9MNm9Pc3Q4VSUzZCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQomZ3Q7PGJyPg0KPGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3Jn PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3Rp bmZvJTJmb2F1dGgmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdj MGRiOGQ5M2RmMTZjNDQ2MmE1NDUwOGQzNWU1NTAwMjAlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk N2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPUlUSFQ0eGIyRCUyYnNxNGF1dkV1T3YxVlV3cUZsOWxS T041YU9MNm9Pc3Q4VSUzZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BN3PR0301MB12340B653C16BDC50001A887A69F0BN3PR0301MB1234_-- From nobody Wed Apr 6 13:13:14 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7EF912D624 for ; Wed, 6 Apr 2016 13:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYAo-UKrnBMa for ; Wed, 6 Apr 2016 13:13:10 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001: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 69F7012D584 for ; Wed, 6 Apr 2016 13:13:10 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id 2so69884083ioy.1 for ; Wed, 06 Apr 2016 13:13:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LWHJcpaY/7FqU6F7ZeIqnR/w5vb+vsQzv+tqj+FXU+s=; b=Tng3WoJ0pCSTWwXbjnrkPHPsAJcNfzU/6g6Q8KEBN2Fxw1eFvZdUYcq5UoWJVdWTkM zxqg/qMeYqTPpqPqVUxd80aIgtCopVdx901/V9XD5BDqB5V5MBg5/oN/iu+6fpGPQWPx xqxYSHAgDur6H6RhrMB2Fb58qEUG6xhVqTYEw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LWHJcpaY/7FqU6F7ZeIqnR/w5vb+vsQzv+tqj+FXU+s=; b=QhvLjfNiWlfjLtwRBw4Nxl3ncBVqD+qw9WFcW+o6QXMdJFWSOQdlQ254MA6MyIwxMP fsTOuzAZ3KB7X1Vk80rQR6RhUlFKi12Rhh1UdI3Qr4vwrlB2AZw8PECWYAXRKsr+Lp3f m0CtYRlPifddprXrWAlZYQ720v5YjOLpmx2ArHVGxr4+hJYqEJovkSq5QrkNW9j6jsnA 13H8CtJ68lxVJbqj+D9zgaCBd0/r180S5RHf2XrIwRLZc84QdfJea3yYF7olcUEW7xua JgBHqb5KJLhUgmDMYsbqP++PCvnpb6c2caM3UAgf5ZH11m53IfeZ4aQzYSz1rzMxU9O/ QH0g== X-Gm-Message-State: AD7BkJJBtbsCyZYHXhSAzeugS8fjokJGvxCmXvTgM7/Tw+YcTM9km0WxAvUMnkPcdbm2MUjZv47oKn2ou0Jwk4Im X-Received: by 10.107.162.7 with SMTP id l7mr22985740ioe.147.1459973589546; Wed, 06 Apr 2016 13:13:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.74.162 with HTTP; Wed, 6 Apr 2016 13:12:40 -0700 (PDT) In-Reply-To: References: <570546A1.8040509@gmx.net> <57055D2D.9000600@gmx.net> <5AD9C0D6-C3BA-421D-99F6-B98FA509ADC6@oracle.com> From: Brian Campbell Date: Wed, 6 Apr 2016 17:12:40 -0300 Message-ID: To: Anthony Nadalin Content-Type: multipart/alternative; boundary=001a1140e638300301052fd69702 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 20:13:12 -0000 --001a1140e638300301052fd69702 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Multiple resources are there now. I have no idea what "interaction with Token Exchange" means. Can you please explain? On Wed, Apr 6, 2016 at 5:04 PM, Anthony Nadalin wrote: > I would like to see the multiple resources servers, interaction with Toke= n > Exchange resolved before this is adopted to see if this will actually sol= ve > the problems > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian > Campbell > *Sent:* Wednesday, April 6, 2016 12:52 PM > *To:* Phil Hunt (IDM) > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Call for Adoption: Resource Indicators for > OAuth 2.0 > > > > I support the adoption of this draft by the working group. > > I don't think an immediate WGLC was expected here. > > > > On Wed, Apr 6, 2016 at 4:06 PM, Phil Hunt (IDM) > wrote: > > With the process of immediate wglc I think we should review all documents > more thoroughly before adoption. > > As I said I support the work. > > Phil > > > > On Apr 6, 2016, at 16:02, Hannes Tschofenig > wrote: > > > > Phil, > > > > we have discussed this concept already for years. In fact, it dates bac= k > > to the days of the OAuth base specification and the security > > consideration section even talks about it. > > > > We have had the content of this in the PoP key distribution draft and w= e > > are now moving it into a separate document. > > > > I am not sure how much longer you want to discuss it. > > > > Ciao > > Hannes > > > > > >> On 04/06/2016 08:07 PM, Phil Hunt (IDM) wrote: > >> I would like to have more discussion before wg adoption. > >> > >> I support the work and am willing to help. > >> > >> Phil > >> > >>> On Apr 6, 2016, at 14:25, Hannes Tschofenig > wrote: > >>> > >>> Hi all, > >>> > >>> this is the call for adoption of 'Resource Indicators for OAuth 2.0', > see > >>> > http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/ > > >>> > >>> Please let us know by April 20th 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 Bueno= s > >>> Aires then you don't need to re-state your opinion, if you want. > >>> > >>> The feedback at the BA IETF meeting was the following: ~10 persons > >>> for accepting the document and 0 persons against. > >>> > >>> 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 > > > > --001a1140e638300301052fd69702 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Multiple resources are there now.

I hav= e no idea what "interaction with Token Exchange" means. Can you p= lease explain?

On Wed, Apr 6, 2016 at 5:04 PM, Anthony Nadalin &l= t;tonynad@micros= oft.com> wrote:

I would like to see the multiple resources servers,= interaction with Token Exchange resolved before this is adopted to see if = this will actually solve the problems

<= u>=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Wednesday, April 6, 2016 12:52 PM
To: Phil Hunt (IDM) <phil.hunt@oracle.com>
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for O= Auth 2.0

=C2=A0

I support the adoptio= n of this draft by the working group.

I don't think an immediate WGLC was expected her= e.

=C2=A0

On Wed, Apr 6, 2016 at 4:06 PM, Phil Hunt (IDM) <= phil.hunt@oracle.= com> wrote:

With the process of immediate wglc I think we should= review all documents more thoroughly before adoption.

As I said I support the work.

Phil


> On Apr 6, 2016, at 16:02, Hannes Tschofenig <hannes.tschofenig@gmx.net> = wrote:
>
> Phil,
>
> we have discussed this concept already for years. In fact, it dates ba= ck
> to the days of the OAuth base specification and the security
> consideration section even talks about it.
>
> We have had the content of this in the PoP key distribution draft and = we
> are now moving it into a separate document.
>
> I am not sure how much longer you want to discuss it.
>
> Ciao
> Hannes
>
>
>> On 04/06/2016 08:07 PM, Phil Hunt (IDM) wrote:
>> I would like to have more discussion before wg adoption.
>>
>> I support the work and am willing to help.
>>
>> Phil
>>
>>> On Apr 6, 2016, at 14:25, Hannes Tschofenig <hannes.tschofenig@gmx.net<= /a>> wrote:
>>>
>>> Hi all,
>>>
>>> this is the call for adoption of 'Resource Indicators for = OAuth 2.0', see
>>> http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
>>>
>>> Please let us know by April 20th whether you accept / object t= o 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 i= n Buenos
>>> Aires then you don't need to re-state your opinion, if you= want.
>>>
>>> The feedback at the BA IETF meeting was the following: ~10 per= sons
>>> for accepting the document and 0 persons against.
>>>
>>> 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

=C2=A0


--001a1140e638300301052fd69702-- From nobody Wed Apr 6 13:17:19 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B2112D7B4 for ; Wed, 6 Apr 2016 13:17:17 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFoMn8KMbqhF for ; Wed, 6 Apr 2016 13:17:14 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0798.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::798]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 205B112D79D for ; Wed, 6 Apr 2016 13:17:14 -0700 (PDT) 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=dKBylBP+odTeiAaob90b8dej3PvBymYoWmyqJ6jm9Qg=; b=AnxTrPD0jdaQjRycI8Cm47JIRKWZFsHn6j9My00kidW4ODzHRKviut2Ze4BfYzr1cIUi1F12kI8Wk+fJ0P8V1Js26t5MIdvAixedPiKPxONdkvDxml3xgPD+S3TVH3QzGlAj3MBPJwl7p+J/xWcEVU4YMMOKc3izfquC1VxWZkk= 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.447.15; Wed, 6 Apr 2016 20:16: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.0447.028; Wed, 6 Apr 2016 20:16:55 +0000 From: Anthony Nadalin To: Brian Campbell Thread-Topic: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0 Thread-Index: AQHRkCmB9ToVpiQsqkic7QI3EfNCup99PgWAgAAPRoCAAAE9gIAADLSAgAACpgCAAAMhAIAAAHJA Date: Wed, 6 Apr 2016 20:16:55 +0000 Message-ID: References: <570546A1.8040509@gmx.net> <57055D2D.9000600@gmx.net> <5AD9C0D6-C3BA-421D-99F6-B98FA509ADC6@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: pingidentity.com; dkim=none (message not signed) header.d=none;pingidentity.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [31.133.163.127] x-ms-office365-filtering-correlation-id: 525a7de2-b45b-4c6e-7bae-08d35e586630 x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1234; 5:IR9DBluAQgG+1ERFH7keluh64jarnjLVGxr1R2T9XLyGC0o7+IBBXot0uEZQYG49Kntmh0EIDwBdr/d2NaLwdMqhHf2Cs3kE3c6MyGKhZl4z4hpbaKEh8J6hJ+3OBTGWikXbfhggdeG80YGvLoCx+A==; 24:wHzxHhcyVZaBbuNUInvmf6y4tX1yHadxcHVDBY1/nkQv+KnSUZMf+hDM6cDY+B6Xv04rR0bSoVWf9NlyGhkgrgDdsXa1QWgy3KgmhonTdEI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1234; 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)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BN3PR0301MB1234; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1234; x-forefront-prvs: 0904004ECB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(53754006)(377454003)(99286002)(1220700001)(81166005)(11100500001)(87936001)(2950100001)(1096002)(102836003)(3846002)(2900100001)(790700001)(586003)(6116002)(10090500001)(5008740100001)(19580395003)(33656002)(122556002)(19580405001)(2906002)(4326007)(86362001)(3280700002)(5002640100001)(92566002)(110136002)(77096005)(50986999)(54356999)(3660700001)(74316001)(76176999)(86612001)(189998001)(15975445007)(5003600100002)(19609705001)(106116001)(19617315012)(5004730100002)(66066001)(8990500004)(93886004)(16236675004)(19625215002)(76576001)(19300405004)(10400500002)(5005710100001)(10290500002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1234; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1234AD45F45AA8983E8BE645A69F0BN3PR0301MB1234_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2016 20:16:55.2083 (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: Resource Indicators for OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 20:17:18 -0000 --_000_BN3PR0301MB1234AD45F45AA8983E8BE645A69F0BN3PR0301MB1234_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb27igJl0IHNlZSBhbnl0aGluZyBpbiB0aGUgZG9jdW1lbnQgdGhhdCBhbGxvd3MgbXVsdGlw bGUgcmVzb3VyY2Ugc2VydmVycyB3aGVyZSB0aGUgdG9rZW4gY2FuIGJlIHVzZWQuIFRva2VuIEV4 Y2hhbmdlIGFsbG93cyBkZWxlZ2F0aW9uIGFuZCBpbXBlcnNvbmF0aW9uLCBzbyBJIGhhdmUgbm8g aWRlYSBvZiB0aGUgc2VtYW50aWNzIHdoZW4gSSB1c2UgYm90aCBvZiB0aGVzZSB0b2dldGhlcg0K DQpGcm9tOiBCcmlhbiBDYW1wYmVsbCBbbWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29t XQ0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCA2LCAyMDE2IDE6MTMgUE0NClRvOiBBbnRob255IE5h ZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0LmNvbT4NCkNjOiBQaGlsIEh1bnQgKElETSkgPHBoaWwu aHVudEBvcmFjbGUuY29tPjsgb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0dd IENhbGwgZm9yIEFkb3B0aW9uOiBSZXNvdXJjZSBJbmRpY2F0b3JzIGZvciBPQXV0aCAyLjANCg0K TXVsdGlwbGUgcmVzb3VyY2VzIGFyZSB0aGVyZSBub3cuDQpJIGhhdmUgbm8gaWRlYSB3aGF0ICJp bnRlcmFjdGlvbiB3aXRoIFRva2VuIEV4Y2hhbmdlIiBtZWFucy4gQ2FuIHlvdSBwbGVhc2UgZXhw bGFpbj8NCg0KT24gV2VkLCBBcHIgNiwgMjAxNiBhdCA1OjA0IFBNLCBBbnRob255IE5hZGFsaW4g PHRvbnluYWRAbWljcm9zb2Z0LmNvbTxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPj4gd3Jv dGU6DQpJIHdvdWxkIGxpa2UgdG8gc2VlIHRoZSBtdWx0aXBsZSByZXNvdXJjZXMgc2VydmVycywg aW50ZXJhY3Rpb24gd2l0aCBUb2tlbiBFeGNoYW5nZSByZXNvbHZlZCBiZWZvcmUgdGhpcyBpcyBh ZG9wdGVkIHRvIHNlZSBpZiB0aGlzIHdpbGwgYWN0dWFsbHkgc29sdmUgdGhlIHByb2JsZW1zDQoN CkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgt Ym91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBCcmlhbiBDYW1wYmVsbA0KU2VudDogV2Vk bmVzZGF5LCBBcHJpbCA2LCAyMDE2IDEyOjUyIFBNDQpUbzogUGhpbCBIdW50IChJRE0pIDxwaGls Lmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+Pg0KQ2M6IG9hdXRo QGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0dd IENhbGwgZm9yIEFkb3B0aW9uOiBSZXNvdXJjZSBJbmRpY2F0b3JzIGZvciBPQXV0aCAyLjANCg0K SSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0IGJ5IHRoZSB3b3JraW5nIGdyb3Vw Lg0KSSBkb24ndCB0aGluayBhbiBpbW1lZGlhdGUgV0dMQyB3YXMgZXhwZWN0ZWQgaGVyZS4NCg0K T24gV2VkLCBBcHIgNiwgMjAxNiBhdCA0OjA2IFBNLCBQaGlsIEh1bnQgKElETSkgPHBoaWwuaHVu dEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+IHdyb3RlOg0KV2l0aCB0 aGUgcHJvY2VzcyBvZiBpbW1lZGlhdGUgd2dsYyBJIHRoaW5rIHdlIHNob3VsZCByZXZpZXcgYWxs IGRvY3VtZW50cyBtb3JlIHRob3JvdWdobHkgYmVmb3JlIGFkb3B0aW9uLg0KDQpBcyBJIHNhaWQg SSBzdXBwb3J0IHRoZSB3b3JrLg0KDQpQaGlsDQoNCj4gT24gQXByIDYsIDIwMTYsIGF0IDE2OjAy LCBIYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDxtYWlsdG86aGFu bmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4+IHdyb3RlOg0KPg0KPiBQaGlsLA0KPg0KPiB3ZSBoYXZl IGRpc2N1c3NlZCB0aGlzIGNvbmNlcHQgYWxyZWFkeSBmb3IgeWVhcnMuIEluIGZhY3QsIGl0IGRh dGVzIGJhY2sNCj4gdG8gdGhlIGRheXMgb2YgdGhlIE9BdXRoIGJhc2Ugc3BlY2lmaWNhdGlvbiBh bmQgdGhlIHNlY3VyaXR5DQo+IGNvbnNpZGVyYXRpb24gc2VjdGlvbiBldmVuIHRhbGtzIGFib3V0 IGl0Lg0KPg0KPiBXZSBoYXZlIGhhZCB0aGUgY29udGVudCBvZiB0aGlzIGluIHRoZSBQb1Aga2V5 IGRpc3RyaWJ1dGlvbiBkcmFmdCBhbmQgd2UNCj4gYXJlIG5vdyBtb3ZpbmcgaXQgaW50byBhIHNl cGFyYXRlIGRvY3VtZW50Lg0KPg0KPiBJIGFtIG5vdCBzdXJlIGhvdyBtdWNoIGxvbmdlciB5b3Ug d2FudCB0byBkaXNjdXNzIGl0Lg0KPg0KPiBDaWFvDQo+IEhhbm5lcw0KPg0KPg0KPj4gT24gMDQv MDYvMjAxNiAwODowNyBQTSwgUGhpbCBIdW50IChJRE0pIHdyb3RlOg0KPj4gSSB3b3VsZCBsaWtl IHRvIGhhdmUgbW9yZSBkaXNjdXNzaW9uIGJlZm9yZSB3ZyBhZG9wdGlvbi4NCj4+DQo+PiBJIHN1 cHBvcnQgdGhlIHdvcmsgYW5kIGFtIHdpbGxpbmcgdG8gaGVscC4NCj4+DQo+PiBQaGlsDQo+Pg0K Pj4+IE9uIEFwciA2LCAyMDE2LCBhdCAxNDoyNSwgSGFubmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50 c2Nob2ZlbmlnQGdteC5uZXQ8bWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+PiB3cm90 ZToNCj4+Pg0KPj4+IEhpIGFsbCwNCj4+Pg0KPj4+IHRoaXMgaXMgdGhlIGNhbGwgZm9yIGFkb3B0 aW9uIG9mICdSZXNvdXJjZSBJbmRpY2F0b3JzIGZvciBPQXV0aCAyLjAnLCBzZWUNCj4+PiBodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNhbXBiZWxsLW9hdXRoLXJlc291cmNl LWluZGljYXRvcnMvPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHAlM2ElMmYlMmZkYXRhdHJhY2tlci5pZXRmLm9yZyUyZmRvYyUyZmRyYWZ0LWNh bXBiZWxsLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMlMmYmZGF0YT0wMSU3YzAxJTdjdG9ueW5h ZCU0MG1pY3Jvc29mdC5jb20lN2MwZGI4ZDkzZGYxNmM0NDYyYTU0NTA4ZDM1ZTU1MDAyMCU3Yzcy Zjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1ieU0zTE9Yb1JUVmhnVDhw RUN3cjE4Zkg4bXBpNjliUmVXR0ZpdU9FYk1BJTNkPg0KPj4+DQo+Pj4gUGxlYXNlIGxldCB1cyBr bm93IGJ5IEFwcmlsIDIwdGggd2hldGhlciB5b3UgYWNjZXB0IC8gb2JqZWN0IHRvIHRoZQ0KPj4+ IGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgYXMgYSBzdGFydGluZyBwb2ludCBmb3Igd29yayBp biB0aGUgT0F1dGgNCj4+PiB3b3JraW5nIGdyb3VwLg0KPj4+DQo+Pj4gTm90ZTogSWYgeW91IGFs cmVhZHkgc3RhdGVkIHlvdXIgb3BpbmlvbiBhdCB0aGUgSUVURiBtZWV0aW5nIGluIEJ1ZW5vcw0K Pj4+IEFpcmVzIHRoZW4geW91IGRvbid0IG5lZWQgdG8gcmUtc3RhdGUgeW91ciBvcGluaW9uLCBp ZiB5b3Ugd2FudC4NCj4+Pg0KPj4+IFRoZSBmZWVkYmFjayBhdCB0aGUgQkEgSUVURiBtZWV0aW5n IHdhcyB0aGUgZm9sbG93aW5nOiB+MTAgcGVyc29ucw0KPj4+IGZvciBhY2NlcHRpbmcgdGhlIGRv Y3VtZW50IGFuZCAwIHBlcnNvbnMgYWdhaW5zdC4NCj4+Pg0KPj4+IENpYW8NCj4+PiBIYW5uZXMg JiBEZXJlaw0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+PiBPQXV0aEBpZXRmLm9yZzxtYWls dG86T0F1dGhAaWV0Zi5vcmc+DQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v P3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9h dXRoJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjMGRiOGQ5M2RmMTZj NDQ2MmE1NDUwOGQzNWU1NTAwMjAlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3 YzEmc2RhdGE9SVRIVDR4YjJEJTJic3E0YXV2RXVPdjFWVXdxRmw5bFJPTjVhT0w2b09zdDhVJTNk Pg0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K T0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0dHBzOi8vbmEw MS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3 LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmZGF0YT0wMSU3YzAxJTdjdG9u eW5hZCU0MG1pY3Jvc29mdC5jb20lN2MwZGI4ZDkzZGYxNmM0NDYyYTU0NTA4ZDM1ZTU1MDAyMCU3 YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1JVEhUNHhiMkQlMmJz cTRhdXZFdU92MVZVd3FGbDlsUk9ONWFPTDZvT3N0OFUlM2Q+DQoNCg0K --_000_BN3PR0301MB1234AD45F45AA8983E8BE645A69F0BN3PR0301MB1234_ 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 YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgZG9u4oCZdCBzZWUgYW55dGhpbmcgaW4gdGhlIGRvY3Vt ZW50IHRoYXQgYWxsb3dzIG11bHRpcGxlIHJlc291cmNlIHNlcnZlcnMgd2hlcmUgdGhlIHRva2Vu IGNhbiBiZSB1c2VkLiBUb2tlbiBFeGNoYW5nZSBhbGxvd3MgZGVsZWdhdGlvbiBhbmQgaW1wZXJz b25hdGlvbiwgc28gSSBoYXZlIG5vIGlkZWENCiBvZiB0aGUgc2VtYW50aWNzIHdoZW4gSSB1c2Ug Ym90aCBvZiB0aGVzZSB0b2dldGhlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpf TWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEJyaWFuIENhbXBiZWxs IFttYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4g V2VkbmVzZGF5LCBBcHJpbCA2LCAyMDE2IDE6MTMgUE08YnI+DQo8Yj5Ubzo8L2I+IEFudGhvbnkg TmFkYWxpbiAmbHQ7dG9ueW5hZEBtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gUGhp bCBIdW50IChJRE0pICZsdDtwaGlsLmh1bnRAb3JhY2xlLmNvbSZndDs7IG9hdXRoQGlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIENhbGwgZm9yIEFkb3B0aW9uOiBS ZXNvdXJjZSBJbmRpY2F0b3JzIGZvciBPQXV0aCAyLjA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5NdWx0aXBs ZSByZXNvdXJjZXMgYXJlIHRoZXJlIG5vdy4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgbm8gaWRlYSB3aGF0ICZxdW90O2ludGVyYWN0aW9uIHdp dGggVG9rZW4gRXhjaGFuZ2UmcXVvdDsgbWVhbnMuIENhbiB5b3UgcGxlYXNlIGV4cGxhaW4/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEFwciA2 LCAyMDE2IGF0IDU6MDQgUE0sIEFudGhvbnkgTmFkYWxpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRv bnluYWRAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRvbnluYWRAbWljcm9zb2Z0LmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgd291bGQgbGlrZSB0 byBzZWUgdGhlIG11bHRpcGxlIHJlc291cmNlcyBzZXJ2ZXJzLCBpbnRlcmFjdGlvbiB3aXRoIFRv a2VuIEV4Y2hhbmdlIHJlc29sdmVkIGJlZm9yZSB0aGlzIGlzIGFkb3B0ZWQNCiB0byBzZWUgaWYg dGhpcyB3aWxsIGFjdHVhbGx5IHNvbHZlIHRoZSBwcm9ibGVtczwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgbmFtZT0ibV8tNTI0NzMzMzg5OTE3MDQ5OTg5 X19NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9hPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBPQXV0aCBbbWFpbHRvOjxhIGhyZWY9Im1h aWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNl c0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJyaWFuIENhbXBiZWxsPGJyPg0K PGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXByaWwgNiwgMjAxNiAxMjo1MiBQTTxicj4NCjxiPlRv OjwvYj4gUGhpbCBIdW50IChJRE0pICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNs ZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7PGJyPg0K PGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10g Q2FsbCBmb3IgQWRvcHRpb246IFJlc291cmNlIEluZGljYXRvcnMgZm9yIE9BdXRoIDIuMDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5JIHN1 cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHRoaXMgZHJhZnQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAuDQo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGRvbid0IHRo aW5rIGFuIGltbWVkaWF0ZSBXR0xDIHdhcyBleHBlY3RlZCBoZXJlLg0KPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gV2VkLCBBcHIgNiwgMjAxNiBh dCA0OjA2IFBNLCBQaGlsIEh1bnQgKElETSkgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRA b3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2l0aCB0aGUgcHJvY2VzcyBv ZiBpbW1lZGlhdGUgd2dsYyBJIHRoaW5rIHdlIHNob3VsZCByZXZpZXcgYWxsIGRvY3VtZW50cyBt b3JlIHRob3JvdWdobHkgYmVmb3JlIGFkb3B0aW9uLjxicj4NCjxicj4NCkFzIEkgc2FpZCBJIHN1 cHBvcnQgdGhlIHdvcmsuPGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NClBo aWw8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGJyPg0KJmd0OyBPbiBBcHIgNiwgMjAxNiwgYXQgMTY6MDIsIEhhbm5lcyBUc2Nob2Zl bmlnICZsdDs8YSBocmVmPSJtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldCIgdGFyZ2V0 PSJfYmxhbmsiPmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ8L2E+Jmd0OyB3cm90ZTo8YnI+DQom Z3Q7PGJyPg0KJmd0OyBQaGlsLDxicj4NCiZndDs8YnI+DQomZ3Q7IHdlIGhhdmUgZGlzY3Vzc2Vk IHRoaXMgY29uY2VwdCBhbHJlYWR5IGZvciB5ZWFycy4gSW4gZmFjdCwgaXQgZGF0ZXMgYmFjazxi cj4NCiZndDsgdG8gdGhlIGRheXMgb2YgdGhlIE9BdXRoIGJhc2Ugc3BlY2lmaWNhdGlvbiBhbmQg dGhlIHNlY3VyaXR5PGJyPg0KJmd0OyBjb25zaWRlcmF0aW9uIHNlY3Rpb24gZXZlbiB0YWxrcyBh Ym91dCBpdC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBXZSBoYXZlIGhhZCB0aGUgY29udGVudCBvZiB0 aGlzIGluIHRoZSBQb1Aga2V5IGRpc3RyaWJ1dGlvbiBkcmFmdCBhbmQgd2U8YnI+DQomZ3Q7IGFy ZSBub3cgbW92aW5nIGl0IGludG8gYSBzZXBhcmF0ZSBkb2N1bWVudC48YnI+DQomZ3Q7PGJyPg0K Jmd0OyBJIGFtIG5vdCBzdXJlIGhvdyBtdWNoIGxvbmdlciB5b3Ugd2FudCB0byBkaXNjdXNzIGl0 Ljxicj4NCiZndDs8YnI+DQomZ3Q7IENpYW88YnI+DQomZ3Q7IEhhbm5lczxicj4NCiZndDs8YnI+ DQomZ3Q7PGJyPg0KJmd0OyZndDsgT24gMDQvMDYvMjAxNiAwODowNyBQTSwgUGhpbCBIdW50IChJ RE0pIHdyb3RlOjxicj4NCiZndDsmZ3Q7IEkgd291bGQgbGlrZSB0byBoYXZlIG1vcmUgZGlzY3Vz c2lvbiBiZWZvcmUgd2cgYWRvcHRpb24uPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJIHN1 cHBvcnQgdGhlIHdvcmsgYW5kIGFtIHdpbGxpbmcgdG8gaGVscC48YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7IFBoaWw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBPbiBBcHIgNiwg MjAxNiwgYXQgMTQ6MjUsIEhhbm5lcyBUc2Nob2ZlbmlnICZsdDs8YSBocmVmPSJtYWlsdG86aGFu bmVzLnRzY2hvZmVuaWdAZ214Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmhhbm5lcy50c2Nob2Zlbmln QGdteC5uZXQ8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsgSGkgYWxsLDxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyB0aGlzIGlzIHRo ZSBjYWxsIGZvciBhZG9wdGlvbiBvZiAnUmVzb3VyY2UgSW5kaWNhdG9ycyBmb3IgT0F1dGggMi4w Jywgc2VlPGJyPg0KJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZkYXRhdHJhY2tlci5pZXRm Lm9yZyUyZmRvYyUyZmRyYWZ0LWNhbXBiZWxsLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMlMmYm YW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjMGRiOGQ5M2RmMTZj NDQ2MmE1NDUwOGQzNWU1NTAwMjAlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3 YzEmYW1wO3NkYXRhPWJ5TTNMT1hvUlRWaGdUOHBFQ3dyMThmSDhtcGk2OWJSZVdHRml1T0ViTUEl M2QiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtY2FtcGJlbGwtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy88L2E+PGJyPg0KJmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IFBsZWFzZSBsZXQgdXMga25vdyBieSBBcHJpbCAyMHRoIHdo ZXRoZXIgeW91IGFjY2VwdCAvIG9iamVjdCB0byB0aGU8YnI+DQomZ3Q7Jmd0OyZndDsgYWRvcHRp b24gb2YgdGhpcyBkb2N1bWVudCBhcyBhIHN0YXJ0aW5nIHBvaW50IGZvciB3b3JrIGluIHRoZSBP QXV0aDxicj4NCiZndDsmZ3Q7Jmd0OyB3b3JraW5nIGdyb3VwLjxicj4NCiZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7Jmd0OyBOb3RlOiBJZiB5b3UgYWxyZWFkeSBzdGF0ZWQgeW91ciBvcGluaW9u IGF0IHRoZSBJRVRGIG1lZXRpbmcgaW4gQnVlbm9zPGJyPg0KJmd0OyZndDsmZ3Q7IEFpcmVzIHRo ZW4geW91IGRvbid0IG5lZWQgdG8gcmUtc3RhdGUgeW91ciBvcGluaW9uLCBpZiB5b3Ugd2FudC48 YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgVGhlIGZlZWRiYWNrIGF0IHRoZSBC QSBJRVRGIG1lZXRpbmcgd2FzIHRoZSBmb2xsb3dpbmc6IH4xMCBwZXJzb25zPGJyPg0KJmd0OyZn dDsmZ3Q7IGZvciBhY2NlcHRpbmcgdGhlIGRvY3VtZW50IGFuZCAwIHBlcnNvbnMgYWdhaW5zdC48 YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgQ2lhbzxicj4NCiZndDsmZ3Q7Jmd0 OyBIYW5uZXMgJmFtcDsgRGVyZWs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7 Jmd0OyZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1h aWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxi cj4NCiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4l MmZsaXN0aW5mbyUyZm9hdXRoJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0 LmNvbSU3YzBkYjhkOTNkZjE2YzQ0NjJhNTQ1MDhkMzVlNTUwMDIwJTdjNzJmOTg4YmY4NmYxNDFh ZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1JVEhUNHhiMkQlMmJzcTRhdXZFdU92MVZV d3FGbDlsUk9ONWFPTDZvT3N0OFUlM2QiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0Ozxicj4NCjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGgg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNh ZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0 Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9u eW5hZCU0MG1pY3Jvc29mdC5jb20lN2MwZGI4ZDkzZGYxNmM0NDYyYTU0NTA4ZDM1ZTU1MDAyMCU3 YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9SVRIVDR4YjJE JTJic3E0YXV2RXVPdjFWVXdxRmw5bFJPTjVhT0w2b09zdDhVJTNkIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_BN3PR0301MB1234AD45F45AA8983E8BE645A69F0BN3PR0301MB1234_-- From nobody Wed Apr 6 13:24:17 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B0212D542 for ; Wed, 6 Apr 2016 13:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HkDDLP9vT-Q for ; Wed, 6 Apr 2016 13:24:10 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AEAD12D174 for ; Wed, 6 Apr 2016 13:24:10 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id o126so47871339iod.0 for ; Wed, 06 Apr 2016 13:24:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Tlme7WH+lLGLqK2ak1tm2wcn87A/ziFc4uupOPbldXA=; b=XLCrxm6ccRk1lDXyXHUXk5DGLFYrkcr8G6qYR6uL9MtKNnG5gC49AhgL2Xyuc+m9nX AK5aVLNB74U/wjvyceDNvgAIjBUrzbs6yG006i5/x2XFEicABeA4p2DOhYtJcV5PszaC nePuTUYPFCTb8OmbCnPJQydW6PGhs7nnO1kkI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Tlme7WH+lLGLqK2ak1tm2wcn87A/ziFc4uupOPbldXA=; b=bxHRTmy88pzI8gffdeIaiqPAFyM3ZlvckN07sai+EijZgVEHdQsly8PCzIIIuBp2Ni He6sS4yzXW9RNtL+mb0o8vbMsj+1yLk2pR4L5/0o9FjohY9ujC4IQOi21sdjw0laiplG cD/XB07qdtM36cjl6FLyLVmlKeuaz7h4Jx2yf/N5D8x9DPaRGyr3yeqnbof4Sou48LOF S1jmka9G3dWjqIuHUySWpNB18WH51D9JYcPf+6jGiDGPR+hNGSb+y1NWahb1w0tCS0vF +XLZtEBIVneNU4lR60ekteOKyx4SMTQLPcu+FdJJ9Q52nJTlZa1pe5RYJ/fpRnZrIC2t 0dFQ== X-Gm-Message-State: AD7BkJLMTmqrIiruey5P9WsKbibvaSZphYAGucVEb8dA7XsxZiNpZDjtIZ8ojLKvak0xRU05bHDjSWFVTnZMwPqb X-Received: by 10.107.13.133 with SMTP id 127mr28341497ion.129.1459974249895; Wed, 06 Apr 2016 13:24:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.74.162 with HTTP; Wed, 6 Apr 2016 13:23:40 -0700 (PDT) In-Reply-To: References: <570546A1.8040509@gmx.net> <57055D2D.9000600@gmx.net> <5AD9C0D6-C3BA-421D-99F6-B98FA509ADC6@oracle.com> From: Brian Campbell Date: Wed, 6 Apr 2016 17:23:40 -0300 Message-ID: To: Anthony Nadalin Content-Type: multipart/alternative; boundary=001a113ffc708bf0d6052fd6becf Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 20:24:13 -0000 --001a113ffc708bf0d6052fd6becf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Please read the draft. On Wed, Apr 6, 2016 at 5:16 PM, Anthony Nadalin wrote: > I don=E2=80=99t see anything in the document that allows multiple resourc= e servers > where the token can be used. Token Exchange allows delegation and > impersonation, so I have no idea of the semantics when I use both of thes= e > together > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Wednesday, April 6, 2016 1:13 PM > *To:* Anthony Nadalin > *Cc:* Phil Hunt (IDM) ; oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] Call for Adoption: Resource Indicators for > OAuth 2.0 > > > > Multiple resources are there now. > > I have no idea what "interaction with Token Exchange" means. Can you > please explain? > > > > On Wed, Apr 6, 2016 at 5:04 PM, Anthony Nadalin > wrote: > > I would like to see the multiple resources servers, interaction with Toke= n > Exchange resolved before this is adopted to see if this will actually sol= ve > the problems > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian > Campbell > *Sent:* Wednesday, April 6, 2016 12:52 PM > *To:* Phil Hunt (IDM) > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Call for Adoption: Resource Indicators for > OAuth 2.0 > > > > I support the adoption of this draft by the working group. > > I don't think an immediate WGLC was expected here. > > > > On Wed, Apr 6, 2016 at 4:06 PM, Phil Hunt (IDM) > wrote: > > With the process of immediate wglc I think we should review all documents > more thoroughly before adoption. > > As I said I support the work. > > Phil > > > > On Apr 6, 2016, at 16:02, Hannes Tschofenig > wrote: > > > > Phil, > > > > we have discussed this concept already for years. In fact, it dates bac= k > > to the days of the OAuth base specification and the security > > consideration section even talks about it. > > > > We have had the content of this in the PoP key distribution draft and w= e > > are now moving it into a separate document. > > > > I am not sure how much longer you want to discuss it. > > > > Ciao > > Hannes > > > > > >> On 04/06/2016 08:07 PM, Phil Hunt (IDM) wrote: > >> I would like to have more discussion before wg adoption. > >> > >> I support the work and am willing to help. > >> > >> Phil > >> > >>> On Apr 6, 2016, at 14:25, Hannes Tschofenig > wrote: > >>> > >>> Hi all, > >>> > >>> this is the call for adoption of 'Resource Indicators for OAuth 2.0', > see > >>> > http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/ > > >>> > >>> Please let us know by April 20th 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 Bueno= s > >>> Aires then you don't need to re-state your opinion, if you want. > >>> > >>> The feedback at the BA IETF meeting was the following: ~10 persons > >>> for accepting the document and 0 persons against. > >>> > >>> 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 > > > > > > --001a113ffc708bf0d6052fd6becf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Please read the draft.

On Wed, Apr 6, 2016 at 5:16 PM, Anthony Nad= alin <tonynad@microsoft.com> wrote:

I don=E2=80=99t see anything in the document that a= llows multiple resource servers where the token can be used. Token Exchange= allows delegation and impersonation, so I have no idea of the semantics when I use both of these together

<= u>=C2=A0

From: Brian Campbell [mailto:bcampbell@pingiden= tity.com]
Sent: Wednesday, April 6, 2016 1:13 PM
To: Anthony Nadalin <tonynad@microsoft.com>
Cc: Phil Hunt (IDM) <phil.hunt@oracle.com>; oauth@ietf.org

Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for O= Auth 2.0

=C2=A0

Multiple resources ar= e there now.

I have no idea what "interaction with Token Exc= hange" means. Can you please explain?

=C2=A0

On Wed, Apr 6, 2016 at 5:04 PM, Anthony Nadalin <= tonynad@microsof= t.com> wrote:

I would like to see the multiple resources servers,= interaction with Token Exchange resolved before this is adopted to see if this will actually solve the problems

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Wednesday, April 6, 2016 12:52 PM
To: Phil Hunt (IDM) <phil.hunt@oracle.com>
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for O= Auth 2.0

=C2=A0

I support the adoptio= n of this draft by the working group.

I don't think an immediate WGLC was expected her= e.

=C2=A0

On Wed, Apr 6, 2016 at 4:06 PM, Phil Hunt (IDM) <= phil.hunt@oracle.= com> wrote:

With the process of immediate wglc I think we should= review all documents more thoroughly before adoption.

As I said I support the work.

Phil


> On Apr 6, 2016, at 16:02, Hannes Tschofenig <hannes.tschofenig@gmx.net> = wrote:
>
> Phil,
>
> we have discussed this concept already for years. In fact, it dates ba= ck
> to the days of the OAuth base specification and the security
> consideration section even talks about it.
>
> We have had the content of this in the PoP key distribution draft and = we
> are now moving it into a separate document.
>
> I am not sure how much longer you want to discuss it.
>
> Ciao
> Hannes
>
>
>> On 04/06/2016 08:07 PM, Phil Hunt (IDM) wrote:
>> I would like to have more discussion before wg adoption.
>>
>> I support the work and am willing to help.
>>
>> Phil
>>
>>> On Apr 6, 2016, at 14:25, Hannes Tschofenig <hannes.tschofenig@gmx.net<= /a>> wrote:
>>>
>>> Hi all,
>>>
>>> this is the call for adoption of 'Resource Indicators for = OAuth 2.0', see
>>> http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
>>>
>>> Please let us know by April 20th whether you accept / object t= o 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 i= n Buenos
>>> Aires then you don't need to re-state your opinion, if you= want.
>>>
>>> The feedback at the BA IETF meeting was the following: ~10 per= sons
>>> for accepting the document and 0 persons against.
>>>
>>> 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

=C2=A0

=C2=A0


--001a113ffc708bf0d6052fd6becf-- From nobody Wed Apr 6 14:03:20 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34AE612D5C9 for ; Wed, 6 Apr 2016 14:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ei2FQB7a19UF for ; Wed, 6 Apr 2016 14:03:16 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2032812D542 for ; Wed, 6 Apr 2016 14:03:15 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id k135so19164319qke.0 for ; Wed, 06 Apr 2016 14:03:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FzarFLqjjUpU+TjuCjVJRU0PDiB25FAGuUChMe+I6MA=; b=1aKBWp1M9KWcnB6f4hUnyUd1i/WeXudsqHEP3TGz4WcI/P0ACj94tLM7dDUP9c3PKW +r1atxCss4jrQlTTXuRpen/YrRb+3SDVsEUdd27E8m2cGRJP4/wGF2d34+mPsB+y15Af /or/fDUTwqsJnlA0cRWEshiUPeuA8HOE4e0I3gO48/MAhE1PpbFjgdlmnkljpiVRpYu2 C/GjsN9AaTotGf6oeqdt/KS55aWTr/7rmZPyAHupDvlWmFahEU8f7rDds33B+dVyRyqK gM1p4tvUFSQVc7dzVo24ie7BBIv35uen/YO2Rj++sMweBxWoUV1UFda2zJ6QCN0ocog+ hpcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FzarFLqjjUpU+TjuCjVJRU0PDiB25FAGuUChMe+I6MA=; b=fLxVWtxhnDF5T/xoKqzMXK2YmUnxPQyhFQMvZZG3IxQ9eJA+4gMITrTci/iVwSghsg QP0sKju5pshtOvtu0SYOnrp7uJ9lV8soJ65n5+NnrQLF0ijRDCK9NlTNkvLei6mDmtx9 rGpY9zYN0gbOfGB5OWLLRYE555ZWutdu+Cl3VOaISDDgdFAWvigPgswxILMbFphxjOIX euMN10zndYY+UADPKsIGmF7uUhQDga9EEGq3QaSfSHUsu0s0pIIe+XjAQNDjw7bDCqNh Pf5E03xA+QaeSkyms28xH/tk1sN610OxClNzff5LEkbuHVD3URaxMLKgq/wkQNOXpDVV DGsQ== X-Gm-Message-State: AD7BkJKq0u0PH9wnurrSIOMpbkhmKChtgfe1jCrc09w9yx6hJswuBHOeTXRr0E6kDi7A1w== X-Received: by 10.55.75.85 with SMTP id y82mr49452549qka.29.1459976595017; Wed, 06 Apr 2016 14:03:15 -0700 (PDT) Received: from dhcp-a325.meeting.ietf.org (dhcp-a325.meeting.ietf.org. [31.133.163.37]) by smtp.gmail.com with ESMTPSA id c90sm2033370qkj.47.2016.04.06.14.03.13 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 06 Apr 2016 14:03:13 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: <570546A1.8040509@gmx.net> Date: Wed, 6 Apr 2016 18:03:10 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <570546A1.8040509@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 21:03:18 -0000 I support adoption by the WG. > On Apr 6, 2016, at 2:25 PM, Hannes Tschofenig = wrote: >=20 > Hi all, >=20 > this is the call for adoption of 'Resource Indicators for OAuth 2.0', = see > = http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/ >=20 > Please let us know by April 20th 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 Buenos > Aires then you don't need to re-state your opinion, if you want. >=20 > The feedback at the BA IETF meeting was the following: ~10 persons > for accepting the document and 0 persons against. >=20 > Ciao > Hannes & Derek >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Apr 6 14:31:30 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797A412D5BD for ; Wed, 6 Apr 2016 14:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=salesforce.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTIKVffe46TM for ; Wed, 6 Apr 2016 14:20:42 -0700 (PDT) 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 B7BA812D542 for ; Wed, 6 Apr 2016 14:20:42 -0700 (PDT) Received: by mail-ig0-x232.google.com with SMTP id kb1so168601igb.0 for ; Wed, 06 Apr 2016 14:20:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salesforce.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uQ+bDznJYqqwwaZYyuGX9/49QkOUiFhrzyHJn7c908k=; b=a7Ywn7Gpr5uz9UyWsDfCfYOp420pFeaazEaA4d6Wdi8bdV0CZnBRHJPBZy8AWlsPiz hZLcOo/g2yNpnzAwxKYX83xYFO/zaBEgzCGh8PzY/fNKyV8Tp78Iceu6AdSrm5QM0Lfm Z8y+Rq8C4LMh4E0Wtsbt7ppMpVuh6/4wCPggs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uQ+bDznJYqqwwaZYyuGX9/49QkOUiFhrzyHJn7c908k=; b=eJirt1wNW06GWHl0gMAIAZjJVjoCHFcDHozAHfbMPyns8AS8+ahILOrBUu5qRF2ITu LE4oufrgxj4UqXi99THlhqmbAzi2bsFSaGLPfGFIX2FnJ1w333Xw5AYFjsrKT82BRi5W X9MnXumyvYoUd95ADbl2MbVRS0+KR9H8FtHr6s3elWNNs7qlZAOm2rt53zR+gJJxc2Or OywkAy2d1Fj3wXw4KJksKfl2601/jnxgifc2tsv8OkalnLAenZ61Zv9DPvO6jkxzIUc+ 7BYT1WvhqGV0L4RfykMFiJw+XYAApKFiT3tr5y6/QRHFahmltbL4scUnH9A1V7fUNsBA d88Q== X-Gm-Message-State: AD7BkJKLRWEKsNwjCKcz2x9t3i+iKjdIWLGVC1wmOSdBZS67ByhO9IXv693w/UKduv7Kgzd9/hZEXivt7tWmRvL3 X-Received: by 10.50.72.82 with SMTP id b18mr33913igv.79.1459977641942; Wed, 06 Apr 2016 14:20:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.61.16 with HTTP; Wed, 6 Apr 2016 14:20:22 -0700 (PDT) In-Reply-To: References: From: Ian Glazer Date: Wed, 6 Apr 2016 17:20:22 -0400 Message-ID: To: "Hardt, Dick" Content-Type: multipart/alternative; boundary=047d7bdc9e76bab493052fd7886e Archived-At: X-Mailman-Approved-At: Wed, 06 Apr 2016 14:31:28 -0700 Cc: "scim@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 21:20:44 -0000 --047d7bdc9e76bab493052fd7886e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'd be interested too On Tue, Apr 5, 2016 at 5:59 PM, Hardt, Dick wrote: > Use case: An admin for an organization would like to enable her users to > access a SaaS application at her IdP. > > User experience: > > 1. Admin authenticates to IdP in browser > 2. Admin selects SaaS app to federate with from list at IdP > 3. IdP optionally presents config options > 4. IdP redirects Admin to SaaS app > 5. Admin authenticates to SaaS app > 6. SaaS app optionally gathers config options > 7. SaaS app redirects admin to IdP > 8. IdP confirms successful federation =3D> OIDC / SAML and SCIM are no= w > configured and working between IdP and SaaS App > > Who else is interested in solving this? > > Is there interest in working on this in either SCIM or OAUTH Wgs? > > Any one in BA interested in meeting on this topic this week? > > =E2=80=94 Dick > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --=20 Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer --047d7bdc9e76bab493052fd7886e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'd be interested too
=
On Tue, Apr 5, 2016 at 5:59 PM, Hardt, Dick = <= dick@amazon.com> wrote:
Use case: An admin for an organization would like to enable her users = to access a SaaS application at her IdP.=C2=A0

User experience:=C2=A0
  1. Admin authenticates to IdP in browser
  2. Admin selects SaaS app to= federate with from list at IdP
  3. IdP optionally presents config opti= ons
  4. IdP redirects Admin to SaaS app
  5. Admin authenticates to = SaaS app
  6. SaaS app optionally gathers config options
  7. SaaS ap= p redirects admin to IdP
  8. IdP confirms successful federation =3D>= OIDC / SAML and SCIM are now configured and working between IdP and SaaS A= pp
Who else is interested in solving this?

Is there interest in working on this in either SCIM or OAUTH Wgs?

Any one in BA interested in meeting on this topic this week?

=E2=80=94 Dick

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




--
Ian Glazer
Senio= r Director, Identity
+1 202 255 3166
--047d7bdc9e76bab493052fd7886e-- From nobody Wed Apr 6 15:14:17 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F49212D149; Wed, 6 Apr 2016 15:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43zuuj6s3wmV; Wed, 6 Apr 2016 15:14:13 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0131.outbound.protection.outlook.com [65.55.169.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF37912D101; Wed, 6 Apr 2016 15:14:12 -0700 (PDT) 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=5Pob+67REjignU4lVpAn7JlH9r0CDGcsIdx9K9urtuw=; b=KtOdk27DX8vGaJ2m6nyYkew2HULV6dGZoOLtH9VnHT4T8OHztxMhIDi684TurX7bRKrtPWqgXK5RcydaoCS8/Q1NWJcuTFevejWAMzFOACN6OjufCM8M1LTKHiAeIoheqDkhxbDJdoDAUsyKOPEo+39KZTzgQXpf4bTChfMs6tI= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1648.namprd03.prod.outlook.com (10.162.130.142) with Microsoft SMTP Server (TLS) id 15.1.447.15; Wed, 6 Apr 2016 22:14:10 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0447.028; Wed, 6 Apr 2016 22:14:10 +0000 From: Mike Jones To: "Hardt, Dick" , "Phil Hunt (IDM)" Thread-Topic: [scim] Simple Federation Deployment Thread-Index: AQHRj4qWMk6yJIjegUqu3vwLPN62ep99hBVg Date: Wed, 6 Apr 2016 22:14:09 +0000 Message-ID: References: <086477E4-5F4E-4C52-AC91-E26824A9FA7A@oracle.com> <78D87E6B-DBFE-46D9-B7FA-15201924DA12@amazon.com> In-Reply-To: <78D87E6B-DBFE-46D9-B7FA-15201924DA12@amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: amazon.com; dkim=none (message not signed) header.d=none;amazon.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:67c:370:160:e425:92d3:f758:ab2b] x-ms-office365-filtering-correlation-id: c6e7fffe-1f7a-4509-bb5e-08d35e68c72d x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1648; 5:gfyPScsHpjC5fOqw8CN19Kz4HfRgE/shRpnjWo3Upb//ptH36iEMaVJNiKpgA8y5IGUAKz2mACXYYvIQoz2mRujnohwwmSFOzzjraYL/ci9EYqoFS01R1UDUAfXBSvZZTN+xYkvdNHg/0qzysbEUJg==; 24:bpwui8G3WrfL9qHQQicPFA2tYx8BXF4pGzLFr24wn7yE/2siQmfXlia9PgrLGGucUzp9EOa7ZcnXSSlaAGTPU7q4BFagfH1d5CNKc/qKckw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1648; 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)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1648; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1648; x-forefront-prvs: 0904004ECB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(6116002)(106116001)(102836003)(19300405004)(790700001)(86362001)(586003)(5008740100001)(1096002)(10090500001)(86612001)(76176999)(50986999)(2900100001)(8990500004)(189998001)(3280700002)(19580405001)(19580395003)(5001770100001)(3660700001)(99286002)(74316001)(1220700001)(10400500002)(2906002)(16236675004)(54356999)(15975445007)(77096005)(10290500002)(4326007)(5005710100001)(33656002)(87936001)(92566002)(5004730100002)(19617315012)(19625215002)(19609705001)(122556002)(76576001)(11100500001)(5003600100002)(2950100001)(81166005)(5002640100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1648; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB16451EB9061C26F639F2FD0AF59F0SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2016 22:14:09.9394 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1648 Archived-At: Cc: "scim@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 22:14:15 -0000 --_000_SN1PR0301MB16451EB9061C26F639F2FD0AF59F0SN1PR0301MB1645_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9yIHRoZSByZWNvcmQsIEnigJltIGludGVyZXN0ZWQuDQoNCkZyb206IHNjaW0gW21haWx0bzpz Y2ltLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIYXJkdCwgRGljaw0KU2VudDogVHVl c2RheSwgQXByaWwgNSwgMjAxNiA3OjI2IFBNDQpUbzogUGhpbCBIdW50IChJRE0pIDxwaGlsLmh1 bnRAb3JhY2xlLmNvbT4NCkNjOiBzY2ltQGlldGYub3JnOyBvYXV0aEBpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtzY2ltXSBTaW1wbGUgRmVkZXJhdGlvbiBEZXBsb3ltZW50DQoNCknigJltIHRhbGtp bmcgYWJvdXQgcmVtb3ZpbmcgbWFudWFsIHN0ZXBzIGluIHdoYXQgaGFwcGVucyB0b2RheSB3aGVy ZSBjb25maWd1cmluZyBhIFNhYVMgYXBwIGF0IGFuIElkUCAoc3VjaCBhcyBHb29nbGUsIEF6dXJl LCBQaW5nLCBPY3RhKSByZXF1aXJlcyBpcyBhIGJ1bmNoIG9mIGN1dHRpbmcgYW5kIHBhc3Rpbmcg b2YgYWNjZXNzIHRva2VucyAvIGtleXMgLyBjZXJ0cyBhbmQgZG9pbmcgYSBidW5jaCBvZiAgY29u ZmlnIHRoYXQgaXMgZXJyb3IgcHJvbmUgYW5kIHVuaXF1ZSBmb3IgZWFjaCByZWxhdGlvbnNoaXAu DQoNCkRvbuKAmXQgd2FudCB0byBzb2x2ZSBvbiB0aGUgdGhyZWFkIOKApiBsb29raW5nIHRvIHNl ZSBpZiB0aGVyZSBpcyBpbnRlcmVzdCENCg0KT24gNC81LzE2LCA3OjExIFBNLCBzb21lb25lIGNs YWltaW5nIHRvIGJlICJzY2ltIG9uIGJlaGFsZiBvZiBQaGlsIEh1bnQgKElETSkiIDxzY2ltLWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNjaW0tYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9m IHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+IHdyb3Rl Og0KDQpJcyB0aGUgaWRwIHRoZSBjZW50ZXIgb2YgYWxsIHRoaW5ncyBmb3IgdGhlc2UgdXNlcnM/ DQoNClVzdWFsbHkgeW91IGhhdmUgYSBwcm92aXNpb25pbmcgc3lzdGVtIHRoYXQgY29vcmRpbmF0 ZXMgc3RhdGUgYW5kIHVzZXMgdGhpbmdzIGxpa2Ugc2NpbSBjb25uZWN0b3JzIHRvIGRvIHRoaXMu DQoNCkFub3RoZXIgYXBwcm9hY2ggZnJvbSB0b2RheSB3b3VsZCBiZSB0byBwYXNzIGEgc2NpbSBl dmVudCB0byB0aGUgcmVtb3RlIHByb3ZpZGVyIHdoaWNoIHRoZW4gZGVjaWRlcyB3aGF0IG5lZWRz IHRvIGJlIGRvbmUgdG8gZmFjaWxpdGF0ZSB0aGUgdGhpbmdkIHlvdSBkZXNjcmliZS4NCg0KSW93 LiBFaXRoZXIgdGhlIGlkcCAoc2VuZGVyKSBvciB0aGUgc3AgKHJlY2VpdmVyKSBoYXZlIGEgcHJv dmlzaW9uaW5nIHN5c3RlbSB0byBkbyB0aGlzLg0KDQpUaGUgc29sdXRpb24gYW5kIHRoZSBzaW1w bGljaXR5IGRlcGVuZHMgb24gd2hlcmUgdGhlIGNvbnRyb2wgbmVlZHMgdG8gYmUuDQoNClBoaWwN Cg0KT24gQXByIDUsIDIwMTYsIGF0IDE4OjU5LCBIYXJkdCwgRGljayA8ZGlja0BhbWF6b24uY29t PG1haWx0bzpkaWNrQGFtYXpvbi5jb20+PiB3cm90ZToNClVzZSBjYXNlOiBBbiBhZG1pbiBmb3Ig YW4gb3JnYW5pemF0aW9uIHdvdWxkIGxpa2UgdG8gZW5hYmxlIGhlciB1c2VycyB0byBhY2Nlc3Mg YSBTYWFTIGFwcGxpY2F0aW9uIGF0IGhlciBJZFAuDQoNClVzZXIgZXhwZXJpZW5jZToNCg0KICAx LiAgQWRtaW4gYXV0aGVudGljYXRlcyB0byBJZFAgaW4gYnJvd3Nlcg0KICAyLiAgQWRtaW4gc2Vs ZWN0cyBTYWFTIGFwcCB0byBmZWRlcmF0ZSB3aXRoIGZyb20gbGlzdCBhdCBJZFANCiAgMy4gIElk UCBvcHRpb25hbGx5IHByZXNlbnRzIGNvbmZpZyBvcHRpb25zDQogIDQuICBJZFAgcmVkaXJlY3Rz IEFkbWluIHRvIFNhYVMgYXBwDQogIDUuICBBZG1pbiBhdXRoZW50aWNhdGVzIHRvIFNhYVMgYXBw DQogIDYuICBTYWFTIGFwcCBvcHRpb25hbGx5IGdhdGhlcnMgY29uZmlnIG9wdGlvbnMNCiAgNy4g IFNhYVMgYXBwIHJlZGlyZWN0cyBhZG1pbiB0byBJZFANCiAgOC4gIElkUCBjb25maXJtcyBzdWNj ZXNzZnVsIGZlZGVyYXRpb24gPT4gT0lEQyAvIFNBTUwgYW5kIFNDSU0gYXJlIG5vdyBjb25maWd1 cmVkIGFuZCB3b3JraW5nIGJldHdlZW4gSWRQIGFuZCBTYWFTIEFwcA0KV2hvIGVsc2UgaXMgaW50 ZXJlc3RlZCBpbiBzb2x2aW5nIHRoaXM/DQoNCklzIHRoZXJlIGludGVyZXN0IGluIHdvcmtpbmcg b24gdGhpcyBpbiBlaXRoZXIgU0NJTSBvciBPQVVUSCBXZ3M/DQoNCkFueSBvbmUgaW4gQkEgaW50 ZXJlc3RlZCBpbiBtZWV0aW5nIG9uIHRoaXMgdG9waWMgdGhpcyB3ZWVrPw0KDQrigJQgRGljaw0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNjaW0gbWFp bGluZyBsaXN0DQpzY2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltDQo= --_000_SN1PR0301MB16451EB9061C26F639F2FD0AF59F0SN1PR0301MB1645_ 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 IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBE ZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTY0NDc3NDI4OTsNCgltc28t bGlzdC10ZW1wbGF0ZS1pZHM6LTE3OTk0NDYwMDA7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5G b3IgdGhlIHJlY29yZCwgSeKAmW0gaW50ZXJlc3RlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBzY2ltIFttYWlsdG86 c2NpbS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5IYXJkdCwgRGljazxi cj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBcHJpbCA1LCAyMDE2IDc6MjYgUE08YnI+DQo8Yj5U bzo8L2I+IFBoaWwgSHVudCAoSURNKSAmbHQ7cGhpbC5odW50QG9yYWNsZS5jb20mZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBzY2ltQGlldGYub3JnOyBvYXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW3NjaW1dIFNpbXBsZSBGZWRlcmF0aW9uIERlcGxveW1lbnQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+SeKAmW0gdGFsa2luZyBhYm91dCByZW1vdmluZyBtYW51YWwg c3RlcHMgaW4gd2hhdCBoYXBwZW5zIHRvZGF5IHdoZXJlIGNvbmZpZ3VyaW5nIGEgU2FhUyBhcHAg YXQgYW4gSWRQIChzdWNoIGFzIEdvb2dsZSwgQXp1cmUsIFBpbmcsIE9jdGEpIHJlcXVpcmVzIGlz IGEgYnVuY2ggb2YNCiBjdXR0aW5nIGFuZCBwYXN0aW5nIG9mIGFjY2VzcyB0b2tlbnMgLyBrZXlz IC8gY2VydHMgYW5kIGRvaW5nIGEgYnVuY2ggb2YgJm5ic3A7Y29uZmlnIHRoYXQgaXMgZXJyb3Ig cHJvbmUgYW5kIHVuaXF1ZSBmb3IgZWFjaCByZWxhdGlvbnNoaXAuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkRvbuKA mXQgd2FudCB0byBzb2x2ZSBvbiB0aGUgdGhyZWFkIOKApiBsb29raW5nIHRvIHNlZSBpZiB0aGVy ZSBpcyBpbnRlcmVzdCE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+T24gNC81LzE2LCA3OjEx IFBNLCBzb21lb25lIGNsYWltaW5nIHRvIGJlICZxdW90O3NjaW0gb24gYmVoYWxmIG9mIFBoaWwg SHVudCAoSURNKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNjaW0tYm91bmNlc0BpZXRmLm9y ZyI+c2NpbS1ib3VuY2VzQGlldGYub3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxhIGhyZWY9Im1haWx0 bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21h cmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tcmlnaHQ6MGluIiBpZD0iTUFDX09VVExPT0tfQVRUUklC VVRJT05fQkxPQ0tRVU9URSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPklzIHRoZSBpZHAgdGhlIGNlbnRlciBv ZiBhbGwgdGhpbmdzIGZvciB0aGVzZSB1c2Vycz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VXN1YWxseSB5b3UgaGF2ZSBhIHByb3Zp c2lvbmluZyBzeXN0ZW0gdGhhdCBjb29yZGluYXRlcyBzdGF0ZSBhbmQgdXNlcyB0aGluZ3MgbGlr ZSBzY2ltIGNvbm5lY3RvcnMgdG8gZG8gdGhpcy4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+QW5vdGhlciBhcHByb2FjaCBm cm9tIHRvZGF5IHdvdWxkIGJlIHRvIHBhc3MgYSBzY2ltIGV2ZW50IHRvIHRoZSByZW1vdGUgcHJv dmlkZXIgd2hpY2ggdGhlbiBkZWNpZGVzIHdoYXQgbmVlZHMgdG8gYmUgZG9uZSB0byBmYWNpbGl0 YXRlIHRoZSB0aGluZ2QgeW91IGRlc2NyaWJlLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Jb3cuIEVpdGhlciB0aGUgaWRw IChzZW5kZXIpIG9yIHRoZSBzcCAocmVjZWl2ZXIpIGhhdmUgYSBwcm92aXNpb25pbmcgc3lzdGVt IHRvIGRvIHRoaXMuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk PSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPlRoZSBzb2x1dGlvbiBhbmQgdGhlIHNpbXBsaWNpdHkgZGVw ZW5kcyBvbiB3aGVyZSB0aGUgY29udHJvbCBuZWVkcyB0byBiZS4mbmJzcDs8YnI+DQo8YnI+DQpQ aGlsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPjxicj4NCk9uIEFwciA1LCAyMDE2LCBhdCAxODo1OSwgSGFyZHQsIERpY2sgJmx0Ozxh IGhyZWY9Im1haWx0bzpkaWNrQGFtYXpvbi5jb20iPmRpY2tAYW1hem9uLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VXNlIGNhc2U6IEFu IGFkbWluIGZvciBhbiBvcmdhbml6YXRpb24gd291bGQgbGlrZSB0byBlbmFibGUgaGVyIHVzZXJz IHRvIGFjY2VzcyBhIFNhYVMgYXBwbGljYXRpb24gYXQgaGVyIElkUC4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+VXNlciBleHBlcmllbmNlOiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29s b3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BZG1pbiBhdXRo ZW50aWNhdGVzIHRvIElkUCBpbiBicm93c2VyPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+QWRtaW4gc2VsZWN0cyBTYWFTIGFwcCB0byBmZWRlcmF0ZSB3aXRoIGZy b20gbGlzdCBhdCBJZFA8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5JZFAgb3B0aW9uYWxseSBwcmVzZW50cyBjb25maWcgb3B0aW9uczxvOnA+PC9vOnA+PC9zcGFu PjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZl bDEgbGZvMSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPklkUCByZWRpcmVjdHMgQWRtaW4gdG8gU2FhUyBh cHA8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29s b3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BZG1pbiBhdXRo ZW50aWNhdGVzIHRvIFNhYVMgYXBwPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+U2FhUyBhcHAgb3B0aW9uYWxseSBnYXRoZXJzIGNvbmZpZyBvcHRpb25zPG86cD48 L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNr O21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1s aXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U2FhUyBhcHAgcmVkaXJlY3Rz IGFkbWluIHRvIElkUDxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PklkUCBjb25maXJtcyBzdWNjZXNzZnVsIGZlZGVyYXRpb24gPSZndDsgT0lEQyAvIFNBTUwgYW5k IFNDSU0gYXJlIG5vdyBjb25maWd1cmVkIGFuZCB3b3JraW5nIGJldHdlZW4gSWRQIGFuZCBTYWFT IEFwcDxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC9vbD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPldobyBlbHNlIGlzIGludGVyZXN0ZWQg aW4gc29sdmluZyB0aGlzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5JcyB0aGVyZSBpbnRlcmVzdCBpbiB3b3JraW5n IG9uIHRoaXMgaW4gZWl0aGVyIFNDSU0gb3IgT0FVVEggV2dzPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Bbnkgb25l IGluIEJBIGludGVyZXN0ZWQgaW4gbWVldGluZyBvbiB0aGlzIHRvcGljIHRoaXMgd2Vlaz88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+4oCUIERpY2s8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCnNjaW0gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNjaW1A aWV0Zi5vcmciPnNjaW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NjaW08L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_SN1PR0301MB16451EB9061C26F639F2FD0AF59F0SN1PR0301MB1645_-- From nobody Wed Apr 6 16:18:05 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F51812D722; Wed, 6 Apr 2016 16:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CccI8X5q-Da; Wed, 6 Apr 2016 16:18:01 -0700 (PDT) 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 C7A8212D71A; Wed, 6 Apr 2016 16:18:01 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id n1so42714067pfn.2; Wed, 06 Apr 2016 16:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9mMm/knuzWl1aHW8qRBsl/5V8Ku248iEjj9rm/maTnM=; b=0jxvXXGz0xuV7fTV65ZKBI+4JvRiqd0abhJzskDmnGopkbC49Lua75aQVEjcVcJMhO 5LPYMKYFVHiSNueOJsmo2bTFounc1jsH442sUv8DFFOx+sioyaam40TEjEMD7Tx24eq8 C6hRjC0Re1FLdHf5uP+5N6ytLV2DjQZgYbw1lODi3+EVDiIGQG9Q6aQ5AcHS9UUfdqFK siBdGuGJkEqpDWfpYftCBodUdk/UKMu1p+3prvtySBKcPIFWflcmLHkzqwevuMSi4FcV iL7lsiGdJcfqKzMR/I1djJPuOPX5EzLyWu+6toNlAmiqI2pgjmjBVEyDOGFBfRZx3DyU IkWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9mMm/knuzWl1aHW8qRBsl/5V8Ku248iEjj9rm/maTnM=; b=JQWZXIrRz+o8XNM+GYniqpucosWsVQ/RQciuojWLN7gedxvuaCjm2hzbg8xqy6XbAj ftbr9HLwoqdQry+PSLQwhKUdIkxkQAH+xaMWfogLesmT73f8ab2QnprbDl9DvTBNTeug 4P/J+yw4HZAbwFzGAXW3Wydn9DwMjwOdu+so6tc8xzIjp+HEUD39BfwEBQhvWLTKXhBt ytuUbhfTI/+5ZfLBcjrDgAx3Xack/R/K917/e6AT2AMZuBVhdoe08Jzb0ae24aCjWwhp HTRCYS8vON9+TEAQkvntvrLF8U8NslH9VPSiWoYqjXZoKx+x2m4YhLGqI2yHQnYO7A5r UMUQ== X-Gm-Message-State: AD7BkJJ0NfCh4qMO0itVuKoZdRV4fQeHT3zo/5gZRgHCWpKnDQq5Rm16Q7CqaekD6ZYxXQ== X-Received: by 10.98.10.20 with SMTP id s20mr74466572pfi.109.1459984681409; Wed, 06 Apr 2016 16:18:01 -0700 (PDT) Received: from [172.16.80.127] (122x210x153x65.ap122.ftth.ucom.ne.jp. [122.210.153.65]) by smtp.gmail.com with ESMTPSA id 79sm7266084pfq.65.2016.04.06.16.18.00 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2016 16:18:00 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-A6B4F314-793C-4656-8371-87DB6865591F Mime-Version: 1.0 (1.0) From: Nov Matake X-Mailer: iPhone Mail (13E238) In-Reply-To: Date: Thu, 7 Apr 2016 08:17:58 +0900 Content-Transfer-Encoding: 7bit Message-Id: <63C77E0A-1FE3-4AD6-A03C-4E045C5DC607@gmail.com> References: <086477E4-5F4E-4C52-AC91-E26824A9FA7A@oracle.com> <78D87E6B-DBFE-46D9-B7FA-15201924DA12@amazon.com> To: Mike Jones Archived-At: Cc: "scim@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 23:18:04 -0000 --Apple-Mail-A6B4F314-793C-4656-8371-87DB6865591F Content-Type: text/plain; charset=cp932 Content-Transfer-Encoding: quoted-printable I'm interested in too. nov > On Apr 7, 2016, at 07:14, Mike Jones wrote: >=20 > For the record, I=81fm interested. > =20 > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Hardt, Dick > Sent: Tuesday, April 5, 2016 7:26 PM > To: Phil Hunt (IDM) > Cc: scim@ietf.org; oauth@ietf.org > Subject: Re: [scim] Simple Federation Deployment > =20 > I=81fm talking about removing manual steps in what happens today where con= figuring a SaaS app at an IdP (such as Google, Azure, Ping, Octa) requires i= s a bunch of cutting and pasting of access tokens / keys / certs and doing a= bunch of config that is error prone and unique for each relationship. > =20 > Don=81ft want to solve on the thread =81c looking to see if there is inter= est! > =20 > On 4/5/16, 7:11 PM, someone claiming to be "scim on behalf of Phil Hunt (I= DM)" wrote: > =20 > Is the idp the center of all things for these users? > =20 > Usually you have a provisioning system that coordinates state and uses thi= ngs like scim connectors to do this.=20 > =20 > Another approach from today would be to pass a scim event to the remote pr= ovider which then decides what needs to be done to facilitate the thingd you= describe.=20 > =20 > Iow. Either the idp (sender) or the sp (receiver) have a provisioning syst= em to do this.=20 > =20 > The solution and the simplicity depends on where the control needs to be.=20= >=20 > Phil >=20 > On Apr 5, 2016, at 18:59, Hardt, Dick wrote: >=20 > Use case: An admin for an organization would like to enable her users to a= ccess a SaaS application at her IdP.=20 > =20 > User experience:=20 > Admin authenticates to IdP in browser > Admin selects SaaS app to federate with from list at IdP > IdP optionally presents config options > IdP redirects Admin to SaaS app > Admin authenticates to SaaS app > SaaS app optionally gathers config options > SaaS app redirects admin to IdP > IdP confirms successful federation =3D> OIDC / SAML and SCIM are now confi= gured and working between IdP and SaaS App > Who else is interested in solving this? > =20 > Is there interest in working on this in either SCIM or OAUTH Wgs? > =20 > Any one in BA interested in meeting on this topic this week? > =20 > =81\ Dick > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-A6B4F314-793C-4656-8371-87DB6865591F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I'm interested in too.

nov

On Apr 7, 2016, at 07:14, Mike Jones <Michael.Jones@microsoft.com> wrote:

For the record, I=E2=80=99m interested.=

 =

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Hardt, Dick
Sent: Tuesday, April 5, 2016 7:26 PM
To: Phil Hunt (IDM) <phil.= hunt@oracle.com>
Cc: scim@ietf.org; oauth@ietf.org
Subject: Re: [scim] Simple Federation Deployment

 

I=E2=80=99m talking about removing manual= steps in what happens today where configuring a SaaS app at an IdP (such as= Google, Azure, Ping, Octa) requires is a bunch of cutting and pasting of access tokens / keys / certs and doing a bunch of &n= bsp;config that is error prone and unique for each relationship.<= /span>

 

Don=E2=80=99t want to solve on the thread= =E2=80=A6 looking to see if there is interest!

 

On 4/5/16, 7:11 PM, someone claiming to b= e "scim on behalf of Phil Hunt (IDM)" <scim-bounces@ietf.org on behalf of phil.hunt@oracle.com> wrote:<= o:p>

 

Is the idp the center of all things for t= hese users?

 

Usually you have a provisioning system th= at coordinates state and uses things like scim connectors to do this. <= o:p>

 

Another approach from today would be to p= ass a scim event to the remote provider which then decides what needs to be d= one to facilitate the thingd you describe. 

 

Iow. Either the idp (sender) or the sp (r= eceiver) have a provisioning system to do this. 

 

The solution and the simplicity depends o= n where the control needs to be. 

Phil


On Apr 5, 2016, at 18:59, Hardt, Dick <dick@amazon.com> wrote:

Use case: An admin for an organization wo= uld like to enable her users to access a SaaS application at her IdP. <= o:p>

 

User experience: <= /p>

  1. = Admin authenticates to IdP in browser
  2. = Admin selects SaaS app to federate with from list at IdP
  3. = IdP optionally presents config options
  4. = IdP redirects Admin to SaaS app
  5. = Admin authenticates to SaaS app
  6. = SaaS app optionally gathers config options
  7. = SaaS app redirects admin to IdP
  8. = IdP confirms successful federation =3D> OIDC / SAML and SCIM are now conf= igured and working between IdP and SaaS App

Who else is interested in solving this?

 

Is there interest in working on this in e= ither SCIM or OAUTH Wgs?

 

Any one in BA interested in meeting on th= is topic this week?

 

=E2=80=94 Dick

_________________________________________= ______
scim mailing list
scim@ietf.org
https://www.ietf.org/= mailman/listinfo/scim

____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-A6B4F314-793C-4656-8371-87DB6865591F-- From nobody Wed Apr 6 17:16:06 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDDA12D7F1; Wed, 6 Apr 2016 17:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.932 X-Spam-Level: X-Spam-Status: No, score=-106.932 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXuNfNhZ8HSA; Wed, 6 Apr 2016 17:15:55 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02B2312D7CB; Wed, 6 Apr 2016 17:15:53 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BDB2818000B; Wed, 6 Apr 2016 17:14:58 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160407001458.BDB2818000B@rfc-editor.org> Date: Wed, 6 Apr 2016 17:14:58 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, oauth@ietf.org, rfc-editor@rfc-editor.org Subject: [OAUTH-WG] RFC 7800 on Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 00:16:02 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7800 Title: Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) Author: M. Jones, J. Bradley, H. Tschofenig Status: Standards Track Stream: IETF Date: April 2016 Mailbox: mbj@microsoft.com, ve7jtb@ve7jtb.com, Hannes.Tschofenig@gmx.net Pages: 15 Characters: 33625 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-oauth-proof-of-possession-11.txt URL: https://www.rfc-editor.org/info/rfc7800 DOI: http://dx.doi.org/10.17487/RFC7800 This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. This document is a product of the Web Authorization Protocol Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Apr 6 18:35:22 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C49212D6D3; Wed, 6 Apr 2016 18:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLv1e_mfNyg8; Wed, 6 Apr 2016 18:35:08 -0700 (PDT) Received: from out4133-82.mail.aliyun.com (out4133-82.mail.aliyun.com [42.120.133.82]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD8D12D126; Wed, 6 Apr 2016 18:35:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1459992906; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=6RTEyvBI+UFHIHr08A9f41qlB/2cPAlJydDF25CJwVQ=; b=uy96gYepRgeStgSs1fFKE+5skj/neFwvSKApiCJM0QAFeGuhyo0vD+FuwNoek6QyksSUdcaqgCwEoBGGo1YBa/EH761qU+kmG3D47sFFZBCfe6FghZRP5YbggNbcMIGpzaY2aYBfjB2sl3GHZp3mJHnEeMaTwHvPvvsAmDVmHpc= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R191e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03296; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=6; SR=0; TI=SMTPD_----4gKK-ts_1459992890; Received: from 30.10.37.162(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.74.90) by smtp.aliyun-inc.com(127.0.0.1); Thu, 07 Apr 2016 09:34:54 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Thu, 07 Apr 2016 09:34:47 +0800 From: "Kepeng Li" To: "ace@ietf.org" Message-ID: Thread-Topic: Call for adoption for draft-wahlstroem-ace-cbor-web-token-00 Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3542866494_289664" Archived-At: Cc: cose@ietf.org, oauth@ietf.org Subject: [OAUTH-WG] Call for adoption for draft-wahlstroem-ace-cbor-web-token-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 01:35:12 -0000 > ´ËÓʼþʹÓà MIME ¸ñʽ¡£ÓÉÓÚÓʼþÔĶÁ³ÌÐò²»ÄÜʶ±ð ´Ë¸ñʽ£¬Òò´Ë£¬¿ÉÄÜÎÞ·¨Ê¶±ð¸ÃÓʼþµÄ·Ö²¿»ò²¿·ÖÄÚÈÝ¡£ --B_3542866494_289664 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: 7bit To: ACE WG Cc: OAuth and COSE WG Hello all, This note begins a Call For Adoption for draft-wahlstroem-ace-cbor-web-token-00 [1] to be adopted as an ACE working group item, and added in the charter. The call ends on April 22, 2016. Keep in mind that adoption of a document does not mean the document as-is is ready for publication. It is merely acceptance of the document as a starting point for what will be the final product of the ACE working group. The working group is free to make changes to the document according to the normal consensus process. Please reply on this thread with expressions of support or opposition, preferably with comments, regarding accepting this as a work item. Note that this email was also copied to OAuth and COSE WG, in order to get input from wider audience. Thanks, Kind Regards Kepeng (ACE co-chair) [1] https://datatracker.ietf.org/doc/draft-wahlstroem-ace-cbor-web-token/ --B_3542866494_289664 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable
To: ACE WG
Cc: OAuth and COSE WG

Hello all,= 

This note begins a Call For Adoption for draft-wahlstr=
oem-ace-cbor-web-token-00 [1]
to be adopted as an ACE working group ite= m, and added in the charter.
The call ends = on April 22, 2016.

Keep in mind that adoption of a docu=
ment does not mean the document
as-is is ready for publication. It is merely acceptance of the
document as a starting point for what will be the final product
of the ACE working group. The working group is free to make changes to
the document according to the normal consensus process.

Please reply on this thread with expressions of support or opposition,
preferably with comments, regarding accepting this as a work item.

Note that this email was also copied to OAuth an= d COSE WG, in order to 
get input from wider audience.

Thanks,

Kind Regards
Kepeng (ACE co-chair)


--B_3542866494_289664-- From nobody Wed Apr 6 19:15:01 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B246312D181 for ; Wed, 6 Apr 2016 19:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqtZ5E_Q9zpX for ; Wed, 6 Apr 2016 19:14:57 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0114.outbound.protection.outlook.com [207.46.100.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 790F012D0FC for ; Wed, 6 Apr 2016 19:14:57 -0700 (PDT) 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=LEsbl1wN6mT7w+ZKye+tyU+K9L0Eh5cawMM9KSOxs5Y=; b=E8xhVu6nhTsxJkY/ntSXd88u8A043SH5utjNZJIF9+gTNXgHROIRKTMZP5a/eolIixV/zPHLSE5XW8Pr6sP2HrL/PuQR/hHGyVFiZILIBXdbnj9GqH7mF8VQIc8f+C7ZwloTgUunL1y8HqbBb2HniMY6bUARpJxPKKwSky4T4DM= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) with Microsoft SMTP Server (TLS) id 15.1.447.15; Thu, 7 Apr 2016 02:14:55 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0447.028; Thu, 7 Apr 2016 02:14:55 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) is now RFC 7800 Thread-Index: AdGPc6wRmGi97ElZR+aVYnE0fRt7wg== Date: Thu, 7 Apr 2016 02:14:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:67c:370:136:4837:2cfb:1d37:c4e6] x-ms-office365-filtering-correlation-id: b80c6515-d8f1-4e49-3a4e-08d35e8a699b x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1645; 5:NfgyNy2oXXLqlLvSJO+o5eDiLlc8E2FKcX5jUczPHo1yqqWeBxP8tH4oSStpQuSM0gmU3Sj0eNsWjsDeFQe266IA/NyjvbEDY9rG4zyi2wDypqIGNIwbh3I+BO1b8GjHUT6D8ueQ1I0wSaAu9KLF+w==; 24:0Ekdj/p5JiAWB+5HBhmMr9XeIUd+bq8YAS8sF+Kacupeu5mcumFzfpkRAY/bZ2Gy6P1x4vTFVOYAFnPbU4mV46Qt43BZ/G7runK2goAzUDQ= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1645; 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)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1645; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1645; x-forefront-prvs: 0905A6B2C7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(107886002)(5640700001)(110136002)(5630700001)(6116002)(16236675004)(189998001)(81166005)(76576001)(102836003)(33656002)(586003)(5002640100001)(230783001)(790700001)(5004730100002)(19580395003)(86362001)(5003600100002)(19625215002)(86612001)(1730700002)(1096002)(1220700001)(99286002)(2351001)(19617315012)(74316001)(77096005)(229853001)(50986999)(92566002)(54356999)(10400500002)(15975445007)(10290500002)(19300405004)(5005710100001)(10090500001)(8990500004)(3280700002)(2900100001)(3660700001)(87936001)(2906002)(5008740100001)(450100001)(122556002)(2501003)(11100500001)(3826002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1645; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB1645BF9A28BDE76682F03F75F5900SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2016 02:14:55.7931 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1645 Archived-At: Subject: [OAUTH-WG] Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) is now RFC 7800 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 02:14:59 -0000 --_000_SN1PR0301MB1645BF9A28BDE76682F03F75F5900SN1PR0301MB1645_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) specificat= ion is now RFC 7800 - an IETF stand= ard. The abstract describes the specification as: This specification describes how to declare in a JSON Web Token (JWT) that = the presenter of the JWT possesses a particular proof-of-possession key and= how the recipient can cryptographically confirm proof of possession of the= key by the presenter. Being able to prove possession of a key is also some= times described as the presenter being a holder-of-key. Thanks to John Bradley, Hannes Tschofenig, and the OAuth working group for their work on thi= s specification. -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1561 and = as @selfissued. --_000_SN1PR0301MB1645BF9A28BDE76682F03F75F5900SN1PR0301MB1645_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The Proof-of-Possession Key Semantics for JSON Web T= okens (JWTs) specification is now RFC 7800 – an = IETF standard. The abstract describes the specification as:

 

This specification descri= bes how to declare in a JSON Web Token (JWT) that the presenter of the JWT = possesses a particular proof-of-possession key and how the recipient can cr= yptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is al= so sometimes described as the presenter being a holder-of-key.

 

Thanks to Jo= hn Bradley, Hannes Tschofenig, and the OAut= h working group for their work on this specification.

 

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

 

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

 

--_000_SN1PR0301MB1645BF9A28BDE76682F03F75F5900SN1PR0301MB1645_-- From nobody Wed Apr 6 19:59:30 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B5612D0B3; Wed, 6 Apr 2016 19:59:24 -0700 (PDT) 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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEx-GDOe3CsN; Wed, 6 Apr 2016 19:59:21 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0783.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:783]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCF2B12D146; Wed, 6 Apr 2016 19:59:19 -0700 (PDT) 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=Zs6LcTX9Vt64B/UEL13nRBUjxCzU4TpK7lta6o/N9Pw=; b=IDKKI+Bh2buwaNp6JCGGydjr3uSG5ETh1ZGVKYg2lKr0MUkSzb4huhNtrMyfcapcft0SefESBs//MQWhKbmjbrtGHbWY+S/FX8u3t40SCcKfAnt82hAh/PRbAp0SLlzjEC/d3GYWWGwbpJdiumpFrq1jX2YpbUoP6dFXhb2/HE4= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1648.namprd03.prod.outlook.com (10.162.130.142) with Microsoft SMTP Server (TLS) id 15.1.447.15; Thu, 7 Apr 2016 02:59:01 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0447.028; Thu, 7 Apr 2016 02:59:01 +0000 From: Mike Jones To: Kepeng Li , "ace@ietf.org" Thread-Topic: Call for adoption for draft-wahlstroem-ace-cbor-web-token-00 Thread-Index: AQHRkG299//iUC6O6EGSqoxS6svzQJ990fHA Date: Thu, 7 Apr 2016 02:59:00 +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: alibaba-inc.com; dkim=none (message not signed) header.d=none;alibaba-inc.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:67c:370:136:4837:2cfb:1d37:c4e6] x-ms-office365-filtering-correlation-id: 85549ad6-5837-4d0c-cb8f-08d35e909247 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1648; 5:eygIGK1N6ZBzd/CmPAW5rTBY8dNH4GWV8e5EwHqatWj8UvjiHysfWC8UV31MkAXVFu3eRqK7xaz3+X+Tvv/kjMIdp0mP1Mqb3Tkl/v/0sKiVk98sKsgqy7zCipkRXQ5RYf82WwlmatpQJYs8NVBF+A==; 24:/lCO/3qH8NIO2DCaa5ZS5UAk0W5eGfbeVapF6ni9Zql5Nm5GR1DheNuvIWVTUvzauHzecP63ceCaFomduKHiZVWWI0NHxDxZDqJZznz/hfk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1648; 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)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1648; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1648; x-forefront-prvs: 0905A6B2C7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(53754006)(71364002)(122556002)(19617315012)(19625215002)(77096005)(10290500002)(15975445007)(87936001)(5005710100001)(5004730100002)(92566002)(4326007)(2950100001)(33656002)(5003600100002)(5002640100001)(81166005)(11100500001)(1096002)(5008740100001)(2900100001)(86362001)(586003)(76176999)(76576001)(86612001)(50986999)(10090500001)(230783001)(790700001)(106116001)(19300405004)(6116002)(102836003)(8990500004)(1220700001)(10400500002)(74316001)(2501003)(3660700001)(99286002)(54356999)(16236675004)(2906002)(3280700002)(189998001)(164054004)(5001770100001)(19580405001)(19580395003)(3826002)(564094006); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1648; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB1645D4830C04B586FABEC296F5900SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2016 02:59:00.9820 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1648 Archived-At: Cc: "oauth@ietf.org" , "cose@ietf.org" Subject: Re: [OAUTH-WG] Call for adoption for draft-wahlstroem-ace-cbor-web-token-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 02:59:24 -0000 --_000_SN1PR0301MB1645D4830C04B586FABEC296F5900SN1PR0301MB1645_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 for adoption From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Kepeng Li Sent: Wednesday, April 6, 2016 10:35 PM To: ace@ietf.org Cc: Kathleen Moriarty ; Hannes Tschofenig= ; cose@ietf.org; oauth@ietf.org; Stephen Farrel= l Subject: [Ace] Call for adoption for draft-wahlstroem-ace-cbor-web-token-00 To: ACE WG Cc: OAuth and COSE WG Hello all, This note begins a Call For Adoption for draft-wahlstroem-ace-cbor-web-toke= n-00 [1] to be adopted as an ACE working group item, and added in the charter. The call ends on April 22, 2016. Keep in mind that adoption of a document does not mean the document as-is is ready for publication. It is merely acceptance of the document as a starting point for what will be the final product of the ACE working group. The working group is free to make changes to the document according to the normal consensus process. Please reply on this thread with expressions of support or opposition, preferably with comments, regarding accepting this as a work item. Note that this email was also copied to OAuth and COSE WG, in order to get input from wider audience. Thanks, Kind Regards Kepeng (ACE co-chair) [1] https://datatracker.ietf.org/doc/draft-wahlstroem-ace-cbor-web-token/ --_000_SN1PR0301MB1645D4830C04B586FABEC296F5900SN1PR0301MB1645_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1 for= adoption

 

From: Ace [mailto:ace-bounces@ietf.o= rg] On Behalf Of Kepeng Li
Sent: Wednesday, April 6, 2016 10:35 PM
To: ace@ietf.org
Cc: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>; Hann= es Tschofenig <hannes.tschofenig@gmx.net>; cose@ietf.org; oauth@ietf.= org; Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: [Ace] Call for adoption for draft-wahlstroem-ace-cbor-web-t= oken-00

 

To: ACE WG<= o:p>

Cc: OAuth and COSE WG

 

Hello all,

 
This note begins a Ca=
ll For Adoption for draft-wahlstroem-ace=
-cbor-web-token-00 [1]

to be adopted as an ACE working group item, and added in the ch= arter.

The call ends on April 22, 2016.

&n= bsp;

Keep in mind that adoption of a document does not mean the docum=
ent
as-is is ready for publication. It is merely acceptance of the
document as a starting point for what will be the final product<=
o:p>
of the ACE working group. The working group is free to make chan=
ges to
the document according to the normal consensus process.
 
Please reply on this thread with expressions of support or oppos=
ition,
preferably with comments, regarding accepting this as a work ite=
m.

&n= bsp;

Note that this email was also copied to OAuth and COSE WG, in o= rder to 

get input from wider audience.

 

Thanks,


 


Kind Regards


Kepeng (ACE co-chair)

&n= bsp;

&n= bsp;

--_000_SN1PR0301MB1645D4830C04B586FABEC296F5900SN1PR0301MB1645_-- From nobody Wed Apr 6 23:23:45 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6B712D555 for ; Wed, 6 Apr 2016 23:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nf6tOl3vwLer for ; Wed, 6 Apr 2016 23:23:40 -0700 (PDT) Received: from mail-lf0-x243.google.com (mail-lf0-x243.google.com [IPv6:2a00:1450:4010:c07::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADD3812D146 for ; Wed, 6 Apr 2016 23:23:37 -0700 (PDT) Received: by mail-lf0-x243.google.com with SMTP id p81so6496153lfb.3 for ; Wed, 06 Apr 2016 23:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=Fxm3q6ZsLkKiMN1LbOdvEWQ0m/gWoPrkABX+FmHaAOo=; b=s+Md9sgf2BGeTwSoBxseUYuH271NGb39+rPawsmLdQdoJgUqiuFnIX4uwhchGlOeo1 XVXx/oyCzanVmUE88iwPFwSuRbSee6ZIsJHNvcC3IE1xpV9+mktTJiXC+rZ31qv13B3r grCkqEFgx828M2mNpoYcldhHv0ldxN+atnxBUqqtHHRnAiMazzluL/WpDLoaDfatQ800 OYp+xtrJQKHncnWx3gSvA3fvAsr8jAHTZw3Gm2icWAMJ2uN3opZcRbh7dMmnL5wIL9Oy V3J+jnrH6crQeSW5ZdRFrimY/WT36OeWbdYZ9MFyeAYT9sWUKZG2PYEOmHkwMv4U1BIA 9bLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=Fxm3q6ZsLkKiMN1LbOdvEWQ0m/gWoPrkABX+FmHaAOo=; b=gp/hPmTfjzBCjBm5uou9KA9VDsMA+25jnV9CZiiIyuUCPqGmzSHmyHGRlwOh4CSJB5 Q4zfoEg+zCYV8/oT6aj6dQiWLzN8Nn/UZnkthfju1yaaiDMv5wfI1R2x9j36zKv3UvHY VIv1zrACaB0LPOW9hLgl03GJhjMvbxIFVELkTZDPCPMkPiwZDOX/5BwGlUE3THAY/viD oqwj+qUkto/vHo2y1EhhEHSIJOH3wVItkgDjHqQSBasSedf6Kv6/JeTpJ7YWgnDTm/8/ SJqvXDOvB4wLD7Sebn6ERD1Wui8+LghBQKq/KFc+/IT5zWf2zJ6/MlatrKNRVOq7e+VO njWQ== X-Gm-Message-State: AD7BkJKFiLltIGyutj40BSHINg0LJ5wV09TBzLl/1dl7wkfyu5p9nJEKNqhywjhHVdGZqg== X-Received: by 10.25.146.206 with SMTP id u197mr589171lfd.139.1460010215690; Wed, 06 Apr 2016 23:23:35 -0700 (PDT) Received: from ?IPv6:2a01:2b0:3041:30c0:dd3d:a4ee:eed:382e? ([2a01:2b0:3041:30c0:dd3d:a4ee:eed:382e]) by smtp.gmail.com with ESMTPSA id i204sm961979lfg.47.2016.04.06.23.23.34 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2016 23:23:34 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-9A9B9DEF-4435-42B5-9696-B5A1444E1B69 Content-Transfer-Encoding: 7bit From: Samuel Erdtman Mime-Version: 1.0 (1.0) Date: Thu, 7 Apr 2016 06:47:46 +0200 Message-Id: References: In-Reply-To: To: Kepeng Li X-Mailer: iPhone Mail (13E237) Archived-At: Cc: cose@ietf.org, "ace@ietf.org" , oauth@ietf.org Subject: Re: [OAUTH-WG] [Ace] Call for adoption for draft-wahlstroem-ace-cbor-web-token-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 06:23:41 -0000 --Apple-Mail-9A9B9DEF-4435-42B5-9696-B5A1444E1B69 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable +1 for adoption Sent from my iPhone > On 7 apr. 2016, at 03:34, Kepeng Li wrote: >=20 > To: ACE WG > Cc: OAuth and COSE WG >=20 > Hello all, >=20 > This note begins a Call For Adoption for draft-wahlstroem-ace-cbor-web-tok= en-00 [1] > to be adopted as an ACE working group item, and added in the charter. > The call ends on April 22, 2016. >=20 > Keep in mind that adoption of a document does not mean the document > as-is is ready for publication. It is merely acceptance of the > document as a starting point for what will be the final product > of the ACE working group. The working group is free to make changes to > the document according to the normal consensus process. >=20 > Please reply on this thread with expressions of support or opposition, > preferably with comments, regarding accepting this as a work item. >=20 > Note that this email was also copied to OAuth and COSE WG, in order to=20 > get input from wider audience. >=20 > Thanks, >=20 > Kind Regards > Kepeng (ACE co-chair) >=20 > [1] https://datatracker.ietf.org/doc/draft-wahlstroem-ace-cbor-web-token/ >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --Apple-Mail-9A9B9DEF-4435-42B5-9696-B5A1444E1B69 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1 for adoption

Sent from my iP= hone

On 7 apr. 2016, at 03:34, Kepeng Li <kepeng.lkp@alibaba-inc.com> wrote:
To: ACE WG
Cc: OAuth and COSE WG
Hello all,
= 

This note begins a Call For Adoption for draft-wahlstro=
em-ace-cbor-web-token-00 [1]
to be adopted as a= n ACE working group item, and added in the charter.
The call ends on April 22, 2016.
= 

Keep in mind that adopt=
ion of a document does not mean the document
as-is is ready for publication. It is merely acceptance of the
document as a starting point for what will be the final product
of the ACE working group. The working group is free to make changes to
the document according to the normal consensus process.

Please reply on this thread with expressions of support or opposition,
preferably with comments, regarding accepting this as a work item.

Note that thi= s email was also copied to OAuth and COSE WG, in order to 
=
get i= nput from wider audience.

= 
Thanks,

<= pre class=3D"wordwrap" style=3D"margin-top: 0px; margin-bottom: 0px; padding= : 0px; border: 0px; font-family: Courier, 'Courier New', monospace; font-siz= e: 12px; line-height: 18px; vertical-align: baseline; white-space: pre-wrap;= word-wrap: break-word;">Kind Regards
Kepeng (=
ACE co-chair)
____________________= ___________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/lis= tinfo/ace
= --Apple-Mail-9A9B9DEF-4435-42B5-9696-B5A1444E1B69-- From nobody Thu Apr 7 00:59:44 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E90A312D17B; Thu, 7 Apr 2016 00:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEUL095qein3; Thu, 7 Apr 2016 00:59:39 -0700 (PDT) Received: from smtpauth.rollernet.us (smtpauth.rollernet.us [IPv6:2607:fe70:0:3::d]) (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 53C9812D11E; Thu, 7 Apr 2016 00:59:39 -0700 (PDT) Received: from smtpauth.rollernet.us (localhost [127.0.0.1]) by smtpauth.rollernet.us (Postfix) with ESMTP id DC21B2800C38; Thu, 7 Apr 2016 00:59:31 -0700 (PDT) Received: from lingon.ladok.umu.se (lingon.ladok.umu.se [130.239.200.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpauth.rollernet.us (Postfix) with ESMTPSA; Thu, 7 Apr 2016 00:59:31 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Roland Hedberg In-Reply-To: <63C77E0A-1FE3-4AD6-A03C-4E045C5DC607@gmail.com> Date: Thu, 7 Apr 2016 09:59:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <086477E4-5F4E-4C52-AC91-E26824A9FA7A@oracle.com> <78D87E6B-DBFE-46D9-B7FA-15201924DA12@amazon.com> <63C77E0A-1FE3-4AD6-A03C-4E045C5DC607@gmail.com> To: Nov Matake X-Mailer: Apple Mail (2.3124) X-Rollernet-Abuse: Processed by Roller Network Mail Services. Contact abuse@rollernet.us to report violations. Abuse policy: http://www.rollernet.us/policy X-Rollernet-Submit: Submit ID 478d.57061363.94ed2.0 Archived-At: Cc: "scim@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 07:59:42 -0000 Count me in ! > 7 apr. 2016 kl. 01:17 skrev Nov Matake : >=20 > I'm interested in too. >=20 > nov >=20 > On Apr 7, 2016, at 07:14, Mike Jones = wrote: >=20 >> For the record, I=E2=80=99m interested. >> =20 >> From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Hardt, Dick >> Sent: Tuesday, April 5, 2016 7:26 PM >> To: Phil Hunt (IDM) >> Cc: scim@ietf.org; oauth@ietf.org >> Subject: Re: [scim] Simple Federation Deployment >> =20 >> I=E2=80=99m talking about removing manual steps in what happens today = where configuring a SaaS app at an IdP (such as Google, Azure, Ping, = Octa) requires is a bunch of cutting and pasting of access tokens / keys = / certs and doing a bunch of config that is error prone and unique for = each relationship. >> =20 >> Don=E2=80=99t want to solve on the thread =E2=80=A6 looking to see if = there is interest! >> =20 >> On 4/5/16, 7:11 PM, someone claiming to be "scim on behalf of Phil = Hunt (IDM)" = wrote: >> =20 >> Is the idp the center of all things for these users? >> =20 >> Usually you have a provisioning system that coordinates state and = uses things like scim connectors to do this.=20 >> =20 >> Another approach from today would be to pass a scim event to the = remote provider which then decides what needs to be done to facilitate = the thingd you describe.=20 >> =20 >> Iow. Either the idp (sender) or the sp (receiver) have a provisioning = system to do this.=20 >> =20 >> The solution and the simplicity depends on where the control needs to = be.=20 >>=20 >> Phil >>=20 >> On Apr 5, 2016, at 18:59, Hardt, Dick wrote: >>=20 >> Use case: An admin for an organization would like to enable her users = to access a SaaS application at her IdP.=20 >> =20 >> User experience:=20 >> =E2=80=A2 Admin authenticates to IdP in browser >> =E2=80=A2 Admin selects SaaS app to federate with from list at = IdP >> =E2=80=A2 IdP optionally presents config options >> =E2=80=A2 IdP redirects Admin to SaaS app >> =E2=80=A2 Admin authenticates to SaaS app >> =E2=80=A2 SaaS app optionally gathers config options >> =E2=80=A2 SaaS app redirects admin to IdP >> =E2=80=A2 IdP confirms successful federation =3D> OIDC / SAML = and SCIM are now configured and working between IdP and SaaS App >> Who else is interested in solving this? >> =20 >> Is there interest in working on this in either SCIM or OAUTH Wgs? >> =20 >> Any one in BA interested in meeting on this topic this week? >> =20 >> =E2=80=94 Dick >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Roland "Education is the path from cocky ignorance to miserable uncertainty.=E2=80= =9D - Mark Twain From nobody Thu Apr 7 03:39:35 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB22E12D0F7 for ; Thu, 7 Apr 2016 03:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trWep2lO9FQE for ; Thu, 7 Apr 2016 03:39:31 -0700 (PDT) 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 DFE1D12D0B6 for ; Thu, 7 Apr 2016 03:39:30 -0700 (PDT) Received: by mail-qg0-x233.google.com with SMTP id f105so35302972qge.2 for ; Thu, 07 Apr 2016 03:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=kDDMOaKCA9dDqlomN429qFe2CUr37nHNnThaJiDZgz0=; b=U0p0iHfAhMWik4JcNX9KVMLfuGWrClR0Hj5hxMVOa3H4o+yEZ/Q8+5wb8Dhmrg1Vxg J5VV6Z1nIgG24N5e3+0kIZ0yQLbHUlKwDtkEhXa2WBhgr59BR+jC8NhuvOxbr8TWc5+n dvnPpT/rKdWlEomzVmUTc1I1BVh+MzJSDlmlM0GyxXAhFgCWqoTfYBTMcA+piyf6h8L5 21+vEEx32FomMtjbOTU76dAAv3+Wb7PdVpUchKE4dmVDv/g+EAV5anNDrupRDRV7onT8 Fs+62yjuSGMwsfSNFBoydu0Qnf38Ai5Y/iEP0UzYO+UFjMBt/rHPZV6a2exKI7xYPzIc OOMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=kDDMOaKCA9dDqlomN429qFe2CUr37nHNnThaJiDZgz0=; b=fAY9A0vm/8YxsK2rac6AVPr9w552SdFciV4dzY6cNU6IUaXiFR0h73e1kAFGcR9j3d whNBpT9146BQFHoyzo5q7I/aLgGw7SmQ58+pIMJvtQUmcaS0KZLdoIVEGSLst3YcGYXR 3UrWbwbtCnyuYzzHD9WxExgEzmA/L1jybAfxYEFxLoNdKQez3GTB1nHACRMKBBlhFlaS WmmIvz4nMeRmtqT6MNMYqDN7H3MUk+MocIZpMKUQ8LnqKIWYgAnvF937lusxvTZBnj88 VEGUj0650htnLhZcM3PA6H3yvCGVutF9emsjCAvGv6dQ5710spaYALxEyj49MfRoCyE4 t+sg== X-Gm-Message-State: AD7BkJK0pFJR3BUaoV5vhhFD8VAdgqSsKf6p39OZILf+FJEg/NErURKx+XzCKUa4Xwu8OOGUG6TP709ZRQ/ffw== MIME-Version: 1.0 X-Received: by 10.140.165.205 with SMTP id l196mr2717159qhl.58.1460025569964; Thu, 07 Apr 2016 03:39:29 -0700 (PDT) Received: by 10.55.16.18 with HTTP; Thu, 7 Apr 2016 03:39:29 -0700 (PDT) In-Reply-To: References: <570546A1.8040509@gmx.net> <57055D2D.9000600@gmx.net> <5AD9C0D6-C3BA-421D-99F6-B98FA509ADC6@oracle.com> Date: Thu, 7 Apr 2016 07:39:29 -0300 Message-ID: From: Nat Sakimura To: Anthony Nadalin Content-Type: multipart/alternative; boundary=001a1134f04c761334052fe2b18d Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 10:39:34 -0000 --001a1134f04c761334052fe2b18d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Surprisingly ;-), I kind of agree with Tony. We need to hash out the requirements more fully. Nat 2016-04-06 17:16 GMT-03:00 Anthony Nadalin : > I don=E2=80=99t see anything in the document that allows multiple resourc= e servers > where the token can be used. Token Exchange allows delegation and > impersonation, so I have no idea of the semantics when I use both of thes= e > together > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Wednesday, April 6, 2016 1:13 PM > *To:* Anthony Nadalin > *Cc:* Phil Hunt (IDM) ; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Call for Adoption: Resource Indicators for > OAuth 2.0 > > > > Multiple resources are there now. > > I have no idea what "interaction with Token Exchange" means. Can you > please explain? > > > > On Wed, Apr 6, 2016 at 5:04 PM, Anthony Nadalin > wrote: > > I would like to see the multiple resources servers, interaction with Toke= n > Exchange resolved before this is adopted to see if this will actually sol= ve > the problems > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian > Campbell > *Sent:* Wednesday, April 6, 2016 12:52 PM > *To:* Phil Hunt (IDM) > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Call for Adoption: Resource Indicators for > OAuth 2.0 > > > > I support the adoption of this draft by the working group. > > I don't think an immediate WGLC was expected here. > > > > On Wed, Apr 6, 2016 at 4:06 PM, Phil Hunt (IDM) > wrote: > > With the process of immediate wglc I think we should review all documents > more thoroughly before adoption. > > As I said I support the work. > > Phil > > > > On Apr 6, 2016, at 16:02, Hannes Tschofenig > wrote: > > > > Phil, > > > > we have discussed this concept already for years. In fact, it dates bac= k > > to the days of the OAuth base specification and the security > > consideration section even talks about it. > > > > We have had the content of this in the PoP key distribution draft and w= e > > are now moving it into a separate document. > > > > I am not sure how much longer you want to discuss it. > > > > Ciao > > Hannes > > > > > >> On 04/06/2016 08:07 PM, Phil Hunt (IDM) wrote: > >> I would like to have more discussion before wg adoption. > >> > >> I support the work and am willing to help. > >> > >> Phil > >> > >>> On Apr 6, 2016, at 14:25, Hannes Tschofenig > wrote: > >>> > >>> Hi all, > >>> > >>> this is the call for adoption of 'Resource Indicators for OAuth 2.0', > see > >>> > http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/ > > >>> > >>> Please let us know by April 20th 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 Bueno= s > >>> Aires then you don't need to re-state your opinion, if you want. > >>> > >>> The feedback at the BA IETF meeting was the following: ~10 persons > >>> for accepting the document and 0 persons against. > >>> > >>> 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 --001a1134f04c761334052fe2b18d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Surprisingly ;-), I kind of agree with Tony.=C2=A0
We need to hash out the requirements more fully.=C2=A0

Nat

2016-04-06 17:16 GMT-03:00 Anthony Nadalin <tonynad@m= icrosoft.com>:

I don=E2=80=99t see anything in the document that a= llows multiple resource servers where the token can be used. Token Exchange= allows delegation and impersonation, so I have no idea of the semantics when I use both of these together

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= =C2=A0

From: Brian Campbell [mailto:bcampbell@pingiden= tity.com]
Sent: Wednesday, April 6, 2016 1:13 PM
To: Anthony Nadalin <tonynad@microsoft.com>
Cc: Phil Hunt (IDM) <phil.hunt@oracle.com>; oauth@ietf.org
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for O= Auth 2.0

=C2=A0

Multiple resources ar= e there now.

I have no idea what "interaction with Token Exc= hange" means. Can you please explain?

=C2=A0

On Wed, Apr 6, 2016 at 5:04 PM, Anthony Nadalin <= tonynad@microsof= t.com> wrote:

I would like to see the multiple resources servers,= interaction with Token Exchange resolved before this is adopted to see if this will actually solve the problems

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Wednesday, April 6, 2016 12:52 PM
To: Phil Hunt (IDM) <phil.hunt@oracle.com>
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for O= Auth 2.0

=C2=A0

I support the adoptio= n of this draft by the working group.

I don't think an immediate WGLC was expected her= e.

=C2=A0

On Wed, Apr 6, 2016 at 4:06 PM, Phil Hunt (IDM) <= phil.hunt@oracle.= com> wrote:

With the process of immediate wglc I think we should= review all documents more thoroughly before adoption.

As I said I support the work.

Phil


> On Apr 6, 2016, at 16:02, Hannes Tschofenig <hannes.tschofenig@gmx.net> = wrote:
>
> Phil,
>
> we have discussed this concept already for years. In fact, it dates ba= ck
> to the days of the OAuth base specification and the security
> consideration section even talks about it.
>
> We have had the content of this in the PoP key distribution draft and = we
> are now moving it into a separate document.
>
> I am not sure how much longer you want to discuss it.
>
> Ciao
> Hannes
>
>
>> On 04/06/2016 08:07 PM, Phil Hunt (IDM) wrote:
>> I would like to have more discussion before wg adoption.
>>
>> I support the work and am willing to help.
>>
>> Phil
>>
>>> On Apr 6, 2016, at 14:25, Hannes Tschofenig <hannes.tschofenig@gmx.net<= /a>> wrote:
>>>
>>> Hi all,
>>>
>>> this is the call for adoption of 'Resource Indicators for = OAuth 2.0', see
>>> http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
>>>
>>> Please let us know by April 20th whether you accept / object t= o 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 i= n Buenos
>>> Aires then you don't need to re-state your opinion, if you= want.
>>>
>>> The feedback at the BA IETF meeting was the following: ~10 per= sons
>>> for accepting the document and 0 persons against.
>>>
>>> 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

=C2=A0

=C2=A0


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




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundatio= n
http://nat.saki= mura.org/
@_nat_en
--001a1134f04c761334052fe2b18d-- From nobody Thu Apr 7 05:08:24 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54DD512D83D for ; Thu, 7 Apr 2016 05:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Hqw7MQwZKHP for ; Thu, 7 Apr 2016 05:08:18 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB81012D833 for ; Thu, 7 Apr 2016 05:08:12 -0700 (PDT) Received: from [190.136.21.26] (helo=[172.16.55.144]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84) (envelope-from ) id 1ao8jJ-0000eR-BB; Thu, 07 Apr 2016 14:08:10 +0200 Content-Type: multipart/alternative; boundary=Apple-Mail-FBD0DD27-71EC-47F5-AAF1-0441A1460FAA Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPad Mail (13E238) In-Reply-To: Date: Thu, 7 Apr 2016 09:08:05 -0300 Content-Transfer-Encoding: 7bit Message-Id: References: To: Mike Jones X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) is now RFC 7800 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 12:08:22 -0000 --Apple-Mail-FBD0DD27-71EC-47F5-AAF1-0441A1460FAA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Congratulations! And what an RFC number ;-) > Am 06.04.2016 um 23:14 schrieb Mike Jones : >=20 > The Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) specifica= tion is now RFC 7800 =E2=80=93 an IETF standard. The abstract describes the s= pecification as: > =20 > This specification describes how to declare in a JSON Web Token (JWT) that= the presenter of the JWT possesses a particular proof-of-possession key and= how the recipient can cryptographically confirm proof of possession of the k= ey by the presenter. Being able to prove possession of a key is also sometim= es described as the presenter being a holder-of-key. > =20 > Thanks to John Bradley, Hannes Tschofenig, and the OAuth working group for= their work on this specification. > =20 > -- Mike > =20 > P.S. This notice was also posted at http://self-issued.info/?p=3D1561 and= as @selfissued. > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-FBD0DD27-71EC-47F5-AAF1-0441A1460FAA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Congratulations! And what a= n RFC number ;-)

Am 06.04.2016 um 23:14 schrieb Mike Jones <= ;Michael.Jones@microsoft.com<= /a>>:

=

The Proof-of-Possession Key Semantics for JSON Web To= kens (JWTs) specification is now RFC 7800 =E2=80=93 an= IETF standard. The abstract describes the specification as:

 

This specification describ= es how to declare in a JSON Web Token (JWT) that the presenter of the JWT po= ssesses a particular proof-of-possession key and how the recipient can crypt= ographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is als= o sometimes described as the presenter being a holder-of-key.

 

Thanks to Joh= n Bradley, Hannes Tschofenig, and the OAuth= working group for their work on this specification.

 

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

 

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

 

____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-FBD0DD27-71EC-47F5-AAF1-0441A1460FAA-- From nobody Thu Apr 7 05:32:51 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A7E12D893 for ; Thu, 7 Apr 2016 05:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.852 X-Spam-Level: X-Spam-Status: No, score=-1.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvYT4ElM9j3X for ; Thu, 7 Apr 2016 05:32:47 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.43]) (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 706C012D88E for ; Thu, 7 Apr 2016 05:32:47 -0700 (PDT) Received: from [190.136.21.26] (helo=[172.16.55.144]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84) (envelope-from ) id 1ao974-000641-Oc; Thu, 07 Apr 2016 14:32:44 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPad Mail (13E238) In-Reply-To: <57055DE2.50201@aol.com> Date: Thu, 7 Apr 2016 09:32:25 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <570548D6.8010605@gmx.net> <57055DE2.50201@aol.com> To: George Fletcher X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 12:32:50 -0000 Hi all, as I already said in the meeting: I would very much prefer to have an extens= ion/update of RFC 6819 covering all "new" threats, including: - mix up - code injection aka copy and paste - open redirector at AS and client - potential other threats in the context of "dynamic" OAuth I also assume mitigations for (at least some of) the threats need to go into= an update of RFC 6749 as normative text. To give an example: if we agree on= using the state parameter at the token endpoint to mitigate code injection,= this MUST be part of the core spec (request description and security consod= erations). Otherwise, noone will even consider it. We should also use the opportunity to improve/enhance the text of the spec. I= n the course of the last years, we have learned a lot about ambiquities of t= he text and how different implementations utilize OAuth.=20 I think time is right to define scopes more precisely. As the discussions in= the last days proved again (at least for me), scope is not sufficiently def= ined to come up with interoperable implementations. Additionally, there seem= s to be a need to represent resource server locations (to not say identities= :-)) in this context. To bundle all changes in a version 2.1 would also make communication into th= e market much easier.=20 best regards, Torsten. > Am 06.04.2016 um 16:05 schrieb George Fletcher : >=20 > I'd definitely prefer a single solution document to many little ones that h= ave to be combined to actually build a secure solution. It's already getting= complex with the additional specs that have been added. >=20 > Additionally, I'm not against working on OAuth 2.1. >=20 > Thanks, > George >=20 >> On 4/6/16 2:06 PM, Phil Hunt (IDM) wrote: >> =20 >> Existing implementations are for the large part ok and do not need these m= itigations. >>=20 >> Only the new use cases we have been discussing (configure on the fly and m= ulti-as, etc) really need mitigation. >>=20 >> The updated by approach seems like a good way to address the new cases. >>=20 >> Phil >>=20 >>> On Apr 6, 2016, at 14:35, Hannes Tschofenig w= rote: >>>=20 >>> Hi all, >>>=20 >>> today we discussed the OAuth Authorization Server Mixup draft. We were >>> wondering what types of threats the document should find solutions for. >>>=20 >>> We discussed various document handling approaches including >>> * OAuth Mix-Up and Cut-and-Paste attacks documented in separate >>> solution documents >>> * combined solution document covering the OAuth Mix-Up and the >>> Cut-and-Paste attacks. >>>=20 >>> Barry pointed out that these documents could update the OAuth base >>> specification. >>>=20 >>> As a more radical change it was also suggested to revise RFC 6749 "OAuth= >>> 2.0 Authorization Framework" and RFC 6819 "OAuth 2.0 Threat Model and >>> Security Considerations". >>>=20 >>> Opening up the OAuth base specification obviously raises various other >>> questions about cleaning up parts that go far beyond the AS mix-up and >>> the cut-and-paste attacks. Other specifications, such as the Open >>> Redirector, could be folded into such a new specification. >>>=20 >>> Derek and I would appreciate your input on this topic before we make a >>> decision since it has significant impact on our work. >>>=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 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Apr 7 05:46:58 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF0A12D1B0 for ; Thu, 7 Apr 2016 05:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.232 X-Spam-Level: X-Spam-Status: No, score=-1.232 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdaAi3HMVco3 for ; Thu, 7 Apr 2016 05:46:55 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0779.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::779]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2D6412D0FB for ; Thu, 7 Apr 2016 05:46:54 -0700 (PDT) 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=ZQQH6o/ujK5NjwRheMapW7j0ut9KRKSHHQKXtGZIMPs=; b=llvqG/vqomfpBJRydCPwyj2ECWUm1ESW8lYlzKaAVU3ztIbLS8P9lydFimCGmZlDddlD3ZdelMPB9NGsYvoqpeAE76hCg2XguTtguxrNinMm7aXhvUH+peo8ruXaKfbaUropVRruPHVmrsI3MeyWXCel6kWDw6E4dLXRBkR2q38= 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.447.15; Thu, 7 Apr 2016 12:46:37 +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.0447.029; Thu, 7 Apr 2016 12:46:37 +0000 From: Anthony Nadalin To: Torsten Lodderstedt , George Fletcher Thread-Topic: [OAUTH-WG] OAuth 2.1 Thread-Index: AQHRkCrC9FL7Md1fqki7Njw+atUP2p99PcEAgAAQXwCAASSegIAAAjqQ Date: Thu, 7 Apr 2016 12:46:37 +0000 Message-ID: References: <570548D6.8010605@gmx.net> <57055DE2.50201@aol.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: lodderstedt.net; dkim=none (message not signed) header.d=none;lodderstedt.net; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [200.127.148.163] x-ms-office365-filtering-correlation-id: 648d2f08-5585-4f9c-ffdf-08d35ee2a8ce x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1234; 5:B/JEUGeQQC2byTmrFyukjJAntOCyl6x82do786ELOEnBwTa4R7R5xVuxajeRVOtDSmC7dBYJuV5fOdNUJtiVXo6pVD2LPwhvWITCndy70IDq2++H53XZESjuBc6VfqD/U0wGKbWJJpvD5bmiWFEWJw==; 24:i4JAtNE4ZOGcV90DiJPYprNMn8AhKGuX9sZs2yfrQccRHQMlMXzm8sMJT5FZVQGpTiQC8iOsWYqVJ0NRpfEsc5tyhrH3fZYtuP4cGlGyRBQ= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1234; 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)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BN3PR0301MB1234; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1234; x-forefront-prvs: 0905A6B2C7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(53754006)(13464003)(377454003)(10400500002)(19580395003)(19580405001)(33656002)(5005710100001)(2900100001)(2950100001)(92566002)(15975445007)(77096005)(1220700001)(2906002)(1096002)(106116001)(76576001)(99286002)(164054004)(10290500002)(3660700001)(66066001)(3280700002)(4326007)(5002640100001)(189998001)(3846002)(10090500001)(93886004)(575784001)(86612001)(5004730100002)(586003)(5008740100001)(6116002)(102836003)(5003600100002)(5001770100001)(11100500001)(122556002)(50986999)(81166005)(87936001)(86362001)(76176999)(54356999)(74316001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1234; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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: 07 Apr 2016 12:46:37.5098 (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] OAuth 2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 12:46:57 -0000 I don't belive that scopes should be defined more precisely as this opaquen= ess was a design feature, I'm not seeing the reason why scopes need to be d= efined, as these are application specific. -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten Loddersted= t Sent: Thursday, April 7, 2016 5:32 AM To: George Fletcher Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.1 Hi all, as I already said in the meeting: I would very much prefer to have an exten= sion/update of RFC 6819 covering all "new" threats, including: - mix up - code injection aka copy and paste - open redirector at AS and client - potential other threats in the context of "dynamic" OAuth I also assume mitigations for (at least some of) the threats need to go int= o an update of RFC 6749 as normative text. To give an example: if we agree = on using the state parameter at the token endpoint to mitigate code injecti= on, this MUST be part of the core spec (request description and security co= nsoderations). Otherwise, noone will even consider it. We should also use the opportunity to improve/enhance the text of the spec.= In the course of the last years, we have learned a lot about ambiquities o= f the text and how different implementations utilize OAuth.=20 I think time is right to define scopes more precisely. As the discussions i= n the last days proved again (at least for me), scope is not sufficiently d= efined to come up with interoperable implementations. Additionally, there s= eems to be a need to represent resource server locations (to not say identi= ties :-)) in this context. To bundle all changes in a version 2.1 would also make communication into t= he market much easier.=20 best regards, Torsten. > Am 06.04.2016 um 16:05 schrieb George Fletcher : >=20 > I'd definitely prefer a single solution document to many little ones that= have to be combined to actually build a secure solution. It's already gett= ing complex with the additional specs that have been added. >=20 > Additionally, I'm not against working on OAuth 2.1. >=20 > Thanks, > George >=20 >> On 4/6/16 2:06 PM, Phil Hunt (IDM) wrote: >> =20 >> Existing implementations are for the large part ok and do not need these= mitigations. >>=20 >> Only the new use cases we have been discussing (configure on the fly and= multi-as, etc) really need mitigation. >>=20 >> The updated by approach seems like a good way to address the new cases. >>=20 >> Phil >>=20 >>> On Apr 6, 2016, at 14:35, Hannes Tschofenig = wrote: >>>=20 >>> Hi all, >>>=20 >>> today we discussed the OAuth Authorization Server Mixup draft. We=20 >>> were wondering what types of threats the document should find solutions= for. >>>=20 >>> We discussed various document handling approaches including >>> * OAuth Mix-Up and Cut-and-Paste attacks documented in separate=20 >>> solution documents >>> * combined solution document covering the OAuth Mix-Up and the=20 >>> Cut-and-Paste attacks. >>>=20 >>> Barry pointed out that these documents could update the OAuth base=20 >>> specification. >>>=20 >>> As a more radical change it was also suggested to revise RFC 6749=20 >>> "OAuth >>> 2.0 Authorization Framework" and RFC 6819 "OAuth 2.0 Threat Model=20 >>> and Security Considerations". >>>=20 >>> Opening up the OAuth base specification obviously raises various=20 >>> other questions about cleaning up parts that go far beyond the AS=20 >>> mix-up and the cut-and-paste attacks. Other specifications, such as=20 >>> the Open Redirector, could be folded into such a new specification. >>>=20 >>> Derek and I would appreciate your input on this topic before we make=20 >>> a decision since it has significant impact on our work. >>>=20 >>> Ciao >>> Hannes & Derek >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww >>> .ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40micr >>> osoft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2 >>> d7cd011db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww. >> ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40micros >> oft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7c >> d011db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.i > etf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40microsof > t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd01 > 1db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d _______________________________________________ OAuth mailing list OAuth@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40microsoft.com%= 7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd011db47%7c1&s= data=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d From nobody Thu Apr 7 09:05:03 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A559712D0B1 for ; Thu, 7 Apr 2016 09:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6Mfg0jpf5Wl for ; Thu, 7 Apr 2016 09:05:00 -0700 (PDT) Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.189.228]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB46712D1B4 for ; Thu, 7 Apr 2016 09:04:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1460045090; x=1491581090; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=2mH2rvQ2jha4xI2gg85B+6B47cQl1YjAyUl4hMtIFjM=; b=BbGUS/0KoInbGY3P1mWXI96Yaf2tTvpLF6LV50I5UN8+jtThbeeUdx3G Cnu1svuw10Z4zmPp5yePYKTanfHk9hWIYeTYD89M5tBPAoHKibQaIJ4vY 84j7x9bcrUpa2K7Ri6VNFN9sTS4gyhiiT90sSFqqRgZgBd1L7lfZShaM3 4=; X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208";a="472230084" Received: from sea19-co-svc-lb5-vlan2.sea.amazon.com (HELO email-inbound-relay-71004.iad55.amazon.com) ([10.47.22.162]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Apr 2016 16:04:47 +0000 Received: from ex10-hub-7002.ant.amazon.com (iad1-ws-svc-lb91-vlan2.amazon.com [10.0.103.146]) by email-inbound-relay-71004.iad55.amazon.com (8.14.7/8.14.7) with ESMTP id u37G4TN1013818 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Apr 2016 16:04:44 GMT Received: from EX13D03UWA003.ant.amazon.com (10.43.160.39) by ex10-hub-7002.ant.amazon.com (10.43.110.153) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 7 Apr 2016 09:04:24 -0700 Received: from EX13D03UWA001.ant.amazon.com (10.43.160.141) by EX13D03UWA003.ant.amazon.com (10.43.160.39) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 7 Apr 2016 16:04:23 +0000 Received: from EX13D03UWA001.ant.amazon.com ([10.43.160.141]) by EX13D03UWA001.ant.amazon.com ([10.43.160.141]) with mapi id 15.00.1104.000; Thu, 7 Apr 2016 16:04:23 +0000 From: "Hardt, Dick" To: Hannes Tschofenig Thread-Topic: dinner Thursday night Thread-Index: AQHRkOcmfsPwwLsyyUqx5pFvpUN3Kg== Date: Thu, 7 Apr 2016 16:04:22 +0000 Message-ID: <3C8A6B97-27B6-4588-84F7-F7143E8C11F1@amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.160.28] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Precedence: Bulk Archived-At: Cc: "oauth@ietf.org" Subject: [OAUTH-WG] dinner Thursday night X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 16:05:01 -0000 Q29uZmlybWluZyB3ZSBhcmUgc3RpbGwgZ2F0aGVyaW5nIGZvciBkaW5uZXIgdG9uaWdodCAoVGh1 cnNkYXkpIGFuZCB3b25kZXJpbmcgd2hlbiAvIHdoZXJlIHdlIHdpbGwgbWVldC4NCg0KDQoNCuKA lCBEaWNrDQo= From nobody Thu Apr 7 09:29:17 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFAB212D0C6 for ; Thu, 7 Apr 2016 09:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V17E7YbmAUxv for ; Thu, 7 Apr 2016 09:29:13 -0700 (PDT) Received: from mail-lb0-x241.google.com (mail-lb0-x241.google.com [IPv6:2a00:1450:4010:c04::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9293D12D0B8 for ; Thu, 7 Apr 2016 09:29:12 -0700 (PDT) Received: by mail-lb0-x241.google.com with SMTP id vk4so6832229lbb.1 for ; Thu, 07 Apr 2016 09:29:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=WaN9FpBPeiV41Nt4/g23TXe3WX6urYCd0YPL4wHiLKY=; b=IPuZ1QqXqRvdv9vT3JvCpovVBfKTtSxphzGyeqNN7HgtTDD3vEbxNNMEMe30pL/tqr NFAXob/ezX29GR6RBmChDkDvk5X9rrS6Fu1CYkT10IQlLheB+J853gV0pgEE8NACk/Vv buiM+/pEpprC4BS1zW8EaJQRewnatAku2Zs5JyBbBv3M41ZCRn0s9+MCI9vhay6P7nWt ci+aYO+AtUsz0V4Jt/auDEwSKjCy2WywkS+NmznftE09baOvrVBSSJCXKIduVKBGXgVp rN8hP9t6Yc6jJN+8uQUK/tXdXvBxNAB8w1/Hjk7Zhv5WjubxrzS/rEyS4neiI9bWpZPP k5Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=WaN9FpBPeiV41Nt4/g23TXe3WX6urYCd0YPL4wHiLKY=; b=QNrd5ZBrvZEMMmPPMg9UXnGgHX+Knu6JpG+WdYK6ZP2G31GMmTXQTMtLFlMP4b25vx pqwCCMuhpZ0fkpSO5otlRmkDyBriu5RGlaDVoVFv56YOlqyGr1wZk/dgt5chalSeETWt RLVpdVt/J3vp6GBhSM+gJsDTPwokdOojIaNfH8ewLHolTi1cUiHsRAwzqTL7FMWF0sLp XuZ/bEOEnyoT9YlUZGP/466EiGWJfgCpb4btNTaAM41W9kGPwOprpkSBENtM4ApJtUl7 i8oXLIkkCq68YtPoFK6PDOAg9w1VLKiM5s2RM1RjkfPlT2tTPIO5RZEryobg2ldtSmIv /w7A== X-Gm-Message-State: AD7BkJJi9dc+UeGB/igANayA+775JWZRP32BqvUftC0UUXM06joa/zt5YIUD0cyE+UnThQ== X-Received: by 10.112.141.197 with SMTP id rq5mr1741932lbb.5.1460046550702; Thu, 07 Apr 2016 09:29:10 -0700 (PDT) Received: from [10.0.1.5] (c-14d471d5.02-430-7570702.cust.bredbandsbolaget.se. [213.113.212.20]) by smtp.gmail.com with ESMTPSA id k190sm1352094lfb.20.2016.04.07.09.29.09 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 09:29:10 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable From: Samuel Erdtman Mime-Version: 1.0 (1.0) Date: Thu, 7 Apr 2016 17:47:51 +0200 Message-Id: <7A8E4B64-4741-4A54-84D6-B887690F77B5@erdtman.se> References: <570548D6.8010605@gmx.net> <57055DE2.50201@aol.com> In-Reply-To: To: Anthony Nadalin X-Mailer: iPhone Mail (13E237) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 16:29:16 -0000 +1 on a 2.1 version -1 on defining scopes more precisely in 2.1 Sent from my iPhone > On 7 apr. 2016, at 14:46, Anthony Nadalin wrote: >=20 > I don't belive that scopes should be defined more precisely as this opaque= ness was a design feature, I'm not seeing the reason why scopes need to be d= efined, as these are application specific. >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten Lodderste= dt > Sent: Thursday, April 7, 2016 5:32 AM > To: George Fletcher > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.1 >=20 > Hi all, >=20 > as I already said in the meeting: I would very much prefer to have an exte= nsion/update of RFC 6819 covering all "new" threats, including: > - mix up > - code injection aka copy and paste > - open redirector at AS and client > - potential other threats in the context of "dynamic" OAuth >=20 > I also assume mitigations for (at least some of) the threats need to go in= to an update of RFC 6749 as normative text. To give an example: if we agree o= n using the state parameter at the token endpoint to mitigate code injection= , this MUST be part of the core spec (request description and security conso= derations). Otherwise, noone will even consider it. >=20 > We should also use the opportunity to improve/enhance the text of the spec= . In the course of the last years, we have learned a lot about ambiquities o= f the text and how different implementations utilize OAuth.=20 >=20 > I think time is right to define scopes more precisely. As the discussions i= n the last days proved again (at least for me), scope is not sufficiently de= fined to come up with interoperable implementations. Additionally, there see= ms to be a need to represent resource server locations (to not say identitie= s :-)) in this context. >=20 > To bundle all changes in a version 2.1 would also make communication into t= he market much easier.=20 >=20 > best regards, > Torsten. >=20 >> Am 06.04.2016 um 16:05 schrieb George Fletcher : >>=20 >> I'd definitely prefer a single solution document to many little ones that= have to be combined to actually build a secure solution. It's already getti= ng complex with the additional specs that have been added. >>=20 >> Additionally, I'm not against working on OAuth 2.1. >>=20 >> Thanks, >> George >>=20 >>> On 4/6/16 2:06 PM, Phil Hunt (IDM) wrote: >>>=20 >>> Existing implementations are for the large part ok and do not need these= mitigations. >>>=20 >>> Only the new use cases we have been discussing (configure on the fly and= multi-as, etc) really need mitigation. >>>=20 >>> The updated by approach seems like a good way to address the new cases. >>>=20 >>> Phil >>>=20 >>>> On Apr 6, 2016, at 14:35, Hannes Tschofenig = wrote: >>>>=20 >>>> Hi all, >>>>=20 >>>> today we discussed the OAuth Authorization Server Mixup draft. We=20 >>>> were wondering what types of threats the document should find solutions= for. >>>>=20 >>>> We discussed various document handling approaches including >>>> * OAuth Mix-Up and Cut-and-Paste attacks documented in separate=20 >>>> solution documents >>>> * combined solution document covering the OAuth Mix-Up and the=20 >>>> Cut-and-Paste attacks. >>>>=20 >>>> Barry pointed out that these documents could update the OAuth base=20 >>>> specification. >>>>=20 >>>> As a more radical change it was also suggested to revise RFC 6749=20 >>>> "OAuth >>>> 2.0 Authorization Framework" and RFC 6819 "OAuth 2.0 Threat Model=20 >>>> and Security Considerations". >>>>=20 >>>> Opening up the OAuth base specification obviously raises various=20 >>>> other questions about cleaning up parts that go far beyond the AS=20 >>>> mix-up and the cut-and-paste attacks. Other specifications, such as=20 >>>> the Open Redirector, could be folded into such a new specification. >>>>=20 >>>> Derek and I would appreciate your input on this topic before we make=20= >>>> a decision since it has significant impact on our work. >>>>=20 >>>> Ciao >>>> Hannes & Derek >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww >>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40micr >>>> osoft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2 >>>> d7cd011db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww. >>> ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40micros >>> oft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7c >>> d011db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.i >> etf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40microsof >> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd01 >> 1db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.iet= f.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40microsoft.com%= 7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd011db47%7c1&sd= ata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Apr 7 09:38:37 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E1612D11D for ; Thu, 7 Apr 2016 09:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OB6XOzdI13Y5 for ; Thu, 7 Apr 2016 09:38:33 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0733.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:733]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EC0A12D1E1 for ; Thu, 7 Apr 2016 09:38:33 -0700 (PDT) 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=WhqFbewQ3wzoLsVOPXDW0E3JSJrlZ3l8prhTylvD+ZE=; b=AS91fa9SDlLDP2v9PHSeqQjuwV/mMLXNqHqOFaw27yXhvZDkJT/alxARMl2wS1NNgTM2wT+Fs/lBz3tHSuIi4XHKPdn1WfmGRwJjBzJSGvJPXcc3ViKBicvDgsr2IU4yZ2ADyjYTwRC4Rv8ecG6oigKtopGTpbMnXEPcZrBrieQ= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by BY1PR0301MB1238.namprd03.prod.outlook.com (10.161.203.22) with Microsoft SMTP Server (TLS) id 15.1.453.26; Thu, 7 Apr 2016 16:38:15 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0447.028; Thu, 7 Apr 2016 16:38:15 +0000 From: Mike Jones To: Samuel Erdtman , Anthony Nadalin Thread-Topic: [OAUTH-WG] OAuth 2.1 Thread-Index: AQHRkCrDP1Jnm0oCX0OWdyvM+93ryZ99PcEAgAAQXwCAASSegIAAA/iAgAAyo4CAAAvR0A== Date: Thu, 7 Apr 2016 16:38:15 +0000 Message-ID: References: <570548D6.8010605@gmx.net> <57055DE2.50201@aol.com> <7A8E4B64-4741-4A54-84D6-B887690F77B5@erdtman.se> In-Reply-To: <7A8E4B64-4741-4A54-84D6-B887690F77B5@erdtman.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: erdtman.se; dkim=none (message not signed) header.d=none;erdtman.se; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [31.133.139.105] x-ms-office365-filtering-correlation-id: 7dc66e2f-7dc4-4e73-d90c-08d35f0304a0 x-microsoft-exchange-diagnostics: 1; BY1PR0301MB1238; 5:5I1544mn0+Of0glP3DGGpBq9+0DiySUxw1LXTWP2wCCOD7carAappwcRX7stIh+M0rmyxgMODeORPcb1frTWvWvUNxKVVcSvo5UQhQIB32Q7V41UmcVHYGgHwW1mkw4hnlnR4+Qg3etYDa4B+ZZc4w==; 24:UeK2SAhWQB5hXnPNtg/xtoTb/7bANN6DdLen+KdWZGL4LTQrzs7C1ApcXcC/3+B+EQ/8jajzziqDvvj+d5Rwwq0sY5rIPLLWPWFVcMokdEQ= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB1238; 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)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BY1PR0301MB1238; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0301MB1238; x-forefront-prvs: 0905A6B2C7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(53754006)(93886004)(99286002)(92566002)(2561002)(2421001)(189998001)(106116001)(3660700001)(76576001)(3280700002)(122556002)(2906002)(19580405001)(5003630100001)(5001770100001)(5002640100001)(5003600100002)(11100500001)(86362001)(575784001)(33656002)(66066001)(15975445007)(5004730100002)(77096005)(164054004)(586003)(74316001)(2950100001)(4326007)(10400500002)(4001450100002)(10090500001)(86612001)(6116002)(19580395003)(1096002)(3846002)(1220700001)(102836003)(2900100001)(5005710100001)(10290500002)(87936001)(5008740100001)(81166005)(50986999)(54356999)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB1238; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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: 07 Apr 2016 16:38:15.5000 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0301MB1238 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 16:38:36 -0000 I am strongly against creating a 2.1 spec until we have at least a year of = deployment experience with the contents we're adding to 2.0, so as not to f= ragment the OAuth marketplace. I think we should: 1. Continue working on new security mitigations in new drafts (such as mix= -up-mitigation, etc.) that add features to use with 2.0 2. Continue working on PoP specs (such as pop-key-distribution, etc.) that= add features to use with 2.0 3. Continue working on other new specs (such as discovery, resource-indica= tors, etc.) that add features to use with 2.0 4. Learn from deployment experience with all of them 5. Iterate if the deployment experience tells us that we need to Only after we believe we have all the features right and we know that they = work together well should we consider creating a 2.1. If we rush to a 2.1 = and get it wrong, we'll lose developers' trust and we'll never get it back. -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Samuel Erdtman Sent: Thursday, April 7, 2016 12:48 PM To: Anthony Nadalin Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.1 +1 on a 2.1 version -1 on defining scopes more precisely in 2.1 Sent from my iPhone > On 7 apr. 2016, at 14:46, Anthony Nadalin wrote: >=20 > I don't belive that scopes should be defined more precisely as this opaqu= eness was a design feature, I'm not seeing the reason why scopes need to be= defined, as these are application specific. >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten=20 > Lodderstedt > Sent: Thursday, April 7, 2016 5:32 AM > To: George Fletcher > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.1 >=20 > Hi all, >=20 > as I already said in the meeting: I would very much prefer to have an ext= ension/update of RFC 6819 covering all "new" threats, including: > - mix up > - code injection aka copy and paste > - open redirector at AS and client > - potential other threats in the context of "dynamic" OAuth >=20 > I also assume mitigations for (at least some of) the threats need to go i= nto an update of RFC 6749 as normative text. To give an example: if we agre= e on using the state parameter at the token endpoint to mitigate code injec= tion, this MUST be part of the core spec (request description and security = consoderations). Otherwise, noone will even consider it. >=20 > We should also use the opportunity to improve/enhance the text of the spe= c. In the course of the last years, we have learned a lot about ambiquities= of the text and how different implementations utilize OAuth.=20 >=20 > I think time is right to define scopes more precisely. As the discussions= in the last days proved again (at least for me), scope is not sufficiently= defined to come up with interoperable implementations. Additionally, there= seems to be a need to represent resource server locations (to not say iden= tities :-)) in this context. >=20 > To bundle all changes in a version 2.1 would also make communication into= the market much easier.=20 >=20 > best regards, > Torsten. >=20 >> Am 06.04.2016 um 16:05 schrieb George Fletcher : >>=20 >> I'd definitely prefer a single solution document to many little ones tha= t have to be combined to actually build a secure solution. It's already get= ting complex with the additional specs that have been added. >>=20 >> Additionally, I'm not against working on OAuth 2.1. >>=20 >> Thanks, >> George >>=20 >>> On 4/6/16 2:06 PM, Phil Hunt (IDM) wrote: >>>=20 >>> Existing implementations are for the large part ok and do not need thes= e mitigations. >>>=20 >>> Only the new use cases we have been discussing (configure on the fly an= d multi-as, etc) really need mitigation. >>>=20 >>> The updated by approach seems like a good way to address the new cases. >>>=20 >>> Phil >>>=20 >>>> On Apr 6, 2016, at 14:35, Hannes Tschofenig wrote: >>>>=20 >>>> Hi all, >>>>=20 >>>> today we discussed the OAuth Authorization Server Mixup draft. We=20 >>>> were wondering what types of threats the document should find solution= s for. >>>>=20 >>>> We discussed various document handling approaches including >>>> * OAuth Mix-Up and Cut-and-Paste attacks documented in separate=20 >>>> solution documents >>>> * combined solution document covering the OAuth Mix-Up and the=20 >>>> Cut-and-Paste attacks. >>>>=20 >>>> Barry pointed out that these documents could update the OAuth base=20 >>>> specification. >>>>=20 >>>> As a more radical change it was also suggested to revise RFC 6749=20 >>>> "OAuth >>>> 2.0 Authorization Framework" and RFC 6819 "OAuth 2.0 Threat Model=20 >>>> and Security Considerations". >>>>=20 >>>> Opening up the OAuth base specification obviously raises various=20 >>>> other questions about cleaning up parts that go far beyond the AS=20 >>>> mix-up and the cut-and-paste attacks. Other specifications, such as=20 >>>> the Open Redirector, could be folded into such a new specification. >>>>=20 >>>> Derek and I would appreciate your input on this topic before we=20 >>>> make a decision since it has significant impact on our work. >>>>=20 >>>> Ciao >>>> Hannes & Derek >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fww >>>> w=20 >>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40mic >>>> r >>>> osoft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab >>>> 2=20 >>>> d7cd011db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3 >>>> d >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww. >>> ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40micro >>> s=20 >>> oft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7 >>> c d011db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww. >> i=20 >> etf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40microso >> f >> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd0 >> 1 1db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.i > etf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40microsof > t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd01 > 1db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Apr 7 09:41:13 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6051612D1B8 for ; Thu, 7 Apr 2016 09:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPlutdokFrwd for ; Thu, 7 Apr 2016 09:41:07 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::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 B3EE112D0B8 for ; Thu, 7 Apr 2016 09:41:07 -0700 (PDT) Received: by mail-ig0-x22e.google.com with SMTP id gy3so17572541igb.1 for ; Thu, 07 Apr 2016 09:41:07 -0700 (PDT) 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; bh=G78LrJd3BzLZNYh6/WaZYLNiR0eTkBZit948u2K/uys=; b=rj/jOsp3jw/mc+hufxYqO03X/+QkfI2L5RHxOvw+//v1mB5iJpRwtXhkL6xtL79mAe g7JT6oTGEwPWkAqA2uJcOVxoVzBXnm9tA47Z79Hiq/e7WdOk1cufnr+MdbYdUtbRkruv yw11UaLi1bhTqghYh+XcYRggiYQpkvoJzVC2zv6HShAQpWs+LqkQXxQzvOmnsSYBN7LO bfh14gb78pWCnicvsMdFDWI/Y1vG4so7t7+BhtsE4Kd2L4Gqu6YzthK19k/GbnDvIoLg ZYBcZNZ50iAYuK83gfG6+TcI7A+imd8l6JipSwWnWAPKv84gYJ1uID/zd2lEIbvUB+9k EdcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=G78LrJd3BzLZNYh6/WaZYLNiR0eTkBZit948u2K/uys=; b=h9Ci4+ebS8yxa69Ihx5bT9sgHUlHdpRcoqzaAr+lnVtSgSay1emdYCF1MdZ+Lr0e+o D/os4EdDkzHs+wSV5YHNr+9RgjVoTV7w2/gZaBNGsX3J/bRG3LW3lAbbFw1fqAQd/c1C hnegTO+8ymP6mCYLKTTEzSwOjHtLjzp/TUiW7DK6/Twd0PeXiRpGV8XmxLSiAK7VHP8X 6whu+AUqLeQ+IR6KMKtSxYwL82P7oObw5WpN+uQpksb3cG1cC8ENPc5QjxFqY2esVK7I FwjzkEs3dTgkolOcJNk8Yr0gLC0BtTJjb20ISmUXlvx7ennLBN6IJItZVnLgFQuP7sei qlmA== X-Gm-Message-State: AD7BkJLGqdZ7AHt33KCG/vEdtHT+gRMQ3ynxP4zaXba79Hc+AJR8Z8Gy442FiJohg+yoww== X-Received: by 10.50.60.9 with SMTP id d9mr31989509igr.54.1460047266996; Thu, 07 Apr 2016 09:41:06 -0700 (PDT) Received: from mail-io0-f169.google.com (mail-io0-f169.google.com. [209.85.223.169]) by smtp.gmail.com with ESMTPSA id n4sm11918756igv.3.2016.04.07.09.41.05 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 09:41:05 -0700 (PDT) Received: by mail-io0-f169.google.com with SMTP id o126so78328293iod.0 for ; Thu, 07 Apr 2016 09:41:05 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.184.68 with SMTP id i65mr4494916iof.76.1460047265441; Thu, 07 Apr 2016 09:41:05 -0700 (PDT) Received: by 10.36.6.85 with HTTP; Thu, 7 Apr 2016 09:41:05 -0700 (PDT) In-Reply-To: References: <570548D6.8010605@gmx.net> <57055DE2.50201@aol.com> <7A8E4B64-4741-4A54-84D6-B887690F77B5@erdtman.se> Date: Thu, 7 Apr 2016 09:41:05 -0700 X-Gmail-Original-Message-ID: Message-ID: From: Aaron Parecki To: Mike Jones Content-Type: multipart/alternative; boundary=94eb2c0770729cdd62052fe7be2d Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 16:41:11 -0000 --94eb2c0770729cdd62052fe7be2d Content-Type: text/plain; charset=UTF-8 The primary critique of OAuth 2.0 right now is that simply reading and implementing the spec does not guarantee interoperable implementations. If there is going to be a new OAuth 2.1 version, then it only makes sense to go through that effort if it will actually lead to interoperable implementations. Otherwise there is very little actually communicated to the market that is useful. I agree with Mike that we need more actual deployment experience before we should consider creating a 2.1 version. The 2.1 version should be based on the implementation experience learned, rather than making it up right now. ---- Aaron Parecki aaronparecki.com @aaronpk On Thu, Apr 7, 2016 at 9:38 AM, Mike Jones wrote: > I am strongly against creating a 2.1 spec until we have at least a year of > deployment experience with the contents we're adding to 2.0, so as not to > fragment the OAuth marketplace. > > I think we should: > 1. Continue working on new security mitigations in new drafts (such as > mix-up-mitigation, etc.) that add features to use with 2.0 > 2. Continue working on PoP specs (such as pop-key-distribution, etc.) > that add features to use with 2.0 > 3. Continue working on other new specs (such as discovery, > resource-indicators, etc.) that add features to use with 2.0 > 4. Learn from deployment experience with all of them > 5. Iterate if the deployment experience tells us that we need to > > Only after we believe we have all the features right and we know that they > work together well should we consider creating a 2.1. If we rush to a 2.1 > and get it wrong, we'll lose developers' trust and we'll never get it back. > > -- Mike > > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Samuel Erdtman > Sent: Thursday, April 7, 2016 12:48 PM > To: Anthony Nadalin > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.1 > > +1 on a 2.1 version > > -1 on defining scopes more precisely in 2.1 > > Sent from my iPhone > > > On 7 apr. 2016, at 14:46, Anthony Nadalin wrote: > > > > I don't belive that scopes should be defined more precisely as this > opaqueness was a design feature, I'm not seeing the reason why scopes need > to be defined, as these are application specific. > > > > -----Original Message----- > > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten > > Lodderstedt > > Sent: Thursday, April 7, 2016 5:32 AM > > To: George Fletcher > > Cc: oauth@ietf.org > > Subject: Re: [OAUTH-WG] OAuth 2.1 > > > > Hi all, > > > > as I already said in the meeting: I would very much prefer to have an > extension/update of RFC 6819 covering all "new" threats, including: > > - mix up > > - code injection aka copy and paste > > - open redirector at AS and client > > - potential other threats in the context of "dynamic" OAuth > > > > I also assume mitigations for (at least some of) the threats need to go > into an update of RFC 6749 as normative text. To give an example: if we > agree on using the state parameter at the token endpoint to mitigate code > injection, this MUST be part of the core spec (request description and > security consoderations). Otherwise, noone will even consider it. > > > > We should also use the opportunity to improve/enhance the text of the > spec. In the course of the last years, we have learned a lot about > ambiquities of the text and how different implementations utilize OAuth. > > > > I think time is right to define scopes more precisely. As the > discussions in the last days proved again (at least for me), scope is not > sufficiently defined to come up with interoperable implementations. > Additionally, there seems to be a need to represent resource server > locations (to not say identities :-)) in this context. > > > > To bundle all changes in a version 2.1 would also make communication > into the market much easier. > > > > best regards, > > Torsten. > > > >> Am 06.04.2016 um 16:05 schrieb George Fletcher : > >> > >> I'd definitely prefer a single solution document to many little ones > that have to be combined to actually build a secure solution. It's already > getting complex with the additional specs that have been added. > >> > >> Additionally, I'm not against working on OAuth 2.1. > >> > >> Thanks, > >> George > >> > >>> On 4/6/16 2:06 PM, Phil Hunt (IDM) wrote: > >>> > >>> Existing implementations are for the large part ok and do not need > these mitigations. > >>> > >>> Only the new use cases we have been discussing (configure on the fly > and multi-as, etc) really need mitigation. > >>> > >>> The updated by approach seems like a good way to address the new cases. > >>> > >>> Phil > >>> > >>>> On Apr 6, 2016, at 14:35, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > >>>> > >>>> Hi all, > >>>> > >>>> today we discussed the OAuth Authorization Server Mixup draft. We > >>>> were wondering what types of threats the document should find > solutions for. > >>>> > >>>> We discussed various document handling approaches including > >>>> * OAuth Mix-Up and Cut-and-Paste attacks documented in separate > >>>> solution documents > >>>> * combined solution document covering the OAuth Mix-Up and the > >>>> Cut-and-Paste attacks. > >>>> > >>>> Barry pointed out that these documents could update the OAuth base > >>>> specification. > >>>> > >>>> As a more radical change it was also suggested to revise RFC 6749 > >>>> "OAuth > >>>> 2.0 Authorization Framework" and RFC 6819 "OAuth 2.0 Threat Model > >>>> and Security Considerations". > >>>> > >>>> Opening up the OAuth base specification obviously raises various > >>>> other questions about cleaning up parts that go far beyond the AS > >>>> mix-up and the cut-and-paste attacks. Other specifications, such as > >>>> the Open Redirector, could be folded into such a new specification. > >>>> > >>>> Derek and I would appreciate your input on this topic before we > >>>> make a decision since it has significant impact on our work. > >>>> > >>>> Ciao > >>>> Hannes & Derek > >>>> > >>>> > >>>> _______________________________________________ > >>>> OAuth mailing list > >>>> OAuth@ietf.org > >>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fww > >>>> w > >>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40mic > >>>> r > >>>> osoft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab > >>>> 2 > >>>> d7cd011db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3 > >>>> d > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww. > >>> ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40micro > >>> s > >>> oft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7 > >>> c d011db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww. > >> i > >> etf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microso > >> f > >> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd0 > >> 1 1db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.i > > etf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsof > > t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd01 > > 1db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d > > > > _______________________________________________ > > OAuth mailing 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 > --94eb2c0770729cdd62052fe7be2d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The primary critique of OAuth 2.0 right now is that simply= reading and implementing the spec does not guarantee interoperable impleme= ntations. If there is going to be a new OAuth 2.1 version, then it only mak= es sense to go through that effort if it will actually lead to interoperabl= e implementations. Otherwise there is very little actually communicated to = the market that is useful.

I agree with Mike that we nee= d more actual deployment experience before we should consider creating a 2.= 1 version. The 2.1 version should be based on the implementation experience= learned, rather than making it up right now.

----
Aaron Parecki


On Thu, Apr 7, 2016 at 9:38 AM, Mike Jones <= span dir=3D"ltr"><Michael.Jones@microsoft.com> wrote:
I am strongly against creating a 2.1 spec until we hav= e at least a year of deployment experience with the contents we're addi= ng to 2.0, so as not to fragment the OAuth marketplace.

I think we should:
1.=C2=A0 Continue working on new security mitigations in new drafts (such a= s mix-up-mitigation, etc.) that add features to use with 2.0
2.=C2=A0 Continue working on PoP specs (such as pop-key-distribution, etc.)= that add features to use with 2.0
3.=C2=A0 Continue working on other new specs (such as discovery, resource-i= ndicators, etc.) that add features to use with 2.0
4.=C2=A0 Learn from deployment experience with all of them
5.=C2=A0 Iterate if the deployment experience tells us that we need to

Only after we believe we have all the features right and we know that they = work together well should we consider creating a 2.1.=C2=A0 If we rush to a= 2.1 and get it wrong, we'll lose developers' trust and we'll n= ever get it back.

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

-----Original Message-----
From: OAuth [mailto:oauth-bounces= @ietf.org] On Behalf Of Samuel Erdtman
Sent: Thursday, April 7, 2016 12:48 PM
To: Anthony Nadalin <tonynad@mi= crosoft.com>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.1

+1 on a 2.1 version

-1 on defining scopes more precisely in 2.1

Sent from my iPhone

> On 7 apr. 2016, at 14:46, Anthony Nadalin <tonynad@microsoft.com> wrote:
>
> I don't belive that scopes should be defined more precisely as thi= s opaqueness was a design feature, I'm not seeing the reason why scopes= need to be defined, as these are application specific.
>
> -----Original Message-----
> From: OAuth [mailto:oauth-bo= unces@ietf.org] On Behalf Of Torsten
> Lodderstedt
> Sent: Thursday, April 7, 2016 5:32 AM
> To: George Fletcher <gffletch@a= ol.com>
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth 2.1
>
> Hi all,
>
> as I already said in the meeting: I would very much prefer to have an = extension/update of RFC 6819 covering all "new" threats, includin= g:
> - mix up
> - code injection aka copy and paste
> - open redirector at AS and client
> - potential other threats in the context of "dynamic" OAuth<= br> >
> I also assume mitigations for (at least some of) the threats need to g= o into an update of RFC 6749 as normative text. To give an example: if we a= gree on using the state parameter at the token endpoint to mitigate code in= jection, this MUST be part of the core spec (request description and securi= ty consoderations). Otherwise, noone will even=C2=A0 consider it.
>
> We should also use the opportunity to improve/enhance the text of the = spec. In the course of the last years, we have learned a lot about ambiquit= ies of the text and how different implementations utilize OAuth.
>
> I think time is right to define scopes more precisely. As the discussi= ons in the last days proved again (at least for me), scope is not sufficien= tly defined to come up with interoperable implementations. Additionally, th= ere seems to be a need to represent resource server locations (to not say i= dentities :-)) in this context.
>
> To bundle all changes in a version 2.1 would also make communication i= nto the market much easier.
>
> best regards,
> Torsten.
>
>> Am 06.04.2016 um 16:05 schrieb George Fletcher <gffletch@aol.com>:
>>
>> I'd definitely prefer a single solution document to many littl= e ones that have to be combined to actually build a secure solution. It'= ;s already getting complex with the additional specs that have been added.<= br> >>
>> Additionally, I'm not against working on OAuth 2.1.
>>
>> Thanks,
>> George
>>
>>> On 4/6/16 2:06 PM, Phil Hunt (IDM) wrote:
>>>
>>> Existing implementations are for the large part ok and do not = need these mitigations.
>>>
>>> Only the new use cases we have been discussing (configure on t= he fly and multi-as, etc) really need mitigation.
>>>
>>> The updated by approach seems like a good way to address the n= ew cases.
>>>
>>> Phil
>>>
>>>> On Apr 6, 2016, at 14:35, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:=
>>>>
>>>> Hi all,
>>>>
>>>> today we discussed the OAuth Authorization Server Mixup dr= aft. We
>>>> were wondering what types of threats the document should f= ind solutions for.
>>>>
>>>> We discussed various document handling approaches includin= g
>>>> * OAuth Mix-Up and Cut-and-Paste attacks documented in sep= arate
>>>> solution documents
>>>> * combined solution document covering the OAuth Mix-Up and= the
>>>> Cut-and-Paste attacks.
>>>>
>>>> Barry pointed out that these documents could update the OA= uth base
>>>> specification.
>>>>
>>>> As a more radical change it was also suggested to revise R= FC 6749
>>>> "OAuth
>>>> 2.0 Authorization Framework" and RFC 6819 "OAuth= 2.0 Threat Model
>>>> and Security Considerations".
>>>>
>>>> Opening up the OAuth base specification obviously raises v= arious
>>>> other questions about cleaning up parts that go far beyond= the AS
>>>> mix-up and the cut-and-paste attacks. Other specifications= , such as
>>>> the Open Redirector, could be folded into such a new speci= fication.
>>>>
>>>> Derek and I would appreciate your input on this topic befo= re we
>>>> make a decision since it has significant impact on our wor= k.
>>>>
>>>> Ciao
>>>> Hannes & Derek
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://na01.s= afelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fww
>>>> w
>>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctony= nad%40mic
>>>> r
>>>> osoft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af= 91ab
>>>> 2
>>>> d7cd011db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYnd= nkLgLa5SPk2HI%3
>>>> d
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://na01.saf= elinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.
>>> ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%4= 0micro
>>> s
>>> oft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7<= br>
>>> c d011db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufou= xS6qYndnkLgLa5SPk2HI%3d
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://na01.safelink= s.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.
>> i
>> et= f.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40micro= so
>> f
>> t.co= m%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd0
>> 1 1db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgL= a5SPk2HI%3d
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://na01.safelinks.= protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.i
> etf.or= g%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40microsof<= br> > t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd01
> 1db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >
> _______________________________________________
> OAuth mailing 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

--94eb2c0770729cdd62052fe7be2d-- From nobody Thu Apr 7 10:34:39 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD35712D564 for ; Thu, 7 Apr 2016 10:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VidW1zLna6S3 for ; Thu, 7 Apr 2016 10:34:29 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002: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 3FEB012D1A3 for ; Thu, 7 Apr 2016 10:34:29 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id d68so105522558ywe.1 for ; Thu, 07 Apr 2016 10:34:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=q3oelWPyFgzMZhoUXtQc72ZMcD49weaFMEPf17NJYvs=; b=tgkWrA0jQobLQ75cL+4Uqr0EV/FTYIpEgUTRQCBtx96NGnqvhm3DQy1zOxBHEfWTu+ mVLtjSGZEonz6MEdXFyrxvdLnDuIfaLCiEojAp6T25Eg3Kcvp500LOr0zeSkkxCvsxRh c4U0TvkKinamR5Y3t9vEhC/sfqgILbthIcrL4vS4SHgA+QUGYKeGCvK0OXNldbYUjg7H lOedlZB6Ufr8m5qLgspP+eTo/Xcx77sWqzpwFKh4kgrDVJUHjNJZ6PWcl9fP5nB7Tqyh KNc+cyza5QCcCYAVmwjBNG7meVEYaVZPk3O672LdI1I2TYpoApgqgriHjp5n8JIVke3g TQ3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=q3oelWPyFgzMZhoUXtQc72ZMcD49weaFMEPf17NJYvs=; b=F0RbH686EcjrprhgAbdj2Q/RtNCVCVQKn5K4n/RNVMf8Oui7bm1ZvIxESXgyxOV29f uWHsX6FYPUOjMZXuxrk2cQZO3gr+s8w8qiweiUrcvmsPTq6hQZiNpTLOxNlPBIHWPQTG 5ICpog5cUQVdm/5ep0WR/G3l9W8EeSETn3v29LDVVl3hFdDViQ7XbTxgVNlefJ8oVw/S 9JUNR6/IXjy/AKl3vJGucksV/JDNpNLZK40Hz043xTxasYCzY3YIyAEfZ4uBVXabuTtT hK3/RmBhrjaDiItmrDgHLA0Ec6Q3oy323OhrOsgi75w4NBmNysTSk3YIPqulj6KprfXI tqUw== X-Gm-Message-State: AD7BkJI6O2v4QatWQIx/hkdrsYB7yjQdJzVchRHgS4foaxscbxj05S+C8A6hAq3cmXBx6UmeIdMbtFmlH7QBMw== MIME-Version: 1.0 X-Received: by 10.13.240.194 with SMTP id z185mr2241992ywe.317.1460050468366; Thu, 07 Apr 2016 10:34:28 -0700 (PDT) Received: by 10.37.207.6 with HTTP; Thu, 7 Apr 2016 10:34:27 -0700 (PDT) Received: by 10.37.207.6 with HTTP; Thu, 7 Apr 2016 10:34:27 -0700 (PDT) In-Reply-To: <3C8A6B97-27B6-4588-84F7-F7143E8C11F1@amazon.com> References: <3C8A6B97-27B6-4588-84F7-F7143E8C11F1@amazon.com> Date: Thu, 7 Apr 2016 14:34:27 -0300 Message-ID: From: John Bradley To: Dick Hardt Content-Type: multipart/alternative; boundary=94eb2c030eb485ac8b052fe87dd2 Archived-At: Cc: IETF oauth WG Subject: Re: [OAUTH-WG] dinner Thursday night X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 17:34:38 -0000 --94eb2c030eb485ac8b052fe87dd2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I thought that the meeting yesterday afternoon replaced the dinner tonight. I don't have any diner info for after bits and bites. On Apr 7, 2016 1:04 PM, "Hardt, Dick" wrote: > Confirming we are still gathering for dinner tonight (Thursday) and > wondering when / where we will meet. > > > > =E2=80=94 Dick > --94eb2c030eb485ac8b052fe87dd2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I thought that the meeting yesterday afternoon replaced the = dinner tonight.

I don't have any diner info for after bits and bites.

On Apr 7, 2016 1:04 PM, "Hardt, Dick" = <dick@amazon.com> wrote:
Confirming we are still g= athering for dinner tonight (Thursday) and wondering when / where we will m= eet.



=E2=80=94 Dick
--94eb2c030eb485ac8b052fe87dd2-- From nobody Thu Apr 7 11:13:17 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF3712D680 for ; Thu, 7 Apr 2016 11:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.622 X-Spam-Level: X-Spam-Status: No, score=-2.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltFyxQLzeb4s for ; Thu, 7 Apr 2016 11:13:12 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.101]) (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 5B0F712D679 for ; Thu, 7 Apr 2016 11:13:12 -0700 (PDT) Received: from [80.187.110.249] (helo=[10.155.172.148]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84) (envelope-from ) id 1aoEQW-0002dc-7k; Thu, 07 Apr 2016 20:13:09 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPad Mail (13E238) In-Reply-To: Date: Thu, 7 Apr 2016 15:13:02 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <570548D6.8010605@gmx.net> <57055DE2.50201@aol.com> To: Anthony Nadalin X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 18:13:16 -0000 Hi Tony, I'm not saying we need to define scopes or scope values. These are certainly= application/API specific. Here are the issues I see: - Namespaces: there is no guidance on how to prevent clashes among scopes fo= r different applications. Say we had used the scope value "email" for our em= ail service before we implemented OIDC. How should we have solved the naming= conflict with the respective claim-related scope value "email"? Resource servers: it's perfectly possible to represent resource server ids i= n scope values today. BUT: not in an interoperable way. That's why we have c= oncepts like aud, audience, resource on the table in different recent specs.= They all try to circumvent the same problem. - Is the scope supposed to describe the grant of the code, the refresh or th= e access token? We had an interresting side discussion about that topic and i= t seems everyone has another _opinion_ about it and implementations differ. I'm mostly interested in support for multi-application deployments and my co= nclusion is: The current scope concept only works in multi-application deypl= oyments if: - there are ecosystem-specific rules of how to use scope values (good luck w= ith standard applications and forget interop) - there is one AS per application (terrible UX) We can do better. best regards, Torsten. > Am 07.04.2016 um 09:46 schrieb Anthony Nadalin : >=20 > I don't belive that scopes should be defined more precisely as this opaque= ness was a design feature, I'm not seeing the reason why scopes need to be d= efined, as these are application specific. >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten Lodderste= dt > Sent: Thursday, April 7, 2016 5:32 AM > To: George Fletcher > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.1 >=20 > Hi all, >=20 > as I already said in the meeting: I would very much prefer to have an exte= nsion/update of RFC 6819 covering all "new" threats, including: > - mix up > - code injection aka copy and paste > - open redirector at AS and client > - potential other threats in the context of "dynamic" OAuth >=20 > I also assume mitigations for (at least some of) the threats need to go in= to an update of RFC 6749 as normative text. To give an example: if we agree o= n using the state parameter at the token endpoint to mitigate code injection= , this MUST be part of the core spec (request description and security conso= derations). Otherwise, noone will even consider it. >=20 > We should also use the opportunity to improve/enhance the text of the spec= . In the course of the last years, we have learned a lot about ambiquities o= f the text and how different implementations utilize OAuth.=20 >=20 > I think time is right to define scopes more precisely. As the discussions i= n the last days proved again (at least for me), scope is not sufficiently de= fined to come up with interoperable implementations. Additionally, there see= ms to be a need to represent resource server locations (to not say identitie= s :-)) in this context. >=20 > To bundle all changes in a version 2.1 would also make communication into t= he market much easier.=20 >=20 > best regards, > Torsten. >=20 >> Am 06.04.2016 um 16:05 schrieb George Fletcher : >>=20 >> I'd definitely prefer a single solution document to many little ones that= have to be combined to actually build a secure solution. It's already getti= ng complex with the additional specs that have been added. >>=20 >> Additionally, I'm not against working on OAuth 2.1. >>=20 >> Thanks, >> George >>=20 >>> On 4/6/16 2:06 PM, Phil Hunt (IDM) wrote: >>>=20 >>> Existing implementations are for the large part ok and do not need these= mitigations. >>>=20 >>> Only the new use cases we have been discussing (configure on the fly and= multi-as, etc) really need mitigation. >>>=20 >>> The updated by approach seems like a good way to address the new cases. >>>=20 >>> Phil >>>=20 >>>> On Apr 6, 2016, at 14:35, Hannes Tschofenig = wrote: >>>>=20 >>>> Hi all, >>>>=20 >>>> today we discussed the OAuth Authorization Server Mixup draft. We=20 >>>> were wondering what types of threats the document should find solutions= for. >>>>=20 >>>> We discussed various document handling approaches including >>>> * OAuth Mix-Up and Cut-and-Paste attacks documented in separate=20 >>>> solution documents >>>> * combined solution document covering the OAuth Mix-Up and the=20 >>>> Cut-and-Paste attacks. >>>>=20 >>>> Barry pointed out that these documents could update the OAuth base=20 >>>> specification. >>>>=20 >>>> As a more radical change it was also suggested to revise RFC 6749=20 >>>> "OAuth >>>> 2.0 Authorization Framework" and RFC 6819 "OAuth 2.0 Threat Model=20 >>>> and Security Considerations". >>>>=20 >>>> Opening up the OAuth base specification obviously raises various=20 >>>> other questions about cleaning up parts that go far beyond the AS=20 >>>> mix-up and the cut-and-paste attacks. Other specifications, such as=20 >>>> the Open Redirector, could be folded into such a new specification. >>>>=20 >>>> Derek and I would appreciate your input on this topic before we make=20= >>>> a decision since it has significant impact on our work. >>>>=20 >>>> Ciao >>>> Hannes & Derek >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww >>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40micr >>>> osoft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2 >>>> d7cd011db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww. >>> ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40micros >>> oft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7c >>> d011db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.i >> etf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40microsof >> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd01 >> 1db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.iet= f.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40microsoft.com%= 7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd011db47%7c1&sd= ata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d From nobody Thu Apr 7 11:16:08 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC84712D578 for ; Thu, 7 Apr 2016 11:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.622 X-Spam-Level: X-Spam-Status: No, score=-2.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gF6NzQ6gX4ww for ; Thu, 7 Apr 2016 11:15:59 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.44]) (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 695C712D695 for ; Thu, 7 Apr 2016 11:15:58 -0700 (PDT) Received: from [80.187.110.249] (helo=[10.155.172.148]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84) (envelope-from ) id 1aoETC-0007B4-Oc; Thu, 07 Apr 2016 20:15:56 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPad Mail (13E238) In-Reply-To: Date: Thu, 7 Apr 2016 15:15:49 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <570548D6.8010605@gmx.net> <57055DE2.50201@aol.com> <7A8E4B64-4741-4A54-84D6-B887690F77B5@erdtman.se> To: Mike Jones X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 18:16:06 -0000 Hi Mike, in my opinion, you described a possible path towards 2.1. Would you agree? best regards, Torsten. > Am 07.04.2016 um 13:38 schrieb Mike Jones : >=20 > I am strongly against creating a 2.1 spec until we have at least a year of= deployment experience with the contents we're adding to 2.0, so as not to f= ragment the OAuth marketplace. >=20 > I think we should: > 1. Continue working on new security mitigations in new drafts (such as mi= x-up-mitigation, etc.) that add features to use with 2.0 > 2. Continue working on PoP specs (such as pop-key-distribution, etc.) tha= t add features to use with 2.0 > 3. Continue working on other new specs (such as discovery, resource-indic= ators, etc.) that add features to use with 2.0 > 4. Learn from deployment experience with all of them > 5. Iterate if the deployment experience tells us that we need to >=20 > Only after we believe we have all the features right and we know that they= work together well should we consider creating a 2.1. If we rush to a 2.1 a= nd get it wrong, we'll lose developers' trust and we'll never get it back. >=20 > -- Mike >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Samuel Erdtman > Sent: Thursday, April 7, 2016 12:48 PM > To: Anthony Nadalin > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.1 >=20 > +1 on a 2.1 version >=20 > -1 on defining scopes more precisely in 2.1 >=20 > Sent from my iPhone >=20 >> On 7 apr. 2016, at 14:46, Anthony Nadalin wrote: >>=20 >> I don't belive that scopes should be defined more precisely as this opaqu= eness was a design feature, I'm not seeing the reason why scopes need to be d= efined, as these are application specific. >>=20 >> -----Original Message----- >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten=20 >> Lodderstedt >> Sent: Thursday, April 7, 2016 5:32 AM >> To: George Fletcher >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] OAuth 2.1 >>=20 >> Hi all, >>=20 >> as I already said in the meeting: I would very much prefer to have an ext= ension/update of RFC 6819 covering all "new" threats, including: >> - mix up >> - code injection aka copy and paste >> - open redirector at AS and client >> - potential other threats in the context of "dynamic" OAuth >>=20 >> I also assume mitigations for (at least some of) the threats need to go i= nto an update of RFC 6749 as normative text. To give an example: if we agree= on using the state parameter at the token endpoint to mitigate code injecti= on, this MUST be part of the core spec (request description and security con= soderations). Otherwise, noone will even consider it. >>=20 >> We should also use the opportunity to improve/enhance the text of the spe= c. In the course of the last years, we have learned a lot about ambiquities o= f the text and how different implementations utilize OAuth.=20 >>=20 >> I think time is right to define scopes more precisely. As the discussions= in the last days proved again (at least for me), scope is not sufficiently d= efined to come up with interoperable implementations. Additionally, there se= ems to be a need to represent resource server locations (to not say identiti= es :-)) in this context. >>=20 >> To bundle all changes in a version 2.1 would also make communication into= the market much easier.=20 >>=20 >> best regards, >> Torsten. >>=20 >>> Am 06.04.2016 um 16:05 schrieb George Fletcher : >>>=20 >>> I'd definitely prefer a single solution document to many little ones tha= t have to be combined to actually build a secure solution. It's already gett= ing complex with the additional specs that have been added. >>>=20 >>> Additionally, I'm not against working on OAuth 2.1. >>>=20 >>> Thanks, >>> George >>>=20 >>>> On 4/6/16 2:06 PM, Phil Hunt (IDM) wrote: >>>>=20 >>>> Existing implementations are for the large part ok and do not need thes= e mitigations. >>>>=20 >>>> Only the new use cases we have been discussing (configure on the fly an= d multi-as, etc) really need mitigation. >>>>=20 >>>> The updated by approach seems like a good way to address the new cases.= >>>>=20 >>>> Phil >>>>=20 >>>>> On Apr 6, 2016, at 14:35, Hannes Tschofenig wrote: >>>>>=20 >>>>> Hi all, >>>>>=20 >>>>> today we discussed the OAuth Authorization Server Mixup draft. We=20 >>>>> were wondering what types of threats the document should find solution= s for. >>>>>=20 >>>>> We discussed various document handling approaches including >>>>> * OAuth Mix-Up and Cut-and-Paste attacks documented in separate=20 >>>>> solution documents >>>>> * combined solution document covering the OAuth Mix-Up and the=20 >>>>> Cut-and-Paste attacks. >>>>>=20 >>>>> Barry pointed out that these documents could update the OAuth base=20 >>>>> specification. >>>>>=20 >>>>> As a more radical change it was also suggested to revise RFC 6749=20 >>>>> "OAuth >>>>> 2.0 Authorization Framework" and RFC 6819 "OAuth 2.0 Threat Model=20 >>>>> and Security Considerations". >>>>>=20 >>>>> Opening up the OAuth base specification obviously raises various=20 >>>>> other questions about cleaning up parts that go far beyond the AS=20 >>>>> mix-up and the cut-and-paste attacks. Other specifications, such as=20= >>>>> the Open Redirector, could be folded into such a new specification. >>>>>=20 >>>>> Derek and I would appreciate your input on this topic before we=20 >>>>> make a decision since it has significant impact on our work. >>>>>=20 >>>>> Ciao >>>>> Hannes & Derek >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fww >>>>> w=20 >>>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40mic >>>>> r >>>>> osoft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab >>>>> 2=20 >>>>> d7cd011db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3 >>>>> d >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.= >>>> ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40micro >>>> s=20 >>>> oft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7 >>>> c d011db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww. >>> i=20 >>> etf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40microso >>> f >>> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd0 >>> 1 1db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.i >> etf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40microsof >> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd01 >> 1db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >>=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 From nobody Thu Apr 7 11:25:46 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF7E12D1B5 for ; Thu, 7 Apr 2016 11:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKJ_KLsiGO13 for ; Thu, 7 Apr 2016 11:25:37 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0116.outbound.protection.outlook.com [207.46.100.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5334B12D6A9 for ; Thu, 7 Apr 2016 11:25:37 -0700 (PDT) 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=ueCRa3NojzSXG/gm0LKaH8pn1A4h2uZREPOuh0lPaoo=; b=cP35OBUcIHGBOSsfB6aq1EiN5Bj0I8U5inH+TINWYlirV8Ssn8im2xlcEQFP3+2j33ad+1SrJFUlPsjPUHdroWGK5zH36/tLJNWDUcHt9XhVl9OH8nY5Vhht5eB60JSPfYNaOOeZhMI2W/c+pORwIf5hjZcK6VxXeS1i2RNhp+M= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1647.namprd03.prod.outlook.com (10.162.130.141) with Microsoft SMTP Server (TLS) id 15.1.447.15; Thu, 7 Apr 2016 18:25:36 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0447.028; Thu, 7 Apr 2016 18:25:34 +0000 From: Mike Jones To: Torsten Lodderstedt Thread-Topic: [OAUTH-WG] OAuth 2.1 Thread-Index: AQHRkCrDP1Jnm0oCX0OWdyvM+93ryZ99PcEAgAAQXwCAASSegIAAA/iAgAAyo4CAAAvR0IAAHYaAgAABgCA= Date: Thu, 7 Apr 2016 18:25:34 +0000 Message-ID: References: <570548D6.8010605@gmx.net> <57055DE2.50201@aol.com> <7A8E4B64-4741-4A54-84D6-B887690F77B5@erdtman.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: lodderstedt.net; dkim=none (message not signed) header.d=none;lodderstedt.net; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [31.133.160.66] x-ms-office365-filtering-correlation-id: 26591fab-c963-4429-fb32-08d35f12027e x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1647; 5:ICgS/FcbLL7Cxzk5LfBoQq77KhQlDR9Eq/yOFqkAADU3wRSMwJwY4+DVJeLnnjwhca0Gl5mStto0eKK+SERDNFdpDN0jKe+0nY7SeLrEtWd76mS/YulmxI1FoP4PhcMDr3NpmTO653gdjWweqwDC6g==; 24:I47FCUbnjTry1lFW98uhzxvaebHbWC6c5HFGl4nkX+pnmi9HTsekykN5q4HVJjTO9fjHp8o15mp0t5EZdEbkDzP8pvJZW+11RZrhwtqVyf4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1647; 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)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1647; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1647; x-forefront-prvs: 0905A6B2C7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(53754006)(110136002)(5003630100001)(189998001)(3660700001)(5005710100001)(5003600100002)(33656002)(10290500002)(10400500002)(3280700002)(93886004)(74316001)(6116002)(87936001)(5004730100002)(2900100001)(102836003)(5008740100001)(81166005)(19580395003)(164054004)(19580405001)(10090500001)(76176999)(50986999)(1220700001)(3846002)(86612001)(575784001)(86362001)(1096002)(54356999)(2906002)(76576001)(122556002)(4326007)(92566002)(2950100001)(5002640100001)(586003)(99286002)(66066001)(106116001)(15975445007)(77096005); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1647; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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: 07 Apr 2016 18:25:34.3266 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1647 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 18:25:45 -0000 Yes - an intentionally conservative, implementation- and experience-driven = path. Revising OAuth 2.0 is a *big deal*. We shouldn't even be talking about it = until we've completed steps 1-5 below - *including* the "iterate" step, as = necessary. If we get this wrong, we'll fragment OAuth, which is a terrible= and irresponsible outcome we should consciously avoid at all costs. In particular, we should not recharter for an OAuth 2.1 until we already kn= ow what will be in it and know from deployment experience that it's the rig= ht stuff. -- Mike -----Original Message----- From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]=20 Sent: Thursday, April 7, 2016 3:16 PM To: Mike Jones Cc: Samuel Erdtman ; Anthony Nadalin ; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.1 Hi Mike, in my opinion, you described a possible path towards 2.1. Would you agree? best regards, Torsten. > Am 07.04.2016 um 13:38 schrieb Mike Jones : >=20 > I am strongly against creating a 2.1 spec until we have at least a year o= f deployment experience with the contents we're adding to 2.0, so as not to= fragment the OAuth marketplace. >=20 > I think we should: > 1. Continue working on new security mitigations in new drafts (such=20 > as mix-up-mitigation, etc.) that add features to use with 2.0 2. =20 > Continue working on PoP specs (such as pop-key-distribution, etc.)=20 > that add features to use with 2.0 3. Continue working on other new=20 > specs (such as discovery, resource-indicators, etc.) that add features=20 > to use with 2.0 4. Learn from deployment experience with all of them=20 > 5. Iterate if the deployment experience tells us that we need to >=20 > Only after we believe we have all the features right and we know that the= y work together well should we consider creating a 2.1. If we rush to a 2.= 1 and get it wrong, we'll lose developers' trust and we'll never get it bac= k. >=20 > -- Mike >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Samuel=20 > Erdtman > Sent: Thursday, April 7, 2016 12:48 PM > To: Anthony Nadalin > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.1 >=20 > +1 on a 2.1 version >=20 > -1 on defining scopes more precisely in 2.1 >=20 > Sent from my iPhone >=20 >> On 7 apr. 2016, at 14:46, Anthony Nadalin wrote: >>=20 >> I don't belive that scopes should be defined more precisely as this opaq= ueness was a design feature, I'm not seeing the reason why scopes need to b= e defined, as these are application specific. >>=20 >> -----Original Message----- >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten=20 >> Lodderstedt >> Sent: Thursday, April 7, 2016 5:32 AM >> To: George Fletcher >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] OAuth 2.1 >>=20 >> Hi all, >>=20 >> as I already said in the meeting: I would very much prefer to have an ex= tension/update of RFC 6819 covering all "new" threats, including: >> - mix up >> - code injection aka copy and paste >> - open redirector at AS and client >> - potential other threats in the context of "dynamic" OAuth >>=20 >> I also assume mitigations for (at least some of) the threats need to go = into an update of RFC 6749 as normative text. To give an example: if we agr= ee on using the state parameter at the token endpoint to mitigate code inje= ction, this MUST be part of the core spec (request description and security= consoderations). Otherwise, noone will even consider it. >>=20 >> We should also use the opportunity to improve/enhance the text of the sp= ec. In the course of the last years, we have learned a lot about ambiquitie= s of the text and how different implementations utilize OAuth.=20 >>=20 >> I think time is right to define scopes more precisely. As the discussion= s in the last days proved again (at least for me), scope is not sufficientl= y defined to come up with interoperable implementations. Additionally, ther= e seems to be a need to represent resource server locations (to not say ide= ntities :-)) in this context. >>=20 >> To bundle all changes in a version 2.1 would also make communication int= o the market much easier.=20 >>=20 >> best regards, >> Torsten. >>=20 >>> Am 06.04.2016 um 16:05 schrieb George Fletcher : >>>=20 >>> I'd definitely prefer a single solution document to many little ones th= at have to be combined to actually build a secure solution. It's already ge= tting complex with the additional specs that have been added. >>>=20 >>> Additionally, I'm not against working on OAuth 2.1. >>>=20 >>> Thanks, >>> George >>>=20 >>>> On 4/6/16 2:06 PM, Phil Hunt (IDM) wrote: >>>>=20 >>>> Existing implementations are for the large part ok and do not need the= se mitigations. >>>>=20 >>>> Only the new use cases we have been discussing (configure on the fly a= nd multi-as, etc) really need mitigation. >>>>=20 >>>> The updated by approach seems like a good way to address the new cases= . >>>>=20 >>>> Phil >>>>=20 >>>>> On Apr 6, 2016, at 14:35, Hannes Tschofenig wrote: >>>>>=20 >>>>> Hi all, >>>>>=20 >>>>> today we discussed the OAuth Authorization Server Mixup draft. We=20 >>>>> were wondering what types of threats the document should find solutio= ns for. >>>>>=20 >>>>> We discussed various document handling approaches including >>>>> * OAuth Mix-Up and Cut-and-Paste attacks documented in separate=20 >>>>> solution documents >>>>> * combined solution document covering the OAuth Mix-Up and the=20 >>>>> Cut-and-Paste attacks. >>>>>=20 >>>>> Barry pointed out that these documents could update the OAuth base=20 >>>>> specification. >>>>>=20 >>>>> As a more radical change it was also suggested to revise RFC 6749=20 >>>>> "OAuth >>>>> 2.0 Authorization Framework" and RFC 6819 "OAuth 2.0 Threat Model=20 >>>>> and Security Considerations". >>>>>=20 >>>>> Opening up the OAuth base specification obviously raises various=20 >>>>> other questions about cleaning up parts that go far beyond the AS=20 >>>>> mix-up and the cut-and-paste attacks. Other specifications, such=20 >>>>> as the Open Redirector, could be folded into such a new specification= . >>>>>=20 >>>>> Derek and I would appreciate your input on this topic before we=20 >>>>> make a decision since it has significant impact on our work. >>>>>=20 >>>>> Ciao >>>>> Hannes & Derek >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fw >>>>> w >>>>> w >>>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40mi >>>>> c >>>>> r >>>>> osoft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91a >>>>> b >>>>> 2 >>>>> d7cd011db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI% >>>>> 3 >>>>> d >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww= . >>>> ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40micr >>>> o >>>> s >>>> oft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d >>>> 7 c=20 >>>> d011db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww. >>> i >>> etf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40micros >>> o >>> f >>> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd >>> 0 >>> 1 1db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww. >> i=20 >> etf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40microso >> f >> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd0 >> 1 1db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >>=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 From nobody Thu Apr 7 11:38:22 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D3312D5E7 for ; Thu, 7 Apr 2016 11:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ihAwQ5KEiHm for ; Thu, 7 Apr 2016 11:38:19 -0700 (PDT) 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 6AD0F12D564 for ; Thu, 7 Apr 2016 11:38:19 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u37IcH8M026422 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Apr 2016 18:38:18 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u37IcHQr029511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Apr 2016 18:38:17 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u37IcGY2032577; Thu, 7 Apr 2016 18:38:17 GMT Received: from [25.145.154.254] (/24.114.85.207) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 07 Apr 2016 11:38:13 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13E238) In-Reply-To: Date: Thu, 7 Apr 2016 15:38:00 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <570548D6.8010605@gmx.net> <57055DE2.50201@aol.com> <7A8E4B64-4741-4A54-84D6-B887690F77B5@erdtman.se> To: Mike Jones X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 18:38:22 -0000 I believe all we need is a new draft that deals with the new "dynamic/mix-up= " cases as these were not considered in the original spec process.=20 The updated by method works best for this. It also consolidates a lot of pie= cemeal specs into one consistent spec.=20 Phil > On Apr 7, 2016, at 15:25, Mike Jones wrote: >=20 > Yes - an intentionally conservative, implementation- and experience-driven= path. >=20 > Revising OAuth 2.0 is a *big deal*. We shouldn't even be talking about it= until we've completed steps 1-5 below - *including* the "iterate" step, as n= ecessary. If we get this wrong, we'll fragment OAuth, which is a terrible a= nd irresponsible outcome we should consciously avoid at all costs. >=20 > In particular, we should not recharter for an OAuth 2.1 until we already k= now what will be in it and know from deployment experience that it's the rig= ht stuff. >=20 > -- Mike >=20 > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]=20 > Sent: Thursday, April 7, 2016 3:16 PM > To: Mike Jones > Cc: Samuel Erdtman ; Anthony Nadalin ; oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.1 >=20 > Hi Mike, >=20 > in my opinion, you described a possible path towards 2.1. Would you agree?= >=20 > best regards, > Torsten. >=20 >> Am 07.04.2016 um 13:38 schrieb Mike Jones : >>=20 >> I am strongly against creating a 2.1 spec until we have at least a year o= f deployment experience with the contents we're adding to 2.0, so as not to f= ragment the OAuth marketplace. >>=20 >> I think we should: >> 1. Continue working on new security mitigations in new drafts (such=20 >> as mix-up-mitigation, etc.) that add features to use with 2.0 2. =20 >> Continue working on PoP specs (such as pop-key-distribution, etc.)=20 >> that add features to use with 2.0 3. Continue working on other new=20 >> specs (such as discovery, resource-indicators, etc.) that add features=20= >> to use with 2.0 4. Learn from deployment experience with all of them=20 >> 5. Iterate if the deployment experience tells us that we need to >>=20 >> Only after we believe we have all the features right and we know that the= y work together well should we consider creating a 2.1. If we rush to a 2.1= and get it wrong, we'll lose developers' trust and we'll never get it back.= >>=20 >> -- Mike >>=20 >> -----Original Message----- >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Samuel=20 >> Erdtman >> Sent: Thursday, April 7, 2016 12:48 PM >> To: Anthony Nadalin >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] OAuth 2.1 >>=20 >> +1 on a 2.1 version >>=20 >> -1 on defining scopes more precisely in 2.1 >>=20 >> Sent from my iPhone >>=20 >>> On 7 apr. 2016, at 14:46, Anthony Nadalin wrote:= >>>=20 >>> I don't belive that scopes should be defined more precisely as this opaq= ueness was a design feature, I'm not seeing the reason why scopes need to be= defined, as these are application specific. >>>=20 >>> -----Original Message----- >>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten=20 >>> Lodderstedt >>> Sent: Thursday, April 7, 2016 5:32 AM >>> To: George Fletcher >>> Cc: oauth@ietf.org >>> Subject: Re: [OAUTH-WG] OAuth 2.1 >>>=20 >>> Hi all, >>>=20 >>> as I already said in the meeting: I would very much prefer to have an ex= tension/update of RFC 6819 covering all "new" threats, including: >>> - mix up >>> - code injection aka copy and paste >>> - open redirector at AS and client >>> - potential other threats in the context of "dynamic" OAuth >>>=20 >>> I also assume mitigations for (at least some of) the threats need to go i= nto an update of RFC 6749 as normative text. To give an example: if we agree= on using the state parameter at the token endpoint to mitigate code injecti= on, this MUST be part of the core spec (request description and security con= soderations). Otherwise, noone will even consider it. >>>=20 >>> We should also use the opportunity to improve/enhance the text of the sp= ec. In the course of the last years, we have learned a lot about ambiquities= of the text and how different implementations utilize OAuth.=20 >>>=20 >>> I think time is right to define scopes more precisely. As the discussion= s in the last days proved again (at least for me), scope is not sufficiently= defined to come up with interoperable implementations. Additionally, there s= eems to be a need to represent resource server locations (to not say identit= ies :-)) in this context. >>>=20 >>> To bundle all changes in a version 2.1 would also make communication int= o the market much easier.=20 >>>=20 >>> best regards, >>> Torsten. >>>=20 >>>> Am 06.04.2016 um 16:05 schrieb George Fletcher : >>>>=20 >>>> I'd definitely prefer a single solution document to many little ones th= at have to be combined to actually build a secure solution. It's already get= ting complex with the additional specs that have been added. >>>>=20 >>>> Additionally, I'm not against working on OAuth 2.1. >>>>=20 >>>> Thanks, >>>> George >>>>=20 >>>>> On 4/6/16 2:06 PM, Phil Hunt (IDM) wrote: >>>>>=20 >>>>> Existing implementations are for the large part ok and do not need the= se mitigations. >>>>>=20 >>>>> Only the new use cases we have been discussing (configure on the fly a= nd multi-as, etc) really need mitigation. >>>>>=20 >>>>> The updated by approach seems like a good way to address the new cases= . >>>>>=20 >>>>> Phil >>>>>=20 >>>>>> On Apr 6, 2016, at 14:35, Hannes Tschofenig wrote: >>>>>>=20 >>>>>> Hi all, >>>>>>=20 >>>>>> today we discussed the OAuth Authorization Server Mixup draft. We=20 >>>>>> were wondering what types of threats the document should find solutio= ns for. >>>>>>=20 >>>>>> We discussed various document handling approaches including >>>>>> * OAuth Mix-Up and Cut-and-Paste attacks documented in separate=20 >>>>>> solution documents >>>>>> * combined solution document covering the OAuth Mix-Up and the=20 >>>>>> Cut-and-Paste attacks. >>>>>>=20 >>>>>> Barry pointed out that these documents could update the OAuth base=20= >>>>>> specification. >>>>>>=20 >>>>>> As a more radical change it was also suggested to revise RFC 6749=20 >>>>>> "OAuth >>>>>> 2.0 Authorization Framework" and RFC 6819 "OAuth 2.0 Threat Model=20 >>>>>> and Security Considerations". >>>>>>=20 >>>>>> Opening up the OAuth base specification obviously raises various=20 >>>>>> other questions about cleaning up parts that go far beyond the AS=20 >>>>>> mix-up and the cut-and-paste attacks. Other specifications, such=20 >>>>>> as the Open Redirector, could be folded into such a new specification= . >>>>>>=20 >>>>>> Derek and I would appreciate your input on this topic before we=20 >>>>>> make a decision since it has significant impact on our work. >>>>>>=20 >>>>>> Ciao >>>>>> Hannes & Derek >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fw >>>>>> w >>>>>> w >>>>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40mi >>>>>> c >>>>>> r >>>>>> osoft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91a >>>>>> b >>>>>> 2 >>>>>> d7cd011db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI% >>>>>> 3 >>>>>> d >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww= . >>>>> ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40micr >>>>> o >>>>> s >>>>> oft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d >>>>> 7 c=20 >>>>> d011db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.= >>>> i >>>> etf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40micros >>>> o >>>> f >>>> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd >>>> 0 >>>> 1 1db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww. >>> i=20 >>> etf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40microso >>> f >>> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd0 >>> 1 1db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >>>=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 From nobody Thu Apr 7 11:56:35 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E29F12D6CC for ; Thu, 7 Apr 2016 11:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.831 X-Spam-Level: X-Spam-Status: No, score=-11.831 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OB_niWMP1VaK for ; Thu, 7 Apr 2016 11:56:32 -0700 (PDT) Received: from smtp-fw-6001.amazon.com (smtp-fw-6001.amazon.com [52.95.48.154]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97C7D12D6A1 for ; Thu, 7 Apr 2016 11:56:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1460055391; x=1491591391; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=41+U5XFKLUBlZhCQS4PLJkXu5oaDQEBG/bAoZ3ClU0I=; b=CDKZckQriHvyh5wAwdVL18Xo+TYcu4tV58dpaI2q5fdjNHWgSTKF6Hq9 jCOWN89kS5ciESJALyos4LwUS6+FZ5gIkLNLJMEWCOTESefXTJy4Q58+T BL9Hr710Wz+S7ENeUNDvzXmU0DSbNgKmKl/3tK4VgMnQuwh61+jL4fbjh 8=; X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208";a="81411324" Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-64004.pdx4.amazon.com) ([10.43.8.2]) by smtp-border-fw-out-6001.iad6.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Apr 2016 18:56:29 +0000 Received: from ex10-hub-7002.ant.amazon.com (pdx1-ws-svc-lb16-vlan2.amazon.com [10.239.138.210]) by email-inbound-relay-64004.pdx4.amazon.com (8.14.7/8.14.7) with ESMTP id u37IuRSi010893 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Apr 2016 18:56:28 GMT Received: from EX13D03UWA004.ant.amazon.com (10.43.160.250) by ex10-hub-7002.ant.amazon.com (10.43.110.153) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 7 Apr 2016 11:56:09 -0700 Received: from EX13D03UWA001.ant.amazon.com (10.43.160.141) by EX13D03UWA004.ant.amazon.com (10.43.160.250) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 7 Apr 2016 18:56:08 +0000 Received: from EX13D03UWA001.ant.amazon.com ([10.43.160.141]) by EX13D03UWA001.ant.amazon.com ([10.43.160.141]) with mapi id 15.00.1104.000; Thu, 7 Apr 2016 18:56:08 +0000 From: "Hardt, Dick" To: Mike Jones , Torsten Lodderstedt Thread-Topic: [OAUTH-WG] OAuth 2.1 Thread-Index: AQHRkCrKGgrGTeZ9REu8zO6lyUV5Qp99PcEAgAAQXwCAASSegIAAA/iAgAAyo4CAAA4UgIAAG0OAgAACuQD//9ZOAA== Date: Thu, 7 Apr 2016 18:56:08 +0000 Message-ID: References: <570548D6.8010605@gmx.net> <57055DE2.50201@aol.com> <7A8E4B64-4741-4A54-84D6-B887690F77B5@erdtman.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.161.78] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Precedence: Bulk Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 18:56:34 -0000 SSB0aGluayB0aGVyZSBhcmUgYWxyZWFkeSB5ZWFycyBvZiBpbXBsZW1lbnRhdGlvbiBhbmQgZXhw ZXJpZW5jZSBzaW5jZSAyLjANCg0KSWYgd2Ugd2FpdCB1bnRpbCBhbGwgdGhlIG91dHN0YW5kaW5n IGlzc3VlcyBhbmQgbmV3IGZlYXR1cmVzIGhhdmUgaGFkIGltcGxlbWVudGF0aW9ucyBhbmQgZXhw ZXJpZW5jZSwgd2Ugd2lsbCBuZXZlciBkbyBhIDIuMSBhcyB0aGVyZSBjb250aW51ZXMgdG8gYmUg bmV3IHRoaW5ncy4NCg0KSSB3b3VsZCBzdWdnZXN0IGEgMi4xIGJlIGEgY2xlYW4sIHNpbXBsZSBk b2N1bWVudCBvZiB0aGUgY29yZSBzcGVjIGluIG9uZSBkb2N1bWVudCB0aGF0IGluY2x1ZGVzIHRo ZSBzZWN1cml0eSBhbmQgaW1wbGVtZW50YXRpb24gcmVjb21tZW5kYXRpb25zLg0KDQpBbHRlcm5h dGl2ZSB0aXRsZTogT0F1dGgsIFRoZSBHb29kIFBhcnRzLiA6KQ0KDQrigJQgRGljaw0KDQoNCg0K DQpPbiA0LzcvMTYsIDM6MjUgUE0sIHNvbWVvbmUgY2xhaW1pbmcgdG8gYmUgIk9BdXRoIG9uIGJl aGFsZiBvZiBNaWtlIEpvbmVzIiA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yg TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPiB3cm90ZToNCg0KWWVzIC0gYW4gaW50ZW50aW9u YWxseSBjb25zZXJ2YXRpdmUsIGltcGxlbWVudGF0aW9uLSBhbmQgZXhwZXJpZW5jZS1kcml2ZW4g cGF0aC4NCg0KUmV2aXNpbmcgT0F1dGggMi4wIGlzIGEgKmJpZyBkZWFsKi4gIFdlIHNob3VsZG4n dCBldmVuIGJlIHRhbGtpbmcgYWJvdXQgaXQgdW50aWwgd2UndmUgY29tcGxldGVkIHN0ZXBzIDEt NSBiZWxvdyAtICppbmNsdWRpbmcqIHRoZSAiaXRlcmF0ZSIgc3RlcCwgYXMgbmVjZXNzYXJ5LiAg SWYgd2UgZ2V0IHRoaXMgd3JvbmcsIHdlJ2xsIGZyYWdtZW50IE9BdXRoLCB3aGljaCBpcyBhIHRl cnJpYmxlIGFuZCBpcnJlc3BvbnNpYmxlIG91dGNvbWUgd2Ugc2hvdWxkIGNvbnNjaW91c2x5IGF2 b2lkIGF0IGFsbCBjb3N0cy4NCg0KSW4gcGFydGljdWxhciwgd2Ugc2hvdWxkIG5vdCByZWNoYXJ0 ZXIgZm9yIGFuIE9BdXRoIDIuMSB1bnRpbCB3ZSBhbHJlYWR5IGtub3cgd2hhdCB3aWxsIGJlIGlu IGl0IGFuZCBrbm93IGZyb20gZGVwbG95bWVudCBleHBlcmllbmNlIHRoYXQgaXQncyB0aGUgcmln aHQgc3R1ZmYuDQoNCgkJCQktLSBNaWtlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBUb3JzdGVuIExvZGRlcnN0ZWR0IFttYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXRd IA0KU2VudDogVGh1cnNkYXksIEFwcmlsIDcsIDIwMTYgMzoxNiBQTQ0KVG86IE1pa2UgSm9uZXMg PE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4NCkNjOiBTYW11ZWwgRXJkdG1hbiA8c2FtdWVs QGVyZHRtYW4uc2U+OyBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0LmNvbT47IG9h dXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjENCg0KSGkgTWlr ZSwNCg0KaW4gbXkgb3BpbmlvbiwgeW91IGRlc2NyaWJlZCBhIHBvc3NpYmxlIHBhdGggdG93YXJk cyAyLjEuIFdvdWxkIHlvdSBhZ3JlZT8NCg0KYmVzdCByZWdhcmRzLA0KVG9yc3Rlbi4NCg0KPiBB bSAwNy4wNC4yMDE2IHVtIDEzOjM4IHNjaHJpZWIgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0Bt aWNyb3NvZnQuY29tPjoNCj4gDQo+IEkgYW0gc3Ryb25nbHkgYWdhaW5zdCBjcmVhdGluZyBhIDIu MSBzcGVjIHVudGlsIHdlIGhhdmUgYXQgbGVhc3QgYSB5ZWFyIG9mIGRlcGxveW1lbnQgZXhwZXJp ZW5jZSB3aXRoIHRoZSBjb250ZW50cyB3ZSdyZSBhZGRpbmcgdG8gMi4wLCBzbyBhcyBub3QgdG8g ZnJhZ21lbnQgdGhlIE9BdXRoIG1hcmtldHBsYWNlLg0KPiANCj4gSSB0aGluayB3ZSBzaG91bGQ6 DQo+IDEuICBDb250aW51ZSB3b3JraW5nIG9uIG5ldyBzZWN1cml0eSBtaXRpZ2F0aW9ucyBpbiBu ZXcgZHJhZnRzIChzdWNoIA0KPiBhcyBtaXgtdXAtbWl0aWdhdGlvbiwgZXRjLikgdGhhdCBhZGQg ZmVhdHVyZXMgdG8gdXNlIHdpdGggMi4wIDIuICANCj4gQ29udGludWUgd29ya2luZyBvbiBQb1Ag c3BlY3MgKHN1Y2ggYXMgcG9wLWtleS1kaXN0cmlidXRpb24sIGV0Yy4pIA0KPiB0aGF0IGFkZCBm ZWF0dXJlcyB0byB1c2Ugd2l0aCAyLjAgMy4gIENvbnRpbnVlIHdvcmtpbmcgb24gb3RoZXIgbmV3 IA0KPiBzcGVjcyAoc3VjaCBhcyBkaXNjb3ZlcnksIHJlc291cmNlLWluZGljYXRvcnMsIGV0Yy4p IHRoYXQgYWRkIGZlYXR1cmVzIA0KPiB0byB1c2Ugd2l0aCAyLjAgNC4gIExlYXJuIGZyb20gZGVw bG95bWVudCBleHBlcmllbmNlIHdpdGggYWxsIG9mIHRoZW0gDQo+IDUuICBJdGVyYXRlIGlmIHRo ZSBkZXBsb3ltZW50IGV4cGVyaWVuY2UgdGVsbHMgdXMgdGhhdCB3ZSBuZWVkIHRvDQo+IA0KPiBP bmx5IGFmdGVyIHdlIGJlbGlldmUgd2UgaGF2ZSBhbGwgdGhlIGZlYXR1cmVzIHJpZ2h0IGFuZCB3 ZSBrbm93IHRoYXQgdGhleSB3b3JrIHRvZ2V0aGVyIHdlbGwgc2hvdWxkIHdlIGNvbnNpZGVyIGNy ZWF0aW5nIGEgMi4xLiAgSWYgd2UgcnVzaCB0byBhIDIuMSBhbmQgZ2V0IGl0IHdyb25nLCB3ZSds bCBsb3NlIGRldmVsb3BlcnMnIHRydXN0IGFuZCB3ZSdsbCBuZXZlciBnZXQgaXQgYmFjay4NCj4g DQo+ICAgICAgICAgICAgICAgIC0tIE1pa2UNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIFNhbXVlbCANCj4gRXJkdG1hbg0KPiBTZW50OiBUaHVyc2RheSwgQXByaWwgNywgMjAx NiAxMjo0OCBQTQ0KPiBUbzogQW50aG9ueSBOYWRhbGluIDx0b255bmFkQG1pY3Jvc29mdC5jb20+ DQo+IENjOiBvYXV0aEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCAy LjENCj4gDQo+ICsxIG9uIGEgMi4xIHZlcnNpb24NCj4gDQo+IC0xIG9uIGRlZmluaW5nIHNjb3Bl cyBtb3JlIHByZWNpc2VseSBpbiAyLjENCj4gDQo+IFNlbnQgZnJvbSBteSBpUGhvbmUNCj4gDQo+ PiBPbiA3IGFwci4gMjAxNiwgYXQgMTQ6NDYsIEFudGhvbnkgTmFkYWxpbiA8dG9ueW5hZEBtaWNy b3NvZnQuY29tPiB3cm90ZToNCj4+IA0KPj4gSSBkb24ndCBiZWxpdmUgdGhhdCBzY29wZXMgc2hv dWxkIGJlIGRlZmluZWQgbW9yZSBwcmVjaXNlbHkgYXMgdGhpcyBvcGFxdWVuZXNzIHdhcyBhIGRl c2lnbiBmZWF0dXJlLCBJJ20gbm90IHNlZWluZyB0aGUgcmVhc29uIHdoeSBzY29wZXMgbmVlZCB0 byBiZSBkZWZpbmVkLCBhcyB0aGVzZSBhcmUgYXBwbGljYXRpb24gc3BlY2lmaWMuDQo+PiANCj4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRo LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUb3JzdGVuIA0KPj4gTG9kZGVyc3RlZHQN Cj4+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCA3LCAyMDE2IDU6MzIgQU0NCj4+IFRvOiBHZW9yZ2Ug RmxldGNoZXIgPGdmZmxldGNoQGFvbC5jb20+DQo+PiBDYzogb2F1dGhAaWV0Zi5vcmcNCj4+IFN1 YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMQ0KPj4gDQo+PiBIaSBhbGwsDQo+PiANCj4+ IGFzIEkgYWxyZWFkeSBzYWlkIGluIHRoZSBtZWV0aW5nOiBJIHdvdWxkIHZlcnkgbXVjaCBwcmVm ZXIgdG8gaGF2ZSBhbiBleHRlbnNpb24vdXBkYXRlIG9mIFJGQyA2ODE5IGNvdmVyaW5nIGFsbCAi bmV3IiB0aHJlYXRzLCBpbmNsdWRpbmc6DQo+PiAtIG1peCB1cA0KPj4gLSBjb2RlIGluamVjdGlv biBha2EgY29weSBhbmQgcGFzdGUNCj4+IC0gb3BlbiByZWRpcmVjdG9yIGF0IEFTIGFuZCBjbGll bnQNCj4+IC0gcG90ZW50aWFsIG90aGVyIHRocmVhdHMgaW4gdGhlIGNvbnRleHQgb2YgImR5bmFt aWMiIE9BdXRoDQo+PiANCj4+IEkgYWxzbyBhc3N1bWUgbWl0aWdhdGlvbnMgZm9yIChhdCBsZWFz dCBzb21lIG9mKSB0aGUgdGhyZWF0cyBuZWVkIHRvIGdvIGludG8gYW4gdXBkYXRlIG9mIFJGQyA2 NzQ5IGFzIG5vcm1hdGl2ZSB0ZXh0LiBUbyBnaXZlIGFuIGV4YW1wbGU6IGlmIHdlIGFncmVlIG9u IHVzaW5nIHRoZSBzdGF0ZSBwYXJhbWV0ZXIgYXQgdGhlIHRva2VuIGVuZHBvaW50IHRvIG1pdGln YXRlIGNvZGUgaW5qZWN0aW9uLCB0aGlzIE1VU1QgYmUgcGFydCBvZiB0aGUgY29yZSBzcGVjIChy ZXF1ZXN0IGRlc2NyaXB0aW9uIGFuZCBzZWN1cml0eSBjb25zb2RlcmF0aW9ucykuIE90aGVyd2lz ZSwgbm9vbmUgd2lsbCBldmVuICBjb25zaWRlciBpdC4NCj4+IA0KPj4gV2Ugc2hvdWxkIGFsc28g dXNlIHRoZSBvcHBvcnR1bml0eSB0byBpbXByb3ZlL2VuaGFuY2UgdGhlIHRleHQgb2YgdGhlIHNw ZWMuIEluIHRoZSBjb3Vyc2Ugb2YgdGhlIGxhc3QgeWVhcnMsIHdlIGhhdmUgbGVhcm5lZCBhIGxv dCBhYm91dCBhbWJpcXVpdGllcyBvZiB0aGUgdGV4dCBhbmQgaG93IGRpZmZlcmVudCBpbXBsZW1l bnRhdGlvbnMgdXRpbGl6ZSBPQXV0aC4gDQo+PiANCj4+IEkgdGhpbmsgdGltZSBpcyByaWdodCB0 byBkZWZpbmUgc2NvcGVzIG1vcmUgcHJlY2lzZWx5LiBBcyB0aGUgZGlzY3Vzc2lvbnMgaW4gdGhl IGxhc3QgZGF5cyBwcm92ZWQgYWdhaW4gKGF0IGxlYXN0IGZvciBtZSksIHNjb3BlIGlzIG5vdCBz dWZmaWNpZW50bHkgZGVmaW5lZCB0byBjb21lIHVwIHdpdGggaW50ZXJvcGVyYWJsZSBpbXBsZW1l bnRhdGlvbnMuIEFkZGl0aW9uYWxseSwgdGhlcmUgc2VlbXMgdG8gYmUgYSBuZWVkIHRvIHJlcHJl c2VudCByZXNvdXJjZSBzZXJ2ZXIgbG9jYXRpb25zICh0byBub3Qgc2F5IGlkZW50aXRpZXMgOi0p KSBpbiB0aGlzIGNvbnRleHQuDQo+PiANCj4+IFRvIGJ1bmRsZSBhbGwgY2hhbmdlcyBpbiBhIHZl cnNpb24gMi4xIHdvdWxkIGFsc28gbWFrZSBjb21tdW5pY2F0aW9uIGludG8gdGhlIG1hcmtldCBt dWNoIGVhc2llci4gDQo+PiANCj4+IGJlc3QgcmVnYXJkcywNCj4+IFRvcnN0ZW4uDQo+PiANCj4+ PiBBbSAwNi4wNC4yMDE2IHVtIDE2OjA1IHNjaHJpZWIgR2VvcmdlIEZsZXRjaGVyIDxnZmZsZXRj aEBhb2wuY29tPjoNCj4+PiANCj4+PiBJJ2QgZGVmaW5pdGVseSBwcmVmZXIgYSBzaW5nbGUgc29s dXRpb24gZG9jdW1lbnQgdG8gbWFueSBsaXR0bGUgb25lcyB0aGF0IGhhdmUgdG8gYmUgY29tYmlu ZWQgdG8gYWN0dWFsbHkgYnVpbGQgYSBzZWN1cmUgc29sdXRpb24uIEl0J3MgYWxyZWFkeSBnZXR0 aW5nIGNvbXBsZXggd2l0aCB0aGUgYWRkaXRpb25hbCBzcGVjcyB0aGF0IGhhdmUgYmVlbiBhZGRl ZC4NCj4+PiANCj4+PiBBZGRpdGlvbmFsbHksIEknbSBub3QgYWdhaW5zdCB3b3JraW5nIG9uIE9B dXRoIDIuMS4NCj4+PiANCj4+PiBUaGFua3MsDQo+Pj4gR2VvcmdlDQo+Pj4gDQo+Pj4+IE9uIDQv Ni8xNiAyOjA2IFBNLCBQaGlsIEh1bnQgKElETSkgd3JvdGU6DQo+Pj4+IA0KPj4+PiBFeGlzdGlu ZyBpbXBsZW1lbnRhdGlvbnMgYXJlIGZvciB0aGUgbGFyZ2UgcGFydCBvayBhbmQgZG8gbm90IG5l ZWQgdGhlc2UgbWl0aWdhdGlvbnMuDQo+Pj4+IA0KPj4+PiBPbmx5IHRoZSBuZXcgdXNlIGNhc2Vz IHdlIGhhdmUgYmVlbiBkaXNjdXNzaW5nIChjb25maWd1cmUgb24gdGhlIGZseSBhbmQgbXVsdGkt YXMsIGV0YykgcmVhbGx5IG5lZWQgbWl0aWdhdGlvbi4NCj4+Pj4gDQo+Pj4+IFRoZSB1cGRhdGVk IGJ5IGFwcHJvYWNoIHNlZW1zIGxpa2UgYSBnb29kIHdheSB0byBhZGRyZXNzIHRoZSBuZXcgY2Fz ZXMuDQo+Pj4+IA0KPj4+PiBQaGlsDQo+Pj4+IA0KPj4+Pj4gT24gQXByIDYsIDIwMTYsIGF0IDE0 OjM1LCBIYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4gd3JvdGU6 DQo+Pj4+PiANCj4+Pj4+IEhpIGFsbCwNCj4+Pj4+IA0KPj4+Pj4gdG9kYXkgd2UgZGlzY3Vzc2Vk IHRoZSBPQXV0aCBBdXRob3JpemF0aW9uIFNlcnZlciBNaXh1cCBkcmFmdC4gV2UgDQo+Pj4+PiB3 ZXJlIHdvbmRlcmluZyB3aGF0IHR5cGVzIG9mIHRocmVhdHMgdGhlIGRvY3VtZW50IHNob3VsZCBm aW5kIHNvbHV0aW9ucyBmb3IuDQo+Pj4+PiANCj4+Pj4+IFdlIGRpc2N1c3NlZCB2YXJpb3VzIGRv Y3VtZW50IGhhbmRsaW5nIGFwcHJvYWNoZXMgaW5jbHVkaW5nDQo+Pj4+PiAqIE9BdXRoIE1peC1V cCBhbmQgQ3V0LWFuZC1QYXN0ZSBhdHRhY2tzIGRvY3VtZW50ZWQgaW4gc2VwYXJhdGUgDQo+Pj4+ PiBzb2x1dGlvbiBkb2N1bWVudHMNCj4+Pj4+ICogY29tYmluZWQgc29sdXRpb24gZG9jdW1lbnQg Y292ZXJpbmcgdGhlIE9BdXRoIE1peC1VcCBhbmQgdGhlIA0KPj4+Pj4gQ3V0LWFuZC1QYXN0ZSBh dHRhY2tzLg0KPj4+Pj4gDQo+Pj4+PiBCYXJyeSBwb2ludGVkIG91dCB0aGF0IHRoZXNlIGRvY3Vt ZW50cyBjb3VsZCB1cGRhdGUgdGhlIE9BdXRoIGJhc2UgDQo+Pj4+PiBzcGVjaWZpY2F0aW9uLg0K Pj4+Pj4gDQo+Pj4+PiBBcyBhIG1vcmUgcmFkaWNhbCBjaGFuZ2UgaXQgd2FzIGFsc28gc3VnZ2Vz dGVkIHRvIHJldmlzZSBSRkMgNjc0OSANCj4+Pj4+ICJPQXV0aA0KPj4+Pj4gMi4wIEF1dGhvcml6 YXRpb24gRnJhbWV3b3JrIiBhbmQgUkZDIDY4MTkgIk9BdXRoIDIuMCBUaHJlYXQgTW9kZWwgDQo+ Pj4+PiBhbmQgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMiLg0KPj4+Pj4gDQo+Pj4+PiBPcGVuaW5n IHVwIHRoZSBPQXV0aCBiYXNlIHNwZWNpZmljYXRpb24gb2J2aW91c2x5IHJhaXNlcyB2YXJpb3Vz IA0KPj4+Pj4gb3RoZXIgcXVlc3Rpb25zIGFib3V0IGNsZWFuaW5nIHVwIHBhcnRzIHRoYXQgZ28g ZmFyIGJleW9uZCB0aGUgQVMgDQo+Pj4+PiBtaXgtdXAgYW5kIHRoZSBjdXQtYW5kLXBhc3RlIGF0 dGFja3MuIE90aGVyIHNwZWNpZmljYXRpb25zLCBzdWNoIA0KPj4+Pj4gYXMgdGhlIE9wZW4gUmVk aXJlY3RvciwgY291bGQgYmUgZm9sZGVkIGludG8gc3VjaCBhIG5ldyBzcGVjaWZpY2F0aW9uLg0K Pj4+Pj4gDQo+Pj4+PiBEZXJlayBhbmQgSSB3b3VsZCBhcHByZWNpYXRlIHlvdXIgaW5wdXQgb24g dGhpcyB0b3BpYyBiZWZvcmUgd2UgDQo+Pj4+PiBtYWtlIGEgZGVjaXNpb24gc2luY2UgaXQgaGFz IHNpZ25pZmljYW50IGltcGFjdCBvbiBvdXIgd29yay4NCj4+Pj4+IA0KPj4+Pj4gQ2lhbw0KPj4+ Pj4gSGFubmVzICYgRGVyZWsNCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gT0F1dGggbWFpbGluZyBsaXN0 DQo+Pj4+PiBPQXV0aEBpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90 ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3DQo+Pj4+PiB3DQo+Pj4+PiB3 DQo+Pj4+PiAuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZkYXRhPTAxJTdj MDElN2N0b255bmFkJTQwbWkNCj4+Pj4+IGMNCj4+Pj4+IHINCj4+Pj4+IG9zb2Z0LmNvbSU3Y2Nl OGM5NDJiZWQ4MTQzN2FjYTA0MDhkMzVlZTBiZTIxJTdjNzJmOTg4YmY4NmYxNDFhZjkxYQ0KPj4+ Pj4gYg0KPj4+Pj4gMg0KPj4+Pj4gZDdjZDAxMWRiNDclN2MxJnNkYXRhPUJxY0U5ZURobThwZ2Rv aXRyUEZ1Zm91eFM2cVluZG5rTGdMYTVTUGsySEklDQo+Pj4+PiAzDQo+Pj4+PiBkDQo+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IE9BdXRo IG1haWxpbmcgbGlzdA0KPj4+PiBPQXV0aEBpZXRmLm9yZw0KPj4+PiBodHRwczovL25hMDEuc2Fm ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy4NCj4+ Pj4gaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZkYXRhPTAxJTdjMDElN2N0 b255bmFkJTQwbWljcg0KPj4+PiBvDQo+Pj4+IHMNCj4+Pj4gb2Z0LmNvbSU3Y2NlOGM5NDJiZWQ4 MTQzN2FjYTA0MDhkMzVlZTBiZTIxJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZA0KPj4+PiA3IGMg DQo+Pj4+IGQwMTFkYjQ3JTdjMSZzZGF0YT1CcWNFOWVEaG04cGdkb2l0clBGdWZvdXhTNnFZbmRu a0xnTGE1U1BrMkhJJTNkDQo+Pj4gDQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+PiBPQXV0aEBpZXRm Lm9yZw0KPj4+IGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHBzJTNhJTJmJTJmd3d3Lg0KPj4+IGkNCj4+PiBldGYub3JnJTJmbWFpbG1hbiUyZmxp c3RpbmZvJTJmb2F1dGgmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvcw0KPj4+IG8NCj4+ PiBmDQo+Pj4gdC5jb20lN2NjZThjOTQyYmVkODE0MzdhY2EwNDA4ZDM1ZWUwYmUyMSU3YzcyZjk4 OGJmODZmMTQxYWY5MWFiMmQ3Y2QNCj4+PiAwDQo+Pj4gMSAxZGI0NyU3YzEmc2RhdGE9QnFjRTll RGhtOHBnZG9pdHJQRnVmb3V4UzZxWW5kbmtMZ0xhNVNQazJISSUzZA0KPj4gDQo+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gT0F1dGggbWFpbGlu ZyBsaXN0DQo+PiBPQXV0aEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90 ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuDQo+PiBpIA0KPj4gZXRm Lm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQl NDBtaWNyb3NvDQo+PiBmDQo+PiB0LmNvbSU3Y2NlOGM5NDJiZWQ4MTQzN2FjYTA0MDhkMzVlZTBi ZTIxJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDANCj4+IDEgMWRiNDclN2MxJnNkYXRhPUJx Y0U5ZURobThwZ2RvaXRyUEZ1Zm91eFM2cVluZG5rTGdMYTVTUGsySEklM2QNCj4+IA0KPj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IE9BdXRoIG1h aWxpbmcgbGlzdA0KPj4gT0F1dGhAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGgNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPQXV0aCBt YWlsaW5nIGxpc3QNCj4gT0F1dGhAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZw0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo= From nobody Thu Apr 7 11:56:50 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E860E12D6E6 for ; Thu, 7 Apr 2016 11:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGs3d2LWjwLQ for ; Thu, 7 Apr 2016 11:56:31 -0700 (PDT) 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 AAB5F12D6C1 for ; Thu, 7 Apr 2016 11:56:31 -0700 (PDT) Received: by mail-ob0-x231.google.com with SMTP id tz8so53378461obc.0 for ; Thu, 07 Apr 2016 11:56:31 -0700 (PDT) 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; bh=bjwX57VP2bEhhDRAg2vEghBtCYtiLpMb+hKuEW61SpI=; b=RHNODZwWgyFiLF0dzcAyc7xsoMkgJFcLTLM7IreXxtpDSINd63TeivIpYWEvojsciD qXWMjp/PZWrp6b6HWvK7vOYi5KNjKboIAvpgAeWVtdpR2jYMhwPyg5eQXTya8ksSbm/H QlaHU2Xa7ULG7FZxFowPSySVatSnFrlBFXSEjlEDh42IwxAc1hZMDwQ4KhJV6cA/h/iQ YIepRH7SE4wp4SV4I9oFmqZOFbasG8A92VNWQE4CqLb6EjwwB2o5/ov4F8hqXrqYGqcu IbUnq2QqqGvid1OWeqze8ojBzSvkMoTOaFrvE0tWgrjuzObG7qWRNeciuhP8zDi3VXoA KX9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bjwX57VP2bEhhDRAg2vEghBtCYtiLpMb+hKuEW61SpI=; b=UDMm5ON+DmVFc+6ofJ49d1fPDD6A+gP2ZfIBi31UM6Vql+nGNcwkjYvIxOdK7okPMY Kujgvcsmgcjmn+3SrqB5HXd8aSfpkraXUuMdRNeEMffthTVme9VI+WnKRQpYxobVkfGd 2y+hZx7n0SJQHwktorO8Q49LMXZ8LKjNoz/q6b/WSshRuGIDxXPBuiByNmVUCAO+e79D d7jABRMllocMgjaS+nilK5geMCvrsjQLB8uIWic+aQpCGv4NPO7zxg/gdmB0dH0Wzdjc d1cttMnTmEgfVdlXzMqgSAuiGrDPO/9Rb/I+ch8sQo0nHA7Rm20jP5peN/97AWSn5/Iu +EZA== X-Gm-Message-State: AD7BkJIYHgKO8skYl/Hde568mYSBpauR4uSgDHC8z2dyy1gXb2HON5ojrSwoKVRLqM5fUh6uaSMHuHq+vHI0Ms7g X-Received: by 10.60.138.9 with SMTP id qm9mr2286222oeb.80.1460055390895; Thu, 07 Apr 2016 11:56:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.79.233 with HTTP; Thu, 7 Apr 2016 11:56:11 -0700 (PDT) In-Reply-To: References: <570548D6.8010605@gmx.net> <57055DE2.50201@aol.com> <7A8E4B64-4741-4A54-84D6-B887690F77B5@erdtman.se> From: William Denniss Date: Thu, 7 Apr 2016 15:56:11 -0300 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=047d7b2ed5bdedab4d052fe9a2d4 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 18:56:49 -0000 --047d7b2ed5bdedab4d052fe9a2d4 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 7, 2016 at 3:25 PM, Mike Jones wrote: > Yes - an intentionally conservative, implementation- and experience-driven > path. > > Revising OAuth 2.0 is a *big deal*. We shouldn't even be talking about it > until we've completed steps 1-5 below - *including* the "iterate" step, as > necessary. If we get this wrong, we'll fragment OAuth, which is a terrible > and irresponsible outcome we should consciously avoid at all costs. > > In particular, we should not recharter for an OAuth 2.1 until we already > know what will be in it and know from deployment experience that it's the > right stuff. > > -- Mike I agree with Mike, it's too soon to consider a 2.1 rev until we've had a chance to test and iterate on the current incremental additions. At some point it would make sense to collect the ones that worked and were widely deployed into a single doc. > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Thursday, April 7, 2016 3:16 PM > To: Mike Jones > Cc: Samuel Erdtman ; Anthony Nadalin < > tonynad@microsoft.com>; oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.1 > > Hi Mike, > > in my opinion, you described a possible path towards 2.1. Would you agree? > > best regards, > Torsten. > > > Am 07.04.2016 um 13:38 schrieb Mike Jones : > > > > I am strongly against creating a 2.1 spec until we have at least a year > of deployment experience with the contents we're adding to 2.0, so as not > to fragment the OAuth marketplace. > > > > I think we should: > > 1. Continue working on new security mitigations in new drafts (such > > as mix-up-mitigation, etc.) that add features to use with 2.0 2. > > Continue working on PoP specs (such as pop-key-distribution, etc.) > > that add features to use with 2.0 3. Continue working on other new > > specs (such as discovery, resource-indicators, etc.) that add features > > to use with 2.0 4. Learn from deployment experience with all of them > > 5. Iterate if the deployment experience tells us that we need to > > > > Only after we believe we have all the features right and we know that > they work together well should we consider creating a 2.1. If we rush to a > 2.1 and get it wrong, we'll lose developers' trust and we'll never get it > back. > > > > -- Mike > > > > -----Original Message----- > > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Samuel > > Erdtman > > Sent: Thursday, April 7, 2016 12:48 PM > > To: Anthony Nadalin > > Cc: oauth@ietf.org > > Subject: Re: [OAUTH-WG] OAuth 2.1 > > > > +1 on a 2.1 version > > > > -1 on defining scopes more precisely in 2.1 > > > > Sent from my iPhone > > > >> On 7 apr. 2016, at 14:46, Anthony Nadalin > wrote: > >> > >> I don't belive that scopes should be defined more precisely as this > opaqueness was a design feature, I'm not seeing the reason why scopes need > to be defined, as these are application specific. > >> > >> -----Original Message----- > >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten > >> Lodderstedt > >> Sent: Thursday, April 7, 2016 5:32 AM > >> To: George Fletcher > >> Cc: oauth@ietf.org > >> Subject: Re: [OAUTH-WG] OAuth 2.1 > >> > >> Hi all, > >> > >> as I already said in the meeting: I would very much prefer to have an > extension/update of RFC 6819 covering all "new" threats, including: > >> - mix up > >> - code injection aka copy and paste > >> - open redirector at AS and client > >> - potential other threats in the context of "dynamic" OAuth > >> > >> I also assume mitigations for (at least some of) the threats need to go > into an update of RFC 6749 as normative text. To give an example: if we > agree on using the state parameter at the token endpoint to mitigate code > injection, this MUST be part of the core spec (request description and > security consoderations). Otherwise, noone will even consider it. > >> > >> We should also use the opportunity to improve/enhance the text of the > spec. In the course of the last years, we have learned a lot about > ambiquities of the text and how different implementations utilize OAuth. > >> > >> I think time is right to define scopes more precisely. As the > discussions in the last days proved again (at least for me), scope is not > sufficiently defined to come up with interoperable implementations. > Additionally, there seems to be a need to represent resource server > locations (to not say identities :-)) in this context. > >> > >> To bundle all changes in a version 2.1 would also make communication > into the market much easier. > >> > >> best regards, > >> Torsten. > >> > >>> Am 06.04.2016 um 16:05 schrieb George Fletcher : > >>> > >>> I'd definitely prefer a single solution document to many little ones > that have to be combined to actually build a secure solution. It's already > getting complex with the additional specs that have been added. > >>> > >>> Additionally, I'm not against working on OAuth 2.1. > >>> > >>> Thanks, > >>> George > >>> > >>>> On 4/6/16 2:06 PM, Phil Hunt (IDM) wrote: > >>>> > >>>> Existing implementations are for the large part ok and do not need > these mitigations. > >>>> > >>>> Only the new use cases we have been discussing (configure on the fly > and multi-as, etc) really need mitigation. > >>>> > >>>> The updated by approach seems like a good way to address the new > cases. > >>>> > >>>> Phil > >>>> > >>>>> On Apr 6, 2016, at 14:35, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > >>>>> > >>>>> Hi all, > >>>>> > >>>>> today we discussed the OAuth Authorization Server Mixup draft. We > >>>>> were wondering what types of threats the document should find > solutions for. > >>>>> > >>>>> We discussed various document handling approaches including > >>>>> * OAuth Mix-Up and Cut-and-Paste attacks documented in separate > >>>>> solution documents > >>>>> * combined solution document covering the OAuth Mix-Up and the > >>>>> Cut-and-Paste attacks. > >>>>> > >>>>> Barry pointed out that these documents could update the OAuth base > >>>>> specification. > >>>>> > >>>>> As a more radical change it was also suggested to revise RFC 6749 > >>>>> "OAuth > >>>>> 2.0 Authorization Framework" and RFC 6819 "OAuth 2.0 Threat Model > >>>>> and Security Considerations". > >>>>> > >>>>> Opening up the OAuth base specification obviously raises various > >>>>> other questions about cleaning up parts that go far beyond the AS > >>>>> mix-up and the cut-and-paste attacks. Other specifications, such > >>>>> as the Open Redirector, could be folded into such a new > specification. > >>>>> > >>>>> Derek and I would appreciate your input on this topic before we > >>>>> make a decision since it has significant impact on our work. > >>>>> > >>>>> Ciao > >>>>> Hannes & Derek > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> OAuth mailing list > >>>>> OAuth@ietf.org > >>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fw > >>>>> w > >>>>> w > >>>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40mi > >>>>> c > >>>>> r > >>>>> osoft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91a > >>>>> b > >>>>> 2 > >>>>> d7cd011db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI% > >>>>> 3 > >>>>> d > >>>> _______________________________________________ > >>>> OAuth mailing list > >>>> OAuth@ietf.org > >>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww. > >>>> ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40micr > >>>> o > >>>> s > >>>> oft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d > >>>> 7 c > >>>> d011db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww. > >>> i > >>> etf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40micros > >>> o > >>> f > >>> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd > >>> 0 > >>> 1 1db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww. > >> i > >> etf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microso > >> f > >> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd0 > >> 1 1db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d > >> > >> _______________________________________________ > >> OAuth mailing 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 > --047d7b2ed5bdedab4d052fe9a2d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Apr 7, 2016 at 3:25 PM, Mike Jones <Michael.Jones@micros= oft.com> wrote:
Yes - an intentionally co= nservative, implementation- and experience-driven path.

Revising OAuth 2.0 is a *big deal*.=C2=A0 We shouldn't even be talking = about it until we've completed steps 1-5 below - *including* the "= iterate" step, as necessary.=C2=A0 If we get this wrong, we'll fra= gment OAuth, which is a terrible and irresponsible outcome we should consci= ously avoid at all costs.

In particular, we should not recharter for an OAuth 2.1 until we already kn= ow what will be in it and know from deployment experience that it's the= right stuff.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =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
<= /div>
I agree with Mike, it's too soon to consider a 2.1 rev until = we've had a chance to test and iterate on the current incremental addit= ions.

At some point it would make sense to collect= the ones that worked and were widely deployed into a single doc.

=C2=A0
-----Original Message-----
From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Thursday, April 7, 2016 3:16 PM
To: Mike Jones <Michael.J= ones@microsoft.com>
Cc: Samuel Erdtman <samuel@erdtman.= se>; Anthony Nadalin <to= nynad@microsoft.com>; oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] OAuth 2.1

Hi Mike,

in my opinion, you described a possible path towards 2.1. Would you agree?<= br>
best regards,
Torsten.

> Am 07.04.2016 um 13:38 schrieb Mike Jones <Michael.Jones@microsoft.com>:
>
> I am strongly against creating a 2.1 spec until we have at least a yea= r of deployment experience with the contents we're adding to 2.0, so as= not to fragment the OAuth marketplace.
>
> I think we should:
> 1.=C2=A0 Continue working on new security mitigations in new drafts (s= uch
> as mix-up-mitigation, etc.) that add features to use with 2.0 2.
> Continue working on PoP specs (such as pop-key-distribution, etc.)
> that add features to use with 2.0 3.=C2=A0 Continue working on other n= ew
> specs (such as discovery, resource-indicators, etc.) that add features=
> to use with 2.0 4.=C2=A0 Learn from deployment experience with all of = them
> 5.=C2=A0 Iterate if the deployment experience tells us that we need to=
>
> Only after we believe we have all the features right and we know that = they work together well should we consider creating a 2.1.=C2=A0 If we rush= to a 2.1 and get it wrong, we'll lose developers' trust and we'= ;ll never get it back.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike
>
> -----Original Message-----
> From: OAuth [mailto:oauth-bo= unces@ietf.org] On Behalf Of Samuel
> Erdtman
> Sent: Thursday, April 7, 2016 12:48 PM
> To: Anthony Nadalin <tonyn= ad@microsoft.com>
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth 2.1
>
> +1 on a 2.1 version
>
> -1 on defining scopes more precisely in 2.1
>
> Sent from my iPhone
>
>> On 7 apr. 2016, at 14:46, Anthony Nadalin <tonynad@microsoft.com> wrote:
>>
>> I don't belive that scopes should be defined more precisely as= this opaqueness was a design feature, I'm not seeing the reason why sc= opes need to be defined, as these are application specific.
>>
>> -----Original Message-----
>> From: OAuth [mailto:oaut= h-bounces@ietf.org] On Behalf Of Torsten
>> Lodderstedt
>> Sent: Thursday, April 7, 2016 5:32 AM
>> To: George Fletcher <gfflet= ch@aol.com>
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] OAuth 2.1
>>
>> Hi all,
>>
>> as I already said in the meeting: I would very much prefer to have= an extension/update of RFC 6819 covering all "new" threats, incl= uding:
>> - mix up
>> - code injection aka copy and paste
>> - open redirector at AS and client
>> - potential other threats in the context of "dynamic" OA= uth
>>
>> I also assume mitigations for (at least some of) the threats need = to go into an update of RFC 6749 as normative text. To give an example: if = we agree on using the state parameter at the token endpoint to mitigate cod= e injection, this MUST be part of the core spec (request description and se= curity consoderations). Otherwise, noone will even=C2=A0 consider it.
>>
>> We should also use the opportunity to improve/enhance the text of = the spec. In the course of the last years, we have learned a lot about ambi= quities of the text and how different implementations utilize OAuth.
>>
>> I think time is right to define scopes more precisely. As the disc= ussions in the last days proved again (at least for me), scope is not suffi= ciently defined to come up with interoperable implementations. Additionally= , there seems to be a need to represent resource server locations (to not s= ay identities :-)) in this context.
>>
>> To bundle all changes in a version 2.1 would also make communicati= on into the market much easier.
>>
>> best regards,
>> Torsten.
>>
>>> Am 06.04.2016 um 16:05 schrieb George Fletcher <gffletch@aol.com>:
>>>
>>> I'd definitely prefer a single solution document to many l= ittle ones that have to be combined to actually build a secure solution. It= 's already getting complex with the additional specs that have been add= ed.
>>>
>>> Additionally, I'm not against working on OAuth 2.1.
>>>
>>> Thanks,
>>> George
>>>
>>>> On 4/6/16 2:06 PM, Phil Hunt (IDM) wrote:
>>>>
>>>> Existing implementations are for the large part ok and do = not need these mitigations.
>>>>
>>>> Only the new use cases we have been discussing (configure = on the fly and multi-as, etc) really need mitigation.
>>>>
>>>> The updated by approach seems like a good way to address t= he new cases.
>>>>
>>>> Phil
>>>>
>>>>> On Apr 6, 2016, at 14:35, Hannes Tschofenig <hannes.tschofenig@gmx.net> wr= ote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> today we discussed the OAuth Authorization Server Mixu= p draft. We
>>>>> were wondering what types of threats the document shou= ld find solutions for.
>>>>>
>>>>> We discussed various document handling approaches incl= uding
>>>>> * OAuth Mix-Up and Cut-and-Paste attacks documented in= separate
>>>>> solution documents
>>>>> * combined solution document covering the OAuth Mix-Up= and the
>>>>> Cut-and-Paste attacks.
>>>>>
>>>>> Barry pointed out that these documents could update th= e OAuth base
>>>>> specification.
>>>>>
>>>>> As a more radical change it was also suggested to revi= se RFC 6749
>>>>> "OAuth
>>>>> 2.0 Authorization Framework" and RFC 6819 "O= Auth 2.0 Threat Model
>>>>> and Security Considerations".
>>>>>
>>>>> Opening up the OAuth base specification obviously rais= es various
>>>>> other questions about cleaning up parts that go far be= yond the AS
>>>>> mix-up and the cut-and-paste attacks. Other specificat= ions, such
>>>>> as the Open Redirector, could be folded into such a ne= w specification.
>>>>>
>>>>> Derek and I would appreciate your input on this topic = before we
>>>>> make a decision since it has significant impact on our= work.
>>>>>
>>>>> Ciao
>>>>> Hannes & Derek
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org >>>>> https://na0= 1.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fw
>>>>> w
>>>>> w
>>>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7c= tonynad%40mi
>>>>> c
>>>>> r
>>>>> osoft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f1= 41af91a
>>>>> b
>>>>> 2
>>>>> d7cd011db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6= qYndnkLgLa5SPk2HI%
>>>>> 3
>>>>> d
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://na01.= safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.
>>>> ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonyn= ad%40micr
>>>> o
>>>> s
>>>> oft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab= 2d
>>>> 7 c
>>>> d011db47%7c1&sdata=3DBqcE9eDhm8pgdo= itrPFufouxS6qYndnkLgLa5SPk2HI%3d
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://na01.saf= elinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.
>>> i
>>> etf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40m= icros
>>> o
>>> f
>>> = t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd >>> 0
>>> 1 1db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5S= Pk2HI%3d
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://na01.safelink= s.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.
>> i
>> et= f.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40micro= so
>> f
>> t.co= m%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd0
>> 1 1db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2H= I%3d
>>
>> _______________________________________________
>> OAuth mailing 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

--047d7b2ed5bdedab4d052fe9a2d4-- From nobody Thu Apr 7 11:59:16 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE96812D5C5 for ; Thu, 7 Apr 2016 11:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8oVtVLmiC7V for ; Thu, 7 Apr 2016 11:59:09 -0700 (PDT) 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 0D85212D59F for ; Thu, 7 Apr 2016 11:59:08 -0700 (PDT) Received: from [80.187.100.164] (helo=[10.29.82.181]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1aoF8z-0000B9-3e; Thu, 07 Apr 2016 20:59:06 +0200 Date: Thu, 07 Apr 2016 15:58:58 -0300 Message-ID: In-Reply-To: References: <570548D6.8010605@gmx.net> <57055DE2.50201@aol.com> <7A8E4B64-4741-4A54-84D6-B887690F77B5@erdtman.se> From: "torsten@lodderstedt.net" To: Phil Hunt , Michael.Jones@microsoft.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.syntomo.email_3036477474667180" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 18:59:14 -0000 ----_com.syntomo.email_3036477474667180 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 QW5kIHdoYXQgYWJvdXQgY29kZSBpbmplY3Rpb24gYW5kIG9wZW4gcmVkaXJlY3RvcnM/IEkgdGhp bmsgd2UgYWxyZWFkeSBoYXZlIGEgbG90IG9mIGRlcGxveW1lbnQgZXhwZXJpZW5jZSB0aGF0IHNo b3VsZCBiZSB1c2VkIHRvIGV2b2x2ZSB0aGUgc3BlYy4KClNlbnQgYnkgTWFpbFdpc2Ug4oCTIFNl ZSB5b3VyIGVtYWlscyBhcyBjbGVhbiwgc2hvcnQgY2hhdHMuCgotLS0tLS0tLSBPcmlnaW5hbG5h Y2hyaWNodCAtLS0tLS0tLQpCZXRyZWZmOiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjEKVm9uOiAi UGhpbCBIdW50IChJRE0pIiA8cGhpbC5odW50QG9yYWNsZS5jb20+CkFuOiBNaWtlIEpvbmVzIDxN aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+CkNjOiBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3Jz dGVuQGxvZGRlcnN0ZWR0Lm5ldD4sb2F1dGhAaWV0Zi5vcmcKCj5JIGJlbGlldmUgYWxsIHdlIG5l ZWQgaXMgYSBuZXcgZHJhZnQgdGhhdCBkZWFscyB3aXRoIHRoZSBuZXcgImR5bmFtaWMvbWl4LXVw IiBjYXNlcyBhcyB0aGVzZSB3ZXJlIG5vdCBjb25zaWRlcmVkIGluIHRoZSBvcmlnaW5hbCBzcGVj IHByb2Nlc3MuIAo+Cj5UaGUgdXBkYXRlZCBieSBtZXRob2Qgd29ya3MgYmVzdCBmb3IgdGhpcy4g SXQgYWxzbyBjb25zb2xpZGF0ZXMgYSBsb3Qgb2YgcGllY2VtZWFsIHNwZWNzIGludG8gb25lIGNv bnNpc3RlbnQgc3BlYy4gCj4KPlBoaWwKPgo+PiBPbiBBcHIgNywgMjAxNiwgYXQgMTU6MjUsIE1p a2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4gd3JvdGU6Cj4+IAo+PiBZZXMg LSBhbiBpbnRlbnRpb25hbGx5IGNvbnNlcnZhdGl2ZSwgaW1wbGVtZW50YXRpb24tIGFuZCBleHBl cmllbmNlLWRyaXZlbiBwYXRoLgo+PiAKPj4gUmV2aXNpbmcgT0F1dGggMi4wIGlzIGEgKmJpZyBk ZWFsKi4gIFdlIHNob3VsZG4ndCBldmVuIGJlIHRhbGtpbmcgYWJvdXQgaXQgdW50aWwgd2UndmUg Y29tcGxldGVkIHN0ZXBzIDEtNSBiZWxvdyAtICppbmNsdWRpbmcqIHRoZSAiaXRlcmF0ZSIgc3Rl cCwgYXMgbmVjZXNzYXJ5LiAgSWYgd2UgZ2V0IHRoaXMgd3JvbmcsIHdlJ2xsIGZyYWdtZW50IE9B dXRoLCB3aGljaCBpcyBhIHRlcnJpYmxlIGFuZCBpcnJlc3BvbnNpYmxlIG91dGNvbWUgd2Ugc2hv dWxkIGNvbnNjaW91c2x5IGF2b2lkIGF0IGFsbCBjb3N0cy4KPj4gCj4+IEluIHBhcnRpY3VsYXIs IHdlIHNob3VsZCBub3QgcmVjaGFydGVyIGZvciBhbiBPQXV0aCAyLjEgdW50aWwgd2UgYWxyZWFk eSBrbm93IHdoYXQgd2lsbCBiZSBpbiBpdCBhbmQga25vdyBmcm9tIGRlcGxveW1lbnQgZXhwZXJp ZW5jZSB0aGF0IGl0J3MgdGhlIHJpZ2h0IHN0dWZmLgo+PiAKPj4gICAgICAgICAgICAgICAgLS0g TWlrZQo+PiAKPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KPj4gRnJvbTogVG9yc3RlbiBM b2RkZXJzdGVkdCBbbWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0XSAKPj4gU2VudDogVGh1 cnNkYXksIEFwcmlsIDcsIDIwMTYgMzoxNiBQTQo+PiBUbzogTWlrZSBKb25lcyA8TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tPgo+PiBDYzogU2FtdWVsIEVyZHRtYW4gPHNhbXVlbEBlcmR0bWFu LnNlPjsgQW50aG9ueSBOYWRhbGluIDx0b255bmFkQG1pY3Jvc29mdC5jb20+OyBvYXV0aEBpZXRm Lm9yZwo+PiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjEKPj4gCj4+IEhpIE1pa2Us Cj4+IAo+PiBpbiBteSBvcGluaW9uLCB5b3UgZGVzY3JpYmVkIGEgcG9zc2libGUgcGF0aCB0b3dh cmRzIDIuMS4gV291bGQgeW91IGFncmVlPwo+PiAKPj4gYmVzdCByZWdhcmRzLAo+PiBUb3JzdGVu Lgo+PiAKPj4+IEFtIDA3LjA0LjIwMTYgdW0gMTM6Mzggc2NocmllYiBNaWtlIEpvbmVzIDxNaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+Ogo+Pj4gCj4+PiBJIGFtIHN0cm9uZ2x5IGFnYWluc3Qg Y3JlYXRpbmcgYSAyLjEgc3BlYyB1bnRpbCB3ZSBoYXZlIGF0IGxlYXN0IGEgeWVhciBvZiBkZXBs b3ltZW50IGV4cGVyaWVuY2Ugd2l0aCB0aGUgY29udGVudHMgd2UncmUgYWRkaW5nIHRvIDIuMCwg c28gYXMgbm90IHRvIGZyYWdtZW50IHRoZSBPQXV0aCBtYXJrZXRwbGFjZS4KPj4+IAo+Pj4gSSB0 aGluayB3ZSBzaG91bGQ6Cj4+PiAxLiAgQ29udGludWUgd29ya2luZyBvbiBuZXcgc2VjdXJpdHkg bWl0aWdhdGlvbnMgaW4gbmV3IGRyYWZ0cyAoc3VjaCAKPj4+IGFzIG1peC11cC1taXRpZ2F0aW9u LCBldGMuKSB0aGF0IGFkZCBmZWF0dXJlcyB0byB1c2Ugd2l0aCAyLjAgMi4gIAo+Pj4gQ29udGlu dWUgd29ya2luZyBvbiBQb1Agc3BlY3MgKHN1Y2ggYXMgcG9wLWtleS1kaXN0cmlidXRpb24sIGV0 Yy4pIAo+Pj4gdGhhdCBhZGQgZmVhdHVyZXMgdG8gdXNlIHdpdGggMi4wIDMuICBDb250aW51ZSB3 b3JraW5nIG9uIG90aGVyIG5ldyAKPj4+IHNwZWNzIChzdWNoIGFzIGRpc2NvdmVyeSwgcmVzb3Vy Y2UtaW5kaWNhdG9ycywgZXRjLikgdGhhdCBhZGQgZmVhdHVyZXMgCj4+PiB0byB1c2Ugd2l0aCAy LjAgNC4gIExlYXJuIGZyb20gZGVwbG95bWVudCBleHBlcmllbmNlIHdpdGggYWxsIG9mIHRoZW0g Cj4+PiA1LiAgSXRlcmF0ZSBpZiB0aGUgZGVwbG95bWVudCBleHBlcmllbmNlIHRlbGxzIHVzIHRo YXQgd2UgbmVlZCB0bwo+Pj4gCj4+PiBPbmx5IGFmdGVyIHdlIGJlbGlldmUgd2UgaGF2ZSBhbGwg dGhlIGZlYXR1cmVzIHJpZ2h0IGFuZCB3ZSBrbm93IHRoYXQgdGhleSB3b3JrIHRvZ2V0aGVyIHdl bGwgc2hvdWxkIHdlIGNvbnNpZGVyIGNyZWF0aW5nIGEgMi4xLiAgSWYgd2UgcnVzaCB0byBhIDIu MSBhbmQgZ2V0IGl0IHdyb25nLCB3ZSdsbCBsb3NlIGRldmVsb3BlcnMnIHRydXN0IGFuZCB3ZSds bCBuZXZlciBnZXQgaXQgYmFjay4KPj4+IAo+Pj4gICAgICAgICAgICAgICAtLSBNaWtlCj4+PiAK Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4+PiBGcm9tOiBPQXV0aCBbbWFpbHRvOm9h dXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTYW11ZWwgCj4+PiBFcmR0bWFuCj4+ PiBTZW50OiBUaHVyc2RheSwgQXByaWwgNywgMjAxNiAxMjo0OCBQTQo+Pj4gVG86IEFudGhvbnkg TmFkYWxpbiA8dG9ueW5hZEBtaWNyb3NvZnQuY29tPgo+Pj4gQ2M6IG9hdXRoQGlldGYub3JnCj4+ PiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjEKPj4+IAo+Pj4gKzEgb24gYSAyLjEg dmVyc2lvbgo+Pj4gCj4+PiAtMSBvbiBkZWZpbmluZyBzY29wZXMgbW9yZSBwcmVjaXNlbHkgaW4g Mi4xCj4+PiAKPj4+IFNlbnQgZnJvbSBteSBpUGhvbmUKPj4+IAo+Pj4+IE9uIDcgYXByLiAyMDE2 LCBhdCAxNDo0NiwgQW50aG9ueSBOYWRhbGluIDx0b255bmFkQG1pY3Jvc29mdC5jb20+IHdyb3Rl Ogo+Pj4+IAo+Pj4+IEkgZG9uJ3QgYmVsaXZlIHRoYXQgc2NvcGVzIHNob3VsZCBiZSBkZWZpbmVk IG1vcmUgcHJlY2lzZWx5IGFzIHRoaXMgb3BhcXVlbmVzcyB3YXMgYSBkZXNpZ24gZmVhdHVyZSwg SSdtIG5vdCBzZWVpbmcgdGhlIHJlYXNvbiB3aHkgc2NvcGVzIG5lZWQgdG8gYmUgZGVmaW5lZCwg YXMgdGhlc2UgYXJlIGFwcGxpY2F0aW9uIHNwZWNpZmljLgo+Pj4+IAo+Pj4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tCj4+Pj4gRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgVG9yc3RlbiAKPj4+PiBMb2RkZXJzdGVkdAo+Pj4+IFNlbnQ6 IFRodXJzZGF5LCBBcHJpbCA3LCAyMDE2IDU6MzIgQU0KPj4+PiBUbzogR2VvcmdlIEZsZXRjaGVy IDxnZmZsZXRjaEBhb2wuY29tPgo+Pj4+IENjOiBvYXV0aEBpZXRmLm9yZwo+Pj4+IFN1YmplY3Q6 IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMQo+Pj4+IAo+Pj4+IEhpIGFsbCwKPj4+PiAKPj4+PiBh cyBJIGFscmVhZHkgc2FpZCBpbiB0aGUgbWVldGluZzogSSB3b3VsZCB2ZXJ5IG11Y2ggcHJlZmVy IHRvIGhhdmUgYW4gZXh0ZW5zaW9uL3VwZGF0ZSBvZiBSRkMgNjgxOSBjb3ZlcmluZyBhbGwgIm5l dyIgdGhyZWF0cywgaW5jbHVkaW5nOgo+Pj4+IC0gbWl4IHVwCj4+Pj4gLSBjb2RlIGluamVjdGlv biBha2EgY29weSBhbmQgcGFzdGUKPj4+PiAtIG9wZW4gcmVkaXJlY3RvciBhdCBBUyBhbmQgY2xp ZW50Cj4+Pj4gLSBwb3RlbnRpYWwgb3RoZXIgdGhyZWF0cyBpbiB0aGUgY29udGV4dCBvZiAiZHlu YW1pYyIgT0F1dGgKPj4+PiAKPj4+PiBJIGFsc28gYXNzdW1lIG1pdGlnYXRpb25zIGZvciAoYXQg bGVhc3Qgc29tZSBvZikgdGhlIHRocmVhdHMgbmVlZCB0byBnbyBpbnRvIGFuIHVwZGF0ZSBvZiBS RkMgNjc0OSBhcyBub3JtYXRpdmUgdGV4dC4gVG8gZ2l2ZSBhbiBleGFtcGxlOiBpZiB3ZSBhZ3Jl ZSBvbiB1c2luZyB0aGUgc3RhdGUgcGFyYW1ldGVyIGF0IHRoZSB0b2tlbiBlbmRwb2ludCB0byBt aXRpZ2F0ZSBjb2RlIGluamVjdGlvbiwgdGhpcyBNVVNUIGJlIHBhcnQgb2YgdGhlIGNvcmUgc3Bl YyAocmVxdWVzdCBkZXNjcmlwdGlvbiBhbmQgc2VjdXJpdHkgY29uc29kZXJhdGlvbnMpLiBPdGhl cndpc2UsIG5vb25lIHdpbGwgZXZlbiAgY29uc2lkZXIgaXQuCj4+Pj4gCj4+Pj4gV2Ugc2hvdWxk IGFsc28gdXNlIHRoZSBvcHBvcnR1bml0eSB0byBpbXByb3ZlL2VuaGFuY2UgdGhlIHRleHQgb2Yg dGhlIHNwZWMuIEluIHRoZSBjb3Vyc2Ugb2YgdGhlIGxhc3QgeWVhcnMsIHdlIGhhdmUgbGVhcm5l ZCBhIGxvdCBhYm91dCBhbWJpcXVpdGllcyBvZiB0aGUgdGV4dCBhbmQgaG93IGRpZmZlcmVudCBp bXBsZW1lbnRhdGlvbnMgdXRpbGl6ZSBPQXV0aC4gCj4+Pj4gCj4+Pj4gSSB0aGluayB0aW1lIGlz IHJpZ2h0IHRvIGRlZmluZSBzY29wZXMgbW9yZSBwcmVjaXNlbHkuIEFzIHRoZSBkaXNjdXNzaW9u cyBpbiB0aGUgbGFzdCBkYXlzIHByb3ZlZCBhZ2FpbiAoYXQgbGVhc3QgZm9yIG1lKSwgc2NvcGUg aXMgbm90IHN1ZmZpY2llbnRseSBkZWZpbmVkIHRvIGNvbWUgdXAgd2l0aCBpbnRlcm9wZXJhYmxl IGltcGxlbWVudGF0aW9ucy4gQWRkaXRpb25hbGx5LCB0aGVyZSBzZWVtcyB0byBiZSBhIG5lZWQg dG8gcmVwcmVzZW50IHJlc291cmNlIHNlcnZlciBsb2NhdGlvbnMgKHRvIG5vdCBzYXkgaWRlbnRp dGllcyA6LSkpIGluIHRoaXMgY29udGV4dC4KPj4+PiAKPj4+PiBUbyBidW5kbGUgYWxsIGNoYW5n ZXMgaW4gYSB2ZXJzaW9uIDIuMSB3b3VsZCBhbHNvIG1ha2UgY29tbXVuaWNhdGlvbiBpbnRvIHRo ZSBtYXJrZXQgbXVjaCBlYXNpZXIuIAo+Pj4+IAo+Pj4+IGJlc3QgcmVnYXJkcywKPj4+PiBUb3Jz dGVuLgo+Pj4+IAo+Pj4+PiBBbSAwNi4wNC4yMDE2IHVtIDE2OjA1IHNjaHJpZWIgR2VvcmdlIEZs ZXRjaGVyIDxnZmZsZXRjaEBhb2wuY29tPjoKPj4+Pj4gCj4+Pj4+IEknZCBkZWZpbml0ZWx5IHBy ZWZlciBhIHNpbmdsZSBzb2x1dGlvbiBkb2N1bWVudCB0byBtYW55IGxpdHRsZSBvbmVzIHRoYXQg aGF2ZSB0byBiZSBjb21iaW5lZCB0byBhY3R1YWxseSBidWlsZCBhIHNlY3VyZSBzb2x1dGlvbi4g SXQncyBhbHJlYWR5IGdldHRpbmcgY29tcGxleCB3aXRoIHRoZSBhZGRpdGlvbmFsIHNwZWNzIHRo YXQgaGF2ZSBiZWVuIGFkZGVkLgo+Pj4+PiAKPj4+Pj4gQWRkaXRpb25hbGx5LCBJJ20gbm90IGFn YWluc3Qgd29ya2luZyBvbiBPQXV0aCAyLjEuCj4+Pj4+IAo+Pj4+PiBUaGFua3MsCj4+Pj4+IEdl b3JnZQo+Pj4+PiAKPj4+Pj4+IE9uIDQvNi8xNiAyOjA2IFBNLCBQaGlsIEh1bnQgKElETSkgd3Jv dGU6Cj4+Pj4+PiAKPj4+Pj4+IEV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBhcmUgZm9yIHRoZSBs YXJnZSBwYXJ0IG9rIGFuZCBkbyBub3QgbmVlZCB0aGVzZSBtaXRpZ2F0aW9ucy4KPj4+Pj4+IAo+ Pj4+Pj4gT25seSB0aGUgbmV3IHVzZSBjYXNlcyB3ZSBoYXZlIGJlZW4gZGlzY3Vzc2luZyAoY29u ZmlndXJlIG9uIHRoZSBmbHkgYW5kIG11bHRpLWFzLCBldGMpIHJlYWxseSBuZWVkIG1pdGlnYXRp b24uCj4+Pj4+PiAKPj4+Pj4+IFRoZSB1cGRhdGVkIGJ5IGFwcHJvYWNoIHNlZW1zIGxpa2UgYSBn b29kIHdheSB0byBhZGRyZXNzIHRoZSBuZXcgY2FzZXMuCj4+Pj4+PiAKPj4+Pj4+IFBoaWwKPj4+ Pj4+IAo+Pj4+Pj4+IE9uIEFwciA2LCAyMDE2LCBhdCAxNDozNSwgSGFubmVzIFRzY2hvZmVuaWcg PGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+IHdyb3RlOgo+Pj4+Pj4+IAo+Pj4+Pj4+IEhpIGFs bCwKPj4+Pj4+PiAKPj4+Pj4+PiB0b2RheSB3ZSBkaXNjdXNzZWQgdGhlIE9BdXRoIEF1dGhvcml6 YXRpb24gU2VydmVyIE1peHVwIGRyYWZ0LiBXZSAKPj4+Pj4+PiB3ZXJlIHdvbmRlcmluZyB3aGF0 IHR5cGVzIG9mIHRocmVhdHMgdGhlIGRvY3VtZW50IHNob3VsZCBmaW5kIHNvbHV0aW9ucyBmb3Iu Cj4+Pj4+Pj4gCj4+Pj4+Pj4gV2UgZGlzY3Vzc2VkIHZhcmlvdXMgZG9jdW1lbnQgaGFuZGxpbmcg YXBwcm9hY2hlcyBpbmNsdWRpbmcKPj4+Pj4+PiAqIE9BdXRoIE1peC1VcCBhbmQgQ3V0LWFuZC1Q YXN0ZSBhdHRhY2tzIGRvY3VtZW50ZWQgaW4gc2VwYXJhdGUgCj4+Pj4+Pj4gc29sdXRpb24gZG9j dW1lbnRzCj4+Pj4+Pj4gKiBjb21iaW5lZCBzb2x1dGlvbiBkb2N1bWVudCBjb3ZlcmluZyB0aGUg T0F1dGggTWl4LVVwIGFuZCB0aGUgCj4+Pj4+Pj4gQ3V0LWFuZC1QYXN0ZSBhdHRhY2tzLgo+Pj4+ Pj4+IAo+Pj4+Pj4+IEJhcnJ5IHBvaW50ZWQgb3V0IHRoYXQgdGhlc2UgZG9jdW1lbnRzIGNvdWxk IHVwZGF0ZSB0aGUgT0F1dGggYmFzZSAKPj4+Pj4+PiBzcGVjaWZpY2F0aW9uLgo+Pj4+Pj4+IAo+ Pj4+Pj4+IEFzIGEgbW9yZSByYWRpY2FsIGNoYW5nZSBpdCB3YXMgYWxzbyBzdWdnZXN0ZWQgdG8g cmV2aXNlIFJGQyA2NzQ5IAo+Pj4+Pj4+ICJPQXV0aAo+Pj4+Pj4+IDIuMCBBdXRob3JpemF0aW9u IEZyYW1ld29yayIgYW5kIFJGQyA2ODE5ICJPQXV0aCAyLjAgVGhyZWF0IE1vZGVsIAo+Pj4+Pj4+ IGFuZCBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyIuCj4+Pj4+Pj4gCj4+Pj4+Pj4gT3BlbmluZyB1 cCB0aGUgT0F1dGggYmFzZSBzcGVjaWZpY2F0aW9uIG9idmlvdXNseSByYWlzZXMgdmFyaW91cyAK Pj4+Pj4+PiBvdGhlciBxdWVzdGlvbnMgYWJvdXQgY2xlYW5pbmcgdXAgcGFydHMgdGhhdCBnbyBm YXIgYmV5b25kIHRoZSBBUyAKPj4+Pj4+PiBtaXgtdXAgYW5kIHRoZSBjdXQtYW5kLXBhc3RlIGF0 dGFja3MuIE90aGVyIHNwZWNpZmljYXRpb25zLCBzdWNoIAo+Pj4+Pj4+IGFzIHRoZSBPcGVuIFJl ZGlyZWN0b3IsIGNvdWxkIGJlIGZvbGRlZCBpbnRvIHN1Y2ggYSBuZXcgc3BlY2lmaWNhdGlvbi4K Pj4+Pj4+PiAKPj4+Pj4+PiBEZXJlayBhbmQgSSB3b3VsZCBhcHByZWNpYXRlIHlvdXIgaW5wdXQg b24gdGhpcyB0b3BpYyBiZWZvcmUgd2UgCj4+Pj4+Pj4gbWFrZSBhIGRlY2lzaW9uIHNpbmNlIGl0 IGhhcyBzaWduaWZpY2FudCBpbXBhY3Qgb24gb3VyIHdvcmsuCj4+Pj4+Pj4gCj4+Pj4+Pj4gQ2lh bwo+Pj4+Pj4+IEhhbm5lcyAmIERlcmVrCj4+Pj4+Pj4gCj4+Pj4+Pj4gCj4+Pj4+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4+Pj4+PiBPQXV0aCBt YWlsaW5nIGxpc3QKPj4+Pj4+PiBPQXV0aEBpZXRmLm9yZwo+Pj4+Pj4+IGh0dHBzOi8vbmEwMS5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmdwo+Pj4+ Pj4+IHcKPj4+Pj4+PiB3Cj4+Pj4+Pj4gLmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJm b2F1dGgmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pCj4+Pj4+Pj4gYwo+Pj4+Pj4+IHIKPj4+ Pj4+PiBvc29mdC5jb20lN2NjZThjOTQyYmVkODE0MzdhY2EwNDA4ZDM1ZWUwYmUyMSU3YzcyZjk4 OGJmODZmMTQxYWY5MWEKPj4+Pj4+PiBiCj4+Pj4+Pj4gMgo+Pj4+Pj4+IGQ3Y2QwMTFkYjQ3JTdj MSZzZGF0YT1CcWNFOWVEaG04cGdkb2l0clBGdWZvdXhTNnFZbmRua0xnTGE1U1BrMkhJJQo+Pj4+ Pj4+IDMKPj4+Pj4+PiBkCj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwo+Pj4+Pj4gT0F1dGggbWFpbGluZyBsaXN0Cj4+Pj4+PiBPQXV0aEBpZXRm Lm9yZwo+Pj4+Pj4gaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29t Lz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuCj4+Pj4+PiBpZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0 aW5mbyUyZm9hdXRoJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyCj4+Pj4+PiBvCj4+Pj4+ PiBzCj4+Pj4+PiBvZnQuY29tJTdjY2U4Yzk0MmJlZDgxNDM3YWNhMDQwOGQzNWVlMGJlMjElN2M3 MmY5ODhiZjg2ZjE0MWFmOTFhYjJkCj4+Pj4+PiA3IGMgCj4+Pj4+PiBkMDExZGI0NyU3YzEmc2Rh dGE9QnFjRTllRGhtOHBnZG9pdHJQRnVmb3V4UzZxWW5kbmtMZ0xhNVNQazJISSUzZAo+Pj4+PiAK Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4+ Pj4gT0F1dGggbWFpbGluZyBsaXN0Cj4+Pj4+IE9BdXRoQGlldGYub3JnCj4+Pj4+IGh0dHBzOi8v bmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJm d3d3Lgo+Pj4+PiBpCj4+Pj4+IGV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZk YXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zCj4+Pj4+IG8KPj4+Pj4gZgo+Pj4+PiB0LmNv bSU3Y2NlOGM5NDJiZWQ4MTQzN2FjYTA0MDhkMzVlZTBiZTIxJTdjNzJmOTg4YmY4NmYxNDFhZjkx YWIyZDdjZAo+Pj4+PiAwCj4+Pj4+IDEgMWRiNDclN2MxJnNkYXRhPUJxY0U5ZURobThwZ2RvaXRy UEZ1Zm91eFM2cVluZG5rTGdMYTVTUGsySEklM2QKPj4+PiAKPj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdAo+ Pj4+IE9BdXRoQGlldGYub3JnCj4+Pj4gaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuCj4+Pj4gaSAKPj4+PiBldGYub3Jn JTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1p Y3Jvc28KPj4+PiBmCj4+Pj4gdC5jb20lN2NjZThjOTQyYmVkODE0MzdhY2EwNDA4ZDM1ZWUwYmUy MSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwCj4+Pj4gMSAxZGI0NyU3YzEmc2RhdGE9QnFj RTllRGhtOHBnZG9pdHJQRnVmb3V4UzZxWW5kbmtMZ0xhNVNQazJISSUzZAo+Pj4+IAo+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+Pj4gT0F1dGgg bWFpbGluZyBsaXN0Cj4+Pj4gT0F1dGhAaWV0Zi5vcmcKPj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoCj4+PiAKPj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QKPj4+IE9BdXRo QGlldGYub3JnCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo Cj4+PiAKPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Cj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QKPj4+IE9BdXRoQGlldGYub3JnCj4+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoCj4+IAo+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+PiBPQXV0aCBtYWlsaW5nIGxpc3QKPj4g T0F1dGhAaWV0Zi5vcmcKPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aAo+Cg== ----_com.syntomo.email_3036477474667180 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PHAgZGlyPSJsdHIiPkFuZCB3aGF0IGFib3V0IGNvZGUgaW5qZWN0aW9uIGFuZCBvcGVuIHJlZGly ZWN0b3JzPyBJIHRoaW5rIHdlIGFscmVhZHkgaGF2ZSBhIGxvdCBvZiBkZXBsb3ltZW50IGV4cGVy aWVuY2UgdGhhdCBzaG91bGQgYmUgdXNlZCB0byBldm9sdmUgdGhlIHNwZWMuPC9wPgo8cCBkaXI9 Imx0ciI+U2VudCBieSA8YSBocmVmPWh0dHA6Ly93d3cubWFpbC13aXNlLmNvbS9pbnN0YWxsYXRp b24vMj5NYWlsV2lzZTwvYT4gJiM4MjExOyBTZWUgeW91ciBlbWFpbHMgYXMgY2xlYW4sIHNob3J0 IGNoYXRzLjwvcD4KPGJyPjxicj4tLS0tLS0tLSBPcmlnaW5hbG5hY2hyaWNodCAtLS0tLS0tLTxi cj5CZXRyZWZmOiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjE8YnI+Vm9uOiAmcXVvdDtQaGlsIEh1 bnQgKElETSkmcXVvdDsgJmx0O3BoaWwuaHVudEBvcmFjbGUuY29tJmd0Ozxicj5BbjogTWlrZSBK b25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0Ozxicj5DYzogVG9yc3RlbiBM b2RkZXJzdGVkdCAmbHQ7dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQmZ3Q7LG9hdXRoQGlldGYub3Jn PGJyPjxicj48cD5JIGJlbGlldmUgYWxsIHdlIG5lZWQgaXMgYSBuZXcgZHJhZnQgdGhhdCBkZWFs cyB3aXRoIHRoZSBuZXcgImR5bmFtaWMvbWl4LXVwIiBjYXNlcyBhcyB0aGVzZSB3ZXJlIG5vdCBj b25zaWRlcmVkIGluIHRoZSBvcmlnaW5hbCBzcGVjIHByb2Nlc3MuIDxicj48YnI+VGhlIHVwZGF0 ZWQgYnkgbWV0aG9kIHdvcmtzIGJlc3QgZm9yIHRoaXMuIEl0IGFsc28gY29uc29saWRhdGVzIGEg bG90IG9mIHBpZWNlbWVhbCBzcGVjcyBpbnRvIG9uZSBjb25zaXN0ZW50IHNwZWMuIDxicj48YnI+ UGhpbDxicj48YnI+Jmd0OyBPbiBBcHIgNywgMjAxNiwgYXQgMTU6MjUsIE1pa2UgSm9uZXMgJmx0 O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSZndDsgd3JvdGU6PGJyPiZndDsgPGJyPiZndDsg WWVzIC0gYW4gaW50ZW50aW9uYWxseSBjb25zZXJ2YXRpdmUsIGltcGxlbWVudGF0aW9uLSBhbmQg ZXhwZXJpZW5jZS1kcml2ZW4gcGF0aC48YnI+Jmd0OyA8YnI+Jmd0OyBSZXZpc2luZyBPQXV0aCAy LjAgaXMgYSAqYmlnIGRlYWwqLiZuYnNwOyBXZSBzaG91bGRuJ3QgZXZlbiBiZSB0YWxraW5nIGFi b3V0IGl0IHVudGlsIHdlJ3ZlIGNvbXBsZXRlZCBzdGVwcyAxLTUgYmVsb3cgLSAqaW5jbHVkaW5n KiB0aGUgIml0ZXJhdGUiIHN0ZXAsIGFzIG5lY2Vzc2FyeS4mbmJzcDsgSWYgd2UgZ2V0IHRoaXMg d3JvbmcsIHdlJ2xsIGZyYWdtZW50IE9BdXRoLCB3aGljaCBpcyBhIHRlcnJpYmxlIGFuZCBpcnJl c3BvbnNpYmxlIG91dGNvbWUgd2Ugc2hvdWxkIGNvbnNjaW91c2x5IGF2b2lkIGF0IGFsbCBjb3N0 cy48YnI+Jmd0OyA8YnI+Jmd0OyBJbiBwYXJ0aWN1bGFyLCB3ZSBzaG91bGQgbm90IHJlY2hhcnRl ciBmb3IgYW4gT0F1dGggMi4xIHVudGlsIHdlIGFscmVhZHkga25vdyB3aGF0IHdpbGwgYmUgaW4g aXQgYW5kIGtub3cgZnJvbSBkZXBsb3ltZW50IGV4cGVyaWVuY2UgdGhhdCBpdCdzIHRoZSByaWdo dCBzdHVmZi48YnI+Jmd0OyA8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAtLSBNaWtlPGJyPiZndDsgPGJyPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+ Jmd0OyBGcm9tOiBUb3JzdGVuIExvZGRlcnN0ZWR0IFttYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVk dC5uZXRdIDxicj4mZ3Q7IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCA3LCAyMDE2IDM6MTYgUE08YnI+ Jmd0OyBUbzogTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0Ozxi cj4mZ3Q7IENjOiBTYW11ZWwgRXJkdG1hbiAmbHQ7c2FtdWVsQGVyZHRtYW4uc2UmZ3Q7OyBBbnRo b255IE5hZGFsaW4gJmx0O3RvbnluYWRAbWljcm9zb2Z0LmNvbSZndDs7IG9hdXRoQGlldGYub3Jn PGJyPiZndDsgU3ViamVjdDogUmU6IFtPQVVUSC1XR10gT0F1dGggMi4xPGJyPiZndDsgPGJyPiZn dDsgSGkgTWlrZSw8YnI+Jmd0OyA8YnI+Jmd0OyBpbiBteSBvcGluaW9uLCB5b3UgZGVzY3JpYmVk IGEgcG9zc2libGUgcGF0aCB0b3dhcmRzIDIuMS4gV291bGQgeW91IGFncmVlPzxicj4mZ3Q7IDxi cj4mZ3Q7IGJlc3QgcmVnYXJkcyw8YnI+Jmd0OyBUb3JzdGVuLjxicj4mZ3Q7IDxicj4mZ3Q7Jmd0 OyBBbSAwNy4wNC4yMDE2IHVtIDEzOjM4IHNjaHJpZWIgTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tJmd0Ozo8YnI+Jmd0OyZndDsgPGJyPiZndDsmZ3Q7IEkgYW0gc3Ry b25nbHkgYWdhaW5zdCBjcmVhdGluZyBhIDIuMSBzcGVjIHVudGlsIHdlIGhhdmUgYXQgbGVhc3Qg YSB5ZWFyIG9mIGRlcGxveW1lbnQgZXhwZXJpZW5jZSB3aXRoIHRoZSBjb250ZW50cyB3ZSdyZSBh ZGRpbmcgdG8gMi4wLCBzbyBhcyBub3QgdG8gZnJhZ21lbnQgdGhlIE9BdXRoIG1hcmtldHBsYWNl Ljxicj4mZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsgSSB0aGluayB3ZSBzaG91bGQ6PGJyPiZndDsmZ3Q7 IDEuJm5ic3A7IENvbnRpbnVlIHdvcmtpbmcgb24gbmV3IHNlY3VyaXR5IG1pdGlnYXRpb25zIGlu IG5ldyBkcmFmdHMgKHN1Y2ggPGJyPiZndDsmZ3Q7IGFzIG1peC11cC1taXRpZ2F0aW9uLCBldGMu KSB0aGF0IGFkZCBmZWF0dXJlcyB0byB1c2Ugd2l0aCAyLjAgMi4mbmJzcDsgPGJyPiZndDsmZ3Q7 IENvbnRpbnVlIHdvcmtpbmcgb24gUG9QIHNwZWNzIChzdWNoIGFzIHBvcC1rZXktZGlzdHJpYnV0 aW9uLCBldGMuKSA8YnI+Jmd0OyZndDsgdGhhdCBhZGQgZmVhdHVyZXMgdG8gdXNlIHdpdGggMi4w IDMuJm5ic3A7IENvbnRpbnVlIHdvcmtpbmcgb24gb3RoZXIgbmV3IDxicj4mZ3Q7Jmd0OyBzcGVj cyAoc3VjaCBhcyBkaXNjb3ZlcnksIHJlc291cmNlLWluZGljYXRvcnMsIGV0Yy4pIHRoYXQgYWRk IGZlYXR1cmVzIDxicj4mZ3Q7Jmd0OyB0byB1c2Ugd2l0aCAyLjAgNC4mbmJzcDsgTGVhcm4gZnJv bSBkZXBsb3ltZW50IGV4cGVyaWVuY2Ugd2l0aCBhbGwgb2YgdGhlbSA8YnI+Jmd0OyZndDsgNS4m bmJzcDsgSXRlcmF0ZSBpZiB0aGUgZGVwbG95bWVudCBleHBlcmllbmNlIHRlbGxzIHVzIHRoYXQg d2UgbmVlZCB0bzxicj4mZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsgT25seSBhZnRlciB3ZSBiZWxpZXZl IHdlIGhhdmUgYWxsIHRoZSBmZWF0dXJlcyByaWdodCBhbmQgd2Uga25vdyB0aGF0IHRoZXkgd29y ayB0b2dldGhlciB3ZWxsIHNob3VsZCB3ZSBjb25zaWRlciBjcmVhdGluZyBhIDIuMS4mbmJzcDsg SWYgd2UgcnVzaCB0byBhIDIuMSBhbmQgZ2V0IGl0IHdyb25nLCB3ZSdsbCBsb3NlIGRldmVsb3Bl cnMnIHRydXN0IGFuZCB3ZSdsbCBuZXZlciBnZXQgaXQgYmFjay48YnI+Jmd0OyZndDsgPGJyPiZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8YnI+Jmd0OyZndDsgPGJy PiZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPiZndDsmZ3Q7IEZyb206IE9B dXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNhbXVlbCA8 YnI+Jmd0OyZndDsgRXJkdG1hbjxicj4mZ3Q7Jmd0OyBTZW50OiBUaHVyc2RheSwgQXByaWwgNywg MjAxNiAxMjo0OCBQTTxicj4mZ3Q7Jmd0OyBUbzogQW50aG9ueSBOYWRhbGluICZsdDt0b255bmFk QG1pY3Jvc29mdC5jb20mZ3Q7PGJyPiZndDsmZ3Q7IENjOiBvYXV0aEBpZXRmLm9yZzxicj4mZ3Q7 Jmd0OyBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjE8YnI+Jmd0OyZndDsgPGJyPiZn dDsmZ3Q7ICsxIG9uIGEgMi4xIHZlcnNpb248YnI+Jmd0OyZndDsgPGJyPiZndDsmZ3Q7IC0xIG9u IGRlZmluaW5nIHNjb3BlcyBtb3JlIHByZWNpc2VseSBpbiAyLjE8YnI+Jmd0OyZndDsgPGJyPiZn dDsmZ3Q7IFNlbnQgZnJvbSBteSBpUGhvbmU8YnI+Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyBP biA3IGFwci4gMjAxNiwgYXQgMTQ6NDYsIEFudGhvbnkgTmFkYWxpbiAmbHQ7dG9ueW5hZEBtaWNy b3NvZnQuY29tJmd0OyB3cm90ZTo8YnI+Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsgSSBk b24ndCBiZWxpdmUgdGhhdCBzY29wZXMgc2hvdWxkIGJlIGRlZmluZWQgbW9yZSBwcmVjaXNlbHkg YXMgdGhpcyBvcGFxdWVuZXNzIHdhcyBhIGRlc2lnbiBmZWF0dXJlLCBJJ20gbm90IHNlZWluZyB0 aGUgcmVhc29uIHdoeSBzY29wZXMgbmVlZCB0byBiZSBkZWZpbmVkLCBhcyB0aGVzZSBhcmUgYXBw bGljYXRpb24gc3BlY2lmaWMuPGJyPiZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPiZndDsmZ3Q7Jmd0OyBGcm9tOiBPQXV0aCBbbWFpbHRv Om9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUb3JzdGVuIDxicj4mZ3Q7Jmd0 OyZndDsgTG9kZGVyc3RlZHQ8YnI+Jmd0OyZndDsmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCA3 LCAyMDE2IDU6MzIgQU08YnI+Jmd0OyZndDsmZ3Q7IFRvOiBHZW9yZ2UgRmxldGNoZXIgJmx0O2dm ZmxldGNoQGFvbC5jb20mZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyBDYzogb2F1dGhAaWV0Zi5vcmc8YnI+ Jmd0OyZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMTxicj4mZ3Q7Jmd0 OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyBIaSBhbGwsPGJyPiZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZn dDsmZ3Q7IGFzIEkgYWxyZWFkeSBzYWlkIGluIHRoZSBtZWV0aW5nOiBJIHdvdWxkIHZlcnkgbXVj aCBwcmVmZXIgdG8gaGF2ZSBhbiBleHRlbnNpb24vdXBkYXRlIG9mIFJGQyA2ODE5IGNvdmVyaW5n IGFsbCAibmV3IiB0aHJlYXRzLCBpbmNsdWRpbmc6PGJyPiZndDsmZ3Q7Jmd0OyAtIG1peCB1cDxi cj4mZ3Q7Jmd0OyZndDsgLSBjb2RlIGluamVjdGlvbiBha2EgY29weSBhbmQgcGFzdGU8YnI+Jmd0 OyZndDsmZ3Q7IC0gb3BlbiByZWRpcmVjdG9yIGF0IEFTIGFuZCBjbGllbnQ8YnI+Jmd0OyZndDsm Z3Q7IC0gcG90ZW50aWFsIG90aGVyIHRocmVhdHMgaW4gdGhlIGNvbnRleHQgb2YgImR5bmFtaWMi IE9BdXRoPGJyPiZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7IEkgYWxzbyBhc3N1bWUgbWl0 aWdhdGlvbnMgZm9yIChhdCBsZWFzdCBzb21lIG9mKSB0aGUgdGhyZWF0cyBuZWVkIHRvIGdvIGlu dG8gYW4gdXBkYXRlIG9mIFJGQyA2NzQ5IGFzIG5vcm1hdGl2ZSB0ZXh0LiBUbyBnaXZlIGFuIGV4 YW1wbGU6IGlmIHdlIGFncmVlIG9uIHVzaW5nIHRoZSBzdGF0ZSBwYXJhbWV0ZXIgYXQgdGhlIHRv a2VuIGVuZHBvaW50IHRvIG1pdGlnYXRlIGNvZGUgaW5qZWN0aW9uLCB0aGlzIE1VU1QgYmUgcGFy dCBvZiB0aGUgY29yZSBzcGVjIChyZXF1ZXN0IGRlc2NyaXB0aW9uIGFuZCBzZWN1cml0eSBjb25z b2RlcmF0aW9ucykuIE90aGVyd2lzZSwgbm9vbmUgd2lsbCBldmVuJm5ic3A7IGNvbnNpZGVyIGl0 Ljxicj4mZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyBXZSBzaG91bGQgYWxzbyB1c2UgdGhl IG9wcG9ydHVuaXR5IHRvIGltcHJvdmUvZW5oYW5jZSB0aGUgdGV4dCBvZiB0aGUgc3BlYy4gSW4g dGhlIGNvdXJzZSBvZiB0aGUgbGFzdCB5ZWFycywgd2UgaGF2ZSBsZWFybmVkIGEgbG90IGFib3V0 IGFtYmlxdWl0aWVzIG9mIHRoZSB0ZXh0IGFuZCBob3cgZGlmZmVyZW50IGltcGxlbWVudGF0aW9u cyB1dGlsaXplIE9BdXRoLiA8YnI+Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsgSSB0aGlu ayB0aW1lIGlzIHJpZ2h0IHRvIGRlZmluZSBzY29wZXMgbW9yZSBwcmVjaXNlbHkuIEFzIHRoZSBk aXNjdXNzaW9ucyBpbiB0aGUgbGFzdCBkYXlzIHByb3ZlZCBhZ2FpbiAoYXQgbGVhc3QgZm9yIG1l KSwgc2NvcGUgaXMgbm90IHN1ZmZpY2llbnRseSBkZWZpbmVkIHRvIGNvbWUgdXAgd2l0aCBpbnRl cm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucy4gQWRkaXRpb25hbGx5LCB0aGVyZSBzZWVtcyB0byBi ZSBhIG5lZWQgdG8gcmVwcmVzZW50IHJlc291cmNlIHNlcnZlciBsb2NhdGlvbnMgKHRvIG5vdCBz YXkgaWRlbnRpdGllcyA6LSkpIGluIHRoaXMgY29udGV4dC48YnI+Jmd0OyZndDsmZ3Q7IDxicj4m Z3Q7Jmd0OyZndDsgVG8gYnVuZGxlIGFsbCBjaGFuZ2VzIGluIGEgdmVyc2lvbiAyLjEgd291bGQg YWxzbyBtYWtlIGNvbW11bmljYXRpb24gaW50byB0aGUgbWFya2V0IG11Y2ggZWFzaWVyLiA8YnI+ Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsgYmVzdCByZWdhcmRzLDxicj4mZ3Q7Jmd0OyZn dDsgVG9yc3Rlbi48YnI+Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IEFtIDA2LjA0 LjIwMTYgdW0gMTY6MDUgc2NocmllYiBHZW9yZ2UgRmxldGNoZXIgJmx0O2dmZmxldGNoQGFvbC5j b20mZ3Q7Ojxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IEknZCBkZWZp bml0ZWx5IHByZWZlciBhIHNpbmdsZSBzb2x1dGlvbiBkb2N1bWVudCB0byBtYW55IGxpdHRsZSBv bmVzIHRoYXQgaGF2ZSB0byBiZSBjb21iaW5lZCB0byBhY3R1YWxseSBidWlsZCBhIHNlY3VyZSBz b2x1dGlvbi4gSXQncyBhbHJlYWR5IGdldHRpbmcgY29tcGxleCB3aXRoIHRoZSBhZGRpdGlvbmFs IHNwZWNzIHRoYXQgaGF2ZSBiZWVuIGFkZGVkLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7 Jmd0OyZndDsmZ3Q7IEFkZGl0aW9uYWxseSwgSSdtIG5vdCBhZ2FpbnN0IHdvcmtpbmcgb24gT0F1 dGggMi4xLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IFRoYW5rcyw8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBHZW9yZ2U8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgT24gNC82LzE2IDI6MDYgUE0sIFBoaWwgSHVudCAoSURNKSB3cm90ZTo8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEV4aXN0aW5n IGltcGxlbWVudGF0aW9ucyBhcmUgZm9yIHRoZSBsYXJnZSBwYXJ0IG9rIGFuZCBkbyBub3QgbmVl ZCB0aGVzZSBtaXRpZ2F0aW9ucy48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IE9ubHkgdGhlIG5ldyB1c2UgY2FzZXMgd2UgaGF2ZSBiZWVuIGRpc2N1c3Np bmcgKGNvbmZpZ3VyZSBvbiB0aGUgZmx5IGFuZCBtdWx0aS1hcywgZXRjKSByZWFsbHkgbmVlZCBt aXRpZ2F0aW9uLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgVGhlIHVwZGF0ZWQgYnkgYXBwcm9hY2ggc2VlbXMgbGlrZSBhIGdvb2Qgd2F5IHRvIGFkZHJl c3MgdGhlIG5ldyBjYXNlcy48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IFBoaWw8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBPbiBBcHIgNiwgMjAxNiwgYXQgMTQ6MzUsIEhhbm5lcyBUc2Nob2ZlbmlnICZs dDtoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Jmd0OyB3cm90ZTo8YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSGkgYWxsLDxicj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0b2RheSB3ZSBk aXNjdXNzZWQgdGhlIE9BdXRoIEF1dGhvcml6YXRpb24gU2VydmVyIE1peHVwIGRyYWZ0LiBXZSA8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdlcmUgd29uZGVyaW5nIHdoYXQgdHlwZXMgb2Yg dGhyZWF0cyB0aGUgZG9jdW1lbnQgc2hvdWxkIGZpbmQgc29sdXRpb25zIGZvci48YnI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgV2UgZGlzY3Vz c2VkIHZhcmlvdXMgZG9jdW1lbnQgaGFuZGxpbmcgYXBwcm9hY2hlcyBpbmNsdWRpbmc8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICogT0F1dGggTWl4LVVwIGFuZCBDdXQtYW5kLVBhc3RlIGF0 dGFja3MgZG9jdW1lbnRlZCBpbiBzZXBhcmF0ZSA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IHNvbHV0aW9uIGRvY3VtZW50czxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKiBjb21iaW5l ZCBzb2x1dGlvbiBkb2N1bWVudCBjb3ZlcmluZyB0aGUgT0F1dGggTWl4LVVwIGFuZCB0aGUgPGJy PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBDdXQtYW5kLVBhc3RlIGF0dGFja3MuPGJyPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEJhcnJ5IHBv aW50ZWQgb3V0IHRoYXQgdGhlc2UgZG9jdW1lbnRzIGNvdWxkIHVwZGF0ZSB0aGUgT0F1dGggYmFz ZSA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNwZWNpZmljYXRpb24uPGJyPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEFzIGEgbW9yZSBy YWRpY2FsIGNoYW5nZSBpdCB3YXMgYWxzbyBzdWdnZXN0ZWQgdG8gcmV2aXNlIFJGQyA2NzQ5IDxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgIk9BdXRoPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyAyLjAgQXV0aG9yaXphdGlvbiBGcmFtZXdvcmsiIGFuZCBSRkMgNjgxOSAiT0F1dGggMi4w IFRocmVhdCBNb2RlbCA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFuZCBTZWN1cml0eSBD b25zaWRlcmF0aW9ucyIuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IE9wZW5pbmcgdXAgdGhlIE9BdXRoIGJhc2Ugc3BlY2lmaWNhdGlvbiBv YnZpb3VzbHkgcmFpc2VzIHZhcmlvdXMgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBvdGhl ciBxdWVzdGlvbnMgYWJvdXQgY2xlYW5pbmcgdXAgcGFydHMgdGhhdCBnbyBmYXIgYmV5b25kIHRo ZSBBUyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1peC11cCBhbmQgdGhlIGN1dC1hbmQt cGFzdGUgYXR0YWNrcy4gT3RoZXIgc3BlY2lmaWNhdGlvbnMsIHN1Y2ggPGJyPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBhcyB0aGUgT3BlbiBSZWRpcmVjdG9yLCBjb3VsZCBiZSBmb2xkZWQgaW50 byBzdWNoIGEgbmV3IHNwZWNpZmljYXRpb24uPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IERlcmVrIGFuZCBJIHdvdWxkIGFwcHJlY2lhdGUg eW91ciBpbnB1dCBvbiB0aGlzIHRvcGljIGJlZm9yZSB3ZSA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IG1ha2UgYSBkZWNpc2lvbiBzaW5jZSBpdCBoYXMgc2lnbmlmaWNhbnQgaW1wYWN0IG9u IG91ciB3b3JrLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBDaWFvPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIYW5uZXMgJmFtcDsg RGVyZWs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT0F1 dGggbWFpbGluZyBsaXN0PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aEBpZXRmLm9y Zzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90 ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3PGJyPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyB3PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3PGJyPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyAuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZhbXA7 ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBj PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBvc29mdC5jb20lN2NjZThjOTQyYmVkODE0MzdhY2EwNDA4ZDM1ZWUwYmUyMSU3YzcyZjk4OGJm ODZmMTQxYWY5MWE8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGI8YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IDI8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGQ3Y2QwMTFkYjQ3JTdj MSZhbXA7c2RhdGE9QnFjRTllRGhtOHBnZG9pdHJQRnVmb3V4UzZxWW5kbmtMZ0xhNVNQazJISSU8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDM8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT0F1dGggbWFpbGluZyBs aXN0PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9BdXRoQGlldGYub3JnPGJyPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHBzJTNhJTJmJTJmd3d3Ljxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpZXRmLm9yZyUy Zm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQw bWljcjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBvPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHM8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgb2Z0LmNvbSU3Y2NlOGM5NDJiZWQ4MTQzN2FjYTA0MDhk MzVlZTBiZTIxJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyA3IGMgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGQwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9QnFj RTllRGhtOHBnZG9pdHJQRnVmb3V4UzZxWW5kbmtMZ0xhNVNQazJISSUzZDxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPiZndDsmZ3Q7Jmd0OyZndDsgT0F1dGggbWFpbGluZyBsaXN0 PGJyPiZndDsmZ3Q7Jmd0OyZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBo dHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUz YSUyZiUyZnd3dy48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBpPGJyPiZndDsmZ3Q7Jmd0OyZndDsgZXRm Lm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmFtcDtkYXRhPTAxJTdjMDElN2N0b255 bmFkJTQwbWljcm9zPGJyPiZndDsmZ3Q7Jmd0OyZndDsgbzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IGY8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyB0LmNvbSU3Y2NlOGM5NDJiZWQ4MTQzN2FjYTA0MDhkMzVlZTBi ZTIxJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IDA8YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyAxIDFkYjQ3JTdjMSZhbXA7c2RhdGE9QnFjRTllRGhtOHBnZG9pdHJQ RnVmb3V4UzZxWW5kbmtMZ0xhNVNQazJISSUzZDxicj4mZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7 Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4m Z3Q7Jmd0OyZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPiZndDsmZ3Q7Jmd0OyBPQXV0aEBpZXRm Lm9yZzxicj4mZ3Q7Jmd0OyZndDsgaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuPGJyPiZndDsmZ3Q7Jmd0OyBpIDxicj4m Z3Q7Jmd0OyZndDsgZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmFtcDtkYXRh PTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zbzxicj4mZ3Q7Jmd0OyZndDsgZjxicj4mZ3Q7Jmd0 OyZndDsgdC5jb20lN2NjZThjOTQyYmVkODE0MzdhY2EwNDA4ZDM1ZWUwYmUyMSU3YzcyZjk4OGJm ODZmMTQxYWY5MWFiMmQ3Y2QwPGJyPiZndDsmZ3Q7Jmd0OyAxIDFkYjQ3JTdjMSZhbXA7c2RhdGE9 QnFjRTllRGhtOHBnZG9pdHJQRnVmb3V4UzZxWW5kbmtMZ0xhNVNQazJISSUzZDxicj4mZ3Q7Jmd0 OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4mZ3Q7Jmd0OyZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPiZndDsm Z3Q7Jmd0OyBPQXV0aEBpZXRmLm9yZzxicj4mZ3Q7Jmd0OyZndDsgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj4mZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyZndDsgT0F1 dGggbWFpbGluZyBsaXN0PGJyPiZndDsmZ3Q7IE9BdXRoQGlldGYub3JnPGJyPiZndDsmZ3Q7IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8YnI+Jmd0OyZndDsgPGJy PiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPiZndDsmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4mZ3Q7Jmd0OyBPQXV0aEBpZXRmLm9y Zzxicj4mZ3Q7Jmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo PGJyPiZndDsgPGJyPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyBPQXV0aEBpZXRmLm9y Zzxicj4mZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8YnI+ PGJyPjwvcD4= ----_com.syntomo.email_3036477474667180-- From nobody Thu Apr 7 12:15:56 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9229712D158 for ; Thu, 7 Apr 2016 12:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5KeSF4pxl20 for ; Thu, 7 Apr 2016 12:15:52 -0700 (PDT) Received: from mx0b-0019e102.pphosted.com (mx0b-0019e102.pphosted.com [67.231.157.237]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9644D12D0B7 for ; Thu, 7 Apr 2016 12:15:52 -0700 (PDT) Received: from pps.filterd (m0074417.ppops.net [127.0.0.1]) by mx0b-0019e102.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u37JB4M3031844 for ; Thu, 7 Apr 2016 14:15:47 -0500 Received: from mail-yw0-f174.google.com (mail-yw0-f174.google.com [209.85.161.174]) by mx0b-0019e102.pphosted.com with ESMTP id 225vmf02pd-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 07 Apr 2016 14:15:47 -0500 Received: by mail-yw0-f174.google.com with SMTP id t10so109029406ywa.0 for ; Thu, 07 Apr 2016 12:15:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9akBfzGAJBVEYPJnKLYST89r3isDAyElPYh5YVi0H78=; b=ELajrgDjNXub/uGcCM9cMDRnpUot9LT8SEnhtzlvTGmeD1g4QPjBqDkB+S5BrR4i5E +HjbiLDft57xOzCmqpjlMS1Wm1FgdxAyl6o6UoTy9sIvvBhq9WINoHJ5VLfqkDH8G9sf Y3eqBp5L+xyRB1Z5AmQJizvd9oSnCpjdJtyKjXDNs5RlAw9FxZV+4hW1ME8SO9WCcfw1 ArQyqye/QMMii7a/YUV2F3uiM93QqR8x5Qa9PVo66gKPqrybMyka0B/1EPXdTIlkOSe9 z6VuK0mW3CMOpiww18UMT8CNqUDFsr3D5E+id59w8UWY4z2GYrqijs84veNrDbxw13vg tE+Q== X-Gm-Message-State: AD7BkJK+g4TgqAEKHinFVTMeo7l/YKsEcd/o71ru86BlG/rPyM/WLbAQzaNEJqvvDmUI1sQkX0JuZFnjHK0PBU1vj0AfevTCcM53e2U7CaZMmvwyXcZ8hbRTml/KwQDtaWGSY6h9U5CuP23E X-Received: by 10.13.212.150 with SMTP id w144mr2677861ywd.31.1460056547026; Thu, 07 Apr 2016 12:15:47 -0700 (PDT) X-Received: by 10.13.212.150 with SMTP id w144mr2677838ywd.31.1460056546753; Thu, 07 Apr 2016 12:15:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.106.132 with HTTP; Thu, 7 Apr 2016 12:15:27 -0700 (PDT) In-Reply-To: References: <570548D6.8010605@gmx.net> <57055DE2.50201@aol.com> <7A8E4B64-4741-4A54-84D6-B887690F77B5@erdtman.se> From: Adam Lewis Date: Thu, 7 Apr 2016 14:15:27 -0500 Message-ID: To: "Hardt, Dick" Content-Type: multipart/alternative; boundary=001a114fa6fcd271d3052fe9e7b1 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603180000 definitions=main-1604070269 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 19:15:56 -0000 --001a114fa6fcd271d3052fe9e7b1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 I will not comment on the timeline for this, but I will passionately endorse the need for an OAuth 2.1 spec. Speaking as somebody who now has spent years advocating for, and building out public safety / first responder architectures built on an OAuth 2.0 architecture, I can say 2 things with conviction: The good: OAuth 2.0 has enabled incredible use cases for us, and it is a gift that keeps on giving, the new WG efforts around POP and token exchange are solving even more use cases for us. This is hands down one of the best WGs I've known, and the work done here is nothing short of awesome. The bad: I have yet to meet anybody outside of the WG that really understands OAuth 2.0. I mean "really" understands it. (to this day, I still think it is only because of the good graces of others in this WG like John and Justin that I understand it with the depth that I do). People talk about it at high levels, they talk about tokens, but still don't get what it is trying to solve nor how to securely deploy it. 99% of the people I meet still don't get the difference between authentication and delegated authorization. I have dedicated massive amounts of cycles trying to educate my own community (and anybody else I meet for that matter). I personally found the core RFC very hard to digest, and now I need to refer to N more, many of which should be folded into a new 2.1 core spec. All this given, It is no wonder there are so many insecure implementations of it. So here's to OAuth 2.1 :-) -adam On Thu, Apr 7, 2016 at 1:56 PM, Hardt, Dick wrote: > I think there are already years of implementation and experience since 2.= 0 > > If we wait until all the outstanding issues and new features have had > implementations and experience, we will never do a 2.1 as there continues > to be new things. > > I would suggest a 2.1 be a clean, simple document of the core spec in one > document that includes the security and implementation recommendations. > > Alternative title: OAuth, The Good Parts. :) > > =E2=80=94 Dick > > > > > On 4/7/16, 3:25 PM, someone claiming to be "OAuth on behalf of Mike Jones= " > wrote: > > Yes - an intentionally conservative, implementation- and experience-drive= n > path. > > Revising OAuth 2.0 is a *big deal*. We shouldn't even be talking about i= t > until we've completed steps 1-5 below - *including* the "iterate" step, a= s > necessary. If we get this wrong, we'll fragment OAuth, which is a terrib= le > and irresponsible outcome we should consciously avoid at all costs. > > In particular, we should not recharter for an OAuth 2.1 until we already > know what will be in it and know from deployment experience that it's the > right stuff. > > -- Mike > > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Thursday, April 7, 2016 3:16 PM > To: Mike Jones > Cc: Samuel Erdtman ; Anthony Nadalin < > tonynad@microsoft.com>; oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.1 > > Hi Mike, > > in my opinion, you described a possible path towards 2.1. Would you agree= ? > > best regards, > Torsten. > > > Am 07.04.2016 um 13:38 schrieb Mike Jones = : > > > > I am strongly against creating a 2.1 spec until we have at least a year > of deployment experience with the contents we're adding to 2.0, so as not > to fragment the OAuth marketplace. > > > > I think we should: > > 1. Continue working on new security mitigations in new drafts (such > > as mix-up-mitigation, etc.) that add features to use with 2.0 2. > > Continue working on PoP specs (such as pop-key-distribution, etc.) > > that add features to use with 2.0 3. Continue working on other new > > specs (such as discovery, resource-indicators, etc.) that add features > > to use with 2.0 4. Learn from deployment experience with all of them > > 5. Iterate if the deployment experience tells us that we need to > > > > Only after we believe we have all the features right and we know that > they work together well should we consider creating a 2.1. If we rush to= a > 2.1 and get it wrong, we'll lose developers' trust and we'll never get it > back. > > > > -- Mike > > > > -----Original Message----- > > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Samuel > > Erdtman > > Sent: Thursday, April 7, 2016 12:48 PM > > To: Anthony Nadalin > > Cc: oauth@ietf.org > > Subject: Re: [OAUTH-WG] OAuth 2.1 > > > > +1 on a 2.1 version > > > > -1 on defining scopes more precisely in 2.1 > > > > Sent from my iPhone > > > >> On 7 apr. 2016, at 14:46, Anthony Nadalin > wrote: > >> > >> I don't belive that scopes should be defined more precisely as this > opaqueness was a design feature, I'm not seeing the reason why scopes nee= d > to be defined, as these are application specific. > >> > >> -----Original Message----- > >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten > >> Lodderstedt > >> Sent: Thursday, April 7, 2016 5:32 AM > >> To: George Fletcher > >> Cc: oauth@ietf.org > >> Subject: Re: [OAUTH-WG] OAuth 2.1 > >> > >> Hi all, > >> > >> as I already said in the meeting: I would very much prefer to have an > extension/update of RFC 6819 covering all "new" threats, including: > >> - mix up > >> - code injection aka copy and paste > >> - open redirector at AS and client > >> - potential other threats in the context of "dynamic" OAuth > >> > >> I also assume mitigations for (at least some of) the threats need to g= o > into an update of RFC 6749 as normative text. To give an example: if we > agree on using the state parameter at the token endpoint to mitigate code > injection, this MUST be part of the core spec (request description and > security consoderations). Otherwise, noone will even consider it. > >> > >> We should also use the opportunity to improve/enhance the text of the > spec. In the course of the last years, we have learned a lot about > ambiquities of the text and how different implementations utilize OAuth. > >> > >> I think time is right to define scopes more precisely. As the > discussions in the last days proved again (at least for me), scope is not > sufficiently defined to come up with interoperable implementations. > Additionally, there seems to be a need to represent resource server > locations (to not say identities :-)) in this context. > >> > >> To bundle all changes in a version 2.1 would also make communication > into the market much easier. > >> > >> best regards, > >> Torsten. > >> > >>> Am 06.04.2016 um 16:05 schrieb George Fletcher : > >>> > >>> I'd definitely prefer a single solution document to many little ones > that have to be combined to actually build a secure solution. It's alread= y > getting complex with the additional specs that have been added. > >>> > >>> Additionally, I'm not against working on OAuth 2.1. > >>> > >>> Thanks, > >>> George > >>> > >>>> On 4/6/16 2:06 PM, Phil Hunt (IDM) wrote: > >>>> > >>>> Existing implementations are for the large part ok and do not need > these mitigations. > >>>> > >>>> Only the new use cases we have been discussing (configure on the fly > and multi-as, etc) really need mitigation. > >>>> > >>>> The updated by approach seems like a good way to address the new > cases. > >>>> > >>>> Phil > >>>> > >>>>> On Apr 6, 2016, at 14:35, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > >>>>> > >>>>> Hi all, > >>>>> > >>>>> today we discussed the OAuth Authorization Server Mixup draft. We > >>>>> were wondering what types of threats the document should find > solutions for. > >>>>> > >>>>> We discussed various document handling approaches including > >>>>> * OAuth Mix-Up and Cut-and-Paste attacks documented in separate > >>>>> solution documents > >>>>> * combined solution document covering the OAuth Mix-Up and the > >>>>> Cut-and-Paste attacks. > >>>>> > >>>>> Barry pointed out that these documents could update the OAuth base > >>>>> specification. > >>>>> > >>>>> As a more radical change it was also suggested to revise RFC 6749 > >>>>> "OAuth > >>>>> 2.0 Authorization Framework" and RFC 6819 "OAuth 2.0 Threat Model > >>>>> and Security Considerations". > >>>>> > >>>>> Opening up the OAuth base specification obviously raises various > >>>>> other questions about cleaning up parts that go far beyond the AS > >>>>> mix-up and the cut-and-paste attacks. Other specifications, such > >>>>> as the Open Redirector, could be folded into such a new > specification. > >>>>> > >>>>> Derek and I would appreciate your input on this topic before we > >>>>> make a decision since it has significant impact on our work. > >>>>> > >>>>> Ciao > >>>>> Hannes & Derek > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> OAuth mailing list > >>>>> OAuth@ietf.org > >>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2f= w > >>>>> w > >>>>> w > >>>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40m= i > >>>>> c > >>>>> r > >>>>> osoft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91a > >>>>> b > >>>>> 2 > >>>>> d7cd011db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI= % > >>>>> 3 > >>>>> d > >>>> _______________________________________________ > >>>> OAuth mailing list > >>>> OAuth@ietf.org > >>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fw= ww. > >>>> ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40mic= r > >>>> o > >>>> s > >>>> oft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d > >>>> 7 c > >>>> d011db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fww= w. > >>> i > >>> etf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40micro= s > >>> o > >>> f > >>> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd > >>> 0 > >>> 1 1db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww= . > >> i > >> etf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40micros= o > >> f > >> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd0 > >> 1 1db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d > >> > >> _______________________________________________ > >> OAuth mailing 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 > --001a114fa6fcd271d3052fe9e7b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

I will not comment on the time= line for this, but I will passionately endorse the need for an OAuth 2.1 sp= ec.=C2=A0

Speaking as somebody who now has spent years a= dvocating for, and building out public safety / first responder architectur= es built on an OAuth 2.0 architecture, I can say 2 things with conviction:= =C2=A0

The good: OAuth 2.0 has enabled incredible = use cases for us, and it is a gift that keeps on giving, the new WG efforts= around POP and token exchange are solving even more use cases for us.=C2= =A0 This is hands down one of the best WGs I've known, and the work don= e here is nothing short of awesome.

The bad: I hav= e yet to meet anybody outside of the WG that really understands OAuth 2.0.= =C2=A0 I mean "really" understands it. =C2=A0(to this day, I stil= l think it is only because of the good graces of others in this WG like Joh= n and Justin that I understand it with the depth that I do).=C2=A0 People t= alk about it at high levels, they talk about tokens, but still don't ge= t what it is trying to solve nor how to securely deploy it. 99% of the peop= le I meet still don't get the difference between authentication and del= egated authorization.=C2=A0 I have dedicated massive amounts of cycles tryi= ng to educate my own community (and anybody else I meet for that matter).= =C2=A0 I personally found the core RFC very hard to digest, and now I need = to refer to N more, many of which should be folded into a new 2.1 core spec= .=C2=A0 All this given, It is no wonder there are so many insecure implemen= tations of it. =C2=A0

So here's to OAuth 2.1 := -)

-adam
On Thu, Apr 7, 2016 at 1:56 PM, Hardt, Dick <dic= k@amazon.com> wrote:
I thin= k there are already years of implementation and experience since 2.0

If we wait until all the outstanding issues and new features have had imple= mentations and experience, we will never do a 2.1 as there continues to be = new things.

I would suggest a 2.1 be a clean, simple document of the core spec in one d= ocument that includes the security and implementation recommendations.

Alternative title: OAuth, The Good Parts. :)

=E2=80=94 Dick




On 4/7/16, 3:25 PM, someone claiming to be "OAuth on behalf of Mike Jo= nes" <oauth-bounces@ietf.= org on behalf of Michael= .Jones@microsoft.com> wrote:

Yes - an intentionally conservative, implementation- and experience-driven = path.

Revising OAuth 2.0 is a *big deal*.=C2=A0 We shouldn't even be talking = about it until we've completed steps 1-5 below - *including* the "= iterate" step, as necessary.=C2=A0 If we get this wrong, we'll fra= gment OAuth, which is a terrible and irresponsible outcome we should consci= ously avoid at all costs.

In particular, we should not recharter for an OAuth 2.1 until we already kn= ow what will be in it and know from deployment experience that it's the= right stuff.

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

-----Original Message-----
From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Thursday, April 7, 2016 3:16 PM
To: Mike Jones <Michael.J= ones@microsoft.com>
Cc: Samuel Erdtman <samuel@erdtman.= se>; Anthony Nadalin <to= nynad@microsoft.com>; oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] OAuth 2.1

Hi Mike,

in my opinion, you described a possible path towards 2.1. Would you agree?<= br>
best regards,
Torsten.

> Am 07.04.2016 um 13:38 schrieb Mike Jones <Michael.Jones@microsoft.com>:
>
> I am strongly against creating a 2.1 spec until we have at least a yea= r of deployment experience with the contents we're adding to 2.0, so as= not to fragment the OAuth marketplace.
>
> I think we should:
> 1.=C2=A0 Continue working on new security mitigations in new drafts (s= uch
> as mix-up-mitigation, etc.) that add features to use with 2.0 2.
> Continue working on PoP specs (such as pop-key-distribution, etc.)
> that add features to use with 2.0 3.=C2=A0 Continue working on other n= ew
> specs (such as discovery, resource-indicators, etc.) that add features=
> to use with 2.0 4.=C2=A0 Learn from deployment experience with all of = them
> 5.=C2=A0 Iterate if the deployment experience tells us that we need to=
>
> Only after we believe we have all the features right and we know that = they work together well should we consider creating a 2.1.=C2=A0 If we rush= to a 2.1 and get it wrong, we'll lose developers' trust and we'= ;ll never get it back.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike
>
> -----Original Message-----
> From: OAuth [mailto:oauth-bo= unces@ietf.org] On Behalf Of Samuel
> Erdtman
> Sent: Thursday, April 7, 2016 12:48 PM
> To: Anthony Nadalin <tonyn= ad@microsoft.com>
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth 2.1
>
> +1 on a 2.1 version
>
> -1 on defining scopes more precisely in 2.1
>
> Sent from my iPhone
>
>> On 7 apr. 2016, at 14:46, Anthony Nadalin <tonynad@microsoft.com> wrote:
>>
>> I don't belive that scopes should be defined more precisely as= this opaqueness was a design feature, I'm not seeing the reason why sc= opes need to be defined, as these are application specific.
>>
>> -----Original Message-----
>> From: OAuth [mailto:oaut= h-bounces@ietf.org] On Behalf Of Torsten
>> Lodderstedt
>> Sent: Thursday, April 7, 2016 5:32 AM
>> To: George Fletcher <gfflet= ch@aol.com>
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] OAuth 2.1
>>
>> Hi all,
>>
>> as I already said in the meeting: I would very much prefer to have= an extension/update of RFC 6819 covering all "new" threats, incl= uding:
>> - mix up
>> - code injection aka copy and paste
>> - open redirector at AS and client
>> - potential other threats in the context of "dynamic" OA= uth
>>
>> I also assume mitigations for (at least some of) the threats need = to go into an update of RFC 6749 as normative text. To give an example: if = we agree on using the state parameter at the token endpoint to mitigate cod= e injection, this MUST be part of the core spec (request description and se= curity consoderations). Otherwise, noone will even=C2=A0 consider it.
>>
>> We should also use the opportunity to improve/enhance the text of = the spec. In the course of the last years, we have learned a lot about ambi= quities of the text and how different implementations utilize OAuth.
>>
>> I think time is right to define scopes more precisely. As the disc= ussions in the last days proved again (at least for me), scope is not suffi= ciently defined to come up with interoperable implementations. Additionally= , there seems to be a need to represent resource server locations (to not s= ay identities :-)) in this context.
>>
>> To bundle all changes in a version 2.1 would also make communicati= on into the market much easier.
>>
>> best regards,
>> Torsten.
>>
>>> Am 06.04.2016 um 16:05 schrieb George Fletcher <gffletch@aol.com>:
>>>
>>> I'd definitely prefer a single solution document to many l= ittle ones that have to be combined to actually build a secure solution. It= 's already getting complex with the additional specs that have been add= ed.
>>>
>>> Additionally, I'm not against working on OAuth 2.1.
>>>
>>> Thanks,
>>> George
>>>
>>>> On 4/6/16 2:06 PM, Phil Hunt (IDM) wrote:
>>>>
>>>> Existing implementations are for the large part ok and do = not need these mitigations.
>>>>
>>>> Only the new use cases we have been discussing (configure = on the fly and multi-as, etc) really need mitigation.
>>>>
>>>> The updated by approach seems like a good way to address t= he new cases.
>>>>
>>>> Phil
>>>>
>>>>> On Apr 6, 2016, at 14:35, Hannes Tschofenig <hannes.tschofenig@gmx.net> wr= ote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> today we discussed the OAuth Authorization Server Mixu= p draft. We
>>>>> were wondering what types of threats the document shou= ld find solutions for.
>>>>>
>>>>> We discussed various document handling approaches incl= uding
>>>>> * OAuth Mix-Up and Cut-and-Paste attacks documented in= separate
>>>>> solution documents
>>>>> * combined solution document covering the OAuth Mix-Up= and the
>>>>> Cut-and-Paste attacks.
>>>>>
>>>>> Barry pointed out that these documents could update th= e OAuth base
>>>>> specification.
>>>>>
>>>>> As a more radical change it was also suggested to revi= se RFC 6749
>>>>> "OAuth
>>>>> 2.0 Authorization Framework" and RFC 6819 "O= Auth 2.0 Threat Model
>>>>> and Security Considerations".
>>>>>
>>>>> Opening up the OAuth base specification obviously rais= es various
>>>>> other questions about cleaning up parts that go far be= yond the AS
>>>>> mix-up and the cut-and-paste attacks. Other specificat= ions, such
>>>>> as the Open Redirector, could be folded into such a ne= w specification.
>>>>>
>>>>> Derek and I would appreciate your input on this topic = before we
>>>>> make a decision since it has significant impact on our= work.
>>>>>
>>>>> Ciao
>>>>> Hannes & Derek
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org >>>>> https://na0= 1.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fw
>>>>> w
>>>>> w
>>>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7c= tonynad%40mi
>>>>> c
>>>>> r
>>>>> osoft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f1= 41af91a
>>>>> b
>>>>> 2
>>>>> d7cd011db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6= qYndnkLgLa5SPk2HI%
>>>>> 3
>>>>> d
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://na01.= safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.
>>>> ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonyn= ad%40micr
>>>> o
>>>> s
>>>> oft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab= 2d
>>>> 7 c
>>>> d011db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkL= gLa5SPk2HI%3d
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://na01.saf= elinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.
>>> i
>>> etf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40m= icros
>>> o
>>> f
>>> = t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd >>> 0
>>> 1 1db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5S= Pk2HI%3d
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://na01.safelink= s.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.
>> i
>> et= f.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40micro= so
>> f
>> t.co= m%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd0
>> 1 1db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2H= I%3d
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth<= br> >
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

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

--001a114fa6fcd271d3052fe9e7b1-- From nobody Thu Apr 7 12:21:18 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEC9912D1C0 for ; Thu, 7 Apr 2016 12:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 796eAczVQ0kU for ; Thu, 7 Apr 2016 12:21:13 -0700 (PDT) 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 4360F12D158 for ; Thu, 7 Apr 2016 12:21:13 -0700 (PDT) Received: by mail-ob0-x232.google.com with SMTP id j9so59201668obd.3 for ; Thu, 07 Apr 2016 12:21:13 -0700 (PDT) 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; bh=7VHZSEOsIVLabnYQn8PELUuW/dd1eMlIz7wBtAKwcu4=; b=DJEI/Sq0qJHuV8rZyxdEf5HpRH4WJDgyGtv4GF/qvsO4k96ff9dSpS4pMQWKHcGsdJ n6Bg8XPtEUmDA7gN2ZyklffziITKiBVLG0VXf3Py6ZxrHCyh8co4wAK5fNJnWIsDWCSl hddQu7ELCjdbHvPqGxaUEWUx/+URRIGpi8KtcyGBmiHeuE6z82YfrGLAOHz9jfaEAqH8 oLzALH7DuB09FWbdNeLAfvlwlffzo0YptCtC86I7qoqlwV9O/x/gF3RyiIoDWYlVVOX4 kaNJcslwYj5GM1VgxRtGjZajznxFx5veE3Sz+Tzb/KY41Ql6MdWjN2YjtxG29C8Ve6A8 OoIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7VHZSEOsIVLabnYQn8PELUuW/dd1eMlIz7wBtAKwcu4=; b=XZPD8Jiim+X5T75EIu+MG29eVZ18jtue38pweFGzfEwf8uZvhrbf5Lmx9oWnggU+JH 2f2LqvT1fa6FLRuhoCzVIpK6fNecqZCaIlQlDRTr87iWtZHaYhnU5d5v1ackAOLyTI1j YXPWNCDRq1hNuSzBIzZqkvbBvOEC9TTEoTteEGroMwTKQ7K2tt5lHGULzVC9ChLAaCSh H4In49SGw8K9K6g6VGmC2UrD0lqI4wfUpB/RdAlMqrJt9GMZufFgcRgIHU+e9S20V7HX E0ZsJDAoY5zUwhwgDt/z6/zmqO9e1O0nyScmIj68SGfjkz2jCtjsgFzqRiOWaVgQUEUH kDIg== X-Gm-Message-State: AD7BkJKUGjFME8I6XRn+EnM4WUHkJUlsUz6QgunK+2F0zbt0Glbm1bcj2XMsUI1QR3peovB3lUr4P9dKQg+Lz6mc X-Received: by 10.60.233.5 with SMTP id ts5mr2327249oec.67.1460056872497; Thu, 07 Apr 2016 12:21:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.79.233 with HTTP; Thu, 7 Apr 2016 12:20:52 -0700 (PDT) In-Reply-To: References: <570548D6.8010605@gmx.net> <57055DE2.50201@aol.com> <7A8E4B64-4741-4A54-84D6-B887690F77B5@erdtman.se> From: William Denniss Date: Thu, 7 Apr 2016 16:20:52 -0300 Message-ID: To: Adam Lewis Content-Type: multipart/alternative; boundary=001a1136a2dc3cfb1f052fe9fb04 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 19:21:17 -0000 --001a1136a2dc3cfb1f052fe9fb04 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Fair points. I also think this is an area where good online documentation, and books like *OAuth 2 in Action* can help, and possibly help a lot sooner= . On Thu, Apr 7, 2016 at 4:15 PM, Adam Lewis wrote: > +1 > > I will not comment on the timeline for this, but I will passionately > endorse the need for an OAuth 2.1 spec. > > Speaking as somebody who now has spent years advocating for, and building > out public safety / first responder architectures built on an OAuth 2.0 > architecture, I can say 2 things with conviction: > > The good: OAuth 2.0 has enabled incredible use cases for us, and it is a > gift that keeps on giving, the new WG efforts around POP and token exchan= ge > are solving even more use cases for us. This is hands down one of the be= st > WGs I've known, and the work done here is nothing short of awesome. > > The bad: I have yet to meet anybody outside of the WG that really > understands OAuth 2.0. I mean "really" understands it. (to this day, I > still think it is only because of the good graces of others in this WG li= ke > John and Justin that I understand it with the depth that I do). People > talk about it at high levels, they talk about tokens, but still don't get > what it is trying to solve nor how to securely deploy it. 99% of the peop= le > I meet still don't get the difference between authentication and delegate= d > authorization. I have dedicated massive amounts of cycles trying to > educate my own community (and anybody else I meet for that matter). I > personally found the core RFC very hard to digest, and now I need to refe= r > to N more, many of which should be folded into a new 2.1 core spec. All > this given, It is no wonder there are so many insecure implementations of > it. > > So here's to OAuth 2.1 :-) > > -adam > > On Thu, Apr 7, 2016 at 1:56 PM, Hardt, Dick wrote: > >> I think there are already years of implementation and experience since 2= .0 >> >> If we wait until all the outstanding issues and new features have had >> implementations and experience, we will never do a 2.1 as there continue= s >> to be new things. >> >> I would suggest a 2.1 be a clean, simple document of the core spec in on= e >> document that includes the security and implementation recommendations. >> >> Alternative title: OAuth, The Good Parts. :) >> >> =E2=80=94 Dick >> >> >> >> >> On 4/7/16, 3:25 PM, someone claiming to be "OAuth on behalf of Mike >> Jones" >> wrote: >> >> Yes - an intentionally conservative, implementation- and >> experience-driven path. >> >> Revising OAuth 2.0 is a *big deal*. We shouldn't even be talking about >> it until we've completed steps 1-5 below - *including* the "iterate" ste= p, >> as necessary. If we get this wrong, we'll fragment OAuth, which is a >> terrible and irresponsible outcome we should consciously avoid at all co= sts. >> >> In particular, we should not recharter for an OAuth 2.1 until we already >> know what will be in it and know from deployment experience that it's th= e >> right stuff. >> >> -- Mike >> >> -----Original Message----- >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >> Sent: Thursday, April 7, 2016 3:16 PM >> To: Mike Jones >> Cc: Samuel Erdtman ; Anthony Nadalin < >> tonynad@microsoft.com>; oauth@ietf.org >> Subject: Re: [OAUTH-WG] OAuth 2.1 >> >> Hi Mike, >> >> in my opinion, you described a possible path towards 2.1. Would you agre= e? >> >> best regards, >> Torsten. >> >> > Am 07.04.2016 um 13:38 schrieb Mike Jones > >: >> > >> > I am strongly against creating a 2.1 spec until we have at least a yea= r >> of deployment experience with the contents we're adding to 2.0, so as no= t >> to fragment the OAuth marketplace. >> > >> > I think we should: >> > 1. Continue working on new security mitigations in new drafts (such >> > as mix-up-mitigation, etc.) that add features to use with 2.0 2. >> > Continue working on PoP specs (such as pop-key-distribution, etc.) >> > that add features to use with 2.0 3. Continue working on other new >> > specs (such as discovery, resource-indicators, etc.) that add features >> > to use with 2.0 4. Learn from deployment experience with all of them >> > 5. Iterate if the deployment experience tells us that we need to >> > >> > Only after we believe we have all the features right and we know that >> they work together well should we consider creating a 2.1. If we rush t= o a >> 2.1 and get it wrong, we'll lose developers' trust and we'll never get i= t >> back. >> > >> > -- Mike >> > >> > -----Original Message----- >> > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Samuel >> > Erdtman >> > Sent: Thursday, April 7, 2016 12:48 PM >> > To: Anthony Nadalin >> > Cc: oauth@ietf.org >> > Subject: Re: [OAUTH-WG] OAuth 2.1 >> > >> > +1 on a 2.1 version >> > >> > -1 on defining scopes more precisely in 2.1 >> > >> > Sent from my iPhone >> > >> >> On 7 apr. 2016, at 14:46, Anthony Nadalin >> wrote: >> >> >> >> I don't belive that scopes should be defined more precisely as this >> opaqueness was a design feature, I'm not seeing the reason why scopes ne= ed >> to be defined, as these are application specific. >> >> >> >> -----Original Message----- >> >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten >> >> Lodderstedt >> >> Sent: Thursday, April 7, 2016 5:32 AM >> >> To: George Fletcher >> >> Cc: oauth@ietf.org >> >> Subject: Re: [OAUTH-WG] OAuth 2.1 >> >> >> >> Hi all, >> >> >> >> as I already said in the meeting: I would very much prefer to have an >> extension/update of RFC 6819 covering all "new" threats, including: >> >> - mix up >> >> - code injection aka copy and paste >> >> - open redirector at AS and client >> >> - potential other threats in the context of "dynamic" OAuth >> >> >> >> I also assume mitigations for (at least some of) the threats need to >> go into an update of RFC 6749 as normative text. To give an example: if = we >> agree on using the state parameter at the token endpoint to mitigate cod= e >> injection, this MUST be part of the core spec (request description and >> security consoderations). Otherwise, noone will even consider it. >> >> >> >> We should also use the opportunity to improve/enhance the text of the >> spec. In the course of the last years, we have learned a lot about >> ambiquities of the text and how different implementations utilize OAuth. >> >> >> >> I think time is right to define scopes more precisely. As the >> discussions in the last days proved again (at least for me), scope is no= t >> sufficiently defined to come up with interoperable implementations. >> Additionally, there seems to be a need to represent resource server >> locations (to not say identities :-)) in this context. >> >> >> >> To bundle all changes in a version 2.1 would also make communication >> into the market much easier. >> >> >> >> best regards, >> >> Torsten. >> >> >> >>> Am 06.04.2016 um 16:05 schrieb George Fletcher : >> >>> >> >>> I'd definitely prefer a single solution document to many little ones >> that have to be combined to actually build a secure solution. It's alrea= dy >> getting complex with the additional specs that have been added. >> >>> >> >>> Additionally, I'm not against working on OAuth 2.1. >> >>> >> >>> Thanks, >> >>> George >> >>> >> >>>> On 4/6/16 2:06 PM, Phil Hunt (IDM) wrote: >> >>>> >> >>>> Existing implementations are for the large part ok and do not need >> these mitigations. >> >>>> >> >>>> Only the new use cases we have been discussing (configure on the fl= y >> and multi-as, etc) really need mitigation. >> >>>> >> >>>> The updated by approach seems like a good way to address the new >> cases. >> >>>> >> >>>> Phil >> >>>> >> >>>>> On Apr 6, 2016, at 14:35, Hannes Tschofenig < >> hannes.tschofenig@gmx.net> wrote: >> >>>>> >> >>>>> Hi all, >> >>>>> >> >>>>> today we discussed the OAuth Authorization Server Mixup draft. We >> >>>>> were wondering what types of threats the document should find >> solutions for. >> >>>>> >> >>>>> We discussed various document handling approaches including >> >>>>> * OAuth Mix-Up and Cut-and-Paste attacks documented in separate >> >>>>> solution documents >> >>>>> * combined solution document covering the OAuth Mix-Up and the >> >>>>> Cut-and-Paste attacks. >> >>>>> >> >>>>> Barry pointed out that these documents could update the OAuth base >> >>>>> specification. >> >>>>> >> >>>>> As a more radical change it was also suggested to revise RFC 6749 >> >>>>> "OAuth >> >>>>> 2.0 Authorization Framework" and RFC 6819 "OAuth 2.0 Threat Model >> >>>>> and Security Considerations". >> >>>>> >> >>>>> Opening up the OAuth base specification obviously raises various >> >>>>> other questions about cleaning up parts that go far beyond the AS >> >>>>> mix-up and the cut-and-paste attacks. Other specifications, such >> >>>>> as the Open Redirector, could be folded into such a new >> specification. >> >>>>> >> >>>>> Derek and I would appreciate your input on this topic before we >> >>>>> make a decision since it has significant impact on our work. >> >>>>> >> >>>>> Ciao >> >>>>> Hannes & Derek >> >>>>> >> >>>>> >> >>>>> _______________________________________________ >> >>>>> OAuth mailing list >> >>>>> OAuth@ietf.org >> >>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2= fw >> >>>>> w >> >>>>> w >> >>>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40= mi >> >>>>> c >> >>>>> r >> >>>>> osoft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91a >> >>>>> b >> >>>>> 2 >> >>>>> d7cd011db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2H= I% >> >>>>> 3 >> >>>>> d >> >>>> _______________________________________________ >> >>>> OAuth mailing list >> >>>> OAuth@ietf.org >> >>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2f= www >> . >> >>>> ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40mi= cr >> >>>> o >> >>>> s >> >>>> oft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d >> >>>> 7 c >> >>>> d011db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >> >>> >> >>> _______________________________________________ >> >>> OAuth mailing list >> >>> OAuth@ietf.org >> >>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fw= ww. >> >>> i >> >>> etf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40micr= os >> >>> o >> >>> f >> >>> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd >> >>> 0 >> >>> 1 1db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fww= w. >> >> i >> >> etf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40micro= so >> >> f >> >> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd0 >> >> 1 1db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >> >> >> >> _______________________________________________ >> >> OAuth mailing 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 > > --001a1136a2dc3cfb1f052fe9fb04 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Fair points. I also think this is an area where good onlin= e documentation, and books like OAuth 2 in Action can help, and poss= ibly help a lot sooner.

On Thu, Apr 7, 2016 at 4:15 PM, Adam Lewis <adam.lewi= s@motorolasolutions.com> wrote:
+1

I will not comment on the= timeline for this, but I will passionately endorse the need for an OAuth 2= .1 spec.=C2=A0

Speaking as somebody who now has spent ye= ars advocating for, and building out public safety / first responder archit= ectures built on an OAuth 2.0 architecture, I can say 2 things with convict= ion:=C2=A0

The good: OAuth 2.0 has enabled incredi= ble use cases for us, and it is a gift that keeps on giving, the new WG eff= orts around POP and token exchange are solving even more use cases for us.= =C2=A0 This is hands down one of the best WGs I've known, and the work = done here is nothing short of awesome.

The bad: I = have yet to meet anybody outside of the WG that really understands OAuth 2.= 0.=C2=A0 I mean "really" understands it. =C2=A0(to this day, I st= ill think it is only because of the good graces of others in this WG like J= ohn and Justin that I understand it with the depth that I do).=C2=A0 People= talk about it at high levels, they talk about tokens, but still don't = get what it is trying to solve nor how to securely deploy it. 99% of the pe= ople I meet still don't get the difference between authentication and d= elegated authorization.=C2=A0 I have dedicated massive amounts of cycles tr= ying to educate my own community (and anybody else I meet for that matter).= =C2=A0 I personally found the core RFC very hard to digest, and now I need = to refer to N more, many of which should be folded into a new 2.1 core spec= .=C2=A0 All this given, It is no wonder there are so many insecure implemen= tations of it. =C2=A0

So here's to OAuth 2.1 := -)

-adam
On Thu, Apr 7, 2016 at 1:56 PM, Hardt, Dick <dic= k@amazon.com> wrote:
I thin= k there are already years of implementation and experience since 2.0

If we wait until all the outstanding issues and new features have had imple= mentations and experience, we will never do a 2.1 as there continues to be = new things.

I would suggest a 2.1 be a clean, simple document of the core spec in one d= ocument that includes the security and implementation recommendations.

Alternative title: OAuth, The Good Parts. :)

=E2=80=94 Dick




On 4/7/16, 3:25 PM, someone claiming to be "OAuth on behalf of Mike Jo= nes" <o= auth-bounces@ietf.org on behalf of Michael.Jones@microsoft.com> wrote:

Yes - an intentionally conservative, implementation- and experience-driven = path.

Revising OAuth 2.0 is a *big deal*.=C2=A0 We shouldn't even be talking = about it until we've completed steps 1-5 below - *including* the "= iterate" step, as necessary.=C2=A0 If we get this wrong, we'll fra= gment OAuth, which is a terrible and irresponsible outcome we should consci= ously avoid at all costs.

In particular, we should not recharter for an OAuth 2.1 until we already kn= ow what will be in it and know from deployment experience that it's the= right stuff.

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

-----Original Message-----
From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Thursday, April 7, 2016 3:16 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Samuel Erdtman <samuel@erdtman.se>; Anthony Nadalin <tonynad@microsoft.com>; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.1

Hi Mike,

in my opinion, you described a possible path towards 2.1. Would you agree?<= br>
best regards,
Torsten.

> Am 07.04.2016 um 13:38 schrieb Mike Jones <Michael.Jones@microsoft.com>= ;:
>
> I am strongly against creating a 2.1 spec until we have at least a yea= r of deployment experience with the contents we're adding to 2.0, so as= not to fragment the OAuth marketplace.
>
> I think we should:
> 1.=C2=A0 Continue working on new security mitigations in new drafts (s= uch
> as mix-up-mitigation, etc.) that add features to use with 2.0 2.
> Continue working on PoP specs (such as pop-key-distribution, etc.)
> that add features to use with 2.0 3.=C2=A0 Continue working on other n= ew
> specs (such as discovery, resource-indicators, etc.) that add features=
> to use with 2.0 4.=C2=A0 Learn from deployment experience with all of = them
> 5.=C2=A0 Iterate if the deployment experience tells us that we need to=
>
> Only after we believe we have all the features right and we know that = they work together well should we consider creating a 2.1.=C2=A0 If we rush= to a 2.1 and get it wrong, we'll lose developers' trust and we'= ;ll never get it back.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike
>
> -----Original Message-----
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Samuel
> Erdtman
> Sent: Thursday, April 7, 2016 12:48 PM
> To: Anthony Nadalin <tonynad@microsoft.com>
> Cc: oauth@ietf.org=
> Subject: Re: [OAUTH-WG] OAuth 2.1
>
> +1 on a 2.1 version
>
> -1 on defining scopes more precisely in 2.1
>
> Sent from my iPhone
>
>> On 7 apr. 2016, at 14:46, Anthony Nadalin <tonynad@microsoft.com> wrote:=
>>
>> I don't belive that scopes should be defined more precisely as= this opaqueness was a design feature, I'm not seeing the reason why sc= opes need to be defined, as these are application specific.
>>
>> -----Original Message-----
>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten
>> Lodderstedt
>> Sent: Thursday, April 7, 2016 5:32 AM
>> To: George Fletcher <gffletch@aol.com>
>> Cc: oauth@ietf= .org
>> Subject: Re: [OAUTH-WG] OAuth 2.1
>>
>> Hi all,
>>
>> as I already said in the meeting: I would very much prefer to have= an extension/update of RFC 6819 covering all "new" threats, incl= uding:
>> - mix up
>> - code injection aka copy and paste
>> - open redirector at AS and client
>> - potential other threats in the context of "dynamic" OA= uth
>>
>> I also assume mitigations for (at least some of) the threats need = to go into an update of RFC 6749 as normative text. To give an example: if = we agree on using the state parameter at the token endpoint to mitigate cod= e injection, this MUST be part of the core spec (request description and se= curity consoderations). Otherwise, noone will even=C2=A0 consider it.
>>
>> We should also use the opportunity to improve/enhance the text of = the spec. In the course of the last years, we have learned a lot about ambi= quities of the text and how different implementations utilize OAuth.
>>
>> I think time is right to define scopes more precisely. As the disc= ussions in the last days proved again (at least for me), scope is not suffi= ciently defined to come up with interoperable implementations. Additionally= , there seems to be a need to represent resource server locations (to not s= ay identities :-)) in this context.
>>
>> To bundle all changes in a version 2.1 would also make communicati= on into the market much easier.
>>
>> best regards,
>> Torsten.
>>
>>> Am 06.04.2016 um 16:05 schrieb George Fletcher <gffletch@aol.com>:
>>>
>>> I'd definitely prefer a single solution document to many l= ittle ones that have to be combined to actually build a secure solution. It= 's already getting complex with the additional specs that have been add= ed.
>>>
>>> Additionally, I'm not against working on OAuth 2.1.
>>>
>>> Thanks,
>>> George
>>>
>>>> On 4/6/16 2:06 PM, Phil Hunt (IDM) wrote:
>>>>
>>>> Existing implementations are for the large part ok and do = not need these mitigations.
>>>>
>>>> Only the new use cases we have been discussing (configure = on the fly and multi-as, etc) really need mitigation.
>>>>
>>>> The updated by approach seems like a good way to address t= he new cases.
>>>>
>>>> Phil
>>>>
>>>>> On Apr 6, 2016, at 14:35, Hannes Tschofenig <hannes.tschofenig@= gmx.net> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> today we discussed the OAuth Authorization Server Mixu= p draft. We
>>>>> were wondering what types of threats the document shou= ld find solutions for.
>>>>>
>>>>> We discussed various document handling approaches incl= uding
>>>>> * OAuth Mix-Up and Cut-and-Paste attacks documented in= separate
>>>>> solution documents
>>>>> * combined solution document covering the OAuth Mix-Up= and the
>>>>> Cut-and-Paste attacks.
>>>>>
>>>>> Barry pointed out that these documents could update th= e OAuth base
>>>>> specification.
>>>>>
>>>>> As a more radical change it was also suggested to revi= se RFC 6749
>>>>> "OAuth
>>>>> 2.0 Authorization Framework" and RFC 6819 "O= Auth 2.0 Threat Model
>>>>> and Security Considerations".
>>>>>
>>>>> Opening up the OAuth base specification obviously rais= es various
>>>>> other questions about cleaning up parts that go far be= yond the AS
>>>>> mix-up and the cut-and-paste attacks. Other specificat= ions, such
>>>>> as the Open Redirector, could be folded into such a ne= w specification.
>>>>>
>>>>> Derek and I would appreciate your input on this topic = before we
>>>>> make a decision since it has significant impact on our= work.
>>>>>
>>>>> Ciao
>>>>> Hannes & Derek
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OA= uth@ietf.org
>>>>> https://na0= 1.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fw
>>>>> w
>>>>> w
>>>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7c= tonynad%40mi
>>>>> c
>>>>> r
>>>>> osoft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f1= 41af91a
>>>>> b
>>>>> 2
>>>>> d7cd011db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6= qYndnkLgLa5SPk2HI%
>>>>> 3
>>>>> d
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@= ietf.org
>>>> https://na01.= safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.
>>>> ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonyn= ad%40micr
>>>> o
>>>> s
>>>> oft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab= 2d
>>>> 7 c
>>>> d011db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkL= gLa5SPk2HI%3d
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://na01.saf= elinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.
>>> i
>>> etf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40m= icros
>>> o
>>> f
>>> = t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd >>> 0
>>> 1 1db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5S= Pk2HI%3d
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://na01.safelink= s.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.
>> i
>> et= f.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40micro= so
>> f
>> t.co= m%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd0
>> 1 1db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2H= I%3d
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth<= br> >
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing 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


--001a1136a2dc3cfb1f052fe9fb04-- From nobody Thu Apr 7 12:26:46 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134B512D0EF for ; Thu, 7 Apr 2016 12:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cLrPtgcPHYO for ; Thu, 7 Apr 2016 12:26:40 -0700 (PDT) Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.189.228]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9B3312D093 for ; Thu, 7 Apr 2016 12:26:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1460057200; x=1491593200; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Xi/Ut6fM+jpYileZ4GY68seQ2ez+1x16DNJNjEC3cpA=; b=cn7r39TK/4gAHSgDVRcQMwapm78h4b+yeu5BMMsbda5v/E1bqCG59ARr 1W07q6AtwqKZZOT5ilvgxISCo3mymG8EDgIpitLCL1uWb8pKhPXPzDWsW 9IXQuzvvmWn6ONz3lhF6xUKY2WOkb8HDk7z/eRFH32ZOxfyb8QZ8xkEmx U=; X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208,217";a="472329536" Received: from sea19-co-svc-lb5-vlan2.sea.amazon.com (HELO email-inbound-relay-6005.iad6.amazon.com) ([10.47.22.162]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Apr 2016 19:26:38 +0000 Received: from ex10-hub-7002.ant.amazon.com (iad1-ws-svc-lb91-vlan2.amazon.com [10.0.103.146]) by email-inbound-relay-6005.iad6.amazon.com (8.14.7/8.14.7) with ESMTP id u37JQF9e013214 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Apr 2016 19:26:36 GMT Received: from EX13D03UWA002.ant.amazon.com (10.43.160.144) by ex10-hub-7002.ant.amazon.com (10.43.110.153) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 7 Apr 2016 12:26:13 -0700 Received: from EX13D03UWA001.ant.amazon.com (10.43.160.141) by EX13D03UWA002.ant.amazon.com (10.43.160.144) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 7 Apr 2016 19:26:12 +0000 Received: from EX13D03UWA001.ant.amazon.com ([10.43.160.141]) by EX13D03UWA001.ant.amazon.com ([10.43.160.141]) with mapi id 15.00.1104.000; Thu, 7 Apr 2016 19:26:12 +0000 From: "Hardt, Dick" To: William Denniss Thread-Topic: [OAUTH-WG] OAuth 2.1 Thread-Index: AQHRkCrKGgrGTeZ9REu8zO6lyUV5Qp99PcEAgAAQXwCAASSegIAAA/iAgAAyo4CAAA4UgIAAG0OAgAACuQCAAAiOgIAACGNU Date: Thu, 7 Apr 2016 19:26:11 +0000 Message-ID: References: <570548D6.8010605@gmx.net> <57055DE2.50201@aol.com> <7A8E4B64-4741-4A54-84D6-B887690F77B5@erdtman.se> , 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_C33678BFF1024FA69AC925204E71EFE8amazoncom_" MIME-Version: 1.0 Precedence: Bulk Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 19:26:44 -0000 --_000_C33678BFF1024FA69AC925204E71EFE8amazoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable When do we decide there are no more incremental improvements? There has been a ton of work and experience since I was last involved that = is not readily available to your average developer. I suspect the active participants in the WG take all of these items for gra= nted and don't appreciate the delta since the 2.0 spec. -- Dick On Apr 7, 2016, at 3:58 PM, William Denniss > wrote: On Thu, Apr 7, 2016 at 3:25 PM, Mike Jones > wrote: Yes - an intentionally conservative, implementation- and experience-driven = path. Revising OAuth 2.0 is a *big deal*. We shouldn't even be talking about it = until we've completed steps 1-5 below - *including* the "iterate" step, as = necessary. If we get this wrong, we'll fragment OAuth, which is a terrible= and irresponsible outcome we should consciously avoid at all costs. In particular, we should not recharter for an OAuth 2.1 until we already kn= ow what will be in it and know from deployment experience that it's the rig= ht stuff. -- Mike I agree with Mike, it's too soon to consider a 2.1 rev until we've had a ch= ance to test and iterate on the current incremental additions. At some point it would make sense to collect the ones that worked and were = widely deployed into a single doc. -----Original Message----- From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] Sent: Thursday, April 7, 2016 3:16 PM To: Mike Jones > Cc: Samuel Erdtman >; Anthony N= adalin >; oauth@ietf.or= g Subject: Re: [OAUTH-WG] OAuth 2.1 Hi Mike, in my opinion, you described a possible path towards 2.1. Would you agree? best regards, Torsten. > Am 07.04.2016 um 13:38 schrieb Mike Jones >: > > I am strongly against creating a 2.1 spec until we have at least a year o= f deployment experience with the contents we're adding to 2.0, so as not to= fragment the OAuth marketplace. > > I think we should: > 1. Continue working on new security mitigations in new drafts (such > as mix-up-mitigation, etc.) that add features to use with 2.0 2. > Continue working on PoP specs (such as pop-key-distribution, etc.) > that add features to use with 2.0 3. Continue working on other new > specs (such as discovery, resource-indicators, etc.) that add features > to use with 2.0 4. Learn from deployment experience with all of them > 5. Iterate if the deployment experience tells us that we need to > > Only after we believe we have all the features right and we know that the= y work together well should we consider creating a 2.1. If we rush to a 2.= 1 and get it wrong, we'll lose developers' trust and we'll never get it bac= k. > > -- Mike > > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org= ] On Behalf Of Samuel > Erdtman > Sent: Thursday, April 7, 2016 12:48 PM > To: Anthony Nadalin > > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.1 > > +1 on a 2.1 version > > -1 on defining scopes more precisely in 2.1 > > Sent from my iPhone > >> On 7 apr. 2016, at 14:46, Anthony Nadalin > wrote: >> >> I don't belive that scopes should be defined more precisely as this opaq= ueness was a design feature, I'm not seeing the reason why scopes need to b= e defined, as these are application specific. >> >> -----Original Message----- >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten >> Lodderstedt >> Sent: Thursday, April 7, 2016 5:32 AM >> To: George Fletcher > >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] OAuth 2.1 >> >> Hi all, >> >> as I already said in the meeting: I would very much prefer to have an ex= tension/update of RFC 6819 covering all "new" threats, including: >> - mix up >> - code injection aka copy and paste >> - open redirector at AS and client >> - potential other threats in the context of "dynamic" OAuth >> >> I also assume mitigations for (at least some of) the threats need to go = into an update of RFC 6749 as normative text. To give an example: if we agr= ee on using the state parameter at the token endpoint to mitigate code inje= ction, this MUST be part of the core spec (request description and security= consoderations). Otherwise, noone will even consider it. >> >> We should also use the opportunity to improve/enhance the text of the sp= ec. In the course of the last years, we have learned a lot about ambiquitie= s of the text and how different implementations utilize OAuth. >> >> I think time is right to define scopes more precisely. As the discussion= s in the last days proved again (at least for me), scope is not sufficientl= y defined to come up with interoperable implementations. Additionally, ther= e seems to be a need to represent resource server locations (to not say ide= ntities :-)) in this context. >> >> To bundle all changes in a version 2.1 would also make communication int= o the market much easier. >> >> best regards, >> Torsten. >> >>> Am 06.04.2016 um 16:05 schrieb George Fletcher >: >>> >>> I'd definitely prefer a single solution document to many little ones th= at have to be combined to actually build a secure solution. It's already ge= tting complex with the additional specs that have been added. >>> >>> Additionally, I'm not against working on OAuth 2.1. >>> >>> Thanks, >>> George >>> >>>> On 4/6/16 2:06 PM, Phil Hunt (IDM) wrote: >>>> >>>> Existing implementations are for the large part ok and do not need the= se mitigations. >>>> >>>> Only the new use cases we have been discussing (configure on the fly a= nd multi-as, etc) really need mitigation. >>>> >>>> The updated by approach seems like a good way to address the new cases= . >>>> >>>> Phil >>>> >>>>> On Apr 6, 2016, at 14:35, Hannes Tschofenig > wrote: >>>>> >>>>> Hi all, >>>>> >>>>> today we discussed the OAuth Authorization Server Mixup draft. We >>>>> were wondering what types of threats the document should find solutio= ns for. >>>>> >>>>> We discussed various document handling approaches including >>>>> * OAuth Mix-Up and Cut-and-Paste attacks documented in separate >>>>> solution documents >>>>> * combined solution document covering the OAuth Mix-Up and the >>>>> Cut-and-Paste attacks. >>>>> >>>>> Barry pointed out that these documents could update the OAuth base >>>>> specification. >>>>> >>>>> As a more radical change it was also suggested to revise RFC 6749 >>>>> "OAuth >>>>> 2.0 Authorization Framework" and RFC 6819 "OAuth 2.0 Threat Model >>>>> and Security Considerations". >>>>> >>>>> Opening up the OAuth base specification obviously raises various >>>>> other questions about cleaning up parts that go far beyond the AS >>>>> mix-up and the cut-and-paste attacks. Other specifications, such >>>>> as the Open Redirector, could be folded into such a new specification= . >>>>> >>>>> Derek and I would appreciate your input on this topic before we >>>>> make a decision since it has significant impact on our work. >>>>> >>>>> Ciao >>>>> Hannes & Derek >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fw >>>>> w >>>>> w >>>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c0= 1%7ctonynad%40mi >>>>> c >>>>> r >>>>> osoft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f9= 88bf86f141af91a >>>>> b >>>>> 2 >>>>> d7cd011db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI% >>>>> 3 >>>>> d >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww= . >>>> ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%= 7ctonynad%40micr >>>> o >>>> s >>>> oft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf8= 6f141af91ab2d >>>> 7 c >>>> d011db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww. >>> i >>> etf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ct= onynad%40micros >>> o >>> f >>> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141= af91ab2d7cd >>> 0 >>> 1 1db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww. >> i >> etf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7cto= nynad%40microso >> f >> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141a= f91ab2d7cd0 >> 1 1db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >> >> _______________________________________________ >> OAuth mailing 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_C33678BFF1024FA69AC925204E71EFE8amazoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
When do we decide there are no more incremental improvements?

There has been a ton of work and experience = since I was last involved that is not readily available to your average dev= eloper.

I suspect the active participants in the WG = take all of these items for granted and don't appreciate the delta since th= e 2.0 spec.

-- Dick

On Apr 7, 2016, at 3:58 PM, William Denniss <wdenniss@google.com> wrote:


On Thu, Apr 7, 2016 at 3:25 PM, Mike Jones <Michae= l.Jones@microsoft.com> wrote:
Yes - an intentionally conservative, implementation- and experience-driven = path.

Revising OAuth 2.0 is a *big deal*.  We shouldn't even be talking abou= t it until we've completed steps 1-5 below - *including* the "iterate&= quot; step, as necessary.  If we get this wrong, we'll fragment OAuth,= which is a terrible and irresponsible outcome we should consciously avoid at all costs.

In particular, we should not recharter for an OAuth 2.1 until we already kn= ow what will be in it and know from deployment experience that it's the rig= ht stuff.

                     = ;           -- Mike
 
I agree with Mike, it's too soon to consider a 2.1 rev until we've had= a chance to test and iterate on the current incremental additions.

At some point it would make sense to collect the ones that worked and = were widely deployed into a single doc.

 
-----Original Message-----
From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Thursday, April 7, 2016 3:16 PM
To: Mike Jones <Michael.J= ones@microsoft.com>
Cc: Samuel Erdtman <samuel@erdtman.= se>; Anthony Nadalin <to= nynad@microsoft.com>; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.1

Hi Mike,

in my opinion, you described a possible path towards 2.1. Would you agree?<= br>
best regards,
Torsten.

> Am 07.04.2016 um 13:38 schrieb Mike Jones <Michael.Jones@microsoft.com>:
>
> I am strongly against creating a 2.1 spec until we have at least a yea= r of deployment experience with the contents we're adding to 2.0, so as not= to fragment the OAuth marketplace.
>
> I think we should:
> 1.  Continue working on new security mitigations in new drafts (s= uch
> as mix-up-mitigation, etc.) that add features to use with 2.0 2.
> Continue working on PoP specs (such as pop-key-distribution, etc.)
> that add features to use with 2.0 3.  Continue working on other n= ew
> specs (such as discovery, resource-indicators, etc.) that add features=
> to use with 2.0 4.  Learn from deployment experience with all of = them
> 5.  Iterate if the deployment experience tells us that we need to=
>
> Only after we believe we have all the features right and we know that = they work together well should we consider creating a 2.1.  If we rush= to a 2.1 and get it wrong, we'll lose developers' trust and we'll never ge= t it back.
>
>                -- Mike
>
> -----Original Message-----
> From: OAuth [mailto:oauth-bo= unces@ietf.org] On Behalf Of Samuel
> Erdtman
> Sent: Thursday, April 7, 2016 12:48 PM
> To: Anthony Nadalin <tonyn= ad@microsoft.com>
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth 2.1
>
> +1 on a 2.1 version
>
> -1 on defining scopes more precisely in 2.1
>
> Sent from my iPhone
>
>> On 7 apr. 2016, at 14:46, Anthony Nadalin <tonynad@microsoft.com> wrote:
>>
>> I don't belive that scopes should be defined more precisely as thi= s opaqueness was a design feature, I'm not seeing the reason why scopes nee= d to be defined, as these are application specific.
>>
>> -----Original Message-----
>> From: OAuth [mailto:oaut= h-bounces@ietf.org] On Behalf Of Torsten
>> Lodderstedt
>> Sent: Thursday, April 7, 2016 5:32 AM
>> To: George Fletcher <gfflet= ch@aol.com>
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] OAuth 2.1
>>
>> Hi all,
>>
>> as I already said in the meeting: I would very much prefer to have= an extension/update of RFC 6819 covering all "new" threats, incl= uding:
>> - mix up
>> - code injection aka copy and paste
>> - open redirector at AS and client
>> - potential other threats in the context of "dynamic" OA= uth
>>
>> I also assume mitigations for (at least some of) the threats need = to go into an update of RFC 6749 as normative text. To give an example: if = we agree on using the state parameter at the token endpoint to mitigate cod= e injection, this MUST be part of the core spec (request description and security consoderations). Otherwise, no= one will even  consider it.
>>
>> We should also use the opportunity to improve/enhance the text of = the spec. In the course of the last years, we have learned a lot about ambi= quities of the text and how different implementations utilize OAuth.
>>
>> I think time is right to define scopes more precisely. As the disc= ussions in the last days proved again (at least for me), scope is not suffi= ciently defined to come up with interoperable implementations. Additionally= , there seems to be a need to represent resource server locations (to not say identities :-)) in this context.
>>
>> To bundle all changes in a version 2.1 would also make communicati= on into the market much easier.
>>
>> best regards,
>> Torsten.
>>
>>> Am 06.04.2016 um 16:05 schrieb George Fletcher <gffletch@aol.com>:
>>>
>>> I'd definitely prefer a single solution document to many littl= e ones that have to be combined to actually build a secure solution. It's a= lready getting complex with the additional specs that have been added.
>>>
>>> Additionally, I'm not against working on OAuth 2.1.
>>>
>>> Thanks,
>>> George
>>>
>>>> On 4/6/16 2:06 PM, Phil Hunt (IDM) wrote:
>>>>
>>>> Existing implementations are for the large part ok and do = not need these mitigations.
>>>>
>>>> Only the new use cases we have been discussing (configure = on the fly and multi-as, etc) really need mitigation.
>>>>
>>>> The updated by approach seems like a good way to address t= he new cases.
>>>>
>>>> Phil
>>>>
>>>>> On Apr 6, 2016, at 14:35, Hannes Tschofenig <hannes.tschofenig@gmx.net> wr= ote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> today we discussed the OAuth Authorization Server Mixu= p draft. We
>>>>> were wondering what types of threats the document shou= ld find solutions for.
>>>>>
>>>>> We discussed various document handling approaches incl= uding
>>>>> * OAuth Mix-Up and Cut-and-Paste attacks documented in= separate
>>>>> solution documents
>>>>> * combined solution document covering the OAuth Mix-Up= and the
>>>>> Cut-and-Paste attacks.
>>>>>
>>>>> Barry pointed out that these documents could update th= e OAuth base
>>>>> specification.
>>>>>
>>>>> As a more radical change it was also suggested to revi= se RFC 6749
>>>>> "OAuth
>>>>> 2.0 Authorization Framework" and RFC 6819 "O= Auth 2.0 Threat Model
>>>>> and Security Considerations".
>>>>>
>>>>> Opening up the OAuth base specification obviously rais= es various
>>>>> other questions about cleaning up parts that go far be= yond the AS
>>>>> mix-up and the cut-and-paste attacks. Other specificat= ions, such
>>>>> as the Open Redirector, could be folded into such a ne= w specification.
>>>>>
>>>>> Derek and I would appreciate your input on this topic = before we
>>>>> make a decision since it has significant impact on our= work.
>>>>>
>>>>> Ciao
>>>>> Hannes & Derek
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org >>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fw >>>>> w
>>>>> w
>>>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7c= tonynad%40mi
>>>>> c
>>>>> r
>>>>> osoft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f1= 41af91a
>>>>> b
>>>>> 2
>>>>> d7cd011db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6= qYndnkLgLa5SPk2HI%
>>>>> 3
>>>>> d
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.=
>>>> ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonyn= ad%40micr
>>>> o
>>>> s
>>>> oft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab= 2d
>>>> 7 c
>>>> d011db47%7c1&sdata=3DBqcE9eDhm8pgdo= itrPFufouxS6qYndnkLgLa5SPk2HI%3d
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.=
>>> i
>>> etf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40m= icros
>>> o
>>> f
>>> = t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd >>> 0
>>> 1 1db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5S= Pk2HI%3d
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.=
>> i
>> et= f.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40micro= so
>> f
>> t.co= m%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd0
>> 1 1db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2H= I%3d
>>
>> _______________________________________________
>> OAuth mailing 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.i= etf.org/mailman/listinfo/oauth
--_000_C33678BFF1024FA69AC925204E71EFE8amazoncom_-- From nobody Thu Apr 7 13:08:54 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF53D12D66A for ; Thu, 7 Apr 2016 13:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DFt-WcOJgRF for ; Thu, 7 Apr 2016 13:08:49 -0700 (PDT) Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C98612D59F for ; Thu, 7 Apr 2016 13:08:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1460059729; x=1491595729; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=LARUb76fPPPyEDcdeCU98LIX6fOv4NDcFk+owKeHreU=; b=aV2t7sl5Lt1GFiYfaBEGl87exC6WyeQyL7c8hKwDSicG7612qa9PRBAH wDOZCa+WR+KaqteIuJC3SHtxAenerjuYMkO55MA0DXMgNjMcmqWPT6oR+ T7BNZmHWGXN1Tb4fV9ZMnkrhodKKH7FlCK7MHAQqgKyq9mKskP6Zufntt 4=; X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208,217";a="462912098" Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-71009.iad55.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Apr 2016 20:08:48 +0000 Received: from ex10-hub-7001.ant.amazon.com (iad1-ws-svc-lb91-vlan3.amazon.com [10.0.103.150]) by email-inbound-relay-71009.iad55.amazon.com (8.14.7/8.14.7) with ESMTP id u37K8WwJ031886 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Apr 2016 20:08:46 GMT Received: from EX13D03UWA004.ant.amazon.com (10.43.160.250) by ex10-hub-7001.ant.amazon.com (10.43.103.49) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 7 Apr 2016 13:08:29 -0700 Received: from EX13D03UWA001.ant.amazon.com (10.43.160.141) by EX13D03UWA004.ant.amazon.com (10.43.160.250) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 7 Apr 2016 20:08:28 +0000 Received: from EX13D03UWA001.ant.amazon.com ([10.43.160.141]) by EX13D03UWA001.ant.amazon.com ([10.43.160.141]) with mapi id 15.00.1104.000; Thu, 7 Apr 2016 20:08:28 +0000 From: "Hardt, Dick" To: William Denniss , Adam Lewis Thread-Topic: [OAUTH-WG] OAuth 2.1 Thread-Index: AQHRkCrKGgrGTeZ9REu8zO6lyUV5Qp99PcEAgAAQXwCAASSegIAAA/iAgAAyo4CAAA4UgIAAG0OAgAACuQD//9ZOAIAAN6KAgAABhAD//9sQAA== Date: Thu, 7 Apr 2016 20:08:28 +0000 Message-ID: <3C1AEFC9-1DF3-4FCB-8AC5-4459991DE27A@amazon.com> References: <570548D6.8010605@gmx.net> <57055DE2.50201@aol.com> <7A8E4B64-4741-4A54-84D6-B887690F77B5@erdtman.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.39] Content-Type: multipart/alternative; boundary="_000_3C1AEFC91DF34FCB8AC54459991DE27Aamazoncom_" MIME-Version: 1.0 Precedence: Bulk Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 20:08:53 -0000 --_000_3C1AEFC91DF34FCB8AC54459991DE27Aamazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXkgcGVyc29uYWwgaW50ZXJlc3QgaXMgdG8gZ2V0IGEgY2hhbmNlIHRvIHNpbXBsaWZ5IHRoZSBk b2N1bWVudCBhbmQgYWRkIG5vbi1ub3JtYXRpdmUgdGV4dCB0byBjbGFyaWZ5IG1hbnkgb2YgdGhl IGFyZWFzIHRoYXQgaGF2ZSBjYXVzZWQgY29uZnVzaW9uLg0KDQpJ4oCZbSBjbGVhcmx5IGJpYXNl ZCwgYnV0IEkgdGhpbmsgbXkgb3JpZ2luYWwgZHJhZnQgd2FzIG11Y2ggZWFzaWVyIHRvIHJlYWQg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhcmR0LW9hdXRoLTAxDQoNCkl0IGNv dWxkIGJlIDIuMSBvciAyLjAueCBvciAyLjBBDQoNCk9uIDQvNy8xNiwgNDoyMCBQTSwgc29tZW9u ZSBjbGFpbWluZyB0byBiZSAiV2lsbGlhbSBEZW5uaXNzIiA8d2Rlbm5pc3NAZ29vZ2xlLmNvbTxt YWlsdG86d2Rlbm5pc3NAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KDQpGYWlyIHBvaW50cy4gSSBhbHNv IHRoaW5rIHRoaXMgaXMgYW4gYXJlYSB3aGVyZSBnb29kIG9ubGluZSBkb2N1bWVudGF0aW9uLCBh bmQgYm9va3MgbGlrZSBPQXV0aCAyIGluIEFjdGlvbiBjYW4gaGVscCwgYW5kIHBvc3NpYmx5IGhl bHAgYSBsb3Qgc29vbmVyLg0KDQpPbiBUaHUsIEFwciA3LCAyMDE2IGF0IDQ6MTUgUE0sIEFkYW0g TGV3aXMgPGFkYW0ubGV3aXNAbW90b3JvbGFzb2x1dGlvbnMuY29tPG1haWx0bzphZGFtLmxld2lz QG1vdG9yb2xhc29sdXRpb25zLmNvbT4+IHdyb3RlOg0KKzENCg0KSSB3aWxsIG5vdCBjb21tZW50 IG9uIHRoZSB0aW1lbGluZSBmb3IgdGhpcywgYnV0IEkgd2lsbCBwYXNzaW9uYXRlbHkgZW5kb3Jz ZSB0aGUgbmVlZCBmb3IgYW4gT0F1dGggMi4xIHNwZWMuDQoNClNwZWFraW5nIGFzIHNvbWVib2R5 IHdobyBub3cgaGFzIHNwZW50IHllYXJzIGFkdm9jYXRpbmcgZm9yLCBhbmQgYnVpbGRpbmcgb3V0 IHB1YmxpYyBzYWZldHkgLyBmaXJzdCByZXNwb25kZXIgYXJjaGl0ZWN0dXJlcyBidWlsdCBvbiBh biBPQXV0aCAyLjAgYXJjaGl0ZWN0dXJlLCBJIGNhbiBzYXkgMiB0aGluZ3Mgd2l0aCBjb252aWN0 aW9uOg0KDQpUaGUgZ29vZDogT0F1dGggMi4wIGhhcyBlbmFibGVkIGluY3JlZGlibGUgdXNlIGNh c2VzIGZvciB1cywgYW5kIGl0IGlzIGEgZ2lmdCB0aGF0IGtlZXBzIG9uIGdpdmluZywgdGhlIG5l dyBXRyBlZmZvcnRzIGFyb3VuZCBQT1AgYW5kIHRva2VuIGV4Y2hhbmdlIGFyZSBzb2x2aW5nIGV2 ZW4gbW9yZSB1c2UgY2FzZXMgZm9yIHVzLiAgVGhpcyBpcyBoYW5kcyBkb3duIG9uZSBvZiB0aGUg YmVzdCBXR3MgSSd2ZSBrbm93biwgYW5kIHRoZSB3b3JrIGRvbmUgaGVyZSBpcyBub3RoaW5nIHNo b3J0IG9mIGF3ZXNvbWUuDQoNClRoZSBiYWQ6IEkgaGF2ZSB5ZXQgdG8gbWVldCBhbnlib2R5IG91 dHNpZGUgb2YgdGhlIFdHIHRoYXQgcmVhbGx5IHVuZGVyc3RhbmRzIE9BdXRoIDIuMC4gIEkgbWVh biAicmVhbGx5IiB1bmRlcnN0YW5kcyBpdC4gICh0byB0aGlzIGRheSwgSSBzdGlsbCB0aGluayBp dCBpcyBvbmx5IGJlY2F1c2Ugb2YgdGhlIGdvb2QgZ3JhY2VzIG9mIG90aGVycyBpbiB0aGlzIFdH IGxpa2UgSm9obiBhbmQgSnVzdGluIHRoYXQgSSB1bmRlcnN0YW5kIGl0IHdpdGggdGhlIGRlcHRo IHRoYXQgSSBkbykuICBQZW9wbGUgdGFsayBhYm91dCBpdCBhdCBoaWdoIGxldmVscywgdGhleSB0 YWxrIGFib3V0IHRva2VucywgYnV0IHN0aWxsIGRvbid0IGdldCB3aGF0IGl0IGlzIHRyeWluZyB0 byBzb2x2ZSBub3IgaG93IHRvIHNlY3VyZWx5IGRlcGxveSBpdC4gOTklIG9mIHRoZSBwZW9wbGUg SSBtZWV0IHN0aWxsIGRvbid0IGdldCB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIGF1dGhlbnRpY2F0 aW9uIGFuZCBkZWxlZ2F0ZWQgYXV0aG9yaXphdGlvbi4gIEkgaGF2ZSBkZWRpY2F0ZWQgbWFzc2l2 ZSBhbW91bnRzIG9mIGN5Y2xlcyB0cnlpbmcgdG8gZWR1Y2F0ZSBteSBvd24gY29tbXVuaXR5IChh bmQgYW55Ym9keSBlbHNlIEkgbWVldCBmb3IgdGhhdCBtYXR0ZXIpLiAgSSBwZXJzb25hbGx5IGZv dW5kIHRoZSBjb3JlIFJGQyB2ZXJ5IGhhcmQgdG8gZGlnZXN0LCBhbmQgbm93IEkgbmVlZCB0byBy ZWZlciB0byBOIG1vcmUsIG1hbnkgb2Ygd2hpY2ggc2hvdWxkIGJlIGZvbGRlZCBpbnRvIGEgbmV3 IDIuMSBjb3JlIHNwZWMuICBBbGwgdGhpcyBnaXZlbiwgSXQgaXMgbm8gd29uZGVyIHRoZXJlIGFy ZSBzbyBtYW55IGluc2VjdXJlIGltcGxlbWVudGF0aW9ucyBvZiBpdC4NCg0KU28gaGVyZSdzIHRv IE9BdXRoIDIuMSA6LSkNCg0KLWFkYW0NCg0KT24gVGh1LCBBcHIgNywgMjAxNiBhdCAxOjU2IFBN LCBIYXJkdCwgRGljayA8ZGlja0BhbWF6b24uY29tPG1haWx0bzpkaWNrQGFtYXpvbi5jb20+PiB3 cm90ZToNCkkgdGhpbmsgdGhlcmUgYXJlIGFscmVhZHkgeWVhcnMgb2YgaW1wbGVtZW50YXRpb24g YW5kIGV4cGVyaWVuY2Ugc2luY2UgMi4wDQoNCklmIHdlIHdhaXQgdW50aWwgYWxsIHRoZSBvdXRz dGFuZGluZyBpc3N1ZXMgYW5kIG5ldyBmZWF0dXJlcyBoYXZlIGhhZCBpbXBsZW1lbnRhdGlvbnMg YW5kIGV4cGVyaWVuY2UsIHdlIHdpbGwgbmV2ZXIgZG8gYSAyLjEgYXMgdGhlcmUgY29udGludWVz IHRvIGJlIG5ldyB0aGluZ3MuDQoNCkkgd291bGQgc3VnZ2VzdCBhIDIuMSBiZSBhIGNsZWFuLCBz aW1wbGUgZG9jdW1lbnQgb2YgdGhlIGNvcmUgc3BlYyBpbiBvbmUgZG9jdW1lbnQgdGhhdCBpbmNs dWRlcyB0aGUgc2VjdXJpdHkgYW5kIGltcGxlbWVudGF0aW9uIHJlY29tbWVuZGF0aW9ucy4NCg0K QWx0ZXJuYXRpdmUgdGl0bGU6IE9BdXRoLCBUaGUgR29vZCBQYXJ0cy4gOikNCg0K4oCUIERpY2sN Cg0KDQoNCg0KT24gNC83LzE2LCAzOjI1IFBNLCBzb21lb25lIGNsYWltaW5nIHRvIGJlICJPQXV0 aCBvbiBiZWhhbGYgb2YgTWlrZSBKb25lcyIgPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv Om9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KDQpZ ZXMgLSBhbiBpbnRlbnRpb25hbGx5IGNvbnNlcnZhdGl2ZSwgaW1wbGVtZW50YXRpb24tIGFuZCBl eHBlcmllbmNlLWRyaXZlbiBwYXRoLg0KDQpSZXZpc2luZyBPQXV0aCAyLjAgaXMgYSAqYmlnIGRl YWwqLiAgV2Ugc2hvdWxkbid0IGV2ZW4gYmUgdGFsa2luZyBhYm91dCBpdCB1bnRpbCB3ZSd2ZSBj b21wbGV0ZWQgc3RlcHMgMS01IGJlbG93IC0gKmluY2x1ZGluZyogdGhlICJpdGVyYXRlIiBzdGVw LCBhcyBuZWNlc3NhcnkuICBJZiB3ZSBnZXQgdGhpcyB3cm9uZywgd2UnbGwgZnJhZ21lbnQgT0F1 dGgsIHdoaWNoIGlzIGEgdGVycmlibGUgYW5kIGlycmVzcG9uc2libGUgb3V0Y29tZSB3ZSBzaG91 bGQgY29uc2Npb3VzbHkgYXZvaWQgYXQgYWxsIGNvc3RzLg0KDQpJbiBwYXJ0aWN1bGFyLCB3ZSBz aG91bGQgbm90IHJlY2hhcnRlciBmb3IgYW4gT0F1dGggMi4xIHVudGlsIHdlIGFscmVhZHkga25v dyB3aGF0IHdpbGwgYmUgaW4gaXQgYW5kIGtub3cgZnJvbSBkZXBsb3ltZW50IGV4cGVyaWVuY2Ug dGhhdCBpdCdzIHRoZSByaWdodCBzdHVmZi4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAtLSBNaWtlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBUb3JzdGVu IExvZGRlcnN0ZWR0IFttYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8bWFpbHRvOnRvcnN0 ZW5AbG9kZGVyc3RlZHQubmV0Pl0NClNlbnQ6IFRodXJzZGF5LCBBcHJpbCA3LCAyMDE2IDM6MTYg UE0NClRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1p Y2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+DQpDYzogU2FtdWVsIEVyZHRtYW4gPHNhbXVlbEBl cmR0bWFuLnNlPG1haWx0bzpzYW11ZWxAZXJkdG1hbi5zZT4+OyBBbnRob255IE5hZGFsaW4gPHRv bnluYWRAbWljcm9zb2Z0LmNvbTxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPj47IG9hdXRo QGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0dd IE9BdXRoIDIuMQ0KDQpIaSBNaWtlLA0KDQppbiBteSBvcGluaW9uLCB5b3UgZGVzY3JpYmVkIGEg cG9zc2libGUgcGF0aCB0b3dhcmRzIDIuMS4gV291bGQgeW91IGFncmVlPw0KDQpiZXN0IHJlZ2Fy ZHMsDQpUb3JzdGVuLg0KDQo+IEFtIDA3LjA0LjIwMTYgdW0gMTM6Mzggc2NocmllYiBNaWtlIEpv bmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWlj cm9zb2Z0LmNvbT4+Og0KPg0KPiBJIGFtIHN0cm9uZ2x5IGFnYWluc3QgY3JlYXRpbmcgYSAyLjEg c3BlYyB1bnRpbCB3ZSBoYXZlIGF0IGxlYXN0IGEgeWVhciBvZiBkZXBsb3ltZW50IGV4cGVyaWVu Y2Ugd2l0aCB0aGUgY29udGVudHMgd2UncmUgYWRkaW5nIHRvIDIuMCwgc28gYXMgbm90IHRvIGZy YWdtZW50IHRoZSBPQXV0aCBtYXJrZXRwbGFjZS4NCj4NCj4gSSB0aGluayB3ZSBzaG91bGQ6DQo+ IDEuICBDb250aW51ZSB3b3JraW5nIG9uIG5ldyBzZWN1cml0eSBtaXRpZ2F0aW9ucyBpbiBuZXcg ZHJhZnRzIChzdWNoDQo+IGFzIG1peC11cC1taXRpZ2F0aW9uLCBldGMuKSB0aGF0IGFkZCBmZWF0 dXJlcyB0byB1c2Ugd2l0aCAyLjAgMi4NCj4gQ29udGludWUgd29ya2luZyBvbiBQb1Agc3BlY3Mg KHN1Y2ggYXMgcG9wLWtleS1kaXN0cmlidXRpb24sIGV0Yy4pDQo+IHRoYXQgYWRkIGZlYXR1cmVz IHRvIHVzZSB3aXRoIDIuMCAzLiAgQ29udGludWUgd29ya2luZyBvbiBvdGhlciBuZXcNCj4gc3Bl Y3MgKHN1Y2ggYXMgZGlzY292ZXJ5LCByZXNvdXJjZS1pbmRpY2F0b3JzLCBldGMuKSB0aGF0IGFk ZCBmZWF0dXJlcw0KPiB0byB1c2Ugd2l0aCAyLjAgNC4gIExlYXJuIGZyb20gZGVwbG95bWVudCBl eHBlcmllbmNlIHdpdGggYWxsIG9mIHRoZW0NCj4gNS4gIEl0ZXJhdGUgaWYgdGhlIGRlcGxveW1l bnQgZXhwZXJpZW5jZSB0ZWxscyB1cyB0aGF0IHdlIG5lZWQgdG8NCj4NCj4gT25seSBhZnRlciB3 ZSBiZWxpZXZlIHdlIGhhdmUgYWxsIHRoZSBmZWF0dXJlcyByaWdodCBhbmQgd2Uga25vdyB0aGF0 IHRoZXkgd29yayB0b2dldGhlciB3ZWxsIHNob3VsZCB3ZSBjb25zaWRlciBjcmVhdGluZyBhIDIu MS4gIElmIHdlIHJ1c2ggdG8gYSAyLjEgYW5kIGdldCBpdCB3cm9uZywgd2UnbGwgbG9zZSBkZXZl bG9wZXJzJyB0cnVzdCBhbmQgd2UnbGwgbmV2ZXIgZ2V0IGl0IGJhY2suDQo+DQo+ICAgICAgICAg ICAgICAgIC0tIE1pa2UNCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog T0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2Vz QGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFNhbXVlbA0KPiBFcmR0bWFuDQo+IFNlbnQ6IFRodXJz ZGF5LCBBcHJpbCA3LCAyMDE2IDEyOjQ4IFBNDQo+IFRvOiBBbnRob255IE5hZGFsaW4gPHRvbnlu YWRAbWljcm9zb2Z0LmNvbTxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPj4NCj4gQ2M6IG9h dXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFtPQVVU SC1XR10gT0F1dGggMi4xDQo+DQo+ICsxIG9uIGEgMi4xIHZlcnNpb24NCj4NCj4gLTEgb24gZGVm aW5pbmcgc2NvcGVzIG1vcmUgcHJlY2lzZWx5IGluIDIuMQ0KPg0KPiBTZW50IGZyb20gbXkgaVBo b25lDQo+DQo+PiBPbiA3IGFwci4gMjAxNiwgYXQgMTQ6NDYsIEFudGhvbnkgTmFkYWxpbiA8dG9u eW5hZEBtaWNyb3NvZnQuY29tPG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20+PiB3cm90ZToN Cj4+DQo+PiBJIGRvbid0IGJlbGl2ZSB0aGF0IHNjb3BlcyBzaG91bGQgYmUgZGVmaW5lZCBtb3Jl IHByZWNpc2VseSBhcyB0aGlzIG9wYXF1ZW5lc3Mgd2FzIGEgZGVzaWduIGZlYXR1cmUsIEknbSBu b3Qgc2VlaW5nIHRoZSByZWFzb24gd2h5IHNjb3BlcyBuZWVkIHRvIGJlIGRlZmluZWQsIGFzIHRo ZXNlIGFyZSBhcHBsaWNhdGlvbiBzcGVjaWZpYy4NCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj4gRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFRvcnN0ZW4NCj4+IExv ZGRlcnN0ZWR0DQo+PiBTZW50OiBUaHVyc2RheSwgQXByaWwgNywgMjAxNiA1OjMyIEFNDQo+PiBU bzogR2VvcmdlIEZsZXRjaGVyIDxnZmZsZXRjaEBhb2wuY29tPG1haWx0bzpnZmZsZXRjaEBhb2wu Y29tPj4NCj4+IENjOiBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQo+PiBT dWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjENCj4+DQo+PiBIaSBhbGwsDQo+Pg0KPj4g YXMgSSBhbHJlYWR5IHNhaWQgaW4gdGhlIG1lZXRpbmc6IEkgd291bGQgdmVyeSBtdWNoIHByZWZl ciB0byBoYXZlIGFuIGV4dGVuc2lvbi91cGRhdGUgb2YgUkZDIDY4MTkgY292ZXJpbmcgYWxsICJu ZXciIHRocmVhdHMsIGluY2x1ZGluZzoNCj4+IC0gbWl4IHVwDQo+PiAtIGNvZGUgaW5qZWN0aW9u IGFrYSBjb3B5IGFuZCBwYXN0ZQ0KPj4gLSBvcGVuIHJlZGlyZWN0b3IgYXQgQVMgYW5kIGNsaWVu dA0KPj4gLSBwb3RlbnRpYWwgb3RoZXIgdGhyZWF0cyBpbiB0aGUgY29udGV4dCBvZiAiZHluYW1p YyIgT0F1dGgNCj4+DQo+PiBJIGFsc28gYXNzdW1lIG1pdGlnYXRpb25zIGZvciAoYXQgbGVhc3Qg c29tZSBvZikgdGhlIHRocmVhdHMgbmVlZCB0byBnbyBpbnRvIGFuIHVwZGF0ZSBvZiBSRkMgNjc0 OSBhcyBub3JtYXRpdmUgdGV4dC4gVG8gZ2l2ZSBhbiBleGFtcGxlOiBpZiB3ZSBhZ3JlZSBvbiB1 c2luZyB0aGUgc3RhdGUgcGFyYW1ldGVyIGF0IHRoZSB0b2tlbiBlbmRwb2ludCB0byBtaXRpZ2F0 ZSBjb2RlIGluamVjdGlvbiwgdGhpcyBNVVNUIGJlIHBhcnQgb2YgdGhlIGNvcmUgc3BlYyAocmVx dWVzdCBkZXNjcmlwdGlvbiBhbmQgc2VjdXJpdHkgY29uc29kZXJhdGlvbnMpLiBPdGhlcndpc2Us IG5vb25lIHdpbGwgZXZlbiAgY29uc2lkZXIgaXQuDQo+Pg0KPj4gV2Ugc2hvdWxkIGFsc28gdXNl IHRoZSBvcHBvcnR1bml0eSB0byBpbXByb3ZlL2VuaGFuY2UgdGhlIHRleHQgb2YgdGhlIHNwZWMu IEluIHRoZSBjb3Vyc2Ugb2YgdGhlIGxhc3QgeWVhcnMsIHdlIGhhdmUgbGVhcm5lZCBhIGxvdCBh Ym91dCBhbWJpcXVpdGllcyBvZiB0aGUgdGV4dCBhbmQgaG93IGRpZmZlcmVudCBpbXBsZW1lbnRh dGlvbnMgdXRpbGl6ZSBPQXV0aC4NCj4+DQo+PiBJIHRoaW5rIHRpbWUgaXMgcmlnaHQgdG8gZGVm aW5lIHNjb3BlcyBtb3JlIHByZWNpc2VseS4gQXMgdGhlIGRpc2N1c3Npb25zIGluIHRoZSBsYXN0 IGRheXMgcHJvdmVkIGFnYWluIChhdCBsZWFzdCBmb3IgbWUpLCBzY29wZSBpcyBub3Qgc3VmZmlj aWVudGx5IGRlZmluZWQgdG8gY29tZSB1cCB3aXRoIGludGVyb3BlcmFibGUgaW1wbGVtZW50YXRp b25zLiBBZGRpdGlvbmFsbHksIHRoZXJlIHNlZW1zIHRvIGJlIGEgbmVlZCB0byByZXByZXNlbnQg cmVzb3VyY2Ugc2VydmVyIGxvY2F0aW9ucyAodG8gbm90IHNheSBpZGVudGl0aWVzIDotKSkgaW4g dGhpcyBjb250ZXh0Lg0KPj4NCj4+IFRvIGJ1bmRsZSBhbGwgY2hhbmdlcyBpbiBhIHZlcnNpb24g Mi4xIHdvdWxkIGFsc28gbWFrZSBjb21tdW5pY2F0aW9uIGludG8gdGhlIG1hcmtldCBtdWNoIGVh c2llci4NCj4+DQo+PiBiZXN0IHJlZ2FyZHMsDQo+PiBUb3JzdGVuLg0KPj4NCj4+PiBBbSAwNi4w NC4yMDE2IHVtIDE2OjA1IHNjaHJpZWIgR2VvcmdlIEZsZXRjaGVyIDxnZmZsZXRjaEBhb2wuY29t PG1haWx0bzpnZmZsZXRjaEBhb2wuY29tPj46DQo+Pj4NCj4+PiBJJ2QgZGVmaW5pdGVseSBwcmVm ZXIgYSBzaW5nbGUgc29sdXRpb24gZG9jdW1lbnQgdG8gbWFueSBsaXR0bGUgb25lcyB0aGF0IGhh dmUgdG8gYmUgY29tYmluZWQgdG8gYWN0dWFsbHkgYnVpbGQgYSBzZWN1cmUgc29sdXRpb24uIEl0 J3MgYWxyZWFkeSBnZXR0aW5nIGNvbXBsZXggd2l0aCB0aGUgYWRkaXRpb25hbCBzcGVjcyB0aGF0 IGhhdmUgYmVlbiBhZGRlZC4NCj4+Pg0KPj4+IEFkZGl0aW9uYWxseSwgSSdtIG5vdCBhZ2FpbnN0 IHdvcmtpbmcgb24gT0F1dGggMi4xLg0KPj4+DQo+Pj4gVGhhbmtzLA0KPj4+IEdlb3JnZQ0KPj4+ DQo+Pj4+IE9uIDQvNi8xNiAyOjA2IFBNLCBQaGlsIEh1bnQgKElETSkgd3JvdGU6DQo+Pj4+DQo+ Pj4+IEV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBhcmUgZm9yIHRoZSBsYXJnZSBwYXJ0IG9rIGFu ZCBkbyBub3QgbmVlZCB0aGVzZSBtaXRpZ2F0aW9ucy4NCj4+Pj4NCj4+Pj4gT25seSB0aGUgbmV3 IHVzZSBjYXNlcyB3ZSBoYXZlIGJlZW4gZGlzY3Vzc2luZyAoY29uZmlndXJlIG9uIHRoZSBmbHkg YW5kIG11bHRpLWFzLCBldGMpIHJlYWxseSBuZWVkIG1pdGlnYXRpb24uDQo+Pj4+DQo+Pj4+IFRo ZSB1cGRhdGVkIGJ5IGFwcHJvYWNoIHNlZW1zIGxpa2UgYSBnb29kIHdheSB0byBhZGRyZXNzIHRo ZSBuZXcgY2FzZXMuDQo+Pj4+DQo+Pj4+IFBoaWwNCj4+Pj4NCj4+Pj4+IE9uIEFwciA2LCAyMDE2 LCBhdCAxNDozNSwgSGFubmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ8 bWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+PiB3cm90ZToNCj4+Pj4+DQo+Pj4+PiBI aSBhbGwsDQo+Pj4+Pg0KPj4+Pj4gdG9kYXkgd2UgZGlzY3Vzc2VkIHRoZSBPQXV0aCBBdXRob3Jp emF0aW9uIFNlcnZlciBNaXh1cCBkcmFmdC4gV2UNCj4+Pj4+IHdlcmUgd29uZGVyaW5nIHdoYXQg dHlwZXMgb2YgdGhyZWF0cyB0aGUgZG9jdW1lbnQgc2hvdWxkIGZpbmQgc29sdXRpb25zIGZvci4N Cj4+Pj4+DQo+Pj4+PiBXZSBkaXNjdXNzZWQgdmFyaW91cyBkb2N1bWVudCBoYW5kbGluZyBhcHBy b2FjaGVzIGluY2x1ZGluZw0KPj4+Pj4gKiBPQXV0aCBNaXgtVXAgYW5kIEN1dC1hbmQtUGFzdGUg YXR0YWNrcyBkb2N1bWVudGVkIGluIHNlcGFyYXRlDQo+Pj4+PiBzb2x1dGlvbiBkb2N1bWVudHMN Cj4+Pj4+ICogY29tYmluZWQgc29sdXRpb24gZG9jdW1lbnQgY292ZXJpbmcgdGhlIE9BdXRoIE1p eC1VcCBhbmQgdGhlDQo+Pj4+PiBDdXQtYW5kLVBhc3RlIGF0dGFja3MuDQo+Pj4+Pg0KPj4+Pj4g QmFycnkgcG9pbnRlZCBvdXQgdGhhdCB0aGVzZSBkb2N1bWVudHMgY291bGQgdXBkYXRlIHRoZSBP QXV0aCBiYXNlDQo+Pj4+PiBzcGVjaWZpY2F0aW9uLg0KPj4+Pj4NCj4+Pj4+IEFzIGEgbW9yZSBy YWRpY2FsIGNoYW5nZSBpdCB3YXMgYWxzbyBzdWdnZXN0ZWQgdG8gcmV2aXNlIFJGQyA2NzQ5DQo+ Pj4+PiAiT0F1dGgNCj4+Pj4+IDIuMCBBdXRob3JpemF0aW9uIEZyYW1ld29yayIgYW5kIFJGQyA2 ODE5ICJPQXV0aCAyLjAgVGhyZWF0IE1vZGVsDQo+Pj4+PiBhbmQgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMiLg0KPj4+Pj4NCj4+Pj4+IE9wZW5pbmcgdXAgdGhlIE9BdXRoIGJhc2Ugc3BlY2lmaWNh dGlvbiBvYnZpb3VzbHkgcmFpc2VzIHZhcmlvdXMNCj4+Pj4+IG90aGVyIHF1ZXN0aW9ucyBhYm91 dCBjbGVhbmluZyB1cCBwYXJ0cyB0aGF0IGdvIGZhciBiZXlvbmQgdGhlIEFTDQo+Pj4+PiBtaXgt dXAgYW5kIHRoZSBjdXQtYW5kLXBhc3RlIGF0dGFja3MuIE90aGVyIHNwZWNpZmljYXRpb25zLCBz dWNoDQo+Pj4+PiBhcyB0aGUgT3BlbiBSZWRpcmVjdG9yLCBjb3VsZCBiZSBmb2xkZWQgaW50byBz dWNoIGEgbmV3IHNwZWNpZmljYXRpb24uDQo+Pj4+Pg0KPj4+Pj4gRGVyZWsgYW5kIEkgd291bGQg YXBwcmVjaWF0ZSB5b3VyIGlucHV0IG9uIHRoaXMgdG9waWMgYmVmb3JlIHdlDQo+Pj4+PiBtYWtl IGEgZGVjaXNpb24gc2luY2UgaXQgaGFzIHNpZ25pZmljYW50IGltcGFjdCBvbiBvdXIgd29yay4N Cj4+Pj4+DQo+Pj4+PiBDaWFvDQo+Pj4+PiBIYW5uZXMgJiBEZXJlaw0KPj4+Pj4NCj4+Pj4+DQo+ Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ Pj4gT0F1dGggbWFpbGluZyBsaXN0DQo+Pj4+PiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhA aWV0Zi5vcmc+DQo+Pj4+PiBodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v ay5jb20vP3VybD1odHRwcyUzYSUyZiUyZncNCj4+Pj4+IHcNCj4+Pj4+IHcNCj4+Pj4+IC5pZXRm Lm9yZzxodHRwOi8vaWV0Zi5vcmc+JTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmZGF0YT0w MSU3YzAxJTdjdG9ueW5hZCU0MG1pDQo+Pj4+PiBjDQo+Pj4+PiByDQo+Pj4+PiBvc29mdC5jb208 aHR0cDovL29zb2Z0LmNvbT4lN2NjZThjOTQyYmVkODE0MzdhY2EwNDA4ZDM1ZWUwYmUyMSU3Yzcy Zjk4OGJmODZmMTQxYWY5MWENCj4+Pj4+IGINCj4+Pj4+IDINCj4+Pj4+IGQ3Y2QwMTFkYjQ3JTdj MSZzZGF0YT1CcWNFOWVEaG04cGdkb2l0clBGdWZvdXhTNnFZbmRua0xnTGE1U1BrMkhJJQ0KPj4+ Pj4gMw0KPj4+Pj4gZA0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+Pj4gT0F1dGhAaWV0Zi5vcmc8 bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPj4+PiBodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3Rl Y3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy4NCj4+Pj4gaWV0Zi5vcmc8 aHR0cDovL2lldGYub3JnPiUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRhdGE9MDElN2Mw MSU3Y3RvbnluYWQlNDBtaWNyDQo+Pj4+IG8NCj4+Pj4gcw0KPj4+PiBvZnQuY29tPGh0dHA6Ly9v ZnQuY29tPiU3Y2NlOGM5NDJiZWQ4MTQzN2FjYTA0MDhkMzVlZTBiZTIxJTdjNzJmOTg4YmY4NmYx NDFhZjkxYWIyZA0KPj4+PiA3IGMNCj4+Pj4gZDAxMWRiNDclN2MxJnNkYXRhPUJxY0U5ZURobThw Z2RvaXRyUEZ1Zm91eFM2cVluZG5rTGdMYTVTUGsySEklM2QNCj4+Pg0KPj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gT0F1dGggbWFpbGluZyBs aXN0DQo+Pj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPj4+IGh0dHBz Oi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJm JTJmd3d3Lg0KPj4+IGkNCj4+PiBldGYub3JnPGh0dHA6Ly9ldGYub3JnPiUyZm1haWxtYW4lMmZs aXN0aW5mbyUyZm9hdXRoJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3MNCj4+PiBvDQo+ Pj4gZg0KPj4+IHQuY29tPGh0dHA6Ly90LmNvbT4lN2NjZThjOTQyYmVkODE0MzdhY2EwNDA4ZDM1 ZWUwYmUyMSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QNCj4+PiAwDQo+Pj4gMSAxZGI0NyU3 YzEmc2RhdGE9QnFjRTllRGhtOHBnZG9pdHJQRnVmb3V4UzZxWW5kbmtMZ0xhNVNQazJISSUzZA0K Pj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRm Lm9yZz4NCj4+IGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHBzJTNhJTJmJTJmd3d3Lg0KPj4gaQ0KPj4gZXRmLm9yZzxodHRwOi8vZXRmLm9yZz4l MmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWlj cm9zbw0KPj4gZg0KPj4gdC5jb208aHR0cDovL3QuY29tPiU3Y2NlOGM5NDJiZWQ4MTQzN2FjYTA0 MDhkMzVlZTBiZTIxJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDANCj4+IDEgMWRiNDclN2Mx JnNkYXRhPUJxY0U5ZURobThwZ2RvaXRyUEZ1Zm91eFM2cVluZG5rTGdMYTVTUGsySEklM2QNCj4+ DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4g T0F1dGggbWFpbGluZyBsaXN0DQo+PiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5v cmc+DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+DQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9BdXRo IG1haWxpbmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4NCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGlu ZyBsaXN0DQo+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0 aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0 bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0K --_000_3C1AEFC91DF34FCB8AC54459991DE27Aamazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <18C3E39A03470A4B9B7A2C2E96515CE4@ant.amazon.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pk15IHBlcnNvbmFsIGludGVyZXN0IGlzIHRvIGdldCBhIGNoYW5jZSB0byBzaW1wbGlmeSB0 aGUgZG9jdW1lbnQgYW5kIGFkZCBub24tbm9ybWF0aXZlIHRleHQgdG8gY2xhcmlmeSBtYW55IG9m IHRoZSBhcmVhcyB0aGF0IGhhdmUgY2F1c2VkIGNvbmZ1c2lvbi48L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PknigJltIGNsZWFybHkgYmlhc2VkLCBidXQgSSB0aGluayBteSBvcmlnaW5h bCBkcmFmdCB3YXMgbXVjaCBlYXNpZXIgdG8gcmVhZCZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oYXJkdC1vYXV0aC0wMSI+aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWhhcmR0LW9hdXRoLTAxPC9hPjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+SXQgY291bGQgYmUgMi4xIG9yIDIuMC54IG9yIDIuMEE8L2Rpdj4NCjxkaXY+DQo8 ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+ DQo8ZGl2Pg0KPGRpdj5PbiA0LzcvMTYsIDQ6MjAgUE0sIHNvbWVvbmUgY2xhaW1pbmcgdG8gYmUg JnF1b3Q7V2lsbGlhbSBEZW5uaXNzJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86d2Rlbm5pc3NA Z29vZ2xlLmNvbSI+d2Rlbm5pc3NAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJ QlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQ QURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGly PSJsdHIiPkZhaXIgcG9pbnRzLiBJIGFsc28gdGhpbmsgdGhpcyBpcyBhbiBhcmVhIHdoZXJlIGdv b2Qgb25saW5lIGRvY3VtZW50YXRpb24sIGFuZCBib29rcyBsaWtlDQo8aT5PQXV0aCAyIGluIEFj dGlvbjwvaT4gY2FuIGhlbHAsIGFuZCBwb3NzaWJseSBoZWxwIGEgbG90IHNvb25lci4NCjxkaXYg Y2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gVGh1 LCBBcHIgNywgMjAxNiBhdCA0OjE1IFBNLCBBZGFtIExld2lzIDxzcGFuIGRpcj0ibHRyIj4NCiZs dDs8YSBocmVmPSJtYWlsdG86YWRhbS5sZXdpc0Btb3Rvcm9sYXNvbHV0aW9ucy5jb20iIHRhcmdl dD0iX2JsYW5rIj5hZGFtLmxld2lzQG1vdG9yb2xhc29sdXRpb25zLmNvbTwvYT4mZ3Q7PC9zcGFu PiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJn aW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4 Ij4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj4mIzQzOzE8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQpJIHdpbGwgbm90IGNvbW1lbnQgb24gdGhlIHRpbWVsaW5lIGZvciB0aGlzLCBidXQgSSB3aWxs IHBhc3Npb25hdGVseSBlbmRvcnNlIHRoZSBuZWVkIGZvciBhbiBPQXV0aCAyLjEgc3BlYy4mbmJz cDsNCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlNwZWFraW5nIGFzIHNvbWVib2R5IHdobyBub3cg aGFzIHNwZW50IHllYXJzIGFkdm9jYXRpbmcgZm9yLCBhbmQgYnVpbGRpbmcgb3V0IHB1YmxpYyBz YWZldHkgLyBmaXJzdCByZXNwb25kZXIgYXJjaGl0ZWN0dXJlcyBidWlsdCBvbiBhbiBPQXV0aCAy LjAgYXJjaGl0ZWN0dXJlLCBJIGNhbiBzYXkgMiB0aGluZ3Mgd2l0aCBjb252aWN0aW9uOiZuYnNw OzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlIGdvb2Q6IE9BdXRoIDIuMCBoYXMg ZW5hYmxlZCBpbmNyZWRpYmxlIHVzZSBjYXNlcyBmb3IgdXMsIGFuZCBpdCBpcyBhIGdpZnQgdGhh dCBrZWVwcyBvbiBnaXZpbmcsIHRoZSBuZXcgV0cgZWZmb3J0cyBhcm91bmQgUE9QIGFuZCB0b2tl biBleGNoYW5nZSBhcmUgc29sdmluZyBldmVuIG1vcmUgdXNlIGNhc2VzIGZvciB1cy4mbmJzcDsg VGhpcyBpcyBoYW5kcyBkb3duIG9uZSBvZiB0aGUgYmVzdCBXR3MgSSd2ZSBrbm93biwgYW5kIHRo ZSB3b3JrDQogZG9uZSBoZXJlIGlzIG5vdGhpbmcgc2hvcnQgb2YgYXdlc29tZS48L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSBiYWQ6IEkgaGF2ZSB5ZXQgdG8gbWVldCBhbnlib2R5 IG91dHNpZGUgb2YgdGhlIFdHIHRoYXQgcmVhbGx5IHVuZGVyc3RhbmRzIE9BdXRoIDIuMC4mbmJz cDsgSSBtZWFuICZxdW90O3JlYWxseSZxdW90OyB1bmRlcnN0YW5kcyBpdC4gJm5ic3A7KHRvIHRo aXMgZGF5LCBJIHN0aWxsIHRoaW5rIGl0IGlzIG9ubHkgYmVjYXVzZSBvZiB0aGUgZ29vZCBncmFj ZXMgb2Ygb3RoZXJzIGluIHRoaXMgV0cgbGlrZSBKb2huIGFuZCBKdXN0aW4gdGhhdCBJIHVuZGVy c3RhbmQgaXQNCiB3aXRoIHRoZSBkZXB0aCB0aGF0IEkgZG8pLiZuYnNwOyBQZW9wbGUgdGFsayBh Ym91dCBpdCBhdCBoaWdoIGxldmVscywgdGhleSB0YWxrIGFib3V0IHRva2VucywgYnV0IHN0aWxs IGRvbid0IGdldCB3aGF0IGl0IGlzIHRyeWluZyB0byBzb2x2ZSBub3IgaG93IHRvIHNlY3VyZWx5 IGRlcGxveSBpdC4gOTklIG9mIHRoZSBwZW9wbGUgSSBtZWV0IHN0aWxsIGRvbid0IGdldCB0aGUg ZGlmZmVyZW5jZSBiZXR3ZWVuIGF1dGhlbnRpY2F0aW9uIGFuZCBkZWxlZ2F0ZWQNCiBhdXRob3Jp emF0aW9uLiZuYnNwOyBJIGhhdmUgZGVkaWNhdGVkIG1hc3NpdmUgYW1vdW50cyBvZiBjeWNsZXMg dHJ5aW5nIHRvIGVkdWNhdGUgbXkgb3duIGNvbW11bml0eSAoYW5kIGFueWJvZHkgZWxzZSBJIG1l ZXQgZm9yIHRoYXQgbWF0dGVyKS4mbmJzcDsgSSBwZXJzb25hbGx5IGZvdW5kIHRoZSBjb3JlIFJG QyB2ZXJ5IGhhcmQgdG8gZGlnZXN0LCBhbmQgbm93IEkgbmVlZCB0byByZWZlciB0byBOIG1vcmUs IG1hbnkgb2Ygd2hpY2ggc2hvdWxkIGJlIGZvbGRlZA0KIGludG8gYSBuZXcgMi4xIGNvcmUgc3Bl Yy4mbmJzcDsgQWxsIHRoaXMgZ2l2ZW4sIEl0IGlzIG5vIHdvbmRlciB0aGVyZSBhcmUgc28gbWFu eSBpbnNlY3VyZSBpbXBsZW1lbnRhdGlvbnMgb2YgaXQuICZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+U28gaGVyZSdzIHRvIE9BdXRoIDIuMSA6LSk8L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2Pi1hZGFtPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4 dHJhIj48YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gVGh1LCBBcHIgNywgMjAxNiBh dCAxOjU2IFBNLCBIYXJkdCwgRGljayA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFp bHRvOmRpY2tAYW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRpY2tAYW1hem9uLmNvbTwvYT4m Z3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0 eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5n LWxlZnQ6MWV4Ij4NCkkgdGhpbmsgdGhlcmUgYXJlIGFscmVhZHkgeWVhcnMgb2YgaW1wbGVtZW50 YXRpb24gYW5kIGV4cGVyaWVuY2Ugc2luY2UgMi4wPGJyPg0KPGJyPg0KSWYgd2Ugd2FpdCB1bnRp bCBhbGwgdGhlIG91dHN0YW5kaW5nIGlzc3VlcyBhbmQgbmV3IGZlYXR1cmVzIGhhdmUgaGFkIGlt cGxlbWVudGF0aW9ucyBhbmQgZXhwZXJpZW5jZSwgd2Ugd2lsbCBuZXZlciBkbyBhIDIuMSBhcyB0 aGVyZSBjb250aW51ZXMgdG8gYmUgbmV3IHRoaW5ncy48YnI+DQo8YnI+DQpJIHdvdWxkIHN1Z2dl c3QgYSAyLjEgYmUgYSBjbGVhbiwgc2ltcGxlIGRvY3VtZW50IG9mIHRoZSBjb3JlIHNwZWMgaW4g b25lIGRvY3VtZW50IHRoYXQgaW5jbHVkZXMgdGhlIHNlY3VyaXR5IGFuZCBpbXBsZW1lbnRhdGlv biByZWNvbW1lbmRhdGlvbnMuPGJyPg0KPGJyPg0KQWx0ZXJuYXRpdmUgdGl0bGU6IE9BdXRoLCBU aGUgR29vZCBQYXJ0cy4gOik8YnI+DQo8c3Bhbj48Zm9udCBjb2xvcj0iIzg4ODg4OCI+PGJyPg0K 4oCUIERpY2s8YnI+DQo8L2ZvbnQ+PC9zcGFuPg0KPGRpdj4NCjxkaXYgY2xhc3M9Img1Ij4NCjxk aXY+DQo8ZGl2Pjxicj4NCjxicj4NCjxicj4NCjxicj4NCk9uIDQvNy8xNiwgMzoyNSBQTSwgc29t ZW9uZSBjbGFpbWluZyB0byBiZSAmcXVvdDtPQXV0aCBvbiBiZWhhbGYgb2YgTWlrZSBKb25lcyZx dW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxhIGhyZWY9 Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQpZZXMgLSBh biBpbnRlbnRpb25hbGx5IGNvbnNlcnZhdGl2ZSwgaW1wbGVtZW50YXRpb24tIGFuZCBleHBlcmll bmNlLWRyaXZlbiBwYXRoLjxicj4NCjxicj4NClJldmlzaW5nIE9BdXRoIDIuMCBpcyBhICpiaWcg ZGVhbCouJm5ic3A7IFdlIHNob3VsZG4ndCBldmVuIGJlIHRhbGtpbmcgYWJvdXQgaXQgdW50aWwg d2UndmUgY29tcGxldGVkIHN0ZXBzIDEtNSBiZWxvdyAtICppbmNsdWRpbmcqIHRoZSAmcXVvdDtp dGVyYXRlJnF1b3Q7IHN0ZXAsIGFzIG5lY2Vzc2FyeS4mbmJzcDsgSWYgd2UgZ2V0IHRoaXMgd3Jv bmcsIHdlJ2xsIGZyYWdtZW50IE9BdXRoLCB3aGljaCBpcyBhIHRlcnJpYmxlIGFuZCBpcnJlc3Bv bnNpYmxlIG91dGNvbWUgd2Ugc2hvdWxkDQogY29uc2Npb3VzbHkgYXZvaWQgYXQgYWxsIGNvc3Rz Ljxicj4NCjxicj4NCkluIHBhcnRpY3VsYXIsIHdlIHNob3VsZCBub3QgcmVjaGFydGVyIGZvciBh biBPQXV0aCAyLjEgdW50aWwgd2UgYWxyZWFkeSBrbm93IHdoYXQgd2lsbCBiZSBpbiBpdCBhbmQg a25vdyBmcm9tIGRlcGxveW1lbnQgZXhwZXJpZW5jZSB0aGF0IGl0J3MgdGhlIHJpZ2h0IHN0dWZm Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAtLSBNaWtlPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 YnI+DQpGcm9tOiBUb3JzdGVuIExvZGRlcnN0ZWR0IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnRv cnN0ZW5AbG9kZGVyc3RlZHQubmV0IiB0YXJnZXQ9Il9ibGFuayI+dG9yc3RlbkBsb2RkZXJzdGVk dC5uZXQ8L2E+XTxicj4NClNlbnQ6IFRodXJzZGF5LCBBcHJpbCA3LCAyMDE2IDM6MTYgUE08YnI+ DQpUbzogTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9z b2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4m Z3Q7PGJyPg0KQ2M6IFNhbXVlbCBFcmR0bWFuICZsdDs8YSBocmVmPSJtYWlsdG86c2FtdWVsQGVy ZHRtYW4uc2UiIHRhcmdldD0iX2JsYW5rIj5zYW11ZWxAZXJkdG1hbi5zZTwvYT4mZ3Q7OyBBbnRo b255IE5hZGFsaW4gJmx0OzxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20iIHRh cmdldD0iX2JsYW5rIj50b255bmFkQG1pY3Jvc29mdC5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1h aWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPjxi cj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMTxicj4NCjxicj4NCkhpIE1pa2Us PGJyPg0KPGJyPg0KaW4gbXkgb3BpbmlvbiwgeW91IGRlc2NyaWJlZCBhIHBvc3NpYmxlIHBhdGgg dG93YXJkcyAyLjEuIFdvdWxkIHlvdSBhZ3JlZT88YnI+DQo8YnI+DQpiZXN0IHJlZ2FyZHMsPGJy Pg0KVG9yc3Rlbi48YnI+DQo8YnI+DQomZ3Q7IEFtIDA3LjA0LjIwMTYgdW0gMTM6Mzggc2Nocmll YiBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDs6 PGJyPg0KJmd0Ozxicj4NCiZndDsgSSBhbSBzdHJvbmdseSBhZ2FpbnN0IGNyZWF0aW5nIGEgMi4x IHNwZWMgdW50aWwgd2UgaGF2ZSBhdCBsZWFzdCBhIHllYXIgb2YgZGVwbG95bWVudCBleHBlcmll bmNlIHdpdGggdGhlIGNvbnRlbnRzIHdlJ3JlIGFkZGluZyB0byAyLjAsIHNvIGFzIG5vdCB0byBm cmFnbWVudCB0aGUgT0F1dGggbWFya2V0cGxhY2UuPGJyPg0KJmd0Ozxicj4NCiZndDsgSSB0aGlu ayB3ZSBzaG91bGQ6PGJyPg0KJmd0OyAxLiZuYnNwOyBDb250aW51ZSB3b3JraW5nIG9uIG5ldyBz ZWN1cml0eSBtaXRpZ2F0aW9ucyBpbiBuZXcgZHJhZnRzIChzdWNoPGJyPg0KJmd0OyBhcyBtaXgt dXAtbWl0aWdhdGlvbiwgZXRjLikgdGhhdCBhZGQgZmVhdHVyZXMgdG8gdXNlIHdpdGggMi4wIDIu PGJyPg0KJmd0OyBDb250aW51ZSB3b3JraW5nIG9uIFBvUCBzcGVjcyAoc3VjaCBhcyBwb3Ata2V5 LWRpc3RyaWJ1dGlvbiwgZXRjLik8YnI+DQomZ3Q7IHRoYXQgYWRkIGZlYXR1cmVzIHRvIHVzZSB3 aXRoIDIuMCAzLiZuYnNwOyBDb250aW51ZSB3b3JraW5nIG9uIG90aGVyIG5ldzxicj4NCiZndDsg c3BlY3MgKHN1Y2ggYXMgZGlzY292ZXJ5LCByZXNvdXJjZS1pbmRpY2F0b3JzLCBldGMuKSB0aGF0 IGFkZCBmZWF0dXJlczxicj4NCiZndDsgdG8gdXNlIHdpdGggMi4wIDQuJm5ic3A7IExlYXJuIGZy b20gZGVwbG95bWVudCBleHBlcmllbmNlIHdpdGggYWxsIG9mIHRoZW08YnI+DQomZ3Q7IDUuJm5i c3A7IEl0ZXJhdGUgaWYgdGhlIGRlcGxveW1lbnQgZXhwZXJpZW5jZSB0ZWxscyB1cyB0aGF0IHdl IG5lZWQgdG88YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbmx5IGFmdGVyIHdlIGJlbGlldmUgd2UgaGF2 ZSBhbGwgdGhlIGZlYXR1cmVzIHJpZ2h0IGFuZCB3ZSBrbm93IHRoYXQgdGhleSB3b3JrIHRvZ2V0 aGVyIHdlbGwgc2hvdWxkIHdlIGNvbnNpZGVyIGNyZWF0aW5nIGEgMi4xLiZuYnNwOyBJZiB3ZSBy dXNoIHRvIGEgMi4xIGFuZCBnZXQgaXQgd3JvbmcsIHdlJ2xsIGxvc2UgZGV2ZWxvcGVycycgdHJ1 c3QgYW5kIHdlJ2xsIG5ldmVyIGdldCBpdCBiYWNrLjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtLSBNaWtl PGJyPg0KJmd0Ozxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7 IEZyb206IE9BdXRoIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxm IE9mIFNhbXVlbDxicj4NCiZndDsgRXJkdG1hbjxicj4NCiZndDsgU2VudDogVGh1cnNkYXksIEFw cmlsIDcsIDIwMTYgMTI6NDggUE08YnI+DQomZ3Q7IFRvOiBBbnRob255IE5hZGFsaW4gJmx0Ozxh IGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj50b255 bmFkQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozxicj4NCiZndDsgQ2M6IDxhIGhyZWY9Im1haWx0bzpv YXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPjxicj4NCiZn dDsgU3ViamVjdDogUmU6IFtPQVVUSC1XR10gT0F1dGggMi4xPGJyPg0KJmd0Ozxicj4NCiZndDsg JiM0MzsxIG9uIGEgMi4xIHZlcnNpb248YnI+DQomZ3Q7PGJyPg0KJmd0OyAtMSBvbiBkZWZpbmlu ZyBzY29wZXMgbW9yZSBwcmVjaXNlbHkgaW4gMi4xPGJyPg0KJmd0Ozxicj4NCiZndDsgU2VudCBm cm9tIG15IGlQaG9uZTxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyBPbiA3IGFwci4gMjAxNiwgYXQg MTQ6NDYsIEFudGhvbnkgTmFkYWxpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbnluYWRAbWljcm9z b2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRvbnluYWRAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdy b3RlOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSSBkb24ndCBiZWxpdmUgdGhhdCBzY29w ZXMgc2hvdWxkIGJlIGRlZmluZWQgbW9yZSBwcmVjaXNlbHkgYXMgdGhpcyBvcGFxdWVuZXNzIHdh cyBhIGRlc2lnbiBmZWF0dXJlLCBJJ20gbm90IHNlZWluZyB0aGUgcmVhc29uIHdoeSBzY29wZXMg bmVlZCB0byBiZSBkZWZpbmVkLCBhcyB0aGVzZSBhcmUgYXBwbGljYXRpb24gc3BlY2lmaWMuPGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4N CiZndDsmZ3Q7IEZyb206IE9BdXRoIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPl0g T24gQmVoYWxmIE9mIFRvcnN0ZW48YnI+DQomZ3Q7Jmd0OyBMb2RkZXJzdGVkdDxicj4NCiZndDsm Z3Q7IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCA3LCAyMDE2IDU6MzIgQU08YnI+DQomZ3Q7Jmd0OyBU bzogR2VvcmdlIEZsZXRjaGVyICZsdDs8YSBocmVmPSJtYWlsdG86Z2ZmbGV0Y2hAYW9sLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmdmZmxldGNoQGFvbC5jb208L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7IENj OiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBp ZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCAy LjE8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEhpIGFsbCw8YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7IGFzIEkgYWxyZWFkeSBzYWlkIGluIHRoZSBtZWV0aW5nOiBJIHdvdWxkIHZlcnkg bXVjaCBwcmVmZXIgdG8gaGF2ZSBhbiBleHRlbnNpb24vdXBkYXRlIG9mIFJGQyA2ODE5IGNvdmVy aW5nIGFsbCAmcXVvdDtuZXcmcXVvdDsgdGhyZWF0cywgaW5jbHVkaW5nOjxicj4NCiZndDsmZ3Q7 IC0gbWl4IHVwPGJyPg0KJmd0OyZndDsgLSBjb2RlIGluamVjdGlvbiBha2EgY29weSBhbmQgcGFz dGU8YnI+DQomZ3Q7Jmd0OyAtIG9wZW4gcmVkaXJlY3RvciBhdCBBUyBhbmQgY2xpZW50PGJyPg0K Jmd0OyZndDsgLSBwb3RlbnRpYWwgb3RoZXIgdGhyZWF0cyBpbiB0aGUgY29udGV4dCBvZiAmcXVv dDtkeW5hbWljJnF1b3Q7IE9BdXRoPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJIGFsc28g YXNzdW1lIG1pdGlnYXRpb25zIGZvciAoYXQgbGVhc3Qgc29tZSBvZikgdGhlIHRocmVhdHMgbmVl ZCB0byBnbyBpbnRvIGFuIHVwZGF0ZSBvZiBSRkMgNjc0OSBhcyBub3JtYXRpdmUgdGV4dC4gVG8g Z2l2ZSBhbiBleGFtcGxlOiBpZiB3ZSBhZ3JlZSBvbiB1c2luZyB0aGUgc3RhdGUgcGFyYW1ldGVy IGF0IHRoZSB0b2tlbiBlbmRwb2ludCB0byBtaXRpZ2F0ZSBjb2RlIGluamVjdGlvbiwgdGhpcyBN VVNUIGJlIHBhcnQgb2YgdGhlDQogY29yZSBzcGVjIChyZXF1ZXN0IGRlc2NyaXB0aW9uIGFuZCBz ZWN1cml0eSBjb25zb2RlcmF0aW9ucykuIE90aGVyd2lzZSwgbm9vbmUgd2lsbCBldmVuJm5ic3A7 IGNvbnNpZGVyIGl0Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgV2Ugc2hvdWxkIGFsc28g dXNlIHRoZSBvcHBvcnR1bml0eSB0byBpbXByb3ZlL2VuaGFuY2UgdGhlIHRleHQgb2YgdGhlIHNw ZWMuIEluIHRoZSBjb3Vyc2Ugb2YgdGhlIGxhc3QgeWVhcnMsIHdlIGhhdmUgbGVhcm5lZCBhIGxv dCBhYm91dCBhbWJpcXVpdGllcyBvZiB0aGUgdGV4dCBhbmQgaG93IGRpZmZlcmVudCBpbXBsZW1l bnRhdGlvbnMgdXRpbGl6ZSBPQXV0aC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEkgdGhp bmsgdGltZSBpcyByaWdodCB0byBkZWZpbmUgc2NvcGVzIG1vcmUgcHJlY2lzZWx5LiBBcyB0aGUg ZGlzY3Vzc2lvbnMgaW4gdGhlIGxhc3QgZGF5cyBwcm92ZWQgYWdhaW4gKGF0IGxlYXN0IGZvciBt ZSksIHNjb3BlIGlzIG5vdCBzdWZmaWNpZW50bHkgZGVmaW5lZCB0byBjb21lIHVwIHdpdGggaW50 ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbnMuIEFkZGl0aW9uYWxseSwgdGhlcmUgc2VlbXMgdG8g YmUgYSBuZWVkIHRvIHJlcHJlc2VudA0KIHJlc291cmNlIHNlcnZlciBsb2NhdGlvbnMgKHRvIG5v dCBzYXkgaWRlbnRpdGllcyA6LSkpIGluIHRoaXMgY29udGV4dC48YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7IFRvIGJ1bmRsZSBhbGwgY2hhbmdlcyBpbiBhIHZlcnNpb24gMi4xIHdvdWxkIGFs c28gbWFrZSBjb21tdW5pY2F0aW9uIGludG8gdGhlIG1hcmtldCBtdWNoIGVhc2llci48YnI+DQom Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IGJlc3QgcmVnYXJkcyw8YnI+DQomZ3Q7Jmd0OyBUb3JzdGVu Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEFtIDA2LjA0LjIwMTYgdW0gMTY6MDUg c2NocmllYiBHZW9yZ2UgRmxldGNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpnZmZsZXRjaEBhb2wu Y29tIiB0YXJnZXQ9Il9ibGFuayI+Z2ZmbGV0Y2hAYW9sLmNvbTwvYT4mZ3Q7Ojxicj4NCiZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBJJ2QgZGVmaW5pdGVseSBwcmVmZXIgYSBzaW5nbGUg c29sdXRpb24gZG9jdW1lbnQgdG8gbWFueSBsaXR0bGUgb25lcyB0aGF0IGhhdmUgdG8gYmUgY29t YmluZWQgdG8gYWN0dWFsbHkgYnVpbGQgYSBzZWN1cmUgc29sdXRpb24uIEl0J3MgYWxyZWFkeSBn ZXR0aW5nIGNvbXBsZXggd2l0aCB0aGUgYWRkaXRpb25hbCBzcGVjcyB0aGF0IGhhdmUgYmVlbiBh ZGRlZC48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgQWRkaXRpb25hbGx5LCBJ J20gbm90IGFnYWluc3Qgd29ya2luZyBvbiBPQXV0aCAyLjEuPGJyPg0KJmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7Jmd0OyZndDsgR2VvcmdlPGJyPg0KJmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBPbiA0LzYvMTYgMjowNiBQTSwgUGhpbCBI dW50IChJRE0pIHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7IEV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBhcmUgZm9yIHRoZSBsYXJnZSBwYXJ0IG9rIGFu ZCBkbyBub3QgbmVlZCB0aGVzZSBtaXRpZ2F0aW9ucy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyBPbmx5IHRoZSBuZXcgdXNlIGNhc2VzIHdlIGhhdmUgYmVlbiBk aXNjdXNzaW5nIChjb25maWd1cmUgb24gdGhlIGZseSBhbmQgbXVsdGktYXMsIGV0YykgcmVhbGx5 IG5lZWQgbWl0aWdhdGlvbi48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyBUaGUgdXBkYXRlZCBieSBhcHByb2FjaCBzZWVtcyBsaWtlIGEgZ29vZCB3YXkgdG8gYWRk cmVzcyB0aGUgbmV3IGNhc2VzLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7IFBoaWw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgT24gQXByIDYsIDIwMTYsIGF0IDE0OjM1LCBIYW5uZXMgVHNjaG9mZW5pZyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQiIHRhcmdldD0iX2JsYW5rIj5oYW5u ZXMudHNjaG9mZW5pZ0BnbXgubmV0PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIaSBhbGwsPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0b2RheSB3ZSBkaXNjdXNzZWQgdGhl IE9BdXRoIEF1dGhvcml6YXRpb24gU2VydmVyIE1peHVwIGRyYWZ0LiBXZTxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IHdlcmUgd29uZGVyaW5nIHdoYXQgdHlwZXMgb2YgdGhyZWF0cyB0aGUgZG9j dW1lbnQgc2hvdWxkIGZpbmQgc29sdXRpb25zIGZvci48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFdlIGRpc2N1c3NlZCB2YXJpb3VzIGRvY3VtZW50 IGhhbmRsaW5nIGFwcHJvYWNoZXMgaW5jbHVkaW5nPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsg KiBPQXV0aCBNaXgtVXAgYW5kIEN1dC1hbmQtUGFzdGUgYXR0YWNrcyBkb2N1bWVudGVkIGluIHNl cGFyYXRlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgc29sdXRpb24gZG9jdW1lbnRzPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKiBjb21iaW5lZCBzb2x1dGlvbiBkb2N1bWVudCBjb3Zlcmlu ZyB0aGUgT0F1dGggTWl4LVVwIGFuZCB0aGU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBDdXQt YW5kLVBhc3RlIGF0dGFja3MuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBCYXJyeSBwb2ludGVkIG91dCB0aGF0IHRoZXNlIGRvY3VtZW50cyBjb3Vs ZCB1cGRhdGUgdGhlIE9BdXRoIGJhc2U8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzcGVjaWZp Y2F0aW9uLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgQXMgYSBtb3JlIHJhZGljYWwgY2hhbmdlIGl0IHdhcyBhbHNvIHN1Z2dlc3RlZCB0byByZXZp c2UgUkZDIDY3NDk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmcXVvdDtPQXV0aDxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IDIuMCBBdXRob3JpemF0aW9uIEZyYW1ld29yayZxdW90OyBhbmQg UkZDIDY4MTkgJnF1b3Q7T0F1dGggMi4wIFRocmVhdCBNb2RlbDxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IGFuZCBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyZxdW90Oy48YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9wZW5pbmcgdXAgdGhlIE9BdXRo IGJhc2Ugc3BlY2lmaWNhdGlvbiBvYnZpb3VzbHkgcmFpc2VzIHZhcmlvdXM8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBvdGhlciBxdWVzdGlvbnMgYWJvdXQgY2xlYW5pbmcgdXAgcGFydHMgdGhh dCBnbyBmYXIgYmV5b25kIHRoZSBBUzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1peC11cCBh bmQgdGhlIGN1dC1hbmQtcGFzdGUgYXR0YWNrcy4gT3RoZXIgc3BlY2lmaWNhdGlvbnMsIHN1Y2g8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhcyB0aGUgT3BlbiBSZWRpcmVjdG9yLCBjb3VsZCBi ZSBmb2xkZWQgaW50byBzdWNoIGEgbmV3IHNwZWNpZmljYXRpb24uPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBEZXJlayBhbmQgSSB3b3VsZCBhcHBy ZWNpYXRlIHlvdXIgaW5wdXQgb24gdGhpcyB0b3BpYyBiZWZvcmUgd2U8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBtYWtlIGEgZGVjaXNpb24gc2luY2UgaXQgaGFzIHNpZ25pZmljYW50IGltcGFj dCBvbiBvdXIgd29yay48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IENpYW88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIYW5uZXMgJmFtcDsgRGVy ZWs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5nIGxp c3Q8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v ay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnciIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxh bmsiPg0KaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9 aHR0cHMlM2ElMmYlMmZ3PC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHc8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyB3PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgLjxhIGhyZWY9Imh0 dHA6Ly9pZXRmLm9yZyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aWV0Zi5vcmc8 L2E+JTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmYW1wO2RhdGE9MDElN2MwMSU3Y3Rvbnlu YWQlNDBtaTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyByPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cDovL29zb2Z0LmNv bSIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+b3NvZnQuY29tPC9hPiU3Y2NlOGM5 NDJiZWQ4MTQzN2FjYTA0MDhkMzVlZTBiZTIxJTdjNzJmOTg4YmY4NmYxNDFhZjkxYTxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGI8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAyPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1CcWNFOWVEaG04cGdk b2l0clBGdWZvdXhTNnFZbmRua0xnTGE1U1BrMkhJJTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IDM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVm PSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwv YT48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3IiByZWw9Im5vcmVm ZXJyZXIiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlv bi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3PC9hPi48YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly9pZXRmLm9yZyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9 Il9ibGFuayI+aWV0Zi5vcmc8L2E+JTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmYW1wO2Rh dGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBvPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyBzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwOi8v b2Z0LmNvbSIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+b2Z0LmNvbTwvYT4lN2Nj ZThjOTQyYmVkODE0MzdhY2EwNDA4ZDM1ZWUwYmUyMSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDcgYzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgZDAxMWRiNDcl N2MxJmFtcDtzZGF0YT1CcWNFOWVEaG04cGdkb2l0clBGdWZvdXhTNnFZbmRua0xnTGE1U1BrMkhJ JTNkPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsmZ3Q7IE9BdXRoIG1h aWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsg PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91 cmw9aHR0cHMlM2ElMmYlMmZ3d3ciIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPg0K aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M2ElMmYlMmZ3d3c8L2E+Ljxicj4NCiZndDsmZ3Q7Jmd0OyBpPGJyPg0KJmd0OyZndDsmZ3Q7IDxh IGhyZWY9Imh0dHA6Ly9ldGYub3JnIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5l dGYub3JnPC9hPiUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmFtcDtkYXRhPTAxJTdjMDEl N2N0b255bmFkJTQwbWljcm9zPGJyPg0KJmd0OyZndDsmZ3Q7IG88YnI+DQomZ3Q7Jmd0OyZndDsg Zjxicj4NCiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwOi8vdC5jb20iIHJlbD0ibm9yZWZlcnJl ciIgdGFyZ2V0PSJfYmxhbmsiPnQuY29tPC9hPiU3Y2NlOGM5NDJiZWQ4MTQzN2FjYTA0MDhkMzVl ZTBiZTIxJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDxicj4NCiZndDsmZ3Q7Jmd0OyAwPGJy Pg0KJmd0OyZndDsmZ3Q7IDEgMWRiNDclN2MxJmFtcDtzZGF0YT1CcWNFOWVEaG04cGdkb2l0clBG dWZvdXhTNnFZbmRua0xnTGE1U1BrMkhJJTNkPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsm Z3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0 aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsm Z3Q7IDxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3IiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5r Ij4NCmh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0 dHBzJTNhJTJmJTJmd3d3PC9hPi48YnI+DQomZ3Q7Jmd0OyBpPGJyPg0KJmd0OyZndDsgPGEgaHJl Zj0iaHR0cDovL2V0Zi5vcmciIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmV0Zi5v cmc8L2E+JTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmYW1wO2RhdGE9MDElN2MwMSU3Y3Rv bnluYWQlNDBtaWNyb3NvPGJyPg0KJmd0OyZndDsgZjxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0 dHA6Ly90LmNvbSIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+dC5jb208L2E+JTdj Y2U4Yzk0MmJlZDgxNDM3YWNhMDQwOGQzNWVlMGJlMjElN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk N2NkMDxicj4NCiZndDsmZ3Q7IDEgMWRiNDclN2MxJmFtcDtzZGF0YT1CcWNFOWVEaG04cGdkb2l0 clBGdWZvdXhTNnFZbmRua0xnTGE1U1BrMkhJJTNkPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZn dDsmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpP QXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCiZn dDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGgiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgT0F1dGgg bWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHJlbD0ibm9yZWZlcnJlciIg dGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aDwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0 OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBp ZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGgiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQo8YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRo IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJy Pg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiByZWw9Im5vcmVmZXJyZXIi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoPC9hPjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiByZWw9Im5vcmVm ZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoPC9hPjxicj4NCjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_3C1AEFC91DF34FCB8AC54459991DE27Aamazoncom_-- From nobody Thu Apr 7 16:11:52 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF4512D546 for ; Thu, 7 Apr 2016 16:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SO1vMGXtaGhO for ; Thu, 7 Apr 2016 16:11:49 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB47F12D12E for ; Thu, 7 Apr 2016 16:11:48 -0700 (PDT) X-AuditID: 1209190e-823ff700000035f6-55-5706e9338edb Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 13.CA.13814.339E6075; Thu, 7 Apr 2016 19:11:47 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u37NBlcT029980; Thu, 7 Apr 2016 19:11:47 -0400 Received: from [10.40.6.58] ([63.88.116.178]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u37NBiJe019875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Apr 2016 19:11:46 -0400 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_27D5A0CB-67F6-487D-8453-79393C672D9B"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Justin Richer In-Reply-To: <570546A1.8040509@gmx.net> Date: Thu, 7 Apr 2016 19:11:43 -0400 Message-Id: <5AEB6A4A-A325-4069-930F-D034D81E41E5@mit.edu> References: <570546A1.8040509@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3112) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMKsWRmVeSWpSXmKPExsUixG6nomv8ki3c4PMNQ4ulO++xWpx8+4rN gclj8ab9bB5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4tU6oYBJ/xdald5kaGLt4uxg5OSQETCQu fZ7M3MXIxSEk0MYksXL7JzYIZwOjxLRLHSwQzkomifdP9rKAtAgL+Ei8u7eaDcTmFdCTOLFq NyuIzSwwhVFi93EuiLFSEi0/rjOB2GwCqhLT17SA2ZwC6hILJ69mB7FZBFQk2q/vB5rDAdSr LtF+0gVipJXE3O4OsJFCAmoSd74fZwaxRQQMJa7PnM4KMV5WYt+GBWwTGAVmIbliFpIrIGxt iWULXzND2JoS+7uXs0DY8hLb386BiltKLJ55AypuK3GrbwEThG0n8WjaItYFjByrGGVTcqt0 cxMzc4pTk3WLkxPz8lKLdI31cjNL9FJTSjcxguKDU5JvB+OkBu9DjAIcjEo8vBadrOFCrIll xZW5hxglOZiURHlldrKFC/El5adUZiQWZ8QXleakFh9iVAHa9WjD6guMUix5+XmpSiK85x4D 1fGmJFZWpRblw5RJc7AoifMyMjAwCAmkJ5akZqemFqQWwWRlODiUJHhdXgA1ChalpqdWpGXm lCCkmTg4DzFKcPAADTcBqeEtLkjMLc5Mh8ifYlSUEue1BUkIgCQySvPgekFpzT6iZNMrRnGg t4R5rzwHquIBpkS47ldAg5mABl/gBxtckoiQkmpg3BM2cZ73yz+8Z3MnVWYVfPgYMzU848af GTrVghrL7O/YJnQX6HQufvd2i0jk9XCJ9WvkP6ZP+V5QpKCdfnDl7WTTg6dfNoXwizjdWhnz zv3MxiOhNTGfwrVX6V5kvXFah9O8hy9287SSs/0WcxnSihP83TnXWpk0CH2VnZax839Mxp6k jpNRSizFGYmGWsxFxYkAvyZFc0YDAAA= Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 23:11:51 -0000 --Apple-Mail=_27D5A0CB-67F6-487D-8453-79393C672D9B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I support adoption of this document as a starting point for working = group work. =E2=80=94 Justin > On Apr 6, 2016, at 1:25 PM, Hannes Tschofenig = wrote: >=20 > Hi all, >=20 > this is the call for adoption of 'Resource Indicators for OAuth 2.0', = see > = http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/ >=20 > Please let us know by April 20th 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 Buenos > Aires then you don't need to re-state your opinion, if you want. >=20 > The feedback at the BA IETF meeting was the following: ~10 persons > for accepting the document and 0 persons against. >=20 > Ciao > Hannes & Derek >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_27D5A0CB-67F6-487D-8453-79393C672D9B 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----- iQEcBAEBCAAGBQJXBukvAAoJEDPAngkbd+w9qHgH/3arULclpnr6SLr10mHVMCxO sxKlh9bfzrYex3VRV7CARVF5MEqzDM5BWqzulB4g37q0NvYUcni8thWwzr9T1OZZ m4wVI2iSCVsPtykT1KJEMJeQ4IRUVMhaIo3N3IdwlZKt1nkvBGh8Cbizeezqsth3 +S0Gy+KWT/NO4vnnwXhFKISqYQh8ZZbXDaTRBWWyNeliB0jqNj3FXKAryiNw1fHm 5Cg2933l6pf7oCdy5e/nRisxY/N/A9dCx9NiEKeY5oGL9XZuOlN85xUcEUSFzjxU mF0CIoaJwh6qRz4eYwCK5/TVtHAEsM7Vw8V63/nKE44XSeZKk0yS7fgfzA3io0c= =Lcz0 -----END PGP SIGNATURE----- --Apple-Mail=_27D5A0CB-67F6-487D-8453-79393C672D9B-- From nobody Thu Apr 7 16:15:57 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B017E12D546; Thu, 7 Apr 2016 16:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.241 X-Spam-Level: X-Spam-Status: No, score=-2.241 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-PdnNk0W8nk; Thu, 7 Apr 2016 16:15:52 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E43312D1ED; Thu, 7 Apr 2016 16:15:51 -0700 (PDT) X-AuditID: 1209190e-823ff700000035f6-da-5706ea264e1a Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id D8.EA.13814.62AE6075; Thu, 7 Apr 2016 19:15:50 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u37NFnBD030330; Thu, 7 Apr 2016 19:15:50 -0400 Received: from [10.40.6.58] ([63.88.116.178]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u37NFjTt020940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Apr 2016 19:15:46 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_1545E06C-937A-43D7-B52F-A0FCC49D4C76" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Justin Richer In-Reply-To: Date: Thu, 7 Apr 2016 19:15:44 -0400 Message-Id: References: To: Brian Campbell X-Mailer: Apple Mail (2.3112) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOKsWRmVeSWpSXmKPExsUixG6noqv2ii3c4Nc6RYvV/28yWpx8+4rN YtHpjcwWm+ZuY3Rg8Viy5CeTR+uOv+wed49eZAlgjuKySUnNySxLLdK3S+DKWHX1JGvBolOM FTtnLmdvYDyxibGLkZNDQsBE4vPBz6xdjFwcQgJtTBLTTq1khnA2MErsmnGWCcJZySTRsWM7 M0gLs0CCROP3P2wgNq+AnsSJVbtZQWxhAR+JOzfbwWw2AVWJ6WtamEBsToFAiacfprGD2CwC KhL7505ihZhTJfHm8n2oOVYSi/evZoRYtpRRYun/H2ANIgL6ErefzmGHuFVWYt+GBWwTGPln IbljFpI7IOLaEssWvmaGsDUl9ncvZ8EU15Do/DaRdQEj2ypG2ZTcKt3cxMyc4tRk3eLkxLy8 1CJdY73czBK91JTSTYyg8OeU5NvBOKnB+xCjAAejEg+vRSdruBBrYllxZe4hRkkOJiVRXpmd bOFCfEn5KZUZicUZ8UWlOanFhxglOJiVRHhbXgDleFMSK6tSi/JhUtIcLErivIwMDAxCAumJ JanZqakFqUUwWRkODiUJXuOXQI2CRanpqRVpmTklCGkmDk6Q4TxAw1VAaniLCxJzizPTIfKn GBWlxHk3gWwVAElklObB9YLSk31EyaZXjOJArwjz1oK08wBTG1z3K6DBTECDL/CDDS5JREhJ NTAmTuPmaHneIHTBzEh1q7Mt68SGdDb7gLYHE3KVD5+Ieb6iQJSBby+PFFfcN/7aGJbAoLPL goRfq7x99H1marF8aY3dv/0zY1X7pk5g3LXz03q1PZNO3Pm2R/3Nh1Ml6anHT4eFNU0u6j3p 63+81Ly8M25/4xkbqaKn4la6d5yr1JWMFkksjFNiKc5INNRiLipOBABF1F3VKgMAAA== Archived-At: Cc: "" , "scim@ietf.org" Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment server to server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 23:15:54 -0000 --Apple-Mail=_1545E06C-937A-43D7-B52F-A0FCC49D4C76 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1, this seems a better fit for openid. =E2=80=94 Justin > On Apr 6, 2016, at 9:05 AM, Brian Campbell = wrote: >=20 > OpenID ... ?=20 >=20 > On Wed, Apr 6, 2016 at 9:59 AM, Anthony Nadalin > wrote: > Good question, since SCIM does not really provide an authorization = model and Oauth does not do provisioning this is sort of caught in the = middle, so if I had to pick I would pick Oauth as this is a generic = server to server issue >=20 > =C2=A0 <> > From: Hardt, Dick [mailto:dick@amazon.com ]=20 > Sent: Wednesday, April 6, 2016 5:52 AM > To: Anthony Nadalin > > Cc: Gil Kirkpatrick >; Nat Sakimura >; Phil Hunt (IDM) >; scim@ietf.org ; = oauth@ietf.org > Subject: Re: [scim] [OAUTH-WG] Simple Federation Deployment >=20 > =20 >=20 > Sounds like there is interest. >=20 > =20 >=20 > SCIM or OAUTH? >=20 > -- Dick >=20 >=20 > On Apr 6, 2016, at 8:57 AM, Anthony Nadalin > wrote: >=20 > I would be interested also >=20 > =20 >=20 > Sent from my Windows 10 phone >=20 > =20 >=20 > From: Gil Kirkpatrick > Sent: Wednesday, April 6, 2016 4:16 AM > To: 'Nat Sakimura' ; 'Hardt, Dick' = ; 'Phil Hunt (IDM)' = > Cc: scim@ietf.org ; oauth@ietf.org = > Subject: Re: [scim] [OAUTH-WG] Simple Federation Deployment >=20 > =20 >=20 > That=E2=80=99s an issue we=E2=80=99re facing as well. Definitely = interested. >=20 > =20 >=20 > -gil >=20 > =20 >=20 > From: OAuth [mailto:oauth-bounces@ietf.org = ] On Behalf Of Nat Sakimura > Sent: Wednesday, April 6, 2016 4:57 PM > To: 'Hardt, Dick' >; 'Phil = Hunt (IDM)' > > Cc: scim@ietf.org ; oauth@ietf.org = > Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment >=20 > =20 >=20 > +1 for removing the manual cut-n-pastes! >=20 > =20 >=20 > Nat >=20 > =20 >=20 > -- >=20 > PLEASE READ :This e-mail is confidential and intended for the >=20 > named recipient only. If you are not an intended recipient, >=20 > please notify the sender and delete this e-mail. >=20 > =20 >=20 > From: scim [mailto:scim-bounces@ietf.org = ] On Behalf Of Hardt, Dick > Sent: Wednesday, April 6, 2016 7:26 AM > To: Phil Hunt (IDM) > > Cc: scim@ietf.org ; oauth@ietf.org = > Subject: Re: [scim] Simple Federation Deployment >=20 > =20 >=20 > I=E2=80=99m talking about removing manual steps in what happens today = where configuring a SaaS app at an IdP (such as Google, Azure, Ping, = Octa) requires is a bunch of cutting and pasting of access tokens / keys = / certs and doing a bunch of config that is error prone and unique for = each relationship. >=20 > =20 >=20 > Don=E2=80=99t want to solve on the thread =E2=80=A6 looking to see if = there is interest! >=20 > =20 >=20 > On 4/5/16, 7:11 PM, someone claiming to be "scim on behalf of Phil = Hunt (IDM)" on = behalf of phil.hunt@oracle.com > wrote: >=20 > =20 >=20 > Is the idp the center of all things for these users? >=20 > =20 >=20 > Usually you have a provisioning system that coordinates state and uses = things like scim connectors to do this.=20 >=20 > =20 >=20 > Another approach from today would be to pass a scim event to the = remote provider which then decides what needs to be done to facilitate = the thingd you describe.=20 >=20 > =20 >=20 > Iow. Either the idp (sender) or the sp (receiver) have a provisioning = system to do this.=20 >=20 > =20 >=20 > The solution and the simplicity depends on where the control needs to = be.=20 >=20 > Phil >=20 >=20 > On Apr 5, 2016, at 18:59, Hardt, Dick > wrote: >=20 > Use case: An admin for an organization would like to enable her users = to access a SaaS application at her IdP.=20 >=20 > =20 >=20 > User experience:=20 >=20 > Admin authenticates to IdP in browser > Admin selects SaaS app to federate with from list at IdP > IdP optionally presents config options > IdP redirects Admin to SaaS app > Admin authenticates to SaaS app > SaaS app optionally gathers config options > SaaS app redirects admin to IdP > IdP confirms successful federation =3D> OIDC / SAML and SCIM are now = configured and working between IdP and SaaS App > Who else is interested in solving this? >=20 > =20 >=20 > Is there interest in working on this in either SCIM or OAUTH Wgs? >=20 > =20 >=20 > Any one in BA interested in meeting on this topic this week? >=20 > =20 >=20 > =E2=80=94 Dick >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim = > _______________________________________________ > 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=_1545E06C-937A-43D7-B52F-A0FCC49D4C76 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1, this seems a better fit for openid.

 =E2=80=94 Justin

On Apr 6, 2016, at 9:05 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

OpenID ... ?

On Wed, Apr 6, 2016 at 9:59 AM, Anthony Nadalin = <tonynad@microsoft.com> = wrote:

Good question, since SCIM does = not really provide an authorization model and Oauth does not do = provisioning this is sort of caught in the middle, so if I had to pick I = would pick Oauth as this is a generic server to server issue

 

From: = Hardt, Dick [mailto:dick@amazon.com]
Sent: Wednesday, April 6, 2016 5:52 AM
To: Anthony Nadalin <tonynad@microsoft.com>
Cc: Gil Kirkpatrick <gil.kirkpatrick@viewds.com>; Nat Sakimura <n-sakimura@nri.co.jp>; Phil Hunt (IDM) <phil.hunt@oracle.com>; scim@ietf.org; oauth@ietf.org
Subject: Re: [scim] [OAUTH-WG] Simple Federation = Deployment

 

Sounds like there is = interest.

 

SCIM or OAUTH?

-- Dick


On Apr 6, 2016, at 8:57 AM, Anthony Nadalin <tonynad@microsoft.com> wrote:

I would be interested also

 

Sent from my = Windows 10 phone

 

From: = Gil Kirkpatrick
Sent: Wednesday, April 6, 2016 4:16 AM
To: 'Nat Sakimura'; 'Hardt, Dick'; 'Phil Hunt (IDM)'
Cc: scim@ietf.org; oauth@ietf.org
Subject: Re: [scim] [OAUTH-WG] Simple Federation = Deployment

 

That=E2=80=99s an issue we=E2=80=99re facing as well. = Definitely interested.

 

-gil

 

From: = OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura
Sent: Wednesday, April 6, 2016 4:57 PM
To: 'Hardt, Dick' <dick@amazon.com>; 'Phil Hunt (IDM)' = <phil.hunt@oracle.com>
Cc: scim@ietf.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] [scim] Simple Federation = Deployment

 

+1 for removing the manual cut-n-pastes!

 

Nat

 

--

PLEASE READ :This e-mail is = confidential and intended for the

named recipient only. If you are = not an intended recipient,

please notify the sender  = and delete this e-mail.

 

From: = scim [mailto:scim-bounces@ietf.org] On Behalf Of Hardt, Dick
Sent: Wednesday, April 6, 2016 7:26 AM
To: Phil Hunt (IDM) <phil.hunt@oracle.com>
Cc: scim@ietf.org; oauth@ietf.org
Subject: Re: [scim] Simple Federation Deployment

 

I=E2=80=99m talking about removing manual steps in = what happens today where configuring a SaaS app at an IdP (such as = Google, Azure, Ping, Octa) requires is a bunch of cutting and pasting of = access tokens / keys / certs and doing a bunch of  config that is error prone = and unique for each relationship.

 

Don=E2=80=99t want to solve on the thread =E2=80=A6 = looking to see if there is interest!

 

On 4/5/16, 7:11 PM, someone claiming to be "scim on = behalf of Phil Hunt (IDM)" <scim-bounces@ietf.org on behalf of phil.hunt@oracle.com> wrote:

 

Is the idp the center of all things for these = users?

 

Usually you have a provisioning system that = coordinates state and uses things like scim connectors to do = this. 

 

Another approach from today would be to pass a scim = event to the remote provider which then decides what needs to be done to = facilitate the thingd you describe. 

 

Iow. Either the idp (sender) or the sp (receiver) = have a provisioning system to do this. 

 

The solution and the simplicity depends on where the = control needs to be. 

Phil


On Apr 5, 2016, at 18:59, Hardt, Dick <dick@amazon.com> wrote:

Use case: An admin for an organization would like to = enable her users to access a SaaS application at her IdP. 

 

User experience: 

  1. Admin authenticates to IdP in browser
  2. Admin selects = SaaS app to federate with from list at IdP
  3. IdP optionally presents config = options
  4. IdP redirects Admin to SaaS app
  5. Admin authenticates to SaaS = app
  6. SaaS app = optionally gathers config options
  7. SaaS app redirects admin to = IdP
  8. IdP confirms = successful federation =3D> OIDC / SAML and SCIM are now configured = and working between IdP and SaaS App

Who else is interested in solving this?

 

Is there interest in working on this in either SCIM = or OAUTH Wgs?

 

Any one in BA interested in meeting on this topic = this week?

 

=E2=80=94 Dick

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


_______________________________________________
OAuth mailing 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=_1545E06C-937A-43D7-B52F-A0FCC49D4C76-- From nobody Thu Apr 7 16:19:30 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B444112D6F1; Thu, 7 Apr 2016 16:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.541 X-Spam-Level: X-Spam-Status: No, score=-12.541 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOgtbsUhaxyS; Thu, 7 Apr 2016 16:19:24 -0700 (PDT) Received: from smtp-fw-9102.amazon.com (smtp-fw-9102.amazon.com [207.171.184.29]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C312F12D1ED; Thu, 7 Apr 2016 16:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1460071163; x=1491607163; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DCBou+grGxLoCDAE3EDHVqEWFpht4M5ClZ8JrFGoqKA=; b=JVR1XUTCrjET/CpxU7393vX3gljw05SJVfpqBhn3Nf2mL3zSBi4rnKBE /s4apUv/x3/S7BmAmhmDOBXb/GNhYM9iijVbg8+nq+PFAzFw5uiVlt0nB dxr9p2eklkXZ7tfaD8dKO1Bz9WQ65ZQy/X41sNMDpRNqG8l+wK5VeV4z+ Y=; X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208,217";a="417069202" Received: from sea19-co-svc-lb5-vlan2.sea.amazon.com (HELO email-inbound-relay-71008.iad55.amazon.com) ([10.47.22.162]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Apr 2016 23:19:22 +0000 Received: from ex10-hub-7002.ant.amazon.com (iad1-ws-svc-lb91-vlan2.amazon.com [10.0.103.146]) by email-inbound-relay-71008.iad55.amazon.com (8.14.7/8.14.7) with ESMTP id u37NJGiM014277 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Apr 2016 23:19:20 GMT Received: from EX13D03UWA001.ant.amazon.com (10.43.160.141) by ex10-hub-7002.ant.amazon.com (10.43.110.153) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 7 Apr 2016 16:19:07 -0700 Received: from EX13D03UWA001.ant.amazon.com (10.43.160.141) by EX13D03UWA001.ant.amazon.com (10.43.160.141) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 7 Apr 2016 23:19:06 +0000 Received: from EX13D03UWA001.ant.amazon.com ([10.43.160.141]) by EX13D03UWA001.ant.amazon.com ([10.43.160.141]) with mapi id 15.00.1104.000; Thu, 7 Apr 2016 23:19:06 +0000 From: "Hardt, Dick" To: Justin Richer Thread-Topic: [OAUTH-WG] [scim] Simple Federation Deployment server to server Thread-Index: AQHRkAUV47DkspjcTE29bhDf8xdvHp9/JscAgAAA8H0= Date: Thu, 7 Apr 2016 23:19:05 +0000 Message-ID: References: , 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_C75E2AC872B34D46A78EBEBA27400EF3amazoncom_" MIME-Version: 1.0 Archived-At: Cc: "scim@ietf.org" , "" Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment server to server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 23:19:26 -0000 --_000_C75E2AC872B34D46A78EBEBA27400EF3amazoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I'm writing an ID to submit in the OAuth WG -- Dick On Apr 7, 2016, at 8:16 PM, Justin Richer > wrote: +1, this seems a better fit for openid. =97 Justin On Apr 6, 2016, at 9:05 AM, Brian Campbell > wrote: OpenID ... ? On Wed, Apr 6, 2016 at 9:59 AM, Anthony Nadalin > wrote: Good question, since SCIM does not really provide an authorization model an= d Oauth does not do provisioning this is sort of caught in the middle, so i= f I had to pick I would pick Oauth as this is a generic server to server is= sue From: Hardt, Dick [mailto:dick@amazon.com] Sent: Wednesday, April 6, 2016 5:52 AM To: Anthony Nadalin > Cc: Gil Kirkpatrick >; Nat Sakimura >;= Phil Hunt (IDM) >; scim@= ietf.org; oauth@ietf.org Subject: Re: [scim] [OAUTH-WG] Simple Federation Deployment Sounds like there is interest. SCIM or OAUTH? -- Dick On Apr 6, 2016, at 8:57 AM, Anthony Nadalin > wrote: I would be interested also Sent from my Windows 10 phone From: Gil Kirkpatrick Sent: Wednesday, April 6, 2016 4:16 AM To: 'Nat Sakimura'; 'Hardt, Dick'; 'Phil Hunt (IDM)' Cc: scim@ietf.org; oauth@ietf.org Subject: Re: [scim] [OAUTH-WG] Simple Federation Deployment That=92s an issue we=92re facing as well. Definitely interested. -gil From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura Sent: Wednesday, April 6, 2016 4:57 PM To: 'Hardt, Dick' >; 'Phil Hunt (ID= M)' > Cc: scim@ietf.org; oauth@ietf.org Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment +1 for removing the manual cut-n-pastes! Nat -- PLEASE READ :This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail. From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Hardt, Dick Sent: Wednesday, April 6, 2016 7:26 AM To: Phil Hunt (IDM) > Cc: scim@ietf.org; oauth@ietf.org Subject: Re: [scim] Simple Federation Deployment I=92m talking about removing manual steps in what happens today where confi= guring a SaaS app at an IdP (such as Google, Azure, Ping, Octa) requires is= a bunch of cutting and pasting of access tokens / keys / certs and doing a= bunch of config that is error prone and unique for each relationship. Don=92t want to solve on the thread =85 looking to see if there is interest= ! On 4/5/16, 7:11 PM, someone claiming to be "scim on behalf of Phil Hunt (ID= M)" on behalf of phil.= hunt@oracle.com> wrote: Is the idp the center of all things for these users? Usually you have a provisioning system that coordinates state and uses thin= gs like scim connectors to do this. Another approach from today would be to pass a scim event to the remote pro= vider which then decides what needs to be done to facilitate the thingd you= describe. Iow. Either the idp (sender) or the sp (receiver) have a provisioning syste= m to do this. The solution and the simplicity depends on where the control needs to be. Phil On Apr 5, 2016, at 18:59, Hardt, Dick > wrote: Use case: An admin for an organization would like to enable her users to ac= cess a SaaS application at her IdP. User experience: 1. Admin authenticates to IdP in browser 2. Admin selects SaaS app to federate with from list at IdP 3. IdP optionally presents config options 4. IdP redirects Admin to SaaS app 5. Admin authenticates to SaaS app 6. SaaS app optionally gathers config options 7. SaaS app redirects admin to IdP 8. IdP confirms successful federation =3D> OIDC / SAML and SCIM are now = configured and working between IdP and SaaS App Who else is interested in solving this? Is there interest in working on this in either SCIM or OAUTH Wgs? Any one in BA interested in meeting on this topic this week? =97 Dick _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ OAuth mailing 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_C75E2AC872B34D46A78EBEBA27400EF3amazoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I'm writing an ID to submit in the OAuth WG

-- Dick

On Apr 7, 2016, at 8:16 PM, Justin Richer <jricher@mit.edu> wrote:

+1, this seems a better fit for openid.

 =97 Justin

On Apr 6, 2016, at 9:05 AM, Brian Campbell <bcampbell@pingidentity.com= > wrote:

OpenID ... ?

On Wed, Apr 6, 2016 at 9:59 AM, Anthony Nadalin = <t= onynad@microsoft.com> wrote:

Good question, since SCIM does not really provide an= authorization model and Oauth does not do provisioning this is sort of cau= ght in the middle, so if I had to pick I would pick Oauth as this is a gene= ric server to server issue

 

From: Hardt, Dick [mailto:dick@amazon.com]
Sent: Wednesday, April 6, 2016 5:52 AM
To: Anthony Nadalin <tonynad@microsoft.com>
Cc: Gil Kirkpatrick <gil.kirkpatrick@viewds.com>= ;; Nat Sakimura <n-sakimura@nri.co.jp>; Phil Hunt (IDM) <p= hil.hunt@oracle.com>; scim@ietf.org= ; oauth@ietf.org
Subject: Re: [scim] [OAUTH-WG] Simple Federation Deployme= nt

 

Sounds like there is interest.

 

SCIM or OAUTH?

-- Dick


On Apr 6, 2016, at 8:57 AM, Anthony Nadalin <tonynad@microsoft.com> wr= ote:

I would be interested also

 

Sent from my Windows 10 phone

 

From: Gil Kirkpatrick
Sent: Wednesday, April 6, 2016 4:16 AM
To: 'Nat Sakimura'; 'Hardt, Dic= k'; 'Phil Hunt (IDM)'
Cc: scim@ietf.org; oauth@ietf.o= rg
Subject: Re: [scim] [OAUTH-WG] Simple Federation Deployme= nt

 

That=92s an= issue we=92re facing as well. Definitely interested.<= /u>

 

-gil=

 

From: OAuth [mailto:oauth-bounces@ietf= .org] On Behalf Of Nat Sakimura
Sent: Wednesday, April 6, 2016 4:57 PM
To: 'Hardt, Dick' <dick@amazon.com>; 'Phil Hunt (IDM)' <= ;phil.= hunt@oracle.com>
Cc: scim@ietf.org; oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployme= nt

 

+1 for removing the manu= al cut-n-pastes!

 <= /u>

Nat=

 <= /u>

--

PLEASE READ :This e-mail is confide= ntial and intended for the

named recipient only. If you are no= t an intended recipient,

please notify the sender  and = delete this e-mail.

 <= /u>

From: scim [mailto:scim-bounces@ietf.or= g] On Behalf Of Hardt, Dick
Sent: Wednesday, April 6, 2016 7:26 AM
To: Phil Hunt (IDM) <phil.hunt@oracle.com>
Cc: scim@ietf.org; oauth@ietf.o= rg
Subject: Re: [scim] Simple Federation Deployment

 

I=92m = talking about removing manual steps in what happens today where configuring= a SaaS app at an IdP (such as Google, Azure, Ping, Octa) requires is a bun= ch of cutting and pasting of access tokens / keys / certs and doing a bunch of  config that is error prone and u= nique for each relationship.

 =

Don=92= t want to solve on the thread =85 looking to see if there is interest!

 =

On 4/5= /16, 7:11 PM, someone claiming to be "scim on behalf of Phil Hunt (IDM= )" <scim-bounces@ietf.org on behalf of phil.h= unt@oracle.com> wrote:

 =

Is the= idp the center of all things for these users?

 =

Usuall= y you have a provisioning system that coordinates state and uses things lik= e scim connectors to do this. <= /u>

 =

Anothe= r approach from today would be to pass a scim event to the remote provider = which then decides what needs to be done to facilitate the thingd you descr= ibe. 

 =

Iow. E= ither the idp (sender) or the sp (receiver) have a provisioning system to d= o this. 

 =

The so= lution and the simplicity depends on where the control needs to be. 
Phil


On Apr 5, 2016, at 18:59, Hardt, Dick <dick@amazon.com> wrote:

Use ca= se: An admin for an organization would like to enable her users to access a= SaaS application at her IdP. <= /u>

 =

User e= xperience: 

  1. Admin authenticates to IdP in browser
  2. Admin selects SaaS app to federate with from list at Id= P
  3. IdP optionally present= s config options
  4. IdP r= edirects Admin to SaaS app
    5. <= li class=3D"MsoNormal" style=3D"">Admin authenticates to SaaS app
  5. SaaS app optionally gathers config options<= /u>
  6. SaaS app redirects admin to IdP
  7. IdP confirms successful federation = =3D> OIDC / SAML and SCIM are now configured and working between IdP and= SaaS App

Who el= se is interested in solving this?

 =

Is the= re interest in working on this in either SCIM or OAUTH Wgs?

 =

Any on= e in BA interested in meeting on this topic this week?=

 =

=97 Di= ck

______= _________________________________________
scim mailing list
scim@ietf.org=
https://www.ietf.org/mailman/listinfo/scim=


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


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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.i= etf.org/mailman/listinfo/oauth
--_000_C75E2AC872B34D46A78EBEBA27400EF3amazoncom_-- From nobody Thu Apr 7 16:23:45 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A4012D1ED for ; Thu, 7 Apr 2016 16:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRLDu1t4IGuz for ; Thu, 7 Apr 2016 16:23:42 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B7A412D15E for ; Thu, 7 Apr 2016 16:23:42 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u37NNd1h024084 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Apr 2016 23:23:39 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u37NNcmp016316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Apr 2016 23:23:39 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u37NNc2x006042; Thu, 7 Apr 2016 23:23:38 GMT Received: from dhcp-whq-2op-6th-and-7th-floor-gen-off-10-209-43-149.usdhcp.oraclecorp.com (/10.209.43.149) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 07 Apr 2016 16:23:37 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Prateek Mishra In-Reply-To: <5AEB6A4A-A325-4069-930F-D034D81E41E5@mit.edu> Date: Thu, 7 Apr 2016 16:23:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <570546A1.8040509@gmx.net> <5AEB6A4A-A325-4069-930F-D034D81E41E5@mit.edu> To: Hannes Tschofenig X-Mailer: Apple Mail (2.2098) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 23:23:44 -0000 While this work addresses a gap in the existing OAuth specification set, = I am very concerned that this incremental extension will lead to even more confusion around the areas = of =E2=80=9Cscope=E2=80=9D, =E2=80=9Caudience=E2=80=9D and =E2=80=9Cresour= ce server=E2=80=9D. I think we should try to solve this problem via a framework that = provides better guidance and implementation models for OAuth use-cases. In other words, I feel that a broader = discussion is needed here. > On Apr 7, 2016, at 4:11 PM, Justin Richer wrote: >=20 > I support adoption of this document as a starting point for working = group work. >=20 > =E2=80=94 Justin >=20 >=20 >> On Apr 6, 2016, at 1:25 PM, Hannes Tschofenig = wrote: >>=20 >> Hi all, >>=20 >> this is the call for adoption of 'Resource Indicators for OAuth 2.0', = see >> = http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/ >>=20 >> Please let us know by April 20th 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 = Buenos >> Aires then you don't need to re-state your opinion, if you want. >>=20 >> The feedback at the BA IETF meeting was the following: ~10 persons >> for accepting the document and 0 persons against. >>=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 Thu Apr 7 16:44:16 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8034D12D546 for ; Thu, 7 Apr 2016 16:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=viewds-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2xilNLNzuap for ; Thu, 7 Apr 2016 16:44:12 -0700 (PDT) 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 A580612D15E for ; Thu, 7 Apr 2016 16:44:12 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id c20so64657533pfc.1 for ; Thu, 07 Apr 2016 16:44:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=viewds-com.20150623.gappssmtp.com; s=20150623; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=zW016SZ/BWP3VLfYSsY586mMJyuUA2UIJewn43vrXUI=; b=r4vkcDTkGs7jnEMGS1qm7sANzM8AXZuLU+e8KaS8sYyOmNWVZyqhfM5ueG5OFXT37R fqnT603Q1kNQhgMNLgyFtIJHowszVMDK3rUmsbire3rfakWxTro9WfIYhx14BqsvggT6 CSUueObBmEy4tXtmeaXYDoBxw+o9Q+JHyY62N84oL09Uph41I4OL7pX1v+rqkqTC/lmZ uiDgWhIKZl/iqkoBm8SEjIGdh2T/tpAu5Oo+M3sCYBzp4VaVvzR5kalQ4X+dWmJyzaO3 3Orjc6ATRQQxq3fqq3Ri0hReZa5UF5CTjOrjLTYvwP+LRNwqw/5qCu+Za1PstTpGBcRK mkVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=zW016SZ/BWP3VLfYSsY586mMJyuUA2UIJewn43vrXUI=; b=Zw3XparYDqLNa8jI4Ez3y493qDa+fffwiQQy1rwObuV05HnX2wJct7soxgU2dYfAvH +HTtvt5LePeK8j7JdWZFWNENGz4g0tuTDUf+MT3lgpmpAhRfMBbLhptqg2Q7vnY23jCb N/pE2WE6rLJmu5nZn0SwJRDBMc62YNfFmUmoGs578MEB7HnO2WsOkAQaqkOgal/gY0R7 7RUEzq470GZ+QIGjP/9mP6MLBXis3luecm1rcia7qG9AFy+kjtJs/iJL/7A5FZ/2YRvL 5+Ma0Sg1YI4GMyFuD3qKxdUZrzXpsHWCm2IYS7CDOy/U0I33DocJUjZ9Uh9xJDkxb9Zo rw1w== X-Gm-Message-State: AD7BkJK3/eU9uZpVxUX+eo01JYeFWDzjl98BOc06Tyalkmu5Iqx6b4uqtQqknpuJyH3Oww== X-Received: by 10.98.64.4 with SMTP id n4mr8337087pfa.58.1460072652288; Thu, 07 Apr 2016 16:44:12 -0700 (PDT) Received: from WINH57TOAH3443 (2.101.96.58.static.exetel.com.au. [58.96.101.2]) by smtp.gmail.com with ESMTPSA id 83sm14526304pfn.46.2016.04.07.16.44.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Apr 2016 16:44:10 -0700 (PDT) From: "Gil Kirkpatrick" To: "'Hannes Tschofenig'" , References: <57054ADF.3010109@gmx.net> In-Reply-To: <57054ADF.3010109@gmx.net> Date: Fri, 8 Apr 2016 09:43:58 +1000 Message-ID: <000501d19127$5f60da70$1e228f50$@viewds.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQDy2qTHLvKoZQS7HB05lNE0bmP5cqE7X4yg Content-Language: en-us Archived-At: Subject: Re: [OAUTH-WG] Meeting Minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 23:44:15 -0000 >> John Bradley sang a few notes from the Sound of Music to end the = meeting. Were the hills alive? :) -gil -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes = Tschofenig Sent: Thursday, April 7, 2016 3:14 AM To: oauth@ietf.org Subject: [OAUTH-WG] Meeting Minutes Leif was so nice to take meeting notes during the OAuth meeting today = and they have been uploaded to: https://www.ietf.org/proceedings/95/minutes/minutes-95-oauth Please take a look at them and let me know if they are incorrect or need = to be extended. Ciao Hannes From nobody Fri Apr 8 04:31:01 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34C512D133 for ; Fri, 8 Apr 2016 04:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1flJjSZ3B9M for ; Fri, 8 Apr 2016 04:30:58 -0700 (PDT) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2349B12D14F for ; Fri, 8 Apr 2016 04:30:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1460115058; x=1491651058; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HEwFE2as6fLNYH377cYb0EMcXHTORA5TD2GBh/hf79s=; b=AXX8vcmv8IaqKdoVlgyfil7xKkVHP2YX+FcVDlwEtNK9qm8wL7e0mdya yt6DEHofNtS8IESnQ92Wv1/M8BLm5gMaEqeMChvSoIK4MauDdXdV/M5s9 +KLEql+wRlTeFWStLvS31F5Q6D5XW7HCe0rpxRUkW4lp3WKCdbleiBoT6 s=; X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208";a="493863749" Received: from sea19-co-svc-lb5-vlan2.sea.amazon.com (HELO email-inbound-relay-25013.iad12.amazon.com) ([10.47.22.162]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Apr 2016 11:30:55 +0000 Received: from ex10-hub-7001.ant.amazon.com (iad1-ws-svc-lb91-vlan3.amazon.com [10.0.103.150]) by email-inbound-relay-25013.iad12.amazon.com (8.14.7/8.14.7) with ESMTP id u38BUbNx025790 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Apr 2016 11:30:53 GMT Received: from EX13D03UWA001.ant.amazon.com (10.43.160.141) by ex10-hub-7001.ant.amazon.com (10.43.103.49) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 8 Apr 2016 04:30:38 -0700 Received: from EX13D03UWA001.ant.amazon.com (10.43.160.141) by EX13D03UWA001.ant.amazon.com (10.43.160.141) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 8 Apr 2016 11:30:37 +0000 Received: from EX13D03UWA001.ant.amazon.com ([10.43.160.141]) by EX13D03UWA001.ant.amazon.com ([10.43.160.141]) with mapi id 15.00.1104.000; Fri, 8 Apr 2016 11:30:37 +0000 From: "Hardt, Dick" To: Prateek Mishra Thread-Topic: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0 Thread-Index: AQHRkCmLjBDIB7Xo7EGcBjaU8mZ9EZ9/JV+AgAADVwCAAMsaNg== Date: Fri, 8 Apr 2016 11:30:36 +0000 Message-ID: References: <570546A1.8040509@gmx.net> <5AEB6A4A-A325-4069-930F-D034D81E41E5@mit.edu>, 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: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Precedence: Bulk Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 11:31:00 -0000 +1 to Prateek's comments -- Dick > On Apr 7, 2016, at 8:24 PM, Prateek Mishra wr= ote: >=20 > While this work addresses a gap in the existing OAuth specification set, = I am very concerned that this > incremental extension will lead to even more confusion around the areas o= f =93scope=94, =93audience=94 and =93resource server=94. >=20 > I think we should try to solve this problem via a framework that provide= s better guidance and implementation > models for OAuth use-cases. In other words, I feel that a broader discuss= ion is needed here. >=20 >=20 >> On Apr 7, 2016, at 4:11 PM, Justin Richer wrote: >>=20 >> I support adoption of this document as a starting point for working grou= p work. >>=20 >> =97 Justin >>=20 >>=20 >>> On Apr 6, 2016, at 1:25 PM, Hannes Tschofenig wrote: >>>=20 >>> Hi all, >>>=20 >>> this is the call for adoption of 'Resource Indicators for OAuth 2.0', s= ee >>> http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicator= s/ >>>=20 >>> Please let us know by April 20th 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 Buenos >>> Aires then you don't need to re-state your opinion, if you want. >>>=20 >>> The feedback at the BA IETF meeting was the following: ~10 persons >>> for accepting the document and 0 persons against. >>>=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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Sat Apr 9 15:10:56 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D8B12D166 for ; Sat, 9 Apr 2016 15:10:54 -0700 (PDT) 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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yL8M5BKT58Y for ; Sat, 9 Apr 2016 15:10:51 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0744.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::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 5F1D412D18D for ; Sat, 9 Apr 2016 15:10:51 -0700 (PDT) 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=NaXw3f1GxYjPTXVNJfn4+kNR8Ivw6S1+wFEbSwMi3T4=; b=Tjxpz0tELEJMjpjyeEQPfUE6CHCIr7aflfvlmtcUPV2cXcHJrR5BOmDiQ6gg4OEV4kgUyKnjymHMEDGugVtwrCS2ilardoPb7i1vx6D9cBQNBIlKoTcbYWAhgZIjlmu+y/Uwj3UdntEjctf3lpi+0ggwYO6DlEwElLT8QJ6DIAY= 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.453.26; Sat, 9 Apr 2016 22:10:33 +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.0453.028; Sat, 9 Apr 2016 22:10:31 +0000 From: Anthony Nadalin To: "oauth@ietf.org" Thread-Topic: Token Binding and RFC5705 Thread-Index: AdGSZE3FeSpwjlS8RnKkmZkfFfNC2A== Date: Sat, 9 Apr 2016 22:10:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.46.126.7] x-ms-office365-filtering-correlation-id: f3aab892-3e33-4ca7-38d1-08d360c3c454 x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1236; 5:FJHxi4q1odJ/K7QZyoklAMrg3JWQVXDYp6Rr3xSJSdHeHvglbKUD0NgCIeKSBv2Y9/mX3YLFj0brbhK6NbMv2v0Sd9mgAxLPiAfhcWoVuwW4Qd/SRRzCvhQHyNVcRXkz29tskrHGTQwn1cHBNUzUrA==; 24:y2lY3X2ZMaO+OoHwUc8imF4AmWov//MQmyRO6LxcPdEMkrhajnjuSoM9M4gP49NdDRmsiAV+eLsUBsgY8fZRVJOomRL7iFzDrkV6GHnYvuc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1236; 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)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BN3PR0301MB1236; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1236; x-forefront-prvs: 0907F58A24 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(50986999)(122556002)(54356999)(5008740100001)(99286002)(19625215002)(3280700002)(74316001)(106356001)(33656002)(229853001)(2906002)(2351001)(189998001)(2900100001)(110136002)(16236675004)(10290500002)(10400500002)(102836003)(6116002)(790700001)(81166005)(3846002)(2501003)(87936001)(5005710100001)(586003)(86362001)(1220700001)(1096002)(66066001)(19300405004)(5640700001)(5630700001)(10090500001)(9686002)(77096005)(19580395003)(15975445007)(5004730100002)(8990500004)(3660700001)(68736007)(5002640100001)(5003600100002)(1730700002)(4326007)(92566002)(76576001)(86612001)(42262002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1236; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB12341E7A16BFB50BC7FD170BA6920BN3PR0301MB1234_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2016 22:10:31.1396 (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: Andrei Popov Subject: [OAUTH-WG] Token Binding and RFC5705 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 22:10:54 -0000 --_000_BN3PR0301MB12341E7A16BFB50BC7FD170BA6920BN3PR0301MB1234_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At the informal Token Binding meeting we had a discussion of Java servers s= upporting TB, the support would have to come out of JSSE, kere is the analy= sis on what it would take to change JSSE Implementing 5705 itself, would not take too long and appears to be pretty = straightforward. The EKM is created by using the same PRF function as the = creating of the key material from the TLS Master secret. In TLS, To generate the key material, compute key_block =3D PRF(SecurityParameters.master_secret, "key expansion", SecurityParameters.server_random + SecurityParameters.client_random); For EKM, If no context is provided, it then computes: PRF(SecurityParameters.master_secret, label, SecurityParameters.client_random + SecurityParameters.server_random )[length] If context is provided, it computes: PRF(SecurityParameters.master_secret, label, SecurityParameters.client_random + SecurityParameters.server_random + context_value_length + context_value )[length] As it states in the RFC: "The issue is the designing a secure mechanism th= at uses exporters is not necessarily straightforward. This document only pr= ovides the exporter mechanism, but the problem of agreeing on the surroundi= ng context and the meaning of the information passed to and from the export= er remains. Any new uses of the exporter mechanism should be subject to car= eful review." --_000_BN3PR0301MB12341E7A16BFB50BC7FD170BA6920BN3PR0301MB1234_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At the informal Token Binding meeting we had a discu= ssion of Java servers supporting TB, the support would have to come out of = JSSE, kere is the analysis on what it would take to change JSSE<= /p>

 

Implementing 5705 its= elf, would not take too long and appears to be pretty straightforward. = ; The EKM is created by using the same PRF function as the creating of the = key material from the TLS Master secret.

In TLS, 

To generate the key material, compute
 
      key_block =3D PRF(SecurityParameters.ma=
ster_secret,
           &nbs=
p;          "key expansio=
n",
           &nbs=
p;          SecurityParameters=
.server_random +
      &nb=
sp;            =
   SecurityParameters.client_random);
For EKM,

If no context is provided, it then computes:
 
           PRF(Secur=
ityParameters.master_secret, label,
           &nbs=
p;   SecurityParameters.client_random +
           &nbs=
p;   SecurityParameters.server_random
           &nbs=
p;   )[length]
 
   If context is provided, it computes:
 
           PRF(Secur=
ityParameters.master_secret, label,
           &nbs=
p;   SecurityParameters.client_random +
           &nbs=
p;   SecurityParameters.server_random +
           &nbs=
p;   context_value_length + context_value
      &nb=
sp;        )[length]

 

As it states in the RFC:  "The issue is th= e designing a secure mechanism that uses exporters is not necessarily strai= ghtforward. This document only provides the exporter mechanism, but the pro= blem of agreeing on the surrounding context and the meaning of the information passed to and from the exporter remains= . Any new uses of the exporter mechanism should be subject to careful revie= w."

 

--_000_BN3PR0301MB12341E7A16BFB50BC7FD170BA6920BN3PR0301MB1234_-- From nobody Sun Apr 10 04:53:36 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76DBB12D096 for ; Sun, 10 Apr 2016 04:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wahlstromstekniska-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TCBdE7Ad0bf for ; Sun, 10 Apr 2016 04:53:29 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010: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 2160612B03D for ; Sun, 10 Apr 2016 04:53:25 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id c126so124699383lfb.2 for ; Sun, 10 Apr 2016 04:53:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wahlstromstekniska-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=RMPyLKAqInjOx7XO1tiF6mwZcyv0F+BqZRDK2vn1EHE=; b=v7N/n4f+dFpAAT1ROPMHkdxesEIYhrTeCZn9nGeWIW79jYAwDuGh8GAAPrfPa85TUs JUk7p/kGDtTM31uD2jjpF+nZRbx02K1xCyoOJc2u0U+M2H0XVLGy0RrT2dxy325libvf EkEdNGFWnqTA0EOxcL7kJGE3PVSshvg2Z3vIwoNjJahPS1aQPphRs4B3YIbCQ6lhR0Nq XGeGUynlzcfHmjE+pLXAV6I0e7pXNuvp8gMUgNHKyiEIVOqda2xjMRCcyvE2RrqsbdIf CK5q3OHDaWPcDQhs1qeEEdkDrGjbteTf58WZ+B0jn+Sf7J8hRF/GuHo/1ard9ImPycf2 CcNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=RMPyLKAqInjOx7XO1tiF6mwZcyv0F+BqZRDK2vn1EHE=; b=FkAD6TBGoiGdA237WGKFWThTkXfAOtZ8bWJAH8s3QsGnsWwt1gXIldhTxpCd059W7P +qnTH70l8lHoEd332S28EX5KUYshshm3OLyF+dxRMta+3MlRpyLoyYEmvpP33V+Soijp /NAgQdCxJbXUeo0BRIhdWGBJgj2nXlpZL5zC2tKtGys65o0UvUSqmn765jOY329IqEHL /Vx933LmSBC8SE8Okwzzp9eme6SCfm2qaUkEAKNck7YUNXKBc+y1Wg7Ie7KmhFRJC873 fyz35hTNUwG+naB74EfT8NmA4ZDrkt50YKKo/FfBfHklYknGUhVQxDvo6FdiIgxROuFG FnXQ== X-Gm-Message-State: AD7BkJLW4TubqNYexanrzH+XtgblUA2lo3UWAqiYeHIQONNEKQh9UATx9ZFgsvpFp/5OmbqWUNXnw+kbLuoDUg== MIME-Version: 1.0 X-Received: by 10.112.49.50 with SMTP id r18mr6693128lbn.65.1460289203569; Sun, 10 Apr 2016 04:53:23 -0700 (PDT) Received: by 10.25.78.72 with HTTP; Sun, 10 Apr 2016 04:53:23 -0700 (PDT) X-Originating-IP: [37.247.26.197] In-Reply-To: References: Date: Sun, 10 Apr 2016 13:53:23 +0200 Message-ID: From: =?UTF-8?Q?Erik_Wahlstr=C3=B6m?= To: Samuel Erdtman Content-Type: multipart/alternative; boundary=001a113605a43f99cb05302013e3 Archived-At: Cc: "ace@ietf.org" , "" , cose Subject: Re: [OAUTH-WG] [Ace] Call for adoption for draft-wahlstroem-ace-cbor-web-token-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2016 11:53:30 -0000 --001a113605a43f99cb05302013e3 Content-Type: text/plain; charset=UTF-8 +1 On Thu, Apr 7, 2016 at 6:47 AM, Samuel Erdtman wrote: > +1 for adoption > > Sent from my iPhone > > On 7 apr. 2016, at 03:34, Kepeng Li wrote: > > To: ACE WG > Cc: OAuth and COSE WG > > Hello all, > > > This note begins a Call For Adoption for draft-wahlstroem-ace-cbor-web-token-00 [1] > > to be adopted as an ACE working group item, and added in the charter. > The call ends on April 22, 2016. > > Keep in mind that adoption of a document does not mean the document > as-is is ready for publication. It is merely acceptance of the > document as a starting point for what will be the final product > of the ACE working group. The working group is free to make changes to > the document according to the normal consensus process. > > Please reply on this thread with expressions of support or opposition, > preferably with comments, regarding accepting this as a work item. > > > Note that this email was also copied to OAuth and COSE WG, in order to > get input from wider audience. > > > Thanks, > > > Kind Regards > > Kepeng (ACE co-chair) > > > [1] https://datatracker.ietf.org/doc/draft-wahlstroem-ace-cbor-web-token/ > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > --001a113605a43f99cb05302013e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

On Thu, Apr 7, 2016 at 6:47 AM, Samuel Erdtman <samuel@erdtman.se>= ; wrote:
+1= for adoption

Sent from my iPhone
<= br>On 7 apr. 2016, at 03:34, Kepeng Li <kepeng.lkp@alibaba-inc.com> wrote:
To: ACE WG
Cc:=C2=A0OAuth and COSE WG

Hello all,

This note begins a Call For Adoption for =
draft-w=
ahlstroem-ace-cbor-web-token-00 [1]
to be adopted as an ACE working grou= p item, and added in the charter.
<= div>The call ends on = April 22, 2016.

Keep =
in mind that adoption of a document does not mean the document
as-is is ready for publication. It is merely acceptance of the
document as a starting point for what will be the final product
of the ACE working group. The working group is free to make changes to
the document according to the normal consensus process.

Please reply on this thread with expressions of support or opposition,
preferably with comments, regarding accepting this as a work item.

<= font face=3D"Courier" style=3D"font-size:12px">Note that this email was als= o copied to OAuth and COSE WG, in order to=C2=A0
= get input from wider audien= ce.

Thanks,

Kind Regards
Kepeng (ACE =
co-chair)


_______= ________________________________________
Ace mailing list
Ace@ietf.o= rg
https://www.ietf.org/mailman/listinfo/ace

_____________________________________________= __
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


--001a113605a43f99cb05302013e3-- From nobody Sun Apr 10 05:51:34 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC98D12D522; Sun, 10 Apr 2016 05:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3tESGFeCfrv; Sun, 10 Apr 2016 05:51:16 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D18E412D11E; Sun, 10 Apr 2016 05:51:14 -0700 (PDT) X-AuditID: 12074422-bf3ff70000007b1b-19-570a4c412059 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 94.E4.31515.14C4A075; Sun, 10 Apr 2016 08:51:13 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u3ACpCqB006169; Sun, 10 Apr 2016 08:51:12 -0400 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u3ACp6aq019742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 10 Apr 2016 08:51:07 -0400 To: =?UTF-8?Q?Erik_Wahlstr=c3=b6m?= , Samuel Erdtman References: From: Justin Richer Message-ID: <570A4C2D.4030701@mit.edu> Date: Sun, 10 Apr 2016 08:50:53 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------050806070808050500030608" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDKsWRmVeSWpSXmKPExsUixCmqrevowxVuMPurlMX3bz3MFtO2TmW1 +DqhidVi6c57rBYNO/MtLs8vsjj59hWbxf+lp5gspu+9xu7A6THx7UcWj7XdV9k8Xvzbw+ix c9Zddo/Fm/azeSxZ8pPJY820GSwB7FFcNimpOZllqUX6dglcGa/XXGYvmFFR8f7JaqYGxu/+ XYycHBICJhLXv3UzdTFycQgJtDFJrF5wiwXC2cgo8fzxGqjMbSaJn4vWMIK0CAtESMw63gmU 4OAQEciVeNTLDFGziVGi7/FMRhCHWWAXk8Sn5n6wBjYBVYnpa1qYQGxeATWJZU/fs4LYLEDx G9+/gcVFBWIkGh+cgqoRlDg58wkLiM0pECjRdeUNG4jNLBAm8WnqPtYJjPyzkJTNQpKCsM0k urZ2MULY8hLNW2czQ9hqEre3XWVHFl/AyLaKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI11QvN7NE LzWldBMjKKLYXZR2ME7853WIUYCDUYmHN6KEM1yINbGsuDL3EKMkB5OSKK/VS45wIb6k/JTK jMTijPii0pzU4kOMEhzMSiK8Jx24woV4UxIrq1KL8mFS0hwsSuK8QZHHwoQE0hNLUrNTUwtS i2CyMhwcShK8BV5AjYJFqempFWmZOSUIaSYOTpDhPEDD2T1BhhcXJOYWZ6ZD5E8x6nKsm3Ft LZMQS15+XqqUOK8PyCABkKKM0jy4OaBEmPD2sOkrRnGgt4R52UBG8QCTKNykV0BLmICWPPvH CbKkJBEhJdXA2BTzmmNbZYBeamCjedIFaeXCbVZ+ueUbpKO5Gpat4Uir/dTVGpnp2FZ258Kh W9NS1oZ+td4rcYZl5p1WkRP8bAWTAgtcKo/K52T3teapLvnMEtgfzeDablwrv+P/ropj708K r9qvLbX3+W5b/YWMD4ynGe18VLGjNDMp4Xn1Tptv27QsJ3QosRRnJBpqMRcVJwIAk9cSyF8D AAA= Archived-At: Cc: cose , "ace@ietf.org" , "" Subject: Re: [OAUTH-WG] [COSE] [Ace] Call for adoption for draft-wahlstroem-ace-cbor-web-token-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2016 12:51:20 -0000 This is a multi-part message in MIME format. --------------050806070808050500030608 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit +1 for adoption, but please remove the "web" from the name. One of the main features of JSON Web Tokens, from which this is inspired, is that it can be passed without any additional encoding in HTTP headers, parameters, forms, strings, etc. It's built for the "web" from the ground up. The same is not true of the COSE-based token format here. It's designed for CoAP and other embedded systems that can speak the CBOR encoding natively. You could argue that this is the "web" in a sense but I think that it's misleading to implementors to claim such. Therefore I strongly encourage the authors and ACE WG to drop the "web" from the name, leaving simply the COSE Token. -- Justin On 4/10/2016 7:53 AM, Erik Wahlström wrote: > +1 > > On Thu, Apr 7, 2016 at 6:47 AM, Samuel Erdtman > wrote: > > +1 for adoption > > Sent from my iPhone > > On 7 apr. 2016, at 03:34, Kepeng Li > wrote: > >> To: ACE WG >> Cc: OAuth and COSE WG >> >> Hello all, >> This note begins a Call For Adoption fordraft-wahlstroem-ace-cbor-web-token-00 [1] >> to be adopted as an ACE working group item, and added in the charter. >> The call ends on April 22, 2016. >> >> Keep in mind that adoption of a document does not mean the document >> as-is is ready for publication. It is merely acceptance of the >> document as a starting point for what will be the final product >> of the ACE working group. The working group is free to make changes to >> the document according to the normal consensus process. >> >> Please reply on this thread with expressions of support or opposition, >> preferably with comments, regarding accepting this as a work item. >> >> Note that this email was also copied to OAuth and COSE WG, in >> order to >> get input from wider audience. >> Thanks, >> Kind Regards >> Kepeng (ACE co-chair) >> >> [1] >> https://datatracker.ietf.org/doc/draft-wahlstroem-ace-cbor-web-token/ >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose --------------050806070808050500030608 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit +1 for adoption, but please remove the "web" from the name.

One of the main features of JSON Web Tokens, from which this is inspired, is that it can be passed without any additional encoding in HTTP headers, parameters, forms, strings, etc. It's built for the "web" from the ground up.

The same is not true of the COSE-based token format here. It's designed for CoAP and other embedded systems that can speak the CBOR encoding natively. You could argue that this is the "web" in a sense but I think that it's misleading to implementors to claim such.

Therefore I strongly encourage the authors and ACE WG to drop the "web" from the name, leaving simply the COSE Token.

 -- Justin

On 4/10/2016 7:53 AM, Erik Wahlström wrote:
+1

On Thu, Apr 7, 2016 at 6:47 AM, Samuel Erdtman <samuel@erdtman.se> wrote:
+1 for adoption

Sent from my iPhone

On 7 apr. 2016, at 03:34, Kepeng Li <kepeng.lkp@alibaba-inc.com> wrote:

To: ACE WG
Cc: OAuth and COSE WG

Hello all,

                                    
This note begins a Call For Adoption for draft-wahlstroem-ace-cbor-web-token-00 [1]

                                  

                                

                            

                          
                        
to be adopted as an ACE working group item, and added in the charter.

                        
                          

                            

                                
The call ends on April 22, 2016.

                              

                          

                        
                        


                        

                        
                          

                            

                                  

                                    
Keep in mind that adoption of a document does not mean the document
as-is is ready for publication. It is merely acceptance of the
document as a starting point for what will be the final product
of the ACE working group. The working group is free to make changes to
the document according to the normal consensus process.

Please reply on this thread with expressions of support or opposition,
preferably with comments, regarding accepting this as a work item.

                                  

                                

                          

                        
                        


                        

                        
Note
                            that this email was also copied to OAuth and
                            COSE WG, in order to 

                        
get
                            input from wider audience.

                        
                          

                            

                                

                                  

                                  
Thanks,

                                  

                                  
Kind Regards

                                  
Kepeng (ACE co-chair)

                                

                              

                          

                        
                        


                          

                        
                        


                        

                      

                    

                  

                

                

                  
_______________________________________________

                    Ace mailing list

                    Ace@ietf.org

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

                  

                

              

              

              _______________________________________________

              Ace mailing list

              Ace@ietf.org

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

              

            

          

          

        

      

      

      

      

      
_______________________________________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose


    

    

  


--------------050806070808050500030608--


From nobody Sun Apr 10 10:43:21 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 702A212B05A for ; Sun, 10 Apr 2016 10:43:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLiK-bqiuOrB for ; Sun, 10 Apr 2016 10:43:17 -0700 (PDT)
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 A77FB12B05B for ; Sun, 10 Apr 2016 10:43:16 -0700 (PDT)
Received: by mail-qg0-x231.google.com with SMTP id f52so127991492qga.3 for ; Sun, 10 Apr 2016 10:43:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XfuKKshH/d5z9uZSvL75rjHFRSg47x2NyvsIvtC1dQc=; b=UbLIx632Mz/ttSW7eii5wIUMkUpvtHWv9k0L3rwBNjBRYogoANmuHt0DppzszZWxTN taQvUXj82LK/n1tqtXXDKgEuNU7ARl9vqCFAL5Qp/XykrGxYuL0NTIJXW9/DVT0zPDo2 9Q2Xao3E7sJ8mikfS9PkePDTQAP0xY+qaH/KptO6azo4vC86KrrWN8608feLjdDsRXht WhlhQ7xmu8zBlsuawaDu1ve5C2nIsc95DKz5bv2i0HH5dEkFFlosx7wDKf+uXmAWVKbt MPylxBvhv1pj8xj2JgV+oPbIlit3u4yVKYzogMuKTTHlZf9vr/H/1v0TLfU0IjnX5xAq NHSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XfuKKshH/d5z9uZSvL75rjHFRSg47x2NyvsIvtC1dQc=; b=MM5gOsdxJzh5IdB0/YUgZ6aIlzBQVPNcOnPrY44NKwitUvQ+z2dajrs0YYPeBsMZLM myrEXodPC3BUMnmCZYSFNGNgexrrYpprgZ8sFK41zhPI0X4wfuNnnkYVZURTwnWh8D6B fdCYMYj709yhSUrvF/VxAIHfADPCAWAazQUs3w/6hc7/nlo03JzSuRvBgiyZ/N277RXx OSK8jHJqrONztFOHs8MoRVt8uiYGbXnzll1sxpRixRgQLPVivgYM7qQpVrZoHy/9a6x3 mWKj6AOQ6PXjxXrbF3Tk07+bzeRmXitGL/PZ4sqQC0Uaj2ek9uXdYqZJSVbzDuf5Wy5F rrOA==
X-Gm-Message-State: AD7BkJIcOvilZwZ+GOyhsCteqIhae4zjrUqGhjxBjoosXo4f9UTi+LcTYlh4AVnnpm7MMmhvBbtXSZxGn0tsTw==
X-Received: by 10.140.252.197 with SMTP id x188mr25167895qhc.81.1460310195681;  Sun, 10 Apr 2016 10:43:15 -0700 (PDT)
MIME-Version: 1.0
References: <570546A1.8040509@gmx.net> <5AEB6A4A-A325-4069-930F-D034D81E41E5@mit.edu> 
In-Reply-To: 
From: Nat Sakimura 
Date: Sun, 10 Apr 2016 17:43:05 +0000
Message-ID: 
To: Prateek Mishra ,  Hannes Tschofenig 
Content-Type: multipart/alternative; boundary=001a113a988a79c180053024f667
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 10 Apr 2016 17:43:19 -0000

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

So, my understanding on the rationale/requirements for having this spec
right now is:

R1. Authz server wants toprevent the replay by the server that received it.
R2. Authz server needs to mint the access token in a variety of format
depending on the resource server and to do that, you need to know which RS
is gong to be receiving it.

To achieve R1, there are couple of methods. The proposed method here is to
audience restrict the token, but the same can be achieved by sender
constraining the token, e.g., by token binding. As far as I can see, the
sentiment of the WG seems to be to use the sender constraint through Token
Binding, so from this respect, this spec is not the one to do R1. Besides,
the current proposal only takes care of the code flow. The same requirement
should be there for implicit flow as well, so the current proposal is not
covering the R1 anyways.

I can sort of understand R2, but I have two critique on the current
proposal:

C1. Current proposal does not support the implicit flow. To support it, the
resource URI has to be sent to the Authz endpoint instead of the Token
endpoint.
C2. It is much more direct to send the required token format rather than
the RS uri and probably better as:
  1) There are use cases where the AS does not maintain the list of RSs
that it supports, e.g., AOL.
       In such a case, even if the RS uri were sent to the AS, the AS
cannot mint the tokens in the appropriate format.
  2) When it is sent in the Authz request, it is leaking the information
about the resource that the client is going to the browser.
  3) There are use cases where it is desirable not to let the AS knows
where the Client is going from the privacy point of view.

So, my suggestion is to drop R1 and concentrate on R2. And to solve R2,
send token type instead of the resource indicator in the request.
This also necessitates the Client to be able to find out what token type
the resource requires, perhaps in the unauthorized response web link header
at the resource in the manner of oauth-meta.

Cheers,

Nat



2016=E5=B9=B44=E6=9C=888=E6=97=A5(=E9=87=91) 8:23 Prateek Mishra :

> While this work addresses a gap in the existing OAuth specification set, =
I
> am very concerned that this
> incremental extension will lead to even more confusion around the areas o=
f
> =E2=80=9Cscope=E2=80=9D, =E2=80=9Caudience=E2=80=9D and =E2=80=9Cresource=
 server=E2=80=9D.
>
> I think we should try to solve this problem via  a framework that provide=
s
> better guidance and implementation
> models for OAuth use-cases. In other words, I feel that a broader
> discussion is needed here.
>
>
> > On Apr 7, 2016, at 4:11 PM, Justin Richer  wrote:
> >
> > I support adoption of this document as a starting point for working
> group work.
> >
> > =E2=80=94 Justin
> >
> >
> >> On Apr 6, 2016, at 1:25 PM, Hannes Tschofenig <
> hannes.tschofenig@gmx.net> wrote:
> >>
> >> Hi all,
> >>
> >> this is the call for adoption of 'Resource Indicators for OAuth 2.0',
> see
> >>
> http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
> >>
> >> Please let us know by April 20th 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 Buenos
> >> Aires then you don't need to re-state your opinion, if you want.
> >>
> >> The feedback at the BA IETF meeting was the following: ~10 persons
> >> for accepting the document and 0 persons against.
> >>
> >> 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
>

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


So, my understanding on the rationale/requirements for hav=
ing this spec right now is:=C2=A0

R1. Authz server wants=
 toprevent the replay by the server that received it.=C2=A0
R2. A=
uthz server needs to mint the access token in a variety of format depending=
 on the resource server and to do that, you need to know which RS is gong t=
o be receiving it.=C2=A0

To achieve R1, there are =
couple of methods. The proposed method here is to audience restrict the tok=
en, but the same can be achieved by sender constraining the token, e.g., by=
 token binding. As far as I can see, the sentiment of the WG seems to be to=
 use the sender constraint through Token Binding, so from this respect, thi=
s spec is not the one to do R1. Besides, the current proposal only takes ca=
re of the code flow. The same requirement should be there for implicit flow=
 as well, so the current proposal is not covering the R1 anyways.=C2=A0

I can sort of understand R2, but I have two critique =
on the current proposal:=C2=A0

C1. Current proposa=
l does not support the implicit flow. To support it, the resource URI has t=
o be sent to the Authz endpoint instead of the Token endpoint.=C2=A0
<=
div>C2. It is much more direct to send the required token format rather tha=
n the RS uri and probably better as:=C2=A0
=C2=A0 1) There are us=
e cases where the AS does not maintain the list of RSs that it supports, e.=
g., AOL.=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0In such a case, even if=
 the RS uri were sent to the AS, the AS cannot mint the tokens in the appro=
priate format.=C2=A0
=C2=A0 2) When it is sent in the Authz reque=
st, it is leaking the information about the resource that the client is goi=
ng to the browser.=C2=A0
=C2=A0 3) There are use cases where it i=
s desirable not to let the AS knows where the Client is going from the priv=
acy point of view.=C2=A0

So, my suggestion is to d=
rop R1 and concentrate on R2. And to solve R2, send token type instead of t=
he resource indicator in the request.=C2=A0
This also necessitate=
s the Client to be able to find out what token type the resource requires, =
perhaps in the unauthorized response web link header at the resource in the=
 manner of oauth-meta.=C2=A0

Cheers,=C2=A0

Nat



2016=E5=B9=B44=E6=9C=888=E6=97=A5(=E9=
=87=91) 8:23 Prateek Mishra <Prateek.Mishra@oracle.com>:
jricher@mit.edu> wrote:

>

> I support adoption of this document as a starting point for working gr=
oup work.

>

> =E2=80=94 Justin

>

>

>> On Apr 6, 2016, at 1:25 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

>>

>> Hi all,

>>

>> this is the call for adoption of 'Resource Indicators for OAut=
h 2.0', see

>> http://datatracker=
.ietf.org/doc/draft-campbell-oauth-resource-indicators/

>>

>> Please let us know by April 20th whether you accept / object to th=
e

>> adoption of this document as a starting point for work in the OAut=
h

>> working group.

>>

>> Note: If you already stated your opinion at the IETF meeting in Bu=
enos

>> Aires then you don't need to re-state your opinion, if you wan=
t.

>>

>> The feedback at the BA IETF meeting was the following: ~10 persons=


>> for accepting the document and 0 persons against.

>>

>> Ciao

>> Hannes & Derek

>>

>> _______________________________________________

>> OAuth mailing list

>> OAuth@ietf.org=


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

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=


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



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--001a113a988a79c180053024f667--


From nobody Mon Apr 11 00:04:58 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2682312E778 for ; Mon, 11 Apr 2016 00:04:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adobe.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2yOLUxX9IaJ for ; Mon, 11 Apr 2016 00:04:53 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0613.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::613]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B540612E775 for ; Mon, 11 Apr 2016 00:04:52 -0700 (PDT)
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=wfLFnq+0zQvt226wiq9EoD28xWLlm+x05IPUzdNIVnE=; b=WU/86JKsvZCFxu/Vd+pFqKn5H/qjRsDtVKw7zZZ4BnLzmc44KVRi0p92VEimIuXCdown64826IZmaO00hCqSbk8mzjJv8Kt8Fkfnoh+wqpownIt0vUOrQg5n4jtp8rE5OFv9q6NzqXUXoP8qbvBJFaLAvC8fQzQqWG4EqDuFlNs=
Received: from BY1PR0201MB1030.namprd02.prod.outlook.com (10.161.203.148) by BY1PR0201MB1029.namprd02.prod.outlook.com (10.161.203.147) with Microsoft SMTP Server (TLS) id 15.1.453.26; Mon, 11 Apr 2016 07:04:34 +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.0453.029; Mon, 11 Apr 2016 07:04:34 +0000
From: Antonio Sanso 
To: "" 
Thread-Topic: Some recent FUD about OAuth
Thread-Index: AQHRk8Bm04dclhGcX0argmp5rc+90Q==
Date: Mon, 11 Apr 2016 07:04:34 +0000
Message-ID: <33F1FAA0-4F0D-455B-8D90-F451346C9BED@adobe.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=adobe.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [192.147.117.11]
x-ms-office365-filtering-correlation-id: f4974773-e106-474c-8c86-08d361d78993
x-microsoft-exchange-diagnostics: 1; BY1PR0201MB1029; 5:nvG62vMVS3o/+28OZ6x7v32H9fs6wPc3OWly59SEWcnd9KIxHPWFXjnyS8xM7o1Q6XU5SIlZSoDw/HwY2Bm6oPB8jfBD3jig2tGp5Kkz+5ZdjQ9yjOML/yN37WsI5MZFxBHVQASNvkD43C4JMbGuMQ==; 24:FJSfiXmrdemKpVRezTBbdd5KJUFgpsSkc8KHJG03JlZKs9MIEH73I08Q18aqCPSTsrkKej7JAwT+uVglPb5456/Tjn6snV8PW04l7/lmtrE=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0201MB1029;
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)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BY1PR0201MB1029; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0201MB1029; 
x-forefront-prvs: 09090B6B69
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(102836003)(3846002)(586003)(6116002)(15975445007)(77096005)(5008740100001)(82746002)(54356999)(50986999)(19580395003)(450100001)(3280700002)(87936001)(3660700001)(83716003)(10400500002)(1096002)(15188555004)(2900100001)(1220700001)(66066001)(5002640100001)(106116001)(110136002)(189998001)(107886002)(558084003)(229853001)(81166005)(92566002)(36756003)(10090500001)(99286002)(2906002)(11100500001)(122556002)(5004730100002)(86362001)(33656002)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0201MB1029; H:BY1PR0201MB1030.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
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: 11 Apr 2016 07:04:34.1820 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0201MB1029
Archived-At: 
Subject: [OAUTH-WG] Some recent FUD about OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Apr 2016 07:04:56 -0000

Just sharing, do not shoot the messenger :)

http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-t=
o-zero-day-attack.html

and  companion website:

http://no-oauth.insanecoding.org/

regards

antonio=


From nobody Mon Apr 11 00:26:42 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE51B12E7DC for ; Mon, 11 Apr 2016 00:26:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2bxvn9nmbKo for ; Mon, 11 Apr 2016 00:26:38 -0700 (PDT)
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 863C812E28C for ; Mon, 11 Apr 2016 00:26:38 -0700 (PDT)
Received: by mail-wm0-x22e.google.com with SMTP id l6so133285049wml.1 for ; Mon, 11 Apr 2016 00:26:38 -0700 (PDT)
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-transfer-encoding; bh=gacvLDHlt/NkC/OG1JS2S6ARitD0sO1NigiQ1M0F03g=; b=c3vmVNELak7MFn9MOjhGhuz31pywra1RBUu0SNbkXHLvPEu5OPj1qTfO4pyAHZ0ly5 Hm2ABi9MRbHWa487PSrVIhu5rWTxDCN1op2EZPgksglvtcLaL7wHasv35ynpuhw1PJEa zSAbSeB4qlPDBbpKHfrIJn1ijMiJwiknXer7w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=gacvLDHlt/NkC/OG1JS2S6ARitD0sO1NigiQ1M0F03g=; b=ihRmOy4fWPKhMuxUrmv0vCO3qpEmI8wcaemyvb0CFXJx+0GrOZ0bNq2cJs3pR7fpQh CPJDn1TjlkkTh6LyAp3Ncu7XqxxpQIn1To1o0Z+YPw+dWKTz/tYYQqgHDp/loqII8ghV m1MjEf3m8KcK98zofGbC9ZpuebuAsWJntzGH2twfFVRfXj5eFgCQnaAO4+Q2/a8SZABV 6Yxg8YEu8qiIhSNAubVwr1Si/FP+oVKfbzHqBKWlgWIo9hnV+Lv/3PXy7ZP3CsRpUjS1 v5zmO6Mtzbqjj1eaI3eXr7a3vZZMaV8P2t0fc54SLwfGibfNrnVF+z7wj+v2QkQy7hN8 p9Bg==
X-Gm-Message-State: AOPr4FVW1zbHq+Vsm+ZRMiNiovfkjZR5YkxNfBNslydEf7XeLozUUlyVGyN4rWeFPZ8ROKR+
X-Received: by 10.28.184.77 with SMTP id i74mr12002418wmf.82.1460359597040; Mon, 11 Apr 2016 00:26:37 -0700 (PDT)
Received: from [192.168.125.52] (static-138-218-78-212.thenetworkfactory.nl. [212.78.218.138]) by smtp.gmail.com with ESMTPSA id o128sm15709880wmb.19.2016.04.11.00.26.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Apr 2016 00:26:35 -0700 (PDT)
To: Antonio Sanso , "" 
References: <33F1FAA0-4F0D-455B-8D90-F451346C9BED@adobe.com>
From: Hans Zandbelt 
Message-ID: <570B51AA.10104@pingidentity.com>
Date: Mon, 11 Apr 2016 09:26:34 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <33F1FAA0-4F0D-455B-8D90-F451346C9BED@adobe.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [OAUTH-WG] Some recent FUD about OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Apr 2016 07:26:40 -0000

"JWT is a specification for allowing SSO or API usage between services. 
In many ways JWT is like SAML"

makes me stop trying to parse/understand the rest of it

Hans.

On 4/11/16 9:04 AM, Antonio Sanso wrote:
> Just sharing, do not shoot the messenger :)
>
> http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html
>
> and  companion website:
>
> http://no-oauth.insanecoding.org/
>
> regards
>
> antonio
> _______________________________________________
> 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 Apr 11 00:37:23 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68FC12E2E0 for ; Mon, 11 Apr 2016 00:37:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adobe.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhlgcyeNlpbi for ; Mon, 11 Apr 2016 00:37:19 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0622.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:622]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B30412E846 for ; Mon, 11 Apr 2016 00:37:19 -0700 (PDT)
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=8JUyVFckkikcuxZO7N785dTYUbgGsa7MiH3bo71nx7c=; b=I03KLevsHRejxThLTRbkw9kBadkQah8MZLUFmLHtiBJPiopFh/HVqqpYJJF+/VvNIIA0OxaSL7liKo2ukQvJX+sJwDV5feNNZGLNwxTLqCEn4DUgANEV14VuCO7H3mii5m9Np9HLYdlgdnh6AW2KNQUTo9lofc1CGLpe1a0+L70=
Received: from BY1PR0201MB1030.namprd02.prod.outlook.com (10.161.203.148) by BY1PR0201MB1032.namprd02.prod.outlook.com (10.161.203.15) with Microsoft SMTP Server (TLS) id 15.1.453.26; Mon, 11 Apr 2016 07:37: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.0453.029; Mon, 11 Apr 2016 07:37:03 +0000
From: Antonio Sanso 
To: Hans Zandbelt 
Thread-Topic: [OAUTH-WG] Some recent FUD about OAuth
Thread-Index: AQHRk8Bm04dclhGcX0argmp5rc+90Z+EX3IAgAADkoA=
Date: Mon, 11 Apr 2016 07:37:03 +0000
Message-ID: <663E3483-794D-4B6C-91FB-3BD3D5F1D047@adobe.com>
References: <33F1FAA0-4F0D-455B-8D90-F451346C9BED@adobe.com> <570B51AA.10104@pingidentity.com>
In-Reply-To: <570B51AA.10104@pingidentity.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: pingidentity.com; dkim=none (message not signed) header.d=none; pingidentity.com; dmarc=none action=none header.from=adobe.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [192.147.117.11]
x-ms-office365-filtering-correlation-id: bd35b3cc-ca11-474d-753b-08d361dc132c
x-microsoft-exchange-diagnostics: 1; BY1PR0201MB1032; 5:hD3hR4STp2Y3nZ3gOWmSn69/1BRo18WWIRZ0Sbu/aU6YDDDIxns/bZONRYVtBSxB2Gry0s1ZQDw3UzfvJsPAQYRTB+Eg2r2Jovl2hMXdMUiMOV4KKzyjZLdwMj2kqgpeWCWi3XAvIUABjK4odJqmpg==; 24:6HiErSjWdRW5WJUnOj7P9WWCbsWIKLGKsLY9jAZI5PSHDEnnESO2l7mqAh4NUze+/DUdp8vuy0cCFSmC59rBYETD4ZNmDJ8DsVlVbmRMcR4=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0201MB1032;
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)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BY1PR0201MB1032; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0201MB1032; 
x-forefront-prvs: 09090B6B69
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(24454002)(122556002)(36756003)(77096005)(2906002)(81166005)(110136002)(5004730100002)(50986999)(15975445007)(189998001)(4326007)(92566002)(19580405001)(1220700001)(3280700002)(1096002)(3660700001)(5008740100001)(2900100001)(2950100001)(19580395003)(86362001)(87936001)(10400500002)(102836003)(6116002)(3846002)(586003)(10090500001)(82746002)(54356999)(11100500001)(83716003)(76176999)(66066001)(99286002)(33656002)(106116001)(5002640100001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0201MB1032; H:BY1PR0201MB1030.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <1E34CFB424B6154787BABC8CB06DC2B5@namprd02.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2016 07:37:03.0658 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0201MB1032
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Some recent FUD about OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Apr 2016 07:37:21 -0000

hi Hans,

indeed I found this article technically inaccurate and it annoyed me quite =
a bit=85

regards

antonio

On Apr 11, 2016, at 9:26 AM, Hans Zandbelt  wro=
te:

> "JWT is a specification for allowing SSO or API usage between services. I=
n many ways JWT is like SAML"
>=20
> makes me stop trying to parse/understand the rest of it
>=20
> Hans.
>=20
> On 4/11/16 9:04 AM, Antonio Sanso wrote:
>> Just sharing, do not shoot the messenger :)
>>=20
>> http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-ho=
w-to-zero-day-attack.html
>>=20
>> and  companion website:
>>=20
>> http://no-oauth.insanecoding.org/
>>=20
>> regards
>>=20
>> antonio
>> _______________________________________________
>> 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


From nobody Mon Apr 11 05:21:42 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D558212D1DA for ; Mon, 11 Apr 2016 05:21:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMCT5URUQTXl for ; Mon, 11 Apr 2016 05:21:39 -0700 (PDT)
Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DDD212D52E for ; Mon, 11 Apr 2016 05:21:39 -0700 (PDT)
Received: by mail-io0-x22a.google.com with SMTP id g185so206050401ioa.2 for ; Mon, 11 Apr 2016 05:21:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wOiyRqUzDBYVtaMyv0zHIFC/7Z5bJB/sCgXreKzJbcA=; b=l94oDGwk298evVG7WCpFg8IlCc4D4xF5CDvvkSGr3ENrzpgn2c5R0pQAR0tw01GUhj BK4WgeNwC12k+ZwSW7WmRE9iyQqpisRKwrlvY1/ooMg7TinrIIWyAG98BJRG3XPvwAe2 VoghXEm9uDoO4qpaAcSo8smn9GyZoMgz90+Mo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wOiyRqUzDBYVtaMyv0zHIFC/7Z5bJB/sCgXreKzJbcA=; b=lYqOAwyFnkW6Sqi2NGrl23TCt/6Nfn2O+7MVIJLWOaIu9UlKHnZKa20J03cWvAEjQo /Zvjh22b5DfdSYiFRHVdgnEqsEK7KXNHyTnShkBzqr9lV5psOC+QR9uydN7t4mXOqhml r3C1xxRx98Nz7Hu9PR0MbLCyA8wikuCsuwK1dWsaO/vyUhaUm+G3MHQW4D4DkH+T5mSU JMK5yROsCRBvryMrnKQ1DScdR9TZcawniYFau3btsmnvgS0rLLvtg9RsgWbvGumOW8fQ ieJwHatMga6QT3SXhJKVMy72hlpc6oJ/6KAnv5aQVDU76M/kCldrMvsyqvz49yvgnGIv hAtw==
X-Gm-Message-State: AD7BkJKcStq3jPuVqZjOeZpNCMenNxuUH1JbRXJC/Rpm925nzLoh+8q6d68QdMwPDtw3PTpHo22ZVICTmXdak+EF
X-Received: by 10.107.162.7 with SMTP id l7mr26119162ioe.147.1460377298398; Mon, 11 Apr 2016 05:21:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.74.162 with HTTP; Mon, 11 Apr 2016 05:21:08 -0700 (PDT)
In-Reply-To: <57054ADF.3010109@gmx.net>
References: <57054ADF.3010109@gmx.net>
From: Brian Campbell 
Date: Mon, 11 Apr 2016 06:21:08 -0600
Message-ID: 
To: Hannes Tschofenig 
Content-Type: multipart/alternative; boundary=001a1140e6381c33e705303496fa
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Meeting Minutes
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Apr 2016 12:21:41 -0000

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

Under the Token Exchange part it says, "Jim Fenton: we have implmentation
that could be adapted to this." but, as I recall, Jim was not speaking for
himself there but rather on behalf of Justin via the Jabber room.



On Wed, Apr 6, 2016 at 11:43 AM, Hannes Tschofenig <
hannes.tschofenig@gmx.net> wrote:

> Leif was so nice to take meeting notes during the OAuth meeting today
> and they have been uploaded to:
> https://www.ietf.org/proceedings/95/minutes/minutes-95-oauth
>
> Please take a look at them and let me know if they are incorrect or need
> to be extended.
>
> Ciao
> Hannes
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

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


Under the Token Exchange part it says, "Jim Fenton: w=
e have implmentation that could be adapted to this." but, as I recall,=
 Jim was not speaking for himself there but rather on behalf of Justin via =
the Jabber room.=C2=A0 



On Wed, Apr 6, 2016 at 11:43 AM, Hannes Tschofenig =
<hannes.tschofenig@gmx.net> wrote:
Leif was so nice to take meeting notes during the OAuth =
meeting today

and they have been uploaded to:

https://www.ietf.org/proceedings/95/minu=
tes/minutes-95-oauth



Please take a look at them and let me know if they are incorrect or need
to be extended.



Ciao

Hannes




_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





--001a1140e6381c33e705303496fa--


From nobody Mon Apr 11 06:25:56 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D23F312EEA1 for ; Mon, 11 Apr 2016 06:25:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5wwoYkzggVg for ; Mon, 11 Apr 2016 06:25:53 -0700 (PDT)
Received: from mx0a-0019e102.pphosted.com (mx0a-0019e102.pphosted.com [67.231.149.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A738A12EEA0 for ; Mon, 11 Apr 2016 06:25:53 -0700 (PDT)
Received: from pps.filterd (m0074413.ppops.net [127.0.0.1]) by mx0a-0019e102.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u3BDLM5D010427 for ; Mon, 11 Apr 2016 08:25:51 -0500
Received: from mail-yw0-f177.google.com (mail-yw0-f177.google.com [209.85.161.177]) by mx0a-0019e102.pphosted.com with ESMTP id 22867kgt3r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 11 Apr 2016 08:25:51 -0500
Received: by mail-yw0-f177.google.com with SMTP id o66so116927618ywc.3 for ; Mon, 11 Apr 2016 06:25:51 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=HoAS91iYQ9KCgiAUcm2iKTuV9cmz/KELQjGGFrBpuyA=; b=A4Pf0FQ+lB2O10tpAYRAzO2hf7/J8RK5u1cMX4tSEItkAo6sauCVAEGzNTIJDHHG3R mWenchUZdV8EY0vHLEtS7YWCHaCrgVVqy3dKkqig3Ufdpa5fGS+hY9X6ikxSmfjtpScQ xDWuCvnSr5IJFUE9D8MFHHhuLL6aCdJrX4xLA1oihzoWNZg9J56w5rdLhXErg+hkOMx/ nfacawQA83tegQAscRPElNf7OnI+mE2XjCdKUka7z8GbdHtBs1Isf6PlnfWonKh9kJU7 G1j08/31BhWrQrFmN7xZxv//n7bdcVQUicAh9EsYztqA/Ko9d+L+Sl00+nU0i35RerSC jsxw==
X-Gm-Message-State: AD7BkJLzH/GtftxAoILn+QTdLfU4oaacZYekLpeXyEF4D8VPVX+dFe+G87n3Y21Fctjq0pXY41QIXWvEJd6jkQewIeDSPdkqWDpyjBC99fGzqiflf1eKTCxGFe0IgusRqIWBHZEFj2haYYPl
X-Received: by 10.129.70.70 with SMTP id t67mr10809960ywa.6.1460381150759; Mon, 11 Apr 2016 06:25:50 -0700 (PDT)
X-Received: by 10.129.70.70 with SMTP id t67mr10809952ywa.6.1460381150510; Mon, 11 Apr 2016 06:25:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.106.132 with HTTP; Mon, 11 Apr 2016 06:25:30 -0700 (PDT)
From: Adam Lewis 
Date: Mon, 11 Apr 2016 08:25:30 -0500
Message-ID: 
To: OAuth WG 
Content-Type: multipart/alternative; boundary=001a114d71ceb6914d0530357b9e
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603180000 definitions=main-1604110197
Archived-At: 
Subject: [OAUTH-WG] Question on draft-ietf-oauth-token-exchange-04
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Apr 2016 13:25:55 -0000

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

Hi,

There are multiple places in draft-ietf-oauth-token-exchange-04 where a
differentiation seems to be drawn between 'access_token' and 'jwt' ... for
example in section 2.2.1. when discussing the issued_token_type, it states:

      a value of "urn:ietf:params:oauth:token-type:access_token" indicates

      that the issued token is an access token and a value of
      "urn:ietf:params:oauth:token-type:jwt" indicates that it is a JWT.


This is confusing to me because an access token represents a delegated
authorization decision, whereas JWT is a token *format*.  An access
token could easily be a JWT (and in many deployments, they are).


So why the desire to differentiate, and what does the differentiation mean?



tx!
adam

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


Hi,

There are multiple places in=C2=A0d=
raft-ietf-oauth-token-exchange-04 where a differentiation seems to be drawn=
 between 'access_token' and 'jwt' ... for example in sectio=
n 2.2.1. when discussing the issued_token_type, it states:

      a value of "urn:ietf:params:oauth:=
token-type:access_token" indicates=C2=A0
   =
   that the issued token is an access token and a value of
      "urn:ietf:params:oauth:token-type:jwt" indicates that it is=
 a JWT.

This is confusing to me because an access token repres=
ents a delegated authorization=C2=A0decision, whereas JWT is a token *forma=
t*.=C2=A0 An access token could easily be a JWT (and in many deployments, t=
hey are). =C2=A0

So why the desire to differentiate, and what does the differentiation m=
ean?


tx!
adam


--001a114d71ceb6914d0530357b9e--


From flint@rocketdesk.com  Sat Apr  9 16:34:01 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C3412D0F8 for ; Sat,  9 Apr 2016 16:34:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorg856253.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfETDbUa69xu for ; Sat,  9 Apr 2016 16:33:59 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0758.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::758]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 190B112D0E0 for ; Sat,  9 Apr 2016 16:33:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORG856253.onmicrosoft.com; s=selector1-rocketdesk-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jxJRO1sQL8AnyuAshuOkyeMF3dz2mR6PoJTzKeENpZs=; b=Q9QVMe/wwcCwYv/XQGoBNbzVf0ehljxdnYzTfbE9RtyLnQZVQMzcDmlgGth6nMyxxDUwBWw/wl8PGdGkvNik0jDrrwPMvtfAEclXj9xcoTrUTPMxUgW5ww8VmFmHdPMCjo1FwAUq/5hLAILdf24Thr3kUOSoq4hNZumWlrMBE1g=
Received: from CY1PR19MB0426.namprd19.prod.outlook.com (10.164.0.144) by CY1PR19MB0428.namprd19.prod.outlook.com (10.164.0.146) with Microsoft SMTP Server (TLS) id 15.1.453.26; Sat, 9 Apr 2016 23:33:41 +0000
Received: from CY1PR19MB0426.namprd19.prod.outlook.com ([10.164.0.144]) by CY1PR19MB0426.namprd19.prod.outlook.com ([10.164.0.144]) with mapi id 15.01.0453.028; Sat, 9 Apr 2016 23:33:40 +0000
From: "Flint (RocketDesk)" 
To: "oauth@ietf.org" 
Thread-Topic: Concerns and suggestions for RFC 7592 (OAuth 2.0 Dynamic Client Registration Management Protocol)
Thread-Index: AdGSs/y2eRKXN3kAQqaZQg4F+eA7EQ==
Date: Sat, 9 Apr 2016 23:33:40 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=rocketdesk.com;
x-originating-ip: [96.2.12.36]
x-ms-office365-filtering-correlation-id: 7f76d532-089f-42c2-f719-08d360cf6201
x-microsoft-exchange-diagnostics: 1; CY1PR19MB0428; 5:SKdPRyoTNztdQdoeGMHX9JmWOaHJhjJXMPeg3BPySWIynCz1FfyiNHKozBb6MVB598dbmt23uqymyWBxDYiT2sCn+oLBejp3DpamiaZsteTOTSKgmdoWWYcvYw0XjzfKN4he7LlIlxUhBobxiijzpA==; 24:23yMWQj6tzy7WpjY596DHtfxUHEv969eQTZ0sTjbH+DA8mpOndLEdKexud0oynefcllgh5+dsvZDqqUABVggtkUxyCo6aNQ9yyKwUqBxwdE=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR19MB0428;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040074)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041046)(6043046); SRVR:CY1PR19MB0428; BCL:0; PCL:0; RULEID:; SRVR:CY1PR19MB0428; 
x-forefront-prvs: 0907F58A24
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(110136002)(107886002)(189998001)(19580395003)(5640700001)(5008740100001)(16236675004)(3660700001)(5630700001)(81166005)(3280700002)(5003600100002)(5004730100002)(2906002)(33656002)(86362001)(229853001)(122556002)(2501003)(19625215002)(10400500002)(1730700002)(1220700001)(1096002)(5002640100001)(19300405004)(6116002)(102836003)(76576001)(99286002)(2351001)(3846002)(790700001)(92566002)(9686002)(77096005)(54356999)(66066001)(87936001)(15975445007)(450100001)(586003)(50986999)(551544002)(74316001)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR19MB0428; H:CY1PR19MB0426.namprd19.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR19MB04263195FE768AAF81B56833D1920CY1PR19MB0426namp_"
MIME-Version: 1.0
X-OriginatorOrg: rocketdesk.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2016 23:33:40.5977 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c36fbab-45d1-4508-9787-a5f969b62581
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR19MB0428
Archived-At: 
X-Mailman-Approved-At: Mon, 11 Apr 2016 06:26:57 -0700
Subject: [OAUTH-WG] Concerns and suggestions for RFC 7592 (OAuth 2.0 Dynamic Client Registration Management Protocol)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 09 Apr 2016 23:34:42 -0000

--_000_CY1PR19MB04263195FE768AAF81B56833D1920CY1PR19MB0426namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

We are implementing the experimental RFC 7592 in our distributed ASP.NET Co=
re OAuth2 farm.  Based on our experience to date, we have a few concerns an=
d suggestions to add to the conversation.  Hopefully these are helpful.

[P.S. Generally the RFC is strong.  Kudos to the RFC 7592 authors.]


1. Storage of Client Secrets

The concern
RFC 7592 requires that servers store client secrets; for most scenarios thi=
s requires that the secrets are effectively stored in plain-text.

For clients using the Authorization Code or Resource Owner Password Credent=
ials grants, this is unfortunate but possibly workable-because the effects =
of client id + client secret compromise are somewhat minimal--and also beca=
use all client ids can be quickly revoked after an OAuth2 server is known t=
o be compromised.

Unfortunately, for many high-trust server-to-server APIs which use the Clie=
nt Credentials grant, compromised client secrets can be catastrophic (simil=
ar to a super-powerful password being leaked).

Furthermore, there is almost always a gap in time between which a server is=
 compromised and detection of the compromise.  With the client secrets expo=
sed as plain text, severe damage can be done rapidly to servers, users and =
data before detection.

Suggestions
1. OAuth2 servers should allowed (or encouraged) to storage client secrets =
as hashed values.  With sufficiently-long crypto-randomly-generated client_=
secrets, an SHA256 hash should provide strong protection without a requirem=
ent for salt.
2. In the Client Read Request, the server should be allowed to return "clie=
nt_secret_suppressed: true" or something similar in the response as a subst=
itute for "client_secret: value".


2. Non-idempotent nature of Client Read Request

The concern
RFC 7592 permits the server to change the client secret and registration ac=
cess token when responding to the Client Read Request.

This makes the GET call non-indempotent and can cause serious issues for cl=
ients, particularly clients which are statically configured such as those u=
sing the Client Credentials grant type.  An interrupted or duplicate GET re=
quest can quickly result in a client which is unable to further modify or d=
elete its registration.

Of course, non-idempotent GET requests are generally discouraged in REST-li=
ke architectures for this sort of reason.

Suggestion
If refresh of the client secret or registration access token is required fo=
r an implementer, a POST call with REFRESH action might be a more reliable =
way to implement this mechanism, similar to the OAuth2 refresh token flow. =
 The older client secret and/or registration token could live for a short p=
eriod of time (perhaps a few minutes) after the new credentials were issued=
 or until the new credentials were used, as a safety mechanism, if desired.


3. Scenarios where registration access tokens are revoked because of action=
s by third parties

The concern
RFC 7592 recommends that registration access tokens be revoked when request=
ing read access to a non-existent client registration.

Given a sufficiently-long token with sufficient entropy, it is mathematical=
ly unlikely that an attacker would use valid tokens to try to get access to=
 invalid client registrations.  But given enough time, an attacker could ef=
fectively destroy the ability for the not-at-fault client to modify or dele=
te its own registration.

Additionally, if an attacker has the registration access token for a valid =
client and tries to use it to get access to another client, would another (=
or a more) appropriate action be to revoke the client_id belonging to the r=
egistration access token as well?

Suggestion
This is a hard scenario to address, and is simply mentioned to spur further=
 discussion.


--_000_CY1PR19MB04263195FE768AAF81B56833D1920CY1PR19MB0426namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











We are implementing the experimental RFC 7592 in our=
 distributed ASP.NET Core OAuth2 farm.  Based on our experience to dat=
e, we have a few concerns and suggestions to add to the conversation. =
 Hopefully these are helpful.


 


[P.S. Generally the RFC is strong.  Kudos to th=
e RFC 7592 authors.]


 


 


1. Storage of Client Secrets


 


The concern


RFC 7592 requires that servers store client s=
ecrets; for most scenarios this requires that the secrets are effectively s=
tored in plain-text.


 


For clients using the Authorization Code or Resource=
 Owner Password Credentials grants, this is unfortunate but possibly workab=
le—because the effects of client id + client secret compromise ar=
e somewhat minimal--and also because all client
 ids can be quickly revoked after an OAuth2 server is known to be compromis=
ed.


 


Unfortunately, for many high-trust server-to-server =
APIs which use the Client Credentials grant, compromised client secrets can=
 be catastrophic (similar to a super-powerful password being leaked).<=
/o:p>


 


Furthermore, there is almost always a gap in time be=
tween which a server is compromised and detection of the compromise.  =
With the client secrets exposed as plain text, severe damage can be done ra=
pidly to servers, users and data before
 detection.


 


Suggestions


1. OAuth2 servers should allowed (or encouraged) to =
storage client secrets as hashed values.  With sufficiently-long crypt=
o-randomly-generated client_secrets, an SHA256 hash should provide strong p=
rotection without a requirement for salt.


2. In the Client Read Request, the server should be =
allowed to return “client_secret_suppressed: true” or something=
 similar in the response as a substitute for “client_secret: value=
221;.


 


 


2. Non-idempotent nature of Client Read Request


 


The concern


RFC 7592 permits the server to change the client sec=
ret and registration access token when responding to the Client Read Reques=
t.


 


This makes the GET call non-indempotent and can caus=
e serious issues for clients, particularly clients which are statically con=
figured such as those using the Client Credentials grant type.  An int=
errupted or duplicate GET request can quickly
 result in a client which is unable to further modify or delete its registr=
ation.


 


Of course, non-idempotent GET requests are generally=
 discouraged in REST-like architectures for this sort of reason.=



 


Suggestion


If refresh of the client secret or registration acce=
ss token is required for an implementer, a POST call with REFRESH action mi=
ght be a more reliable way to implement this mechanism, similar to the OAut=
h2 refresh token flow.  The older
 client secret and/or registration token could live for a short period of t=
ime (perhaps a few minutes) after the new credentials were issued or until =
the new credentials were used, as a safety mechanism, if desired.


 


 


3. Scenarios where registration access tokens are=
 revoked because of actions by third parties


 


The concern


RFC 7592 recommends that registration access tokens =
be revoked when requesting read access to a non-existent client registratio=
n.


 


Given a sufficiently-long token with sufficient entr=
opy, it is mathematically unlikely that an attacker would use valid tokens =
to try to get access to invalid client registrations.  But given enoug=
h time, an attacker could effectively destroy
 the ability for the not-at-fault client to modify or delete its own regist=
ration.


 


Additionally, if an attacker has the registration ac=
cess token for a valid client and tries to use it to get access to another =
client, would another (or a more) appropriate action be to revoke the clien=
t_id belonging to the registration
 access token as well?


 


Suggestion


This is a hard scenario to address, and is simply me=
ntioned to spur further discussion.


 






--_000_CY1PR19MB04263195FE768AAF81B56833D1920CY1PR19MB0426namp_--


From nobody Mon Apr 11 10:33:29 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF21212F254 for ; Mon, 11 Apr 2016 10:33:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.198
X-Spam-Level: 
X-Spam-Status: No, score=-5.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuLbX_UjALSE for ; Mon, 11 Apr 2016 10:33:26 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A836012F253 for ; Mon, 11 Apr 2016 10:33:26 -0700 (PDT)
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 u3BHXPOd022822 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 11 Apr 2016 17:33:25 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 u3BHXPnM002749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 11 Apr 2016 17:33:25 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u3BHXOOe016838 for ; Mon, 11 Apr 2016 17:33:25 GMT
Received: from [172.31.233.54] (/216.9.110.9) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 11 Apr 2016 10:33:24 -0700
From: "Phil Hunt (IDM)" 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Message-Id: <2D15E964-8A56-417C-A3CB-78CFAB5DFA34@oracle.com>
Date: Mon, 11 Apr 2016 10:33:24 -0700
To: oauth@ietf.org
X-Mailer: iPhone Mail (13E238)
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: 
Subject: [OAUTH-WG] Regarding using resource indicator to solve resource config issue
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Apr 2016 17:33:28 -0000

I am finding I am not happy with solving the bad resource endpoint config is=
sue with resource indicator. At best I see this as a special use draft for t=
hings like collab services or things which aren't resource owner centric.=20=


Yet resource endpoint config is a concern for all clients that configure on t=
he fly. Is it reasonable to make resource indicator mandatory for all client=
s? Probably not.=20

As OAuth depends primarily on TLS, it feels wrong not to have a solution tha=
t confirms the server host names are correct either via config lookup or som=
e other mechanism.=20

Tokbind is also a solution but I suspect it may only appeal to large scale s=
ervice providers and may be further off as we wait for load balancers to sup=
port tokbind. Also there are issues with tokbind on initial user binding whe=
re the mitm attack might itself establish its own token binding. I have to t=
hink this through some to confirm. But the issue of worry is what is happeni=
ng on initialization and first use if the hacker has already interceded a mi=
tm. That would make validation at config time still critical.=20

Hopefully somebody can arrive at an alternative for broader oauth use cases.=
=20

Phil=


From nobody Mon Apr 11 12:12:32 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5311D12F367 for ; Mon, 11 Apr 2016 12:12:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.597
X-Spam-Level: 
X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lv-eOICeEsTm for ; Mon, 11 Apr 2016 12:12:29 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EDCD12E6B9 for ; Mon, 11 Apr 2016 12:12:29 -0700 (PDT)
Received: from [192.168.10.140] ([80.92.115.95]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LjaEi-1bMZAd0cjA-00bZ6e; Mon, 11 Apr 2016 21:12:23 +0200
To: Antonio Sanso , "" 
References: <33F1FAA0-4F0D-455B-8D90-F451346C9BED@adobe.com>
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <570BF715.5060503@gmx.net>
Date: Mon, 11 Apr 2016 21:12:21 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <33F1FAA0-4F0D-455B-8D90-F451346C9BED@adobe.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TICqU0IPo0f7UVhChspTHG49d3QDsKMw0"
X-Provags-ID: V03:K0:StKAm/0OXDeZFAWibWFp7iOFex4cOJlhAPqY7gRaOcRMLxtb0BT EkrDUXnL796sHok4/9paItKCiTBG81OlvfmFyIDSYfQi5b6a0toLZIVkGp5eze/bizlMvdN UDPHu4V1YTySjchzHYGc0x4ZnBZKLMlnR+h1jiKZ/yb/qQ7ACu9ydnrUY9vkb2otIYWcnPG hP89jFCc8BJyPtDUaPxUQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:ilJ6ltJ/wN8=:HADpqOtyPeiAZ5/n/TU90d axtX/bvl0CnpCGKbhxSU7dV+wPbc9rs4MPLkSKTzbK7p8IvoYR23lvx8uRqR+yc9+zGgseMA/ BlG+XDkzuT15pZP4Sdbswb+kFRwwWFtSOP2kz3xwwTu/3Jqp07Q6PstxKKjoN2WFe55cKWGwJ xsszlyeZJIXLEck2YCv4VL/h/OlhGG9ERb3P0e5D42emUh0Uxkayd8xXQE9q5d+atR4E3wzdG 7kyVRogynf5BxysbFkoMexSASrQ+WlXWi0GAw+8YAbbnszEIsEwVaZ7WKhdjUMZzKi9shE883 lzmySvmgrCxZ475WpX/3rapfVWeYulJzCk/fb0AF7p+q87Lbcon2eR9MS4sbTeg0bg33mnGBJ xui7jF8Fx6KMFdl390eo5beRq0p9itIYB5a0HV09sFAqUL6uvWZbK+g2GhWuSP8sADoLivgd1 NgnUjd0PwnG5HUenHt1Fu5hIvre+FyQboTsor+AK0o+VPVrjrQ/dEOfgVwZvmCuv3+2nrQEO8 3UbrZsANp+FuigUM7marjxPbFSLhHyd5BrZ8inM21S/UOPkSRie/m53qv9F2lXYVr6OuCXTDP mAhwJFVcm0xey3iUpGKdg98EtbBSeylUaUkSxwkStZXUzYysaoOVtHxZtSD/+wlAWArnl/tX5 Nc4fjjCFlrXW38wwJqvETMtf69nilZORJnSuD6hIm3ToBndWYeGPK6OiccgqJrK+lWAzaKiOn 87z7TlR0KtCDLqiJ3glcoCsyTldwQMkgLS8ccc+8ogsp77FkdNVOG5kiovA=
Archived-At: 
Subject: Re: [OAUTH-WG] Some recent FUD about OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Apr 2016 19:12:31 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--TICqU0IPo0f7UVhChspTHG49d3QDsKMw0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Antonio,

you should recommend him/her your new OAuth book! This may help to get
some of the misconceptions about OAuth clarified!

Ciao
Hannes

On 04/11/2016 09:04 AM, Antonio Sanso wrote:
> Just sharing, do not shoot the messenger :)
>=20
> http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-h=
ow-to-zero-day-attack.html
>=20
> and  companion website:
>=20
> http://no-oauth.insanecoding.org/
>=20
> regards
>=20
> antonio
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20


--TICqU0IPo0f7UVhChspTHG49d3QDsKMw0
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

iQEcBAEBCgAGBQJXC/cVAAoJEGhJURNOOiAtb68H/Roz6x2MTH/KLZY9k/FO9x49
P0Vp3ZAKq+8djYxfr7keZl075wQ/si/IFm0clKNKHKT3ovFSYqrZ/2qJJsNHp4+Z
NZb51vP2L/9jNqQoJ+zRIlkNZ5p9bMjz57yzOagE/bIwowZdtKREbVamdNAinXOF
NwmWZLlZxiUm8nRAQV3CN0i+X8YHrAT+CWkAyE8ILwWX61fvrNx4EkWFAORGev64
JeobvJXgdcPjSg/xJW1LAKQznJqnIzC7tpggYS0iK6VF3lFPMzu/Yp3maHMjdA0w
65GtmXDwsBM+p0Vnt7ypZfm67DAYazfrkaE/9mR5w3yj7/mV+dLZGXDr/a1ayio=
=nFmp
-----END PGP SIGNATURE-----

--TICqU0IPo0f7UVhChspTHG49d3QDsKMw0--


From nobody Mon Apr 11 12:19:01 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAFE912F37D for ; Mon, 11 Apr 2016 12:18:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_dYB7vm-iX3 for ; Mon, 11 Apr 2016 12:18:56 -0700 (PDT)
Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001: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 CAAC412EE64 for ; Mon, 11 Apr 2016 12:18:56 -0700 (PDT)
Received: by mail-io0-x22c.google.com with SMTP id 2so222401891ioy.1 for ; Mon, 11 Apr 2016 12:18:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PgitpMw37oIKcxkozLIK9i5atOv4Uhj4JwtCEhNp4og=; b=XSBxmal+MOmTtYQrmUs92HXJwowPaS0KVWwNzzkc6ZRRflACw/8nONJJ1UR1uXiPYw spefI7N0v0si29W8Os6r38WwtcCdTtP7DgXwvkvMMpBKInvo9x6o6BZIsgzarIoNQ4RP LRuZ4bw9vJ/9oXJyONxb2SBcpcFOYsLJ7vNqA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PgitpMw37oIKcxkozLIK9i5atOv4Uhj4JwtCEhNp4og=; b=fOQLpT8x7lskGV5k4kGsnORdr0N4ruZFwkIgkQxWQvvo/0NJTXDtcsXe057mxj+r/t iAjA7AaEzM51F0O8AsxfEXl74VUAVem+PWoVqJItLyRkBRNjgyJW/dtfc7wJ8E6G3Qpt tBU6Esrmfq88VrOeIXpt2ZtcYlAfnNIf5PtVZTB7o1em1yelwxMa4TDKFk8Bqc2wFfp/ /BRv/BWjwKOXBMnVAL0gtj1fDMemC/TBop5hVJ1yIfBmD3GtG07xqPL34uUOBq8NlmdL 9L6ooqzS86kWko0rqoSs+tBHyzmKfisJp3Z5AHyRla26/izUe97hIPNjEiQPoBw+3wAA 4hLA==
X-Gm-Message-State: AD7BkJJyjaRUA6EO4Spsb+ZKXljt5QDe8xLhT+YVwAl2QPeLVPzrv3W23N66aijAbriMDtH3JBJGue7fftzyhvLh
X-Received: by 10.107.10.144 with SMTP id 16mr27512493iok.48.1460402336056; Mon, 11 Apr 2016 12:18:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.74.162 with HTTP; Mon, 11 Apr 2016 12:18:26 -0700 (PDT)
In-Reply-To: <2D15E964-8A56-417C-A3CB-78CFAB5DFA34@oracle.com>
References: <2D15E964-8A56-417C-A3CB-78CFAB5DFA34@oracle.com>
From: Brian Campbell 
Date: Mon, 11 Apr 2016 13:18:26 -0600
Message-ID: 
To: "Phil Hunt (IDM)" 
Content-Type: multipart/alternative; boundary=001a113f940e78892605303a6a21
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Regarding using resource indicator to solve resource config issue
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Apr 2016 19:18:59 -0000

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

I'm not sure where the idea that it's only applicable to special uses like
collaboration services is coming from. The pattern described in the draft
(using a different parameter name but otherwise the same) is deployed and
in-use for normal OAuth cases including and especially the resource owner
centric ones.


On Mon, Apr 11, 2016 at 11:33 AM, Phil Hunt (IDM) 
wrote:

> I am finding I am not happy with solving the bad resource endpoint config
> issue with resource indicator. At best I see this as a special use draft
> for things like collab services or things which aren't resource owner
> centric.
>
> Yet resource endpoint config is a concern for all clients that configure
> on the fly. Is it reasonable to make resource indicator mandatory for all
> clients? Probably not.
>
> As OAuth depends primarily on TLS, it feels wrong not to have a solution
> that confirms the server host names are correct either via config lookup or
> some other mechanism.
>
> Tokbind is also a solution but I suspect it may only appeal to large scale
> service providers and may be further off as we wait for load balancers to
> support tokbind. Also there are issues with tokbind on initial user binding
> where the mitm attack might itself establish its own token binding. I have
> to think this through some to confirm. But the issue of worry is what is
> happening on initialization and first use if the hacker has already
> interceded a mitm. That would make validation at config time still critical.
>
> Hopefully somebody can arrive at an alternative for broader oauth use
> cases.
>
> Phil
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


I'm not sure where the idea that it's only applica=
ble to special uses like collaboration services is coming from. The pattern=
 described in the draft (using a different parameter name but otherwise the=
 same) is deployed and in-use for normal OAuth cases including and especial=
ly the resource owner centric ones. 

 

On Mon, Apr 11, 2016 at 11:33 AM, Phil Hu=
nt (IDM) <phil.hunt@oracle.com> wrote:
I am finding I am not happy with solving the bad resource e=
ndpoint config issue with resource indicator. At best I see this as a speci=
al use draft for things like collab services or things which aren't res=
ource owner centric.



Yet resource endpoint config is a concern for all clients that configure on=
 the fly. Is it reasonable to make resource indicator mandatory for all cli=
ents? Probably not.



As OAuth depends primarily on TLS, it feels wrong not to have a solution th=
at confirms the server host names are correct either via config lookup or s=
ome other mechanism.



Tokbind is also a solution but I suspect it may only appeal to large scale =
service providers and may be further off as we wait for load balancers to s=
upport tokbind. Also there are issues with tokbind on initial user binding =
where the mitm attack might itself establish its own token binding. I have =
to think this through some to confirm. But the issue of worry is what is ha=
ppening on initialization and first use if the hacker has already intercede=
d a mitm. That would make validation at config time still critical.



Hopefully somebody can arrive at an alternative for broader oauth use cases=
.



Phil

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





--001a113f940e78892605303a6a21--


From nobody Mon Apr 11 12:30:45 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E7C12E1FD for ; Mon, 11 Apr 2016 12:30:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkW13E-637JF for ; Mon, 11 Apr 2016 12:30:41 -0700 (PDT)
Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AEDC12D683 for ; Mon, 11 Apr 2016 12:30:41 -0700 (PDT)
Received: by mail-io0-x235.google.com with SMTP id 2so222829083ioy.1 for ; Mon, 11 Apr 2016 12:30:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QdrgO63LWIaQMLnBZGCAnZZJTMkskUx5ASRJeToNTrU=; b=kml5BsN7EGz0OLZxI4Y5Ognu3gqLd0uEGJ+BOm7eYffMGozf52VlsHc0kBa0EPKmVX JrjCcvBR7AxgrV1PsO68wDTJDlaUm+aypaFF9oI4YOh8cM4T0SxdZrknNWt60jJoJCr9 KmlU7HslCnKhvA9vCyJ0BOPJ5W0IbAQENA66s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QdrgO63LWIaQMLnBZGCAnZZJTMkskUx5ASRJeToNTrU=; b=YRYNNE5eJtcy2hchW0K2z2QWTdPl8iTS9bVXO9Yzk1tK29fcCyGBCAMhoteAJpldoS mCsoyxS3A/+rZbsWmRQveO0KLWOY9DLKaHbCP3QAIC8Jy+mpTEvCglHMVgn1g4OeUu0m t7TzBlXPihbd2DWhU476/kWY+6WzIHd1vBKW9sIlxPYIPB0W9qTmJ4PO4qbsZN1w+ZhC weoRoL7pdJbSV8qpgc4R1x/ZoANCXENCYOPBHIctUvIfuND5vKdtGchmLaKmatetv/6f EEBWgF13xrnxoKoIpVSuRa5G5USCpIatx02+NhGZQjH62kWVceZJRqqTyivjmBHXbmXr lG4A==
X-Gm-Message-State: AD7BkJK+d4c3Q3lxytvnAgIbpEZrXDW2Jli7Ker777TDsgkI2P4MgcLeQxFpESdv5nBIByO0Mw9HQjCRSxmnIj/K
X-Received: by 10.107.162.7 with SMTP id l7mr28755332ioe.147.1460403040626; Mon, 11 Apr 2016 12:30:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.74.162 with HTTP; Mon, 11 Apr 2016 12:30:10 -0700 (PDT)
In-Reply-To: 
References: <570546A1.8040509@gmx.net> <5AEB6A4A-A325-4069-930F-D034D81E41E5@mit.edu>  
From: Brian Campbell 
Date: Mon, 11 Apr 2016 13:30:10 -0600
Message-ID: 
To: Nat Sakimura 
Content-Type: multipart/alternative; boundary=001a1140e638775c3305303a949e
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Apr 2016 19:30:44 -0000

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

Sending a token type is not sufficient. There's more involved than the
format. Many cases need to know if to encrypt and whom to encrypt to.  What
claims to put in the token (or reference by the token). What algorithms and
keys to use for signing/encryption.

The statement that the "Current proposal does not support the implicit
flow" is incorrect. Among other things, sec 2 has, "When an access token
will be returned from the authorization endpoint, the "resource" parameter
is used in the authorization request to the authorization endpoint as
defined in Section 4.2.1 of OAuth 2.0 [RFC6749]."

On Sun, Apr 10, 2016 at 11:43 AM, Nat Sakimura  wrote:

> So, my understanding on the rationale/requirements for having this spec
> right now is:
>
> R1. Authz server wants toprevent the replay by the server that received
> it.
> R2. Authz server needs to mint the access token in a variety of format
> depending on the resource server and to do that, you need to know which R=
S
> is gong to be receiving it.
>
> To achieve R1, there are couple of methods. The proposed method here is t=
o
> audience restrict the token, but the same can be achieved by sender
> constraining the token, e.g., by token binding. As far as I can see, the
> sentiment of the WG seems to be to use the sender constraint through Toke=
n
> Binding, so from this respect, this spec is not the one to do R1. Besides=
,
> the current proposal only takes care of the code flow. The same requireme=
nt
> should be there for implicit flow as well, so the current proposal is not
> covering the R1 anyways.
>
> I can sort of understand R2, but I have two critique on the current
> proposal:
>
> C1. Current proposal does not support the implicit flow. To support it,
> the resource URI has to be sent to the Authz endpoint instead of the Toke=
n
> endpoint.
> C2. It is much more direct to send the required token format rather than
> the RS uri and probably better as:
>   1) There are use cases where the AS does not maintain the list of RSs
> that it supports, e.g., AOL.
>        In such a case, even if the RS uri were sent to the AS, the AS
> cannot mint the tokens in the appropriate format.
>   2) When it is sent in the Authz request, it is leaking the information
> about the resource that the client is going to the browser.
>   3) There are use cases where it is desirable not to let the AS knows
> where the Client is going from the privacy point of view.
>
> So, my suggestion is to drop R1 and concentrate on R2. And to solve R2,
> send token type instead of the resource indicator in the request.
> This also necessitates the Client to be able to find out what token type
> the resource requires, perhaps in the unauthorized response web link head=
er
> at the resource in the manner of oauth-meta.
>
> Cheers,
>
> Nat
>
>
>
> 2016=E5=B9=B44=E6=9C=888=E6=97=A5(=E9=87=91) 8:23 Prateek Mishra :
>
>> While this work addresses a gap in the existing OAuth specification set,
>> I am very concerned that this
>> incremental extension will lead to even more confusion around the areas
>> of =E2=80=9Cscope=E2=80=9D, =E2=80=9Caudience=E2=80=9D and =E2=80=9Creso=
urce server=E2=80=9D.
>>
>> I think we should try to solve this problem via  a framework that
>> provides better guidance and implementation
>> models for OAuth use-cases. In other words, I feel that a broader
>> discussion is needed here.
>>
>>
>> > On Apr 7, 2016, at 4:11 PM, Justin Richer  wrote:
>> >
>> > I support adoption of this document as a starting point for working
>> group work.
>> >
>> > =E2=80=94 Justin
>> >
>> >
>> >> On Apr 6, 2016, at 1:25 PM, Hannes Tschofenig <
>> hannes.tschofenig@gmx.net> wrote:
>> >>
>> >> Hi all,
>> >>
>> >> this is the call for adoption of 'Resource Indicators for OAuth 2.0',
>> see
>> >>
>> http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators=
/
>> >>
>> >> Please let us know by April 20th 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 Bueno=
s
>> >> Aires then you don't need to re-state your opinion, if you want.
>> >>
>> >> The feedback at the BA IETF meeting was the following: ~10 persons
>> >> for accepting the document and 0 persons against.
>> >>
>> >> 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
>
>

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


Sending a token type is not sufficient. There's more i=
nvolved than the format. Many cases need to know if to encrypt and whom to =
encrypt to.=C2=A0 What claims to put in the token (or reference by the toke=
n). What algorithms and keys to use for signing/encryption. =C2=A0 

The statement that the "Current proposal does not =
support the implicit flow" is incorrect. Among other things, sec 2 has=
, "When an access token will be returned from the authorization endpoi=
nt, the "resource" parameter is used in the authorization request=
 to the authorization endpoint as defined in Section 4.2.1 of OAuth 2.0 [RF=
C6749]."
<=
br>
On Sun, Apr 10, 2016 at 11:43 AM, Nat Sakimur=
a <sakimura@gmail.com> wrote:
So, my understanding on the rationale/requirements fo=
r having this spec right now is:=C2=A0

R1. Authz server =
wants toprevent the replay by the server that received it.=C2=A0
=
R2. Authz server needs to mint the access token in a variety of format depe=
nding on the resource server and to do that, you need to know which RS is g=
ong to be receiving it.=C2=A0

To achieve R1, there=
 are couple of methods. The proposed method here is to audience restrict th=
e token, but the same can be achieved by sender constraining the token, e.g=
., by token binding. As far as I can see, the sentiment of the WG seems to =
be to use the sender constraint through Token Binding, so from this respect=
, this spec is not the one to do R1. Besides, the current proposal only tak=
es care of the code flow. The same requirement should be there for implicit=
 flow as well, so the current proposal is not covering the R1 anyways.=C2=
=A0

I can sort of understand R2, but I have two cr=
itique on the current proposal:=C2=A0

C1. Current =
proposal does not support the implicit flow. To support it, the resource UR=
I has to be sent to the Authz endpoint instead of the Token endpoint.=C2=A0=

C2. It is much more direct to send the required token format rat=
her than the RS uri and probably better as:=C2=A0
=C2=A0 1) There=
 are use cases where the AS does not maintain the list of RSs that it suppo=
rts, e.g., AOL.=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0In such a case, =
even if the RS uri were sent to the AS, the AS cannot mint the tokens in th=
e appropriate format.=C2=A0
=C2=A0 2) When it is sent in the Auth=
z request, it is leaking the information about the resource that the client=
 is going to the browser.=C2=A0
=C2=A0 3) There are use cases whe=
re it is desirable not to let the AS knows where the Client is going from t=
he privacy point of view.=C2=A0

So, my suggestion =
is to drop R1 and concentrate on R2. And to solve R2, send token type inste=
ad of the resource indicator in the request.=C2=A0
This also nece=
ssitates the Client to be able to find out what token type the resource req=
uires, perhaps in the unauthorized response web link header at the resource=
 in the manner of oauth-meta.=C2=A0

Cheers,=C2=A0<=
/div>

Nat



<=
div class=3D"gmail_quote">
2016=E5=B9=B44=E6=9C=888=E6=97=
=A5(=E9=87=91) 8:23 Prateek Mishra <Prateek.Mishra@oracle.com>:
While this work addresses=
 a gap in the existing OAuth specification set, I am very concerned that th=
is

incremental extension will lead to even more confusion around the areas of =
=E2=80=9Cscope=E2=80=9D, =E2=80=9Caudience=E2=80=9D and =E2=80=9Cresource s=
erver=E2=80=9D.



I think we should try to solve this problem via=C2=A0 a framework that prov=
ides better guidance and implementation

models for OAuth use-cases. In other words, I feel that a broader discussio=
n is needed here.





> On Apr 7, 2016, at 4:11 PM, Justin Richer <jricher@mit.edu> wrote:

>

> I support adoption of this document as a starting point for working gr=
oup work.

>

> =E2=80=94 Justin

>

>

>> On Apr 6, 2016, at 1:25 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

>>

>> Hi all,

>>

>> this is the call for adoption of 'Resource Indicators for OAut=
h 2.0', see

>> http://datatracker=
.ietf.org/doc/draft-campbell-oauth-resource-indicators/

>>

>> Please let us know by April 20th whether you accept / object to th=
e

>> adoption of this document as a starting point for work in the OAut=
h

>> working group.

>>

>> Note: If you already stated your opinion at the IETF meeting in Bu=
enos

>> Aires then you don't need to re-state your opinion, if you wan=
t.

>>

>> The feedback at the BA IETF meeting was the following: ~10 persons=


>> for accepting the document and 0 persons against.

>>

>> Ciao

>> Hannes & Derek

>>

>> _______________________________________________

>> OAuth mailing list

>> OAuth@ietf.org=


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

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=


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



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





--001a1140e638775c3305303a949e--


From nobody Mon Apr 11 12:45:21 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45EA812D9E4 for ; Mon, 11 Apr 2016 12:45:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sW2iR8H-vOGE for ; Mon, 11 Apr 2016 12:45:16 -0700 (PDT)
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 2070C12E1D4 for ; Mon, 11 Apr 2016 12:45:16 -0700 (PDT)
Received: by mail-ig0-x22f.google.com with SMTP id f1so70283711igr.1 for ; Mon, 11 Apr 2016 12:45:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W4l4WnMyrsfuxAfwfJ09G5QgI1vvWFLeAGLOwNNQrHY=; b=Jepjbvz6TS0tyNv1hMR+Av0KKgmYRinp66S7StnplboYkKG7wYv/lv16HwDaEjJ/fU wUNi2HohFEcAbhFFvEOafZTOHSEJc4bjlOYVSqZJ7kEqodOJIUFRsK3kMoySGuijefjl 7zz51RLo+t/Hh/QW/Inheq369khhcHZOWHLi0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W4l4WnMyrsfuxAfwfJ09G5QgI1vvWFLeAGLOwNNQrHY=; b=D12D1D9LCEviUHvHYa8tIN+XQH/1bBkn9elHQVfYO2veV05drpGbt/LGpvFfZMEiJH IawqnrWGWVxlRUkmbO/2Sq5ZeZR4PsIlBnVQM8S+zG0mf8thsPCBsB4uMWNRrVjtUnjW qNXmanPMPJqvufrolN+x2pgo8cKFr9PtzrZiAACrESOc/5WgzphNSqk9Fo12cCJJlvSG HxWyBqzoNVqGfyBVHxOZRjihbRMXY8ukMyXqOcGmI+6YjTiYsUwHsXroE/3OTvzmX3Pt G6XpQtXFHw+EsEmdzgKeq9I4SbGWP0JScYYTh/EPj55jjx7YdxJYptCiBK7ahgAW64EK /S7w==
X-Gm-Message-State: AD7BkJLwcpGncYW0rXmWbfpp7uyFb46qq4gvbF+Ihkipon7dCTSjk/MvhV4lzJmOT0jDcyt1hKplE6ip1JqvGNWh
X-Received: by 10.50.221.67 with SMTP id qc3mr21287105igc.77.1460403915308; Mon, 11 Apr 2016 12:45:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.74.162 with HTTP; Mon, 11 Apr 2016 12:44:45 -0700 (PDT)
In-Reply-To: 
References: <570548D6.8010605@gmx.net>  <57055DE2.50201@aol.com>   <7A8E4B64-4741-4A54-84D6-B887690F77B5@erdtman.se>   
From: Brian Campbell 
Date: Mon, 11 Apr 2016 13:44:45 -0600
Message-ID: 
To: Mike Jones 
Content-Type: multipart/alternative; boundary=001a11343b789a047b05303ac807
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] OAuth 2.1
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Apr 2016 19:45:19 -0000

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

+1

On Thu, Apr 7, 2016 at 12:25 PM, Mike Jones 
wrote:

> Yes - an intentionally conservative, implementation- and experience-driven
> path.
>
> Revising OAuth 2.0 is a *big deal*.  We shouldn't even be talking about it
> until we've completed steps 1-5 below - *including* the "iterate" step, as
> necessary.  If we get this wrong, we'll fragment OAuth, which is a terrible
> and irresponsible outcome we should consciously avoid at all costs.
>
> In particular, we should not recharter for an OAuth 2.1 until we already
> know what will be in it and know from deployment experience that it's the
> right stuff.
>
>                                 -- Mike
>
> -----Original Message-----
> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
> Sent: Thursday, April 7, 2016 3:16 PM
> To: Mike Jones 
> Cc: Samuel Erdtman ; Anthony Nadalin <
> tonynad@microsoft.com>; oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth 2.1
>
> Hi Mike,
>
> in my opinion, you described a possible path towards 2.1. Would you agree?
>
> best regards,
> Torsten.
>
> > Am 07.04.2016 um 13:38 schrieb Mike Jones :
> >
> > I am strongly against creating a 2.1 spec until we have at least a year
> of deployment experience with the contents we're adding to 2.0, so as not
> to fragment the OAuth marketplace.
> >
> > I think we should:
> > 1.  Continue working on new security mitigations in new drafts (such
> > as mix-up-mitigation, etc.) that add features to use with 2.0 2.
> > Continue working on PoP specs (such as pop-key-distribution, etc.)
> > that add features to use with 2.0 3.  Continue working on other new
> > specs (such as discovery, resource-indicators, etc.) that add features
> > to use with 2.0 4.  Learn from deployment experience with all of them
> > 5.  Iterate if the deployment experience tells us that we need to
> >
> > Only after we believe we have all the features right and we know that
> they work together well should we consider creating a 2.1.  If we rush to a
> 2.1 and get it wrong, we'll lose developers' trust and we'll never get it
> back.
> >
> >                -- Mike
> >
> > -----Original Message-----
> > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Samuel
> > Erdtman
> > Sent: Thursday, April 7, 2016 12:48 PM
> > To: Anthony Nadalin 
> > Cc: oauth@ietf.org
> > Subject: Re: [OAUTH-WG] OAuth 2.1
> >
> > +1 on a 2.1 version
> >
> > -1 on defining scopes more precisely in 2.1
> >
> > Sent from my iPhone
> >
> >> On 7 apr. 2016, at 14:46, Anthony Nadalin 
> wrote:
> >>
> >> I don't belive that scopes should be defined more precisely as this
> opaqueness was a design feature, I'm not seeing the reason why scopes need
> to be defined, as these are application specific.
> >>
> >> -----Original Message-----
> >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten
> >> Lodderstedt
> >> Sent: Thursday, April 7, 2016 5:32 AM
> >> To: George Fletcher 
> >> Cc: oauth@ietf.org
> >> Subject: Re: [OAUTH-WG] OAuth 2.1
> >>
> >> Hi all,
> >>
> >> as I already said in the meeting: I would very much prefer to have an
> extension/update of RFC 6819 covering all "new" threats, including:
> >> - mix up
> >> - code injection aka copy and paste
> >> - open redirector at AS and client
> >> - potential other threats in the context of "dynamic" OAuth
> >>
> >> I also assume mitigations for (at least some of) the threats need to go
> into an update of RFC 6749 as normative text. To give an example: if we
> agree on using the state parameter at the token endpoint to mitigate code
> injection, this MUST be part of the core spec (request description and
> security consoderations). Otherwise, noone will even  consider it.
> >>
> >> We should also use the opportunity to improve/enhance the text of the
> spec. In the course of the last years, we have learned a lot about
> ambiquities of the text and how different implementations utilize OAuth.
> >>
> >> I think time is right to define scopes more precisely. As the
> discussions in the last days proved again (at least for me), scope is not
> sufficiently defined to come up with interoperable implementations.
> Additionally, there seems to be a need to represent resource server
> locations (to not say identities :-)) in this context.
> >>
> >> To bundle all changes in a version 2.1 would also make communication
> into the market much easier.
> >>
> >> best regards,
> >> Torsten.
> >>
> >>> Am 06.04.2016 um 16:05 schrieb George Fletcher :
> >>>
> >>> I'd definitely prefer a single solution document to many little ones
> that have to be combined to actually build a secure solution. It's already
> getting complex with the additional specs that have been added.
> >>>
> >>> Additionally, I'm not against working on OAuth 2.1.
> >>>
> >>> Thanks,
> >>> George
> >>>
> >>>> On 4/6/16 2:06 PM, Phil Hunt (IDM) wrote:
> >>>>
> >>>> Existing implementations are for the large part ok and do not need
> these mitigations.
> >>>>
> >>>> Only the new use cases we have been discussing (configure on the fly
> and multi-as, etc) really need mitigation.
> >>>>
> >>>> The updated by approach seems like a good way to address the new
> cases.
> >>>>
> >>>> Phil
> >>>>
> >>>>> On Apr 6, 2016, at 14:35, Hannes Tschofenig <
> hannes.tschofenig@gmx.net> wrote:
> >>>>>
> >>>>> Hi all,
> >>>>>
> >>>>> today we discussed the OAuth Authorization Server Mixup draft. We
> >>>>> were wondering what types of threats the document should find
> solutions for.
> >>>>>
> >>>>> We discussed various document handling approaches including
> >>>>> * OAuth Mix-Up and Cut-and-Paste attacks documented in separate
> >>>>> solution documents
> >>>>> * combined solution document covering the OAuth Mix-Up and the
> >>>>> Cut-and-Paste attacks.
> >>>>>
> >>>>> Barry pointed out that these documents could update the OAuth base
> >>>>> specification.
> >>>>>
> >>>>> As a more radical change it was also suggested to revise RFC 6749
> >>>>> "OAuth
> >>>>> 2.0 Authorization Framework" and RFC 6819 "OAuth 2.0 Threat Model
> >>>>> and Security Considerations".
> >>>>>
> >>>>> Opening up the OAuth base specification obviously raises various
> >>>>> other questions about cleaning up parts that go far beyond the AS
> >>>>> mix-up and the cut-and-paste attacks. Other specifications, such
> >>>>> as the Open Redirector, could be folded into such a new
> specification.
> >>>>>
> >>>>> Derek and I would appreciate your input on this topic before we
> >>>>> make a decision since it has significant impact on our work.
> >>>>>
> >>>>> Ciao
> >>>>> Hannes & Derek
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>> OAuth@ietf.org
> >>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fw
> >>>>> w
> >>>>> w
> >>>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40mi
> >>>>> c
> >>>>> r
> >>>>> osoft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91a
> >>>>> b
> >>>>> 2
> >>>>> d7cd011db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%
> >>>>> 3
> >>>>> d
> >>>> _______________________________________________
> >>>> OAuth mailing list
> >>>> OAuth@ietf.org
> >>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.
> >>>> ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40micr
> >>>> o
> >>>> s
> >>>> oft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d
> >>>> 7 c
> >>>> d011db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d
> >>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth@ietf.org
> >>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.
> >>> i
> >>> etf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40micros
> >>> o
> >>> f
> >>> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd
> >>> 0
> >>> 1 1db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.
> >> i
> >> etf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microso
> >> f
> >> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd0
> >> 1 1db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d
> >>
> >> _______________________________________________
> >> OAuth mailing 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
>

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


+1 

On Thu, Apr 7, 2016 at 12:25 PM, Mike Jones =
<Michae=
l.Jones@microsoft.com> wrote:
Yes - an intentionally conservative, implementation- and experience-driv=
en path.



Revising OAuth 2.0 is a *big deal*.=C2=A0 We shouldn't even be talking =
about it until we've completed steps 1-5 below - *including* the "=
iterate" step, as necessary.=C2=A0 If we get this wrong, we'll fra=
gment OAuth, which is a terrible and irresponsible outcome we should consci=
ously avoid at all costs.



In particular, we should not recharter for an OAuth 2.1 until we already kn=
ow what will be in it and know from deployment experience that it's the=
 right stuff.



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




-----Original Message-----

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]

Sent: Thursday, April 7, 2016 3:16 PM

To: Mike Jones <Michael.J=
ones@microsoft.com>

Cc: Samuel Erdtman <samuel@erdtman.=
se>; Anthony Nadalin <to=
nynad@microsoft.com>; oauth@ietf.o=
rg

Subject: Re: [OAUTH-WG] OAuth 2.1



Hi Mike,



in my opinion, you described a possible path towards 2.1. Would you agree?<=
br>


best regards,

Torsten.



> Am 07.04.2016 um 13:38 schrieb Mike Jones <Michael.Jones@microsoft.com>:

>

> I am strongly against creating a 2.1 spec until we have at least a yea=
r of deployment experience with the contents we're adding to 2.0, so as=
 not to fragment the OAuth marketplace.

>

> I think we should:

> 1.=C2=A0 Continue working on new security mitigations in new drafts (s=
uch

> as mix-up-mitigation, etc.) that add features to use with 2.0 2.

> Continue working on PoP specs (such as pop-key-distribution, etc.)

> that add features to use with 2.0 3.=C2=A0 Continue working on other n=
ew

> specs (such as discovery, resource-indicators, etc.) that add features=


> to use with 2.0 4.=C2=A0 Learn from deployment experience with all of =
them

> 5.=C2=A0 Iterate if the deployment experience tells us that we need to=


>

> Only after we believe we have all the features right and we know that =
they work together well should we consider creating a 2.1.=C2=A0 If we rush=
 to a 2.1 and get it wrong, we'll lose developers' trust and we'=
;ll never get it back.

>

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

>

> -----Original Message-----

> From: OAuth [mailto:oauth-bo=
unces@ietf.org] On Behalf Of Samuel

> Erdtman

> Sent: Thursday, April 7, 2016 12:48 PM

> To: Anthony Nadalin <tonyn=
ad@microsoft.com>

> Cc: oauth@ietf.org

> Subject: Re: [OAUTH-WG] OAuth 2.1

>

> +1 on a 2.1 version

>

> -1 on defining scopes more precisely in 2.1

>

> Sent from my iPhone

>

>> On 7 apr. 2016, at 14:46, Anthony Nadalin <tonynad@microsoft.com> wrote:

>>

>> I don't belive that scopes should be defined more precisely as=
 this opaqueness was a design feature, I'm not seeing the reason why sc=
opes need to be defined, as these are application specific.

>>

>> -----Original Message-----

>> From: OAuth [mailto:oaut=
h-bounces@ietf.org] On Behalf Of Torsten

>> Lodderstedt

>> Sent: Thursday, April 7, 2016 5:32 AM

>> To: George Fletcher <gfflet=
ch@aol.com>

>> Cc: oauth@ietf.org

>> Subject: Re: [OAUTH-WG] OAuth 2.1

>>

>> Hi all,

>>

>> as I already said in the meeting: I would very much prefer to have=
 an extension/update of RFC 6819 covering all "new" threats, incl=
uding:

>> - mix up

>> - code injection aka copy and paste

>> - open redirector at AS and client

>> - potential other threats in the context of "dynamic" OA=
uth

>>

>> I also assume mitigations for (at least some of) the threats need =
to go into an update of RFC 6749 as normative text. To give an example: if =
we agree on using the state parameter at the token endpoint to mitigate cod=
e injection, this MUST be part of the core spec (request description and se=
curity consoderations). Otherwise, noone will even=C2=A0 consider it.

>>

>> We should also use the opportunity to improve/enhance the text of =
the spec. In the course of the last years, we have learned a lot about ambi=
quities of the text and how different implementations utilize OAuth.

>>

>> I think time is right to define scopes more precisely. As the disc=
ussions in the last days proved again (at least for me), scope is not suffi=
ciently defined to come up with interoperable implementations. Additionally=
, there seems to be a need to represent resource server locations (to not s=
ay identities :-)) in this context.

>>

>> To bundle all changes in a version 2.1 would also make communicati=
on into the market much easier.

>>

>> best regards,

>> Torsten.

>>

>>> Am 06.04.2016 um 16:05 schrieb George Fletcher <gffletch@aol.com>:

>>>

>>> I'd definitely prefer a single solution document to many l=
ittle ones that have to be combined to actually build a secure solution. It=
's already getting complex with the additional specs that have been add=
ed.

>>>

>>> Additionally, I'm not against working on OAuth 2.1.

>>>

>>> Thanks,

>>> George

>>>

>>>> On 4/6/16 2:06 PM, Phil Hunt (IDM) wrote:

>>>>

>>>> Existing implementations are for the large part ok and do =
not need these mitigations.

>>>>

>>>> Only the new use cases we have been discussing (configure =
on the fly and multi-as, etc) really need mitigation.

>>>>

>>>> The updated by approach seems like a good way to address t=
he new cases.

>>>>

>>>> Phil

>>>>

>>>>> On Apr 6, 2016, at 14:35, Hannes Tschofenig <hannes.tschofenig@gmx.net> wr=
ote:

>>>>>

>>>>> Hi all,

>>>>>

>>>>> today we discussed the OAuth Authorization Server Mixu=
p draft. We

>>>>> were wondering what types of threats the document shou=
ld find solutions for.

>>>>>

>>>>> We discussed various document handling approaches incl=
uding

>>>>> * OAuth Mix-Up and Cut-and-Paste attacks documented in=
 separate

>>>>> solution documents

>>>>> * combined solution document covering the OAuth Mix-Up=
 and the

>>>>> Cut-and-Paste attacks.

>>>>>

>>>>> Barry pointed out that these documents could update th=
e OAuth base

>>>>> specification.

>>>>>

>>>>> As a more radical change it was also suggested to revi=
se RFC 6749

>>>>> "OAuth

>>>>> 2.0 Authorization Framework" and RFC 6819 "O=
Auth 2.0 Threat Model

>>>>> and Security Considerations".

>>>>>

>>>>> Opening up the OAuth base specification obviously rais=
es various

>>>>> other questions about cleaning up parts that go far be=
yond the AS

>>>>> mix-up and the cut-and-paste attacks. Other specificat=
ions, such

>>>>> as the Open Redirector, could be folded into such a ne=
w specification.

>>>>>

>>>>> Derek and I would appreciate your input on this topic =
before we

>>>>> make a decision since it has significant impact on our=
 work.

>>>>>

>>>>> Ciao

>>>>> Hannes & Derek

>>>>>

>>>>>

>>>>> _______________________________________________

>>>>> OAuth mailing list

>>>>> OAuth@ietf.org
>>>>> https://na0=
1.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fw

>>>>> w

>>>>> w

>>>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7c=
tonynad%40mi

>>>>> c

>>>>> r

>>>>> osoft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f1=
41af91a

>>>>> b

>>>>> 2

>>>>> d7cd011db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6=
qYndnkLgLa5SPk2HI%

>>>>> 3

>>>>> d

>>>> _______________________________________________

>>>> OAuth mailing list

>>>> OAuth@ietf.org

>>>> https://na01.=
safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.

>>>> ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonyn=
ad%40micr

>>>> o

>>>> s

>>>> oft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab=
2d


>>>> 7 c

>>>> d011db47%7c1&sdata=3DBqcE9eD=
hm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d

>>>

>>> _______________________________________________

>>> OAuth mailing list

>>> OAuth@ietf.org

>>> https://na01.saf=
elinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.

>>> i

>>> etf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40m=
icros

>>> o

>>> f

>>> =
t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd
>>> 0

>>> 1 1db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5S=
Pk2HI%3d

>>

>> _______________________________________________

>> OAuth mailing list

>> OAuth@ietf.org

>> https://na01.safelink=
s.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.

>> i

>> et=
f.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40micro=
so

>> f

>> t.co=
m%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd0

>> 1 1db47%7c1&sdata=3DBqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2H=
I%3d

>>

>> _______________________________________________

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

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



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





--001a11343b789a047b05303ac807--


From nobody Mon Apr 11 13:18:38 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDFE12F3C9 for ; Mon, 11 Apr 2016 13:18:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.013
X-Spam-Level: 
X-Spam-Status: No, score=-0.013 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6DW9dDbAU06 for ; Mon, 11 Apr 2016 13:18:33 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0137.outbound.protection.outlook.com [207.46.100.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4865512F3B2 for ; Mon, 11 Apr 2016 13:18:33 -0700 (PDT)
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=BC6pB4EKrzS+/oMeDmXsFOT1tEOR5EOiRMPO+Facs4U=; b=AVM2SoDrniwa/0/itbYer2CioQlVN9sPrn4e5RqzqtaGg9sxe5vO5s/rlzicteCbz5C0hkZbP/UMgv4V8oJPOI50fx3Hkq23v/TyMNLz9Aqw3SGf/rHE/bDBIODPMyatCzxGdVw+e8AGStOMjt/5XkzF3/OisMeUfmTwQ/IO9ak=
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.453.26; Mon, 11 Apr 2016 20:18:31 +0000
Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0453.029; Mon, 11 Apr 2016 20:18:31 +0000
From: Anthony Nadalin 
To: Brian Campbell , Nat Sakimura 
Thread-Topic: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0
Thread-Index: AQHRkCmB9ToVpiQsqkic7QI3EfNCup9/JV+AgAADVwCABFfWgIABsEAAgAAMjfA=
Date: Mon, 11 Apr 2016 20:18:31 +0000
Message-ID: 
References: <570546A1.8040509@gmx.net> <5AEB6A4A-A325-4069-930F-D034D81E41E5@mit.edu>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: pingidentity.com; dkim=none (message not signed) header.d=none;pingidentity.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [24.54.172.229]
x-ms-office365-filtering-correlation-id: b61421d3-00ee-4000-c2fc-08d3624673ac
x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1234; 5:k4POAT3ng4xNo1DEZY0cPqPqOcBxkdVGgoeu7QxTjT3NScP05hhSnolgkWkkzT13/F4CmnmZnTBuD1CvA1BvRthduV1iSqn3iavxB0ml+hUCO1upPNpo4sQTLMxCEp4aO5Do+olVZ6Wn/c/ud7/30g==; 24:MlYFDKrSoh9J2ZRzeKirhRXOnMFj9M4bIoyzmdhrCkbuStZwaTwEhRgRTM2ms7K4zoOVD31572K9t1e7lEBmkv2qXAd/aOGc60HOl7Au8LU=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1234;
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)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BN3PR0301MB1234; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1234; 
x-forefront-prvs: 09090B6B69
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(53754006)(377454003)(24454002)(189998001)(87936001)(97736004)(5001770100001)(102836003)(586003)(2906002)(68736007)(2950100001)(3846002)(2900100001)(76576001)(5002640100001)(5003600100002)(19617315012)(93886004)(74316001)(5008740100001)(81166005)(6116002)(77096005)(790700001)(1220700001)(1096002)(66066001)(15975445007)(9686002)(3280700002)(16236675004)(19300405004)(8990500004)(19580395003)(11100500001)(92566002)(76176999)(5004730100002)(50986999)(19609705001)(54356999)(86612001)(33656002)(122556002)(106116001)(99286002)(3660700001)(86362001)(10400500002)(561944003)(4326007)(10090500001)(10290500002)(5005710100001)(19580405001)(19625215002)(42262002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1234; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB123431087E4F35D1EAE30598A6940BN3PR0301MB1234_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2016 20:18:31.5275 (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: "" 
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Apr 2016 20:18:36 -0000

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

U28gbm93IHlvdSBhcmUgYWRkaW5nIG1vcmUgcmVxdWlyZW1lbnRzIGZvciBlbmNyeXB0aW9uID8g
VGhlIG1vcmUgdGhpcyB0aHJlYWQgZ29lcyBvbiBzaG93cyBob3cgdW5zdGFibGUgYW5kIG5vdCBm
dWxseSB0aG91Z2h0IG91dCB0aGlzIGRyYWZ0IGlzIHRvIGdvIHRocm91Z2ggV0cgYWRvcHRpb24u
DQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm
IE9mIEJyaWFuIENhbXBiZWxsDQpTZW50OiBNb25kYXksIEFwcmlsIDExLCAyMDE2IDEyOjMwIFBN
DQpUbzogTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb20+DQpDYzogPG9hdXRoQGlldGYu
b3JnPiA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBDYWxsIGZvciBB
ZG9wdGlvbjogUmVzb3VyY2UgSW5kaWNhdG9ycyBmb3IgT0F1dGggMi4wDQoNClNlbmRpbmcgYSB0
b2tlbiB0eXBlIGlzIG5vdCBzdWZmaWNpZW50LiBUaGVyZSdzIG1vcmUgaW52b2x2ZWQgdGhhbiB0
aGUgZm9ybWF0LiBNYW55IGNhc2VzIG5lZWQgdG8ga25vdyBpZiB0byBlbmNyeXB0IGFuZCB3aG9t
IHRvIGVuY3J5cHQgdG8uICBXaGF0IGNsYWltcyB0byBwdXQgaW4gdGhlIHRva2VuIChvciByZWZl
cmVuY2UgYnkgdGhlIHRva2VuKS4gV2hhdCBhbGdvcml0aG1zIGFuZCBrZXlzIHRvIHVzZSBmb3Ig
c2lnbmluZy9lbmNyeXB0aW9uLg0KDQpUaGUgc3RhdGVtZW50IHRoYXQgdGhlICJDdXJyZW50IHBy
b3Bvc2FsIGRvZXMgbm90IHN1cHBvcnQgdGhlIGltcGxpY2l0IGZsb3ciIGlzIGluY29ycmVjdC4g
QW1vbmcgb3RoZXIgdGhpbmdzLCBzZWMgMiBoYXMsICJXaGVuIGFuIGFjY2VzcyB0b2tlbiB3aWxs
IGJlIHJldHVybmVkIGZyb20gdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQsIHRoZSAicmVzb3Vy
Y2UiIHBhcmFtZXRlciBpcyB1c2VkIGluIHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QgdG8gdGhl
IGF1dGhvcml6YXRpb24gZW5kcG9pbnQgYXMgZGVmaW5lZCBpbiBTZWN0aW9uIDQuMi4xIG9mIE9B
dXRoIDIuMCBbUkZDNjc0OV0uIg0KDQpPbiBTdW4sIEFwciAxMCwgMjAxNiBhdCAxMTo0MyBBTSwg
TmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb208bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNv
bT4+IHdyb3RlOg0KU28sIG15IHVuZGVyc3RhbmRpbmcgb24gdGhlIHJhdGlvbmFsZS9yZXF1aXJl
bWVudHMgZm9yIGhhdmluZyB0aGlzIHNwZWMgcmlnaHQgbm93IGlzOg0KDQpSMS4gQXV0aHogc2Vy
dmVyIHdhbnRzIHRvcHJldmVudCB0aGUgcmVwbGF5IGJ5IHRoZSBzZXJ2ZXIgdGhhdCByZWNlaXZl
ZCBpdC4NClIyLiBBdXRoeiBzZXJ2ZXIgbmVlZHMgdG8gbWludCB0aGUgYWNjZXNzIHRva2VuIGlu
IGEgdmFyaWV0eSBvZiBmb3JtYXQgZGVwZW5kaW5nIG9uIHRoZSByZXNvdXJjZSBzZXJ2ZXIgYW5k
IHRvIGRvIHRoYXQsIHlvdSBuZWVkIHRvIGtub3cgd2hpY2ggUlMgaXMgZ29uZyB0byBiZSByZWNl
aXZpbmcgaXQuDQoNClRvIGFjaGlldmUgUjEsIHRoZXJlIGFyZSBjb3VwbGUgb2YgbWV0aG9kcy4g
VGhlIHByb3Bvc2VkIG1ldGhvZCBoZXJlIGlzIHRvIGF1ZGllbmNlIHJlc3RyaWN0IHRoZSB0b2tl
biwgYnV0IHRoZSBzYW1lIGNhbiBiZSBhY2hpZXZlZCBieSBzZW5kZXIgY29uc3RyYWluaW5nIHRo
ZSB0b2tlbiwgZS5nLiwgYnkgdG9rZW4gYmluZGluZy4gQXMgZmFyIGFzIEkgY2FuIHNlZSwgdGhl
IHNlbnRpbWVudCBvZiB0aGUgV0cgc2VlbXMgdG8gYmUgdG8gdXNlIHRoZSBzZW5kZXIgY29uc3Ry
YWludCB0aHJvdWdoIFRva2VuIEJpbmRpbmcsIHNvIGZyb20gdGhpcyByZXNwZWN0LCB0aGlzIHNw
ZWMgaXMgbm90IHRoZSBvbmUgdG8gZG8gUjEuIEJlc2lkZXMsIHRoZSBjdXJyZW50IHByb3Bvc2Fs
IG9ubHkgdGFrZXMgY2FyZSBvZiB0aGUgY29kZSBmbG93LiBUaGUgc2FtZSByZXF1aXJlbWVudCBz
aG91bGQgYmUgdGhlcmUgZm9yIGltcGxpY2l0IGZsb3cgYXMgd2VsbCwgc28gdGhlIGN1cnJlbnQg
cHJvcG9zYWwgaXMgbm90IGNvdmVyaW5nIHRoZSBSMSBhbnl3YXlzLg0KDQpJIGNhbiBzb3J0IG9m
IHVuZGVyc3RhbmQgUjIsIGJ1dCBJIGhhdmUgdHdvIGNyaXRpcXVlIG9uIHRoZSBjdXJyZW50IHBy
b3Bvc2FsOg0KDQpDMS4gQ3VycmVudCBwcm9wb3NhbCBkb2VzIG5vdCBzdXBwb3J0IHRoZSBpbXBs
aWNpdCBmbG93LiBUbyBzdXBwb3J0IGl0LCB0aGUgcmVzb3VyY2UgVVJJIGhhcyB0byBiZSBzZW50
IHRvIHRoZSBBdXRoeiBlbmRwb2ludCBpbnN0ZWFkIG9mIHRoZSBUb2tlbiBlbmRwb2ludC4NCkMy
LiBJdCBpcyBtdWNoIG1vcmUgZGlyZWN0IHRvIHNlbmQgdGhlIHJlcXVpcmVkIHRva2VuIGZvcm1h
dCByYXRoZXIgdGhhbiB0aGUgUlMgdXJpIGFuZCBwcm9iYWJseSBiZXR0ZXIgYXM6DQogIDEpIFRo
ZXJlIGFyZSB1c2UgY2FzZXMgd2hlcmUgdGhlIEFTIGRvZXMgbm90IG1haW50YWluIHRoZSBsaXN0
IG9mIFJTcyB0aGF0IGl0IHN1cHBvcnRzLCBlLmcuLCBBT0wuDQogICAgICAgSW4gc3VjaCBhIGNh
c2UsIGV2ZW4gaWYgdGhlIFJTIHVyaSB3ZXJlIHNlbnQgdG8gdGhlIEFTLCB0aGUgQVMgY2Fubm90
IG1pbnQgdGhlIHRva2VucyBpbiB0aGUgYXBwcm9wcmlhdGUgZm9ybWF0Lg0KICAyKSBXaGVuIGl0
IGlzIHNlbnQgaW4gdGhlIEF1dGh6IHJlcXVlc3QsIGl0IGlzIGxlYWtpbmcgdGhlIGluZm9ybWF0
aW9uIGFib3V0IHRoZSByZXNvdXJjZSB0aGF0IHRoZSBjbGllbnQgaXMgZ29pbmcgdG8gdGhlIGJy
b3dzZXIuDQogIDMpIFRoZXJlIGFyZSB1c2UgY2FzZXMgd2hlcmUgaXQgaXMgZGVzaXJhYmxlIG5v
dCB0byBsZXQgdGhlIEFTIGtub3dzIHdoZXJlIHRoZSBDbGllbnQgaXMgZ29pbmcgZnJvbSB0aGUg
cHJpdmFjeSBwb2ludCBvZiB2aWV3Lg0KDQpTbywgbXkgc3VnZ2VzdGlvbiBpcyB0byBkcm9wIFIx
IGFuZCBjb25jZW50cmF0ZSBvbiBSMi4gQW5kIHRvIHNvbHZlIFIyLCBzZW5kIHRva2VuIHR5cGUg
aW5zdGVhZCBvZiB0aGUgcmVzb3VyY2UgaW5kaWNhdG9yIGluIHRoZSByZXF1ZXN0Lg0KVGhpcyBh
bHNvIG5lY2Vzc2l0YXRlcyB0aGUgQ2xpZW50IHRvIGJlIGFibGUgdG8gZmluZCBvdXQgd2hhdCB0
b2tlbiB0eXBlIHRoZSByZXNvdXJjZSByZXF1aXJlcywgcGVyaGFwcyBpbiB0aGUgdW5hdXRob3Jp
emVkIHJlc3BvbnNlIHdlYiBsaW5rIGhlYWRlciBhdCB0aGUgcmVzb3VyY2UgaW4gdGhlIG1hbm5l
ciBvZiBvYXV0aC1tZXRhLg0KDQpDaGVlcnMsDQoNCk5hdA0KDQoNCg0KMjAxNuW5tDTmnIg45pel
KOmHkSkgODoyMyBQcmF0ZWVrIE1pc2hyYSA8UHJhdGVlay5NaXNocmFAb3JhY2xlLmNvbTxtYWls
dG86UHJhdGVlay5NaXNocmFAb3JhY2xlLmNvbT4+Og0KV2hpbGUgdGhpcyB3b3JrIGFkZHJlc3Nl
cyBhIGdhcCBpbiB0aGUgZXhpc3RpbmcgT0F1dGggc3BlY2lmaWNhdGlvbiBzZXQsIEkgYW0gdmVy
eSBjb25jZXJuZWQgdGhhdCB0aGlzDQppbmNyZW1lbnRhbCBleHRlbnNpb24gd2lsbCBsZWFkIHRv
IGV2ZW4gbW9yZSBjb25mdXNpb24gYXJvdW5kIHRoZSBhcmVhcyBvZiDigJxzY29wZeKAnSwg4oCc
YXVkaWVuY2XigJ0gYW5kIOKAnHJlc291cmNlIHNlcnZlcuKAnS4NCg0KSSB0aGluayB3ZSBzaG91
bGQgdHJ5IHRvIHNvbHZlIHRoaXMgcHJvYmxlbSB2aWEgIGEgZnJhbWV3b3JrIHRoYXQgcHJvdmlk
ZXMgYmV0dGVyIGd1aWRhbmNlIGFuZCBpbXBsZW1lbnRhdGlvbg0KbW9kZWxzIGZvciBPQXV0aCB1
c2UtY2FzZXMuIEluIG90aGVyIHdvcmRzLCBJIGZlZWwgdGhhdCBhIGJyb2FkZXIgZGlzY3Vzc2lv
biBpcyBuZWVkZWQgaGVyZS4NCg0KDQo+IE9uIEFwciA3LCAyMDE2LCBhdCA0OjExIFBNLCBKdXN0
aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+IHdyb3Rl
Og0KPg0KPiBJIHN1cHBvcnQgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCBhcyBhIHN0YXJ0aW5n
IHBvaW50IGZvciB3b3JraW5nIGdyb3VwIHdvcmsuDQo+DQo+IOKAlCBKdXN0aW4NCj4NCj4NCj4+
IE9uIEFwciA2LCAyMDE2LCBhdCAxOjI1IFBNLCBIYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRz
Y2hvZmVuaWdAZ214Lm5ldDxtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4+IHdyb3Rl
Og0KPj4NCj4+IEhpIGFsbCwNCj4+DQo+PiB0aGlzIGlzIHRoZSBjYWxsIGZvciBhZG9wdGlvbiBv
ZiAnUmVzb3VyY2UgSW5kaWNhdG9ycyBmb3IgT0F1dGggMi4wJywgc2VlDQo+PiBodHRwOi8vZGF0
YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNhbXBiZWxsLW9hdXRoLXJlc291cmNlLWluZGlj
YXRvcnMvPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJs
PWh0dHAlM2ElMmYlMmZkYXRhdHJhY2tlci5pZXRmLm9yZyUyZmRvYyUyZmRyYWZ0LWNhbXBiZWxs
LW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMlMmYmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1p
Y3Jvc29mdC5jb20lN2M5NTkwZTQwMjVlYjY0NDJlY2VkZTA4ZDM2MjNmYzk2MSU3YzcyZjk4OGJm
ODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT15ODY5Rms5OTg3ZmYwOWh2SElOJTJi
VkdsJTJmcXh3V0Rta3ZPd3pjUWNXcVhadyUzZD4NCj4+DQo+PiBQbGVhc2UgbGV0IHVzIGtub3cg
YnkgQXByaWwgMjB0aCB3aGV0aGVyIHlvdSBhY2NlcHQgLyBvYmplY3QgdG8gdGhlDQo+PiBhZG9w
dGlvbiBvZiB0aGlzIGRvY3VtZW50IGFzIGEgc3RhcnRpbmcgcG9pbnQgZm9yIHdvcmsgaW4gdGhl
IE9BdXRoDQo+PiB3b3JraW5nIGdyb3VwLg0KPj4NCj4+IE5vdGU6IElmIHlvdSBhbHJlYWR5IHN0
YXRlZCB5b3VyIG9waW5pb24gYXQgdGhlIElFVEYgbWVldGluZyBpbiBCdWVub3MNCj4+IEFpcmVz
IHRoZW4geW91IGRvbid0IG5lZWQgdG8gcmUtc3RhdGUgeW91ciBvcGluaW9uLCBpZiB5b3Ugd2Fu
dC4NCj4+DQo+PiBUaGUgZmVlZGJhY2sgYXQgdGhlIEJBIElFVEYgbWVldGluZyB3YXMgdGhlIGZv
bGxvd2luZzogfjEwIHBlcnNvbnMNCj4+IGZvciBhY2NlcHRpbmcgdGhlIGRvY3VtZW50IGFuZCAw
IHBlcnNvbnMgYWdhaW5zdC4NCj4+DQo+PiBDaWFvDQo+PiBIYW5uZXMgJiBEZXJlaw0KPj4NCj4+
IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBPQXV0
aCBtYWlsaW5nIGxpc3QNCj4+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4N
Cj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8aHR0cHM6Ly9u
YTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3
d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZkYXRhPTAxJTdjMDElN2N0
b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Yzk1OTBlNDAyNWViNjQ0MmVjZWRlMDhkMzYyM2ZjOTYx
JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPWJmcDFER0g1aiUy
YnRNNFp0eDdNJTJidWVLN0t4VjZrTkpFWFpLSEVDSVVLaUJRJTNkPg0KPg0KPiBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPQXV0aCBtYWlsaW5nIGxp
c3QNCj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPiBodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0dHBzOi8vbmEwMS5zYWZlbGlua3Mu
cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJm
bWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jv
c29mdC5jb20lN2M5NTkwZTQwMjVlYjY0NDJlY2VkZTA4ZDM2MjNmYzk2MSU3YzcyZjk4OGJmODZm
MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1iZnAxREdINWolMmJ0TTRadHg3TSUyYnVl
SzdLeFY2a05KRVhaS0hFQ0lVS2lCUSUzZD4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8
bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vYXV0aDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v
P3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9h
dXRoJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjOTU5MGU0MDI1ZWI2
NDQyZWNlZGUwOGQzNjIzZmM5NjElN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3
YzEmc2RhdGE9YmZwMURHSDVqJTJidE00WnR4N00lMmJ1ZUs3S3hWNmtOSkVYWktIRUNJVUtpQlEl
M2Q+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpP
QXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4N
Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8aHR0cHM6Ly9uYTAx
LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cu
aWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZkYXRhPTAxJTdjMDElN2N0b255
bmFkJTQwbWljcm9zb2Z0LmNvbSU3Yzk1OTBlNDAyNWViNjQ0MmVjZWRlMDhkMzYyM2ZjOTYxJTdj
NzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPWJmcDFER0g1aiUyYnRN
NFp0eDdNJTJidWVLN0t4VjZrTkpFWFpLSEVDSVVLaUJRJTNkPg0KDQo=

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA1IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdv
dGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5p
dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy
Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm
b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlw
ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj
b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk
DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0
aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3Jt
YWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h
cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO
ZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBl
cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y
OndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u
bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rp
b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp
bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+
PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz
cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4
bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg
ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N
Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh
c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi
PlNvIG5vdyB5b3UgYXJlIGFkZGluZyBtb3JlIHJlcXVpcmVtZW50cyBmb3IgZW5jcnlwdGlvbiA/
IFRoZSBtb3JlIHRoaXMgdGhyZWFkIGdvZXMgb24gc2hvd3MgaG93IHVuc3RhYmxlIGFuZCBub3Qg
ZnVsbHkgdGhvdWdodCBvdXQgdGhpcyBkcmFmdCBpcyB0byBnbyB0aHJvdWdoIFdHIGFkb3B0aW9u
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9N
YWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L2E+PC9wPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bh
bj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+
PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZiI+IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9y
Z10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QnJpYW4gQ2FtcGJlbGw8YnI+DQo8Yj5TZW50OjwvYj4g
TW9uZGF5LCBBcHJpbCAxMSwgMjAxNiAxMjozMCBQTTxicj4NCjxiPlRvOjwvYj4gTmF0IFNha2lt
dXJhICZsdDtzYWtpbXVyYUBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiAmbHQ7b2F1dGhA
aWV0Zi5vcmcmZ3Q7ICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g
UmU6IFtPQVVUSC1XR10gQ2FsbCBmb3IgQWRvcHRpb246IFJlc291cmNlIEluZGljYXRvcnMgZm9y
IE9BdXRoIDIuMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlbmRpbmcg
YSB0b2tlbiB0eXBlIGlzIG5vdCBzdWZmaWNpZW50LiBUaGVyZSdzIG1vcmUgaW52b2x2ZWQgdGhh
biB0aGUgZm9ybWF0LiBNYW55IGNhc2VzIG5lZWQgdG8ga25vdyBpZiB0byBlbmNyeXB0IGFuZCB3
aG9tIHRvIGVuY3J5cHQgdG8uJm5ic3A7IFdoYXQgY2xhaW1zIHRvIHB1dCBpbiB0aGUgdG9rZW4g
KG9yIHJlZmVyZW5jZSBieSB0aGUgdG9rZW4pLiBXaGF0IGFsZ29yaXRobXMgYW5kIGtleXMgdG8g
dXNlIGZvcg0KIHNpZ25pbmcvZW5jcnlwdGlvbi4gJm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClRoZSBz
dGF0ZW1lbnQgdGhhdCB0aGUgJnF1b3Q7Q3VycmVudCBwcm9wb3NhbCBkb2VzIG5vdCBzdXBwb3J0
IHRoZSBpbXBsaWNpdCBmbG93JnF1b3Q7IGlzIGluY29ycmVjdC4gQW1vbmcgb3RoZXIgdGhpbmdz
LCBzZWMgMiBoYXMsICZxdW90O1doZW4gYW4gYWNjZXNzIHRva2VuIHdpbGwgYmUgcmV0dXJuZWQg
ZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCwgdGhlICZxdW90O3Jlc291cmNlJnF1b3Q7
IHBhcmFtZXRlciBpcyB1c2VkIGluIHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QgdG8NCiB0aGUg
YXV0aG9yaXphdGlvbiBlbmRwb2ludCBhcyBkZWZpbmVkIGluIFNlY3Rpb24gNC4yLjEgb2YgT0F1
dGggMi4wIFtSRkM2NzQ5XS4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU3VuLCBBcHIg
MTAsIDIwMTYgYXQgMTE6NDMgQU0sIE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNh
a2ltdXJhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNha2ltdXJhQGdtYWlsLmNvbTwvYT4m
Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l
O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw
dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5TbywgbXkgdW5kZXJzdGFuZGluZyBvbiB0aGUgcmF0aW9uYWxlL3JlcXVpcmVt
ZW50cyBmb3IgaGF2aW5nIHRoaXMgc3BlYyByaWdodCBub3cgaXM6Jm5ic3A7PG86cD48L286cD48
L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SMS4gQXV0aHogc2VydmVyIHdhbnRz
IHRvcHJldmVudCB0aGUgcmVwbGF5IGJ5IHRoZSBzZXJ2ZXIgdGhhdCByZWNlaXZlZCBpdC4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlIy
LiBBdXRoeiBzZXJ2ZXIgbmVlZHMgdG8gbWludCB0aGUgYWNjZXNzIHRva2VuIGluIGEgdmFyaWV0
eSBvZiBmb3JtYXQgZGVwZW5kaW5nIG9uIHRoZSByZXNvdXJjZSBzZXJ2ZXIgYW5kIHRvIGRvIHRo
YXQsIHlvdSBuZWVkIHRvIGtub3cgd2hpY2ggUlMgaXMgZ29uZyB0byBiZSByZWNlaXZpbmcgaXQu
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPlRvIGFjaGlldmUgUjEsIHRoZXJlIGFyZSBjb3VwbGUgb2YgbWV0aG9kcy4gVGhlIHByb3Bv
c2VkIG1ldGhvZCBoZXJlIGlzIHRvIGF1ZGllbmNlIHJlc3RyaWN0IHRoZSB0b2tlbiwgYnV0IHRo
ZSBzYW1lIGNhbiBiZSBhY2hpZXZlZCBieSBzZW5kZXIgY29uc3RyYWluaW5nIHRoZSB0b2tlbiwg
ZS5nLiwgYnkgdG9rZW4gYmluZGluZy4gQXMgZmFyIGFzIEkgY2FuIHNlZSwgdGhlIHNlbnRpbWVu
dCBvZiB0aGUgV0cNCiBzZWVtcyB0byBiZSB0byB1c2UgdGhlIHNlbmRlciBjb25zdHJhaW50IHRo
cm91Z2ggVG9rZW4gQmluZGluZywgc28gZnJvbSB0aGlzIHJlc3BlY3QsIHRoaXMgc3BlYyBpcyBu
b3QgdGhlIG9uZSB0byBkbyBSMS4gQmVzaWRlcywgdGhlIGN1cnJlbnQgcHJvcG9zYWwgb25seSB0
YWtlcyBjYXJlIG9mIHRoZSBjb2RlIGZsb3cuIFRoZSBzYW1lIHJlcXVpcmVtZW50IHNob3VsZCBi
ZSB0aGVyZSBmb3IgaW1wbGljaXQgZmxvdyBhcyB3ZWxsLCBzbyB0aGUNCiBjdXJyZW50IHByb3Bv
c2FsIGlzIG5vdCBjb3ZlcmluZyB0aGUgUjEgYW55d2F5cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBjYW4gc29ydCBvZiB1bmRl
cnN0YW5kIFIyLCBidXQgSSBoYXZlIHR3byBjcml0aXF1ZSBvbiB0aGUgY3VycmVudCBwcm9wb3Nh
bDombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+QzEuIEN1cnJlbnQgcHJvcG9zYWwgZG9lcyBub3Qgc3VwcG9ydCB0aGUgaW1wbGljaXQg
Zmxvdy4gVG8gc3VwcG9ydCBpdCwgdGhlIHJlc291cmNlIFVSSSBoYXMgdG8gYmUgc2VudCB0byB0
aGUgQXV0aHogZW5kcG9pbnQgaW5zdGVhZCBvZiB0aGUgVG9rZW4gZW5kcG9pbnQuJm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DMi4gSXQg
aXMgbXVjaCBtb3JlIGRpcmVjdCB0byBzZW5kIHRoZSByZXF1aXJlZCB0b2tlbiBmb3JtYXQgcmF0
aGVyIHRoYW4gdGhlIFJTIHVyaSBhbmQgcHJvYmFibHkgYmV0dGVyIGFzOiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IDEpIFRo
ZXJlIGFyZSB1c2UgY2FzZXMgd2hlcmUgdGhlIEFTIGRvZXMgbm90IG1haW50YWluIHRoZSBsaXN0
IG9mIFJTcyB0aGF0IGl0IHN1cHBvcnRzLCBlLmcuLCBBT0wuJm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDtJbiBzdWNoIGEgY2FzZSwgZXZlbiBpZiB0aGUgUlMgdXJpIHdlcmUgc2VudCB0byB0
aGUgQVMsIHRoZSBBUyBjYW5ub3QgbWludCB0aGUgdG9rZW5zIGluIHRoZSBhcHByb3ByaWF0ZSBm
b3JtYXQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4mbmJzcDsgMikgV2hlbiBpdCBpcyBzZW50IGluIHRoZSBBdXRoeiByZXF1ZXN0LCBp
dCBpcyBsZWFraW5nIHRoZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgcmVzb3VyY2UgdGhhdCB0aGUg
Y2xpZW50IGlzIGdvaW5nIHRvIHRoZSBicm93c2VyLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IDMpIFRoZXJlIGFyZSB1c2Ug
Y2FzZXMgd2hlcmUgaXQgaXMgZGVzaXJhYmxlIG5vdCB0byBsZXQgdGhlIEFTIGtub3dzIHdoZXJl
IHRoZSBDbGllbnQgaXMgZ29pbmcgZnJvbSB0aGUgcHJpdmFjeSBwb2ludCBvZiB2aWV3LiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5T
bywgbXkgc3VnZ2VzdGlvbiBpcyB0byBkcm9wIFIxIGFuZCBjb25jZW50cmF0ZSBvbiBSMi4gQW5k
IHRvIHNvbHZlIFIyLCBzZW5kIHRva2VuIHR5cGUgaW5zdGVhZCBvZiB0aGUgcmVzb3VyY2UgaW5k
aWNhdG9yIGluIHRoZSByZXF1ZXN0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBhbHNvIG5lY2Vzc2l0YXRlcyB0aGUgQ2xpZW50
IHRvIGJlIGFibGUgdG8gZmluZCBvdXQgd2hhdCB0b2tlbiB0eXBlIHRoZSByZXNvdXJjZSByZXF1
aXJlcywgcGVyaGFwcyBpbiB0aGUgdW5hdXRob3JpemVkIHJlc3BvbnNlIHdlYiBsaW5rIGhlYWRl
ciBhdCB0aGUgcmVzb3VyY2UgaW4gdGhlIG1hbm5lciBvZiBvYXV0aC1tZXRhLiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMs
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPk5hdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+MjAxNjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVv
dDsiPuW5tDwvc3Bhbj40PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZx
dW90OyI+5pyIPC9zcGFuPjg8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGlj
JnF1b3Q7Ij7ml6U8L3NwYW4+KDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3Ro
aWMmcXVvdDsiPumHkTwvc3Bhbj4pIDg6MjMgUHJhdGVlayBNaXNocmEgJmx0OzxhIGhyZWY9Im1h
aWx0bzpQcmF0ZWVrLk1pc2hyYUBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+UHJhdGVlay5N
aXNocmFAb3JhY2xlLmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj
Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7
bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGlsZSB0aGlzIHdvcmsg
YWRkcmVzc2VzIGEgZ2FwIGluIHRoZSBleGlzdGluZyBPQXV0aCBzcGVjaWZpY2F0aW9uIHNldCwg
SSBhbSB2ZXJ5IGNvbmNlcm5lZCB0aGF0IHRoaXM8YnI+DQppbmNyZW1lbnRhbCBleHRlbnNpb24g
d2lsbCBsZWFkIHRvIGV2ZW4gbW9yZSBjb25mdXNpb24gYXJvdW5kIHRoZSBhcmVhcyBvZiDigJxz
Y29wZeKAnSwg4oCcYXVkaWVuY2XigJ0gYW5kIOKAnHJlc291cmNlIHNlcnZlcuKAnS48YnI+DQo8
YnI+DQpJIHRoaW5rIHdlIHNob3VsZCB0cnkgdG8gc29sdmUgdGhpcyBwcm9ibGVtIHZpYSZuYnNw
OyBhIGZyYW1ld29yayB0aGF0IHByb3ZpZGVzIGJldHRlciBndWlkYW5jZSBhbmQgaW1wbGVtZW50
YXRpb248YnI+DQptb2RlbHMgZm9yIE9BdXRoIHVzZS1jYXNlcy4gSW4gb3RoZXIgd29yZHMsIEkg
ZmVlbCB0aGF0IGEgYnJvYWRlciBkaXNjdXNzaW9uIGlzIG5lZWRlZCBoZXJlLjxicj4NCjxicj4N
Cjxicj4NCiZndDsgT24gQXByIDcsIDIwMTYsIGF0IDQ6MTEgUE0sIEp1c3RpbiBSaWNoZXIgJmx0
OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIj5qcmljaGVy
QG1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIHN1cHBvcnQgYWRv
cHRpb24gb2YgdGhpcyBkb2N1bWVudCBhcyBhIHN0YXJ0aW5nIHBvaW50IGZvciB3b3JraW5nIGdy
b3VwIHdvcmsuPGJyPg0KJmd0Ozxicj4NCiZndDsg4oCUIEp1c3Rpbjxicj4NCiZndDs8YnI+DQom
Z3Q7PGJyPg0KJmd0OyZndDsgT24gQXByIDYsIDIwMTYsIGF0IDE6MjUgUE0sIEhhbm5lcyBUc2No
b2ZlbmlnICZsdDs8YSBocmVmPSJtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldCIgdGFy
Z2V0PSJfYmxhbmsiPmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ8L2E+Jmd0OyB3cm90ZTo8YnI+
DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEhpIGFsbCw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm
Z3Q7IHRoaXMgaXMgdGhlIGNhbGwgZm9yIGFkb3B0aW9uIG9mICdSZXNvdXJjZSBJbmRpY2F0b3Jz
IGZvciBPQXV0aCAyLjAnLCBzZWU8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL25hMDEu
c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJmJTJmZGF0YXRy
YWNrZXIuaWV0Zi5vcmclMmZkb2MlMmZkcmFmdC1jYW1wYmVsbC1vYXV0aC1yZXNvdXJjZS1pbmRp
Y2F0b3JzJTJmJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Yzk1
OTBlNDAyNWViNjQ0MmVjZWRlMDhkMzYyM2ZjOTYxJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdj
ZDAxMWRiNDclN2MxJmFtcDtzZGF0YT15ODY5Rms5OTg3ZmYwOWh2SElOJTJiVkdsJTJmcXh3V0Rt
a3ZPd3pjUWNXcVhadyUzZCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL2RhdGF0cmFja2VyLmll
dGYub3JnL2RvYy9kcmFmdC1jYW1wYmVsbC1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLzwvYT48
YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFBsZWFzZSBsZXQgdXMga25vdyBieSBBcHJpbCAy
MHRoIHdoZXRoZXIgeW91IGFjY2VwdCAvIG9iamVjdCB0byB0aGU8YnI+DQomZ3Q7Jmd0OyBhZG9w
dGlvbiBvZiB0aGlzIGRvY3VtZW50IGFzIGEgc3RhcnRpbmcgcG9pbnQgZm9yIHdvcmsgaW4gdGhl
IE9BdXRoPGJyPg0KJmd0OyZndDsgd29ya2luZyBncm91cC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn
dDsmZ3Q7IE5vdGU6IElmIHlvdSBhbHJlYWR5IHN0YXRlZCB5b3VyIG9waW5pb24gYXQgdGhlIElF
VEYgbWVldGluZyBpbiBCdWVub3M8YnI+DQomZ3Q7Jmd0OyBBaXJlcyB0aGVuIHlvdSBkb24ndCBu
ZWVkIHRvIHJlLXN0YXRlIHlvdXIgb3BpbmlvbiwgaWYgeW91IHdhbnQuPGJyPg0KJmd0OyZndDs8
YnI+DQomZ3Q7Jmd0OyBUaGUgZmVlZGJhY2sgYXQgdGhlIEJBIElFVEYgbWVldGluZyB3YXMgdGhl
IGZvbGxvd2luZzogfjEwIHBlcnNvbnM8YnI+DQomZ3Q7Jmd0OyBmb3IgYWNjZXB0aW5nIHRoZSBk
b2N1bWVudCBhbmQgMCBwZXJzb25zIGFnYWluc3QuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0
OyBDaWFvPGJyPg0KJmd0OyZndDsgSGFubmVzICZhbXA7IERlcmVrPGJyPg0KJmd0OyZndDs8YnI+
DQomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xzxicj4NCiZndDsmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9
Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9h
Pjxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlv
bi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUy
Zmxpc3RpbmZvJTJmb2F1dGgmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQu
Y29tJTdjOTU5MGU0MDI1ZWI2NDQyZWNlZGUwOGQzNjIzZmM5NjElN2M3MmY5ODhiZjg2ZjE0MWFm
OTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPWJmcDFER0g1aiUyYnRNNFp0eDdNJTJidWVL
N0t4VjZrTkpFWFpLSEVDSVVLaUJRJTNkIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBP
QXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9y
ZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0i
aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl
M2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZhbXA7ZGF0
YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2M5NTkwZTQwMjVlYjY0NDJlY2Vk
ZTA4ZDM2MjNmYzk2MSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7
c2RhdGE9YmZwMURHSDVqJTJidE00WnR4N00lMmJ1ZUs3S3hWNmtOSkVYWktIRUNJVUtpQlElM2Qi
IHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
b2F1dGg8L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86
T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8
YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy
bD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRo
JmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Yzk1OTBlNDAyNWVi
NjQ0MmVjZWRlMDhkMzYyM2ZjOTYxJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDcl
N2MxJmFtcDtzZGF0YT1iZnAxREdINWolMmJ0TTRadHg3TSUyYnVlSzdLeFY2a05KRVhaS0hFQ0lV
S2lCUSUzZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox
Mi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGll
dGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL25hMDEuc2Fm
ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRm
Lm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmFtcDtkYXRhPTAxJTdjMDElN2N0b255
bmFkJTQwbWljcm9zb2Z0LmNvbSU3Yzk1OTBlNDAyNWViNjQ0MmVjZWRlMDhkMzYyM2ZjOTYxJTdj
NzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1iZnAxREdINWol
MmJ0TTRadHg3TSUyYnVlSzdLeFY2a05KRVhaS0hFQ0lVS2lCUSUzZCIgdGFyZ2V0PSJfYmxhbmsi
Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286
cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_BN3PR0301MB123431087E4F35D1EAE30598A6940BN3PR0301MB1234_--


From nobody Mon Apr 11 13:26:49 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD0A12F3B6 for ; Mon, 11 Apr 2016 13:26:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2g_SHkypQDwk for ; Mon, 11 Apr 2016 13:26:46 -0700 (PDT)
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 3ABE612F3AB for ; Mon, 11 Apr 2016 13:26:46 -0700 (PDT)
Received: by mail-ig0-x229.google.com with SMTP id kb1so91443371igb.0 for ; Mon, 11 Apr 2016 13:26:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AFeeZHYD/fmWVAdlUqRmL7QA4Y2HD2xwNobzUYtZAYM=; b=l7ffipFBsfUsX2gtrLP5E4aBGD69PDRBlBpVd7eSabSbDXkRQY7DLw4Al6adjdTBuR LszgtKkdxEqKB9+5avD1Y+ZKjhxjZH30uDE92qK5VVPVTy/8SIX9JgoGj050RBjMYfym EcuuQZz6NiL92pTkJ+18adbV98kFb0zaEJuo4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AFeeZHYD/fmWVAdlUqRmL7QA4Y2HD2xwNobzUYtZAYM=; b=LD2OrT6vZkZ2G0a5v8ftD4TGFXkGu8PpQ07CYgkZUHD/yQTonV34oYD4veVklEwDnp uwv9SQj3kv1mx0v8KPU0IqiTl7xmZ4EVCeJst5xjgOkV2e+/YWNxcXjgDcBayVq+OXrz eX+Vr5NcG4lnwB3KO8WYScEMUpZnuncyQg4xnkzwHJTVo2EZysHTm07yT1Ll0aBD1Xf6 zksD6gVfXB3DSPfA+Gx8HYY/fLjP8zmcMMnrifGYa/CRN6DGLnwgOYyZc1OlDypDGw2I 98IyUnCML+7cwU0s7KyEcH/Sgnbh1j8xN1Dcv4L3ELkRMyOBFE0EPyr+1pBn89AkFqXs M4sQ==
X-Gm-Message-State: AD7BkJJunnrUJP9s1awODeO/SSLgR+j0zcOXKXTmJZ+CSwSMLU/bYQ+DdHyXT8gdR/VR6VL28byjdYjhU5LVj6f+
X-Received: by 10.50.126.101 with SMTP id mx5mr20871520igb.49.1460406405424; Mon, 11 Apr 2016 13:26:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.74.162 with HTTP; Mon, 11 Apr 2016 13:26:15 -0700 (PDT)
In-Reply-To: 
References: 
From: Brian Campbell 
Date: Mon, 11 Apr 2016 14:26:15 -0600
Message-ID: 
To: Adam Lewis 
Content-Type: multipart/alternative; boundary=047d7b2e13c706252105303b5dfd
Archived-At: 
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Question on draft-ietf-oauth-token-exchange-04
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Apr 2016 20:26:48 -0000

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

The intent is that urn:ietf:params:oauth:token-type:access_token be an
indicator that the token is a typical OAuth access token issued by the AS
in question, opaque to the client, and usable the same manner as any other
access token obtained from that AS (it could well be a JWT but the client
isn't and needn't be aware of that fact). Whereas
urn:ietf:params:oauth:token-type:jwt is to indicate that a JWT specifically
is being requested or sent (perhaps in a cross-domain use case to get an
access token from a different AS like is facilitated by RFC 7523).

Is that helpful at all?

I agree that it can be confusing. But it's representative of the kinds of
tokens and their usages out there now. So, needs to be allowed. I'd welcome
ideas about how the language could be improved to help alleviate some of
the confusion though.

On Mon, Apr 11, 2016 at 7:25 AM, Adam Lewis <
adam.lewis@motorolasolutions.com> wrote:

> Hi,
>
> There are multiple places in draft-ietf-oauth-token-exchange-04 where a
> differentiation seems to be drawn between 'access_token' and 'jwt' ... for
> example in section 2.2.1. when discussing the issued_token_type, it states:
>
>       a value of "urn:ietf:params:oauth:token-type:access_token" indicates
>
>       that the issued token is an access token and a value of
>       "urn:ietf:params:oauth:token-type:jwt" indicates that it is a JWT.
>
>
> This is confusing to me because an access token represents a delegated authorization decision, whereas JWT is a token *format*.  An access token could easily be a JWT (and in many deployments, they are).
>
>
> So why the desire to differentiate, and what does the differentiation mean?
>
>
>
> tx!
> adam
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

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


The intent is that urn:ietf:params:oauth:to=
ken-type:access_token be an indicator that the token is a typical OAuth acc=
ess token issued by the AS in question, opaque to the client, and usable th=
e same manner as any other access token obtained from that AS (it could wel=
l be a JWT but the client isn't and needn't be aware of that fact).=
 Whereas urn:ietf:params:oauth:token-type:jwt is to indicate that a JWT spe=
cifically is being requested or sent (perhaps in a cross-domain use case to=
 get an access token from a different AS like is facilitated by RFC 7523). =


Is that helpful at all?

I agree that it can be c=
onfusing. But it's representative of the kinds of tokens and their usag=
es out there now. So, needs to be allowed. I'd welcome ideas about how =
the language could be improved to help alleviate some of the confusion thou=
gh. 

On Mon, Apr 11, 2016 at 7:25 AM, Adam Lewis <adam.lewis@=
motorolasolutions.com> wrote:
Hi,

There are multiple places in=C2=
=A0draft-ietf-oauth-token-exchange-04 where a differentiation seems to be d=
rawn between 'access_token' and 'jwt' ... for example in se=
ction 2.2.1. when discussing the issued_token_type, it states:
      a value of "urn:ietf:params:oauth:token-t=
ype:access_token" indicates=C2=A0
      that the issued=
 token is an access token and a value of
      "urn:ietf:params:oauth:token-type:jwt" indicates that it is=
 a JWT.

T=
his is confusing to me because an access token represents a delegated autho=
rization=C2=A0decision, whereas JWT is a token *format*.=C2=A0 An access to=
ken could easily be a JWT (and in many deployments, they are). =C2=A0

So why the desire to differentiate, and =
what does the differentiation mean?


tx!
adam


_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





--047d7b2e13c706252105303b5dfd--


From nobody Mon Apr 11 13:34:26 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18BD12F41C for ; Mon, 11 Apr 2016 13:34:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OpV6G3dHHnQ for ; Mon, 11 Apr 2016 13:34:21 -0700 (PDT)
Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D473412F41B for ; Mon, 11 Apr 2016 13:34:20 -0700 (PDT)
Received: by mail-ig0-x22b.google.com with SMTP id gy3so91544193igb.1 for ; Mon, 11 Apr 2016 13:34:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GbTlCQGU0hcwxygx9ucAeRXIgB9ZqFcJlUJLQn5vRAE=; b=gZg/OVB44gxsvOCgV52z76o3fq3Rf4uzdzY+JiiaQ97+ZoqTiuT0OePk7DsqyJpJJU GhYYv1+HYzXB9nECHdd+tvyqNqqd+z63iS4MwfKANKuFzNHHciKeQe+z30vsfo2yA4md rLRQaQkke6Dhaw36l2odgtDSQ4fduJ1TJKNm0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GbTlCQGU0hcwxygx9ucAeRXIgB9ZqFcJlUJLQn5vRAE=; b=AG/+ruFyvgpqRpYnM16K5Nye9g6tsiUTI1oCuLYMwr9+OfE4zPMulosOLIrMNkDFHd UKbf50EC6G4hiCA1wiuNoH9gMeNWqOxQ9KQCwszMWAjDZhVWJ/Zkpujah9xadDt5p1xv TYmH+t/ZtDWLVPDBAru7/eZ3uz+xTOefakXef+ick9geMjSekyZtH4/cjKib/CoTXnrF Ok4vu2VP6KRO+7/UJEi7LH3MQB++omX7QTgR1SRLJsKFBX7tVdK8w0hvgC5ISFdTr3hY Pe7SId8v6R2oPivCRa6+hGFgx5xqHBB/LZi6Uxj9tgBU6D//ZxG+jxntsnm3AE0+3tY5 EDDA==
X-Gm-Message-State: AD7BkJLl3N5phscs+7JgP7k2e/A4EXAytuSrhL6kBf1MLiQpTIq8M4VnGRNQAyQ5MARBKMaE5V+FAiW77JV78XFR
X-Received: by 10.50.50.176 with SMTP id d16mr20163577igo.57.1460406860205; Mon, 11 Apr 2016 13:34:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.74.162 with HTTP; Mon, 11 Apr 2016 13:33:50 -0700 (PDT)
In-Reply-To: 
References: <570546A1.8040509@gmx.net> <5AEB6A4A-A325-4069-930F-D034D81E41E5@mit.edu>    
From: Brian Campbell 
Date: Mon, 11 Apr 2016 14:33:50 -0600
Message-ID: 
To: Anthony Nadalin 
Content-Type: multipart/alternative; boundary=047d7bdc1608216be505303b78b5
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Apr 2016 20:34:23 -0000

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

No, I'm not adding requirements for encryption. I was pointing out some of
the ways that an access token might be different for different RSs.



On Mon, Apr 11, 2016 at 2:18 PM, Anthony Nadalin 
wrote:

> So now you are adding more requirements for encryption ? The more this
> thread goes on shows how unstable and not fully thought out this draft is
> to go through WG adoption.
>
>
>
> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian
> Campbell
> *Sent:* Monday, April 11, 2016 12:30 PM
> *To:* Nat Sakimura 
> *Cc:*  
> *Subject:* Re: [OAUTH-WG] Call for Adoption: Resource Indicators for
> OAuth 2.0
>
>
>
> Sending a token type is not sufficient. There's more involved than the
> format. Many cases need to know if to encrypt and whom to encrypt to.  Wh=
at
> claims to put in the token (or reference by the token). What algorithms a=
nd
> keys to use for signing/encryption.
>
>
> The statement that the "Current proposal does not support the implicit
> flow" is incorrect. Among other things, sec 2 has, "When an access token
> will be returned from the authorization endpoint, the "resource" paramete=
r
> is used in the authorization request to the authorization endpoint as
> defined in Section 4.2.1 of OAuth 2.0 [RFC6749]."
>
>
>
> On Sun, Apr 10, 2016 at 11:43 AM, Nat Sakimura  wrote=
:
>
> So, my understanding on the rationale/requirements for having this spec
> right now is:
>
>
>
> R1. Authz server wants toprevent the replay by the server that received
> it.
>
> R2. Authz server needs to mint the access token in a variety of format
> depending on the resource server and to do that, you need to know which R=
S
> is gong to be receiving it.
>
>
>
> To achieve R1, there are couple of methods. The proposed method here is t=
o
> audience restrict the token, but the same can be achieved by sender
> constraining the token, e.g., by token binding. As far as I can see, the
> sentiment of the WG seems to be to use the sender constraint through Toke=
n
> Binding, so from this respect, this spec is not the one to do R1. Besides=
,
> the current proposal only takes care of the code flow. The same requireme=
nt
> should be there for implicit flow as well, so the current proposal is not
> covering the R1 anyways.
>
>
>
> I can sort of understand R2, but I have two critique on the current
> proposal:
>
>
>
> C1. Current proposal does not support the implicit flow. To support it,
> the resource URI has to be sent to the Authz endpoint instead of the Toke=
n
> endpoint.
>
> C2. It is much more direct to send the required token format rather than
> the RS uri and probably better as:
>
>   1) There are use cases where the AS does not maintain the list of RSs
> that it supports, e.g., AOL.
>
>        In such a case, even if the RS uri were sent to the AS, the AS
> cannot mint the tokens in the appropriate format.
>
>   2) When it is sent in the Authz request, it is leaking the information
> about the resource that the client is going to the browser.
>
>   3) There are use cases where it is desirable not to let the AS knows
> where the Client is going from the privacy point of view.
>
>
>
> So, my suggestion is to drop R1 and concentrate on R2. And to solve R2,
> send token type instead of the resource indicator in the request.
>
> This also necessitates the Client to be able to find out what token type
> the resource requires, perhaps in the unauthorized response web link head=
er
> at the resource in the manner of oauth-meta.
>
>
>
> Cheers,
>
>
>
> Nat
>
>
>
>
>
>
>
> 2016=E5=B9=B44=E6=9C=888=E6=97=A5(=E9=87=91) 8:23 Prateek Mishra :
>
> While this work addresses a gap in the existing OAuth specification set, =
I
> am very concerned that this
> incremental extension will lead to even more confusion around the areas o=
f
> =E2=80=9Cscope=E2=80=9D, =E2=80=9Caudience=E2=80=9D and =E2=80=9Cresource=
 server=E2=80=9D.
>
> I think we should try to solve this problem via  a framework that provide=
s
> better guidance and implementation
> models for OAuth use-cases. In other words, I feel that a broader
> discussion is needed here.
>
>
> > On Apr 7, 2016, at 4:11 PM, Justin Richer  wrote:
> >
> > I support adoption of this document as a starting point for working
> group work.
> >
> > =E2=80=94 Justin
> >
> >
> >> On Apr 6, 2016, at 1:25 PM, Hannes Tschofenig <
> hannes.tschofenig@gmx.net> wrote:
> >>
> >> Hi all,
> >>
> >> this is the call for adoption of 'Resource Indicators for OAuth 2.0',
> see
> >>
> http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
> 
> >>
> >> Please let us know by April 20th 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 Buenos
> >> Aires then you don't need to re-state your opinion, if you want.
> >>
> >> The feedback at the BA IETF meeting was the following: ~10 persons
> >> for accepting the document and 0 persons against.
> >>
> >> 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
> 
>
>
>

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


No, I'm not adding requirements for encryption. I was =
pointing out some of the ways that an access token might be different for d=
ifferent RSs.




--047d7bdc1608216be505303b78b5--


From nobody Mon Apr 11 13:35:12 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474F112F405 for ; Mon, 11 Apr 2016 13:35:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.232
X-Spam-Level: 
X-Spam-Status: No, score=-1.232 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssW6p7piOUxk for ; Mon, 11 Apr 2016 13:35:08 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0113.outbound.protection.outlook.com [207.46.100.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 737D312F428 for ; Mon, 11 Apr 2016 13:35:07 -0700 (PDT)
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=KUeRhrCaS0Hl8Rezx893GzovJ5igbDGfIhgs4DlNCoY=; b=DwirHn8l3Z6prAVRMcYQM2fr17QAx6UpH+R8elSpHeeB/5g0wLXcm0h9EgangW9wOK69QMSGHG4ETPP1qvGWFsZS9SXYGszzdwEeqWCRa6GFAx9X8/ytAS1fm+pdaNi+HFHZ3PWb/YWpvTtwMs9YS19033CrUxD4RTDB5F4HOsQ=
Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1235.namprd03.prod.outlook.com (10.161.207.23) with Microsoft SMTP Server (TLS) id 15.1.453.26; Mon, 11 Apr 2016 20:35:06 +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.0453.029; Mon, 11 Apr 2016 20:35:06 +0000
From: Anthony Nadalin 
To: Brian Campbell 
Thread-Topic: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0
Thread-Index: AQHRkCmB9ToVpiQsqkic7QI3EfNCup9/JV+AgAADVwCABFfWgIABsEAAgAAMjfCAAAU9AIAAADpg
Date: Mon, 11 Apr 2016 20:35:06 +0000
Message-ID: 
References: <570546A1.8040509@gmx.net> <5AEB6A4A-A325-4069-930F-D034D81E41E5@mit.edu>     
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: pingidentity.com; dkim=none (message not signed) header.d=none;pingidentity.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [64.134.186.9]
x-ms-office365-filtering-correlation-id: 97680e3f-2576-4401-1866-08d36248c479
x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1235; 5:p4mHNGCMhGARFWh6LXbU9ybs3fBbZAjofl/aMVdvDJjg9FlXu/SAeqKYmf09ETEobgRpOK9XKg0eYOc+nZjXXeeoQ8nGaqEgBuBbpfn3L9qihCV6r4NwYl6r5nh1hcyvtLW+U2A80r/8CTUrtO4RAQ==; 24:CuqK2Z0p2aao8GF0iIo2yaEZfhei3MJ/U5l8+o9JvVoJIl+y3OQ8aRQuARD+7rIZQlUYnYaOAqPYqGGe1J/dRDs6J+LKuXQkmU8ITzrhfck=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1235;
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)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BN3PR0301MB1235; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1235; 
x-forefront-prvs: 09090B6B69
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(53754006)(92566002)(86362001)(74316001)(4326007)(122556002)(99286002)(11100500001)(110136002)(19300405004)(93886004)(2950100001)(2900100001)(561944003)(54356999)(2906002)(76576001)(3660700001)(3280700002)(76176999)(50986999)(5003600100002)(19609705001)(5005710100001)(10400500002)(10290500002)(87936001)(15975445007)(102836003)(6116002)(3846002)(1220700001)(1096002)(106116001)(81166005)(790700001)(10090500001)(19580405001)(586003)(77096005)(5004730100002)(5002640100001)(19580395003)(189998001)(66066001)(33656002)(5008740100001)(9686002)(19625215002)(19617315012)(16236675004)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1235; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1234B7AF83F059E441B3B593A6940BN3PR0301MB1234_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2016 20:35:06.1715 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1235
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Apr 2016 20:35:10 -0000

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

U28gaXTigJlzIGFuIGluY29tcGxldGUgc29sdXRpb24gdGhlbiA/DQoNCkZyb206IEJyaWFuIENh
bXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb21dDQpTZW50OiBNb25kYXks
IEFwcmlsIDExLCAyMDE2IDE6MzQgUE0NClRvOiBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWlj
cm9zb2Z0LmNvbT4NCkNjOiBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbT47IDxvYXV0
aEBpZXRmLm9yZz4gPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQ2Fs
bCBmb3IgQWRvcHRpb246IFJlc291cmNlIEluZGljYXRvcnMgZm9yIE9BdXRoIDIuMA0KDQpObywg
SSdtIG5vdCBhZGRpbmcgcmVxdWlyZW1lbnRzIGZvciBlbmNyeXB0aW9uLiBJIHdhcyBwb2ludGlu
ZyBvdXQgc29tZSBvZiB0aGUgd2F5cyB0aGF0IGFuIGFjY2VzcyB0b2tlbiBtaWdodCBiZSBkaWZm
ZXJlbnQgZm9yIGRpZmZlcmVudCBSU3MuDQoNCg0KT24gTW9uLCBBcHIgMTEsIDIwMTYgYXQgMjox
OCBQTSwgQW50aG9ueSBOYWRhbGluIDx0b255bmFkQG1pY3Jvc29mdC5jb208bWFpbHRvOnRvbnlu
YWRAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KU28gbm93IHlvdSBhcmUgYWRkaW5nIG1vcmUgcmVx
dWlyZW1lbnRzIGZvciBlbmNyeXB0aW9uID8gVGhlIG1vcmUgdGhpcyB0aHJlYWQgZ29lcyBvbiBz
aG93cyBob3cgdW5zdGFibGUgYW5kIG5vdCBmdWxseSB0aG91Z2h0IG91dCB0aGlzIGRyYWZ0IGlz
IHRvIGdvIHRocm91Z2ggV0cgYWRvcHRpb24uDQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgt
Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFs
ZiBPZiBCcmlhbiBDYW1wYmVsbA0KU2VudDogTW9uZGF5LCBBcHJpbCAxMSwgMjAxNiAxMjozMCBQ
TQ0KVG86IE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBn
bWFpbC5jb20+Pg0KQ2M6IDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+PiA8
b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FV
VEgtV0ddIENhbGwgZm9yIEFkb3B0aW9uOiBSZXNvdXJjZSBJbmRpY2F0b3JzIGZvciBPQXV0aCAy
LjANCg0KU2VuZGluZyBhIHRva2VuIHR5cGUgaXMgbm90IHN1ZmZpY2llbnQuIFRoZXJlJ3MgbW9y
ZSBpbnZvbHZlZCB0aGFuIHRoZSBmb3JtYXQuIE1hbnkgY2FzZXMgbmVlZCB0byBrbm93IGlmIHRv
IGVuY3J5cHQgYW5kIHdob20gdG8gZW5jcnlwdCB0by4gIFdoYXQgY2xhaW1zIHRvIHB1dCBpbiB0
aGUgdG9rZW4gKG9yIHJlZmVyZW5jZSBieSB0aGUgdG9rZW4pLiBXaGF0IGFsZ29yaXRobXMgYW5k
IGtleXMgdG8gdXNlIGZvciBzaWduaW5nL2VuY3J5cHRpb24uDQoNClRoZSBzdGF0ZW1lbnQgdGhh
dCB0aGUgIkN1cnJlbnQgcHJvcG9zYWwgZG9lcyBub3Qgc3VwcG9ydCB0aGUgaW1wbGljaXQgZmxv
dyIgaXMgaW5jb3JyZWN0LiBBbW9uZyBvdGhlciB0aGluZ3MsIHNlYyAyIGhhcywgIldoZW4gYW4g
YWNjZXNzIHRva2VuIHdpbGwgYmUgcmV0dXJuZWQgZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBlbmRw
b2ludCwgdGhlICJyZXNvdXJjZSIgcGFyYW1ldGVyIGlzIHVzZWQgaW4gdGhlIGF1dGhvcml6YXRp
b24gcmVxdWVzdCB0byB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBhcyBkZWZpbmVkIGluIFNl
Y3Rpb24gNC4yLjEgb2YgT0F1dGggMi4wIFtSRkM2NzQ5XS4iDQoNCk9uIFN1biwgQXByIDEwLCAy
MDE2IGF0IDExOjQzIEFNLCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86
c2FraW11cmFAZ21haWwuY29tPj4gd3JvdGU6DQpTbywgbXkgdW5kZXJzdGFuZGluZyBvbiB0aGUg
cmF0aW9uYWxlL3JlcXVpcmVtZW50cyBmb3IgaGF2aW5nIHRoaXMgc3BlYyByaWdodCBub3cgaXM6
DQoNClIxLiBBdXRoeiBzZXJ2ZXIgd2FudHMgdG9wcmV2ZW50IHRoZSByZXBsYXkgYnkgdGhlIHNl
cnZlciB0aGF0IHJlY2VpdmVkIGl0Lg0KUjIuIEF1dGh6IHNlcnZlciBuZWVkcyB0byBtaW50IHRo
ZSBhY2Nlc3MgdG9rZW4gaW4gYSB2YXJpZXR5IG9mIGZvcm1hdCBkZXBlbmRpbmcgb24gdGhlIHJl
c291cmNlIHNlcnZlciBhbmQgdG8gZG8gdGhhdCwgeW91IG5lZWQgdG8ga25vdyB3aGljaCBSUyBp
cyBnb25nIHRvIGJlIHJlY2VpdmluZyBpdC4NCg0KVG8gYWNoaWV2ZSBSMSwgdGhlcmUgYXJlIGNv
dXBsZSBvZiBtZXRob2RzLiBUaGUgcHJvcG9zZWQgbWV0aG9kIGhlcmUgaXMgdG8gYXVkaWVuY2Ug
cmVzdHJpY3QgdGhlIHRva2VuLCBidXQgdGhlIHNhbWUgY2FuIGJlIGFjaGlldmVkIGJ5IHNlbmRl
ciBjb25zdHJhaW5pbmcgdGhlIHRva2VuLCBlLmcuLCBieSB0b2tlbiBiaW5kaW5nLiBBcyBmYXIg
YXMgSSBjYW4gc2VlLCB0aGUgc2VudGltZW50IG9mIHRoZSBXRyBzZWVtcyB0byBiZSB0byB1c2Ug
dGhlIHNlbmRlciBjb25zdHJhaW50IHRocm91Z2ggVG9rZW4gQmluZGluZywgc28gZnJvbSB0aGlz
IHJlc3BlY3QsIHRoaXMgc3BlYyBpcyBub3QgdGhlIG9uZSB0byBkbyBSMS4gQmVzaWRlcywgdGhl
IGN1cnJlbnQgcHJvcG9zYWwgb25seSB0YWtlcyBjYXJlIG9mIHRoZSBjb2RlIGZsb3cuIFRoZSBz
YW1lIHJlcXVpcmVtZW50IHNob3VsZCBiZSB0aGVyZSBmb3IgaW1wbGljaXQgZmxvdyBhcyB3ZWxs
LCBzbyB0aGUgY3VycmVudCBwcm9wb3NhbCBpcyBub3QgY292ZXJpbmcgdGhlIFIxIGFueXdheXMu
DQoNCkkgY2FuIHNvcnQgb2YgdW5kZXJzdGFuZCBSMiwgYnV0IEkgaGF2ZSB0d28gY3JpdGlxdWUg
b24gdGhlIGN1cnJlbnQgcHJvcG9zYWw6DQoNCkMxLiBDdXJyZW50IHByb3Bvc2FsIGRvZXMgbm90
IHN1cHBvcnQgdGhlIGltcGxpY2l0IGZsb3cuIFRvIHN1cHBvcnQgaXQsIHRoZSByZXNvdXJjZSBV
UkkgaGFzIHRvIGJlIHNlbnQgdG8gdGhlIEF1dGh6IGVuZHBvaW50IGluc3RlYWQgb2YgdGhlIFRv
a2VuIGVuZHBvaW50Lg0KQzIuIEl0IGlzIG11Y2ggbW9yZSBkaXJlY3QgdG8gc2VuZCB0aGUgcmVx
dWlyZWQgdG9rZW4gZm9ybWF0IHJhdGhlciB0aGFuIHRoZSBSUyB1cmkgYW5kIHByb2JhYmx5IGJl
dHRlciBhczoNCiAgMSkgVGhlcmUgYXJlIHVzZSBjYXNlcyB3aGVyZSB0aGUgQVMgZG9lcyBub3Qg
bWFpbnRhaW4gdGhlIGxpc3Qgb2YgUlNzIHRoYXQgaXQgc3VwcG9ydHMsIGUuZy4sIEFPTC4NCiAg
ICAgICBJbiBzdWNoIGEgY2FzZSwgZXZlbiBpZiB0aGUgUlMgdXJpIHdlcmUgc2VudCB0byB0aGUg
QVMsIHRoZSBBUyBjYW5ub3QgbWludCB0aGUgdG9rZW5zIGluIHRoZSBhcHByb3ByaWF0ZSBmb3Jt
YXQuDQogIDIpIFdoZW4gaXQgaXMgc2VudCBpbiB0aGUgQXV0aHogcmVxdWVzdCwgaXQgaXMgbGVh
a2luZyB0aGUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHJlc291cmNlIHRoYXQgdGhlIGNsaWVudCBp
cyBnb2luZyB0byB0aGUgYnJvd3Nlci4NCiAgMykgVGhlcmUgYXJlIHVzZSBjYXNlcyB3aGVyZSBp
dCBpcyBkZXNpcmFibGUgbm90IHRvIGxldCB0aGUgQVMga25vd3Mgd2hlcmUgdGhlIENsaWVudCBp
cyBnb2luZyBmcm9tIHRoZSBwcml2YWN5IHBvaW50IG9mIHZpZXcuDQoNClNvLCBteSBzdWdnZXN0
aW9uIGlzIHRvIGRyb3AgUjEgYW5kIGNvbmNlbnRyYXRlIG9uIFIyLiBBbmQgdG8gc29sdmUgUjIs
IHNlbmQgdG9rZW4gdHlwZSBpbnN0ZWFkIG9mIHRoZSByZXNvdXJjZSBpbmRpY2F0b3IgaW4gdGhl
IHJlcXVlc3QuDQpUaGlzIGFsc28gbmVjZXNzaXRhdGVzIHRoZSBDbGllbnQgdG8gYmUgYWJsZSB0
byBmaW5kIG91dCB3aGF0IHRva2VuIHR5cGUgdGhlIHJlc291cmNlIHJlcXVpcmVzLCBwZXJoYXBz
IGluIHRoZSB1bmF1dGhvcml6ZWQgcmVzcG9uc2Ugd2ViIGxpbmsgaGVhZGVyIGF0IHRoZSByZXNv
dXJjZSBpbiB0aGUgbWFubmVyIG9mIG9hdXRoLW1ldGEuDQoNCkNoZWVycywNCg0KTmF0DQoNCg0K
DQoyMDE25bm0NOaciDjml6Uo6YeRKSA4OjIzIFByYXRlZWsgTWlzaHJhIDxQcmF0ZWVrLk1pc2hy
YUBvcmFjbGUuY29tPG1haWx0bzpQcmF0ZWVrLk1pc2hyYUBvcmFjbGUuY29tPj46DQpXaGlsZSB0
aGlzIHdvcmsgYWRkcmVzc2VzIGEgZ2FwIGluIHRoZSBleGlzdGluZyBPQXV0aCBzcGVjaWZpY2F0
aW9uIHNldCwgSSBhbSB2ZXJ5IGNvbmNlcm5lZCB0aGF0IHRoaXMNCmluY3JlbWVudGFsIGV4dGVu
c2lvbiB3aWxsIGxlYWQgdG8gZXZlbiBtb3JlIGNvbmZ1c2lvbiBhcm91bmQgdGhlIGFyZWFzIG9m
IOKAnHNjb3Bl4oCdLCDigJxhdWRpZW5jZeKAnSBhbmQg4oCccmVzb3VyY2Ugc2VydmVy4oCdLg0K
DQpJIHRoaW5rIHdlIHNob3VsZCB0cnkgdG8gc29sdmUgdGhpcyBwcm9ibGVtIHZpYSAgYSBmcmFt
ZXdvcmsgdGhhdCBwcm92aWRlcyBiZXR0ZXIgZ3VpZGFuY2UgYW5kIGltcGxlbWVudGF0aW9uDQpt
b2RlbHMgZm9yIE9BdXRoIHVzZS1jYXNlcy4gSW4gb3RoZXIgd29yZHMsIEkgZmVlbCB0aGF0IGEg
YnJvYWRlciBkaXNjdXNzaW9uIGlzIG5lZWRlZCBoZXJlLg0KDQoNCj4gT24gQXByIDcsIDIwMTYs
IGF0IDQ6MTEgUE0sIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hl
ckBtaXQuZWR1Pj4gd3JvdGU6DQo+DQo+IEkgc3VwcG9ydCBhZG9wdGlvbiBvZiB0aGlzIGRvY3Vt
ZW50IGFzIGEgc3RhcnRpbmcgcG9pbnQgZm9yIHdvcmtpbmcgZ3JvdXAgd29yay4NCj4NCj4g4oCU
IEp1c3Rpbg0KPg0KPg0KPj4gT24gQXByIDYsIDIwMTYsIGF0IDE6MjUgUE0sIEhhbm5lcyBUc2No
b2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PG1haWx0bzpoYW5uZXMudHNjaG9mZW5p
Z0BnbXgubmV0Pj4gd3JvdGU6DQo+Pg0KPj4gSGkgYWxsLA0KPj4NCj4+IHRoaXMgaXMgdGhlIGNh
bGwgZm9yIGFkb3B0aW9uIG9mICdSZXNvdXJjZSBJbmRpY2F0b3JzIGZvciBPQXV0aCAyLjAnLCBz
ZWUNCj4+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtY2FtcGJlbGwtb2F1
dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy88aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9u
Lm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZmRhdGF0cmFja2VyLmlldGYub3JnJTJmZG9j
JTJmZHJhZnQtY2FtcGJlbGwtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycyUyZiZkYXRhPTAxJTdj
MDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Yzk1OTBlNDAyNWViNjQ0MmVjZWRlMDhkMzYy
M2ZjOTYxJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPXk4NjlG
azk5ODdmZjA5aHZISU4lMmJWR2wlMmZxeHdXRG1rdk93emNRY1dxWFp3JTNkPg0KPj4NCj4+IFBs
ZWFzZSBsZXQgdXMga25vdyBieSBBcHJpbCAyMHRoIHdoZXRoZXIgeW91IGFjY2VwdCAvIG9iamVj
dCB0byB0aGUNCj4+IGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgYXMgYSBzdGFydGluZyBwb2lu
dCBmb3Igd29yayBpbiB0aGUgT0F1dGgNCj4+IHdvcmtpbmcgZ3JvdXAuDQo+Pg0KPj4gTm90ZTog
SWYgeW91IGFscmVhZHkgc3RhdGVkIHlvdXIgb3BpbmlvbiBhdCB0aGUgSUVURiBtZWV0aW5nIGlu
IEJ1ZW5vcw0KPj4gQWlyZXMgdGhlbiB5b3UgZG9uJ3QgbmVlZCB0byByZS1zdGF0ZSB5b3VyIG9w
aW5pb24sIGlmIHlvdSB3YW50Lg0KPj4NCj4+IFRoZSBmZWVkYmFjayBhdCB0aGUgQkEgSUVURiBt
ZWV0aW5nIHdhcyB0aGUgZm9sbG93aW5nOiB+MTAgcGVyc29ucw0KPj4gZm9yIGFjY2VwdGluZyB0
aGUgZG9jdW1lbnQgYW5kIDAgcGVyc29ucyBhZ2FpbnN0Lg0KPj4NCj4+IENpYW8NCj4+IEhhbm5l
cyAmIERlcmVrDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRv
Ok9BdXRoQGlldGYub3JnPg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9vYXV0aDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy
bD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRo
JmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjOTU5MGU0MDI1ZWI2NDQy
ZWNlZGUwOGQzNjIzZmM5NjElN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEm
c2RhdGE9YmZwMURHSDVqJTJidE00WnR4N00lMmJ1ZUs3S3hWNmtOSkVYWktIRUNJVUtpQlElM2Q+
DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+
IE9BdXRoIG1haWxpbmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5v
cmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8aHR0cHM6
Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYl
MmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZkYXRhPTAxJTdjMDEl
N2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Yzk1OTBlNDAyNWViNjQ0MmVjZWRlMDhkMzYyM2Zj
OTYxJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPWJmcDFER0g1
aiUyYnRNNFp0eDdNJTJidWVLN0t4VjZrTkpFWFpLSEVDSVVLaUJRJTNkPg0KDQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0
DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVj
dGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1h
biUyZmxpc3RpbmZvJTJmb2F1dGgmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5j
b20lN2M5NTkwZTQwMjVlYjY0NDJlY2VkZTA4ZDM2MjNmYzk2MSU3YzcyZjk4OGJmODZmMTQxYWY5
MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1iZnAxREdINWolMmJ0TTRadHg3TSUyYnVlSzdLeFY2
a05KRVhaS0hFQ0lVS2lCUSUzZD4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRv
Ok9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v
YXV0aDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1o
dHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRh
dGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjOTU5MGU0MDI1ZWI2NDQyZWNl
ZGUwOGQzNjIzZmM5NjElN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2Rh
dGE9YmZwMURHSDVqJTJidE00WnR4N00lMmJ1ZUs3S3hWNmtOSkVYWktIRUNJVUtpQlElM2Q+DQoN
Cg0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA1IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdv
dGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5p
dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy
Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm
b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlw
ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj
b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk
DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0
aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3Jt
YWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h
cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO
ZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBl
cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y
OndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u
bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rp
b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp
bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+
PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz
cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4
bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg
ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N
Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh
c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi
PlNvIGl04oCZcyBhbiBpbmNvbXBsZXRlIHNvbHV0aW9uIHRoZW4gPzxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNwYW4gc3R5
bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
ZiI+IEJyaWFuIENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb21dDQo8
YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBcHJpbCAxMSwgMjAxNiAxOjM0IFBNPGJyPg0KPGI+
VG86PC9iPiBBbnRob255IE5hZGFsaW4gJmx0O3RvbnluYWRAbWljcm9zb2Z0LmNvbSZndDs8YnI+
DQo8Yj5DYzo8L2I+IE5hdCBTYWtpbXVyYSAmbHQ7c2FraW11cmFAZ21haWwuY29tJmd0OzsgJmx0
O29hdXRoQGlldGYub3JnJmd0OyAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVj
dDo8L2I+IFJlOiBbT0FVVEgtV0ddIENhbGwgZm9yIEFkb3B0aW9uOiBSZXNvdXJjZSBJbmRpY2F0
b3JzIGZvciBPQXV0aCAyLjA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk5vLCBJJ20gbm90IGFkZGluZyByZXF1aXJlbWVu
dHMgZm9yIGVuY3J5cHRpb24uIEkgd2FzIHBvaW50aW5nIG91dCBzb21lIG9mIHRoZSB3YXlzIHRo
YXQgYW4gYWNjZXNzIHRva2VuIG1pZ2h0IGJlIGRpZmZlcmVudCBmb3IgZGlmZmVyZW50IFJTcy48
YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pk9uIE1vbiwgQXByIDExLCAyMDE2IGF0IDI6MTggUE0sIEFudGhvbnkgTmFkYWxpbiAmbHQ7PGEg
aHJlZj0ibWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRvbnlu
YWRAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv
dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk
ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu
Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi
PlNvIG5vdyB5b3UgYXJlIGFkZGluZyBtb3JlIHJlcXVpcmVtZW50cyBmb3IgZW5jcnlwdGlvbiA/
IFRoZSBtb3JlIHRoaXMgdGhyZWFkIGdvZXMgb24gc2hvd3MgaG93IHVuc3RhYmxlIGFuZCBub3QN
CiBmdWxseSB0aG91Z2h0IG91dCB0aGlzIGRyYWZ0IGlzIHRvIGdvIHRocm91Z2ggV0cgYWRvcHRp
b24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBuYW1l
PSJtXy0xMTg3MjY2NzA4NDQwMDEzNThfX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi
PiZuYnNwOzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE9B
dXRoIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl
dD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8
L2I+QnJpYW4gQ2FtcGJlbGw8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBcHJpbCAxMSwgMjAx
NiAxMjozMCBQTTxicj4NCjxiPlRvOjwvYj4gTmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWls
dG86c2FraW11cmFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+c2FraW11cmFAZ21haWwuY29t
PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5v
cmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJt
YWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4m
Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIENhbGwgZm9yIEFkb3B0aW9u
OiBSZXNvdXJjZSBJbmRpY2F0b3JzIGZvciBPQXV0aCAyLjA8L3NwYW4+PG86cD48L286cD48L3A+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TZW5kaW5nIGEgdG9rZW4gdHlwZSBp
cyBub3Qgc3VmZmljaWVudC4gVGhlcmUncyBtb3JlIGludm9sdmVkIHRoYW4gdGhlIGZvcm1hdC4g
TWFueSBjYXNlcyBuZWVkIHRvIGtub3cgaWYgdG8gZW5jcnlwdCBhbmQgd2hvbSB0byBlbmNyeXB0
IHRvLiZuYnNwOyBXaGF0IGNsYWltcyB0byBwdXQgaW4gdGhlIHRva2VuIChvcg0KIHJlZmVyZW5j
ZSBieSB0aGUgdG9rZW4pLiBXaGF0IGFsZ29yaXRobXMgYW5kIGtleXMgdG8gdXNlIGZvciBzaWdu
aW5nL2VuY3J5cHRpb24uICZuYnNwOw0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQpUaGUgc3RhdGVtZW50IHRo
YXQgdGhlICZxdW90O0N1cnJlbnQgcHJvcG9zYWwgZG9lcyBub3Qgc3VwcG9ydCB0aGUgaW1wbGlj
aXQgZmxvdyZxdW90OyBpcyBpbmNvcnJlY3QuIEFtb25nIG90aGVyIHRoaW5ncywgc2VjIDIgaGFz
LCAmcXVvdDtXaGVuIGFuIGFjY2VzcyB0b2tlbiB3aWxsIGJlIHJldHVybmVkIGZyb20gdGhlIGF1
dGhvcml6YXRpb24gZW5kcG9pbnQsIHRoZSAmcXVvdDtyZXNvdXJjZSZxdW90OyBwYXJhbWV0ZXIg
aXMgdXNlZCBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IHRvDQogdGhlIGF1dGhvcml6YXRp
b24gZW5kcG9pbnQgYXMgZGVmaW5lZCBpbiBTZWN0aW9uIDQuMi4xIG9mIE9BdXRoIDIuMCBbUkZD
Njc0OV0uJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBTdW4sIEFwciAxMCwgMjAx
NiBhdCAxMTo0MyBBTSwgTmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11cmFA
Z21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+c2FraW11cmFAZ21haWwuY29tPC9hPiZndDsgd3Jv
dGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy
LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp
bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90
dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNvLCBteSB1bmRlcnN0
YW5kaW5nIG9uIHRoZSByYXRpb25hbGUvcmVxdWlyZW1lbnRzIGZvciBoYXZpbmcgdGhpcyBzcGVj
IHJpZ2h0IG5vdyBpczombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj5SMS4gQXV0aHogc2VydmVyIHdhbnRzIHRvcHJldmVudCB0aGUgcmVwbGF5
IGJ5IHRoZSBzZXJ2ZXIgdGhhdCByZWNlaXZlZCBpdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UjIuIEF1dGh6IHNlcnZlciBuZWVk
cyB0byBtaW50IHRoZSBhY2Nlc3MgdG9rZW4gaW4gYSB2YXJpZXR5IG9mIGZvcm1hdCBkZXBlbmRp
bmcgb24gdGhlIHJlc291cmNlIHNlcnZlciBhbmQgdG8gZG8gdGhhdCwgeW91IG5lZWQgdG8ga25v
dyB3aGljaCBSUyBpcyBnb25nIHRvIGJlIHJlY2VpdmluZyBpdC4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRvIGFjaGlldmUg
UjEsIHRoZXJlIGFyZSBjb3VwbGUgb2YgbWV0aG9kcy4gVGhlIHByb3Bvc2VkIG1ldGhvZCBoZXJl
IGlzIHRvIGF1ZGllbmNlIHJlc3RyaWN0IHRoZSB0b2tlbiwgYnV0IHRoZSBzYW1lIGNhbiBiZSBh
Y2hpZXZlZCBieSBzZW5kZXIgY29uc3RyYWluaW5nIHRoZSB0b2tlbiwgZS5nLiwgYnkgdG9rZW4N
CiBiaW5kaW5nLiBBcyBmYXIgYXMgSSBjYW4gc2VlLCB0aGUgc2VudGltZW50IG9mIHRoZSBXRyBz
ZWVtcyB0byBiZSB0byB1c2UgdGhlIHNlbmRlciBjb25zdHJhaW50IHRocm91Z2ggVG9rZW4gQmlu
ZGluZywgc28gZnJvbSB0aGlzIHJlc3BlY3QsIHRoaXMgc3BlYyBpcyBub3QgdGhlIG9uZSB0byBk
byBSMS4gQmVzaWRlcywgdGhlIGN1cnJlbnQgcHJvcG9zYWwgb25seSB0YWtlcyBjYXJlIG9mIHRo
ZSBjb2RlIGZsb3cuIFRoZSBzYW1lIHJlcXVpcmVtZW50DQogc2hvdWxkIGJlIHRoZXJlIGZvciBp
bXBsaWNpdCBmbG93IGFzIHdlbGwsIHNvIHRoZSBjdXJyZW50IHByb3Bvc2FsIGlzIG5vdCBjb3Zl
cmluZyB0aGUgUjEgYW55d2F5cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgY2FuIHNvcnQgb2YgdW5kZXJzdGFuZCBSMiwg
YnV0IEkgaGF2ZSB0d28gY3JpdGlxdWUgb24gdGhlIGN1cnJlbnQgcHJvcG9zYWw6Jm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5D
MS4gQ3VycmVudCBwcm9wb3NhbCBkb2VzIG5vdCBzdXBwb3J0IHRoZSBpbXBsaWNpdCBmbG93LiBU
byBzdXBwb3J0IGl0LCB0aGUgcmVzb3VyY2UgVVJJIGhhcyB0byBiZSBzZW50IHRvIHRoZSBBdXRo
eiBlbmRwb2ludCBpbnN0ZWFkIG9mIHRoZSBUb2tlbiBlbmRwb2ludC4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QzIuIEl0IGlzIG11
Y2ggbW9yZSBkaXJlY3QgdG8gc2VuZCB0aGUgcmVxdWlyZWQgdG9rZW4gZm9ybWF0IHJhdGhlciB0
aGFuIHRoZSBSUyB1cmkgYW5kIHByb2JhYmx5IGJldHRlciBhczombmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IDEpIFRoZXJl
IGFyZSB1c2UgY2FzZXMgd2hlcmUgdGhlIEFTIGRvZXMgbm90IG1haW50YWluIHRoZSBsaXN0IG9m
IFJTcyB0aGF0IGl0IHN1cHBvcnRzLCBlLmcuLCBBT0wuJm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwO0luIHN1Y2ggYSBjYXNlLCBldmVuIGlmIHRoZSBSUyB1cmkgd2VyZSBzZW50IHRvIHRo
ZSBBUywgdGhlIEFTIGNhbm5vdCBtaW50IHRoZSB0b2tlbnMgaW4gdGhlIGFwcHJvcHJpYXRlIGZv
cm1hdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+Jm5ic3A7IDIpIFdoZW4gaXQgaXMgc2VudCBpbiB0aGUgQXV0aHogcmVxdWVzdCwg
aXQgaXMgbGVha2luZyB0aGUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHJlc291cmNlIHRoYXQgdGhl
IGNsaWVudCBpcyBnb2luZyB0byB0aGUgYnJvd3Nlci4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IDMpIFRoZXJlIGFyZSB1
c2UgY2FzZXMgd2hlcmUgaXQgaXMgZGVzaXJhYmxlIG5vdCB0byBsZXQgdGhlIEFTIGtub3dzIHdo
ZXJlIHRoZSBDbGllbnQgaXMgZ29pbmcgZnJvbSB0aGUgcHJpdmFjeSBwb2ludCBvZiB2aWV3LiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+U28sIG15IHN1Z2dlc3Rpb24gaXMgdG8gZHJvcCBSMSBhbmQgY29uY2VudHJhdGUgb24g
UjIuIEFuZCB0byBzb2x2ZSBSMiwgc2VuZCB0b2tlbiB0eXBlIGluc3RlYWQgb2YgdGhlIHJlc291
cmNlIGluZGljYXRvciBpbiB0aGUgcmVxdWVzdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhpcyBhbHNvIG5lY2Vzc2l0YXRlcyB0
aGUgQ2xpZW50IHRvIGJlIGFibGUgdG8gZmluZCBvdXQgd2hhdCB0b2tlbiB0eXBlIHRoZSByZXNv
dXJjZSByZXF1aXJlcywgcGVyaGFwcyBpbiB0aGUgdW5hdXRob3JpemVkIHJlc3BvbnNlIHdlYiBs
aW5rIGhlYWRlciBhdCB0aGUgcmVzb3VyY2UgaW4gdGhlIG1hbm5lcg0KIG9mIG9hdXRoLW1ldGEu
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj5DaGVlcnMsJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj5OYXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MjAxNjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuW5tDwvc3Bhbj40PHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5pyIPC9zcGFuPjg8c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7ml6U8L3NwYW4+KDxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPumHkTwvc3Bhbj4pDQogODoyMyBQ
cmF0ZWVrIE1pc2hyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOlByYXRlZWsuTWlzaHJhQG9yYWNsZS5j
b20iIHRhcmdldD0iX2JsYW5rIj5QcmF0ZWVrLk1pc2hyYUBvcmFjbGUuY29tPC9hPiZndDs6PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv
cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu
IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdo
dDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldoaWxl
IHRoaXMgd29yayBhZGRyZXNzZXMgYSBnYXAgaW4gdGhlIGV4aXN0aW5nIE9BdXRoIHNwZWNpZmlj
YXRpb24gc2V0LCBJIGFtIHZlcnkgY29uY2VybmVkIHRoYXQgdGhpczxicj4NCmluY3JlbWVudGFs
IGV4dGVuc2lvbiB3aWxsIGxlYWQgdG8gZXZlbiBtb3JlIGNvbmZ1c2lvbiBhcm91bmQgdGhlIGFy
ZWFzIG9mIOKAnHNjb3Bl4oCdLCDigJxhdWRpZW5jZeKAnSBhbmQg4oCccmVzb3VyY2Ugc2VydmVy
4oCdLjxicj4NCjxicj4NCkkgdGhpbmsgd2Ugc2hvdWxkIHRyeSB0byBzb2x2ZSB0aGlzIHByb2Js
ZW0gdmlhJm5ic3A7IGEgZnJhbWV3b3JrIHRoYXQgcHJvdmlkZXMgYmV0dGVyIGd1aWRhbmNlIGFu
ZCBpbXBsZW1lbnRhdGlvbjxicj4NCm1vZGVscyBmb3IgT0F1dGggdXNlLWNhc2VzLiBJbiBvdGhl
ciB3b3JkcywgSSBmZWVsIHRoYXQgYSBicm9hZGVyIGRpc2N1c3Npb24gaXMgbmVlZGVkIGhlcmUu
PGJyPg0KPGJyPg0KPGJyPg0KJmd0OyBPbiBBcHIgNywgMjAxNiwgYXQgNDoxMSBQTSwgSnVzdGlu
IFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxh
bmsiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7IEkg
c3VwcG9ydCBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50IGFzIGEgc3RhcnRpbmcgcG9pbnQgZm9y
IHdvcmtpbmcgZ3JvdXAgd29yay48YnI+DQomZ3Q7PGJyPg0KJmd0OyDigJQgSnVzdGluPGJyPg0K
Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyBPbiBBcHIgNiwgMjAxNiwgYXQgMToyNSBQTSwg
SGFubmVzIFRzY2hvZmVuaWcgJmx0OzxhIGhyZWY9Im1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0Bn
bXgubmV0IiB0YXJnZXQ9Il9ibGFuayI+aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDwvYT4mZ3Q7
IHdyb3RlOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSGkgYWxsLDxicj4NCiZndDsmZ3Q7
PGJyPg0KJmd0OyZndDsgdGhpcyBpcyB0aGUgY2FsbCBmb3IgYWRvcHRpb24gb2YgJ1Jlc291cmNl
IEluZGljYXRvcnMgZm9yIE9BdXRoIDIuMCcsIHNlZTxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0
dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2El
MmYlMmZkYXRhdHJhY2tlci5pZXRmLm9yZyUyZmRvYyUyZmRyYWZ0LWNhbXBiZWxsLW9hdXRoLXJl
c291cmNlLWluZGljYXRvcnMlMmYmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3Nv
ZnQuY29tJTdjOTU5MGU0MDI1ZWI2NDQyZWNlZGUwOGQzNjIzZmM5NjElN2M3MmY5ODhiZjg2ZjE0
MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPXk4NjlGazk5ODdmZjA5aHZISU4lMmJW
R2wlMmZxeHdXRG1rdk93emNRY1dxWFp3JTNkIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vZGF0
YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNhbXBiZWxsLW9hdXRoLXJlc291cmNlLWluZGlj
YXRvcnMvPC9hPjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgUGxlYXNlIGxldCB1cyBrbm93
IGJ5IEFwcmlsIDIwdGggd2hldGhlciB5b3UgYWNjZXB0IC8gb2JqZWN0IHRvIHRoZTxicj4NCiZn
dDsmZ3Q7IGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgYXMgYSBzdGFydGluZyBwb2ludCBmb3Ig
d29yayBpbiB0aGUgT0F1dGg8YnI+DQomZ3Q7Jmd0OyB3b3JraW5nIGdyb3VwLjxicj4NCiZndDsm
Z3Q7PGJyPg0KJmd0OyZndDsgTm90ZTogSWYgeW91IGFscmVhZHkgc3RhdGVkIHlvdXIgb3Bpbmlv
biBhdCB0aGUgSUVURiBtZWV0aW5nIGluIEJ1ZW5vczxicj4NCiZndDsmZ3Q7IEFpcmVzIHRoZW4g
eW91IGRvbid0IG5lZWQgdG8gcmUtc3RhdGUgeW91ciBvcGluaW9uLCBpZiB5b3Ugd2FudC48YnI+
DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoZSBmZWVkYmFjayBhdCB0aGUgQkEgSUVURiBtZWV0
aW5nIHdhcyB0aGUgZm9sbG93aW5nOiB+MTAgcGVyc29uczxicj4NCiZndDsmZ3Q7IGZvciBhY2Nl
cHRpbmcgdGhlIGRvY3VtZW50IGFuZCAwIHBlcnNvbnMgYWdhaW5zdC48YnI+DQomZ3Q7Jmd0Ozxi
cj4NCiZndDsmZ3Q7IENpYW88YnI+DQomZ3Q7Jmd0OyBIYW5uZXMgJmFtcDsgRGVyZWs8YnI+DQom
Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZn
dDsgPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhA
aWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5r
cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmcl
MmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0
MG1pY3Jvc29mdC5jb20lN2M5NTkwZTQwMjVlYjY0NDJlY2VkZTA4ZDM2MjNmYzk2MSU3YzcyZjk4
OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9YmZwMURHSDVqJTJidE00
WnR4N00lMmJ1ZUs3S3hWNmtOSkVYWktIRUNJVUtpQlElM2QiIHRhcmdldD0iX2JsYW5rIj4NCmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0Ozxi
cj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188
YnI+DQomZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOk9B
dXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0
OyA8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v
P3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9h
dXRoJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Yzk1OTBlNDAy
NWViNjQ0MmVjZWRlMDhkMzYyM2ZjOTYxJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRi
NDclN2MxJmFtcDtzZGF0YT1iZnAxREdINWolMmJ0TTRadHg3TSUyYnVlSzdLeFY2a05KRVhaS0hF
Q0lVS2lCUSUzZCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy
ZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3Jn
PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs
b29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3Rp
bmZvJTJmb2F1dGgmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdj
OTU5MGU0MDI1ZWI2NDQyZWNlZGUwOGQzNjIzZmM5NjElN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk
N2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPWJmcDFER0g1aiUyYnRNNFp0eDdNJTJidWVLN0t4VjZr
TkpFWFpLSEVDSVVLaUJRJTNkIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5n
IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r
Ij5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtz
LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUy
Zm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQw
bWljcm9zb2Z0LmNvbSU3Yzk1OTBlNDAyNWViNjQ0MmVjZWRlMDhkMzYyM2ZjOTYxJTdjNzJmOTg4
YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1iZnAxREdINWolMmJ0TTRa
dHg3TSUyYnVlSzdLeFY2a05KRVhaS0hFQ0lVS2lCUSUzZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+
DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i
bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_BN3PR0301MB1234B7AF83F059E441B3B593A6940BN3PR0301MB1234_--


From nobody Mon Apr 11 13:37:16 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E36E12F42C for ; Mon, 11 Apr 2016 13:37:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQfxS5HqoWkU for ; Mon, 11 Apr 2016 13:37:12 -0700 (PDT)
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 4018C12F42E for ; Mon, 11 Apr 2016 13:37:12 -0700 (PDT)
Received: by mail-io0-x22f.google.com with SMTP id 2so1799702ioy.1 for ; Mon, 11 Apr 2016 13:37:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ASg0lNQXOWq0+CxYbdmXa0FFt0XBMPMvOzbbzqL+fgo=; b=padnq1jRyFP/c7f3sYcN2ljn2wKvMScX4kPZj03am7xkNHbLRpVVy9QheCbxZXN1Iv Gf06JBVgBoGCD2F2GPPV6BNAnbZWbwPbDSZqtL89+yAM8qyUIzADqCdUXd+3AUU6l7lA hNBSXLnjA1F70fRoUwvUR3wdzOY2s8+IElzcU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ASg0lNQXOWq0+CxYbdmXa0FFt0XBMPMvOzbbzqL+fgo=; b=guFJRHAHajAt9/nRPC9XeNVhQD280cS7Vs4VgEFFWUXuyIJKIjg/3YR7gJKEOAElKk MA0uyGAxzyw51bShqitrxMFrewhZQTI3fAGaWg2ckfvLZFjn8/poakssB/Jv0H1m2Gni 1N4W0+FjxW9DfCxDvBY4zlKzNDeb4tOTMqwiJ2mQkwxz9TXOsQeSFSuaVMQiKy6Of03V G2ao+380PicXhqbT+OwCP5nUGi5K2RyIK2VcllTRIB8L/+JIuliK3RBhowz+kEw4HwMb fDZ/PjcDmmFKn9xuKqJ83wtqV5QhTRjURWrABB4eqSu29aM277kZ0fPKaXW43Pnjf9gT mKsg==
X-Gm-Message-State: AOPr4FWx3VK5su9i5YRxbSeXXDhozle3G2Y6XOpH+5VBgoEOmYlDlGoQEP+2QkaWbfS8DCMS/MkW9HyrlwQUbG2+
X-Received: by 10.107.13.133 with SMTP id 127mr1310ion.129.1460407031494; Mon, 11 Apr 2016 13:37:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.74.162 with HTTP; Mon, 11 Apr 2016 13:36:42 -0700 (PDT)
In-Reply-To: 
References:  
From: Brian Campbell 
Date: Mon, 11 Apr 2016 14:36:42 -0600
Message-ID: 
To: Adam Lewis 
Content-Type: multipart/alternative; boundary=001a113ffc70570f2005303b828e
Archived-At: 
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Question on draft-ietf-oauth-token-exchange-04
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Apr 2016 20:37:15 -0000

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

I will work to try and clarify in the next draft but would happily listen
to suggestions.

On Mon, Apr 11, 2016 at 2:26 PM, Brian Campbell 
wrote:

> The intent is that urn:ietf:params:oauth:token-type:access_token be an
> indicator that the token is a typical OAuth access token issued by the AS
> in question, opaque to the client, and usable the same manner as any other
> access token obtained from that AS (it could well be a JWT but the client
> isn't and needn't be aware of that fact). Whereas
> urn:ietf:params:oauth:token-type:jwt is to indicate that a JWT specifically
> is being requested or sent (perhaps in a cross-domain use case to get an
> access token from a different AS like is facilitated by RFC 7523).
>
> Is that helpful at all?
>
> I agree that it can be confusing. But it's representative of the kinds of
> tokens and their usages out there now. So, needs to be allowed. I'd welcome
> ideas about how the language could be improved to help alleviate some of
> the confusion though.
>
> On Mon, Apr 11, 2016 at 7:25 AM, Adam Lewis <
> adam.lewis@motorolasolutions.com> wrote:
>
>> Hi,
>>
>> There are multiple places in draft-ietf-oauth-token-exchange-04 where a
>> differentiation seems to be drawn between 'access_token' and 'jwt' ... for
>> example in section 2.2.1. when discussing the issued_token_type, it states:
>>
>>       a value of "urn:ietf:params:oauth:token-type:access_token" indicates
>>
>>       that the issued token is an access token and a value of
>>       "urn:ietf:params:oauth:token-type:jwt" indicates that it is a JWT.
>>
>>
>> This is confusing to me because an access token represents a delegated authorization decision, whereas JWT is a token *format*.  An access token could easily be a JWT (and in many deployments, they are).
>>
>>
>> So why the desire to differentiate, and what does the differentiation mean?
>>
>>
>>
>> tx!
>> adam
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>

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


I will work to try and clarify in the next draft but would=
 happily listen to suggestions. 

On Mon, Apr 11, 2016 at 2:26 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
The intent is that urn:iet=
f:params:oauth:token-type:access_token be an indicator that the token is a =
typical OAuth access token issued by the AS in question, opaque to the clie=
nt, and usable the same manner as any other access token obtained from that=
 AS (it could well be a JWT but the client isn't and needn't be awa=
re of that fact). Whereas urn:ietf:params:oauth:token-type:jwt is to indica=
te that a JWT specifically is being requested or sent (perhaps in a cross-d=
omain use case to get an access token from a different AS like is facilitat=
ed by RFC 7523). 

Is that helpful at all?

I agree=
 that it can be confusing. But it's representative of the kinds of toke=
ns and their usages out there now. So, needs to be allowed. I'd welcome=
 ideas about how the language could be improved to help alleviate some of t=
he confusion though. 

On Mon, Apr 11, 2016 at 7:25 AM,=
 Adam Lewis <adam.lewis@motorolasolutions.com> wrote:
Hi,

There are multiple places in=C2=
=A0draft-ietf-oauth-token-exchange-04 where a differentiation seems to be d=
rawn between 'access_token' and 'jwt' ... for example in se=
ction 2.2.1. when discussing the issued_token_type, it states:
      a value of "urn:ietf:params:oauth:token-t=
ype:access_token" indicates=C2=A0
      that the issued=
 token is an access token and a value of
      "urn:ietf:params:oauth:token-type:jwt" indicates that it is=
 a JWT.

T=
his is confusing to me because an access token represents a delegated autho=
rization=C2=A0decision, whereas JWT is a token *format*.=C2=A0 An access to=
ken could easily be a JWT (and in many deployments, they are). =C2=A0

So why the desire to differentiate, and =
what does the differentiation mean?


tx!
adam


_______________________________________________

OAuth mailing list

OAuth@ietf.org

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








--001a113ffc70570f2005303b828e--


From nobody Mon Apr 11 14:14:13 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52ECB12DD5C for ; Mon, 11 Apr 2016 14:14:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Level: 
X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jive-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8v5K3KEPXYw5 for ; Mon, 11 Apr 2016 14:14:09 -0700 (PDT)
Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00DCC12DC74 for ; Mon, 11 Apr 2016 14:14:08 -0700 (PDT)
Received: by mail-io0-x230.google.com with SMTP id u185so2865537iod.3 for ; Mon, 11 Apr 2016 14:14:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jive-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Um86Ykb4LG5bOQT6dbYTeBn0JnC7LX1QmAscCxeFHRM=; b=MnjNGy6XJaJj3VFwsNEaSwr/W2LLPFj6BT9J+E2O6gBv9D5M/b2dWu0gLtYJGhXDVY mauPLICWoP+sKw38yeYIdZu8cw5W1yOohbLPTRQPz4/CqapQclXH4HY1cG8X338nCjuv iWRP6YtxVnleDZpcDUZCBwr98P5Ko3+5qDzu669swLgePui6YRREMBALnZY4a9rEeR50 Pe3eehqJ1lF53Tj+cQI0x0UJF258A5PrSHf+zSBnSKNAC/l0L3xZsf88osGAtdN6V0Ii Hmc8tGvmiWr2r1y4eThEPlBf3DzB3RmTSp5Gop6pm/m9k2HdYsyUhPNWpQB8bOozUFLK AAmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Um86Ykb4LG5bOQT6dbYTeBn0JnC7LX1QmAscCxeFHRM=; b=KksfupLxjc7NPPKjOMDFOBtNMXO+lbf2rgIclL/ie9YNhRtYPGAewMPc9f1Eje2u+A TgIufK2TdLlDcHN8IMceDjd25KcndwriOzMdPETXpE5WW6dxxxLBJOZIj/wM8Zqq7J5C GgwXtfpcPWH8k8+yMWLkjC6UedbjZ0ZDEXRvzxJIUDBKIifyF2PFgW2osA6zrggqSGrf E0l+QPzRkVZPK1iBmHpoLubrT6wurjVxjMkGtTQemlqBMyHdl7zLuIm3tk3yravHp+zS +3BENRwmBAyftjZpKqU5Xbvvc3K4dQsPOREyIGxVj8jBUfCzoDECgqZ6zcHFFCx0ScHP y0VQ==
X-Gm-Message-State: AOPr4FWeL05iZark/mwc+oSfp1foHaHESZOhvH8oyj2R74aPz2Enl9Ri1I3lNGQyKbG0LY4q/ENPh2qSHI0Y8BVIQuqMCtKMdT1VdhP6nVyi+N0K9qVJbtT0AOtbI8u7U/Mqb3Bb
MIME-Version: 1.0
X-Received: by 10.107.128.26 with SMTP id b26mr151227iod.87.1460409248194; Mon, 11 Apr 2016 14:14:08 -0700 (PDT)
Received: by 10.36.62.69 with HTTP; Mon, 11 Apr 2016 14:14:08 -0700 (PDT)
In-Reply-To: 
References:  
Date: Mon, 11 Apr 2016 15:14:08 -0600
Message-ID: 
From: Eduardo Gueiros 
To: John Bradley 
Content-Type: multipart/alternative; boundary=001a113eb78a7741bf05303c0669
Archived-At: 
Cc: "" , Andy Zmolek 
Subject: Re: [OAUTH-WG] OAuth 2.0 for Native Apps: open source client libraries
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Apr 2016 21:14:11 -0000

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

No, no especial need at this time. It was more out of curiosity, you guys
did a great work...and quick too!

I mean, It's just nice for a new project in Swift to be able to work with
Swift libraries instead of having to mock with bridging files and @objc
annotations. But again, not a strong reason at this time.

I did find https://github.com/p2/OAuth2 which is Swift and adheres to the
Best Practices document by using SFSafariViewController for OAuth, so since
someone else is working on it I will not be volunteering to re-invent the
wheel :)

Keep up the good work!


On Sat, Apr 2, 2016 at 6:44 AM, John Bradley  wrote:

> The current iOS version works just fine with apps written in Swift.
>
> I don=E2=80=99t know that there is a compelling reason to support two cod=
e bases
> on the same platform as long as the SDK supports all the development tool=
s.
>
> Other than as an example, do you have a reason for needing it in Swift?
>
> At the moment the focus is more on expanding the functionality.
>
> Adding options for creating and validating JWT/id_tokens,  JWE encryption
> support ,  Token binding for refresh tokens that can use the TPM for
> security,  Application Configuration via a EMM (AppConfig) ,  Alignment
> with the the GSMA Mobile Connect SDK so that developers don=E2=80=99t win=
d up
> needing one SDK for Azure and another to support the Mobile Network
> Operator openID service.
>
> Let us know what directions are important to you.
>
> Regards
> John B.
>
> > On Apr 1, 2016, at 10:39 PM, Andy Zmolek  wrote:
> >
> > > Any plan to bring the libraries to more ?young? languages like Swift
> in iOS and Kotlin in Android?
> >
> > Are you volunteering?
> > _______________________________________________
> > OAuth mailing 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
*Eduardo Gueiros*
*Director, Mobile B.U.* |  Jive Communications, Inc.
jive.com  |  *egueiros@jive.com *

 



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


No, no especial need at this time. It was more out of curi=
osity, you guys did a great work...and quick too!=C2=A0

=
I mean, It's just nice for a new project in Swift to be able to work wi=
th Swift libraries instead of having to mock with bridging files and @objc =
annotations. But again, not a strong reason at this time.

I did find=C2=A0https://github.c=
om/p2/OAuth2 which is Swift and adheres to the Best Practices document =
by using SFSafariViewController for OAuth, so since someone else is working=
 on it I will not be volunteering to re-invent the wheel :)

Keep up the good work!


On Sat, Apr 2, 2016 at 6:44=
 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
The current iOS version works just fine with apps writte=
n in Swift.



I don=E2=80=99t know that there is a compelling reason to support two code =
bases on the same platform as long as the SDK supports all the development =
tools.



Other than as an example, do you have a reason for needing it in Swift?



At the moment the focus is more on expanding the functionality.



Adding options for creating and validating JWT/id_tokens,=C2=A0 JWE encrypt=
ion support ,=C2=A0 Token binding for refresh tokens that can use the TPM f=
or security,=C2=A0 Application Configuration via a EMM (AppConfig) ,=C2=A0 =
Alignment with the the GSMA Mobile Connect SDK so that developers don=E2=80=
=99t wind up needing one SDK for Azure and another to support the Mobile Ne=
twork Operator openID service.



Let us know what directions are important to you.



Regards

John B.



> On Apr 1, 2016, at 10:39 PM, Andy Zmolek <zmolek@google.com> wrote:

>

> > Any plan to bring the libraries to more ?young? languages like Sw=
ift in iOS and Kotlin in Android?

>

> Are you volunteering?

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org

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



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





-- 
--=C2=A0
Eduardo GueirosDirector, Mobile B.U.=C2=A0| =C2=A0Jive Communications, Inc.
jive.com=C2=A0=C2=A0=
| =C2=A0egueiros@jive.com
3D""




--001a113eb78a7741bf05303c0669--


From nobody Mon Apr 11 15:20:04 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40FE12F56B for ; Mon, 11 Apr 2016 15:20:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.196
X-Spam-Level: 
X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljfMy52pA4Vu for ; Mon, 11 Apr 2016 15:20:01 -0700 (PDT)
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 F167C12F56A for ; Mon, 11 Apr 2016 15:20:00 -0700 (PDT)
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u3BMJxUM022766 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Apr 2016 22:20:00 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 u3BMJx2r021775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Apr 2016 22:19:59 GMT
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u3BMJxnv001693; Mon, 11 Apr 2016 22:19:59 GMT
Received: from [25.173.235.224] (/24.114.26.135) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 11 Apr 2016 15:19:58 -0700
Content-Type: multipart/alternative; boundary=Apple-Mail-38217915-68B0-446E-A6D0-B3179FCFE1C2
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13E238)
In-Reply-To: 
Date: Mon, 11 Apr 2016 15:19:57 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <824192A8-4F6F-4002-B7E0-518CAA0BF34A@oracle.com>
References: <2D15E964-8A56-417C-A3CB-78CFAB5DFA34@oracle.com> 
To: Brian Campbell 
X-Source-IP: userv0021.oracle.com [156.151.31.71]
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Regarding using resource indicator to solve resource config issue
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Apr 2016 22:20:02 -0000

--Apple-Mail-38217915-68B0-446E-A6D0-B3179FCFE1C2
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

I am objecting to modifying the protocol in the default case as a majority d=
o not need RI in the case of fixed endpoints.=20

Migration would be challenging because the change is breaking and affects ex=
isting clients.=20

Dynamic discovery are up and coming cases and a relatively green field. Deal=
ing with it at configuration/discovery makes broader sense as it has no impa=
ct on existing clients.=20

Phil

> On Apr 11, 2016, at 12:18, Brian Campbell  wro=
te:
>=20
> I'm not sure where the idea that it's only applicable to special uses like=
 collaboration services is coming from. The pattern described in the draft (=
using a different parameter name but otherwise the same) is deployed and in-=
use for normal OAuth cases including and especially the resource owner centr=
ic ones.=20
>=20
>=20
>> On Mon, Apr 11, 2016 at 11:33 AM, Phil Hunt (IDM)  w=
rote:
>> I am finding I am not happy with solving the bad resource endpoint config=
 issue with resource indicator. At best I see this as a special use draft fo=
r things like collab services or things which aren't resource owner centric.=

>>=20
>> Yet resource endpoint config is a concern for all clients that configure o=
n the fly. Is it reasonable to make resource indicator mandatory for all cli=
ents? Probably not.
>>=20
>> As OAuth depends primarily on TLS, it feels wrong not to have a solution t=
hat confirms the server host names are correct either via config lookup or s=
ome other mechanism.
>>=20
>> Tokbind is also a solution but I suspect it may only appeal to large scal=
e service providers and may be further off as we wait for load balancers to s=
upport tokbind. Also there are issues with tokbind on initial user binding w=
here the mitm attack might itself establish its own token binding. I have to=
 think this through some to confirm. But the issue of worry is what is happe=
ning on initialization and first use if the hacker has already interceded a m=
itm. That would make validation at config time still critical.
>>=20
>> Hopefully somebody can arrive at an alternative for broader oauth use cas=
es.
>>=20
>> Phil
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20

--Apple-Mail-38217915-68B0-446E-A6D0-B3179FCFE1C2
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


I am objecting to modifying the protoc=
ol in the default case as a majority do not need RI in the case of fixed end=
points. 

Migration would be challenging because the change is breaking=
 and affects existing clients. 
Dynamic discovery are up and coming ca=
ses and a relatively green field. Dealing with it at configuration/discovery=
 makes broader sense as it has no impact on existing clients. 

P=
hil

On Apr 11, 2016, at 12:18, Brian Campbell <bcampbell@pingidentity.com> wrote:<=
br>
I'm not sure wh=
ere the idea that it's only applicable to special uses like collaboration se=
rvices is coming from. The pattern described in the draft (using a different=
 parameter name but otherwise the same) is deployed and in-use for normal OA=
uth cases including and especially the resource owner centric ones. 

=
 

On Mon, Apr=
 11, 2016 at 11:33 AM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
I am finding I am not happy with s=
olving the bad resource endpoint config issue with resource indicator. At be=
st I see this as a special use draft for things like collab services or thin=
gs which aren't resource owner centric.



Yet resource endpoint config is a concern for all clients that configure on t=
he fly. Is it reasonable to make resource indicator mandatory for all client=
s? Probably not.



As OAuth depends primarily on TLS, it feels wrong not to have a solution tha=
t confirms the server host names are correct either via config lookup or som=
e other mechanism.



Tokbind is also a solution but I suspect it may only appeal to large scale s=
ervice providers and may be further off as we wait for load balancers to sup=
port tokbind. Also there are issues with tokbind on initial user binding whe=
re the mitm attack might itself establish its own token binding. I have to t=
hink this through some to confirm. But the issue of worry is what is happeni=
ng on initialization and first use if the hacker has already interceded a mi=
tm. That would make validation at config time still critical.



Hopefully somebody can arrive at an alternative for broader oauth use cases.=




Phil

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





=

--Apple-Mail-38217915-68B0-446E-A6D0-B3179FCFE1C2--


From nobody Mon Apr 11 17:53:45 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1940D12DA0F for ; Mon, 11 Apr 2016 17:53:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.696
X-Spam-Level: 
X-Spam-Status: No, score=-3.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9UPvg__exhM for ; Mon, 11 Apr 2016 17:53:42 -0700 (PDT)
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 40B1A12DA04 for ; Mon, 11 Apr 2016 17:53:42 -0700 (PDT)
Received: by mail-oi0-x22d.google.com with SMTP id w85so4006194oiw.0 for ; Mon, 11 Apr 2016 17:53:42 -0700 (PDT)
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; bh=UTFQL2yeTBcLrolJg7JgNt96SqsY0XOJnHVBOG7EVFE=; b=Yh3JJ/hakzL/ZCZVyVn5+6OJQm2NCqJIUoby9zBwf4nyfXUcx2txc0btZLhU8xfxr1 NwIJcUr5njGH2wqSnRD85qrclZdp7E7/nHpN2SxUXiFtelJ8MXO7cowG6eHf9Td/1l9w 5ZNbaI63dqsj/qrwj41eHsAZIRFoSM8uUPd4Fyj+EtBkZjFIzS51BjxUC2nyC2hyXltW wXspWyXjMFFN5bYgZ9Cv8wU55/oB7JXVpfCGRy8Njghgq05WczrPChwoubwRuuyjFmUW LvnSqv3Dc5DQgZPge88M2Gwaq4pP1vbXvCTExEWKaClvavSUHLgvzcwR1SmK9tF3REpp N1zQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UTFQL2yeTBcLrolJg7JgNt96SqsY0XOJnHVBOG7EVFE=; b=eZV1Zed3WVunuGY+lgiPkuD8YT0z2ebiF8vS1YmR9rYAZnh0gClnRxbIKxCcQyNKwV R335FRukia8FBBcgatZOB1/dhmZlRFYAcqi605heBFb/rUTyfZu1h6lKL7KiHf1sEBdZ dNM3jYiwOcmYRLsB8xLCXMoj3h98vMdiv2KeUvvSpx3b58a5V20u4OwLA3GsaNEizpIv FgQYTK9rY7vmUbYRKYltIdhE/QqcuJEQasK0rhZ4AbqtRRg2mwES8F6gs+nchMn0fnBA eAwF2H1F/7UBcBCx01RTriyNV7C8bzTajf/Bi4nhwg2J8/n8cnxpwsALyl+1Rr5Yct6D MfIg==
X-Gm-Message-State: AOPr4FV8gtffLsX/5MrKeD9Lyqixtu63zHgJxIneew1h0rEbaFKjc/UbTWvwGCKHiRyoMm3yglKlNGANxyonWqh+
X-Received: by 10.157.6.65 with SMTP id 59mr179016otn.39.1460422421492; Mon, 11 Apr 2016 17:53:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.78.68 with HTTP; Mon, 11 Apr 2016 17:53:21 -0700 (PDT)
In-Reply-To: 
References:   
From: William Denniss 
Date: Mon, 11 Apr 2016 17:53:21 -0700
Message-ID: 
To: Eduardo Gueiros 
Content-Type: multipart/alternative; boundary=94eb2c0924b6a815a405303f1797
Archived-At: 
Cc: Steven Wright , "" , Andy Zmolek 
Subject: Re: [OAUTH-WG] OAuth 2.0 for Native Apps: open source client libraries
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Apr 2016 00:53:44 -0000

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

On Mon, Apr 11, 2016 at 2:14 PM, Eduardo Gueiros  wrote:

> No, no especial need at this time. It was more out of curiosity, you guys
> did a great work...and quick too!
>

Thanks :-)


> I mean, It's just nice for a new project in Swift to be able to work with
> Swift libraries instead of having to mock with bridging files and @objc
> annotations. But again, not a strong reason at this time.
>

One thing we need to do is publish an example in Swift showing the
integration, and test it all. I've created
https://github.com/openid/AppAuth-iOS/issues/19 to track that, feel free to
subscribe.

I'm hoping we can create a seamless experience for Swift developers, so
that (in so much as possible) it won't matter to them what language the
underlying library is written in. I don't see any value in the extra work
of porting the library if we can get it working well in Swift. But we do
need to verify that, add Swift it to our testing, and get out a sample.

I did find https://github.com/p2/OAuth2 which is Swift and adheres to the
> Best Practices document by using SFSafariViewController for OAuth, so sin=
ce
> someone else is working on it I will not be volunteering to re-invent the
> wheel :)
>

p2/OAuth2 doesn't appear to be following the draft best practice
 fully, it
doesn't send PKCE, and is currently recommending using WebView to sign-in
to Google on iOS (filed a bug  for
the latter).

Keep up the good work!
>

Thanks for the feedback!


On Sat, Apr 2, 2016 at 6:44 AM, John Bradley  wrote:
>
>> The current iOS version works just fine with apps written in Swift.
>>
>> I don=E2=80=99t know that there is a compelling reason to support two co=
de bases
>> on the same platform as long as the SDK supports all the development too=
ls.
>>
>> Other than as an example, do you have a reason for needing it in Swift?
>>
>> At the moment the focus is more on expanding the functionality.
>>
>> Adding options for creating and validating JWT/id_tokens,  JWE encryptio=
n
>> support ,  Token binding for refresh tokens that can use the TPM for
>> security,  Application Configuration via a EMM (AppConfig) ,  Alignment
>> with the the GSMA Mobile Connect SDK so that developers don=E2=80=99t wi=
nd up
>> needing one SDK for Azure and another to support the Mobile Network
>> Operator openID service.
>>
>> Let us know what directions are important to you.
>>
>> Regards
>> John B.
>>
>> > On Apr 1, 2016, at 10:39 PM, Andy Zmolek  wrote:
>> >
>> > > Any plan to bring the libraries to more ?young? languages like Swift
>> in iOS and Kotlin in Android?
>> >
>> > Are you volunteering?
>> > _______________________________________________
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
>
> --
> --
> *Eduardo Gueiros*
> *Director, Mobile B.U.* |  Jive Communications, Inc.
> jive.com  |  *egueiros@jive.com *
> 
>  
> 
> 
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

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



On Mon, Apr 11, 2016 at 2:14 PM, Eduardo Gueiros <egueiro=
s@jive.com> wrote:
No, n=
o especial need at this time. It was more out of curiosity, you guys did a =
great work...and quick too!=C2=A0

Tha=
nks :-)
=C2=A0
I mean=
, It's just nice for a new project in Swift to be able to work with Swi=
ft libraries instead of having to mock with bridging files and @objc annota=
tions. But again, not a strong reason at this time.

One thing we need to do is publish an example in Swift show=
ing the integration, and test it all. I've created=C2=A0https://gith=
ub.com/openid/AppAuth-iOS/issues/19=C2=A0to track that, feel free to su=
bscribe.

I'm hoping we can create a seamless experience for Swift d=
evelopers, so that (in so much as possible) it won't matter to them wha=
t language the underlying library is written in. I don't see any value =
in the extra work of porting the library if we can get it working well in S=
wift. But we do need to verify that, add Swift it to our testing, and get o=
ut a sample.

I did find=C2=A0https://github.com/p2/OAuth2 which is Swift and adheres to the =
Best Practices document by using SFSafariViewController for OAuth, so since=
 someone else is working on it I will not be volunteering to re-invent the =
wheel :)
=C2=A0
p2/OAuth2 does=
n't appear to be following the draft=C2=A0best practice=
=C2=A0fully, it doesn't send PKCE, and is currently recommending using =
WebView to sign-in to Google on iOS (filed a bug=C2=A0for the latter).
=


Keep up th=
e good work!

Thanks for the fee=
dback!
=C2=A0

On Sat, Apr 2, 2016 at 6:=
44 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
The current iOS version works just fine with apps written in Swift.<=
br>


I don=E2=80=99t know that there is a compelling reason to support two code =
bases on the same platform as long as the SDK supports all the development =
tools.



Other than as an example, do you have a reason for needing it in Swift?



At the moment the focus is more on expanding the functionality.



Adding options for creating and validating JWT/id_tokens,=C2=A0 JWE encrypt=
ion support ,=C2=A0 Token binding for refresh tokens that can use the TPM f=
or security,=C2=A0 Application Configuration via a EMM (AppConfig) ,=C2=A0 =
Alignment with the the GSMA Mobile Connect SDK so that developers don=E2=80=
=99t wind up needing one SDK for Azure and another to support the Mobile Ne=
twork Operator openID service.



Let us know what directions are important to you.



Regards

John B.



> On Apr 1, 2016, at 10:39 PM, Andy Zmolek <zmolek@google.com> wrote:

>

> > Any plan to bring the libraries to more ?young? languages like Sw=
ift in iOS and Kotlin in Android?

>

> Are you volunteering?

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=


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



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





<=
font color=3D"#888888">-- 


_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





--94eb2c0924b6a815a405303f1797--


From nobody Mon Apr 11 22:30:19 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5FB12E420 for ; Mon, 11 Apr 2016 22:30:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.612
X-Spam-Level: 
X-Spam-Status: No, score=-0.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-QCJJ4wUE4h for ; Mon, 11 Apr 2016 22:30:13 -0700 (PDT)
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 1B6B912E3CA for ; Mon, 11 Apr 2016 22:30:12 -0700 (PDT)
Received: from [80.187.113.1] (helo=[10.38.74.239]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84) (envelope-from ) id 1apqtt-0002r5-8K; Tue, 12 Apr 2016 07:30:09 +0200
Content-Type: multipart/alternative; boundary=Apple-Mail-3E764094-5C81-4201-A9AE-6FF9E69C35FE
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt 
X-Mailer: iPad Mail (13E238)
In-Reply-To: 
Date: Tue, 12 Apr 2016 07:30:08 +0200
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <570546A1.8040509@gmx.net> <5AEB6A4A-A325-4069-930F-D034D81E41E5@mit.edu>      
To: Anthony Nadalin 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Apr 2016 05:30:17 -0000

--Apple-Mail-3E764094-5C81-4201-A9AE-6FF9E69C35FE
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Indicating the resource server to the AS allows the AS to automatically sele=
ct token type, encryption scheme and user data to be put into the access tok=
en based on a RS-specific policy. So there is no need to explicitely ask the=
 AS for a certain token format or encryption scheme.=20

> Am 11.04.2016 um 22:35 schrieb Anthony Nadalin :
>=20
> So it=E2=80=99s an incomplete solution then ?
> =20
> From: Brian Campbell [mailto:bcampbell@pingidentity.com]=20
> Sent: Monday, April 11, 2016 1:34 PM
> To: Anthony Nadalin 
> Cc: Nat Sakimura ;  
> Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2=
.0
> =20
> No, I'm not adding requirements for encryption. I was pointing out some of=
 the ways that an access token might be different for different RSs.
>=20
>=20
> =20
> On Mon, Apr 11, 2016 at 2:18 PM, Anthony Nadalin  w=
rote:
> So now you are adding more requirements for encryption ? The more this thr=
ead goes on shows how unstable and not fully thought out this draft is to go=
 through WG adoption.
> =20
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
> Sent: Monday, April 11, 2016 12:30 PM
> To: Nat Sakimura 
> Cc:  
> Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2=
.0
> =20
> Sending a token type is not sufficient. There's more involved than the for=
mat. Many cases need to know if to encrypt and whom to encrypt to.  What cla=
ims to put in the token (or reference by the token). What algorithms and key=
s to use for signing/encryption. =20
>=20
> The statement that the "Current proposal does not support the implicit flo=
w" is incorrect. Among other things, sec 2 has, "When an access token will b=
e returned from the authorization endpoint, the "resource" parameter is used=
 in the authorization request to the authorization endpoint as defined in Se=
ction 4.2.1 of OAuth 2.0 [RFC6749]."
> =20
> On Sun, Apr 10, 2016 at 11:43 AM, Nat Sakimura  wrote:=

> So, my understanding on the rationale/requirements for having this spec ri=
ght now is:=20
> =20
> R1. Authz server wants toprevent the replay by the server that received it=
.=20
> R2. Authz server needs to mint the access token in a variety of format dep=
ending on the resource server and to do that, you need to know which RS is g=
ong to be receiving it.=20
> =20
> To achieve R1, there are couple of methods. The proposed method here is to=
 audience restrict the token, but the same can be achieved by sender constra=
ining the token, e.g., by token binding. As far as I can see, the sentiment o=
f the WG seems to be to use the sender constraint through Token Binding, so f=
rom this respect, this spec is not the one to do R1. Besides, the current pr=
oposal only takes care of the code flow. The same requirement should be ther=
e for implicit flow as well, so the current proposal is not covering the R1 a=
nyways.=20
> =20
> I can sort of understand R2, but I have two critique on the current propos=
al:=20
> =20
> C1. Current proposal does not support the implicit flow. To support it, th=
e resource URI has to be sent to the Authz endpoint instead of the Token end=
point.=20
> C2. It is much more direct to send the required token format rather than t=
he RS uri and probably better as:=20
>   1) There are use cases where the AS does not maintain the list of RSs th=
at it supports, e.g., AOL.=20
>        In such a case, even if the RS uri were sent to the AS, the AS cann=
ot mint the tokens in the appropriate format.=20
>   2) When it is sent in the Authz request, it is leaking the information a=
bout the resource that the client is going to the browser.=20
>   3) There are use cases where it is desirable not to let the AS knows whe=
re the Client is going from the privacy point of view.=20
> =20
> So, my suggestion is to drop R1 and concentrate on R2. And to solve R2, se=
nd token type instead of the resource indicator in the request.=20
> This also necessitates the Client to be able to find out what token type t=
he resource requires, perhaps in the unauthorized response web link header a=
t the resource in the manner of oauth-meta.=20
> =20
> Cheers,=20
> =20
> Nat
> =20
> =20
> =20
> 2016=E5=B9=B44=E6=9C=888=E6=97=A5(=E9=87=91) 8:23 Prateek Mishra :
> While this work addresses a gap in the existing OAuth specification set, I=
 am very concerned that this
> incremental extension will lead to even more confusion around the areas of=
 =E2=80=9Cscope=E2=80=9D, =E2=80=9Caudience=E2=80=9D and =E2=80=9Cresource s=
erver=E2=80=9D.
>=20
> I think we should try to solve this problem via  a framework that provides=
 better guidance and implementation
> models for OAuth use-cases. In other words, I feel that a broader discussi=
on is needed here.
>=20
>=20
> > On Apr 7, 2016, at 4:11 PM, Justin Richer  wrote:
> >
> > I support adoption of this document as a starting point for working grou=
p work.
> >
> > =E2=80=94 Justin
> >
> >
> >> On Apr 6, 2016, at 1:25 PM, Hannes Tschofenig  wrote:
> >>
> >> Hi all,
> >>
> >> this is the call for adoption of 'Resource Indicators for OAuth 2.0', s=
ee
> >> http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicator=
s/
> >>
> >> Please let us know by April 20th 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 Buenos
> >> Aires then you don't need to re-state your opinion, if you want.
> >>
> >> The feedback at the BA IETF meeting was the following: ~10 persons
> >> for accepting the document and 0 persons against.
> >>
> >> 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
>=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

--Apple-Mail-3E764094-5C81-4201-A9AE-6FF9E69C35FE
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Indicating the resource ser=
ver to the AS allows the AS to automatically select token type, encryption s=
cheme and user data to be put into the access token based on a RS-specific p=
olicy. So there is no need to explicitely ask the AS for a certain token for=
mat or encryption scheme. 

Am 11.04.2016 um 22:35 schrieb=
 Anthony Nadalin <tonynad@micros=
oft.com>:











So it=E2=80=99s an incomplete solution then ?


 <=
/a>



From: Brian Campbell [mailto:bcampbell@pingidentity.com]


Sent: Monday, April 11, 2016 1:34 PM

To: Anthony Nadalin <tony=
nad@microsoft.com>

Cc: Nat Sakimura <sakimura@g=
mail.com>; <oauth@ietf.org&g=
t; <oauth@ietf.org>

Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OA=
uth 2.0


 




No, I'm not adding req=
uirements for encryption. I was pointing out some of the ways that an access=
 token might be different for different RSs.










 




On Mon, Apr 11, 2016 at 2:18 PM, Anthony Nadalin <=
tonynad@microsoft=
.com> wrote:








So now you are adding more requirements for encryption ? The more th=
is thread goes on shows how unstable and not
 fully thought out this draft is to go through WG adoption.


 <=
o:p>


From: OAuth [mailto:oauth-bounces@ietf.org]
On Behalf Of Brian Campbell

Sent: Monday, April 11, 2016 12:30 PM

To: Nat Sakimura <sakimura@gmail.com>

Cc: <oauth@iet=
f.org> <oauth@=
ietf.org>

Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OA=
uth 2.0






 




Sending a token type is not sufficient. There's more involved than t=
he format. Many cases need to know if to encrypt and whom to encrypt to.&nbs=
p; What claims to put in the token (or
 reference by the token). What algorithms and keys to use for signing/encryp=
tion.  













The statement that the "Current proposal does not support the implicit flow"=
 is incorrect. Among other things, sec 2 has, "When an access token will be r=
eturned from the authorization endpoint, the "resource" parameter is used in=
 the authorization request to
 the authorization endpoint as defined in Section 4.2.1 of OAuth 2.0 [RFC674=
9]."














 




On Sun, Apr 10, 2016 at 11:43 AM, Nat Sakimura <sakimura@gmail.com> wrote:






So, my understanding on the rationale/requirements for having this s=
pec right now is: 




 






R1. Authz server wants toprevent the replay by the server that recei=
ved it. 






R2. Authz server needs to mint the access token in a variety of form=
at depending on the resource server and to do that, you need to know which R=
S is gong to be receiving it. 






 






To achieve R1, there are couple of methods. The proposed method here=
 is to audience restrict the token, but the same can be achieved by sender c=
onstraining the token, e.g., by token
 binding. As far as I can see, the sentiment of the WG seems to be to use th=
e sender constraint through Token Binding, so from this respect, this spec i=
s not the one to do R1. Besides, the current proposal only takes care of the=
 code flow. The same requirement
 should be there for implicit flow as well, so the current proposal is not c=
overing the R1 anyways. 






 






I can sort of understand R2, but I have two critique on the current p=
roposal: 






 






C1. Current proposal does not support the implicit flow. To support i=
t, the resource URI has to be sent to the Authz endpoint instead of the Toke=
n endpoint. 






C2. It is much more direct to send the required token format rather t=
han the RS uri and probably better as: 






  1) There are use cases where the AS does not maintain the lis=
t of RSs that it supports, e.g., AOL. 






       In such a case, even if the RS uri were s=
ent to the AS, the AS cannot mint the tokens in the appropriate format. =
;






  2) When it is sent in the Authz request, it is leaking the in=
formation about the resource that the client is going to the browser. <=
o:p>






  3) There are use cases where it is desirable not to let the A=
S knows where the Client is going from the privacy point of view. =







 






So, my suggestion is to drop R1 and concentrate on R2. And to solve R=
2, send token type instead of the resource indicator in the request. 






This also necessitates the Client to be able to find out what token t=
ype the resource requires, perhaps in the unauthorized response web link hea=
der at the resource in the manner
 of oauth-meta. 






 






Cheers, 






 






Nat






 






 






 






2016=E5=B9=B44=E6=9C=888=E6=97=A5(=E9=87=91)
 8:23 Prateek Mishra <Prateek.Mishra@oracle.com>:










While this work addresses a gap in the existing OAuth specification s=
et, I am very concerned that this

incremental extension will lead to even more confusion around the areas of =E2=
=80=9Cscope=E2=80=9D, =E2=80=9Caudience=E2=80=9D and =E2=80=9Cresource serve=
r=E2=80=9D.



I think we should try to solve this problem via  a framework that provi=
des better guidance and implementation

models for OAuth use-cases. In other words, I feel that a broader discussion=
 is needed here.





> On Apr 7, 2016, at 4:11 PM, Justin Richer <jricher@mit.edu> wrote:

>

> I support adoption of this document as a starting point for working gro=
up work.

>

> =E2=80=94 Justin

>

>

>> On Apr 6, 2016, at 1:25 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net&=
gt; wrote:

>>

>> Hi all,

>>

>> this is the call for adoption of 'Resource Indicators for OAuth 2.0=
', see

>> 
http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/

>>

>> Please let us know by April 20th 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 Bue=
nos

>> Aires then you don't need to re-state your opinion, if you want.
>>

>> The feedback at the BA IETF meeting was the following: ~10 persons<=
br>
>> for accepting the document and 0 persons against.

>>

>> Ciao

>> Hannes & Derek

>>

>> _______________________________________________

>> OAuth mailing list

>> OAuth@ietf.org<=
/a>

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

>

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org<=
br>
> 
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/mailman/listinfo/oauth<=
/p>





 
















 








____________________=
___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai=
lman/listinfo/oauth
=

--Apple-Mail-3E764094-5C81-4201-A9AE-6FF9E69C35FE--


From nobody Tue Apr 12 01:30:56 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B989712D6AB for ; Tue, 12 Apr 2016 01:30:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSfTb0av_MtM for ; Tue, 12 Apr 2016 01:30:52 -0700 (PDT)
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 E3FA812D6BB for ; Tue, 12 Apr 2016 01:30:50 -0700 (PDT)
Received: by mail-lf0-x230.google.com with SMTP id c126so14776795lfb.2 for ; Tue, 12 Apr 2016 01:30:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=9N8prPn/l5lynGZ9hq4y32W0mrb4tQpYTbn+0EOaBjA=; b=p1JxmOsE7vgquPhKw5fRiWGo+ljZ5s0C+gHu65cnCxxqC4kiwGgcVzhRUmatpu2sNy 7P7DnogggweXj2cAsSO2IdqDbezmxFI6V/acYEPULVJiQnctS2q3+dMecBvfLVOUw1q6 K0R4a75NO5EGTH0gU6P9uXPsJ15xR6NfAhqkixxxamqxxWeQJfo3OUoIh2f8+GSyVfrh JsMtcWfvIeVfhhMdLrLfpLLtlKz1CVl0OBDkkIWHdhVB6WwFuMj7syok0F/PCD3pLHvt q7KiqMy8TgMvtYDzQ5ZdKOZx8i9j+YI44uXAnF5UgZ0V8gz68/eM/AI2befBAGlR873l XvKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=9N8prPn/l5lynGZ9hq4y32W0mrb4tQpYTbn+0EOaBjA=; b=alXf6Kq0gOXFL4ZT/O2+Mqg+B4fBadhKaSu9UqUJy5vsal2OCwBfCVHQo1rWKjF/ts CVFhlFtqw6JWAVtZCIev05wNmBIigEdAtq0NdfVXxhtJ1LcOEfN4BVqsNZxl4YgJ0q9l WOA5pePO8FWt0UHpAfxvlttApXXhkMpU15Ht2KxfQfuiiVv+OCbb89olgmS/JiZcfk3B n3lvq6Y1hBDlGOXhoOjYz+/wNhhsL+BgzZX0aYDXjDcQpkXDjYSdKWajaRIlHuF/1h4L RGEo2aAtsLahP1LT13bWf8ESSj3r1GN2qlgqo8aMla92mbe+OMo3auRzpSsEoYJMNcYN vlMA==
X-Gm-Message-State: AOPr4FUcZuSq90zht5h5cgTK04a2p+onnRMcetKbPRkKY+jvsSrtKlXzlzv30bxGr+iwkg==
X-Received: by 10.112.54.132 with SMTP id j4mr838286lbp.3.1460449849089; Tue, 12 Apr 2016 01:30:49 -0700 (PDT)
Received: from [192.168.2.7] ([80.111.78.209]) by smtp.googlemail.com with ESMTPSA id td7sm5128690lbb.6.2016.04.12.01.30.47 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Apr 2016 01:30:48 -0700 (PDT)
To: "Phil Hunt (IDM)" , Brian Campbell 
References: <2D15E964-8A56-417C-A3CB-78CFAB5DFA34@oracle.com>  <824192A8-4F6F-4002-B7E0-518CAA0BF34A@oracle.com>
From: Sergey Beryozkin 
Message-ID: <570CB228.8070703@gmail.com>
Date: Tue, 12 Apr 2016 09:30:32 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <824192A8-4F6F-4002-B7E0-518CAA0BF34A@oracle.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Regarding using resource indicator to solve resource config issue
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Apr 2016 08:30:55 -0000

Hi
On 11/04/16 23:19, Phil Hunt (IDM) wrote:
> I am objecting to modifying the protocol in the default case as a
> majority do not need RI in the case of fixed endpoints.
>
> Migration would be challenging because the change is breaking and
> affects existing clients.
>
How does it break the existing clients given this is an optional feature 
? Can you please describe the situation where the existing clients get 
broken ?

Brian, would it make sense to update the text to mention that the 
clients do not have to be directly configured and instead it can be set 
during the registration time, so that the property gets seamlessly 
linked to client access tokens, etc, without the client applications 
having to be set up with the resource indicators manually ?

Thanks, Sergey

> Dynamic discovery are up and coming cases and a relatively green field.
> Dealing with it at configuration/discovery makes broader sense as it has
> no impact on existing clients.
>
> Phil
>
> On Apr 11, 2016, at 12:18, Brian Campbell  > wrote:
>
>> I'm not sure where the idea that it's only applicable to special uses
>> like collaboration services is coming from. The pattern described in
>> the draft (using a different parameter name but otherwise the same) is
>> deployed and in-use for normal OAuth cases including and especially
>> the resource owner centric ones.
>>
>>
>> On Mon, Apr 11, 2016 at 11:33 AM, Phil Hunt (IDM)
>> > wrote:
>>
>>     I am finding I am not happy with solving the bad resource endpoint
>>     config issue with resource indicator. At best I see this as a
>>     special use draft for things like collab services or things which
>>     aren't resource owner centric.
>>
>>     Yet resource endpoint config is a concern for all clients that
>>     configure on the fly. Is it reasonable to make resource indicator
>>     mandatory for all clients? Probably not.
>>
>>     As OAuth depends primarily on TLS, it feels wrong not to have a
>>     solution that confirms the server host names are correct either
>>     via config lookup or some other mechanism.
>>
>>     Tokbind is also a solution but I suspect it may only appeal to
>>     large scale service providers and may be further off as we wait
>>     for load balancers to support tokbind. Also there are issues with
>>     tokbind on initial user binding where the mitm attack might itself
>>     establish its own token binding. I have to think this through some
>>     to confirm. But the issue of worry is what is happening on
>>     initialization and first use if the hacker has already interceded
>>     a mitm. That would make validation at config time still critical.
>>
>>     Hopefully somebody can arrive at an alternative for broader oauth
>>     use cases.
>>
>>     Phil
>>     _______________________________________________
>>     OAuth mailing 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 Apr 12 03:49:58 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8192B12EB27 for ; Tue, 12 Apr 2016 03:49:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaV3Xb2EoLuc for ; Tue, 12 Apr 2016 03:49:54 -0700 (PDT)
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 40EB512EB1F for ; Tue, 12 Apr 2016 03:49:54 -0700 (PDT)
Received: by mail-qg0-x236.google.com with SMTP id f105so11886827qge.2 for ; Tue, 12 Apr 2016 03:49:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tZFj27GX9XjEHhAt/QdwkqfLRNyZ9JGYBCP7hkH1J98=; b=vfX8EgW5j2ATLUN7D71ibmcaHe+RlYPYRq0R4LaAxddY/h2T3rSjeyGNfW8oaHjWXx rFiMHgvjxeIe5UDqVXC8Jxs378eP40Bi5FmQrjWEjWNooP8GHLH/F1FCFE4BRkSgjWRw zcT9U7tot7vXFHauQL5FbvWnpT/Re9qv3dzI73/pn8KsMKHhQtaRCDmXHXS97UYQGOwr cPJ4usahUSDihL+hFnP4qWp65gSZy8AhtAE8cXr4tH3Ujnh4/ehw0uufHB4plN6hFgkn 3iv9XCSVJTJMrCU5AAolqFnzr6WP7kOq+/Mn4dZdzbmBV2fzcSE3ZxG2oYOs0gh1Eg9Y geog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tZFj27GX9XjEHhAt/QdwkqfLRNyZ9JGYBCP7hkH1J98=; b=fGbU2uiYuwusk2IvWtefz0apTuC5166drDUkr1Y7nzFhGc3+zPE96IohzvtKF+qH/B LKIONUZNt++SeYG1AIgP6eaA+ZN8cCIhgz2E0YgeUEWzzloRvUXDHJ4yQU0P845keHo/ niFaFuu10lSgGmkXBxqDbkPIjrFWyPo2kd27HMjF+ibcDNL0zp1fv4SDWZhCDtPL9QR1 NpyGWmA2pzGNYwsdB+m51F+0NFo+mg7E0qBkUgkKK7wv6xEuypioorQTDXcaK1UKz9e0 GJiRum/DDjTE3cxDSFJcl5OlvfDAr2ym4SsvqDBAkx3/YEVKhMP3Z6QZFrVWEOexrNLU ulNw==
X-Gm-Message-State: AOPr4FUKStz/C3yCONbwioP8E5HUFfVByOjjK/NuEuylYfPgtqAw1UnRL3g9MHr4Zu2dDw==
X-Received: by 10.140.194.67 with SMTP id p64mr3050426qha.19.1460458193173; Tue, 12 Apr 2016 03:49:53 -0700 (PDT)
Received: from [192.168.6.44] (ip-64-134-98-118.public.wayport.net. [64.134.98.118]) by smtp.gmail.com with ESMTPSA id b85sm13246510qhc.23.2016.04.12.03.49.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 12 Apr 2016 03:49:51 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: John Bradley 
In-Reply-To: <570CB228.8070703@gmail.com>
Date: Tue, 12 Apr 2016 06:49:48 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <22B70247-C110-4D91-B510-1CCD59CB0260@ve7jtb.com>
References: <2D15E964-8A56-417C-A3CB-78CFAB5DFA34@oracle.com>  <824192A8-4F6F-4002-B7E0-518CAA0BF34A@oracle.com> <570CB228.8070703@gmail.com>
To: Sergey Beryozkin 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Regarding using resource indicator to solve resource config issue
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Apr 2016 10:49:56 -0000

We did agree in BA that if the client sends no resource the AS would =
audience the AT per configured policy and reply to the client with =
additional meta-data about what resources the AT can be used at.

It should be obvious that this is in no way a breaking change.

The only clients that need to provide a resource are ones that are =
asking for a token for a unknown resource, not something that is =
supported securely currently or by Pil=E2=80=99s spec.   Or when down =
scoping  a RT with multiple audiences so that the server can provide the =
correct token type/ claims / encryption/ signing.   Can we agree that =
with symmetrically signed AT it is not a good thing to use the same key =
for all RS?

At the moment this can sort of be done with scopes but the client needs =
much more documentation about the scopes to understand the mapping =
between resource and scope, or possibly discovery of meta-data about the =
resource, something also not covered in Phil=E2=80=99s draft.

We can update the draft as an ID. =20

This is essentially the audience part of the POP key distribution with =
the addition of Nat=E2=80=99s meta-data for the token endpoint (in the =
existing JSON rather than a new header)

We need to address this.  Discovery in general and Phil=E2=80=99s draft =
specifically are not a replacement, even if we were to adopt them.

To Phil=E2=80=99s other question about token binding, no an attacker =
can=E2=80=99t usefully  MitM a token bound AT. =20
The private key is controlled by the client and never disclosed.  You =
can give the token to a MitM attacker but they cannot use it anyplace =
even with themselves as they don=E2=80=99t have the private key.   That =
is the security goal of token binding.

John B.

> On Apr 12, 2016, at 4:30 AM, Sergey Beryozkin  =
wrote:
>=20
> Hi
> On 11/04/16 23:19, Phil Hunt (IDM) wrote:
>> I am objecting to modifying the protocol in the default case as a
>> majority do not need RI in the case of fixed endpoints.
>>=20
>> Migration would be challenging because the change is breaking and
>> affects existing clients.
>>=20
> How does it break the existing clients given this is an optional =
feature ? Can you please describe the situation where the existing =
clients get broken ?
>=20
> Brian, would it make sense to update the text to mention that the =
clients do not have to be directly configured and instead it can be set =
during the registration time, so that the property gets seamlessly =
linked to client access tokens, etc, without the client applications =
having to be set up with the resource indicators manually ?
>=20
> Thanks, Sergey
>=20
>> Dynamic discovery are up and coming cases and a relatively green =
field.
>> Dealing with it at configuration/discovery makes broader sense as it =
has
>> no impact on existing clients.
>>=20
>> Phil
>>=20
>> On Apr 11, 2016, at 12:18, Brian Campbell > > wrote:
>>=20
>>> I'm not sure where the idea that it's only applicable to special =
uses
>>> like collaboration services is coming from. The pattern described in
>>> the draft (using a different parameter name but otherwise the same) =
is
>>> deployed and in-use for normal OAuth cases including and especially
>>> the resource owner centric ones.
>>>=20
>>>=20
>>> On Mon, Apr 11, 2016 at 11:33 AM, Phil Hunt (IDM)
>>> > wrote:
>>>=20
>>>    I am finding I am not happy with solving the bad resource =
endpoint
>>>    config issue with resource indicator. At best I see this as a
>>>    special use draft for things like collab services or things which
>>>    aren't resource owner centric.
>>>=20
>>>    Yet resource endpoint config is a concern for all clients that
>>>    configure on the fly. Is it reasonable to make resource indicator
>>>    mandatory for all clients? Probably not.
>>>=20
>>>    As OAuth depends primarily on TLS, it feels wrong not to have a
>>>    solution that confirms the server host names are correct either
>>>    via config lookup or some other mechanism.
>>>=20
>>>    Tokbind is also a solution but I suspect it may only appeal to
>>>    large scale service providers and may be further off as we wait
>>>    for load balancers to support tokbind. Also there are issues with
>>>    tokbind on initial user binding where the mitm attack might =
itself
>>>    establish its own token binding. I have to think this through =
some
>>>    to confirm. But the issue of worry is what is happening on
>>>    initialization and first use if the hacker has already interceded
>>>    a mitm. That would make validation at config time still critical.
>>>=20
>>>    Hopefully somebody can arrive at an alternative for broader oauth
>>>    use cases.
>>>=20
>>>    Phil
>>>    _______________________________________________
>>>    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
> Sergey Beryozkin
>=20
> Talend Community Coders
> http://coders.talend.com/
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Tue Apr 12 05:41:06 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7137412DE07 for ; Tue, 12 Apr 2016 05:41:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.216
X-Spam-Level: 
X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fY0cjufYkHq for ; Tue, 12 Apr 2016 05:41:02 -0700 (PDT)
Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 665EC12DD10 for ; Tue, 12 Apr 2016 05:41:02 -0700 (PDT)
X-AuditID: 1209190d-ab7ff70000004038-cc-570cecdd353c
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by  (Symantec Messaging Gateway) with SMTP id CC.8F.16440.DDCEC075; Tue, 12 Apr 2016 08:41:01 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u3CCf0Qj024631; Tue, 12 Apr 2016 08:41:01 -0400
Received: from [172.25.213.223] ([199.244.219.64]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u3CCetYc014680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Apr 2016 08:40:58 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_385A0E2C-0318-4CC9-A706-B5D8B617EEC8"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Justin Richer 
In-Reply-To: 
Date: Tue, 12 Apr 2016 08:40:49 -0400
Message-Id: <9EE48660-1A58-4DE8-A5CE-507EF6EFB900@mit.edu>
References: <57054ADF.3010109@gmx.net> 
To: Brian Campbell 
X-Mailer: Apple Mail (2.3112)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupileLIzCtJLcpLzFFi42IR4hTV1r37hifc4NVdCYvV/28yWizdeY/V 4uTbV2wOzB6LN+1n81iy5CeTx92jF1kCmKO4bFJSczLLUov07RK4Mqb8cCpYq16xsnkxYwPj K6UuRk4OCQETifvrPjN2MXJxCAm0MUnsXzSFBcLZyChx8/d5qMx6JonXEy+wdTFycDALJEis aXYG6eYV0JM4sWo3K0hYWEBdoumHHkiYTUBVYvqaFiYQm1MgUGJHVw8biM0CFN+2fCcLxJR4 idUb4yGmWEl8nwMS5gTalC0x/91LZhBbREBf4vbTOewQd8pK7NuwgG0CI/8shBtmIbkBxGYW 0JZYtvA1M4StKbG/ezkLpriGROe3iawLGNlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Rrp5WaW 6KWmlG5iBAe5JO8Oxn93vQ4xCnAwKvHwPnDmCRdiTSwrrsw9xCjJwaQkylu/CyjEl5SfUpmR WJwRX1Sak1p8iFGCg1lJhJfhNVCONyWxsiq1KB8mJc3BoiTOG3PzaJiQQHpiSWp2ampBahFM VoaDQ0mCtxukUbAoNT21Ii0zpwQhzcTBCTKcB2h4A9jw4oLE3OLMdIj8KUZFKXHecmAaERIA SWSU5sH1gpLQ8S+3HV4xigO9IswbAtLOA0xgcN2vgAYzAQ1+9o8TZHBJIkJKqoFxi2O39dkL 11+L3Fl9fkVu5FzuxOzGmRqs649omdZEmIjzF186KjS35hNbpN9b5iBPDT4/sTm3/TScCgxy 43qML2bdv7Xq7+RvD29euLHtlPIBqdSIfZv9PDs0Zy55cSO5pLtcYFH/ulkdU85Ys3gVPf+z YnPAS0mzXRc1HK8zpgSuEWXxuZWjxFKckWioxVxUnAgAIHF9nB0DAAA=
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Meeting Minutes
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Apr 2016 12:41:04 -0000

--Apple-Mail=_385A0E2C-0318-4CC9-A706-B5D8B617EEC8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

That=E2=80=99s correct, we=E2=80=99ve filed an issue in our project to =
track its eventual implementation:

=
https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/issue=
s/1055 =


 =E2=80=94 Justin

> On Apr 11, 2016, at 8:21 AM, Brian Campbell =
 wrote:
>=20
> Under the Token Exchange part it says, "Jim Fenton: we have =
implmentation that could be adapted to this." but, as I recall, Jim was =
not speaking for himself there but rather on behalf of Justin via the =
Jabber room. =20
>=20
>=20
>=20
> On Wed, Apr 6, 2016 at 11:43 AM, Hannes Tschofenig =
> wrote:
> Leif was so nice to take meeting notes during the OAuth meeting today
> and they have been uploaded to:
> https://www.ietf.org/proceedings/95/minutes/minutes-95-oauth =

>=20
> Please take a look at them and let me know if they are incorrect or =
need
> to be extended.
>=20
> Ciao
> Hannes
>=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=_385A0E2C-0318-4CC9-A706-B5D8B617EEC8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

That=E2=80=99s correct, we=E2=80=99ve filed an issue in our =
project to track its eventual implementation:

https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-S=
erver/issues/1055

 =E2=80=94 Justin

On =
Apr 11, 2016, at 8:21 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Under the Token Exchange part it =
says, "Jim Fenton: we have implmentation that could be adapted to this." =
but, as I recall, Jim was not speaking for himself there but rather on =
behalf of Justin via the Jabber room.  



On Wed, Apr 6, 2016 at 11:43 AM, =
Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Leif was so nice to =
take meeting notes during the OAuth meeting today

and they have been uploaded to:

https://www.ietf.org/proceedings/95/minutes/minutes-95-oauth



Please take a look at them and let me know if they are incorrect or =
need

to be extended.



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=_385A0E2C-0318-4CC9-A706-B5D8B617EEC8--


From nobody Tue Apr 12 05:46:40 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E87B712DCDA for ; Tue, 12 Apr 2016 05:46:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.207
X-Spam-Level: 
X-Spam-Status: No, score=-3.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDV2c-lnh0LZ for ; Tue, 12 Apr 2016 05:46:32 -0700 (PDT)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 844C712D515 for ; Tue, 12 Apr 2016 05:46:32 -0700 (PDT)
X-AuditID: 12074424-8d3ff700000073db-98-570cee274ac8
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by  (Symantec Messaging Gateway) with SMTP id A1.F5.29659.72EEC075; Tue, 12 Apr 2016 08:46:31 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u3CCkUa3024752; Tue, 12 Apr 2016 08:46:30 -0400
Received: from [172.25.213.223] ([199.244.219.64]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u3CCkNJu016023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Apr 2016 08:46:28 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_FA538BEA-76A3-4F2B-B72C-5F324B10FD9A"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Justin Richer 
In-Reply-To: 
Date: Tue, 12 Apr 2016 08:46:19 -0400
Message-Id: <9FA7FA11-0FED-40D6-AD49-506BA4EEF8E4@mit.edu>
References: <570546A1.8040509@gmx.net> <5AEB6A4A-A325-4069-930F-D034D81E41E5@mit.edu>       
To: Torsten Lodderstadt 
X-Mailer: Apple Mail (2.3112)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNKsWRmVeSWpSXmKPExsUixG6nrqv+jifc4FInj8XJt6/YLDbN3cZo 8erYUxYHZo8lS34yeRzr6Wf1aN3xlz2AOYrLJiU1J7MstUjfLoEro/kVR8Hd9UwVb7cfYWxg nNXF1MXIySEhYCJxvuEzYxcjF4eQQBuTxNs/U5ggnI2MEpMfTWYEqRISWM8k8WVDEIjNLJAg MePsThYQm1dAT+LEqt2sILawgI/Eu3ur2UBsNgFVielrWsA2cAo4Szx9vhFsDgtQ/NCfC8wQ cyIl5na+Z4WYYyUx/2wnG8Ti7SwSyyfsAGrm4BARMJT4NScT4lJZiX0bFrBNYOSfheSMWUjO gIhrSyxb+JoZwtaU2N+9nAVTXEOi89tE1gWMbKsYZVNyq3RzEzNzilOTdYuTE/PyUot0zfVy M0v0UlNKNzGCw91FZQdjd4/3IUYBDkYlHt4HzjzhQqyJZcWVuYcYJTmYlER563cBhfiS8lMq MxKLM+KLSnNSiw8xSnAwK4nwMrwGyvGmJFZWpRblw6SkOViUxHkZGRgYhATSE0tSs1NTC1KL YLIyHBxKErw/3gA1ChalpqdWpGXmlCCkmTg4QYbzAA1XegsyvLggMbc4Mx0if4pRl6NpTtcG JiGWvPy8VClx3nKQQQIgRRmleXBzQGnq+JfbDq8YxYHeEubdBVLFA0xxcJNeAS1hAlry7B8n yJKSRISUVANj5oq7qnd3sZ4qVdqoErRuxU397S8u5DjU13tbOHS2xvRwpXDM+Za9s4lnZerG FBvPey6Lfqyep894t8tN9XrZrrKVC5zdZh/sa1dzY2buM/JfaPkoMoZdx2a7NNtu0bBvivMO Po+O7TDfcYx1n5eOiIy1Pv/zic9f35+VdXNVttsOjv8dJ/YqsRRnJBpqMRcVJwIAKhE0ZC4D AAA=
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Apr 2016 12:46:39 -0000

--Apple-Mail=_FA538BEA-76A3-4F2B-B72C-5F324B10FD9A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

+1 to Torsten=E2=80=99s point.

And a reminder to Tony that call for adoption is the *start* of the =
document editing process, not the end. We=E2=80=99re not saying this is =
a complete solution with everything thought out when we adopt the =
document, we=E2=80=99re saying it=E2=80=99s a problem we want to work on =
and a direction that we want to move in. Stop trying to confuse people.

 =E2=80=94 Justin

> On Apr 12, 2016, at 1:30 AM, Torsten Lodderstedt =
 wrote:
>=20
> Indicating the resource server to the AS allows the AS to =
automatically select token type, encryption scheme and user data to be =
put into the access token based on a RS-specific policy. So there is no =
need to explicitely ask the AS for a certain token format or encryption =
scheme.=20
>=20
> Am 11.04.2016 um 22:35 schrieb Anthony Nadalin >:
>=20
>> So it=E2=80=99s an incomplete solution then ?
>> =C2=A0 <>
>> From: Brian Campbell [mailto:bcampbell@pingidentity.com =
]=20
>> Sent: Monday, April 11, 2016 1:34 PM
>> To: Anthony Nadalin >
>> Cc: Nat Sakimura >; =
> >
>> Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for =
OAuth 2.0
>> =20
>> No, I'm not adding requirements for encryption. I was pointing out =
some of the ways that an access token might be different for different =
RSs.
>>=20
>>=20
>> =20
>> On Mon, Apr 11, 2016 at 2:18 PM, Anthony Nadalin =
> wrote:
>> So now you are adding more requirements for encryption ? The more =
this thread goes on shows how unstable and not fully thought out this =
draft is to go through WG adoption.
>> =C2=A0 <>
>> From: OAuth [mailto:oauth-bounces@ietf.org =
] On Behalf Of Brian Campbell
>> Sent: Monday, April 11, 2016 12:30 PM
>> To: Nat Sakimura >
>> Cc: > >
>> Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for =
OAuth 2.0
>> =20
>> Sending a token type is not sufficient. There's more involved than =
the format. Many cases need to know if to encrypt and whom to encrypt =
to.  What claims to put in the token (or reference by the token). What =
algorithms and keys to use for signing/encryption. =20
>>=20
>> The statement that the "Current proposal does not support the =
implicit flow" is incorrect. Among other things, sec 2 has, "When an =
access token will be returned from the authorization endpoint, the =
"resource" parameter is used in the authorization request to the =
authorization endpoint as defined in Section 4.2.1 of OAuth 2.0 =
[RFC6749]."
>> =20
>> On Sun, Apr 10, 2016 at 11:43 AM, Nat Sakimura > wrote:
>> So, my understanding on the rationale/requirements for having this =
spec right now is:=20
>> =20
>> R1. Authz server wants toprevent the replay by the server that =
received it.=20
>> R2. Authz server needs to mint the access token in a variety of =
format depending on the resource server and to do that, you need to know =
which RS is gong to be receiving it.=20
>> =20
>> To achieve R1, there are couple of methods. The proposed method here =
is to audience restrict the token, but the same can be achieved by =
sender constraining the token, e.g., by token binding. As far as I can =
see, the sentiment of the WG seems to be to use the sender constraint =
through Token Binding, so from this respect, this spec is not the one to =
do R1. Besides, the current proposal only takes care of the code flow. =
The same requirement should be there for implicit flow as well, so the =
current proposal is not covering the R1 anyways.=20
>> =20
>> I can sort of understand R2, but I have two critique on the current =
proposal:=20
>> =20
>> C1. Current proposal does not support the implicit flow. To support =
it, the resource URI has to be sent to the Authz endpoint instead of the =
Token endpoint.=20
>> C2. It is much more direct to send the required token format rather =
than the RS uri and probably better as:=20
>>   1) There are use cases where the AS does not maintain the list of =
RSs that it supports, e.g., AOL.=20
>>        In such a case, even if the RS uri were sent to the AS, the AS =
cannot mint the tokens in the appropriate format.=20
>>   2) When it is sent in the Authz request, it is leaking the =
information about the resource that the client is going to the browser.=20=

>>   3) There are use cases where it is desirable not to let the AS =
knows where the Client is going from the privacy point of view.=20
>> =20
>> So, my suggestion is to drop R1 and concentrate on R2. And to solve =
R2, send token type instead of the resource indicator in the request.=20
>> This also necessitates the Client to be able to find out what token =
type the resource requires, perhaps in the unauthorized response web =
link header at the resource in the manner of oauth-meta.=20
>> =20
>> Cheers,=20
>> =20
>> Nat
>> =20
>> =20
>> =20
>> 2016=E5=B9=B44=E6=9C=888=E6=97=A5(=E9=87=91) 8:23 Prateek Mishra =
>:
>> While this work addresses a gap in the existing OAuth specification =
set, I am very concerned that this
>> incremental extension will lead to even more confusion around the =
areas of =E2=80=9Cscope=E2=80=9D, =E2=80=9Caudience=E2=80=9D and =
=E2=80=9Cresource server=E2=80=9D.
>>=20
>> I think we should try to solve this problem via  a framework that =
provides better guidance and implementation
>> models for OAuth use-cases. In other words, I feel that a broader =
discussion is needed here.
>>=20
>>=20
>> > On Apr 7, 2016, at 4:11 PM, Justin Richer > wrote:
>> >
>> > I support adoption of this document as a starting point for working =
group work.
>> >
>> > =E2=80=94 Justin
>> >
>> >
>> >> On Apr 6, 2016, at 1:25 PM, Hannes Tschofenig =
> wrote:
>> >>
>> >> Hi all,
>> >>
>> >> this is the call for adoption of 'Resource Indicators for OAuth =
2.0', see
>> >> =
http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/ =

>> >>
>> >> Please let us know by April 20th 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 =
Buenos
>> >> Aires then you don't need to re-state your opinion, if you want.
>> >>
>> >> The feedback at the BA IETF meeting was the following: ~10 persons
>> >> for accepting the document and 0 persons against.
>> >>
>> >> 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 =

>>=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
>> _______________________________________________
>> OAuth mailing 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=_FA538BEA-76A3-4F2B-B72C-5F324B10FD9A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

+1 to Torsten=E2=80=99s point.

And a reminder to Tony that call for =
adoption is the *start* of the document editing process, not the end. =
We=E2=80=99re not saying this is a complete solution with everything =
thought out when we adopt the document, we=E2=80=99re saying it=E2=80=99s =
a problem we want to work on and a direction that we want to move in. =
Stop trying to confuse people.

 =E2=80=94 Justin

On Apr 12, 2016, at 1:30 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Indicating the resource =
server to the AS allows the AS to automatically select token type, =
encryption scheme and user data to be put into the access token based on =
a RS-specific policy. So there is no need to explicitely ask the AS for =
a certain token format or encryption scheme. 

Am 11.04.2016 =
um 22:35 schrieb Anthony Nadalin <tonynad@microsoft.com>:

So it=E2=80=99s an incomplete solution then =
?
From: Brian Campbell [mailto:bcampbell@pingidentity.com] 
Sent: Monday, April 11, 2016 1:34 =
PM
To: Anthony Nadalin <tonynad@microsoft.com>
Cc: Nat Sakimura <sakimura@gmail.com>; =
<oauth@ietf.org> <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Call for =
Adoption: Resource Indicators for OAuth 2.0
 
No, I'm not adding requirements for encryption. I was =
pointing out some of the ways that an access token might be different =
for different RSs.

 
On Mon, Apr 11, 2016 at 2:18 PM, Anthony =
Nadalin <tonynad@microsoft.com> wrote:
So now you are adding more requirements for =
encryption ? The more this thread goes on shows how unstable and not =
fully thought out this draft is to go through WG adoption.
 
From: OAuth =
[mailto:oauth-bounces@ietf.org] On Behalf =
Of Brian =
Campbell
Sent: Monday, April 11, 2016 =
12:30 PM
To: Nat Sakimura <sakimura@gmail.com>
Cc: <oauth@ietf.org> <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Call for =
Adoption: Resource Indicators for OAuth 2.0
 
Sending a token type =
is not sufficient. There's more involved than the format. Many cases =
need to know if to encrypt and whom to encrypt to.  What claims to =
put in the token (or reference by the token). What algorithms and keys =
to use for signing/encryption.  

The statement that the =
"Current proposal does not support the implicit flow" is incorrect. =
Among other things, sec 2 has, "When an access token will be returned =
from the authorization endpoint, the "resource" parameter is used in the =
authorization request to the authorization endpoint as defined in =
Section 4.2.1 of OAuth 2.0 [RFC6749]."
 
On Sun, Apr 10, 2016 =
at 11:43 AM, Nat Sakimura <sakimura@gmail.com> wrote:
So, my understanding =
on the rationale/requirements for having this spec right now =
is: 
 
R1. Authz server =
wants toprevent the replay by the server that received it. 
R2. Authz server needs to mint the access token in a variety =
of format depending on the resource server and to do that, you need to =
know which RS is gong to be receiving it. 
 
To achieve R1, there are couple of =
methods. The proposed method here is to audience restrict the token, but =
the same can be achieved by sender constraining the token, e.g., by =
token binding. As far as I can see, the sentiment of the WG seems to be =
to use the sender constraint through Token Binding, so from this =
respect, this spec is not the one to do R1. Besides, the current =
proposal only takes care of the code flow. The same requirement should =
be there for implicit flow as well, so the current proposal is not =
covering the R1 anyways. 
 
I can sort of understand R2, but I have two critique on the =
current proposal: 
 
C1. Current proposal does not support the implicit flow. To =
support it, the resource URI has to be sent to the Authz endpoint =
instead of the Token endpoint. 
C2. It is much more =
direct to send the required token format rather than the RS uri and =
probably better as: 
  1) There are =
use cases where the AS does not maintain the list of RSs that it =
supports, e.g., AOL. 
      =
 In such a case, even if the RS uri were sent to the AS, the AS =
cannot mint the tokens in the appropriate format. 
  2) When it is sent in the Authz request, it is leaking =
the information about the resource that the client is going to the =
browser. 
  3) There are use cases where it is =
desirable not to let the AS knows where the Client is going from the =
privacy point of view. 
 
So, my suggestion is to drop R1 and concentrate on R2. And to =
solve R2, send token type instead of the resource indicator in the =
request. 
This also necessitates the Client to be =
able to find out what token type the resource requires, perhaps in the =
unauthorized response web link header at the resource in the manner of =
oauth-meta. 
 
Cheers, 
 
Nat
 
 
 
2016=E5=B9=B44=E6=9C=888=E6=97=A5(=E9=87=91) 8:23 Prateek Mishra <Prateek.Mishra@oracle.com>:
While =
this work addresses a gap in the existing OAuth specification set, I am =
very concerned that this
incremental extension will lead =
to even more confusion around the areas of =E2=80=9Cscope=E2=80=9D, =
=E2=80=9Caudience=E2=80=9D and =E2=80=9Cresource server=E2=80=9D.

I think we should try to solve this problem =
via  a framework that provides better guidance and =
implementation
models for OAuth use-cases. In other words, =
I feel that a broader discussion is needed here.


> On Apr 7, 2016, at 4:11 PM, Justin Richer =
<jricher@mit.edu> =
wrote:
>
> I support adoption of this =
document as a starting point for working group work.
>> =E2=80=94 Justin
>
>>> On Apr 6, 2016, at 1:25 PM, Hannes Tschofenig =
<hannes.tschofenig@gmx.net> wrote:
>>
>> Hi all,
>>
>> this is the call for adoption =
of 'Resource Indicators for OAuth 2.0', see
>> http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-i=
ndicators/
>>
>> Please let =
us know by April 20th 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 Buenos
>> Aires =
then you don't need to re-state your opinion, if you want.
>>
>> The feedback at the BA IETF =
meeting was the following: ~10 persons
>> for =
accepting the document and 0 persons against.
>>
>> 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
=

--Apple-Mail=_FA538BEA-76A3-4F2B-B72C-5F324B10FD9A--


From nobody Tue Apr 12 06:04:04 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7EA912ED28 for ; Tue, 12 Apr 2016 06:04:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.013
X-Spam-Level: 
X-Spam-Status: No, score=-0.013 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NX3eDc72UAcf for ; Tue, 12 Apr 2016 06:03:56 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0132.outbound.protection.outlook.com [65.55.169.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 674AF12E702 for ; Tue, 12 Apr 2016 06:03:56 -0700 (PDT)
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=PWciJA+ux/Y4t7xGVD7L9Gbc47PgZlm2v6n2wOReVno=; b=i7hASXgo2gUz5oD+0wmUIyutl7jBKC53db7+2WqeJiNycNo3XrC22UsFmq8RalOLzMmu2F2eDT8lTvoKjBR/6vPklvbbb/WW64y7EaTj6JCWJj4gd5nsmzmNalRLq5BWyUQWYT7WVMQtuRvgFMzEsd3jGZNPny7TN2PtlHwOxvU=
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.453.26; Tue, 12 Apr 2016 13:03:53 +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.0453.029; Tue, 12 Apr 2016 13:03:53 +0000
From: Anthony Nadalin 
To: Justin Richer , Torsten Lodderstadt 
Thread-Topic: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0
Thread-Index: AQHRkCmB9ToVpiQsqkic7QI3EfNCup9/JV+AgAADVwCABFfWgIABsEAAgAAMjfCAAAU9AIAAADpggACVnQCAAHnegIAAAXkA
Date: Tue, 12 Apr 2016 13:03:53 +0000
Message-ID: 
References: <570546A1.8040509@gmx.net> <5AEB6A4A-A325-4069-930F-D034D81E41E5@mit.edu>        <9FA7FA11-0FED-40D6-AD49-506BA4EEF8E4@mit.edu>
In-Reply-To: <9FA7FA11-0FED-40D6-AD49-506BA4EEF8E4@mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [24.54.172.229]
x-ms-office365-filtering-correlation-id: a2c39c6f-ecad-4cdf-8916-08d362d2e641
x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1233; 5:RvImQAb5/J9myzAQmSE0oIrntXCGFqlHfRkLvzZR/rt2VdZeiz5rC8rJ+MxoCRlVRA4x2S72LnhXbAovzwKut/gWfqZLqaCFuMIyIqDhTDm/WL16pK0WBYltiQK57SyVuUdAQ5y/syfv7t1yNxxlqA==; 24:tFvOq44KJ47gurcRw+R2jtuoL/wUx+PKviZ17sT8xLun47S2MwxDdHSjTTnVOtiVO7h14CX8+iMTyQdaVK9Vwh+HP2wmYzHhssFOtriPF9c=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1233;
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)(6055026)(61426038)(61427038); SRVR:BN3PR0301MB1233; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1233; 
x-forefront-prvs: 0910AAF391
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(53754006)(24454002)(377454003)(50986999)(5004730100002)(54356999)(76176999)(189998001)(33656002)(1096002)(561944003)(2171001)(19617315012)(19609705001)(87936001)(19625215002)(3280700002)(2906002)(8990500004)(586003)(5008740100001)(92566002)(77096005)(99286002)(15975445007)(16236675004)(76576001)(86362001)(5005710100001)(1220700001)(3846002)(5001770100001)(86612001)(2950100001)(2900100001)(5003600100002)(102836003)(6116002)(106116001)(790700001)(81166005)(74316001)(10090500001)(5002640100001)(122556002)(3660700001)(10290500002)(19300405004)(9686002)(11100500001)(10400500002)(4326007)(93886004)(66066001)(19580405001)(19580395003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1233; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB12341A528F84D33823F66387A6950BN3PR0301MB1234_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2016 13:03:53.3049 (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: "" 
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Apr 2016 13:04:04 -0000

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

U3BlY2lmaWNhdGlvbnMgc2hvdWxkIGJlIHNvbWV3aGF0IGNvbXBsZXRlIGFuZCBub3Qgb3BlbiBl
bmRlZC9ub3QgdGhvdWdodCBvdXQsIHlvdSBzaG91bGQgdGhpbmsgYWJvdXQgdGhlIGlzc3Vlcywg
cmVxdWlyZW1lbnRzIGFuZCB1c2UgY2FzZXMgZmlyc3QgYmVmb3JlIHlvdSB0cnkgdG8gZm9yY2Ug
dGhpcyBpbnRvIHRoZSB3b3JraW5nIGdyb3VwIHByb2Nlc3MgYW5kIGNvbmZ1c2UgcGVvcGxlICwg
d2UgaGFkIHRvbyBtYW55IG9mIHRoZXNlIHNwZWNpZmljYXRpb25zIGxhdGVseS4NCg0KV2UgYXJl
IG5vdyB1cCB0byAxNSsgc3BlY2lmaWNhdGlvbnMgdGhhdCBzb21lb25lIGhhcyB0byByZWFkIGFu
ZCB1bmRlcnN0YW5kIGhvdyB0aGVzZSBhbGwgbWF5IG9yIG1heSBub3QgZml0IHRvZ2V0aGVyIGFu
ZCBhbGwgdGhlIGludGVyYWN0aW9ucyB0aGF0IG1heSBvY2N1ci4gU28gbXVjaCBmb3IgdGhlIHNp
bXBsZSBPYXV0aC4NCg0KRnJvbTogSnVzdGluIFJpY2hlciBbbWFpbHRvOmpyaWNoZXJAbWl0LmVk
dV0NClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDEyLCAyMDE2IDU6NDYgQU0NClRvOiBUb3JzdGVuIExv
ZGRlcnN0YWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4NCkNjOiBBbnRob255IE5hZGFsaW4g
PHRvbnluYWRAbWljcm9zb2Z0LmNvbT47IDxvYXV0aEBpZXRmLm9yZz4gPG9hdXRoQGlldGYub3Jn
Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQ2FsbCBmb3IgQWRvcHRpb246IFJlc291cmNlIElu
ZGljYXRvcnMgZm9yIE9BdXRoIDIuMA0KDQorMSB0byBUb3JzdGVu4oCZcyBwb2ludC4NCg0KQW5k
IGEgcmVtaW5kZXIgdG8gVG9ueSB0aGF0IGNhbGwgZm9yIGFkb3B0aW9uIGlzIHRoZSAqc3RhcnQq
IG9mIHRoZSBkb2N1bWVudCBlZGl0aW5nIHByb2Nlc3MsIG5vdCB0aGUgZW5kLiBXZeKAmXJlIG5v
dCBzYXlpbmcgdGhpcyBpcyBhIGNvbXBsZXRlIHNvbHV0aW9uIHdpdGggZXZlcnl0aGluZyB0aG91
Z2h0IG91dCB3aGVuIHdlIGFkb3B0IHRoZSBkb2N1bWVudCwgd2XigJlyZSBzYXlpbmcgaXTigJlz
IGEgcHJvYmxlbSB3ZSB3YW50IHRvIHdvcmsgb24gYW5kIGEgZGlyZWN0aW9uIHRoYXQgd2Ugd2Fu
dCB0byBtb3ZlIGluLiBTdG9wIHRyeWluZyB0byBjb25mdXNlIHBlb3BsZS4NCg0KIOKAlCBKdXN0
aW4NCg0KT24gQXByIDEyLCAyMDE2LCBhdCAxOjMwIEFNLCBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0
b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+PiB3
cm90ZToNCg0KSW5kaWNhdGluZyB0aGUgcmVzb3VyY2Ugc2VydmVyIHRvIHRoZSBBUyBhbGxvd3Mg
dGhlIEFTIHRvIGF1dG9tYXRpY2FsbHkgc2VsZWN0IHRva2VuIHR5cGUsIGVuY3J5cHRpb24gc2No
ZW1lIGFuZCB1c2VyIGRhdGEgdG8gYmUgcHV0IGludG8gdGhlIGFjY2VzcyB0b2tlbiBiYXNlZCBv
biBhIFJTLXNwZWNpZmljIHBvbGljeS4gU28gdGhlcmUgaXMgbm8gbmVlZCB0byBleHBsaWNpdGVs
eSBhc2sgdGhlIEFTIGZvciBhIGNlcnRhaW4gdG9rZW4gZm9ybWF0IG9yIGVuY3J5cHRpb24gc2No
ZW1lLg0KDQpBbSAxMS4wNC4yMDE2IHVtIDIyOjM1IHNjaHJpZWIgQW50aG9ueSBOYWRhbGluIDx0
b255bmFkQG1pY3Jvc29mdC5jb208bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbT4+Og0KU28g
aXTigJlzIGFuIGluY29tcGxldGUgc29sdXRpb24gdGhlbiA/DQoNCkZyb206IEJyaWFuIENhbXBi
ZWxsIFttYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb21dDQpTZW50OiBNb25kYXksIEFw
cmlsIDExLCAyMDE2IDE6MzQgUE0NClRvOiBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9z
b2Z0LmNvbTxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPj4NCkNjOiBOYXQgU2FraW11cmEg
PHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86c2FraW11cmFAZ21haWwuY29tPj47IDxvYXV0aEBp
ZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+PiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9h
dXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIENhbGwgZm9yIEFkb3B0aW9u
OiBSZXNvdXJjZSBJbmRpY2F0b3JzIGZvciBPQXV0aCAyLjANCg0KTm8sIEknbSBub3QgYWRkaW5n
IHJlcXVpcmVtZW50cyBmb3IgZW5jcnlwdGlvbi4gSSB3YXMgcG9pbnRpbmcgb3V0IHNvbWUgb2Yg
dGhlIHdheXMgdGhhdCBhbiBhY2Nlc3MgdG9rZW4gbWlnaHQgYmUgZGlmZmVyZW50IGZvciBkaWZm
ZXJlbnQgUlNzLg0KDQoNCg0KT24gTW9uLCBBcHIgMTEsIDIwMTYgYXQgMjoxOCBQTSwgQW50aG9u
eSBOYWRhbGluIDx0b255bmFkQG1pY3Jvc29mdC5jb208bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0
LmNvbT4+IHdyb3RlOg0KU28gbm93IHlvdSBhcmUgYWRkaW5nIG1vcmUgcmVxdWlyZW1lbnRzIGZv
ciBlbmNyeXB0aW9uID8gVGhlIG1vcmUgdGhpcyB0aHJlYWQgZ29lcyBvbiBzaG93cyBob3cgdW5z
dGFibGUgYW5kIG5vdCBmdWxseSB0aG91Z2h0IG91dCB0aGlzIGRyYWZ0IGlzIHRvIGdvIHRocm91
Z2ggV0cgYWRvcHRpb24uDQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRm
Lm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBCcmlhbiBD
YW1wYmVsbA0KU2VudDogTW9uZGF5LCBBcHJpbCAxMSwgMjAxNiAxMjozMCBQTQ0KVG86IE5hdCBT
YWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+Pg0K
Q2M6IDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+PiA8b2F1dGhAaWV0Zi5v
cmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIENhbGwg
Zm9yIEFkb3B0aW9uOiBSZXNvdXJjZSBJbmRpY2F0b3JzIGZvciBPQXV0aCAyLjANCg0KU2VuZGlu
ZyBhIHRva2VuIHR5cGUgaXMgbm90IHN1ZmZpY2llbnQuIFRoZXJlJ3MgbW9yZSBpbnZvbHZlZCB0
aGFuIHRoZSBmb3JtYXQuIE1hbnkgY2FzZXMgbmVlZCB0byBrbm93IGlmIHRvIGVuY3J5cHQgYW5k
IHdob20gdG8gZW5jcnlwdCB0by4gIFdoYXQgY2xhaW1zIHRvIHB1dCBpbiB0aGUgdG9rZW4gKG9y
IHJlZmVyZW5jZSBieSB0aGUgdG9rZW4pLiBXaGF0IGFsZ29yaXRobXMgYW5kIGtleXMgdG8gdXNl
IGZvciBzaWduaW5nL2VuY3J5cHRpb24uDQoNClRoZSBzdGF0ZW1lbnQgdGhhdCB0aGUgIkN1cnJl
bnQgcHJvcG9zYWwgZG9lcyBub3Qgc3VwcG9ydCB0aGUgaW1wbGljaXQgZmxvdyIgaXMgaW5jb3Jy
ZWN0LiBBbW9uZyBvdGhlciB0aGluZ3MsIHNlYyAyIGhhcywgIldoZW4gYW4gYWNjZXNzIHRva2Vu
IHdpbGwgYmUgcmV0dXJuZWQgZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCwgdGhlICJy
ZXNvdXJjZSIgcGFyYW1ldGVyIGlzIHVzZWQgaW4gdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdCB0
byB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBhcyBkZWZpbmVkIGluIFNlY3Rpb24gNC4yLjEg
b2YgT0F1dGggMi4wIFtSRkM2NzQ5XS4iDQoNCk9uIFN1biwgQXByIDEwLCAyMDE2IGF0IDExOjQz
IEFNLCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86c2FraW11cmFAZ21h
aWwuY29tPj4gd3JvdGU6DQpTbywgbXkgdW5kZXJzdGFuZGluZyBvbiB0aGUgcmF0aW9uYWxlL3Jl
cXVpcmVtZW50cyBmb3IgaGF2aW5nIHRoaXMgc3BlYyByaWdodCBub3cgaXM6DQoNClIxLiBBdXRo
eiBzZXJ2ZXIgd2FudHMgdG9wcmV2ZW50IHRoZSByZXBsYXkgYnkgdGhlIHNlcnZlciB0aGF0IHJl
Y2VpdmVkIGl0Lg0KUjIuIEF1dGh6IHNlcnZlciBuZWVkcyB0byBtaW50IHRoZSBhY2Nlc3MgdG9r
ZW4gaW4gYSB2YXJpZXR5IG9mIGZvcm1hdCBkZXBlbmRpbmcgb24gdGhlIHJlc291cmNlIHNlcnZl
ciBhbmQgdG8gZG8gdGhhdCwgeW91IG5lZWQgdG8ga25vdyB3aGljaCBSUyBpcyBnb25nIHRvIGJl
IHJlY2VpdmluZyBpdC4NCg0KVG8gYWNoaWV2ZSBSMSwgdGhlcmUgYXJlIGNvdXBsZSBvZiBtZXRo
b2RzLiBUaGUgcHJvcG9zZWQgbWV0aG9kIGhlcmUgaXMgdG8gYXVkaWVuY2UgcmVzdHJpY3QgdGhl
IHRva2VuLCBidXQgdGhlIHNhbWUgY2FuIGJlIGFjaGlldmVkIGJ5IHNlbmRlciBjb25zdHJhaW5p
bmcgdGhlIHRva2VuLCBlLmcuLCBieSB0b2tlbiBiaW5kaW5nLiBBcyBmYXIgYXMgSSBjYW4gc2Vl
LCB0aGUgc2VudGltZW50IG9mIHRoZSBXRyBzZWVtcyB0byBiZSB0byB1c2UgdGhlIHNlbmRlciBj
b25zdHJhaW50IHRocm91Z2ggVG9rZW4gQmluZGluZywgc28gZnJvbSB0aGlzIHJlc3BlY3QsIHRo
aXMgc3BlYyBpcyBub3QgdGhlIG9uZSB0byBkbyBSMS4gQmVzaWRlcywgdGhlIGN1cnJlbnQgcHJv
cG9zYWwgb25seSB0YWtlcyBjYXJlIG9mIHRoZSBjb2RlIGZsb3cuIFRoZSBzYW1lIHJlcXVpcmVt
ZW50IHNob3VsZCBiZSB0aGVyZSBmb3IgaW1wbGljaXQgZmxvdyBhcyB3ZWxsLCBzbyB0aGUgY3Vy
cmVudCBwcm9wb3NhbCBpcyBub3QgY292ZXJpbmcgdGhlIFIxIGFueXdheXMuDQoNCkkgY2FuIHNv
cnQgb2YgdW5kZXJzdGFuZCBSMiwgYnV0IEkgaGF2ZSB0d28gY3JpdGlxdWUgb24gdGhlIGN1cnJl
bnQgcHJvcG9zYWw6DQoNCkMxLiBDdXJyZW50IHByb3Bvc2FsIGRvZXMgbm90IHN1cHBvcnQgdGhl
IGltcGxpY2l0IGZsb3cuIFRvIHN1cHBvcnQgaXQsIHRoZSByZXNvdXJjZSBVUkkgaGFzIHRvIGJl
IHNlbnQgdG8gdGhlIEF1dGh6IGVuZHBvaW50IGluc3RlYWQgb2YgdGhlIFRva2VuIGVuZHBvaW50
Lg0KQzIuIEl0IGlzIG11Y2ggbW9yZSBkaXJlY3QgdG8gc2VuZCB0aGUgcmVxdWlyZWQgdG9rZW4g
Zm9ybWF0IHJhdGhlciB0aGFuIHRoZSBSUyB1cmkgYW5kIHByb2JhYmx5IGJldHRlciBhczoNCiAg
MSkgVGhlcmUgYXJlIHVzZSBjYXNlcyB3aGVyZSB0aGUgQVMgZG9lcyBub3QgbWFpbnRhaW4gdGhl
IGxpc3Qgb2YgUlNzIHRoYXQgaXQgc3VwcG9ydHMsIGUuZy4sIEFPTC4NCiAgICAgICBJbiBzdWNo
IGEgY2FzZSwgZXZlbiBpZiB0aGUgUlMgdXJpIHdlcmUgc2VudCB0byB0aGUgQVMsIHRoZSBBUyBj
YW5ub3QgbWludCB0aGUgdG9rZW5zIGluIHRoZSBhcHByb3ByaWF0ZSBmb3JtYXQuDQogIDIpIFdo
ZW4gaXQgaXMgc2VudCBpbiB0aGUgQXV0aHogcmVxdWVzdCwgaXQgaXMgbGVha2luZyB0aGUgaW5m
b3JtYXRpb24gYWJvdXQgdGhlIHJlc291cmNlIHRoYXQgdGhlIGNsaWVudCBpcyBnb2luZyB0byB0
aGUgYnJvd3Nlci4NCiAgMykgVGhlcmUgYXJlIHVzZSBjYXNlcyB3aGVyZSBpdCBpcyBkZXNpcmFi
bGUgbm90IHRvIGxldCB0aGUgQVMga25vd3Mgd2hlcmUgdGhlIENsaWVudCBpcyBnb2luZyBmcm9t
IHRoZSBwcml2YWN5IHBvaW50IG9mIHZpZXcuDQoNClNvLCBteSBzdWdnZXN0aW9uIGlzIHRvIGRy
b3AgUjEgYW5kIGNvbmNlbnRyYXRlIG9uIFIyLiBBbmQgdG8gc29sdmUgUjIsIHNlbmQgdG9rZW4g
dHlwZSBpbnN0ZWFkIG9mIHRoZSByZXNvdXJjZSBpbmRpY2F0b3IgaW4gdGhlIHJlcXVlc3QuDQpU
aGlzIGFsc28gbmVjZXNzaXRhdGVzIHRoZSBDbGllbnQgdG8gYmUgYWJsZSB0byBmaW5kIG91dCB3
aGF0IHRva2VuIHR5cGUgdGhlIHJlc291cmNlIHJlcXVpcmVzLCBwZXJoYXBzIGluIHRoZSB1bmF1
dGhvcml6ZWQgcmVzcG9uc2Ugd2ViIGxpbmsgaGVhZGVyIGF0IHRoZSByZXNvdXJjZSBpbiB0aGUg
bWFubmVyIG9mIG9hdXRoLW1ldGEuDQoNCkNoZWVycywNCg0KTmF0DQoNCg0KDQoyMDE25bm0NOac
iDjml6Uo6YeRKSA4OjIzIFByYXRlZWsgTWlzaHJhIDxQcmF0ZWVrLk1pc2hyYUBvcmFjbGUuY29t
PG1haWx0bzpQcmF0ZWVrLk1pc2hyYUBvcmFjbGUuY29tPj46DQpXaGlsZSB0aGlzIHdvcmsgYWRk
cmVzc2VzIGEgZ2FwIGluIHRoZSBleGlzdGluZyBPQXV0aCBzcGVjaWZpY2F0aW9uIHNldCwgSSBh
bSB2ZXJ5IGNvbmNlcm5lZCB0aGF0IHRoaXMNCmluY3JlbWVudGFsIGV4dGVuc2lvbiB3aWxsIGxl
YWQgdG8gZXZlbiBtb3JlIGNvbmZ1c2lvbiBhcm91bmQgdGhlIGFyZWFzIG9mIOKAnHNjb3Bl4oCd
LCDigJxhdWRpZW5jZeKAnSBhbmQg4oCccmVzb3VyY2Ugc2VydmVy4oCdLg0KDQpJIHRoaW5rIHdl
IHNob3VsZCB0cnkgdG8gc29sdmUgdGhpcyBwcm9ibGVtIHZpYSAgYSBmcmFtZXdvcmsgdGhhdCBw
cm92aWRlcyBiZXR0ZXIgZ3VpZGFuY2UgYW5kIGltcGxlbWVudGF0aW9uDQptb2RlbHMgZm9yIE9B
dXRoIHVzZS1jYXNlcy4gSW4gb3RoZXIgd29yZHMsIEkgZmVlbCB0aGF0IGEgYnJvYWRlciBkaXNj
dXNzaW9uIGlzIG5lZWRlZCBoZXJlLg0KDQoNCj4gT24gQXByIDcsIDIwMTYsIGF0IDQ6MTEgUE0s
IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4g
d3JvdGU6DQo+DQo+IEkgc3VwcG9ydCBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50IGFzIGEgc3Rh
cnRpbmcgcG9pbnQgZm9yIHdvcmtpbmcgZ3JvdXAgd29yay4NCj4NCj4g4oCUIEp1c3Rpbg0KPg0K
Pg0KPj4gT24gQXByIDYsIDIwMTYsIGF0IDE6MjUgUE0sIEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5u
ZXMudHNjaG9mZW5pZ0BnbXgubmV0PG1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Pj4g
d3JvdGU6DQo+Pg0KPj4gSGkgYWxsLA0KPj4NCj4+IHRoaXMgaXMgdGhlIGNhbGwgZm9yIGFkb3B0
aW9uIG9mICdSZXNvdXJjZSBJbmRpY2F0b3JzIGZvciBPQXV0aCAyLjAnLCBzZWUNCj4+IGh0dHA6
Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtY2FtcGJlbGwtb2F1dGgtcmVzb3VyY2Ut
aW5kaWNhdG9ycy88aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29t
Lz91cmw9aHR0cCUzYSUyZiUyZmRhdGF0cmFja2VyLmlldGYub3JnJTJmZG9jJTJmZHJhZnQtY2Ft
cGJlbGwtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycyUyZiZkYXRhPTAxJTdjMDElN2N0b255bmFk
JTQwbWljcm9zb2Z0LmNvbSU3Yzk1OTBlNDAyNWViNjQ0MmVjZWRlMDhkMzYyM2ZjOTYxJTdjNzJm
OTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPXk4NjlGazk5ODdmZjA5aHZI
SU4lMmJWR2wlMmZxeHdXRG1rdk93emNRY1dxWFp3JTNkPg0KPj4NCj4+IFBsZWFzZSBsZXQgdXMg
a25vdyBieSBBcHJpbCAyMHRoIHdoZXRoZXIgeW91IGFjY2VwdCAvIG9iamVjdCB0byB0aGUNCj4+
IGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgYXMgYSBzdGFydGluZyBwb2ludCBmb3Igd29yayBp
biB0aGUgT0F1dGgNCj4+IHdvcmtpbmcgZ3JvdXAuDQo+Pg0KPj4gTm90ZTogSWYgeW91IGFscmVh
ZHkgc3RhdGVkIHlvdXIgb3BpbmlvbiBhdCB0aGUgSUVURiBtZWV0aW5nIGluIEJ1ZW5vcw0KPj4g
QWlyZXMgdGhlbiB5b3UgZG9uJ3QgbmVlZCB0byByZS1zdGF0ZSB5b3VyIG9waW5pb24sIGlmIHlv
dSB3YW50Lg0KPj4NCj4+IFRoZSBmZWVkYmFjayBhdCB0aGUgQkEgSUVURiBtZWV0aW5nIHdhcyB0
aGUgZm9sbG93aW5nOiB+MTAgcGVyc29ucw0KPj4gZm9yIGFjY2VwdGluZyB0aGUgZG9jdW1lbnQg
YW5kIDAgcGVyc29ucyBhZ2FpbnN0Lg0KPj4NCj4+IENpYW8NCj4+IEhhbm5lcyAmIERlcmVrDQo+
Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+
IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYu
b3JnPg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRw
czovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUy
ZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRhdGE9MDElN2Mw
MSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjOTU5MGU0MDI1ZWI2NDQyZWNlZGUwOGQzNjIz
ZmM5NjElN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9YmZwMURH
SDVqJTJidE00WnR4N00lMmJ1ZUs3S3hWNmtOSkVYWktIRUNJVUtpQlElM2Q+DQo+DQo+IF9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9BdXRoIG1haWxp
bmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQo+IGh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8aHR0cHM6Ly9uYTAxLnNhZmVs
aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5v
cmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQw
bWljcm9zb2Z0LmNvbSU3Yzk1OTBlNDAyNWViNjQ0MmVjZWRlMDhkMzYyM2ZjOTYxJTdjNzJmOTg4
YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPWJmcDFER0g1aiUyYnRNNFp0eDdN
JTJidWVLN0t4VjZrTkpFWFpLSEVDSVVLaUJRJTNkPg0KDQpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRm
Lm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL29hdXRoPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r
LmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZv
JTJmb2F1dGgmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2M5NTkwZTQw
MjVlYjY0NDJlY2VkZTA4ZDM2MjNmYzk2MSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFk
YjQ3JTdjMSZzZGF0YT1iZnAxREdINWolMmJ0TTRadHg3TSUyYnVlSzdLeFY2a05KRVhaS0hFQ0lV
S2lCUSUzZD4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYu
b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRwczov
L25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUy
Znd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRhdGE9MDElN2MwMSU3
Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjOTU5MGU0MDI1ZWI2NDQyZWNlZGUwOGQzNjIzZmM5
NjElN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9YmZwMURHSDVq
JTJidE00WnR4N00lMmJ1ZUs3S3hWNmtOSkVYWktIRUNJVUtpQlElM2Q+DQoNCg0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlz
dA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3Rl
Y3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxt
YW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQu
Y29tJTdjODEyNDQ5NTdmMDg2NDkxZWQ4NDUwOGQzNjJkMDdhMmQlN2M3MmY5ODhiZjg2ZjE0MWFm
OTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9QXBINiUyZmJSczIxT1lVUldXWXg0TjRsV1ZTZUNJ
JTJmQVBqMmVTT0EzZmRjVHclM2Q+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86
T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h
dXRoPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0
dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmZGF0
YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2M4MTI0NDk1N2YwODY0OTFlZDg0
NTA4ZDM2MmQwN2EyZCU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0
YT1BcEg2JTJmYlJzMjFPWVVSV1dZeDRONGxXVlNlQ0klMmZBUGoyZVNPQTNmZGNUdyUzZD4NCg0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA1IDAgMCAwIDAgMCAw
IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2Ut
MToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJy
aTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt
ZmFtaWx5OiJcQE1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0K
LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N
c29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z
aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxp
bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi
bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5
cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7
DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1h
bDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt
ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNw
YWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWls
U3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0
DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh
Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp
biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N
Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6
ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn
dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2
OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t
LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl
Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWYiPlNwZWNpZmljYXRpb25zIHNob3VsZCBiZSBzb21ld2hhdCBjb21wbGV0ZSBh
bmQgbm90IG9wZW4gZW5kZWQvbm90IHRob3VnaHQgb3V0LCB5b3Ugc2hvdWxkIHRoaW5rIGFib3V0
IHRoZSBpc3N1ZXMsIHJlcXVpcmVtZW50cyBhbmQgdXNlIGNhc2VzIGZpcnN0IGJlZm9yZSB5b3Ug
dHJ5IHRvIGZvcmNlIHRoaXMNCiBpbnRvIHRoZSB3b3JraW5nIGdyb3VwIHByb2Nlc3MgYW5kIGNv
bmZ1c2UgcGVvcGxlICwgd2UgaGFkIHRvbyBtYW55IG9mIHRoZXNlIHNwZWNpZmljYXRpb25zIGxh
dGVseS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5XZSBhcmUgbm93IHVwIHRvIDE1JiM0Mzsgc3BlY2lmaWNh
dGlvbnMgdGhhdCBzb21lb25lIGhhcyB0byByZWFkIGFuZCB1bmRlcnN0YW5kIGhvdyB0aGVzZSBh
bGwgbWF5IG9yIG1heSBub3QgZml0IHRvZ2V0aGVyIGFuZCBhbGwgdGhlIGludGVyYWN0aW9ucyB0
aGF0IG1heSBvY2N1ci4gU28gbXVjaCBmb3IgdGhlDQogc2ltcGxlIE9hdXRoLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9z
ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNw
YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxkaXY+DQo8
ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk
ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBKdXN0aW4gUmljaGVy
IFttYWlsdG86anJpY2hlckBtaXQuZWR1XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEFw
cmlsIDEyLCAyMDE2IDU6NDYgQU08YnI+DQo8Yj5Ubzo8L2I+IFRvcnN0ZW4gTG9kZGVyc3RhZHQg
Jmx0O3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Jmd0Ozxicj4NCjxiPkNjOjwvYj4gQW50aG9ueSBO
YWRhbGluICZsdDt0b255bmFkQG1pY3Jvc29mdC5jb20mZ3Q7OyAmbHQ7b2F1dGhAaWV0Zi5vcmcm
Z3Q7ICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVU
SC1XR10gQ2FsbCBmb3IgQWRvcHRpb246IFJlc291cmNlIEluZGljYXRvcnMgZm9yIE9BdXRoIDIu
MDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7MSB0
byBUb3JzdGVu4oCZcyBwb2ludC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkFuZCBhIHJlbWluZGVyIHRvIFRvbnkgdGhhdCBjYWxsIGZvciBhZG9wdGlvbiBp
cyB0aGUgKnN0YXJ0KiBvZiB0aGUgZG9jdW1lbnQgZWRpdGluZyBwcm9jZXNzLCBub3QgdGhlIGVu
ZC4gV2XigJlyZSBub3Qgc2F5aW5nIHRoaXMgaXMgYSBjb21wbGV0ZSBzb2x1dGlvbiB3aXRoIGV2
ZXJ5dGhpbmcgdGhvdWdodCBvdXQgd2hlbiB3ZSBhZG9wdCB0aGUgZG9jdW1lbnQsIHdl4oCZcmUg
c2F5aW5nIGl04oCZcyBhIHByb2JsZW0NCiB3ZSB3YW50IHRvIHdvcmsgb24gYW5kIGEgZGlyZWN0
aW9uIHRoYXQgd2Ugd2FudCB0byBtb3ZlIGluLiBTdG9wIHRyeWluZyB0byBjb25mdXNlIHBlb3Bs
ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A74oCUIEp1c3RpbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5
bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+T24gQXByIDEyLCAyMDE2LCBhdCAxOjMwIEFNLCBUb3JzdGVuIExvZGRl
cnN0ZWR0ICZsdDs8YSBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiPnRvcnN0
ZW5AbG9kZGVyc3RlZHQubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JbmRpY2F0aW5nIHRoZSBy
ZXNvdXJjZSBzZXJ2ZXIgdG8gdGhlIEFTIGFsbG93cyB0aGUgQVMgdG8gYXV0b21hdGljYWxseSBz
ZWxlY3QgdG9rZW4gdHlwZSwgZW5jcnlwdGlvbiBzY2hlbWUgYW5kIHVzZXIgZGF0YSB0byBiZSBw
dXQgaW50byB0aGUgYWNjZXNzIHRva2VuIGJhc2VkIG9uIGEgUlMtc3BlY2lmaWMNCiBwb2xpY3ku
IFNvIHRoZXJlIGlzIG5vIG5lZWQgdG8gZXhwbGljaXRlbHkgYXNrIHRoZSBBUyBmb3IgYSBjZXJ0
YWluIHRva2VuIGZvcm1hdCBvciBlbmNyeXB0aW9uIHNjaGVtZS4mbmJzcDs8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy
Z2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCkFtIDExLjA0LjIwMTYg
dW0gMjI6MzUgc2NocmllYiBBbnRob255IE5hZGFsaW4gJmx0OzxhIGhyZWY9Im1haWx0bzp0b255
bmFkQG1pY3Jvc29mdC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnRvbnluYWRAbWlj
cm9zb2Z0LmNvbTwvc3Bhbj48L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQ7
b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQt
c3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U28gaXTigJlzIGFuIGluY29tcGxldGUg
c29sdXRpb24gdGhlbiA/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5C
cmlhbg0KIENhbXBiZWxsIFs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5j
b20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50
aXR5LmNvbTwvc3Bhbj48L2E+XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu
YnNwOzwvc3Bhbj48YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk
LXNwYWNlIj4mbmJzcDs8L3NwYW4+TW9uZGF5LCBBcHJpbCAxMSwgMjAxNiAxOjM0IFBNPGJyPg0K
PGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh
bj5BbnRob255IE5hZGFsaW4gJmx0OzxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5j
b20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnRvbnluYWRAbWljcm9zb2Z0LmNvbTwvc3Bh
bj48L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw
YWNlIj4mbmJzcDs8L3NwYW4+TmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11
cmFAZ21haWwuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5zYWtpbXVyYUBnbWFpbC5j
b208L3NwYW4+PC9hPiZndDs7ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPjxz
cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm9hdXRoQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7ICZs
dDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw
bGUiPm9hdXRoQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNw
YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbT0FVVEgt
V0ddIENhbGwgZm9yIEFkb3B0aW9uOiBSZXNvdXJjZSBJbmRpY2F0b3JzIGZvciBPQXV0aCAyLjA8
L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Tm8sIEknbSBub3QgYWRkaW5nIHJlcXVp
cmVtZW50cyBmb3IgZW5jcnlwdGlvbi4gSSB3YXMgcG9pbnRpbmcgb3V0IHNvbWUgb2YgdGhlIHdh
eXMgdGhhdCBhbiBhY2Nlc3MgdG9rZW4gbWlnaHQgYmUgZGlmZmVyZW50IGZvciBkaWZmZXJlbnQg
UlNzLjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgQXByIDExLCAyMDE2IGF0
IDI6MTggUE0sIEFudGhvbnkgTmFkYWxpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbnluYWRAbWlj
cm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnRv
bnluYWRAbWljcm9zb2Z0LmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk
ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw
dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWYiPlNvIG5vdyB5b3UgYXJlIGFkZGluZyBtb3JlIHJlcXVpcmVtZW50cyBmb3IgZW5jcnlwdGlv
biA/IFRoZSBtb3JlIHRoaXMgdGhyZWFkIGdvZXMgb24gc2hvd3MgaG93IHVuc3RhYmxlIGFuZCBu
b3QgZnVsbHkgdGhvdWdodCBvdXQgdGhpcyBkcmFmdCBpcyB0byBnbyB0aHJvdWdoIFdHIGFkb3B0
aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxhIG5hbWU9Im1fLTExODcyNjY3MDg0NDAwMTM1OF9fTWFpbEVuZENvbXBvc2UiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr
Om1fLTExODcyNjY3MDg0NDAwMTM1OF9fTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk9B
dXRoDQogW21haWx0bzo8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFy
Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm9hdXRoLWJvdW5jZXNAaWV0
Zi5vcmc8L3NwYW4+PC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz
cDs8L3NwYW4+PGI+T24gQmVoYWxmIE9mPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj
ZSI+Jm5ic3A7PC9zcGFuPjwvYj5CcmlhbiBDYW1wYmVsbDxicj4NCjxiPlNlbnQ6PC9iPjxzcGFu
IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5Nb25kYXksIEFwcmls
IDExLCAyMDE2IDEyOjMwIFBNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252
ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5OYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0
bzpzYWtpbXVyYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6
cHVycGxlIj5zYWtpbXVyYUBnbWFpbC5jb208L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+
PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZsdDs8YSBo
cmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i
Y29sb3I6cHVycGxlIj5vYXV0aEBpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0OyAmbHQ7PGEgaHJlZj0i
bWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9y
OnB1cnBsZSI+b2F1dGhAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv
Yj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtP
QVVUSC1XR10gQ2FsbCBmb3IgQWRvcHRpb246IFJlc291cmNlIEluZGljYXRvcnMgZm9yIE9BdXRo
IDIuMDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VuZGluZyBhIHRva2VuIHR5cGUgaXMgbm90
IHN1ZmZpY2llbnQuIFRoZXJlJ3MgbW9yZSBpbnZvbHZlZCB0aGFuIHRoZSBmb3JtYXQuIE1hbnkg
Y2FzZXMgbmVlZCB0byBrbm93IGlmIHRvIGVuY3J5cHQgYW5kIHdob20gdG8gZW5jcnlwdCB0by4m
bmJzcDsgV2hhdCBjbGFpbXMgdG8gcHV0IGluIHRoZSB0b2tlbiAob3IgcmVmZXJlbmNlIGJ5IHRo
ZSB0b2tlbikuIFdoYXQgYWxnb3JpdGhtcyBhbmQga2V5cyB0byB1c2UgZm9yDQogc2lnbmluZy9l
bmNyeXB0aW9uLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpUaGUgc3RhdGVt
ZW50IHRoYXQgdGhlICZxdW90O0N1cnJlbnQgcHJvcG9zYWwgZG9lcyBub3Qgc3VwcG9ydCB0aGUg
aW1wbGljaXQgZmxvdyZxdW90OyBpcyBpbmNvcnJlY3QuIEFtb25nIG90aGVyIHRoaW5ncywgc2Vj
IDIgaGFzLCAmcXVvdDtXaGVuIGFuIGFjY2VzcyB0b2tlbiB3aWxsIGJlIHJldHVybmVkIGZyb20g
dGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQsIHRoZSAmcXVvdDtyZXNvdXJjZSZxdW90OyBwYXJh
bWV0ZXIgaXMgdXNlZCBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IHRvDQogdGhlIGF1dGhv
cml6YXRpb24gZW5kcG9pbnQgYXMgZGVmaW5lZCBpbiBTZWN0aW9uIDQuMi4xIG9mIE9BdXRoIDIu
MCBbUkZDNjc0OV0uJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPk9uIFN1biwgQXByIDEwLCAyMDE2IGF0IDExOjQzIEFNLCBOYXQgU2FraW11
cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r
Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5zYWtpbXVyYUBnbWFpbC5jb208L3NwYW4+PC9h
PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi
b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp
biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln
aHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5TbywgbXkgdW5kZXJzdGFuZGluZyBvbiB0aGUgcmF0aW9uYWxlL3JlcXVpcmVtZW50
cyBmb3IgaGF2aW5nIHRoaXMgc3BlYyByaWdodCBub3cgaXM6Jm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5SMS4gQXV0aHogc2VydmVyIHdhbnRzIHRvcHJldmVudCB0aGUgcmVwbGF5IGJ5IHRoZSBz
ZXJ2ZXIgdGhhdCByZWNlaXZlZCBpdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlIyLiBBdXRoeiBzZXJ2ZXIg
bmVlZHMgdG8gbWludCB0aGUgYWNjZXNzIHRva2VuIGluIGEgdmFyaWV0eSBvZiBmb3JtYXQgZGVw
ZW5kaW5nIG9uIHRoZSByZXNvdXJjZSBzZXJ2ZXIgYW5kIHRvIGRvIHRoYXQsIHlvdSBuZWVkIHRv
IGtub3cgd2hpY2ggUlMgaXMgZ29uZyB0byBiZSByZWNlaXZpbmcgaXQuJm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPlRvIGFjaGlldmUgUjEsIHRoZXJlIGFyZSBjb3VwbGUgb2YgbWV0
aG9kcy4gVGhlIHByb3Bvc2VkIG1ldGhvZCBoZXJlIGlzIHRvIGF1ZGllbmNlIHJlc3RyaWN0IHRo
ZSB0b2tlbiwgYnV0IHRoZSBzYW1lIGNhbiBiZSBhY2hpZXZlZCBieSBzZW5kZXIgY29uc3RyYWlu
aW5nIHRoZSB0b2tlbiwgZS5nLiwgYnkgdG9rZW4gYmluZGluZy4gQXMgZmFyIGFzIEkgY2FuIHNl
ZSwgdGhlIHNlbnRpbWVudCBvZiB0aGUgV0cNCiBzZWVtcyB0byBiZSB0byB1c2UgdGhlIHNlbmRl
ciBjb25zdHJhaW50IHRocm91Z2ggVG9rZW4gQmluZGluZywgc28gZnJvbSB0aGlzIHJlc3BlY3Qs
IHRoaXMgc3BlYyBpcyBub3QgdGhlIG9uZSB0byBkbyBSMS4gQmVzaWRlcywgdGhlIGN1cnJlbnQg
cHJvcG9zYWwgb25seSB0YWtlcyBjYXJlIG9mIHRoZSBjb2RlIGZsb3cuIFRoZSBzYW1lIHJlcXVp
cmVtZW50IHNob3VsZCBiZSB0aGVyZSBmb3IgaW1wbGljaXQgZmxvdyBhcyB3ZWxsLCBzbyB0aGUN
CiBjdXJyZW50IHByb3Bvc2FsIGlzIG5vdCBjb3ZlcmluZyB0aGUgUjEgYW55d2F5cy4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBjYW4gc29ydCBvZiB1bmRlcnN0YW5kIFIyLCBi
dXQgSSBoYXZlIHR3byBjcml0aXF1ZSBvbiB0aGUgY3VycmVudCBwcm9wb3NhbDombmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QzEuIEN1cnJlbnQgcHJvcG9zYWwgZG9lcyBub3Qgc3Vw
cG9ydCB0aGUgaW1wbGljaXQgZmxvdy4gVG8gc3VwcG9ydCBpdCwgdGhlIHJlc291cmNlIFVSSSBo
YXMgdG8gYmUgc2VudCB0byB0aGUgQXV0aHogZW5kcG9pbnQgaW5zdGVhZCBvZiB0aGUgVG9rZW4g
ZW5kcG9pbnQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DMi4gSXQgaXMgbXVjaCBtb3JlIGRpcmVjdCB0byBz
ZW5kIHRoZSByZXF1aXJlZCB0b2tlbiBmb3JtYXQgcmF0aGVyIHRoYW4gdGhlIFJTIHVyaSBhbmQg
cHJvYmFibHkgYmV0dGVyIGFzOiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IDEpIFRoZXJlIGFyZSB1
c2UgY2FzZXMgd2hlcmUgdGhlIEFTIGRvZXMgbm90IG1haW50YWluIHRoZSBsaXN0IG9mIFJTcyB0
aGF0IGl0IHN1cHBvcnRzLCBlLmcuLCBBT0wuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDtJbiBzdWNoIGEgY2FzZSwgZXZlbiBpZiB0aGUgUlMgdXJpIHdlcmUgc2Vu
dCB0byB0aGUgQVMsIHRoZSBBUyBjYW5ub3QgbWludCB0aGUgdG9rZW5zIGluIHRoZSBhcHByb3By
aWF0ZSBmb3JtYXQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgMikgV2hlbiBpdCBpcyBzZW50IGlu
IHRoZSBBdXRoeiByZXF1ZXN0LCBpdCBpcyBsZWFraW5nIHRoZSBpbmZvcm1hdGlvbiBhYm91dCB0
aGUgcmVzb3VyY2UgdGhhdCB0aGUgY2xpZW50IGlzIGdvaW5nIHRvIHRoZSBicm93c2VyLiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Jm5ic3A7IDMpIFRoZXJlIGFyZSB1c2UgY2FzZXMgd2hlcmUgaXQgaXMgZGVz
aXJhYmxlIG5vdCB0byBsZXQgdGhlIEFTIGtub3dzIHdoZXJlIHRoZSBDbGllbnQgaXMgZ29pbmcg
ZnJvbSB0aGUgcHJpdmFjeSBwb2ludCBvZiB2aWV3LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5TbywgbXkgc3VnZ2VzdGlvbiBpcyB0byBkcm9wIFIxIGFuZCBjb25jZW50cmF0ZSBv
biBSMi4gQW5kIHRvIHNvbHZlIFIyLCBzZW5kIHRva2VuIHR5cGUgaW5zdGVhZCBvZiB0aGUgcmVz
b3VyY2UgaW5kaWNhdG9yIGluIHRoZSByZXF1ZXN0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBhbHNv
IG5lY2Vzc2l0YXRlcyB0aGUgQ2xpZW50IHRvIGJlIGFibGUgdG8gZmluZCBvdXQgd2hhdCB0b2tl
biB0eXBlIHRoZSByZXNvdXJjZSByZXF1aXJlcywgcGVyaGFwcyBpbiB0aGUgdW5hdXRob3JpemVk
IHJlc3BvbnNlIHdlYiBsaW5rIGhlYWRlciBhdCB0aGUgcmVzb3VyY2UgaW4gdGhlIG1hbm5lciBv
ZiBvYXV0aC1tZXRhLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMsJm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5hdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MjAxNjxzcGFuIHN0eWxlPSJm
b250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuW5tDwvc3Bhbj40PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5pyIPC9zcGFuPjg8c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7ml6U8L3NwYW4+KDxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPumHkTwvc3Bhbj4pIDg6MjMg
UHJhdGVlayBNaXNocmEgJmx0OzxhIGhyZWY9Im1haWx0bzpQcmF0ZWVrLk1pc2hyYUBvcmFjbGUu
Y29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+UHJhdGVlay5N
aXNocmFAb3JhY2xlLmNvbTwvc3Bhbj48L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk
ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy
Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1i
b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoaWxlIHRoaXMgd29y
ayBhZGRyZXNzZXMgYSBnYXAgaW4gdGhlIGV4aXN0aW5nIE9BdXRoIHNwZWNpZmljYXRpb24gc2V0
LCBJIGFtIHZlcnkgY29uY2VybmVkIHRoYXQgdGhpczxicj4NCmluY3JlbWVudGFsIGV4dGVuc2lv
biB3aWxsIGxlYWQgdG8gZXZlbiBtb3JlIGNvbmZ1c2lvbiBhcm91bmQgdGhlIGFyZWFzIG9mIOKA
nHNjb3Bl4oCdLCDigJxhdWRpZW5jZeKAnSBhbmQg4oCccmVzb3VyY2Ugc2VydmVy4oCdLjxicj4N
Cjxicj4NCkkgdGhpbmsgd2Ugc2hvdWxkIHRyeSB0byBzb2x2ZSB0aGlzIHByb2JsZW0gdmlhJm5i
c3A7IGEgZnJhbWV3b3JrIHRoYXQgcHJvdmlkZXMgYmV0dGVyIGd1aWRhbmNlIGFuZCBpbXBsZW1l
bnRhdGlvbjxicj4NCm1vZGVscyBmb3IgT0F1dGggdXNlLWNhc2VzLiBJbiBvdGhlciB3b3Jkcywg
SSBmZWVsIHRoYXQgYSBicm9hZGVyIGRpc2N1c3Npb24gaXMgbmVlZGVkIGhlcmUuPGJyPg0KPGJy
Pg0KPGJyPg0KJmd0OyBPbiBBcHIgNywgMjAxNiwgYXQgNDoxMSBQTSwgSnVzdGluIFJpY2hlciAm
bHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu
IHN0eWxlPSJjb2xvcjpwdXJwbGUiPmpyaWNoZXJAbWl0LmVkdTwvc3Bhbj48L2E+Jmd0OyB3cm90
ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIHN1cHBvcnQgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVu
dCBhcyBhIHN0YXJ0aW5nIHBvaW50IGZvciB3b3JraW5nIGdyb3VwIHdvcmsuPGJyPg0KJmd0Ozxi
cj4NCiZndDsg4oCUIEp1c3Rpbjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgT24g
QXByIDYsIDIwMTYsIGF0IDE6MjUgUE0sIEhhbm5lcyBUc2Nob2ZlbmlnICZsdDs8YSBocmVmPSJt
YWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0
eWxlPSJjb2xvcjpwdXJwbGUiPmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ8L3NwYW4+PC9hPiZn
dDsgd3JvdGU6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBIaSBhbGwsPGJyPg0KJmd0OyZn
dDs8YnI+DQomZ3Q7Jmd0OyB0aGlzIGlzIHRoZSBjYWxsIGZvciBhZG9wdGlvbiBvZiAnUmVzb3Vy
Y2UgSW5kaWNhdG9ycyBmb3IgT0F1dGggMi4wJywgc2VlPGJyPg0KJmd0OyZndDs8c3BhbiBjbGFz
cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9u
YTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZmRh
dGF0cmFja2VyLmlldGYub3JnJTJmZG9jJTJmZHJhZnQtY2FtcGJlbGwtb2F1dGgtcmVzb3VyY2Ut
aW5kaWNhdG9ycyUyZiZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20l
N2M5NTkwZTQwMjVlYjY0NDJlY2VkZTA4ZDM2MjNmYzk2MSU3YzcyZjk4OGJmODZmMTQxYWY5MWFi
MmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9eTg2OUZrOTk4N2ZmMDlodkhJTiUyYlZHbCUyZnF4
d1dEbWt2T3d6Y1FjV3FYWnclM2QiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6
cHVycGxlIj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNhbXBiZWxsLW9h
dXRoLXJlc291cmNlLWluZGljYXRvcnMvPC9zcGFuPjwvYT48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn
dDsmZ3Q7IFBsZWFzZSBsZXQgdXMga25vdyBieSBBcHJpbCAyMHRoIHdoZXRoZXIgeW91IGFjY2Vw
dCAvIG9iamVjdCB0byB0aGU8YnI+DQomZ3Q7Jmd0OyBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50
IGFzIGEgc3RhcnRpbmcgcG9pbnQgZm9yIHdvcmsgaW4gdGhlIE9BdXRoPGJyPg0KJmd0OyZndDsg
d29ya2luZyBncm91cC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IE5vdGU6IElmIHlvdSBh
bHJlYWR5IHN0YXRlZCB5b3VyIG9waW5pb24gYXQgdGhlIElFVEYgbWVldGluZyBpbiBCdWVub3M8
YnI+DQomZ3Q7Jmd0OyBBaXJlcyB0aGVuIHlvdSBkb24ndCBuZWVkIHRvIHJlLXN0YXRlIHlvdXIg
b3BpbmlvbiwgaWYgeW91IHdhbnQuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGUgZmVl
ZGJhY2sgYXQgdGhlIEJBIElFVEYgbWVldGluZyB3YXMgdGhlIGZvbGxvd2luZzogfjEwIHBlcnNv
bnM8YnI+DQomZ3Q7Jmd0OyBmb3IgYWNjZXB0aW5nIHRoZSBkb2N1bWVudCBhbmQgMCBwZXJzb25z
IGFnYWluc3QuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBDaWFvPGJyPg0KJmd0OyZndDsg
SGFubmVzICZhbXA7IERlcmVrPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7IE9BdXRo
IG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z
cGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0
PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPk9BdXRoQGlldGYub3JnPC9zcGFu
PjwvYT48YnI+DQomZ3Q7Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu
YnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0
bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0
aW5mbyUyZm9hdXRoJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3
Yzk1OTBlNDAyNWViNjQ0MmVjZWRlMDhkMzYyM2ZjOTYxJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIy
ZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1iZnAxREdINWolMmJ0TTRadHg3TSUyYnVlSzdLeFY2
a05KRVhaS0hFQ0lVS2lCUSUzZCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw
dXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L3NwYW4+
PC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fPGJyPg0KJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7PHNw
YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1h
aWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw
dXJwbGUiPk9BdXRoQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQomZ3Q7PHNwYW4gY2xhc3M9ImFw
cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5z
YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3Lmll
dGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmYW1wO2RhdGE9MDElN2MwMSU3Y3Rv
bnluYWQlNDBtaWNyb3NvZnQuY29tJTdjOTU5MGU0MDI1ZWI2NDQyZWNlZGUwOGQzNjIzZmM5NjEl
N2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPWJmcDFER0g1
aiUyYnRNNFp0eDdNJTJidWVLN0t4VjZrTkpFWFpLSEVDSVVLaUJRJTNkIiB0YXJnZXQ9Il9ibGFu
ayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aDwvc3Bhbj48L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+
DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz
dHlsZT0iY29sb3I6cHVycGxlIj5PQXV0aEBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGEgaHJl
Zj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0
cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZhbXA7
ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2M5NTkwZTQwMjVlYjY0NDJl
Y2VkZTA4ZDM2MjNmYzk2MSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZh
bXA7c2RhdGE9YmZwMURHSDVqJTJidE00WnR4N00lMmJ1ZUs3S3hWNmtOSkVYWktIRUNJVUtpQlEl
M2QiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxp
bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh
bmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPk9BdXRoQGlldGYub3JnPC9zcGFuPjwvYT48
YnI+DQo8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5j
b20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUy
Zm9hdXRoJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Yzk1OTBl
NDAyNWViNjQ0MmVjZWRlMDhkMzYyM2ZjOTYxJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAx
MWRiNDclN2MxJmFtcDtzZGF0YT1iZnAxREdINWolMmJ0TTRadHg3TSUyYnVlSzdLeFY2a05KRVha
S0hFQ0lVS2lCUSUzZCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi
Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L3NwYW4+PC9hPjxv
OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0
O21hcmdpbi1ib3R0b206NS4wcHQ7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93
czogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw
dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+X19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5n
IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJj
b2xvcjpwdXJwbGUiPk9BdXRoQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8YSBocmVmPSJodHRw
czovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUy
ZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmFtcDtkYXRhPTAx
JTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzgxMjQ0OTU3ZjA4NjQ5MWVkODQ1MDhk
MzYyZDA3YTJkJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0
YT1BcEg2JTJmYlJzMjFPWVVSV1dZeDRONGxXVlNlQ0klMmZBUGoyZVNPQTNmZGNUdyUzZCI+PHNw
YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vYXV0aDwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Js
b2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxp
bmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlIj5PQXV0aEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3Mu
cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJm
bWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBt
aWNyb3NvZnQuY29tJTdjODEyNDQ5NTdmMDg2NDkxZWQ4NDUwOGQzNjJkMDdhMmQlN2M3MmY5ODhi
Zjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPUFwSDYlMmZiUnMyMU9ZVVJX
V1l4NE40bFdWU2VDSSUyZkFQajJlU09BM2ZkY1R3JTNkIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvc3Bh
bj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9ib2R5Pg0KPC9odG1sPg0K

--_000_BN3PR0301MB12341A528F84D33823F66387A6950BN3PR0301MB1234_--


From nobody Tue Apr 12 08:58:13 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158E912DD63 for ; Tue, 12 Apr 2016 08:58:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.198
X-Spam-Level: 
X-Spam-Status: No, score=-5.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3iHlQabX9kA for ; Tue, 12 Apr 2016 08:58:10 -0700 (PDT)
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 B9DBE12DA06 for ; Tue, 12 Apr 2016 08:58:10 -0700 (PDT)
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u3CFw8u1005554 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Apr 2016 15:58:09 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u3CFw8VM031310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Apr 2016 15:58:08 GMT
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u3CFw7fv009344; Tue, 12 Apr 2016 15:58:08 GMT
Received: from [10.0.1.3] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 12 Apr 2016 08:58:07 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13E238)
In-Reply-To: <570CB228.8070703@gmail.com>
Date: Tue, 12 Apr 2016 08:58:05 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <9E82A52C-6E06-48D2-A364-A033E921FEF7@oracle.com>
References: <2D15E964-8A56-417C-A3CB-78CFAB5DFA34@oracle.com>  <824192A8-4F6F-4002-B7E0-518CAA0BF34A@oracle.com> <570CB228.8070703@gmail.com>
To: Sergey Beryozkin 
X-Source-IP: userv0021.oracle.com [156.151.31.71]
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Regarding using resource indicator to solve resource config issue
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Apr 2016 15:58:12 -0000

John's assertion that RI can be used to detect mis-configured clients would m=
ake it mandatory.=20

To avoid that we need a config time solution for misconfiguration.=20

Phil

> On Apr 12, 2016, at 01:30, Sergey Beryozkin  wrote:
>=20
> Hi
>> On 11/04/16 23:19, Phil Hunt (IDM) wrote:
>> I am objecting to modifying the protocol in the default case as a
>> majority do not need RI in the case of fixed endpoints.
>>=20
>> Migration would be challenging because the change is breaking and
>> affects existing clients.
> How does it break the existing clients given this is an optional feature ?=
 Can you please describe the situation where the existing clients get broken=
 ?
>=20
> Brian, would it make sense to update the text to mention that the clients d=
o not have to be directly configured and instead it can be set during the re=
gistration time, so that the property gets seamlessly linked to client acces=
s tokens, etc, without the client applications having to be set up with the r=
esource indicators manually ?
>=20
> Thanks, Sergey
>=20
>> Dynamic discovery are up and coming cases and a relatively green field.
>> Dealing with it at configuration/discovery makes broader sense as it has
>> no impact on existing clients.
>>=20
>> Phil
>>=20
>> On Apr 11, 2016, at 12:18, Brian Campbell > > wrote:
>>=20
>>> I'm not sure where the idea that it's only applicable to special uses
>>> like collaboration services is coming from. The pattern described in
>>> the draft (using a different parameter name but otherwise the same) is
>>> deployed and in-use for normal OAuth cases including and especially
>>> the resource owner centric ones.
>>>=20
>>>=20
>>> On Mon, Apr 11, 2016 at 11:33 AM, Phil Hunt (IDM)
>>> > wrote:
>>>=20
>>>    I am finding I am not happy with solving the bad resource endpoint
>>>    config issue with resource indicator. At best I see this as a
>>>    special use draft for things like collab services or things which
>>>    aren't resource owner centric.
>>>=20
>>>    Yet resource endpoint config is a concern for all clients that
>>>    configure on the fly. Is it reasonable to make resource indicator
>>>    mandatory for all clients? Probably not.
>>>=20
>>>    As OAuth depends primarily on TLS, it feels wrong not to have a
>>>    solution that confirms the server host names are correct either
>>>    via config lookup or some other mechanism.
>>>=20
>>>    Tokbind is also a solution but I suspect it may only appeal to
>>>    large scale service providers and may be further off as we wait
>>>    for load balancers to support tokbind. Also there are issues with
>>>    tokbind on initial user binding where the mitm attack might itself
>>>    establish its own token binding. I have to think this through some
>>>    to confirm. But the issue of worry is what is happening on
>>>    initialization and first use if the hacker has already interceded
>>>    a mitm. That would make validation at config time still critical.
>>>=20
>>>    Hopefully somebody can arrive at an alternative for broader oauth
>>>    use cases.
>>>=20
>>>    Phil
>>>    _______________________________________________
>>>    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
> Sergey Beryozkin
>=20
> Talend Community Coders
> http://coders.talend.com/


From nobody Tue Apr 12 09:00:56 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BECE12D5E0 for ; Tue, 12 Apr 2016 09:00:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.198
X-Spam-Level: 
X-Spam-Status: No, score=-5.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swesvfbB_4Qa for ; Tue, 12 Apr 2016 09:00:52 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19B3F12D1BD for ; Tue, 12 Apr 2016 09:00:52 -0700 (PDT)
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u3CG0nbA021163 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Apr 2016 16:00:50 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u3CG0ntl006158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Apr 2016 16:00:49 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u3CG0m2Q010424; Tue, 12 Apr 2016 16:00:48 GMT
Received: from [10.0.1.3] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 12 Apr 2016 09:00:48 -0700
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13E238)
In-Reply-To: <22B70247-C110-4D91-B510-1CCD59CB0260@ve7jtb.com>
Date: Tue, 12 Apr 2016 09:00:45 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <2CC00BB1-ADB6-4E1B-B0FF-E169871F700E@oracle.com>
References: <2D15E964-8A56-417C-A3CB-78CFAB5DFA34@oracle.com>  <824192A8-4F6F-4002-B7E0-518CAA0BF34A@oracle.com> <570CB228.8070703@gmail.com> <22B70247-C110-4D91-B510-1CCD59CB0260@ve7jtb.com>
To: John Bradley 
X-Source-IP: aserv0022.oracle.com [141.146.126.234]
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Regarding using resource indicator to solve resource config issue
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Apr 2016 16:00:54 -0000

Phil

> On Apr 12, 2016, at 03:49, John Bradley  wrote:
>=20
> We did agree in BA that if the client sends no resource the AS would audie=
nce the AT per configured policy and reply to the client with additional met=
a-data about what resources the AT can be used at.

We also agreed that was not a remedy for an attack where an attacker simply w=
ants the token to use at the correct site to gain access to the resource.=20=


RI is no remedy for misconfiguration esp if it should be optional for the cl=
ient.=20
>=20
> It should be obvious that this is in no way a breaking change.
>=20
> The only clients that need to provide a resource are ones that are asking f=
or a token for a unknown resource, not something that is supported securely c=
urrently or by Pil=E2=80=99s spec.   Or when down scoping  a RT with multipl=
e audiences so that the server can provide the correct token type/ claims / e=
ncryption/ signing.   Can we agree that with symmetrically signed AT it is n=
ot a good thing to use the same key for all RS?
>=20
> At the moment this can sort of be done with scopes but the client needs mu=
ch more documentation about the scopes to understand the mapping between res=
ource and scope, or possibly discovery of meta-data about the resource, some=
thing also not covered in Phil=E2=80=99s draft.
>=20
> We can update the draft as an ID. =20
>=20
> This is essentially the audience part of the POP key distribution with the=
 addition of Nat=E2=80=99s meta-data for the token endpoint (in the existing=
 JSON rather than a new header)
>=20
> We need to address this.  Discovery in general and Phil=E2=80=99s draft sp=
ecifically are not a replacement, even if we were to adopt them.
>=20
> To Phil=E2=80=99s other question about token binding, no an attacker can=E2=
=80=99t usefully  MitM a token bound AT. =20
> The private key is controlled by the client and never disclosed.  You can g=
ive the token to a MitM attacker but they cannot use it anyplace even with t=
hemselves as they don=E2=80=99t have the private key.   That is the security=
 goal of token binding.
>=20
> John B.
>=20
>> On Apr 12, 2016, at 4:30 AM, Sergey Beryozkin  wrot=
e:
>>=20
>> Hi
>>> On 11/04/16 23:19, Phil Hunt (IDM) wrote:
>>> I am objecting to modifying the protocol in the default case as a
>>> majority do not need RI in the case of fixed endpoints.
>>>=20
>>> Migration would be challenging because the change is breaking and
>>> affects existing clients.
>> How does it break the existing clients given this is an optional feature ?=
 Can you please describe the situation where the existing clients get broken=
 ?
>>=20
>> Brian, would it make sense to update the text to mention that the clients=
 do not have to be directly configured and instead it can be set during the r=
egistration time, so that the property gets seamlessly linked to client acce=
ss tokens, etc, without the client applications having to be set up with the=
 resource indicators manually ?
>>=20
>> Thanks, Sergey
>>=20
>>> Dynamic discovery are up and coming cases and a relatively green field.
>>> Dealing with it at configuration/discovery makes broader sense as it has=

>>> no impact on existing clients.
>>>=20
>>> Phil
>>>=20
>>> On Apr 11, 2016, at 12:18, Brian Campbell >> > wrote:
>>>=20
>>>> I'm not sure where the idea that it's only applicable to special uses
>>>> like collaboration services is coming from. The pattern described in
>>>> the draft (using a different parameter name but otherwise the same) is
>>>> deployed and in-use for normal OAuth cases including and especially
>>>> the resource owner centric ones.
>>>>=20
>>>>=20
>>>> On Mon, Apr 11, 2016 at 11:33 AM, Phil Hunt (IDM)
>>>> > wrote:
>>>>=20
>>>>   I am finding I am not happy with solving the bad resource endpoint
>>>>   config issue with resource indicator. At best I see this as a
>>>>   special use draft for things like collab services or things which
>>>>   aren't resource owner centric.
>>>>=20
>>>>   Yet resource endpoint config is a concern for all clients that
>>>>   configure on the fly. Is it reasonable to make resource indicator
>>>>   mandatory for all clients? Probably not.
>>>>=20
>>>>   As OAuth depends primarily on TLS, it feels wrong not to have a
>>>>   solution that confirms the server host names are correct either
>>>>   via config lookup or some other mechanism.
>>>>=20
>>>>   Tokbind is also a solution but I suspect it may only appeal to
>>>>   large scale service providers and may be further off as we wait
>>>>   for load balancers to support tokbind. Also there are issues with
>>>>   tokbind on initial user binding where the mitm attack might itself
>>>>   establish its own token binding. I have to think this through some
>>>>   to confirm. But the issue of worry is what is happening on
>>>>   initialization and first use if the hacker has already interceded
>>>>   a mitm. That would make validation at config time still critical.
>>>>=20
>>>>   Hopefully somebody can arrive at an alternative for broader oauth
>>>>   use cases.
>>>>=20
>>>>   Phil
>>>>   _______________________________________________
>>>>   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
>> Sergey Beryozkin
>>=20
>> Talend Community Coders
>> http://coders.talend.com/
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20


From nobody Tue Apr 12 09:05:01 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7A612D6AE for ; Tue, 12 Apr 2016 09:04:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mz-4R4ngGDLa for ; Tue, 12 Apr 2016 09:04:57 -0700 (PDT)
Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::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 886FD12D5E0 for ; Tue, 12 Apr 2016 09:04:56 -0700 (PDT)
Received: by mail-ob0-x22d.google.com with SMTP id tz8so14518678obc.0 for ; Tue, 12 Apr 2016 09:04:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nKd3B++22cUQR+N4y+Ea+JxApqAnhWBZZhvPgTJp35M=; b=Csj1N+nhkCUza6wAInooJR6+QQPOS0tn7UfrZUXGJajbTLqYmJWOevzKkNPhu0CzKK CAYmsUzEtvnvFd6r8FHphHgKdVvpnnmfxCpokaR0MY/CRugqURiJ4q7gGPFd58WCpllc 8aKXrU/6h6lbdA3/dppkbJ8mlh3xnm3GAhMhW9FaqyBPP1b1y88THetDReBBCmoGKJfz akE4k7sPUFWOHToQmfZnzDj9kqFb8c6MoslOMFy2MxoVA2H+ZknbqFczmhcL3fY+TUh4 9N1PT+AMBCturTzxxP1gGACYoKAAyFAZ0grLqYDja/C5X8DHNYOP9kfBIE+UvYtntcOA KSOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nKd3B++22cUQR+N4y+Ea+JxApqAnhWBZZhvPgTJp35M=; b=NomBKXLtrUIYYKoTkIm+9Qr2slvq81vvdqbWT4P42MUBAlDcQQYZHBuk/quO5/eMWC 8W/iqDypxIyXXlB9EtV1pNeJ1KuRThj34T86faiBu7rkXNEQ5e5D3K1dtBFTvyFT6N7t 27BEvoi/XGZQ2dewOBYhZA17PZAa7/Ecruw7kAYikk3Jqkut9o++yFD6+e3Zk6fjOc94 onWELGOq8a2jFLdggp8OQqtmIbEOiHed9xlfMiM95VQGYr13OwbYM/BCpR/0KNc1afQ0 kUIptbcvTlcr/R+fr+o8uqpK4nkNh+65uZDR7ZqAfZxdRPfnCGrJah7L8ui04NgurDbc bzgA==
X-Gm-Message-State: AOPr4FUB8ItH1PmUHSUxo3JLqAS37HHlJcJBjn8eAZZfzUX8lyFfI+u2rD+l3XqRuQxzOQ==
X-Received: by 10.60.117.102 with SMTP id kd6mr1876774oeb.73.1460477095764; Tue, 12 Apr 2016 09:04:55 -0700 (PDT)
Received: from [10.2.2.240] (75-147-25-205-NewEngland.hfc.comcastbusiness.net. [75.147.25.205]) by smtp.gmail.com with ESMTPSA id q81sm10033770ota.29.2016.04.12.09.04.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 12 Apr 2016 09:04:55 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: John Bradley 
In-Reply-To: <9E82A52C-6E06-48D2-A364-A033E921FEF7@oracle.com>
Date: Tue, 12 Apr 2016 12:04:53 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <2D15E964-8A56-417C-A3CB-78CFAB5DFA34@oracle.com>  <824192A8-4F6F-4002-B7E0-518CAA0BF34A@oracle.com> <570CB228.8070703@gmail.com> <9E82A52C-6E06-48D2-A364-A033E921FEF7@oracle.com>
To: "Phil Hunt (IDM)" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Regarding using resource indicator to solve resource config issue
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Apr 2016 16:04:59 -0000

Yes clients that are dynamically configured would need to check the =
returned resources, or send the resource if you want to detect =
misconfiguration.

This check is at run time and can be enforced by the AS.

A discovery check is fake-able if the web-finger URI is compromised.  =
Likely in my opinion if the resource is compromised in the config.  It =
also can not be enforced.   Other than that it is a fine idea.

John B.
> On Apr 12, 2016, at 11:58 AM, Phil Hunt (IDM)  =
wrote:
>=20
> John's assertion that RI can be used to detect mis-configured clients =
would make it mandatory.=20
>=20
> To avoid that we need a config time solution for misconfiguration.=20
>=20
> Phil
>=20
>> On Apr 12, 2016, at 01:30, Sergey Beryozkin  =
wrote:
>>=20
>> Hi
>>> On 11/04/16 23:19, Phil Hunt (IDM) wrote:
>>> I am objecting to modifying the protocol in the default case as a
>>> majority do not need RI in the case of fixed endpoints.
>>>=20
>>> Migration would be challenging because the change is breaking and
>>> affects existing clients.
>> How does it break the existing clients given this is an optional =
feature ? Can you please describe the situation where the existing =
clients get broken ?
>>=20
>> Brian, would it make sense to update the text to mention that the =
clients do not have to be directly configured and instead it can be set =
during the registration time, so that the property gets seamlessly =
linked to client access tokens, etc, without the client applications =
having to be set up with the resource indicators manually ?
>>=20
>> Thanks, Sergey
>>=20
>>> Dynamic discovery are up and coming cases and a relatively green =
field.
>>> Dealing with it at configuration/discovery makes broader sense as it =
has
>>> no impact on existing clients.
>>>=20
>>> Phil
>>>=20
>>> On Apr 11, 2016, at 12:18, Brian Campbell =
>> > wrote:
>>>=20
>>>> I'm not sure where the idea that it's only applicable to special =
uses
>>>> like collaboration services is coming from. The pattern described =
in
>>>> the draft (using a different parameter name but otherwise the same) =
is
>>>> deployed and in-use for normal OAuth cases including and especially
>>>> the resource owner centric ones.
>>>>=20
>>>>=20
>>>> On Mon, Apr 11, 2016 at 11:33 AM, Phil Hunt (IDM)
>>>> > wrote:
>>>>=20
>>>>   I am finding I am not happy with solving the bad resource =
endpoint
>>>>   config issue with resource indicator. At best I see this as a
>>>>   special use draft for things like collab services or things which
>>>>   aren't resource owner centric.
>>>>=20
>>>>   Yet resource endpoint config is a concern for all clients that
>>>>   configure on the fly. Is it reasonable to make resource indicator
>>>>   mandatory for all clients? Probably not.
>>>>=20
>>>>   As OAuth depends primarily on TLS, it feels wrong not to have a
>>>>   solution that confirms the server host names are correct either
>>>>   via config lookup or some other mechanism.
>>>>=20
>>>>   Tokbind is also a solution but I suspect it may only appeal to
>>>>   large scale service providers and may be further off as we wait
>>>>   for load balancers to support tokbind. Also there are issues with
>>>>   tokbind on initial user binding where the mitm attack might =
itself
>>>>   establish its own token binding. I have to think this through =
some
>>>>   to confirm. But the issue of worry is what is happening on
>>>>   initialization and first use if the hacker has already interceded
>>>>   a mitm. That would make validation at config time still critical.
>>>>=20
>>>>   Hopefully somebody can arrive at an alternative for broader oauth
>>>>   use cases.
>>>>=20
>>>>   Phil
>>>>   _______________________________________________
>>>>   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
>> Sergey Beryozkin
>>=20
>> Talend Community Coders
>> http://coders.talend.com/
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Tue Apr 12 09:07:06 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6300112DD5B for ; Tue, 12 Apr 2016 09:07:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.197
X-Spam-Level: 
X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdiLgIKS3cCZ for ; Tue, 12 Apr 2016 09:07:01 -0700 (PDT)
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 8E12C12DBB6 for ; Tue, 12 Apr 2016 09:07:01 -0700 (PDT)
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u3CG70EE019832 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Apr 2016 16:07:00 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u3CG70jF032397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Apr 2016 16:07:00 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u3CG6x3X015548; Tue, 12 Apr 2016 16:06:59 GMT
Received: from [10.0.1.3] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 12 Apr 2016 09:06:59 -0700
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13E238)
In-Reply-To: <2CC00BB1-ADB6-4E1B-B0FF-E169871F700E@oracle.com>
Date: Tue, 12 Apr 2016 09:06:57 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <3BFA50D5-3BE6-4A56-BA52-AB2720B7BC0B@oracle.com>
References: <2D15E964-8A56-417C-A3CB-78CFAB5DFA34@oracle.com>  <824192A8-4F6F-4002-B7E0-518CAA0BF34A@oracle.com> <570CB228.8070703@gmail.com> <22B70247-C110-4D91-B510-1CCD59CB0260@ve7jtb.com> <2CC00BB1-ADB6-4E1B-B0FF-E169871F700E@oracle.com>
To: John Bradley 
X-Source-IP: aserv0022.oracle.com [141.146.126.234]
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Regarding using resource indicator to solve resource config issue
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Apr 2016 16:07:03 -0000

To be clear what I am saying... RI should be considered on its own merits as=
 an optional protocol extension.=20

I do not believe it has merit when linking it to client mis-configuration de=
tection. The issues should be kept separate.=20

Phil

> On Apr 12, 2016, at 09:00, Phil Hunt (IDM)  wrote:
>=20
>=20
>=20
> Phil
>=20
>> On Apr 12, 2016, at 03:49, John Bradley  wrote:
>>=20
>> We did agree in BA that if the client sends no resource the AS would audi=
ence the AT per configured policy and reply to the client with additional me=
ta-data about what resources the AT can be used at.
>=20
> We also agreed that was not a remedy for an attack where an attacker simpl=
y wants the token to use at the correct site to gain access to the resource.=
=20
>=20
> RI is no remedy for misconfiguration esp if it should be optional for the c=
lient.=20
>>=20
>> It should be obvious that this is in no way a breaking change.
>>=20
>> The only clients that need to provide a resource are ones that are asking=
 for a token for a unknown resource, not something that is supported securel=
y currently or by Pil=E2=80=99s spec.   Or when down scoping  a RT with mult=
iple audiences so that the server can provide the correct token type/ claims=
 / encryption/ signing.   Can we agree that with symmetrically signed AT it i=
s not a good thing to use the same key for all RS?
>>=20
>> At the moment this can sort of be done with scopes but the client needs m=
uch more documentation about the scopes to understand the mapping between re=
source and scope, or possibly discovery of meta-data about the resource, som=
ething also not covered in Phil=E2=80=99s draft.
>>=20
>> We can update the draft as an ID. =20
>>=20
>> This is essentially the audience part of the POP key distribution with th=
e addition of Nat=E2=80=99s meta-data for the token endpoint (in the existin=
g JSON rather than a new header)
>>=20
>> We need to address this.  Discovery in general and Phil=E2=80=99s draft s=
pecifically are not a replacement, even if we were to adopt them.
>>=20
>> To Phil=E2=80=99s other question about token binding, no an attacker can=E2=
=80=99t usefully  MitM a token bound AT. =20
>> The private key is controlled by the client and never disclosed.  You can=
 give the token to a MitM attacker but they cannot use it anyplace even with=
 themselves as they don=E2=80=99t have the private key.   That is the securi=
ty goal of token binding.
>>=20
>> John B.
>>=20
>>> On Apr 12, 2016, at 4:30 AM, Sergey Beryozkin  wro=
te:
>>>=20
>>> Hi
>>>> On 11/04/16 23:19, Phil Hunt (IDM) wrote:
>>>> I am objecting to modifying the protocol in the default case as a
>>>> majority do not need RI in the case of fixed endpoints.
>>>>=20
>>>> Migration would be challenging because the change is breaking and
>>>> affects existing clients.
>>> How does it break the existing clients given this is an optional feature=
 ? Can you please describe the situation where the existing clients get brok=
en ?
>>>=20
>>> Brian, would it make sense to update the text to mention that the client=
s do not have to be directly configured and instead it can be set during the=
 registration time, so that the property gets seamlessly linked to client ac=
cess tokens, etc, without the client applications having to be set up with t=
he resource indicators manually ?
>>>=20
>>> Thanks, Sergey
>>>=20
>>>> Dynamic discovery are up and coming cases and a relatively green field.=

>>>> Dealing with it at configuration/discovery makes broader sense as it ha=
s
>>>> no impact on existing clients.
>>>>=20
>>>> Phil
>>>>=20
>>>> On Apr 11, 2016, at 12:18, Brian Campbell >>> > wrote:
>>>>=20
>>>>> I'm not sure where the idea that it's only applicable to special uses
>>>>> like collaboration services is coming from. The pattern described in
>>>>> the draft (using a different parameter name but otherwise the same) is=

>>>>> deployed and in-use for normal OAuth cases including and especially
>>>>> the resource owner centric ones.
>>>>>=20
>>>>>=20
>>>>> On Mon, Apr 11, 2016 at 11:33 AM, Phil Hunt (IDM)
>>>>> > wrote:
>>>>>=20
>>>>>  I am finding I am not happy with solving the bad resource endpoint
>>>>>  config issue with resource indicator. At best I see this as a
>>>>>  special use draft for things like collab services or things which
>>>>>  aren't resource owner centric.
>>>>>=20
>>>>>  Yet resource endpoint config is a concern for all clients that
>>>>>  configure on the fly. Is it reasonable to make resource indicator
>>>>>  mandatory for all clients? Probably not.
>>>>>=20
>>>>>  As OAuth depends primarily on TLS, it feels wrong not to have a
>>>>>  solution that confirms the server host names are correct either
>>>>>  via config lookup or some other mechanism.
>>>>>=20
>>>>>  Tokbind is also a solution but I suspect it may only appeal to
>>>>>  large scale service providers and may be further off as we wait
>>>>>  for load balancers to support tokbind. Also there are issues with
>>>>>  tokbind on initial user binding where the mitm attack might itself
>>>>>  establish its own token binding. I have to think this through some
>>>>>  to confirm. But the issue of worry is what is happening on
>>>>>  initialization and first use if the hacker has already interceded
>>>>>  a mitm. That would make validation at config time still critical.
>>>>>=20
>>>>>  Hopefully somebody can arrive at an alternative for broader oauth
>>>>>  use cases.
>>>>>=20
>>>>>  Phil
>>>>>  _______________________________________________
>>>>>  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
>>> Sergey Beryozkin
>>>=20
>>> Talend Community Coders
>>> http://coders.talend.com/
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Tue Apr 12 09:07:37 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7409D12DADB for ; Tue, 12 Apr 2016 09:07:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rztqAxDTZkiO for ; Tue, 12 Apr 2016 09:07:33 -0700 (PDT)
Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::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 E7BAF12DE69 for ; Tue, 12 Apr 2016 09:07:28 -0700 (PDT)
Received: by mail-ob0-x233.google.com with SMTP id j9so14495642obd.3 for ; Tue, 12 Apr 2016 09:07:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dkfO/5Vm3E+4y4QPFM+8//FnHgHSeltNf/Efcf1CO4Y=; b=K4T+6cGf7O2lT+jPMqdL6/AUzhnu8rXgB0vO6pmynAnwwxQ8uk6fQJHCmQbKkCd6Xn TXQV9ubcyHlKtLegCqeGSFewIn/4iLnz+d76OSRrAoJf+IAsVTTtLASaVKVG8nlr5JWt +xIhq0yUokK3bn+o4q/5jFYXKmTU3IW6hfkXt2tdB+vqHFC/BDjCDKVUFJ/r9vNx3BVL U2dGs49lJUb1KtPCr9F5E2T8AumwKIhyaowydNefO5v2w3+9PFSDJcb/yR17xTS6M25s bq+xyizMxQg0c94Q46+aQZd3JDyzLumLp6nEf1zBlkqpBpDepZEG2eRng7KDjbLY9xHM J1ew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dkfO/5Vm3E+4y4QPFM+8//FnHgHSeltNf/Efcf1CO4Y=; b=BfGQzzJuqg3MOG/7XzhV4ba8cRHFgSjumChPmIEh5wJDJijjWlICNzzOe3KtNMI+M3 TPctIrUpRrSq2M1VHW+U3ENahHr4kXMQX2gtQI1Hdo71Gqz2uYHzWLLqYOcFjmB37S6d kFjOh3cegoDAHiFMb93uEknSud9EUtZTH3wHE9RjBjbqC3GcxgKkpNH1R+ASSkEQmH7e ocFdqO0xh3LV37fh0Aq4bMPfghGQbM0zRjbe9SDabvuyMpseLjeE7ovtn2SpJtE7nIEO iCFpB+NY7Taf5Owu+QBmzZ4V8kiwFI5f4gOm8emFqcH1gHYxecJiDSw1UuzfXytf6tN4 SHKg==
X-Gm-Message-State: AOPr4FVYPr7ji52fHQ7Og7fWU/Ymb5RTYHnERDgOupWhhCDjPZ+HHa4CNnJtnjnF6c3Hyw==
X-Received: by 10.60.78.3 with SMTP id x3mr1874780oew.8.1460477248266; Tue, 12 Apr 2016 09:07:28 -0700 (PDT)
Received: from [10.2.2.240] (75-147-25-205-NewEngland.hfc.comcastbusiness.net. [75.147.25.205]) by smtp.gmail.com with ESMTPSA id p48sm9939130otp.36.2016.04.12.09.07.27 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 12 Apr 2016 09:07:27 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: John Bradley 
In-Reply-To: <2CC00BB1-ADB6-4E1B-B0FF-E169871F700E@oracle.com>
Date: Tue, 12 Apr 2016 12:07:25 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <2D15E964-8A56-417C-A3CB-78CFAB5DFA34@oracle.com>  <824192A8-4F6F-4002-B7E0-518CAA0BF34A@oracle.com> <570CB228.8070703@gmail.com> <22B70247-C110-4D91-B510-1CCD59CB0260@ve7jtb.com> <2CC00BB1-ADB6-4E1B-B0FF-E169871F700E@oracle.com>
To: "Phil Hunt (IDM)" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Regarding using resource indicator to solve resource config issue
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Apr 2016 16:07:36 -0000

Sorry I don=E2=80=99t recall agreeing that audience restricting the AT =
is not a remedy for an attacker getting the token to access a resource.=20=


I don=E2=80=99t quite follow that.

John B.
> On Apr 12, 2016, at 12:00 PM, Phil Hunt (IDM)  =
wrote:
>=20
>=20
>=20
> Phil
>=20
>> On Apr 12, 2016, at 03:49, John Bradley  wrote:
>>=20
>> We did agree in BA that if the client sends no resource the AS would =
audience the AT per configured policy and reply to the client with =
additional meta-data about what resources the AT can be used at.
>=20
> We also agreed that was not a remedy for an attack where an attacker =
simply wants the token to use at the correct site to gain access to the =
resource.=20
>=20
> RI is no remedy for misconfiguration esp if it should be optional for =
the client.=20
>>=20
>> It should be obvious that this is in no way a breaking change.
>>=20
>> The only clients that need to provide a resource are ones that are =
asking for a token for a unknown resource, not something that is =
supported securely currently or by Pil=E2=80=99s spec.   Or when down =
scoping  a RT with multiple audiences so that the server can provide the =
correct token type/ claims / encryption/ signing.   Can we agree that =
with symmetrically signed AT it is not a good thing to use the same key =
for all RS?
>>=20
>> At the moment this can sort of be done with scopes but the client =
needs much more documentation about the scopes to understand the mapping =
between resource and scope, or possibly discovery of meta-data about the =
resource, something also not covered in Phil=E2=80=99s draft.
>>=20
>> We can update the draft as an ID. =20
>>=20
>> This is essentially the audience part of the POP key distribution =
with the addition of Nat=E2=80=99s meta-data for the token endpoint (in =
the existing JSON rather than a new header)
>>=20
>> We need to address this.  Discovery in general and Phil=E2=80=99s =
draft specifically are not a replacement, even if we were to adopt them.
>>=20
>> To Phil=E2=80=99s other question about token binding, no an attacker =
can=E2=80=99t usefully  MitM a token bound AT. =20
>> The private key is controlled by the client and never disclosed.  You =
can give the token to a MitM attacker but they cannot use it anyplace =
even with themselves as they don=E2=80=99t have the private key.   That =
is the security goal of token binding.
>>=20
>> John B.
>>=20
>>> On Apr 12, 2016, at 4:30 AM, Sergey Beryozkin  =
wrote:
>>>=20
>>> Hi
>>>> On 11/04/16 23:19, Phil Hunt (IDM) wrote:
>>>> I am objecting to modifying the protocol in the default case as a
>>>> majority do not need RI in the case of fixed endpoints.
>>>>=20
>>>> Migration would be challenging because the change is breaking and
>>>> affects existing clients.
>>> How does it break the existing clients given this is an optional =
feature ? Can you please describe the situation where the existing =
clients get broken ?
>>>=20
>>> Brian, would it make sense to update the text to mention that the =
clients do not have to be directly configured and instead it can be set =
during the registration time, so that the property gets seamlessly =
linked to client access tokens, etc, without the client applications =
having to be set up with the resource indicators manually ?
>>>=20
>>> Thanks, Sergey
>>>=20
>>>> Dynamic discovery are up and coming cases and a relatively green =
field.
>>>> Dealing with it at configuration/discovery makes broader sense as =
it has
>>>> no impact on existing clients.
>>>>=20
>>>> Phil
>>>>=20
>>>> On Apr 11, 2016, at 12:18, Brian Campbell =
>>> > wrote:
>>>>=20
>>>>> I'm not sure where the idea that it's only applicable to special =
uses
>>>>> like collaboration services is coming from. The pattern described =
in
>>>>> the draft (using a different parameter name but otherwise the =
same) is
>>>>> deployed and in-use for normal OAuth cases including and =
especially
>>>>> the resource owner centric ones.
>>>>>=20
>>>>>=20
>>>>> On Mon, Apr 11, 2016 at 11:33 AM, Phil Hunt (IDM)
>>>>> > wrote:
>>>>>=20
>>>>>  I am finding I am not happy with solving the bad resource =
endpoint
>>>>>  config issue with resource indicator. At best I see this as a
>>>>>  special use draft for things like collab services or things which
>>>>>  aren't resource owner centric.
>>>>>=20
>>>>>  Yet resource endpoint config is a concern for all clients that
>>>>>  configure on the fly. Is it reasonable to make resource indicator
>>>>>  mandatory for all clients? Probably not.
>>>>>=20
>>>>>  As OAuth depends primarily on TLS, it feels wrong not to have a
>>>>>  solution that confirms the server host names are correct either
>>>>>  via config lookup or some other mechanism.
>>>>>=20
>>>>>  Tokbind is also a solution but I suspect it may only appeal to
>>>>>  large scale service providers and may be further off as we wait
>>>>>  for load balancers to support tokbind. Also there are issues with
>>>>>  tokbind on initial user binding where the mitm attack might =
itself
>>>>>  establish its own token binding. I have to think this through =
some
>>>>>  to confirm. But the issue of worry is what is happening on
>>>>>  initialization and first use if the hacker has already interceded
>>>>>  a mitm. That would make validation at config time still critical.
>>>>>=20
>>>>>  Hopefully somebody can arrive at an alternative for broader oauth
>>>>>  use cases.
>>>>>=20
>>>>>  Phil
>>>>>  _______________________________________________
>>>>>  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
>>> Sergey Beryozkin
>>>=20
>>> Talend Community Coders
>>> http://coders.talend.com/
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>=20


From nobody Tue Apr 12 09:09:18 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACCE12D512 for ; Tue, 12 Apr 2016 09:09:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O87pxhPUpf4A for ; Tue, 12 Apr 2016 09:09:09 -0700 (PDT)
Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70FAE12D13B for ; Tue, 12 Apr 2016 09:09:09 -0700 (PDT)
Received: by mail-oi0-x234.google.com with SMTP id w85so28247730oiw.0 for ; Tue, 12 Apr 2016 09:09:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jjBWnF8B089/NRXh7RYJVhbzfzl8KE8FunRNIqtYj1E=; b=DDDDBs6wTo61cFW+O/OJ9q2LXSKOpm+hre00bLa3IyCNG9eka4Bo9HEn+m4axd4lU2 c3AjmVtUMxx4mc/X1hnBhdivbQ50CvH8Uo1hiMiXtokt3ZCe69Rz7kRGczYEXYXafhek AsgiqhmoHy47KS8cF6wuoOgbHw5Y9jJYyQ7OkoxXqzC7+nf3N1gylaGDPy8UBgwDVU8c h4akW/NY7IcmwU1Hmii4Cm0trwQM5iqvZGoIwHZYE0rOEMLLuPtZeXt5p8AVthsWi5Pl le/qHlzwkzpM/iPFLrFwrQAE6RkRlC6T3keJFI0NH0M1dFYvRgxIx/r2mqKewL70xaxN UOoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jjBWnF8B089/NRXh7RYJVhbzfzl8KE8FunRNIqtYj1E=; b=VTD7biL1NgPWEPOqDUkh18ADiIG9Mt9VF3SPWK/BoheXS4v24ueohNwPNtshck+xF+ U4Xt95BkErmiJ1YtTbDWfu/MjTibauadGHHgJHIZGKE3rU9GnJV+RaS9SSps+2eNt0rs xHe2gSYKQrYln8CKxhWiC7kbWa+KoqSaJKKYPK7JHuZiTpEGEsgUS4yyp92AEq+BIyvR vs6OH+0fXay54dU2Qdrdl4LL99pLMbKcWlUAr3RSjHVyvL4c7nqcdETXK9RCHZM1Me/N Ckv5RJII2VApsr7ZOJf1QH0UUAxm188Ha8ToX42KQuYLOsWpp0SpkiBkKFZhxtjxOChX sufA==
X-Gm-Message-State: AOPr4FXUto8WX/CBdji4UoSkXAwh7de4x/+xYCcwpkXeD/txSPiGp99O2amJDNa11+jylg==
X-Received: by 10.202.183.7 with SMTP id h7mr1903069oif.25.1460477348790; Tue, 12 Apr 2016 09:09:08 -0700 (PDT)
Received: from [10.2.2.240] (75-147-25-205-NewEngland.hfc.comcastbusiness.net. [75.147.25.205]) by smtp.gmail.com with ESMTPSA id wz10sm9223863obc.23.2016.04.12.09.09.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 12 Apr 2016 09:09:08 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: John Bradley 
In-Reply-To: <3BFA50D5-3BE6-4A56-BA52-AB2720B7BC0B@oracle.com>
Date: Tue, 12 Apr 2016 12:09:06 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <06E21CE2-C05F-4F2C-A53F-FA292AE95455@ve7jtb.com>
References: <2D15E964-8A56-417C-A3CB-78CFAB5DFA34@oracle.com>  <824192A8-4F6F-4002-B7E0-518CAA0BF34A@oracle.com> <570CB228.8070703@gmail.com> <22B70247-C110-4D91-B510-1CCD59CB0260@ve7jtb.com> <2CC00BB1-ADB6-4E1B-B0FF-E169871F700E@oracle.com> <3BFA50D5-3BE6-4A56-BA52-AB2720B7BC0B@oracle.com>
To: "Phil Hunt (IDM)" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Regarding using resource indicator to solve resource config issue
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Apr 2016 16:09:17 -0000

I am fine with keeping it separate, however proper audience restriction =
of bearer tokens or POP tokens are key mechanisms to protect AT from =
miss use from a number of attacks.

John B.
> On Apr 12, 2016, at 12:06 PM, Phil Hunt (IDM)  =
wrote:
>=20
> To be clear what I am saying... RI should be considered on its own =
merits as an optional protocol extension.=20
>=20
> I do not believe it has merit when linking it to client =
mis-configuration detection. The issues should be kept separate.=20
>=20
> Phil
>=20
>> On Apr 12, 2016, at 09:00, Phil Hunt (IDM)  =
wrote:
>>=20
>>=20
>>=20
>> Phil
>>=20
>>> On Apr 12, 2016, at 03:49, John Bradley  wrote:
>>>=20
>>> We did agree in BA that if the client sends no resource the AS would =
audience the AT per configured policy and reply to the client with =
additional meta-data about what resources the AT can be used at.
>>=20
>> We also agreed that was not a remedy for an attack where an attacker =
simply wants the token to use at the correct site to gain access to the =
resource.=20
>>=20
>> RI is no remedy for misconfiguration esp if it should be optional for =
the client.=20
>>>=20
>>> It should be obvious that this is in no way a breaking change.
>>>=20
>>> The only clients that need to provide a resource are ones that are =
asking for a token for a unknown resource, not something that is =
supported securely currently or by Pil=E2=80=99s spec.   Or when down =
scoping  a RT with multiple audiences so that the server can provide the =
correct token type/ claims / encryption/ signing.   Can we agree that =
with symmetrically signed AT it is not a good thing to use the same key =
for all RS?
>>>=20
>>> At the moment this can sort of be done with scopes but the client =
needs much more documentation about the scopes to understand the mapping =
between resource and scope, or possibly discovery of meta-data about the =
resource, something also not covered in Phil=E2=80=99s draft.
>>>=20
>>> We can update the draft as an ID. =20
>>>=20
>>> This is essentially the audience part of the POP key distribution =
with the addition of Nat=E2=80=99s meta-data for the token endpoint (in =
the existing JSON rather than a new header)
>>>=20
>>> We need to address this.  Discovery in general and Phil=E2=80=99s =
draft specifically are not a replacement, even if we were to adopt them.
>>>=20
>>> To Phil=E2=80=99s other question about token binding, no an attacker =
can=E2=80=99t usefully  MitM a token bound AT. =20
>>> The private key is controlled by the client and never disclosed.  =
You can give the token to a MitM attacker but they cannot use it =
anyplace even with themselves as they don=E2=80=99t have the private =
key.   That is the security goal of token binding.
>>>=20
>>> John B.
>>>=20
>>>> On Apr 12, 2016, at 4:30 AM, Sergey Beryozkin =
 wrote:
>>>>=20
>>>> Hi
>>>>> On 11/04/16 23:19, Phil Hunt (IDM) wrote:
>>>>> I am objecting to modifying the protocol in the default case as a
>>>>> majority do not need RI in the case of fixed endpoints.
>>>>>=20
>>>>> Migration would be challenging because the change is breaking and
>>>>> affects existing clients.
>>>> How does it break the existing clients given this is an optional =
feature ? Can you please describe the situation where the existing =
clients get broken ?
>>>>=20
>>>> Brian, would it make sense to update the text to mention that the =
clients do not have to be directly configured and instead it can be set =
during the registration time, so that the property gets seamlessly =
linked to client access tokens, etc, without the client applications =
having to be set up with the resource indicators manually ?
>>>>=20
>>>> Thanks, Sergey
>>>>=20
>>>>> Dynamic discovery are up and coming cases and a relatively green =
field.
>>>>> Dealing with it at configuration/discovery makes broader sense as =
it has
>>>>> no impact on existing clients.
>>>>>=20
>>>>> Phil
>>>>>=20
>>>>> On Apr 11, 2016, at 12:18, Brian Campbell =
>>>> > wrote:
>>>>>=20
>>>>>> I'm not sure where the idea that it's only applicable to special =
uses
>>>>>> like collaboration services is coming from. The pattern described =
in
>>>>>> the draft (using a different parameter name but otherwise the =
same) is
>>>>>> deployed and in-use for normal OAuth cases including and =
especially
>>>>>> the resource owner centric ones.
>>>>>>=20
>>>>>>=20
>>>>>> On Mon, Apr 11, 2016 at 11:33 AM, Phil Hunt (IDM)
>>>>>> > wrote:
>>>>>>=20
>>>>>> I am finding I am not happy with solving the bad resource =
endpoint
>>>>>> config issue with resource indicator. At best I see this as a
>>>>>> special use draft for things like collab services or things which
>>>>>> aren't resource owner centric.
>>>>>>=20
>>>>>> Yet resource endpoint config is a concern for all clients that
>>>>>> configure on the fly. Is it reasonable to make resource indicator
>>>>>> mandatory for all clients? Probably not.
>>>>>>=20
>>>>>> As OAuth depends primarily on TLS, it feels wrong not to have a
>>>>>> solution that confirms the server host names are correct either
>>>>>> via config lookup or some other mechanism.
>>>>>>=20
>>>>>> Tokbind is also a solution but I suspect it may only appeal to
>>>>>> large scale service providers and may be further off as we wait
>>>>>> for load balancers to support tokbind. Also there are issues with
>>>>>> tokbind on initial user binding where the mitm attack might =
itself
>>>>>> establish its own token binding. I have to think this through =
some
>>>>>> to confirm. But the issue of worry is what is happening on
>>>>>> initialization and first use if the hacker has already interceded
>>>>>> a mitm. That would make validation at config time still critical.
>>>>>>=20
>>>>>> Hopefully somebody can arrive at an alternative for broader oauth
>>>>>> use cases.
>>>>>>=20
>>>>>> Phil
>>>>>> _______________________________________________
>>>>>> 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
>>>> Sergey Beryozkin
>>>>=20
>>>> Talend Community Coders
>>>> http://coders.talend.com/
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20


From nobody Tue Apr 12 09:19:17 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039DA12D7B2 for ; Tue, 12 Apr 2016 09:19:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7U8xyqBGjD56 for ; Tue, 12 Apr 2016 09:19:14 -0700 (PDT)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7E6B12D6A9 for ; Tue, 12 Apr 2016 09:19:13 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id a140so60411236wma.0 for ; Tue, 12 Apr 2016 09:19:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=JvbNZKfBP2Udev0mMet//1DaMlnLE++bwmH1E+Vud9w=; b=jdopfLFuWmzrjXlsIBuI7hnLh8eS04OMvZoP9rbppCZknV3yaeAVz9b/hlG0TZlp/t 3bAxljR6duEXNosWV+rnbY2owfetTJseqREkOHLWwqpfo5rDxuOojKZc4XSNovygAvhQ wfEWdZdhpSASkTs1BFHA4FZ3bDxc2Wvug9IOWxXDRLbsStsysyFFsGQukONIUvjjXVmr 87aOaj8qJwtZcZV3Zwv+Nz0KcqB2jUHVwHk8+JQBSRs/eP3eFiFGSTX2g8nZbtvBVt+Y 0MmCe3DZ3HaexE7VZYcaIxFuIdX2O5l0AQYa05P4kwVim5lD234g7KE+7y4va+fryelJ uRDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=JvbNZKfBP2Udev0mMet//1DaMlnLE++bwmH1E+Vud9w=; b=ZzE1UqfZYEJYvqJk0yPj1ZIBdV6iXrXVIPOUCRL6dzgJV8Alw9GW14LPu7Jy2J2GUY PLgeU1vIxf1k0vhHZntiYE1xF514LnRDiG3a5VNiYh3mcOwJvxFktvzeJ3hefifx0F/s UDBQXEwCLjsIDI187FlTnm5DIR6Qqz0A5yiQqaPqRE3R2L/LzCdGhEvblgVh8lsONhv0 Plb4oe6wcKWuILU9E8TZ7BhUAtYHDXOHra6Vucps/8YGnbm0JWWYHToXxs37vg7YRQTd NaBaZSBted4rH3x6OrbxFga55y517Ah3SObWX0N8HSo28V21K8/voEUWwTdh32OaSB61 ez4g==
X-Gm-Message-State: AOPr4FVY/y/rvEvpMZGWpOCyfs2v4JsJaVaEuoTc1s41KLcKzf9/gypYkndYRrm//ozOxw==
X-Received: by 10.28.177.134 with SMTP id a128mr5467766wmf.55.1460477952188; Tue, 12 Apr 2016 09:19:12 -0700 (PDT)
Received: from [192.168.2.7] ([80.111.78.209]) by smtp.googlemail.com with ESMTPSA id b1sm34117697wjy.0.2016.04.12.09.19.10 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Apr 2016 09:19:11 -0700 (PDT)
To: "Phil Hunt (IDM)" 
References: <2D15E964-8A56-417C-A3CB-78CFAB5DFA34@oracle.com>  <824192A8-4F6F-4002-B7E0-518CAA0BF34A@oracle.com> <570CB228.8070703@gmail.com> <9E82A52C-6E06-48D2-A364-A033E921FEF7@oracle.com>
From: Sergey Beryozkin 
Message-ID: <570D1FFE.6000907@gmail.com>
Date: Tue, 12 Apr 2016 17:19:10 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <9E82A52C-6E06-48D2-A364-A033E921FEF7@oracle.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Regarding using resource indicator to solve resource config issue
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Apr 2016 16:19:16 -0000

Hi
On 12/04/16 16:58, Phil Hunt (IDM) wrote:
> John's assertion that RI can be used to detect mis-configured clients would make it mandatory.
>
This is an AS + RS decision, right (make the tokens bound to specific 
RSs only) ? So if the client wants to access RS with (from now on) 
stronger security restrictions then it is up to the client to ensure it 
can do so.
Yes, if the client does not have this property (directly or indirectly) 
available then it won't be able to access RS but I'm not sure it 
qualifies as breaking the existing clients. (similarly, if the server 
updates its server certificate then the client should be made aware of 
it, etc)...

> To avoid that we need a config time solution for misconfiguration.
>
How about setting the property at the AS Client registration process 
time ? Or updating the existing client's registrations to ensure the 
existing clients can stay operational ?

Cheers, Sergey


> Phil
>
>> On Apr 12, 2016, at 01:30, Sergey Beryozkin  wrote:
>>
>> Hi
>>> On 11/04/16 23:19, Phil Hunt (IDM) wrote:
>>> I am objecting to modifying the protocol in the default case as a
>>> majority do not need RI in the case of fixed endpoints.
>>>
>>> Migration would be challenging because the change is breaking and
>>> affects existing clients.
>> How does it break the existing clients given this is an optional feature ? Can you please describe the situation where the existing clients get broken ?
>>
>> Brian, would it make sense to update the text to mention that the clients do not have to be directly configured and instead it can be set during the registration time, so that the property gets seamlessly linked to client access tokens, etc, without the client applications having to be set up with the resource indicators manually ?
>>
>> Thanks, Sergey
>>
>>> Dynamic discovery are up and coming cases and a relatively green field.
>>> Dealing with it at configuration/discovery makes broader sense as it has
>>> no impact on existing clients.
>>>
>>> Phil
>>>
>>> On Apr 11, 2016, at 12:18, Brian Campbell >> > wrote:
>>>
>>>> I'm not sure where the idea that it's only applicable to special uses
>>>> like collaboration services is coming from. The pattern described in
>>>> the draft (using a different parameter name but otherwise the same) is
>>>> deployed and in-use for normal OAuth cases including and especially
>>>> the resource owner centric ones.
>>>>
>>>>
>>>> On Mon, Apr 11, 2016 at 11:33 AM, Phil Hunt (IDM)
>>>> > wrote:
>>>>
>>>>     I am finding I am not happy with solving the bad resource endpoint
>>>>     config issue with resource indicator. At best I see this as a
>>>>     special use draft for things like collab services or things which
>>>>     aren't resource owner centric.
>>>>
>>>>     Yet resource endpoint config is a concern for all clients that
>>>>     configure on the fly. Is it reasonable to make resource indicator
>>>>     mandatory for all clients? Probably not.
>>>>
>>>>     As OAuth depends primarily on TLS, it feels wrong not to have a
>>>>     solution that confirms the server host names are correct either
>>>>     via config lookup or some other mechanism.
>>>>
>>>>     Tokbind is also a solution but I suspect it may only appeal to
>>>>     large scale service providers and may be further off as we wait
>>>>     for load balancers to support tokbind. Also there are issues with
>>>>     tokbind on initial user binding where the mitm attack might itself
>>>>     establish its own token binding. I have to think this through some
>>>>     to confirm. But the issue of worry is what is happening on
>>>>     initialization and first use if the hacker has already interceded
>>>>     a mitm. That would make validation at config time still critical.
>>>>
>>>>     Hopefully somebody can arrive at an alternative for broader oauth
>>>>     use cases.
>>>>
>>>>     Phil
>>>>     _______________________________________________
>>>>     OAuth mailing 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/
>


-- 
Sergey Beryozkin

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


From nobody Tue Apr 12 09:24:40 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7811012DB0A for ; Tue, 12 Apr 2016 09:24:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08hwPGd5WZca for ; Tue, 12 Apr 2016 09:24:35 -0700 (PDT)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6160012D7A0 for ; Tue, 12 Apr 2016 09:24:35 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id l6so195177370wml.1 for ; Tue, 12 Apr 2016 09:24:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=0oB7ZESs9SI2jrkH5xvgi5uqu2PsZxyr9JnB2wivjy4=; b=G+Kl4P/CkUqkCRmJunjJDh+SknGpi8YTUcCA8yQVheZq3HtdUb5riMlbTcUnd00OM7 0wfqXsuNEU32GL4Ku/i1rZ9djsTUMoHjIzsA9C3nx76+VWcfeN+HykkyDkLOQ0C+oJ+R 4PfbFWMOFDZt73EWKbVlSTaH+gnEB2AS85z1jZRNfFiQ324YGAthZinoMnghxh5n1XCp aaTH5TMoZDHehHjkhFuSvJNfcsVEdVxr6Ovq2VfXxZ0Op1q9PXHzw1hluoFkQRfPNQxt kLKQOxWcQfXvmysZavPcJr1WCviZ9a+0tIzGds1NzZVU1S/ScjDx5JxnopVKoUr8ATaY EXOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=0oB7ZESs9SI2jrkH5xvgi5uqu2PsZxyr9JnB2wivjy4=; b=YYTOvWewCj1TdjT6iEsRpR4c7jyAgGhRFh7aL5Zgx3eQ2h5WixQzHsXr1lw8THmVDu wKdOERAdsSgM9dLGQRf27ICUByFw7I3TPXHe7Cg/MPnGvv8hFpLa8biWy/iIkqF7cGzQ 4LauAxVJ8yYXOzrz3aKKMrqJrEPWM1kj3Iezw/EljeHG7LrVUczOgqgYKNyAbB6HPMkY ZzCC15+/XGUIoqEnZ0ND/DVTQRn3pVi4PjSX2Wx2NeSp0CKrGMWMUBlDlFoIU9QdT2I6 Y8O3S4C6sreFaR0vMMpAHxGp2rkIFon3HIHYrMbhmU0F5j0QhWTr11OzNHpiA6ay1qvh zdAA==
X-Gm-Message-State: AOPr4FUdfBSveY+Zm7MQH3knIv43ORSVznhY1l/dGOu+vrCfFP2sQq4pAMaeqxu8AecKpQ==
X-Received: by 10.194.16.8 with SMTP id b8mr4718864wjd.51.1460478273866; Tue, 12 Apr 2016 09:24:33 -0700 (PDT)
Received: from [192.168.2.7] ([80.111.78.209]) by smtp.googlemail.com with ESMTPSA id us3sm16368124wjc.41.2016.04.12.09.24.32 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Apr 2016 09:24:32 -0700 (PDT)
To: Anthony Nadalin , Justin Richer ,  Torsten Lodderstadt 
References: <570546A1.8040509@gmx.net> <5AEB6A4A-A325-4069-930F-D034D81E41E5@mit.edu>        <9FA7FA11-0FED-40D6-AD49-506BA4EEF8E4@mit.edu> 
From: Sergey Beryozkin 
Message-ID: <570D2140.2080105@gmail.com>
Date: Tue, 12 Apr 2016 17:24:32 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
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] Call for Adoption: Resource Indicators for OAuth 2.0
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Apr 2016 16:24:38 -0000

Hi
On 12/04/16 14:03, Anthony Nadalin wrote:
> Specifications should be somewhat complete and not open ended/not
> thought out, you should think about the issues, requirements and use
> cases first before you try to force this into the working group process
> and confuse people , we had too many of these specifications lately.
>
I'm not an expert yet I'm not consider myself confused :-). It is a 
basic incremental improvement, trying to come up with a standard 
approach toward restricting tokens to very specific resource servers.

> We are now up to 15+ specifications that someone has to read and
> understand how these all may or may not fit together and all the
> interactions that may occur. So much for the simple Oauth.
This particular text is simpler than a token exchange draft :-).
By the way there was a proposal recently to have OAuth 2.1 document 
where the best practices/etc are suggested, I suppose that can help 
consolidate various texts created since original OAuth 2.0

Thanks, Sergey
>
> *From:*Justin Richer [mailto:jricher@mit.edu]
> *Sent:* Tuesday, April 12, 2016 5:46 AM
> *To:* Torsten Lodderstadt 
> *Cc:* Anthony Nadalin ; 
> 
> *Subject:* Re: [OAUTH-WG] Call for Adoption: Resource Indicators for
> OAuth 2.0
>
> +1 to Torsten’s point.
>
> And a reminder to Tony that call for adoption is the *start* of the
> document editing process, not the end. We’re not saying this is a
> complete solution with everything thought out when we adopt the
> document, we’re saying it’s a problem we want to work on and a direction
> that we want to move in. Stop trying to confuse people.
>
>   — Justin
>
>     On Apr 12, 2016, at 1:30 AM, Torsten Lodderstedt
>     > wrote:
>
>     Indicating the resource server to the AS allows the AS to
>     automatically select token type, encryption scheme and user data to
>     be put into the access token based on a RS-specific policy. So there
>     is no need to explicitely ask the AS for a certain token format or
>     encryption scheme.
>
>
>     Am 11.04.2016 um 22:35 schrieb Anthony Nadalin
>     >:
>
>         So it’s an incomplete solution then ?
>
>         *From:*Brian Campbell [mailto:bcampbell@pingidentity.com]
>         *Sent:*Monday, April 11, 2016 1:34 PM
>         *To:*Anthony Nadalin          >
>         *Cc:*Nat Sakimura          >;          > >
>         *Subject:*Re: [OAUTH-WG] Call for Adoption: Resource Indicators
>         for OAuth 2.0
>
>         No, I'm not adding requirements for encryption. I was pointing
>         out some of the ways that an access token might be different for
>         different RSs.
>
>
>         On Mon, Apr 11, 2016 at 2:18 PM, Anthony Nadalin
>         > wrote:
>
>             So now you are adding more requirements for encryption ? The
>             more this thread goes on shows how unstable and not fully
>             thought out this draft is to go through WG adoption.
>
>             *From:*OAuth [mailto:oauth-bounces@ietf.org
>             ]*On Behalf Of*Brian Campbell
>             *Sent:*Monday, April 11, 2016 12:30 PM
>             *To:*Nat Sakimura              >
>             *Cc:*>
>             >
>             *Subject:*Re: [OAUTH-WG] Call for Adoption: Resource
>             Indicators for OAuth 2.0
>
>             Sending a token type is not sufficient. There's more
>             involved than the format. Many cases need to know if to
>             encrypt and whom to encrypt to.  What claims to put in the
>             token (or reference by the token). What algorithms and keys
>             to use for signing/encryption.
>
>
>             The statement that the "Current proposal does not support
>             the implicit flow" is incorrect. Among other things, sec 2
>             has, "When an access token will be returned from the
>             authorization endpoint, the "resource" parameter is used in
>             the authorization request to the authorization endpoint as
>             defined in Section 4.2.1 of OAuth 2.0 [RFC6749]."
>
>             On Sun, Apr 10, 2016 at 11:43 AM, Nat Sakimura
>             > wrote:
>
>                 So, my understanding on the rationale/requirements for
>                 having this spec right now is:
>
>                 R1. Authz server wants toprevent the replay by the
>                 server that received it.
>
>                 R2. Authz server needs to mint the access token in a
>                 variety of format depending on the resource server and
>                 to do that, you need to know which RS is gong to be
>                 receiving it.
>
>                 To achieve R1, there are couple of methods. The proposed
>                 method here is to audience restrict the token, but the
>                 same can be achieved by sender constraining the token,
>                 e.g., by token binding. As far as I can see, the
>                 sentiment of the WG seems to be to use the sender
>                 constraint through Token Binding, so from this respect,
>                 this spec is not the one to do R1. Besides, the current
>                 proposal only takes care of the code flow. The same
>                 requirement should be there for implicit flow as well,
>                 so the current proposal is not covering the R1 anyways.
>
>                 I can sort of understand R2, but I have two critique on
>                 the current proposal:
>
>                 C1. Current proposal does not support the implicit flow.
>                 To support it, the resource URI has to be sent to the
>                 Authz endpoint instead of the Token endpoint.
>
>                 C2. It is much more direct to send the required token
>                 format rather than the RS uri and probably better as:
>
>                    1) There are use cases where the AS does not maintain
>                 the list of RSs that it supports, e.g., AOL.
>
>                         In such a case, even if the RS uri were sent to
>                 the AS, the AS cannot mint the tokens in the appropriate
>                 format.
>
>                    2) When it is sent in the Authz request, it is
>                 leaking the information about the resource that the
>                 client is going to the browser.
>
>                    3) There are use cases where it is desirable not to
>                 let the AS knows where the Client is going from the
>                 privacy point of view.
>
>                 So, my suggestion is to drop R1 and concentrate on R2.
>                 And to solve R2, send token type instead of the resource
>                 indicator in the request.
>
>                 This also necessitates the Client to be able to find out
>                 what token type the resource requires, perhaps in the
>                 unauthorized response web link header at the resource in
>                 the manner of oauth-meta.
>
>                 Cheers,
>
>                 Nat
>
>                 2016年4月8日(金) 8:23 Prateek Mishra
>                                  >:
>
>                     While this work addresses a gap in the existing
>                     OAuth specification set, I am very concerned that this
>                     incremental extension will lead to even more
>                     confusion around the areas of “scopeâ€, “audienceâ€
>                     and “resource serverâ€.
>
>                     I think we should try to solve this problem via  a
>                     framework that provides better guidance and
>                     implementation
>                     models for OAuth use-cases. In other words, I feel
>                     that a broader discussion is needed here.
>
>
>                      > On Apr 7, 2016, at 4:11 PM, Justin Richer
>                     > wrote:
>                      >
>                      > I support adoption of this document as a starting
>                     point for working group work.
>                      >
>                      > — Justin
>                      >
>                      >
>                      >> On Apr 6, 2016, at 1:25 PM, Hannes Tschofenig
>                                          > wrote:
>                      >>
>                      >> Hi all,
>                      >>
>                      >> this is the call for adoption of 'Resource
>                     Indicators for OAuth 2.0', see
>                      >>http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/ 
>                      >>
>                      >> Please let us know by April 20th 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 Buenos
>                      >> Aires then you don't need to re-state your
>                     opinion, if you want.
>                      >>
>                      >> The feedback at the BA IETF meeting was the
>                     following: ~10 persons
>                      >> for accepting the document and 0 persons against.
>                      >>
>                      >> 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
>     
>
>
>
> _______________________________________________
> 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 Apr 12 09:50:58 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF74212E920 for ; Tue, 12 Apr 2016 09:50:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.996
X-Spam-Level: 
X-Spam-Status: No, score=-2.996 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, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jkb33_9WtJI4 for ; Tue, 12 Apr 2016 09:50:48 -0700 (PDT)
Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE27612E88E for ; Tue, 12 Apr 2016 09:50:47 -0700 (PDT)
Received: by mail-oi0-x229.google.com with SMTP id p188so29653180oih.2 for ; Tue, 12 Apr 2016 09:50:47 -0700 (PDT)
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; bh=/dvk26n3lxQMAFlg3V+1/Q5FI9o2afcQaDZwEO1+S2o=; b=jwebXHUqXTqkadQSSVZeycVus3MpUbY5oRKUGMZspv3cekzuPLv+ACaDbWCUh7Dmu5 B5FkdcqpTs2GHwzx4kfr8XI8LGP8f8UxHTSWYfuHK37HM0PCqLSsBI5NufFMcDxFg5Fk 7iUIWVauZcF5sdPVOspIHZq3lMyBqqJncKp7WCkfawzunPBQKSD9AIQFfIpq2LwV7I+S 5YYJEtKFGjOWfKOxueJP2jTa1o0RKdyyts/LCjItGVpxhOxBDL7GibpJMFnNwvEHPs8n pxCxcS3z3W2qe344ynv9YqLC3rUhCtwzMOTdGgrnCkhujCBuuR9cRU5qDIdgAdgCRgGq KddA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/dvk26n3lxQMAFlg3V+1/Q5FI9o2afcQaDZwEO1+S2o=; b=C0bPvO4gXrIE1cMXyEAu2tCa3oYGFdySMJJ0bYk+7M+LDUkwMdHk+FQI0YgAvQAAii TO2i7olCT7cZCAhgUSuMJnh0FMEkH99jzXJmMVxd7vGiWWb/3vmUmmSaFAqe3rJFZM+S j5dasIm9gficste8YCJwaJsi/RrHRECxkorPxGfD2B4OzqG+n/qIXONWiOp1iOjG0PdZ SfYZnx93nEZQK8D3E0kJxPgGsUda98MeKCtRKdjhTGZVrIibzm4N2gcfdmREMRZVft1d QVtjOxCtHTnGkguFgm+DZfbX2DTKfLH327YXFaarQmZoxWpGtipo9J3aWCIOhg9hRGWT Jf9g==
X-Gm-Message-State: AOPr4FXTS1kaXiydnXf5v9txutInHpe34CtfC3ZNplUXzKFDyf9mcabI+RZ1aoBizb+Gymumi/gBs3YjuQQ5EgJV
X-Received: by 10.202.69.134 with SMTP id s128mr1926931oia.97.1460479846963; Tue, 12 Apr 2016 09:50:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.78.68 with HTTP; Tue, 12 Apr 2016 09:50:27 -0700 (PDT)
In-Reply-To: <570D2140.2080105@gmail.com>
References: <570546A1.8040509@gmx.net> <5AEB6A4A-A325-4069-930F-D034D81E41E5@mit.edu>        <9FA7FA11-0FED-40D6-AD49-506BA4EEF8E4@mit.edu>  <570D2140.2080105@gmail.com>
From: William Denniss 
Date: Tue, 12 Apr 2016 09:50:27 -0700
Message-ID: 
To: Sergey Beryozkin 
Content-Type: multipart/alternative; boundary=001a113dc9a27b63b805304c762d
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Apr 2016 16:50:57 -0000

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

On Tue, Apr 12, 2016 at 9:24 AM, Sergey Beryozkin 
wrote:

> Hi
> On 12/04/16 14:03, Anthony Nadalin wrote:
>
>> Specifications should be somewhat complete and not open ended/not
>> thought out, you should think about the issues, requirements and use
>> cases first before you try to force this into the working group process
>> and confuse people , we had too many of these specifications lately.
>>
>> I'm not an expert yet I'm not consider myself confused :-). It is a basi=
c
> incremental improvement, trying to come up with a standard approach towar=
d
> restricting tokens to very specific resource servers.


Yes, so basically you have a refresh token with scopes A & B. You want to
get an access token for use at Resource Server 1 (RS1) with only scope A,
then one for Resource Server 2 (RS2) with only scope B, so you would refres=
h
 the token stating
scope=3DA&resource=3DRS1, and then scope=3DB&resource=3DRS2.  OAuth already
supports the ability to request a scope sub-set during refresh, Brian's
spec adds the ability to indicate what RS you intend to use the resulting
access token at.

This topic has also came up in the context of Token Binding which is one
place where it is relevant to have RS-specific tokens, and I had the
impression from that meeting that some method of specifying the intended
resource would be helpful.

This is a really simple proposal that just standardizes that pattern so
people don't try to jam everything but the kitchen sink into 'scope'.


> We are now up to 15+ specifications that someone has to read and
>> understand how these all may or may not fit together and all the
>> interactions that may occur. So much for the simple Oauth.
>>
>

> This particular text is simpler than a token exchange draft :-).
>


> By the way there was a proposal recently to have OAuth 2.1 document where
> the best practices/etc are suggested, I suppose that can help consolidate
> various texts created since original OAuth 2.0
>

At some point this may make sense, but I think for now the better
consolidated approach is online documentation and books
. Not everyone needs to
start at the RFC level.

As Mike Jones suggested earlier we should have some rounds of iteration and
get experience with the various extension specs before we attempt to merge
them together into 1 document. For example, it's likely that not all the
specs would get included in such a document and we need more deployment
experience to know what to include, and what not to.



> *From:*Justin Richer [mailto:jricher@mit.edu]
>> *Sent:* Tuesday, April 12, 2016 5:46 AM
>> *To:* Torsten Lodderstadt 
>> *Cc:* Anthony Nadalin ; 
>> 
>> *Subject:* Re: [OAUTH-WG] Call for Adoption: Resource Indicators for
>> OAuth 2.0
>>
>> +1 to Torsten=E2=80=99s point.
>>
>> And a reminder to Tony that call for adoption is the *start* of the
>> document editing process, not the end. We=E2=80=99re not saying this is =
a
>> complete solution with everything thought out when we adopt the
>> document, we=E2=80=99re saying it=E2=80=99s a problem we want to work on=
 and a direction
>> that we want to move in. Stop trying to confuse people.
>>
>>   =E2=80=94 Justin
>>
>>     On Apr 12, 2016, at 1:30 AM, Torsten Lodderstedt
>>     > wrote:
>>
>>     Indicating the resource server to the AS allows the AS to
>>     automatically select token type, encryption scheme and user data to
>>     be put into the access token based on a RS-specific policy. So there
>>     is no need to explicitely ask the AS for a certain token format or
>>     encryption scheme.
>>
>>
>>     Am 11.04.2016 um 22:35 schrieb Anthony Nadalin
>>     >:
>>
>>         So it=E2=80=99s an incomplete solution then ?
>>
>>         *From:*Brian Campbell [mailto:bcampbell@pingidentity.com]
>>         *Sent:*Monday, April 11, 2016 1:34 PM
>>         *To:*Anthony Nadalin >         >
>>         *Cc:*Nat Sakimura >         >; >         > =
>
>>         *Subject:*Re: [OAUTH-WG] Call for Adoption: Resource Indicators
>>         for OAuth 2.0
>>
>>         No, I'm not adding requirements for encryption. I was pointing
>>         out some of the ways that an access token might be different for
>>         different RSs.
>>
>>
>>         On Mon, Apr 11, 2016 at 2:18 PM, Anthony Nadalin
>>         > wrote:
>>
>>             So now you are adding more requirements for encryption ? The
>>             more this thread goes on shows how unstable and not fully
>>             thought out this draft is to go through WG adoption.
>>
>>             *From:*OAuth [mailto:oauth-bounces@ietf.org
>>             ]*On Behalf Of*Brian Campbell
>>             *Sent:*Monday, April 11, 2016 12:30 PM
>>             *To:*Nat Sakimura >             >
>>             *Cc:*>
>>             >
>>             *Subject:*Re: [OAUTH-WG] Call for Adoption: Resource
>>             Indicators for OAuth 2.0
>>
>>             Sending a token type is not sufficient. There's more
>>             involved than the format. Many cases need to know if to
>>             encrypt and whom to encrypt to.  What claims to put in the
>>             token (or reference by the token). What algorithms and keys
>>             to use for signing/encryption.
>>
>>
>>             The statement that the "Current proposal does not support
>>             the implicit flow" is incorrect. Among other things, sec 2
>>             has, "When an access token will be returned from the
>>             authorization endpoint, the "resource" parameter is used in
>>             the authorization request to the authorization endpoint as
>>             defined in Section 4.2.1 of OAuth 2.0 [RFC6749]."
>>
>>             On Sun, Apr 10, 2016 at 11:43 AM, Nat Sakimura
>>             > wrote:
>>
>>                 So, my understanding on the rationale/requirements for
>>                 having this spec right now is:
>>
>>                 R1. Authz server wants toprevent the replay by the
>>                 server that received it.
>>
>>                 R2. Authz server needs to mint the access token in a
>>                 variety of format depending on the resource server and
>>                 to do that, you need to know which RS is gong to be
>>                 receiving it.
>>
>>                 To achieve R1, there are couple of methods. The proposed
>>                 method here is to audience restrict the token, but the
>>                 same can be achieved by sender constraining the token,
>>                 e.g., by token binding. As far as I can see, the
>>                 sentiment of the WG seems to be to use the sender
>>                 constraint through Token Binding, so from this respect,
>>                 this spec is not the one to do R1. Besides, the current
>>                 proposal only takes care of the code flow. The same
>>                 requirement should be there for implicit flow as well,
>>                 so the current proposal is not covering the R1 anyways.
>>
>>                 I can sort of understand R2, but I have two critique on
>>                 the current proposal:
>>
>>                 C1. Current proposal does not support the implicit flow.
>>                 To support it, the resource URI has to be sent to the
>>                 Authz endpoint instead of the Token endpoint.
>>
>>                 C2. It is much more direct to send the required token
>>                 format rather than the RS uri and probably better as:
>>
>>                    1) There are use cases where the AS does not maintain
>>                 the list of RSs that it supports, e.g., AOL.
>>
>>                         In such a case, even if the RS uri were sent to
>>                 the AS, the AS cannot mint the tokens in the appropriate
>>                 format.
>>
>>                    2) When it is sent in the Authz request, it is
>>                 leaking the information about the resource that the
>>                 client is going to the browser.
>>
>>                    3) There are use cases where it is desirable not to
>>                 let the AS knows where the Client is going from the
>>                 privacy point of view.
>>
>>                 So, my suggestion is to drop R1 and concentrate on R2.
>>                 And to solve R2, send token type instead of the resource
>>                 indicator in the request.
>>
>>                 This also necessitates the Client to be able to find out
>>                 what token type the resource requires, perhaps in the
>>                 unauthorized response web link header at the resource in
>>                 the manner of oauth-meta.
>>
>>                 Cheers,
>>
>>                 Nat
>>
>>                 2016=E5=B9=B44=E6=9C=888=E6=97=A5(=E9=87=91) 8:23 Pratee=
k Mishra
>>                 >                 >:
>>
>>                     While this work addresses a gap in the existing
>>                     OAuth specification set, I am very concerned that th=
is
>>                     incremental extension will lead to even more
>>                     confusion around the areas of =E2=80=9Cscope=E2=80=
=9D, =E2=80=9Caudience=E2=80=9D
>>                     and =E2=80=9Cresource server=E2=80=9D.
>>
>>                     I think we should try to solve this problem via  a
>>                     framework that provides better guidance and
>>                     implementation
>>                     models for OAuth use-cases. In other words, I feel
>>                     that a broader discussion is needed here.
>>
>>
>>                      > On Apr 7, 2016, at 4:11 PM, Justin Richer
>>                     > wrote:
>>                      >
>>                      > I support adoption of this document as a starting
>>                     point for working group work.
>>                      >
>>                      > =E2=80=94 Justin
>>                      >
>>                      >
>>                      >> On Apr 6, 2016, at 1:25 PM, Hannes Tschofenig
>>                     >                     > wrote:
>>                      >>
>>                      >> Hi all,
>>                      >>
>>                      >> this is the call for adoption of 'Resource
>>                     Indicators for OAuth 2.0', see
>>                      >>
>> http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators=
/
>> <
>> https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3a%2f%2fdatatr=
acker.ietf.org%2fdoc%2fdraft-campbell-oauth-resource-indicators%2f&data=3D0=
1%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f98=
8bf86f141af91ab2d7cd011db47%7c1&sdata=3Dy869Fk9987ff09hvHIN%2bVGl%2fqxwWDmk=
vOwzcQcWqXZw%3d
>> >
>>                      >>
>>                      >> Please let us know by April 20th 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 Buenos
>>                      >> Aires then you don't need to re-state your
>>                     opinion, if you want.
>>                      >>
>>                      >> The feedback at the BA IETF meeting was the
>>                     following: ~10 persons
>>                      >> for accepting the document and 0 persons against=
.
>>                      >>
>>                      >> Ciao
>>                      >> Hannes & Derek
>>                      >>
>>                      >> _______________________________________________
>>                      >> OAuth mailing list
>>                      >>OAuth@ietf.org 
>>                      >>https://www.ietf.org/mailman/listinfo/oauth
>>                     <
>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.i=
etf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40microsoft.c=
om%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c=
1&sdata=3Dbfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d
>> >
>>                      >
>>                      > _______________________________________________
>>                      > OAuth mailing list
>>                      >OAuth@ietf.org 
>>                      >https://www.ietf.org/mailman/listinfo/oauth
>>                     <
>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.i=
etf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40microsoft.c=
om%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c=
1&sdata=3Dbfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d
>> >
>>
>>                     _______________________________________________
>>                     OAuth mailing list
>>                     OAuth@ietf.org 
>>                     https://www.ietf.org/mailman/listinfo/oauth
>>                     <
>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.i=
etf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40microsoft.c=
om%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c=
1&sdata=3Dbfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d
>> >
>>
>>
>>                 _______________________________________________
>>                 OAuth mailing list
>>                 OAuth@ietf.org 
>>                 https://www.ietf.org/mailman/listinfo/oauth
>>                 <
>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.i=
etf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40microsoft.c=
om%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c=
1&sdata=3Dbfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d
>> >
>>
>>         _______________________________________________
>>         OAuth mailing list
>>         OAuth@ietf.org 
>>         https://www.ietf.org/mailman/listinfo/oauth
>>         <
>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.i=
etf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40microsoft.c=
om%7c81244957f086491ed84508d362d07a2d%7c72f988bf86f141af91ab2d7cd011db47%7c=
1&sdata=3DApH6%2fbRs21OYURWWYx4N4lWVSeCI%2fAPj2eSOA3fdcTw%3d
>> >
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     OAuth@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/oauth
>>     <
>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.i=
etf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40microsoft.c=
om%7c81244957f086491ed84508d362d07a2d%7c72f988bf86f141af91ab2d7cd011db47%7c=
1&sdata=3DApH6%2fbRs21OYURWWYx4N4lWVSeCI%2fAPj2eSOA3fdcTw%3d
>> >
>>
>>
>>
>> _______________________________________________
>> 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
>

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




On Tue, Apr 12, 2016 at 9:24 AM, Sergey Beryozkin <=
;sberyozkin@gmail.com> wrote:
Hi

On 12/04/16 14:03, Anthony Nadalin wrote:



Specifications should be somewhat complete and not open ended/not

thought out, you should think about the issues, requirements and use

cases first before you try to force this into the working group process

and confuse people , we had too many of these specifications lately.





I'm not an expert yet I'm not consider myself confused :-). It is a=
 basic incremental improvement, trying to come up with a standard approach =
toward restricting tokens to very specific resource servers.

Yes, so basically you have a refresh token with scopes A =
& B. You want to get an access token for use at Resource Server 1 (RS1)=
 with only scope A, then one for Resource Server 2 (RS2) with only scope B,=
 so you would ref=
resh the token stating scope=3DA&am=
p;resource=3DRS1, and then=C2=A0=
scope=3DB&resource=3DRS2.=C2=A0 OAuth already supports the abili=
ty to request a scope sub-set during refresh, Brian's spec adds the abi=
lity to indicate what RS you intend to use the resulting access token at.

This topic has also came up in the context of Token=
 Binding which is one place where it is relevant to have RS-specific tokens=
, and I had the impression from that meeting that some method of specifying=
 the intended resource would be helpful.

This =
is a really simple proposal that just standardizes that pattern so people d=
on't try to jam everything but the kitchen sink into 'scope'.
=C2=A0



We are now up to 15+ specifications that someone has to read and

understand how these all may or may not fit together and all the

interactions that may occur. So much for the simple Oauth.
=

=C2=A0



This particular text is simpler than a token exchange draft :-).
=C2=A0

By the way there was a proposal recently to have OAuth 2.1 document where t=
he best practices/etc are suggested, I suppose that can help consolidate va=
rious texts created since original OAuth 2.0

At some point this may make sense, but I think for now the better con=
solidated approach is online documentation and books. Not everyone needs to start at t=
he RFC level.

As Mike Jones suggested earlier we s=
hould have some rounds of iteration and get experience with the various ext=
ension specs before we attempt to merge them together into 1 document. For =
example, it's likely that not all the specs would get included in such =
a document and we need more deployment experience to know what to include, =
and what not to.

=C2=A0

*From:*Justin Richer [mailto:jricher@mit=
.edu]

*Sent:* Tuesday, April 12, 2016 5:46 AM

*To:* Torsten Lodderstadt <to=
rsten@lodderstedt.net>

*Cc:* Anthony Nadalin <tonynad@=
microsoft.com>; <oauth@ietf.org=
>

<oauth@ietf.org>

*Subject:* Re: [OAUTH-WG] Call for Adoption: Resource Indicators for

OAuth 2.0



+1 to Torsten=E2=80=99s point.



And a reminder to Tony that call for adoption is the *start* of the

document editing process, not the end. We=E2=80=99re not saying this is a
complete solution with everything thought out when we adopt the

document, we=E2=80=99re saying it=E2=80=99s a problem we want to work on an=
d a direction

that we want to move in. Stop trying to confuse people.



=C2=A0 =E2=80=94 Justin



=C2=A0 =C2=A0 On Apr 12, 2016, at 1:30 AM, Torsten Lodderstedt

=C2=A0 =C2=A0 <torsten@lodder=
stedt.net <mailto:torsten=
@lodderstedt.net>> wrote:



=C2=A0 =C2=A0 Indicating the resource server to the AS allows the AS to

=C2=A0 =C2=A0 automatically select token type, encryption scheme and user d=
ata to

=C2=A0 =C2=A0 be put into the access token based on a RS-specific policy. S=
o there

=C2=A0 =C2=A0 is no need to explicitely ask the AS for a certain token form=
at or

=C2=A0 =C2=A0 encryption scheme.





=C2=A0 =C2=A0 Am 11.04.2016 um 22:35 schrieb Anthony Nadalin

=C2=A0 =C2=A0 <tonynad@microsof=
t.com <mailto:tonynad@micro=
soft.com>>:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 So it=E2=80=99s an incomplete solution then ?


=C2=A0 =C2=A0 =C2=A0 =C2=A0 *From:*Brian Campbell [mailto:bcampbell@pingidentity.com]

=C2=A0 =C2=A0 =C2=A0 =C2=A0 *Sent:*Monday, April 11, 2016 1:34 PM

=C2=A0 =C2=A0 =C2=A0 =C2=A0 *To:*Anthony Nadalin <tonynad@microsoft.com

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:tonynad@microsoft.com>>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 *Cc:*Nat Sakimura <sakimura@gmail.com

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:sakimura@gmail.com>>; <oau=
th@ietf.org

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:oa=
uth@ietf.org>> <oauth@ietf.o=
rg <mailto:oauth@ietf.org>&=
gt;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 *Subject:*Re: [OAUTH-WG] Call for Adoption: Res=
ource Indicators

=C2=A0 =C2=A0 =C2=A0 =C2=A0 for OAuth 2.0



=C2=A0 =C2=A0 =C2=A0 =C2=A0 No, I'm not adding requirements for encrypt=
ion. I was pointing

=C2=A0 =C2=A0 =C2=A0 =C2=A0 out some of the ways that an access token might=
 be different for

=C2=A0 =C2=A0 =C2=A0 =C2=A0 different RSs.





=C2=A0 =C2=A0 =C2=A0 =C2=A0 On Mon, Apr 11, 2016 at 2:18 PM, Anthony Nadali=
n

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <to=
nynad@microsoft.com <mailto:tonynad@microsoft.com>> wrote:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 So now you are adding more requir=
ements for encryption ? The

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 more this thread goes on shows ho=
w unstable and not fully

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 thought out this draft is to go t=
hrough WG adoption.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *From:*OAuth [mailto:oauth-bounces@ietf.org

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:oauth-bounces@ietf.org>]*On Behalf Of*Brian Camp=
bell

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *Sent:*Monday, April 11, 2016 12:=
30 PM

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *To:*Nat Sakimura <sakimura@gmail.com

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *Cc:*<oauth@ietf.org <mailto:o=
auth@ietf.org>>

=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 *Subject:*Re: [OAUTH-WG] Call for=
 Adoption: Resource

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Indicators for OAuth 2.0



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Sending a token type is not suffi=
cient. There's more

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 involved than the format. Many ca=
ses need to know if to

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 encrypt and whom to encrypt to.=
=C2=A0 What claims to put in the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 token (or reference by the token)=
. What algorithms and keys

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to use for signing/encryption.




=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The statement that the "Curr=
ent proposal does not support

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the implicit flow" is incorr=
ect. Among other things, sec 2

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 has, "When an access token w=
ill be returned from the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 authorization endpoint, the "=
;resource" parameter is used in

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the authorization request to the =
authorization endpoint as

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 defined in Section 4.2.1 of OAuth=
 2.0 [RFC6749]."



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Sun, Apr 10, 2016 at 11:43 AM,=
 Nat Sakimura

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



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 So, my understandin=
g on the rationale/requirements for

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 having this spec ri=
ght now is:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 R1. Authz server wa=
nts toprevent the replay by the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 server that receive=
d it.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 R2. Authz server ne=
eds to mint the access token in a

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 variety of format d=
epending on the resource server and

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to do that, you nee=
d to know which RS is gong to be

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 receiving it.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 To achieve R1, ther=
e are couple of methods. The proposed

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 method here is to a=
udience restrict the token, but the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 same can be achieve=
d by sender constraining the token,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 e.g., by token bind=
ing. As far as I can see, the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sentiment of the WG=
 seems to be to use the sender

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 constraint through =
Token Binding, so from this respect,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this spec is not th=
e one to do R1. Besides, the current

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 proposal only takes=
 care of the code flow. The same

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 requirement should =
be there for implicit flow as well,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 so the current prop=
osal is not covering the R1 anyways.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I can sort of under=
stand R2, but I have two critique on

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the current proposa=
l:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 C1. Current proposa=
l does not support the implicit flow.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 To support it, the =
resource URI has to be sent to the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authz endpoint inst=
ead of the Token endpoint.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 C2. It is much more=
 direct to send the required token

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 format rather than =
the RS uri and probably better as:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01) The=
re are use cases where the AS does not maintain

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the list of RSs tha=
t it supports, e.g., AOL.



=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 such a case, even if the RS uri were sent to

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the AS, the AS cann=
ot mint the tokens in the appropriate

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 format.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02) Whe=
n it is sent in the Authz request, it is

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaking the informa=
tion about the resource that the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 client is going to =
the browser.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03) The=
re are use cases where it is desirable not to

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 let the AS knows wh=
ere the Client is going from the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 privacy point of vi=
ew.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 So, my suggestion i=
s to drop R1 and concentrate on R2.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 And to solve R2, se=
nd token type instead of the resource

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 indicator in the re=
quest.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This also necessita=
tes the Client to be able to find out

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 what token type the=
 resource requires, perhaps in the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 unauthorized respon=
se web link header at the resource in

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the manner of oauth=
-meta.



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



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2016=E5=B9=B44=E6=
=9C=888=E6=97=A5(=E9=87=91) 8:23 Prateek Mishra

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <Prateek.Mishra@oracle.com

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:Prateek.Mishra@oracle.com>>=
:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 While=
 this work addresses a gap in the existing

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OAuth=
 specification set, I am very concerned that this

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 incre=
mental extension will lead to even more

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 confu=
sion around the areas of =E2=80=9Cscope=E2=80=9D, =E2=80=9Caudience=E2=80=
=9D

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and =
=E2=80=9Cresource server=E2=80=9D.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I thi=
nk we should try to solve this problem via=C2=A0 a

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 frame=
work that provides better guidance and

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 imple=
mentation

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 model=
s for OAuth use-cases. In other words, I feel

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that =
a broader discussion is needed here.





=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0> On Apr 7, 2016, at 4:11 PM, Justin Richer

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<=
a href=3D"mailto:jricher@mit.edu">jricher@mit.edu <mailto:jricher@mit.edu>> 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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0> I support adoption of this document as a starting

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 point=
 for working group work.

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

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

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

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0>> On Apr 6, 2016, at 1:25 PM, Hannes Tschofenig

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<=
a href=3D"mailto:hannes.tschofenig@gmx.net">hannes.tschofenig@gmx.net
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <m=
ailto:hannes.tschofenig@gmx.ne=
t>> 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 =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 =C2=A0 =C2=A0 =C2=
=A0>> this is the call for adoption of 'Resource

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Indic=
ators for OAuth 2.0', see

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0>>http://datatracker.ietf.org/doc/dr=
aft-campbell-oauth-resource-indicators/ <https://na01.safelinks.protection.outlook.com/?url=
=3Dhttp%3a%2f%2fdatatracker.ietf.org%2fdoc%2fdraft-campbell-oauth-resource-=
indicators%2f&data=3D01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb644=
2ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3Dy869F=
k9987ff09hvHIN%2bVGl%2fqxwWDmkvOwzcQcWqXZw%3d>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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 April 20th whether you

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 accep=
t / object to the

=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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for w=
ork 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>> 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 =C2=A0 =C2=A0 =C2=
=A0>> Note: If you already stated your opinion at the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IETF =
meeting in Buenos

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0>> Aires then you don't need to re-state your

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 opini=
on, if you want.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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 feedback at the BA IETF meeting was the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 follo=
wing: ~10 persons

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0>> for accepting the document and 0 persons against.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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>> 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>> 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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<=
a href=3D"https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%=
2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40=
microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7c=
d011db47%7c1&sdata=3Dbfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d=
" rel=3D"noreferrer">https://na01.safelinks.protection.outlook.com/?url=3Dh=
ttps%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7=
ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f14=
1af91ab2d7cd011db47%7c1&sdata=3Dbfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKH=
ECIUKiBQ%3d>

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<=
a href=3D"https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%=
2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40=
microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7c=
d011db47%7c1&sdata=3Dbfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d=
" rel=3D"noreferrer">https://na01.safelinks.protection.outlook.com/?url=3Dh=
ttps%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7=
ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f14=
1af91ab2d7cd011db47%7c1&sdata=3Dbfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKH=
ECIUKiBQ%3d>



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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 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 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 <<=
a href=3D"https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%=
2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40=
microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7c=
d011db47%7c1&sdata=3Dbfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d=
" rel=3D"noreferrer">https://na01.safelinks.protection.outlook.com/?url=3Dh=
ttps%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7=
ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f14=
1af91ab2d7cd011db47%7c1&sdata=3Dbfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKH=
ECIUKiBQ%3d>





=C2=A0 =C2=A0 =C2=A0 =C2=A0 =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<=
br>
=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 https://www.ietf.or=
g/mailman/listinfo/oauth

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fw=
ww.ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40mic=
rosoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd01=
1db47%7c1&sdata=3Dbfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d>



=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 OAuth@ietf.or=
g <mailto:OAuth@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/oauth=


=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://na01.safelink=
s.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf.org%2fmailman%2flist=
info%2foauth&data=3D01%7c01%7ctonynad%40microsoft.com%7c81244957f086491=
ed84508d362d07a2d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DApH6%2=
fbRs21OYURWWYx4N4lWVSeCI%2fAPj2eSOA3fdcTw%3d>



=C2=A0 =C2=A0 _______________________________________________

=C2=A0 =C2=A0 OAuth mailing list

=C2=A0 =C2=A0 OAuth@ietf.org <mail=
to:OAuth@ietf.org>

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

=C2=A0 =C2=A0 <https://na01.safelinks.protection.o=
utlook.com/?url=3Dhttps%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&a=
mp;data=3D01%7c01%7ctonynad%40microsoft.com%7c81244957f086491ed84508d362d07=
a2d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DApH6%2fbRs21OYURWWYx=
4N4lWVSeCI%2fAPj2eSOA3fdcTw%3d>







_______________________________________________

OAuth mailing list

OAuth@ietf.org

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









-- 

Sergey Beryozkin



Talend Community Coders

http://coders.tale=
nd.com/




_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





--001a113dc9a27b63b805304c762d--


From nobody Wed Apr 13 05:23:49 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F1D12D52C for ; Wed, 13 Apr 2016 05:23:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.631
X-Spam-Level: 
X-Spam-Status: No, score=-0.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gm34_17vdyCb for ; Wed, 13 Apr 2016 05:23:45 -0700 (PDT)
Received: from mx0b-0019e102.pphosted.com (mx0b-0019e102.pphosted.com [67.231.157.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF77112D50A for ; Wed, 13 Apr 2016 05:23:44 -0700 (PDT)
Received: from pps.filterd (m0074414.ppops.net [127.0.0.1]) by mx0b-0019e102.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u3DCLGOi000902 for ; Wed, 13 Apr 2016 07:23:40 -0500
Received: from mail-yw0-f176.google.com (mail-yw0-f176.google.com [209.85.161.176]) by mx0b-0019e102.pphosted.com with ESMTP id 229hr08hs0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 13 Apr 2016 07:23:39 -0500
Received: by mail-yw0-f176.google.com with SMTP id o66so65584029ywc.3 for ; Wed, 13 Apr 2016 05:23:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uwJ7Bn3tzAaWsqx9h4harctTKvEUREvtG52D6sejX7U=; b=ISgcWSCpTBgtAHuinugtG4DhyA2cnLcwPzEld2+/OD1HkH6MDqEwTufmrc1u1B4HEt w7EpD9PvSLa/2SwTr+9BO0EPb0/q5UnbHlTJ3EwIlKvDV+1GOoNxxyNO28Gr255UaJxI snjX1rqkbEaEc7hW/RB+uEHkfiwrfM86eqQLicFTAdbfL610SC91tJ/PLQj3rSYn7xrn ObiAgDdSksL81qlmPEjDRUzEaw9xidQypVhP/e5XShCNM+mh8pBCw828k1EX4Jq0WvTd jDENExEouK1ix7wMjprdPQmhYyN2TZs4Z++jFxVxD8sseDsjkhZ4K+ruW5MToIR1kDS9 mYhg==
X-Gm-Message-State: AOPr4FXEH7edWeVHhO8rpfcwYgmk45lzipVXmmvKMtiKLkwrS/1yir9USavjGLQR+j5PYmsD5HoYGR65Q4GIZUznxRnot1c/9vcujIyOWrR8noulIudUuxytcRxcIXiEkW2gH9MDhQ+N9ajk
X-Received: by 10.129.32.137 with SMTP id g131mr4468267ywg.126.1460550219539;  Wed, 13 Apr 2016 05:23:39 -0700 (PDT)
X-Received: by 10.129.32.137 with SMTP id g131mr4468259ywg.126.1460550219366;  Wed, 13 Apr 2016 05:23:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.106.132 with HTTP; Wed, 13 Apr 2016 05:23:19 -0700 (PDT)
In-Reply-To: 
References:  
From: Adam Lewis 
Date: Wed, 13 Apr 2016 07:23:19 -0500
Message-ID: 
To: Brian Campbell 
Content-Type: multipart/alternative; boundary=001a1140496400b2a705305cd984
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603180000 definitions=main-1604130179
Archived-At: 
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Question on draft-ietf-oauth-token-exchange-04
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Apr 2016 12:23:47 -0000

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

Hi Brian,

Your explanation is helpful, makes sense now.

In fact, this makes things very interesting for me because it could provide
a round-about way to do an ac/dc like flow where a client C whose AS1 is in
security domain 1 can swap an access token from AS1 for a JWT to present to
AS2 via a JWT grant type, in exchange for an access token from AS2 to use
at RS2.

I've been bumbed out about ac/dc losing steam because it provided a very
elegant solution for some of my critical use cases, but token exchange is
shaping up to indirectly provide the same functionality.  Awesome :-)



-adam

On Mon, Apr 11, 2016 at 3:26 PM, Brian Campbell 
wrote:

> The intent is that urn:ietf:params:oauth:token-type:access_token be an
> indicator that the token is a typical OAuth access token issued by the AS
> in question, opaque to the client, and usable the same manner as any othe=
r
> access token obtained from that AS (it could well be a JWT but the client
> isn't and needn't be aware of that fact). Whereas
> urn:ietf:params:oauth:token-type:jwt is to indicate that a JWT specifical=
ly
> is being requested or sent (perhaps in a cross-domain use case to get an
> access token from a different AS like is facilitated by RFC 7523).
>
> Is that helpful at all?
>
> I agree that it can be confusing. But it's representative of the kinds of
> tokens and their usages out there now. So, needs to be allowed. I'd welco=
me
> ideas about how the language could be improved to help alleviate some of
> the confusion though.
>
> On Mon, Apr 11, 2016 at 7:25 AM, Adam Lewis <
> adam.lewis@motorolasolutions.com> wrote:
>
>> Hi,
>>
>> There are multiple places in draft-ietf-oauth-token-exchange-04 where a
>> differentiation seems to be drawn between 'access_token' and 'jwt' ... f=
or
>> example in section 2.2.1. when discussing the issued_token_type, it stat=
es:
>>
>>       a value of "urn:ietf:params:oauth:token-type:access_token" indicat=
es
>>
>>       that the issued token is an access token and a value of
>>       "urn:ietf:params:oauth:token-type:jwt" indicates that it is a JWT.
>>
>>
>> This is confusing to me because an access token represents a delegated a=
uthorization decision, whereas JWT is a token *format*.  An access token co=
uld easily be a JWT (and in many deployments, they are).
>>
>>
>> So why the desire to differentiate, and what does the differentiation me=
an?
>>
>>
>>
>> tx!
>> adam
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>>
>>
>

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


Hi Brian,

Your explanation is helpf=
ul, makes sense now. =C2=A0

In fact, this makes th=
ings very interesting for me because it could provide a round-about way to =
do an ac/dc like flow where a client C whose AS1 is in security domain 1 ca=
n swap an access token from AS1 for a JWT to present to AS2 via a JWT grant=
 type, in exchange for an access token from AS2 to use at RS2.
I've been bumbed out about ac/dc losing steam because it p=
rovided a very elegant solution for some of my critical use cases, but toke=
n exchange is shaping up to indirectly provide the same functionality.=C2=
=A0 Awesome :-)



-ada=
m

On M=
on, Apr 11, 2016 at 3:26 PM, Brian Campbell <bcampbell@pingiden=
tity.com> wrote:
The intent is that urn:ietf:params:oauth:token-type=
:access_token be an indicator that the token is a typical OAuth access toke=
n issued by the AS in question, opaque to the client, and usable the same m=
anner as any other access token obtained from that AS (it could well be a J=
WT but the client isn't and needn't be aware of that fact). Whereas=
 urn:ietf:params:oauth:token-type:jwt is to indicate that a JWT specificall=
y is being requested or sent (perhaps in a cross-domain use case to get an =
access token from a different AS like is facilitated by RFC 7523). 

=

Is that helpful at all?

I agree that it can be confusing=
. But it's representative of the kinds of tokens and their usages out t=
here now. So, needs to be allowed. I'd welcome ideas about how the lang=
uage could be improved to help alleviate some of the confusion though. 
=


=

On Mon, Apr 11, 2016 at 7:25 AM, Adam Lewis <adam.lewis@motorolasolutions.com> wrote:
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">
Hi,
There are multiple places in=C2=A0draft-ietf-oauth-token-=
exchange-04 where a differentiation seems to be drawn between 'access_t=
oken' and 'jwt' ... for example in section 2.2.1. when discussi=
ng the issued_token_type, it states:

   =
   a value of "urn:ietf:params:oauth:token-type:access_token" ind=
icates=C2=A0
      that the issued token is an access token =
and a value of
      "urn:ietf:params:oauth:token-type:jwt" indicates that it is=
 a JWT.

T=
his is confusing to me because an access token represents a delegated autho=
rization=C2=A0decision, whereas JWT is a token *format*.=C2=A0 An access to=
ken could easily be a JWT (and in many deployments, they are). =C2=A0

So why the desire to differentiate, and =
what does the differentiation mean?


tx!
adam


_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mai=
lman/listinfo/oauth








--001a1140496400b2a705305cd984--


From olivida@microsoft.com  Wed Apr 13 11:45:14 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9D012DFF2 for ; Wed, 13 Apr 2016 11:45:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pde7UuQT2IBn for ; Wed, 13 Apr 2016 11:45:12 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0103.outbound.protection.outlook.com [65.55.169.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 9E3FA12DFD3 for ; Wed, 13 Apr 2016 11:45:11 -0700 (PDT)
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=atuLgsZ4/N6wKggEpwEQ2Y/gE1o9Z6OixUiWuVEd1cs=; b=noQrJFMVTTFkZwSFbWILjpd62/AYVZVOfzLAk8JvFsj5/n0/XzZy0Y/adhFVsOdGdCkL70FE4KdkSKRPDYfHIBckF66VVbA0agkvGW0U2oX1nwYQZY4Og0ZoXtLKEwmrrhqjPeCpU4hmrpNXRfMjf1H9t5/anzZDnk/lJp1dufg=
Received: from CY1PR0301MB0857.namprd03.prod.outlook.com (10.160.163.151) by CY1PR0301MB0860.namprd03.prod.outlook.com (10.160.163.155) with Microsoft SMTP Server (TLS) id 15.1.453.26; Wed, 13 Apr 2016 18:45:07 +0000
Received: from CY1PR0301MB0857.namprd03.prod.outlook.com ([10.160.163.151]) by CY1PR0301MB0857.namprd03.prod.outlook.com ([10.160.163.151]) with mapi id 15.01.0453.029; Wed, 13 Apr 2016 18:45:07 +0000
From: Oli Dagenais 
To: "oauth@ietf.org" 
Thread-Topic: Feedback on Device Flow draft 01
Thread-Index: AdGVtDcErPk4odyqSS659ZZea1sDvw==
Date: Wed, 13 Apr 2016 18:45:07 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [216.58.27.239]
x-ms-office365-filtering-correlation-id: 5ed7af4d-fc77-4e85-8b8d-08d363cbbc67
x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0860; 5:OOf5SI3sNsqFJ9Zl5NMQUFCqzwRWP9FeO2C6XCqzHgTs9EyTFljIQRGJN7GjtOl7bf7T+vKFLQQlegyZ3iiJUeZky1j75Y44u1MZFY6j4yaBSH+auhu2tUcB0jO0H+0P3H9gIuOAFdQ6Jof/j5Pnsw==; 24:mKu2gYx0ZlytPkIlNweJff+dnSMoGjGeYD/fX80UjlG0L6cK5OqhfmHKsi5sJbM5Jv/laNnZ7Zl5cpsl0IogICr4t54nAiW3BuJDqU4F3VI=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0860;
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)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0860; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0860; 
x-forefront-prvs: 0911D5CE78
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(19580395003)(74316001)(99286002)(5005710100001)(450100001)(10400500002)(189998001)(2501003)(19300405004)(10290500002)(10090500001)(92566002)(102836003)(5004730100002)(19625215002)(8990500004)(77096005)(54356999)(50986999)(86612001)(9686002)(33656002)(1096002)(3846002)(790700001)(6116002)(1220700001)(66066001)(11100500001)(5008740100001)(5002640100001)(86362001)(586003)(81156013)(15975445007)(76576001)(5003600100002)(19617315012)(3280700002)(2906002)(3660700001)(1730700002)(16236675004)(575784001)(5630700001)(2351001)(5640700001)(110136002)(81166005)(107886002)(2900100001)(229853001)(87936001)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0860; H:CY1PR0301MB0857.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB0857560F53492E159A3CFA4DB1960CY1PR0301MB0857_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2016 18:45:07.8379 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0860
Archived-At: 
Subject: [OAUTH-WG] Feedback on Device Flow draft 01
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Apr 2016 18:47:48 -0000

--_000_CY1PR0301MB0857560F53492E159A3CFA4DB1960CY1PR0301MB0857_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I am in the process of implementing Device Flow and, going by the specifica=
tion draft at https://tools.ietf.org/html/draft-ietf-oauth-device-flow-01, =
have noticed some opportunities for improvement, which I am sharing and hop=
ing to discuss.  I am new to providing feedback on IETF drafts, so if you w=
ould prefer my feedback be in another form (i.e. pull requests of suggested=
 changes to the document source, creating tickets/issues in a work item tra=
cker, posting to another mailing list, etc.), please let me know.

1.       Section 3.1 reads:

The client constructs a request URI by adding the following parameters to t=
he request:



...it should read (since it's a POST request) like the first paragraph of s=
ection 4.1.3 in RFC6749 (although then we would need to add appendices - wh=
ich makes sense if this is to become its own RFC):


   The client makes a request to the device endpoint by sending the
   following parameters using the "application/x-www-form-urlencoded"
   format per Appendix B wi=
th a character encoding of UTF-8 in the HTTP
   request entity-body:
2.       We may want to have Section 3.1 suggest (i.e. "RECOMMENDED") reaso=
nable defaults for "expires_in" and "interval". It's probably reasonable to=
 match the authorization code lifetime from section 4.1.2 of RFC6749 for ex=
pires_in:



"A maximum verification code lifetime of 600 seconds (10 minutes) is RECOMM=
ENDED."



...alternatively, we write it like in section 4.2.2 of RFC6749:

   expires_in

         RECOMMENDED.  The lifetime in seconds of the verification code.

         For example, the value "600" denotes that the verification code

         will expire in ten minutes from the time the response was

         generated. If omitted, the authorization server SHOULD provide

         the expiration time via other means or document the default

         value.



As for "interval", the example in that section would lead us to believe 5 s=
econds is a reasonable default.  Again, we probably should flag it as RECOM=
MENDED to prevent too many clients from hammering the server, which will ha=
ve to respond with "slow_down".
3.       Section 3.2 links to "Section 4.1.1 of RFC6749" but it seems to me=
 it should link to section "4.1.3 of RFC6749" (Access Token Request).
4.       I recommend splitting section 3.1 (perhaps by using subsections) i=
nto "Authorization Request" and "Authorization Response".
5.       Section 3.2 is rather ambiguous as to the use of the token endpoin=
t.  It might be useful to copy and adapt section 4.1.3 of RFC6749 to be exp=
licit.  For example, is the "grant_type" supposed to be "authorization_code=
"?  I noticed the Azure Active Directory Library for .NET sets the grant_ty=
pe to "device_code".  Something like:



grant_type
         REQUIRED.  Value MUST be set to "device_code".



code
         REQUIRED.  The device verification code received from the
         authorization server.



client_id
         REQUIRED, if the client is not authenticating with the
         authorization server as described in Section 3.2.1 of

         [RFC6749].



If the client type is confidential or the client was issued client
   credentials (or assigned other authentication requirements), the
   client MUST authenticate with the authorization server as described
   in Section 3.2.1 of [RFC6749].



For example, the client makes the following HTTPS request
   (with extra line breaks for display purposes only):



     POST /token HTTP/1.1
     Host: server.example.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
     Content-Type: application/x-www-form-urlencoded



     grant_type=3Ddevice_code&code=3D74tq5miHKB



The authorization server MUST:



o  require client authentication for confidential clients or for any
      client that was issued client credentials (or with other
      authentication requirements),



o  authenticate the client if client authentication is included,



o  ensure that the verification code was issued to the authenticated
      confidential client, or if the client is public, ensure that the
      code was issued to "client_id" in the request, and



o  verify that the device verification code is valid.
6.       It seems like the device endpoint _could_ return an error (HTTP 40=
0), under the following conditions:
a.       response_type is not "device_code"
b.       client_id is not recognized OR client did not otherwise authentica=
te appropriately
c.       scope isn't a value recognized by the implementation
d.       the method isn't POST (it appears Azure Active Directory supports =
GET and POST)
e.       Content-Type is not application/x-www-form-urlencoded
7.       Are there extra parameters that can be supplied to the device endp=
oint? What should happen to those?  Would they be passed through to the res=
ponse?  If so, the documentation for the response should warn about extra p=
arameters that MUST not break the client.
8.       In section 3.1, the device endpoint response example JSON reads:

"interval"=3D5

...it SHOULD read: (notice the '=3D' should have been ':')

"interval":5
9.       Section 3.3 reads:

   The following error responses are defined in addition to those within

   Section 4.2.2.1. of [RFC6749]:

...I think linking to Section 5.2 would be more appropriate, because 4.2.2.=
1 is about returning the response as parameters in the redirection URI wher=
eas 5.2 is about responding with HTTP 400 and an application/json payload, =
which would make it more consistent with a successful device flow.  I see, =
however, that 4.2.2.1 includes "access_denied" and "server_error" error cod=
es, so perhaps we must again cherry-pick from two sections to create new co=
ntent that is unambiguous for the Device Flow specification.
10.   In Section 3.1, the type of "expires_in" and "interval" is not made e=
xplicit, although it is implied from the example.  Azure Active Directory r=
eturns them as JSON strings instead of JSON numbers.  We may want to replac=
e:

   In response, the authorization server generates a verification code

   and an end-user code and includes them in the HTTP response body

   using the "application/json" format with a 200 status code (OK).  The

   response contains the following parameters:

...with something like:

   The authorization server generates a verification code and an

   end-user code, and constructs the response by adding the following

   parameters to the entity-body of the HTTP response with a 200 (OK)

   status code:

...and then add this between the last parameter and the example:

   The parameters are included in the entity-body of the HTTP response

   using the "application/json" media type as defined by [RFC4627].  The

   parameters are serialized into a JavaScript Object Notation (JSON)

   structure by adding each parameter at the highest structure level.

   Parameter names and string values are included as JSON strings.

   Numerical values are included as JSON numbers.  The order of

   parameters does not matter and can vary.



   The authorization server MUST include the HTTP "Cache-Control"

   response header field [RFC2616] with a value of "no-store" in any

   response containing tokens, credentials, or other sensitive

   information, as well as the "Pragma" response header field [RFC2616]

   with a value of "no-cache".


Cheers,
- Oli

--
Let me help you be awesome at what you do, using
Microsoft Developer Tools
+1 613-212-5551


--_000_CY1PR0301MB0857560F53492E159A3CFA4DB1960CY1PR0301MB0857_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I am in the process of implementing Device Flow and=
, going by the specification draft at
htt=
ps://tools.ietf.org/html/draft-ietf-oauth-device-flow-01, have noticed =
some opportunities for improvement, which I am sharing and hoping to discus=
s.  I am new to providing feedback
 on IETF drafts, so if you would prefer my feedback be in another form (i.e=
. pull requests of suggested changes to the document source, creating ticke=
ts/issues in a work item tracker, posting to another mailing list, etc.), p=
lease let me know.


 



1.      
Section 3.1 reads:



The cl=
ient constructs a request URI by adding the following parameters to the req=
uest:



 



...it should read (since it's a POST request) like the first paragraph of =
section 4.1.3 in RFC6749 (although then we would need to add appendices - w=
hich makes sense if this is to become its own
 RFC):

 



 =
  The client makes a request to the device endpoint by sending the

   following parameters using the "application/x-www-form-ur=
lencoded"

   format per Appendix B with a character encoding of UTF-8 in the HTTP

   request entity-body:



2.      
We may want to have Section 3.1 suggest (i.e. "=
;RECOMMENDED") reasonable defaults for "expires_in" and &quo=
t;interval". It's probably reasonable to match the authorization code =
lifetime from section 4.1.2 of RFC6749 for expires_in:



 



"A maximum verification code lifetime of 600 seconds (10 minutes) is=
 RECOMMENDED."



 =




...alternatively, we write it like in section 4.2.2 of RFC6749:=




 =
  expires_in



 =
        RECOMMENDED.  The lifetime =
in seconds of the verification code.



 =
        For example, the value "600=
" denotes that the verification code



 =
        will expire in ten minutes from =
the time the response was



 =
        generated. If omitted, the autho=
rization server SHOULD provide



 =
        the expiration time via other me=
ans or document the default



 =
        value.



 



As for "interval", the example in that section would lead us to =
believe 5 seconds is a reasonable default.  Again, we probably should =
flag it as RECOMMENDED to prevent too many clients from hammering
 the server, which will have to respond with "slow_down".



3.      
Section 3.2 links to "Section 4.1.1 of RFC6749=
" but it seems to me it should link to section "4.1.3 of RFC6749&=
quot; (Access Token Request).



4.      
I recommend splitting section 3.1 (perhaps by using=
 subsections) into "Authorization Request" and "Authorizatio=
n Response".



5.      
Section 3.2 is rather ambiguous as to the use of th=
e token endpoint.  It might be useful to copy and adapt section 4.1.3 =
of RFC6749 to be explicit.  For example, is the "grant_type"=
 supposed to be "authorization_code"?  I noticed the
 Azure Active Directory Library for .NET sets the grant_type to "devic=
e_code".  Something like:



 



grant_=
type

         REQUIRED.  Value MUST=
 be set to "device_code".



 =




code
         REQUIRED.  The device=
 verification code received from the

         authorization server.=




 =




client=
_id

         REQUIRED, if the client is=
 not authenticating with the

         authorization server as de=
scribed in Section 3.2.1 of



 =
        [RFC6749].



 =




If the=
 client type is confidential or the client was issued client

   credentials (or assigned other authentication requirements), t=
he

   client MUST authenticate with the authorization server as desc=
ribed

   in Section 3.2.1 of [RFC6749].



 =




For ex=
ample, the client makes the following HTTPS request

   (with extra line breaks for display purposes only):=




 =




 =
    POST /token HTTP/1.1

     Host: server.example.com

     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW<=
br>
     Content-Type: application/x-www-form-urlencoded



 =




 =
    grant_type=3Ddevice_code&code=3D74tq=
5miHKB



 



The au=
thorization server MUST:



 =




o =
; require client authentication for confidential clients or for any

      client that was issued client credentials (o=
r with other

      authentication requirements),



 =




o =
; authenticate the client if client authentication is included,<=
/span>



 =




o =
; ensure that the verification code was issued to the authenticated

      confidential client, or if the client is pub=
lic, ensure that the

      code was issued to "client_id" in =
the request, and



 =




o =
; verify that the device verification code is valid.



6.      
It seems like the device endpoint _could_ return an=
 error (HTTP 400), under the following conditions:



a.      
response_type is not "device_code"



b.      
client_id is not recognized OR client did not other=
wise authenticate appropriately



c.      
scope isn't a value recognized by the implementatio=
n



d.      
the method isn't POST (it appears Azure Active Dire=
ctory supports GET and POST)



e.      
Content-Type is not application/x-www-form-urlencod=
ed



7.      
Are there extra parameters that can be supplied to =
the device endpoint? What should happen to those?  Would they be passe=
d through to the response?  If so, the documentation for the response =
should warn about extra parameters that MUST
 not break the client.



8.      
In section 3.1, the device endpoint response exampl=
e JSON reads:



"=
interval"=3D5



...it SHOULD read: (notice the '=3D' should have been ':')



"=
interval":5



9.      
Section 3.3 reads:



 =
  The following error responses are defined in addition to those withi=
n



 =
  Section 4.2.2.1. of [RFC6749]:



...I think linking to Section 5.2 would be more appropriate, because 4.2.2=
.1 is about returning the response as parameters in the redirection URI whe=
reas 5.2 is about responding with HTTP 400 and
 an application/json payload, which would make it more consistent with a su=
ccessful device flow.  I see, however, that 4.2.2.1 includes "acc=
ess_denied" and "server_error" error codes, so perhaps we mu=
st again cherry-pick from two sections to create new content
 that is unambiguous for the Device Flow specification.


10.  
In Section 3.1, the type of "expires_in" =
and "interval" is not made explicit, although it is implied from =
the example.  Azure Active Directory returns them as JSON strings inst=
ead of JSON numbers.  We may want to replace:



 =
  In response, the authorization server generates a verification code<=
o:p>



 =
  and an end-user code and includes them in the HTTP response body



 =
  using the "application/json" format with a 200 status code=
 (OK).  The



 =
  response contains the following parameters:



...with something like:



 =
  The authorization server generates a verification code and an



 =
  end-user code, and constructs the response by adding the following



 =
  parameters to the entity-body of the HTTP response with a 200 (OK)



 =
  status code:



...and then add this between the last parameter and the example:



 =
  The parameters are included in the entity-body of the HTTP response<=
o:p>



 =
  using the "application/json" media type as defined by [RFC=
4627].  The



 =
  parameters are serialized into a JavaScript Object Notation (JSON)



 =
  structure by adding each parameter at the highest structure level.



 =
  Parameter names and string values are included as JSON strings.=




 =
  Numerical values are included as JSON numbers.  The order of



 =
  parameters does not matter and can vary.



 =




 =
  The authorization server MUST include the HTTP "Cache-Control&q=
uot;



 =
  response header field [RFC2616] with a value of "no-store"=
 in any



 =
  response containing tokens, credentials, or other sensitive



 =
  information, as well as the "Pragma" response header field=
 [RFC2616]



 =
  with a value of "no-cache".


 


 


Cheers,


- Oli


 


--



Let me help you be awesome at what you =
do, using


Microsoft Developer Tools


+1 613-212-5551

 






--_000_CY1PR0301MB0857560F53492E159A3CFA4DB1960CY1PR0301MB0857_--


From nobody Thu Apr 14 22:10:45 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA6912E0A1 for ; Thu, 14 Apr 2016 22:10:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=herberg.name
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMrdMJEYUjH8 for ; Thu, 14 Apr 2016 22:10:42 -0700 (PDT)
Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 329E812E0CE for ; Thu, 14 Apr 2016 22:10:42 -0700 (PDT)
Received: by mail-vk0-x22a.google.com with SMTP id n62so18938872vkb.0 for ; Thu, 14 Apr 2016 22:10:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to;  bh=N2JPxVIuHSZF3YSlE4vT45RMr5bz0P0VMC0rvi1Rb9s=; b=AAkSyhjA+NA+6tBvveT39UwoVqOt025hF/XYxHmFCHCWCQjS8xmLQADtExMqv1YUw9 jWCJ/ramb9eptLFzcy+POItrRjK7SLY8CmrACEoRMgPFeKrYCpOE3dE76iVfLU+G6A+U X12T4DfnfR/5FXQr7/z+fu0YwwWPyT8t+zy30=
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; bh=N2JPxVIuHSZF3YSlE4vT45RMr5bz0P0VMC0rvi1Rb9s=; b=lfgX3q0Ha9KmzdrFOW2aLqaCl0kEkI0rX6uag/7FpUUN+XOfYLLJUsqJH9CgvRJ4na qFmvjqMslkj27UOkbtP2sz7ZL/FEDA/iuwZhgfyr80C+I+iiaBHngXRXQ9VajPdDwlGD 86GT7R9OZGsuLIjGHDdYInQ68q7X7l4ulMqYtwidjR1nrjRgmW2W8QI33PUtf3kUG0Of 57x3Lq7RwvVFYsQcCtPf+1+Sk0PrUqBEGaowTOoXj4FuBOM9b7zg5ZYdSLPvASMuRykd 6gLzIspl/kCk+husyhQ+ho2Tj0muK4+wDxlPsE+zkuvoa/kZH/5TfLW7tls9ozKRvmj0 t/lw==
X-Gm-Message-State: AOPr4FVkvvDDd5Vt9I9gbrbRp2NC+qpQ3O5HtzCXmU26DDIQRIGwsi2nIIuLafj1i7+N9GpnAPXiENI81yYlSQ==
MIME-Version: 1.0
X-Received: by 10.31.162.3 with SMTP id l3mr9471155vke.68.1460697041239; Thu, 14 Apr 2016 22:10:41 -0700 (PDT)
Received: by 10.31.87.66 with HTTP; Thu, 14 Apr 2016 22:10:41 -0700 (PDT)
In-Reply-To: 
References: 
Date: Thu, 14 Apr 2016 22:10:41 -0700
Message-ID: 
From: Ulrich Herberg 
To: oauth@ietf.org
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: Re: [OAUTH-WG] draft-ietf-oauth-native-apps-01
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Apr 2016 05:10:43 -0000

Hi,

I was wondering if you had any thoughts about my comments below from
my other email?

In addition, I was wondering about the case where the client ID and
client secret of an app has been leaked. The draft mentions the case
where a rogue app intercepts the auth code by using the same redirect
URL scheme of another app and how to mitigate that with PKCE.
But how could you prevent the rogue app from pretending to be another
app in case it got hold of the Client ID and Client Secret of that
app? In that case, couldn't it initiate the auth request (and thereby
pass the PKCE verification correctly)?

Thanks
Ulrich

On Mon, Apr 4, 2016 at 10:09 AM, Ulrich Herberg  wrote:
> Hi,
>
> I have read draft-ietf-oauth-native-apps-01 and I generally agree with
> the overall recommendations in the draft, and it is well written (I
> haven't participated in this WG before, so I don't know what to what
> level it has already been discussed).
>
> Some comments:
> - Section 2, last paragraph:
> I agree with the general recommendation to not use an external user
> agent because of complexity. However, there are cases when a tablet is
> sold as a closed system and under full control of the vendor. In these
> cases, the vendor can preinstall the AS user agent into the operating
> system and provide APIs for other apps to use it.
>
>
> - Section 5.1 (Embedded User-agents): "Authorization servers SHOULD
> consider taking steps to detect and block logins via embedded
> user-agents that are not their own, where possible."
>
> Do you have any recommendation how to do that, other than reading the
> (easily modifiable) User-Agent HTTP header? Maybe you could add a
> sentence for providing some guidance here.
>
>
> - Section 5.3 (Phishing):
> This is indeed concerning; it's very easy to fake the in-app browser.
> The draft says: "If all native apps use the techniques described in
> this best practice, users will not need to sign-in frequently and thus
> should be suspicious of any sign-in request when they should have
> already been signed-in."
>
> That is true, in theory, but sounds like a big "if" to me. Most users
> are not savvy enough to be suspicious if a login screen appears and it
> looks the same as the one they know.
> I admit that I don't have any suggestion how to do it better, but this
> part seems to be the most problematic to me for using OAuth on native
> devices.
>
> Best regards
> Ulrich


From nobody Fri Apr 15 10:32:04 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9827512E871 for ; Fri, 15 Apr 2016 10:32:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.82
X-Spam-Level: 
X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=alexbilbie-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRWQl9--V1_D for ; Fri, 15 Apr 2016 10:32:02 -0700 (PDT)
Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010: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 BD39112E86F for ; Fri, 15 Apr 2016 10:32:01 -0700 (PDT)
Received: by mail-lf0-x22e.google.com with SMTP id e190so153667659lfe.0 for ; Fri, 15 Apr 2016 10:32:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alexbilbie-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Lfccd1khzmE2D2FJgKHk1fKHu8Q5U1952iJJawqikJ0=; b=zcNMcHtA5AOK7v+M1ceUGuXdbtDSAjmimSCv7COdDtukrUIa+tJmG/cuJTAXk9SDhL P5i/t/O+JYwNNzOMSLseQxVo68xr5TYlcOWKbMVPJxxaFa3KtWa2TPUXz1oiOqGmaZ8B CRTa+4JVVB1Lkk6uErIlPX0g472Qf9MbYsS2/4W9IpOtCcj3jfhJPotOBJVdOO+/s5lf NjNP8bLqqpQE3i4PuaZDK6ScaYDBzn8Ro8XVM2xaT2ygEdozt+rkpKUO0RIays2ObNDU U6ZGkkCNA/VrIl2gc5ZAQFetulj+tmMEJZqAvpkKuDq6o/JfihbbIByX4z3Lxk7FE0pu 291A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Lfccd1khzmE2D2FJgKHk1fKHu8Q5U1952iJJawqikJ0=; b=E4PffG2KWPSWGKGH4HCRIyFqCYM/iQ7imX8+WvtNmHybM5cltUHUfJe4z08xviRMPT fNNgmRCJ5gXB68E2/PtX3qDy9fYENtk/P8rOJx8bFx07o80yQwkqYRu0x48S1qUmKKp6 RXsv/mMDDPfUBx0ijfo55XJl878CERr4Q6Z/hSR6+5ZQ4J18ZF0BTsqt8jIXETy9n2uh +1hwmecH62vhDkKbLEZizUyobEZAP2MvRS/CuaXJd1+75xq43QZZJ6tQifW4qHNTnIrv MyCCtoiy+QAP7S1n4NDNtIZ3OKUq02N5bfo+9J2WrzCJee8zG4q1h64qAA5B79pk5lB2 mwxQ==
X-Gm-Message-State: AOPr4FXgt/rqw/QHI5ToAnB64mfdg5o++diesrxKQ8DBWgf/EjbMEakBNcqzmTu/aHsqyMX0yxDrHx8PVjWWqg==
X-Received: by 10.112.37.10 with SMTP id u10mr1877750lbj.28.1460741519604; Fri, 15 Apr 2016 10:31:59 -0700 (PDT)
MIME-Version: 1.0
From: Alex Bilbie 
Date: Fri, 15 Apr 2016 17:31:49 +0000
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary=001a11348416629e1005308963be
Archived-At: 
Subject: [OAUTH-WG] Device flow clarifications
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Apr 2016 17:32:03 -0000

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

N.B: I sent the following email to
draft-ietf-oauth-device-flow@tools.ietf.org on 12th April but didn't
receive a reply so am reposting here:

---

Hello,

I've been working on an implementation of the OAuth 2.0 Device Flow (as
described at https://tools.ietf.org/html/draft-ietf-oauth-device-flow-01).

Please could the following points please be clarified:

Section 3.2: "The client requests an access token by making an HTTP "POST"
request to the token endpoint as described in Section 4.1.1 of [RFC6749]"

Should this actually say Section 4.1.3 of RFC6749 which is the Access Token
Request section for the authorisation code grant?

Assuming the above is true, should the `code` parameter POSTed to the
authorisation server  be the value of the `device_code` parameter returned
to the client in the initiating request?

Many thanks,

Alex Bilbie

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


<=
span style=3D"color:rgb(136,136,136);font-size:12.8px">--=C2=A0
Eduardo Gueiros
Director, Mobile B.U.=C2=A0| =C2=A0Jive Communica=
tions, Inc.
jive.com=C2=A0=C2=A0| =C2=A0eguei=
ros@jive.com
3D""



On Mon, Apr 11, 2016 at 2:18 PM, Anthony Nadalin <tonyna=
d@microsoft.com> wrote:











So now you are adding more requirements for encrypt=
ion ? The more this thread goes on shows how unstable and not fully thought=
 out this draft is to go through WG adoption.


<=
u>=C2=A0



From: OAuth [mailto:oauth-bounces@ietf.org]
On Behalf Of Brian Campbell

Sent: Monday, April 11, 2016 12:30 PM

To: Nat Sakimura <sakimura@gmail.com>

Cc: <oauth@ie=
tf.org> <oaut=
h@ietf.org>

Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for O=
Auth 2.0


=C2=A0




Sending a token type is not sufficient. There's =
more involved than the format. Many cases need to know if to encrypt and wh=
om to encrypt to.=C2=A0 What claims to put in the token (or reference by th=
e token). What algorithms and keys to use for
 signing/encryption. =C2=A0 












The statement that the "Current proposal does not support the implicit=
 flow" is incorrect. Among other things, sec 2 has, "When an acce=
ss token will be returned from the authorization endpoint, the "resour=
ce" parameter is used in the authorization request to
 the authorization endpoint as defined in Section 4.2.1 of OAuth 2.0 [RFC67=
49]."














=C2=A0




On Sun, Apr 10, 2016 at 11:43 AM, Nat Sakimura <<=
a href=3D"mailto:sakimura@gmail.com" target=3D"_blank">sakimura@gmail.com> wrote:






So, my understanding on the rationale/requirements f=
or having this spec right now is:=C2=A0




=C2=A0






R1. Authz server wants toprevent the replay by the s=
erver that received it.=C2=A0






R2. Authz server needs to mint the access token in a=
 variety of format depending on the resource server and to do that, you nee=
d to know which RS is gong to be receiving it.=C2=A0






=C2=A0






To achieve R1, there are couple of methods. The prop=
osed method here is to audience restrict the token, but the same can be ach=
ieved by sender constraining the token, e.g., by token binding. As far as I=
 can see, the sentiment of the WG
 seems to be to use the sender constraint through Token Binding, so from th=
is respect, this spec is not the one to do R1. Besides, the current proposa=
l only takes care of the code flow. The same requirement should be there fo=
r implicit flow as well, so the
 current proposal is not covering the R1 anyways.=C2=A0






=C2=A0






I can sort of understand R2, but I have two critique=
 on the current proposal:=C2=A0






=C2=A0






C1. Current proposal does not support the implicit f=
low. To support it, the resource URI has to be sent to the Authz endpoint i=
nstead of the Token endpoint.=C2=A0






C2. It is much more direct to send the required toke=
n format rather than the RS uri and probably better as:=C2=A0=







=C2=A0 1) There are use cases where the AS does not =
maintain the list of RSs that it supports, e.g., AOL.=C2=A0





=C2=A0 =C2=A0 =C2=A0 =C2=A0In such a case, even if t=
he RS uri were sent to the AS, the AS cannot mint the tokens in the appropr=
iate format.=C2=A0






=C2=A0 2) When it is sent in the Authz request, it i=
s leaking the information about the resource that the client is going to th=
e browser.=C2=A0






=C2=A0 3) There are use cases where it is desirable =
not to let the AS knows where the Client is going from the privacy point of=
 view.=C2=A0






=C2=A0






So, my suggestion is to drop R1 and concentrate on R=
2. And to solve R2, send token type instead of the resource indicator in th=
e request.=C2=A0






This also necessitates the Client to be able to find=
 out what token type the resource requires, perhaps in the unauthorized res=
ponse web link header at the resource in the manner of oauth-meta.=C2=A0=







=C2=A0






Cheers,=C2=A0






=C2=A0






Nat






=C2=A0






=C2=A0






=C2=A0






2016=E6=9C=
=888=E6=97=A5(=E9=87=91) 8:23=
 Prateek Mishra <Prateek.Mishra@oracle.com>:










While this work addresses a gap in the existing OAut=
h specification set, I am very concerned that this

incremental extension will lead to even more confusion around the areas of =
=E2=80=9Cscope=E2=80=9D, =E2=80=9Caudience=E2=80=9D and =E2=80=9Cresource s=
erver=E2=80=9D.



I think we should try to solve this problem via=C2=A0 a framework that prov=
ides better guidance and implementation

models for OAuth use-cases. In other words, I feel that a broader discussio=
n is needed here.





> On Apr 7, 2016, at 4:11 PM, Justin Richer <jricher@mit.edu> wrote:

>

> I support adoption of this document as a starting point for working gr=
oup work.

>

> =E2=80=94 Justin

>

>

>> On Apr 6, 2016, at 1:25 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

>>

>> Hi all,

>>

>> this is the call for adoption of 'Resource Indicators for OAut=
h 2.0', see

>> 
http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/

>>

>> Please let us know by April 20th whether you accept / object to th=
e

>> adoption of this document as a starting point for work in the OAut=
h

>> working group.

>>

>> Note: If you already stated your opinion at the IETF meeting in Bu=
enos

>> Aires then you don't need to re-state your opinion, if you wan=
t.

>>

>> The feedback at the BA IETF meeting was the following: ~10 persons=


>> for accepting the document and 0 persons against.

>>

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







=C2=A0










=

N.B: I sent the following email to=C2=A0<=
a href=3D"mailto:draft-ietf-oauth-device-flow@tools.ietf.org">draft-ietf-oa=
uth-device-flow@tools.ietf.org=C2=A0on 12th April but didn't receiv=
e a=C2=A0reply so am reposting here:

---

Hello,

I've been working on an implementation=
 of the OAuth 2.0 Device Flow (as described at=C2=A0https://=
tools.ietf.org/html/draft-ietf-oauth-device-flow-01).

Please coul=
d the following points please be clarified:

Section 3.2: "The client r=
equests an access token by making an HTTP "POST" request to the t=
oken endpoint as described in Section 4.1.1 of [RFC6749]"

Should this =
actually say Section 4.1.3 of RFC6749 which is the Access Token Request sec=
tion for the authorisation code grant?
<=
br>
Assuming the above is true, should t=
he `code` parameter POSTed to the authorisation server =C2=A0be the value o=
f the `device_code` parameter returned to the client in the initiating requ=
est?

Many thanks,

Alex Bilbie



--001a11348416629e1005308963be--


From nobody Fri Apr 15 11:24:24 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E80112D5E3 for ; Fri, 15 Apr 2016 11:24:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.013
X-Spam-Level: 
X-Spam-Status: No, score=-0.013 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5RBkcnJDuW4 for ; Fri, 15 Apr 2016 11:24:21 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0101.outbound.protection.outlook.com [65.55.169.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6225112D0C5 for ; Fri, 15 Apr 2016 11:24:20 -0700 (PDT)
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=mbootRPul8qC/vjXnN9+HlmaEgMoT5ep4ncm5h3TOQY=; b=kSDuGHzAER9R0gjVhd6fuHJ8Hb/+Jlzhtlv0imk7e0LW6AT7tbE2Mgf4JphT8NlbQrraKya9CQDLWNy/j5wT74W7LtZlgKDUeB0jJJZyiCfEQcOCuUZaIn1wE1ykqF1n5AjnScM7p6nHRkFxSzwmuOAX9PPGJBUL1pjUaU/u4zE=
Received: from CY1PR0301MB0857.namprd03.prod.outlook.com (10.160.163.151) by CY1PR0301MB0860.namprd03.prod.outlook.com (10.160.163.155) with Microsoft SMTP Server (TLS) id 15.1.453.26; Fri, 15 Apr 2016 18:24:18 +0000
Received: from CY1PR0301MB0857.namprd03.prod.outlook.com ([10.160.163.151]) by CY1PR0301MB0857.namprd03.prod.outlook.com ([10.160.163.151]) with mapi id 15.01.0453.030; Fri, 15 Apr 2016 18:24:19 +0000
From: Oli Dagenais 
To: Alex Bilbie , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Device flow clarifications
Thread-Index: AQHRlzy9C5WwbuqFsESbKU94+UnxHp+LVkGQ
Date: Fri, 15 Apr 2016 18:24:18 +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: alexbilbie.com; dkim=none (message not signed) header.d=none;alexbilbie.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [216.58.27.239]
x-ms-office365-filtering-correlation-id: 25fe9c56-1b79-4859-a788-08d3655b28ce
x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0860; 5:AaBzQSHgXi4ekRxo6FfBSzOLOlM6h38C3P3VhVvWwT4HzQ9RDz7ZDcVc88PPBFMm8ea+g7pZcC3GQnDOupF1CKP++5147TvT/Q302uVwoPzd0WqRwJ91UpXheF3buI5I6lG8Ma/H9+qZwcE2yAdMgw==; 24:us+LmTk6aDZQyYYrFjwEvE38B+KOWz7QhiPWNL0GreXJ8dYOx8LvTV2xtKApwQ3BWtbhdEZf62x9p9MtMnwWL0ytCdYTZ6Y//P4bOhrrxog=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0860;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0860; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0860; 
x-forefront-prvs: 0913EA1D60
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(66066001)(3660700001)(5004730100002)(19617315012)(77096005)(5005710100001)(10400500002)(92566002)(74316001)(19580405001)(3280700002)(19580395003)(189998001)(16236675004)(19625215002)(33656002)(107886002)(86362001)(87936001)(2900100001)(106116001)(586003)(19300405004)(2906002)(790700001)(102836003)(6116002)(3846002)(5002640100001)(1096002)(15975445007)(19609705001)(5003600100002)(5008740100001)(9686002)(10090500001)(1220700001)(76576001)(122556002)(2950100001)(99286002)(81166005)(86612001)(54356999)(50986999)(8990500004)(76176999)(5001770100001)(10290500002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0860; H:CY1PR0301MB0857.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB085734F6AED2C06D11249B10B1680CY1PR0301MB0857_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2016 18:24:18.7151 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0860
Archived-At: 
Subject: Re: [OAUTH-WG] Device flow clarifications
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Apr 2016 18:24:23 -0000

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

SGkgQWxleCwNCg0KSeKAmW0gYWxzbyB3b3JraW5nIG9uIGFuIGltcGxlbWVudGF0aW9uIGJhc2Vk
IG9uIHRoZSBkcmFmdCBzcGVjaWZpY2F0aW9uLiBJIGNhbWUgdG8gdGhlIHNhbWUgY29uY2x1c2lv
biBhYm91dCBsaW5raW5nIHRvIFNlY3Rpb24gNC4xLjMgb2YgUkZDNjc0OS4NCg0KQXMgZm9yIHlv
dXIgc2Vjb25kIHF1ZXN0aW9uLCBJIGFsc28gY2FtZSB0byB0aGUgc2FtZSBjb25jbHVzaW9uLCB3
aGljaCB3YXMgY29uZmlybWVkIGJ5IGxvb2tpbmcgYXQgdGhlIHNvdXJjZSBjb2RlIHRvIHRoZSBB
Y3RpdmUgRGlyZWN0b3J5IEF1dGhlbnRpY2F0aW9uIExpYnJhcnkgKEFEQUwpIGZvciAuTkVUIChB
enVyZSBBY3RpdmUgRGlyZWN0b3J5IGlzIG15IHByb2plY3TigJlzIGZpcnN0IHRhcmdldCkuIEFE
QUwgYWxzbyBzZXRzIHRoZSBncmFudF90eXBlIHBhcmFtZXRlciB0byDigJxkZXZpY2VfY29kZeKA
nSAoY29udHJhc3QgdGhpcyB3aXRoIHRoZSB2YWx1ZSBvcmlnaW5hbGx5IGluIHNlY3Rpb24gNC4x
LjMpLg0KDQpJIGFtIGhvcGluZyB0byBhbHNvIHRlc3QgbXkgaW1wbGVtZW50YXRpb24gYWdhaW5z
dCBvdGhlciBtYWpvciBzZXJ2ZXIgaW1wbGVtZW50YXRpb25zIChHb29nbGUgYW5kIEZhY2Vib29r
IGNvbWUgdG8gbWluZCkgaW4gdGhlIG5leHQgZmV3IHdlZWtzIGFuZCB3aWxsIHJlcG9ydCBteSBm
aW5kaW5ncyB0byB0aGlzIG1haWxpbmcgbGlzdC4NCg0KQ2hlZXJzLA0KLSBPbGkNCg0KLS0NCkxl
dCBtZSBoZWxwIHlvdSBiZSBhd2Vzb21lIGF0IHdoYXQgeW91IGRvLCB1c2luZw0KTWljcm9zb2Z0
IERldmVsb3BlciBUb29scw0KKzEgNjEzLTIxMi01NTUxDQoNCkZyb206IE9BdXRoIFttYWlsdG86
b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFsZXggQmlsYmllDQpTZW50OiBG
cmlkYXksIEFwcmlsIDE1LCAyMDE2IDEzOjMyDQpUbzogb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6
IFtPQVVUSC1XR10gRGV2aWNlIGZsb3cgY2xhcmlmaWNhdGlvbnMNCg0KTi5COiBJIHNlbnQgdGhl
IGZvbGxvd2luZyBlbWFpbCB0byBkcmFmdC1pZXRmLW9hdXRoLWRldmljZS1mbG93QHRvb2xzLmll
dGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW9hdXRoLWRldmljZS1mbG93QHRvb2xzLmlldGYub3Jn
PiBvbiAxMnRoIEFwcmlsIGJ1dCBkaWRuJ3QgcmVjZWl2ZSBhIHJlcGx5IHNvIGFtIHJlcG9zdGlu
ZyBoZXJlOg0KDQotLS0NCg0KSGVsbG8sDQoNCkkndmUgYmVlbiB3b3JraW5nIG9uIGFuIGltcGxl
bWVudGF0aW9uIG9mIHRoZSBPQXV0aCAyLjAgRGV2aWNlIEZsb3cgKGFzIGRlc2NyaWJlZCBhdCBo
dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1kZXZpY2UtZmxvdy0w
MTxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw
cyUzYSUyZiUyZnRvb2xzLmlldGYub3JnJTJmaHRtbCUyZmRyYWZ0LWlldGYtb2F1dGgtZGV2aWNl
LWZsb3ctMDEmZGF0YT0wMSU3YzAxJTdjb2xpdmlkYSU0MG1pY3Jvc29mdC5jb20lN2MxY2YwMTY0
ZTE1OTg0Yjk2ZDZhZDA4ZDM2NTUzZGU1ZSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFk
YjQ3JTdjMSZzZGF0YT1BdzZoSWRyQWVYNSUyZmVleGxiUGRaWmlPWU5kRDZFVEJQMmJ3blZwQXVC
SVklM2Q+KS4NCg0KUGxlYXNlIGNvdWxkIHRoZSBmb2xsb3dpbmcgcG9pbnRzIHBsZWFzZSBiZSBj
bGFyaWZpZWQ6DQoNClNlY3Rpb24gMy4yOiAiVGhlIGNsaWVudCByZXF1ZXN0cyBhbiBhY2Nlc3Mg
dG9rZW4gYnkgbWFraW5nIGFuIEhUVFAgIlBPU1QiIHJlcXVlc3QgdG8gdGhlIHRva2VuIGVuZHBv
aW50IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuMS4xIG9mIFtSRkM2NzQ5XSINCg0KU2hvdWxk
IHRoaXMgYWN0dWFsbHkgc2F5IFNlY3Rpb24gNC4xLjMgb2YgUkZDNjc0OSB3aGljaCBpcyB0aGUg
QWNjZXNzIFRva2VuIFJlcXVlc3Qgc2VjdGlvbiBmb3IgdGhlIGF1dGhvcmlzYXRpb24gY29kZSBn
cmFudD8NCg0KQXNzdW1pbmcgdGhlIGFib3ZlIGlzIHRydWUsIHNob3VsZCB0aGUgYGNvZGVgIHBh
cmFtZXRlciBQT1NUZWQgdG8gdGhlIGF1dGhvcmlzYXRpb24gc2VydmVyICBiZSB0aGUgdmFsdWUg
b2YgdGhlIGBkZXZpY2VfY29kZWAgcGFyYW1ldGVyIHJldHVybmVkIHRvIHRoZSBjbGllbnQgaW4g
dGhlIGluaXRpYXRpbmcgcmVxdWVzdD8NCg0KTWFueSB0aGFua3MsDQoNCkFsZXggQmlsYmllDQoN
Cg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEg
NiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg
bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv
bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS
b21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp
b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6
dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6
OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29u
b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt
c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN
Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z
aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFu
LkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh
bWlseToiVmVyZGFuYSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2Vp
Z2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBu
b25lO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBw
YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w
aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9
DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2
OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg
Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg
djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd
LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs
ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEg
bmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVy
ZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5IaSBBbGV4LDxvOnA+PC9vOnA+PC9zcGFuPjwvYT48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5k
Q29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fu
cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5J4oCZ
bSBhbHNvIHdvcmtpbmcgb24gYW4gaW1wbGVtZW50YXRpb24gYmFzZWQgb24gdGhlIGRyYWZ0IHNw
ZWNpZmljYXRpb24uIEkgY2FtZSB0byB0aGUgc2FtZSBjb25jbHVzaW9uIGFib3V0IGxpbmtpbmcg
dG8gU2VjdGlvbiA0LjEuMyBvZiBSRkM2NzQ5LjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5k
Q29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fu
cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5BcyBm
b3IgeW91ciBzZWNvbmQgcXVlc3Rpb24sIEkgYWxzbyBjYW1lIHRvIHRoZSBzYW1lIGNvbmNsdXNp
b24sIHdoaWNoIHdhcyBjb25maXJtZWQgYnkgbG9va2luZyBhdCB0aGUgc291cmNlIGNvZGUgdG8g
dGhlIEFjdGl2ZSBEaXJlY3RvcnkgQXV0aGVudGljYXRpb24NCiBMaWJyYXJ5IChBREFMKSBmb3Ig
Lk5FVCAoQXp1cmUgQWN0aXZlIERpcmVjdG9yeSBpcyBteSBwcm9qZWN04oCZcyBmaXJzdCB0YXJn
ZXQpLiBBREFMIGFsc28gc2V0cyB0aGUgZ3JhbnRfdHlwZSBwYXJhbWV0ZXIgdG8g4oCcZGV2aWNl
X2NvZGXigJ0gKGNvbnRyYXN0IHRoaXMgd2l0aCB0aGUgdmFsdWUgb3JpZ2luYWxseSBpbiBzZWN0
aW9uIDQuMS4zKS48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SSBhbSBob3Bp
bmcgdG8gYWxzbyB0ZXN0IG15IGltcGxlbWVudGF0aW9uIGFnYWluc3Qgb3RoZXIgbWFqb3Igc2Vy
dmVyIGltcGxlbWVudGF0aW9ucyAoR29vZ2xlIGFuZCBGYWNlYm9vayBjb21lIHRvIG1pbmQpIGlu
IHRoZSBuZXh0IGZldw0KIHdlZWtzIGFuZCB3aWxsIHJlcG9ydCBteSBmaW5kaW5ncyB0byB0aGlz
IG1haWxpbmcgbGlzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi
bGFjayI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi
bGFjayI+LSBPbGk8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh
Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj
ayI+LS0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+
TGV0IG1lIGhlbHAgeW91IGJlIGF3ZXNvbWUgYXQgd2hhdCB5b3UgZG8sIHVzaW5nPG86cD48L286
cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt
c28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1
b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5NaWNyb3NvZnQgRGV2ZWxv
cGVyIFRvb2xzPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr
Ij4mIzQzOzEgNjEzLTIxMi01NTUxPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3Nl
Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlm
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHNwYW4gc3R5bGU9Im1zby1i
b29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE9BdXRo
IFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QWxl
eCBCaWxiaWU8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBBcHJpbCAxNSwgMjAxNiAxMzozMjxi
cj4NCjxiPlRvOjwvYj4gb2F1dGhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW09BVVRI
LVdHXSBEZXZpY2UgZmxvdyBjbGFyaWZpY2F0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpi
bGFjayI+Ti5COiBJIHNlbnQgdGhlIGZvbGxvd2luZyBlbWFpbCB0byZuYnNwOzxhIGhyZWY9Im1h
aWx0bzpkcmFmdC1pZXRmLW9hdXRoLWRldmljZS1mbG93QHRvb2xzLmlldGYub3JnIj5kcmFmdC1p
ZXRmLW9hdXRoLWRldmljZS1mbG93QHRvb2xzLmlldGYub3JnPC9hPiZuYnNwO29uIDEydGggQXBy
aWwgYnV0IGRpZG4ndCByZWNlaXZlIGEmbmJzcDs8L3NwYW4+cmVwbHkgc28NCiBhbSByZXBvc3Rp
bmcgaGVyZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+LS0tPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdCI+SGVsbG8sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkkndmUgYmVlbiB3b3JraW5nIG9uIGFu
IGltcGxlbWVudGF0aW9uIG9mIHRoZSBPQXV0aCAyLjAgRGV2aWNlIEZsb3cgKGFzIGRlc2NyaWJl
ZCBhdCZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs
b29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmdG9vbHMuaWV0Zi5vcmclMmZodG1sJTJmZHJhZnQt
aWV0Zi1vYXV0aC1kZXZpY2UtZmxvdy0wMSZhbXA7ZGF0YT0wMSU3YzAxJTdjb2xpdmlkYSU0MG1p
Y3Jvc29mdC5jb20lN2MxY2YwMTY0ZTE1OTg0Yjk2ZDZhZDA4ZDM2NTUzZGU1ZSU3YzcyZjk4OGJm
ODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9QXc2aElkckFlWDUlMmZlZXhs
YlBkWlppT1lOZEQ2RVRCUDJid25WcEF1QklZJTNkIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90
b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtZGV2aWNlLWZsb3ctMDE8L2E+KS48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+UGxlYXNlIGNvdWxkIHRoZSBmb2xsb3dpbmcgcG9pbnRz
IHBsZWFzZSBiZSBjbGFyaWZpZWQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5TZWN0aW9uIDMuMjogJnF1b3Q7
VGhlIGNsaWVudCByZXF1ZXN0cyBhbiBhY2Nlc3MgdG9rZW4gYnkgbWFraW5nIGFuIEhUVFAgJnF1
b3Q7UE9TVCZxdW90OyByZXF1ZXN0IHRvIHRoZSB0b2tlbiBlbmRwb2ludCBhcyBkZXNjcmliZWQg
aW4gU2VjdGlvbiA0LjEuMSBvZiBbUkZDNjc0OV0mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlNob3Vs
ZCB0aGlzIGFjdHVhbGx5IHNheSBTZWN0aW9uIDQuMS4zIG9mIFJGQzY3NDkgd2hpY2ggaXMgdGhl
IEFjY2VzcyBUb2tlbiBSZXF1ZXN0IHNlY3Rpb24gZm9yIHRoZSBhdXRob3Jpc2F0aW9uIGNvZGUg
Z3JhbnQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0Ij5Bc3N1bWluZyB0aGUgYWJvdmUgaXMgdHJ1ZSwgc2hvdWxk
IHRoZSBgY29kZWAgcGFyYW1ldGVyIFBPU1RlZCB0byB0aGUgYXV0aG9yaXNhdGlvbiBzZXJ2ZXIg
Jm5ic3A7YmUgdGhlIHZhbHVlIG9mIHRoZSBgZGV2aWNlX2NvZGVgIHBhcmFtZXRlciByZXR1cm5l
ZCB0byB0aGUgY2xpZW50IGluIHRoZSBpbml0aWF0aW5nIHJlcXVlc3Q/PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
Ij5NYW55IHRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkFsZXggQmlsYmllPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_CY1PR0301MB085734F6AED2C06D11249B10B1680CY1PR0301MB0857_--


From nobody Fri Apr 15 15:42:55 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E21F12E0E9 for ; Fri, 15 Apr 2016 15:42:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.611
X-Spam-Level: 
X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUP34p2ZYj6Y for ; Fri, 15 Apr 2016 15:42:52 -0700 (PDT)
Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::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 1AC4D12DFDB for ; Fri, 15 Apr 2016 15:42:52 -0700 (PDT)
Received: by mail-pf0-x22c.google.com with SMTP id e128so60702304pfe.3 for ; Fri, 15 Apr 2016 15:42:52 -0700 (PDT)
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; bh=teTWW+4eiWDVkpXU077jdUAWAjDUzzFada5V2QKG4j8=; b=flDizrKnkzkMBOj7I5yWkQ+s/2Q4NmkHh53DdwR0TSF3+3R64J+mMba7Y8QriLOojO YvTaTubHMckhD83tUjGbsXcktRBjRgobRTg7gpjqISzDD+JgyAJDF9HFvauCnV9c6xK3 +wQIoKM5wGJWRcG15HjHIq2wgD5y6yHlRqS0I8po/q5Flhh/fwC0ZhojI/Dk8i6dIQPL nWZtAWG0PzMevn97SzMkDx7O/eNadaWXE1kOgdd8JNJLg4bqPt5wo7aNdDft0OSsCsGG zoujZ4GpG9hjlo+QkEKadc3GDfcG6xTwIl00SPiZTe0M08DEUZWl9bldIsbMUUJOv/CB fuGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=teTWW+4eiWDVkpXU077jdUAWAjDUzzFada5V2QKG4j8=; b=PdmeWe0keU7axDM7kAlu8v0wPIFDOJdTHR8QnjXK/BPQqTFMbkAUDlcw/vF5kN5xFu HD0qBiYveMcj6HNcyMy32gmWNJIz8ZOC5RQ5dxK4qERZce3XhVeVHpFKEhx1HLz2vSOq 2fnuqPbX55jL9CEbZiEwC+UUIBzlnPuSj08DGY07t8T9ZPofcaTS4pW8q5FdBD47fJak hGpXQufBHUrCNp8/Ust4bVUYDhvaNf/cDiT4la3mA3224KM1WUX+X/wq8rEp+dHQv8XQ 1PFtzPfENtl4fR0JlaDJdej/5Iwaa7T8KOG3yjIEKCoSDKIItzmvddHwsw/R965GoZD8 xpnQ==
X-Gm-Message-State: AOPr4FUUf3FJtHN0snHpT2GDBg9BP/NQDW6QceA9DCyHTwJrJFyUzS6lBx2anLSfOmWSSw==
X-Received: by 10.98.40.200 with SMTP id o191mr32889214pfo.83.1460760171677; Fri, 15 Apr 2016 15:42:51 -0700 (PDT)
Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com. [209.85.220.51]) by smtp.gmail.com with ESMTPSA id s64sm66945290pfi.77.2016.04.15.15.42.50 for  (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Apr 2016 15:42:50 -0700 (PDT)
Received: by mail-pa0-f51.google.com with SMTP id zm5so59275566pac.0 for ; Fri, 15 Apr 2016 15:42:50 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.67.21.167 with SMTP id hl7mr32556903pad.16.1460760170101; Fri, 15 Apr 2016 15:42:50 -0700 (PDT)
Received: by 10.66.168.206 with HTTP; Fri, 15 Apr 2016 15:42:50 -0700 (PDT)
In-Reply-To: 
References:  
Date: Sat, 16 Apr 2016 00:42:50 +0200
X-Gmail-Original-Message-ID: 
Message-ID: 
From: Aaron Parecki 
To: Oli Dagenais 
Content-Type: multipart/alternative; boundary=001a1133165a0a872005308dbbfd
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Device flow clarifications
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Apr 2016 22:42:54 -0000

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

Hi Alex and Oli,

I also believe you are correct. I posted a similar question a while ago
here:

https://www.ietf.org/mail-archive/web/oauth/current/msg15139.html

I had a couple other notes you may be interested in:

https://www.ietf.org/mail-archive/web/oauth/current/msg15138.html

My implementation of a server that implements the device flow is here,
although it actually acts as a proxy for existing OAuth services:

https://github.com/aaronpk/TVAuthServer

Cheers!

----
Aaron Parecki
aaronparecki.com
@aaronpk 


On Fri, Apr 15, 2016 at 8:24 PM, Oli Dagenais  wrote=
:

> Hi Alex,
>
>
>
> I=E2=80=99m also working on an implementation based on the draft specific=
ation. I
> came to the same conclusion about linking to Section 4.1.3 of RFC6749.
>
>
>
> As for your second question, I also came to the same conclusion, which wa=
s
> confirmed by looking at the source code to the Active Directory
> Authentication Library (ADAL) for .NET (Azure Active Directory is my
> project=E2=80=99s first target). ADAL also sets the grant_type parameter =
to
> =E2=80=9Cdevice_code=E2=80=9D (contrast this with the value originally in=
 section 4.1.3).
>
>
>
> I am hoping to also test my implementation against other major server
> implementations (Google and Facebook come to mind) in the next few weeks
> and will report my findings to this mailing list.
>
>
>
> Cheers,
>
> - Oli
>
>
>
> --
>
> Let me help you be awesome at what you do, using
>
> Microsoft Developer Tools
>
> +1 613-212-5551
>
>
>
> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Alex Bilbie
> *Sent:* Friday, April 15, 2016 13:32
> *To:* oauth@ietf.org
> *Subject:* [OAUTH-WG] Device flow clarifications
>
>
>
> N.B: I sent the following email to
> draft-ietf-oauth-device-flow@tools.ietf.org on 12th April but didn't
> receive a reply so am reposting here:
>
>
>
> ---
>
>
>
> Hello,
>
>
>
> I've been working on an implementation of the OAuth 2.0 Device Flow (as
> described at https://tools.ietf.org/html/draft-ietf-oauth-device-flow-01
> 
> ).
>
>
>
> Please could the following points please be clarified:
>
>
>
> Section 3.2: "The client requests an access token by making an HTTP "POST=
"
> request to the token endpoint as described in Section 4.1.1 of [RFC6749]"
>
>
>
> Should this actually say Section 4.1.3 of RFC6749 which is the Access
> Token Request section for the authorisation code grant?
>
>
>
> Assuming the above is true, should the `code` parameter POSTed to the
> authorisation server  be the value of the `device_code` parameter returne=
d
> to the client in the initiating request?
>
>
>
> Many thanks,
>
>
>
> Alex Bilbie
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

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


Hi Alex and Oli,

I also believe you are=
 correct. I posted a similar question a while ago here:

=

----
Aaron Parecki

=



On Fri, Apr 15, 2016 at 8:24 PM, Oli Dagenai=
s <olivida@microsoft.com> wrote:











Hi Alex,=



=C2=A0


I=E2=80=99m also working on an implementation based on the dra=
ft specification. I came to the same conclusion about linking to Section 4.=
1.3 of RFC6749.


=C2=A0


As for your second question, I also came to the same conclusio=
n, which was confirmed by looking at the source code to the Active Director=
y Authentication
 Library (ADAL) for .NET (Azure Active Directory is my project=E2=80=99s fi=
rst target). ADAL also sets the grant_type parameter to =E2=80=9Cdevice_cod=
e=E2=80=9D (contrast this with the value originally in section 4.1.3).


=C2=A0


I am hoping to also test my implementation against=
 other major server implementations (Google and Facebook come to mind) in t=
he next few
 weeks and will report my findings to this mailing list.


=C2=A0


Cheers,


- Oli


=C2=A0


--



Let me help you be awesome at what you do, using


Microsoft Developer Tools


+1 613-212-5551<=
/p>

=C2=A0



From: OAuth [mailto:oauth-bounces@ietf.org]
On Behalf Of Alex Bilbie

Sent: Friday, April 15, 2016 13:32

To: oauth@ietf.o=
rg

Subject: [OAUTH-WG] Device flow clarifications<=
/p>


=C2=A0






N.B: I =
sent the following email to=C2=A0draft-ietf-oauth-device-flow@tools.i=
etf.org=C2=A0on 12th April but didn't receive a=C2=A0reply s=
o
 am reposting here:






=C2=A0






---






=C2=A0




Hello,






=C2=A0






I've been worki=
ng on an implementation of the OAuth 2.0 Device Flow (as described at=C2=A0=
https://tools.ietf.org/html/draft-ietf-oau=
th-device-flow-01).








=C2=A0






Please could the fo=
llowing points please be clarified:






=C2=A0






Section 3.2: "=
The client requests an access token by making an HTTP "POST" requ=
est to the token endpoint as described in Section 4.1.1 of [RFC6749]"<=
u>






=C2=A0






Should this actuall=
y say Section 4.1.3 of RFC6749 which is the Access Token Request section fo=
r the authorisation code grant?






=C2=A0






Assuming the above =
is true, should the `code` parameter POSTed to the authorisation server =C2=
=A0be the value of the `device_code` parameter returned to the client in th=
e initiating request?






=C2=A0






Many thanks,=







=C2=A0






Alex Bilbie<=
u>




=C2=A0









_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





--001a1133165a0a872005308dbbfd--


From nobody Sat Apr 16 15:42:34 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA94112DB62 for ; Sat, 16 Apr 2016 15:42:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKtqGgvNZ6EJ for ; Sat, 16 Apr 2016 15:42:29 -0700 (PDT)
Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c: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 902A712DB32 for ; Sat, 16 Apr 2016 15:42:29 -0700 (PDT)
Received: by mail-vk0-x233.google.com with SMTP id c4so184582785vkb.3 for ; Sat, 16 Apr 2016 15:42:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=AtR6g9z2HKHdMZ4VArR8YChbh2H3g8+/L58ACqLKPec=; b=BHcsYyaTMosCfIa/WW39pQoqX17a5B0A+roBGAXpJhznDyS+7nYkgpjTYNsHW8H1J+ iDIRfywAYXE+S2zdPbE15cDnkeAHvABFhxKlMXaBAEqKBmehcbQepNyPxASmpLCwWWPd i1XTAcMhdDfdQ2pKM90sagnNR+2+JiuoITRE2dZgCgPW/eaVqJ1vSCRna2tbM96hqRIW oeVdrVp2TWOGLdUPctOAwbrBr6b/lhNN9TebS1Z9km/It5/tgd6pj9ltHC4C8SNxzqtu 8o2g0F6a0UXvSVr3C7YflvueqhZI4JN9gVVL/9PXO6lWQrleb7OTxXdnpOtVKZFNFWAz 96FQ==
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; bh=AtR6g9z2HKHdMZ4VArR8YChbh2H3g8+/L58ACqLKPec=; b=gbBrtn3GJgx2dUV+4+ofrGejowWeZyQeR7XsHERYTNJRKGoHccBn22np4CFO3A+vj1 vv3H7Djg+UpkhNUPGUuCWExQIvHmLyDGKkN7XH601ZpCD1dxSySKD0J411LiyCxet4YD Vh54D88Q370ehoizAwTcNXjGb1Hhs1b6e+VRfBuPJMr1XSwYw6PCEoEFxv2hNkk9OMfE Wp1XG2r+i82N2kW9QloaP7JLIQYPMARRPvdqxYm0vXWgG9ZWgcOVc5ra0d06T2BjxRSN 4XExgzk4cm25IbEBIBwWcJKuMwTL73GtfHnX3/XUm4vX2c6G81bJlAYvuHqWl0faqLEA aJYw==
X-Gm-Message-State: AOPr4FWOiI1R7KL8QIEO5mqCU7DChQDXeA13sGzKMBuiNJm6QzMfNY1zGIVO93FwB4PzHVg2l75yA84ogqt0Cw==
MIME-Version: 1.0
X-Received: by 10.159.36.143 with SMTP id 15mr4195160uar.136.1460846548209; Sat, 16 Apr 2016 15:42:28 -0700 (PDT)
Received: by 10.176.1.182 with HTTP; Sat, 16 Apr 2016 15:42:28 -0700 (PDT)
Date: Sun, 17 Apr 2016 00:42:28 +0200
Message-ID: 
From: Samuel Erdtman 
To: "" , Ace@ietf.org
Content-Type: multipart/alternative; boundary=001a113df51693ea670530a1d754
Archived-At: 
Subject: [OAUTH-WG] PoP, Introspection and ACE
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Apr 2016 22:42:32 -0000

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

Hi,

I'm working on the IANA section in
https://tools.ietf.org/html/draft-ietf-ace-oauth-authz.

In https://tools.ietf.org/html/draft-ietf-ace-oauth-authz we want to have
the option to get the PoP parameters (alg, key and aud) via introspection
e.g. if using a reference token.

At the moment I wrote the registration text of the parameters in the ACE
specification but I think it would be preferable if
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution did the
registration for introspection too.

Comments?

//Samuel

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


Hi,

I'm working on th=
e IANA section in https://tools.ietf.org/html/draft-ietf-ace-oauth-authz.
In https://tools.ietf.org/html/draft-ietf-ace-oauth-authz we want to ha=
ve the option to get the PoP parameters (alg, key and aud) via introspectio=
n e.g. if using a reference token.

At the moment I wrote the r=
egistration text of the parameters in the ACE specification but I think it =
would be preferable if https://tools.ietf.org/html/draft-ietf-oauth-pop-=
key-distribution did the registration for introspection too.

Comments?

//Samuel


--001a113df51693ea670530a1d754--


From nobody Sat Apr 16 16:23:25 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD9E12E110 for ; Sat, 16 Apr 2016 16:23:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLJsK8f4dKIS for ; Sat, 16 Apr 2016 16:23:22 -0700 (PDT)
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 8BE7012E10C for ; Sat, 16 Apr 2016 16:23:22 -0700 (PDT)
Received: by mail-qg0-x232.google.com with SMTP id f105so99568100qge.2 for ; Sat, 16 Apr 2016 16:23:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=75Dc61EZJiztZUO1Fd7yGrMjSEjJ/V3CMIDj4XjE4YM=; b=dFGo27kDZB2NMLtp4MTJ9HO6QG6m8acopJ3zkM2/pT9iAet/JaBO9/92pXgoVqKVUe 6zZKZk6ES0zNcTbFyTW6fyj6PT2P/O/p3D2HKQJJpNpr/q/RBpzE1lupegrqkYnInDE3 rSeKdw9IOpTNCpEjqHkC2S3r3i5LgJ5MJTbYeLOiLAU7BSLirKBy7McecBFJLklePv49 LkZBVBoI8q333j5+CBGRfRNA4FlNJNa63GrcBGPN/zsRwvNgc8/shC1M3ZcV2Tz6leIv cz/ic97T9NvcePC5LNE9p1PG7YQhTDmBK/Mn/fhwxRxH/rpBo/TGXzA3DTAr9ljuJqEM crIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=75Dc61EZJiztZUO1Fd7yGrMjSEjJ/V3CMIDj4XjE4YM=; b=XJaUilHTqQDfzW8JDGGOPpTiVy86ALlfuiy3pO/EDvxeEJYXbNE9Fi1AbY3OOpsmp4 Ef+Fl+8IiUaOfgsedEs8rzgAjstHEwZsIPDi9ghS570pk/uYmL9r4AV4xmwHwFgs4Rzm P5VqQWKnjx4OcETq4ADlQGK+a1L5cd05s144qlc9UqEsjT6mJ4EFSIGBD4BHuIiNSW4P YTDvDT0CrRYWp4nDlfsIRvA35Yqrin4Al/KfMvj7dqiUC9D5iKi9DKF7v0LMpaA+W87J 7ybgVSd144i/fi0sTosdRdcJASO8J834nQYhwFytHGK/FUg7Q8iGofPcAlGqZ+ap/g0a qLIw==
X-Gm-Message-State: AOPr4FX4EzZC1b7HxXbnNx7STyx7yz8xnAUQga5oAtGwuBo036odHJejiuvIRvi15BqMZA==
X-Received: by 10.140.142.144 with SMTP id 138mr35853165qho.84.1460849001568;  Sat, 16 Apr 2016 16:23:21 -0700 (PDT)
Received: from [192.168.9.7] (ip-64-134-65-170.public.wayport.net. [64.134.65.170]) by smtp.gmail.com with ESMTPSA id y129sm23512490qka.33.2016.04.16.16.23.20 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 16 Apr 2016 16:23:20 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_543DE61F-F594-47B1-BD76-D789B466C3E4"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: John Bradley 
In-Reply-To: 
Date: Sat, 16 Apr 2016 19:23:19 -0400
Message-Id: 
References: 
To: Samuel Erdtman 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "" , Ace@ietf.org
Subject: Re: [OAUTH-WG] [Ace] PoP, Introspection and ACE
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Apr 2016 23:23:24 -0000

--Apple-Mail=_543DE61F-F594-47B1-BD76-D789B466C3E4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

It is probably best to register =E2=80=9Ccnf=E2=80=9D to match RFC 7600 =
so we don=E2=80=99t have two different structures one for JWT/CWT and =
one for introspection.

On the other hand introspected tokens are generally relatively custom in =
what claims they pass.

I will discuss it with Hannes.

John B.
> On Apr 16, 2016, at 6:42 PM, Samuel Erdtman  wrote:
>=20
> Hi,
>=20
> I'm working on the IANA section in =
https://tools.ietf.org/html/draft-ietf-ace-oauth-authz =
.
>=20
> In https://tools.ietf.org/html/draft-ietf-ace-oauth-authz =
 we want to have =
the option to get the PoP parameters (alg, key and aud) via =
introspection e.g. if using a reference token.
>=20
> At the moment I wrote the registration text of the parameters in the =
ACE specification but I think it would be preferable if =
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution =
 did =
the registration for introspection too.
>=20
> Comments?
>=20
> //Samuel
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace


--Apple-Mail=_543DE61F-F594-47B1-BD76-D789B466C3E4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

It is probably best to register =E2=80=9Ccnf=E2=80=9D to =
match RFC 7600 so we don=E2=80=99t have two different structures one for =
JWT/CWT and one for introspection.

On the other hand introspected tokens =
are generally relatively custom in what claims they pass.

I will discuss it with =
Hannes.

John =
B.
On Apr 16, 2016, at 6:42 PM, Samuel Erdtman <samuel@erdtman.se> =
wrote:

Hi,

I'm =
working on the IANA section in https://tools.ietf.org/html/draft-ietf-ace-oauth-authz.

In https://tools.ietf.org/html/draft-ietf-ace-oauth-authz we =
want to have the option to get the PoP parameters (alg, key and aud) via =
introspection e.g. if using a reference token.

At the moment I wrote the registration text of the =
parameters in the ACE specification but I think it would be preferable =
if https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distributi=
on did the registration for introspection too.

Comments?

//Samuel

_______________________________________________
Ace =
mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

=

--Apple-Mail=_543DE61F-F594-47B1-BD76-D789B466C3E4--


From nobody Sun Apr 17 01:46:18 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA93B12DA05 for ; Sun, 17 Apr 2016 01:46:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.622
X-Spam-Level: 
X-Spam-Status: No, score=-2.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zb_l-3gI8dwW for ; Sun, 17 Apr 2016 01:46:14 -0700 (PDT)
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 108DA12D6DA for ; Sun, 17 Apr 2016 01:46:13 -0700 (PDT)
Received: from [79.218.78.53] (helo=[192.168.71.101]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84) (envelope-from ) id 1ariLL-0003uS-Gn; Sun, 17 Apr 2016 10:46:11 +0200
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt 
X-Mailer: iPad Mail (13E238)
In-Reply-To: <57054ADF.3010109@gmx.net>
Date: Sun, 17 Apr 2016 10:46:10 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <57054ADF.3010109@gmx.net>
To: Hannes Tschofenig 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Meeting Minutes
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Apr 2016 08:46:17 -0000

Hi all,

the security discussion started with mix up and cut and paste, but we had a m=
uch broader discussion including further issues, such as open redirector. I s=
uggested to merge all threats we are currently discussing into a single docu=
ment in order to come up with a consolidated view on "enhanced OAuth securit=
y". This would at least include:
- mix up
- copy and paste
- changed behavior of browsers regarding URL fragments
- open redirector (AS and client)
- (potentially) XSRF and advice on how to mitigate it using state

I think that would help the working group to get an overview on ALL issues (=
including e.g. fragments) and _systematically_ improve OAuth. We did the sam=
e when we originally published the core spec - and it worked.

I felt some consensous around the topic that in the end, there must be norma=
tive chances to the core protocol and the respective security considerations=
.

Barry gave his advice regarding updates in this context.

best regards,
Torsten.

> Am 06.04.2016 um 19:43 schrieb Hannes Tschofenig :
>=20
> Leif was so nice to take meeting notes during the OAuth meeting today
> and they have been uploaded to:
> https://www.ietf.org/proceedings/95/minutes/minutes-95-oauth
>=20
> Please take a look at them and let me know if they are incorrect or need
> to be extended.
>=20
> Ciao
> Hannes
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Mon Apr 18 15:35:15 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE0012DBFC for ; Mon, 18 Apr 2016 15:35:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pN33-ZB0K8S1 for ; Mon, 18 Apr 2016 15:35:11 -0700 (PDT)
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 AA57212D78F for ; Mon, 18 Apr 2016 15:35:11 -0700 (PDT)
Received: by mail-io0-x22b.google.com with SMTP id u185so1446033iod.3 for ; Mon, 18 Apr 2016 15:35:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=d0iuboWYEGOU8ieDpe6BgDFBD5CjsaTbYTecyYtSGvw=; b=Rk1yduQwH3RFKNYIu07BpOdx8zoc3WsA7D7Q4RZJYY/Cw2si0zy+I6eeestFOV75QM vdyZusjYX5hcvNx1QFxHZlf+znjux4PcEwf7lTvguvlgH8D4EmGSoR25QIKvfnt5zOsb VKp2xhhiWWXnFV80fap0pXxTFz8mEZGqG0qZ4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=d0iuboWYEGOU8ieDpe6BgDFBD5CjsaTbYTecyYtSGvw=; b=HjEHloOKuZDBGEfEnS0MflI6Ke3uwPgf8AYs9rRq8TFcsjhZU8y+buc8UhAXhV4kl2 aJfOp772Jt2FLjLJ4j+8ye1bim8ES3x5JTkCbUw+sPIQY2rAK3qgJPBvgzetedqV3Xsk p9nQXuRYCMOeff79MHX4XU7A/FCpqvlQJ5srqu5FaMsiAdj3Vic30VD0dtq+p7Xf5rYF HpyaQLs382qSA0amJjD8yA77xutWgUMrhjNG4xFAOSRGT1DyrX5J4Qz9QuLBvrcSCsLF jY8fkMpkzS8YASZqr/+NHodm9B47eQKAOzRn9TsYDWgFAwY+LREgbFPMpveX+Iw+wMgi bEJw==
X-Gm-Message-State: AOPr4FVAn4Tmqs1USIpgwL8aTYYF/TyMvxv5qE7nJNsPalLz+ZvB7wr3LpZyPQmkWsx6dTd/SQSIZdSVqZBV0jzM
X-Received: by 10.107.162.7 with SMTP id l7mr225388ioe.147.1461018910855; Mon, 18 Apr 2016 15:35:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.74.162 with HTTP; Mon, 18 Apr 2016 15:34:41 -0700 (PDT)
In-Reply-To: 
References: <57054ADF.3010109@gmx.net> 
From: Brian Campbell 
Date: Mon, 18 Apr 2016 16:34:41 -0600
Message-ID: 
To: Torsten Lodderstedt 
Content-Type: multipart/alternative; boundary=001a1140e6383131a20530c9f97e
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Meeting Minutes
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Apr 2016 22:35:13 -0000

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

Yeah, as I recall, there was at least some support around the idea of an
"enhanced OAuth security" document.

On Sun, Apr 17, 2016 at 2:46 AM, Torsten Lodderstedt <
torsten@lodderstedt.net> wrote:

> Hi all,
>
> the security discussion started with mix up and cut and paste, but we had
> a much broader discussion including further issues, such as open
> redirector. I suggested to merge all threats we are currently discussing
> into a single document in order to come up with a consolidated view on
> "enhanced OAuth security". This would at least include:
> - mix up
> - copy and paste
> - changed behavior of browsers regarding URL fragments
> - open redirector (AS and client)
> - (potentially) XSRF and advice on how to mitigate it using state
>
> I think that would help the working group to get an overview on ALL issues
> (including e.g. fragments) and _systematically_ improve OAuth. We did the
> same when we originally published the core spec - and it worked.
>
> I felt some consensous around the topic that in the end, there must be
> normative chances to the core protocol and the respective security
> considerations.
>
> Barry gave his advice regarding updates in this context.
>
> best regards,
> Torsten.
>
> > Am 06.04.2016 um 19:43 schrieb Hannes Tschofenig <
> hannes.tschofenig@gmx.net>:
> >
> > Leif was so nice to take meeting notes during the OAuth meeting today
> > and they have been uploaded to:
> > https://www.ietf.org/proceedings/95/minutes/minutes-95-oauth
> >
> > Please take a look at them and let me know if they are incorrect or need
> > to be extended.
> >
> > 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
>

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


Yeah, as I recall, there was at least some support around =
the idea of an "enhanced OAuth security" document. 

On Sun, Apr 17, 2016 =
at 2:46 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi all,



the security discussion started with mix up and cut and paste, but we had a=
 much broader discussion including further issues, such as open redirector.=
 I suggested to merge all threats we are currently discussing into a single=
 document in order to come up with a consolidated view on "enhanced OA=
uth security". This would at least include:

- mix up

- copy and paste

- changed behavior of browsers regarding URL fragments

- open redirector (AS and client)

- (potentially) XSRF and advice on how to mitigate it using state



I think that would help the working group to get an overview on ALL issues =
(including e.g. fragments) and _systematically_ improve OAuth. We did the s=
ame when we originally published the core spec - and it worked.



I felt some consensous around the topic that in the end, there must be norm=
ative chances to the core protocol and the respective security consideratio=
ns.



Barry gave his advice regarding updates in this context.



best regards,

Torsten.




> Am 06.04.2016 um 19:43 schrieb Hannes Tschofenig <hannes.tschofenig@gmx.net>:

>

> Leif was so nice to take meeting notes during the OAuth meeting today<=
br>
> and they have been uploaded to:

> https://www.ietf.org/proceedings/95=
/minutes/minutes-95-oauth

>

> Please take a look at them and let me know if they are incorrect or ne=
ed

> to be extended.

>

> 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





--001a1140e6383131a20530c9f97e--


From nobody Mon Apr 18 16:21:05 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E798B12E94A for ; Mon, 18 Apr 2016 16:21:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.196
X-Spam-Level: 
X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mi8-TF8KNfu for ; Mon, 18 Apr 2016 16:21:01 -0700 (PDT)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5AEB12E949 for ; Mon, 18 Apr 2016 16:21:00 -0700 (PDT)
X-AuditID: 12074425-747ff70000001901-57-57156bdbfd6c
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by  (Symantec Messaging Gateway) with SMTP id B8.A8.06401.BDB65175; Mon, 18 Apr 2016 19:20:59 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u3INKw4T008837; Mon, 18 Apr 2016 19:20:59 -0400
Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u3INKuK6008781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Apr 2016 19:20:57 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_F481E33C-A8B2-4C53-B092-E5E21EA98909"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Justin Richer 
In-Reply-To: 
Date: Mon, 18 Apr 2016 19:20:56 -0400
Message-Id: <4448ED56-22E6-4C4E-9AE6-FBC5AC2C7A47@mit.edu>
References: <57054ADF.3010109@gmx.net>  
To: Brian Campbell 
X-Mailer: Apple Mail (2.3124)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IR4hTV1r2dLRpusGWWqsXq/zcZLU6+fcVm 8erYUxYHZo8lS34yeRzr6Wf1uHv0IksAcxSXTUpqTmZZapG+XQJXxtkPL5kLVtlUnF2zmKWB scOki5GTQ0LAROLO41ssXYxcHEICbUwS0ybvYQJJCAlsZJR4MyUDIvGQSeLOzWdsIAlmgQSJ NXdfs4PYvAJ6EpvWvwVq4OAQFlCXaPqhBxJmE1CVmL6mBWwOp0CgxP7HN8FaWYDiLUs3MIKU MwvESzw9qAIxxUri5MV3bBCrFjFKXGr8zAiSEBHQl7j9dA47xKGyEk9OLmKZwMg/C8kVs5Bc ARHXlli28DUzhK0psb97OQumuIZE57eJrAsY2VYxyqbkVunmJmbmFKcm6xYnJ+blpRbpWujl ZpbopaaUbmIEhTq7i+oOxjl/vQ4xCnAwKvHwRjCIhAuxJpYVV+YeYpTkYFIS5ZXxEA0X4kvK T6nMSCzOiC8qzUktPsQowcGsJMIrlQmU401JrKxKLcqHSUlzsCiJ8zIyMDAICaQnlqRmp6YW pBbBZGU4OJQkeP2ygBoFi1LTUyvSMnNKENJMHJwgw3mAhnuC1PAWFyTmFmemQ+RPMSpKifMm gCQEQBIZpXlwvaBUlPD2sOkrRnGgV4R5Q0CqeIBpDK77FdBgJqDB1m8EQQaXJCKkpBoYHT8o X/6TysN2lC+R6VP9youJa+fnfVHzy1pyeIrIMTmpvP1z1DdoVOyuZ9/7L3ZbxUnFPTUpD6SU /yitNnzexmV/+CifetTiQwx2y7NOZKj+yrlx6LBBuKD4fRnVuh1JW3988zy1psme7dgz3eyS U9W+ZSvZw5Ldlsp927rX4k7hpl9Nj/N7lViKMxINtZiLihMBJMNkZSADAAA=
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Meeting Minutes
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Apr 2016 23:21:04 -0000

--Apple-Mail=_F481E33C-A8B2-4C53-B092-E5E21EA98909
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I recall +1=E2=80=99ing that idea in the chat. It=E2=80=99s an =
=E2=80=9Cupdates=E2=80=9D to 6819 at least.

 =E2=80=94 Justin


> On Apr 18, 2016, at 6:34 PM, Brian Campbell =
 wrote:
>=20
> Yeah, as I recall, there was at least some support around the idea of =
an "enhanced OAuth security" document.=20
>=20
> On Sun, Apr 17, 2016 at 2:46 AM, Torsten Lodderstedt =
> wrote:
> Hi all,
>=20
> the security discussion started with mix up and cut and paste, but we =
had a much broader discussion including further issues, such as open =
redirector. I suggested to merge all threats we are currently discussing =
into a single document in order to come up with a consolidated view on =
"enhanced OAuth security". This would at least include:
> - mix up
> - copy and paste
> - changed behavior of browsers regarding URL fragments
> - open redirector (AS and client)
> - (potentially) XSRF and advice on how to mitigate it using state
>=20
> I think that would help the working group to get an overview on ALL =
issues (including e.g. fragments) and _systematically_ improve OAuth. We =
did the same when we originally published the core spec - and it worked.
>=20
> I felt some consensous around the topic that in the end, there must be =
normative chances to the core protocol and the respective security =
considerations.
>=20
> Barry gave his advice regarding updates in this context.
>=20
> best regards,
> Torsten.
>=20
> > Am 06.04.2016 um 19:43 schrieb Hannes Tschofenig =
>:
> >
> > Leif was so nice to take meeting notes during the OAuth meeting =
today
> > and they have been uploaded to:
> > https://www.ietf.org/proceedings/95/minutes/minutes-95-oauth =

> >
> > Please take a look at them and let me know if they are incorrect or =
need
> > to be extended.
> >
> > 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
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_F481E33C-A8B2-4C53-B092-E5E21EA98909
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I recall +1=E2=80=99ing that idea in the chat. It=E2=80=99s =
an =E2=80=9Cupdates=E2=80=9D to 6819 at least.

 =E2=80=94 Justin


On =
Apr 18, 2016, at 6:34 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Yeah, as I recall, there was at =
least some support around the idea of an "enhanced OAuth security" =
document. 

On Sun, Apr 17, 2016 at 2:46 AM, =
Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi all,



the security discussion started with mix up and cut and paste, but we =
had a much broader discussion including further issues, such as open =
redirector. I suggested to merge all threats we are currently discussing =
into a single document in order to come up with a consolidated view on =
"enhanced OAuth security". This would at least include:

- mix up

- copy and paste

- changed behavior of browsers regarding URL fragments

- open redirector (AS and client)

- (potentially) XSRF and advice on how to mitigate it using state



I think that would help the working group to get an overview on ALL =
issues (including e.g. fragments) and _systematically_ improve OAuth. We =
did the same when we originally published the core spec - and it =
worked.



I felt some consensous around the topic that in the end, there must be =
normative chances to the core protocol and the respective security =
considerations.



Barry gave his advice regarding updates in this context.



best regards,

Torsten.




> Am 06.04.2016 um 19:43 schrieb Hannes Tschofenig <hannes.tschofenig@gmx.net>:

>

> Leif was so nice to take meeting notes during the OAuth meeting =
today

> and they have been uploaded to:

> https://www.ietf.org/proceedings/95/minutes/minutes-95-oauth

>

> Please take a look at them and let me know if they are incorrect or =
need

> to be extended.

>

> 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=_F481E33C-A8B2-4C53-B092-E5E21EA98909--


From nobody Mon Apr 18 16:35:00 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D83FC12DA36 for ; Mon, 18 Apr 2016 16:34:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.216
X-Spam-Level: 
X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOG9UzIgm0vw for ; Mon, 18 Apr 2016 16:34:57 -0700 (PDT)
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 6875E12DDBE for ; Mon, 18 Apr 2016 16:34:57 -0700 (PDT)
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 u3INYtP7019358 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 18 Apr 2016 23:34:56 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 u3INYtOU006231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Apr 2016 23:34:55 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 u3INYrRc029749; Mon, 18 Apr 2016 23:34:54 GMT
Received: from [192.168.1.22] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 18 Apr 2016 16:34:53 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_40DC3CC8-075A-4F28-9EAA-81B41141D573"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Phil Hunt 
In-Reply-To: <4448ED56-22E6-4C4E-9AE6-FBC5AC2C7A47@mit.edu>
Date: Mon, 18 Apr 2016 16:34:49 -0700
Message-Id: <98621CB7-58C4-43C0-BE80-41E984FCBB58@oracle.com>
References: <57054ADF.3010109@gmx.net>   <4448ED56-22E6-4C4E-9AE6-FBC5AC2C7A47@mit.edu>
To: Justin Richer 
X-Mailer: Apple Mail (2.3124)
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Meeting Minutes
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Apr 2016 23:35:00 -0000

--Apple-Mail=_40DC3CC8-075A-4F28-9EAA-81B41141D573
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

There were multiple options discussed in the meeting and on the emails.

I noticed there was strong support for consolidation if there is an =
opportunity to reduce the number of RFCs developers have to pay =
attention to.  This is where Barry commented that there are differences =
between a 6749bis, vs an UpdateBy vs. adding more drafts.

I=E2=80=99m not sure what the best RFC approach is, but if I was to =
re-organize the drafts to make life easy for implementers I would start =
to break things down into distinct areas where there is minimal overlap =
(except with core). Maybe something along the lines of...

*  Core =E2=80=94 what is the core protocol and the security measures =
that apply to all implementations
*  Functional Cases
   =E2=80=94 Mobile - threats and remediation that apply to mobile =
applications
   =E2=80=94 Browser - threats and remediations that apply to javascript =
apps
    =E2=80=94 Dynamic clients - Formalizing how client applications =
configure at run time or on the fly and/or talk to more than one service =
provider or oauth service. This can also include dynamic registration.
   =E2=80=94 Dynamic Resources - Resource services that are deployed =
against multiple different OAuth infrastructure providers (e.g. hosted =
in multi-clouds), or accept authorization/tokens from more than one =
authorization service. This may include formalization of how resource =
express or register scopes with ASes and how they register to be served.

Regarding Dynamic Resources, we haven=E2=80=99t really discussed this. =
But it seems like many AS=E2=80=99s are now issuing generic tokens in =
enterprise scenarios because they actually know nothing about the =
resources they are controlling access to. Potentially this is because =
resources are spun up and taken down independently.  This seems to be =
its own set of problems and risks that would be worth discussing in its =
own document. Some of this has been discussed in the UMA cases, but =
I=E2=80=99m not sure the UMA proposals work in the broader application =
space.  Certainly we can be informed by the UMA work here.

Phil

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






> On Apr 18, 2016, at 4:20 PM, Justin Richer  wrote:
>=20
> I recall +1=E2=80=99ing that idea in the chat. It=E2=80=99s an =
=E2=80=9Cupdates=E2=80=9D to 6819 at least.
>=20
>  =E2=80=94 Justin
>=20
>=20
>> On Apr 18, 2016, at 6:34 PM, Brian Campbell =
> wrote:
>>=20
>> Yeah, as I recall, there was at least some support around the idea of =
an "enhanced OAuth security" document.=20
>>=20
>> On Sun, Apr 17, 2016 at 2:46 AM, Torsten Lodderstedt =
> wrote:
>> Hi all,
>>=20
>> the security discussion started with mix up and cut and paste, but we =
had a much broader discussion including further issues, such as open =
redirector. I suggested to merge all threats we are currently discussing =
into a single document in order to come up with a consolidated view on =
"enhanced OAuth security". This would at least include:
>> - mix up
>> - copy and paste
>> - changed behavior of browsers regarding URL fragments
>> - open redirector (AS and client)
>> - (potentially) XSRF and advice on how to mitigate it using state
>>=20
>> I think that would help the working group to get an overview on ALL =
issues (including e.g. fragments) and _systematically_ improve OAuth. We =
did the same when we originally published the core spec - and it worked.
>>=20
>> I felt some consensous around the topic that in the end, there must =
be normative chances to the core protocol and the respective security =
considerations.
>>=20
>> Barry gave his advice regarding updates in this context.
>>=20
>> best regards,
>> Torsten.
>>=20
>> > Am 06.04.2016 um 19:43 schrieb Hannes Tschofenig =
>:
>> >
>> > Leif was so nice to take meeting notes during the OAuth meeting =
today
>> > and they have been uploaded to:
>> > https://www.ietf.org/proceedings/95/minutes/minutes-95-oauth =

>> >
>> > Please take a look at them and let me know if they are incorrect or =
need
>> > to be extended.
>> >
>> > 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
>> _______________________________________________
>> 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=_40DC3CC8-075A-4F28-9EAA-81B41141D573
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

There were multiple options discussed in the meeting and on =
the emails.

I =
noticed there was strong support for consolidation if there is an =
opportunity to reduce the number of RFCs developers have to pay =
attention to.  This is where Barry commented that there are =
differences between a 6749bis, vs an UpdateBy vs. adding more =
drafts.

I=E2=80=99=
m not sure what the best RFC approach is, but if I was to re-organize =
the drafts to make life easy for implementers I would start to break =
things down into distinct areas where there is minimal overlap (except =
with core). Maybe something along the lines of...
*  Core =E2=80=94 what is the =
core protocol and the security measures that apply to all =
implementations
*  Functional Cases
   =E2=80=94 Mobile - threats and remediation that =
apply to mobile applications
   =E2=80=94 =
Browser - threats and remediations that apply to javascript =
apps
    =E2=80=94 Dynamic clients - =
Formalizing how client applications configure at run time or on the fly =
and/or talk to more than one service provider or oauth service. This can =
also include dynamic registration.
   =E2=80=
=94 Dynamic Resources - Resource services that are deployed against =
multiple different OAuth infrastructure providers (e.g. hosted in =
multi-clouds), or accept authorization/tokens from more than one =
authorization service. This may include formalization of how resource =
express or register scopes with ASes and how they register to be =
served.

Regarding Dynamic Resources, we haven=E2=80=99t really =
discussed this. But it seems like many AS=E2=80=99s are now issuing =
generic tokens in enterprise scenarios because they actually know =
nothing about the resources they are controlling access to. Potentially =
this is because resources are spun up and taken down independently. =
 This seems to be its own set of problems and risks that would be =
worth discussing in its own document. Some of this has been discussed in =
the UMA cases, but I=E2=80=99m not sure the UMA proposals work in the =
broader application space.  Certainly we can be informed by the UMA =
work here.








On Apr 18, 2016, at 4:20 PM, Justin Richer <jricher@mit.edu> =
wrote:

I recall =
+1=E2=80=99ing that idea in the chat. It=E2=80=99s an =E2=80=9Cupdates=E2=80=
=9D to 6819 at least.

 =E2=80=94 Justin


On Apr =
18, 2016, at 6:34 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Yeah, as I recall, there was at =
least some support around the idea of an "enhanced OAuth security" =
document. 

On Sun, Apr 17, 2016 at 2:46 AM, =
Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi all,



the security discussion started with mix up and cut and paste, but we =
had a much broader discussion including further issues, such as open =
redirector. I suggested to merge all threats we are currently discussing =
into a single document in order to come up with a consolidated view on =
"enhanced OAuth security". This would at least include:

- mix up

- copy and paste

- changed behavior of browsers regarding URL fragments

- open redirector (AS and client)

- (potentially) XSRF and advice on how to mitigate it using state



I think that would help the working group to get an overview on ALL =
issues (including e.g. fragments) and _systematically_ improve OAuth. We =
did the same when we originally published the core spec - and it =
worked.



I felt some consensous around the topic that in the end, there must be =
normative chances to the core protocol and the respective security =
considerations.



Barry gave his advice regarding updates in this context.



best regards,

Torsten.




> Am 06.04.2016 um 19:43 schrieb Hannes Tschofenig <hannes.tschofenig@gmx.net>:

>

> Leif was so nice to take meeting notes during the OAuth meeting =
today

> and they have been uploaded to:

> https://www.ietf.org/proceedings/95/minutes/minutes-95-oauth

>

> Please take a look at them and let me know if they are incorrect or =
need

> to be extended.

>

> 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

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

=

--Apple-Mail=_40DC3CC8-075A-4F28-9EAA-81B41141D573--


From nobody Mon Apr 18 17:25:14 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8B512EA0B for ; Mon, 18 Apr 2016 17:25:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.71
X-Spam-Level: 
X-Spam-Status: No, score=-0.71 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpl8_E-sGmHt for ; Mon, 18 Apr 2016 17:25:09 -0700 (PDT)
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 3234712EA0C for ; Mon, 18 Apr 2016 17:25:09 -0700 (PDT)
Received: by mail-qg0-x22d.google.com with SMTP id c6so380381qga.1 for ; Mon, 18 Apr 2016 17:25:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8jqvcLvU4KcJb9K+KAoNC8WAUDN1TGFH2att1V5Dprw=; b=P3g0KVaB/U/5zUn/zjVLc68GOstIdYdRFcB2m0iMsJOJVqCB6R44NG/Z6HdZqDkoyE SY396KG5hWA91WMXnHM9BnufSdqQINe59Y7qEWXzbgFItEoucyP0NsIIXaqC1GGpToeD heyanc4EBxeYvZ3Zcu7H3NGznv58wEkidGoFYByyrNRSikaX3Kz9ilrX+YoticdRT/J5 C2qp/oxzeSbdYEMVbQc0znL7e6Mc9lCeDH0Y/G2BGmrdRYshPrE+S9eUSQainYnEmUZq MoNQ/l4ogtsy3URZeC59leJQStv+Bo8sw+7AY4zC98s9WiesDG4+47ikAWl1PaylYkI5 0D6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8jqvcLvU4KcJb9K+KAoNC8WAUDN1TGFH2att1V5Dprw=; b=SSXKTYLDA37vSsrWex5/kDTZnhYD4Q0ynvk0oZt6MzRenNOhnmlGaE/seA1bqQ7+Tw vJyPVHHPhhscT1NDLVz2k9NXw9GtEDMwyBtvnDLQiKr4meePBH0IYX8qzAaW3AYR7Rmn D3BcSeJekv+YdTCUkDETTnfJ3S41B7MsYDJT77YdiaBTVXD1gFfdnUsRL8CPmHt18sQm 04n2hLl4TDdc7PmwmX4BZ61lJjny7PS+AUknSkn4rG8f/zKW6grbqwpP5iF/Wabrgvp4 SOT4NUxiXZhlnkIaqtNeDDvNI99pbKrCKNb6MmJ4yuLb3H9wbfqMt0NAprHvklhoWoBW t9JQ==
X-Gm-Message-State: AOPr4FX4n/uLU5md0MHfVzWAVa9WxHeVes8GWqTs4qpb7nGz0eDv8C9lYTIAhdu4qSPcyaU2+BN5ZXf/xSQ4mg==
X-Received: by 10.140.252.197 with SMTP id x188mr48665044qhc.81.1461025508073;  Mon, 18 Apr 2016 17:25:08 -0700 (PDT)
MIME-Version: 1.0
References: <570546A1.8040509@gmx.net> <5AEB6A4A-A325-4069-930F-D034D81E41E5@mit.edu>        <9FA7FA11-0FED-40D6-AD49-506BA4EEF8E4@mit.edu> 
In-Reply-To: 
From: Nat Sakimura 
Date: Tue, 19 Apr 2016 00:24:58 +0000
Message-ID: 
To: Anthony Nadalin , Justin Richer ,  Torsten Lodderstadt 
Content-Type: multipart/alternative; boundary=001a113a988a6aaad80530cb82ce
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Apr 2016 00:25:13 -0000

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

+1

We should distill the use cases to get a set of requirements before jumping
onto a solution.

On Tue, Apr 12, 2016 at 14:04 Anthony Nadalin  wrote=
:

> Specifications should be somewhat complete and not open ended/not thought
> out, you should think about the issues, requirements and use cases first
> before you try to force this into the working group process and confuse
> people , we had too many of these specifications lately.
>
>
>
> We are now up to 15+ specifications that someone has to read and
> understand how these all may or may not fit together and all the
> interactions that may occur. So much for the simple Oauth.
>
>
>
> *From:* Justin Richer [mailto:jricher@mit.edu]
> *Sent:* Tuesday, April 12, 2016 5:46 AM
> *To:* Torsten Lodderstadt 
> *Cc:* Anthony Nadalin ;  <
> oauth@ietf.org>
>
>
> *Subject:* Re: [OAUTH-WG] Call for Adoption: Resource Indicators for
> OAuth 2.0
>
>
>
> +1 to Torsten=E2=80=99s point.
>
>
>
> And a reminder to Tony that call for adoption is the *start* of the
> document editing process, not the end. We=E2=80=99re not saying this is a=
 complete
> solution with everything thought out when we adopt the document, we=E2=80=
=99re
> saying it=E2=80=99s a problem we want to work on and a direction that we =
want to
> move in. Stop trying to confuse people.
>
>
>
>  =E2=80=94 Justin
>
>
>
> On Apr 12, 2016, at 1:30 AM, Torsten Lodderstedt 
> wrote:
>
>
>
> Indicating the resource server to the AS allows the AS to automatically
> select token type, encryption scheme and user data to be put into the
> access token based on a RS-specific policy. So there is no need to
> explicitely ask the AS for a certain token format or encryption scheme.
>
>
> Am 11.04.2016 um 22:35 schrieb Anthony Nadalin :
>
> So it=E2=80=99s an incomplete solution then ?
>
>
>
> *From:* Brian Campbell [mailto:bcampbell@pingidentity.com
> ]
> *Sent:* Monday, April 11, 2016 1:34 PM
> *To:* Anthony Nadalin 
> *Cc:* Nat Sakimura ;  
> *Subject:* Re: [OAUTH-WG] Call for Adoption: Resource Indicators for
> OAuth 2.0
>
>
>
> No, I'm not adding requirements for encryption. I was pointing out some o=
f
> the ways that an access token might be different for different RSs.
>
>
>
>
> On Mon, Apr 11, 2016 at 2:18 PM, Anthony Nadalin 
> wrote:
>
> So now you are adding more requirements for encryption ? The more this
> thread goes on shows how unstable and not fully thought out this draft is
> to go through WG adoption.
>
>
>
> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian
> Campbell
> *Sent:* Monday, April 11, 2016 12:30 PM
> *To:* Nat Sakimura 
> *Cc:*  
> *Subject:* Re: [OAUTH-WG] Call for Adoption: Resource Indicators for
> OAuth 2.0
>
>
>
> Sending a token type is not sufficient. There's more involved than the
> format. Many cases need to know if to encrypt and whom to encrypt to.  Wh=
at
> claims to put in the token (or reference by the token). What algorithms a=
nd
> keys to use for signing/encryption.
>
>
> The statement that the "Current proposal does not support the implicit
> flow" is incorrect. Among other things, sec 2 has, "When an access token
> will be returned from the authorization endpoint, the "resource" paramete=
r
> is used in the authorization request to the authorization endpoint as
> defined in Section 4.2.1 of OAuth 2.0 [RFC6749]."
>
>
>
> On Sun, Apr 10, 2016 at 11:43 AM, Nat Sakimura  wrote=
:
>
> So, my understanding on the rationale/requirements for having this spec
> right now is:
>
>
>
> R1. Authz server wants toprevent the replay by the server that received
> it.
>
> R2. Authz server needs to mint the access token in a variety of format
> depending on the resource server and to do that, you need to know which R=
S
> is gong to be receiving it.
>
>
>
> To achieve R1, there are couple of methods. The proposed method here is t=
o
> audience restrict the token, but the same can be achieved by sender
> constraining the token, e.g., by token binding. As far as I can see, the
> sentiment of the WG seems to be to use the sender constraint through Toke=
n
> Binding, so from this respect, this spec is not the one to do R1. Besides=
,
> the current proposal only takes care of the code flow. The same requireme=
nt
> should be there for implicit flow as well, so the current proposal is not
> covering the R1 anyways.
>
>
>
> I can sort of understand R2, but I have two critique on the current
> proposal:
>
>
>
> C1. Current proposal does not support the implicit flow. To support it,
> the resource URI has to be sent to the Authz endpoint instead of the Toke=
n
> endpoint.
>
> C2. It is much more direct to send the required token format rather than
> the RS uri and probably better as:
>
>   1) There are use cases where the AS does not maintain the list of RSs
> that it supports, e.g., AOL.
>
>        In such a case, even if the RS uri were sent to the AS, the AS
> cannot mint the tokens in the appropriate format.
>
>   2) When it is sent in the Authz request, it is leaking the information
> about the resource that the client is going to the browser.
>
>   3) There are use cases where it is desirable not to let the AS knows
> where the Client is going from the privacy point of view.
>
>
>
> So, my suggestion is to drop R1 and concentrate on R2. And to solve R2,
> send token type instead of the resource indicator in the request.
>
> This also necessitates the Client to be able to find out what token type
> the resource requires, perhaps in the unauthorized response web link head=
er
> at the resource in the manner of oauth-meta.
>
>
>
> Cheers,
>
>
>
> Nat
>
>
>
>
>
>
>
> 2016=E5=B9=B44=E6=9C=888=E6=97=A5(=E9=87=91) 8:23 Prateek Mishra :
>
> While this work addresses a gap in the existing OAuth specification set, =
I
> am very concerned that this
> incremental extension will lead to even more confusion around the areas o=
f
> =E2=80=9Cscope=E2=80=9D, =E2=80=9Caudience=E2=80=9D and =E2=80=9Cresource=
 server=E2=80=9D.
>
> I think we should try to solve this problem via  a framework that provide=
s
> better guidance and implementation
> models for OAuth use-cases. In other words, I feel that a broader
> discussion is needed here.
>
>
> > On Apr 7, 2016, at 4:11 PM, Justin Richer  wrote:
> >
> > I support adoption of this document as a starting point for working
> group work.
> >
> > =E2=80=94 Justin
> >
> >
> >> On Apr 6, 2016, at 1:25 PM, Hannes Tschofenig <
> hannes.tschofenig@gmx.net> wrote:
> >>
> >> Hi all,
> >>
> >> this is the call for adoption of 'Resource Indicators for OAuth 2.0',
> see
> >>
> http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
> 
> >>
> >> Please let us know by April 20th 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 Buenos
> >> Aires then you don't need to re-state your opinion, if you want.
> >>
> >> The feedback at the BA IETF meeting was the following: ~10 persons
> >> for accepting the document and 0 persons against.
> >>
> >> 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
> 
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


+1 

We should distill the use ca=
ses to get a set of requirements before jumping onto a solution.  
On Tue, Apr 12, 2016 at 14:04 =
Anthony Nadalin <tonynad@micros=
oft.com> wrote:











Specifications should be somewhat complete and not =
open ended/not thought out, you should think about the issues, requirements=
 and use cases first before you try to force this
 into the working group process and confuse people , we had too many of the=
se specifications lately.



=C2=A0


We are now up to 15+ specifications that someone ha=
s to read and understand how these all may or may not fit together and all =
the interactions that may occur. So much for the
 simple Oauth.


<=
u>=C2=A0







From: Justin Richer [mailto:jricher@mit.edu]


Sent: Tuesday, April 12, 2016 5:46 AM

To: Torsten Lodderstadt <torsten@lodderstedt.net>

Cc: Anthony Nadalin <tonynad@microsoft.com>; <oauth@ietf.org> <oauth@ietf.org>
<=
div style=3D"border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0=
in 0in">


Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for O=
Auth 2.0


=C2=A0


+1 to Torsten=E2=80=99s point.




=C2=A0






And a reminder to Tony that call for adoption is the=
 *start* of the document editing process, not the end. We=E2=80=99re not sa=
ying this is a complete solution with everything thought out when we adopt =
the document, we=E2=80=99re saying it=E2=80=99s a problem
 we want to work on and a direction that we want to move in. Stop trying to=
 confuse people.






=C2=A0






=C2=A0=E2=80=94 Justin






=C2=A0








On Apr 12, 2016, at 1:30 AM, Torsten Lodderstedt <=
;torsten@lodde=
rstedt.net> wrote:




=C2=A0






Indicating the resource server to the AS allows th=
e AS to automatically select token type, encryption scheme and user data to=
 be put into the access token based on a RS-specific
 policy. So there is no need to explicitely ask the AS for a certain token =
format or encryption scheme.=C2=A0








Am 11.04.2016 um 22:35 schrieb Anthony Nadalin <tonynad@mic=
rosoft.com>:










So it=E2=80=99s an incomplete solution then ?






=C2=A0






From:=C2=A0Bria=
n
 Campbell [=
mailto:bcampbell@pingidentity.com]<=
span>=C2=A0

Sent:=C2=A0Monday, April 11, 2016 1:34 PM

To:=C2=A0Anthony Nadalin <tonynad@micro=
soft.com>

Cc:=C2=A0Nat Sakimura <sakimura@gmail.com<=
/span>>; <oauth@ietf.org> <oauth@iet=
f.org>

Subject:=C2=A0Re: [OAUTH-WG] Call for Adoption: Resourc=
e Indicators for OAuth 2.0






=C2=A0






No, I'm not addin=
g requirements for encryption. I was pointing out some of the ways that an =
access token might be different for different RSs.














=C2=A0








On Mon, Apr 11, 2016 at 2:18 PM, Anthony Nadalin <=
;tonynad@microsoft.com> wrote:












So now you are adding more requirements for encrypt=
ion ? The more this thread goes on shows how unstable and not fully thought=
 out this draft is to go through WG adoption.







From:=C2=A0OAut=
h
 [mailto:oauth-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Brian Campbell

Sent:=C2=A0Monday, April 11, 2016 12:30 PM

To:=C2=A0Nat Sakimura <sakimura@gmail.com<=
/span>>

Cc:=C2=A0<oauth@ietf.org> <=
oauth@ietf.org>

Subject:=C2=A0Re: [OAUTH-WG] Call for Adoption: Resourc=
e Indicators for OAuth 2.0










=C2=A0








Sending a token type is not sufficient. There's =
more involved than the format. Many cases need to know if to encrypt and wh=
om to encrypt to.=C2=A0 What claims to put in the token (or reference by th=
e token). What algorithms and keys to use for
 signing/encryption. =C2=A0
















The statement that the "Current proposal does not support the implicit=
 flow" is incorrect. Among other things, sec 2 has, "When an acce=
ss token will be returned from the authorization endpoint, the "resour=
ce" parameter is used in the authorization request to
 the authorization endpoint as defined in Section 4.2.1 of OAuth 2.0 [RFC67=
49]."


















=C2=A0








On Sun, Apr 10, 2016 at 11:43 AM, Nat Sakimura <<=
a href=3D"mailto:sakimura@gmail.com" target=3D"_blank">sakimura@gmail.com> wrote:










So, my understanding on the rationale/requirements f=
or having this spec right now is:=C2=A0








=C2=A0










R1. Authz server wants toprevent the replay by the s=
erver that received it.=C2=A0










R2. Authz server needs to mint the access token in a=
 variety of format depending on the resource server and to do that, you nee=
d to know which RS is gong to be receiving it.=C2=A0










=C2=A0










To achieve R1, there are couple of methods. The prop=
osed method here is to audience restrict the token, but the same can be ach=
ieved by sender constraining the token, e.g., by token binding. As far as I=
 can see, the sentiment of the WG
 seems to be to use the sender constraint through Token Binding, so from th=
is respect, this spec is not the one to do R1. Besides, the current proposa=
l only takes care of the code flow. The same requirement should be there fo=
r implicit flow as well, so the
 current proposal is not covering the R1 anyways.=C2=A0










=C2=A0










I can sort of understand R2, but I have two critique=
 on the current proposal:=C2=A0










=C2=A0










C1. Current proposal does not support the implicit f=
low. To support it, the resource URI has to be sent to the Authz endpoint i=
nstead of the Token endpoint.=C2=A0










C2. It is much more direct to send the required toke=
n format rather than the RS uri and probably better as:=C2=A0=











=C2=A0 1) There are use cases where the AS does not =
maintain the list of RSs that it supports, e.g., AOL.=C2=A0









=C2=A0 =C2=A0 =C2=A0 =C2=A0In such a case, even if t=
he RS uri were sent to the AS, the AS cannot mint the tokens in the appropr=
iate format.=C2=A0










=C2=A0 2) When it is sent in the Authz request, it i=
s leaking the information about the resource that the client is going to th=
e browser.=C2=A0










=C2=A0 3) There are use cases where it is desirable =
not to let the AS knows where the Client is going from the privacy point of=
 view.=C2=A0










=C2=A0










So, my suggestion is to drop R1 and concentrate on R=
2. And to solve R2, send token type instead of the resource indicator in th=
e request.=C2=A0










This also necessitates the Client to be able to find=
 out what token type the resource requires, perhaps in the unauthorized res=
ponse web link header at the resource in the manner of oauth-meta.=C2=A0=











=C2=A0










Cheers,=C2=A0










=C2=A0










Nat










=C2=A0










=C2=A0










=C2=A0










2016=E6=9C=
=888=E6=97=A5(=E9=87=91) 8:23=
 Prateek Mishra <Prateek.Mishra@oracle.com&g=
t;:














While this work addresses a gap in the existing OAut=
h specification set, I am very concerned that this

incremental extension will lead to even more confusion around the areas of =
=E2=80=9Cscope=E2=80=9D, =E2=80=9Caudience=E2=80=9D and =E2=80=9Cresource s=
erver=E2=80=9D.



I think we should try to solve this problem via=C2=A0 a framework that prov=
ides better guidance and implementation

models for OAuth use-cases. In other words, I feel that a broader discussio=
n is needed here.





> On Apr 7, 2016, at 4:11 PM, Justin Richer <jricher@mit.edu> wrote:

>

> I support adoption of this document as a starting point for working gr=
oup work.

>

> =E2=80=94 Justin

>

>

>> On Apr 6, 2016, at 1:25 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

>>

>> Hi all,

>>

>> this is the call for adoption of 'Resource Indicators for OAut=
h 2.0', see

>>=C2=A0http://datatracker.ietf.org/doc/draft-campb=
ell-oauth-resource-indicators/

>>

>> Please let us know by April 20th whether you accept / object to th=
e

>> adoption of this document as a starting point for work in the OAut=
h

>> working group.

>>

>> Note: If you already stated your opinion at the IETF meeting in Bu=
enos

>> Aires then you don't need to re-state your opinion, if you wan=
t.

>>

>> The feedback at the BA IETF meeting was the following: ~10 persons=


>> for accepting the document and 0 persons against.

>>

>> Ciao

>> Hannes & Derek

>>

>> _______________________________________________

>> OAuth mailing list

>>=C2=A0OAuth@ietf.org

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

>

> _______________________________________________

> OAuth mailing list

>=C2=A0=
OAuth@ietf.org

>=C2=A0ht=
tps://www.ietf.org/mailman/listinfo/oauth



_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mail=
man/listinfo/oauth














_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mail=
man/listinfo/oauth








=C2=A0




















=C2=A0














_______________________________________________
OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mail=
man/listinfo/oauth






_______________________________________________
OAuth mailing list

O=
Auth@ietf.org

https://www.ietf.org/mailman/lis=
tinfo/oauth








=C2=A0






_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--001a113a988a6aaad80530cb82ce--


From nobody Tue Apr 19 00:51:38 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 965E112ECDD for ; Tue, 19 Apr 2016 00:51:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.597
X-Spam-Level: 
X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZF3trECRU4Ko for ; Tue, 19 Apr 2016 00:51:32 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B08A12ECE0 for ; Tue, 19 Apr 2016 00:51:32 -0700 (PDT)
Received: from [192.168.10.140] ([195.149.223.228]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M0Ppl-1bjqub0pSv-00ubWU; Tue, 19 Apr 2016 09:51:28 +0200
To: Brian Campbell , Torsten Lodderstedt 
References: <57054ADF.3010109@gmx.net>  
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <5715E383.1010805@gmx.net>
Date: Tue, 19 Apr 2016 09:51:31 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="n5b0iDI1eQwFPLWKntaeqXR0uumfVKoLW"
X-Provags-ID: V03:K0:XiSFOAu12cW29RLdMZ6pzGV8TujXjav8raucESCjE/jlggKyXUI AC5Mm7YwJXhzZcXVn5I/e1TCufX4HeZPc6CMH4nSIWxNzH+PA1Ovlv7mN4G/q83IRwrMEa+ tIvznsfH9wOxH3RzGXp/N7fTPMgxO+ehTOuRWuy6o0wEZI040JkFeeB/dPu5ixFZ1iAAp1t cuCmPuf9JQwTW57WwKTzQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:dYp/aN9XR4Y=:rB7WAdTQxCqi3KkswmYhbF lmrLwfKEoySwjnjQL8OUYHfXZC4XhB/Quo/DZJWf07wu6bbDr4Afso8GMKPEivbtOD/0Gc941 sXMkN6FavnTgraoKZGqH143sD6/HT+OMxrKt6v8O5AWK3Y+3aFOzuQCJeLtzFl21RMT3/Ri8w zzcdoVrClc3R7N5Vdqaxl3NMVLSVlMU3zOrT79fD/ZMcelFXU0vdmzH68Fsx1fP630nGd3Jcv 1xqn2Mem0jjtQpzU77G44hUgGDIcxCRFK/gmnyLHTmfLsaNnSy63mep5cM/X4KvCTrUucQEUv 4xydxKBtNSQfP+68tPmNMrKQTMsl4UF7y7wuki3b4TqbPtmF9O7q1db7UiZobku5YnkHL+vza NchSzcIT/2NwgQRlmLqW2bmif3vF9eprEfWqc3umkLU9frLF1MPZrseTeY0WkDgZIiE55fKmw RAU9hzhpLnrEmw8L1WH6TEZwAnqEmuZqcLFw76kwWKxw/JFPFlSUQ4m1klTjsInIYcs0vk7D1 vW9Q5WJcvHp3jGLc+IREbo4UqK65lTjj4ZN9Jc197ay22TOXPY1p2hf0dr51HpMLygkn6Os+v k+zLiJfMbSRx/lTup9PuwAXS2EOc2G68mX2dNCyiv2NmYb8Ce9IWmjnFxhxHM70jqkOxMsPIc lXSvBDTJCBzQVayMb9rxczLI8S3oTY3Yy58GEJxp/Dd5ys+N/mDCz0feOCF+KtvRyjwmYrRLJ toseYzx3afSJo3DXWnLm0SEpxeeiCZQLH5EOdY/7gDsBzdAIQN0mw/mLkdg=
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Meeting Minutes
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Apr 2016 07:51:34 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--n5b0iDI1eQwFPLWKntaeqXR0uumfVKoLW
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Torsten,

On 04/19/2016 12:34 AM, Brian Campbell wrote:
>
> I felt some consensous around the topic that in the end, there must be
> normative chances to the core protocol and the respective security
> considerations.
>
> Barry gave his advice regarding updates in this context.

There was no consensus on this topic during the meeting and, in
addition, we have to consult those on the mailing list as well.

Barry, in my understanding, outlined the different options we have at
the meeting.


Ciao
Hannes


--n5b0iDI1eQwFPLWKntaeqXR0uumfVKoLW
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

iQEcBAEBCgAGBQJXFeOEAAoJEGhJURNOOiAtKnoH/0+s4L8jpKnOcNkknJrsOiLo
AfNvrtH6Hvya3oN4HkQsG+0ahNcFubJ+JHPmx0ojFrd1zGkcm+9eNCcnMvK+J5j1
bdy0u9Bs/rvTsW5vt4pzevte7mPgN7Hcs6Vq8+RNsbgT39d7oTkakH7cUIKAmgbJ
vqeNrUDAI/2JIuvFoCM3GLya6gvJVJ2RxbC+IRzl7GYryTBXLYrCieR0GtKAMoln
CxfSCXuTK11Ck9EfmMv1R38km9mUvRKiT6RkGpDIXVyiiGSihnSEElVf7HqUp3lA
yBxAAY4MFA2e+mgZJ0SBmdLgqAO13ZCeOo5oex6+MkiC+d9GxaZkQKjBleZHAN4=
=x36r
-----END PGP SIGNATURE-----

--n5b0iDI1eQwFPLWKntaeqXR0uumfVKoLW--


From nobody Tue Apr 19 01:17:22 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1748012E888 for ; Tue, 19 Apr 2016 01:17:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level: 
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyA-hQppDasZ for ; Tue, 19 Apr 2016 01:17:18 -0700 (PDT)
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 AFB3D12E6BE for ; Tue, 19 Apr 2016 01:17:18 -0700 (PDT)
Received: from [80.187.109.189] (helo=[10.56.238.75]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1asQqR-0001bi-NB; Tue, 19 Apr 2016 10:17:16 +0200
Date: Tue, 19 Apr 2016 10:17:04 +0200
Message-ID: 
In-Reply-To: <5715E383.1010805@gmx.net>
References: <57054ADF.3010109@gmx.net>   <5715E383.1010805@gmx.net>
From: "torsten@lodderstedt.net" 
To: hannes.tschofenig@gmx.net, bcampbell@pingidentity.com
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.syntomo.email_4611259539947972"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Meeting Minutes
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Apr 2016 08:17:21 -0000

----_com.syntomo.email_4611259539947972
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

RGlmZmVyZW50IHBlb3BsZSwgZGlmZmVyZW50IHBlcmNlcHRpb25zIDotKQoKQnV0IGFueXdheSwg
dGhlIGRpc2N1c3Npb24gb24gdGhlIGxpc3QgaGFzIGFscmVhZHkgc3RhcnRlZCwgcmlnaHQ/Cgot
LS0tLS0tLSBPcmlnaW5hbG5hY2hyaWNodCAtLS0tLS0tLQpCZXRyZWZmOiBSZTogW09BVVRILVdH
XSBNZWV0aW5nIE1pbnV0ZXMKVm9uOiBIYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVu
aWdAZ214Lm5ldD4KQW46IEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNv
bT4sVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+CkNjOiBvYXV0
aEBpZXRmLm9yZwoKPkhpIFRvcnN0ZW4sCj4KPk9uIDA0LzE5LzIwMTYgMTI6MzQgQU0sIEJyaWFu
IENhbXBiZWxsIHdyb3RlOgo+Pgo+PiBJIGZlbHQgc29tZSBjb25zZW5zb3VzIGFyb3VuZCB0aGUg
dG9waWMgdGhhdCBpbiB0aGUgZW5kLCB0aGVyZSBtdXN0IGJlCj4+IG5vcm1hdGl2ZSBjaGFuY2Vz
IHRvIHRoZSBjb3JlIHByb3RvY29sIGFuZCB0aGUgcmVzcGVjdGl2ZSBzZWN1cml0eQo+PiBjb25z
aWRlcmF0aW9ucy4KPj4KPj4gQmFycnkgZ2F2ZSBoaXMgYWR2aWNlIHJlZ2FyZGluZyB1cGRhdGVz
IGluIHRoaXMgY29udGV4dC4KPgo+VGhlcmUgd2FzIG5vIGNvbnNlbnN1cyBvbiB0aGlzIHRvcGlj
IGR1cmluZyB0aGUgbWVldGluZyBhbmQsIGluCj5hZGRpdGlvbiwgd2UgaGF2ZSB0byBjb25zdWx0
IHRob3NlIG9uIHRoZSBtYWlsaW5nIGxpc3QgYXMgd2VsbC4KPgo+QmFycnksIGluIG15IHVuZGVy
c3RhbmRpbmcsIG91dGxpbmVkIHRoZSBkaWZmZXJlbnQgb3B0aW9ucyB3ZSBoYXZlIGF0Cj50aGUg
bWVldGluZy4KPgo+Cj5DaWFvCj5IYW5uZXMKPgo=
----_com.syntomo.email_4611259539947972
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

PHAgZGlyPSJsdHIiPkRpZmZlcmVudCBwZW9wbGUsIGRpZmZlcmVudCBwZXJjZXB0aW9ucyA6LSk8
L3A+CjxwIGRpcj0ibHRyIj5CdXQgYW55d2F5LCB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdCBo
YXMgYWxyZWFkeSBzdGFydGVkLCByaWdodD88L3A+Cjxicj48YnI+LS0tLS0tLS0gT3JpZ2luYWxu
YWNocmljaHQgLS0tLS0tLS08YnI+QmV0cmVmZjogUmU6IFtPQVVUSC1XR10gTWVldGluZyBNaW51
dGVzPGJyPlZvbjogSGFubmVzIFRzY2hvZmVuaWcgJmx0O2hhbm5lcy50c2Nob2ZlbmlnQGdteC5u
ZXQmZ3Q7PGJyPkFuOiBCcmlhbiBDYW1wYmVsbCAmbHQ7YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5j
b20mZ3Q7LFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0O3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Jmd0
Ozxicj5DYzogb2F1dGhAaWV0Zi5vcmc8YnI+PGJyPjxwPkhpIFRvcnN0ZW4sPGJyPjxicj5PbiAw
NC8xOS8yMDE2IDEyOjM0IEFNLCBCcmlhbiBDYW1wYmVsbCB3cm90ZTo8YnI+Jmd0Ozxicj4mZ3Q7
IEkgZmVsdCBzb21lIGNvbnNlbnNvdXMgYXJvdW5kIHRoZSB0b3BpYyB0aGF0IGluIHRoZSBlbmQs
IHRoZXJlIG11c3QgYmU8YnI+Jmd0OyBub3JtYXRpdmUgY2hhbmNlcyB0byB0aGUgY29yZSBwcm90
b2NvbCBhbmQgdGhlIHJlc3BlY3RpdmUgc2VjdXJpdHk8YnI+Jmd0OyBjb25zaWRlcmF0aW9ucy48
YnI+Jmd0Ozxicj4mZ3Q7IEJhcnJ5IGdhdmUgaGlzIGFkdmljZSByZWdhcmRpbmcgdXBkYXRlcyBp
biB0aGlzIGNvbnRleHQuPGJyPjxicj5UaGVyZSB3YXMgbm8gY29uc2Vuc3VzIG9uIHRoaXMgdG9w
aWMgZHVyaW5nIHRoZSBtZWV0aW5nIGFuZCwgaW48YnI+YWRkaXRpb24sIHdlIGhhdmUgdG8gY29u
c3VsdCB0aG9zZSBvbiB0aGUgbWFpbGluZyBsaXN0IGFzIHdlbGwuPGJyPjxicj5CYXJyeSwgaW4g
bXkgdW5kZXJzdGFuZGluZywgb3V0bGluZWQgdGhlIGRpZmZlcmVudCBvcHRpb25zIHdlIGhhdmUg
YXQ8YnI+dGhlIG1lZXRpbmcuPGJyPjxicj48YnI+Q2lhbzxicj5IYW5uZXM8YnI+PGJyPjwvcD4=
----_com.syntomo.email_4611259539947972--


From nobody Tue Apr 19 01:27:30 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601A412ED15 for ; Tue, 19 Apr 2016 01:27:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.597
X-Spam-Level: 
X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSSrGB8QajSj for ; Tue, 19 Apr 2016 01:27:28 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3DAE12E9F8 for ; Tue, 19 Apr 2016 01:21:20 -0700 (PDT)
Received: from [192.168.10.140] ([195.149.223.228]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lz3rc-1bnPEQ2pg8-014Ep5; Tue, 19 Apr 2016 10:21:15 +0200
To: "torsten@lodderstedt.net" , bcampbell@pingidentity.com
References: <57054ADF.3010109@gmx.net>   <5715E383.1010805@gmx.net> 
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <5715EA78.4080400@gmx.net>
Date: Tue, 19 Apr 2016 10:21:12 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Fn6uCTlkoIvsCVpLPo8ChkWUDa0NxFfn2"
X-Provags-ID: V03:K0:R6xe0VViC+jinzHOtk1zgyz6pyGWlSrMO13WFLTZqZcrOAynfyx PVIh7tX6di6pMudsidpZ75e7WhD7HOSkkccsqUuKPoF1E2UOtpuvPh/PCM8gCtl0baaYleu e5K3ii3cFs8UyIcwRhxo+oo0utbdRY+ZA0eUlQIHT6RQUi7ru3d4N5Pp7McsGv35nqGutT5 3hKqvycCF1KvR58G3gpng==
X-UI-Out-Filterresults: notjunk:1;V01:K0:C/eoEa+6txk=:NhD0Xv3B2vFHmQqMiKcNQD CTl8nvEyXVQpGFJDhomFXSNAvpwE+AaDmZNyaxJFyjjGyjr2If/KxJ0TdGsutsJUh/NXdXQla 586mXlsRLXAP+UiUNm5zq236ZxtN69OLyVVm7EL6yJXuFrWR7BNEIAJgrEJD1J7jFhJ7RhbUD j2gL5Y30ZIfK453NlrTDptx6QqjstPMH07IgVCeg3IVdtsfF4uzuKDGhmJ4jAHIybegRvwgs7 xjR7JEw0ME78tFUh1BZ9mHo6wYWpZ3u5feIr5aoMTfjoGSMM73VAK5JxuGLjIZAlGiN22tYN8 n3BcRppf+UofG9FzGdLoj5tesOCGdX9eotRPjGtDPZOi11QiiHOS4/jOx+I2t3hoXn/yWjam8 mJUWuoghurMGENcfeJF7IOdDZH5LSZFKn3U6+nqdK2JzvLyRwu2yf6LcwSsIWLvoMh9uXxEZh xOVyoI1VbJXNJ3Wwloj0Ff6YpnrK8zWfnd/FPf4UsVuVPbJnbPVIuf6DK5wH130idrOnWeJEP hx6107KnsQisNBRKYfm3GRKXx5/oN79RQI/D0dhs5bk2Xh8/iZoqBrVtctBAf7PiY2km4bWUY k1gyCRBvORLGcT1RPPy9jkpeLESFMvB7X2aVwVtJXDqOZf85O9cwaF47h2TALLNoz28nmyfD5 ChN5L5oc+prra4P40xhZXlaziVZI7a/Ki5OWOx1pcbURfLiNT0c59Ri2wu5ETZXFuH1o/YP9s hDmYfaG/qYONow20HkpT/2bNq4vQERc76Ld+7ZpQ/AVJV0261IsN1oQqGtg=
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Meeting Minutes
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Apr 2016 08:27:29 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Fn6uCTlkoIvsCVpLPo8ChkWUDa0NxFfn2
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 04/19/2016 10:17 AM, torsten@lodderstedt.net wrote:
> But anyway, the discussion on the list has already started, right?

I triggered the discussion since I believe it is a worthwhile topic to
think about and, given that it is a bigger decision, we should be
mindful about the direction we take

Ciao
Hannes


--Fn6uCTlkoIvsCVpLPo8ChkWUDa0NxFfn2
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

iQEcBAEBCgAGBQJXFep5AAoJEGhJURNOOiAtDC8H/0MYargmuKB1TH5BUOx1zJcm
mM5rh/3wJSFWU3Ak5c5KvuWjwjgdPO0Lav3fSbGjGuXwJyFBpbbQ9Fb7KTtbRVCX
2tCZ4sBj72lwxmkaCTJismlQRtc5i/G6FpZsroXiFQrJ3Jl0sLrGfRF2UQ44JfpD
bpJ9V6vLY9RZiJX1XSpmHLCgmipjGT6HDPk8Vsils5NbcK0vMvzkesWBTfrh53Y0
2+49PTh/mAea5LN6D/S5TJOv5BKnm07igmZMDx3hN6S5lGHozAe9YaOWwx1b1+h2
S77LS8BXc6OpJ1Lmx+FwFd1leDQABB9uctH/vIADYYWR6NH2iqmwy89FMoIu2WE=
=dQrg
-----END PGP SIGNATURE-----

--Fn6uCTlkoIvsCVpLPo8ChkWUDa0NxFfn2--


From nobody Tue Apr 19 09:18:59 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4730F12DB66 for ; Tue, 19 Apr 2016 09:18:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGvKIHI9uVqT for ; Tue, 19 Apr 2016 09:18:56 -0700 (PDT)
Received: from mail-qg0-x262.google.com (mail-qg0-x262.google.com [IPv6:2607:f8b0:400d:c04::262]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D44CD12D9C9 for ; Tue, 19 Apr 2016 09:18:55 -0700 (PDT)
Received: by mail-qg0-x262.google.com with SMTP id m8so2230470qgd.0 for ; Tue, 19 Apr 2016 09:18:55 -0700 (PDT)
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:user-agent:mime-version; bh=1T2bFaDNIWFEnMgZ7wYLrvxGEicJr7XBGlvmuO0hCDo=; b=CucTCwptlFK6911QDExJqc6XRoyFtp6DWjpWQMwodWNFJ8E+FXlr41K4N1pvFQYu1N 34U0fk3y9wELHQSn9Lxy+o4+cQ5cJJZMGrkRmCp1t50jy0Ggs9waIUyBma62K2GMNzl7 h97YPmVrwwQZAddzkVa8PlIeu28UwYF/0jVUi24zVrveXmLWvwwKD5YuiKBu69OyrJBx F7ZiZvBS1EJ4iTcl65ARYGlPBeTwQdBevMEtKuk6vXkLkPSTO0M3p3qKjHCzHnKH2hG9 M9whtKF/IkzW+gqtCt3NebQ613hwPntOoB3NYPjj6S+QuiR0tJkOz9ovh2/qbvrGx5b6 pF9A==
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:user-agent:mime-version; bh=1T2bFaDNIWFEnMgZ7wYLrvxGEicJr7XBGlvmuO0hCDo=; b=BJXqb4gAf5nPY0WQeXGe93xKEAI5eIdaPaYb66icp6aWxmiD6fK61Ehd5zLYgQOQH3 Q022astjV5fQsGCD5PPjv+yc2jhLqLV5GapZEzC3PdpbLaAlEOnxfzDTtXM4W64al8S2 EEsmq3Mp/VSlcUwJSHBdM3AGbcew/2i0/t8Hfqbducv2RS5uLKVn95CqSz20Vp5chSyp NR14YCQE/pTyQNLa7YSaY3RaeidYdyO5iytGlfw6/esfmZwzLYcbiipU8hsDpI3SqZPj WHb+457FY+jP/0V6q+bgtmKL+/gmvmXDGGbxAhmVoz5GQk/TKN31jt0Nac0zVGlv5/Zf HUmw==
X-Gm-Message-State: AOPr4FXBRcbTduSAOFwFvGSVYhe0VbILvVIPHviYClJq02P4CFVtEW3Dax6UwN6KJNha063aQAtsDhv/wh1hFAvmUzKUrwHc
X-Received: by 10.140.91.194 with SMTP id z60mr3028760qgd.70.1461082734732; Tue, 19 Apr 2016 09:18:54 -0700 (PDT)
Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id y135sm8998253qky.9.2016.04.19.09.18.54 for  (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 19 Apr 2016 09:18:54 -0700 (PDT)
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 u3JGIsXS006978 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 19 Apr 2016 12:18:54 -0400
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 19 Apr 2016 12:18:51 -0400
From: "Fregly, Andrew" 
To: "oauth@ietf.org" 
Thread-Topic: =?utf-8?B?QnVpbGRpbmcgb24gdGhlIHByb3RvY29sIGluIHRoZSBkcmFmdCDigJxPQXV0?= =?utf-8?B?aCAgMi4wIFRva2VuIEV4Y2hhbmdlOiBBbiBTVFMgZm9yIHRoZSBSRVNUIG9m?= =?utf-8?B?IFVz4oCdIHRvIGluY2x1ZGUgQXV0aGVudGljYXRpb24gVG9rZW5z?=
Thread-Index: AQHRmlcomE8l0QoCm0C5ZCXr0BuVzw==
Date: Tue, 19 Apr 2016 16:18:50 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.160212
x-originating-ip: [10.173.152.4]
Content-Type: multipart/alternative; boundary="_000_FF8F219EAB2E48F5AD90DEA783343C1Bverisigncom_"
MIME-Version: 1.0
Archived-At: 
Subject: [OAUTH-WG] =?utf-8?q?Building_on_the_protocol_in_the_draft_?= =?utf-8?q?=E2=80=9COAuth__2=2E0_Token_Exchange=3A_An_STS_for_the_REST_of_?= =?utf-8?q?Us=E2=80=9D_to_include_Authentication_Tokens?=
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Apr 2016 16:18:58 -0000

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

SSBoYXZlIGEgdXNlIGNhc2Ugd2hlcmUgYSBjbGllbnQgYXBwbGljYXRpb24gbmVlZHMgdG8gYXV0
aGVudGljYXRlIHdpdGggYSBkeW5hbWljYWxseSBkZXRlcm1pbmVkIElkZW50aXR5IFByb3ZpZGVy
IHRoYXQgaXMgc2VwYXJhdGUgZnJvbSB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2aWNlIHRoYXQgd2ls
bCBiZSB1c2VkIGlzc3VlIGFuIGFjY2VzcyB0b2tlbiB0byB0aGUgY2xpZW50LiBUaGUgdXNlIGNh
c2UgYWxzbyByZXF1aXJlcyB0aGF0IGFzIHBhcnQgb2YgYXV0aG9yaXphdGlvbiwgdGhlIGNsaWVu
dCBwcm92aWRlcyB0byB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2aWNlIGFuIGF1dGhlbnRpY2F0aW9u
IHRva2VuIHNpZ25lZCBieSBhbiBJZGVudGl0eSBQcm92aWRlciB0aGF0IHRoZSBBdXRob3JpemF0
aW9uIFNlcnZpY2UgaGFzIGEgdHJ1c3QgcmVsYXRpb25zaGlwIHdpdGguIFRoZSB0cnVzdCByZWxh
dGlvbnNoaXAgaXMgdmVyaWZpYWJsZSBiYXNlZCBvbiB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2aWNl
IGhhdmluZyByZWNvcmRlZCB0aGUgcHVibGljIGtleXMgb3IgY2VydGlmaWNhdGVzIG9mIHRydXN0
ZWQgSWRlbnRpdHkgUHJvdmlkZXJzIGluIGEgdHJ1c3Qgc3RvcmUsIHRoaXMgYWxsb3dpbmcgdGhl
IEF1dGhvcml6YXRpb24gU2VydmljZSB0byB2ZXJpZnkgYW4gSWRlbnRpdHkgUHJvdmlkZXLigJlz
IHNpZ25hdHVyZSBvbiBhbiBhdXRoZW50aWNhdGlvbiB0b2tlbi4NCg0KSW4gbG9va2luZyBhdCB0
aGUgdmFyaW91cyBPQXV0aCBSRkNzLCBwYXJ0aWN1bGFybHkgUkZDcyA3NTIxLCA3NTIyLCBhbmQg
NzUyMywgSSBzZWUgdGhhdCB0aGV5IGdldCBtZSBjbG9zZSBpbiB0ZXJtcyBvZiBzdXBwb3J0aW5n
IHRoZSB1c2UgY2FzZS4gV2hhdCBpcyBtaXNzaW5nIGlzIGEgbWVhbnMgZm9yIHNvbHZpbmcgdGhl
IGZvbGxvd2luZyBwcm9ibGVtLiBUaGVzZSBSRkNzIHJlcXVpcmUgdGhhdCB0aGUgSWRlbnRpdHkg
UHJvdmlkZXIgcHV0IGFuIEF1ZGllbmNlIGNsYWltIGluIHRoZSBhdXRoZW50aWNhdGlvbiB0b2tl
bi4gVGhlIHByb2JsZW0gd2l0aCB0aGlzIGlzIHRoYXQgSSBkbyBub3Qgc2VlIGluIHRoZSBSRkNz
IGhvdyB0aGUgSWRlbnRpdHkgUHJvdmlkZXIgY2FuIGJlIHRvbGQgd2hvIHRoZSBBdWRpZW5jZSBp
cyB0byBwdXQgaW50byB0aGUgYXV0aGVudGljYXRpb24gdG9rZW4uIFRoaXMgbGVhZHMgbWUgdG8g
dGhlIHRpdGxlIG9mIHRoaXMgbWVzc2FnZS4gVGhlIGRyYWZ0IOKAnE9BdXRoIDIuMCBUb2tlbiBF
eGNoYW5nZTogQW4gU1RTIGZvciB0aGUgUkVTVCBvZiBVc+KAnSBkZWZpbmVzIGEgbWVjaGFuaXNt
IGZvciBpZGVudGlmeWluZyB0aGUgQXVkaWVuY2UgZm9yIGFuIFNUUyB0byBwdXQgaW50byBhIHRv
a2VuIGl0IGdlbmVyYXRlcy4gVGhhdCB3b3VsZCBzb2x2ZSBteSBwcm9ibGVtIGV4Y2VwdCB0aGF0
IHRoZSBkcmFmdCBsaW1pdHMgdGhlIHR5cGUgb2YgU1RTIHRvIGJlaW5nIEF1dGhvcml6YXRpb24g
U2VydmVycy4gV2hhdCBpcyBuZWVkZWQgaXMgdGhpcyBzYW1lIGNhcGFiaWxpdHkgZm9yIGludGVy
YWN0aW5nIHdpdGggYW4gSWRlbnRpdHkgUHJvdmlkZXIuIFRoaXMgd291bGQgZW5hYmxlIFJGQ3Mg
NzUyMSwgNzUyMiBhbmQgNzUyMyB0byBiZSB1c2VmdWwgaW4gc2l0dWF0aW9uIHdoZXJlIHRoZSBJ
ZGVudGl0eSBQcm92aWRlciBuZWVkcyB0byBiZSB0b2xkIHRoZSBpZGVudGl0eSBvZiB0aGUgQXV0
aG9yaXphdGlvbiBTZXJ2aWNlLg0KDQpJIGFtIG5ldyB0byBpbnRlcmFjdGluZyB3aXRoIHRoZSBJ
RVRGLiBJIGFsc28gYW0gbm90IGFuIGV4cGVydCBvbiB0aGUgUkZDcyBvciBwcmlvciBoaXN0b3J5
IG9mIHRoZSBPQXV0aCBncm91cCByZWxhdGl2ZSB0byB0aGlzIHRvcGljLCBzbyBwbGVhc2UgcG9p
bnQgbWUgdG8gYW55IGV4aXN0aW5nIHNvbHV0aW9uIGlmIHRoaXMgaXMgYSBzb2x2ZWQgcHJvYmxl
bS4gT3RoZXJ3aXNlLCBJIHdvdWxkIGxpa2UgdG8gZ2V0IGZlZWRiYWNrIG9uIG15IHN1Z2dlc3Rp
b24uDQoNClRoYW5rcyBZb3UsDQoNCkFuZHJldyBGcmVnbHkNClZlcmlzaWduIEluYy4NCg==

--_000_FF8F219EAB2E48F5AD90DEA783343C1Bverisigncom_
Content-Type: text/html; charset="utf-8"
Content-ID: <4063561166623741B8022B1F23971ECA@verisign.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IlRpdGxlIiBjb250ZW50PSIi
Pg0KPG1ldGEgbmFtZT0iS2V5d29yZHMiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJQcm9nSWQi
IGNvbnRlbnQ9IldvcmQuRG9jdW1lbnQiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50
PSJNaWNyb3NvZnQgV29yZCAxNSI+DQo8bWV0YSBuYW1lPSJPcmlnaW5hdG9yIiBjb250ZW50PSJN
aWNyb3NvZnQgV29yZCAxNSI+DQo8bGluayByZWw9IkZpbGUtTGlzdCIgaHJlZj0iZmlsZTovL2xv
Y2FsaG9zdC9Vc2Vycy9hZnJlZ2x5L0xpYnJhcnkvR3JvdXAlMjBDb250YWluZXJzL1VCRjhUMzQ2
RzkuT2ZmaWNlL21zb2NsaXAxLzAxL2NsaXBfZmlsZWxpc3QueG1sIj48IS0tW2lmIGd0ZSBtc28g
OV0+PHhtbD4NCiA8bzpPZmZpY2VEb2N1bWVudFNldHRpbmdzPg0KICA8bzpBbGxvd1BORy8+DQog
IDxvOlBpeGVsc1BlckluY2g+OTY8L286UGl4ZWxzUGVySW5jaD4NCiA8L286T2ZmaWNlRG9jdW1l
bnRTZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjxsaW5rIHJlbD0idGhlbWVEYXRhIiBocmVm
PSJmaWxlOi8vbG9jYWxob3N0L1VzZXJzL2FmcmVnbHkvTGlicmFyeS9Hcm91cCUyMENvbnRhaW5l
cnMvVUJGOFQzNDZHOS5PZmZpY2UvbXNvY2xpcDEvMDEvY2xpcF90aGVtZWRhdGEudGhteCI+PCEt
LVtpZiBndGUgbXNvIDldPjx4bWw+DQogPHc6V29yZERvY3VtZW50Pg0KICA8dzpWaWV3Pk5vcm1h
bDwvdzpWaWV3Pg0KICA8dzpab29tPjA8L3c6Wm9vbT4NCiAgPHc6VHJhY2tNb3Zlcy8+DQogIDx3
OlRyYWNrRm9ybWF0dGluZy8+DQogIDx3OlB1bmN0dWF0aW9uS2VybmluZy8+DQogIDx3OlZhbGlk
YXRlQWdhaW5zdFNjaGVtYXMvPg0KICA8dzpTYXZlSWZYTUxJbnZhbGlkPmZhbHNlPC93OlNhdmVJ
ZlhNTEludmFsaWQ+DQogIDx3Oklnbm9yZU1peGVkQ29udGVudD5mYWxzZTwvdzpJZ25vcmVNaXhl
ZENvbnRlbnQ+DQogIDx3OkFsd2F5c1Nob3dQbGFjZWhvbGRlclRleHQ+ZmFsc2U8L3c6QWx3YXlz
U2hvd1BsYWNlaG9sZGVyVGV4dD4NCiAgPHc6RG9Ob3RQcm9tb3RlUUYvPg0KICA8dzpMaWRUaGVt
ZU90aGVyPkVOLVVTPC93OkxpZFRoZW1lT3RoZXI+DQogIDx3OkxpZFRoZW1lQXNpYW4+WC1OT05F
PC93OkxpZFRoZW1lQXNpYW4+DQogIDx3OkxpZFRoZW1lQ29tcGxleFNjcmlwdD5YLU5PTkU8L3c6
TGlkVGhlbWVDb21wbGV4U2NyaXB0Pg0KICA8dzpDb21wYXRpYmlsaXR5Pg0KICAgPHc6QnJlYWtX
cmFwcGVkVGFibGVzLz4NCiAgIDx3OlNuYXBUb0dyaWRJbkNlbGwvPg0KICAgPHc6V3JhcFRleHRX
aXRoUHVuY3QvPg0KICAgPHc6VXNlQXNpYW5CcmVha1J1bGVzLz4NCiAgIDx3OkRvbnRHcm93QXV0
b2ZpdC8+DQogICA8dzpTcGxpdFBnQnJlYWtBbmRQYXJhTWFyay8+DQogICA8dzpFbmFibGVPcGVu
VHlwZUtlcm5pbmcvPg0KICAgPHc6RG9udEZsaXBNaXJyb3JJbmRlbnRzLz4NCiAgIDx3Ok92ZXJy
aWRlVGFibGVTdHlsZUhwcy8+DQogIDwvdzpDb21wYXRpYmlsaXR5Pg0KICA8bTptYXRoUHI+DQog
ICA8bTptYXRoRm9udCBtOnZhbD0iQ2FtYnJpYSBNYXRoIi8+DQogICA8bTpicmtCaW4gbTp2YWw9
ImJlZm9yZSIvPg0KICAgPG06YnJrQmluU3ViIG06dmFsPSImIzQ1Oy0iLz4NCiAgIDxtOnNtYWxs
RnJhYyBtOnZhbD0ib2ZmIi8+DQogICA8bTpkaXNwRGVmLz4NCiAgIDxtOmxNYXJnaW4gbTp2YWw9
IjAiLz4NCiAgIDxtOnJNYXJnaW4gbTp2YWw9IjAiLz4NCiAgIDxtOmRlZkpjIG06dmFsPSJjZW50
ZXJHcm91cCIvPg0KICAgPG06d3JhcEluZGVudCBtOnZhbD0iMTQ0MCIvPg0KICAgPG06aW50TGlt
IG06dmFsPSJzdWJTdXAiLz4NCiAgIDxtOm5hcnlMaW0gbTp2YWw9InVuZE92ciIvPg0KICA8L206
bWF0aFByPjwvdzpXb3JkRG9jdW1lbnQ+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt
c28gOV0+PHhtbD4NCiA8dzpMYXRlbnRTdHlsZXMgRGVmTG9ja2VkU3RhdGU9ImZhbHNlIiBEZWZV
bmhpZGVXaGVuVXNlZD0iZmFsc2UiDQogIERlZlNlbWlIaWRkZW49ImZhbHNlIiBEZWZRRm9ybWF0
PSJmYWxzZSIgRGVmUHJpb3JpdHk9Ijk5Ig0KICBMYXRlbnRTdHlsZUNvdW50PSIzODAiPg0KICA8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjAiIFFGb3JtYXQ9InRydWUi
IE5hbWU9Ik5vcm1hbCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp
dHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgMSIvPg0KICA8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49InRydWUiDQogICBVbmhp
ZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyAyIi8+DQogIDx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1
ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5n
IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1p
SGlkZGVuPSJ0cnVlIg0KICAgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5h
bWU9ImhlYWRpbmcgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp
dHk9IjkiIFNlbWlIaWRkZW49InRydWUiDQogICBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1h
dD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJ0
cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDYiLz4NCiAgPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIg0KICAgVW5oaWRl
V2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgNyIvPg0KICA8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49InRydWUi
DQogICBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA4
Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhp
ZGRlbj0idHJ1ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1l
PSJoZWFkaW5nIDkiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk
ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iaW5kZXggMSIvPg0KICA8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl
blVzZWQ9InRydWUiDQogICBOYW1lPSJpbmRleCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5h
bWU9ImluZGV4IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk
ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iaW5kZXggNCIvPg0KICA8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl
blVzZWQ9InRydWUiDQogICBOYW1lPSJpbmRleCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5h
bWU9ImluZGV4IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk
ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iaW5kZXggNyIvPg0KICA8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl
blVzZWQ9InRydWUiDQogICBOYW1lPSJpbmRleCA4Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5h
bWU9ImluZGV4IDkiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5
PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0
b2MgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBT
ZW1pSGlkZGVuPSJ0cnVlIg0KICAgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyAyIi8+
DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRk
ZW49InRydWUiDQogICBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDMiLz4NCiAgPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1
ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgNCIvPg0KICA8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIg0KICAg
VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiDQogICBVbmhpZGVX
aGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i
ZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSINCiAgIFVuaGlkZVdoZW5Vc2Vk
PSJ0cnVlIiBOYW1lPSJ0b2MgNyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg
UHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIg0KICAgVW5oaWRlV2hlblVzZWQ9InRydWUi
IE5hbWU9InRvYyA4Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0
eT0iMzkiIFNlbWlIaWRkZW49InRydWUiDQogICBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i
dG9jIDkiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy
dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iTm9ybWFsIEluZGVudCIvPg0KICA8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl
blVzZWQ9InRydWUiDQogICBOYW1lPSJmb290bm90ZSB0ZXh0Ii8+DQogIDx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIN
CiAgIE5hbWU9ImFubm90YXRpb24gdGV4dCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJo
ZWFkZXIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy
dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iZm9vdGVyIi8+DQogIDx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i
dHJ1ZSINCiAgIE5hbWU9ImluZGV4IGhlYWRpbmciLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0iZmFsc2UiIFByaW9yaXR5PSIzNSIgU2VtaUhpZGRlbj0idHJ1ZSINCiAgIFVuaGlkZVdoZW5V
c2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJjYXB0aW9uIi8+DQogIDx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1
ZSINCiAgIE5hbWU9InRhYmxlIG9mIGZpZ3VyZXMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFt
ZT0iZW52ZWxvcGUgYWRkcmVzcyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg
U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJlbnZlbG9w
ZSByZXR1cm4iLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49
InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iZm9vdG5vdGUgcmVmZXJlbmNl
Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV
bmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9ImFubm90YXRpb24gcmVmZXJlbmNlIi8+DQog
IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX
aGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9ImxpbmUgbnVtYmVyIi8+DQogIDx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIN
CiAgIE5hbWU9InBhZ2UgbnVtYmVyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl
IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9ImVuZG5v
dGUgcmVmZXJlbmNlIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk
ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9ImVuZG5vdGUgdGV4dCIv
Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o
aWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJ0YWJsZSBvZiBhdXRob3JpdGllcyIvPg0KICA8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl
blVzZWQ9InRydWUiDQogICBOYW1lPSJtYWNybyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1l
PSJ0b2EgaGVhZGluZyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp
ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJMaXN0Ii8+DQogIDx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu
VXNlZD0idHJ1ZSINCiAgIE5hbWU9Ikxpc3QgQnVsbGV0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAg
IE5hbWU9Ikxpc3QgTnVtYmVyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT
ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ikxpc3QgMiIv
Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o
aWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJMaXN0IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0K
ICAgTmFtZT0iTGlzdCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p
SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ikxpc3QgNSIvPg0K
ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl
V2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJMaXN0IEJ1bGxldCAyIi8+DQogIDx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1
ZSINCiAgIE5hbWU9Ikxpc3QgQnVsbGV0IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i
ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0i
TGlzdCBCdWxsZXQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp
ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJMaXN0IEJ1bGxldCA1
Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV
bmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ikxpc3QgTnVtYmVyIDIiLz4NCiAgPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk
PSJ0cnVlIg0KICAgTmFtZT0iTGlzdCBOdW1iZXIgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j
a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBO
YW1lPSJMaXN0IE51bWJlciA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT
ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ikxpc3QgTnVt
YmVyIDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxMCIg
UUZvcm1hdD0idHJ1ZSIgTmFtZT0iVGl0bGUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i
ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0i
Q2xvc2luZyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i
dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJTaWduYXR1cmUiLz4NCiAgPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxIiBTZW1pSGlkZGVuPSJ0cnVl
Ig0KICAgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkRlZmF1bHQgUGFyYWdyYXBoIEZvbnQi
Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu
aGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iQm9keSBUZXh0Ii8+DQogIDx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1
ZSINCiAgIE5hbWU9IkJvZHkgVGV4dCBJbmRlbnQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFt
ZT0iTGlzdCBDb250aW51ZSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt
aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJMaXN0IENvbnRp
bnVlIDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy
dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iTGlzdCBDb250aW51ZSAzIi8+DQog
IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX
aGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ikxpc3QgQ29udGludWUgNCIvPg0KICA8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy
dWUiDQogICBOYW1lPSJMaXN0IENvbnRpbnVlIDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFt
ZT0iTWVzc2FnZSBIZWFkZXIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy
aW9yaXR5PSIxMSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGl0bGUiLz4NCiAgPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0
cnVlIg0KICAgTmFtZT0iU2FsdXRhdGlvbiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJE
YXRlIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl
IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IkJvZHkgVGV4dCBGaXJzdCBJbmRlbnQi
Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu
aGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iQm9keSBUZXh0IEZpcnN0IEluZGVudCAyIi8+
DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp
ZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ik5vdGUgSGVhZGluZyIvPg0KICA8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy
dWUiDQogICBOYW1lPSJCb2R5IFRleHQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJC
b2R5IFRleHQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl
bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJCb2R5IFRleHQgSW5kZW50
IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi
IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iQm9keSBUZXh0IEluZGVudCAzIi8+DQog
IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX
aGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IkJsb2NrIFRleHQiLz4NCiAgPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0K
ICAgTmFtZT0iSHlwZXJsaW5rIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT
ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IkZvbGxvd2Vk
SHlwZXJsaW5rIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i
MjIiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN0cm9uZyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j
a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIwIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJFbXBoYXNpcyIv
Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o
aWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJEb2N1bWVudCBNYXAiLz4NCiAgPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0
cnVlIg0KICAgTmFtZT0iUGxhaW4gVGV4dCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJF
LW1haWwgU2lnbmF0dXJlIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p
SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IkhUTUwgVG9wIG9m
IEZvcm0iLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy
dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iSFRNTCBCb3R0b20gb2YgRm9ybSIv
Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o
aWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJOb3JtYWwgKFdlYikiLz4NCiAgPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0
cnVlIg0KICAgTmFtZT0iSFRNTCBBY3JvbnltIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9
IkhUTUwgQWRkcmVzcyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp
ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJIVE1MIENpdGUiLz4N
CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk
ZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iSFRNTCBDb2RlIi8+DQogIDx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIN
CiAgIE5hbWU9IkhUTUwgRGVmaW5pdGlvbiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJI
VE1MIEtleWJvYXJkIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk
ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IkhUTUwgUHJlZm9ybWF0
dGVkIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl
IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IkhUTUwgU2FtcGxlIi8+DQogIDx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl
ZD0idHJ1ZSINCiAgIE5hbWU9IkhUTUwgVHlwZXdyaXRlciIvPg0KICA8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQog
ICBOYW1lPSJIVE1MIFZhcmlhYmxlIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl
IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ik5vcm1h
bCBUYWJsZSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i
dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJhbm5vdGF0aW9uIHN1YmplY3Qi
Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu
aGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iTm8gTGlzdCIvPg0KICA8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi
DQogICBOYW1lPSJPdXRsaW5lIExpc3QgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJP
dXRsaW5lIExpc3QgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp
ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJPdXRsaW5lIExpc3Qg
MyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg
VW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBTaW1wbGUgMSIvPg0KICA8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz
ZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBTaW1wbGUgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQog
ICBOYW1lPSJUYWJsZSBTaW1wbGUgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJs
ZSBDbGFzc2ljIDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk
ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgQ2xhc3NpYyAy
Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV
bmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIENsYXNzaWMgMyIvPg0KICA8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz
ZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBDbGFzc2ljIDQiLz4NCiAgPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0K
ICAgTmFtZT0iVGFibGUgQ29sb3JmdWwgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJU
YWJsZSBDb2xvcmZ1bCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p
SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIENvbG9y
ZnVsIDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy
dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgQ29sdW1ucyAxIi8+DQog
IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX
aGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIENvbHVtbnMgMiIvPg0KICA8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy
dWUiDQogICBOYW1lPSJUYWJsZSBDb2x1bW5zIDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFt
ZT0iVGFibGUgQ29sdW1ucyA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT
ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIENv
bHVtbnMgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i
dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBHcmlkIDEiLz4NCiAg
PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo
ZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgR3JpZCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIN
CiAgIE5hbWU9IlRhYmxlIEdyaWQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJs
ZSBHcmlkIDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49
InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgR3JpZCA1Ii8+DQog
IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX
aGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIEdyaWQgNiIvPg0KICA8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi
DQogICBOYW1lPSJUYWJsZSBHcmlkIDciLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs
c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFi
bGUgR3JpZCA4Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu
PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIExpc3QgMSIvPg0K
ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl
V2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBMaXN0IDIiLz4NCiAgPHc6THNkRXhjZXB0
aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl
Ig0KICAgTmFtZT0iVGFibGUgTGlzdCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRh
YmxlIExpc3QgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl
bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBMaXN0IDUiLz4N
CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk
ZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgTGlzdCA2Ii8+DQogIDx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1
ZSINCiAgIE5hbWU9IlRhYmxlIExpc3QgNyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJU
YWJsZSBMaXN0IDgiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk
ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgM0QgZWZmZWN0
cyAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl
IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIDNEIGVmZmVjdHMgMiIvPg0K
ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl
V2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSAzRCBlZmZlY3RzIDMiLz4NCiAgPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk
PSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgQ29udGVtcG9yYXJ5Ii8+DQogIDx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIN
CiAgIE5hbWU9IlRhYmxlIEVsZWdhbnQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs
c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFi
bGUgUHJvZmVzc2lvbmFsIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p
SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIFN1YnRs
ZSAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl
IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIFN1YnRsZSAyIi8+DQogIDx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu
VXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIFdlYiAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAg
IE5hbWU9IlRhYmxlIFdlYiAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT
ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIFdl
YiAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl
IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IkJhbGxvb24gVGV4dCIvPg0KICA8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJUYWJsZSBHcmlk
Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV
bmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIFRoZW1lIi8+DQogIDx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i
dHJ1ZSINCiAgIE5hbWU9Ik5vdGUgTGV2ZWwgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1l
PSJOb3RlIExldmVsIDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI
aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iTm90ZSBMZXZlbCAz
Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV
bmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ik5vdGUgTGV2ZWwgNCIvPg0KICA8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9
InRydWUiDQogICBOYW1lPSJOb3RlIExldmVsIDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFt
ZT0iTm90ZSBMZXZlbCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p
SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ik5vdGUgTGV2ZWwg
NyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg
VW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJOb3RlIExldmVsIDgiLz4NCiAgPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk
PSJ0cnVlIg0KICAgTmFtZT0iTm90ZSBMZXZlbCA5Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBOYW1lPSJQbGFjZWhvbGRlciBUZXh0Ii8+DQog
IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMSIgUUZvcm1hdD0idHJ1
ZSIgTmFtZT0iTm8gU3BhY2luZyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg
UHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdodCBTaGFkaW5nIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3QiLz4NCiAgPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCIv
Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJN
ZWRpdW0gU2hhZGluZyAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv
cml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVkaXVtIExpc3QgMSIvPg0KICA8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlz
dCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIE5h
bWU9Ik1lZGl1bSBHcmlkIDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy
aW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j
a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAzIi8+DQogIDx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIE5hbWU9IkRhcmsgTGlzdCIv
Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBOYW1lPSJD
b2xvcmZ1bCBTaGFkaW5nIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv
cml0eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExpc3QiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCIvPg0KICA8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdodCBTaGFkaW5n
IEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i
NjEiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgMSIvPg0KICA8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0g
U2hhZGluZyAxIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ
cmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDEiLz4NCiAgPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVkaXVtIExpc3Qg
MSBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl
bj0idHJ1ZSIgTmFtZT0iUmV2aXNpb24iLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs
c2UiIFByaW9yaXR5PSIzNCIgUUZvcm1hdD0idHJ1ZSINCiAgIE5hbWU9Ikxpc3QgUGFyYWdyYXBo
Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjkiIFFGb3Jt
YXQ9InRydWUiIE5hbWU9IlF1b3RlIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl
IiBQcmlvcml0eT0iMzAiIFFGb3JtYXQ9InRydWUiDQogICBOYW1lPSJJbnRlbnNlIFF1b3RlIi8+
DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1l
ZGl1bSBMaXN0IDIgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui
IFByaW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgMSIvPg0KICA8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAy
IEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i
NjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCAxIi8+DQog
IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9y
ZnVsIFNoYWRpbmcgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui
IFByaW9yaXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgMSIvPg0KICA8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlk
IEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i
NjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgMiIvPg0K
ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdo
dCBHcmlkIEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv
cml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFtZT0iTWVkaXVtIFNoYWRpbmcg
MiBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9
IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDIi
Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFtZT0i
TWVkaXVtIEdyaWQgMSBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCAyIi8+DQogIDx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlk
IDMgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5
PSI3MCIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDIi
Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgTmFtZT0i
Q29sb3JmdWwgTGlzdCBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAyIi8+DQogIDx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRp
bmcgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5
PSI2MSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j
a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAzIi8+DQog
IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1
bSBTaGFkaW5nIDEgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui
IFByaW9yaXR5PSI2NCIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMyIvPg0KICA8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlz
dCAxIEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0
eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQg
MyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1l
PSJNZWRpdW0gR3JpZCAyIEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBQcmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDMiLz4NCiAgPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0
IEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i
NzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQg
MyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBOYW1l
PSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDQiLz4NCiAgPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgTmFtZT0iTGlnaHQgTGlz
dCBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9
IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDQi
Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFtZT0i
TWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCA0Ii8+DQogIDx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1lZGl1bSBM
aXN0IDIgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y
aXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2Vu
dCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5h
bWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i
ZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA0Ii8+DQogIDx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNo
YWRpbmcgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y
aXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2Vu
dCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5h
bWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i
ZmFsc2UiIFByaW9yaXR5PSI2MSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNSIvPg0KICA8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlk
IEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i
NjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2Nl
bnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBO
YW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDUiLz4NCiAg
PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVt
IEdyaWQgMSBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp
b3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNj
ZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIg
TmFtZT0iRGFyayBMaXN0IEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDUiLz4NCiAg
PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgTmFtZT0iQ29sb3Jm
dWwgTGlzdCBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp
b3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNj
ZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIg
TmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCA2Ii8+DQogIDx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFk
aW5nIDEgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y
aXR5PSI2NCIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFj
Y2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYi
IE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgNiIvPg0K
ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRp
dW0gR3JpZCAyIEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ
cmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0IEFjY2Vu
dCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5h
bWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNiIvPg0K
ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xv
cmZ1bCBHcmlkIEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ
cmlvcml0eT0iMTkiIFFGb3JtYXQ9InRydWUiDQogICBOYW1lPSJTdWJ0bGUgRW1waGFzaXMiLz4N
CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyMSIgUUZvcm1hdD0i
dHJ1ZSINCiAgIE5hbWU9IkludGVuc2UgRW1waGFzaXMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzMSIgUUZvcm1hdD0idHJ1ZSINCiAgIE5hbWU9IlN1YnRs
ZSBSZWZlcmVuY2UiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5
PSIzMiIgUUZvcm1hdD0idHJ1ZSINCiAgIE5hbWU9IkludGVuc2UgUmVmZXJlbmNlIi8+DQogIDx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzMiIFFGb3JtYXQ9InRydWUi
IE5hbWU9IkJvb2sgVGl0bGUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy
aW9yaXR5PSIzNyIgU2VtaUhpZGRlbj0idHJ1ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO
YW1lPSJCaWJsaW9ncmFwaHkiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy
aW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBR
Rm9ybWF0PSJ0cnVlIiBOYW1lPSJUT0MgSGVhZGluZyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j
a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQxIiBOYW1lPSJQbGFpbiBUYWJsZSAxIi8+DQogIDx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDIiIE5hbWU9IlBsYWluIFRhYmxl
IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0MyIgTmFt
ZT0iUGxhaW4gVGFibGUgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp
b3JpdHk9IjQ0IiBOYW1lPSJQbGFpbiBUYWJsZSA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDUiIE5hbWU9IlBsYWluIFRhYmxlIDUiLz4NCiAgPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0MCIgTmFtZT0iR3JpZCBUYWJsZSBM
aWdodCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBO
YW1lPSJHcmlkIFRhYmxlIDEgTGlnaHQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs
c2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIi8+DQogIDx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyIvPg0KICA8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJHcmlkIFRh
YmxlIDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIg
TmFtZT0iR3JpZCBUYWJsZSA1IERhcmsiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs
c2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iR3JpZCBUYWJsZSA2IENvbG9yZnVsIi8+DQogIDx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9IkdyaWQgVGFibGUg
NyBDb2xvcmZ1bCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9
IjQ2Ig0KICAgTmFtZT0iR3JpZCBUYWJsZSAxIExpZ2h0IEFjY2VudCAxIi8+DQogIDx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiBB
Y2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4
IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iR3JpZCBUYWJsZSA0IEFjY2VudCAxIi8+DQog
IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9IkdyaWQg
VGFibGUgNSBEYXJrIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl
IiBQcmlvcml0eT0iNTEiDQogICBOYW1lPSJHcmlkIFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDEi
Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiINCiAgIE5h
bWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2Ig0KICAgTmFtZT0iR3JpZCBUYWJsZSAxIExpZ2h0
IEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i
NDciIE5hbWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j
a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50IDIiLz4N
CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iR3Jp
ZCBUYWJsZSA0IEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ
cmlvcml0eT0iNTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCAyIi8+DQogIDx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiDQogICBOYW1lPSJHcmlkIFRh
YmxlIDYgQ29sb3JmdWwgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs
c2UiIFByaW9yaXR5PSI1MiINCiAgIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQg
MiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2Ig0KICAg
TmFtZT0iR3JpZCBUYWJsZSAxIExpZ2h0IEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgMyIv
Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJH
cmlkIFRhYmxlIDMgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui
IFByaW9yaXR5PSI0OSIgTmFtZT0iR3JpZCBUYWJsZSA0IEFjY2VudCAzIi8+DQogIDx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9IkdyaWQgVGFibGUgNSBE
YXJrIEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0
eT0iNTEiDQogICBOYW1lPSJHcmlkIFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDMiLz4NCiAgPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiINCiAgIE5hbWU9IkdyaWQg
VGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgUHJpb3JpdHk9IjQ2Ig0KICAgTmFtZT0iR3JpZCBUYWJsZSAxIExpZ2h0IEFjY2VudCA0
Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9
IkdyaWQgVGFibGUgMiBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50IDQiLz4NCiAgPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iR3JpZCBUYWJsZSA0
IEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i
NTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiDQogICBOYW1lPSJHcmlkIFRhYmxlIDYgQ29s
b3JmdWwgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y
aXR5PSI1MiINCiAgIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNCIvPg0KICA8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2Ig0KICAgTmFtZT0iR3Jp
ZCBUYWJsZSAxIExpZ2h0IEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBQcmlvcml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgNSIvPg0KICA8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxl
IDMgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5
PSI0OSIgTmFtZT0iR3JpZCBUYWJsZSA0IEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2Vu
dCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiDQog
ICBOYW1lPSJHcmlkIFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0
aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiINCiAgIE5hbWU9IkdyaWQgVGFibGUgNyBD
b2xvcmZ1bCBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp
b3JpdHk9IjQ2Ig0KICAgTmFtZT0iR3JpZCBUYWJsZSAxIExpZ2h0IEFjY2VudCA2Ii8+DQogIDx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9IkdyaWQgVGFi
bGUgMiBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp
dHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iR3JpZCBUYWJsZSA0IEFjY2VudCA2
Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9
IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBQcmlvcml0eT0iNTEiDQogICBOYW1lPSJHcmlkIFRhYmxlIDYgQ29sb3JmdWwgQWNj
ZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIN
CiAgIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGln
aHQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFt
ZT0iTGlzdCBUYWJsZSAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv
cml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQiLz4NCiAgPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iTGlzdCBUYWJsZSA1IERh
cmsiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFt
ZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9Ikxpc3QgVGFibGUgNyBDb2xvcmZ1bCIvPg0KICA8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2Ig0KICAgTmFtZT0iTGlzdCBU
YWJsZSAxIExpZ2h0IEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl
IiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3QgVGFibGUgMiBBY2NlbnQgMSIvPg0KICA8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMg
QWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0
OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxpc3QgVGFibGUgNSBEYXJrIEFjY2VudCAx
Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiDQogICBO
YW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiINCiAgIE5hbWU9Ikxpc3QgVGFibGUgNyBDb2xv
cmZ1bCBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp
dHk9IjQ2Ig0KICAgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCAyIi8+DQogIDx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3QgVGFibGUg
MiBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9
IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2VudCAyIi8+
DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxp
c3QgVGFibGUgNSBEYXJrIEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBQcmlvcml0eT0iNTEiDQogICBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50
IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiINCiAg
IE5hbWU9Ikxpc3QgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2Ig0KICAgTmFtZT0iTGlzdCBUYWJsZSAxIExp
Z2h0IEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0
eT0iNDciIE5hbWU9Ikxpc3QgVGFibGUgMiBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDMi
Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0i
TGlzdCBUYWJsZSA0IEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl
IiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxpc3QgVGFibGUgNSBEYXJrIEFjY2VudCAzIi8+DQogIDx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiDQogICBOYW1lPSJMaXN0
IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i
ZmFsc2UiIFByaW9yaXR5PSI1MiINCiAgIE5hbWU9Ikxpc3QgVGFibGUgNyBDb2xvcmZ1bCBBY2Nl
bnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2Ig0K
ICAgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3QgVGFibGUgMiBBY2NlbnQg
NCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1l
PSJMaXN0IFRhYmxlIDMgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs
c2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2VudCA0Ii8+DQogIDx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxpc3QgVGFibGUg
NSBEYXJrIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv
cml0eT0iNTEiDQogICBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDQiLz4NCiAg
PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiINCiAgIE5hbWU9Ikxp
c3QgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PSJmYWxzZSIgUHJpb3JpdHk9IjQ2Ig0KICAgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2Vu
dCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5h
bWU9Ikxpc3QgVGFibGUgMiBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDUiLz4NCiAgPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJs
ZSA0IEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0
eT0iNTAiIE5hbWU9Ikxpc3QgVGFibGUgNSBEYXJrIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiDQogICBOYW1lPSJMaXN0IFRhYmxlIDYg
Q29sb3JmdWwgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy
aW9yaXR5PSI1MiINCiAgIE5hbWU9Ikxpc3QgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNSIvPg0K
ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2Ig0KICAgTmFtZT0i
TGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3QgVGFibGUgMiBBY2NlbnQgNiIvPg0KICA8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJMaXN0IFRh
YmxlIDMgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y
aXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxpc3QgVGFibGUgNSBEYXJrIEFj
Y2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEi
DQogICBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiINCiAgIE5hbWU9Ikxpc3QgVGFibGUg
NyBDb2xvcmZ1bCBBY2NlbnQgNiIvPg0KIDwvdzpMYXRlbnRTdHlsZXM+DQo8L3htbD48IVtlbmRp
Zl0tLT48c3R5bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg
MiA0Ow0KCW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTphdXRv
Ow0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTotNTM2ODcw
MTQ1IDExMDczMDU3MjcgMCAwIDQxNSAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2Fs
aWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDsNCgltc28tZm9udC1jaGFyc2V0
OjA7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6YXV0bzsNCgltc28tZm9udC1waXRjaDp2YXJp
YWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6LTUzNjg3MDE0NSAxMDczNzg2MTExIDEgMCA0MTUg
MDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bXNvLXN0eWxlLXVuaGlkZTpubzsNCgltc28tc3R5bGUtcWZvcm1h
dDp5ZXM7DQoJbXNvLXN0eWxlLXBhcmVudDoiIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjEy
LjBwdDsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1hc2NpaS1mb250LWZhbWlseTpDYWxp
YnJpOw0KCW1zby1hc2NpaS10aGVtZS1mb250Om1pbm9yLWxhdGluOw0KCW1zby1mYXJlYXN0LWZv
bnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWZhcmVhc3QtdGhlbWUtZm9udDptaW5vci1sYXRpbjsN
Cgltc28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28taGFuc2ktdGhlbWUtZm9udDpt
aW5vci1sYXRpbjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCglt
c28tYmlkaS10aGVtZS1mb250Om1pbm9yLWJpZGk7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0
eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLWRlZmF1bHQtcHJvcHM6eWVzOw0KCWZvbnQtZmFt
aWx5OkNhbGlicmk7DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWFzY2lp
LXRoZW1lLWZvbnQ6bWlub3ItbGF0aW47DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJy
aTsNCgltc28tZmFyZWFzdC10aGVtZS1mb250Om1pbm9yLWxhdGluOw0KCW1zby1oYW5zaS1mb250
LWZhbWlseTpDYWxpYnJpOw0KCW1zby1oYW5zaS10aGVtZS1mb250Om1pbm9yLWxhdGluOw0KCW1z
by1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1iaWRpLXRoZW1lLWZv
bnQ6bWlub3ItYmlkaTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47
DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluOw0KCW1zby1oZWFkZXItbWFyZ2luOi41
aW47DQoJbXNvLWZvb3Rlci1tYXJnaW46LjVpbjsNCgltc28tcGFwZXItc291cmNlOjA7fQ0KZGl2
LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT4NCjwvc3R5bGU+PCEtLVtp
ZiBndGUgbXNvIDEwXT4NCjxzdHlsZT4NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KdGFibGUu
TXNvTm9ybWFsVGFibGUNCgl7bXNvLXN0eWxlLW5hbWU6IlRhYmxlIE5vcm1hbCI7DQoJbXNvLXRz
dHlsZS1yb3diYW5kLXNpemU6MDsNCgltc28tdHN0eWxlLWNvbGJhbmQtc2l6ZTowOw0KCW1zby1z
dHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtcGFy
ZW50OiIiOw0KCW1zby1wYWRkaW5nLWFsdDowaW4gNS40cHQgMGluIDUuNHB0Ow0KCW1zby1wYXJh
LW1hcmdpbjowaW47DQoJbXNvLXBhcmEtbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdp
bmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OkNh
bGlicmk7DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWFzY2lpLXRoZW1l
LWZvbnQ6bWlub3ItbGF0aW47DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNv
LWhhbnNpLXRoZW1lLWZvbnQ6bWlub3ItbGF0aW47fQ0KPC9zdHlsZT4NCjwhW2VuZGlmXS0tPg0K
PC9oZWFkPg0KPGJvZHkgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNw
LW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyBjb2xv
cjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz
YW5zLXNlcmlmOyI+DQo8ZGl2PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOk9mZmljZURv
Y3VtZW50U2V0dGluZ3M+DQogIDxvOkFsbG93UE5HLz4NCiAgPG86UGl4ZWxzUGVySW5jaD45Njwv
bzpQaXhlbHNQZXJJbmNoPg0KIDwvbzpPZmZpY2VEb2N1bWVudFNldHRpbmdzPg0KPC94bWw+PCFb
ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPHc6V29yZERvY3VtZW50Pg0KICA8
dzpWaWV3Pk5vcm1hbDwvdzpWaWV3Pg0KICA8dzpab29tPjA8L3c6Wm9vbT4NCiAgPHc6VHJhY2tN
b3Zlcy8+DQogIDx3OlRyYWNrRm9ybWF0dGluZy8+DQogIDx3OlB1bmN0dWF0aW9uS2VybmluZy8+
DQogIDx3OlZhbGlkYXRlQWdhaW5zdFNjaGVtYXMvPg0KICA8dzpTYXZlSWZYTUxJbnZhbGlkPmZh
bHNlPC93OlNhdmVJZlhNTEludmFsaWQ+DQogIDx3Oklnbm9yZU1peGVkQ29udGVudD5mYWxzZTwv
dzpJZ25vcmVNaXhlZENvbnRlbnQ+DQogIDx3OkFsd2F5c1Nob3dQbGFjZWhvbGRlclRleHQ+ZmFs
c2U8L3c6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4dD4NCiAgPHc6RG9Ob3RQcm9tb3RlUUYvPg0K
ICA8dzpMaWRUaGVtZU90aGVyPkVOLVVTPC93OkxpZFRoZW1lT3RoZXI+DQogIDx3OkxpZFRoZW1l
QXNpYW4+WC1OT05FPC93OkxpZFRoZW1lQXNpYW4+DQogIDx3OkxpZFRoZW1lQ29tcGxleFNjcmlw
dD5YLU5PTkU8L3c6TGlkVGhlbWVDb21wbGV4U2NyaXB0Pg0KICA8dzpDb21wYXRpYmlsaXR5Pg0K
ICAgPHc6QnJlYWtXcmFwcGVkVGFibGVzLz4NCiAgIDx3OlNuYXBUb0dyaWRJbkNlbGwvPg0KICAg
PHc6V3JhcFRleHRXaXRoUHVuY3QvPg0KICAgPHc6VXNlQXNpYW5CcmVha1J1bGVzLz4NCiAgIDx3
OkRvbnRHcm93QXV0b2ZpdC8+DQogICA8dzpTcGxpdFBnQnJlYWtBbmRQYXJhTWFyay8+DQogICA8
dzpFbmFibGVPcGVuVHlwZUtlcm5pbmcvPg0KICAgPHc6RG9udEZsaXBNaXJyb3JJbmRlbnRzLz4N
CiAgIDx3Ok92ZXJyaWRlVGFibGVTdHlsZUhwcy8+DQogIDwvdzpDb21wYXRpYmlsaXR5Pg0KICA8
bTptYXRoUHI+DQogICA8bTptYXRoRm9udCBtOnZhbD0iQ2FtYnJpYSBNYXRoIi8+DQogICA8bTpi
cmtCaW4gbTp2YWw9ImJlZm9yZSIvPg0KICAgPG06YnJrQmluU3ViIG06dmFsPSImIzQ1Oy0iLz4N
CiAgIDxtOnNtYWxsRnJhYyBtOnZhbD0ib2ZmIi8+DQogICA8bTpkaXNwRGVmLz4NCiAgIDxtOmxN
YXJnaW4gbTp2YWw9IjAiLz4NCiAgIDxtOnJNYXJnaW4gbTp2YWw9IjAiLz4NCiAgIDxtOmRlZkpj
IG06dmFsPSJjZW50ZXJHcm91cCIvPg0KICAgPG06d3JhcEluZGVudCBtOnZhbD0iMTQ0MCIvPg0K
ICAgPG06aW50TGltIG06dmFsPSJzdWJTdXAiLz4NCiAgIDxtOm5hcnlMaW0gbTp2YWw9InVuZE92
ciIvPg0KICA8L206bWF0aFByPjwvdzpXb3JkRG9jdW1lbnQ+DQo8L3htbD48IVtlbmRpZl0tLT48
IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8dzpMYXRlbnRTdHlsZXMgRGVmTG9ja2VkU3RhdGU9
ImZhbHNlIiBEZWZVbmhpZGVXaGVuVXNlZD0iZmFsc2UiDQogIERlZlNlbWlIaWRkZW49ImZhbHNl
IiBEZWZRRm9ybWF0PSJmYWxzZSIgRGVmUHJpb3JpdHk9Ijk5Ig0KICBMYXRlbnRTdHlsZUNvdW50
PSIzODAiPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjAiIFFG
b3JtYXQ9InRydWUiIE5hbWU9Ik5vcm1hbCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgMSIvPg0KICA8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49InRy
dWUiDQogICBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGlu
ZyAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2Vt
aUhpZGRlbj0idHJ1ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBO
YW1lPSJoZWFkaW5nIDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y
aXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIg0KICAgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3Jt
YXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49InRydWUiDQogICBVbmhpZGVXaGVuVXNlZD0i
dHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSINCiAgIFVuaGlk
ZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDYiLz4NCiAgPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVl
Ig0KICAgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcg
NyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlI
aWRkZW49InRydWUiDQogICBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFt
ZT0iaGVhZGluZyA4Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0
eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0
PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDkiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs
c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iaW5k
ZXggMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1
ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJpbmRleCAyIi8+DQogIDx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i
dHJ1ZSINCiAgIE5hbWU9ImluZGV4IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs
c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iaW5k
ZXggNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1
ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJpbmRleCA1Ii8+DQogIDx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i
dHJ1ZSINCiAgIE5hbWU9ImluZGV4IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs
c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iaW5k
ZXggNyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1
ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJpbmRleCA4Ii8+DQogIDx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i
dHJ1ZSINCiAgIE5hbWU9ImluZGV4IDkiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs
c2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJ0
cnVlIiBOYW1lPSJ0b2MgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp
b3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIg0KICAgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h
bWU9InRvYyAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i
MzkiIFNlbWlIaWRkZW49InRydWUiDQogICBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9j
IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2Vt
aUhpZGRlbj0idHJ1ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgNCIvPg0K
ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVu
PSJ0cnVlIg0KICAgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyA1Ii8+DQogIDx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUi
DQogICBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDYiLz4NCiAgPHc6THNkRXhjZXB0
aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSINCiAgIFVu
aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgNyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j
a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIg0KICAgVW5oaWRlV2hl
blVzZWQ9InRydWUiIE5hbWU9InRvYyA4Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiDQogICBVbmhpZGVXaGVuVXNlZD0i
dHJ1ZSIgTmFtZT0idG9jIDkiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl
bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iTm9ybWFsIElu
ZGVudCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1
ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJmb290bm90ZSB0ZXh0Ii8+DQogIDx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu
VXNlZD0idHJ1ZSINCiAgIE5hbWU9ImFubm90YXRpb24gdGV4dCIvPg0KICA8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi
DQogICBOYW1lPSJoZWFkZXIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl
bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iZm9vdGVyIi8+
DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp
ZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9ImluZGV4IGhlYWRpbmciLz4NCiAgPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNSIgU2VtaUhpZGRlbj0idHJ1ZSINCiAg
IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJjYXB0aW9uIi8+DQog
IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX
aGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9InRhYmxlIG9mIGZpZ3VyZXMiLz4NCiAgPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0
cnVlIg0KICAgTmFtZT0iZW52ZWxvcGUgYWRkcmVzcyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j
a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBO
YW1lPSJlbnZlbG9wZSByZXR1cm4iLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui
IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iZm9vdG5v
dGUgcmVmZXJlbmNlIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk
ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9ImFubm90YXRpb24gcmVm
ZXJlbmNlIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0
cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9ImxpbmUgbnVtYmVyIi8+DQogIDx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu
VXNlZD0idHJ1ZSINCiAgIE5hbWU9InBhZ2UgbnVtYmVyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAg
IE5hbWU9ImVuZG5vdGUgcmVmZXJlbmNlIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9ImVu
ZG5vdGUgdGV4dCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl
bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJ0YWJsZSBvZiBhdXRob3Jp
dGllcyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1
ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJtYWNybyIvPg0KICA8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy
dWUiDQogICBOYW1lPSJ0b2EgaGVhZGluZyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJM
aXN0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl
IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ikxpc3QgQnVsbGV0Ii8+DQogIDx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl
ZD0idHJ1ZSINCiAgIE5hbWU9Ikxpc3QgTnVtYmVyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5h
bWU9Ikxpc3QgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl
bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJMaXN0IDMiLz4NCiAgPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V
c2VkPSJ0cnVlIg0KICAgTmFtZT0iTGlzdCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9
Ikxpc3QgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i
dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJMaXN0IEJ1bGxldCAyIi8+DQog
IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX
aGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ikxpc3QgQnVsbGV0IDMiLz4NCiAgPHc6THNkRXhjZXB0
aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl
Ig0KICAgTmFtZT0iTGlzdCBCdWxsZXQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJM
aXN0IEJ1bGxldCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk
ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ikxpc3QgTnVtYmVyIDIi
Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu
aGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iTGlzdCBOdW1iZXIgMyIvPg0KICA8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9
InRydWUiDQogICBOYW1lPSJMaXN0IE51bWJlciA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5h
bWU9Ikxpc3QgTnVtYmVyIDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy
aW9yaXR5PSIxMCIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iVGl0bGUiLz4NCiAgPHc6THNkRXhjZXB0
aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl
Ig0KICAgTmFtZT0iQ2xvc2luZyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg
U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJTaWduYXR1
cmUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxIiBTZW1p
SGlkZGVuPSJ0cnVlIg0KICAgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkRlZmF1bHQgUGFy
YWdyYXBoIEZvbnQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk
ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iQm9keSBUZXh0Ii8+DQog
IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX
aGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IkJvZHkgVGV4dCBJbmRlbnQiLz4NCiAgPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0
cnVlIg0KICAgTmFtZT0iTGlzdCBDb250aW51ZSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1l
PSJMaXN0IENvbnRpbnVlIDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl
bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iTGlzdCBDb250
aW51ZSAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0
cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ikxpc3QgQ29udGludWUgNCIvPg0K
ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl
V2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJMaXN0IENvbnRpbnVlIDUiLz4NCiAgPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0
cnVlIg0KICAgTmFtZT0iTWVzc2FnZSBIZWFkZXIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0iZmFsc2UiIFByaW9yaXR5PSIxMSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGl0bGUiLz4N
CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk
ZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iU2FsdXRhdGlvbiIvPg0KICA8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi
DQogICBOYW1lPSJEYXRlIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p
SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IkJvZHkgVGV4dCBG
aXJzdCBJbmRlbnQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk
ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iQm9keSBUZXh0IEZpcnN0
IEluZGVudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu
PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ik5vdGUgSGVhZGluZyIvPg0K
ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl
V2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJCb2R5IFRleHQgMiIvPg0KICA8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi
DQogICBOYW1lPSJCb2R5IFRleHQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJCb2R5
IFRleHQgSW5kZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI
aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iQm9keSBUZXh0IElu
ZGVudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0
cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IkJsb2NrIFRleHQiLz4NCiAgPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V
c2VkPSJ0cnVlIg0KICAgTmFtZT0iSHlwZXJsaW5rIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5h
bWU9IkZvbGxvd2VkSHlwZXJsaW5rIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl
IiBQcmlvcml0eT0iMjIiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN0cm9uZyIvPg0KICA8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIwIiBRRm9ybWF0PSJ0cnVlIiBOYW1l
PSJFbXBoYXNpcyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl
bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJEb2N1bWVudCBNYXAiLz4N
CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk
ZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iUGxhaW4gVGV4dCIvPg0KICA8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi
DQogICBOYW1lPSJFLW1haWwgU2lnbmF0dXJlIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9
IkhUTUwgVG9wIG9mIEZvcm0iLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl
bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iSFRNTCBCb3R0
b20gb2YgRm9ybSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl
bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJOb3JtYWwgKFdlYikiLz4N
CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk
ZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iSFRNTCBBY3JvbnltIi8+DQogIDx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1
ZSINCiAgIE5hbWU9IkhUTUwgQWRkcmVzcyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJI
VE1MIENpdGUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49
InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iSFRNTCBDb2RlIi8+DQogIDx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu
VXNlZD0idHJ1ZSINCiAgIE5hbWU9IkhUTUwgRGVmaW5pdGlvbiIvPg0KICA8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi
DQogICBOYW1lPSJIVE1MIEtleWJvYXJkIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IkhU
TUwgUHJlZm9ybWF0dGVkIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p
SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IkhUTUwgU2FtcGxl
Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV
bmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IkhUTUwgVHlwZXdyaXRlciIvPg0KICA8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz
ZWQ9InRydWUiDQogICBOYW1lPSJIVE1MIFZhcmlhYmxlIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAg
IE5hbWU9Ik5vcm1hbCBUYWJsZSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg
U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJhbm5vdGF0
aW9uIHN1YmplY3QiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk
ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iTm8gTGlzdCIvPg0KICA8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl
blVzZWQ9InRydWUiDQogICBOYW1lPSJPdXRsaW5lIExpc3QgMSIvPg0KICA8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi
DQogICBOYW1lPSJPdXRsaW5lIExpc3QgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJP
dXRsaW5lIExpc3QgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp
ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBTaW1wbGUg
MSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg
VW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBTaW1wbGUgMiIvPg0KICA8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz
ZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBTaW1wbGUgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQog
ICBOYW1lPSJUYWJsZSBDbGFzc2ljIDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs
c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFi
bGUgQ2xhc3NpYyAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk
ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIENsYXNzaWMg
MyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg
VW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBDbGFzc2ljIDQiLz4NCiAgPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V
c2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgQ29sb3JmdWwgMSIvPg0KICA8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi
DQogICBOYW1lPSJUYWJsZSBDb2xvcmZ1bCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9
IlRhYmxlIENvbG9yZnVsIDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl
bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgQ29s
dW1ucyAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0
cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIENvbHVtbnMgMiIvPg0K
ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl
V2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBDb2x1bW5zIDMiLz4NCiAgPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0
cnVlIg0KICAgTmFtZT0iVGFibGUgQ29sdW1ucyA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5h
bWU9IlRhYmxlIENvbHVtbnMgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg
U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBH
cmlkIDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy
dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgR3JpZCAyIi8+DQogIDx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu
VXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIEdyaWQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQog
ICBOYW1lPSJUYWJsZSBHcmlkIDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui
IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUg
R3JpZCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0
cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIEdyaWQgNiIvPg0KICA8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl
blVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBHcmlkIDciLz4NCiAgPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0K
ICAgTmFtZT0iVGFibGUgR3JpZCA4Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl
IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxl
IExpc3QgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i
dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBMaXN0IDIiLz4NCiAg
PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo
ZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgTGlzdCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIN
CiAgIE5hbWU9IlRhYmxlIExpc3QgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJs
ZSBMaXN0IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49
InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgTGlzdCA2Ii8+DQog
IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX
aGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIExpc3QgNyIvPg0KICA8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi
DQogICBOYW1lPSJUYWJsZSBMaXN0IDgiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs
c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFi
bGUgM0QgZWZmZWN0cyAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p
SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIDNEIGVm
ZmVjdHMgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i
dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSAzRCBlZmZlY3RzIDMi
Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu
aGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgQ29udGVtcG9yYXJ5Ii8+DQogIDx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu
VXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIEVsZWdhbnQiLz4NCiAgPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0K
ICAgTmFtZT0iVGFibGUgUHJvZmVzc2lvbmFsIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9
IlRhYmxlIFN1YnRsZSAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p
SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIFN1YnRs
ZSAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl
IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIFdlYiAxIi8+DQogIDx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl
ZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIFdlYiAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5h
bWU9IlRhYmxlIFdlYiAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p
SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IkJhbGxvb24gVGV4
dCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1l
PSJUYWJsZSBHcmlkIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk
ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIFRoZW1lIi8+
DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp
ZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ik5vdGUgTGV2ZWwgMSIvPg0KICA8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy
dWUiDQogICBOYW1lPSJOb3RlIExldmVsIDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i
ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0i
Tm90ZSBMZXZlbCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk
ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ik5vdGUgTGV2ZWwgNCIv
Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o
aWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJOb3RlIExldmVsIDUiLz4NCiAgPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0
cnVlIg0KICAgTmFtZT0iTm90ZSBMZXZlbCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9
Ik5vdGUgTGV2ZWwgNyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp
ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJOb3RlIExldmVsIDgi
Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu
aGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iTm90ZSBMZXZlbCA5Ii8+DQogIDx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBOYW1lPSJQbGFjZWhvbGRl
ciBUZXh0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMSIg
UUZvcm1hdD0idHJ1ZSIgTmFtZT0iTm8gU3BhY2luZyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j
a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdodCBTaGFkaW5nIi8+DQogIDx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3Qi
Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgTmFtZT0i
TGlnaHQgR3JpZCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9
IjYzIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIiLz4NCiAgPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVkaXVtIExpc3Qg
MSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1l
PSJNZWRpdW0gTGlzdCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv
cml0eT0iNjciIE5hbWU9Ik1lZGl1bSBHcmlkIDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiIvPg0KICA8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAz
Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIE5hbWU9
IkRhcmsgTGlzdCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9
IjcxIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExpc3QiLz4NCiAgPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCIv
Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJM
aWdodCBTaGFkaW5nIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl
IiBQcmlvcml0eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCBBY2Nl
bnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBO
YW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDEi
Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0i
TWVkaXVtIExpc3QgMSBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgTmFtZT0iUmV2aXNpb24iLz4NCiAgPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNCIgUUZvcm1hdD0idHJ1ZSINCiAgIE5hbWU9Ikxp
c3QgUGFyYWdyYXBoIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0
eT0iMjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlF1b3RlIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzAiIFFGb3JtYXQ9InRydWUiDQogICBOYW1lPSJJbnRl
bnNlIFF1b3RlIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i
NjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgMSIv
Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJN
ZWRpdW0gR3JpZCAyIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl
IiBQcmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDEiLz4NCiAgPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0IEFj
Y2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEi
IE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgMSIv
Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJD
b2xvcmZ1bCBHcmlkIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl
IiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDIiLz4NCiAgPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgTmFtZT0iTGlnaHQgTGlzdCBB
Y2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYy
IiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDIiLz4N
CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFtZT0iTWVk
aXVtIFNoYWRpbmcgMiBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCAyIi8+DQogIDx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0
IDIgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5
PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCAy
Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5hbWU9
Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs
c2UiIFByaW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCAyIi8+DQogIDx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRp
bmcgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5
PSI3MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAy
Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9
IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs
c2UiIFByaW9yaXR5PSI2MSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgMyIvPg0KICA8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFj
Y2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMi
IE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQg
MyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1l
PSJNZWRpdW0gTGlzdCAxIEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDMiLz4NCiAgPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdy
aWQgMSBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp
dHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50
IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFt
ZT0iRGFyayBMaXN0IEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl
IiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDMiLz4NCiAgPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwg
TGlzdCBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp
dHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50
IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgTmFt
ZT0iTGlnaHQgTGlzdCBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5n
IDEgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5
PSI2NCIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2Vu
dCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIE5h
bWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i
ZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgNCIvPg0KICA8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0g
R3JpZCAyIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv
cml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0
aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA0
Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9
IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i
ZmFsc2UiIFByaW9yaXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNCIvPg0KICA8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1
bCBHcmlkIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv
cml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0
aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQg
NSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1l
PSJMaWdodCBHcmlkIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl
IiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDUiLz4NCiAgPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFtZT0iTWVkaXVtIFNo
YWRpbmcgMiBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp
b3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNj
ZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIg
TmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCA1Ii8+DQog
IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1
bSBHcmlkIDMgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy
aW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNj
ZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIg
TmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PSJmYWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA1Ii8+DQog
IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0
IFNoYWRpbmcgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy
aW9yaXR5PSI2MSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCA2
Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9
Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i
ZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNiIvPg0K
ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRp
dW0gTGlzdCAxIEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ
cmlvcml0eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBB
Y2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4
IiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDYiLz4N
CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFtZT0iRGFy
ayBMaXN0IEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv
cml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCBB
Y2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcz
IiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBQcmlvcml0eT0iMTkiIFFGb3JtYXQ9InRydWUiDQogICBOYW1lPSJTdWJ0bGUg
RW1waGFzaXMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIy
MSIgUUZvcm1hdD0idHJ1ZSINCiAgIE5hbWU9IkludGVuc2UgRW1waGFzaXMiLz4NCiAgPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzMSIgUUZvcm1hdD0idHJ1ZSINCiAg
IE5hbWU9IlN1YnRsZSBSZWZlcmVuY2UiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs
c2UiIFByaW9yaXR5PSIzMiIgUUZvcm1hdD0idHJ1ZSINCiAgIE5hbWU9IkludGVuc2UgUmVmZXJl
bmNlIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzMiIFFG
b3JtYXQ9InRydWUiIE5hbWU9IkJvb2sgVGl0bGUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0iZmFsc2UiIFByaW9yaXR5PSIzNyIgU2VtaUhpZGRlbj0idHJ1ZSINCiAgIFVuaGlkZVdoZW5V
c2VkPSJ0cnVlIiBOYW1lPSJCaWJsaW9ncmFwaHkiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSINCiAgIFVuaGlkZVdoZW5V
c2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJUT0MgSGVhZGluZyIvPg0KICA8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQxIiBOYW1lPSJQbGFpbiBUYWJsZSAx
Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDIiIE5hbWU9
IlBsYWluIFRhYmxlIDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y
aXR5PSI0MyIgTmFtZT0iUGxhaW4gVGFibGUgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PSJmYWxzZSIgUHJpb3JpdHk9IjQ0IiBOYW1lPSJQbGFpbiBUYWJsZSA0Ii8+DQogIDx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDUiIE5hbWU9IlBsYWluIFRhYmxlIDUi
Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0MCIgTmFtZT0i
R3JpZCBUYWJsZSBMaWdodCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp
b3JpdHk9IjQ2IiBOYW1lPSJHcmlkIFRhYmxlIDEgTGlnaHQiLz4NCiAgPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIi8+DQogIDx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFi
bGUgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBO
YW1lPSJHcmlkIFRhYmxlIDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy
aW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsiLz4NCiAgPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iR3JpZCBUYWJsZSA2IENvbG9yZnVs
Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9
IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgUHJpb3JpdHk9IjQ2Ig0KICAgTmFtZT0iR3JpZCBUYWJsZSAxIExpZ2h0IEFjY2VudCAxIi8+
DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikdy
aWQgVGFibGUgMiBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg
UHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iR3JpZCBUYWJsZSA0IEFj
Y2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAi
IE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiDQogICBOYW1lPSJHcmlkIFRhYmxlIDYgQ29sb3Jm
dWwgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5
PSI1MiINCiAgIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMSIvPg0KICA8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2Ig0KICAgTmFtZT0iR3JpZCBU
YWJsZSAxIExpZ2h0IEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl
IiBQcmlvcml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgMiIvPg0KICA8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMg
QWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0
OSIgTmFtZT0iR3JpZCBUYWJsZSA0IEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCAy
Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiDQogICBO
YW1lPSJHcmlkIFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiINCiAgIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xv
cmZ1bCBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp
dHk9IjQ2Ig0KICAgTmFtZT0iR3JpZCBUYWJsZSAxIExpZ2h0IEFjY2VudCAzIi8+DQogIDx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUg
MiBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9
IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iR3JpZCBUYWJsZSA0IEFjY2VudCAzIi8+
DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikdy
aWQgVGFibGUgNSBEYXJrIEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBQcmlvcml0eT0iNTEiDQogICBOYW1lPSJHcmlkIFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50
IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiINCiAg
IE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2Ig0KICAgTmFtZT0iR3JpZCBUYWJsZSAxIExp
Z2h0IEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0
eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50IDQi
Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0i
R3JpZCBUYWJsZSA0IEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl
IiBQcmlvcml0eT0iNTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCA0Ii8+DQogIDx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiDQogICBOYW1lPSJHcmlk
IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i
ZmFsc2UiIFByaW9yaXR5PSI1MiINCiAgIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2Nl
bnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2Ig0K
ICAgTmFtZT0iR3JpZCBUYWJsZSAxIExpZ2h0IEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiBBY2NlbnQg
NSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1l
PSJHcmlkIFRhYmxlIDMgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs
c2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iR3JpZCBUYWJsZSA0IEFjY2VudCA1Ii8+DQogIDx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9IkdyaWQgVGFibGUg
NSBEYXJrIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv
cml0eT0iNTEiDQogICBOYW1lPSJHcmlkIFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDUiLz4NCiAg
PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiINCiAgIE5hbWU9Ikdy
aWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PSJmYWxzZSIgUHJpb3JpdHk9IjQ2Ig0KICAgTmFtZT0iR3JpZCBUYWJsZSAxIExpZ2h0IEFjY2Vu
dCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5h
bWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50IDYiLz4NCiAgPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iR3JpZCBUYWJs
ZSA0IEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0
eT0iNTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiDQogICBOYW1lPSJHcmlkIFRhYmxlIDYg
Q29sb3JmdWwgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy
aW9yaXR5PSI1MiINCiAgIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNiIvPg0K
ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0
IFRhYmxlIDEgTGlnaHQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y
aXR5PSI0NyIgTmFtZT0iTGlzdCBUYWJsZSAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyIvPg0KICA8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQiLz4N
CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iTGlz
dCBUYWJsZSA1IERhcmsiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y
aXR5PSI1MSIgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIi8+DQogIDx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9Ikxpc3QgVGFibGUgNyBDb2xvcmZ1
bCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2Ig0KICAg
TmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3QgVGFibGUgMiBBY2NlbnQgMSIv
Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJM
aXN0IFRhYmxlIDMgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui
IFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2VudCAxIi8+DQogIDx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxpc3QgVGFibGUgNSBE
YXJrIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0
eT0iNTEiDQogICBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDEiLz4NCiAgPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiINCiAgIE5hbWU9Ikxpc3Qg
VGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgUHJpb3JpdHk9IjQ2Ig0KICAgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCAy
Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9
Ikxpc3QgVGFibGUgMiBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDIiLz4NCiAgPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0
IEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i
NTAiIE5hbWU9Ikxpc3QgVGFibGUgNSBEYXJrIEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiDQogICBOYW1lPSJMaXN0IFRhYmxlIDYgQ29s
b3JmdWwgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y
aXR5PSI1MiINCiAgIE5hbWU9Ikxpc3QgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMiIvPg0KICA8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2Ig0KICAgTmFtZT0iTGlz
dCBUYWJsZSAxIExpZ2h0IEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3QgVGFibGUgMiBBY2NlbnQgMyIvPg0KICA8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxl
IDMgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5
PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxpc3QgVGFibGUgNSBEYXJrIEFjY2Vu
dCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiDQog
ICBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0
aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiINCiAgIE5hbWU9Ikxpc3QgVGFibGUgNyBD
b2xvcmZ1bCBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp
b3JpdHk9IjQ2Ig0KICAgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCA0Ii8+DQogIDx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3QgVGFi
bGUgMiBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp
dHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2VudCA0
Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9
Ikxpc3QgVGFibGUgNSBEYXJrIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBQcmlvcml0eT0iNTEiDQogICBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNj
ZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIN
CiAgIE5hbWU9Ikxpc3QgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2Ig0KICAgTmFtZT0iTGlzdCBUYWJsZSAx
IExpZ2h0IEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv
cml0eT0iNDciIE5hbWU9Ikxpc3QgVGFibGUgMiBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50
IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFt
ZT0iTGlzdCBUYWJsZSA0IEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxpc3QgVGFibGUgNSBEYXJrIEFjY2VudCA1Ii8+DQog
IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiDQogICBOYW1lPSJM
aXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0iZmFsc2UiIFByaW9yaXR5PSI1MiINCiAgIE5hbWU9Ikxpc3QgVGFibGUgNyBDb2xvcmZ1bCBB
Y2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2
Ig0KICAgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3QgVGFibGUgMiBBY2Nl
bnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBO
YW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i
ZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2VudCA2Ii8+DQogIDx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxpc3QgVGFi
bGUgNSBEYXJrIEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ
cmlvcml0eT0iNTEiDQogICBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDYiLz4N
CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiINCiAgIE5hbWU9
Ikxpc3QgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNiIvPg0KIDwvdzpMYXRlbnRTdHlsZXM+DQo8
L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gMTBdPg0KPHN0eWxlPg0KIC8qIFN0eWxl
IERlZmluaXRpb25zICovDQp0YWJsZS5Nc29Ob3JtYWxUYWJsZQ0KCXttc28tc3R5bGUtbmFtZToi
VGFibGUgTm9ybWFsIjsNCgltc28tdHN0eWxlLXJvd2JhbmQtc2l6ZTowOw0KCW1zby10c3R5bGUt
Y29sYmFuZC1zaXplOjA7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCW1zby1zdHlsZS1wYXJlbnQ6IiI7DQoJbXNvLXBhZGRpbmctYWx0OjBpbiA1LjRw
dCAwaW4gNS40cHQ7DQoJbXNvLXBhcmEtbWFyZ2luOjBpbjsNCgltc28tcGFyYS1tYXJnaW4tYm90
dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZTox
Mi4wcHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6Q2Fs
aWJyaTsNCgltc28tYXNjaWktdGhlbWUtZm9udDptaW5vci1sYXRpbjsNCgltc28taGFuc2ktZm9u
dC1mYW1pbHk6Q2FsaWJyaTsNCgltc28taGFuc2ktdGhlbWUtZm9udDptaW5vci1sYXRpbjt9DQo8
L3N0eWxlPg0KPCFbZW5kaWZdLS0+PCEtLVN0YXJ0RnJhZ21lbnQtLT4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7Ij5JIGhhdmUgYSB1c2UgY2FzZSB3
aGVyZSBhIGNsaWVudCBhcHBsaWNhdGlvbiBuZWVkcyB0byBhdXRoZW50aWNhdGUgd2l0aCBhIGR5
bmFtaWNhbGx5IGRldGVybWluZWQgSWRlbnRpdHkgUHJvdmlkZXIgdGhhdCBpcyBzZXBhcmF0ZSBm
cm9tIHRoZSBBdXRob3JpemF0aW9uIFNlcnZpY2UgdGhhdCB3aWxsIGJlIHVzZWQgaXNzdWUgYW4g
YWNjZXNzIHRva2VuIHRvDQogdGhlIGNsaWVudC4gVGhlIHVzZSBjYXNlIGFsc28gcmVxdWlyZXMg
dGhhdCBhcyBwYXJ0IG9mIGF1dGhvcml6YXRpb24sIHRoZSBjbGllbnQgcHJvdmlkZXMgdG8gdGhl
IEF1dGhvcml6YXRpb24gU2VydmljZSBhbiBhdXRoZW50aWNhdGlvbiB0b2tlbiBzaWduZWQgYnkg
YW4gSWRlbnRpdHkgUHJvdmlkZXIgdGhhdCB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2aWNlIGhhcyBh
IHRydXN0IHJlbGF0aW9uc2hpcCB3aXRoLiBUaGUgdHJ1c3QgcmVsYXRpb25zaGlwDQogaXMgdmVy
aWZpYWJsZSBiYXNlZCBvbiB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2aWNlIGhhdmluZyByZWNvcmRl
ZCB0aGUgcHVibGljIGtleXMgb3IgY2VydGlmaWNhdGVzIG9mIHRydXN0ZWQgSWRlbnRpdHkgUHJv
dmlkZXJzIGluIGEgdHJ1c3Qgc3RvcmUsIHRoaXMgYWxsb3dpbmcgdGhlIEF1dGhvcml6YXRpb24g
U2VydmljZSB0byB2ZXJpZnkgYW4gSWRlbnRpdHkgUHJvdmlkZXLigJlzIHNpZ25hdHVyZSBvbiBh
biBhdXRoZW50aWNhdGlvbiB0b2tlbi48L3NwYW4+PGEgbmFtZT0iT0xFX0xJTks1Ij48L2E+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIGxvb2tp
bmcgYXQgdGhlIHZhcmlvdXMgT0F1dGggUkZDcywgcGFydGljdWxhcmx5IFJGQ3MgNzUyMSwgNzUy
MiwgYW5kIDc1MjMsIEkgc2VlIHRoYXQgdGhleSBnZXQgbWUgY2xvc2UgaW4gdGVybXMgb2Ygc3Vw
cG9ydGluZyB0aGUgdXNlIGNhc2UuIFdoYXQgaXMgbWlzc2luZyBpcyBhIG1lYW5zIGZvciBzb2x2
aW5nIHRoZSBmb2xsb3dpbmcgcHJvYmxlbS4gVGhlc2UgUkZDcyByZXF1aXJlIHRoYXQgdGhlIElk
ZW50aXR5DQogUHJvdmlkZXIgcHV0IGFuIEF1ZGllbmNlIGNsYWltIGluIHRoZSBhdXRoZW50aWNh
dGlvbiB0b2tlbi4gVGhlIHByb2JsZW0gd2l0aCB0aGlzIGlzIHRoYXQgSSBkbyBub3Qgc2VlIGlu
IHRoZSBSRkNzIGhvdyB0aGUgSWRlbnRpdHkgUHJvdmlkZXIgY2FuIGJlIHRvbGQgd2hvIHRoZSBB
dWRpZW5jZSBpcyB0byBwdXQgaW50byB0aGUgYXV0aGVudGljYXRpb24gdG9rZW4uIFRoaXMgbGVh
ZHMgbWUgdG8gdGhlIHRpdGxlIG9mIHRoaXMgbWVzc2FnZS4gVGhlDQogZHJhZnQg4oCcT0F1dGgg
Mi4wIFRva2VuIEV4Y2hhbmdlOiBBbiBTVFMgZm9yIHRoZSBSRVNUIG9mIFVz4oCdIGRlZmluZXMg
YSBtZWNoYW5pc20gZm9yIGlkZW50aWZ5aW5nIHRoZSBBdWRpZW5jZSBmb3IgYW4gU1RTIHRvIHB1
dCBpbnRvIGEgdG9rZW4gaXQgZ2VuZXJhdGVzLiBUaGF0IHdvdWxkIHNvbHZlIG15IHByb2JsZW0g
ZXhjZXB0IHRoYXQgdGhlIGRyYWZ0IGxpbWl0cyB0aGUgdHlwZSBvZiBTVFMgdG8gYmVpbmcgQXV0
aG9yaXphdGlvbiBTZXJ2ZXJzLg0KIFdoYXQgaXMgbmVlZGVkIGlzIHRoaXMgc2FtZSBjYXBhYmls
aXR5IGZvciBpbnRlcmFjdGluZyB3aXRoIGFuIElkZW50aXR5IFByb3ZpZGVyLiBUaGlzIHdvdWxk
IGVuYWJsZSBSRkNzIDc1MjEsIDc1MjIgYW5kIDc1MjMgdG8gYmUgdXNlZnVsIGluIHNpdHVhdGlv
biB3aGVyZSB0aGUgSWRlbnRpdHkgUHJvdmlkZXIgbmVlZHMgdG8gYmUgdG9sZCB0aGUgaWRlbnRp
dHkgb2YgdGhlIEF1dGhvcml6YXRpb24gU2VydmljZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
SSBhbSBuZXcgdG8gaW50ZXJhY3Rpbmcgd2l0aCB0aGUgSUVURi4gSSBhbHNvIGFtIG5vdCBhbiBl
eHBlcnQgb24gdGhlIFJGQ3Mgb3IgcHJpb3IgaGlzdG9yeSBvZiB0aGUgT0F1dGggZ3JvdXAgcmVs
YXRpdmUgdG8gdGhpcyB0b3BpYywgc28gcGxlYXNlIHBvaW50IG1lIHRvIGFueSBleGlzdGluZyBz
b2x1dGlvbiBpZiB0aGlzIGlzIGEgc29sdmVkIHByb2JsZW0uIE90aGVyd2lzZSwgSSB3b3VsZCBs
aWtlIHRvIGdldA0KIGZlZWRiYWNrIG9uIG15IHN1Z2dlc3Rpb24uPG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPlRoYW5rcyBZb3UsPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5kcmV3IEZyZWdseTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+VmVyaXNpZ24gSW5jLjwvcD4NCjwhLS1FbmRGcmFnbWVudC0tPjwvZGl2
Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRMT09LX1NJR05BVFVSRSI+PC9kaXY+DQo8L2Rpdj4N
CjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_FF8F219EAB2E48F5AD90DEA783343C1Bverisigncom_--


From nobody Tue Apr 19 11:06:19 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F6A12EE1B for ; Tue, 19 Apr 2016 11:06:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgphMX-c2pyb for ; Tue, 19 Apr 2016 11:06:16 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E26ED12EB79 for ; Tue, 19 Apr 2016 11:06:15 -0700 (PDT)
Received: by mail-qk0-x236.google.com with SMTP id r191so6281653qke.2 for ; Tue, 19 Apr 2016 11:06:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=/U/xBmyNe56UKeKx30/emiSwj0TvN5afpVheOSWF48A=; b=2IJ+P2ec5eM2y95oJfIrFZaIb4lbZamy/5nXLRWBKm1y8/5QaRDJKjiWp0llFEp0pS ZsunEY94Y4HJyQODG8/hXCol00EZKtnuu8Ms42xYIfwuijv6VJnVkCfe+geIUs8suAM2 mzQhst5f2jIm9jKKW3xgZrZrSU8eui4FrcI9N51AhkqmAHnKELz1zHQ7t/U4Gbnb2YLK 5PaC462qAvE28TG9/rbnYojKu/jcXTFGLfUiMo9W4w4BuoxWWAPiV5zX9FR7vNRFIYvD y2uVRtgFjKcqlOl6Oz8suQXOpQo/5pbA2BnO+kYgcM0lHyOo3I15fIMrkHwl9hPaCunS htAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=/U/xBmyNe56UKeKx30/emiSwj0TvN5afpVheOSWF48A=; b=gK+Lr7lteyPEMuDT92triXy7Muz0+7/0rVW88j4uEezy9blfim0w+gDrOfIvVG3IM4 u7SHnHd4/CU4XIkRLHMUgf1uF8UbVUA2+ux6JRkTBbUzXra/3H7DjOILGOiH2XKdfA3w 38T6vGf2c8UtmulExPH+N78xiOCOSDt8pGenBf/JG1Y1Eu+rCfnkzx96TOB0FPRIquPU niKXNhi1XXPCSmgTogM7f5aLxjWSedLg9hYDTLL0b3QQ+wBwqcD2Fs2QeRdZL8J1+46Z 3Dik78Dl1VZOtXltADcGu3RJ1JlX7f2+60ZwPkGSDIuxT/tJ9KA1kzntPtu3pYHkpQ8Y OGMw==
X-Gm-Message-State: AOPr4FV0Z8Xv2OjO6ki2Sl8ZrEaFrfI6UyhqL70bUKdFbcLStayyIZE71IEVgG08cxYfJA==
X-Received: by 10.55.204.197 with SMTP id n66mr5598507qkl.95.1461089174878; Tue, 19 Apr 2016 11:06:14 -0700 (PDT)
Received: from [192.168.8.100] ([181.202.40.4]) by smtp.gmail.com with ESMTPSA id p188sm9354888qke.1.2016.04.19.11.06.13 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 19 Apr 2016 11:06:14 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_E4BFB470-169C-4D63-926A-7888AA003738"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: John Bradley 
In-Reply-To: 
Date: Tue, 19 Apr 2016 15:06:09 -0300
Message-Id: 
References: 
To: "Fregly, Andrew" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] =?utf-8?q?Building_on_the_protocol_in_the_draft_?= =?utf-8?q?=E2=80=9COAuth__2=2E0_Token_Exchange=3A_An_STS_for_the_REST_of_?= =?utf-8?q?Us=E2=80=9D_to_include_Authentication_Tokens?=
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Apr 2016 18:06:18 -0000

--Apple-Mail=_E4BFB470-169C-4D63-926A-7888AA003738
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Looking at OpenID Connect and it=E2=80=99s trust model for producing =
id_tokens that assert identity may help you.
http://openid.net/wg/connect/ 

Unfortunately I can=E2=80=99t quite make out what you are trying to do.=20=


It sort of sounds like you want an id_token from a idP and then have the =
client exchange that assertion for another token?

John B.
> On Apr 19, 2016, at 1:18 PM, Fregly, Andrew  =
wrote:
>=20
> I have a use case where a client application needs to authenticate =
with a dynamically determined Identity Provider that is separate from =
the Authorization Service that will be used issue an access token to the =
client. The use case also requires that as part of authorization, the =
client provides to the Authorization Service an authentication token =
signed by an Identity Provider that the Authorization Service has a =
trust relationship with. The trust relationship is verifiable based on =
the Authorization Service having recorded the public keys or =
certificates of trusted Identity Providers in a trust store, this =
allowing the Authorization Service to verify an Identity Provider=E2=80=99=
s signature on an authentication token. <>
> =20
> In looking at the various OAuth RFCs, particularly RFCs 7521, 7522, =
and 7523, I see that they get me close in terms of supporting the use =
case. What is missing is a means for solving the following problem. =
These RFCs require that the Identity Provider put an Audience claim in =
the authentication token. The problem with this is that I do not see in =
the RFCs how the Identity Provider can be told who the Audience is to =
put into the authentication token. This leads me to the title of this =
message. The draft =E2=80=9COAuth 2.0 Token Exchange: An STS for the =
REST of Us=E2=80=9D defines a mechanism for identifying the Audience for =
an STS to put into a token it generates. That would solve my problem =
except that the draft limits the type of STS to being Authorization =
Servers. What is needed is this same capability for interacting with an =
Identity Provider. This would enable RFCs 7521, 7522 and 7523 to be =
useful in situation where the Identity Provider needs to be told the =
identity of the Authorization Service.
> =20
> I am new to interacting with the IETF. I also am not an expert on the =
RFCs or prior history of the OAuth group relative to this topic, so =
please point me to any existing solution if this is a solved problem. =
Otherwise, I would like to get feedback on my suggestion.
> =20
> Thanks You,
>=20
> Andrew Fregly
> Verisign Inc.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth =


--Apple-Mail=_E4BFB470-169C-4D63-926A-7888AA003738
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Looking at OpenID Connect and it=E2=80=99s trust model for =
producing id_tokens that assert identity may help you.
http://openid.net/wg/connect/

Unfortunately I can=E2=80=99=
t quite make out what you are trying to do. 
It sort of sounds like you want an =
id_token from a idP and then have the client exchange that assertion for =
another token?

John B.
On Apr 19, 2016, at 1:18 PM, Fregly, Andrew =
<afregly@verisign.com> wrote:

I have a use case where a client =
application needs to authenticate with a dynamically determined Identity =
Provider that is separate from the Authorization Service that will be =
used issue an access token to the client. The use case also requires =
that as part of authorization, the client provides to the Authorization =
Service an authentication token signed by an Identity Provider that the =
Authorization Service has a trust relationship with. The trust =
relationship is verifiable based on the Authorization Service having =
recorded the public keys or certificates of trusted Identity Providers =
in a trust store, this allowing the Authorization Service to verify an =
Identity Provider=E2=80=99s signature on an authentication =
token.
 
In looking at the =
various OAuth RFCs, particularly RFCs 7521, 7522, and 7523, I see that =
they get me close in terms of supporting the use case. What is missing =
is a means for solving the following problem. These RFCs require that =
the Identity Provider put an Audience claim in the authentication token. =
The problem with this is that I do not see in the RFCs how the Identity =
Provider can be told who the Audience is to put into the authentication =
token. This leads me to the title of this message. The draft =E2=80=9COAut=
h 2.0 Token Exchange: An STS for the REST of Us=E2=80=9D defines a =
mechanism for identifying the Audience for an STS to put into a token it =
generates. That would solve my problem except that the draft limits the =
type of STS to being Authorization Servers. What is needed is this same =
capability for interacting with an Identity Provider. This would enable =
RFCs 7521, 7522 and 7523 to be useful in situation where the Identity =
Provider needs to be told the identity of the Authorization Service.
 
I am new to =
interacting with the IETF. I also am not an expert on the RFCs or prior =
history of the OAuth group relative to this topic, so please point me to =
any existing solution if this is a solved problem. Otherwise, I would =
like to get feedback on my suggestion.
 
Thanks You,

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

=

--Apple-Mail=_E4BFB470-169C-4D63-926A-7888AA003738--


From nobody Tue Apr 19 11:31:10 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1E912E3F7 for ; Tue, 19 Apr 2016 11:31:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDs2rWEVmPCO for ; Tue, 19 Apr 2016 11:31:07 -0700 (PDT)
Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 979D712E3E2 for ; Tue, 19 Apr 2016 11:31:07 -0700 (PDT)
Received: by mail-ig0-x231.google.com with SMTP id g8so25532691igr.0 for ; Tue, 19 Apr 2016 11:31:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HLEI478uDYzMdsSXNGw5tJJFw8X1LEFB1dbyLJvDfBo=; b=gGtV26t9T338rtbSqWAt+m9ARzRu2pMe8aGzJtoRqTNShh2jIRlE+Ta3ZKk6FYLh9R z6gt/LVHTtlccR0Nr0F+tmjnkQ1ZP7YGG7apLVJpjO1LwN0Of83memq3oIrfFlMC3rX4 dEBKBlBScd9JcADte8RLeQUoxf6tdAWpc3t4Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HLEI478uDYzMdsSXNGw5tJJFw8X1LEFB1dbyLJvDfBo=; b=CkoE/t9ZqLlGG2ioQ69PoPu5K8nGIfOwoiwe7Vp1tx8eD2yszy9Ky7IIua/8Z3iBHE bYX4XbcTr9lS+0EG8uYfcLuOGN6MwQ5le4Ni49Q8L0LQdPl7oF980OAuxDy/b441oJSh rUrxj2/ySdhU0Vwqut8iEWTGbY8xd/7ETlABrIFBUv7xRFfDfe5Id/qHNqv/vFzShwmH 5E0QcEeI8a/RNpW7Ca19E4axeurFlvub+pOINMmOnKqb1QcLhesQhpyjucblLpb9aJpd 885nQhk1eqQDeepng1k1r27TqefdLV63ASrbY/R9xGO6/zv15WFwgMazk54WHC5KTLwe sDtg==
X-Gm-Message-State: AOPr4FUEq0Z6O4oT69xb4ocnfelQmtfV2eNFp1gdj/FRs/STwRYt71q3wkxjvCMVGC91WPxR6f9z2yr29EVrlyfC
X-Received: by 10.50.29.242 with SMTP id n18mr5519854igh.62.1461090666000; Tue, 19 Apr 2016 11:31:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.77.215 with HTTP; Tue, 19 Apr 2016 11:30:36 -0700 (PDT)
In-Reply-To: 
References:  
From: Brian Campbell 
Date: Tue, 19 Apr 2016 12:30:36 -0600
Message-ID: 
To: John Bradley 
Content-Type: multipart/alternative; boundary=f46d04428eca220ee30530daae55
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] =?utf-8?q?Building_on_the_protocol_in_the_draft_?= =?utf-8?q?=E2=80=9COAuth_2=2E0_Token_Exchange=3A_An_STS_for_the_REST_of_U?= =?utf-8?q?s=E2=80=9D_to_include_Authentication_Tokens?=
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Apr 2016 18:31:10 -0000

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

The Token Exchange draft does put the Authorization Server (AS) in the role
of STS because it's an extension of OAuth. But that shouldn't be viewed as
limiting. An AS is often deployed as one part of an Identity Provider.
OpenID Connect, as John mentioned, is one standard that combines the roles.
And many products/services/deployments have an AS as part of their overall
Identity Provider offering, which might also have OpenID Connect, SAML,
etc.

On Tue, Apr 19, 2016 at 12:06 PM, John Bradley  wrote:

> Looking at OpenID Connect and it=E2=80=99s trust model for producing id_t=
okens
> that assert identity may help you.
> http://openid.net/wg/connect/
>
> Unfortunately I can=E2=80=99t quite make out what you are trying to do.
>
> It sort of sounds like you want an id_token from a idP and then have the
> client exchange that assertion for another token?
>
> John B.
>
> On Apr 19, 2016, at 1:18 PM, Fregly, Andrew  wrote:
>
> I have a use case where a client application needs to authenticate with a
> dynamically determined Identity Provider that is separate from the
> Authorization Service that will be used issue an access token to the
> client. The use case also requires that as part of authorization, the
> client provides to the Authorization Service an authentication token sign=
ed
> by an Identity Provider that the Authorization Service has a trust
> relationship with. The trust relationship is verifiable based on the
> Authorization Service having recorded the public keys or certificates of
> trusted Identity Providers in a trust store, this allowing the
> Authorization Service to verify an Identity Provider=E2=80=99s signature =
on an
> authentication token.
>
> In looking at the various OAuth RFCs, particularly RFCs 7521, 7522, and
> 7523, I see that they get me close in terms of supporting the use case.
> What is missing is a means for solving the following problem. These RFCs
> require that the Identity Provider put an Audience claim in the
> authentication token. The problem with this is that I do not see in the
> RFCs how the Identity Provider can be told who the Audience is to put int=
o
> the authentication token. This leads me to the title of this message. The
> draft =E2=80=9COAuth 2.0 Token Exchange: An STS for the REST of Us=E2=80=
=9D defines a
> mechanism for identifying the Audience for an STS to put into a token it
> generates. That would solve my problem except that the draft limits the
> type of STS to being Authorization Servers. What is needed is this same
> capability for interacting with an Identity Provider. This would enable
> RFCs 7521, 7522 and 7523 to be useful in situation where the Identity
> Provider needs to be told the identity of the Authorization Service.
>
> I am new to interacting with the IETF. I also am not an expert on the RFC=
s
> or prior history of the OAuth group relative to this topic, so please poi=
nt
> me to any existing solution if this is a solved problem. Otherwise, I wou=
ld
> like to get feedback on my suggestion.
>
> Thanks You,
>
> Andrew Fregly
> Verisign Inc.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

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


The Token Exchange draft does put the Authorization Server=
 (AS) in the role of STS because it's an extension of OAuth. But that s=
houldn't be viewed as limiting. An AS is often deployed as one part of =
an Identity Provider. OpenID Connect, as John mentioned, is one standard th=
at combines the roles. And many products/services/deployments have an AS as=
 part of their overall Identity Provider offering, which might also have Op=
enID Connect, SAML, etc. 

On Tue, Apr 19, 2016 at 12:06 PM, John Bradley <ve7jtb@=
ve7jtb.com> wrote:
Looking at OpenID Connect and it=E2=80=99s trus=
t model for producing id_tokens that assert identity may help you.
http://openid.net/w=
g/connect/

Unfortunately I can=E2=80=99t quite m=
ake out what you are trying to do.=C2=A0

It sort o=
f sounds like you want an id_token from a idP and then have the client exch=
ange that assertion for another token?

John B.
=

On Apr 19, 2016,=
 at 1:18 PM, Fregly, Andrew <afregly@verisign.com> wrote:

I have a use case where a client app=
lication needs to authenticate with a dynamically determined Identity Provi=
der that is separate from the Authorization Service that will be used issue=
 an access token to the client. The use case also requires that as part of =
authorization, the client provides to the Authorization Service an authenti=
cation token signed by an Identity Provider that the Authorization Service =
has a trust relationship with. The trust relationship is verifiable based o=
n the Authorization Service having recorded the public keys or certificates=
 of trusted Identity Providers in a trust store, this allowing the Authoriz=
ation Service to verify an Identity Provider=E2=80=99s signature on an auth=
entication token.
=C2=A0
In looking at the various OAu=
th RFCs, particularly RFCs 7521, 7522, and 7523, I see that they get me clo=
se in terms of supporting the use case. What is missing is a means for solv=
ing the following problem. These RFCs require that the Identity Provider pu=
t an Audience claim in the authentication token. The problem with this is t=
hat I do not see in the RFCs how the Identity Provider can be told who the =
Audience is to put into the authentication token. This leads me to the titl=
e of this message. The draft =E2=80=9COAuth 2.0 Token Exchange: An STS for =
the REST of Us=E2=80=9D defines a mechanism for identifying the Audience fo=
r an STS to put into a token it generates. That would solve my problem exce=
pt that the draft limits the type of STS to being Authorization Servers. Wh=
at is needed is this same capability for interacting with an Identity Provi=
der. This would enable RFCs 7521, 7522 and 7523 to be useful in situation w=
here the Identity Provider needs to be told the identity of the Authorizati=
on Service.
=C2=A0
I am new to interact=
ing with the IETF. I also am not an expert on the RFCs or prior history of =
the OAuth group relative to this topic, so please point me to any existing =
solution if this is a solved problem. Otherwise, I would like to get feedba=
ck on my suggestion.
=C2=A0
Thanks You,=


Andrew Fregly
Verisign Inc.
_____________________________________________=
__
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<=
/a>


_____________________=
__________________________

OAuth mailing list

OAuth@ietf.org

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





--f46d04428eca220ee30530daae55--


From nobody Tue Apr 19 13:05:25 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9DB712E61A for ; Tue, 19 Apr 2016 13:05:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJ9A-e_0Tcr3 for ; Tue, 19 Apr 2016 13:05:22 -0700 (PDT)
Received: from mail-qg0-x261.google.com (mail-qg0-x261.google.com [IPv6:2607:f8b0:400d:c04::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 877F512E50E for ; Tue, 19 Apr 2016 13:05:19 -0700 (PDT)
Received: by mail-qg0-x261.google.com with SMTP id a74so2779079qgf.2 for ; Tue, 19 Apr 2016 13:05:19 -0700 (PDT)
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:user-agent :mime-version; bh=oXqmh983mrZOePKvGyaIUQ2CON1J0oqK4FZenzfWoEU=; b=185PfJ6IvWiwl3HIthvEHx/2wIMJQsFe9/zmB6f4yZ3AG4h6j0zhRL6y3LdI1AaIuo PvVC1Ly6wtg8rEOgfVWJL5cB4RE/350Tzh2SUe+2PKNBK5JuEEpDN+K5vH7k/dbXZKJM RZ+8+Y/PPjb0DeYNpVFO3uY+U6LT8812XtDC7YfzFPYfXnrv/HxiaerOk8ZTBVEdcK9x zrQuPlY/ZzUcnsSk6c9vGveMiBSePLLGHI9uXKpNvmragIU+bIectMtyE/bMDAZ5O5Lr HkdBPqOm7Z0ZEc83tuyM1WJNVmAIN6jqMXZ8tFoXLWMCyqm2vSfGb3ZBAgao1IQyaYOv lEeg==
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 :user-agent:mime-version; bh=oXqmh983mrZOePKvGyaIUQ2CON1J0oqK4FZenzfWoEU=; b=TX76gNZz9dgUAllvUEh5bywVwhwnvq2LH+h3/B5l75V5TpRkkeN7eklmS1G8aLyDlS RGYCvNG4RLcseJv5k9kuOOa3UxkLCs8YgcrT6wmUdxBENGoUrH6q6930AOZegrt32Zsi +pWTL1+ySE19zMw8NRCyL0DJI7V3sdPnAQaxBv3nZi0kdpS1SJc9O73qu3G70t8lf/sa 1HgjT3c4oZq1+SfkjlWvCT5QgDmpVwXhhzTxKXVooZ9LQGLFYQCNo0wzU2v4IB5zto9U /EmTovNsGldD2hyOgOM1s+EDejWJA5YgYPAbZff9n7jXNdZdP6Hej3zEK8UXoRtAW72F YIew==
X-Gm-Message-State: AOPr4FVxUzJ4fZAo0kMOhdm21gNIpCyKME+JJx7hwDtSuYJqw1lNd3j/QPJMKAag/qtJxXxoCG1dT7DQbt8zqCon4/S4fi9n
X-Received: by 10.140.85.133 with SMTP id n5mr6163227qgd.32.1461096318458; Tue, 19 Apr 2016 13:05:18 -0700 (PDT)
Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id x71sm2347044qkb.3.2016.04.19.13.05.18 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 19 Apr 2016 13:05:18 -0700 (PDT)
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 u3JK5HI4014091 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Apr 2016 16:05:18 -0400
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 19 Apr 2016 16:05:17 -0400
From: "Fregly, Andrew" 
To: John Bradley , "oauth@ietf.org" 
Thread-Topic: =?utf-8?B?W09BVVRILVdHXSBCdWlsZGluZyBvbiB0aGUgcHJvdG9jb2wgaW4gdGhlIGRy?= =?utf-8?B?YWZ0IOKAnE9BdXRoICAyLjAgVG9rZW4gRXhjaGFuZ2U6IEFuIFNUUyBmb3Ig?= =?utf-8?B?dGhlIFJFU1Qgb2YgVXPigJ0gdG8gaW5jbHVkZSBBdXRoZW50aWNhdGlvbiBU?= =?utf-8?Q?okens?=
Thread-Index: AQHRmlcomE8l0QoCm0C5ZCXr0BuVz5+R2qyA///eO4A=
Date: Tue, 19 Apr 2016 20:05:17 +0000
Message-ID: <8B748252-9AE2-4824-923B-00CD46CB8D68@verisign.com>
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.160212
x-originating-ip: [10.173.152.4]
Content-Type: multipart/alternative; boundary="_000_8B7482529AE24824923B00CD46CB8D68verisigncom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] =?utf-8?q?Building_on_the_protocol_in_the_draft_?= =?utf-8?q?=E2=80=9COAuth__2=2E0_Token_Exchange=3A_An_STS_for_the_REST_of_?= =?utf-8?q?Us=E2=80=9D_to_include_Authentication_Tokens?=
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Apr 2016 20:05:25 -0000

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

VGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlIEpvaG4uIEkgYWxzbyBnb3QgYSBnb29kIHJlc3BvbnNl
IGZyb20gQnJpYW4gQ2FtcGJlbGwgYW5kIGFwcHJlY2lhdGUgdGhhdC4gSSB3aWxsIHJlc3BvbmQg
c2VwYXJhdGVseSB0byBCcmlhbuKAmXMgcmVzcG9uc2UgYXMgSSB0aGluayBpdCB3b3VsZCBrZWVw
IHRoaW5ncyBjbGVhcmVyIHRvIGRvIHRoYXQuDQoNClRoZSBwcm9ibGVtIHdlIGhhdmUgZm9yIHVz
aW5nIE9wZW5JRCBDb25uZWN0IGlzIHRoYXQgaXQgY29tYmluZXMgdGhlIHJvbGUgb2YgQXV0aGVu
dGljYXRpb24gU2VydmljZSB3aXRoIHRoZSByb2xlIG9mIEF1dGhvcml6YXRpb24gU2VydmljZS4g
UGVyaGFwcyB0aGUgZm9sbG93aW5nIGRlc2NyaXB0aW9uIG9mIHdoYXQgd2Ugd2FudCB0byBkbyB3
aWxsIGNsYXJpZnkgd2h5IHRoaXMgd29u4oCZdCB3b3JrIGZvciB1czoNCg0KVGhlIGJhc2ljIHBy
b2JsZW0gc3RhdGVtZW50IGlzIHRoYXQgd2UgbmVlZCB0byBoYXZlIGEgY2xpZW50IGFwcGxpY2F0
aW9uIGF1dGhvcml6ZWQgYnkgYSBTZXJ2aWNlIFByb3ZpZGVyIGJhc2VkIG9uIHByb29mIHRoYXQg
YSB1c2VyIGlzIGN1cnJlbnRseSBhIG1lbWJlciBvZiBzb21lIG9yZ2FuaXphdGlvbi4gVGhpcyBh
c3N1bWVzIHRoZSBvcmdhbml6YXRpb24gaGFzIHByZXZpb3VzbHkgZXN0YWJsaXNoZWQgc29tZSBs
ZXZlbCBvZiBhdXRob3JpemVkIGFjY2VzcyB3aXRoIHRoZSBTZXJ2aWNlIFByb3ZpZGVyLg0KDQpI
ZXJlIGlzIGFuIGV4YW1wbGU6IFN1cHBvc2UgSSBhbSBhIG1lbWJlciBvZiBTb21lT3JnIEluYy4g
U3VwcG9zZSBTb21lT3JnIEluYy4gaXMgZG9pbmcgcmVzZWFyY2ggdGhhdCByZXF1aXJlcyBpdCB0
byBnYXRoZXIgZGF0YSBvdmVyIHRoZSBJbnRlcm5ldCBmcm9tIGEgbnVtYmVyIG9mIGRhdGEgcHJv
dmlkZXJzLiBUaGUgZGF0YSBwcm92aWRlcnMgcmVxdWlyZSBhdXRoZW50aWNhdGlvbiBhbmQgcHJv
b2Ygb2Ygb3JnYW5pemF0aW9uYWwgbWVtYmVyc2hpcCBpbiBvcmRlciB0byBhdXRob3JpemUgdmFy
aW91cyBsZXZlbHMgb2YgYWNjZXNzIHRvIHRoZWlyIGRhdGEuIFRoZSBkYXRhIHByb3ZpZGVycyBk
byBub3QgY29uc2lkZXIgaGF2aW5nIGFuIGFjY291bnQgd2l0aCB0aGVtIG9yIGEgUHVibGljIElk
ZW50aXR5IFByb3ZpZGVyIHRvIGJlIHN1aXRhYmxlIGZvciBwcm92aW5nIHRoYXQgSSBhbSBzdGls
bCBhIG1lbWJlciBvZiBTb21lT3JnIGF0IHRpbWUgb2YgYXV0aGVudGljYXRpb24uIFRoZXkgd291
bGQgaGF2ZSBubyB3YXkgb2Yga25vd2luZyB3aGV0aGVyIG9yIG5vdCBteSByZWxhdGlvbnNoaXAg
d2l0aCBTb21lT3JnIHN0aWxsIGV4aXN0cyBhdCB0aGF0IHRpbWUuIFRoZSBkYXRhIHByb3ZpZGVy
cyB3b3VsZCB0aGVyZWZvcmUgbGlrZSB0aGUgQ2xpZW50IHNvZnR3YXJlIHRvIGF1dGhlbnRpY2F0
ZSBtZSBhZ2FpbnN0IFNvbWVPcmdzIElkZW50aXR5IFByb3ZpZGVyLiBUaGlzIHdvdWxkIGJlIGdv
b2QgcHJvb2YgdGhhdCBJIGFtIHN0aWxsIGEgbWVtYmVyIG9mIFNvbWVPcmcgYXQgdGhlIHRpbWUg
SSBhdXRoZW50aWNhdGUuIFRoaXMgYXV0aGVudGljYXRpb24gd291bGQgZW5hYmxlIHRoZSBkYXRh
IHByb3ZpZGVycyBBdXRob3JpemF0aW9uIFNlcnZlciB0byBncmFudCBtZSBhY2Nlc3MgYXBwcm9w
cmlhdGUgdG8gYSBtZW1iZXIgb2YgU29tZU9yZy4gIE5vdGUgdGhhdCBhcyBhIHByZXJlcXVpc2l0
ZSB0byBhbGwgb2YgdGhpcywgU29tZU9yZyB3aWxsIGhhdmUgdXNlZCBhbiBvdXQtb2YtYmFuZCBw
cm9jZXNzIHRvIHNldCB1cCBhIHRydXN0IHJlbGF0aW9uc2hpcCBmb3IgU29tZU9yZydzIElkZW50
aXR5IFByb3ZpZGVyIHdpdGggdGhlIGRhdGEgcHJvdmlkZXLigJlzIEF1dGhvcml6YXRpb24gU2Vy
dmljZSwgYW5kIHdpbGwgaGF2ZSBuZWdvdGlhdGVkIGF1dGhvcml6YXRpb24gY2xhaW1zIHRvIGJl
IGdyYW50ZWQgdG8gU29tZU9yZ3MgbWVtYmVycy4NCg0KV2hhdCBJIGFtIGhhdmluZyBkaWZmaWN1
bHR5IHdpdGggaXMgaW4ga25pdHRpbmcgdG9nZXRoZXIgYW4gYXBwcm9hY2ggYmFzZWQgb24gdGhl
IGhlIE9wZW5JRCBDb25uZWN0IHNwZWNpZmljYXRpb25zLCBTQU1MIHNwZWNpZmljYXRpb25zLCBh
bmQgT0F1dGggUkZDcyBhbmQgZHJhZnRzIGluIGEgd2F5IHRoYXQgc3VwcG9ydHMgdGhlIGFib3Zl
IHVzZSBjYXNlIGVuZC10by1lbmQuIFRoZSBPQXV0aCBSRkNzIGFuZCBkcmFmdHMgYWxtb3N0IGdl
dCBtZSB0aGVyZS4gV2hhdCBzZWVtcyB0byBiZSBtaXNzaW5nIGlzIGEgd2F5IG9mIHRlbGxpbmcg
YW4gSWRlbnRpdHkgUHJvdmlkZXIgdGhlIFVSTCBmb3IgdGhlIEF1dGhvcml6YXRpb24gU2Vydmlj
ZSAodGhlIHJlcXVpcmVkIEF1ZGllbmNlIGNsYWltIGluIGFuIGF1dGhlbnRpY2F0aW9uIGFzc2Vy
dGlvbiBhcyBkZWZpbmVkIGluIFJGQ3MgNzI1MSwgNzI1MiBhbmQgNzI1MyksIGFuZCB0aGVuIGEg
cmVxdWlyZW1lbnQgdGhhdCB0aGUgSWRlbnRpdHkgUHJvdmlkZXJzIHB1dCB0aGUgc3VwcGxpZWQg
QXVkaWVuY2UgSWRlbnRpZmllciBpbnRvIEF1dGhlbnRpY2F0aW9uIFRva2Vucy4gUGVyaGFwcyBh
IGxpdHRsZSBmdXJ0aGVyIGJhY2stYW5kLWZvcnRoIHdpdGggQnJpYW4gd2lsbCByZXNvbHZlIHRo
aXMuDQoNCkkgY2FuIGdvIGludG8gZGVlcGVyIGRldGFpbCBpZiBuZWVkZWQuIElmIHRoaXMgaXMg
b2ZmLXRvcGljIGZvciB0aGUgT0F1dGggd29ya2luZyBncm91cCwgbGV0IG1lIGtub3cuDQoNClRo
YW5rcywNCkFuZHJldyBGcmVnbHkNClZlcmlzaWduIEluYy4NCg0KDQpGcm9tOiBKb2huIEJyYWRs
ZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4+DQpEYXRlOiBU
dWVzZGF5LCBBcHJpbCAxOSwgMjAxNiBhdCAyOjA2IFBNDQpUbzogQW5kcmV3IEZyZWdseSA8YWZy
ZWdseUB2ZXJpc2lnbi5jb208bWFpbHRvOmFmcmVnbHlAdmVyaXNpZ24uY29tPj4NCkNjOiAib2F1
dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPiIgPG9hdXRoQGlldGYub3JnPG1haWx0
bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBCdWlsZGluZyBvbiB0
aGUgcHJvdG9jb2wgaW4gdGhlIGRyYWZ0IOKAnE9BdXRoIDIuMCBUb2tlbiBFeGNoYW5nZTogQW4g
U1RTIGZvciB0aGUgUkVTVCBvZiBVc+KAnSB0byBpbmNsdWRlIEF1dGhlbnRpY2F0aW9uIFRva2Vu
cw0KDQpMb29raW5nIGF0IE9wZW5JRCBDb25uZWN0IGFuZCBpdOKAmXMgdHJ1c3QgbW9kZWwgZm9y
IHByb2R1Y2luZyBpZF90b2tlbnMgdGhhdCBhc3NlcnQgaWRlbnRpdHkgbWF5IGhlbHAgeW91Lg0K
aHR0cDovL29wZW5pZC5uZXQvd2cvY29ubmVjdC8NCg0KVW5mb3J0dW5hdGVseSBJIGNhbuKAmXQg
cXVpdGUgbWFrZSBvdXQgd2hhdCB5b3UgYXJlIHRyeWluZyB0byBkby4NCg0KSXQgc29ydCBvZiBz
b3VuZHMgbGlrZSB5b3Ugd2FudCBhbiBpZF90b2tlbiBmcm9tIGEgaWRQIGFuZCB0aGVuIGhhdmUg
dGhlIGNsaWVudCBleGNoYW5nZSB0aGF0IGFzc2VydGlvbiBmb3IgYW5vdGhlciB0b2tlbj8NCg0K
Sm9obiBCLg0KT24gQXByIDE5LCAyMDE2LCBhdCAxOjE4IFBNLCBGcmVnbHksIEFuZHJldyA8YWZy
ZWdseUB2ZXJpc2lnbi5jb208bWFpbHRvOmFmcmVnbHlAdmVyaXNpZ24uY29tPj4gd3JvdGU6DQoN
CkkgaGF2ZSBhIHVzZSBjYXNlIHdoZXJlIGEgY2xpZW50IGFwcGxpY2F0aW9uIG5lZWRzIHRvIGF1
dGhlbnRpY2F0ZSB3aXRoIGEgZHluYW1pY2FsbHkgZGV0ZXJtaW5lZCBJZGVudGl0eSBQcm92aWRl
ciB0aGF0IGlzIHNlcGFyYXRlIGZyb20gdGhlIEF1dGhvcml6YXRpb24gU2VydmljZSB0aGF0IHdp
bGwgYmUgdXNlZCBpc3N1ZSBhbiBhY2Nlc3MgdG9rZW4gdG8gdGhlIGNsaWVudC4gVGhlIHVzZSBj
YXNlIGFsc28gcmVxdWlyZXMgdGhhdCBhcyBwYXJ0IG9mIGF1dGhvcml6YXRpb24sIHRoZSBjbGll
bnQgcHJvdmlkZXMgdG8gdGhlIEF1dGhvcml6YXRpb24gU2VydmljZSBhbiBhdXRoZW50aWNhdGlv
biB0b2tlbiBzaWduZWQgYnkgYW4gSWRlbnRpdHkgUHJvdmlkZXIgdGhhdCB0aGUgQXV0aG9yaXph
dGlvbiBTZXJ2aWNlIGhhcyBhIHRydXN0IHJlbGF0aW9uc2hpcCB3aXRoLiBUaGUgdHJ1c3QgcmVs
YXRpb25zaGlwIGlzIHZlcmlmaWFibGUgYmFzZWQgb24gdGhlIEF1dGhvcml6YXRpb24gU2Vydmlj
ZSBoYXZpbmcgcmVjb3JkZWQgdGhlIHB1YmxpYyBrZXlzIG9yIGNlcnRpZmljYXRlcyBvZiB0cnVz
dGVkIElkZW50aXR5IFByb3ZpZGVycyBpbiBhIHRydXN0IHN0b3JlLCB0aGlzIGFsbG93aW5nIHRo
ZSBBdXRob3JpemF0aW9uIFNlcnZpY2UgdG8gdmVyaWZ5IGFuIElkZW50aXR5IFByb3ZpZGVy4oCZ
cyBzaWduYXR1cmUgb24gYW4gYXV0aGVudGljYXRpb24gdG9rZW4uDQoNCkluIGxvb2tpbmcgYXQg
dGhlIHZhcmlvdXMgT0F1dGggUkZDcywgcGFydGljdWxhcmx5IFJGQ3MgNzUyMSwgNzUyMiwgYW5k
IDc1MjMsIEkgc2VlIHRoYXQgdGhleSBnZXQgbWUgY2xvc2UgaW4gdGVybXMgb2Ygc3VwcG9ydGlu
ZyB0aGUgdXNlIGNhc2UuIFdoYXQgaXMgbWlzc2luZyBpcyBhIG1lYW5zIGZvciBzb2x2aW5nIHRo
ZSBmb2xsb3dpbmcgcHJvYmxlbS4gVGhlc2UgUkZDcyByZXF1aXJlIHRoYXQgdGhlIElkZW50aXR5
IFByb3ZpZGVyIHB1dCBhbiBBdWRpZW5jZSBjbGFpbSBpbiB0aGUgYXV0aGVudGljYXRpb24gdG9r
ZW4uIFRoZSBwcm9ibGVtIHdpdGggdGhpcyBpcyB0aGF0IEkgZG8gbm90IHNlZSBpbiB0aGUgUkZD
cyBob3cgdGhlIElkZW50aXR5IFByb3ZpZGVyIGNhbiBiZSB0b2xkIHdobyB0aGUgQXVkaWVuY2Ug
aXMgdG8gcHV0IGludG8gdGhlIGF1dGhlbnRpY2F0aW9uIHRva2VuLiBUaGlzIGxlYWRzIG1lIHRv
IHRoZSB0aXRsZSBvZiB0aGlzIG1lc3NhZ2UuIFRoZSBkcmFmdCDigJxPQXV0aCAyLjAgVG9rZW4g
RXhjaGFuZ2U6IEFuIFNUUyBmb3IgdGhlIFJFU1Qgb2YgVXPigJ0gZGVmaW5lcyBhIG1lY2hhbmlz
bSBmb3IgaWRlbnRpZnlpbmcgdGhlIEF1ZGllbmNlIGZvciBhbiBTVFMgdG8gcHV0IGludG8gYSB0
b2tlbiBpdCBnZW5lcmF0ZXMuIFRoYXQgd291bGQgc29sdmUgbXkgcHJvYmxlbSBleGNlcHQgdGhh
dCB0aGUgZHJhZnQgbGltaXRzIHRoZSB0eXBlIG9mIFNUUyB0byBiZWluZyBBdXRob3JpemF0aW9u
IFNlcnZlcnMuIFdoYXQgaXMgbmVlZGVkIGlzIHRoaXMgc2FtZSBjYXBhYmlsaXR5IGZvciBpbnRl
cmFjdGluZyB3aXRoIGFuIElkZW50aXR5IFByb3ZpZGVyLiBUaGlzIHdvdWxkIGVuYWJsZSBSRkNz
IDc1MjEsIDc1MjIgYW5kIDc1MjMgdG8gYmUgdXNlZnVsIGluIHNpdHVhdGlvbiB3aGVyZSB0aGUg
SWRlbnRpdHkgUHJvdmlkZXIgbmVlZHMgdG8gYmUgdG9sZCB0aGUgaWRlbnRpdHkgb2YgdGhlIEF1
dGhvcml6YXRpb24gU2VydmljZS4NCg0KSSBhbSBuZXcgdG8gaW50ZXJhY3Rpbmcgd2l0aCB0aGUg
SUVURi4gSSBhbHNvIGFtIG5vdCBhbiBleHBlcnQgb24gdGhlIFJGQ3Mgb3IgcHJpb3IgaGlzdG9y
eSBvZiB0aGUgT0F1dGggZ3JvdXAgcmVsYXRpdmUgdG8gdGhpcyB0b3BpYywgc28gcGxlYXNlIHBv
aW50IG1lIHRvIGFueSBleGlzdGluZyBzb2x1dGlvbiBpZiB0aGlzIGlzIGEgc29sdmVkIHByb2Js
ZW0uIE90aGVyd2lzZSwgSSB3b3VsZCBsaWtlIHRvIGdldCBmZWVkYmFjayBvbiBteSBzdWdnZXN0
aW9uLg0KDQpUaGFua3MgWW91LA0KDQpBbmRyZXcgRnJlZ2x5DQpWZXJpc2lnbiBJbmMuDQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGlu
ZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg==

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

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+VGhh
bmtzIGZvciB5b3VyIHJlc3BvbnNlIEpvaG4uIEkgYWxzbyBnb3QgYSBnb29kIHJlc3BvbnNlIGZy
b20gQnJpYW4gQ2FtcGJlbGwgYW5kIGFwcHJlY2lhdGUgdGhhdC4gSSB3aWxsIHJlc3BvbmQgc2Vw
YXJhdGVseSB0byBCcmlhbuKAmXMgcmVzcG9uc2UgYXMgSSB0aGluayBpdCB3b3VsZCBrZWVwIHRo
aW5ncyBjbGVhcmVyIHRvIGRvIHRoYXQuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5U
aGUgcHJvYmxlbSB3ZSBoYXZlIGZvciB1c2luZyBPcGVuSUQgQ29ubmVjdCBpcyB0aGF0IGl0IGNv
bWJpbmVzIHRoZSByb2xlIG9mIEF1dGhlbnRpY2F0aW9uIFNlcnZpY2Ugd2l0aCB0aGUgcm9sZSBv
ZiBBdXRob3JpemF0aW9uIFNlcnZpY2UuIFBlcmhhcHMgdGhlIGZvbGxvd2luZyBkZXNjcmlwdGlv
biBvZiB3aGF0IHdlIHdhbnQgdG8gZG8gd2lsbCBjbGFyaWZ5IHdoeSB0aGlzIHdvbuKAmXQgd29y
ayBmb3IgdXM6PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgYmFzaWMgcHJvYmxl
bSBzdGF0ZW1lbnQgaXMgdGhhdCB3ZSBuZWVkIHRvIGhhdmUgYSBjbGllbnQgYXBwbGljYXRpb24g
YXV0aG9yaXplZCBieSBhIFNlcnZpY2UgUHJvdmlkZXIgYmFzZWQgb24gcHJvb2YgdGhhdCBhIHVz
ZXIgaXMgY3VycmVudGx5IGEgbWVtYmVyIG9mIHNvbWUgb3JnYW5pemF0aW9uLiBUaGlzIGFzc3Vt
ZXMgdGhlIG9yZ2FuaXphdGlvbiBoYXMgcHJldmlvdXNseSBlc3RhYmxpc2hlZCBzb21lIGxldmVs
IG9mIGF1dGhvcml6ZWQNCiBhY2Nlc3Mgd2l0aCB0aGUgU2VydmljZSBQcm92aWRlci4mbmJzcDs8
L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkhlcmUgaXMgYW4gZXhhbXBsZTogU3VwcG9z
ZSBJIGFtIGEgbWVtYmVyIG9mIFNvbWVPcmcgSW5jLiBTdXBwb3NlIFNvbWVPcmcgSW5jLiBpcyBk
b2luZyByZXNlYXJjaCB0aGF0IHJlcXVpcmVzIGl0IHRvIGdhdGhlciBkYXRhIG92ZXIgdGhlIElu
dGVybmV0IGZyb20gYSBudW1iZXIgb2YgZGF0YSBwcm92aWRlcnMuIFRoZSBkYXRhIHByb3ZpZGVy
cyByZXF1aXJlIGF1dGhlbnRpY2F0aW9uIGFuZCBwcm9vZiBvZiBvcmdhbml6YXRpb25hbCBtZW1i
ZXJzaGlwDQogaW4gb3JkZXIgdG8gYXV0aG9yaXplIHZhcmlvdXMgbGV2ZWxzIG9mIGFjY2VzcyB0
byB0aGVpciBkYXRhLiBUaGUgZGF0YSBwcm92aWRlcnMgZG8gbm90IGNvbnNpZGVyIGhhdmluZyBh
biBhY2NvdW50IHdpdGggdGhlbSBvciBhIFB1YmxpYyBJZGVudGl0eSBQcm92aWRlciB0byBiZSBz
dWl0YWJsZSBmb3IgcHJvdmluZyB0aGF0IEkgYW0gc3RpbGwgYSBtZW1iZXIgb2YgU29tZU9yZyBh
dCB0aW1lIG9mIGF1dGhlbnRpY2F0aW9uLiBUaGV5IHdvdWxkDQogaGF2ZSBubyB3YXkgb2Yga25v
d2luZyB3aGV0aGVyIG9yIG5vdCBteSByZWxhdGlvbnNoaXAgd2l0aCBTb21lT3JnIHN0aWxsIGV4
aXN0cyBhdCB0aGF0IHRpbWUuIFRoZSBkYXRhIHByb3ZpZGVycyB3b3VsZCB0aGVyZWZvcmUgbGlr
ZSB0aGUgQ2xpZW50IHNvZnR3YXJlIHRvIGF1dGhlbnRpY2F0ZSBtZSBhZ2FpbnN0IFNvbWVPcmdz
IElkZW50aXR5IFByb3ZpZGVyLiBUaGlzIHdvdWxkIGJlIGdvb2QgcHJvb2YgdGhhdCBJIGFtIHN0
aWxsIGEgbWVtYmVyDQogb2YgU29tZU9yZyBhdCB0aGUgdGltZSBJIGF1dGhlbnRpY2F0ZS4gVGhp
cyBhdXRoZW50aWNhdGlvbiB3b3VsZCBlbmFibGUgdGhlIGRhdGEgcHJvdmlkZXJzIEF1dGhvcml6
YXRpb24gU2VydmVyIHRvIGdyYW50IG1lIGFjY2VzcyBhcHByb3ByaWF0ZSB0byBhIG1lbWJlciBv
ZiBTb21lT3JnLiAmbmJzcDtOb3RlIHRoYXQgYXMgYSBwcmVyZXF1aXNpdGUgdG8gYWxsIG9mIHRo
aXMsIFNvbWVPcmcgd2lsbCBoYXZlIHVzZWQgYW4gb3V0LW9mLWJhbmQgcHJvY2Vzcw0KIHRvIHNl
dCB1cCBhIHRydXN0IHJlbGF0aW9uc2hpcCBmb3IgU29tZU9yZydzIElkZW50aXR5IFByb3ZpZGVy
IHdpdGggdGhlIGRhdGEgcHJvdmlkZXLigJlzIEF1dGhvcml6YXRpb24gU2VydmljZSwgYW5kIHdp
bGwgaGF2ZSBuZWdvdGlhdGVkIGF1dGhvcml6YXRpb24gY2xhaW1zIHRvIGJlIGdyYW50ZWQgdG8g
U29tZU9yZ3MgbWVtYmVycy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldoYXQgSSBh
bSBoYXZpbmcgZGlmZmljdWx0eSB3aXRoIGlzIGluIGtuaXR0aW5nIHRvZ2V0aGVyIGFuIGFwcHJv
YWNoIGJhc2VkIG9uIHRoZSBoZSBPcGVuSUQgQ29ubmVjdCBzcGVjaWZpY2F0aW9ucywgU0FNTCBz
cGVjaWZpY2F0aW9ucywgYW5kIE9BdXRoIFJGQ3MgYW5kIGRyYWZ0cyBpbiBhIHdheSB0aGF0IHN1
cHBvcnRzIHRoZSBhYm92ZSB1c2UgY2FzZSBlbmQtdG8tZW5kLiBUaGUgT0F1dGggUkZDcyBhbmQg
ZHJhZnRzIGFsbW9zdCBnZXQNCiBtZSB0aGVyZS4gV2hhdCBzZWVtcyB0byBiZSBtaXNzaW5nIGlz
IGEgd2F5IG9mIHRlbGxpbmcgYW4gSWRlbnRpdHkgUHJvdmlkZXIgdGhlIFVSTCBmb3IgdGhlIEF1
dGhvcml6YXRpb24gU2VydmljZSAodGhlIHJlcXVpcmVkIEF1ZGllbmNlIGNsYWltIGluIGFuIGF1
dGhlbnRpY2F0aW9uIGFzc2VydGlvbiBhcyBkZWZpbmVkIGluIFJGQ3MgNzI1MSwgNzI1MiBhbmQg
NzI1MyksIGFuZCB0aGVuIGEgcmVxdWlyZW1lbnQgdGhhdCB0aGUgSWRlbnRpdHkNCiBQcm92aWRl
cnMgcHV0IHRoZSBzdXBwbGllZCBBdWRpZW5jZSBJZGVudGlmaWVyIGludG8gQXV0aGVudGljYXRp
b24gVG9rZW5zLiBQZXJoYXBzIGEgbGl0dGxlIGZ1cnRoZXIgYmFjay1hbmQtZm9ydGggd2l0aCBC
cmlhbiB3aWxsIHJlc29sdmUgdGhpcy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pkkg
Y2FuIGdvIGludG8gZGVlcGVyIGRldGFpbCBpZiBuZWVkZWQuIElmIHRoaXMgaXMgb2ZmLXRvcGlj
IGZvciB0aGUgT0F1dGggd29ya2luZyBncm91cCwgbGV0IG1lIGtub3cuPC9kaXY+DQo8ZGl2Pjxi
cj4NCjwvZGl2Pg0KPGRpdj5UaGFua3MsPC9kaXY+DQo8ZGl2PkFuZHJldyBGcmVnbHk8L2Rpdj4N
CjxkaXY+VmVyaXNpZ24gSW5jLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHls
ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjEycHQ7IHRleHQtYWxpZ246bGVmdDsg
Y29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVk
aXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5H
LVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6
IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo
dDpib2xkIj5Gcm9tOiA8L3NwYW4+Sm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3
anRiQHZlN2p0Yi5jb20iPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHls
ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPlR1ZXNkYXksIEFwcmlsIDE5LCAyMDE2
IGF0IDI6MDYgUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bh
bj5BbmRyZXcgRnJlZ2x5ICZsdDs8YSBocmVmPSJtYWlsdG86YWZyZWdseUB2ZXJpc2lnbi5jb20i
PmFmcmVnbHlAdmVyaXNpZ24uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln
aHQ6Ym9sZCI+Q2M6IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmci
Pm9hdXRoQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYu
b3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0
OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW09BVVRILVdHXSBCdWlsZGluZyBvbiB0aGUgcHJv
dG9jb2wgaW4gdGhlIGRyYWZ0IOKAnE9BdXRoIDIuMCBUb2tlbiBFeGNoYW5nZTogQW4gU1RTIGZv
ciB0aGUgUkVTVCBvZiBVc+KAnSB0byBpbmNsdWRlIEF1dGhlbnRpY2F0aW9uIFRva2Vuczxicj4N
CjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19B
VFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xp
ZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXYgc3R5bGU9
IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0
LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQpMb29raW5nIGF0IE9w
ZW5JRCBDb25uZWN0IGFuZCBpdOKAmXMgdHJ1c3QgbW9kZWwgZm9yIHByb2R1Y2luZyBpZF90b2tl
bnMgdGhhdCBhc3NlcnQgaWRlbnRpdHkgbWF5IGhlbHAgeW91Lg0KPGRpdiBjbGFzcz0iIj48YSBo
cmVmPSJodHRwOi8vb3BlbmlkLm5ldC93Zy9jb25uZWN0LyIgY2xhc3M9IiI+aHR0cDovL29wZW5p
ZC5uZXQvd2cvY29ubmVjdC88L2E+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh
c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VW5mb3J0dW5hdGVseSBJIGNhbuKAmXQgcXVp
dGUgbWFrZSBvdXQgd2hhdCB5b3UgYXJlIHRyeWluZyB0byBkby4mbmJzcDs8L2Rpdj4NCjxkaXYg
Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkl0IHNvcnQgb2Yg
c291bmRzIGxpa2UgeW91IHdhbnQgYW4gaWRfdG9rZW4gZnJvbSBhIGlkUCBhbmQgdGhlbiBoYXZl
IHRoZSBjbGllbnQgZXhjaGFuZ2UgdGhhdCBhc3NlcnRpb24gZm9yIGFub3RoZXIgdG9rZW4/PC9k
aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5K
b2huIEIuPGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNz
PSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBBcHIgMTksIDIwMTYsIGF0IDE6MTggUE0sIEZyZWdseSwg
QW5kcmV3ICZsdDs8YSBocmVmPSJtYWlsdG86YWZyZWdseUB2ZXJpc2lnbi5jb20iIGNsYXNzPSIi
PmFmcmVnbHlAdmVyaXNpZ24uY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFw
cGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImZv
bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5
bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h
bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3Rh
cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog
bm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry
b2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAw
LjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogQ2FsaWJyaTsiIGNsYXNzPSIi
Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsiIGNsYXNzPSIiPkkgaGF2ZSBhIHVzZSBj
YXNlIHdoZXJlIGEgY2xpZW50IGFwcGxpY2F0aW9uIG5lZWRzIHRvIGF1dGhlbnRpY2F0ZSB3aXRo
IGEgZHluYW1pY2FsbHkgZGV0ZXJtaW5lZCBJZGVudGl0eSBQcm92aWRlciB0aGF0IGlzIHNlcGFy
YXRlIGZyb20gdGhlIEF1dGhvcml6YXRpb24gU2VydmljZSB0aGF0IHdpbGwgYmUgdXNlZCBpc3N1
ZSBhbiBhY2Nlc3MgdG9rZW4gdG8gdGhlIGNsaWVudC4NCiBUaGUgdXNlIGNhc2UgYWxzbyByZXF1
aXJlcyB0aGF0IGFzIHBhcnQgb2YgYXV0aG9yaXphdGlvbiwgdGhlIGNsaWVudCBwcm92aWRlcyB0
byB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2aWNlIGFuIGF1dGhlbnRpY2F0aW9uIHRva2VuIHNpZ25l
ZCBieSBhbiBJZGVudGl0eSBQcm92aWRlciB0aGF0IHRoZSBBdXRob3JpemF0aW9uIFNlcnZpY2Ug
aGFzIGEgdHJ1c3QgcmVsYXRpb25zaGlwIHdpdGguIFRoZSB0cnVzdCByZWxhdGlvbnNoaXAgaXMg
dmVyaWZpYWJsZQ0KIGJhc2VkIG9uIHRoZSBBdXRob3JpemF0aW9uIFNlcnZpY2UgaGF2aW5nIHJl
Y29yZGVkIHRoZSBwdWJsaWMga2V5cyBvciBjZXJ0aWZpY2F0ZXMgb2YgdHJ1c3RlZCBJZGVudGl0
eSBQcm92aWRlcnMgaW4gYSB0cnVzdCBzdG9yZSwgdGhpcyBhbGxvd2luZyB0aGUgQXV0aG9yaXph
dGlvbiBTZXJ2aWNlIHRvIHZlcmlmeSBhbiBJZGVudGl0eSBQcm92aWRlcuKAmXMgc2lnbmF0dXJl
IG9uIGFuIGF1dGhlbnRpY2F0aW9uIHRva2VuLjwvc3Bhbj48YSBuYW1lPSJPTEVfTElOSzUiIGNs
YXNzPSIiPjwvYT48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg
Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogQ2FsaWJyaTsiIGNsYXNzPSIiPg0KPG86cCBj
bGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw
dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogQ2FsaWJyaTsiIGNsYXNzPSIiPg0KPG86
cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp
biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogQ2FsaWJyaTsiIGNsYXNz
PSIiPg0KSW4gbG9va2luZyBhdCB0aGUgdmFyaW91cyBPQXV0aCBSRkNzLCBwYXJ0aWN1bGFybHkg
UkZDcyA3NTIxLCA3NTIyLCBhbmQgNzUyMywgSSBzZWUgdGhhdCB0aGV5IGdldCBtZSBjbG9zZSBp
biB0ZXJtcyBvZiBzdXBwb3J0aW5nIHRoZSB1c2UgY2FzZS4gV2hhdCBpcyBtaXNzaW5nIGlzIGEg
bWVhbnMgZm9yIHNvbHZpbmcgdGhlIGZvbGxvd2luZyBwcm9ibGVtLiBUaGVzZSBSRkNzIHJlcXVp
cmUgdGhhdCB0aGUgSWRlbnRpdHkgUHJvdmlkZXIgcHV0IGFuDQogQXVkaWVuY2UgY2xhaW0gaW4g
dGhlIGF1dGhlbnRpY2F0aW9uIHRva2VuLiBUaGUgcHJvYmxlbSB3aXRoIHRoaXMgaXMgdGhhdCBJ
IGRvIG5vdCBzZWUgaW4gdGhlIFJGQ3MgaG93IHRoZSBJZGVudGl0eSBQcm92aWRlciBjYW4gYmUg
dG9sZCB3aG8gdGhlIEF1ZGllbmNlIGlzIHRvIHB1dCBpbnRvIHRoZSBhdXRoZW50aWNhdGlvbiB0
b2tlbi4gVGhpcyBsZWFkcyBtZSB0byB0aGUgdGl0bGUgb2YgdGhpcyBtZXNzYWdlLiBUaGUgZHJh
ZnQg4oCcT0F1dGgNCiAyLjAgVG9rZW4gRXhjaGFuZ2U6IEFuIFNUUyBmb3IgdGhlIFJFU1Qgb2Yg
VXPigJ0gZGVmaW5lcyBhIG1lY2hhbmlzbSBmb3IgaWRlbnRpZnlpbmcgdGhlIEF1ZGllbmNlIGZv
ciBhbiBTVFMgdG8gcHV0IGludG8gYSB0b2tlbiBpdCBnZW5lcmF0ZXMuIFRoYXQgd291bGQgc29s
dmUgbXkgcHJvYmxlbSBleGNlcHQgdGhhdCB0aGUgZHJhZnQgbGltaXRzIHRoZSB0eXBlIG9mIFNU
UyB0byBiZWluZyBBdXRob3JpemF0aW9uIFNlcnZlcnMuIFdoYXQgaXMgbmVlZGVkDQogaXMgdGhp
cyBzYW1lIGNhcGFiaWxpdHkgZm9yIGludGVyYWN0aW5nIHdpdGggYW4gSWRlbnRpdHkgUHJvdmlk
ZXIuIFRoaXMgd291bGQgZW5hYmxlIFJGQ3MgNzUyMSwgNzUyMiBhbmQgNzUyMyB0byBiZSB1c2Vm
dWwgaW4gc2l0dWF0aW9uIHdoZXJlIHRoZSBJZGVudGl0eSBQcm92aWRlciBuZWVkcyB0byBiZSB0
b2xkIHRoZSBpZGVudGl0eSBvZiB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2aWNlLjxvOnAgY2xhc3M9
IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZv
bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IENhbGlicmk7IiBjbGFzcz0iIj4NCjxvOnAgY2xh
c3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w
MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IENhbGlicmk7IiBjbGFzcz0iIj4N
CkkgYW0gbmV3IHRvIGludGVyYWN0aW5nIHdpdGggdGhlIElFVEYuIEkgYWxzbyBhbSBub3QgYW4g
ZXhwZXJ0IG9uIHRoZSBSRkNzIG9yIHByaW9yIGhpc3Rvcnkgb2YgdGhlIE9BdXRoIGdyb3VwIHJl
bGF0aXZlIHRvIHRoaXMgdG9waWMsIHNvIHBsZWFzZSBwb2ludCBtZSB0byBhbnkgZXhpc3Rpbmcg
c29sdXRpb24gaWYgdGhpcyBpcyBhIHNvbHZlZCBwcm9ibGVtLiBPdGhlcndpc2UsIEkgd291bGQg
bGlrZSB0byBnZXQgZmVlZGJhY2sgb24gbXkgc3VnZ2VzdGlvbi48bzpwIGNsYXNzPSIiPjwvbzpw
PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6
IDEycHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZu
YnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBm
b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyIgY2xhc3M9IiI+DQpUaGFua3Mg
WW91LDwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNp
emU6IDEycHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+
DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl
OiAxMnB0OyBmb250LWZhbWlseTogQ2FsaWJyaTsiIGNsYXNzPSIiPg0KQW5kcmV3IEZyZWdseTxv
OnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w
MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IENhbGlicmk7IiBjbGFzcz0iIj4N
ClZlcmlzaWduIEluYy48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENh
bGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm
b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh
Y2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl
bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93
czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw
eDsiIGNsYXNzPSIiPg0KPGRpdiBpZD0iIiBjbGFzcz0iIj48L2Rpdj4NCjwvZGl2Pg0KPHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7
IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6
IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw
cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1
dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZs
b2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxiciBzdHlsZT0i
Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1z
dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y
bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBz
dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl
OiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z
dHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBD
YWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg
Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0
bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu
b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4
OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBp
bmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPk9BdXRoDQogbWFpbGluZyBsaXN0PC9zcGFuPjxi
ciBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRw
eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl
aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0
LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo
aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr
aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOk9B
dXRoQGlldGYub3JnIiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZv
bnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y
bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5z
OiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv
cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5n
OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPk9BdXRoQGll
dGYub3JnPC9hPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZv
bnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y
bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5z
OiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv
cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5n
OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGEgaHJl
Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgc3R5bGU9ImZv
bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5
bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h
bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3Rh
cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog
bm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry
b2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29hdXRoPC9hPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9
IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bh
bj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_8B7482529AE24824923B00CD46CB8D68verisigncom_--


From nobody Tue Apr 19 13:13:43 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07BA112DDA9 for ; Tue, 19 Apr 2016 13:13:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2D6pLYUdks7M for ; Tue, 19 Apr 2016 13:13:39 -0700 (PDT)
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 E7AA812DD2C for ; Tue, 19 Apr 2016 13:13:38 -0700 (PDT)
Received: by mail-qg0-x232.google.com with SMTP id f52so16415343qga.3 for ; Tue, 19 Apr 2016 13:13:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=FLHN0NMnpPK3jbujStBPMh+/XcNvqgdQRWZofNILSaM=; b=PztzugNXWMTxdObxlbKGvBkfgDu/WhVsfzWETmttm8z8ySVVUdAQ5/he47OzWWT3sv LY2uTCupRYdJx+vMWU77WAXiIcijKCqzRpXZ0DiLtIFk99Q+pDashBHy30WEQegFpSOA tkVas39ari8eDKVwLKaXJcIE2TbanBq0647bAt0/PFUXixQAdDYT1xEO/44uQghoLRtN OwmWCApTBhsNkLJIm/MXa8frMhxsQYF71KxOZq1cJbMMIsdEgWAnsnniKO8mO/7rjxay GVyqde53gyec2dsbQ4LIHvohy5+dt3SrHjZGVJko0cCM3pC0TZQ+cOj+Fi9eZL/dLNlf 0C1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=FLHN0NMnpPK3jbujStBPMh+/XcNvqgdQRWZofNILSaM=; b=SWo8Gj/Odm/+JGJk1cwxBEhaVF2jkWCNAZvaN1HhA9VxEF2z++L2kZGqcZoUHW7/bS lMdFsHQh6W68ci8+PJDZmqnjvVJKEgI0RuTPSvSWSABJmrja5R+oQ0OpLmdSdzUd1RVg pB69u69aXG8JJMRjVv99zmXO7BPREE8bjAkGRJ31VHy2zFfM7yWRAV4JXP8HtFd7wejv 4LOtrch2ICqoSUBD1nldc8M2E8liQaZAvVkgVJnJdcxwYWy9zQbSNXYDtErD0UUTFQTs s8afo1nW66ONV4MaWMqfh4I+9/yk+M+0jjDr8AvSZBzbDJgTDo4aNZnkN3U6V/QAsz7a jaLg==
X-Gm-Message-State: AOPr4FU28HwsQqMBWkIoq2dOmA6p8E/rO+MGa1lME+wkN1NFzs8somJnOOpKKgLHiH7rO9Krgrmswm5FWaM5Kw==
X-Received: by 10.140.38.199 with SMTP id t65mr6097765qgt.64.1461096816792; Tue, 19 Apr 2016 13:13:36 -0700 (PDT)
MIME-Version: 1.0
References:   <8B748252-9AE2-4824-923B-00CD46CB8D68@verisign.com>
In-Reply-To: <8B748252-9AE2-4824-923B-00CD46CB8D68@verisign.com>
From: Nat Sakimura 
Date: Tue, 19 Apr 2016 20:13:27 +0000
Message-ID: 
To: "Fregly, Andrew" , John Bradley ,  "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c12c56bf5b940530dc1c5d
Archived-At: 
Subject: Re: [OAUTH-WG] Building on the protocol in the draft "OAuth 2.0 Token Exchange: An STS for the REST of Us" to include Authentication Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Apr 2016 20:13:42 -0000

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

Get OpenID Connect id_token by the authentication request with prompt=3Dnon=
e
and verifying the sub to be the same with what you expected seem to suffice
your needs. Am I missing something?
On Wed, Apr 20, 2016 at 05:05 Fregly, Andrew  wrote:

> Thanks for your response John. I also got a good response from Brian
> Campbell and appreciate that. I will respond separately to Brian=E2=80=99=
s response
> as I think it would keep things clearer to do that.
>
> The problem we have for using OpenID Connect is that it combines the role
> of Authentication Service with the role of Authorization Service. Perhaps
> the following description of what we want to do will clarify why this won=
=E2=80=99t
> work for us:
>
> The basic problem statement is that we need to have a client application
> authorized by a Service Provider based on proof that a user is currently =
a
> member of some organization. This assumes the organization has previously
> established some level of authorized access with the Service Provider.
>
> Here is an example: Suppose I am a member of SomeOrg Inc. Suppose SomeOrg
> Inc. is doing research that requires it to gather data over the Internet
> from a number of data providers. The data providers require authenticatio=
n
> and proof of organizational membership in order to authorize various leve=
ls
> of access to their data. The data providers do not consider having an
> account with them or a Public Identity Provider to be suitable for provin=
g
> that I am still a member of SomeOrg at time of authentication. They would
> have no way of knowing whether or not my relationship with SomeOrg still
> exists at that time. The data providers would therefore like the Client
> software to authenticate me against SomeOrgs Identity Provider. This woul=
d
> be good proof that I am still a member of SomeOrg at the time I
> authenticate. This authentication would enable the data providers
> Authorization Server to grant me access appropriate to a member of
> SomeOrg.  Note that as a prerequisite to all of this, SomeOrg will have
> used an out-of-band process to set up a trust relationship for SomeOrg's
> Identity Provider with the data provider=E2=80=99s Authorization Service,=
 and will
> have negotiated authorization claims to be granted to SomeOrgs members.
>
> What I am having difficulty with is in knitting together an approach base=
d
> on the he OpenID Connect specifications, SAML specifications, and OAuth
> RFCs and drafts in a way that supports the above use case end-to-end. The
> OAuth RFCs and drafts almost get me there. What seems to be missing is a
> way of telling an Identity Provider the URL for the Authorization Service
> (the required Audience claim in an authentication assertion as defined in
> RFCs 7251, 7252 and 7253), and then a requirement that the Identity
> Providers put the supplied Audience Identifier into Authentication Tokens=
.
> Perhaps a little further back-and-forth with Brian will resolve this.
>
> I can go into deeper detail if needed. If this is off-topic for the OAuth
> working group, let me know.
>
> Thanks,
> Andrew Fregly
> Verisign Inc.
>
>
> From: John Bradley 
> Date: Tuesday, April 19, 2016 at 2:06 PM
> To: Andrew Fregly 
> Cc: "oauth@ietf.org" 
> Subject: Re: [OAUTH-WG] Building on the protocol in the draft =E2=80=9COA=
uth 2.0
> Token Exchange: An STS for the REST of Us=E2=80=9D to include Authenticat=
ion Tokens
>
> Looking at OpenID Connect and it=E2=80=99s trust model for producing id_t=
okens
> that assert identity may help you.
> http://openid.net/wg/connect/
>
> Unfortunately I can=E2=80=99t quite make out what you are trying to do.
>
> It sort of sounds like you want an id_token from a idP and then have the
> client exchange that assertion for another token?
>
> John B.
>
> On Apr 19, 2016, at 1:18 PM, Fregly, Andrew  wrote:
>
> I have a use case where a client application needs to authenticate with a
> dynamically determined Identity Provider that is separate from the
> Authorization Service that will be used issue an access token to the
> client. The use case also requires that as part of authorization, the
> client provides to the Authorization Service an authentication token sign=
ed
> by an Identity Provider that the Authorization Service has a trust
> relationship with. The trust relationship is verifiable based on the
> Authorization Service having recorded the public keys or certificates of
> trusted Identity Providers in a trust store, this allowing the
> Authorization Service to verify an Identity Provider=E2=80=99s signature =
on an
> authentication token.
>
> In looking at the various OAuth RFCs, particularly RFCs 7521, 7522, and
> 7523, I see that they get me close in terms of supporting the use case.
> What is missing is a means for solving the following problem. These RFCs
> require that the Identity Provider put an Audience claim in the
> authentication token. The problem with this is that I do not see in the
> RFCs how the Identity Provider can be told who the Audience is to put int=
o
> the authentication token. This leads me to the title of this message. The
> draft =E2=80=9COAuth 2.0 Token Exchange: An STS for the REST of Us=E2=80=
=9D defines a
> mechanism for identifying the Audience for an STS to put into a token it
> generates. That would solve my problem except that the draft limits the
> type of STS to being Authorization Servers. What is needed is this same
> capability for interacting with an Identity Provider. This would enable
> RFCs 7521, 7522 and 7523 to be useful in situation where the Identity
> Provider needs to be told the identity of the Authorization Service.
>
> I am new to interacting with the IETF. I also am not an expert on the RFC=
s
> or prior history of the OAuth group relative to this topic, so please poi=
nt
> me to any existing solution if this is a solved problem. Otherwise, I wou=
ld
> like to get feedback on my suggestion.
>
> Thanks You,
>
> Andrew Fregly
> Verisign Inc.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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

Get OpenID Connect id_token by the authentication request  with prompt=3Dno=
ne and verifying the sub to be the same with what you expected seem to suff=
ice your needs. Am I missing something? 
On Wed, Apr 20, 2016 at 05:05 Fregly, Andrew <afregly@verisign.com> wrote:









Thanks for your response John. I also got a good response from Brian C=
ampbell and appreciate that. I will respond separately to Brian=E2=80=99s r=
esponse as I think it would keep things clearer to do that.







The problem we have for using OpenID Connect is that it combines the r=
ole of Authentication Service with the role of Authorization Service. Perha=
ps the following description of what we want to do will clarify why this wo=
n=E2=80=99t work for us:







The basic problem statement is that we need to have a client applicati=
on authorized by a Service Provider based on proof that a user is currently=
 a member of some organization. This assumes the organization has previousl=
y established some level of authorized
 access with the Service Provider.=C2=A0







Here is an example: Suppose I am a member of SomeOrg Inc. Suppose Some=
Org Inc. is doing research that requires it to gather data over the Interne=
t from a number of data providers. The data providers require authenticatio=
n and proof of organizational membership
 in order to authorize various levels of access to their data. The data pro=
viders do not consider having an account with them or a Public Identity Pro=
vider to be suitable for proving that I am still a member of SomeOrg at tim=
e of authentication. They would
 have no way of knowing whether or not my relationship with SomeOrg still e=
xists at that time. The data providers would therefore like the Client soft=
ware to authenticate me against SomeOrgs Identity Provider. This would be g=
ood proof that I am still a member
 of SomeOrg at the time I authenticate. This authentication would enable th=
e data providers Authorization Server to grant me access appropriate to a m=
ember of SomeOrg.=C2=A0 Note that as a prerequisite to all of this, SomeOrg=
 will have used an out-of-band process
 to set up a trust relationship for SomeOrg's Identity Provider with th=
e data provider=E2=80=99s Authorization Service, and will have negotiated a=
uthorization claims to be granted to SomeOrgs members.







What I am having difficulty with is in knitting together an approach b=
ased on the he OpenID Connect specifications, SAML specifications, and OAut=
h RFCs and drafts in a way that supports the above use case end-to-end. The=
 OAuth RFCs and drafts almost get
 me there. What seems to be missing is a way of telling an Identity Provide=
r the URL for the Authorization Service (the required Audience claim in an =
authentication assertion as defined in RFCs 7251, 7252 and 7253), and then =
a requirement that the Identity
 Providers put the supplied Audience Identifier into Authentication Tokens.=
 Perhaps a little further back-and-forth with Brian will resolve this.






I can go into deeper detail if needed. If this is off-topic for the OA=
uth working group, let me know.







Thanks,


Andrew Fregly


Verisign Inc.






















From: John Bradley <ve7jtb@ve7jtb.com>

Date: Tuesday, April 19, 2016 at 2:=
06 PM

To: Andrew Fregly <afregly@verisign.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>

Subject: Re: [OAUTH-WG] Building on=
 the protocol in the draft =E2=80=9COAuth 2.0 Token Exchange: An STS for th=
e REST of Us=E2=80=9D to include Authentication Tokens














Looking at OpenID Connect and it=E2=80=99s trust model for producing id_tok=
ens that assert identity may help you.

http://ope=
nid.net/wg/connect/







Unfortunately I can=E2=80=99t quite make out what you are trying to do=
.=C2=A0







It sort of sounds like you want an id_token from a idP and then have t=
he client exchange that assertion for another token?







John B.






On Apr 19, 2016, at 1:18 PM, Fregly, Andrew <afregly@verisign.com> wrote:








I have a use case where a client application=
 needs to authenticate with a dynamically determined Identity Provider that=
 is separate from the Authorization Service that will be used issue an acce=
ss token to the client.
 The use case also requires that as part of authorization, the client provi=
des to the Authorization Service an authentication token signed by an Ident=
ity Provider that the Authorization Service has a trust relationship with. =
The trust relationship is verifiable
 based on the Authorization Service having recorded the public keys or cert=
ificates of trusted Identity Providers in a trust store, this allowing the =
Authorization Service to verify an Identity Provider=E2=80=99s signature on=
 an authentication token.







=C2=A0



In looking at the various OAuth RFCs, particularly RFCs 7521, 7522, and 752=
3, I see that they get me close in terms of supporting the use case. What i=
s missing is a means for solving the following problem. These RFCs require =
that the Identity Provider put an
 Audience claim in the authentication token. The problem with this is that =
I do not see in the RFCs how the Identity Provider can be told who the Audi=
ence is to put into the authentication token. This leads me to the title of=
 this message. The draft =E2=80=9COAuth
 2.0 Token Exchange: An STS for the REST of Us=E2=80=9D defines a mechanism=
 for identifying the Audience for an STS to put into a token it generates. =
That would solve my problem except that the draft limits the type of STS to=
 being Authorization Servers. What is needed
 is this same capability for interacting with an Identity Provider. This wo=
uld enable RFCs 7521, 7522 and 7523 to be useful in situation where the Ide=
ntity Provider needs to be told the identity of the Authorization Service.<=
u>



=C2=A0



I am new to interacting with the IETF. I also am not an expert on the RFCs =
or prior history of the OAuth group relative to this topic, so please point=
 me to any existing solution if this is a solved problem. Otherwise, I woul=
d like to get feedback on my suggestion.



=C2=A0



Thanks You,









Andrew Fregly



Verisign Inc.









_______________________________________________=


OAuth
 mailing list

OAuth@ietf.org

https://www.ietf.org/m=
ailman/listinfo/oauth




















_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--001a11c12c56bf5b940530dc1c5d--


From nobody Tue Apr 19 13:18:49 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A8712DFF5 for ; Tue, 19 Apr 2016 13:18:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.895
X-Spam-Level: 
X-Spam-Status: No, score=-2.895 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.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mx.aol.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSDOERcEQzXe for ; Tue, 19 Apr 2016 13:18:44 -0700 (PDT)
Received: from omr-a016e.mx.aol.com (omr-a016e.mx.aol.com [204.29.186.65]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88D9F12D615 for ; Tue, 19 Apr 2016 13:18:43 -0700 (PDT)
Received: from mtaout-mab01.mx.aol.com (mtaout-mab01.mx.aol.com [172.26.249.81]) by omr-a016e.mx.aol.com (Outbound Mail Relay) with ESMTP id C8F2B3800085; Tue, 19 Apr 2016 16:18:42 -0400 (EDT)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-mab01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id BE33D38000092; Tue, 19 Apr 2016 16:18:41 -0400 (EDT)
To: "Fregly, Andrew" , John Bradley , "oauth@ietf.org" 
References:   <8B748252-9AE2-4824-923B-00CD46CB8D68@verisign.com>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <571692A1.5070000@aol.com>
Date: Tue, 19 Apr 2016 16:18:41 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <8B748252-9AE2-4824-923B-00CD46CB8D68@verisign.com>
Content-Type: multipart/alternative; boundary="------------070909030202010903040501"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1461097122; bh=SwT423foLwyqy5MSI9yE+wwCgh3c7O3v1ndQGi3QYEQ=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=ahjO+DwV0u6snyERhl8H3j/c+9fb5ChIwHfr6Um0N9zsuqeo5iJuMGhj5XxKXHQLh KEep10Jj7RkariN/8Boe4B8lHnZAis9gbPbJhH9yg0HMnihfr1NdlYo7U6bf0ggc0Q 10hgWY9h6c0xkTA+FrpFm+nXUxAkz8S6X6Rf+xn0=
x-aol-sid: 3039ac1af951571692a1288c
X-AOL-IP: 10.172.102.179
Archived-At: 
Subject: Re: [OAUTH-WG] =?utf-8?q?Building_on_the_protocol_in_the_draft_?= =?utf-8?q?=E2=80=9COAuth_2=2E0_Token_Exchange=3A_An_STS_for_the_REST_of_U?= =?utf-8?q?s=E2=80=9D_to_include_Authentication_Tokens?=
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Apr 2016 20:18:47 -0000

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

So if I understand this correctly, what is really required is a 
verifiable claim that the user is still a member of SomeOrg Inc. OpenID 
Connect supports both distributed and aggregated claims that can be 
signed by the appropriate Identity Provider. The point being that I'm 
not sure an "authentication token" is required for this use case to 
succeed, it's just one kind of token that can be used.

Also, is the expected flow that the user will first go to the data 
provider and then be directed else where from there? If that is the 
case, the data provider can just be an OpenID Connect relying party and 
give the user an option of the list of supported IdPs to choose from. 
The user will then be redirected to SomeOrg Inc. IdP, authenticate and 
the data provider will have the authorization and recent authentication 
they can validate.

Is the user/data flow more complicated than this?

Thanks,
George

On 4/19/16 4:05 PM, Fregly, Andrew wrote:
> Thanks for your response John. I also got a good response from Brian 
> Campbell and appreciate that. I will respond separately to Brian’s 
> response as I think it would keep things clearer to do that.
>
> The problem we have for using OpenID Connect is that it combines the 
> role of Authentication Service with the role of Authorization Service. 
> Perhaps the following description of what we want to do will clarify 
> why this won’t work for us:
>
> The basic problem statement is that we need to have a client 
> application authorized by a Service Provider based on proof that a 
> user is currently a member of some organization. This assumes the 
> organization has previously established some level of authorized 
> access with the Service Provider.
>
> Here is an example: Suppose I am a member of SomeOrg Inc. Suppose 
> SomeOrg Inc. is doing research that requires it to gather data over 
> the Internet from a number of data providers. The data providers 
> require authentication and proof of organizational membership in order 
> to authorize various levels of access to their data. The data 
> providers do not consider having an account with them or a Public 
> Identity Provider to be suitable for proving that I am still a member 
> of SomeOrg at time of authentication. They would have no way of 
> knowing whether or not my relationship with SomeOrg still exists at 
> that time. The data providers would therefore like the Client software 
> to authenticate me against SomeOrgs Identity Provider. This would be 
> good proof that I am still a member of SomeOrg at the time I 
> authenticate. This authentication would enable the data providers 
> Authorization Server to grant me access appropriate to a member of 
> SomeOrg.  Note that as a prerequisite to all of this, SomeOrg will 
> have used an out-of-band process to set up a trust relationship for 
> SomeOrg's Identity Provider with the data provider’s Authorization 
> Service, and will have negotiated authorization claims to be granted 
> to SomeOrgs members.
>
> What I am having difficulty with is in knitting together an approach 
> based on the he OpenID Connect specifications, SAML specifications, 
> and OAuth RFCs and drafts in a way that supports the above use case 
> end-to-end. The OAuth RFCs and drafts almost get me there. What seems 
> to be missing is a way of telling an Identity Provider the URL for the 
> Authorization Service (the required Audience claim in an 
> authentication assertion as defined in RFCs 7251, 7252 and 7253), and 
> then a requirement that the Identity Providers put the supplied 
> Audience Identifier into Authentication Tokens. Perhaps a little 
> further back-and-forth with Brian will resolve this.
>
> I can go into deeper detail if needed. If this is off-topic for the 
> OAuth working group, let me know.
>
> Thanks,
> Andrew Fregly
> Verisign Inc.
>
>
> From: John Bradley >
> Date: Tuesday, April 19, 2016 at 2:06 PM
> To: Andrew Fregly >
> Cc: "oauth@ietf.org "  >
> Subject: Re: [OAUTH-WG] Building on the protocol in the draft “OAuth 
> 2.0 Token Exchange: An STS for the REST of Us†to include 
> Authentication Tokens
>
>     Looking at OpenID Connect and it’s trust model for producing
>     id_tokens that assert identity may help you.
>     http://openid.net/wg/connect/
>
>     Unfortunately I can’t quite make out what you are trying to do.
>
>     It sort of sounds like you want an id_token from a idP and then
>     have the client exchange that assertion for another token?
>
>     John B.
>>     On Apr 19, 2016, at 1:18 PM, Fregly, Andrew >     > wrote:
>>
>>     I have a use case where a client application needs to
>>     authenticate with a dynamically determined Identity Provider that
>>     is separate from the Authorization Service that will be used
>>     issue an access token to the client. The use case also requires
>>     that as part of authorization, the client provides to the
>>     Authorization Service an authentication token signed by an
>>     Identity Provider that the Authorization Service has a trust
>>     relationship with. The trust relationship is verifiable based on
>>     the Authorization Service having recorded the public keys or
>>     certificates of trusted Identity Providers in a trust store, this
>>     allowing the Authorization Service to verify an Identity
>>     Provider’s signature on an authentication token.
>>     In looking at the various OAuth RFCs, particularly RFCs 7521,
>>     7522, and 7523, I see that they get me close in terms of
>>     supporting the use case. What is missing is a means for solving
>>     the following problem. These RFCs require that the Identity
>>     Provider put an Audience claim in the authentication token. The
>>     problem with this is that I do not see in the RFCs how the
>>     Identity Provider can be told who the Audience is to put into the
>>     authentication token. This leads me to the title of this message.
>>     The draft “OAuth 2.0 Token Exchange: An STS for the REST of Usâ€
>>     defines a mechanism for identifying the Audience for an STS to
>>     put into a token it generates. That would solve my problem except
>>     that the draft limits the type of STS to being Authorization
>>     Servers. What is needed is this same capability for interacting
>>     with an Identity Provider. This would enable RFCs 7521, 7522 and
>>     7523 to be useful in situation where the Identity Provider needs
>>     to be told the identity of the Authorization Service.
>>     I am new to interacting with the IETF. I also am not an expert on
>>     the RFCs or prior history of the OAuth group relative to this
>>     topic, so please point me to any existing solution if this is a
>>     solved problem. Otherwise, I would like to get feedback on my
>>     suggestion.
>>     Thanks You,
>>
>>     Andrew Fregly
>>     Verisign Inc.
>>     _______________________________________________
>>     OAuth mailing list
>>     OAuth@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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


  
    
  
  
    So if I understand this
      correctly, what is really required is a verifiable claim that the
      user is still a member of SomeOrg Inc. OpenID Connect supports
      both distributed and aggregated claims that can be signed by the
      appropriate Identity Provider. The point being that I'm not sure
      an "authentication token" is required for this use case to succeed,
      it's just one kind of token that can be used.

      

      Also, is the expected flow that the user will first go to the data
      provider and then be directed else where from there? If that is
      the case, the data provider can just be an OpenID Connect relying
      party and give the user an option of the list of supported IdPs to
      choose from. The user will then be redirected to SomeOrg Inc. IdP,
      authenticate and the data provider will have the authorization and
      recent authentication they can validate.

      

      Is the user/data flow more complicated than this?

      

      Thanks,

      George

    

    
On 4/19/16 4:05 PM, Fregly, Andrew
      wrote:

    

    

      
      

        
Thanks for your response John. I also got a good response
          from Brian Campbell and appreciate that. I will respond
          separately to Brian’s response as I think it would keep things
          clearer to do that.

        


        

        
The problem we have for using OpenID Connect is that it
          combines the role of Authentication Service with the role of
          Authorization Service. Perhaps the following description of
          what we want to do will clarify why this won’t work for us:

        


        

        
The basic problem statement is that we need to have a
          client application authorized by a Service Provider based on
          proof that a user is currently a member of some organization.
          This assumes the organization has previously established some
          level of authorized access with the Service Provider. 

        


        

        
Here is an example: Suppose I am a member of SomeOrg Inc.
          Suppose SomeOrg Inc. is doing research that requires it to
          gather data over the Internet from a number of data providers.
          The data providers require authentication and proof of
          organizational membership in order to authorize various levels
          of access to their data. The data providers do not consider
          having an account with them or a Public Identity Provider to
          be suitable for proving that I am still a member of SomeOrg at
          time of authentication. They would have no way of knowing
          whether or not my relationship with SomeOrg still exists at
          that time. The data providers would therefore like the Client
          software to authenticate me against SomeOrgs Identity
          Provider. This would be good proof that I am still a member of
          SomeOrg at the time I authenticate. This authentication would
          enable the data providers Authorization Server to grant me
          access appropriate to a member of SomeOrg.  Note that as a
          prerequisite to all of this, SomeOrg will have used an
          out-of-band process to set up a trust relationship for
          SomeOrg's Identity Provider with the data provider’s
          Authorization Service, and will have negotiated authorization
          claims to be granted to SomeOrgs members.

        


        

        
What I am having difficulty with is in knitting together an
          approach based on the he OpenID Connect specifications, SAML
          specifications, and OAuth RFCs and drafts in a way that
          supports the above use case end-to-end. The OAuth RFCs and
          drafts almost get me there. What seems to be missing is a way
          of telling an Identity Provider the URL for the Authorization
          Service (the required Audience claim in an authentication
          assertion as defined in RFCs 7251, 7252 and 7253), and then a
          requirement that the Identity Providers put the supplied
          Audience Identifier into Authentication Tokens. Perhaps a
          little further back-and-forth with Brian will resolve this.

        


        

        
I can go into deeper detail if needed. If this is off-topic
          for the OAuth working group, let me know.

        


        

        
Thanks,

        
Andrew Fregly

        
Verisign Inc.

        


        

        

        

      

      


      

      
        

          From: John Bradley <ve7jtb@ve7jtb.com>

          Date: Tuesday, April
          19, 2016 at 2:06 PM

          To: Andrew Fregly <afregly@verisign.com>

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

          Subject: Re: [OAUTH-WG]
          Building on the protocol in the draft “OAuth 2.0 Token
          Exchange: An STS for the REST of Us†to include Authentication
          Tokens

        

        


        

        

          

            

              Looking at OpenID Connect and it’s trust model for
              producing id_tokens that assert identity may help you.
              
http://openid.net/wg/connect/

                


                

                
Unfortunately I can’t quite make out what
                  you are trying to do. 

                


                

                
It sort of sounds like you want an
                  id_token from a idP and then have the client exchange
                  that assertion for another token?

                


                

                
John B.

                  

                    

                      
On Apr 19, 2016, at 1:18 PM, Fregly,
                        Andrew <afregly@verisign.com>
                        wrote:

                      

                      

                        

                          

                            I
                              have a use case where a client application
                              needs to authenticate with a dynamically
                              determined Identity Provider that is
                              separate from the Authorization Service
                              that will be used issue an access token to
                              the client. The use case also requires
                              that as part of authorization, the client
                              provides to the Authorization Service an
                              authentication token signed by an Identity
                              Provider that the Authorization Service
                              has a trust relationship with. The trust
                              relationship is verifiable based on the
                              Authorization Service having recorded the
                              public keys or certificates of trusted
                              Identity Providers in a trust store, this
                              allowing the Authorization Service to
                              verify an Identity Provider’s signature on
                              an authentication token.

                          

                            

                          

                             

                          

                            In looking at the various OAuth RFCs,
                            particularly RFCs 7521, 7522, and 7523, I
                            see that they get me close in terms of
                            supporting the use case. What is missing is
                            a means for solving the following problem.
                            These RFCs require that the Identity
                            Provider put an Audience claim in the
                            authentication token. The problem with this
                            is that I do not see in the RFCs how the
                            Identity Provider can be told who the
                            Audience is to put into the authentication
                            token. This leads me to the title of this
                            message. The draft “OAuth 2.0 Token
                            Exchange: An STS for the REST of Us†defines
                            a mechanism for identifying the Audience for
                            an STS to put into a token it generates.
                            That would solve my problem except that the
                            draft limits the type of STS to being
                            Authorization Servers. What is needed is
                            this same capability for interacting with an
                            Identity Provider. This would enable RFCs
                            7521, 7522 and 7523 to be useful in
                            situation where the Identity Provider needs
                            to be told the identity of the Authorization
                            Service.

                          

                             

                          

                            I am new to interacting with the IETF. I
                            also am not an expert on the RFCs or prior
                            history of the OAuth group relative to this
                            topic, so please point me to any existing
                            solution if this is a solved problem.
                            Otherwise, I would like to get feedback on
                            my suggestion.

                          

                             

                          

                            Thanks You,

                          

                            

                          

                          

                            Andrew Fregly

                          

                            Verisign Inc.

                        

                        

                        

                        _______________________________________________

                        OAuth
                          mailing list

                        OAuth@ietf.org

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

                    

                  

                  

                

              

            

          

        

      
      

      

      

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


    

    

  


--------------070909030202010903040501--


From nobody Tue Apr 19 13:19:42 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF3512D863 for ; Tue, 19 Apr 2016 13:19:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGzbbprY2EDH for ; Tue, 19 Apr 2016 13:19:36 -0700 (PDT)
Received: from mail-qg0-x261.google.com (mail-qg0-x261.google.com [IPv6:2607:f8b0:400d:c04::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 0756E12D8A8 for ; Tue, 19 Apr 2016 13:19:36 -0700 (PDT)
Received: by mail-qg0-x261.google.com with SMTP id a74so2810184qgf.2 for ; Tue, 19 Apr 2016 13:19:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language:user-agent :mime-version; bh=xadHeNSDhGhyznFuLyMgZzpT70WWgzVygZu27cbfLRw=; b=M/lOlHL48ywAWpTqQ1d9LQy3IMCE2Y+RHyilGQnKIEjSXsy3Bq0+WPfH+DzvYoT2F1 p/jOAU+TGRW509kU8/c6rMaXbSX3hFA/SuGJATvZlijNtncTow09n3NgDuUo5DulUdvs Sbo3/p6Q7zzFMBYewVODRHSfNaSW+OjAQBEsGJuqMiKLMklzYxPZj61q7dCNU/02y+iq NXl/qtPjArlW8xlw7gxzta1WBoBO7i6Ar/jH6WLlD+jUl6G3ZcraIOtBOclI/I6UIauh LUsCY+1kSxFm4hQ/WhO5tcXhKQ4hkUEUob+6aXo/jTNqticJqWkjFzxH3W1Dec4DpyST hy4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:user-agent:mime-version; bh=xadHeNSDhGhyznFuLyMgZzpT70WWgzVygZu27cbfLRw=; b=HJb0v/9zOgEMQ/Duw9c257S17qd04ZEXLMlUCdBmMh7BQ+sSeW2XyqrQxYKUeXw9nl 7/du4xCUeSwuOuOIpoYWvV0FBkLetuZm5X+oQgnxZQSMDD4sew0qzwLZ2efUxEYZ25b4 W2auCDZdeJD1O4EshSl5SEZHer5qZh1Eh3WbR6j4le9WxeSD2qZH2647lZXclLIDZWJX HmUEiHMRNyKZmCjnkoMM4vwFNU946op7T1tK0YV+ZIXgHkPg103v8encEcTgXbDxxN4U eq66CWjezwxjcmJZEsOgJEc1sccPKyNaj+mH+Hr/EON2AeP0vV5yHp2HAKy/SunP8b3A bVTQ==
X-Gm-Message-State: AOPr4FXMTvMVvJ4pLD0LbXBVSgodBqJJNGnN0F5Sovv9Rn+6bAp6N+TZ2VL3ilUdMNo60ceO+Yg7MKMAtiwWArI6Aj/dlJ9I
X-Received: by 10.55.71.66 with SMTP id u63mr6450777qka.67.1461097175113; Tue, 19 Apr 2016 13:19:35 -0700 (PDT)
Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id 13sm1135174qkg.5.2016.04.19.13.19.34 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 19 Apr 2016 13:19:35 -0700 (PDT)
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 u3JKJYxI015820 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Apr 2016 16:19:34 -0400
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 19 Apr 2016 16:19:32 -0400
From: "Fregly, Andrew" 
To: Brian Campbell , John Bradley 
Thread-Topic: =?utf-8?B?W09BVVRILVdHXSBCdWlsZGluZyBvbiB0aGUgcHJvdG9jb2wgaW4gdGhlIGRy?= =?utf-8?B?YWZ0IOKAnE9BdXRoIDIuMCBUb2tlbiBFeGNoYW5nZTogQW4gU1RTIGZvciB0?= =?utf-8?B?aGUgUkVTVCBvZiBVc+KAnSB0byBpbmNsdWRlIEF1dGhlbnRpY2F0aW9uIFRv?= =?utf-8?Q?kens?=
Thread-Index: AQHRmmmltTMKsQ6A10ecv0+1vsUllp+RvLyA
Date: Tue, 19 Apr 2016 20:19:31 +0000
Message-ID: <97FB56BD-0990-4A46-AA98-B0E5C2A8994C@verisign.com>
References:   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.160212
x-originating-ip: [10.173.152.4]
Content-Type: multipart/alternative; boundary="_000_97FB56BD09904A46AA98B0E5C2A8994Cverisigncom_"
MIME-Version: 1.0
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] =?utf-8?q?Building_on_the_protocol_in_the_draft_?= =?utf-8?q?=E2=80=9COAuth_2=2E0_Token_Exchange=3A_An_STS_for_the_REST_of_U?= =?utf-8?q?s=E2=80=9D_to_include_Authentication_Tokens?=
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Apr 2016 20:19:41 -0000

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

QnJpYW4sDQoNCk9uY2UgYWdhaW4sIHRoYW5rIHlvdSBmb3IgeW91ciBpbnB1dC4gUGVyIG15IHBy
aW9yIHJlc3BvbnNlIHRvIEpvaG4gQnJhZGxleSwgb3VyIHVzZSBjYXNlIGhhcyB0aGUgSWRlbnRp
dHkgUHJvdmlkZXIgYmVpbmcgcHJvdmlkZWQgYnkgYSBkaWZmZXJlbnQgb3JnYW5pemF0aW9uIHRo
YW4gdGhlIG9yZ2FuaXphdGlvbiBwcm92aWRpbmcgdGhlIEF1dGhvcml6YXRpb24gU2VydmljZS4N
Cg0KVGhhbmtzLA0KICAgICBBbmR5DQoNCkZyb206IEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxA
cGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+Pg0KRGF0
ZTogVHVlc2RheSwgQXByaWwgMTksIDIwMTYgYXQgMjozMCBQTQ0KVG86IEpvaG4gQnJhZGxleSA8
dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4NCkNjOiBBbmRyZXcg
RnJlZ2x5IDxhZnJlZ2x5QHZlcmlzaWduLmNvbTxtYWlsdG86YWZyZWdseUB2ZXJpc2lnbi5jb20+
PiwgIm9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4iIDxvYXV0aEBpZXRmLm9y
ZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQnVpbGRp
bmcgb24gdGhlIHByb3RvY29sIGluIHRoZSBkcmFmdCDigJxPQXV0aCAyLjAgVG9rZW4gRXhjaGFu
Z2U6IEFuIFNUUyBmb3IgdGhlIFJFU1Qgb2YgVXPigJ0gdG8gaW5jbHVkZSBBdXRoZW50aWNhdGlv
biBUb2tlbnMNCg0KVGhlIFRva2VuIEV4Y2hhbmdlIGRyYWZ0IGRvZXMgcHV0IHRoZSBBdXRob3Jp
emF0aW9uIFNlcnZlciAoQVMpIGluIHRoZSByb2xlIG9mIFNUUyBiZWNhdXNlIGl0J3MgYW4gZXh0
ZW5zaW9uIG9mIE9BdXRoLiBCdXQgdGhhdCBzaG91bGRuJ3QgYmUgdmlld2VkIGFzIGxpbWl0aW5n
LiBBbiBBUyBpcyBvZnRlbiBkZXBsb3llZCBhcyBvbmUgcGFydCBvZiBhbiBJZGVudGl0eSBQcm92
aWRlci4gT3BlbklEIENvbm5lY3QsIGFzIEpvaG4gbWVudGlvbmVkLCBpcyBvbmUgc3RhbmRhcmQg
dGhhdCBjb21iaW5lcyB0aGUgcm9sZXMuIEFuZCBtYW55IHByb2R1Y3RzL3NlcnZpY2VzL2RlcGxv
eW1lbnRzIGhhdmUgYW4gQVMgYXMgcGFydCBvZiB0aGVpciBvdmVyYWxsIElkZW50aXR5IFByb3Zp
ZGVyIG9mZmVyaW5nLCB3aGljaCBtaWdodCBhbHNvIGhhdmUgT3BlbklEIENvbm5lY3QsIFNBTUws
IGV0Yy4NCg0KT24gVHVlLCBBcHIgMTksIDIwMTYgYXQgMTI6MDYgUE0sIEpvaG4gQnJhZGxleSA8
dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4gd3JvdGU6DQpMb29r
aW5nIGF0IE9wZW5JRCBDb25uZWN0IGFuZCBpdOKAmXMgdHJ1c3QgbW9kZWwgZm9yIHByb2R1Y2lu
ZyBpZF90b2tlbnMgdGhhdCBhc3NlcnQgaWRlbnRpdHkgbWF5IGhlbHAgeW91Lg0KaHR0cDovL29w
ZW5pZC5uZXQvd2cvY29ubmVjdC8NCg0KVW5mb3J0dW5hdGVseSBJIGNhbuKAmXQgcXVpdGUgbWFr
ZSBvdXQgd2hhdCB5b3UgYXJlIHRyeWluZyB0byBkby4NCg0KSXQgc29ydCBvZiBzb3VuZHMgbGlr
ZSB5b3Ugd2FudCBhbiBpZF90b2tlbiBmcm9tIGEgaWRQIGFuZCB0aGVuIGhhdmUgdGhlIGNsaWVu
dCBleGNoYW5nZSB0aGF0IGFzc2VydGlvbiBmb3IgYW5vdGhlciB0b2tlbj8NCg0KSm9obiBCLg0K
T24gQXByIDE5LCAyMDE2LCBhdCAxOjE4IFBNLCBGcmVnbHksIEFuZHJldyA8YWZyZWdseUB2ZXJp
c2lnbi5jb208bWFpbHRvOmFmcmVnbHlAdmVyaXNpZ24uY29tPj4gd3JvdGU6DQoNCkkgaGF2ZSBh
IHVzZSBjYXNlIHdoZXJlIGEgY2xpZW50IGFwcGxpY2F0aW9uIG5lZWRzIHRvIGF1dGhlbnRpY2F0
ZSB3aXRoIGEgZHluYW1pY2FsbHkgZGV0ZXJtaW5lZCBJZGVudGl0eSBQcm92aWRlciB0aGF0IGlz
IHNlcGFyYXRlIGZyb20gdGhlIEF1dGhvcml6YXRpb24gU2VydmljZSB0aGF0IHdpbGwgYmUgdXNl
ZCBpc3N1ZSBhbiBhY2Nlc3MgdG9rZW4gdG8gdGhlIGNsaWVudC4gVGhlIHVzZSBjYXNlIGFsc28g
cmVxdWlyZXMgdGhhdCBhcyBwYXJ0IG9mIGF1dGhvcml6YXRpb24sIHRoZSBjbGllbnQgcHJvdmlk
ZXMgdG8gdGhlIEF1dGhvcml6YXRpb24gU2VydmljZSBhbiBhdXRoZW50aWNhdGlvbiB0b2tlbiBz
aWduZWQgYnkgYW4gSWRlbnRpdHkgUHJvdmlkZXIgdGhhdCB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2
aWNlIGhhcyBhIHRydXN0IHJlbGF0aW9uc2hpcCB3aXRoLiBUaGUgdHJ1c3QgcmVsYXRpb25zaGlw
IGlzIHZlcmlmaWFibGUgYmFzZWQgb24gdGhlIEF1dGhvcml6YXRpb24gU2VydmljZSBoYXZpbmcg
cmVjb3JkZWQgdGhlIHB1YmxpYyBrZXlzIG9yIGNlcnRpZmljYXRlcyBvZiB0cnVzdGVkIElkZW50
aXR5IFByb3ZpZGVycyBpbiBhIHRydXN0IHN0b3JlLCB0aGlzIGFsbG93aW5nIHRoZSBBdXRob3Jp
emF0aW9uIFNlcnZpY2UgdG8gdmVyaWZ5IGFuIElkZW50aXR5IFByb3ZpZGVy4oCZcyBzaWduYXR1
cmUgb24gYW4gYXV0aGVudGljYXRpb24gdG9rZW4uDQoNCkluIGxvb2tpbmcgYXQgdGhlIHZhcmlv
dXMgT0F1dGggUkZDcywgcGFydGljdWxhcmx5IFJGQ3MgNzUyMSwgNzUyMiwgYW5kIDc1MjMsIEkg
c2VlIHRoYXQgdGhleSBnZXQgbWUgY2xvc2UgaW4gdGVybXMgb2Ygc3VwcG9ydGluZyB0aGUgdXNl
IGNhc2UuIFdoYXQgaXMgbWlzc2luZyBpcyBhIG1lYW5zIGZvciBzb2x2aW5nIHRoZSBmb2xsb3dp
bmcgcHJvYmxlbS4gVGhlc2UgUkZDcyByZXF1aXJlIHRoYXQgdGhlIElkZW50aXR5IFByb3ZpZGVy
IHB1dCBhbiBBdWRpZW5jZSBjbGFpbSBpbiB0aGUgYXV0aGVudGljYXRpb24gdG9rZW4uIFRoZSBw
cm9ibGVtIHdpdGggdGhpcyBpcyB0aGF0IEkgZG8gbm90IHNlZSBpbiB0aGUgUkZDcyBob3cgdGhl
IElkZW50aXR5IFByb3ZpZGVyIGNhbiBiZSB0b2xkIHdobyB0aGUgQXVkaWVuY2UgaXMgdG8gcHV0
IGludG8gdGhlIGF1dGhlbnRpY2F0aW9uIHRva2VuLiBUaGlzIGxlYWRzIG1lIHRvIHRoZSB0aXRs
ZSBvZiB0aGlzIG1lc3NhZ2UuIFRoZSBkcmFmdCDigJxPQXV0aCAyLjAgVG9rZW4gRXhjaGFuZ2U6
IEFuIFNUUyBmb3IgdGhlIFJFU1Qgb2YgVXPigJ0gZGVmaW5lcyBhIG1lY2hhbmlzbSBmb3IgaWRl
bnRpZnlpbmcgdGhlIEF1ZGllbmNlIGZvciBhbiBTVFMgdG8gcHV0IGludG8gYSB0b2tlbiBpdCBn
ZW5lcmF0ZXMuIFRoYXQgd291bGQgc29sdmUgbXkgcHJvYmxlbSBleGNlcHQgdGhhdCB0aGUgZHJh
ZnQgbGltaXRzIHRoZSB0eXBlIG9mIFNUUyB0byBiZWluZyBBdXRob3JpemF0aW9uIFNlcnZlcnMu
IFdoYXQgaXMgbmVlZGVkIGlzIHRoaXMgc2FtZSBjYXBhYmlsaXR5IGZvciBpbnRlcmFjdGluZyB3
aXRoIGFuIElkZW50aXR5IFByb3ZpZGVyLiBUaGlzIHdvdWxkIGVuYWJsZSBSRkNzIDc1MjEsIDc1
MjIgYW5kIDc1MjMgdG8gYmUgdXNlZnVsIGluIHNpdHVhdGlvbiB3aGVyZSB0aGUgSWRlbnRpdHkg
UHJvdmlkZXIgbmVlZHMgdG8gYmUgdG9sZCB0aGUgaWRlbnRpdHkgb2YgdGhlIEF1dGhvcml6YXRp
b24gU2VydmljZS4NCg0KSSBhbSBuZXcgdG8gaW50ZXJhY3Rpbmcgd2l0aCB0aGUgSUVURi4gSSBh
bHNvIGFtIG5vdCBhbiBleHBlcnQgb24gdGhlIFJGQ3Mgb3IgcHJpb3IgaGlzdG9yeSBvZiB0aGUg
T0F1dGggZ3JvdXAgcmVsYXRpdmUgdG8gdGhpcyB0b3BpYywgc28gcGxlYXNlIHBvaW50IG1lIHRv
IGFueSBleGlzdGluZyBzb2x1dGlvbiBpZiB0aGlzIGlzIGEgc29sdmVkIHByb2JsZW0uIE90aGVy
d2lzZSwgSSB3b3VsZCBsaWtlIHRvIGdldCBmZWVkYmFjayBvbiBteSBzdWdnZXN0aW9uLg0KDQpU
aGFua3MgWW91LA0KDQpBbmRyZXcgRnJlZ2x5DQpWZXJpc2lnbiBJbmMuDQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpP
QXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8
bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vYXV0aA0KDQoNCg==

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

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8
ZGl2PkJyaWFuLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+T25jZSBhZ2FpbiwgdGhh
bmsgeW91IGZvciB5b3VyIGlucHV0LiBQZXIgbXkgcHJpb3IgcmVzcG9uc2UgdG8gSm9obiBCcmFk
bGV5LCBvdXIgdXNlIGNhc2UgaGFzIHRoZSBJZGVudGl0eSBQcm92aWRlciBiZWluZyBwcm92aWRl
ZCBieSBhIGRpZmZlcmVudCBvcmdhbml6YXRpb24gdGhhbiB0aGUgb3JnYW5pemF0aW9uIHByb3Zp
ZGluZyB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2aWNlLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8
L2Rpdj4NCjxkaXY+VGhhbmtzLDwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7ICZuYnNwO0FuZHk8
L2Rpdj4NCjxkaXY+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JD
X0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNp
emU6MTJwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVk
aXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsg
UEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRk
ZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQi
Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5CcmlhbiBDYW1w
YmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIj5iY2Ft
cGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp
Z2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5UdWVzZGF5LCBBcHJpbCAxOSwgMjAxNiBhdCAyOjMwIFBN
PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+Sm9obiBCcmFk
bGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iPnZlN2p0YkB2ZTdqdGIu
Y29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bh
bj5BbmRyZXcgRnJlZ2x5ICZsdDs8YSBocmVmPSJtYWlsdG86YWZyZWdseUB2ZXJpc2lnbi5jb20i
PmFmcmVnbHlAdmVyaXNpZ24uY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpvYXV0
aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86
b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0i
Zm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbT0FVVEgtV0ddIEJ1aWxkaW5n
IG9uIHRoZSBwcm90b2NvbCBpbiB0aGUgZHJhZnQg4oCcT0F1dGggMi4wIFRva2VuIEV4Y2hhbmdl
OiBBbiBTVFMgZm9yIHRoZSBSRVNUIG9mIFVz4oCdIHRvIGluY2x1ZGUgQXV0aGVudGljYXRpb24g
VG9rZW5zPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1B
Q19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1
YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXYgZGlyPSJsdHIiPlRoZSBUb2tlbiBFeGNoYW5nZSBkcmFmdCBkb2VzIHB1dCB0
aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgKEFTKSBpbiB0aGUgcm9sZSBvZiBTVFMgYmVjYXVzZSBp
dCdzIGFuIGV4dGVuc2lvbiBvZiBPQXV0aC4gQnV0IHRoYXQgc2hvdWxkbid0IGJlIHZpZXdlZCBh
cyBsaW1pdGluZy4gQW4gQVMgaXMgb2Z0ZW4gZGVwbG95ZWQgYXMgb25lIHBhcnQgb2YgYW4gSWRl
bnRpdHkgUHJvdmlkZXIuIE9wZW5JRCBDb25uZWN0LCBhcyBKb2huDQogbWVudGlvbmVkLCBpcyBv
bmUgc3RhbmRhcmQgdGhhdCBjb21iaW5lcyB0aGUgcm9sZXMuIEFuZCBtYW55IHByb2R1Y3RzL3Nl
cnZpY2VzL2RlcGxveW1lbnRzIGhhdmUgYW4gQVMgYXMgcGFydCBvZiB0aGVpciBvdmVyYWxsIElk
ZW50aXR5IFByb3ZpZGVyIG9mZmVyaW5nLCB3aGljaCBtaWdodCBhbHNvIGhhdmUgT3BlbklEIENv
bm5lY3QsIFNBTUwsIGV0Yy4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEi
Pjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBUdWUsIEFwciAxOSwgMjAxNiBhdCAx
MjowNiBQTSwgSm9obiBCcmFkbGV5IDxzcGFuIGRpcj0ibHRyIj4NCiZsdDs8YSBocmVmPSJtYWls
dG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0iX2JsYW5rIj52ZTdqdGJAdmU3anRiLmNvbTwv
YT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUi
IHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRk
aW5nLWxlZnQ6MWV4Ij4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj5Mb29raW5n
IGF0IE9wZW5JRCBDb25uZWN0IGFuZCBpdOKAmXMgdHJ1c3QgbW9kZWwgZm9yIHByb2R1Y2luZyBp
ZF90b2tlbnMgdGhhdCBhc3NlcnQgaWRlbnRpdHkgbWF5IGhlbHAgeW91Lg0KPGRpdj48YSBocmVm
PSJodHRwOi8vb3BlbmlkLm5ldC93Zy9jb25uZWN0LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9v
cGVuaWQubmV0L3dnL2Nvbm5lY3QvPC9hPjxicj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlVu
Zm9ydHVuYXRlbHkgSSBjYW7igJl0IHF1aXRlIG1ha2Ugb3V0IHdoYXQgeW91IGFyZSB0cnlpbmcg
dG8gZG8uJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JdCBzb3J0IG9mIHNv
dW5kcyBsaWtlIHlvdSB3YW50IGFuIGlkX3Rva2VuIGZyb20gYSBpZFAgYW5kIHRoZW4gaGF2ZSB0
aGUgY2xpZW50IGV4Y2hhbmdlIHRoYXQgYXNzZXJ0aW9uIGZvciBhbm90aGVyIHRva2VuPzwvZGl2
Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Sm9obiBCLjxicj4NCjxkaXY+DQo8YmxvY2txdW90
ZSB0eXBlPSJjaXRlIj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJoNSI+DQo8ZGl2Pk9uIEFwciAxOSwg
MjAxNiwgYXQgMToxOCBQTSwgRnJlZ2x5LCBBbmRyZXcgJmx0OzxhIGhyZWY9Im1haWx0bzphZnJl
Z2x5QHZlcmlzaWduLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFmcmVnbHlAdmVyaXNpZ24uY29tPC9h
PiZndDsgd3JvdGU6PC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2IGNsYXNzPSJoNSI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2Vy
aWY7Zm9udC1zaXplOjE0cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xl
dHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0
LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxk
aXYgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFt
aWx5OkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJwdCI+SSBoYXZlIGEgdXNlIGNh
c2Ugd2hlcmUgYSBjbGllbnQgYXBwbGljYXRpb24gbmVlZHMgdG8gYXV0aGVudGljYXRlIHdpdGgg
YSBkeW5hbWljYWxseSBkZXRlcm1pbmVkIElkZW50aXR5IFByb3ZpZGVyIHRoYXQgaXMgc2VwYXJh
dGUgZnJvbSB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2aWNlDQogdGhhdCB3aWxsIGJlIHVzZWQgaXNz
dWUgYW4gYWNjZXNzIHRva2VuIHRvIHRoZSBjbGllbnQuIFRoZSB1c2UgY2FzZSBhbHNvIHJlcXVp
cmVzIHRoYXQgYXMgcGFydCBvZiBhdXRob3JpemF0aW9uLCB0aGUgY2xpZW50IHByb3ZpZGVzIHRv
IHRoZSBBdXRob3JpemF0aW9uIFNlcnZpY2UgYW4gYXV0aGVudGljYXRpb24gdG9rZW4gc2lnbmVk
IGJ5IGFuIElkZW50aXR5IFByb3ZpZGVyIHRoYXQgdGhlIEF1dGhvcml6YXRpb24gU2VydmljZSBo
YXMgYSB0cnVzdA0KIHJlbGF0aW9uc2hpcCB3aXRoLiBUaGUgdHJ1c3QgcmVsYXRpb25zaGlwIGlz
IHZlcmlmaWFibGUgYmFzZWQgb24gdGhlIEF1dGhvcml6YXRpb24gU2VydmljZSBoYXZpbmcgcmVj
b3JkZWQgdGhlIHB1YmxpYyBrZXlzIG9yIGNlcnRpZmljYXRlcyBvZiB0cnVzdGVkIElkZW50aXR5
IFByb3ZpZGVycyBpbiBhIHRydXN0IHN0b3JlLCB0aGlzIGFsbG93aW5nIHRoZSBBdXRob3JpemF0
aW9uIFNlcnZpY2UgdG8gdmVyaWZ5IGFuIElkZW50aXR5IFByb3ZpZGVy4oCZcw0KIHNpZ25hdHVy
ZSBvbiBhbiBhdXRoZW50aWNhdGlvbiB0b2tlbi48L3NwYW4+PGEgbmFtZT0ibV82MjUzMDc0OTMy
MjQ5MzQyNzM3X09MRV9MSU5LNSI+PC9hPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBpbiAw
aW4gMC4wMDAxcHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PHU+PC91Pjx1
PjwvdT48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0O2ZvbnQtc2l6
ZToxMnB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9kaXY+DQo8
ZGl2IHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250LWZh
bWlseTpDYWxpYnJpIj5JbiBsb29raW5nIGF0IHRoZSB2YXJpb3VzIE9BdXRoIFJGQ3MsIHBhcnRp
Y3VsYXJseSBSRkNzIDc1MjEsIDc1MjIsIGFuZCA3NTIzLCBJIHNlZSB0aGF0IHRoZXkgZ2V0IG1l
IGNsb3NlIGluIHRlcm1zIG9mIHN1cHBvcnRpbmcgdGhlIHVzZSBjYXNlLiBXaGF0IGlzIG1pc3Np
bmcgaXMgYSBtZWFucyBmb3Igc29sdmluZyB0aGUNCiBmb2xsb3dpbmcgcHJvYmxlbS4gVGhlc2Ug
UkZDcyByZXF1aXJlIHRoYXQgdGhlIElkZW50aXR5IFByb3ZpZGVyIHB1dCBhbiBBdWRpZW5jZSBj
bGFpbSBpbiB0aGUgYXV0aGVudGljYXRpb24gdG9rZW4uIFRoZSBwcm9ibGVtIHdpdGggdGhpcyBp
cyB0aGF0IEkgZG8gbm90IHNlZSBpbiB0aGUgUkZDcyBob3cgdGhlIElkZW50aXR5IFByb3ZpZGVy
IGNhbiBiZSB0b2xkIHdobyB0aGUgQXVkaWVuY2UgaXMgdG8gcHV0IGludG8gdGhlIGF1dGhlbnRp
Y2F0aW9uDQogdG9rZW4uIFRoaXMgbGVhZHMgbWUgdG8gdGhlIHRpdGxlIG9mIHRoaXMgbWVzc2Fn
ZS4gVGhlIGRyYWZ0IOKAnE9BdXRoIDIuMCBUb2tlbiBFeGNoYW5nZTogQW4gU1RTIGZvciB0aGUg
UkVTVCBvZiBVc+KAnSBkZWZpbmVzIGEgbWVjaGFuaXNtIGZvciBpZGVudGlmeWluZyB0aGUgQXVk
aWVuY2UgZm9yIGFuIFNUUyB0byBwdXQgaW50byBhIHRva2VuIGl0IGdlbmVyYXRlcy4gVGhhdCB3
b3VsZCBzb2x2ZSBteSBwcm9ibGVtIGV4Y2VwdCB0aGF0IHRoZSBkcmFmdA0KIGxpbWl0cyB0aGUg
dHlwZSBvZiBTVFMgdG8gYmVpbmcgQXV0aG9yaXphdGlvbiBTZXJ2ZXJzLiBXaGF0IGlzIG5lZWRl
ZCBpcyB0aGlzIHNhbWUgY2FwYWJpbGl0eSBmb3IgaW50ZXJhY3Rpbmcgd2l0aCBhbiBJZGVudGl0
eSBQcm92aWRlci4gVGhpcyB3b3VsZCBlbmFibGUgUkZDcyA3NTIxLCA3NTIyIGFuZCA3NTIzIHRv
IGJlIHVzZWZ1bCBpbiBzaXR1YXRpb24gd2hlcmUgdGhlIElkZW50aXR5IFByb3ZpZGVyIG5lZWRz
IHRvIGJlIHRvbGQgdGhlIGlkZW50aXR5DQogb2YgdGhlIEF1dGhvcml6YXRpb24gU2VydmljZS48
dT48L3U+PHU+PC91PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7
Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PHU+PC91PiZuYnNwOzx1PjwvdT48
L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0O2ZvbnQtc2l6ZToxMnB0
O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkkgYW0gbmV3IHRvIGludGVyYWN0aW5nIHdpdGggdGhlIElF
VEYuIEkgYWxzbyBhbSBub3QgYW4gZXhwZXJ0IG9uIHRoZSBSRkNzIG9yIHByaW9yIGhpc3Rvcnkg
b2YgdGhlIE9BdXRoIGdyb3VwIHJlbGF0aXZlIHRvIHRoaXMgdG9waWMsIHNvIHBsZWFzZSBwb2lu
dCBtZSB0byBhbnkgZXhpc3Rpbmcgc29sdXRpb24gaWYgdGhpcw0KIGlzIGEgc29sdmVkIHByb2Js
ZW0uIE90aGVyd2lzZSwgSSB3b3VsZCBsaWtlIHRvIGdldCBmZWVkYmFjayBvbiBteSBzdWdnZXN0
aW9uLjx1PjwvdT48dT48L3U+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAw
MDFwdDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTpDYWxpYnJpIj48dT48L3U+Jm5ic3A7PHU+
PC91PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7Zm9udC1zaXpl
OjEycHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+VGhhbmtzIFlvdSw8L2Rpdj4NCjxkaXYgc3R5bGU9
Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OkNhbGli
cmkiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7Zm9u
dC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+QW5kcmV3IEZyZWdseTx1PjwvdT48dT48
L3U+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFwdDtmb250LXNpemU6
MTJwdDtmb250LWZhbWlseTpDYWxpYnJpIj5WZXJpc2lnbiBJbmMuPC9kaXY+DQo8L2Rpdj4NCjxk
aXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjtmb250LXNpemU6MTRweDtm
b250LXN0eWxlOm5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFs
O3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hp
dGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2luZzowcHgiPg0KPGRpdj48L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z
ZXJpZjsgZm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu
b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu
ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29y
ZC1zcGFjaW5nOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsi
Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxi
ciBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxNHB4O2Zv
bnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7
dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0
ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9y
bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFs
aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl
LXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTog
aW5saW5lICFpbXBvcnRhbnQ7Ij5PQXV0aA0KIG1haWxpbmcgbGlzdDwvc3Bhbj48YnIgc3R5bGU9
ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjtmb250LXNpemU6MTRweDtmb250LXN0eWxl
Om5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxp
Z246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6
bm9ybWFsO3dvcmQtc3BhY2luZzowcHgiPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn
IiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxNHB4O2Zv
bnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7
dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0
ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweCIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGll
dGYub3JnPC9hPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmO2ZvbnQt
c2l6ZToxNHB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3Bh
Y2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zv
cm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweCI+DQo8YSBocmVmPSJo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiBzdHlsZT0iZm9udC1m
YW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxNHB4O2ZvbnQtc3R5bGU6bm9ybWFs
O2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFy
dDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7
d29yZC1zcGFjaW5nOjBweCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxi
cj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEg
aHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBo
cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiByZWw9Im5v
cmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29hdXRoPC9hPjxicj4NCjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPC9ib2R5Pg0K
PC9odG1sPg0K

--_000_97FB56BD09904A46AA98B0E5C2A8994Cverisigncom_--


From nobody Tue Apr 19 13:27:13 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D260912E1C0 for ; Tue, 19 Apr 2016 13:27:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnB2CX8mFSh8 for ; Tue, 19 Apr 2016 13:27:08 -0700 (PDT)
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 46CEC12E1B0 for ; Tue, 19 Apr 2016 13:27:08 -0700 (PDT)
Received: by mail-qg0-x230.google.com with SMTP id c6so16707289qga.1 for ; Tue, 19 Apr 2016 13:27:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=2ESrdEwhJ1m/quD0IwTTGKDH2K7xmo/kdSEWO3vyM6E=; b=AnBr7fFpSEy7ym1Q04fZ0vJaoKQ47kwTUW9nWJk2v7cuJBE91oLa0RM5+bczqwMsUT HT56oM09grA3tNHDF7W81SQ5f/pOOi97TWvgvOyb3zhRMPhdWaOm2VEpwwfQ1HoN50yI +alL+ov3v9pNtTH/huJR5r7tmz9enlgQHBEB000raFit9Gb8lW905g0ZKlCCIcYo7wG9 b7LEHeuKfjHmaqEzLWLB3e7udAgrw0pgZVfx5RCxnXBQ9aQht8xNOJpSfOmktvon8e5K W5rfINaAPzckBHJjn9Pp3wY3xNOUYeHj+HmRUFycvfQXZessIjD9a+Xed7wCw5FxIlpa hFfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=2ESrdEwhJ1m/quD0IwTTGKDH2K7xmo/kdSEWO3vyM6E=; b=U7tNFD98WOIpgrXkC7ytDaxNivwxcEIaojSL8rVNkdFq27xGYhJdyYgF5q9g9MvJYa sLBb0hjJHA2fPCciAe/udxKkZWku7H+4wEz0F0lQKMK83OMWWEdA4uCX0BvHPoySHRs8 44xfPAUTsegZeBpY89CKi5kcsRL7RpnGZcNQ6M8q03BbBVKIJSMl8e0xpgMX1guF0reP q1rMbVdeUQZ+tQPVBgXExRmNwxNHHteqStXY8ROBGEn0374jm5SIteaepFcOSmSmdvr+ nbnqf+hC9B59bYTgscV6TWgynXhrbcma5cB0mhuCFFwp4U6aFureiIIpvyvUESGSZXIo yt7Q==
X-Gm-Message-State: AOPr4FX/HuvYAsKVv1RgR0TsYq4Rgdr9Ha7l9cCZqj4S8mf3qNx51ehorJhEAeAujrAU7A==
X-Received: by 10.140.232.15 with SMTP id d15mr6654503qhc.87.1461097627082; Tue, 19 Apr 2016 13:27:07 -0700 (PDT)
Received: from [192.168.8.100] ([181.202.68.46]) by smtp.gmail.com with ESMTPSA id n1sm13435847qkn.3.2016.04.19.13.27.05 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 19 Apr 2016 13:27:06 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_D9A3626A-734A-4C1B-8C90-F66E559D3430"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: John Bradley 
In-Reply-To: <8B748252-9AE2-4824-923B-00CD46CB8D68@verisign.com>
Date: Tue, 19 Apr 2016 17:27:02 -0300
Message-Id: <4382930D-CADD-466A-B078-B121B8E894E5@ve7jtb.com>
References:   <8B748252-9AE2-4824-923B-00CD46CB8D68@verisign.com>
To: "Fregly, Andrew" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] =?utf-8?q?Building_on_the_protocol_in_the_draft_?= =?utf-8?q?=E2=80=9COAuth__2=2E0_Token_Exchange=3A_An_STS_for_the_REST_of_?= =?utf-8?q?Us=E2=80=9D_to_include_Authentication_Tokens?=
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Apr 2016 20:27:12 -0000

--Apple-Mail=_D9A3626A-734A-4C1B-8C90-F66E559D3430
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

You can use connect just as a authentication service as you would SAML.

Lots of SaaS providers have a authorization service that chains to a =
external authentication service via SAML or Connect by use of a browser.

I am not getting what is front channel with the user and what is back =
channel.

Is the user authenticating with the service that provides the role info, =
or are you trying to do that in the back channel via a token exchange.

I probably need a diagram.

John B.
> On Apr 19, 2016, at 5:05 PM, Fregly, Andrew  =
wrote:
>=20
> Thanks for your response John. I also got a good response from Brian =
Campbell and appreciate that. I will respond separately to Brian=E2=80=99s=
 response as I think it would keep things clearer to do that.
>=20
> The problem we have for using OpenID Connect is that it combines the =
role of Authentication Service with the role of Authorization Service. =
Perhaps the following description of what we want to do will clarify why =
this won=E2=80=99t work for us:
>=20
> The basic problem statement is that we need to have a client =
application authorized by a Service Provider based on proof that a user =
is currently a member of some organization. This assumes the =
organization has previously established some level of authorized access =
with the Service Provider.=20
>=20
> Here is an example: Suppose I am a member of SomeOrg Inc. Suppose =
SomeOrg Inc. is doing research that requires it to gather data over the =
Internet from a number of data providers. The data providers require =
authentication and proof of organizational membership in order to =
authorize various levels of access to their data. The data providers do =
not consider having an account with them or a Public Identity Provider =
to be suitable for proving that I am still a member of SomeOrg at time =
of authentication. They would have no way of knowing whether or not my =
relationship with SomeOrg still exists at that time. The data providers =
would therefore like the Client software to authenticate me against =
SomeOrgs Identity Provider. This would be good proof that I am still a =
member of SomeOrg at the time I authenticate. This authentication would =
enable the data providers Authorization Server to grant me access =
appropriate to a member of SomeOrg.  Note that as a prerequisite to all =
of this, SomeOrg will have used an out-of-band process to set up a trust =
relationship for SomeOrg's Identity Provider with the data provider=E2=80=99=
s Authorization Service, and will have negotiated authorization claims =
to be granted to SomeOrgs members.
>=20
> What I am having difficulty with is in knitting together an approach =
based on the he OpenID Connect specifications, SAML specifications, and =
OAuth RFCs and drafts in a way that supports the above use case =
end-to-end. The OAuth RFCs and drafts almost get me there. What seems to =
be missing is a way of telling an Identity Provider the URL for the =
Authorization Service (the required Audience claim in an authentication =
assertion as defined in RFCs 7251, 7252 and 7253), and then a =
requirement that the Identity Providers put the supplied Audience =
Identifier into Authentication Tokens. Perhaps a little further =
back-and-forth with Brian will resolve this.
>=20
> I can go into deeper detail if needed. If this is off-topic for the =
OAuth working group, let me know.
>=20
> Thanks,
> Andrew Fregly
> Verisign Inc.
>=20
>=20
> From: John Bradley >
> Date: Tuesday, April 19, 2016 at 2:06 PM
> To: Andrew Fregly >
> Cc: "oauth@ietf.org " >
> Subject: Re: [OAUTH-WG] Building on the protocol in the draft =E2=80=9CO=
Auth 2.0 Token Exchange: An STS for the REST of Us=E2=80=9D to include =
Authentication Tokens
>=20
>> Looking at OpenID Connect and it=E2=80=99s trust model for producing =
id_tokens that assert identity may help you.
>> http://openid.net/wg/connect/ 
>>=20
>> Unfortunately I can=E2=80=99t quite make out what you are trying to =
do.=20
>>=20
>> It sort of sounds like you want an id_token from a idP and then have =
the client exchange that assertion for another token?
>>=20
>> John B.
>>> On Apr 19, 2016, at 1:18 PM, Fregly, Andrew > wrote:
>>>=20
>>> I have a use case where a client application needs to authenticate =
with a dynamically determined Identity Provider that is separate from =
the Authorization Service that will be used issue an access token to the =
client. The use case also requires that as part of authorization, the =
client provides to the Authorization Service an authentication token =
signed by an Identity Provider that the Authorization Service has a =
trust relationship with. The trust relationship is verifiable based on =
the Authorization Service having recorded the public keys or =
certificates of trusted Identity Providers in a trust store, this =
allowing the Authorization Service to verify an Identity Provider=E2=80=99=
s signature on an authentication token. <>
>>> =20
>>> In looking at the various OAuth RFCs, particularly RFCs 7521, 7522, =
and 7523, I see that they get me close in terms of supporting the use =
case. What is missing is a means for solving the following problem. =
These RFCs require that the Identity Provider put an Audience claim in =
the authentication token. The problem with this is that I do not see in =
the RFCs how the Identity Provider can be told who the Audience is to =
put into the authentication token. This leads me to the title of this =
message. The draft =E2=80=9COAuth 2.0 Token Exchange: An STS for the =
REST of Us=E2=80=9D defines a mechanism for identifying the Audience for =
an STS to put into a token it generates. That would solve my problem =
except that the draft limits the type of STS to being Authorization =
Servers. What is needed is this same capability for interacting with an =
Identity Provider. This would enable RFCs 7521, 7522 and 7523 to be =
useful in situation where the Identity Provider needs to be told the =
identity of the Authorization Service.
>>> =20
>>> I am new to interacting with the IETF. I also am not an expert on =
the RFCs or prior history of the OAuth group relative to this topic, so =
please point me to any existing solution if this is a solved problem. =
Otherwise, I would like to get feedback on my suggestion.
>>> =20
>>> Thanks You,
>>>=20
>>> Andrew Fregly
>>> Verisign Inc.
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth =



--Apple-Mail=_D9A3626A-734A-4C1B-8C90-F66E559D3430
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

You can use connect just as a authentication service as you =
would SAML.

Lots of =
SaaS providers have a authorization service that chains to a external =
authentication service via SAML or Connect by use of a =
browser.

I am =
not getting what is front channel with the user and what is back =
channel.

Is =
the user authenticating with the service that provides the role info, or =
are you trying to do that in the back channel via a token =
exchange.

I =
probably need a diagram.

John B.
On Apr 19, 2016, at 5:05 PM, Fregly, Andrew =
<afregly@verisign.com> wrote:










Thanks for your response John. I also got a good =
response from Brian Campbell and appreciate that. I will respond =
separately to Brian=E2=80=99s response as I think it would keep things =
clearer to do that.







The problem we have for using OpenID Connect is that it =
combines the role of Authentication Service with the role of =
Authorization Service. Perhaps the following description of what we want =
to do will clarify why this won=E2=80=99t work for us:







The basic problem statement is that we need to have a =
client application authorized by a Service Provider based on proof that =
a user is currently a member of some organization. This assumes the =
organization has previously established some level of authorized
 access with the Service Provider. 







Here is an example: Suppose I am a member of SomeOrg =
Inc. Suppose SomeOrg Inc. is doing research that requires it to gather =
data over the Internet from a number of data providers. The data =
providers require authentication and proof of organizational membership
 in order to authorize various levels of access to their data. The data =
providers do not consider having an account with them or a Public =
Identity Provider to be suitable for proving that I am still a member of =
SomeOrg at time of authentication. They would
 have no way of knowing whether or not my relationship with SomeOrg =
still exists at that time. The data providers would therefore like the =
Client software to authenticate me against SomeOrgs Identity Provider. =
This would be good proof that I am still a member
 of SomeOrg at the time I authenticate. This authentication would enable =
the data providers Authorization Server to grant me access appropriate =
to a member of SomeOrg.  Note that as a prerequisite to all of =
this, SomeOrg will have used an out-of-band process
 to set up a trust relationship for SomeOrg's Identity Provider with the =
data provider=E2=80=99s Authorization Service, and will have negotiated =
authorization claims to be granted to SomeOrgs members.







What I am having difficulty with is in knitting together =
an approach based on the he OpenID Connect specifications, SAML =
specifications, and OAuth RFCs and drafts in a way that supports the =
above use case end-to-end. The OAuth RFCs and drafts almost get
 me there. What seems to be missing is a way of telling an Identity =
Provider the URL for the Authorization Service (the required Audience =
claim in an authentication assertion as defined in RFCs 7251, 7252 and =
7253), and then a requirement that the Identity
 Providers put the supplied Audience Identifier into Authentication =
Tokens. Perhaps a little further back-and-forth with Brian will resolve =
this.







I can go into deeper detail if needed. If this is =
off-topic for the OAuth working group, let me know.







Thanks,


Andrew Fregly


Verisign Inc.






















From: John Bradley =
<ve7jtb@ve7jtb.com>

Date: Tuesday, April =
19, 2016 at 2:06 PM

To: Andrew Fregly =
<afregly@verisign.com>

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

Subject: Re: =
[OAUTH-WG] Building on the protocol in the draft =E2=80=9COAuth 2.0 =
Token Exchange: An STS for the REST of Us=E2=80=9D to include =
Authentication Tokens














Looking at OpenID Connect and it=E2=80=99s trust model for producing =
id_tokens that assert identity may help you.

http://openid.net/wg/connect/







Unfortunately I can=E2=80=99t quite make out what you =
are trying to do. 







It sort of sounds like you want an id_token from a idP =
and then have the client exchange that assertion for another =
token?







John B.






On Apr 19, 2016, at 1:18 PM, Fregly, Andrew <afregly@verisign.com> wrote:









I have a use case where a =
client application needs to authenticate with a dynamically determined =
Identity Provider that is separate from the Authorization Service that =
will be used issue an access token to the client.
 The use case also requires that as part of authorization, the client =
provides to the Authorization Service an authentication token signed by =
an Identity Provider that the Authorization Service has a trust =
relationship with. The trust relationship is verifiable
 based on the Authorization Service having recorded the public keys or =
certificates of trusted Identity Providers in a trust store, this =
allowing the Authorization Service to verify an Identity Provider=E2=80=99=
s signature on an authentication token.







 



In looking at the various OAuth RFCs, particularly RFCs 7521, 7522, and =
7523, I see that they get me close in terms of supporting the use case. =
What is missing is a means for solving the following problem. These RFCs =
require that the Identity Provider put an
 Audience claim in the authentication token. The problem with this is =
that I do not see in the RFCs how the Identity Provider can be told who =
the Audience is to put into the authentication token. This leads me to =
the title of this message. The draft =E2=80=9COAuth
 2.0 Token Exchange: An STS for the REST of Us=E2=80=9D defines a =
mechanism for identifying the Audience for an STS to put into a token it =
generates. That would solve my problem except that the draft limits the =
type of STS to being Authorization Servers. What is needed
 is this same capability for interacting with an Identity Provider. This =
would enable RFCs 7521, 7522 and 7523 to be useful in situation where =
the Identity Provider needs to be told the identity of the Authorization =
Service.



 



I am new to interacting with the IETF. I also am not an expert on the =
RFCs or prior history of the OAuth group relative to this topic, so =
please point me to any existing solution if this is a solved problem. =
Otherwise, I would like to get feedback on my suggestion.



 



Thanks You,









Andrew Fregly



Verisign Inc.









_______________________________________________

OAuth
 mailing list

OAuth@ietf.org

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























=

--Apple-Mail=_D9A3626A-734A-4C1B-8C90-F66E559D3430--


From nobody Tue Apr 19 13:34:37 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2411712B061 for ; Tue, 19 Apr 2016 13:34:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FImAG5pq_yfp for ; Tue, 19 Apr 2016 13:34:33 -0700 (PDT)
Received: from mail-qg0-x261.google.com (mail-qg0-x261.google.com [IPv6:2607:f8b0:400d:c04::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 A691112DA34 for ; Tue, 19 Apr 2016 13:34:32 -0700 (PDT)
Received: by mail-qg0-x261.google.com with SMTP id m8so2845430qgd.0 for ; Tue, 19 Apr 2016 13:34:32 -0700 (PDT)
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:user-agent :mime-version; bh=kj82wtloM0j4zh5aEsm3ubxPWkeGOM0tPLmh7smu7lc=; b=rwGEAhi6edeUuiG6h2ggK8wxWT0ZiofhiTCSKbgs0KGMHH2mz1O/uVImZ8HhvdDBm1 +AutEjC677/CiVQ6ZRF6yBOw7pY26/v9WdvwF91hKhkDXU3omlbcZFM1rSlZ0+xOn0XH wTvZNuBumhLijY3FwSz+ltDVXFgwLFLPS0/2DbM85NFQO143Jv2NvaoXdlIhwfSRbK7d sbXSYBAxH+GWKiTtlAsEto4Ctkni99pfA3DueFy14z/p6EYluSWPaR1fT7VRsvaTEI6H JEEY08y4eqZY1JFL0bRFfRZMzo7eZtwaWm4N1377Z4cNhHiWjGwV/7pZllQMIdvt7rPZ quYg==
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 :user-agent:mime-version; bh=kj82wtloM0j4zh5aEsm3ubxPWkeGOM0tPLmh7smu7lc=; b=IPjOVyLvFMjALbhha8Nf98lUESbBaFX3SE8a06EbJtlGFmqfYHHeP5f5P6SeMkql0N n/CUKk4hvdU/J17vmk1ZkFcCi9E/kQNRfgO9ADSDKoC4/RzIudiIKkPuZmv7m1boKxsj D9KNX0R0kTex/cr9cUPOSCD9LHxAV6SBPgEMHqU7qgAdP6LqrlETThxLuT6EBRO2aU2b 70PnaTL5Lpt7qQDi1wzWJ/ZGItjGp4ZDA6caUzy2cSJyqAaewHZ4v9Sisq6XJtWwiyTu bAP4oY8uTHhnGPysiTnlJ7A1WERLW5+auFHihIcZsD4/IawsF5bC6FKvbwLaP7DbgMEf 2J2Q==
X-Gm-Message-State: AOPr4FXP5DGszIRfBSwbbXTklPNN6OpNaaaUHnPu3Nt0ri79/l6J/lxHJhhH0r4WqOQS516XrVSPYRrRPrZUsKN0xy8k4Lc+
X-Received: by 10.140.19.52 with SMTP id 49mr6211305qgg.103.1461098071614; Tue, 19 Apr 2016 13:34:31 -0700 (PDT)
Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id e185sm8467936qkb.6.2016.04.19.13.34.31 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 19 Apr 2016 13:34:31 -0700 (PDT)
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 u3JKYVn8017602 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Apr 2016 16:34:31 -0400
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 19 Apr 2016 16:34:30 -0400
From: "Fregly, Andrew" 
To: Nat Sakimura , John Bradley , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Building on the protocol in the draft "OAuth 2.0 Token Exchange: An STS for the REST of Us" to include Authentication Tokens
Thread-Index: AQHRmnf3unJXk5gQwkmZNEmlF2rMzJ+RwM0A
Date: Tue, 19 Apr 2016 20:34:29 +0000
Message-ID: <5958E90F-EF8C-4641-96C1-A9077B450D53@verisign.com>
References:   <8B748252-9AE2-4824-923B-00CD46CB8D68@verisign.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.160212
x-originating-ip: [10.173.152.4]
Content-Type: multipart/alternative; boundary="_000_5958E90FEF8C464196C1A9077B450D53verisigncom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] Building on the protocol in the draft "OAuth 2.0 Token Exchange: An STS for the REST of Us" to include Authentication Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Apr 2016 20:34:36 -0000

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

VGhhbmtzIGZvciB5b3VyIHJlcGx5IE5hdC4NCg0KRG9lcyB5b3VyIGFwcHJvYWNoIG1hdGNoIHdp
dGggYW4gSUVURiBPQXV0aCBSRkMgb3IgRHJhZnQgZGVzY3JpYmluZyBob3cgYW4gQXV0aG9yaXph
dGlvbiBTZXJ2aWNlIGNhbiBhY2NlcHQgYW5kIHZlcmlmeSBhbiBhdXRoZW50aWNhdGlvbiB0b2tl
biBwcm92aWRlZCBieSBhIGNsaWVudCBkdXJpbmcgdGhlIGF1dGhvcml6YXRpb24gcHJvY2Vzcz8g
SWYgc28sIHBsZWFzZSBwb2ludCBtZSB0byB0aGF0LiBUaGUgb25seSBSRkNzIEkgaGF2ZSBzZWVu
IHRoYXQgYWRkcmVzcyB0aGlzIGFyZSBSRkNzIDcyNTEsIDcyNTIgYW5kIDcyNTMsIGFuZCB0aGV5
IGFsbCBoYXZlIGEgcmVxdWlyZW1lbnQgdGhhdCBhbiDigJxhdWRpZW5jZeKAnSBjbGFpbSBjb3Jy
ZXNwb25kaW5nIHRvIHRoZSBBdXRob3JpemF0aW9uIFNlcnZpY2UgaXMgaW4gdGhlIGF1dGhlbnRp
Y2F0aW9uIHRva2VuLiBHZXR0aW5nIHRoYXQgY2xhaW0gaW50byBhbiBhdXRoZW50aWNhdGlvbiB0
b2tlbiBwcm92aWRlZCBieSBhbiBPcmdhbml6YXRpb27igJlzIElkZW50aXR5IHByb3ZpZGVyIHNl
ZW1zIHRvIGJlIG15IGZ1bmRhbWVudGFsIHByb2JsZW0uDQoNClRoYW5rcywNCiAgICAgIEFuZHkN
Cg0KRnJvbTogTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb208bWFpbHRvOnNha2ltdXJh
QGdtYWlsLmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBBcHJpbCAxOSwgMjAxNiBhdCA0OjEzIFBNDQpU
bzogQW5kcmV3IEZyZWdseSA8YWZyZWdseUB2ZXJpc2lnbi5jb208bWFpbHRvOmFmcmVnbHlAdmVy
aXNpZ24uY29tPj4sIEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0
YkB2ZTdqdGIuY29tPj4sICJvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IiA8
b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FV
VEgtV0ddIEJ1aWxkaW5nIG9uIHRoZSBwcm90b2NvbCBpbiB0aGUgZHJhZnQgIk9BdXRoIDIuMCBU
b2tlbiBFeGNoYW5nZTogQW4gU1RTIGZvciB0aGUgUkVTVCBvZiBVcyIgdG8gaW5jbHVkZSBBdXRo
ZW50aWNhdGlvbiBUb2tlbnMNCg0KR2V0IE9wZW5JRCBDb25uZWN0IGlkX3Rva2VuIGJ5IHRoZSBh
dXRoZW50aWNhdGlvbiByZXF1ZXN0IHdpdGggcHJvbXB0PW5vbmUgYW5kIHZlcmlmeWluZyB0aGUg
c3ViIHRvIGJlIHRoZSBzYW1lIHdpdGggd2hhdCB5b3UgZXhwZWN0ZWQgc2VlbSB0byBzdWZmaWNl
IHlvdXIgbmVlZHMuIEFtIEkgbWlzc2luZyBzb21ldGhpbmc/DQpPbiBXZWQsIEFwciAyMCwgMjAx
NiBhdCAwNTowNSBGcmVnbHksIEFuZHJldyA8YWZyZWdseUB2ZXJpc2lnbi5jb208bWFpbHRvOmFm
cmVnbHlAdmVyaXNpZ24uY29tPj4gd3JvdGU6DQpUaGFua3MgZm9yIHlvdXIgcmVzcG9uc2UgSm9o
bi4gSSBhbHNvIGdvdCBhIGdvb2QgcmVzcG9uc2UgZnJvbSBCcmlhbiBDYW1wYmVsbCBhbmQgYXBw
cmVjaWF0ZSB0aGF0LiBJIHdpbGwgcmVzcG9uZCBzZXBhcmF0ZWx5IHRvIEJyaWFu4oCZcyByZXNw
b25zZSBhcyBJIHRoaW5rIGl0IHdvdWxkIGtlZXAgdGhpbmdzIGNsZWFyZXIgdG8gZG8gdGhhdC4N
Cg0KVGhlIHByb2JsZW0gd2UgaGF2ZSBmb3IgdXNpbmcgT3BlbklEIENvbm5lY3QgaXMgdGhhdCBp
dCBjb21iaW5lcyB0aGUgcm9sZSBvZiBBdXRoZW50aWNhdGlvbiBTZXJ2aWNlIHdpdGggdGhlIHJv
bGUgb2YgQXV0aG9yaXphdGlvbiBTZXJ2aWNlLiBQZXJoYXBzIHRoZSBmb2xsb3dpbmcgZGVzY3Jp
cHRpb24gb2Ygd2hhdCB3ZSB3YW50IHRvIGRvIHdpbGwgY2xhcmlmeSB3aHkgdGhpcyB3b27igJl0
IHdvcmsgZm9yIHVzOg0KDQpUaGUgYmFzaWMgcHJvYmxlbSBzdGF0ZW1lbnQgaXMgdGhhdCB3ZSBu
ZWVkIHRvIGhhdmUgYSBjbGllbnQgYXBwbGljYXRpb24gYXV0aG9yaXplZCBieSBhIFNlcnZpY2Ug
UHJvdmlkZXIgYmFzZWQgb24gcHJvb2YgdGhhdCBhIHVzZXIgaXMgY3VycmVudGx5IGEgbWVtYmVy
IG9mIHNvbWUgb3JnYW5pemF0aW9uLiBUaGlzIGFzc3VtZXMgdGhlIG9yZ2FuaXphdGlvbiBoYXMg
cHJldmlvdXNseSBlc3RhYmxpc2hlZCBzb21lIGxldmVsIG9mIGF1dGhvcml6ZWQgYWNjZXNzIHdp
dGggdGhlIFNlcnZpY2UgUHJvdmlkZXIuDQoNCkhlcmUgaXMgYW4gZXhhbXBsZTogU3VwcG9zZSBJ
IGFtIGEgbWVtYmVyIG9mIFNvbWVPcmcgSW5jLiBTdXBwb3NlIFNvbWVPcmcgSW5jLiBpcyBkb2lu
ZyByZXNlYXJjaCB0aGF0IHJlcXVpcmVzIGl0IHRvIGdhdGhlciBkYXRhIG92ZXIgdGhlIEludGVy
bmV0IGZyb20gYSBudW1iZXIgb2YgZGF0YSBwcm92aWRlcnMuIFRoZSBkYXRhIHByb3ZpZGVycyBy
ZXF1aXJlIGF1dGhlbnRpY2F0aW9uIGFuZCBwcm9vZiBvZiBvcmdhbml6YXRpb25hbCBtZW1iZXJz
aGlwIGluIG9yZGVyIHRvIGF1dGhvcml6ZSB2YXJpb3VzIGxldmVscyBvZiBhY2Nlc3MgdG8gdGhl
aXIgZGF0YS4gVGhlIGRhdGEgcHJvdmlkZXJzIGRvIG5vdCBjb25zaWRlciBoYXZpbmcgYW4gYWNj
b3VudCB3aXRoIHRoZW0gb3IgYSBQdWJsaWMgSWRlbnRpdHkgUHJvdmlkZXIgdG8gYmUgc3VpdGFi
bGUgZm9yIHByb3ZpbmcgdGhhdCBJIGFtIHN0aWxsIGEgbWVtYmVyIG9mIFNvbWVPcmcgYXQgdGlt
ZSBvZiBhdXRoZW50aWNhdGlvbi4gVGhleSB3b3VsZCBoYXZlIG5vIHdheSBvZiBrbm93aW5nIHdo
ZXRoZXIgb3Igbm90IG15IHJlbGF0aW9uc2hpcCB3aXRoIFNvbWVPcmcgc3RpbGwgZXhpc3RzIGF0
IHRoYXQgdGltZS4gVGhlIGRhdGEgcHJvdmlkZXJzIHdvdWxkIHRoZXJlZm9yZSBsaWtlIHRoZSBD
bGllbnQgc29mdHdhcmUgdG8gYXV0aGVudGljYXRlIG1lIGFnYWluc3QgU29tZU9yZ3MgSWRlbnRp
dHkgUHJvdmlkZXIuIFRoaXMgd291bGQgYmUgZ29vZCBwcm9vZiB0aGF0IEkgYW0gc3RpbGwgYSBt
ZW1iZXIgb2YgU29tZU9yZyBhdCB0aGUgdGltZSBJIGF1dGhlbnRpY2F0ZS4gVGhpcyBhdXRoZW50
aWNhdGlvbiB3b3VsZCBlbmFibGUgdGhlIGRhdGEgcHJvdmlkZXJzIEF1dGhvcml6YXRpb24gU2Vy
dmVyIHRvIGdyYW50IG1lIGFjY2VzcyBhcHByb3ByaWF0ZSB0byBhIG1lbWJlciBvZiBTb21lT3Jn
LiAgTm90ZSB0aGF0IGFzIGEgcHJlcmVxdWlzaXRlIHRvIGFsbCBvZiB0aGlzLCBTb21lT3JnIHdp
bGwgaGF2ZSB1c2VkIGFuIG91dC1vZi1iYW5kIHByb2Nlc3MgdG8gc2V0IHVwIGEgdHJ1c3QgcmVs
YXRpb25zaGlwIGZvciBTb21lT3JnJ3MgSWRlbnRpdHkgUHJvdmlkZXIgd2l0aCB0aGUgZGF0YSBw
cm92aWRlcuKAmXMgQXV0aG9yaXphdGlvbiBTZXJ2aWNlLCBhbmQgd2lsbCBoYXZlIG5lZ290aWF0
ZWQgYXV0aG9yaXphdGlvbiBjbGFpbXMgdG8gYmUgZ3JhbnRlZCB0byBTb21lT3JncyBtZW1iZXJz
Lg0KDQpXaGF0IEkgYW0gaGF2aW5nIGRpZmZpY3VsdHkgd2l0aCBpcyBpbiBrbml0dGluZyB0b2dl
dGhlciBhbiBhcHByb2FjaCBiYXNlZCBvbiB0aGUgaGUgT3BlbklEIENvbm5lY3Qgc3BlY2lmaWNh
dGlvbnMsIFNBTUwgc3BlY2lmaWNhdGlvbnMsIGFuZCBPQXV0aCBSRkNzIGFuZCBkcmFmdHMgaW4g
YSB3YXkgdGhhdCBzdXBwb3J0cyB0aGUgYWJvdmUgdXNlIGNhc2UgZW5kLXRvLWVuZC4gVGhlIE9B
dXRoIFJGQ3MgYW5kIGRyYWZ0cyBhbG1vc3QgZ2V0IG1lIHRoZXJlLiBXaGF0IHNlZW1zIHRvIGJl
IG1pc3NpbmcgaXMgYSB3YXkgb2YgdGVsbGluZyBhbiBJZGVudGl0eSBQcm92aWRlciB0aGUgVVJM
IGZvciB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2aWNlICh0aGUgcmVxdWlyZWQgQXVkaWVuY2UgY2xh
aW0gaW4gYW4gYXV0aGVudGljYXRpb24gYXNzZXJ0aW9uIGFzIGRlZmluZWQgaW4gUkZDcyA3MjUx
LCA3MjUyIGFuZCA3MjUzKSwgYW5kIHRoZW4gYSByZXF1aXJlbWVudCB0aGF0IHRoZSBJZGVudGl0
eSBQcm92aWRlcnMgcHV0IHRoZSBzdXBwbGllZCBBdWRpZW5jZSBJZGVudGlmaWVyIGludG8gQXV0
aGVudGljYXRpb24gVG9rZW5zLiBQZXJoYXBzIGEgbGl0dGxlIGZ1cnRoZXIgYmFjay1hbmQtZm9y
dGggd2l0aCBCcmlhbiB3aWxsIHJlc29sdmUgdGhpcy4NCg0KSSBjYW4gZ28gaW50byBkZWVwZXIg
ZGV0YWlsIGlmIG5lZWRlZC4gSWYgdGhpcyBpcyBvZmYtdG9waWMgZm9yIHRoZSBPQXV0aCB3b3Jr
aW5nIGdyb3VwLCBsZXQgbWUga25vdy4NCg0KVGhhbmtzLA0KQW5kcmV3IEZyZWdseQ0KVmVyaXNp
Z24gSW5jLg0KDQoNCkZyb206IEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRv
OnZlN2p0YkB2ZTdqdGIuY29tPj4NCkRhdGU6IFR1ZXNkYXksIEFwcmlsIDE5LCAyMDE2IGF0IDI6
MDYgUE0NClRvOiBBbmRyZXcgRnJlZ2x5IDxhZnJlZ2x5QHZlcmlzaWduLmNvbTxtYWlsdG86YWZy
ZWdseUB2ZXJpc2lnbi5jb20+Pg0KQ2M6ICJvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0
Zi5vcmc+IiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6
IFJlOiBbT0FVVEgtV0ddIEJ1aWxkaW5nIG9uIHRoZSBwcm90b2NvbCBpbiB0aGUgZHJhZnQg4oCc
T0F1dGggMi4wIFRva2VuIEV4Y2hhbmdlOiBBbiBTVFMgZm9yIHRoZSBSRVNUIG9mIFVz4oCdIHRv
IGluY2x1ZGUgQXV0aGVudGljYXRpb24gVG9rZW5zDQoNCkxvb2tpbmcgYXQgT3BlbklEIENvbm5l
Y3QgYW5kIGl04oCZcyB0cnVzdCBtb2RlbCBmb3IgcHJvZHVjaW5nIGlkX3Rva2VucyB0aGF0IGFz
c2VydCBpZGVudGl0eSBtYXkgaGVscCB5b3UuDQpodHRwOi8vb3BlbmlkLm5ldC93Zy9jb25uZWN0
Lw0KDQpVbmZvcnR1bmF0ZWx5IEkgY2Fu4oCZdCBxdWl0ZSBtYWtlIG91dCB3aGF0IHlvdSBhcmUg
dHJ5aW5nIHRvIGRvLg0KDQpJdCBzb3J0IG9mIHNvdW5kcyBsaWtlIHlvdSB3YW50IGFuIGlkX3Rv
a2VuIGZyb20gYSBpZFAgYW5kIHRoZW4gaGF2ZSB0aGUgY2xpZW50IGV4Y2hhbmdlIHRoYXQgYXNz
ZXJ0aW9uIGZvciBhbm90aGVyIHRva2VuPw0KDQpKb2huIEIuDQpPbiBBcHIgMTksIDIwMTYsIGF0
IDE6MTggUE0sIEZyZWdseSwgQW5kcmV3IDxhZnJlZ2x5QHZlcmlzaWduLmNvbTxtYWlsdG86YWZy
ZWdseUB2ZXJpc2lnbi5jb20+PiB3cm90ZToNCg0KSSBoYXZlIGEgdXNlIGNhc2Ugd2hlcmUgYSBj
bGllbnQgYXBwbGljYXRpb24gbmVlZHMgdG8gYXV0aGVudGljYXRlIHdpdGggYSBkeW5hbWljYWxs
eSBkZXRlcm1pbmVkIElkZW50aXR5IFByb3ZpZGVyIHRoYXQgaXMgc2VwYXJhdGUgZnJvbSB0aGUg
QXV0aG9yaXphdGlvbiBTZXJ2aWNlIHRoYXQgd2lsbCBiZSB1c2VkIGlzc3VlIGFuIGFjY2VzcyB0
b2tlbiB0byB0aGUgY2xpZW50LiBUaGUgdXNlIGNhc2UgYWxzbyByZXF1aXJlcyB0aGF0IGFzIHBh
cnQgb2YgYXV0aG9yaXphdGlvbiwgdGhlIGNsaWVudCBwcm92aWRlcyB0byB0aGUgQXV0aG9yaXph
dGlvbiBTZXJ2aWNlIGFuIGF1dGhlbnRpY2F0aW9uIHRva2VuIHNpZ25lZCBieSBhbiBJZGVudGl0
eSBQcm92aWRlciB0aGF0IHRoZSBBdXRob3JpemF0aW9uIFNlcnZpY2UgaGFzIGEgdHJ1c3QgcmVs
YXRpb25zaGlwIHdpdGguIFRoZSB0cnVzdCByZWxhdGlvbnNoaXAgaXMgdmVyaWZpYWJsZSBiYXNl
ZCBvbiB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2aWNlIGhhdmluZyByZWNvcmRlZCB0aGUgcHVibGlj
IGtleXMgb3IgY2VydGlmaWNhdGVzIG9mIHRydXN0ZWQgSWRlbnRpdHkgUHJvdmlkZXJzIGluIGEg
dHJ1c3Qgc3RvcmUsIHRoaXMgYWxsb3dpbmcgdGhlIEF1dGhvcml6YXRpb24gU2VydmljZSB0byB2
ZXJpZnkgYW4gSWRlbnRpdHkgUHJvdmlkZXLigJlzIHNpZ25hdHVyZSBvbiBhbiBhdXRoZW50aWNh
dGlvbiB0b2tlbi4NCg0KSW4gbG9va2luZyBhdCB0aGUgdmFyaW91cyBPQXV0aCBSRkNzLCBwYXJ0
aWN1bGFybHkgUkZDcyA3NTIxLCA3NTIyLCBhbmQgNzUyMywgSSBzZWUgdGhhdCB0aGV5IGdldCBt
ZSBjbG9zZSBpbiB0ZXJtcyBvZiBzdXBwb3J0aW5nIHRoZSB1c2UgY2FzZS4gV2hhdCBpcyBtaXNz
aW5nIGlzIGEgbWVhbnMgZm9yIHNvbHZpbmcgdGhlIGZvbGxvd2luZyBwcm9ibGVtLiBUaGVzZSBS
RkNzIHJlcXVpcmUgdGhhdCB0aGUgSWRlbnRpdHkgUHJvdmlkZXIgcHV0IGFuIEF1ZGllbmNlIGNs
YWltIGluIHRoZSBhdXRoZW50aWNhdGlvbiB0b2tlbi4gVGhlIHByb2JsZW0gd2l0aCB0aGlzIGlz
IHRoYXQgSSBkbyBub3Qgc2VlIGluIHRoZSBSRkNzIGhvdyB0aGUgSWRlbnRpdHkgUHJvdmlkZXIg
Y2FuIGJlIHRvbGQgd2hvIHRoZSBBdWRpZW5jZSBpcyB0byBwdXQgaW50byB0aGUgYXV0aGVudGlj
YXRpb24gdG9rZW4uIFRoaXMgbGVhZHMgbWUgdG8gdGhlIHRpdGxlIG9mIHRoaXMgbWVzc2FnZS4g
VGhlIGRyYWZ0IOKAnE9BdXRoIDIuMCBUb2tlbiBFeGNoYW5nZTogQW4gU1RTIGZvciB0aGUgUkVT
VCBvZiBVc+KAnSBkZWZpbmVzIGEgbWVjaGFuaXNtIGZvciBpZGVudGlmeWluZyB0aGUgQXVkaWVu
Y2UgZm9yIGFuIFNUUyB0byBwdXQgaW50byBhIHRva2VuIGl0IGdlbmVyYXRlcy4gVGhhdCB3b3Vs
ZCBzb2x2ZSBteSBwcm9ibGVtIGV4Y2VwdCB0aGF0IHRoZSBkcmFmdCBsaW1pdHMgdGhlIHR5cGUg
b2YgU1RTIHRvIGJlaW5nIEF1dGhvcml6YXRpb24gU2VydmVycy4gV2hhdCBpcyBuZWVkZWQgaXMg
dGhpcyBzYW1lIGNhcGFiaWxpdHkgZm9yIGludGVyYWN0aW5nIHdpdGggYW4gSWRlbnRpdHkgUHJv
dmlkZXIuIFRoaXMgd291bGQgZW5hYmxlIFJGQ3MgNzUyMSwgNzUyMiBhbmQgNzUyMyB0byBiZSB1
c2VmdWwgaW4gc2l0dWF0aW9uIHdoZXJlIHRoZSBJZGVudGl0eSBQcm92aWRlciBuZWVkcyB0byBi
ZSB0b2xkIHRoZSBpZGVudGl0eSBvZiB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2aWNlLg0KDQpJIGFt
IG5ldyB0byBpbnRlcmFjdGluZyB3aXRoIHRoZSBJRVRGLiBJIGFsc28gYW0gbm90IGFuIGV4cGVy
dCBvbiB0aGUgUkZDcyBvciBwcmlvciBoaXN0b3J5IG9mIHRoZSBPQXV0aCBncm91cCByZWxhdGl2
ZSB0byB0aGlzIHRvcGljLCBzbyBwbGVhc2UgcG9pbnQgbWUgdG8gYW55IGV4aXN0aW5nIHNvbHV0
aW9uIGlmIHRoaXMgaXMgYSBzb2x2ZWQgcHJvYmxlbS4gT3RoZXJ3aXNlLCBJIHdvdWxkIGxpa2Ug
dG8gZ2V0IGZlZWRiYWNrIG9uIG15IHN1Z2dlc3Rpb24uDQoNClRoYW5rcyBZb3UsDQoNCkFuZHJl
dyBGcmVnbHkNClZlcmlzaWduIEluYy4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0
bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
b2F1dGgNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
Ck9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3Jn
Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K

--_000_5958E90FEF8C464196C1A9077B450D53verisigncom_
Content-Type: text/html; charset="utf-8"
Content-ID: <6840632D5372D8468CD96C0365493B63@verisign.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+VGhh
bmtzIGZvciB5b3VyIHJlcGx5IE5hdC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkRv
ZXMgeW91ciBhcHByb2FjaCBtYXRjaCB3aXRoIGFuIElFVEYgT0F1dGggUkZDIG9yIERyYWZ0IGRl
c2NyaWJpbmcgaG93IGFuIEF1dGhvcml6YXRpb24gU2VydmljZSBjYW4gYWNjZXB0IGFuZCB2ZXJp
ZnkgYW4gYXV0aGVudGljYXRpb24gdG9rZW4gcHJvdmlkZWQgYnkgYSBjbGllbnQgZHVyaW5nIHRo
ZSBhdXRob3JpemF0aW9uIHByb2Nlc3M/IElmIHNvLCBwbGVhc2UgcG9pbnQgbWUgdG8gdGhhdC4g
VGhlIG9ubHkgUkZDcyBJIGhhdmUgc2Vlbg0KIHRoYXQgYWRkcmVzcyB0aGlzIGFyZSBSRkNzIDcy
NTEsIDcyNTIgYW5kIDcyNTMsIGFuZCB0aGV5IGFsbCBoYXZlIGEgcmVxdWlyZW1lbnQgdGhhdCBh
biDigJxhdWRpZW5jZeKAnSBjbGFpbSBjb3JyZXNwb25kaW5nIHRvIHRoZSBBdXRob3JpemF0aW9u
IFNlcnZpY2UgaXMgaW4gdGhlIGF1dGhlbnRpY2F0aW9uIHRva2VuLiBHZXR0aW5nIHRoYXQgY2xh
aW0gaW50byBhbiBhdXRoZW50aWNhdGlvbiB0b2tlbiBwcm92aWRlZCBieSBhbiBPcmdhbml6YXRp
b27igJlzDQogSWRlbnRpdHkgcHJvdmlkZXIgc2VlbXMgdG8gYmUgbXkgZnVuZGFtZW50YWwgcHJv
YmxlbS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgQW5keTwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRM
T09LX1NJR05BVFVSRSI+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N
CjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWls
eTpDYWxpYnJpOyBmb250LXNpemU6MTJwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsg
Qk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFE
RElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsg
Qk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7
IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206
IDwvc3Bhbj5OYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5j
b20iPnNha2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp
Z2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5UdWVzZGF5LCBBcHJpbCAxOSwgMjAxNiBhdCA0OjEzIFBN
PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+QW5kcmV3IEZy
ZWdseSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFmcmVnbHlAdmVyaXNpZ24uY29tIj5hZnJlZ2x5QHZl
cmlzaWduLmNvbTwvYT4mZ3Q7LCBKb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdq
dGJAdmU3anRiLmNvbSI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0i
bWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhy
ZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxz
cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtPQVVUSC1X
R10gQnVpbGRpbmcgb24gdGhlIHByb3RvY29sIGluIHRoZSBkcmFmdCAmcXVvdDtPQXV0aCAyLjAg
VG9rZW4gRXhjaGFuZ2U6IEFuIFNUUyBmb3IgdGhlIFJFU1Qgb2YgVXMmcXVvdDsgdG8gaW5jbHVk
ZSBBdXRoZW50aWNhdGlvbiBUb2tlbnM8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8
YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9
IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAg
MCAwIDU7Ij4NCjxkaXY+DQo8ZGl2PkdldCBPcGVuSUQgQ29ubmVjdCBpZF90b2tlbiBieSB0aGUg
YXV0aGVudGljYXRpb24gcmVxdWVzdCB3aXRoIHByb21wdD1ub25lIGFuZCB2ZXJpZnlpbmcgdGhl
IHN1YiB0byBiZSB0aGUgc2FtZSB3aXRoIHdoYXQgeW91IGV4cGVjdGVkIHNlZW0gdG8gc3VmZmlj
ZSB5b3VyIG5lZWRzLiBBbSBJIG1pc3Npbmcgc29tZXRoaW5nPw0KPGJyPg0KPGRpdiBjbGFzcz0i
Z21haWxfcXVvdGUiPg0KPGRpdiBkaXI9Imx0ciI+T24gV2VkLCBBcHIgMjAsIDIwMTYgYXQgMDU6
MDUgRnJlZ2x5LCBBbmRyZXcgJmx0OzxhIGhyZWY9Im1haWx0bzphZnJlZ2x5QHZlcmlzaWduLmNv
bSI+YWZyZWdseUB2ZXJpc2lnbi5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxibG9j
a3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRl
ci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBzdHlsZT0id29y
ZC13cmFwOmJyZWFrLXdvcmQ7Y29sb3I6cmdiKDAsMCwwKTtmb250LXNpemU6MTRweDtmb250LWZh
bWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPg0KPGRpdj4NCjxkaXY+VGhhbmtzIGZvciB5b3VyIHJl
c3BvbnNlIEpvaG4uIEkgYWxzbyBnb3QgYSBnb29kIHJlc3BvbnNlIGZyb20gQnJpYW4gQ2FtcGJl
bGwgYW5kIGFwcHJlY2lhdGUgdGhhdC4gSSB3aWxsIHJlc3BvbmQgc2VwYXJhdGVseSB0byBCcmlh
buKAmXMgcmVzcG9uc2UgYXMgSSB0aGluayBpdCB3b3VsZCBrZWVwIHRoaW5ncyBjbGVhcmVyIHRv
IGRvIHRoYXQuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgcHJvYmxlbSB3ZSBo
YXZlIGZvciB1c2luZyBPcGVuSUQgQ29ubmVjdCBpcyB0aGF0IGl0IGNvbWJpbmVzIHRoZSByb2xl
IG9mIEF1dGhlbnRpY2F0aW9uIFNlcnZpY2Ugd2l0aCB0aGUgcm9sZSBvZiBBdXRob3JpemF0aW9u
IFNlcnZpY2UuIFBlcmhhcHMgdGhlIGZvbGxvd2luZyBkZXNjcmlwdGlvbiBvZiB3aGF0IHdlIHdh
bnQgdG8gZG8gd2lsbCBjbGFyaWZ5IHdoeSB0aGlzIHdvbuKAmXQgd29yayBmb3IgdXM6PC9kaXY+
DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgYmFzaWMgcHJvYmxlbSBzdGF0ZW1lbnQgaXMg
dGhhdCB3ZSBuZWVkIHRvIGhhdmUgYSBjbGllbnQgYXBwbGljYXRpb24gYXV0aG9yaXplZCBieSBh
IFNlcnZpY2UgUHJvdmlkZXIgYmFzZWQgb24gcHJvb2YgdGhhdCBhIHVzZXIgaXMgY3VycmVudGx5
IGEgbWVtYmVyIG9mIHNvbWUgb3JnYW5pemF0aW9uLiBUaGlzIGFzc3VtZXMgdGhlIG9yZ2FuaXph
dGlvbiBoYXMgcHJldmlvdXNseSBlc3RhYmxpc2hlZCBzb21lIGxldmVsIG9mIGF1dGhvcml6ZWQN
CiBhY2Nlc3Mgd2l0aCB0aGUgU2VydmljZSBQcm92aWRlci4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJy
Pg0KPC9kaXY+DQo8ZGl2PkhlcmUgaXMgYW4gZXhhbXBsZTogU3VwcG9zZSBJIGFtIGEgbWVtYmVy
IG9mIFNvbWVPcmcgSW5jLiBTdXBwb3NlIFNvbWVPcmcgSW5jLiBpcyBkb2luZyByZXNlYXJjaCB0
aGF0IHJlcXVpcmVzIGl0IHRvIGdhdGhlciBkYXRhIG92ZXIgdGhlIEludGVybmV0IGZyb20gYSBu
dW1iZXIgb2YgZGF0YSBwcm92aWRlcnMuIFRoZSBkYXRhIHByb3ZpZGVycyByZXF1aXJlIGF1dGhl
bnRpY2F0aW9uIGFuZCBwcm9vZiBvZiBvcmdhbml6YXRpb25hbCBtZW1iZXJzaGlwDQogaW4gb3Jk
ZXIgdG8gYXV0aG9yaXplIHZhcmlvdXMgbGV2ZWxzIG9mIGFjY2VzcyB0byB0aGVpciBkYXRhLiBU
aGUgZGF0YSBwcm92aWRlcnMgZG8gbm90IGNvbnNpZGVyIGhhdmluZyBhbiBhY2NvdW50IHdpdGgg
dGhlbSBvciBhIFB1YmxpYyBJZGVudGl0eSBQcm92aWRlciB0byBiZSBzdWl0YWJsZSBmb3IgcHJv
dmluZyB0aGF0IEkgYW0gc3RpbGwgYSBtZW1iZXIgb2YgU29tZU9yZyBhdCB0aW1lIG9mIGF1dGhl
bnRpY2F0aW9uLiBUaGV5IHdvdWxkDQogaGF2ZSBubyB3YXkgb2Yga25vd2luZyB3aGV0aGVyIG9y
IG5vdCBteSByZWxhdGlvbnNoaXAgd2l0aCBTb21lT3JnIHN0aWxsIGV4aXN0cyBhdCB0aGF0IHRp
bWUuIFRoZSBkYXRhIHByb3ZpZGVycyB3b3VsZCB0aGVyZWZvcmUgbGlrZSB0aGUgQ2xpZW50IHNv
ZnR3YXJlIHRvIGF1dGhlbnRpY2F0ZSBtZSBhZ2FpbnN0IFNvbWVPcmdzIElkZW50aXR5IFByb3Zp
ZGVyLiBUaGlzIHdvdWxkIGJlIGdvb2QgcHJvb2YgdGhhdCBJIGFtIHN0aWxsIGEgbWVtYmVyDQog
b2YgU29tZU9yZyBhdCB0aGUgdGltZSBJIGF1dGhlbnRpY2F0ZS4gVGhpcyBhdXRoZW50aWNhdGlv
biB3b3VsZCBlbmFibGUgdGhlIGRhdGEgcHJvdmlkZXJzIEF1dGhvcml6YXRpb24gU2VydmVyIHRv
IGdyYW50IG1lIGFjY2VzcyBhcHByb3ByaWF0ZSB0byBhIG1lbWJlciBvZiBTb21lT3JnLiZuYnNw
OyBOb3RlIHRoYXQgYXMgYSBwcmVyZXF1aXNpdGUgdG8gYWxsIG9mIHRoaXMsIFNvbWVPcmcgd2ls
bCBoYXZlIHVzZWQgYW4gb3V0LW9mLWJhbmQgcHJvY2Vzcw0KIHRvIHNldCB1cCBhIHRydXN0IHJl
bGF0aW9uc2hpcCBmb3IgU29tZU9yZydzIElkZW50aXR5IFByb3ZpZGVyIHdpdGggdGhlIGRhdGEg
cHJvdmlkZXLigJlzIEF1dGhvcml6YXRpb24gU2VydmljZSwgYW5kIHdpbGwgaGF2ZSBuZWdvdGlh
dGVkIGF1dGhvcml6YXRpb24gY2xhaW1zIHRvIGJlIGdyYW50ZWQgdG8gU29tZU9yZ3MgbWVtYmVy
cy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldoYXQgSSBhbSBoYXZpbmcgZGlmZmlj
dWx0eSB3aXRoIGlzIGluIGtuaXR0aW5nIHRvZ2V0aGVyIGFuIGFwcHJvYWNoIGJhc2VkIG9uIHRo
ZSBoZSBPcGVuSUQgQ29ubmVjdCBzcGVjaWZpY2F0aW9ucywgU0FNTCBzcGVjaWZpY2F0aW9ucywg
YW5kIE9BdXRoIFJGQ3MgYW5kIGRyYWZ0cyBpbiBhIHdheSB0aGF0IHN1cHBvcnRzIHRoZSBhYm92
ZSB1c2UgY2FzZSBlbmQtdG8tZW5kLiBUaGUgT0F1dGggUkZDcyBhbmQgZHJhZnRzIGFsbW9zdCBn
ZXQNCiBtZSB0aGVyZS4gV2hhdCBzZWVtcyB0byBiZSBtaXNzaW5nIGlzIGEgd2F5IG9mIHRlbGxp
bmcgYW4gSWRlbnRpdHkgUHJvdmlkZXIgdGhlIFVSTCBmb3IgdGhlIEF1dGhvcml6YXRpb24gU2Vy
dmljZSAodGhlIHJlcXVpcmVkIEF1ZGllbmNlIGNsYWltIGluIGFuIGF1dGhlbnRpY2F0aW9uIGFz
c2VydGlvbiBhcyBkZWZpbmVkIGluIFJGQ3MgNzI1MSwgNzI1MiBhbmQgNzI1MyksIGFuZCB0aGVu
IGEgcmVxdWlyZW1lbnQgdGhhdCB0aGUgSWRlbnRpdHkNCiBQcm92aWRlcnMgcHV0IHRoZSBzdXBw
bGllZCBBdWRpZW5jZSBJZGVudGlmaWVyIGludG8gQXV0aGVudGljYXRpb24gVG9rZW5zLiBQZXJo
YXBzIGEgbGl0dGxlIGZ1cnRoZXIgYmFjay1hbmQtZm9ydGggd2l0aCBCcmlhbiB3aWxsIHJlc29s
dmUgdGhpcy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgY2FuIGdvIGludG8gZGVl
cGVyIGRldGFpbCBpZiBuZWVkZWQuIElmIHRoaXMgaXMgb2ZmLXRvcGljIGZvciB0aGUgT0F1dGgg
d29ya2luZyBncm91cCwgbGV0IG1lIGtub3cuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp
dj5UaGFua3MsPC9kaXY+DQo8ZGl2PkFuZHJldyBGcmVnbHk8L2Rpdj4NCjxkaXY+VmVyaXNpZ24g
SW5jLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2PjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3Bhbj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFt
aWx5OkNhbGlicmk7Zm9udC1zaXplOjEycHQ7dGV4dC1hbGlnbjpsZWZ0O2NvbG9yOmJsYWNrO0JP
UkRFUi1CT1RUT006bWVkaXVtIG5vbmU7Qk9SREVSLUxFRlQ6bWVkaXVtIG5vbmU7UEFERElORy1C
T1RUT006MGluO1BBRERJTkctTEVGVDowaW47UEFERElORy1SSUdIVDowaW47Qk9SREVSLVRPUDoj
YjVjNGRmIDFwdCBzb2xpZDtCT1JERVItUklHSFQ6bWVkaXVtIG5vbmU7UEFERElORy1UT1A6M3B0
Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+Sm9obiBCcmFk
bGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0iX2JsYW5r
Ij52ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0
OmJvbGQiPkRhdGU6IDwvc3Bhbj5UdWVzZGF5LCBBcHJpbCAxOSwgMjAxNiBhdCAyOjA2IFBNPGJy
Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+QW5kcmV3IEZyZWds
eSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFmcmVnbHlAdmVyaXNpZ24uY29tIiB0YXJnZXQ9Il9ibGFu
ayI+YWZyZWdseUB2ZXJpc2lnbi5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdl
aWdodDpib2xkIj5DYzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9y
ZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0i
bWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+
Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+
UmU6IFtPQVVUSC1XR10gQnVpbGRpbmcgb24gdGhlIHByb3RvY29sIGluIHRoZSBkcmFmdCDigJxP
QXV0aCAyLjAgVG9rZW4gRXhjaGFuZ2U6IEFuIFNUUyBmb3IgdGhlIFJFU1Qgb2YgVXPigJ0gdG8g
aW5jbHVkZSBBdXRoZW50aWNhdGlvbiBUb2tlbnM8YnI+DQo8L2Rpdj4NCjwvc3Bhbj48L2Rpdj4N
CjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO2NvbG9yOnJnYigwLDAsMCk7Zm9udC1z
aXplOjE0cHg7Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj4NCjxzcGFuPg0KPGRpdj48
YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJCT1JERVItTEVGVDojYjVjNGRmIDUgc29s
aWQ7UEFERElORzowIDAgMCA1O01BUkdJTjowIDAgMCA1Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJ3
b3JkLXdyYXA6YnJlYWstd29yZCI+TG9va2luZyBhdCBPcGVuSUQgQ29ubmVjdCBhbmQgaXTigJlz
IHRydXN0IG1vZGVsIGZvciBwcm9kdWNpbmcgaWRfdG9rZW5zIHRoYXQgYXNzZXJ0IGlkZW50aXR5
IG1heSBoZWxwIHlvdS4NCjxkaXY+PGEgaHJlZj0iaHR0cDovL29wZW5pZC5uZXQvd2cvY29ubmVj
dC8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vb3BlbmlkLm5ldC93Zy9jb25uZWN0LzwvYT48YnI+
DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5VbmZvcnR1bmF0ZWx5IEkgY2Fu4oCZdCBxdWl0ZSBt
YWtlIG91dCB3aGF0IHlvdSBhcmUgdHJ5aW5nIHRvIGRvLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+
DQo8L2Rpdj4NCjxkaXY+SXQgc29ydCBvZiBzb3VuZHMgbGlrZSB5b3Ugd2FudCBhbiBpZF90b2tl
biBmcm9tIGEgaWRQIGFuZCB0aGVuIGhhdmUgdGhlIGNsaWVudCBleGNoYW5nZSB0aGF0IGFzc2Vy
dGlvbiBmb3IgYW5vdGhlciB0b2tlbj88L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pkpv
aG4gQi48YnI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2Pk9uIEFwciAx
OSwgMjAxNiwgYXQgMToxOCBQTSwgRnJlZ2x5LCBBbmRyZXcgJmx0OzxhIGhyZWY9Im1haWx0bzph
ZnJlZ2x5QHZlcmlzaWduLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFmcmVnbHlAdmVyaXNpZ24uY29t
PC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1p
bHk6Q2FsaWJyaSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxNHB4O2ZvbnQtc3R5bGU6bm9ybWFsO2Zv
bnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0
ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29y
ZC1zcGFjaW5nOjBweCI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFwdDtmb250
LXNpemU6MTJwdDtmb250LWZhbWlseTpDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy
cHQiPkkgaGF2ZSBhIHVzZSBjYXNlIHdoZXJlIGEgY2xpZW50IGFwcGxpY2F0aW9uIG5lZWRzIHRv
IGF1dGhlbnRpY2F0ZSB3aXRoIGEgZHluYW1pY2FsbHkgZGV0ZXJtaW5lZCBJZGVudGl0eSBQcm92
aWRlciB0aGF0IGlzIHNlcGFyYXRlIGZyb20gdGhlIEF1dGhvcml6YXRpb24gU2VydmljZQ0KIHRo
YXQgd2lsbCBiZSB1c2VkIGlzc3VlIGFuIGFjY2VzcyB0b2tlbiB0byB0aGUgY2xpZW50LiBUaGUg
dXNlIGNhc2UgYWxzbyByZXF1aXJlcyB0aGF0IGFzIHBhcnQgb2YgYXV0aG9yaXphdGlvbiwgdGhl
IGNsaWVudCBwcm92aWRlcyB0byB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2aWNlIGFuIGF1dGhlbnRp
Y2F0aW9uIHRva2VuIHNpZ25lZCBieSBhbiBJZGVudGl0eSBQcm92aWRlciB0aGF0IHRoZSBBdXRo
b3JpemF0aW9uIFNlcnZpY2UgaGFzIGEgdHJ1c3QNCiByZWxhdGlvbnNoaXAgd2l0aC4gVGhlIHRy
dXN0IHJlbGF0aW9uc2hpcCBpcyB2ZXJpZmlhYmxlIGJhc2VkIG9uIHRoZSBBdXRob3JpemF0aW9u
IFNlcnZpY2UgaGF2aW5nIHJlY29yZGVkIHRoZSBwdWJsaWMga2V5cyBvciBjZXJ0aWZpY2F0ZXMg
b2YgdHJ1c3RlZCBJZGVudGl0eSBQcm92aWRlcnMgaW4gYSB0cnVzdCBzdG9yZSwgdGhpcyBhbGxv
d2luZyB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2aWNlIHRvIHZlcmlmeSBhbiBJZGVudGl0eSBQcm92
aWRlcuKAmXMNCiBzaWduYXR1cmUgb24gYW4gYXV0aGVudGljYXRpb24gdG9rZW4uPC9zcGFuPjxh
IG5hbWU9Im1fLTY1NTExMzYwMTA3MjAxNzg3MDBfT0xFX0xJTks1Ij48L2E+PC9kaXY+DQo8ZGl2
IHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250LWZhbWls
eTpDYWxpYnJpIj48dT48L3U+PHU+PC91PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBpbiAw
aW4gMC4wMDAxcHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PHU+PC91PiZu
YnNwOzx1PjwvdT48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0O2Zv
bnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkluIGxvb2tpbmcgYXQgdGhlIHZhcmlv
dXMgT0F1dGggUkZDcywgcGFydGljdWxhcmx5IFJGQ3MgNzUyMSwgNzUyMiwgYW5kIDc1MjMsIEkg
c2VlIHRoYXQgdGhleSBnZXQgbWUgY2xvc2UgaW4gdGVybXMgb2Ygc3VwcG9ydGluZyB0aGUgdXNl
IGNhc2UuIFdoYXQgaXMgbWlzc2luZyBpcyBhIG1lYW5zIGZvciBzb2x2aW5nIHRoZQ0KIGZvbGxv
d2luZyBwcm9ibGVtLiBUaGVzZSBSRkNzIHJlcXVpcmUgdGhhdCB0aGUgSWRlbnRpdHkgUHJvdmlk
ZXIgcHV0IGFuIEF1ZGllbmNlIGNsYWltIGluIHRoZSBhdXRoZW50aWNhdGlvbiB0b2tlbi4gVGhl
IHByb2JsZW0gd2l0aCB0aGlzIGlzIHRoYXQgSSBkbyBub3Qgc2VlIGluIHRoZSBSRkNzIGhvdyB0
aGUgSWRlbnRpdHkgUHJvdmlkZXIgY2FuIGJlIHRvbGQgd2hvIHRoZSBBdWRpZW5jZSBpcyB0byBw
dXQgaW50byB0aGUgYXV0aGVudGljYXRpb24NCiB0b2tlbi4gVGhpcyBsZWFkcyBtZSB0byB0aGUg
dGl0bGUgb2YgdGhpcyBtZXNzYWdlLiBUaGUgZHJhZnQg4oCcT0F1dGggMi4wIFRva2VuIEV4Y2hh
bmdlOiBBbiBTVFMgZm9yIHRoZSBSRVNUIG9mIFVz4oCdIGRlZmluZXMgYSBtZWNoYW5pc20gZm9y
IGlkZW50aWZ5aW5nIHRoZSBBdWRpZW5jZSBmb3IgYW4gU1RTIHRvIHB1dCBpbnRvIGEgdG9rZW4g
aXQgZ2VuZXJhdGVzLiBUaGF0IHdvdWxkIHNvbHZlIG15IHByb2JsZW0gZXhjZXB0IHRoYXQgdGhl
IGRyYWZ0DQogbGltaXRzIHRoZSB0eXBlIG9mIFNUUyB0byBiZWluZyBBdXRob3JpemF0aW9uIFNl
cnZlcnMuIFdoYXQgaXMgbmVlZGVkIGlzIHRoaXMgc2FtZSBjYXBhYmlsaXR5IGZvciBpbnRlcmFj
dGluZyB3aXRoIGFuIElkZW50aXR5IFByb3ZpZGVyLiBUaGlzIHdvdWxkIGVuYWJsZSBSRkNzIDc1
MjEsIDc1MjIgYW5kIDc1MjMgdG8gYmUgdXNlZnVsIGluIHNpdHVhdGlvbiB3aGVyZSB0aGUgSWRl
bnRpdHkgUHJvdmlkZXIgbmVlZHMgdG8gYmUgdG9sZCB0aGUgaWRlbnRpdHkNCiBvZiB0aGUgQXV0
aG9yaXphdGlvbiBTZXJ2aWNlLjx1PjwvdT48dT48L3U+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn
aW46MGluIDBpbiAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTpDYWxpYnJpIj48
dT48L3U+Jm5ic3A7PHU+PC91PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMC4w
MDAxcHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+SSBhbSBuZXcgdG8gaW50
ZXJhY3Rpbmcgd2l0aCB0aGUgSUVURi4gSSBhbHNvIGFtIG5vdCBhbiBleHBlcnQgb24gdGhlIFJG
Q3Mgb3IgcHJpb3IgaGlzdG9yeSBvZiB0aGUgT0F1dGggZ3JvdXAgcmVsYXRpdmUgdG8gdGhpcyB0
b3BpYywgc28gcGxlYXNlIHBvaW50IG1lIHRvIGFueSBleGlzdGluZyBzb2x1dGlvbiBpZiB0aGlz
DQogaXMgYSBzb2x2ZWQgcHJvYmxlbS4gT3RoZXJ3aXNlLCBJIHdvdWxkIGxpa2UgdG8gZ2V0IGZl
ZWRiYWNrIG9uIG15IHN1Z2dlc3Rpb24uPHU+PC91Pjx1PjwvdT48L2Rpdj4NCjxkaXYgc3R5bGU9
Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OkNhbGli
cmkiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MGluIDBp
biAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTpDYWxpYnJpIj5UaGFua3MgWW91
LDwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7Zm9udC1zaXplOjEy
cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46
MGluIDBpbiAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTpDYWxpYnJpIj5BbmRy
ZXcgRnJlZ2x5PHU+PC91Pjx1PjwvdT48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowaW4gMGlu
IDAuMDAwMXB0O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlZlcmlzaWduIElu
Yy48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNl
cmlmO2ZvbnQtc2l6ZToxNHB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDts
ZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4
dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweCI+DQo8
ZGl2PjwvZGl2Pg0KPC9kaXY+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNh
bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXdlaWdo
dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4
dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7
IHdvcmQtc3BhY2luZzogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRh
bnQ7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bh
bj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjtmb250LXNpemU6MTRw
eDtmb250LXN0eWxlOm5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9y
bWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7
d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6
IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4
dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3
aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3Bs
YXk6IGlubGluZSAhaW1wb3J0YW50OyI+T0F1dGgNCiBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyIHN0
eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7Zm9udC1zaXplOjE0cHg7Zm9udC1z
dHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0
LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNw
YWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRm
Lm9yZyIgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjtmb250LXNpemU6MTRw
eDtmb250LXN0eWxlOm5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9y
bWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7
d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2luZzowcHgiIHRhcmdldD0iX2JsYW5rIj5PQXV0
aEBpZXRmLm9yZzwvYT48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjtm
b250LXNpemU6MTRweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVy
LXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJh
bnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2luZzowcHgiPg0KPGEgaHJl
Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgc3R5bGU9ImZv
bnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjtmb250LXNpemU6MTRweDtmb250LXN0eWxlOm5v
cm1hbDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246
c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9y
bWFsO3dvcmQtc3BhY2luZzowcHgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+
DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv
c3Bhbj48L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGll
dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgcmVsPSJub3JlZmVy
cmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9vYXV0aDwvYT48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_5958E90FEF8C464196C1A9077B450D53verisigncom_--


From nobody Tue Apr 19 14:06:42 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1BAF12E6E2 for ; Tue, 19 Apr 2016 14:06:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y_UWtaAOfDWz for ; Tue, 19 Apr 2016 14:06:38 -0700 (PDT)
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 CFEB812E6D9 for ; Tue, 19 Apr 2016 14:06:37 -0700 (PDT)
Received: by mail-oi0-x261.google.com with SMTP id r186so1604537oie.2 for ; Tue, 19 Apr 2016 14:06:37 -0700 (PDT)
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:user-agent :mime-version; bh=sFi+VpLzN90icR/aPRhmh4WBJjywS1tb6JPkBYYkhJE=; b=xablP3D8UP0Za7A2dIyhdDeft5idbLdHtZIjhTe9AXRSiEoX8jrObAJNmB4MwkSRVw D9onTpuW8+vdk6d3HsPqOYsoAjcat13mDNSvzPZmPKkbvcFeLEnkx/ZqRyqcOAVpizvb BbOKNkLYR3T+zd9KXT2L6XNniNYRVoGkex2Drzyi3rYyCsY9vTJlvHAiVupYFo62nIC2 h/UgOxRn4oy2gDH/I7+rrArLZ4JTTe9iAq+ahoJKrd4dmUL0ZJp1/ldUesdGHUB2Dp72 qvsr/WX8ffDQKmqsrn3Gm6LKp6QZylUe37nAXuYkyA6ZQbHiA1YMh4o9mO9kNEaytcMy O0Kw==
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 :user-agent:mime-version; bh=sFi+VpLzN90icR/aPRhmh4WBJjywS1tb6JPkBYYkhJE=; b=SPuxgmXYKNWJ5pxASgHWfOmvd7r32BFZFxmR2njpvH7Rngwyct4AqWnQxZSYNIBpZm HWVtH+fiSYc7wuJY7Bg0F2VvOxKt+D6OtJZsxdFuf2hTOOK0mXCaULSRuWUj5Dmx5atn TD1kht03hztZglE5RivsHGBeHyPkxRTIH0YELn7H/uNJdQCsO8pf7ifDN47wgCSPm7hm jWIl1mivZSfaPVDqw2IozG7P2bVJF3TqXJB+E0Fb4SY3bUO3a2lPRjO6v72qxeaoLGI7 pDYBoW87SAceCkz8WBU9D6bGAhxlYHO7cTkVphuCrxr/8/WuHItQcu17KJXWaLzZwWN7 lNQA==
X-Gm-Message-State: AOPr4FXvWm9jImajdJp3Ehq+rJECP3jTdxu5P7/Wx2dOaSXAtdiVuFsJwlSXYdwzdddFSL4q99LM0osmQ1+hCQxtarehBXe0
X-Received: by 10.55.6.23 with SMTP id 23mr2080609qkg.66.1461099996963; Tue, 19 Apr 2016 14:06:36 -0700 (PDT)
Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id g133sm8616881qkb.1.2016.04.19.14.06.36 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 19 Apr 2016 14:06:36 -0700 (PDT)
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 u3JL6aB4021467 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Apr 2016 17:06:36 -0400
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 19 Apr 2016 17:06:35 -0400
From: "Fregly, Andrew" 
To: George Fletcher , John Bradley , "oauth@ietf.org" 
Thread-Topic: =?utf-8?B?W09BVVRILVdHXSBCdWlsZGluZyBvbiB0aGUgcHJvdG9jb2wgaW4gdGhlIGRy?= =?utf-8?B?YWZ0IOKAnE9BdXRoIDIuMCBUb2tlbiBFeGNoYW5nZTogQW4gU1RTIGZvciB0?= =?utf-8?B?aGUgUkVTVCBvZiBVc+KAnSB0byBpbmNsdWRlIEF1dGhlbnRpY2F0aW9uIFRv?= =?utf-8?Q?kens?=
Thread-Index: AQHRmnitgCv5cI6zuEydb4HTyF4ZfZ+RycMA
Date: Tue, 19 Apr 2016 21:06:34 +0000
Message-ID: <6101D0EB-E04B-4574-8899-ED8F4E631D67@verisign.com>
References:   <8B748252-9AE2-4824-923B-00CD46CB8D68@verisign.com> <571692A1.5070000@aol.com>
In-Reply-To: <571692A1.5070000@aol.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.160212
x-originating-ip: [10.173.152.4]
Content-Type: multipart/alternative; boundary="_000_6101D0EBE04B45748899ED8F4E631D67verisigncom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] =?utf-8?q?Building_on_the_protocol_in_the_draft_?= =?utf-8?q?=E2=80=9COAuth_2=2E0_Token_Exchange=3A_An_STS_for_the_REST_of_U?= =?utf-8?q?s=E2=80=9D_to_include_Authentication_Tokens?=
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Apr 2016 21:06:40 -0000

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

VGhhbmsgeW91IGZvciB5b3VyIHJlc3BvbnNlIEdlb3JnZS4gSXQgcG9pbnRzIG1lIHRvIHNvbWUg
bW9yZSByZXNlYXJjaCB0byBkbywgc3VjaCBhcyBsb29raW5nIGF0IE9wZW5JRCBDb25uZWN0IHN1
cHBvcnQgZm9yIGJvdGggZGlzdHJpYnV0ZWQgYW5kIGFnZ3JlZ2F0ZWQgY2xhaW1zLg0KDQpCZWxv
dyBhcmUgcmVwbGllcyB0byB5b3VyIHF1ZXN0aW9ucy9hc3NlcnRpb25zIGJhc2VkIG9uIG15IGN1
cnJlbnQgdW5kZXJzdGFuZGluZyBvZiB0aGUgdmFyaW91cyBwcm90b2NvbHMuIEZ1cnRoZXIgcmVz
ZWFyY2ggYW5kIGFkdmljZSB3aWxsIGxpa2VseSBlbnJpY2ggdGhpcyBzaWduaWZpY2FudGx5Lg0K
DQpZZXMsIHdoYXQgaXMgcmVxdWlyZWQgaXMgYSB2ZXJpZmlhYmxlIGNsYWltIHRoYXQgdGhlIHVz
ZXIgaXMgc3RpbGwgYSBtZW1iZXIgb2YgU29tZU9yZyBJbmMuIEkgaGF2ZSBiZWVuIG9wZXJhdGlu
ZyB1bmRlciB0aGUgYXNzdW1wdGlvbiB0aGF0IHRoZSBvbmx5IHdheSB0aGlzIGNhbiBiZSBkb25l
IHdvdWxkIGJlIHRvIGhhdmUgdGhlIHVzZXIgYXV0aGVudGljYXRlZCBieSB0aGUgSWRlbnRpdHkg
UHJvdmlkZXIgZm9yIFNvbWVPcmcuIFBlcmhhcHMgdGhlIHJlc2VhcmNoIGludG8gT3BlbklEIENv
bm5lY3Qgc3VwcG9ydCBmb3IgZGlzdHJpYnV0ZWQgYW5kIGFnZ3JlZ2F0ZWQgY2xhaW1zIHdpbGwg
cmV2ZWFsIGFuIGFsdGVybmF0aXZlLiBJIGZvcmVzZWUgYSBjaGFsbGVuZ2UgaW4gZGVhbGluZyB3
aXRoIElkZW50aXR5IFByb3ZpZGVy4oCZcyBmb3Igb3JnYW5pemF0aW9ucyB1c2luZyBTQU1MIGFz
c2VydGlvbnMgb24gdG9wIG9mIEFjdGl2ZSBEaXJlY3RvcnkgYW5kIExEQVAsIGFuZCB3aGljaCBh
cmUgbm90IGdvaW5nIHRvIGRvIGFueSB1cGRhdGluZyB0byBzdXBwb3J0IG91ciBuZWVkcy4NCg0K
V2UgZG8gbm90IGV4cGVjdCB0aGUgdXNlciB0byBmaXJzdCBnbyB0byB0aGUgZGF0YSBwcm92aWRl
ci4gV2UgYW50aWNpcGF0ZSB0aGF0IHRoZSBjbGllbnQgYXBwbGljYXRpb24gd291bGQgcHJvdmlk
ZSBhIEF1dGhlbnRpY2F0aW9uIFRva2VuIHRvIGFuICBBdXRob3JpemF0aW9uIFNlcnZpY2Ugc2Vy
dmljZSB0aGF0IHRoZW4gaXNzdWVzIHRvIHRoZSBjbGllbnQgYW4gYWNjZXNzIHRva2VuIHRoYXQg
dGhlIGRhdGEgcHJvdmlkZXIgd2lsbCB0cnVzdC4gT25lIG9mIG91ciByZWFzb25zIGZvciBkb2lu
ZyBpdCB0aGlzIHdheSBpcyB0aGF0IHdlIGFyZSB0cnlpbmcgdG8gZWxpbWluYXRlIHJlZGlyZWN0
cyB0byBlYXNlIGltcGxlbWVudGF0aW9uIG9mIGEgbmF0aXZlIGNsaWVudC4gV2UgYXJlIHRoZXJl
Zm9yZSByZXF1aXJpbmcgdGhlIGNsaWVudCB0byBoYW5kbGUgYXV0aGVudGljYXRpb24gd2l0aCB0
aGUgSWRlbnRpdHkgUHJvdmlkZXIgYXMgYSBzZXBhcmF0ZSBzdGVwIGZyb20gYXV0aG9yaXphdGlv
bi4NCg0KSXQgbWlnaHQgaGVscCBpZiBJIGNsYXJpZmllZCB0aGF0IFZlcmlzaWdu4oCZcyByb2xl
IGluIHRoZSBzY2VuYXJpbyBJIGRlc2NyaWJlZCBpcyB0byBiZSBqdXN0IG9uZSBvZiBtYW55IGRh
dGEgcHJvdmlkZXJzLg0KDQpGcm9tOiBHZW9yZ2UgRmxldGNoZXIgPGdmZmxldGNoQGFvbC5jb208
bWFpbHRvOmdmZmxldGNoQGFvbC5jb20+Pg0KT3JnYW5pemF0aW9uOiBBT0wgTExDDQpEYXRlOiBU
dWVzZGF5LCBBcHJpbCAxOSwgMjAxNiBhdCA0OjE4IFBNDQpUbzogQW5kcmV3IEZyZWdseSA8YWZy
ZWdseUB2ZXJpc2lnbi5jb208bWFpbHRvOmFmcmVnbHlAdmVyaXNpZ24uY29tPj4sIEpvaG4gQnJh
ZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4sICJvYXV0
aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRv
Om9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEJ1aWxkaW5nIG9uIHRo
ZSBwcm90b2NvbCBpbiB0aGUgZHJhZnQg4oCcT0F1dGggMi4wIFRva2VuIEV4Y2hhbmdlOiBBbiBT
VFMgZm9yIHRoZSBSRVNUIG9mIFVz4oCdIHRvIGluY2x1ZGUgQXV0aGVudGljYXRpb24gVG9rZW5z
DQoNClNvIGlmIEkgdW5kZXJzdGFuZCB0aGlzIGNvcnJlY3RseSwgd2hhdCBpcyByZWFsbHkgcmVx
dWlyZWQgaXMgYSB2ZXJpZmlhYmxlIGNsYWltIHRoYXQgdGhlIHVzZXIgaXMgc3RpbGwgYSBtZW1i
ZXIgb2YgU29tZU9yZyBJbmMuIE9wZW5JRCBDb25uZWN0IHN1cHBvcnRzIGJvdGggZGlzdHJpYnV0
ZWQgYW5kIGFnZ3JlZ2F0ZWQgY2xhaW1zIHRoYXQgY2FuIGJlIHNpZ25lZCBieSB0aGUgYXBwcm9w
cmlhdGUgSWRlbnRpdHkgUHJvdmlkZXIuIFRoZSBwb2ludCBiZWluZyB0aGF0IEknbSBub3Qgc3Vy
ZSBhbiAiYXV0aGVudGljYXRpb24gdG9rZW4iIGlzIHJlcXVpcmVkIGZvciB0aGlzIHVzZSBjYXNl
IHRvIHN1Y2NlZWQsIGl0J3MganVzdCBvbmUga2luZCBvZiB0b2tlbiB0aGF0IGNhbiBiZSB1c2Vk
Lg0KDQpBbHNvLCBpcyB0aGUgZXhwZWN0ZWQgZmxvdyB0aGF0IHRoZSB1c2VyIHdpbGwgZmlyc3Qg
Z28gdG8gdGhlIGRhdGEgcHJvdmlkZXIgYW5kIHRoZW4gYmUgZGlyZWN0ZWQgZWxzZSB3aGVyZSBm
cm9tIHRoZXJlPyBJZiB0aGF0IGlzIHRoZSBjYXNlLCB0aGUgZGF0YSBwcm92aWRlciBjYW4ganVz
dCBiZSBhbiBPcGVuSUQgQ29ubmVjdCByZWx5aW5nIHBhcnR5IGFuZCBnaXZlIHRoZSB1c2VyIGFu
IG9wdGlvbiBvZiB0aGUgbGlzdCBvZiBzdXBwb3J0ZWQgSWRQcyB0byBjaG9vc2UgZnJvbS4gVGhl
IHVzZXIgd2lsbCB0aGVuIGJlIHJlZGlyZWN0ZWQgdG8gU29tZU9yZyBJbmMuIElkUCwgYXV0aGVu
dGljYXRlIGFuZCB0aGUgZGF0YSBwcm92aWRlciB3aWxsIGhhdmUgdGhlIGF1dGhvcml6YXRpb24g
YW5kIHJlY2VudCBhdXRoZW50aWNhdGlvbiB0aGV5IGNhbiB2YWxpZGF0ZS4NCg0KSXMgdGhlIHVz
ZXIvZGF0YSBmbG93IG1vcmUgY29tcGxpY2F0ZWQgdGhhbiB0aGlzPw0KDQpUaGFua3MsDQpHZW9y
Z2UNCg0KT24gNC8xOS8xNiA0OjA1IFBNLCBGcmVnbHksIEFuZHJldyB3cm90ZToNClRoYW5rcyBm
b3IgeW91ciByZXNwb25zZSBKb2huLiBJIGFsc28gZ290IGEgZ29vZCByZXNwb25zZSBmcm9tIEJy
aWFuIENhbXBiZWxsIGFuZCBhcHByZWNpYXRlIHRoYXQuIEkgd2lsbCByZXNwb25kIHNlcGFyYXRl
bHkgdG8gQnJpYW7igJlzIHJlc3BvbnNlIGFzIEkgdGhpbmsgaXQgd291bGQga2VlcCB0aGluZ3Mg
Y2xlYXJlciB0byBkbyB0aGF0Lg0KDQpUaGUgcHJvYmxlbSB3ZSBoYXZlIGZvciB1c2luZyBPcGVu
SUQgQ29ubmVjdCBpcyB0aGF0IGl0IGNvbWJpbmVzIHRoZSByb2xlIG9mIEF1dGhlbnRpY2F0aW9u
IFNlcnZpY2Ugd2l0aCB0aGUgcm9sZSBvZiBBdXRob3JpemF0aW9uIFNlcnZpY2UuIFBlcmhhcHMg
dGhlIGZvbGxvd2luZyBkZXNjcmlwdGlvbiBvZiB3aGF0IHdlIHdhbnQgdG8gZG8gd2lsbCBjbGFy
aWZ5IHdoeSB0aGlzIHdvbuKAmXQgd29yayBmb3IgdXM6DQoNClRoZSBiYXNpYyBwcm9ibGVtIHN0
YXRlbWVudCBpcyB0aGF0IHdlIG5lZWQgdG8gaGF2ZSBhIGNsaWVudCBhcHBsaWNhdGlvbiBhdXRo
b3JpemVkIGJ5IGEgU2VydmljZSBQcm92aWRlciBiYXNlZCBvbiBwcm9vZiB0aGF0IGEgdXNlciBp
cyBjdXJyZW50bHkgYSBtZW1iZXIgb2Ygc29tZSBvcmdhbml6YXRpb24uIFRoaXMgYXNzdW1lcyB0
aGUgb3JnYW5pemF0aW9uIGhhcyBwcmV2aW91c2x5IGVzdGFibGlzaGVkIHNvbWUgbGV2ZWwgb2Yg
YXV0aG9yaXplZCBhY2Nlc3Mgd2l0aCB0aGUgU2VydmljZSBQcm92aWRlci4NCg0KSGVyZSBpcyBh
biBleGFtcGxlOiBTdXBwb3NlIEkgYW0gYSBtZW1iZXIgb2YgU29tZU9yZyBJbmMuIFN1cHBvc2Ug
U29tZU9yZyBJbmMuIGlzIGRvaW5nIHJlc2VhcmNoIHRoYXQgcmVxdWlyZXMgaXQgdG8gZ2F0aGVy
IGRhdGEgb3ZlciB0aGUgSW50ZXJuZXQgZnJvbSBhIG51bWJlciBvZiBkYXRhIHByb3ZpZGVycy4g
VGhlIGRhdGEgcHJvdmlkZXJzIHJlcXVpcmUgYXV0aGVudGljYXRpb24gYW5kIHByb29mIG9mIG9y
Z2FuaXphdGlvbmFsIG1lbWJlcnNoaXAgaW4gb3JkZXIgdG8gYXV0aG9yaXplIHZhcmlvdXMgbGV2
ZWxzIG9mIGFjY2VzcyB0byB0aGVpciBkYXRhLiBUaGUgZGF0YSBwcm92aWRlcnMgZG8gbm90IGNv
bnNpZGVyIGhhdmluZyBhbiBhY2NvdW50IHdpdGggdGhlbSBvciBhIFB1YmxpYyBJZGVudGl0eSBQ
cm92aWRlciB0byBiZSBzdWl0YWJsZSBmb3IgcHJvdmluZyB0aGF0IEkgYW0gc3RpbGwgYSBtZW1i
ZXIgb2YgU29tZU9yZyBhdCB0aW1lIG9mIGF1dGhlbnRpY2F0aW9uLiBUaGV5IHdvdWxkIGhhdmUg
bm8gd2F5IG9mIGtub3dpbmcgd2hldGhlciBvciBub3QgbXkgcmVsYXRpb25zaGlwIHdpdGggU29t
ZU9yZyBzdGlsbCBleGlzdHMgYXQgdGhhdCB0aW1lLiBUaGUgZGF0YSBwcm92aWRlcnMgd291bGQg
dGhlcmVmb3JlIGxpa2UgdGhlIENsaWVudCBzb2Z0d2FyZSB0byBhdXRoZW50aWNhdGUgbWUgYWdh
aW5zdCBTb21lT3JncyBJZGVudGl0eSBQcm92aWRlci4gVGhpcyB3b3VsZCBiZSBnb29kIHByb29m
IHRoYXQgSSBhbSBzdGlsbCBhIG1lbWJlciBvZiBTb21lT3JnIGF0IHRoZSB0aW1lIEkgYXV0aGVu
dGljYXRlLiBUaGlzIGF1dGhlbnRpY2F0aW9uIHdvdWxkIGVuYWJsZSB0aGUgZGF0YSBwcm92aWRl
cnMgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgdG8gZ3JhbnQgbWUgYWNjZXNzIGFwcHJvcHJpYXRlIHRv
IGEgbWVtYmVyIG9mIFNvbWVPcmcuICBOb3RlIHRoYXQgYXMgYSBwcmVyZXF1aXNpdGUgdG8gYWxs
IG9mIHRoaXMsIFNvbWVPcmcgd2lsbCBoYXZlIHVzZWQgYW4gb3V0LW9mLWJhbmQgcHJvY2VzcyB0
byBzZXQgdXAgYSB0cnVzdCByZWxhdGlvbnNoaXAgZm9yIFNvbWVPcmcncyBJZGVudGl0eSBQcm92
aWRlciB3aXRoIHRoZSBkYXRhIHByb3ZpZGVy4oCZcyBBdXRob3JpemF0aW9uIFNlcnZpY2UsIGFu
ZCB3aWxsIGhhdmUgbmVnb3RpYXRlZCBhdXRob3JpemF0aW9uIGNsYWltcyB0byBiZSBncmFudGVk
IHRvIFNvbWVPcmdzIG1lbWJlcnMuDQoNCldoYXQgSSBhbSBoYXZpbmcgZGlmZmljdWx0eSB3aXRo
IGlzIGluIGtuaXR0aW5nIHRvZ2V0aGVyIGFuIGFwcHJvYWNoIGJhc2VkIG9uIHRoZSBoZSBPcGVu
SUQgQ29ubmVjdCBzcGVjaWZpY2F0aW9ucywgU0FNTCBzcGVjaWZpY2F0aW9ucywgYW5kIE9BdXRo
IFJGQ3MgYW5kIGRyYWZ0cyBpbiBhIHdheSB0aGF0IHN1cHBvcnRzIHRoZSBhYm92ZSB1c2UgY2Fz
ZSBlbmQtdG8tZW5kLiBUaGUgT0F1dGggUkZDcyBhbmQgZHJhZnRzIGFsbW9zdCBnZXQgbWUgdGhl
cmUuIFdoYXQgc2VlbXMgdG8gYmUgbWlzc2luZyBpcyBhIHdheSBvZiB0ZWxsaW5nIGFuIElkZW50
aXR5IFByb3ZpZGVyIHRoZSBVUkwgZm9yIHRoZSBBdXRob3JpemF0aW9uIFNlcnZpY2UgKHRoZSBy
ZXF1aXJlZCBBdWRpZW5jZSBjbGFpbSBpbiBhbiBhdXRoZW50aWNhdGlvbiBhc3NlcnRpb24gYXMg
ZGVmaW5lZCBpbiBSRkNzIDcyNTEsIDcyNTIgYW5kIDcyNTMpLCBhbmQgdGhlbiBhIHJlcXVpcmVt
ZW50IHRoYXQgdGhlIElkZW50aXR5IFByb3ZpZGVycyBwdXQgdGhlIHN1cHBsaWVkIEF1ZGllbmNl
IElkZW50aWZpZXIgaW50byBBdXRoZW50aWNhdGlvbiBUb2tlbnMuIFBlcmhhcHMgYSBsaXR0bGUg
ZnVydGhlciBiYWNrLWFuZC1mb3J0aCB3aXRoIEJyaWFuIHdpbGwgcmVzb2x2ZSB0aGlzLg0KDQpJ
IGNhbiBnbyBpbnRvIGRlZXBlciBkZXRhaWwgaWYgbmVlZGVkLiBJZiB0aGlzIGlzIG9mZi10b3Bp
YyBmb3IgdGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAsIGxldCBtZSBrbm93Lg0KDQpUaGFua3MsDQpB
bmRyZXcgRnJlZ2x5DQpWZXJpc2lnbiBJbmMuDQoNCg0KRnJvbTogSm9obiBCcmFkbGV5IDw8bWFp
bHRvOnZlN2p0YkB2ZTdqdGIuY29tPnZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3
anRiLmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBBcHJpbCAxOSwgMjAxNiBhdCAyOjA2IFBNDQpUbzog
QW5kcmV3IEZyZWdseSA8PG1haWx0bzphZnJlZ2x5QHZlcmlzaWduLmNvbT5hZnJlZ2x5QHZlcmlz
aWduLmNvbTxtYWlsdG86YWZyZWdseUB2ZXJpc2lnbi5jb20+Pg0KQ2M6ICI8bWFpbHRvOm9hdXRo
QGlldGYub3JnPm9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4iIDxvYXV0aEBp
ZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10g
QnVpbGRpbmcgb24gdGhlIHByb3RvY29sIGluIHRoZSBkcmFmdCDigJxPQXV0aCAyLjAgVG9rZW4g
RXhjaGFuZ2U6IEFuIFNUUyBmb3IgdGhlIFJFU1Qgb2YgVXPigJ0gdG8gaW5jbHVkZSBBdXRoZW50
aWNhdGlvbiBUb2tlbnMNCg0KTG9va2luZyBhdCBPcGVuSUQgQ29ubmVjdCBhbmQgaXTigJlzIHRy
dXN0IG1vZGVsIGZvciBwcm9kdWNpbmcgaWRfdG9rZW5zIHRoYXQgYXNzZXJ0IGlkZW50aXR5IG1h
eSBoZWxwIHlvdS4NCmh0dHA6Ly9vcGVuaWQubmV0L3dnL2Nvbm5lY3QvDQoNClVuZm9ydHVuYXRl
bHkgSSBjYW7igJl0IHF1aXRlIG1ha2Ugb3V0IHdoYXQgeW91IGFyZSB0cnlpbmcgdG8gZG8uDQoN
Ckl0IHNvcnQgb2Ygc291bmRzIGxpa2UgeW91IHdhbnQgYW4gaWRfdG9rZW4gZnJvbSBhIGlkUCBh
bmQgdGhlbiBoYXZlIHRoZSBjbGllbnQgZXhjaGFuZ2UgdGhhdCBhc3NlcnRpb24gZm9yIGFub3Ro
ZXIgdG9rZW4/DQoNCkpvaG4gQi4NCk9uIEFwciAxOSwgMjAxNiwgYXQgMToxOCBQTSwgRnJlZ2x5
LCBBbmRyZXcgPGFmcmVnbHlAdmVyaXNpZ24uY29tPG1haWx0bzphZnJlZ2x5QHZlcmlzaWduLmNv
bT4+IHdyb3RlOg0KDQpJIGhhdmUgYSB1c2UgY2FzZSB3aGVyZSBhIGNsaWVudCBhcHBsaWNhdGlv
biBuZWVkcyB0byBhdXRoZW50aWNhdGUgd2l0aCBhIGR5bmFtaWNhbGx5IGRldGVybWluZWQgSWRl
bnRpdHkgUHJvdmlkZXIgdGhhdCBpcyBzZXBhcmF0ZSBmcm9tIHRoZSBBdXRob3JpemF0aW9uIFNl
cnZpY2UgdGhhdCB3aWxsIGJlIHVzZWQgaXNzdWUgYW4gYWNjZXNzIHRva2VuIHRvIHRoZSBjbGll
bnQuIFRoZSB1c2UgY2FzZSBhbHNvIHJlcXVpcmVzIHRoYXQgYXMgcGFydCBvZiBhdXRob3JpemF0
aW9uLCB0aGUgY2xpZW50IHByb3ZpZGVzIHRvIHRoZSBBdXRob3JpemF0aW9uIFNlcnZpY2UgYW4g
YXV0aGVudGljYXRpb24gdG9rZW4gc2lnbmVkIGJ5IGFuIElkZW50aXR5IFByb3ZpZGVyIHRoYXQg
dGhlIEF1dGhvcml6YXRpb24gU2VydmljZSBoYXMgYSB0cnVzdCByZWxhdGlvbnNoaXAgd2l0aC4g
VGhlIHRydXN0IHJlbGF0aW9uc2hpcCBpcyB2ZXJpZmlhYmxlIGJhc2VkIG9uIHRoZSBBdXRob3Jp
emF0aW9uIFNlcnZpY2UgaGF2aW5nIHJlY29yZGVkIHRoZSBwdWJsaWMga2V5cyBvciBjZXJ0aWZp
Y2F0ZXMgb2YgdHJ1c3RlZCBJZGVudGl0eSBQcm92aWRlcnMgaW4gYSB0cnVzdCBzdG9yZSwgdGhp
cyBhbGxvd2luZyB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2aWNlIHRvIHZlcmlmeSBhbiBJZGVudGl0
eSBQcm92aWRlcuKAmXMgc2lnbmF0dXJlIG9uIGFuIGF1dGhlbnRpY2F0aW9uIHRva2VuLg0KDQpJ
biBsb29raW5nIGF0IHRoZSB2YXJpb3VzIE9BdXRoIFJGQ3MsIHBhcnRpY3VsYXJseSBSRkNzIDc1
MjEsIDc1MjIsIGFuZCA3NTIzLCBJIHNlZSB0aGF0IHRoZXkgZ2V0IG1lIGNsb3NlIGluIHRlcm1z
IG9mIHN1cHBvcnRpbmcgdGhlIHVzZSBjYXNlLiBXaGF0IGlzIG1pc3NpbmcgaXMgYSBtZWFucyBm
b3Igc29sdmluZyB0aGUgZm9sbG93aW5nIHByb2JsZW0uIFRoZXNlIFJGQ3MgcmVxdWlyZSB0aGF0
IHRoZSBJZGVudGl0eSBQcm92aWRlciBwdXQgYW4gQXVkaWVuY2UgY2xhaW0gaW4gdGhlIGF1dGhl
bnRpY2F0aW9uIHRva2VuLiBUaGUgcHJvYmxlbSB3aXRoIHRoaXMgaXMgdGhhdCBJIGRvIG5vdCBz
ZWUgaW4gdGhlIFJGQ3MgaG93IHRoZSBJZGVudGl0eSBQcm92aWRlciBjYW4gYmUgdG9sZCB3aG8g
dGhlIEF1ZGllbmNlIGlzIHRvIHB1dCBpbnRvIHRoZSBhdXRoZW50aWNhdGlvbiB0b2tlbi4gVGhp
cyBsZWFkcyBtZSB0byB0aGUgdGl0bGUgb2YgdGhpcyBtZXNzYWdlLiBUaGUgZHJhZnQg4oCcT0F1
dGggMi4wIFRva2VuIEV4Y2hhbmdlOiBBbiBTVFMgZm9yIHRoZSBSRVNUIG9mIFVz4oCdIGRlZmlu
ZXMgYSBtZWNoYW5pc20gZm9yIGlkZW50aWZ5aW5nIHRoZSBBdWRpZW5jZSBmb3IgYW4gU1RTIHRv
IHB1dCBpbnRvIGEgdG9rZW4gaXQgZ2VuZXJhdGVzLiBUaGF0IHdvdWxkIHNvbHZlIG15IHByb2Js
ZW0gZXhjZXB0IHRoYXQgdGhlIGRyYWZ0IGxpbWl0cyB0aGUgdHlwZSBvZiBTVFMgdG8gYmVpbmcg
QXV0aG9yaXphdGlvbiBTZXJ2ZXJzLiBXaGF0IGlzIG5lZWRlZCBpcyB0aGlzIHNhbWUgY2FwYWJp
bGl0eSBmb3IgaW50ZXJhY3Rpbmcgd2l0aCBhbiBJZGVudGl0eSBQcm92aWRlci4gVGhpcyB3b3Vs
ZCBlbmFibGUgUkZDcyA3NTIxLCA3NTIyIGFuZCA3NTIzIHRvIGJlIHVzZWZ1bCBpbiBzaXR1YXRp
b24gd2hlcmUgdGhlIElkZW50aXR5IFByb3ZpZGVyIG5lZWRzIHRvIGJlIHRvbGQgdGhlIGlkZW50
aXR5IG9mIHRoZSBBdXRob3JpemF0aW9uIFNlcnZpY2UuDQoNCkkgYW0gbmV3IHRvIGludGVyYWN0
aW5nIHdpdGggdGhlIElFVEYuIEkgYWxzbyBhbSBub3QgYW4gZXhwZXJ0IG9uIHRoZSBSRkNzIG9y
IHByaW9yIGhpc3Rvcnkgb2YgdGhlIE9BdXRoIGdyb3VwIHJlbGF0aXZlIHRvIHRoaXMgdG9waWMs
IHNvIHBsZWFzZSBwb2ludCBtZSB0byBhbnkgZXhpc3Rpbmcgc29sdXRpb24gaWYgdGhpcyBpcyBh
IHNvbHZlZCBwcm9ibGVtLiBPdGhlcndpc2UsIEkgd291bGQgbGlrZSB0byBnZXQgZmVlZGJhY2sg
b24gbXkgc3VnZ2VzdGlvbi4NCg0KVGhhbmtzIFlvdSwNCg0KQW5kcmV3IEZyZWdseQ0KVmVyaXNp
Z24gSW5jLg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
Ck9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3Jn
Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0KDQpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFp
bGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+aHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo=

--_000_6101D0EBE04B45748899ED8F4E631D67verisigncom_
Content-Type: text/html; charset="utf-8"
Content-ID: <59B4B37C351E684BA737ADFD1B7424E3@verisign.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+VGhh
bmsgeW91IGZvciB5b3VyIHJlc3BvbnNlIEdlb3JnZS4gSXQgcG9pbnRzIG1lIHRvIHNvbWUgbW9y
ZSByZXNlYXJjaCB0byBkbywgc3VjaCBhcyBsb29raW5nIGF0IE9wZW5JRCBDb25uZWN0IHN1cHBv
cnQgZm9yIGJvdGggZGlzdHJpYnV0ZWQgYW5kIGFnZ3JlZ2F0ZWQgY2xhaW1zLjwvZGl2Pg0KPGRp
dj48YnI+DQo8L2Rpdj4NCjxkaXY+QmVsb3cgYXJlIHJlcGxpZXMgdG8geW91ciBxdWVzdGlvbnMv
YXNzZXJ0aW9ucyBiYXNlZCBvbiBteSBjdXJyZW50IHVuZGVyc3RhbmRpbmcgb2YgdGhlIHZhcmlv
dXMgcHJvdG9jb2xzLiBGdXJ0aGVyIHJlc2VhcmNoIGFuZCBhZHZpY2Ugd2lsbCBsaWtlbHkgZW5y
aWNoIHRoaXMgc2lnbmlmaWNhbnRseS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Plll
cywgd2hhdCBpcyByZXF1aXJlZCBpcyBhIHZlcmlmaWFibGUgY2xhaW0gdGhhdCB0aGUgdXNlciBp
cyBzdGlsbCBhIG1lbWJlciBvZiBTb21lT3JnIEluYy4gSSBoYXZlIGJlZW4gb3BlcmF0aW5nIHVu
ZGVyIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlIG9ubHkgd2F5IHRoaXMgY2FuIGJlIGRvbmUgd291
bGQgYmUgdG8gaGF2ZSB0aGUgdXNlciBhdXRoZW50aWNhdGVkIGJ5IHRoZSBJZGVudGl0eSBQcm92
aWRlciBmb3IgU29tZU9yZy4gUGVyaGFwcw0KIHRoZSByZXNlYXJjaCBpbnRvIE9wZW5JRCBDb25u
ZWN0IHN1cHBvcnQgZm9yIGRpc3RyaWJ1dGVkIGFuZCBhZ2dyZWdhdGVkIGNsYWltcyB3aWxsIHJl
dmVhbCBhbiBhbHRlcm5hdGl2ZS4gSSBmb3Jlc2VlIGEgY2hhbGxlbmdlIGluIGRlYWxpbmcgd2l0
aCBJZGVudGl0eSBQcm92aWRlcuKAmXMgZm9yIG9yZ2FuaXphdGlvbnMgdXNpbmcgU0FNTCBhc3Nl
cnRpb25zIG9uIHRvcCBvZiBBY3RpdmUgRGlyZWN0b3J5IGFuZCBMREFQLCBhbmQgd2hpY2ggYXJl
DQogbm90IGdvaW5nIHRvIGRvIGFueSB1cGRhdGluZyB0byBzdXBwb3J0IG91ciBuZWVkcy48L2Rp
dj4NCjxkaXY+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldlIGRvIG5vdCBleHBlY3QgdGhlIHVz
ZXIgdG8gZmlyc3QgZ28gdG8gdGhlIGRhdGEgcHJvdmlkZXIuIFdlIGFudGljaXBhdGUgdGhhdCB0
aGUgY2xpZW50IGFwcGxpY2F0aW9uIHdvdWxkIHByb3ZpZGUgYSBBdXRoZW50aWNhdGlvbiBUb2tl
biB0byBhbiAmbmJzcDtBdXRob3JpemF0aW9uIFNlcnZpY2Ugc2VydmljZSB0aGF0IHRoZW4gaXNz
dWVzIHRvIHRoZSBjbGllbnQgYW4gYWNjZXNzIHRva2VuIHRoYXQgdGhlIGRhdGEgcHJvdmlkZXIg
d2lsbCB0cnVzdC4NCiBPbmUgb2Ygb3VyIHJlYXNvbnMgZm9yIGRvaW5nIGl0IHRoaXMgd2F5IGlz
IHRoYXQgd2UgYXJlIHRyeWluZyB0byBlbGltaW5hdGUgcmVkaXJlY3RzIHRvIGVhc2UgaW1wbGVt
ZW50YXRpb24gb2YgYSBuYXRpdmUgY2xpZW50LiBXZSBhcmUgdGhlcmVmb3JlIHJlcXVpcmluZyB0
aGUgY2xpZW50IHRvIGhhbmRsZSBhdXRoZW50aWNhdGlvbiB3aXRoIHRoZSBJZGVudGl0eSBQcm92
aWRlciBhcyBhIHNlcGFyYXRlIHN0ZXAgZnJvbSBhdXRob3JpemF0aW9uLjwvZGl2Pg0KPGRpdj48
YnI+DQo8L2Rpdj4NCjxkaXY+SXQgbWlnaHQgaGVscCBpZiBJIGNsYXJpZmllZCB0aGF0IFZlcmlz
aWdu4oCZcyByb2xlIGluIHRoZSBzY2VuYXJpbyBJIGRlc2NyaWJlZCBpcyB0byBiZSBqdXN0IG9u
ZSBvZiBtYW55IGRhdGEgcHJvdmlkZXJzLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFu
IGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxp
YnJpOyBmb250LXNpemU6MTJwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVS
LUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1C
T1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVS
LVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJ
TkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bh
bj5HZW9yZ2UgRmxldGNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpnZmZsZXRjaEBhb2wuY29tIj5n
ZmZsZXRjaEBhb2wuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s
ZCI+T3JnYW5pemF0aW9uOiA8L3NwYW4+QU9MIExMQzxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdl
aWdodDpib2xkIj5EYXRlOiA8L3NwYW4+VHVlc2RheSwgQXByaWwgMTksIDIwMTYgYXQgNDoxOCBQ
TTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPkFuZHJldyBG
cmVnbHkgJmx0OzxhIGhyZWY9Im1haWx0bzphZnJlZ2x5QHZlcmlzaWduLmNvbSI+YWZyZWdseUB2
ZXJpc2lnbi5jb208L2E+Jmd0OywgSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3
anRiQHZlN2p0Yi5jb20iPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9
Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBo
cmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8
c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbT0FVVEgt
V0ddIEJ1aWxkaW5nIG9uIHRoZSBwcm90b2NvbCBpbiB0aGUgZHJhZnQg4oCcT0F1dGggMi4wIFRv
a2VuIEV4Y2hhbmdlOiBBbiBTVFMgZm9yIHRoZSBSRVNUIG9mIFVz4oCdIHRvIGluY2x1ZGUgQXV0
aGVudGljYXRpb24gVG9rZW5zPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2Nr
cXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JE
RVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1
OyI+DQo8ZGl2Pg0KPGRpdiBiZ2NvbG9yPSIjRkZGRkZGIiB0ZXh0PSIjMDAwMDAwIj48Zm9udCBm
YWNlPSJIZWx2ZXRpY2EsQXJpYWwsc2Fucy1zZXJpZiI+U28gaWYgSSB1bmRlcnN0YW5kIHRoaXMg
Y29ycmVjdGx5LCB3aGF0IGlzIHJlYWxseSByZXF1aXJlZCBpcyBhIHZlcmlmaWFibGUgY2xhaW0g
dGhhdCB0aGUgdXNlciBpcyBzdGlsbCBhIG1lbWJlciBvZiBTb21lT3JnIEluYy4gT3BlbklEIENv
bm5lY3Qgc3VwcG9ydHMgYm90aCBkaXN0cmlidXRlZCBhbmQgYWdncmVnYXRlZA0KIGNsYWltcyB0
aGF0IGNhbiBiZSBzaWduZWQgYnkgdGhlIGFwcHJvcHJpYXRlIElkZW50aXR5IFByb3ZpZGVyLiBU
aGUgcG9pbnQgYmVpbmcgdGhhdCBJJ20gbm90IHN1cmUgYW4gJnF1b3Q7YXV0aGVudGljYXRpb24g
dG9rZW4mcXVvdDsgaXMgcmVxdWlyZWQgZm9yIHRoaXMgdXNlIGNhc2UgdG8gc3VjY2VlZCwgaXQn
cyBqdXN0IG9uZSBraW5kIG9mIHRva2VuIHRoYXQgY2FuIGJlIHVzZWQuPGJyPg0KPGJyPg0KQWxz
bywgaXMgdGhlIGV4cGVjdGVkIGZsb3cgdGhhdCB0aGUgdXNlciB3aWxsIGZpcnN0IGdvIHRvIHRo
ZSBkYXRhIHByb3ZpZGVyIGFuZCB0aGVuIGJlIGRpcmVjdGVkIGVsc2Ugd2hlcmUgZnJvbSB0aGVy
ZT8gSWYgdGhhdCBpcyB0aGUgY2FzZSwgdGhlIGRhdGEgcHJvdmlkZXIgY2FuIGp1c3QgYmUgYW4g
T3BlbklEIENvbm5lY3QgcmVseWluZyBwYXJ0eSBhbmQgZ2l2ZSB0aGUgdXNlciBhbiBvcHRpb24g
b2YgdGhlIGxpc3Qgb2Ygc3VwcG9ydGVkIElkUHMNCiB0byBjaG9vc2UgZnJvbS4gVGhlIHVzZXIg
d2lsbCB0aGVuIGJlIHJlZGlyZWN0ZWQgdG8gU29tZU9yZyBJbmMuIElkUCwgYXV0aGVudGljYXRl
IGFuZCB0aGUgZGF0YSBwcm92aWRlciB3aWxsIGhhdmUgdGhlIGF1dGhvcml6YXRpb24gYW5kIHJl
Y2VudCBhdXRoZW50aWNhdGlvbiB0aGV5IGNhbiB2YWxpZGF0ZS48YnI+DQo8YnI+DQpJcyB0aGUg
dXNlci9kYXRhIGZsb3cgbW9yZSBjb21wbGljYXRlZCB0aGFuIHRoaXM/PGJyPg0KPGJyPg0KVGhh
bmtzLDxicj4NCkdlb3JnZTxicj4NCjwvZm9udD48YnI+DQo8ZGl2IGNsYXNzPSJtb3otY2l0ZS1w
cmVmaXgiPk9uIDQvMTkvMTYgNDowNSBQTSwgRnJlZ2x5LCBBbmRyZXcgd3JvdGU6PGJyPg0KPC9k
aXY+DQo8YmxvY2txdW90ZSBjaXRlPSJtaWQ6OEI3NDgyNTItOUFFMi00ODI0LTkyM0ItMDBDRDQ2
Q0I4RDY4QHZlcmlzaWduLmNvbSIgdHlwZT0iY2l0ZSI+DQo8ZGl2Pg0KPGRpdj5UaGFua3MgZm9y
IHlvdXIgcmVzcG9uc2UgSm9obi4gSSBhbHNvIGdvdCBhIGdvb2QgcmVzcG9uc2UgZnJvbSBCcmlh
biBDYW1wYmVsbCBhbmQgYXBwcmVjaWF0ZSB0aGF0LiBJIHdpbGwgcmVzcG9uZCBzZXBhcmF0ZWx5
IHRvIEJyaWFu4oCZcyByZXNwb25zZSBhcyBJIHRoaW5rIGl0IHdvdWxkIGtlZXAgdGhpbmdzIGNs
ZWFyZXIgdG8gZG8gdGhhdC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSBwcm9i
bGVtIHdlIGhhdmUgZm9yIHVzaW5nIE9wZW5JRCBDb25uZWN0IGlzIHRoYXQgaXQgY29tYmluZXMg
dGhlIHJvbGUgb2YgQXV0aGVudGljYXRpb24gU2VydmljZSB3aXRoIHRoZSByb2xlIG9mIEF1dGhv
cml6YXRpb24gU2VydmljZS4gUGVyaGFwcyB0aGUgZm9sbG93aW5nIGRlc2NyaXB0aW9uIG9mIHdo
YXQgd2Ugd2FudCB0byBkbyB3aWxsIGNsYXJpZnkgd2h5IHRoaXMgd29u4oCZdCB3b3JrIGZvciB1
czo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSBiYXNpYyBwcm9ibGVtIHN0YXRl
bWVudCBpcyB0aGF0IHdlIG5lZWQgdG8gaGF2ZSBhIGNsaWVudCBhcHBsaWNhdGlvbiBhdXRob3Jp
emVkIGJ5IGEgU2VydmljZSBQcm92aWRlciBiYXNlZCBvbiBwcm9vZiB0aGF0IGEgdXNlciBpcyBj
dXJyZW50bHkgYSBtZW1iZXIgb2Ygc29tZSBvcmdhbml6YXRpb24uIFRoaXMgYXNzdW1lcyB0aGUg
b3JnYW5pemF0aW9uIGhhcyBwcmV2aW91c2x5IGVzdGFibGlzaGVkIHNvbWUgbGV2ZWwgb2YgYXV0
aG9yaXplZA0KIGFjY2VzcyB3aXRoIHRoZSBTZXJ2aWNlIFByb3ZpZGVyLiZuYnNwOzwvZGl2Pg0K
PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SGVyZSBpcyBhbiBleGFtcGxlOiBTdXBwb3NlIEkgYW0g
YSBtZW1iZXIgb2YgU29tZU9yZyBJbmMuIFN1cHBvc2UgU29tZU9yZyBJbmMuIGlzIGRvaW5nIHJl
c2VhcmNoIHRoYXQgcmVxdWlyZXMgaXQgdG8gZ2F0aGVyIGRhdGEgb3ZlciB0aGUgSW50ZXJuZXQg
ZnJvbSBhIG51bWJlciBvZiBkYXRhIHByb3ZpZGVycy4gVGhlIGRhdGEgcHJvdmlkZXJzIHJlcXVp
cmUgYXV0aGVudGljYXRpb24gYW5kIHByb29mIG9mIG9yZ2FuaXphdGlvbmFsIG1lbWJlcnNoaXAN
CiBpbiBvcmRlciB0byBhdXRob3JpemUgdmFyaW91cyBsZXZlbHMgb2YgYWNjZXNzIHRvIHRoZWly
IGRhdGEuIFRoZSBkYXRhIHByb3ZpZGVycyBkbyBub3QgY29uc2lkZXIgaGF2aW5nIGFuIGFjY291
bnQgd2l0aCB0aGVtIG9yIGEgUHVibGljIElkZW50aXR5IFByb3ZpZGVyIHRvIGJlIHN1aXRhYmxl
IGZvciBwcm92aW5nIHRoYXQgSSBhbSBzdGlsbCBhIG1lbWJlciBvZiBTb21lT3JnIGF0IHRpbWUg
b2YgYXV0aGVudGljYXRpb24uIFRoZXkgd291bGQNCiBoYXZlIG5vIHdheSBvZiBrbm93aW5nIHdo
ZXRoZXIgb3Igbm90IG15IHJlbGF0aW9uc2hpcCB3aXRoIFNvbWVPcmcgc3RpbGwgZXhpc3RzIGF0
IHRoYXQgdGltZS4gVGhlIGRhdGEgcHJvdmlkZXJzIHdvdWxkIHRoZXJlZm9yZSBsaWtlIHRoZSBD
bGllbnQgc29mdHdhcmUgdG8gYXV0aGVudGljYXRlIG1lIGFnYWluc3QgU29tZU9yZ3MgSWRlbnRp
dHkgUHJvdmlkZXIuIFRoaXMgd291bGQgYmUgZ29vZCBwcm9vZiB0aGF0IEkgYW0gc3RpbGwgYSBt
ZW1iZXINCiBvZiBTb21lT3JnIGF0IHRoZSB0aW1lIEkgYXV0aGVudGljYXRlLiBUaGlzIGF1dGhl
bnRpY2F0aW9uIHdvdWxkIGVuYWJsZSB0aGUgZGF0YSBwcm92aWRlcnMgQXV0aG9yaXphdGlvbiBT
ZXJ2ZXIgdG8gZ3JhbnQgbWUgYWNjZXNzIGFwcHJvcHJpYXRlIHRvIGEgbWVtYmVyIG9mIFNvbWVP
cmcuICZuYnNwO05vdGUgdGhhdCBhcyBhIHByZXJlcXVpc2l0ZSB0byBhbGwgb2YgdGhpcywgU29t
ZU9yZyB3aWxsIGhhdmUgdXNlZCBhbiBvdXQtb2YtYmFuZCBwcm9jZXNzDQogdG8gc2V0IHVwIGEg
dHJ1c3QgcmVsYXRpb25zaGlwIGZvciBTb21lT3JnJ3MgSWRlbnRpdHkgUHJvdmlkZXIgd2l0aCB0
aGUgZGF0YSBwcm92aWRlcuKAmXMgQXV0aG9yaXphdGlvbiBTZXJ2aWNlLCBhbmQgd2lsbCBoYXZl
IG5lZ290aWF0ZWQgYXV0aG9yaXphdGlvbiBjbGFpbXMgdG8gYmUgZ3JhbnRlZCB0byBTb21lT3Jn
cyBtZW1iZXJzLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V2hhdCBJIGFtIGhhdmlu
ZyBkaWZmaWN1bHR5IHdpdGggaXMgaW4ga25pdHRpbmcgdG9nZXRoZXIgYW4gYXBwcm9hY2ggYmFz
ZWQgb24gdGhlIGhlIE9wZW5JRCBDb25uZWN0IHNwZWNpZmljYXRpb25zLCBTQU1MIHNwZWNpZmlj
YXRpb25zLCBhbmQgT0F1dGggUkZDcyBhbmQgZHJhZnRzIGluIGEgd2F5IHRoYXQgc3VwcG9ydHMg
dGhlIGFib3ZlIHVzZSBjYXNlIGVuZC10by1lbmQuIFRoZSBPQXV0aCBSRkNzIGFuZCBkcmFmdHMg
YWxtb3N0IGdldA0KIG1lIHRoZXJlLiBXaGF0IHNlZW1zIHRvIGJlIG1pc3NpbmcgaXMgYSB3YXkg
b2YgdGVsbGluZyBhbiBJZGVudGl0eSBQcm92aWRlciB0aGUgVVJMIGZvciB0aGUgQXV0aG9yaXph
dGlvbiBTZXJ2aWNlICh0aGUgcmVxdWlyZWQgQXVkaWVuY2UgY2xhaW0gaW4gYW4gYXV0aGVudGlj
YXRpb24gYXNzZXJ0aW9uIGFzIGRlZmluZWQgaW4gUkZDcyA3MjUxLCA3MjUyIGFuZCA3MjUzKSwg
YW5kIHRoZW4gYSByZXF1aXJlbWVudCB0aGF0IHRoZSBJZGVudGl0eQ0KIFByb3ZpZGVycyBwdXQg
dGhlIHN1cHBsaWVkIEF1ZGllbmNlIElkZW50aWZpZXIgaW50byBBdXRoZW50aWNhdGlvbiBUb2tl
bnMuIFBlcmhhcHMgYSBsaXR0bGUgZnVydGhlciBiYWNrLWFuZC1mb3J0aCB3aXRoIEJyaWFuIHdp
bGwgcmVzb2x2ZSB0aGlzLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSBjYW4gZ28g
aW50byBkZWVwZXIgZGV0YWlsIGlmIG5lZWRlZC4gSWYgdGhpcyBpcyBvZmYtdG9waWMgZm9yIHRo
ZSBPQXV0aCB3b3JraW5nIGdyb3VwLCBsZXQgbWUga25vdy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9k
aXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+QW5kcmV3IEZyZWdseTwvZGl2Pg0KPGRpdj5W
ZXJpc2lnbiBJbmMuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48L2Rpdj4NCjwvZGl2
Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8
ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTJwdDsNCiAgICAgICAg
ICB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9u
ZTsNCiAgICAgICAgICBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAw
aW47IFBBRERJTkctTEVGVDoNCiAgICAgICAgICAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9S
REVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7DQogICAgICAgICAgQk9SREVSLVJJR0hUOiBtZWRp
dW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s
ZCI+RnJvbTogPC9zcGFuPkpvaG4gQnJhZGxleSAmbHQ7PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVl
IiBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iPjwvYT48YSBjbGFzcz0ibW96LXR4dC1s
aW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iPnZlN2p0YkB2
ZTdqdGIuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0
ZTogPC9zcGFuPlR1ZXNkYXksIEFwcmlsIDE5LCAyMDE2IGF0IDI6MDYgUE08YnI+DQo8c3BhbiBz
dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5BbmRyZXcgRnJlZ2x5ICZsdDs8YSBt
b3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzphZnJlZ2x5QHZlcmlzaWduLmNvbSI+
PC9hPjxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzphZnJl
Z2x5QHZlcmlzaWduLmNvbSI+YWZyZWdseUB2ZXJpc2lnbi5jb208L2E+Jmd0Ozxicj4NCjxzcGFu
IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPiZxdW90OzxhIG1vei1kby1ub3Qt
c2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj48L2E+PGEgY2xhc3M9Im1v
ei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0
aEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0i
bWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4g
c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW09BVVRILVdHXSBC
dWlsZGluZyBvbiB0aGUgcHJvdG9jb2wgaW4gdGhlIGRyYWZ0IOKAnE9BdXRoIDIuMCBUb2tlbiBF
eGNoYW5nZTogQW4gU1RTIGZvciB0aGUgUkVTVCBvZiBVc+KAnSB0byBpbmNsdWRlIEF1dGhlbnRp
Y2F0aW9uIFRva2Vuczxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl
IGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxF
RlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MA0KICAgICAgICAg
IDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Vi
a2l0LW5ic3AtbW9kZTogc3BhY2U7DQogICAgICAgICAgICAgIC13ZWJraXQtbGluZS1icmVhazog
YWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkxvb2tpbmcgYXQgT3BlbklEIENvbm5lY3Qg
YW5kIGl04oCZcyB0cnVzdCBtb2RlbCBmb3IgcHJvZHVjaW5nIGlkX3Rva2VucyB0aGF0IGFzc2Vy
dCBpZGVudGl0eSBtYXkgaGVscCB5b3UuDQo8ZGl2IGNsYXNzPSIiPjxhIG1vei1kby1ub3Qtc2Vu
ZD0idHJ1ZSIgaHJlZj0iaHR0cDovL29wZW5pZC5uZXQvd2cvY29ubmVjdC8iIGNsYXNzPSIiPmh0
dHA6Ly9vcGVuaWQubmV0L3dnL2Nvbm5lY3QvPC9hPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9
IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlVuZm9ydHVuYXRlbHkgSSBj
YW7igJl0IHF1aXRlIG1ha2Ugb3V0IHdoYXQgeW91IGFyZSB0cnlpbmcgdG8gZG8uJm5ic3A7PC9k
aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5J
dCBzb3J0IG9mIHNvdW5kcyBsaWtlIHlvdSB3YW50IGFuIGlkX3Rva2VuIGZyb20gYSBpZFAgYW5k
IHRoZW4gaGF2ZSB0aGUgY2xpZW50IGV4Y2hhbmdlIHRoYXQgYXNzZXJ0aW9uIGZvciBhbm90aGVy
IHRva2VuPzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg
Y2xhc3M9IiI+Sm9obiBCLjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJj
aXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gQXByIDE5LCAyMDE2LCBhdCAxOjE4IFBN
LCBGcmVnbHksIEFuZHJldyAmbHQ7PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWls
dG86YWZyZWdseUB2ZXJpc2lnbi5jb20iIGNsYXNzPSIiPmFmcmVnbHlAdmVyaXNpZ24uY29tPC9h
PiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUi
Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z
LXNlcmlmOw0KICAgICAgICAgICAgICAgICAgICAgICAgICBmb250LXNpemU6IDE0cHg7IGZvbnQt
c3R5bGU6IG5vcm1hbDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgZm9udC12YXJpYW50LWNh
cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6DQogICAgICAgICAgICAgICAgICAgICAgICAgIG5vcm1h
bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7DQogICAgICAg
ICAgICAgICAgICAgICAgICAgIHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y
bWFsOw0KICAgICAgICAgICAgICAgICAgICAgICAgICB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu
ZzogMHB4Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAtd2Via2l0LXRleHQtc3Ryb2tlLXdp
ZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw
dDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt
aWx5OiBDYWxpYnJpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyIg
Y2xhc3M9IiI+SSBoYXZlIGEgdXNlIGNhc2Ugd2hlcmUgYSBjbGllbnQgYXBwbGljYXRpb24gbmVl
ZHMgdG8gYXV0aGVudGljYXRlIHdpdGggYSBkeW5hbWljYWxseSBkZXRlcm1pbmVkIElkZW50aXR5
IFByb3ZpZGVyIHRoYXQgaXMgc2VwYXJhdGUgZnJvbSB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2aWNl
IHRoYXQgd2lsbCBiZSB1c2VkIGlzc3VlIGFuIGFjY2VzcyB0b2tlbiB0byB0aGUgY2xpZW50Lg0K
IFRoZSB1c2UgY2FzZSBhbHNvIHJlcXVpcmVzIHRoYXQgYXMgcGFydCBvZiBhdXRob3JpemF0aW9u
LCB0aGUgY2xpZW50IHByb3ZpZGVzIHRvIHRoZSBBdXRob3JpemF0aW9uIFNlcnZpY2UgYW4gYXV0
aGVudGljYXRpb24gdG9rZW4gc2lnbmVkIGJ5IGFuIElkZW50aXR5IFByb3ZpZGVyIHRoYXQgdGhl
IEF1dGhvcml6YXRpb24gU2VydmljZSBoYXMgYSB0cnVzdCByZWxhdGlvbnNoaXAgd2l0aC4gVGhl
IHRydXN0IHJlbGF0aW9uc2hpcCBpcyB2ZXJpZmlhYmxlDQogYmFzZWQgb24gdGhlIEF1dGhvcml6
YXRpb24gU2VydmljZSBoYXZpbmcgcmVjb3JkZWQgdGhlIHB1YmxpYyBrZXlzIG9yIGNlcnRpZmlj
YXRlcyBvZiB0cnVzdGVkIElkZW50aXR5IFByb3ZpZGVycyBpbiBhIHRydXN0IHN0b3JlLCB0aGlz
IGFsbG93aW5nIHRoZSBBdXRob3JpemF0aW9uIFNlcnZpY2UgdG8gdmVyaWZ5IGFuIElkZW50aXR5
IFByb3ZpZGVy4oCZcyBzaWduYXR1cmUgb24gYW4gYXV0aGVudGljYXRpb24gdG9rZW4uPC9zcGFu
PjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgbmFtZT0iT0xFX0xJTks1IiBjbGFzcz0iIj48L2E+
PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7DQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogQ2FsaWJyaTsi
IGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp
bjogMGluIDBpbiAwLjAwMDFwdDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBmb250LXNp
emU6IDEycHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIi
PiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0
Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p
bHk6IENhbGlicmk7IiBjbGFzcz0iIj4NCkluIGxvb2tpbmcgYXQgdGhlIHZhcmlvdXMgT0F1dGgg
UkZDcywgcGFydGljdWxhcmx5IFJGQ3MgNzUyMSwgNzUyMiwgYW5kIDc1MjMsIEkgc2VlIHRoYXQg
dGhleSBnZXQgbWUgY2xvc2UgaW4gdGVybXMgb2Ygc3VwcG9ydGluZyB0aGUgdXNlIGNhc2UuIFdo
YXQgaXMgbWlzc2luZyBpcyBhIG1lYW5zIGZvciBzb2x2aW5nIHRoZSBmb2xsb3dpbmcgcHJvYmxl
bS4gVGhlc2UgUkZDcyByZXF1aXJlIHRoYXQgdGhlIElkZW50aXR5IFByb3ZpZGVyIHB1dCBhbg0K
IEF1ZGllbmNlIGNsYWltIGluIHRoZSBhdXRoZW50aWNhdGlvbiB0b2tlbi4gVGhlIHByb2JsZW0g
d2l0aCB0aGlzIGlzIHRoYXQgSSBkbyBub3Qgc2VlIGluIHRoZSBSRkNzIGhvdyB0aGUgSWRlbnRp
dHkgUHJvdmlkZXIgY2FuIGJlIHRvbGQgd2hvIHRoZSBBdWRpZW5jZSBpcyB0byBwdXQgaW50byB0
aGUgYXV0aGVudGljYXRpb24gdG9rZW4uIFRoaXMgbGVhZHMgbWUgdG8gdGhlIHRpdGxlIG9mIHRo
aXMgbWVzc2FnZS4gVGhlIGRyYWZ0IOKAnE9BdXRoDQogMi4wIFRva2VuIEV4Y2hhbmdlOiBBbiBT
VFMgZm9yIHRoZSBSRVNUIG9mIFVz4oCdIGRlZmluZXMgYSBtZWNoYW5pc20gZm9yIGlkZW50aWZ5
aW5nIHRoZSBBdWRpZW5jZSBmb3IgYW4gU1RTIHRvIHB1dCBpbnRvIGEgdG9rZW4gaXQgZ2VuZXJh
dGVzLiBUaGF0IHdvdWxkIHNvbHZlIG15IHByb2JsZW0gZXhjZXB0IHRoYXQgdGhlIGRyYWZ0IGxp
bWl0cyB0aGUgdHlwZSBvZiBTVFMgdG8gYmVpbmcgQXV0aG9yaXphdGlvbiBTZXJ2ZXJzLiBXaGF0
IGlzIG5lZWRlZA0KIGlzIHRoaXMgc2FtZSBjYXBhYmlsaXR5IGZvciBpbnRlcmFjdGluZyB3aXRo
IGFuIElkZW50aXR5IFByb3ZpZGVyLiBUaGlzIHdvdWxkIGVuYWJsZSBSRkNzIDc1MjEsIDc1MjIg
YW5kIDc1MjMgdG8gYmUgdXNlZnVsIGluIHNpdHVhdGlvbiB3aGVyZSB0aGUgSWRlbnRpdHkgUHJv
dmlkZXIgbmVlZHMgdG8gYmUgdG9sZCB0aGUgaWRlbnRpdHkgb2YgdGhlIEF1dGhvcml6YXRpb24g
U2VydmljZS48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw
aW4gMGluIDAuMDAwMXB0Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZvbnQtc2l6ZTog
MTJwdDsgZm9udC1mYW1pbHk6IENhbGlicmk7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5i
c3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog
Q2FsaWJyaTsiIGNsYXNzPSIiPg0KSSBhbSBuZXcgdG8gaW50ZXJhY3Rpbmcgd2l0aCB0aGUgSUVU
Ri4gSSBhbHNvIGFtIG5vdCBhbiBleHBlcnQgb24gdGhlIFJGQ3Mgb3IgcHJpb3IgaGlzdG9yeSBv
ZiB0aGUgT0F1dGggZ3JvdXAgcmVsYXRpdmUgdG8gdGhpcyB0b3BpYywgc28gcGxlYXNlIHBvaW50
IG1lIHRvIGFueSBleGlzdGluZyBzb2x1dGlvbiBpZiB0aGlzIGlzIGEgc29sdmVkIHByb2JsZW0u
IE90aGVyd2lzZSwgSSB3b3VsZCBsaWtlIHRvIGdldCBmZWVkYmFjayBvbiBteSBzdWdnZXN0aW9u
LjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g
MC4wMDAxcHQ7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgZm9udC1zaXplOiAxMnB0OyBm
b250LWZhbWlseTogQ2FsaWJyaTsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286
cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp
OyIgY2xhc3M9IiI+DQpUaGFua3MgWW91LDwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g
MGluIDAuMDAwMXB0Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZvbnQtc2l6ZTogMTJw
dDsgZm9udC1mYW1pbHk6IENhbGlicmk7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2
Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0Ow0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IENhbGlicmk7IiBjbGFz
cz0iIj4NCkFuZHJldyBGcmVnbHk8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHls
ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IENhbGlicmk7IiBjbGFzcz0iIj4NClZlcmlz
aWduIEluYy48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmks
IHNhbnMtc2VyaWY7DQogICAgICAgICAgICAgICAgICAgICAgICAgIGZvbnQtc2l6ZTogMTRweDsg
Zm9udC1zdHlsZTogbm9ybWFsOw0KICAgICAgICAgICAgICAgICAgICAgICAgICBmb250LXZhcmlh
bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOw0KICAgICAgICAg
ICAgICAgICAgICAgICAgICB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl
OiBub3JtYWw7DQogICAgICAgICAgICAgICAgICAgICAgICAgIHdpZG93czogYXV0bzsgd29yZC1z
cGFjaW5nOiAwcHg7DQogICAgICAgICAgICAgICAgICAgICAgICAgIC13ZWJraXQtdGV4dC1zdHJv
a2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPC9kaXY+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9y
bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5z
OiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv
cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5n
OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3Bs
YXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+X19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogQ2Fs
aWJyaSwgc2Fucy1zZXJpZjsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgZm9udC1zaXplOiAx
NHB4OyBmb250LXN0eWxlOiBub3JtYWw7DQogICAgICAgICAgICAgICAgICAgICAgICAgIGZvbnQt
dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0Og0KICAgICAgICAgICAgICAgICAgICAg
ICAgICBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87DQogICAg
ICAgICAgICAgICAgICAgICAgICAgIHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4
Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt
c3BhY2U6IG5vcm1hbDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgd2lkb3dzOiBhdXRvOyB3
b3JkLXNwYWNpbmc6IDBweDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgLXdlYmtpdC10ZXh0
LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFs
OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBh
dXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06
IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAw
cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6
IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+T0F1dGgNCiBtYWlsaW5nIGxpc3Q8L3NwYW4+
PGJyIHN0eWxlPSJmb250LWZhbWlseToNCiAgICAgICAgICAgICAgICAgICAgICAgICAgQ2FsaWJy
aSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4Ow0KICAgICAgICAgICAgICAgICAgICAgICAg
ICBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7DQogICAgICAg
ICAgICAgICAgICAgICAgICAgIGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu
b3JtYWw7DQogICAgICAgICAgICAgICAgICAgICAgICAgIG9ycGhhbnM6IGF1dG87IHRleHQtYWxp
Z246IHN0YXJ0OyB0ZXh0LWluZGVudDoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgMHB4OyB0
ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6DQogICAgICAgICAgICAgICAgICAgICAg
ICAgIG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+
DQo8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIg
c3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOw0KICAgICAgICAgICAgICAg
ICAgICAgICAgICBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6
DQogICAgICAgICAgICAgICAgICAgICAgICAgIG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h
bDsgb3JwaGFuczogYXV0bzsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgdGV4dC1hbGlnbjog
c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7DQogICAgICAgICAgICAgICAgICAgICAgICAgIHRleHQt
dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOw0KICAgICAgICAgICAgICAgICAg
ICAgICAgICB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4Ow0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5PQXV0
aEBpZXRmLm9yZzwvYT48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm
Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6
IG5vcm1hbDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgZm9udC12YXJpYW50LWNhcHM6IG5v
cm1hbDsgZm9udC13ZWlnaHQ6DQogICAgICAgICAgICAgICAgICAgICAgICAgIG5vcm1hbDsgbGV0
dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7DQogICAgICAgICAgICAg
ICAgICAgICAgICAgIHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOw0K
ICAgICAgICAgICAgICAgICAgICAgICAgICB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4
Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw
cHg7IiBjbGFzcz0iIj4NCjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0iaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgc3R5bGU9ImZvbnQtZmFtaWx5OiBD
YWxpYnJpLCBzYW5zLXNlcmlmOw0KICAgICAgICAgICAgICAgICAgICAgICAgICBmb250LXNpemU6
IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgZm9u
dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6DQogICAgICAgICAgICAgICAgICAg
ICAgICAgIG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw
cHg7DQogICAgICAgICAgICAgICAgICAgICAgICAgIHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0
ZS1zcGFjZTogbm9ybWFsOw0KICAgICAgICAgICAgICAgICAgICAgICAgICB3aWRvd3M6IGF1dG87
IHdvcmQtc3BhY2luZzogMHB4Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAtd2Via2l0LXRl
eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL29hdXRoPC9hPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIg
Y2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N
Cjwvc3Bhbj48YnI+DQo8ZmllbGRzZXQgY2xhc3M9Im1pbWVBdHRhY2htZW50SGVhZGVyIj48L2Zp
ZWxkc2V0PiA8YnI+DQo8cHJlIHdyYXA9IiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KPGEgY2xhc3M9Im1vei10eHQt
bGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRm
Lm9yZzwvYT48YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPGJyPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_6101D0EBE04B45748899ED8F4E631D67verisigncom_--


From nobody Tue Apr 19 14:07:59 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB33D12E6EE for ; Tue, 19 Apr 2016 14:07:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MegzCyPl68Vb for ; Tue, 19 Apr 2016 14:07:53 -0700 (PDT)
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 910F912E6A3 for ; Tue, 19 Apr 2016 14:07:53 -0700 (PDT)
Received: by mail-qg0-x264.google.com with SMTP id 7so2913584qgj.3 for ; Tue, 19 Apr 2016 14:07:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language:user-agent :mime-version; bh=/jIoToO5c5umbUe0HrC4cBwlrV19aUyWTLJuTNztHqs=; b=yY+ltFjZn/kHYWa6UQilEI/X4fmFwCjR4VR751DPlpGEIgd955Rb9OX4eaPtJTZ5fN UcmA3ZezITYktU+8GEM4G/f7VKD5UYB+ZQeNTevyhAvVwgs7n6sQ+ecYLKgtpphJKPwS 5NuUn/Sjgiq1g+yuvTCBp6CFR/o+fEWC3OfqCbSqdlbY+IBmnaSn+Os0CqvSGvyP683U 9lWfehetCvgL5Hoe6ENoRc/Pkml+BFsMkm/JvKlGb+5Y2E2E82q/jINKDaPSyMw5Q1iI UK+zQckeLFT3iA7FJDLpHpHuWjHkmSmVYaRggtXquKda6nEX7rees8Gt40YdKIyb8wP2 hQ4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:user-agent:mime-version; bh=/jIoToO5c5umbUe0HrC4cBwlrV19aUyWTLJuTNztHqs=; b=LSH+ETpjdfKS1TzjTVJgePS8RUNa4gx7jmE30lKZFb/KYriIWfvyKd4Wjc/6bE3kOR waKD2Z++axRUiIZecxsmvn3BNGyn2V4TtcpePQXxKr/zIdooXs4nvkyIrb0LZS5gDttJ U5KgmyPoPP1rKgFlFeLYCgni0XvWWhl2/ZpZz3IzAWHIj34to3jhFuNuw0C76g3Ta0fT nNxXhoPY2bhS1A+VvrRXPMbfZFa1FISoNJEUUbU2VRty66f7Ct6QIDHPCBrsFOlrZTsy inDLZUc2vpy6UzoGeVIjU8eN7Whqa3PM2UKUwW3AHRiH7SzElh+bx4+CTy4UaLF5m1oI M+Dw==
X-Gm-Message-State: AOPr4FX11H5+QHVROPO4WMar7/NJgczSC5y2va+C4eFGp+g014RLNoVV69Pa9H84f/aWz6IAnfUSSyhU/VeFO+KYJ3boaXjg
X-Received: by 10.140.157.16 with SMTP id d16mr6741005qhd.89.1461100072500; Tue, 19 Apr 2016 14:07:52 -0700 (PDT)
Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id v131sm8982890qka.10.2016.04.19.14.07.52 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 19 Apr 2016 14:07:52 -0700 (PDT)
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 u3JL7peL010050 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Apr 2016 17:07:52 -0400
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 19 Apr 2016 17:07:49 -0400
From: "Fregly, Andrew" 
To: John Bradley 
Thread-Topic: =?utf-8?B?W09BVVRILVdHXSBCdWlsZGluZyBvbiB0aGUgcHJvdG9jb2wgaW4gdGhlIGRy?= =?utf-8?B?YWZ0IOKAnE9BdXRoICAyLjAgVG9rZW4gRXhjaGFuZ2U6IEFuIFNUUyBmb3Ig?= =?utf-8?B?dGhlIFJFU1Qgb2YgVXPigJ0gdG8gaW5jbHVkZSBBdXRoZW50aWNhdGlvbiBU?= =?utf-8?Q?okens?=
Thread-Index: AQHRmlcomE8l0QoCm0C5ZCXr0BuVz5+R2qyA///eO4CAAEkiAP//yFeA
Date: Tue, 19 Apr 2016 21:07:48 +0000
Message-ID: <621AAD5E-FD50-4A2D-8B4C-2A10431FA55C@verisign.com>
References:   <8B748252-9AE2-4824-923B-00CD46CB8D68@verisign.com> <4382930D-CADD-466A-B078-B121B8E894E5@ve7jtb.com>
In-Reply-To: <4382930D-CADD-466A-B078-B121B8E894E5@ve7jtb.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.160212
x-originating-ip: [10.173.152.4]
Content-Type: multipart/alternative; boundary="_000_621AAD5EFD504A2D8B4C2A10431FA55Cverisigncom_"
MIME-Version: 1.0
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] =?utf-8?q?Building_on_the_protocol_in_the_draft_?= =?utf-8?q?=E2=80=9COAuth__2=2E0_Token_Exchange=3A_An_STS_for_the_REST_of_?= =?utf-8?q?Us=E2=80=9D_to_include_Authentication_Tokens?=
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Apr 2016 21:07:56 -0000

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

VGhhbmtzIEpvaG4hIEkgd2lsbCBwcm92aWRlIGEgZGlhZ3JhbSB0b21vcnJvdy4NCg0KQW5keQ0K
DQpGcm9tOiBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3
anRiLmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBBcHJpbCAxOSwgMjAxNiBhdCA0OjI3IFBNDQpUbzog
QW5kcmV3IEZyZWdseSA8YWZyZWdseUB2ZXJpc2lnbi5jb208bWFpbHRvOmFmcmVnbHlAdmVyaXNp
Z24uY29tPj4NCkNjOiAib2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPiIgPG9h
dXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRI
LVdHXSBCdWlsZGluZyBvbiB0aGUgcHJvdG9jb2wgaW4gdGhlIGRyYWZ0IOKAnE9BdXRoIDIuMCBU
b2tlbiBFeGNoYW5nZTogQW4gU1RTIGZvciB0aGUgUkVTVCBvZiBVc+KAnSB0byBpbmNsdWRlIEF1
dGhlbnRpY2F0aW9uIFRva2Vucw0KDQpZb3UgY2FuIHVzZSBjb25uZWN0IGp1c3QgYXMgYSBhdXRo
ZW50aWNhdGlvbiBzZXJ2aWNlIGFzIHlvdSB3b3VsZCBTQU1MLg0KDQpMb3RzIG9mIFNhYVMgcHJv
dmlkZXJzIGhhdmUgYSBhdXRob3JpemF0aW9uIHNlcnZpY2UgdGhhdCBjaGFpbnMgdG8gYSBleHRl
cm5hbCBhdXRoZW50aWNhdGlvbiBzZXJ2aWNlIHZpYSBTQU1MIG9yIENvbm5lY3QgYnkgdXNlIG9m
IGEgYnJvd3Nlci4NCg0KSSBhbSBub3QgZ2V0dGluZyB3aGF0IGlzIGZyb250IGNoYW5uZWwgd2l0
aCB0aGUgdXNlciBhbmQgd2hhdCBpcyBiYWNrIGNoYW5uZWwuDQoNCklzIHRoZSB1c2VyIGF1dGhl
bnRpY2F0aW5nIHdpdGggdGhlIHNlcnZpY2UgdGhhdCBwcm92aWRlcyB0aGUgcm9sZSBpbmZvLCBv
ciBhcmUgeW91IHRyeWluZyB0byBkbyB0aGF0IGluIHRoZSBiYWNrIGNoYW5uZWwgdmlhIGEgdG9r
ZW4gZXhjaGFuZ2UuDQoNCkkgcHJvYmFibHkgbmVlZCBhIGRpYWdyYW0uDQoNCkpvaG4gQi4NCk9u
IEFwciAxOSwgMjAxNiwgYXQgNTowNSBQTSwgRnJlZ2x5LCBBbmRyZXcgPGFmcmVnbHlAdmVyaXNp
Z24uY29tPG1haWx0bzphZnJlZ2x5QHZlcmlzaWduLmNvbT4+IHdyb3RlOg0KDQpUaGFua3MgZm9y
IHlvdXIgcmVzcG9uc2UgSm9obi4gSSBhbHNvIGdvdCBhIGdvb2QgcmVzcG9uc2UgZnJvbSBCcmlh
biBDYW1wYmVsbCBhbmQgYXBwcmVjaWF0ZSB0aGF0LiBJIHdpbGwgcmVzcG9uZCBzZXBhcmF0ZWx5
IHRvIEJyaWFu4oCZcyByZXNwb25zZSBhcyBJIHRoaW5rIGl0IHdvdWxkIGtlZXAgdGhpbmdzIGNs
ZWFyZXIgdG8gZG8gdGhhdC4NCg0KVGhlIHByb2JsZW0gd2UgaGF2ZSBmb3IgdXNpbmcgT3BlbklE
IENvbm5lY3QgaXMgdGhhdCBpdCBjb21iaW5lcyB0aGUgcm9sZSBvZiBBdXRoZW50aWNhdGlvbiBT
ZXJ2aWNlIHdpdGggdGhlIHJvbGUgb2YgQXV0aG9yaXphdGlvbiBTZXJ2aWNlLiBQZXJoYXBzIHRo
ZSBmb2xsb3dpbmcgZGVzY3JpcHRpb24gb2Ygd2hhdCB3ZSB3YW50IHRvIGRvIHdpbGwgY2xhcmlm
eSB3aHkgdGhpcyB3b27igJl0IHdvcmsgZm9yIHVzOg0KDQpUaGUgYmFzaWMgcHJvYmxlbSBzdGF0
ZW1lbnQgaXMgdGhhdCB3ZSBuZWVkIHRvIGhhdmUgYSBjbGllbnQgYXBwbGljYXRpb24gYXV0aG9y
aXplZCBieSBhIFNlcnZpY2UgUHJvdmlkZXIgYmFzZWQgb24gcHJvb2YgdGhhdCBhIHVzZXIgaXMg
Y3VycmVudGx5IGEgbWVtYmVyIG9mIHNvbWUgb3JnYW5pemF0aW9uLiBUaGlzIGFzc3VtZXMgdGhl
IG9yZ2FuaXphdGlvbiBoYXMgcHJldmlvdXNseSBlc3RhYmxpc2hlZCBzb21lIGxldmVsIG9mIGF1
dGhvcml6ZWQgYWNjZXNzIHdpdGggdGhlIFNlcnZpY2UgUHJvdmlkZXIuDQoNCkhlcmUgaXMgYW4g
ZXhhbXBsZTogU3VwcG9zZSBJIGFtIGEgbWVtYmVyIG9mIFNvbWVPcmcgSW5jLiBTdXBwb3NlIFNv
bWVPcmcgSW5jLiBpcyBkb2luZyByZXNlYXJjaCB0aGF0IHJlcXVpcmVzIGl0IHRvIGdhdGhlciBk
YXRhIG92ZXIgdGhlIEludGVybmV0IGZyb20gYSBudW1iZXIgb2YgZGF0YSBwcm92aWRlcnMuIFRo
ZSBkYXRhIHByb3ZpZGVycyByZXF1aXJlIGF1dGhlbnRpY2F0aW9uIGFuZCBwcm9vZiBvZiBvcmdh
bml6YXRpb25hbCBtZW1iZXJzaGlwIGluIG9yZGVyIHRvIGF1dGhvcml6ZSB2YXJpb3VzIGxldmVs
cyBvZiBhY2Nlc3MgdG8gdGhlaXIgZGF0YS4gVGhlIGRhdGEgcHJvdmlkZXJzIGRvIG5vdCBjb25z
aWRlciBoYXZpbmcgYW4gYWNjb3VudCB3aXRoIHRoZW0gb3IgYSBQdWJsaWMgSWRlbnRpdHkgUHJv
dmlkZXIgdG8gYmUgc3VpdGFibGUgZm9yIHByb3ZpbmcgdGhhdCBJIGFtIHN0aWxsIGEgbWVtYmVy
IG9mIFNvbWVPcmcgYXQgdGltZSBvZiBhdXRoZW50aWNhdGlvbi4gVGhleSB3b3VsZCBoYXZlIG5v
IHdheSBvZiBrbm93aW5nIHdoZXRoZXIgb3Igbm90IG15IHJlbGF0aW9uc2hpcCB3aXRoIFNvbWVP
cmcgc3RpbGwgZXhpc3RzIGF0IHRoYXQgdGltZS4gVGhlIGRhdGEgcHJvdmlkZXJzIHdvdWxkIHRo
ZXJlZm9yZSBsaWtlIHRoZSBDbGllbnQgc29mdHdhcmUgdG8gYXV0aGVudGljYXRlIG1lIGFnYWlu
c3QgU29tZU9yZ3MgSWRlbnRpdHkgUHJvdmlkZXIuIFRoaXMgd291bGQgYmUgZ29vZCBwcm9vZiB0
aGF0IEkgYW0gc3RpbGwgYSBtZW1iZXIgb2YgU29tZU9yZyBhdCB0aGUgdGltZSBJIGF1dGhlbnRp
Y2F0ZS4gVGhpcyBhdXRoZW50aWNhdGlvbiB3b3VsZCBlbmFibGUgdGhlIGRhdGEgcHJvdmlkZXJz
IEF1dGhvcml6YXRpb24gU2VydmVyIHRvIGdyYW50IG1lIGFjY2VzcyBhcHByb3ByaWF0ZSB0byBh
IG1lbWJlciBvZiBTb21lT3JnLiAgTm90ZSB0aGF0IGFzIGEgcHJlcmVxdWlzaXRlIHRvIGFsbCBv
ZiB0aGlzLCBTb21lT3JnIHdpbGwgaGF2ZSB1c2VkIGFuIG91dC1vZi1iYW5kIHByb2Nlc3MgdG8g
c2V0IHVwIGEgdHJ1c3QgcmVsYXRpb25zaGlwIGZvciBTb21lT3JnJ3MgSWRlbnRpdHkgUHJvdmlk
ZXIgd2l0aCB0aGUgZGF0YSBwcm92aWRlcuKAmXMgQXV0aG9yaXphdGlvbiBTZXJ2aWNlLCBhbmQg
d2lsbCBoYXZlIG5lZ290aWF0ZWQgYXV0aG9yaXphdGlvbiBjbGFpbXMgdG8gYmUgZ3JhbnRlZCB0
byBTb21lT3JncyBtZW1iZXJzLg0KDQpXaGF0IEkgYW0gaGF2aW5nIGRpZmZpY3VsdHkgd2l0aCBp
cyBpbiBrbml0dGluZyB0b2dldGhlciBhbiBhcHByb2FjaCBiYXNlZCBvbiB0aGUgaGUgT3BlbklE
IENvbm5lY3Qgc3BlY2lmaWNhdGlvbnMsIFNBTUwgc3BlY2lmaWNhdGlvbnMsIGFuZCBPQXV0aCBS
RkNzIGFuZCBkcmFmdHMgaW4gYSB3YXkgdGhhdCBzdXBwb3J0cyB0aGUgYWJvdmUgdXNlIGNhc2Ug
ZW5kLXRvLWVuZC4gVGhlIE9BdXRoIFJGQ3MgYW5kIGRyYWZ0cyBhbG1vc3QgZ2V0IG1lIHRoZXJl
LiBXaGF0IHNlZW1zIHRvIGJlIG1pc3NpbmcgaXMgYSB3YXkgb2YgdGVsbGluZyBhbiBJZGVudGl0
eSBQcm92aWRlciB0aGUgVVJMIGZvciB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2aWNlICh0aGUgcmVx
dWlyZWQgQXVkaWVuY2UgY2xhaW0gaW4gYW4gYXV0aGVudGljYXRpb24gYXNzZXJ0aW9uIGFzIGRl
ZmluZWQgaW4gUkZDcyA3MjUxLCA3MjUyIGFuZCA3MjUzKSwgYW5kIHRoZW4gYSByZXF1aXJlbWVu
dCB0aGF0IHRoZSBJZGVudGl0eSBQcm92aWRlcnMgcHV0IHRoZSBzdXBwbGllZCBBdWRpZW5jZSBJ
ZGVudGlmaWVyIGludG8gQXV0aGVudGljYXRpb24gVG9rZW5zLiBQZXJoYXBzIGEgbGl0dGxlIGZ1
cnRoZXIgYmFjay1hbmQtZm9ydGggd2l0aCBCcmlhbiB3aWxsIHJlc29sdmUgdGhpcy4NCg0KSSBj
YW4gZ28gaW50byBkZWVwZXIgZGV0YWlsIGlmIG5lZWRlZC4gSWYgdGhpcyBpcyBvZmYtdG9waWMg
Zm9yIHRoZSBPQXV0aCB3b3JraW5nIGdyb3VwLCBsZXQgbWUga25vdy4NCg0KVGhhbmtzLA0KQW5k
cmV3IEZyZWdseQ0KVmVyaXNpZ24gSW5jLg0KDQoNCkZyb206IEpvaG4gQnJhZGxleSA8dmU3anRi
QHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4NCkRhdGU6IFR1ZXNkYXksIEFw
cmlsIDE5LCAyMDE2IGF0IDI6MDYgUE0NClRvOiBBbmRyZXcgRnJlZ2x5IDxhZnJlZ2x5QHZlcmlz
aWduLmNvbTxtYWlsdG86YWZyZWdseUB2ZXJpc2lnbi5jb20+Pg0KQ2M6ICJvYXV0aEBpZXRmLm9y
ZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGll
dGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEJ1aWxkaW5nIG9uIHRoZSBwcm90b2Nv
bCBpbiB0aGUgZHJhZnQg4oCcT0F1dGggMi4wIFRva2VuIEV4Y2hhbmdlOiBBbiBTVFMgZm9yIHRo
ZSBSRVNUIG9mIFVz4oCdIHRvIGluY2x1ZGUgQXV0aGVudGljYXRpb24gVG9rZW5zDQoNCkxvb2tp
bmcgYXQgT3BlbklEIENvbm5lY3QgYW5kIGl04oCZcyB0cnVzdCBtb2RlbCBmb3IgcHJvZHVjaW5n
IGlkX3Rva2VucyB0aGF0IGFzc2VydCBpZGVudGl0eSBtYXkgaGVscCB5b3UuDQpodHRwOi8vb3Bl
bmlkLm5ldC93Zy9jb25uZWN0Lw0KDQpVbmZvcnR1bmF0ZWx5IEkgY2Fu4oCZdCBxdWl0ZSBtYWtl
IG91dCB3aGF0IHlvdSBhcmUgdHJ5aW5nIHRvIGRvLg0KDQpJdCBzb3J0IG9mIHNvdW5kcyBsaWtl
IHlvdSB3YW50IGFuIGlkX3Rva2VuIGZyb20gYSBpZFAgYW5kIHRoZW4gaGF2ZSB0aGUgY2xpZW50
IGV4Y2hhbmdlIHRoYXQgYXNzZXJ0aW9uIGZvciBhbm90aGVyIHRva2VuPw0KDQpKb2huIEIuDQpP
biBBcHIgMTksIDIwMTYsIGF0IDE6MTggUE0sIEZyZWdseSwgQW5kcmV3IDxhZnJlZ2x5QHZlcmlz
aWduLmNvbTxtYWlsdG86YWZyZWdseUB2ZXJpc2lnbi5jb20+PiB3cm90ZToNCg0KSSBoYXZlIGEg
dXNlIGNhc2Ugd2hlcmUgYSBjbGllbnQgYXBwbGljYXRpb24gbmVlZHMgdG8gYXV0aGVudGljYXRl
IHdpdGggYSBkeW5hbWljYWxseSBkZXRlcm1pbmVkIElkZW50aXR5IFByb3ZpZGVyIHRoYXQgaXMg
c2VwYXJhdGUgZnJvbSB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2aWNlIHRoYXQgd2lsbCBiZSB1c2Vk
IGlzc3VlIGFuIGFjY2VzcyB0b2tlbiB0byB0aGUgY2xpZW50LiBUaGUgdXNlIGNhc2UgYWxzbyBy
ZXF1aXJlcyB0aGF0IGFzIHBhcnQgb2YgYXV0aG9yaXphdGlvbiwgdGhlIGNsaWVudCBwcm92aWRl
cyB0byB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2aWNlIGFuIGF1dGhlbnRpY2F0aW9uIHRva2VuIHNp
Z25lZCBieSBhbiBJZGVudGl0eSBQcm92aWRlciB0aGF0IHRoZSBBdXRob3JpemF0aW9uIFNlcnZp
Y2UgaGFzIGEgdHJ1c3QgcmVsYXRpb25zaGlwIHdpdGguIFRoZSB0cnVzdCByZWxhdGlvbnNoaXAg
aXMgdmVyaWZpYWJsZSBiYXNlZCBvbiB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2aWNlIGhhdmluZyBy
ZWNvcmRlZCB0aGUgcHVibGljIGtleXMgb3IgY2VydGlmaWNhdGVzIG9mIHRydXN0ZWQgSWRlbnRp
dHkgUHJvdmlkZXJzIGluIGEgdHJ1c3Qgc3RvcmUsIHRoaXMgYWxsb3dpbmcgdGhlIEF1dGhvcml6
YXRpb24gU2VydmljZSB0byB2ZXJpZnkgYW4gSWRlbnRpdHkgUHJvdmlkZXLigJlzIHNpZ25hdHVy
ZSBvbiBhbiBhdXRoZW50aWNhdGlvbiB0b2tlbi4NCg0KSW4gbG9va2luZyBhdCB0aGUgdmFyaW91
cyBPQXV0aCBSRkNzLCBwYXJ0aWN1bGFybHkgUkZDcyA3NTIxLCA3NTIyLCBhbmQgNzUyMywgSSBz
ZWUgdGhhdCB0aGV5IGdldCBtZSBjbG9zZSBpbiB0ZXJtcyBvZiBzdXBwb3J0aW5nIHRoZSB1c2Ug
Y2FzZS4gV2hhdCBpcyBtaXNzaW5nIGlzIGEgbWVhbnMgZm9yIHNvbHZpbmcgdGhlIGZvbGxvd2lu
ZyBwcm9ibGVtLiBUaGVzZSBSRkNzIHJlcXVpcmUgdGhhdCB0aGUgSWRlbnRpdHkgUHJvdmlkZXIg
cHV0IGFuIEF1ZGllbmNlIGNsYWltIGluIHRoZSBhdXRoZW50aWNhdGlvbiB0b2tlbi4gVGhlIHBy
b2JsZW0gd2l0aCB0aGlzIGlzIHRoYXQgSSBkbyBub3Qgc2VlIGluIHRoZSBSRkNzIGhvdyB0aGUg
SWRlbnRpdHkgUHJvdmlkZXIgY2FuIGJlIHRvbGQgd2hvIHRoZSBBdWRpZW5jZSBpcyB0byBwdXQg
aW50byB0aGUgYXV0aGVudGljYXRpb24gdG9rZW4uIFRoaXMgbGVhZHMgbWUgdG8gdGhlIHRpdGxl
IG9mIHRoaXMgbWVzc2FnZS4gVGhlIGRyYWZ0IOKAnE9BdXRoIDIuMCBUb2tlbiBFeGNoYW5nZTog
QW4gU1RTIGZvciB0aGUgUkVTVCBvZiBVc+KAnSBkZWZpbmVzIGEgbWVjaGFuaXNtIGZvciBpZGVu
dGlmeWluZyB0aGUgQXVkaWVuY2UgZm9yIGFuIFNUUyB0byBwdXQgaW50byBhIHRva2VuIGl0IGdl
bmVyYXRlcy4gVGhhdCB3b3VsZCBzb2x2ZSBteSBwcm9ibGVtIGV4Y2VwdCB0aGF0IHRoZSBkcmFm
dCBsaW1pdHMgdGhlIHR5cGUgb2YgU1RTIHRvIGJlaW5nIEF1dGhvcml6YXRpb24gU2VydmVycy4g
V2hhdCBpcyBuZWVkZWQgaXMgdGhpcyBzYW1lIGNhcGFiaWxpdHkgZm9yIGludGVyYWN0aW5nIHdp
dGggYW4gSWRlbnRpdHkgUHJvdmlkZXIuIFRoaXMgd291bGQgZW5hYmxlIFJGQ3MgNzUyMSwgNzUy
MiBhbmQgNzUyMyB0byBiZSB1c2VmdWwgaW4gc2l0dWF0aW9uIHdoZXJlIHRoZSBJZGVudGl0eSBQ
cm92aWRlciBuZWVkcyB0byBiZSB0b2xkIHRoZSBpZGVudGl0eSBvZiB0aGUgQXV0aG9yaXphdGlv
biBTZXJ2aWNlLg0KDQpJIGFtIG5ldyB0byBpbnRlcmFjdGluZyB3aXRoIHRoZSBJRVRGLiBJIGFs
c28gYW0gbm90IGFuIGV4cGVydCBvbiB0aGUgUkZDcyBvciBwcmlvciBoaXN0b3J5IG9mIHRoZSBP
QXV0aCBncm91cCByZWxhdGl2ZSB0byB0aGlzIHRvcGljLCBzbyBwbGVhc2UgcG9pbnQgbWUgdG8g
YW55IGV4aXN0aW5nIHNvbHV0aW9uIGlmIHRoaXMgaXMgYSBzb2x2ZWQgcHJvYmxlbS4gT3RoZXJ3
aXNlLCBJIHdvdWxkIGxpa2UgdG8gZ2V0IGZlZWRiYWNrIG9uIG15IHN1Z2dlc3Rpb24uDQoNClRo
YW5rcyBZb3UsDQoNCkFuZHJldyBGcmVnbHkNClZlcmlzaWduIEluYy4NCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9B
dXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQo=

--_000_621AAD5EFD504A2D8B4C2A10431FA55Cverisigncom_
Content-Type: text/html; charset="utf-8"
Content-ID: <1E399C27663C00458DF510583F6E8FC1@verisign.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8
ZGl2PlRoYW5rcyBKb2huISBJIHdpbGwgcHJvdmlkZSBhIGRpYWdyYW0gdG9tb3Jyb3cuPC9kaXY+
DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5BbmR5PC9kaXY+DQo8ZGl2Pg0KPGRpdiBpZD0iTUFD
X09VVExPT0tfU0lHTkFUVVJFIj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHls
ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjEycHQ7IHRleHQtYWxpZ246bGVmdDsg
Y29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVk
aXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5H
LVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6
IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo
dDpib2xkIj5Gcm9tOiA8L3NwYW4+Sm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3
anRiQHZlN2p0Yi5jb20iPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHls
ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPlR1ZXNkYXksIEFwcmlsIDE5LCAyMDE2
IGF0IDQ6MjcgUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bh
bj5BbmRyZXcgRnJlZ2x5ICZsdDs8YSBocmVmPSJtYWlsdG86YWZyZWdseUB2ZXJpc2lnbi5jb20i
PmFmcmVnbHlAdmVyaXNpZ24uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln
aHQ6Ym9sZCI+Q2M6IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmci
Pm9hdXRoQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYu
b3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0
OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW09BVVRILVdHXSBCdWlsZGluZyBvbiB0aGUgcHJv
dG9jb2wgaW4gdGhlIGRyYWZ0IOKAnE9BdXRoIDIuMCBUb2tlbiBFeGNoYW5nZTogQW4gU1RTIGZv
ciB0aGUgUkVTVCBvZiBVc+KAnSB0byBpbmNsdWRlIEF1dGhlbnRpY2F0aW9uIFRva2Vuczxicj4N
CjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19B
VFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xp
ZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXYgc3R5bGU9
IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0
LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQpZb3UgY2FuIHVzZSBj
b25uZWN0IGp1c3QgYXMgYSBhdXRoZW50aWNhdGlvbiBzZXJ2aWNlIGFzIHlvdSB3b3VsZCBTQU1M
Lg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+TG90
cyBvZiBTYWFTIHByb3ZpZGVycyBoYXZlIGEgYXV0aG9yaXphdGlvbiBzZXJ2aWNlIHRoYXQgY2hh
aW5zIHRvIGEgZXh0ZXJuYWwgYXV0aGVudGljYXRpb24gc2VydmljZSB2aWEgU0FNTCBvciBDb25u
ZWN0IGJ5IHVzZSBvZiBhIGJyb3dzZXIuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i
Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGFtIG5vdCBnZXR0aW5nIHdoYXQgaXMgZnJvbnQg
Y2hhbm5lbCB3aXRoIHRoZSB1c2VyIGFuZCB3aGF0IGlzIGJhY2sgY2hhbm5lbC48L2Rpdj4NCjxk
aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPklzIHRoZSB1
c2VyIGF1dGhlbnRpY2F0aW5nIHdpdGggdGhlIHNlcnZpY2UgdGhhdCBwcm92aWRlcyB0aGUgcm9s
ZSBpbmZvLCBvciBhcmUgeW91IHRyeWluZyB0byBkbyB0aGF0IGluIHRoZSBiYWNrIGNoYW5uZWwg
dmlhIGEgdG9rZW4gZXhjaGFuZ2UuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N
CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIHByb2JhYmx5IG5lZWQgYSBkaWFncmFtLjwvZGl2Pg0K
PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Sm9obiBC
LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBj
bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gQXByIDE5LCAyMDE2LCBhdCA1OjA1IFBNLCBGcmVn
bHksIEFuZHJldyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFmcmVnbHlAdmVyaXNpZ24uY29tIiBjbGFz
cz0iIj5hZnJlZ2x5QHZlcmlzaWduLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNz
PSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl
PSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtp
dC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZh
bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxk
aXYgY2xhc3M9IiI+VGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlIEpvaG4uIEkgYWxzbyBnb3QgYSBn
b29kIHJlc3BvbnNlIGZyb20gQnJpYW4gQ2FtcGJlbGwgYW5kIGFwcHJlY2lhdGUgdGhhdC4gSSB3
aWxsIHJlc3BvbmQgc2VwYXJhdGVseSB0byBCcmlhbuKAmXMgcmVzcG9uc2UgYXMgSSB0aGluayBp
dCB3b3VsZCBrZWVwIHRoaW5ncyBjbGVhcmVyIHRvIGRvIHRoYXQuPC9kaXY+DQo8ZGl2IGNsYXNz
PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGUgcHJvYmxlbSB3ZSBo
YXZlIGZvciB1c2luZyBPcGVuSUQgQ29ubmVjdCBpcyB0aGF0IGl0IGNvbWJpbmVzIHRoZSByb2xl
IG9mIEF1dGhlbnRpY2F0aW9uIFNlcnZpY2Ugd2l0aCB0aGUgcm9sZSBvZiBBdXRob3JpemF0aW9u
IFNlcnZpY2UuIFBlcmhhcHMgdGhlIGZvbGxvd2luZyBkZXNjcmlwdGlvbiBvZiB3aGF0IHdlIHdh
bnQgdG8gZG8gd2lsbCBjbGFyaWZ5IHdoeSB0aGlzIHdvbuKAmXQgd29yayBmb3IgdXM6PC9kaXY+
DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGUg
YmFzaWMgcHJvYmxlbSBzdGF0ZW1lbnQgaXMgdGhhdCB3ZSBuZWVkIHRvIGhhdmUgYSBjbGllbnQg
YXBwbGljYXRpb24gYXV0aG9yaXplZCBieSBhIFNlcnZpY2UgUHJvdmlkZXIgYmFzZWQgb24gcHJv
b2YgdGhhdCBhIHVzZXIgaXMgY3VycmVudGx5IGEgbWVtYmVyIG9mIHNvbWUgb3JnYW5pemF0aW9u
LiBUaGlzIGFzc3VtZXMgdGhlIG9yZ2FuaXphdGlvbiBoYXMgcHJldmlvdXNseSBlc3RhYmxpc2hl
ZCBzb21lIGxldmVsDQogb2YgYXV0aG9yaXplZCBhY2Nlc3Mgd2l0aCB0aGUgU2VydmljZSBQcm92
aWRlci4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8
ZGl2IGNsYXNzPSIiPkhlcmUgaXMgYW4gZXhhbXBsZTogU3VwcG9zZSBJIGFtIGEgbWVtYmVyIG9m
IFNvbWVPcmcgSW5jLiBTdXBwb3NlIFNvbWVPcmcgSW5jLiBpcyBkb2luZyByZXNlYXJjaCB0aGF0
IHJlcXVpcmVzIGl0IHRvIGdhdGhlciBkYXRhIG92ZXIgdGhlIEludGVybmV0IGZyb20gYSBudW1i
ZXIgb2YgZGF0YSBwcm92aWRlcnMuIFRoZSBkYXRhIHByb3ZpZGVycyByZXF1aXJlIGF1dGhlbnRp
Y2F0aW9uIGFuZCBwcm9vZiBvZiBvcmdhbml6YXRpb25hbA0KIG1lbWJlcnNoaXAgaW4gb3JkZXIg
dG8gYXV0aG9yaXplIHZhcmlvdXMgbGV2ZWxzIG9mIGFjY2VzcyB0byB0aGVpciBkYXRhLiBUaGUg
ZGF0YSBwcm92aWRlcnMgZG8gbm90IGNvbnNpZGVyIGhhdmluZyBhbiBhY2NvdW50IHdpdGggdGhl
bSBvciBhIFB1YmxpYyBJZGVudGl0eSBQcm92aWRlciB0byBiZSBzdWl0YWJsZSBmb3IgcHJvdmlu
ZyB0aGF0IEkgYW0gc3RpbGwgYSBtZW1iZXIgb2YgU29tZU9yZyBhdCB0aW1lIG9mIGF1dGhlbnRp
Y2F0aW9uLg0KIFRoZXkgd291bGQgaGF2ZSBubyB3YXkgb2Yga25vd2luZyB3aGV0aGVyIG9yIG5v
dCBteSByZWxhdGlvbnNoaXAgd2l0aCBTb21lT3JnIHN0aWxsIGV4aXN0cyBhdCB0aGF0IHRpbWUu
IFRoZSBkYXRhIHByb3ZpZGVycyB3b3VsZCB0aGVyZWZvcmUgbGlrZSB0aGUgQ2xpZW50IHNvZnR3
YXJlIHRvIGF1dGhlbnRpY2F0ZSBtZSBhZ2FpbnN0IFNvbWVPcmdzIElkZW50aXR5IFByb3ZpZGVy
LiBUaGlzIHdvdWxkIGJlIGdvb2QgcHJvb2YgdGhhdCBJIGFtIHN0aWxsDQogYSBtZW1iZXIgb2Yg
U29tZU9yZyBhdCB0aGUgdGltZSBJIGF1dGhlbnRpY2F0ZS4gVGhpcyBhdXRoZW50aWNhdGlvbiB3
b3VsZCBlbmFibGUgdGhlIGRhdGEgcHJvdmlkZXJzIEF1dGhvcml6YXRpb24gU2VydmVyIHRvIGdy
YW50IG1lIGFjY2VzcyBhcHByb3ByaWF0ZSB0byBhIG1lbWJlciBvZiBTb21lT3JnLiAmbmJzcDtO
b3RlIHRoYXQgYXMgYSBwcmVyZXF1aXNpdGUgdG8gYWxsIG9mIHRoaXMsIFNvbWVPcmcgd2lsbCBo
YXZlIHVzZWQgYW4gb3V0LW9mLWJhbmQNCiBwcm9jZXNzIHRvIHNldCB1cCBhIHRydXN0IHJlbGF0
aW9uc2hpcCBmb3IgU29tZU9yZydzIElkZW50aXR5IFByb3ZpZGVyIHdpdGggdGhlIGRhdGEgcHJv
dmlkZXLigJlzIEF1dGhvcml6YXRpb24gU2VydmljZSwgYW5kIHdpbGwgaGF2ZSBuZWdvdGlhdGVk
IGF1dGhvcml6YXRpb24gY2xhaW1zIHRvIGJlIGdyYW50ZWQgdG8gU29tZU9yZ3MgbWVtYmVycy48
L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi
PldoYXQgSSBhbSBoYXZpbmcgZGlmZmljdWx0eSB3aXRoIGlzIGluIGtuaXR0aW5nIHRvZ2V0aGVy
IGFuIGFwcHJvYWNoIGJhc2VkIG9uIHRoZSBoZSBPcGVuSUQgQ29ubmVjdCBzcGVjaWZpY2F0aW9u
cywgU0FNTCBzcGVjaWZpY2F0aW9ucywgYW5kIE9BdXRoIFJGQ3MgYW5kIGRyYWZ0cyBpbiBhIHdh
eSB0aGF0IHN1cHBvcnRzIHRoZSBhYm92ZSB1c2UgY2FzZSBlbmQtdG8tZW5kLiBUaGUgT0F1dGgg
UkZDcyBhbmQgZHJhZnRzDQogYWxtb3N0IGdldCBtZSB0aGVyZS4gV2hhdCBzZWVtcyB0byBiZSBt
aXNzaW5nIGlzIGEgd2F5IG9mIHRlbGxpbmcgYW4gSWRlbnRpdHkgUHJvdmlkZXIgdGhlIFVSTCBm
b3IgdGhlIEF1dGhvcml6YXRpb24gU2VydmljZSAodGhlIHJlcXVpcmVkIEF1ZGllbmNlIGNsYWlt
IGluIGFuIGF1dGhlbnRpY2F0aW9uIGFzc2VydGlvbiBhcyBkZWZpbmVkIGluIFJGQ3MgNzI1MSwg
NzI1MiBhbmQgNzI1MyksIGFuZCB0aGVuIGEgcmVxdWlyZW1lbnQgdGhhdCB0aGUNCiBJZGVudGl0
eSBQcm92aWRlcnMgcHV0IHRoZSBzdXBwbGllZCBBdWRpZW5jZSBJZGVudGlmaWVyIGludG8gQXV0
aGVudGljYXRpb24gVG9rZW5zLiBQZXJoYXBzIGEgbGl0dGxlIGZ1cnRoZXIgYmFjay1hbmQtZm9y
dGggd2l0aCBCcmlhbiB3aWxsIHJlc29sdmUgdGhpcy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy
IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgY2FuIGdvIGludG8gZGVlcGVyIGRl
dGFpbCBpZiBuZWVkZWQuIElmIHRoaXMgaXMgb2ZmLXRvcGljIGZvciB0aGUgT0F1dGggd29ya2lu
ZyBncm91cCwgbGV0IG1lIGtub3cuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N
CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGFua3MsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkFuZHJl
dyBGcmVnbHk8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VmVyaXNpZ24gSW5jLjwvZGl2Pg0KPGRpdiBj
bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGlkPSIi
IGNsYXNzPSIiPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz
PSIiPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iIGNsYXNzPSIiPg0K
PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmk7IGZvbnQtc2l6ZTogMTJwdDsgdGV4dC1h
bGlnbjogbGVmdDsgYm9yZGVyLXdpZHRoOiAxcHQgbWVkaXVtIG1lZGl1bTsgYm9yZGVyLXN0eWxl
OiBzb2xpZCBub25lIG5vbmU7IHBhZGRpbmc6IDNwdCAwaW4gMGluOyBib3JkZXItdG9wLWNvbG9y
OiByZ2IoMTgxLCAxOTYsIDIyMyk7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo
dDpib2xkIiBjbGFzcz0iIj5Gcm9tOiA8L3NwYW4+Sm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJt
YWlsdG86dmU3anRiQHZlN2p0Yi5jb20iIGNsYXNzPSIiPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZn
dDs8YnIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCIgY2xhc3M9IiI+
RGF0ZTogPC9zcGFuPlR1ZXNkYXksIEFwcmlsIDE5LCAyMDE2IGF0IDI6MDYgUE08YnIgY2xhc3M9
IiI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCIgY2xhc3M9IiI+VG86IDwvc3Bhbj5B
bmRyZXcgRnJlZ2x5ICZsdDs8YSBocmVmPSJtYWlsdG86YWZyZWdseUB2ZXJpc2lnbi5jb20iIGNs
YXNzPSIiPmFmcmVnbHlAdmVyaXNpZ24uY29tPC9hPiZndDs8YnIgY2xhc3M9IiI+DQo8c3BhbiBz
dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCIgY2xhc3M9IiI+Q2M6IDwvc3Bhbj4mcXVvdDs8YSBocmVm
PSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIGNsYXNzPSIiPm9hdXRoQGlldGYub3JnPC9hPiZxdW90
OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiBjbGFzcz0iIj5vYXV0aEBpZXRm
Lm9yZzwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi
IGNsYXNzPSIiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW09BVVRILVdHXSBCdWlsZGluZyBvbiB0aGUg
cHJvdG9jb2wgaW4gdGhlIGRyYWZ0IOKAnE9BdXRoIDIuMCBUb2tlbiBFeGNoYW5nZTogQW4gU1RT
IGZvciB0aGUgUkVTVCBvZiBVc+KAnSB0byBpbmNsdWRlIEF1dGhlbnRpY2F0aW9uIFRva2Vuczxi
ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N
CjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHls
ZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46
MCAwIDAgNTsiIGNsYXNzPSIiIHR5cGU9ImNpdGUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5
bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Vi
a2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQpMb29raW5nIGF0
IE9wZW5JRCBDb25uZWN0IGFuZCBpdOKAmXMgdHJ1c3QgbW9kZWwgZm9yIHByb2R1Y2luZyBpZF90
b2tlbnMgdGhhdCBhc3NlcnQgaWRlbnRpdHkgbWF5IGhlbHAgeW91Lg0KPGRpdiBjbGFzcz0iIj48
YSBocmVmPSJodHRwOi8vb3BlbmlkLm5ldC93Zy9jb25uZWN0LyIgY2xhc3M9IiI+aHR0cDovL29w
ZW5pZC5uZXQvd2cvY29ubmVjdC88L2E+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIg
Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VW5mb3J0dW5hdGVseSBJIGNhbuKAmXQg
cXVpdGUgbWFrZSBvdXQgd2hhdCB5b3UgYXJlIHRyeWluZyB0byBkby4mbmJzcDs8L2Rpdj4NCjxk
aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkl0IHNvcnQg
b2Ygc291bmRzIGxpa2UgeW91IHdhbnQgYW4gaWRfdG9rZW4gZnJvbSBhIGlkUCBhbmQgdGhlbiBo
YXZlIHRoZSBjbGllbnQgZXhjaGFuZ2UgdGhhdCBhc3NlcnRpb24gZm9yIGFub3RoZXIgdG9rZW4/
PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i
Ij5Kb2huIEIuPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9
ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBBcHIgMTksIDIwMTYsIGF0IDE6MTgg
UE0sIEZyZWdseSwgQW5kcmV3ICZsdDs8YSBocmVmPSJtYWlsdG86YWZyZWdseUB2ZXJpc2lnbi5j
b20iIGNsYXNzPSIiPmFmcmVnbHlAdmVyaXNpZ24uY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8
YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxk
aXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0
cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13
ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4
dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3
aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi
a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdp
bjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogQ2FsaWJy
aTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsiIGNsYXNzPSIiPkkg
aGF2ZSBhIHVzZSBjYXNlIHdoZXJlIGEgY2xpZW50IGFwcGxpY2F0aW9uIG5lZWRzIHRvIGF1dGhl
bnRpY2F0ZSB3aXRoIGEgZHluYW1pY2FsbHkgZGV0ZXJtaW5lZCBJZGVudGl0eSBQcm92aWRlciB0
aGF0IGlzIHNlcGFyYXRlIGZyb20gdGhlIEF1dGhvcml6YXRpb24gU2VydmljZSB0aGF0IHdpbGwg
YmUgdXNlZCBpc3N1ZSBhbiBhY2Nlc3MgdG9rZW4gdG8gdGhlIGNsaWVudC4NCiBUaGUgdXNlIGNh
c2UgYWxzbyByZXF1aXJlcyB0aGF0IGFzIHBhcnQgb2YgYXV0aG9yaXphdGlvbiwgdGhlIGNsaWVu
dCBwcm92aWRlcyB0byB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2aWNlIGFuIGF1dGhlbnRpY2F0aW9u
IHRva2VuIHNpZ25lZCBieSBhbiBJZGVudGl0eSBQcm92aWRlciB0aGF0IHRoZSBBdXRob3JpemF0
aW9uIFNlcnZpY2UgaGFzIGEgdHJ1c3QgcmVsYXRpb25zaGlwIHdpdGguIFRoZSB0cnVzdCByZWxh
dGlvbnNoaXAgaXMgdmVyaWZpYWJsZQ0KIGJhc2VkIG9uIHRoZSBBdXRob3JpemF0aW9uIFNlcnZp
Y2UgaGF2aW5nIHJlY29yZGVkIHRoZSBwdWJsaWMga2V5cyBvciBjZXJ0aWZpY2F0ZXMgb2YgdHJ1
c3RlZCBJZGVudGl0eSBQcm92aWRlcnMgaW4gYSB0cnVzdCBzdG9yZSwgdGhpcyBhbGxvd2luZyB0
aGUgQXV0aG9yaXphdGlvbiBTZXJ2aWNlIHRvIHZlcmlmeSBhbiBJZGVudGl0eSBQcm92aWRlcuKA
mXMgc2lnbmF0dXJlIG9uIGFuIGF1dGhlbnRpY2F0aW9uIHRva2VuLjwvc3Bhbj48YSBuYW1lPSJP
TEVfTElOSzUiIGNsYXNzPSIiPjwvYT48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp
biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogQ2FsaWJyaTsiIGNsYXNz
PSIiPg0KPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu
IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogQ2FsaWJyaTsiIGNs
YXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1h
cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogQ2Fs
aWJyaTsiIGNsYXNzPSIiPg0KSW4gbG9va2luZyBhdCB0aGUgdmFyaW91cyBPQXV0aCBSRkNzLCBw
YXJ0aWN1bGFybHkgUkZDcyA3NTIxLCA3NTIyLCBhbmQgNzUyMywgSSBzZWUgdGhhdCB0aGV5IGdl
dCBtZSBjbG9zZSBpbiB0ZXJtcyBvZiBzdXBwb3J0aW5nIHRoZSB1c2UgY2FzZS4gV2hhdCBpcyBt
aXNzaW5nIGlzIGEgbWVhbnMgZm9yIHNvbHZpbmcgdGhlIGZvbGxvd2luZyBwcm9ibGVtLiBUaGVz
ZSBSRkNzIHJlcXVpcmUgdGhhdCB0aGUgSWRlbnRpdHkgUHJvdmlkZXIgcHV0IGFuDQogQXVkaWVu
Y2UgY2xhaW0gaW4gdGhlIGF1dGhlbnRpY2F0aW9uIHRva2VuLiBUaGUgcHJvYmxlbSB3aXRoIHRo
aXMgaXMgdGhhdCBJIGRvIG5vdCBzZWUgaW4gdGhlIFJGQ3MgaG93IHRoZSBJZGVudGl0eSBQcm92
aWRlciBjYW4gYmUgdG9sZCB3aG8gdGhlIEF1ZGllbmNlIGlzIHRvIHB1dCBpbnRvIHRoZSBhdXRo
ZW50aWNhdGlvbiB0b2tlbi4gVGhpcyBsZWFkcyBtZSB0byB0aGUgdGl0bGUgb2YgdGhpcyBtZXNz
YWdlLiBUaGUgZHJhZnQg4oCcT0F1dGgNCiAyLjAgVG9rZW4gRXhjaGFuZ2U6IEFuIFNUUyBmb3Ig
dGhlIFJFU1Qgb2YgVXPigJ0gZGVmaW5lcyBhIG1lY2hhbmlzbSBmb3IgaWRlbnRpZnlpbmcgdGhl
IEF1ZGllbmNlIGZvciBhbiBTVFMgdG8gcHV0IGludG8gYSB0b2tlbiBpdCBnZW5lcmF0ZXMuIFRo
YXQgd291bGQgc29sdmUgbXkgcHJvYmxlbSBleGNlcHQgdGhhdCB0aGUgZHJhZnQgbGltaXRzIHRo
ZSB0eXBlIG9mIFNUUyB0byBiZWluZyBBdXRob3JpemF0aW9uIFNlcnZlcnMuIFdoYXQgaXMgbmVl
ZGVkDQogaXMgdGhpcyBzYW1lIGNhcGFiaWxpdHkgZm9yIGludGVyYWN0aW5nIHdpdGggYW4gSWRl
bnRpdHkgUHJvdmlkZXIuIFRoaXMgd291bGQgZW5hYmxlIFJGQ3MgNzUyMSwgNzUyMiBhbmQgNzUy
MyB0byBiZSB1c2VmdWwgaW4gc2l0dWF0aW9uIHdoZXJlIHRoZSBJZGVudGl0eSBQcm92aWRlciBu
ZWVkcyB0byBiZSB0b2xkIHRoZSBpZGVudGl0eSBvZiB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2aWNl
LjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g
MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IENhbGlicmk7IiBjbGFzcz0i
Ij4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46
IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IENhbGlicmk7
IiBjbGFzcz0iIj4NCkkgYW0gbmV3IHRvIGludGVyYWN0aW5nIHdpdGggdGhlIElFVEYuIEkgYWxz
byBhbSBub3QgYW4gZXhwZXJ0IG9uIHRoZSBSRkNzIG9yIHByaW9yIGhpc3Rvcnkgb2YgdGhlIE9B
dXRoIGdyb3VwIHJlbGF0aXZlIHRvIHRoaXMgdG9waWMsIHNvIHBsZWFzZSBwb2ludCBtZSB0byBh
bnkgZXhpc3Rpbmcgc29sdXRpb24gaWYgdGhpcyBpcyBhIHNvbHZlZCBwcm9ibGVtLiBPdGhlcndp
c2UsIEkgd291bGQgbGlrZSB0byBnZXQgZmVlZGJhY2sgb24gbXkgc3VnZ2VzdGlvbi48bzpwIGNs
YXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0
OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyIgY2xhc3M9IiI+DQo8bzpw
IGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu
IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyIgY2xhc3M9
IiI+DQpUaGFua3MgWW91LDwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw
MXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyIgY2xhc3M9IiI+DQo8
YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw
dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogQ2FsaWJyaTsiIGNsYXNzPSIiPg0KQW5k
cmV3IEZyZWdseTxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46
IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IENhbGlicmk7
IiBjbGFzcz0iIj4NClZlcmlzaWduIEluYy48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u
dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1zdHls
ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs
OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFy
dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu
b3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv
a2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGRpdiBpZD0iIiBjbGFzcz0iIj48L2Rpdj4NCjwv
ZGl2Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250
LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0
dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl
eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs
OyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp
ZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNz
PSIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFu
PjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog
MTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250
LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0
ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7
IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13
ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5
bGU6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg
b3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt
dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQt
c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25l
OyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPk9BdXRoDQogbWFpbGluZyBs
aXN0PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZv
bnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y
bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5z
OiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv
cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5n
OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGEgaHJl
Zj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNh
bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh
bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y
bWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg
dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg
d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNz
PSIiPk9BdXRoQGlldGYub3JnPC9hPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNh
bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh
bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y
bWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg
dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg
d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNz
PSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0
aCIgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0
cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13
ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4
dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3
aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi
a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+
DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx
dW90ZT4NCjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIg
Y2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+
DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_621AAD5EFD504A2D8B4C2A10431FA55Cverisigncom_--


From nobody Tue Apr 19 14:35:42 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E4412E7E4 for ; Tue, 19 Apr 2016 14:35:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lTYM3lziOdb for ; Tue, 19 Apr 2016 14:35:38 -0700 (PDT)
Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d: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 73F5812E7CD for ; Tue, 19 Apr 2016 14:35:37 -0700 (PDT)
Received: by mail-qk0-x230.google.com with SMTP id r184so8972503qkc.1 for ; Tue, 19 Apr 2016 14:35:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=NfPoEnhdRGlaQA99V+YqS432DEC+P65E28Mxbd0vb4s=; b=MdquUPXixTYWcJW11xl464T9Sr6lYvmLGo9BunPCmUSSBExzq1jRTXawWHf1zX35ip 2LllQ3y2VIBQiWlpKTKvNdNK7LN768hsm2CkurthyE3QqJQWkZVR6J4MkD6AkUbFhl38 hdKgMD+ZvMl3/8vHy/uHmSEfPCSE4HG67J0HFgq7JjqYFcxvVgfueG+C79tKYeKdIsSf VmvunZLdAy7O7DyKKGDVedjnGws55+/tEBEdiWzIqRZ0THUByMkLkRGqlKcBj5hxFHPZ K368PBmnVK5foqMpzEXf8MttN+65PHWiodX/OxfofUv8PW3+vTcBHYVHop4/2mEl3PmF RwNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=NfPoEnhdRGlaQA99V+YqS432DEC+P65E28Mxbd0vb4s=; b=Qe6mq5fK/W+bbTUq62DvWuJllRg2l5jw9azZ3DCrrJebFpaIr7Jd4ydOYQjoaRa4fQ 2V37C8pCkO8Gfx2rl8Z9DcIx86kO40CjOLaou2Bq/1yVTJa5pyFaHJJi9r5HPmHu7Noo zi/jivzHEKirHLdL4AGXiSb/Uk+LdsJ1lUzi7u/GluxoDTrvpecUay6U+xkoXZEVu82R WOkS7KTTlFkE6EtqRKvQ2uGxpU0Sc7EMOe0z+4fyhIDf7VwGfraEsLsaVOF4WPo8Grov GW5owOjJ6cxFmimN2zmfmALsRKelgK7+VXUjSHF8V0Mz3kolzh8AyH3Yv01IAfRX3LZx zZfA==
X-Gm-Message-State: AOPr4FW7lkpC1p4EbC4qPfHJv6+4qmWDwLwXzakZo5dtHzLgILRXpGXDlQ2Z3i81T8HCrLzJ8Rgx87/ZDPgr+Q==
X-Received: by 10.55.204.197 with SMTP id n66mr6864752qkl.95.1461101736499; Tue, 19 Apr 2016 14:35:36 -0700 (PDT)
MIME-Version: 1.0
References:   <8B748252-9AE2-4824-923B-00CD46CB8D68@verisign.com>  <5958E90F-EF8C-4641-96C1-A9077B450D53@verisign.com>
In-Reply-To: <5958E90F-EF8C-4641-96C1-A9077B450D53@verisign.com>
From: Nat Sakimura 
Date: Tue, 19 Apr 2016 21:35:25 +0000
Message-ID: 
To: "Fregly, Andrew" , John Bradley ,  "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary=001a1149a45cfc20f10530dd411e
Archived-At: 
Subject: Re: [OAUTH-WG] Building on the protocol in the draft "OAuth 2.0 Token Exchange: An STS for the REST of Us" to include Authentication Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Apr 2016 21:35:41 -0000

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

Hi Andrew,

In OAuth 2.0, the resource owner authentication /end user authentication is
out of scope. What it deals with is "client authentication". They should
not be mixed up. There is no end user identity nor authentication token in
the OAuth. You cannot do end user authentication with pure OAuth. For that,
you have to rely on something like OpenID Connect.

As John noted, it is perfectly fine to chain the external authentication
and the internal authorization. It is often done. It is just that the
RFC6749 Authz server is an RP of OpenID Connect or SP of SAML. Nothing
precludes it.

If you really want to avoid the front channel re-auth with prompt=3Dnone,
which is more secure and proper ways to do, but just to make sure that the
user still exists in the authentication service, you can infer it by making
a userinfo request to the userinfo endpoint of OpenID Connect. It would
fail in various reasons, but would certainly fail if the user does not
exist anymore. Other error conditions like the user revoked the
access/refresh token etc. would cause the same invalid_token error though.

Best,

Nat

P.S. I do not see why the RFCs you sited are relevant here. I guess you are
talking about RFC7521-7523 ;-)

RFC7251 AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS
RFC7252 The Constrained Application Protocol (CoAP)
RFC7253 The OCB Authenticated-Encryption Algorithm







2016=E5=B9=B44=E6=9C=8820=E6=97=A5(=E6=B0=B4) 5:34 Fregly, Andrew :

> Thanks for your reply Nat.
>
> Does your approach match with an IETF OAuth RFC or Draft describing how a=
n
> Authorization Service can accept and verify an authentication token
> provided by a client during the authorization process? If so, please poin=
t
> me to that. The only RFCs I have seen that address this are RFCs 7251, 72=
52
> and 7253, and they all have a requirement that an =E2=80=9Caudience=E2=80=
=9D claim
> corresponding to the Authorization Service is in the authentication token=
.
> Getting that claim into an authentication token provided by an
> Organization=E2=80=99s Identity provider seems to be my fundamental probl=
em.
>
> Thanks,
>       Andy
>
> From: Nat Sakimura 
> Date: Tuesday, April 19, 2016 at 4:13 PM
> To: Andrew Fregly , John Bradley ,
> "oauth@ietf.org" 
>
> Subject: Re: [OAUTH-WG] Building on the protocol in the draft "OAuth 2.0
> Token Exchange: An STS for the REST of Us" to include Authentication Toke=
ns
>
> Get OpenID Connect id_token by the authentication request with prompt=3Dn=
one
> and verifying the sub to be the same with what you expected seem to suffi=
ce
> your needs. Am I missing something?
> On Wed, Apr 20, 2016 at 05:05 Fregly, Andrew  wrote=
:
>
>> Thanks for your response John. I also got a good response from Brian
>> Campbell and appreciate that. I will respond separately to Brian=E2=80=
=99s response
>> as I think it would keep things clearer to do that.
>>
>> The problem we have for using OpenID Connect is that it combines the rol=
e
>> of Authentication Service with the role of Authorization Service. Perhap=
s
>> the following description of what we want to do will clarify why this wo=
n=E2=80=99t
>> work for us:
>>
>> The basic problem statement is that we need to have a client application
>> authorized by a Service Provider based on proof that a user is currently=
 a
>> member of some organization. This assumes the organization has previousl=
y
>> established some level of authorized access with the Service Provider.
>>
>> Here is an example: Suppose I am a member of SomeOrg Inc. Suppose SomeOr=
g
>> Inc. is doing research that requires it to gather data over the Internet
>> from a number of data providers. The data providers require authenticati=
on
>> and proof of organizational membership in order to authorize various lev=
els
>> of access to their data. The data providers do not consider having an
>> account with them or a Public Identity Provider to be suitable for provi=
ng
>> that I am still a member of SomeOrg at time of authentication. They woul=
d
>> have no way of knowing whether or not my relationship with SomeOrg still
>> exists at that time. The data providers would therefore like the Client
>> software to authenticate me against SomeOrgs Identity Provider. This wou=
ld
>> be good proof that I am still a member of SomeOrg at the time I
>> authenticate. This authentication would enable the data providers
>> Authorization Server to grant me access appropriate to a member of
>> SomeOrg.  Note that as a prerequisite to all of this, SomeOrg will have
>> used an out-of-band process to set up a trust relationship for SomeOrg's
>> Identity Provider with the data provider=E2=80=99s Authorization Service=
, and will
>> have negotiated authorization claims to be granted to SomeOrgs members.
>>
>> What I am having difficulty with is in knitting together an approach
>> based on the he OpenID Connect specifications, SAML specifications, and
>> OAuth RFCs and drafts in a way that supports the above use case end-to-e=
nd.
>> The OAuth RFCs and drafts almost get me there. What seems to be missing =
is
>> a way of telling an Identity Provider the URL for the Authorization Serv=
ice
>> (the required Audience claim in an authentication assertion as defined i=
n
>> RFCs 7251, 7252 and 7253), and then a requirement that the Identity
>> Providers put the supplied Audience Identifier into Authentication Token=
s.
>> Perhaps a little further back-and-forth with Brian will resolve this.
>>
>> I can go into deeper detail if needed. If this is off-topic for the OAut=
h
>> working group, let me know.
>>
>> Thanks,
>> Andrew Fregly
>> Verisign Inc.
>>
>>
>> From: John Bradley 
>> Date: Tuesday, April 19, 2016 at 2:06 PM
>> To: Andrew Fregly 
>> Cc: "oauth@ietf.org" 
>> Subject: Re: [OAUTH-WG] Building on the protocol in the draft =E2=80=9CO=
Auth 2.0
>> Token Exchange: An STS for the REST of Us=E2=80=9D to include Authentica=
tion Tokens
>>
>> Looking at OpenID Connect and it=E2=80=99s trust model for producing id_=
tokens
>> that assert identity may help you.
>> http://openid.net/wg/connect/
>>
>> Unfortunately I can=E2=80=99t quite make out what you are trying to do.
>>
>> It sort of sounds like you want an id_token from a idP and then have the
>> client exchange that assertion for another token?
>>
>> John B.
>>
>> On Apr 19, 2016, at 1:18 PM, Fregly, Andrew  wrote=
:
>>
>> I have a use case where a client application needs to authenticate with =
a
>> dynamically determined Identity Provider that is separate from the
>> Authorization Service that will be used issue an access token to the
>> client. The use case also requires that as part of authorization, the
>> client provides to the Authorization Service an authentication token sig=
ned
>> by an Identity Provider that the Authorization Service has a trust
>> relationship with. The trust relationship is verifiable based on the
>> Authorization Service having recorded the public keys or certificates of
>> trusted Identity Providers in a trust store, this allowing the
>> Authorization Service to verify an Identity Provider=E2=80=99s signature=
 on an
>> authentication token.
>>
>> In looking at the various OAuth RFCs, particularly RFCs 7521, 7522, and
>> 7523, I see that they get me close in terms of supporting the use case.
>> What is missing is a means for solving the following problem. These RFCs
>> require that the Identity Provider put an Audience claim in the
>> authentication token. The problem with this is that I do not see in the
>> RFCs how the Identity Provider can be told who the Audience is to put in=
to
>> the authentication token. This leads me to the title of this message. Th=
e
>> draft =E2=80=9COAuth 2.0 Token Exchange: An STS for the REST of Us=E2=80=
=9D defines a
>> mechanism for identifying the Audience for an STS to put into a token it
>> generates. That would solve my problem except that the draft limits the
>> type of STS to being Authorization Servers. What is needed is this same
>> capability for interacting with an Identity Provider. This would enable
>> RFCs 7521, 7522 and 7523 to be useful in situation where the Identity
>> Provider needs to be told the identity of the Authorization Service.
>>
>> I am new to interacting with the IETF. I also am not an expert on the
>> RFCs or prior history of the OAuth group relative to this topic, so plea=
se
>> point me to any existing solution if this is a solved problem. Otherwise=
, I
>> would like to get feedback on my suggestion.
>>
>> Thanks You,
>>
>> Andrew Fregly
>> Verisign Inc.
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>

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


Hi Andrew,=C2=A0

=
In OAuth 2.0, the resource owner authentica=
tion /end user authentication is out of scope. What it deals with is "=
client authentication". They should not be mixed up. There is no end u=
ser identity nor authentication token in the OAuth. You cannot do end user =
authentication with pure OAuth. For that, you have to rely on something lik=
e OpenID Connect.=C2=A0

As John noted, it i=
s perfectly fine to chain the external authentication and the internal auth=
orization. It is often done. It is just that the RFC6749 Authz server is an=
 RP of OpenID Connect or SP of SAML. Nothing precludes it.=C2=A0

If you really want to avoid the front channel re-auth wit=
h prompt=3Dnone, which is more secure and proper ways to do, but just to ma=
ke sure that the user still exists in the authentication service, you can i=
nfer it by making a userinfo request to the userinfo endpoint of OpenID Con=
nect. It would fail in various reasons, but would certainly fail if the use=
r does not exist anymore. Other error conditions like the user revoked the =
access/refresh token etc. would cause the same=C2=A0invalid_token error=
 though.=C2=A0

Best,=C2=A0
<=
span style=3D"line-height:1.5">
Nat

P.S.=C2=A0I do not see why the RFCs you sited are relevant here. I g=
uess you are talking about RFC7521-7523 ;-)

RFC7=
251 AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS
RFC7=
252 The Constrained Application Protocol (CoAP)
RFC7253 The OCB Authenti=
cated-Encryption Algorithm



=




20=
16=E5=B9=B44=E6=9C=8820=E6=97=A5(=E6=B0=B4) 5:34 Fregly, Andrew <afregly@verisign.com>:









Thanks for your reply Nat.







Does your approach match with an IETF OAuth RFC or Draft describing ho=
w an Authorization Service can accept and verify an authentication token pr=
ovided by a client during the authorization process? If so, please point me=
 to that. The only RFCs I have seen
 that address this are RFCs 7251, 7252 and 7253, and they all have a requir=
ement that an =E2=80=9Caudience=E2=80=9D claim corresponding to the Authori=
zation Service is in the authentication token. Getting that claim into an a=
uthentication token provided by an Organization=E2=80=99s
 Identity provider seems to be my fundamental problem.







Thanks,


=C2=A0 =C2=A0 =C2=A0 Andy

















From: Nat Sakimura <sakimura@gmail.com>

Date: Tuesday, April 19, 2016 at 4:=
13 PM

To: Andrew Fregly <afregly@verisign.com>, =
John Bradley <ve7=
jtb@ve7jtb.com>, "oauth@ietf.org" <oauth@ietf.org>


Subject: Re: [OAUTH-WG] Building on=
 the protocol in the draft "OAuth 2.0 Token Exchange: An STS for the R=
EST of Us" to include Authentication Tokens













Get OpenID Connect id_token by the authentication request with prompt=
=3Dnone and verifying the sub to be the same with what you expected seem to=
 suffice your needs. Am I missing something?





On Wed, Apr 20, 2016 at 05:05 Fregly, Andrew <afregly@verisign.com=
> wrote:










Thanks for your response John. I also got a good response from Brian C=
ampbell and appreciate that. I will respond separately to Brian=E2=80=99s r=
esponse as I think it would keep things clearer to do that.







The problem we have for using OpenID Connect is that it combines the r=
ole of Authentication Service with the role of Authorization Service. Perha=
ps the following description of what we want to do will clarify why this wo=
n=E2=80=99t work for us:







The basic problem statement is that we need to have a client applicati=
on authorized by a Service Provider based on proof that a user is currently=
 a member of some organization. This assumes the organization has previousl=
y established some level of authorized
 access with the Service Provider.=C2=A0







Here is an example: Suppose I am a member of SomeOrg Inc. Suppose Some=
Org Inc. is doing research that requires it to gather data over the Interne=
t from a number of data providers. The data providers require authenticatio=
n and proof of organizational membership
 in order to authorize various levels of access to their data. The data pro=
viders do not consider having an account with them or a Public Identity Pro=
vider to be suitable for proving that I am still a member of SomeOrg at tim=
e of authentication. They would
 have no way of knowing whether or not my relationship with SomeOrg still e=
xists at that time. The data providers would therefore like the Client soft=
ware to authenticate me against SomeOrgs Identity Provider. This would be g=
ood proof that I am still a member
 of SomeOrg at the time I authenticate. This authentication would enable th=
e data providers Authorization Server to grant me access appropriate to a m=
ember of SomeOrg.=C2=A0 Note that as a prerequisite to all of this, SomeOrg=
 will have used an out-of-band process
 to set up a trust relationship for SomeOrg's Identity Provider with th=
e data provider=E2=80=99s Authorization Service, and will have negotiated a=
uthorization claims to be granted to SomeOrgs members.







What I am having difficulty with is in knitting together an approach b=
ased on the he OpenID Connect specifications, SAML specifications, and OAut=
h RFCs and drafts in a way that supports the above use case end-to-end. The=
 OAuth RFCs and drafts almost get
 me there. What seems to be missing is a way of telling an Identity Provide=
r the URL for the Authorization Service (the required Audience claim in an =
authentication assertion as defined in RFCs 7251, 7252 and 7253), and then =
a requirement that the Identity
 Providers put the supplied Audience Identifier into Authentication Tokens.=
 Perhaps a little further back-and-forth with Brian will resolve this.






I can go into deeper detail if needed. If this is off-topic for the OA=
uth working group, let me know.







Thanks,


Andrew Fregly


Verisign Inc.






















From: John Bradley <ve7jtb@ve7jtb.com>

Date: Tuesday, April 19, 2016 at 2:=
06 PM

To: Andrew Fregly <afregly@verisign.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>

Subject: Re: [OAUTH-WG] Building on=
 the protocol in the draft =E2=80=9COAuth 2.0 Token Exchange: An STS for th=
e REST of Us=E2=80=9D to include Authentication Tokens


















Looking at OpenID Connect and it=E2=80=
=99s trust model for producing id_tokens that assert identity may help you.

http://ope=
nid.net/wg/connect/







Unfortunately I can=E2=80=99t quite make out what you are trying to do=
.=C2=A0







It sort of sounds like you want an id_token from a idP and then have t=
he client exchange that assertion for another token?







John B.






On Apr 19, 2016, at 1:18 PM, Fregly, Andrew <afregly@verisign.com> wrote:







<=
span style=3D"font-size:12pt">I have a use case where a client application =
needs to authenticate with a dynamically determined Identity Provider that =
is separate from the Authorization Service
 that will be used issue an access token to the client. The use case also r=
equires that as part of authorization, the client provides to the Authoriza=
tion Service an authentication token signed by an Identity Provider that th=
e Authorization Service has a trust
 relationship with. The trust relationship is verifiable based on the Autho=
rization Service having recorded the public keys or certificates of trusted=
 Identity Providers in a trust store, this allowing the Authorization Servi=
ce to verify an Identity Provider=E2=80=99s
 signature on an authentication token.


<=
u>


<=
u>=C2=A0


I=
n looking at the various OAuth RFCs, particularly RFCs 7521, 7522, and 7523=
, I see that they get me close in terms of supporting the use case. What is=
 missing is a means for solving the
 following problem. These RFCs require that the Identity Provider put an Au=
dience claim in the authentication token. The problem with this is that I d=
o not see in the RFCs how the Identity Provider can be told who the Audienc=
e is to put into the authentication
 token. This leads me to the title of this message. The draft =E2=80=9COAut=
h 2.0 Token Exchange: An STS for the REST of Us=E2=80=9D defines a mechanis=
m for identifying the Audience for an STS to put into a token it generates.=
 That would solve my problem except that the draft
 limits the type of STS to being Authorization Servers. What is needed is t=
his same capability for interacting with an Identity Provider. This would e=
nable RFCs 7521, 7522 and 7523 to be useful in situation where the Identity=
 Provider needs to be told the identity
 of the Authorization Service.


<=
u>=C2=A0


I=
 am new to interacting with the IETF. I also am not an expert on the RFCs o=
r prior history of the OAuth group relative to this topic, so please point =
me to any existing solution if this
 is a solved problem. Otherwise, I would like to get feedback on my suggest=
ion.


<=
u>=C2=A0


T=
hanks You,


<=
br>



A=
ndrew Fregly


V=
erisign Inc.









_______________________________________________=


OAuth
 mailing list

OAuth@ietf.org

https://www.ietf.org/m=
ailman/listinfo/oauth



















_______________________________________________

OAuth mailing list

OAuth@ietf.org

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














--001a1149a45cfc20f10530dd411e--


From nobody Tue Apr 19 22:50:03 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B769812E366 for ; Tue, 19 Apr 2016 22:50:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbFSP0-K7j0L for ; Tue, 19 Apr 2016 22:50:00 -0700 (PDT)
Received: from nrifs04.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0479312D86E for ; Tue, 19 Apr 2016 22:49:59 -0700 (PDT)
Received: from nriea02.index.or.jp (unknown [172.19.246.37]) by nrifs04.index.or.jp (Postfix) with SMTP id 9C718472EDF; Wed, 20 Apr 2016 14:49:58 +0900 (JST)
Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea02.index.or.jp (unknown) with ESMTP id u3K5nwoi020588; Wed, 20 Apr 2016 14:49:58 +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 u3K5nwlD016487; Wed, 20 Apr 2016 14:49:58 +0900
Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id u3K5nwwW016486; Wed, 20 Apr 2016 14:49:58 +0900
X-Authentication-Warning: nrims00a.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f
Received: from nrizmf12.index.or.jp ([172.100.25.21]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id u3K5nwbt016483; Wed, 20 Apr 2016 14:49:58 +0900
From: "Nat Sakimura" 
To: , , 
References: <57054ADF.3010109@gmx.net>   <5715E383.1010805@gmx.net> 
In-Reply-To: 
Date: Wed, 20 Apr 2016 14:49:58 +0900
Message-ID: <02b001d19ac8$798c0050$6ca400f0$@nri.co.jp>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_02B1_01D19B13.E974E0D0"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQDy2qTHLvKoZQS7HB05lNE0bmP5cgGNMsJdAX2+TVcCHt8WUQECxZnNoR5204A=
Content-Language: ja
X-MailAdviser: 20141126
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Meeting Minutes
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Apr 2016 05:50:02 -0000

This is a multipart message in MIME format.

------=_NextPart_000_02B1_01D19B13.E974E0D0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I recall the same with Torsten and Brian.=20

At least, there was a sentiment in the room that we have to come up with =
a comprehensive analysis of the security model and threat to come up =
with a proper solution.=20

=20

Trying to keep patching the protocol because you can would not be =
helpful.=20

=20

Nat

=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 =
torsten@lodderstedt.net
Sent: Tuesday, April 19, 2016 5:17 PM
To: hannes.tschofenig@gmx.net; bcampbell@pingidentity.com
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Meeting Minutes

=20

Different people, different perceptions :-)

But anyway, the discussion on the list has already started, right?



-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] Meeting Minutes
Von: Hannes Tschofenig  >
An: Brian Campbell  >,Torsten Lodderstedt =
 >
Cc: oauth@ietf.org =20

Hi Torsten,

On 04/19/2016 12:34 AM, Brian Campbell wrote:
>
> I felt some consensous around the topic that in the end, there must be
> normative chances to the core protocol and the respective security
> considerations.
>
> Barry gave his advice regarding updates in this context.

There was no consensus on this topic during the meeting and, in
addition, we have to consult those on the mailing list as well.

Barry, in my understanding, outlined the different options we have at
the meeting.


Ciao
Hannes


------=_NextPart_000_02B1_01D19B13.E974E0D0
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I=
 recall the same with Torsten and Brian. 
A=
t least, there was a sentiment in the room that we have to come up with =
a comprehensive analysis of the security model and threat to come up =
with a proper solution. 
<=
o:p> 
T=
rying to keep patching the protocol because you can would not be =
helpful. 
<=
o:p> 
N=
at
<=
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:<=
/b> OAuth =
[mailto:oauth-bounces@ietf.org] On Behalf Of =
torsten@lodderstedt.net
Sent: Tuesday, April 19, 2016 5:17 =
PM
To: hannes.tschofenig@gmx.net; =
bcampbell@pingidentity.com
Cc: =
oauth@ietf.org
Subject: Re: [OAUTH-WG] Meeting =
Minutes
 
Different =
people, different perceptions :-)
But anyway, the discussion on the list has already started, =
right?


-------- =
Originalnachricht --------
Betreff: Re: [OAUTH-WG] Meeting =
Minutes
Von: Hannes Tschofenig <hannes.tschofenig@gmx.net&g=
t;
An: Brian Campbell <bcampbell@pingidentity.com=
>,Torsten Lodderstedt <torsten@lodderstedt.net>Cc: oauth@ietf.org
Hi Torsten,

On =
04/19/2016 12:34 AM, Brian Campbell wrote:
>
> I felt some =
consensous around the topic that in the end, there must be
> =
normative chances to the core protocol and the respective =
security
> considerations.
>
> Barry gave his advice =
regarding updates in this context.

There was no consensus on this =
topic during the meeting and, in
addition, we have to consult those =
on the mailing list as well.

Barry, in my understanding, outlined =
the different options we have at
the =
meeting.


Ciao
Hannes

------=_NextPart_000_02B1_01D19B13.E974E0D0--


From nobody Wed Apr 20 05:49:31 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2668012D91F for ; Wed, 20 Apr 2016 05:49:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.896
X-Spam-Level: 
X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mx.aol.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id picFqPT2d8fZ for ; Wed, 20 Apr 2016 05:49:26 -0700 (PDT)
Received: from omr-a020e.mx.aol.com (omr-a020e.mx.aol.com [204.29.186.66]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 788B212D985 for ; Wed, 20 Apr 2016 05:49:22 -0700 (PDT)
Received: from mtaout-aag02.mx.aol.com (mtaout-aag02.mx.aol.com [172.26.126.78]) by omr-a020e.mx.aol.com (Outbound Mail Relay) with ESMTP id AB4C03800095; Wed, 20 Apr 2016 08:49:21 -0400 (EDT)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (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 16D6C3800008B; Wed, 20 Apr 2016 08:49:21 -0400 (EDT)
To: "Fregly, Andrew" , John Bradley , "oauth@ietf.org" 
References:   <8B748252-9AE2-4824-923B-00CD46CB8D68@verisign.com> <571692A1.5070000@aol.com> <6101D0EB-E04B-4574-8899-ED8F4E631D67@verisign.com>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <57177AD0.1090300@aol.com>
Date: Wed, 20 Apr 2016 08:49:20 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <6101D0EB-E04B-4574-8899-ED8F4E631D67@verisign.com>
Content-Type: multipart/alternative; boundary="------------080105020000080800020700"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1461156561; bh=LIHR7s48PzGY7j1fo3TQDePs5KX+tCadLa8hA0dUbPo=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=bn8DGII5VoWmX/6LnBNcatEwVMHB6rQOWPs4PjeIE2J9IBruAavOfLLDxyM8t7nSQ PqqxxYz66QOtWh7+h2o073y7xDBUNUR008BW6IL+XMcUmKenk9G8YTPGSCHqhnpvLo 76Zqz6dXjKXJNnKc8Ssjlr87Lz9+PQsZ0Hx4crJ8=
x-aol-sid: 3039ac1a7e4e57177ad17ba4
X-AOL-IP: 10.172.102.179
Archived-At: 
Subject: Re: [OAUTH-WG] =?utf-8?q?Building_on_the_protocol_in_the_draft_?= =?utf-8?q?=E2=80=9COAuth_2=2E0_Token_Exchange=3A_An_STS_for_the_REST_of_U?= =?utf-8?q?s=E2=80=9D_to_include_Authentication_Tokens?=
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Apr 2016 12:49:30 -0000

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

I should probably just wait for the diagram... but not wanting to wait... :)

If I understand correctly, the user is going to use a client and the 
client will authenticate the user via some IdP using an existing method 
(SAML, LDAP (?), OpenID Connect, etc). The desire is to take that 
response and in some way present it to an "Authorization Server" which 
will validate the "authentication response" and return an access token 
for use at the data provider(s).

What if the Authorization Server also took on the role of the OpenID 
Connect provider. This could work by having the client start an OpenID 
Connect flow with Authorization Server (hints could be provided as to 
which IdP the user wants to authenticate at). The AS would look at the 
"idp hint" and either start and SP SAML flow, or present UI for 
collecting LDAP credentials (I don't recommend this) or chain to any 
other proprietary IdP flow. Once the user successfully authenticates 
with the correct IdP, the AS will finish the OpenID Connect flow 
allowing the client to obtain an access token, refresh token and 
id_token. The AS could add to the id_token a claim specifying which IdP 
the user used during the authentication processed.

The IdP the user used for authentication could also be encoded in the 
access_token (or returned as part of an introspection call).

This way whether the data providers are validating the access_tokens 
locally or using introspection they can obtain the IdP the user used and 
apply their own authorization rules.

The user is only required to do one authorization flow for the client 
that is managed by the Authorization Server.

Thanks,
George

On 4/19/16 5:06 PM, Fregly, Andrew wrote:
> Thank you for your response George. It points me to some more research 
> to do, such as looking at OpenID Connect support for both distributed 
> and aggregated claims.
>
> Below are replies to your questions/assertions based on my current 
> understanding of the various protocols. Further research and advice 
> will likely enrich this significantly.
>
> Yes, what is required is a verifiable claim that the user is still a 
> member of SomeOrg Inc. I have been operating under the assumption that 
> the only way this can be done would be to have the user authenticated 
> by the Identity Provider for SomeOrg. Perhaps the research into OpenID 
> Connect support for distributed and aggregated claims will reveal an 
> alternative. I foresee a challenge in dealing with Identity Provider’s 
> for organizations using SAML assertions on top of Active Directory and 
> LDAP, and which are not going to do any updating to support our needs.
>
> We do not expect the user to first go to the data provider. We 
> anticipate that the client application would provide a Authentication 
> Token to an  Authorization Service service that then issues to the 
> client an access token that the data provider will trust. One of our 
> reasons for doing it this way is that we are trying to eliminate 
> redirects to ease implementation of a native client. We are therefore 
> requiring the client to handle authentication with the Identity 
> Provider as a separate step from authorization.
>
> It might help if I clarified that Verisign’s role in the scenario I 
> described is to be just one of many data providers.
>
> From: George Fletcher >
> Organization: AOL LLC
> Date: Tuesday, April 19, 2016 at 4:18 PM
> To: Andrew Fregly  >, John Bradley  >, "oauth@ietf.org " 
> >
> Subject: Re: [OAUTH-WG] Building on the protocol in the draft “OAuth 
> 2.0 Token Exchange: An STS for the REST of Us†to include 
> Authentication Tokens
>
>     So if I understand this correctly, what is really required is a
>     verifiable claim that the user is still a member of SomeOrg Inc.
>     OpenID Connect supports both distributed and aggregated claims
>     that can be signed by the appropriate Identity Provider. The point
>     being that I'm not sure an "authentication token" is required for
>     this use case to succeed, it's just one kind of token that can be
>     used.
>
>     Also, is the expected flow that the user will first go to the data
>     provider and then be directed else where from there? If that is
>     the case, the data provider can just be an OpenID Connect relying
>     party and give the user an option of the list of supported IdPs to
>     choose from. The user will then be redirected to SomeOrg Inc. IdP,
>     authenticate and the data provider will have the authorization and
>     recent authentication they can validate.
>
>     Is the user/data flow more complicated than this?
>
>     Thanks,
>     George
>
>     On 4/19/16 4:05 PM, Fregly, Andrew wrote:
>>     Thanks for your response John. I also got a good response from
>>     Brian Campbell and appreciate that. I will respond separately to
>>     Brian’s response as I think it would keep things clearer to do that.
>>
>>     The problem we have for using OpenID Connect is that it combines
>>     the role of Authentication Service with the role of Authorization
>>     Service. Perhaps the following description of what we want to do
>>     will clarify why this won’t work for us:
>>
>>     The basic problem statement is that we need to have a client
>>     application authorized by a Service Provider based on proof that
>>     a user is currently a member of some organization. This assumes
>>     the organization has previously established some level of
>>     authorized access with the Service Provider.
>>
>>     Here is an example: Suppose I am a member of SomeOrg Inc. Suppose
>>     SomeOrg Inc. is doing research that requires it to gather data
>>     over the Internet from a number of data providers. The data
>>     providers require authentication and proof of organizational
>>     membership in order to authorize various levels of access to
>>     their data. The data providers do not consider having an account
>>     with them or a Public Identity Provider to be suitable for
>>     proving that I am still a member of SomeOrg at time of
>>     authentication. They would have no way of knowing whether or not
>>     my relationship with SomeOrg still exists at that time. The data
>>     providers would therefore like the Client software to
>>     authenticate me against SomeOrgs Identity Provider. This would be
>>     good proof that I am still a member of SomeOrg at the time I
>>     authenticate. This authentication would enable the data providers
>>     Authorization Server to grant me access appropriate to a member
>>     of SomeOrg.  Note that as a prerequisite to all of this, SomeOrg
>>     will have used an out-of-band process to set up a trust
>>     relationship for SomeOrg's Identity Provider with the data
>>     provider’s Authorization Service, and will have negotiated
>>     authorization claims to be granted to SomeOrgs members.
>>
>>     What I am having difficulty with is in knitting together an
>>     approach based on the he OpenID Connect specifications, SAML
>>     specifications, and OAuth RFCs and drafts in a way that supports
>>     the above use case end-to-end. The OAuth RFCs and drafts almost
>>     get me there. What seems to be missing is a way of telling an
>>     Identity Provider the URL for the Authorization Service (the
>>     required Audience claim in an authentication assertion as defined
>>     in RFCs 7251, 7252 and 7253), and then a requirement that the
>>     Identity Providers put the supplied Audience Identifier into
>>     Authentication Tokens. Perhaps a little further back-and-forth
>>     with Brian will resolve this.
>>
>>     I can go into deeper detail if needed. If this is off-topic for
>>     the OAuth working group, let me know.
>>
>>     Thanks,
>>     Andrew Fregly
>>     Verisign Inc.
>>
>>
>>     From: John Bradley 
>>     Date: Tuesday, April 19, 2016 at 2:06 PM
>>     To: Andrew Fregly 
>>     Cc: "oauth@ietf.org" >
>>     Subject: Re: [OAUTH-WG] Building on the protocol in the draft
>>     “OAuth 2.0 Token Exchange: An STS for the REST of Us†to include
>>     Authentication Tokens
>>
>>         Looking at OpenID Connect and it’s trust model for producing
>>         id_tokens that assert identity may help you.
>>         http://openid.net/wg/connect/
>>
>>         Unfortunately I can’t quite make out what you are trying to do.
>>
>>         It sort of sounds like you want an id_token from a idP and
>>         then have the client exchange that assertion for another token?
>>
>>         John B.
>>>         On Apr 19, 2016, at 1:18 PM, Fregly, Andrew
>>>         > wrote:
>>>
>>>         I have a use case where a client application needs to
>>>         authenticate with a dynamically determined Identity Provider
>>>         that is separate from the Authorization Service that will be
>>>         used issue an access token to the client. The use case also
>>>         requires that as part of authorization, the client provides
>>>         to the Authorization Service an authentication token signed
>>>         by an Identity Provider that the Authorization Service has a
>>>         trust relationship with. The trust relationship is
>>>         verifiable based on the Authorization Service having
>>>         recorded the public keys or certificates of trusted Identity
>>>         Providers in a trust store, this allowing the Authorization
>>>         Service to verify an Identity Provider’s signature on an
>>>         authentication token.
>>>         In looking at the various OAuth RFCs, particularly RFCs
>>>         7521, 7522, and 7523, I see that they get me close in terms
>>>         of supporting the use case. What is missing is a means for
>>>         solving the following problem. These RFCs require that the
>>>         Identity Provider put an Audience claim in the
>>>         authentication token. The problem with this is that I do not
>>>         see in the RFCs how the Identity Provider can be told who
>>>         the Audience is to put into the authentication token. This
>>>         leads me to the title of this message. The draft “OAuth 2.0
>>>         Token Exchange: An STS for the REST of Us†defines a
>>>         mechanism for identifying the Audience for an STS to put
>>>         into a token it generates. That would solve my problem
>>>         except that the draft limits the type of STS to being
>>>         Authorization Servers. What is needed is this same
>>>         capability for interacting with an Identity Provider. This
>>>         would enable RFCs 7521, 7522 and 7523 to be useful in
>>>         situation where the Identity Provider needs to be told the
>>>         identity of the Authorization Service.
>>>         I am new to interacting with the IETF. I also am not an
>>>         expert on the RFCs or prior history of the OAuth group
>>>         relative to this topic, so please point me to any existing
>>>         solution if this is a solved problem. Otherwise, I would
>>>         like to get feedback on my suggestion.
>>>         Thanks You,
>>>
>>>         Andrew Fregly
>>>         Verisign Inc.
>>>         _______________________________________________
>>>         OAuth mailing list
>>>         OAuth@ietf.org 
>>>         https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>


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


  
    
  
  
    I should probably just
      wait for the diagram... but not wanting to wait... :)

      

      If I understand correctly, the user is going to use a client and
      the client will authenticate the user via some IdP using an
      existing method (SAML, LDAP (?), OpenID Connect, etc). The desire
      is to take that response and in some way present it to an
      "Authorization Server" which will validate the "authentication
      response" and return an access token for use at the data provider(s).

      

      What if the Authorization Server also took on the role of the
      OpenID Connect provider. This could work by having the client
      start an OpenID Connect flow with Authorization Server (hints
      could be provided as to which IdP the user wants to authenticate
      at). The AS would look at the "idp hint" and either start and SP
      SAML flow, or present UI for collecting LDAP credentials (I don't
      recommend this) or chain to any other proprietary IdP flow. Once
      the user successfully authenticates with the correct IdP, the AS
      will finish the OpenID Connect flow allowing the client to obtain
      an access token, refresh token and id_token. The AS could add to
      the id_token a claim specifying which IdP the user used during the
      authentication processed.

      

      The IdP the user used for authentication could also be encoded in
      the access_token (or returned as part of an introspection call).

      

      This way whether the data providers are validating the
      access_tokens locally or using introspection they can obtain the
      IdP the user used and apply their own authorization rules.

      

      The user is only required to do one authorization flow for the
      client that is managed by the Authorization Server.

      

      Thanks,

      George

    

    
On 4/19/16 5:06 PM, Fregly, Andrew
      wrote:

    

    

      
      

        
Thank you for your response George. It points me to some
          more research to do, such as looking at OpenID Connect support
          for both distributed and aggregated claims.

        


        

        
Below are replies to your questions/assertions based on my
          current understanding of the various protocols. Further
          research and advice will likely enrich this significantly.

        


        

        
Yes, what is required is a verifiable claim that the user
          is still a member of SomeOrg Inc. I have been operating under
          the assumption that the only way this can be done would be to
          have the user authenticated by the Identity Provider for
          SomeOrg. Perhaps the research into OpenID Connect support for
          distributed and aggregated claims will reveal an alternative.
          I foresee a challenge in dealing with Identity Provider’s for
          organizations using SAML assertions on top of Active Directory
          and LDAP, and which are not going to do any updating to
          support our needs.

        

        

      

      


      

      
We do not expect the user to first go to the data provider.
        We anticipate that the client application would provide a
        Authentication Token to an  Authorization Service service that
        then issues to the client an access token that the data provider
        will trust. One of our reasons for doing it this way is that we
        are trying to eliminate redirects to ease implementation of a
        native client. We are therefore requiring the client to handle
        authentication with the Identity Provider as a separate step
        from authorization.

      


      

      
It might help if I clarified that Verisign’s role in the
        scenario I described is to be just one of many data providers.

      


      

      
        

          From: George Fletcher
          <gffletch@aol.com>

          Organization: AOL LLC

          Date: Tuesday, April
          19, 2016 at 4:18 PM

          To: Andrew Fregly <afregly@verisign.com>,
          John Bradley <ve7jtb@ve7jtb.com>, "oauth@ietf.org"
          <oauth@ietf.org>

          Subject: Re: [OAUTH-WG]
          Building on the protocol in the draft “OAuth 2.0 Token
          Exchange: An STS for the REST of Us†to include Authentication
          Tokens

        

        


        

        

          

            
So if I understand
                this correctly, what is really required is a verifiable
                claim that the user is still a member of SomeOrg Inc.
                OpenID Connect supports both distributed and aggregated
                claims that can be signed by the appropriate Identity
                Provider. The point being that I'm not sure an
                "authentication token" is required for this use case to
                succeed, it's just one kind of token that can be used.

                

                Also, is the expected flow that the user will first go
                to the data provider and then be directed else where
                from there? If that is the case, the data provider can
                just be an OpenID Connect relying party and give the
                user an option of the list of supported IdPs to choose
                from. The user will then be redirected to SomeOrg Inc.
                IdP, authenticate and the data provider will have the
                authorization and recent authentication they can
                validate.

                

                Is the user/data flow more complicated than this?

                

                Thanks,

                George

              

              
On 4/19/16 4:05 PM, Fregly,
                Andrew wrote:

              

              

                

                  
Thanks for your response John. I also got a good
                    response from Brian Campbell and appreciate that. I
                    will respond separately to Brian’s response as I
                    think it would keep things clearer to do that.

                  


                  

                  
The problem we have for using OpenID Connect is
                    that it combines the role of Authentication Service
                    with the role of Authorization Service. Perhaps the
                    following description of what we want to do will
                    clarify why this won’t work for us:

                  


                  

                  
The basic problem statement is that we need to
                    have a client application authorized by a Service
                    Provider based on proof that a user is currently a
                    member of some organization. This assumes the
                    organization has previously established some level
                    of authorized access with the Service Provider. 

                  


                  

                  
Here is an example: Suppose I am a member of
                    SomeOrg Inc. Suppose SomeOrg Inc. is doing research
                    that requires it to gather data over the Internet
                    from a number of data providers. The data providers
                    require authentication and proof of organizational
                    membership in order to authorize various levels of
                    access to their data. The data providers do not
                    consider having an account with them or a Public
                    Identity Provider to be suitable for proving that I
                    am still a member of SomeOrg at time of
                    authentication. They would have no way of knowing
                    whether or not my relationship with SomeOrg still
                    exists at that time. The data providers would
                    therefore like the Client software to authenticate
                    me against SomeOrgs Identity Provider. This would be
                    good proof that I am still a member of SomeOrg at
                    the time I authenticate. This authentication would
                    enable the data providers Authorization Server to
                    grant me access appropriate to a member of SomeOrg.
                     Note that as a prerequisite to all of this, SomeOrg
                    will have used an out-of-band process to set up a
                    trust relationship for SomeOrg's Identity Provider
                    with the data provider’s Authorization Service, and
                    will have negotiated authorization claims to be
                    granted to SomeOrgs members.

                  


                  

                  
What I am having difficulty with is in knitting
                    together an approach based on the he OpenID Connect
                    specifications, SAML specifications, and OAuth RFCs
                    and drafts in a way that supports the above use case
                    end-to-end. The OAuth RFCs and drafts almost get me
                    there. What seems to be missing is a way of telling
                    an Identity Provider the URL for the Authorization
                    Service (the required Audience claim in an
                    authentication assertion as defined in RFCs 7251,
                    7252 and 7253), and then a requirement that the
                    Identity Providers put the supplied Audience
                    Identifier into Authentication Tokens. Perhaps a
                    little further back-and-forth with Brian will
                    resolve this.

                  


                  

                  
I can go into deeper detail if needed. If this is
                    off-topic for the OAuth working group, let me know.

                  


                  

                  
Thanks,

                  
Andrew Fregly

                  
Verisign Inc.

                  


                  

                

                


                

                
                  

                    From: John
                    Bradley <ve7jtb@ve7jtb.com>

                    Date: Tuesday,
                    April 19, 2016 at 2:06 PM

                    To: Andrew
                    Fregly <afregly@verisign.com>

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

                    Subject: Re:
                    [OAUTH-WG] Building on the protocol in the draft
                    “OAuth 2.0 Token Exchange: An STS for the REST of
                    Us†to include Authentication Tokens

                  

                  


                  

                  

                    

                      

                        Looking at OpenID Connect and it’s trust model
                        for producing id_tokens that assert identity may
                        help you.
                        
http://openid.net/wg/connect/

                          


                          

                          
Unfortunately I can’t quite make
                            out what you are trying to do. 

                          


                          

                          
It sort of sounds like you want
                            an id_token from a idP and then have the
                            client exchange that assertion for another
                            token?

                          


                          

                          
John B.

                            

                              

                                
On Apr 19, 2016, at 1:18
                                  PM, Fregly, Andrew <afregly@verisign.com>
                                  wrote:

                                

                                

                                  

                                    

                                      I have a use case where
                                        a client application needs to
                                        authenticate with a dynamically
                                        determined Identity Provider
                                        that is separate from the
                                        Authorization Service that will
                                        be used issue an access token to
                                        the client. The use case also
                                        requires that as part of
                                        authorization, the client
                                        provides to the Authorization
                                        Service an authentication token
                                        signed by an Identity Provider
                                        that the Authorization Service
                                        has a trust relationship with.
                                        The trust relationship is
                                        verifiable based on the
                                        Authorization Service having
                                        recorded the public keys or
                                        certificates of trusted Identity
                                        Providers in a trust store, this
                                        allowing the Authorization
                                        Service to verify an Identity
                                        Provider’s signature on an
                                        authentication token.

                                    

                                      

                                    

                                       

                                    

                                      In looking at the various OAuth
                                      RFCs, particularly RFCs 7521,
                                      7522, and 7523, I see that they
                                      get me close in terms of
                                      supporting the use case. What is
                                      missing is a means for solving the
                                      following problem. These RFCs
                                      require that the Identity Provider
                                      put an Audience claim in the
                                      authentication token. The problem
                                      with this is that I do not see in
                                      the RFCs how the Identity Provider
                                      can be told who the Audience is to
                                      put into the authentication token.
                                      This leads me to the title of this
                                      message. The draft “OAuth 2.0
                                      Token Exchange: An STS for the
                                      REST of Us†defines a mechanism
                                      for identifying the Audience for
                                      an STS to put into a token it
                                      generates. That would solve my
                                      problem except that the draft
                                      limits the type of STS to being
                                      Authorization Servers. What is
                                      needed is this same capability for
                                      interacting with an Identity
                                      Provider. This would enable RFCs
                                      7521, 7522 and 7523 to be useful
                                      in situation where the Identity
                                      Provider needs to be told the
                                      identity of the Authorization
                                      Service.

                                    

                                       

                                    

                                      I am new to interacting with the
                                      IETF. I also am not an expert on
                                      the RFCs or prior history of the
                                      OAuth group relative to this
                                      topic, so please point me to any
                                      existing solution if this is a
                                      solved problem. Otherwise, I would
                                      like to get feedback on my
                                      suggestion.

                                    

                                       

                                    

                                      Thanks You,

                                    

                                      

                                    

                                    

                                      Andrew Fregly

                                    

                                      Verisign Inc.

                                  

                                  

                                  

                                  _______________________________________________

                                  OAuth mailing
                                    list

                                  OAuth@ietf.org

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

                              

                            

                            

                          

                        

                      

                    

                  

                

                

                

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

              

              

            

          

        

      
    

    

  


--------------080105020000080800020700--


From nobody Wed Apr 20 06:58:13 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C072812E564 for ; Wed, 20 Apr 2016 06:58:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6MO-BkO1zmc for ; Wed, 20 Apr 2016 06:58:07 -0700 (PDT)
Received: from mail-oi0-x264.google.com (mail-oi0-x264.google.com [IPv6:2607:f8b0:4003:c06::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 D478612D1B3 for ; Wed, 20 Apr 2016 06:58:06 -0700 (PDT)
Received: by mail-oi0-x264.google.com with SMTP id w133so2312565oie.0 for ; Wed, 20 Apr 2016 06:58:06 -0700 (PDT)
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:user-agent :mime-version; bh=xb9YLr0mdnOdBfy721GVeXOb4OSFdeejt9KUpyncnjc=; b=C/E4eXjFcj7YrzD96GJCyIToXkX4d1w5t/ubhDwELu6gWP12kvZ/8FqmsNoJcdhQym lZVAIrmFrM3ogROALgK470f2DVr63S7b5w/sR7SRdpSTKWpolxhAIpQMuJQ9ul2tWcwQ AntT6OUePSZcUzT3acTntkxBGXF0bhH6JFdlDh36Cx6jkTL9cpAWAZFFbjpdjl1JA7KI EHMPu0zvC/zaBlAdUOEc5zY7/NGQluhj1Rc8xt/QZ8s33/edidh526pfcOehFZhRyf55 M06X8K+IWPAby271bYpD5iK6Zaws4sXE7WlawU6zNthnG8XViCfB+2oD9uWUoeXjZAL0 h25w==
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 :user-agent:mime-version; bh=xb9YLr0mdnOdBfy721GVeXOb4OSFdeejt9KUpyncnjc=; b=YYkaAwMisZJUo/4oYxXeLzHOlhNvEHqwob0w4IIlHj2WChkeHyS1L/rWlVhpO0XKH1 YciW9nLMJLMQ7BJyq9rC9+LNJ3Q+2v+AjzGvpXxy11CLV/8lUfhn+yaw1qrLBzLaN7FR 0f+CIlVlz6RVm+8rnSzL2bRQ/2e3k8kiXAS5L9O1Y8dH00cSSyMpZ5PTt1BqRPbYHOSr gD2whtG84RBxBfo2K5Jr0rHOf+jYecv9ZnonGOTiuBGRw6iicql4mDQ0UORS+quEwPxI tKH6VZzsJIwO+ntnc4ds45NoL+0G6E5jfTj6uYt0nsXn1b+MGjVxMfAOwriGc1XQ9l4d X9lQ==
X-Gm-Message-State: AOPr4FUml9e56VihCcrEI6aRK3rFej1r/iAT3SCJSzpUA5XZHXUBtmQzmhdRmPPCf/hiAVnwM/nuEsgY4GoLwvzOuHEew+XI
X-Received: by 10.140.222.71 with SMTP id s68mr11652761qhb.49.1461160685649; Wed, 20 Apr 2016 06:58:05 -0700 (PDT)
Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id 13sm1619950qkg.5.2016.04.20.06.58.05 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 20 Apr 2016 06:58:05 -0700 (PDT)
X-Relaying-Domain: verisign.com
Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id u3KDw5St030633 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Apr 2016 09:58:05 -0400
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 20 Apr 2016 09:58:02 -0400
From: "Fregly, Andrew" 
To: Nat Sakimura , John Bradley , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Building on the protocol in the draft "OAuth 2.0 Token Exchange: An STS for the REST of Us" to include Authentication Tokens
Thread-Index: AQHRmnf3unJXk5gQwkmZNEmlF2rMzJ+RwM0AgABUFYCAAM97gA==
Date: Wed, 20 Apr 2016 13:58:01 +0000
Message-ID: 
References:   <8B748252-9AE2-4824-923B-00CD46CB8D68@verisign.com>  <5958E90F-EF8C-4641-96C1-A9077B450D53@verisign.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.160212
x-originating-ip: [10.173.152.4]
Content-Type: multipart/alternative; boundary="_000_ACF4DECCB69C4E3586D11FCDA0F56A5Cverisigncom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] Building on the protocol in the draft "OAuth 2.0 Token Exchange: An STS for the REST of Us" to include Authentication Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Apr 2016 13:58:12 -0000

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

VGhhbmsgeW91IGFnYWluIG9mIHlvdXIgaW5wdXQgTmF0Lg0KDQpGaXJzdCBvZiBhbGwsIEkgYXBv
bG9naXplIGZvciBjb25mdXNpbmcgdGhlIHNpdHVhdGlvbiBieSByZWZlcmVuY2luZyB0aGUgd3Jv
bmcgUkZDcyBpbiBhIHByaW9yIGVtYWlsLiBJIHRyYW5zcG9zZWQgdHdvIGRpZ2l0cy4gVGhlIFJG
Q3MgSSBtZWFudCB0byByZWZlcmVuY2Ugd2hlcmUgNzUyMS03NTIzIChzZWUgYmVsb3cpLg0KDQpJ
IGdldCB0aGF0IHRoZSBvcmlnaW5hbCBSRkMgZm9yIE9BdXRoIGhhcyB0aGUgbWVjaGFuaXNtIGZv
ciBjbGllbnQgYXV0aGVudGljYXRpb24gYmVpbmcgb3V0IG9mIHNjb3BlLiAgV2hhdCBpcyBtdWRk
eWluZyB0aGUgd2F0ZXIgZm9yIG1lIGlzIHRoYXQgUkZDcyA3NTIxLCA3NTIyLCBhbmQgNzUyMyBz
ZWVtIHRvIHNwZWNpZnkgdGhlIG1lYW5zIGJ5IHdoaWNoIGEgY2xpZW50IGNhbiBwcm92aWRlIGFu
IGF1dGhlbnRpY2F0aW9uIHRva2VuIHRvIGFuIEF1dGhvcml6YXRpb24gU2VydmljZS4gVGhpcyBw
dXJwb3NlIGlzIHN0YXRlZCBhdCB0aGUgdG9wIG9mIHRoZSBhYnN0cmFjdCBmb3IgUkZDIDc1MjE6
DQoNCiJUaGUgaW50ZW50IG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyB0byBwcm92aWRlIGEgY29t
bW9uIGZyYW1ld29yayBmb3IgT0F1dGggMi4wIHRvIGludGVyd29yayB3aXRoIG90aGVyIGlkZW50
aXR5IHN5c3RlbXMgdXNpbmcgYXNzZXJ0aW9ucyBhbmQgdG8gcHJvdmlkZSBhbHRlcm5hdGl2ZSBj
bGllbnQgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtcy7igJ0NCg0KSW4gb3VyIHVzZSBjYXNlLCB3
ZSBuZWVkIHRvIGhhdmUgdXNlcnMgYXV0aGVudGljYXRlZCBhZ2FpbnN0IGlkZW50aXR5IHByb3Zp
ZGVycyB0aGF0IG9yZ2FuaXphdGlvbnMgdXNlIGludGVybmFsbHkgYXMgdGhlIG1lYW5zIGZvciBh
dXRoZW50aWNhdGluZyBjbGllbnRzIGFjY2Vzc2luZyBvdXIgc2VydmljZS4gV2UgbmVlZCB0aGlz
IGJlY2F1c2Ugd2UgYmVsaWV2ZSB0aGlzIGlzIHRoZSBiZXN0IG1lYW5zIGZvciBwcm92aW5nIGEg
dXNlciBpcyBzdGlsbCBhIG1lbWJlciBvZiBhbiBvcmdhbml6YXRpb24gYXQgdGhlIHRpbWUgdGhl
eSBhdXRoZW50aWNhdGUuIE1vc3QsIHBlcmhhcHMgYWxsIG9mIHRoZXNlIG9yZ2FuaXphdGlvbnMs
IHdpbGwgaW50ZXJuYWxseSB1c2UgYW4gSWRlbnRpdHkgUHJvdmlkZXIgdGhhdCBwcm92aWRlcyBT
QU1MIGF1dGhlbnRpY2F0aW9uIGFzc2VydGlvbnMuIFRoaXMgbGVkIG1lIHRvIGxvb2tpbmcgZm9y
IGEgd2F5IHRvIHVzZSBhdXRoZW50aWNhdGlvbiB0b2tlbnMgcHJvZHVjZWQgYnkgaW50ZXJuYWwg
SWRlbnRpdHkgUHJvdmlkZXJzIGFzIGEgbWVhbnMgZm9yIHByb3ZpbmcgYSBjbGllbnQgaGFkIGJl
ZW4gYXV0aGVudGljYXRlZCBieSB0aGUgb3JnYW5pemF0aW9uLiBBIGJpdCBvZiBpbnZlc3RpZ2F0
aW9uIGluIGhvdyB0aGlzIG1pZ2h0IGJlIGRvbmUgbGVkIG1lIHRvIE9BdXRoIFJGQ3MgNzUyMSwg
NzUyMiBhbmQgNzUyMy4gVGhleSAgYWxtb3N0IGdldCBtZSB0aGVyZS4gVGhleSBzcGVjaWZ5IHdo
YXQgbmVlZHMgdG8gYmUgaW4gYW4gQXV0aGVudGljYXRpb24gdG9rZW4gdGhhdCBpcyBnaXZlbiBi
eSBhIGNsaWVudCB0byBhbiBBdXRob3JpemF0aW9uIFNlcnZpY2UuIFRoZSBnb3RjaGEgd2FzIHRo
YXQgdGhlc2UgUkZDcyByZXF1aXJlIGFuIGF1ZGllbmNlIGNsYWltIGluIHRoZSBhdXRoZW50aWNh
dGlvbiB0b2tlbi4gVGhpcyBhdWRpZW5jZSBjbGFpbSBpcyB1c2VkIHRvIGlkZW50aWZ5IHRoZSBz
cGVjaWZpYyBBdXRob3JpemF0aW9uIFNlcnZpY2UgdGhlIHRva2VuIGlzIG1lYW50IGZvci4gRm9y
IHRoaXMgYXVkaWVuY2UgY2xhaW0gdG8gZ2V0IGZpbGxlZCBpbiBieSBzb21lIGFyYml0cmFyeSBv
cmdhbml6YXRpb27igJlzIElkZW50aXR5IFByb3ZpZGVyLCBpdCBzZWVtcyB0aGUgSWRlbnRpdHkg
UHJvdmlkZXIgd2lsbCBuZWVkIHRvIGJlIHRvbGQgd2hvIHRoZSBBdXRob3JpemF0aW9uIFNlcnZp
Y2UgaXMgYnkgdGhlIGNsaWVudCBpbml0aWF0aW5nIHRoZSBhdXRoZW50aWNhdGlvbi4gSSBoYXZl
IHRoZXJlZm9yZSBiZWVuIGxvb2tpbmcgZm9yIGEgc3RhbmRhcmQgdGhhdCBzcGVjaWZpZXMgaG93
IGEgY2xpZW50IGNhbiB0ZWxsIHRoZSBJZGVudGl0eSBQcm92aWRlciB0aGUgaWRlbnRpdHkgb2Yg
dGhlIEF1dGhvcml6YXRpb24gU2VydmljZS4gSSB3YXMgc3R1Y2sgZm9yIGEgYml0IG9uIGhvdyB0
aGUgSUVURiBPQXV0aCB3b3JraW5nIGdyb3VwIGNvdWxkIGFkZHJlc3MgdGhpcyBpc3N1ZSBzaW5j
ZSBhdXRoZW50aWNhdGlvbiBzZWVtZWQgdG8gYmUgb3V0IG9mIHNjb3BlIGZvciB0aGUgZ3JvdXAu
IFRoZW4gSSBmb3VuZCB0aGUgIElFVEYgZHJhZnQgIk9BdXRoIDIuMCBUb2tlbiBFeGNoYW5nZTog
QW4gU1RTIGZvciB0aGUgUkVTVCBvZiBVc+KAnS4gSXQgZGVmaW5lcyBhIG1lY2hhbmlzbSBmb3Ig
dGVsbGluZyBhIFNlY3VyaXR5IFRva2VuIFNlcnZpY2UgdGhlIGF1ZGllbmNlIGZvciB0aGUgdG9r
ZW4gaXQgaXMgYmVpbmcgYXNrZWQgdG8gaXNzdWUuIEkgdGhvdWdodCB0aGF0IHdvdWxkIHNvbHZl
IG15IHByb2JsZW0gc2luY2UgYW4gaW50ZW50IG9mIHRoZSBkcmFmdCBzZWVtZWQgdG8gYmUgb24g
Z2VuZXJhbGl6aW5nIHRoZSBkZXNjcmliZWQgYXBwcm9hY2ggdG8gYW55IHR5cGUgb2YgU2VjdXJp
dHkgVG9rZW4gU2VydmljZS4gVGhlcmUgd2FzIG9uZSBnb3RjaGEgaW4gdGhlIGRyYWZ0IHRob3Vn
aC4gSXQgbGltaXRlZCB0aGUgdHlwZSBvZiBTVFMgdG8gd2hpY2ggdGhlIHByb3RvY29sIGFwcGxp
ZWQgdG8gYmUganVzdCBBdXRob3JpemF0aW9uIFNlcnZpY2VzLiBGb3IgbXkgdXNlIGNhc2UsIEkg
bmVlZGVkIHRoZSBjYXBhYmlsaXR5IGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQsIGJ1dCBhcHBsaWNh
YmxlIHRvIElkZW50aXR5IFByb3ZpZGVycyB0b28uIElmIGl0IHdlcmUgYXBwbGljYWJsZSB0byBJ
ZGVudGl0eSBQcm92aWRlcnMsIHRoZXJlIHdvdWxkIHRoZW4gYmUgYSBmdWxsIHNldCBvZiBleGlz
dGluZyBSRkNzIGFuZCBkcmFmdHMgdGhhdCBjb3ZlcmVkIHRoZSBmdW5jdGlvbmFsaXR5IG5lZWRl
ZCBmb3Igb3VyIHVzZSBjYXNlLg0KDQpUaGVyZSBhcmUgYSBjb3VwbGUgb2YgcG9zc2libGUgYWN0
aW9ucyB0aGF0IEkgaGF2ZSBiZWVuIGNvbnRlbXBsYXRpbmcgcmVsYXRpdmUgdG8gT0F1dGg6DQoN
CiAgMS4gIFdyaXRlIGV4dGVuc2lvbnMgdG8gUkZDcyA3NTIxLCA3NTIyIGFuZCA3NTIzIHRoYXQg
ZWxpbWluYXRlIHRoZSBuZWVkIGZvciBhbiBhdWRpZW5jZSBjbGFpbSBpbiB0aGUgYXV0aGVudGlj
YXRpb24gdG9rZW4gaWYgdGhlIEF1dGhvcml6YXRpb24gU2VydmljZSBoYXMgYSB0cnVzdCByZWxh
dGlvbnNoaXAgd2l0aCB0aGUgSWRlbnRpdHkgUHJvdmlkZXIgdGhhdCBpc3N1ZWQgdGhlIGF1dGhl
bnRpY2F0aW9uIHRva2VuLg0KICAyLiAgQXNrIHRoZSBhdXRob3JzIG9mIHRoZSDigJxPQXV0aCAy
LjAgVG9rZW4gRXhjaGFuZ2U6IEFuIFNUUyBmb3IgdGhlIFJFU1Qgb2YgVXPigJ0gdG8gZXhwbGlj
aXRseSBzdGF0ZSB0aGF0IHRoZSB0aGUgYXBwcm9hY2ggZGVzY3JpYmVkIHRoZXJlLWluIGlzIGFw
cGxpY2FibGUgdG8gYm90aCBJZGVudGl0eSBQcm92aWRlcnMgYW5kIEF1dGhvcml6YXRpb24gc2Vy
dmljZXMuDQoNCkJlZm9yZSBkb2luZyBlaXRoZXIgb2YgdGhlc2Ugc3RlcHMsIEkgd2FudCB0byBt
YWtlIHN1cmUgdGhhdCBJIGFtIG5vdCBtaXNzaW5nIHNvbWV0aGluZyBpbiBleGlzdGluZyBSRkNz
IGFuZCBkcmFmdHMgdGhhdCB3b3VsZCBhZGRyZXNzIG91ciB1c2UgY2FzZS4gSSBoYXZlIG9ubHkg
YmVlbiBsb29raW5nIGF0IHRoaXMgaXNzdWUgZm9yIGEgZmV3IHdlZWtzLCBzbyBJIHRob3VnaHQg
aXQgd291bGQgYmUgYmVzdCB0byBnbyB0byB0aGUgZXhwZXJ0cyB0byBnZXQgYWR2aWNlLiBUaGlz
IGxlZCB0byB0aGlzIGVtYWlsIGNoYWluLg0KDQpUaGFua3MgdG8gYWxsIGZvbGxvd2luZyB0aGlz
IGNoYWluIGZvciB5b3VyIHRpbWUgYW5kIGNvbnNpZGVyYXRpb24gb24gdGhpcyENCg0KQW5keQ0K
DQpGcm9tOiBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86c2FraW11cmFA
Z21haWwuY29tPj4NCkRhdGU6IFR1ZXNkYXksIEFwcmlsIDE5LCAyMDE2IGF0IDU6MzUgUE0NClRv
OiBBbmRyZXcgRnJlZ2x5IDxhZnJlZ2x5QHZlcmlzaWduLmNvbTxtYWlsdG86YWZyZWdseUB2ZXJp
c2lnbi5jb20+PiwgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRi
QHZlN2p0Yi5jb20+PiwgIm9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4iIDxv
YXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVU
SC1XR10gQnVpbGRpbmcgb24gdGhlIHByb3RvY29sIGluIHRoZSBkcmFmdCAiT0F1dGggMi4wIFRv
a2VuIEV4Y2hhbmdlOiBBbiBTVFMgZm9yIHRoZSBSRVNUIG9mIFVzIiB0byBpbmNsdWRlIEF1dGhl
bnRpY2F0aW9uIFRva2Vucw0KDQpIaSBBbmRyZXcsDQoNCkluIE9BdXRoIDIuMCwgdGhlIHJlc291
cmNlIG93bmVyIGF1dGhlbnRpY2F0aW9uIC9lbmQgdXNlciBhdXRoZW50aWNhdGlvbiBpcyBvdXQg
b2Ygc2NvcGUuIFdoYXQgaXQgZGVhbHMgd2l0aCBpcyAiY2xpZW50IGF1dGhlbnRpY2F0aW9uIi4g
VGhleSBzaG91bGQgbm90IGJlIG1peGVkIHVwLiBUaGVyZSBpcyBubyBlbmQgdXNlciBpZGVudGl0
eSBub3IgYXV0aGVudGljYXRpb24gdG9rZW4gaW4gdGhlIE9BdXRoLiBZb3UgY2Fubm90IGRvIGVu
ZCB1c2VyIGF1dGhlbnRpY2F0aW9uIHdpdGggcHVyZSBPQXV0aC4gRm9yIHRoYXQsIHlvdSBoYXZl
IHRvIHJlbHkgb24gc29tZXRoaW5nIGxpa2UgT3BlbklEIENvbm5lY3QuDQoNCkFzIEpvaG4gbm90
ZWQsIGl0IGlzIHBlcmZlY3RseSBmaW5lIHRvIGNoYWluIHRoZSBleHRlcm5hbCBhdXRoZW50aWNh
dGlvbiBhbmQgdGhlIGludGVybmFsIGF1dGhvcml6YXRpb24uIEl0IGlzIG9mdGVuIGRvbmUuIEl0
IGlzIGp1c3QgdGhhdCB0aGUgUkZDNjc0OSBBdXRoeiBzZXJ2ZXIgaXMgYW4gUlAgb2YgT3BlbklE
IENvbm5lY3Qgb3IgU1Agb2YgU0FNTC4gTm90aGluZyBwcmVjbHVkZXMgaXQuDQoNCklmIHlvdSBy
ZWFsbHkgd2FudCB0byBhdm9pZCB0aGUgZnJvbnQgY2hhbm5lbCByZS1hdXRoIHdpdGggcHJvbXB0
PW5vbmUsIHdoaWNoIGlzIG1vcmUgc2VjdXJlIGFuZCBwcm9wZXIgd2F5cyB0byBkbywgYnV0IGp1
c3QgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIHVzZXIgc3RpbGwgZXhpc3RzIGluIHRoZSBhdXRoZW50
aWNhdGlvbiBzZXJ2aWNlLCB5b3UgY2FuIGluZmVyIGl0IGJ5IG1ha2luZyBhIHVzZXJpbmZvIHJl
cXVlc3QgdG8gdGhlIHVzZXJpbmZvIGVuZHBvaW50IG9mIE9wZW5JRCBDb25uZWN0LiBJdCB3b3Vs
ZCBmYWlsIGluIHZhcmlvdXMgcmVhc29ucywgYnV0IHdvdWxkIGNlcnRhaW5seSBmYWlsIGlmIHRo
ZSB1c2VyIGRvZXMgbm90IGV4aXN0IGFueW1vcmUuIE90aGVyIGVycm9yIGNvbmRpdGlvbnMgbGlr
ZSB0aGUgdXNlciByZXZva2VkIHRoZSBhY2Nlc3MvcmVmcmVzaCB0b2tlbiBldGMuIHdvdWxkIGNh
dXNlIHRoZSBzYW1lIGludmFsaWRfdG9rZW4gZXJyb3IgdGhvdWdoLg0KDQpCZXN0LA0KDQpOYXQN
Cg0KUC5TLiBJIGRvIG5vdCBzZWUgd2h5IHRoZSBSRkNzIHlvdSBzaXRlZCBhcmUgcmVsZXZhbnQg
aGVyZS4gSSBndWVzcyB5b3UgYXJlIHRhbGtpbmcgYWJvdXQgUkZDNzUyMS03NTIzIDstKQ0KDQpS
RkM3MjUxIEFFUy1DQ00gRWxsaXB0aWMgQ3VydmUgQ3J5cHRvZ3JhcGh5IChFQ0MpIENpcGhlciBT
dWl0ZXMgZm9yIFRMUw0KUkZDNzI1MiBUaGUgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9j
b2wgKENvQVApDQpSRkM3MjUzIFRoZSBPQ0IgQXV0aGVudGljYXRlZC1FbmNyeXB0aW9uIEFsZ29y
aXRobQ0KDQoNCg0KDQoNCg0KDQoyMDE25bm0NOaciDIw5pelKOawtCkgNTozNCBGcmVnbHksIEFu
ZHJldyA8YWZyZWdseUB2ZXJpc2lnbi5jb208bWFpbHRvOmFmcmVnbHlAdmVyaXNpZ24uY29tPj46
DQpUaGFua3MgZm9yIHlvdXIgcmVwbHkgTmF0Lg0KDQpEb2VzIHlvdXIgYXBwcm9hY2ggbWF0Y2gg
d2l0aCBhbiBJRVRGIE9BdXRoIFJGQyBvciBEcmFmdCBkZXNjcmliaW5nIGhvdyBhbiBBdXRob3Jp
emF0aW9uIFNlcnZpY2UgY2FuIGFjY2VwdCBhbmQgdmVyaWZ5IGFuIGF1dGhlbnRpY2F0aW9uIHRv
a2VuIHByb3ZpZGVkIGJ5IGEgY2xpZW50IGR1cmluZyB0aGUgYXV0aG9yaXphdGlvbiBwcm9jZXNz
PyBJZiBzbywgcGxlYXNlIHBvaW50IG1lIHRvIHRoYXQuIFRoZSBvbmx5IFJGQ3MgSSBoYXZlIHNl
ZW4gdGhhdCBhZGRyZXNzIHRoaXMgYXJlIFJGQ3MgNzI1MSwgNzI1MiBhbmQgNzI1MywgYW5kIHRo
ZXkgYWxsIGhhdmUgYSByZXF1aXJlbWVudCB0aGF0IGFuIOKAnGF1ZGllbmNl4oCdIGNsYWltIGNv
cnJlc3BvbmRpbmcgdG8gdGhlIEF1dGhvcml6YXRpb24gU2VydmljZSBpcyBpbiB0aGUgYXV0aGVu
dGljYXRpb24gdG9rZW4uIEdldHRpbmcgdGhhdCBjbGFpbSBpbnRvIGFuIGF1dGhlbnRpY2F0aW9u
IHRva2VuIHByb3ZpZGVkIGJ5IGFuIE9yZ2FuaXphdGlvbuKAmXMgSWRlbnRpdHkgcHJvdmlkZXIg
c2VlbXMgdG8gYmUgbXkgZnVuZGFtZW50YWwgcHJvYmxlbS4NCg0KVGhhbmtzLA0KICAgICAgQW5k
eQ0KDQpGcm9tOiBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86c2FraW11
cmFAZ21haWwuY29tPj4NCkRhdGU6IFR1ZXNkYXksIEFwcmlsIDE5LCAyMDE2IGF0IDQ6MTMgUE0N
ClRvOiBBbmRyZXcgRnJlZ2x5IDxhZnJlZ2x5QHZlcmlzaWduLmNvbTxtYWlsdG86YWZyZWdseUB2
ZXJpc2lnbi5jb20+PiwgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3
anRiQHZlN2p0Yi5jb20+PiwgIm9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4i
IDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KDQpTdWJqZWN0OiBSZTog
W09BVVRILVdHXSBCdWlsZGluZyBvbiB0aGUgcHJvdG9jb2wgaW4gdGhlIGRyYWZ0ICJPQXV0aCAy
LjAgVG9rZW4gRXhjaGFuZ2U6IEFuIFNUUyBmb3IgdGhlIFJFU1Qgb2YgVXMiIHRvIGluY2x1ZGUg
QXV0aGVudGljYXRpb24gVG9rZW5zDQoNCkdldCBPcGVuSUQgQ29ubmVjdCBpZF90b2tlbiBieSB0
aGUgYXV0aGVudGljYXRpb24gcmVxdWVzdCB3aXRoIHByb21wdD1ub25lIGFuZCB2ZXJpZnlpbmcg
dGhlIHN1YiB0byBiZSB0aGUgc2FtZSB3aXRoIHdoYXQgeW91IGV4cGVjdGVkIHNlZW0gdG8gc3Vm
ZmljZSB5b3VyIG5lZWRzLiBBbSBJIG1pc3Npbmcgc29tZXRoaW5nPw0KT24gV2VkLCBBcHIgMjAs
IDIwMTYgYXQgMDU6MDUgRnJlZ2x5LCBBbmRyZXcgPGFmcmVnbHlAdmVyaXNpZ24uY29tPG1haWx0
bzphZnJlZ2x5QHZlcmlzaWduLmNvbT4+IHdyb3RlOg0KVGhhbmtzIGZvciB5b3VyIHJlc3BvbnNl
IEpvaG4uIEkgYWxzbyBnb3QgYSBnb29kIHJlc3BvbnNlIGZyb20gQnJpYW4gQ2FtcGJlbGwgYW5k
IGFwcHJlY2lhdGUgdGhhdC4gSSB3aWxsIHJlc3BvbmQgc2VwYXJhdGVseSB0byBCcmlhbuKAmXMg
cmVzcG9uc2UgYXMgSSB0aGluayBpdCB3b3VsZCBrZWVwIHRoaW5ncyBjbGVhcmVyIHRvIGRvIHRo
YXQuDQoNClRoZSBwcm9ibGVtIHdlIGhhdmUgZm9yIHVzaW5nIE9wZW5JRCBDb25uZWN0IGlzIHRo
YXQgaXQgY29tYmluZXMgdGhlIHJvbGUgb2YgQXV0aGVudGljYXRpb24gU2VydmljZSB3aXRoIHRo
ZSByb2xlIG9mIEF1dGhvcml6YXRpb24gU2VydmljZS4gUGVyaGFwcyB0aGUgZm9sbG93aW5nIGRl
c2NyaXB0aW9uIG9mIHdoYXQgd2Ugd2FudCB0byBkbyB3aWxsIGNsYXJpZnkgd2h5IHRoaXMgd29u
4oCZdCB3b3JrIGZvciB1czoNCg0KVGhlIGJhc2ljIHByb2JsZW0gc3RhdGVtZW50IGlzIHRoYXQg
d2UgbmVlZCB0byBoYXZlIGEgY2xpZW50IGFwcGxpY2F0aW9uIGF1dGhvcml6ZWQgYnkgYSBTZXJ2
aWNlIFByb3ZpZGVyIGJhc2VkIG9uIHByb29mIHRoYXQgYSB1c2VyIGlzIGN1cnJlbnRseSBhIG1l
bWJlciBvZiBzb21lIG9yZ2FuaXphdGlvbi4gVGhpcyBhc3N1bWVzIHRoZSBvcmdhbml6YXRpb24g
aGFzIHByZXZpb3VzbHkgZXN0YWJsaXNoZWQgc29tZSBsZXZlbCBvZiBhdXRob3JpemVkIGFjY2Vz
cyB3aXRoIHRoZSBTZXJ2aWNlIFByb3ZpZGVyLg0KDQpIZXJlIGlzIGFuIGV4YW1wbGU6IFN1cHBv
c2UgSSBhbSBhIG1lbWJlciBvZiBTb21lT3JnIEluYy4gU3VwcG9zZSBTb21lT3JnIEluYy4gaXMg
ZG9pbmcgcmVzZWFyY2ggdGhhdCByZXF1aXJlcyBpdCB0byBnYXRoZXIgZGF0YSBvdmVyIHRoZSBJ
bnRlcm5ldCBmcm9tIGEgbnVtYmVyIG9mIGRhdGEgcHJvdmlkZXJzLiBUaGUgZGF0YSBwcm92aWRl
cnMgcmVxdWlyZSBhdXRoZW50aWNhdGlvbiBhbmQgcHJvb2Ygb2Ygb3JnYW5pemF0aW9uYWwgbWVt
YmVyc2hpcCBpbiBvcmRlciB0byBhdXRob3JpemUgdmFyaW91cyBsZXZlbHMgb2YgYWNjZXNzIHRv
IHRoZWlyIGRhdGEuIFRoZSBkYXRhIHByb3ZpZGVycyBkbyBub3QgY29uc2lkZXIgaGF2aW5nIGFu
IGFjY291bnQgd2l0aCB0aGVtIG9yIGEgUHVibGljIElkZW50aXR5IFByb3ZpZGVyIHRvIGJlIHN1
aXRhYmxlIGZvciBwcm92aW5nIHRoYXQgSSBhbSBzdGlsbCBhIG1lbWJlciBvZiBTb21lT3JnIGF0
IHRpbWUgb2YgYXV0aGVudGljYXRpb24uIFRoZXkgd291bGQgaGF2ZSBubyB3YXkgb2Yga25vd2lu
ZyB3aGV0aGVyIG9yIG5vdCBteSByZWxhdGlvbnNoaXAgd2l0aCBTb21lT3JnIHN0aWxsIGV4aXN0
cyBhdCB0aGF0IHRpbWUuIFRoZSBkYXRhIHByb3ZpZGVycyB3b3VsZCB0aGVyZWZvcmUgbGlrZSB0
aGUgQ2xpZW50IHNvZnR3YXJlIHRvIGF1dGhlbnRpY2F0ZSBtZSBhZ2FpbnN0IFNvbWVPcmdzIElk
ZW50aXR5IFByb3ZpZGVyLiBUaGlzIHdvdWxkIGJlIGdvb2QgcHJvb2YgdGhhdCBJIGFtIHN0aWxs
IGEgbWVtYmVyIG9mIFNvbWVPcmcgYXQgdGhlIHRpbWUgSSBhdXRoZW50aWNhdGUuIFRoaXMgYXV0
aGVudGljYXRpb24gd291bGQgZW5hYmxlIHRoZSBkYXRhIHByb3ZpZGVycyBBdXRob3JpemF0aW9u
IFNlcnZlciB0byBncmFudCBtZSBhY2Nlc3MgYXBwcm9wcmlhdGUgdG8gYSBtZW1iZXIgb2YgU29t
ZU9yZy4gIE5vdGUgdGhhdCBhcyBhIHByZXJlcXVpc2l0ZSB0byBhbGwgb2YgdGhpcywgU29tZU9y
ZyB3aWxsIGhhdmUgdXNlZCBhbiBvdXQtb2YtYmFuZCBwcm9jZXNzIHRvIHNldCB1cCBhIHRydXN0
IHJlbGF0aW9uc2hpcCBmb3IgU29tZU9yZydzIElkZW50aXR5IFByb3ZpZGVyIHdpdGggdGhlIGRh
dGEgcHJvdmlkZXLigJlzIEF1dGhvcml6YXRpb24gU2VydmljZSwgYW5kIHdpbGwgaGF2ZSBuZWdv
dGlhdGVkIGF1dGhvcml6YXRpb24gY2xhaW1zIHRvIGJlIGdyYW50ZWQgdG8gU29tZU9yZ3MgbWVt
YmVycy4NCg0KV2hhdCBJIGFtIGhhdmluZyBkaWZmaWN1bHR5IHdpdGggaXMgaW4ga25pdHRpbmcg
dG9nZXRoZXIgYW4gYXBwcm9hY2ggYmFzZWQgb24gdGhlIGhlIE9wZW5JRCBDb25uZWN0IHNwZWNp
ZmljYXRpb25zLCBTQU1MIHNwZWNpZmljYXRpb25zLCBhbmQgT0F1dGggUkZDcyBhbmQgZHJhZnRz
IGluIGEgd2F5IHRoYXQgc3VwcG9ydHMgdGhlIGFib3ZlIHVzZSBjYXNlIGVuZC10by1lbmQuIFRo
ZSBPQXV0aCBSRkNzIGFuZCBkcmFmdHMgYWxtb3N0IGdldCBtZSB0aGVyZS4gV2hhdCBzZWVtcyB0
byBiZSBtaXNzaW5nIGlzIGEgd2F5IG9mIHRlbGxpbmcgYW4gSWRlbnRpdHkgUHJvdmlkZXIgdGhl
IFVSTCBmb3IgdGhlIEF1dGhvcml6YXRpb24gU2VydmljZSAodGhlIHJlcXVpcmVkIEF1ZGllbmNl
IGNsYWltIGluIGFuIGF1dGhlbnRpY2F0aW9uIGFzc2VydGlvbiBhcyBkZWZpbmVkIGluIFJGQ3Mg
NzI1MSwgNzI1MiBhbmQgNzI1MyksIGFuZCB0aGVuIGEgcmVxdWlyZW1lbnQgdGhhdCB0aGUgSWRl
bnRpdHkgUHJvdmlkZXJzIHB1dCB0aGUgc3VwcGxpZWQgQXVkaWVuY2UgSWRlbnRpZmllciBpbnRv
IEF1dGhlbnRpY2F0aW9uIFRva2Vucy4gUGVyaGFwcyBhIGxpdHRsZSBmdXJ0aGVyIGJhY2stYW5k
LWZvcnRoIHdpdGggQnJpYW4gd2lsbCByZXNvbHZlIHRoaXMuDQoNCkkgY2FuIGdvIGludG8gZGVl
cGVyIGRldGFpbCBpZiBuZWVkZWQuIElmIHRoaXMgaXMgb2ZmLXRvcGljIGZvciB0aGUgT0F1dGgg
d29ya2luZyBncm91cCwgbGV0IG1lIGtub3cuDQoNClRoYW5rcywNCkFuZHJldyBGcmVnbHkNClZl
cmlzaWduIEluYy4NCg0KDQpGcm9tOiBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1h
aWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBBcHJpbCAxOSwgMjAxNiBh
dCAyOjA2IFBNDQpUbzogQW5kcmV3IEZyZWdseSA8YWZyZWdseUB2ZXJpc2lnbi5jb208bWFpbHRv
OmFmcmVnbHlAdmVyaXNpZ24uY29tPj4NCkNjOiAib2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRo
QGlldGYub3JnPiIgPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJq
ZWN0OiBSZTogW09BVVRILVdHXSBCdWlsZGluZyBvbiB0aGUgcHJvdG9jb2wgaW4gdGhlIGRyYWZ0
IOKAnE9BdXRoIDIuMCBUb2tlbiBFeGNoYW5nZTogQW4gU1RTIGZvciB0aGUgUkVTVCBvZiBVc+KA
nSB0byBpbmNsdWRlIEF1dGhlbnRpY2F0aW9uIFRva2Vucw0KDQpMb29raW5nIGF0IE9wZW5JRCBD
b25uZWN0IGFuZCBpdOKAmXMgdHJ1c3QgbW9kZWwgZm9yIHByb2R1Y2luZyBpZF90b2tlbnMgdGhh
dCBhc3NlcnQgaWRlbnRpdHkgbWF5IGhlbHAgeW91Lg0KaHR0cDovL29wZW5pZC5uZXQvd2cvY29u
bmVjdC8NCg0KVW5mb3J0dW5hdGVseSBJIGNhbuKAmXQgcXVpdGUgbWFrZSBvdXQgd2hhdCB5b3Ug
YXJlIHRyeWluZyB0byBkby4NCg0KSXQgc29ydCBvZiBzb3VuZHMgbGlrZSB5b3Ugd2FudCBhbiBp
ZF90b2tlbiBmcm9tIGEgaWRQIGFuZCB0aGVuIGhhdmUgdGhlIGNsaWVudCBleGNoYW5nZSB0aGF0
IGFzc2VydGlvbiBmb3IgYW5vdGhlciB0b2tlbj8NCg0KSm9obiBCLg0KT24gQXByIDE5LCAyMDE2
LCBhdCAxOjE4IFBNLCBGcmVnbHksIEFuZHJldyA8YWZyZWdseUB2ZXJpc2lnbi5jb208bWFpbHRv
OmFmcmVnbHlAdmVyaXNpZ24uY29tPj4gd3JvdGU6DQoNCkkgaGF2ZSBhIHVzZSBjYXNlIHdoZXJl
IGEgY2xpZW50IGFwcGxpY2F0aW9uIG5lZWRzIHRvIGF1dGhlbnRpY2F0ZSB3aXRoIGEgZHluYW1p
Y2FsbHkgZGV0ZXJtaW5lZCBJZGVudGl0eSBQcm92aWRlciB0aGF0IGlzIHNlcGFyYXRlIGZyb20g
dGhlIEF1dGhvcml6YXRpb24gU2VydmljZSB0aGF0IHdpbGwgYmUgdXNlZCBpc3N1ZSBhbiBhY2Nl
c3MgdG9rZW4gdG8gdGhlIGNsaWVudC4gVGhlIHVzZSBjYXNlIGFsc28gcmVxdWlyZXMgdGhhdCBh
cyBwYXJ0IG9mIGF1dGhvcml6YXRpb24sIHRoZSBjbGllbnQgcHJvdmlkZXMgdG8gdGhlIEF1dGhv
cml6YXRpb24gU2VydmljZSBhbiBhdXRoZW50aWNhdGlvbiB0b2tlbiBzaWduZWQgYnkgYW4gSWRl
bnRpdHkgUHJvdmlkZXIgdGhhdCB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2aWNlIGhhcyBhIHRydXN0
IHJlbGF0aW9uc2hpcCB3aXRoLiBUaGUgdHJ1c3QgcmVsYXRpb25zaGlwIGlzIHZlcmlmaWFibGUg
YmFzZWQgb24gdGhlIEF1dGhvcml6YXRpb24gU2VydmljZSBoYXZpbmcgcmVjb3JkZWQgdGhlIHB1
YmxpYyBrZXlzIG9yIGNlcnRpZmljYXRlcyBvZiB0cnVzdGVkIElkZW50aXR5IFByb3ZpZGVycyBp
biBhIHRydXN0IHN0b3JlLCB0aGlzIGFsbG93aW5nIHRoZSBBdXRob3JpemF0aW9uIFNlcnZpY2Ug
dG8gdmVyaWZ5IGFuIElkZW50aXR5IFByb3ZpZGVy4oCZcyBzaWduYXR1cmUgb24gYW4gYXV0aGVu
dGljYXRpb24gdG9rZW4uDQoNCkluIGxvb2tpbmcgYXQgdGhlIHZhcmlvdXMgT0F1dGggUkZDcywg
cGFydGljdWxhcmx5IFJGQ3MgNzUyMSwgNzUyMiwgYW5kIDc1MjMsIEkgc2VlIHRoYXQgdGhleSBn
ZXQgbWUgY2xvc2UgaW4gdGVybXMgb2Ygc3VwcG9ydGluZyB0aGUgdXNlIGNhc2UuIFdoYXQgaXMg
bWlzc2luZyBpcyBhIG1lYW5zIGZvciBzb2x2aW5nIHRoZSBmb2xsb3dpbmcgcHJvYmxlbS4gVGhl
c2UgUkZDcyByZXF1aXJlIHRoYXQgdGhlIElkZW50aXR5IFByb3ZpZGVyIHB1dCBhbiBBdWRpZW5j
ZSBjbGFpbSBpbiB0aGUgYXV0aGVudGljYXRpb24gdG9rZW4uIFRoZSBwcm9ibGVtIHdpdGggdGhp
cyBpcyB0aGF0IEkgZG8gbm90IHNlZSBpbiB0aGUgUkZDcyBob3cgdGhlIElkZW50aXR5IFByb3Zp
ZGVyIGNhbiBiZSB0b2xkIHdobyB0aGUgQXVkaWVuY2UgaXMgdG8gcHV0IGludG8gdGhlIGF1dGhl
bnRpY2F0aW9uIHRva2VuLiBUaGlzIGxlYWRzIG1lIHRvIHRoZSB0aXRsZSBvZiB0aGlzIG1lc3Nh
Z2UuIFRoZSBkcmFmdCDigJxPQXV0aCAyLjAgVG9rZW4gRXhjaGFuZ2U6IEFuIFNUUyBmb3IgdGhl
IFJFU1Qgb2YgVXPigJ0gZGVmaW5lcyBhIG1lY2hhbmlzbSBmb3IgaWRlbnRpZnlpbmcgdGhlIEF1
ZGllbmNlIGZvciBhbiBTVFMgdG8gcHV0IGludG8gYSB0b2tlbiBpdCBnZW5lcmF0ZXMuIFRoYXQg
d291bGQgc29sdmUgbXkgcHJvYmxlbSBleGNlcHQgdGhhdCB0aGUgZHJhZnQgbGltaXRzIHRoZSB0
eXBlIG9mIFNUUyB0byBiZWluZyBBdXRob3JpemF0aW9uIFNlcnZlcnMuIFdoYXQgaXMgbmVlZGVk
IGlzIHRoaXMgc2FtZSBjYXBhYmlsaXR5IGZvciBpbnRlcmFjdGluZyB3aXRoIGFuIElkZW50aXR5
IFByb3ZpZGVyLiBUaGlzIHdvdWxkIGVuYWJsZSBSRkNzIDc1MjEsIDc1MjIgYW5kIDc1MjMgdG8g
YmUgdXNlZnVsIGluIHNpdHVhdGlvbiB3aGVyZSB0aGUgSWRlbnRpdHkgUHJvdmlkZXIgbmVlZHMg
dG8gYmUgdG9sZCB0aGUgaWRlbnRpdHkgb2YgdGhlIEF1dGhvcml6YXRpb24gU2VydmljZS4NCg0K
SSBhbSBuZXcgdG8gaW50ZXJhY3Rpbmcgd2l0aCB0aGUgSUVURi4gSSBhbHNvIGFtIG5vdCBhbiBl
eHBlcnQgb24gdGhlIFJGQ3Mgb3IgcHJpb3IgaGlzdG9yeSBvZiB0aGUgT0F1dGggZ3JvdXAgcmVs
YXRpdmUgdG8gdGhpcyB0b3BpYywgc28gcGxlYXNlIHBvaW50IG1lIHRvIGFueSBleGlzdGluZyBz
b2x1dGlvbiBpZiB0aGlzIGlzIGEgc29sdmVkIHByb2JsZW0uIE90aGVyd2lzZSwgSSB3b3VsZCBs
aWtlIHRvIGdldCBmZWVkYmFjayBvbiBteSBzdWdnZXN0aW9uLg0KDQpUaGFua3MgWW91LA0KDQpB
bmRyZXcgRnJlZ2x5DQpWZXJpc2lnbiBJbmMuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxt
YWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL29hdXRoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRm
Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg==

--_000_ACF4DECCB69C4E3586D11FCDA0F56A5Cverisigncom_
Content-Type: text/html; charset="utf-8"
Content-ID: <179C50CBE5281B4B87F616B28C2EE010@verisign.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjx0aXRsZT5SRkMgNzUyMSAtIEFzc2VydGlvbiBG
cmFtZXdvcmsgZm9yIE9BdXRoIDIuMCBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEF1dGhvcml6
YXRpb24gR3JhbnRzPC90aXRsZT4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdyYXA6IGJy
ZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBh
ZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwg
MCk7Ij5UaGFuayB5b3UgYWdhaW4gb2YgeW91ciBpbnB1dCBOYXQuJm5ic3A7PC9kaXY+DQo8ZGl2
IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJj
b2xvcjogcmdiKDAsIDAsIDApOyI+Rmlyc3Qgb2YgYWxsLCBJIGFwb2xvZ2l6ZSBmb3IgY29uZnVz
aW5nIHRoZSBzaXR1YXRpb24gYnkgcmVmZXJlbmNpbmcgdGhlIHdyb25nIFJGQ3MgaW4gYSBwcmlv
ciBlbWFpbC4gSSB0cmFuc3Bvc2VkIHR3byBkaWdpdHMuIFRoZSBSRkNzIEkgbWVhbnQgdG8gcmVm
ZXJlbmNlIHdoZXJlIDc1MjEtNzUyMyAoc2VlIGJlbG93KS48L2Rpdj4NCjxkaXYgc3R5bGU9ImNv
bG9yOiByZ2IoMCwgMCwgMCk7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2Io
MCwgMCwgMCk7Ij5JIGdldCB0aGF0IHRoZSBvcmlnaW5hbCBSRkMgZm9yIE9BdXRoIGhhcyB0aGUg
bWVjaGFuaXNtIGZvciBjbGllbnQgYXV0aGVudGljYXRpb24gYmVpbmcgb3V0IG9mIHNjb3BlLiAm
bmJzcDtXaGF0IGlzIG11ZGR5aW5nIHRoZSB3YXRlciBmb3IgbWUgaXMgdGhhdCBSRkNzIDc1MjEs
IDc1MjIsIGFuZCA3NTIzIHNlZW0gdG8gc3BlY2lmeSB0aGUgbWVhbnMgYnkgd2hpY2ggYSBjbGll
bnQgY2FuIHByb3ZpZGUNCiBhbiBhdXRoZW50aWNhdGlvbiB0b2tlbiB0byBhbiBBdXRob3JpemF0
aW9uIFNlcnZpY2UuIFRoaXMgcHVycG9zZSBpcyBzdGF0ZWQgYXQgdGhlIHRvcCBvZiB0aGUgYWJz
dHJhY3QgZm9yIFJGQyA3NTIxOjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw
KTsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsiPiZxdW90
OzxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2Io
MjU1LCAyNTUsIDI1NSk7Ij5UaGUgaW50ZW50IG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyB0byBw
cm92aWRlIGEgY29tbW9uIGZyYW1ld29yayBmb3ImbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNv
bG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsi
Pk9BdXRoDQogMi4wIHRvIGludGVyd29yayB3aXRoIG90aGVyIGlkZW50aXR5IHN5c3RlbXMgdXNp
bmcgYXNzZXJ0aW9uczwvc3Bhbj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1
NSwgMjU1LCAyNTUpOyI+Jm5ic3A7YW5kIHRvIHByb3ZpZGUgYWx0ZXJuYXRpdmUgY2xpZW50IGF1
dGhlbnRpY2F0aW9uIG1lY2hhbmlzbXMu4oCdPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29s
b3I6IHJnYigwLCAwLCAwKTsiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1
LCAyNTUsIDI1NSk7Ij48YnI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2PkluIG91ciB1c2UgY2FzZSwg
d2UgbmVlZCB0byBoYXZlIHVzZXJzIGF1dGhlbnRpY2F0ZWQgYWdhaW5zdCBpZGVudGl0eSBwcm92
aWRlcnMgdGhhdCBvcmdhbml6YXRpb25zIHVzZSBpbnRlcm5hbGx5IGFzIHRoZSBtZWFucyBmb3Ig
YXV0aGVudGljYXRpbmcgY2xpZW50cyBhY2Nlc3Npbmcgb3VyIHNlcnZpY2UuIFdlIG5lZWQgdGhp
cyBiZWNhdXNlIHdlIGJlbGlldmUgdGhpcyBpcyB0aGUgYmVzdCBtZWFucyBmb3IgcHJvdmluZyBh
IHVzZXIgaXMNCiBzdGlsbCBhIG1lbWJlciBvZiBhbiBvcmdhbml6YXRpb24gYXQgdGhlIHRpbWUg
dGhleSBhdXRoZW50aWNhdGUuIE1vc3QsIHBlcmhhcHMgYWxsIG9mIHRoZXNlIG9yZ2FuaXphdGlv
bnMsIHdpbGwgaW50ZXJuYWxseSB1c2UgYW4gSWRlbnRpdHkgUHJvdmlkZXIgdGhhdCBwcm92aWRl
cyBTQU1MIGF1dGhlbnRpY2F0aW9uIGFzc2VydGlvbnMuIFRoaXMgbGVkIG1lIHRvIGxvb2tpbmcg
Zm9yIGEgd2F5IHRvIHVzZSBhdXRoZW50aWNhdGlvbiB0b2tlbnMNCiBwcm9kdWNlZCBieSBpbnRl
cm5hbCBJZGVudGl0eSBQcm92aWRlcnMgYXMgYSBtZWFucyBmb3IgcHJvdmluZyBhIGNsaWVudCBo
YWQgYmVlbiBhdXRoZW50aWNhdGVkIGJ5IHRoZSBvcmdhbml6YXRpb24uIEEgYml0IG9mIGludmVz
dGlnYXRpb24gaW4gaG93IHRoaXMgbWlnaHQgYmUgZG9uZSBsZWQgbWUgdG8gT0F1dGggUkZDcyA3
NTIxLCA3NTIyIGFuZCA3NTIzLiBUaGV5ICZuYnNwO2FsbW9zdCBnZXQgbWUgdGhlcmUuIFRoZXkg
c3BlY2lmeSB3aGF0IG5lZWRzDQogdG8gYmUgaW4gYW4gQXV0aGVudGljYXRpb24gdG9rZW4gdGhh
dCBpcyBnaXZlbiBieSBhIGNsaWVudCB0byBhbiBBdXRob3JpemF0aW9uIFNlcnZpY2UuIFRoZSBn
b3RjaGEgd2FzIHRoYXQgdGhlc2UgUkZDcyByZXF1aXJlIGFuIGF1ZGllbmNlIGNsYWltIGluIHRo
ZSBhdXRoZW50aWNhdGlvbiB0b2tlbi4gVGhpcyBhdWRpZW5jZSBjbGFpbSBpcyB1c2VkIHRvIGlk
ZW50aWZ5IHRoZSBzcGVjaWZpYyBBdXRob3JpemF0aW9uIFNlcnZpY2UgdGhlIHRva2VuDQogaXMg
bWVhbnQgZm9yLiBGb3IgdGhpcyBhdWRpZW5jZSBjbGFpbSB0byBnZXQgZmlsbGVkIGluIGJ5IHNv
bWUgYXJiaXRyYXJ5IG9yZ2FuaXphdGlvbuKAmXMgSWRlbnRpdHkgUHJvdmlkZXIsIGl0IHNlZW1z
IHRoZSBJZGVudGl0eSBQcm92aWRlciB3aWxsIG5lZWQgdG8gYmUgdG9sZCB3aG8gdGhlIEF1dGhv
cml6YXRpb24gU2VydmljZSBpcyBieSB0aGUgY2xpZW50IGluaXRpYXRpbmcgdGhlIGF1dGhlbnRp
Y2F0aW9uLiBJIGhhdmUgdGhlcmVmb3JlIGJlZW4NCiBsb29raW5nIGZvciBhIHN0YW5kYXJkIHRo
YXQgc3BlY2lmaWVzIGhvdyBhIGNsaWVudCBjYW4gdGVsbCB0aGUgSWRlbnRpdHkgUHJvdmlkZXIg
dGhlIGlkZW50aXR5IG9mIHRoZSBBdXRob3JpemF0aW9uIFNlcnZpY2UuIEkgd2FzIHN0dWNrIGZv
ciBhIGJpdCBvbiBob3cgdGhlIElFVEYgT0F1dGggd29ya2luZyBncm91cCBjb3VsZCBhZGRyZXNz
IHRoaXMgaXNzdWUgc2luY2UgYXV0aGVudGljYXRpb24gc2VlbWVkIHRvIGJlIG91dCBvZiBzY29w
ZSBmb3INCiB0aGUgZ3JvdXAuIFRoZW4gSSBmb3VuZCB0aGUgJm5ic3A7SUVURiBkcmFmdCZuYnNw
OyZxdW90O09BdXRoIDIuMCBUb2tlbiBFeGNoYW5nZTogQW4gU1RTIGZvciB0aGUgUkVTVCBvZiBV
c+KAnS4gSXQgZGVmaW5lcyBhIG1lY2hhbmlzbSBmb3IgdGVsbGluZyBhIFNlY3VyaXR5IFRva2Vu
IFNlcnZpY2UgdGhlIGF1ZGllbmNlIGZvciB0aGUgdG9rZW4gaXQgaXMgYmVpbmcgYXNrZWQgdG8g
aXNzdWUuIEkgdGhvdWdodCB0aGF0IHdvdWxkIHNvbHZlIG15IHByb2JsZW0gc2luY2UgYW4NCiBp
bnRlbnQgb2YgdGhlIGRyYWZ0IHNlZW1lZCB0byBiZSBvbiBnZW5lcmFsaXppbmcmbmJzcDt0aGUg
ZGVzY3JpYmVkIGFwcHJvYWNoIHRvIGFueSB0eXBlIG9mIFNlY3VyaXR5IFRva2VuIFNlcnZpY2Uu
IFRoZXJlIHdhcyBvbmUgZ290Y2hhIGluIHRoZSBkcmFmdCB0aG91Z2guIEl0IGxpbWl0ZWQgdGhl
IHR5cGUgb2YgU1RTIHRvIHdoaWNoIHRoZSBwcm90b2NvbCBhcHBsaWVkIHRvIGJlIGp1c3QgQXV0
aG9yaXphdGlvbiBTZXJ2aWNlcy4gRm9yIG15IHVzZQ0KIGNhc2UsIEkgbmVlZGVkIHRoZSBjYXBh
YmlsaXR5IGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQsIGJ1dCBhcHBsaWNhYmxlIHRvIElkZW50aXR5
IFByb3ZpZGVycyB0b28uIElmIGl0IHdlcmUgYXBwbGljYWJsZSB0byBJZGVudGl0eSBQcm92aWRl
cnMsIHRoZXJlIHdvdWxkIHRoZW4gYmUgYSBmdWxsIHNldCBvZiBleGlzdGluZyBSRkNzIGFuZCBk
cmFmdHMgdGhhdCBjb3ZlcmVkIHRoZSBmdW5jdGlvbmFsaXR5IG5lZWRlZCBmb3Igb3VyIHVzZSBj
YXNlLiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsiPjxicj4N
CjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsiPlRoZXJlIGFyZSBhIGNv
dXBsZSBvZiBwb3NzaWJsZSBhY3Rpb25zIHRoYXQgSSBoYXZlIGJlZW4gY29udGVtcGxhdGluZyBy
ZWxhdGl2ZSB0byBPQXV0aDo8L2Rpdj4NCjxvbCBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsi
Pg0KPGxpPldyaXRlIGV4dGVuc2lvbnMgdG8gUkZDcyA3NTIxLCA3NTIyIGFuZCA3NTIzIHRoYXQg
ZWxpbWluYXRlIHRoZSBuZWVkIGZvciBhbiBhdWRpZW5jZSBjbGFpbSBpbiB0aGUgYXV0aGVudGlj
YXRpb24gdG9rZW4gaWYgdGhlIEF1dGhvcml6YXRpb24gU2VydmljZSBoYXMgYSB0cnVzdCByZWxh
dGlvbnNoaXAgd2l0aCB0aGUgSWRlbnRpdHkgUHJvdmlkZXIgdGhhdCBpc3N1ZWQgdGhlIGF1dGhl
bnRpY2F0aW9uIHRva2VuLjwvbGk+PGxpPkFzayB0aGUgYXV0aG9ycyBvZiB0aGUg4oCcT0F1dGgg
Mi4wIFRva2VuIEV4Y2hhbmdlOiBBbiBTVFMgZm9yIHRoZSBSRVNUIG9mIFVz4oCdIHRvIGV4cGxp
Y2l0bHkgc3RhdGUgdGhhdCB0aGUgdGhlIGFwcHJvYWNoIGRlc2NyaWJlZCB0aGVyZS1pbiBpcyBh
cHBsaWNhYmxlIHRvIGJvdGggSWRlbnRpdHkgUHJvdmlkZXJzIGFuZCBBdXRob3JpemF0aW9uIHNl
cnZpY2VzLjwvbGk+PC9vbD4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7Ij5CZWZv
cmUgZG9pbmcgZWl0aGVyIG9mIHRoZXNlIHN0ZXBzLCBJIHdhbnQgdG8gbWFrZSBzdXJlIHRoYXQg
SSBhbSBub3QgbWlzc2luZyBzb21ldGhpbmcgaW4gZXhpc3RpbmcgUkZDcyBhbmQgZHJhZnRzIHRo
YXQgd291bGQgYWRkcmVzcyBvdXIgdXNlIGNhc2UuIEkgaGF2ZSBvbmx5IGJlZW4gbG9va2luZyBh
dCB0aGlzIGlzc3VlIGZvciBhIGZldyB3ZWVrcywgc28gSSB0aG91Z2h0IGl0IHdvdWxkDQogYmUg
YmVzdCB0byBnbyB0byB0aGUgZXhwZXJ0cyB0byBnZXQgYWR2aWNlLiBUaGlzIGxlZCB0byB0aGlz
IGVtYWlsIGNoYWluLiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw
KTsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsiPg0KPGRp
diBpZD0iTUFDX09VVExPT0tfU0lHTkFUVVJFIj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyI+VGhhbmtzIHRvIGFsbCBmb2xsb3dpbmcgdGhp
cyBjaGFpbiBmb3IgeW91ciB0aW1lIGFuZCBjb25zaWRlcmF0aW9uIG9uIHRoaXMhPC9kaXY+DQo8
ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxl
PSJjb2xvcjogcmdiKDAsIDAsIDApOyI+QW5keTwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJn
YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog
MTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iIHN0
eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp
ZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBm
b250LXNpemU6MTJwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRP
TTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006
IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDog
I2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9Q
OiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5OYXQg
U2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iPnNha2ltdXJh
QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRh
dGU6IDwvc3Bhbj5UdWVzZGF5LCBBcHJpbCAxOSwgMjAxNiBhdCA1OjM1IFBNPGJyPg0KPHNwYW4g
c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+QW5kcmV3IEZyZWdseSAmbHQ7PGEg
aHJlZj0ibWFpbHRvOmFmcmVnbHlAdmVyaXNpZ24uY29tIj5hZnJlZ2x5QHZlcmlzaWduLmNvbTwv
YT4mZ3Q7LCBKb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNv
bSI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm9hdXRo
QGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpv
YXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJm
b250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtPQVVUSC1XR10gQnVpbGRpbmcg
b24gdGhlIHByb3RvY29sIGluIHRoZSBkcmFmdCAmcXVvdDtPQXV0aCAyLjAgVG9rZW4gRXhjaGFu
Z2U6IEFuIFNUUyBmb3IgdGhlIFJFU1Qgb2YgVXMmcXVvdDsgdG8gaW5jbHVkZSBBdXRoZW50aWNh
dGlvbiBUb2tlbnM8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBp
ZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZU
OiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2PkhpIEFuZHJldywmbmJzcDs8L2Rpdj4N
CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0ibGluZS1o
ZWlnaHQ6MS41Ij5JbiBPQXV0aCAyLjAsIHRoZSByZXNvdXJjZSBvd25lciBhdXRoZW50aWNhdGlv
biAvZW5kIHVzZXIgYXV0aGVudGljYXRpb24gaXMgb3V0IG9mIHNjb3BlLiBXaGF0IGl0IGRlYWxz
IHdpdGggaXMgJnF1b3Q7Y2xpZW50IGF1dGhlbnRpY2F0aW9uJnF1b3Q7LiBUaGV5IHNob3VsZCBu
b3QgYmUgbWl4ZWQgdXAuIFRoZXJlIGlzIG5vIGVuZCB1c2VyIGlkZW50aXR5IG5vciBhdXRoZW50
aWNhdGlvbiB0b2tlbiBpbg0KIHRoZSBPQXV0aC4gWW91IGNhbm5vdCBkbyBlbmQgdXNlciBhdXRo
ZW50aWNhdGlvbiB3aXRoIHB1cmUgT0F1dGguIEZvciB0aGF0LCB5b3UgaGF2ZSB0byByZWx5IG9u
IHNvbWV0aGluZyBsaWtlIE9wZW5JRCBDb25uZWN0LiZuYnNwOzwvc3Bhbj48YnI+DQo8L2Rpdj4N
CjxkaXY+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OjEuNSI+PGJyPg0KPC9zcGFuPjwvZGl2Pg0K
PGRpdj48c3BhbiBzdHlsZT0ibGluZS1oZWlnaHQ6MS41Ij5BcyBKb2huIG5vdGVkLCBpdCBpcyBw
ZXJmZWN0bHkgZmluZSB0byBjaGFpbiB0aGUgZXh0ZXJuYWwgYXV0aGVudGljYXRpb24gYW5kIHRo
ZSBpbnRlcm5hbCBhdXRob3JpemF0aW9uLiBJdCBpcyBvZnRlbiBkb25lLiBJdCBpcyBqdXN0IHRo
YXQgdGhlIFJGQzY3NDkgQXV0aHogc2VydmVyIGlzIGFuIFJQIG9mIE9wZW5JRCBDb25uZWN0IG9y
IFNQIG9mIFNBTUwuIE5vdGhpbmcgcHJlY2x1ZGVzDQogaXQuJm5ic3A7PC9zcGFuPjwvZGl2Pg0K
PGRpdj48c3BhbiBzdHlsZT0ibGluZS1oZWlnaHQ6MS41Ij48YnI+DQo8L3NwYW4+PC9kaXY+DQo8
ZGl2PjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDoxLjUiPklmIHlvdSByZWFsbHkgd2FudCB0byBh
dm9pZCB0aGUgZnJvbnQgY2hhbm5lbCByZS1hdXRoIHdpdGggcHJvbXB0PW5vbmUsIHdoaWNoIGlz
IG1vcmUgc2VjdXJlIGFuZCBwcm9wZXIgd2F5cyB0byBkbywgYnV0IGp1c3QgdG8gbWFrZSBzdXJl
IHRoYXQgdGhlIHVzZXIgc3RpbGwgZXhpc3RzIGluIHRoZSBhdXRoZW50aWNhdGlvbiBzZXJ2aWNl
LCB5b3UgY2FuIGluZmVyIGl0IGJ5IG1ha2luZw0KIGEgdXNlcmluZm8gcmVxdWVzdCB0byB0aGUg
dXNlcmluZm8gZW5kcG9pbnQgb2YgT3BlbklEIENvbm5lY3QuIEl0IHdvdWxkIGZhaWwgaW4gdmFy
aW91cyByZWFzb25zLCBidXQgd291bGQgY2VydGFpbmx5IGZhaWwgaWYgdGhlIHVzZXIgZG9lcyBu
b3QgZXhpc3QgYW55bW9yZS4gT3RoZXIgZXJyb3IgY29uZGl0aW9ucyBsaWtlIHRoZSB1c2VyIHJl
dm9rZWQgdGhlIGFjY2Vzcy9yZWZyZXNoIHRva2VuIGV0Yy4gd291bGQgY2F1c2UgdGhlIHNhbWUm
bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOnJnYigwLDAsMCk7Zm9udC1zaXplOjEzLjMz
MzNweDtsaW5lLWhlaWdodDpub3JtYWwiPmludmFsaWRfdG9rZW4NCiBlcnJvciB0aG91Z2guJm5i
c3A7PC9zcGFuPjwvZGl2Pg0KPGRpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkJlc3QsJm5i
c3A7PC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDoxLjUiPjxicj4NCjwvc3Bh
bj48L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OjEuNSI+TmF0PC9zcGFuPjxi
cj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UC5TLiZuYnNwOzxzcGFuIHN0eWxl
PSJsaW5lLWhlaWdodDoxLjUiPkkgZG8gbm90IHNlZSB3aHkgdGhlIFJGQ3MgeW91IHNpdGVkIGFy
ZSByZWxldmFudCBoZXJlLiBJIGd1ZXNzIHlvdSBhcmUgdGFsa2luZyBhYm91dCBSRkM3NTIxLTc1
MjMgOy0pPC9zcGFuPjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NClJGQzcyNTEgQUVTLUNDTSBF
bGxpcHRpYyBDdXJ2ZSBDcnlwdG9ncmFwaHkgKEVDQykgQ2lwaGVyIFN1aXRlcyBmb3IgVExTPGJy
Pg0KUkZDNzI1MiBUaGUgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApPGJy
Pg0KUkZDNzI1MyBUaGUgT0NCIEF1dGhlbnRpY2F0ZWQtRW5jcnlwdGlvbiBBbGdvcml0aG0NCjxk
aXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPGRp
dj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjFlbTtsaW5lLWhlaWdodDowcHQ7Zm9udC13ZWlnaHQ6
Ym9sZDtjb2xvcjpyZ2IoMCwwLDApIj48YnI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2PjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MWVtO2xpbmUtaGVpZ2h0OjBwdDtmb250LXdlaWdodDpib2xkO2NvbG9y
OnJnYigwLDAsMCkiPjxicj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxZW07bGluZS1oZWlnaHQ6MHB0O2ZvbnQtd2VpZ2h0OmJvbGQ7Y29sb3I6cmdiKDAsMCww
KSI+PGJyPg0KPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2IGRpcj0ibHRyIj4yMDE25bm0NOac
iDIw5pelKOawtCkgNTozNCBGcmVnbHksIEFuZHJldyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFmcmVn
bHlAdmVyaXNpZ24uY29tIj5hZnJlZ2x5QHZlcmlzaWduLmNvbTwvYT4mZ3Q7Ojxicj4NCjwvZGl2
Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44
ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IHN0
eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZDtjb2xvcjpyZ2IoMCwwLDApO2ZvbnQtc2l6ZToxNHB4
O2ZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQo8ZGl2Pg0KPGRpdj5UaGFua3MgZm9y
IHlvdXIgcmVwbHkgTmF0LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+RG9lcyB5b3Vy
IGFwcHJvYWNoIG1hdGNoIHdpdGggYW4gSUVURiBPQXV0aCBSRkMgb3IgRHJhZnQgZGVzY3JpYmlu
ZyBob3cgYW4gQXV0aG9yaXphdGlvbiBTZXJ2aWNlIGNhbiBhY2NlcHQgYW5kIHZlcmlmeSBhbiBh
dXRoZW50aWNhdGlvbiB0b2tlbiBwcm92aWRlZCBieSBhIGNsaWVudCBkdXJpbmcgdGhlIGF1dGhv
cml6YXRpb24gcHJvY2Vzcz8gSWYgc28sIHBsZWFzZSBwb2ludCBtZSB0byB0aGF0LiBUaGUgb25s
eSBSRkNzIEkgaGF2ZSBzZWVuDQogdGhhdCBhZGRyZXNzIHRoaXMgYXJlIFJGQ3MgNzI1MSwgNzI1
MiBhbmQgNzI1MywgYW5kIHRoZXkgYWxsIGhhdmUgYSByZXF1aXJlbWVudCB0aGF0IGFuIOKAnGF1
ZGllbmNl4oCdIGNsYWltIGNvcnJlc3BvbmRpbmcgdG8gdGhlIEF1dGhvcml6YXRpb24gU2Vydmlj
ZSBpcyBpbiB0aGUgYXV0aGVudGljYXRpb24gdG9rZW4uIEdldHRpbmcgdGhhdCBjbGFpbSBpbnRv
IGFuIGF1dGhlbnRpY2F0aW9uIHRva2VuIHByb3ZpZGVkIGJ5IGFuIE9yZ2FuaXphdGlvbuKAmXMN
CiBJZGVudGl0eSBwcm92aWRlciBzZWVtcyB0byBiZSBteSBmdW5kYW1lbnRhbCBwcm9ibGVtLjwv
ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzLDwvZGl2Pg0KPGRpdj4mbmJzcDsg
Jm5ic3A7ICZuYnNwOyBBbmR5PC9kaXY+DQo8ZGl2Pg0KPGRpdj48L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpD
YWxpYnJpO2ZvbnQtc2l6ZToxMnB0O3RleHQtYWxpZ246bGVmdDtjb2xvcjpibGFjaztCT1JERVIt
Qk9UVE9NOm1lZGl1bSBub25lO0JPUkRFUi1MRUZUOm1lZGl1bSBub25lO1BBRERJTkctQk9UVE9N
OjBpbjtQQURESU5HLUxFRlQ6MGluO1BBRERJTkctUklHSFQ6MGluO0JPUkRFUi1UT1A6I2I1YzRk
ZiAxcHQgc29saWQ7Qk9SREVSLVJJR0hUOm1lZGl1bSBub25lO1BBRERJTkctVE9QOjNwdCI+DQo8
c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPk5hdCBTYWtpbXVyYSAm
bHQ7PGEgaHJlZj0ibWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNh
a2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv
bGQiPkRhdGU6IDwvc3Bhbj5UdWVzZGF5LCBBcHJpbCAxOSwgMjAxNiBhdCA0OjEzIFBNPGJyPg0K
PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+QW5kcmV3IEZyZWdseSAm
bHQ7PGEgaHJlZj0ibWFpbHRvOmFmcmVnbHlAdmVyaXNpZ24uY29tIiB0YXJnZXQ9Il9ibGFuayI+
YWZyZWdseUB2ZXJpc2lnbi5jb208L2E+Jmd0OywgSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJt
YWlsdG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0iX2JsYW5rIj52ZTdqdGJAdmU3anRiLmNv
bTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0i
X2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mcXVvdDsNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9h
dXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0OzwvZGl2
Pg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7Y29sb3I6
cmdiKDAsMCwwKTtmb250LXNpemU6MTRweDtmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYi
Pg0KPHNwYW4+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2ZvbnQtc2l6ZToxMnB0
O3RleHQtYWxpZ246bGVmdDtjb2xvcjpibGFjaztCT1JERVItQk9UVE9NOm1lZGl1bSBub25lO0JP
UkRFUi1MRUZUOm1lZGl1bSBub25lO1BBRERJTkctQk9UVE9NOjBpbjtQQURESU5HLUxFRlQ6MGlu
O1BBRERJTkctUklHSFQ6MGluO0JPUkRFUi1UT1A6I2I1YzRkZiAxcHQgc29saWQ7Qk9SREVSLVJJ
R0hUOm1lZGl1bSBub25lO1BBRERJTkctVE9QOjNwdCI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9u
dC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbT0FVVEgtV0ddIEJ1aWxkaW5nIG9u
IHRoZSBwcm90b2NvbCBpbiB0aGUgZHJhZnQgJnF1b3Q7T0F1dGggMi4wIFRva2VuIEV4Y2hhbmdl
OiBBbiBTVFMgZm9yIHRoZSBSRVNUIG9mIFVzJnF1b3Q7IHRvIGluY2x1ZGUgQXV0aGVudGljYXRp
b24gVG9rZW5zPGJyPg0KPC9kaXY+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdy
YXA6YnJlYWstd29yZDtjb2xvcjpyZ2IoMCwwLDApO2ZvbnQtc2l6ZToxNHB4O2ZvbnQtZmFtaWx5
OkNhbGlicmksc2Fucy1zZXJpZiI+DQo8c3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2tx
dW90ZSBzdHlsZT0iQk9SREVSLUxFRlQ6I2I1YzRkZiA1IHNvbGlkO1BBRERJTkc6MCAwIDAgNTtN
QVJHSU46MCAwIDAgNSI+DQo8ZGl2Pg0KPGRpdj5HZXQgT3BlbklEIENvbm5lY3QgaWRfdG9rZW4g
YnkgdGhlIGF1dGhlbnRpY2F0aW9uIHJlcXVlc3Qgd2l0aCBwcm9tcHQ9bm9uZSBhbmQgdmVyaWZ5
aW5nIHRoZSBzdWIgdG8gYmUgdGhlIHNhbWUgd2l0aCB3aGF0IHlvdSBleHBlY3RlZCBzZWVtIHRv
IHN1ZmZpY2UgeW91ciBuZWVkcy4gQW0gSSBtaXNzaW5nIHNvbWV0aGluZz8NCjxicj4NCjxkaXYg
Y2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiPk9uIFdlZCwgQXByIDIwLCAyMDE2
IGF0IDA1OjA1IEZyZWdseSwgQW5kcmV3ICZsdDs8YSBocmVmPSJtYWlsdG86YWZyZWdseUB2ZXJp
c2lnbi5jb20iIHRhcmdldD0iX2JsYW5rIj5hZnJlZ2x5QHZlcmlzaWduLmNvbTwvYT4mZ3Q7IHdy
b3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0i
bWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0
OjFleCI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZDtjb2xvcjpyZ2IoMCwwLDAp
O2ZvbnQtc2l6ZToxNHB4O2ZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQo8ZGl2Pg0K
PGRpdj5UaGFua3MgZm9yIHlvdXIgcmVzcG9uc2UgSm9obi4gSSBhbHNvIGdvdCBhIGdvb2QgcmVz
cG9uc2UgZnJvbSBCcmlhbiBDYW1wYmVsbCBhbmQgYXBwcmVjaWF0ZSB0aGF0LiBJIHdpbGwgcmVz
cG9uZCBzZXBhcmF0ZWx5IHRvIEJyaWFu4oCZcyByZXNwb25zZSBhcyBJIHRoaW5rIGl0IHdvdWxk
IGtlZXAgdGhpbmdzIGNsZWFyZXIgdG8gZG8gdGhhdC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+
DQo8ZGl2PlRoZSBwcm9ibGVtIHdlIGhhdmUgZm9yIHVzaW5nIE9wZW5JRCBDb25uZWN0IGlzIHRo
YXQgaXQgY29tYmluZXMgdGhlIHJvbGUgb2YgQXV0aGVudGljYXRpb24gU2VydmljZSB3aXRoIHRo
ZSByb2xlIG9mIEF1dGhvcml6YXRpb24gU2VydmljZS4gUGVyaGFwcyB0aGUgZm9sbG93aW5nIGRl
c2NyaXB0aW9uIG9mIHdoYXQgd2Ugd2FudCB0byBkbyB3aWxsIGNsYXJpZnkgd2h5IHRoaXMgd29u
4oCZdCB3b3JrIGZvciB1czo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSBiYXNp
YyBwcm9ibGVtIHN0YXRlbWVudCBpcyB0aGF0IHdlIG5lZWQgdG8gaGF2ZSBhIGNsaWVudCBhcHBs
aWNhdGlvbiBhdXRob3JpemVkIGJ5IGEgU2VydmljZSBQcm92aWRlciBiYXNlZCBvbiBwcm9vZiB0
aGF0IGEgdXNlciBpcyBjdXJyZW50bHkgYSBtZW1iZXIgb2Ygc29tZSBvcmdhbml6YXRpb24uIFRo
aXMgYXNzdW1lcyB0aGUgb3JnYW5pemF0aW9uIGhhcyBwcmV2aW91c2x5IGVzdGFibGlzaGVkIHNv
bWUgbGV2ZWwgb2YgYXV0aG9yaXplZA0KIGFjY2VzcyB3aXRoIHRoZSBTZXJ2aWNlIFByb3ZpZGVy
LiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SGVyZSBpcyBhbiBleGFtcGxl
OiBTdXBwb3NlIEkgYW0gYSBtZW1iZXIgb2YgU29tZU9yZyBJbmMuIFN1cHBvc2UgU29tZU9yZyBJ
bmMuIGlzIGRvaW5nIHJlc2VhcmNoIHRoYXQgcmVxdWlyZXMgaXQgdG8gZ2F0aGVyIGRhdGEgb3Zl
ciB0aGUgSW50ZXJuZXQgZnJvbSBhIG51bWJlciBvZiBkYXRhIHByb3ZpZGVycy4gVGhlIGRhdGEg
cHJvdmlkZXJzIHJlcXVpcmUgYXV0aGVudGljYXRpb24gYW5kIHByb29mIG9mIG9yZ2FuaXphdGlv
bmFsIG1lbWJlcnNoaXANCiBpbiBvcmRlciB0byBhdXRob3JpemUgdmFyaW91cyBsZXZlbHMgb2Yg
YWNjZXNzIHRvIHRoZWlyIGRhdGEuIFRoZSBkYXRhIHByb3ZpZGVycyBkbyBub3QgY29uc2lkZXIg
aGF2aW5nIGFuIGFjY291bnQgd2l0aCB0aGVtIG9yIGEgUHVibGljIElkZW50aXR5IFByb3ZpZGVy
IHRvIGJlIHN1aXRhYmxlIGZvciBwcm92aW5nIHRoYXQgSSBhbSBzdGlsbCBhIG1lbWJlciBvZiBT
b21lT3JnIGF0IHRpbWUgb2YgYXV0aGVudGljYXRpb24uIFRoZXkgd291bGQNCiBoYXZlIG5vIHdh
eSBvZiBrbm93aW5nIHdoZXRoZXIgb3Igbm90IG15IHJlbGF0aW9uc2hpcCB3aXRoIFNvbWVPcmcg
c3RpbGwgZXhpc3RzIGF0IHRoYXQgdGltZS4gVGhlIGRhdGEgcHJvdmlkZXJzIHdvdWxkIHRoZXJl
Zm9yZSBsaWtlIHRoZSBDbGllbnQgc29mdHdhcmUgdG8gYXV0aGVudGljYXRlIG1lIGFnYWluc3Qg
U29tZU9yZ3MgSWRlbnRpdHkgUHJvdmlkZXIuIFRoaXMgd291bGQgYmUgZ29vZCBwcm9vZiB0aGF0
IEkgYW0gc3RpbGwgYSBtZW1iZXINCiBvZiBTb21lT3JnIGF0IHRoZSB0aW1lIEkgYXV0aGVudGlj
YXRlLiBUaGlzIGF1dGhlbnRpY2F0aW9uIHdvdWxkIGVuYWJsZSB0aGUgZGF0YSBwcm92aWRlcnMg
QXV0aG9yaXphdGlvbiBTZXJ2ZXIgdG8gZ3JhbnQgbWUgYWNjZXNzIGFwcHJvcHJpYXRlIHRvIGEg
bWVtYmVyIG9mIFNvbWVPcmcuJm5ic3A7IE5vdGUgdGhhdCBhcyBhIHByZXJlcXVpc2l0ZSB0byBh
bGwgb2YgdGhpcywgU29tZU9yZyB3aWxsIGhhdmUgdXNlZCBhbiBvdXQtb2YtYmFuZCBwcm9jZXNz
DQogdG8gc2V0IHVwIGEgdHJ1c3QgcmVsYXRpb25zaGlwIGZvciBTb21lT3JnJ3MgSWRlbnRpdHkg
UHJvdmlkZXIgd2l0aCB0aGUgZGF0YSBwcm92aWRlcuKAmXMgQXV0aG9yaXphdGlvbiBTZXJ2aWNl
LCBhbmQgd2lsbCBoYXZlIG5lZ290aWF0ZWQgYXV0aG9yaXphdGlvbiBjbGFpbXMgdG8gYmUgZ3Jh
bnRlZCB0byBTb21lT3JncyBtZW1iZXJzLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+
V2hhdCBJIGFtIGhhdmluZyBkaWZmaWN1bHR5IHdpdGggaXMgaW4ga25pdHRpbmcgdG9nZXRoZXIg
YW4gYXBwcm9hY2ggYmFzZWQgb24gdGhlIGhlIE9wZW5JRCBDb25uZWN0IHNwZWNpZmljYXRpb25z
LCBTQU1MIHNwZWNpZmljYXRpb25zLCBhbmQgT0F1dGggUkZDcyBhbmQgZHJhZnRzIGluIGEgd2F5
IHRoYXQgc3VwcG9ydHMgdGhlIGFib3ZlIHVzZSBjYXNlIGVuZC10by1lbmQuIFRoZSBPQXV0aCBS
RkNzIGFuZCBkcmFmdHMgYWxtb3N0IGdldA0KIG1lIHRoZXJlLiBXaGF0IHNlZW1zIHRvIGJlIG1p
c3NpbmcgaXMgYSB3YXkgb2YgdGVsbGluZyBhbiBJZGVudGl0eSBQcm92aWRlciB0aGUgVVJMIGZv
ciB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2aWNlICh0aGUgcmVxdWlyZWQgQXVkaWVuY2UgY2xhaW0g
aW4gYW4gYXV0aGVudGljYXRpb24gYXNzZXJ0aW9uIGFzIGRlZmluZWQgaW4gUkZDcyA3MjUxLCA3
MjUyIGFuZCA3MjUzKSwgYW5kIHRoZW4gYSByZXF1aXJlbWVudCB0aGF0IHRoZSBJZGVudGl0eQ0K
IFByb3ZpZGVycyBwdXQgdGhlIHN1cHBsaWVkIEF1ZGllbmNlIElkZW50aWZpZXIgaW50byBBdXRo
ZW50aWNhdGlvbiBUb2tlbnMuIFBlcmhhcHMgYSBsaXR0bGUgZnVydGhlciBiYWNrLWFuZC1mb3J0
aCB3aXRoIEJyaWFuIHdpbGwgcmVzb2x2ZSB0aGlzLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N
CjxkaXY+SSBjYW4gZ28gaW50byBkZWVwZXIgZGV0YWlsIGlmIG5lZWRlZC4gSWYgdGhpcyBpcyBv
ZmYtdG9waWMgZm9yIHRoZSBPQXV0aCB3b3JraW5nIGdyb3VwLCBsZXQgbWUga25vdy48L2Rpdj4N
CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+QW5kcmV3IEZyZWds
eTwvZGl2Pg0KPGRpdj5WZXJpc2lnbiBJbmMuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXY+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFu
Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtmb250LXNpemU6MTJwdDt0ZXh0LWFs
aWduOmxlZnQ7Y29sb3I6YmxhY2s7Qk9SREVSLUJPVFRPTTptZWRpdW0gbm9uZTtCT1JERVItTEVG
VDptZWRpdW0gbm9uZTtQQURESU5HLUJPVFRPTTowaW47UEFERElORy1MRUZUOjBpbjtQQURESU5H
LVJJR0hUOjBpbjtCT1JERVItVE9QOiNiNWM0ZGYgMXB0IHNvbGlkO0JPUkRFUi1SSUdIVDptZWRp
dW0gbm9uZTtQQURESU5HLVRPUDozcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi
PkZyb206IDwvc3Bhbj5Kb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3
anRiLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDs8YnI+DQo8
c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPlR1ZXNkYXksIEFwcmls
IDE5LCAyMDE2IGF0IDI6MDYgUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+
VG86IDwvc3Bhbj5BbmRyZXcgRnJlZ2x5ICZsdDs8YSBocmVmPSJtYWlsdG86YWZyZWdseUB2ZXJp
c2lnbi5jb20iIHRhcmdldD0iX2JsYW5rIj5hZnJlZ2x5QHZlcmlzaWduLmNvbTwvYT4mZ3Q7PGJy
Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+JnF1b3Q7PGEgaHJl
Zj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8
L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2Js
YW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0
OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW09BVVRILVdHXSBCdWlsZGluZyBvbiB0aGUgcHJv
dG9jb2wgaW4gdGhlIGRyYWZ0IOKAnE9BdXRoIDIuMCBUb2tlbiBFeGNoYW5nZTogQW4gU1RTIGZv
ciB0aGUgUkVTVCBvZiBVc+KAnSB0byBpbmNsdWRlIEF1dGhlbnRpY2F0aW9uIFRva2Vuczxicj4N
CjwvZGl2Pg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7
Y29sb3I6cmdiKDAsMCwwKTtmb250LXNpemU6MTRweDtmb250LWZhbWlseTpDYWxpYnJpLHNhbnMt
c2VyaWYiPg0KPHNwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9IkJP
UkRFUi1MRUZUOiNiNWM0ZGYgNSBzb2xpZDtQQURESU5HOjAgMCAwIDU7TUFSR0lOOjAgMCAwIDUi
Pg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj5Mb29raW5nIGF0IE9w
ZW5JRCBDb25uZWN0IGFuZCBpdOKAmXMgdHJ1c3QgbW9kZWwgZm9yIHByb2R1Y2luZyBpZF90b2tl
bnMgdGhhdCBhc3NlcnQgaWRlbnRpdHkgbWF5IGhlbHAgeW91Lg0KPGRpdj48YSBocmVmPSJodHRw
Oi8vb3BlbmlkLm5ldC93Zy9jb25uZWN0LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9vcGVuaWQu
bmV0L3dnL2Nvbm5lY3QvPC9hPjxicj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlVuZm9ydHVu
YXRlbHkgSSBjYW7igJl0IHF1aXRlIG1ha2Ugb3V0IHdoYXQgeW91IGFyZSB0cnlpbmcgdG8gZG8u
Jm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JdCBzb3J0IG9mIHNvdW5kcyBs
aWtlIHlvdSB3YW50IGFuIGlkX3Rva2VuIGZyb20gYSBpZFAgYW5kIHRoZW4gaGF2ZSB0aGUgY2xp
ZW50IGV4Y2hhbmdlIHRoYXQgYXNzZXJ0aW9uIGZvciBhbm90aGVyIHRva2VuPzwvZGl2Pg0KPGRp
dj48YnI+DQo8L2Rpdj4NCjxkaXY+Sm9obiBCLjxicj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBl
PSJjaXRlIj4NCjxkaXY+T24gQXByIDE5LCAyMDE2LCBhdCAxOjE4IFBNLCBGcmVnbHksIEFuZHJl
dyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFmcmVnbHlAdmVyaXNpZ24uY29tIiB0YXJnZXQ9Il9ibGFu
ayI+YWZyZWdseUB2ZXJpc2lnbi5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxicj4NCjxkaXY+
DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7Zm9udC1zaXplOjE0
cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5v
cm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25l
O3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxkaXYgc3R5bGU9Im1hcmdp
bjowaW4gMGluIDAuMDAwMXB0O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTJwdCI+SSBoYXZlIGEgdXNlIGNhc2Ugd2hlcmUgYSBjbGll
bnQgYXBwbGljYXRpb24gbmVlZHMgdG8gYXV0aGVudGljYXRlIHdpdGggYSBkeW5hbWljYWxseSBk
ZXRlcm1pbmVkIElkZW50aXR5IFByb3ZpZGVyIHRoYXQgaXMgc2VwYXJhdGUgZnJvbSB0aGUgQXV0
aG9yaXphdGlvbiBTZXJ2aWNlDQogdGhhdCB3aWxsIGJlIHVzZWQgaXNzdWUgYW4gYWNjZXNzIHRv
a2VuIHRvIHRoZSBjbGllbnQuIFRoZSB1c2UgY2FzZSBhbHNvIHJlcXVpcmVzIHRoYXQgYXMgcGFy
dCBvZiBhdXRob3JpemF0aW9uLCB0aGUgY2xpZW50IHByb3ZpZGVzIHRvIHRoZSBBdXRob3JpemF0
aW9uIFNlcnZpY2UgYW4gYXV0aGVudGljYXRpb24gdG9rZW4gc2lnbmVkIGJ5IGFuIElkZW50aXR5
IFByb3ZpZGVyIHRoYXQgdGhlIEF1dGhvcml6YXRpb24gU2VydmljZSBoYXMgYSB0cnVzdA0KIHJl
bGF0aW9uc2hpcCB3aXRoLiBUaGUgdHJ1c3QgcmVsYXRpb25zaGlwIGlzIHZlcmlmaWFibGUgYmFz
ZWQgb24gdGhlIEF1dGhvcml6YXRpb24gU2VydmljZSBoYXZpbmcgcmVjb3JkZWQgdGhlIHB1Ymxp
YyBrZXlzIG9yIGNlcnRpZmljYXRlcyBvZiB0cnVzdGVkIElkZW50aXR5IFByb3ZpZGVycyBpbiBh
IHRydXN0IHN0b3JlLCB0aGlzIGFsbG93aW5nIHRoZSBBdXRob3JpemF0aW9uIFNlcnZpY2UgdG8g
dmVyaWZ5IGFuIElkZW50aXR5IFByb3ZpZGVy4oCZcw0KIHNpZ25hdHVyZSBvbiBhbiBhdXRoZW50
aWNhdGlvbiB0b2tlbi48L3NwYW4+PGEgbmFtZT0ibV8tODE4NTQ2NTkxMzIxOTg3MjYzNl9tXy02
NTUxMTM2MDEwNzIwMTc4NzAwX09MRV9MSU5LNSI+PC9hPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy
Z2luOjBpbiAwaW4gMC4wMDAxcHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+
PHU+PC91Pjx1PjwvdT48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0
O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjx1PjwvdT4mbmJzcDs8dT48L3U+
PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFwdDtmb250LXNpemU6MTJw
dDtmb250LWZhbWlseTpDYWxpYnJpIj5JbiBsb29raW5nIGF0IHRoZSB2YXJpb3VzIE9BdXRoIFJG
Q3MsIHBhcnRpY3VsYXJseSBSRkNzIDc1MjEsIDc1MjIsIGFuZCA3NTIzLCBJIHNlZSB0aGF0IHRo
ZXkgZ2V0IG1lIGNsb3NlIGluIHRlcm1zIG9mIHN1cHBvcnRpbmcgdGhlIHVzZSBjYXNlLiBXaGF0
IGlzIG1pc3NpbmcgaXMgYSBtZWFucyBmb3Igc29sdmluZyB0aGUNCiBmb2xsb3dpbmcgcHJvYmxl
bS4gVGhlc2UgUkZDcyByZXF1aXJlIHRoYXQgdGhlIElkZW50aXR5IFByb3ZpZGVyIHB1dCBhbiBB
dWRpZW5jZSBjbGFpbSBpbiB0aGUgYXV0aGVudGljYXRpb24gdG9rZW4uIFRoZSBwcm9ibGVtIHdp
dGggdGhpcyBpcyB0aGF0IEkgZG8gbm90IHNlZSBpbiB0aGUgUkZDcyBob3cgdGhlIElkZW50aXR5
IFByb3ZpZGVyIGNhbiBiZSB0b2xkIHdobyB0aGUgQXVkaWVuY2UgaXMgdG8gcHV0IGludG8gdGhl
IGF1dGhlbnRpY2F0aW9uDQogdG9rZW4uIFRoaXMgbGVhZHMgbWUgdG8gdGhlIHRpdGxlIG9mIHRo
aXMgbWVzc2FnZS4gVGhlIGRyYWZ0IOKAnE9BdXRoIDIuMCBUb2tlbiBFeGNoYW5nZTogQW4gU1RT
IGZvciB0aGUgUkVTVCBvZiBVc+KAnSBkZWZpbmVzIGEgbWVjaGFuaXNtIGZvciBpZGVudGlmeWlu
ZyB0aGUgQXVkaWVuY2UgZm9yIGFuIFNUUyB0byBwdXQgaW50byBhIHRva2VuIGl0IGdlbmVyYXRl
cy4gVGhhdCB3b3VsZCBzb2x2ZSBteSBwcm9ibGVtIGV4Y2VwdCB0aGF0IHRoZSBkcmFmdA0KIGxp
bWl0cyB0aGUgdHlwZSBvZiBTVFMgdG8gYmVpbmcgQXV0aG9yaXphdGlvbiBTZXJ2ZXJzLiBXaGF0
IGlzIG5lZWRlZCBpcyB0aGlzIHNhbWUgY2FwYWJpbGl0eSBmb3IgaW50ZXJhY3Rpbmcgd2l0aCBh
biBJZGVudGl0eSBQcm92aWRlci4gVGhpcyB3b3VsZCBlbmFibGUgUkZDcyA3NTIxLCA3NTIyIGFu
ZCA3NTIzIHRvIGJlIHVzZWZ1bCBpbiBzaXR1YXRpb24gd2hlcmUgdGhlIElkZW50aXR5IFByb3Zp
ZGVyIG5lZWRzIHRvIGJlIHRvbGQgdGhlIGlkZW50aXR5DQogb2YgdGhlIEF1dGhvcml6YXRpb24g
U2VydmljZS48dT48L3U+PHU+PC91PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4g
MC4wMDAxcHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PHU+PC91PiZuYnNw
Ozx1PjwvdT48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0O2ZvbnQt
c2l6ZToxMnB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkkgYW0gbmV3IHRvIGludGVyYWN0aW5nIHdp
dGggdGhlIElFVEYuIEkgYWxzbyBhbSBub3QgYW4gZXhwZXJ0IG9uIHRoZSBSRkNzIG9yIHByaW9y
IGhpc3Rvcnkgb2YgdGhlIE9BdXRoIGdyb3VwIHJlbGF0aXZlIHRvIHRoaXMgdG9waWMsIHNvIHBs
ZWFzZSBwb2ludCBtZSB0byBhbnkgZXhpc3Rpbmcgc29sdXRpb24gaWYgdGhpcw0KIGlzIGEgc29s
dmVkIHByb2JsZW0uIE90aGVyd2lzZSwgSSB3b3VsZCBsaWtlIHRvIGdldCBmZWVkYmFjayBvbiBt
eSBzdWdnZXN0aW9uLjx1PjwvdT48dT48L3U+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MGlu
IDBpbiAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTpDYWxpYnJpIj48dT48L3U+
Jm5ic3A7PHU+PC91PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7
Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+VGhhbmtzIFlvdSw8L2Rpdj4NCjxk
aXYgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFt
aWx5OkNhbGlicmkiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMC4w
MDAxcHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+QW5kcmV3IEZyZWdseTx1
PjwvdT48dT48L3U+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFwdDtm
b250LXNpemU6MTJwdDtmb250LWZhbWlseTpDYWxpYnJpIj5WZXJpc2lnbiBJbmMuPC9kaXY+DQo8
L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjtmb250LXNp
emU6MTRweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNp
bmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3Jt
Om5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2luZzowcHgiPg0KPGRpdj48L2Rpdj4N
CjwvZGl2Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBm
b250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg
bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw
cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNp
bmc6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyI+X19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyIHN0eWxl
PSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7Zm9udC1zaXplOjE0cHg7Zm9udC1zdHls
ZTpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFs
aWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNl
Om5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2Fs
aWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv
bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0
YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6
IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUg
IWltcG9ydGFudDsiPk9BdXRoDQogbWFpbGluZyBsaXN0PC9zcGFuPjxiciBzdHlsZT0iZm9udC1m
YW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxNHB4O2ZvbnQtc3R5bGU6bm9ybWFs
O2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFy
dDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7
d29yZC1zcGFjaW5nOjBweCI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHN0eWxl
PSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7Zm9udC1zaXplOjE0cHg7Zm9udC1zdHls
ZTpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFs
aWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNl
Om5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4IiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8
L2E+PGJyIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7Zm9udC1zaXplOjE0
cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5v
cm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25l
O3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxhIGhyZWY9Imh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHN0eWxlPSJmb250LWZhbWlseTpD
YWxpYnJpLHNhbnMtc2VyaWY7Zm9udC1zaXplOjE0cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13
ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQt
aW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNw
YWNpbmc6MHB4IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9vYXV0aDwvYT48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+PC9kaXY+
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9B
dXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFy
Z2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0
PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+
PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl
Pg0KPC9zcGFuPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_ACF4DECCB69C4E3586D11FCDA0F56A5Cverisigncom_--


From nobody Wed Apr 20 07:31:11 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E35F12EF56 for ; Wed, 20 Apr 2016 07:31:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b43td12TamGV for ; Wed, 20 Apr 2016 07:31:07 -0700 (PDT)
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 19FED12EF57 for ; Wed, 20 Apr 2016 07:31:07 -0700 (PDT)
Received: by mail-oi0-x261.google.com with SMTP id i2so2890299oib.3 for ; Wed, 20 Apr 2016 07:31:06 -0700 (PDT)
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:user-agent :mime-version; bh=yyNoYEe9yffG7dIl1Raq5KzxpJSTB4rhU2icBYARpFA=; b=pVlnIW67DYCxiEUKB+LterL+G7jYkMrwnjvOnjLgdDNKDn7HVAbpPdGVCU9sBziNGH yIINNvNOqgOaceQwzGkB2Xyh6EOBKEDM1m6nWs7V2o1PZQHt0Yykgj9huVOmuqRI3crC kkHaXbxOjwK26sCVEZCb+2jdfP5qbU3wvgg9qTivKEaDALGhv4zcS8boYYjbP7fjxamH ddAyrDsqorXZPjqAdovkAto3AbNiMgSus1A7SwKuDP+RL1XmGwMkBMKNQu8P2ksZ0JE/ 1frKWuGvDTEfGR3IdbuOu80yQfozi3GFj4fi+rHnJ76rVDKeRWJRUbZQsHfydG3ALj0D rCsg==
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 :user-agent:mime-version; bh=yyNoYEe9yffG7dIl1Raq5KzxpJSTB4rhU2icBYARpFA=; b=nHJ4FFovOpymTBANjGtCRe2DPeDg2eJUX0C041hnhHfAQSKA6kepPJ0r5rQMYko8a1 XNBZKDVf3CSgK19JyhKftLt2KcRBV2ncQgkZgJ2cKx94/VL/3ODRzndWWWXPFbD3o0he VFOiAHoRw9+E5G37zA1qTBrM4gAZE07JsrmxqYpyH5rI4/osaIJFZ0AQpoR53R+NeyCw f5iysRYTIMeYk8jSRQBTE/inN3V/jKyx0O+4Ncvakl1c58BqJfEVyllxTCzSpo4rG5Wq lm72D7w14PYm9D3V4RhPhq45ZDonwkSwDAt4A1XoyYHpRcsf4Qko/w3xeAEvyQULGLb2 T+Qg==
X-Gm-Message-State: AOPr4FVEmXT6kjZUj9JrbBpZ1N2PuXnpQb/gG/bXdhgNslFCRnnmz3o0/O6ea9r2nIeMQYknYk9X+G2zg2melzAPiAJjhx/n
X-Received: by 10.140.29.7 with SMTP id a7mr11304059qga.98.1461162666159; Wed, 20 Apr 2016 07:31:06 -0700 (PDT)
Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id y135sm9637599qky.9.2016.04.20.07.31.05 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 20 Apr 2016 07:31:06 -0700 (PDT)
X-Relaying-Domain: verisign.com
Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id u3KEV5Tm023388 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Apr 2016 10:31:05 -0400
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 20 Apr 2016 10:31:02 -0400
From: "Fregly, Andrew" 
To: George Fletcher , John Bradley , "oauth@ietf.org" 
Thread-Topic: =?utf-8?B?W09BVVRILVdHXSBCdWlsZGluZyBvbiB0aGUgcHJvdG9jb2wgaW4gdGhlIGRy?= =?utf-8?B?YWZ0IOKAnE9BdXRoIDIuMCBUb2tlbiBFeGNoYW5nZTogQW4gU1RTIGZvciB0?= =?utf-8?B?aGUgUkVTVCBvZiBVc+KAnSB0byBpbmNsdWRlIEF1dGhlbnRpY2F0aW9uIFRv?= =?utf-8?Q?kens?=
Thread-Index: AQHRmnitgCv5cI6zuEydb4HTyF4ZfZ+RycMAgAFKdgD//9lbgA==
Date: Wed, 20 Apr 2016 14:31:02 +0000
Message-ID: 
References:   <8B748252-9AE2-4824-923B-00CD46CB8D68@verisign.com> <571692A1.5070000@aol.com> <6101D0EB-E04B-4574-8899-ED8F4E631D67@verisign.com> <57177AD0.1090300@aol.com>
In-Reply-To: <57177AD0.1090300@aol.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.160212
x-originating-ip: [10.173.152.4]
Content-Type: multipart/alternative; boundary="_000_C8795E07F9D84CDEA1871EA7D9604E1Fverisigncom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] =?utf-8?q?Building_on_the_protocol_in_the_draft_?= =?utf-8?q?=E2=80=9COAuth_2=2E0_Token_Exchange=3A_An_STS_for_the_REST_of_U?= =?utf-8?q?s=E2=80=9D_to_include_Authentication_Tokens?=
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Apr 2016 14:31:10 -0000

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

SGkgR2VvcmdlLA0KDQpZb3UgZnVsbHkgY2FwdHVyZWQgb25lIG9mIHRoZSBvcHRpb25zIHdlIGhh
dmUgYmVlbiBjb250ZW1wbGF0aW5nLiBJIGRpZG7igJl0IHByb3Bvc2UgdGhpcyBmbG93IGJlY2F1
c2UgSSB3YXMgbG9va2luZyBmb3IgYSB3YXkgdG8gc29sdmUgb3VyIG91ciB1c2UgY2FzZSBiYXNl
ZCBvbiB0aGUgZXhpc3RpbmcgUkZDcyBhbmQgT3BlbklEIENvbm5lY3Qgc3BlY2lmaWNhdGlvbnMg
d2l0aCBtaW5pbWFsIG5ldyBzcGVjaWZpY2F0aW9uIHJlcXVpcmVkLiBUaGF0IGxlZCBtZSB0byB0
aGUgcGF0aCBkZXNjcmliZWQgaW4gdGhlIGVtYWlsIHJlc3BvbnNlIEkgc2VudCBvdXQgYSBsaXR0
bGUgd2hpbGUgYWdvIHRvIE5hdCBTYWtpbXVyYeKAmXMgcmVzcG9uc2UuIFBsZWFzZSB0YWtlIGEg
bG9vayBhdCB0aGF0IGVtYWlsIGFuZCBzZWUgd2hhdCB5b3UgdGhpbmsuDQoNCkdpdmVuIGhvdyB3
ZWxsIHN0YXRlZCB5b3VyIHN1bW1hcnkgb2Ygb3VyIG5lZWRzIHdhcywgZG8geW91IHN0aWxsIHdh
bnQgbWUgdG8gcHJvdmlkZSBhIGRpYWdyYW0/DQoNClRoYW5rcywNCiAgICBBbmR5DQoNCkZyb206
IEdlb3JnZSBGbGV0Y2hlciA8Z2ZmbGV0Y2hAYW9sLmNvbTxtYWlsdG86Z2ZmbGV0Y2hAYW9sLmNv
bT4+DQpPcmdhbml6YXRpb246IEFPTCBMTEMNCkRhdGU6IFdlZG5lc2RheSwgQXByaWwgMjAsIDIw
MTYgYXQgODo0OSBBTQ0KVG86IEFuZHJldyBGcmVnbHkgPGFmcmVnbHlAdmVyaXNpZ24uY29tPG1h
aWx0bzphZnJlZ2x5QHZlcmlzaWduLmNvbT4+LCBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIu
Y29tPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4+LCAib2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9h
dXRoQGlldGYub3JnPiIgPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpT
dWJqZWN0OiBSZTogW09BVVRILVdHXSBCdWlsZGluZyBvbiB0aGUgcHJvdG9jb2wgaW4gdGhlIGRy
YWZ0IOKAnE9BdXRoIDIuMCBUb2tlbiBFeGNoYW5nZTogQW4gU1RTIGZvciB0aGUgUkVTVCBvZiBV
c+KAnSB0byBpbmNsdWRlIEF1dGhlbnRpY2F0aW9uIFRva2Vucw0KDQpJIHNob3VsZCBwcm9iYWJs
eSBqdXN0IHdhaXQgZm9yIHRoZSBkaWFncmFtLi4uIGJ1dCBub3Qgd2FudGluZyB0byB3YWl0Li4u
IDopDQoNCklmIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHksIHRoZSB1c2VyIGlzIGdvaW5nIHRvIHVz
ZSBhIGNsaWVudCBhbmQgdGhlIGNsaWVudCB3aWxsIGF1dGhlbnRpY2F0ZSB0aGUgdXNlciB2aWEg
c29tZSBJZFAgdXNpbmcgYW4gZXhpc3RpbmcgbWV0aG9kIChTQU1MLCBMREFQICg/KSwgT3BlbklE
IENvbm5lY3QsIGV0YykuIFRoZSBkZXNpcmUgaXMgdG8gdGFrZSB0aGF0IHJlc3BvbnNlIGFuZCBp
biBzb21lIHdheSBwcmVzZW50IGl0IHRvIGFuICJBdXRob3JpemF0aW9uIFNlcnZlciIgd2hpY2gg
d2lsbCB2YWxpZGF0ZSB0aGUgImF1dGhlbnRpY2F0aW9uIHJlc3BvbnNlIiBhbmQgcmV0dXJuIGFu
IGFjY2VzcyB0b2tlbiBmb3IgdXNlIGF0IHRoZSBkYXRhIHByb3ZpZGVyKHMpLg0KDQpXaGF0IGlm
IHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBhbHNvIHRvb2sgb24gdGhlIHJvbGUgb2YgdGhlIE9w
ZW5JRCBDb25uZWN0IHByb3ZpZGVyLiBUaGlzIGNvdWxkIHdvcmsgYnkgaGF2aW5nIHRoZSBjbGll
bnQgc3RhcnQgYW4gT3BlbklEIENvbm5lY3QgZmxvdyB3aXRoIEF1dGhvcml6YXRpb24gU2VydmVy
IChoaW50cyBjb3VsZCBiZSBwcm92aWRlZCBhcyB0byB3aGljaCBJZFAgdGhlIHVzZXIgd2FudHMg
dG8gYXV0aGVudGljYXRlIGF0KS4gVGhlIEFTIHdvdWxkIGxvb2sgYXQgdGhlICJpZHAgaGludCIg
YW5kIGVpdGhlciBzdGFydCBhbmQgU1AgU0FNTCBmbG93LCBvciBwcmVzZW50IFVJIGZvciBjb2xs
ZWN0aW5nIExEQVAgY3JlZGVudGlhbHMgKEkgZG9uJ3QgcmVjb21tZW5kIHRoaXMpIG9yIGNoYWlu
IHRvIGFueSBvdGhlciBwcm9wcmlldGFyeSBJZFAgZmxvdy4gT25jZSB0aGUgdXNlciBzdWNjZXNz
ZnVsbHkgYXV0aGVudGljYXRlcyB3aXRoIHRoZSBjb3JyZWN0IElkUCwgdGhlIEFTIHdpbGwgZmlu
aXNoIHRoZSBPcGVuSUQgQ29ubmVjdCBmbG93IGFsbG93aW5nIHRoZSBjbGllbnQgdG8gb2J0YWlu
IGFuIGFjY2VzcyB0b2tlbiwgcmVmcmVzaCB0b2tlbiBhbmQgaWRfdG9rZW4uIFRoZSBBUyBjb3Vs
ZCBhZGQgdG8gdGhlIGlkX3Rva2VuIGEgY2xhaW0gc3BlY2lmeWluZyB3aGljaCBJZFAgdGhlIHVz
ZXIgdXNlZCBkdXJpbmcgdGhlIGF1dGhlbnRpY2F0aW9uIHByb2Nlc3NlZC4NCg0KVGhlIElkUCB0
aGUgdXNlciB1c2VkIGZvciBhdXRoZW50aWNhdGlvbiBjb3VsZCBhbHNvIGJlIGVuY29kZWQgaW4g
dGhlIGFjY2Vzc190b2tlbiAob3IgcmV0dXJuZWQgYXMgcGFydCBvZiBhbiBpbnRyb3NwZWN0aW9u
IGNhbGwpLg0KDQpUaGlzIHdheSB3aGV0aGVyIHRoZSBkYXRhIHByb3ZpZGVycyBhcmUgdmFsaWRh
dGluZyB0aGUgYWNjZXNzX3Rva2VucyBsb2NhbGx5IG9yIHVzaW5nIGludHJvc3BlY3Rpb24gdGhl
eSBjYW4gb2J0YWluIHRoZSBJZFAgdGhlIHVzZXIgdXNlZCBhbmQgYXBwbHkgdGhlaXIgb3duIGF1
dGhvcml6YXRpb24gcnVsZXMuDQoNClRoZSB1c2VyIGlzIG9ubHkgcmVxdWlyZWQgdG8gZG8gb25l
IGF1dGhvcml6YXRpb24gZmxvdyBmb3IgdGhlIGNsaWVudCB0aGF0IGlzIG1hbmFnZWQgYnkgdGhl
IEF1dGhvcml6YXRpb24gU2VydmVyLg0KDQpUaGFua3MsDQpHZW9yZ2UNCg0KT24gNC8xOS8xNiA1
OjA2IFBNLCBGcmVnbHksIEFuZHJldyB3cm90ZToNClRoYW5rIHlvdSBmb3IgeW91ciByZXNwb25z
ZSBHZW9yZ2UuIEl0IHBvaW50cyBtZSB0byBzb21lIG1vcmUgcmVzZWFyY2ggdG8gZG8sIHN1Y2gg
YXMgbG9va2luZyBhdCBPcGVuSUQgQ29ubmVjdCBzdXBwb3J0IGZvciBib3RoIGRpc3RyaWJ1dGVk
IGFuZCBhZ2dyZWdhdGVkIGNsYWltcy4NCg0KQmVsb3cgYXJlIHJlcGxpZXMgdG8geW91ciBxdWVz
dGlvbnMvYXNzZXJ0aW9ucyBiYXNlZCBvbiBteSBjdXJyZW50IHVuZGVyc3RhbmRpbmcgb2YgdGhl
IHZhcmlvdXMgcHJvdG9jb2xzLiBGdXJ0aGVyIHJlc2VhcmNoIGFuZCBhZHZpY2Ugd2lsbCBsaWtl
bHkgZW5yaWNoIHRoaXMgc2lnbmlmaWNhbnRseS4NCg0KWWVzLCB3aGF0IGlzIHJlcXVpcmVkIGlz
IGEgdmVyaWZpYWJsZSBjbGFpbSB0aGF0IHRoZSB1c2VyIGlzIHN0aWxsIGEgbWVtYmVyIG9mIFNv
bWVPcmcgSW5jLiBJIGhhdmUgYmVlbiBvcGVyYXRpbmcgdW5kZXIgdGhlIGFzc3VtcHRpb24gdGhh
dCB0aGUgb25seSB3YXkgdGhpcyBjYW4gYmUgZG9uZSB3b3VsZCBiZSB0byBoYXZlIHRoZSB1c2Vy
IGF1dGhlbnRpY2F0ZWQgYnkgdGhlIElkZW50aXR5IFByb3ZpZGVyIGZvciBTb21lT3JnLiBQZXJo
YXBzIHRoZSByZXNlYXJjaCBpbnRvIE9wZW5JRCBDb25uZWN0IHN1cHBvcnQgZm9yIGRpc3RyaWJ1
dGVkIGFuZCBhZ2dyZWdhdGVkIGNsYWltcyB3aWxsIHJldmVhbCBhbiBhbHRlcm5hdGl2ZS4gSSBm
b3Jlc2VlIGEgY2hhbGxlbmdlIGluIGRlYWxpbmcgd2l0aCBJZGVudGl0eSBQcm92aWRlcuKAmXMg
Zm9yIG9yZ2FuaXphdGlvbnMgdXNpbmcgU0FNTCBhc3NlcnRpb25zIG9uIHRvcCBvZiBBY3RpdmUg
RGlyZWN0b3J5IGFuZCBMREFQLCBhbmQgd2hpY2ggYXJlIG5vdCBnb2luZyB0byBkbyBhbnkgdXBk
YXRpbmcgdG8gc3VwcG9ydCBvdXIgbmVlZHMuDQoNCldlIGRvIG5vdCBleHBlY3QgdGhlIHVzZXIg
dG8gZmlyc3QgZ28gdG8gdGhlIGRhdGEgcHJvdmlkZXIuIFdlIGFudGljaXBhdGUgdGhhdCB0aGUg
Y2xpZW50IGFwcGxpY2F0aW9uIHdvdWxkIHByb3ZpZGUgYSBBdXRoZW50aWNhdGlvbiBUb2tlbiB0
byBhbiAgQXV0aG9yaXphdGlvbiBTZXJ2aWNlIHNlcnZpY2UgdGhhdCB0aGVuIGlzc3VlcyB0byB0
aGUgY2xpZW50IGFuIGFjY2VzcyB0b2tlbiB0aGF0IHRoZSBkYXRhIHByb3ZpZGVyIHdpbGwgdHJ1
c3QuIE9uZSBvZiBvdXIgcmVhc29ucyBmb3IgZG9pbmcgaXQgdGhpcyB3YXkgaXMgdGhhdCB3ZSBh
cmUgdHJ5aW5nIHRvIGVsaW1pbmF0ZSByZWRpcmVjdHMgdG8gZWFzZSBpbXBsZW1lbnRhdGlvbiBv
ZiBhIG5hdGl2ZSBjbGllbnQuIFdlIGFyZSB0aGVyZWZvcmUgcmVxdWlyaW5nIHRoZSBjbGllbnQg
dG8gaGFuZGxlIGF1dGhlbnRpY2F0aW9uIHdpdGggdGhlIElkZW50aXR5IFByb3ZpZGVyIGFzIGEg
c2VwYXJhdGUgc3RlcCBmcm9tIGF1dGhvcml6YXRpb24uDQoNCkl0IG1pZ2h0IGhlbHAgaWYgSSBj
bGFyaWZpZWQgdGhhdCBWZXJpc2lnbuKAmXMgcm9sZSBpbiB0aGUgc2NlbmFyaW8gSSBkZXNjcmli
ZWQgaXMgdG8gYmUganVzdCBvbmUgb2YgbWFueSBkYXRhIHByb3ZpZGVycy4NCg0KRnJvbTogR2Vv
cmdlIEZsZXRjaGVyIDxnZmZsZXRjaEBhb2wuY29tPG1haWx0bzpnZmZsZXRjaEBhb2wuY29tPj4N
Ck9yZ2FuaXphdGlvbjogQU9MIExMQw0KRGF0ZTogVHVlc2RheSwgQXByaWwgMTksIDIwMTYgYXQg
NDoxOCBQTQ0KVG86IEFuZHJldyBGcmVnbHkgPDxtYWlsdG86YWZyZWdseUB2ZXJpc2lnbi5jb20+
YWZyZWdseUB2ZXJpc2lnbi5jb208bWFpbHRvOmFmcmVnbHlAdmVyaXNpZ24uY29tPj4sIEpvaG4g
QnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4sICI8
bWFpbHRvOm9hdXRoQGlldGYub3JnPm9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9y
Zz4iIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6
IFtPQVVUSC1XR10gQnVpbGRpbmcgb24gdGhlIHByb3RvY29sIGluIHRoZSBkcmFmdCDigJxPQXV0
aCAyLjAgVG9rZW4gRXhjaGFuZ2U6IEFuIFNUUyBmb3IgdGhlIFJFU1Qgb2YgVXPigJ0gdG8gaW5j
bHVkZSBBdXRoZW50aWNhdGlvbiBUb2tlbnMNCg0KU28gaWYgSSB1bmRlcnN0YW5kIHRoaXMgY29y
cmVjdGx5LCB3aGF0IGlzIHJlYWxseSByZXF1aXJlZCBpcyBhIHZlcmlmaWFibGUgY2xhaW0gdGhh
dCB0aGUgdXNlciBpcyBzdGlsbCBhIG1lbWJlciBvZiBTb21lT3JnIEluYy4gT3BlbklEIENvbm5l
Y3Qgc3VwcG9ydHMgYm90aCBkaXN0cmlidXRlZCBhbmQgYWdncmVnYXRlZCBjbGFpbXMgdGhhdCBj
YW4gYmUgc2lnbmVkIGJ5IHRoZSBhcHByb3ByaWF0ZSBJZGVudGl0eSBQcm92aWRlci4gVGhlIHBv
aW50IGJlaW5nIHRoYXQgSSdtIG5vdCBzdXJlIGFuICJhdXRoZW50aWNhdGlvbiB0b2tlbiIgaXMg
cmVxdWlyZWQgZm9yIHRoaXMgdXNlIGNhc2UgdG8gc3VjY2VlZCwgaXQncyBqdXN0IG9uZSBraW5k
IG9mIHRva2VuIHRoYXQgY2FuIGJlIHVzZWQuDQoNCkFsc28sIGlzIHRoZSBleHBlY3RlZCBmbG93
IHRoYXQgdGhlIHVzZXIgd2lsbCBmaXJzdCBnbyB0byB0aGUgZGF0YSBwcm92aWRlciBhbmQgdGhl
biBiZSBkaXJlY3RlZCBlbHNlIHdoZXJlIGZyb20gdGhlcmU/IElmIHRoYXQgaXMgdGhlIGNhc2Us
IHRoZSBkYXRhIHByb3ZpZGVyIGNhbiBqdXN0IGJlIGFuIE9wZW5JRCBDb25uZWN0IHJlbHlpbmcg
cGFydHkgYW5kIGdpdmUgdGhlIHVzZXIgYW4gb3B0aW9uIG9mIHRoZSBsaXN0IG9mIHN1cHBvcnRl
ZCBJZFBzIHRvIGNob29zZSBmcm9tLiBUaGUgdXNlciB3aWxsIHRoZW4gYmUgcmVkaXJlY3RlZCB0
byBTb21lT3JnIEluYy4gSWRQLCBhdXRoZW50aWNhdGUgYW5kIHRoZSBkYXRhIHByb3ZpZGVyIHdp
bGwgaGF2ZSB0aGUgYXV0aG9yaXphdGlvbiBhbmQgcmVjZW50IGF1dGhlbnRpY2F0aW9uIHRoZXkg
Y2FuIHZhbGlkYXRlLg0KDQpJcyB0aGUgdXNlci9kYXRhIGZsb3cgbW9yZSBjb21wbGljYXRlZCB0
aGFuIHRoaXM/DQoNClRoYW5rcywNCkdlb3JnZQ0KDQpPbiA0LzE5LzE2IDQ6MDUgUE0sIEZyZWds
eSwgQW5kcmV3IHdyb3RlOg0KVGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlIEpvaG4uIEkgYWxzbyBn
b3QgYSBnb29kIHJlc3BvbnNlIGZyb20gQnJpYW4gQ2FtcGJlbGwgYW5kIGFwcHJlY2lhdGUgdGhh
dC4gSSB3aWxsIHJlc3BvbmQgc2VwYXJhdGVseSB0byBCcmlhbuKAmXMgcmVzcG9uc2UgYXMgSSB0
aGluayBpdCB3b3VsZCBrZWVwIHRoaW5ncyBjbGVhcmVyIHRvIGRvIHRoYXQuDQoNClRoZSBwcm9i
bGVtIHdlIGhhdmUgZm9yIHVzaW5nIE9wZW5JRCBDb25uZWN0IGlzIHRoYXQgaXQgY29tYmluZXMg
dGhlIHJvbGUgb2YgQXV0aGVudGljYXRpb24gU2VydmljZSB3aXRoIHRoZSByb2xlIG9mIEF1dGhv
cml6YXRpb24gU2VydmljZS4gUGVyaGFwcyB0aGUgZm9sbG93aW5nIGRlc2NyaXB0aW9uIG9mIHdo
YXQgd2Ugd2FudCB0byBkbyB3aWxsIGNsYXJpZnkgd2h5IHRoaXMgd29u4oCZdCB3b3JrIGZvciB1
czoNCg0KVGhlIGJhc2ljIHByb2JsZW0gc3RhdGVtZW50IGlzIHRoYXQgd2UgbmVlZCB0byBoYXZl
IGEgY2xpZW50IGFwcGxpY2F0aW9uIGF1dGhvcml6ZWQgYnkgYSBTZXJ2aWNlIFByb3ZpZGVyIGJh
c2VkIG9uIHByb29mIHRoYXQgYSB1c2VyIGlzIGN1cnJlbnRseSBhIG1lbWJlciBvZiBzb21lIG9y
Z2FuaXphdGlvbi4gVGhpcyBhc3N1bWVzIHRoZSBvcmdhbml6YXRpb24gaGFzIHByZXZpb3VzbHkg
ZXN0YWJsaXNoZWQgc29tZSBsZXZlbCBvZiBhdXRob3JpemVkIGFjY2VzcyB3aXRoIHRoZSBTZXJ2
aWNlIFByb3ZpZGVyLg0KDQpIZXJlIGlzIGFuIGV4YW1wbGU6IFN1cHBvc2UgSSBhbSBhIG1lbWJl
ciBvZiBTb21lT3JnIEluYy4gU3VwcG9zZSBTb21lT3JnIEluYy4gaXMgZG9pbmcgcmVzZWFyY2gg
dGhhdCByZXF1aXJlcyBpdCB0byBnYXRoZXIgZGF0YSBvdmVyIHRoZSBJbnRlcm5ldCBmcm9tIGEg
bnVtYmVyIG9mIGRhdGEgcHJvdmlkZXJzLiBUaGUgZGF0YSBwcm92aWRlcnMgcmVxdWlyZSBhdXRo
ZW50aWNhdGlvbiBhbmQgcHJvb2Ygb2Ygb3JnYW5pemF0aW9uYWwgbWVtYmVyc2hpcCBpbiBvcmRl
ciB0byBhdXRob3JpemUgdmFyaW91cyBsZXZlbHMgb2YgYWNjZXNzIHRvIHRoZWlyIGRhdGEuIFRo
ZSBkYXRhIHByb3ZpZGVycyBkbyBub3QgY29uc2lkZXIgaGF2aW5nIGFuIGFjY291bnQgd2l0aCB0
aGVtIG9yIGEgUHVibGljIElkZW50aXR5IFByb3ZpZGVyIHRvIGJlIHN1aXRhYmxlIGZvciBwcm92
aW5nIHRoYXQgSSBhbSBzdGlsbCBhIG1lbWJlciBvZiBTb21lT3JnIGF0IHRpbWUgb2YgYXV0aGVu
dGljYXRpb24uIFRoZXkgd291bGQgaGF2ZSBubyB3YXkgb2Yga25vd2luZyB3aGV0aGVyIG9yIG5v
dCBteSByZWxhdGlvbnNoaXAgd2l0aCBTb21lT3JnIHN0aWxsIGV4aXN0cyBhdCB0aGF0IHRpbWUu
IFRoZSBkYXRhIHByb3ZpZGVycyB3b3VsZCB0aGVyZWZvcmUgbGlrZSB0aGUgQ2xpZW50IHNvZnR3
YXJlIHRvIGF1dGhlbnRpY2F0ZSBtZSBhZ2FpbnN0IFNvbWVPcmdzIElkZW50aXR5IFByb3ZpZGVy
LiBUaGlzIHdvdWxkIGJlIGdvb2QgcHJvb2YgdGhhdCBJIGFtIHN0aWxsIGEgbWVtYmVyIG9mIFNv
bWVPcmcgYXQgdGhlIHRpbWUgSSBhdXRoZW50aWNhdGUuIFRoaXMgYXV0aGVudGljYXRpb24gd291
bGQgZW5hYmxlIHRoZSBkYXRhIHByb3ZpZGVycyBBdXRob3JpemF0aW9uIFNlcnZlciB0byBncmFu
dCBtZSBhY2Nlc3MgYXBwcm9wcmlhdGUgdG8gYSBtZW1iZXIgb2YgU29tZU9yZy4gIE5vdGUgdGhh
dCBhcyBhIHByZXJlcXVpc2l0ZSB0byBhbGwgb2YgdGhpcywgU29tZU9yZyB3aWxsIGhhdmUgdXNl
ZCBhbiBvdXQtb2YtYmFuZCBwcm9jZXNzIHRvIHNldCB1cCBhIHRydXN0IHJlbGF0aW9uc2hpcCBm
b3IgU29tZU9yZydzIElkZW50aXR5IFByb3ZpZGVyIHdpdGggdGhlIGRhdGEgcHJvdmlkZXLigJlz
IEF1dGhvcml6YXRpb24gU2VydmljZSwgYW5kIHdpbGwgaGF2ZSBuZWdvdGlhdGVkIGF1dGhvcml6
YXRpb24gY2xhaW1zIHRvIGJlIGdyYW50ZWQgdG8gU29tZU9yZ3MgbWVtYmVycy4NCg0KV2hhdCBJ
IGFtIGhhdmluZyBkaWZmaWN1bHR5IHdpdGggaXMgaW4ga25pdHRpbmcgdG9nZXRoZXIgYW4gYXBw
cm9hY2ggYmFzZWQgb24gdGhlIGhlIE9wZW5JRCBDb25uZWN0IHNwZWNpZmljYXRpb25zLCBTQU1M
IHNwZWNpZmljYXRpb25zLCBhbmQgT0F1dGggUkZDcyBhbmQgZHJhZnRzIGluIGEgd2F5IHRoYXQg
c3VwcG9ydHMgdGhlIGFib3ZlIHVzZSBjYXNlIGVuZC10by1lbmQuIFRoZSBPQXV0aCBSRkNzIGFu
ZCBkcmFmdHMgYWxtb3N0IGdldCBtZSB0aGVyZS4gV2hhdCBzZWVtcyB0byBiZSBtaXNzaW5nIGlz
IGEgd2F5IG9mIHRlbGxpbmcgYW4gSWRlbnRpdHkgUHJvdmlkZXIgdGhlIFVSTCBmb3IgdGhlIEF1
dGhvcml6YXRpb24gU2VydmljZSAodGhlIHJlcXVpcmVkIEF1ZGllbmNlIGNsYWltIGluIGFuIGF1
dGhlbnRpY2F0aW9uIGFzc2VydGlvbiBhcyBkZWZpbmVkIGluIFJGQ3MgNzI1MSwgNzI1MiBhbmQg
NzI1MyksIGFuZCB0aGVuIGEgcmVxdWlyZW1lbnQgdGhhdCB0aGUgSWRlbnRpdHkgUHJvdmlkZXJz
IHB1dCB0aGUgc3VwcGxpZWQgQXVkaWVuY2UgSWRlbnRpZmllciBpbnRvIEF1dGhlbnRpY2F0aW9u
IFRva2Vucy4gUGVyaGFwcyBhIGxpdHRsZSBmdXJ0aGVyIGJhY2stYW5kLWZvcnRoIHdpdGggQnJp
YW4gd2lsbCByZXNvbHZlIHRoaXMuDQoNCkkgY2FuIGdvIGludG8gZGVlcGVyIGRldGFpbCBpZiBu
ZWVkZWQuIElmIHRoaXMgaXMgb2ZmLXRvcGljIGZvciB0aGUgT0F1dGggd29ya2luZyBncm91cCwg
bGV0IG1lIGtub3cuDQoNClRoYW5rcywNCkFuZHJldyBGcmVnbHkNClZlcmlzaWduIEluYy4NCg0K
DQpGcm9tOiBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3
anRiLmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBBcHJpbCAxOSwgMjAxNiBhdCAyOjA2IFBNDQpUbzog
QW5kcmV3IEZyZWdseSA8YWZyZWdseUB2ZXJpc2lnbi5jb208bWFpbHRvOmFmcmVnbHlAdmVyaXNp
Z24uY29tPj4NCkNjOiAiPG1haWx0bzpvYXV0aEBpZXRmLm9yZz5vYXV0aEBpZXRmLm9yZzxtYWls
dG86b2F1dGhAaWV0Zi5vcmc+IiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3Jn
Pj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEJ1aWxkaW5nIG9uIHRoZSBwcm90b2NvbCBpbiB0
aGUgZHJhZnQg4oCcT0F1dGggMi4wIFRva2VuIEV4Y2hhbmdlOiBBbiBTVFMgZm9yIHRoZSBSRVNU
IG9mIFVz4oCdIHRvIGluY2x1ZGUgQXV0aGVudGljYXRpb24gVG9rZW5zDQoNCkxvb2tpbmcgYXQg
T3BlbklEIENvbm5lY3QgYW5kIGl04oCZcyB0cnVzdCBtb2RlbCBmb3IgcHJvZHVjaW5nIGlkX3Rv
a2VucyB0aGF0IGFzc2VydCBpZGVudGl0eSBtYXkgaGVscCB5b3UuDQpodHRwOi8vb3BlbmlkLm5l
dC93Zy9jb25uZWN0Lw0KDQpVbmZvcnR1bmF0ZWx5IEkgY2Fu4oCZdCBxdWl0ZSBtYWtlIG91dCB3
aGF0IHlvdSBhcmUgdHJ5aW5nIHRvIGRvLg0KDQpJdCBzb3J0IG9mIHNvdW5kcyBsaWtlIHlvdSB3
YW50IGFuIGlkX3Rva2VuIGZyb20gYSBpZFAgYW5kIHRoZW4gaGF2ZSB0aGUgY2xpZW50IGV4Y2hh
bmdlIHRoYXQgYXNzZXJ0aW9uIGZvciBhbm90aGVyIHRva2VuPw0KDQpKb2huIEIuDQpPbiBBcHIg
MTksIDIwMTYsIGF0IDE6MTggUE0sIEZyZWdseSwgQW5kcmV3IDw8bWFpbHRvOmFmcmVnbHlAdmVy
aXNpZ24uY29tPmFmcmVnbHlAdmVyaXNpZ24uY29tPG1haWx0bzphZnJlZ2x5QHZlcmlzaWduLmNv
bT4+IHdyb3RlOg0KDQpJIGhhdmUgYSB1c2UgY2FzZSB3aGVyZSBhIGNsaWVudCBhcHBsaWNhdGlv
biBuZWVkcyB0byBhdXRoZW50aWNhdGUgd2l0aCBhIGR5bmFtaWNhbGx5IGRldGVybWluZWQgSWRl
bnRpdHkgUHJvdmlkZXIgdGhhdCBpcyBzZXBhcmF0ZSBmcm9tIHRoZSBBdXRob3JpemF0aW9uIFNl
cnZpY2UgdGhhdCB3aWxsIGJlIHVzZWQgaXNzdWUgYW4gYWNjZXNzIHRva2VuIHRvIHRoZSBjbGll
bnQuIFRoZSB1c2UgY2FzZSBhbHNvIHJlcXVpcmVzIHRoYXQgYXMgcGFydCBvZiBhdXRob3JpemF0
aW9uLCB0aGUgY2xpZW50IHByb3ZpZGVzIHRvIHRoZSBBdXRob3JpemF0aW9uIFNlcnZpY2UgYW4g
YXV0aGVudGljYXRpb24gdG9rZW4gc2lnbmVkIGJ5IGFuIElkZW50aXR5IFByb3ZpZGVyIHRoYXQg
dGhlIEF1dGhvcml6YXRpb24gU2VydmljZSBoYXMgYSB0cnVzdCByZWxhdGlvbnNoaXAgd2l0aC4g
VGhlIHRydXN0IHJlbGF0aW9uc2hpcCBpcyB2ZXJpZmlhYmxlIGJhc2VkIG9uIHRoZSBBdXRob3Jp
emF0aW9uIFNlcnZpY2UgaGF2aW5nIHJlY29yZGVkIHRoZSBwdWJsaWMga2V5cyBvciBjZXJ0aWZp
Y2F0ZXMgb2YgdHJ1c3RlZCBJZGVudGl0eSBQcm92aWRlcnMgaW4gYSB0cnVzdCBzdG9yZSwgdGhp
cyBhbGxvd2luZyB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2aWNlIHRvIHZlcmlmeSBhbiBJZGVudGl0
eSBQcm92aWRlcuKAmXMgc2lnbmF0dXJlIG9uIGFuIGF1dGhlbnRpY2F0aW9uIHRva2VuLg0KDQpJ
biBsb29raW5nIGF0IHRoZSB2YXJpb3VzIE9BdXRoIFJGQ3MsIHBhcnRpY3VsYXJseSBSRkNzIDc1
MjEsIDc1MjIsIGFuZCA3NTIzLCBJIHNlZSB0aGF0IHRoZXkgZ2V0IG1lIGNsb3NlIGluIHRlcm1z
IG9mIHN1cHBvcnRpbmcgdGhlIHVzZSBjYXNlLiBXaGF0IGlzIG1pc3NpbmcgaXMgYSBtZWFucyBm
b3Igc29sdmluZyB0aGUgZm9sbG93aW5nIHByb2JsZW0uIFRoZXNlIFJGQ3MgcmVxdWlyZSB0aGF0
IHRoZSBJZGVudGl0eSBQcm92aWRlciBwdXQgYW4gQXVkaWVuY2UgY2xhaW0gaW4gdGhlIGF1dGhl
bnRpY2F0aW9uIHRva2VuLiBUaGUgcHJvYmxlbSB3aXRoIHRoaXMgaXMgdGhhdCBJIGRvIG5vdCBz
ZWUgaW4gdGhlIFJGQ3MgaG93IHRoZSBJZGVudGl0eSBQcm92aWRlciBjYW4gYmUgdG9sZCB3aG8g
dGhlIEF1ZGllbmNlIGlzIHRvIHB1dCBpbnRvIHRoZSBhdXRoZW50aWNhdGlvbiB0b2tlbi4gVGhp
cyBsZWFkcyBtZSB0byB0aGUgdGl0bGUgb2YgdGhpcyBtZXNzYWdlLiBUaGUgZHJhZnQg4oCcT0F1
dGggMi4wIFRva2VuIEV4Y2hhbmdlOiBBbiBTVFMgZm9yIHRoZSBSRVNUIG9mIFVz4oCdIGRlZmlu
ZXMgYSBtZWNoYW5pc20gZm9yIGlkZW50aWZ5aW5nIHRoZSBBdWRpZW5jZSBmb3IgYW4gU1RTIHRv
IHB1dCBpbnRvIGEgdG9rZW4gaXQgZ2VuZXJhdGVzLiBUaGF0IHdvdWxkIHNvbHZlIG15IHByb2Js
ZW0gZXhjZXB0IHRoYXQgdGhlIGRyYWZ0IGxpbWl0cyB0aGUgdHlwZSBvZiBTVFMgdG8gYmVpbmcg
QXV0aG9yaXphdGlvbiBTZXJ2ZXJzLiBXaGF0IGlzIG5lZWRlZCBpcyB0aGlzIHNhbWUgY2FwYWJp
bGl0eSBmb3IgaW50ZXJhY3Rpbmcgd2l0aCBhbiBJZGVudGl0eSBQcm92aWRlci4gVGhpcyB3b3Vs
ZCBlbmFibGUgUkZDcyA3NTIxLCA3NTIyIGFuZCA3NTIzIHRvIGJlIHVzZWZ1bCBpbiBzaXR1YXRp
b24gd2hlcmUgdGhlIElkZW50aXR5IFByb3ZpZGVyIG5lZWRzIHRvIGJlIHRvbGQgdGhlIGlkZW50
aXR5IG9mIHRoZSBBdXRob3JpemF0aW9uIFNlcnZpY2UuDQoNCkkgYW0gbmV3IHRvIGludGVyYWN0
aW5nIHdpdGggdGhlIElFVEYuIEkgYWxzbyBhbSBub3QgYW4gZXhwZXJ0IG9uIHRoZSBSRkNzIG9y
IHByaW9yIGhpc3Rvcnkgb2YgdGhlIE9BdXRoIGdyb3VwIHJlbGF0aXZlIHRvIHRoaXMgdG9waWMs
IHNvIHBsZWFzZSBwb2ludCBtZSB0byBhbnkgZXhpc3Rpbmcgc29sdXRpb24gaWYgdGhpcyBpcyBh
IHNvbHZlZCBwcm9ibGVtLiBPdGhlcndpc2UsIEkgd291bGQgbGlrZSB0byBnZXQgZmVlZGJhY2sg
b24gbXkgc3VnZ2VzdGlvbi4NCg0KVGhhbmtzIFlvdSwNCg0KQW5kcmV3IEZyZWdseQ0KVmVyaXNp
Z24gSW5jLg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
Ck9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3Jn
Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0KDQpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFp
bGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+aHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg==

--_000_C8795E07F9D84CDEA1871EA7D9604E1Fverisigncom_
Content-Type: text/html; charset="utf-8"
Content-ID: <8DB1254E153439498EB614D891AD391E@verisign.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8
ZGl2PkhpIEdlb3JnZSw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PllvdSBmdWxseSBj
YXB0dXJlZCBvbmUgb2YgdGhlIG9wdGlvbnMgd2UgaGF2ZSBiZWVuIGNvbnRlbXBsYXRpbmcuIEkg
ZGlkbuKAmXQgcHJvcG9zZSB0aGlzIGZsb3cgYmVjYXVzZSBJIHdhcyBsb29raW5nIGZvciBhIHdh
eSB0byBzb2x2ZSBvdXIgb3VyIHVzZSBjYXNlIGJhc2VkIG9uIHRoZSBleGlzdGluZyBSRkNzIGFu
ZCBPcGVuSUQgQ29ubmVjdCBzcGVjaWZpY2F0aW9ucyB3aXRoIG1pbmltYWwgbmV3IHNwZWNpZmlj
YXRpb24gcmVxdWlyZWQuDQogVGhhdCBsZWQgbWUgdG8gdGhlIHBhdGggZGVzY3JpYmVkIGluIHRo
ZSBlbWFpbCByZXNwb25zZSBJIHNlbnQgb3V0IGEgbGl0dGxlIHdoaWxlIGFnbyB0byBOYXQgU2Fr
aW11cmHigJlzIHJlc3BvbnNlLiBQbGVhc2UgdGFrZSBhIGxvb2sgYXQgdGhhdCBlbWFpbCBhbmQg
c2VlIHdoYXQgeW91IHRoaW5rLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+R2l2ZW4g
aG93IHdlbGwgc3RhdGVkIHlvdXIgc3VtbWFyeSBvZiBvdXIgbmVlZHMgd2FzLCBkbyB5b3Ugc3Rp
bGwgd2FudCBtZSB0byBwcm92aWRlIGEgZGlhZ3JhbT88L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+
DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwOyBBbmR5PC9kaXY+DQo8ZGl2
Pg0KPGRpdiBpZD0iTUFDX09VVExPT0tfU0lHTkFUVVJFIj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJ
T04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjEycHQ7IHRl
eHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBC
T1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVG
VDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlk
OyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0
eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+R2VvcmdlIEZsZXRjaGVyICZsdDs8
YSBocmVmPSJtYWlsdG86Z2ZmbGV0Y2hAYW9sLmNvbSI+Z2ZmbGV0Y2hAYW9sLmNvbTwvYT4mZ3Q7
PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPk9yZ2FuaXphdGlvbjogPC9zcGFu
PkFPTCBMTEM8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFu
PldlZG5lc2RheSwgQXByaWwgMjAsIDIwMTYgYXQgODo0OSBBTTxicj4NCjxzcGFuIHN0eWxlPSJm
b250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPkFuZHJldyBGcmVnbHkgJmx0OzxhIGhyZWY9Im1h
aWx0bzphZnJlZ2x5QHZlcmlzaWduLmNvbSI+YWZyZWdseUB2ZXJpc2lnbi5jb208L2E+Jmd0Oywg
Sm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iPnZlN2p0
YkB2ZTdqdGIuY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9y
ZyI+b2F1dGhAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0
Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln
aHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbT0FVVEgtV0ddIEJ1aWxkaW5nIG9uIHRoZSBw
cm90b2NvbCBpbiB0aGUgZHJhZnQg4oCcT0F1dGggMi4wIFRva2VuIEV4Y2hhbmdlOiBBbiBTVFMg
Zm9yIHRoZSBSRVNUIG9mIFVz4oCdIHRvIGluY2x1ZGUgQXV0aGVudGljYXRpb24gVG9rZW5zPGJy
Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09L
X0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNv
bGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdiBiZ2Nv
bG9yPSIjRkZGRkZGIiB0ZXh0PSIjMDAwMDAwIj48Zm9udCBmYWNlPSJIZWx2ZXRpY2EsQXJpYWws
c2Fucy1zZXJpZiI+SSBzaG91bGQgcHJvYmFibHkganVzdCB3YWl0IGZvciB0aGUgZGlhZ3JhbS4u
LiBidXQgbm90IHdhbnRpbmcgdG8gd2FpdC4uLiA6KTxicj4NCjxicj4NCklmIEkgdW5kZXJzdGFu
ZCBjb3JyZWN0bHksIHRoZSB1c2VyIGlzIGdvaW5nIHRvIHVzZSBhIGNsaWVudCBhbmQgdGhlIGNs
aWVudCB3aWxsIGF1dGhlbnRpY2F0ZSB0aGUgdXNlciB2aWEgc29tZSBJZFAgdXNpbmcgYW4gZXhp
c3RpbmcgbWV0aG9kIChTQU1MLCBMREFQICg/KSwgT3BlbklEIENvbm5lY3QsIGV0YykuIFRoZSBk
ZXNpcmUgaXMgdG8gdGFrZSB0aGF0IHJlc3BvbnNlIGFuZCBpbiBzb21lIHdheSBwcmVzZW50IGl0
IHRvIGFuICZxdW90O0F1dGhvcml6YXRpb24NCiBTZXJ2ZXImcXVvdDsgd2hpY2ggd2lsbCB2YWxp
ZGF0ZSB0aGUgJnF1b3Q7YXV0aGVudGljYXRpb24gcmVzcG9uc2UmcXVvdDsgYW5kIHJldHVybiBh
biBhY2Nlc3MgdG9rZW4gZm9yIHVzZSBhdCB0aGUgZGF0YSBwcm92aWRlcihzKS48YnI+DQo8YnI+
DQpXaGF0IGlmIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBhbHNvIHRvb2sgb24gdGhlIHJvbGUg
b2YgdGhlIE9wZW5JRCBDb25uZWN0IHByb3ZpZGVyLiBUaGlzIGNvdWxkIHdvcmsgYnkgaGF2aW5n
IHRoZSBjbGllbnQgc3RhcnQgYW4gT3BlbklEIENvbm5lY3QgZmxvdyB3aXRoIEF1dGhvcml6YXRp
b24gU2VydmVyIChoaW50cyBjb3VsZCBiZSBwcm92aWRlZCBhcyB0byB3aGljaCBJZFAgdGhlIHVz
ZXIgd2FudHMgdG8gYXV0aGVudGljYXRlIGF0KS4gVGhlDQogQVMgd291bGQgbG9vayBhdCB0aGUg
JnF1b3Q7aWRwIGhpbnQmcXVvdDsgYW5kIGVpdGhlciBzdGFydCBhbmQgU1AgU0FNTCBmbG93LCBv
ciBwcmVzZW50IFVJIGZvciBjb2xsZWN0aW5nIExEQVAgY3JlZGVudGlhbHMgKEkgZG9uJ3QgcmVj
b21tZW5kIHRoaXMpIG9yIGNoYWluIHRvIGFueSBvdGhlciBwcm9wcmlldGFyeSBJZFAgZmxvdy4g
T25jZSB0aGUgdXNlciBzdWNjZXNzZnVsbHkgYXV0aGVudGljYXRlcyB3aXRoIHRoZSBjb3JyZWN0
IElkUCwgdGhlIEFTIHdpbGwNCiBmaW5pc2ggdGhlIE9wZW5JRCBDb25uZWN0IGZsb3cgYWxsb3dp
bmcgdGhlIGNsaWVudCB0byBvYnRhaW4gYW4gYWNjZXNzIHRva2VuLCByZWZyZXNoIHRva2VuIGFu
ZCBpZF90b2tlbi4gVGhlIEFTIGNvdWxkIGFkZCB0byB0aGUgaWRfdG9rZW4gYSBjbGFpbSBzcGVj
aWZ5aW5nIHdoaWNoIElkUCB0aGUgdXNlciB1c2VkIGR1cmluZyB0aGUgYXV0aGVudGljYXRpb24g
cHJvY2Vzc2VkLjxicj4NCjxicj4NClRoZSBJZFAgdGhlIHVzZXIgdXNlZCBmb3IgYXV0aGVudGlj
YXRpb24gY291bGQgYWxzbyBiZSBlbmNvZGVkIGluIHRoZSBhY2Nlc3NfdG9rZW4gKG9yIHJldHVy
bmVkIGFzIHBhcnQgb2YgYW4gaW50cm9zcGVjdGlvbiBjYWxsKS48YnI+DQo8YnI+DQpUaGlzIHdh
eSB3aGV0aGVyIHRoZSBkYXRhIHByb3ZpZGVycyBhcmUgdmFsaWRhdGluZyB0aGUgYWNjZXNzX3Rv
a2VucyBsb2NhbGx5IG9yIHVzaW5nIGludHJvc3BlY3Rpb24gdGhleSBjYW4gb2J0YWluIHRoZSBJ
ZFAgdGhlIHVzZXIgdXNlZCBhbmQgYXBwbHkgdGhlaXIgb3duIGF1dGhvcml6YXRpb24gcnVsZXMu
PGJyPg0KPGJyPg0KVGhlIHVzZXIgaXMgb25seSByZXF1aXJlZCB0byBkbyBvbmUgYXV0aG9yaXph
dGlvbiBmbG93IGZvciB0aGUgY2xpZW50IHRoYXQgaXMgbWFuYWdlZCBieSB0aGUgQXV0aG9yaXph
dGlvbiBTZXJ2ZXIuPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCkdlb3JnZTxicj4NCjwvZm9udD48
YnI+DQo8ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPk9uIDQvMTkvMTYgNTowNiBQTSwgRnJl
Z2x5LCBBbmRyZXcgd3JvdGU6PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjaXRlPSJtaWQ6NjEw
MUQwRUItRTA0Qi00NTc0LTg4OTktRUQ4RjRFNjMxRDY3QHZlcmlzaWduLmNvbSIgdHlwZT0iY2l0
ZSI+DQo8ZGl2Pg0KPGRpdj5UaGFuayB5b3UgZm9yIHlvdXIgcmVzcG9uc2UgR2VvcmdlLiBJdCBw
b2ludHMgbWUgdG8gc29tZSBtb3JlIHJlc2VhcmNoIHRvIGRvLCBzdWNoIGFzIGxvb2tpbmcgYXQg
T3BlbklEIENvbm5lY3Qgc3VwcG9ydCBmb3IgYm90aCBkaXN0cmlidXRlZCBhbmQgYWdncmVnYXRl
ZCBjbGFpbXMuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5CZWxvdyBhcmUgcmVwbGll
cyB0byB5b3VyIHF1ZXN0aW9ucy9hc3NlcnRpb25zIGJhc2VkIG9uIG15IGN1cnJlbnQgdW5kZXJz
dGFuZGluZyBvZiB0aGUgdmFyaW91cyBwcm90b2NvbHMuIEZ1cnRoZXIgcmVzZWFyY2ggYW5kIGFk
dmljZSB3aWxsIGxpa2VseSBlbnJpY2ggdGhpcyBzaWduaWZpY2FudGx5LjwvZGl2Pg0KPGRpdj48
YnI+DQo8L2Rpdj4NCjxkaXY+WWVzLCB3aGF0IGlzIHJlcXVpcmVkIGlzIGEgdmVyaWZpYWJsZSBj
bGFpbSB0aGF0IHRoZSB1c2VyIGlzIHN0aWxsIGEgbWVtYmVyIG9mIFNvbWVPcmcgSW5jLiBJIGhh
dmUgYmVlbiBvcGVyYXRpbmcgdW5kZXIgdGhlIGFzc3VtcHRpb24gdGhhdCB0aGUgb25seSB3YXkg
dGhpcyBjYW4gYmUgZG9uZSB3b3VsZCBiZSB0byBoYXZlIHRoZSB1c2VyIGF1dGhlbnRpY2F0ZWQg
YnkgdGhlIElkZW50aXR5IFByb3ZpZGVyIGZvciBTb21lT3JnLiBQZXJoYXBzDQogdGhlIHJlc2Vh
cmNoIGludG8gT3BlbklEIENvbm5lY3Qgc3VwcG9ydCBmb3IgZGlzdHJpYnV0ZWQgYW5kIGFnZ3Jl
Z2F0ZWQgY2xhaW1zIHdpbGwgcmV2ZWFsIGFuIGFsdGVybmF0aXZlLiBJIGZvcmVzZWUgYSBjaGFs
bGVuZ2UgaW4gZGVhbGluZyB3aXRoIElkZW50aXR5IFByb3ZpZGVy4oCZcyBmb3Igb3JnYW5pemF0
aW9ucyB1c2luZyBTQU1MIGFzc2VydGlvbnMgb24gdG9wIG9mIEFjdGl2ZSBEaXJlY3RvcnkgYW5k
IExEQVAsIGFuZCB3aGljaCBhcmUNCiBub3QgZ29pbmcgdG8gZG8gYW55IHVwZGF0aW5nIHRvIHN1
cHBvcnQgb3VyIG5lZWRzLjwvZGl2Pg0KPGRpdj48L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8
L2Rpdj4NCjxkaXY+V2UgZG8gbm90IGV4cGVjdCB0aGUgdXNlciB0byBmaXJzdCBnbyB0byB0aGUg
ZGF0YSBwcm92aWRlci4gV2UgYW50aWNpcGF0ZSB0aGF0IHRoZSBjbGllbnQgYXBwbGljYXRpb24g
d291bGQgcHJvdmlkZSBhIEF1dGhlbnRpY2F0aW9uIFRva2VuIHRvIGFuICZuYnNwO0F1dGhvcml6
YXRpb24gU2VydmljZSBzZXJ2aWNlIHRoYXQgdGhlbiBpc3N1ZXMgdG8gdGhlIGNsaWVudCBhbiBh
Y2Nlc3MgdG9rZW4gdGhhdCB0aGUgZGF0YSBwcm92aWRlciB3aWxsIHRydXN0Lg0KIE9uZSBvZiBv
dXIgcmVhc29ucyBmb3IgZG9pbmcgaXQgdGhpcyB3YXkgaXMgdGhhdCB3ZSBhcmUgdHJ5aW5nIHRv
IGVsaW1pbmF0ZSByZWRpcmVjdHMgdG8gZWFzZSBpbXBsZW1lbnRhdGlvbiBvZiBhIG5hdGl2ZSBj
bGllbnQuIFdlIGFyZSB0aGVyZWZvcmUgcmVxdWlyaW5nIHRoZSBjbGllbnQgdG8gaGFuZGxlIGF1
dGhlbnRpY2F0aW9uIHdpdGggdGhlIElkZW50aXR5IFByb3ZpZGVyIGFzIGEgc2VwYXJhdGUgc3Rl
cCBmcm9tIGF1dGhvcml6YXRpb24uPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JdCBt
aWdodCBoZWxwIGlmIEkgY2xhcmlmaWVkIHRoYXQgVmVyaXNpZ27igJlzIHJvbGUgaW4gdGhlIHNj
ZW5hcmlvIEkgZGVzY3JpYmVkIGlzIHRvIGJlIGp1c3Qgb25lIG9mIG1hbnkgZGF0YSBwcm92aWRl
cnMuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNU
SU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMnB0Ow0K
ICAgICAgICAgIHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1l
ZGl1bSBub25lOw0KICAgICAgICAgIEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1C
T1RUT006IDBpbjsgUEFERElORy1MRUZUOg0KICAgICAgICAgIDBpbjsgUEFERElORy1SSUdIVDog
MGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsNCiAgICAgICAgICBCT1JERVItUklH
SFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdl
aWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+R2VvcmdlIEZsZXRjaGVyICZsdDs8YSBtb3otZG8tbm90
LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpnZmZsZXRjaEBhb2wuY29tIj5nZmZsZXRjaEBhb2wu
Y29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+T3JnYW5pemF0
aW9uOiA8L3NwYW4+QU9MIExMQzxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5E
YXRlOiA8L3NwYW4+VHVlc2RheSwgQXByaWwgMTksIDIwMTYgYXQgNDoxOCBQTTxicj4NCjxzcGFu
IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPkFuZHJldyBGcmVnbHkgJmx0Ozxh
IG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOmFmcmVnbHlAdmVyaXNpZ24uY29t
Ij48L2E+PGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOmFm
cmVnbHlAdmVyaXNpZ24uY29tIj5hZnJlZ2x5QHZlcmlzaWduLmNvbTwvYT4mZ3Q7LCBKb2huIEJy
YWRsZXkgJmx0OzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOnZlN2p0YkB2
ZTdqdGIuY29tIj52ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7LA0KICZxdW90OzxhIG1vei1kby1u
b3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj48L2E+PGEgY2xhc3M9
Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5v
YXV0aEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJl
Zj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNw
YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW09BVVRILVdH
XSBCdWlsZGluZyBvbiB0aGUgcHJvdG9jb2wgaW4gdGhlIGRyYWZ0IOKAnE9BdXRoIDIuMCBUb2tl
biBFeGNoYW5nZTogQW4gU1RTIGZvciB0aGUgUkVTVCBvZiBVc+KAnSB0byBpbmNsdWRlIEF1dGhl
bnRpY2F0aW9uIFRva2Vuczxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1
b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVS
LUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MA0KICAgICAg
ICAgIDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdiBiZ2NvbG9yPSIjRkZGRkZGIiB0ZXh0PSIjMDAwMDAw
Ij48Zm9udCBmYWNlPSJIZWx2ZXRpY2EsQXJpYWwsc2Fucy1zZXJpZiI+U28gaWYgSSB1bmRlcnN0
YW5kIHRoaXMgY29ycmVjdGx5LCB3aGF0IGlzIHJlYWxseSByZXF1aXJlZCBpcyBhIHZlcmlmaWFi
bGUgY2xhaW0gdGhhdCB0aGUgdXNlciBpcyBzdGlsbCBhIG1lbWJlciBvZiBTb21lT3JnIEluYy4g
T3BlbklEIENvbm5lY3Qgc3VwcG9ydHMgYm90aCBkaXN0cmlidXRlZCBhbmQgYWdncmVnYXRlZA0K
IGNsYWltcyB0aGF0IGNhbiBiZSBzaWduZWQgYnkgdGhlIGFwcHJvcHJpYXRlIElkZW50aXR5IFBy
b3ZpZGVyLiBUaGUgcG9pbnQgYmVpbmcgdGhhdCBJJ20gbm90IHN1cmUgYW4gJnF1b3Q7YXV0aGVu
dGljYXRpb24gdG9rZW4mcXVvdDsgaXMgcmVxdWlyZWQgZm9yIHRoaXMgdXNlIGNhc2UgdG8gc3Vj
Y2VlZCwgaXQncyBqdXN0IG9uZSBraW5kIG9mIHRva2VuIHRoYXQgY2FuIGJlIHVzZWQuPGJyPg0K
PGJyPg0KQWxzbywgaXMgdGhlIGV4cGVjdGVkIGZsb3cgdGhhdCB0aGUgdXNlciB3aWxsIGZpcnN0
IGdvIHRvIHRoZSBkYXRhIHByb3ZpZGVyIGFuZCB0aGVuIGJlIGRpcmVjdGVkIGVsc2Ugd2hlcmUg
ZnJvbSB0aGVyZT8gSWYgdGhhdCBpcyB0aGUgY2FzZSwgdGhlIGRhdGEgcHJvdmlkZXIgY2FuIGp1
c3QgYmUgYW4gT3BlbklEIENvbm5lY3QgcmVseWluZyBwYXJ0eSBhbmQgZ2l2ZSB0aGUgdXNlciBh
biBvcHRpb24gb2YgdGhlIGxpc3Qgb2Ygc3VwcG9ydGVkIElkUHMNCiB0byBjaG9vc2UgZnJvbS4g
VGhlIHVzZXIgd2lsbCB0aGVuIGJlIHJlZGlyZWN0ZWQgdG8gU29tZU9yZyBJbmMuIElkUCwgYXV0
aGVudGljYXRlIGFuZCB0aGUgZGF0YSBwcm92aWRlciB3aWxsIGhhdmUgdGhlIGF1dGhvcml6YXRp
b24gYW5kIHJlY2VudCBhdXRoZW50aWNhdGlvbiB0aGV5IGNhbiB2YWxpZGF0ZS48YnI+DQo8YnI+
DQpJcyB0aGUgdXNlci9kYXRhIGZsb3cgbW9yZSBjb21wbGljYXRlZCB0aGFuIHRoaXM/PGJyPg0K
PGJyPg0KVGhhbmtzLDxicj4NCkdlb3JnZTxicj4NCjwvZm9udD48YnI+DQo8ZGl2IGNsYXNzPSJt
b3otY2l0ZS1wcmVmaXgiPk9uIDQvMTkvMTYgNDowNSBQTSwgRnJlZ2x5LCBBbmRyZXcgd3JvdGU6
PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjaXRlPSJtaWQ6OEI3NDgyNTItOUFFMi00ODI0LTky
M0ItMDBDRDQ2Q0I4RDY4QHZlcmlzaWduLmNvbSIgdHlwZT0iY2l0ZSI+DQo8ZGl2Pg0KPGRpdj5U
aGFua3MgZm9yIHlvdXIgcmVzcG9uc2UgSm9obi4gSSBhbHNvIGdvdCBhIGdvb2QgcmVzcG9uc2Ug
ZnJvbSBCcmlhbiBDYW1wYmVsbCBhbmQgYXBwcmVjaWF0ZSB0aGF0LiBJIHdpbGwgcmVzcG9uZCBz
ZXBhcmF0ZWx5IHRvIEJyaWFu4oCZcyByZXNwb25zZSBhcyBJIHRoaW5rIGl0IHdvdWxkIGtlZXAg
dGhpbmdzIGNsZWFyZXIgdG8gZG8gdGhhdC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2
PlRoZSBwcm9ibGVtIHdlIGhhdmUgZm9yIHVzaW5nIE9wZW5JRCBDb25uZWN0IGlzIHRoYXQgaXQg
Y29tYmluZXMgdGhlIHJvbGUgb2YgQXV0aGVudGljYXRpb24gU2VydmljZSB3aXRoIHRoZSByb2xl
IG9mIEF1dGhvcml6YXRpb24gU2VydmljZS4gUGVyaGFwcyB0aGUgZm9sbG93aW5nIGRlc2NyaXB0
aW9uIG9mIHdoYXQgd2Ugd2FudCB0byBkbyB3aWxsIGNsYXJpZnkgd2h5IHRoaXMgd29u4oCZdCB3
b3JrIGZvciB1czo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSBiYXNpYyBwcm9i
bGVtIHN0YXRlbWVudCBpcyB0aGF0IHdlIG5lZWQgdG8gaGF2ZSBhIGNsaWVudCBhcHBsaWNhdGlv
biBhdXRob3JpemVkIGJ5IGEgU2VydmljZSBQcm92aWRlciBiYXNlZCBvbiBwcm9vZiB0aGF0IGEg
dXNlciBpcyBjdXJyZW50bHkgYSBtZW1iZXIgb2Ygc29tZSBvcmdhbml6YXRpb24uIFRoaXMgYXNz
dW1lcyB0aGUgb3JnYW5pemF0aW9uIGhhcyBwcmV2aW91c2x5IGVzdGFibGlzaGVkIHNvbWUgbGV2
ZWwgb2YgYXV0aG9yaXplZA0KIGFjY2VzcyB3aXRoIHRoZSBTZXJ2aWNlIFByb3ZpZGVyLiZuYnNw
OzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SGVyZSBpcyBhbiBleGFtcGxlOiBTdXBw
b3NlIEkgYW0gYSBtZW1iZXIgb2YgU29tZU9yZyBJbmMuIFN1cHBvc2UgU29tZU9yZyBJbmMuIGlz
IGRvaW5nIHJlc2VhcmNoIHRoYXQgcmVxdWlyZXMgaXQgdG8gZ2F0aGVyIGRhdGEgb3ZlciB0aGUg
SW50ZXJuZXQgZnJvbSBhIG51bWJlciBvZiBkYXRhIHByb3ZpZGVycy4gVGhlIGRhdGEgcHJvdmlk
ZXJzIHJlcXVpcmUgYXV0aGVudGljYXRpb24gYW5kIHByb29mIG9mIG9yZ2FuaXphdGlvbmFsIG1l
bWJlcnNoaXANCiBpbiBvcmRlciB0byBhdXRob3JpemUgdmFyaW91cyBsZXZlbHMgb2YgYWNjZXNz
IHRvIHRoZWlyIGRhdGEuIFRoZSBkYXRhIHByb3ZpZGVycyBkbyBub3QgY29uc2lkZXIgaGF2aW5n
IGFuIGFjY291bnQgd2l0aCB0aGVtIG9yIGEgUHVibGljIElkZW50aXR5IFByb3ZpZGVyIHRvIGJl
IHN1aXRhYmxlIGZvciBwcm92aW5nIHRoYXQgSSBhbSBzdGlsbCBhIG1lbWJlciBvZiBTb21lT3Jn
IGF0IHRpbWUgb2YgYXV0aGVudGljYXRpb24uIFRoZXkgd291bGQNCiBoYXZlIG5vIHdheSBvZiBr
bm93aW5nIHdoZXRoZXIgb3Igbm90IG15IHJlbGF0aW9uc2hpcCB3aXRoIFNvbWVPcmcgc3RpbGwg
ZXhpc3RzIGF0IHRoYXQgdGltZS4gVGhlIGRhdGEgcHJvdmlkZXJzIHdvdWxkIHRoZXJlZm9yZSBs
aWtlIHRoZSBDbGllbnQgc29mdHdhcmUgdG8gYXV0aGVudGljYXRlIG1lIGFnYWluc3QgU29tZU9y
Z3MgSWRlbnRpdHkgUHJvdmlkZXIuIFRoaXMgd291bGQgYmUgZ29vZCBwcm9vZiB0aGF0IEkgYW0g
c3RpbGwgYSBtZW1iZXINCiBvZiBTb21lT3JnIGF0IHRoZSB0aW1lIEkgYXV0aGVudGljYXRlLiBU
aGlzIGF1dGhlbnRpY2F0aW9uIHdvdWxkIGVuYWJsZSB0aGUgZGF0YSBwcm92aWRlcnMgQXV0aG9y
aXphdGlvbiBTZXJ2ZXIgdG8gZ3JhbnQgbWUgYWNjZXNzIGFwcHJvcHJpYXRlIHRvIGEgbWVtYmVy
IG9mIFNvbWVPcmcuICZuYnNwO05vdGUgdGhhdCBhcyBhIHByZXJlcXVpc2l0ZSB0byBhbGwgb2Yg
dGhpcywgU29tZU9yZyB3aWxsIGhhdmUgdXNlZCBhbiBvdXQtb2YtYmFuZCBwcm9jZXNzDQogdG8g
c2V0IHVwIGEgdHJ1c3QgcmVsYXRpb25zaGlwIGZvciBTb21lT3JnJ3MgSWRlbnRpdHkgUHJvdmlk
ZXIgd2l0aCB0aGUgZGF0YSBwcm92aWRlcuKAmXMgQXV0aG9yaXphdGlvbiBTZXJ2aWNlLCBhbmQg
d2lsbCBoYXZlIG5lZ290aWF0ZWQgYXV0aG9yaXphdGlvbiBjbGFpbXMgdG8gYmUgZ3JhbnRlZCB0
byBTb21lT3JncyBtZW1iZXJzLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V2hhdCBJ
IGFtIGhhdmluZyBkaWZmaWN1bHR5IHdpdGggaXMgaW4ga25pdHRpbmcgdG9nZXRoZXIgYW4gYXBw
cm9hY2ggYmFzZWQgb24gdGhlIGhlIE9wZW5JRCBDb25uZWN0IHNwZWNpZmljYXRpb25zLCBTQU1M
IHNwZWNpZmljYXRpb25zLCBhbmQgT0F1dGggUkZDcyBhbmQgZHJhZnRzIGluIGEgd2F5IHRoYXQg
c3VwcG9ydHMgdGhlIGFib3ZlIHVzZSBjYXNlIGVuZC10by1lbmQuIFRoZSBPQXV0aCBSRkNzIGFu
ZCBkcmFmdHMgYWxtb3N0IGdldA0KIG1lIHRoZXJlLiBXaGF0IHNlZW1zIHRvIGJlIG1pc3Npbmcg
aXMgYSB3YXkgb2YgdGVsbGluZyBhbiBJZGVudGl0eSBQcm92aWRlciB0aGUgVVJMIGZvciB0aGUg
QXV0aG9yaXphdGlvbiBTZXJ2aWNlICh0aGUgcmVxdWlyZWQgQXVkaWVuY2UgY2xhaW0gaW4gYW4g
YXV0aGVudGljYXRpb24gYXNzZXJ0aW9uIGFzIGRlZmluZWQgaW4gUkZDcyA3MjUxLCA3MjUyIGFu
ZCA3MjUzKSwgYW5kIHRoZW4gYSByZXF1aXJlbWVudCB0aGF0IHRoZSBJZGVudGl0eQ0KIFByb3Zp
ZGVycyBwdXQgdGhlIHN1cHBsaWVkIEF1ZGllbmNlIElkZW50aWZpZXIgaW50byBBdXRoZW50aWNh
dGlvbiBUb2tlbnMuIFBlcmhhcHMgYSBsaXR0bGUgZnVydGhlciBiYWNrLWFuZC1mb3J0aCB3aXRo
IEJyaWFuIHdpbGwgcmVzb2x2ZSB0aGlzLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+
SSBjYW4gZ28gaW50byBkZWVwZXIgZGV0YWlsIGlmIG5lZWRlZC4gSWYgdGhpcyBpcyBvZmYtdG9w
aWMgZm9yIHRoZSBPQXV0aCB3b3JraW5nIGdyb3VwLCBsZXQgbWUga25vdy48L2Rpdj4NCjxkaXY+
PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+QW5kcmV3IEZyZWdseTwvZGl2
Pg0KPGRpdj5WZXJpc2lnbiBJbmMuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYg
c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMnB0Ow0KICAgICAgICAgICAg
ICAgICAgICB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRp
dW0NCiAgICAgICAgICAgICAgICAgICAgbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQ
QURESU5HLUJPVFRPTTogMGluOw0KICAgICAgICAgICAgICAgICAgICBQQURESU5HLUxFRlQ6IDBp
bjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOg0KICAgICAgICAgICAgICAgICAgICAj
YjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsNCiAgICAgICAgICAg
ICAgICAgICAgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s
ZCI+RnJvbTogPC9zcGFuPkpvaG4gQnJhZGxleSAmbHQ7PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVl
IiBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86dmU3anRiQHZl
N2p0Yi5jb20iPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9u
dC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPlR1ZXNkYXksIEFwcmlsIDE5LCAyMDE2IGF0IDI6
MDYgUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5BbmRy
ZXcgRnJlZ2x5ICZsdDs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGNsYXNzPSJtb3otdHh0LWxp
bmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzphZnJlZ2x5QHZlcmlzaWduLmNvbSI+YWZyZWds
eUB2ZXJpc2lnbi5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk
Ij5DYzogPC9zcGFuPiZxdW90OzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgY2xhc3M9Im1vei10
eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj48L2E+PGEg
Y2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYu
b3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1
ZSIgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJy
Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW09B
VVRILVdHXSBCdWlsZGluZyBvbiB0aGUgcHJvdG9jb2wgaW4gdGhlIGRyYWZ0IOKAnE9BdXRoIDIu
MCBUb2tlbiBFeGNoYW5nZTogQW4gU1RTIGZvciB0aGUgUkVTVCBvZiBVc+KAnSB0byBpbmNsdWRl
IEF1dGhlbnRpY2F0aW9uIFRva2Vuczxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxi
bG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0i
Qk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMA0KICAgICAgICAgICAg
ICAgICAgICA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3Jh
cDogYnJlYWstd29yZDsNCiAgICAgICAgICAgICAgICAgICAgICAgIC13ZWJraXQtbmJzcC1tb2Rl
OiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOg0KICAgICAgICAgICAgICAgICAgICAgICAgYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkxvb2tpbmcgYXQgT3BlbklEIENvbm5lY3QgYW5k
IGl04oCZcyB0cnVzdCBtb2RlbCBmb3IgcHJvZHVjaW5nIGlkX3Rva2VucyB0aGF0IGFzc2VydCBp
ZGVudGl0eSBtYXkgaGVscCB5b3UuDQo8ZGl2IGNsYXNzPSIiPjxhIG1vei1kby1ub3Qtc2VuZD0i
dHJ1ZSIgaHJlZj0iaHR0cDovL29wZW5pZC5uZXQvd2cvY29ubmVjdC8iIGNsYXNzPSIiPmh0dHA6
Ly9vcGVuaWQubmV0L3dnL2Nvbm5lY3QvPC9hPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+
PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlVuZm9ydHVuYXRlbHkgSSBjYW7i
gJl0IHF1aXRlIG1ha2Ugb3V0IHdoYXQgeW91IGFyZSB0cnlpbmcgdG8gZG8uJm5ic3A7PC9kaXY+
DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JdCBz
b3J0IG9mIHNvdW5kcyBsaWtlIHlvdSB3YW50IGFuIGlkX3Rva2VuIGZyb20gYSBpZFAgYW5kIHRo
ZW4gaGF2ZSB0aGUgY2xpZW50IGV4Y2hhbmdlIHRoYXQgYXNzZXJ0aW9uIGZvciBhbm90aGVyIHRv
a2VuPzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh
c3M9IiI+Sm9obiBCLjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl
IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gQXByIDE5LCAyMDE2LCBhdCAxOjE4IFBNLCBG
cmVnbHksIEFuZHJldyAmbHQ7PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86
YWZyZWdseUB2ZXJpc2lnbi5jb20iIGNsYXNzPSIiPjwvYT48YSBjbGFzcz0ibW96LXR4dC1saW5r
LWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86YWZyZWdseUB2ZXJpc2lnbi5jb20iPmFmcmVnbHlA
dmVyaXNpZ24uY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVy
Y2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5
OiBDYWxpYnJpLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2Fucy1zZXJp
ZjsgZm9udC1zaXplOiAxNHB4Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Zm9udC1zdHlsZTogbm9ybWFsOw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWdu
Og0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RhcnQ7IHRleHQtaW5kZW50
OiAwcHg7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0ZXh0LXRyYW5zZm9y
bTogbm9uZTsgd2hpdGUtc3BhY2U6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMHB4OyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl
PSJtYXJnaW46IDBpbiAwaW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgZm9udC1mYW1pbHk6IENhbGlicmk7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJm
b250LXNpemU6IDEycHQ7IiBjbGFzcz0iIj5JIGhhdmUgYSB1c2UgY2FzZSB3aGVyZSBhIGNsaWVu
dCBhcHBsaWNhdGlvbiBuZWVkcyB0byBhdXRoZW50aWNhdGUgd2l0aCBhIGR5bmFtaWNhbGx5IGRl
dGVybWluZWQgSWRlbnRpdHkgUHJvdmlkZXIgdGhhdCBpcyBzZXBhcmF0ZSBmcm9tIHRoZSBBdXRo
b3JpemF0aW9uIFNlcnZpY2UgdGhhdCB3aWxsIGJlIHVzZWQgaXNzdWUgYW4gYWNjZXNzIHRva2Vu
IHRvIHRoZSBjbGllbnQuDQogVGhlIHVzZSBjYXNlIGFsc28gcmVxdWlyZXMgdGhhdCBhcyBwYXJ0
IG9mIGF1dGhvcml6YXRpb24sIHRoZSBjbGllbnQgcHJvdmlkZXMgdG8gdGhlIEF1dGhvcml6YXRp
b24gU2VydmljZSBhbiBhdXRoZW50aWNhdGlvbiB0b2tlbiBzaWduZWQgYnkgYW4gSWRlbnRpdHkg
UHJvdmlkZXIgdGhhdCB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2aWNlIGhhcyBhIHRydXN0IHJlbGF0
aW9uc2hpcCB3aXRoLiBUaGUgdHJ1c3QgcmVsYXRpb25zaGlwIGlzIHZlcmlmaWFibGUNCiBiYXNl
ZCBvbiB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2aWNlIGhhdmluZyByZWNvcmRlZCB0aGUgcHVibGlj
IGtleXMgb3IgY2VydGlmaWNhdGVzIG9mIHRydXN0ZWQgSWRlbnRpdHkgUHJvdmlkZXJzIGluIGEg
dHJ1c3Qgc3RvcmUsIHRoaXMgYWxsb3dpbmcgdGhlIEF1dGhvcml6YXRpb24gU2VydmljZSB0byB2
ZXJpZnkgYW4gSWRlbnRpdHkgUHJvdmlkZXLigJlzIHNpZ25hdHVyZSBvbiBhbiBhdXRoZW50aWNh
dGlvbiB0b2tlbi48L3NwYW4+PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBuYW1lPSJPTEVfTElO
SzUiIGNsYXNzPSIiPjwvYT48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwLjAwMDFwdDsgZm9udC1zaXplOiAx
MnB0Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmb250LWZhbWlseTog
Q2FsaWJyaTsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5
bGU9Im1hcmdpbjogMGluIDBpbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBmb250LWZhbWlseTogQ2FsaWJyaTsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0i
Ij4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0
Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmb250LWZhbWlseTogQ2Fs
aWJyaTsiIGNsYXNzPSIiPg0KSW4gbG9va2luZyBhdCB0aGUgdmFyaW91cyBPQXV0aCBSRkNzLCBw
YXJ0aWN1bGFybHkgUkZDcyA3NTIxLCA3NTIyLCBhbmQgNzUyMywgSSBzZWUgdGhhdCB0aGV5IGdl
dCBtZSBjbG9zZSBpbiB0ZXJtcyBvZiBzdXBwb3J0aW5nIHRoZSB1c2UgY2FzZS4gV2hhdCBpcyBt
aXNzaW5nIGlzIGEgbWVhbnMgZm9yIHNvbHZpbmcgdGhlIGZvbGxvd2luZyBwcm9ibGVtLiBUaGVz
ZSBSRkNzIHJlcXVpcmUgdGhhdCB0aGUgSWRlbnRpdHkgUHJvdmlkZXIgcHV0IGFuDQogQXVkaWVu
Y2UgY2xhaW0gaW4gdGhlIGF1dGhlbnRpY2F0aW9uIHRva2VuLiBUaGUgcHJvYmxlbSB3aXRoIHRo
aXMgaXMgdGhhdCBJIGRvIG5vdCBzZWUgaW4gdGhlIFJGQ3MgaG93IHRoZSBJZGVudGl0eSBQcm92
aWRlciBjYW4gYmUgdG9sZCB3aG8gdGhlIEF1ZGllbmNlIGlzIHRvIHB1dCBpbnRvIHRoZSBhdXRo
ZW50aWNhdGlvbiB0b2tlbi4gVGhpcyBsZWFkcyBtZSB0byB0aGUgdGl0bGUgb2YgdGhpcyBtZXNz
YWdlLiBUaGUgZHJhZnQg4oCcT0F1dGgNCiAyLjAgVG9rZW4gRXhjaGFuZ2U6IEFuIFNUUyBmb3Ig
dGhlIFJFU1Qgb2YgVXPigJ0gZGVmaW5lcyBhIG1lY2hhbmlzbSBmb3IgaWRlbnRpZnlpbmcgdGhl
IEF1ZGllbmNlIGZvciBhbiBTVFMgdG8gcHV0IGludG8gYSB0b2tlbiBpdCBnZW5lcmF0ZXMuIFRo
YXQgd291bGQgc29sdmUgbXkgcHJvYmxlbSBleGNlcHQgdGhhdCB0aGUgZHJhZnQgbGltaXRzIHRo
ZSB0eXBlIG9mIFNUUyB0byBiZWluZyBBdXRob3JpemF0aW9uIFNlcnZlcnMuIFdoYXQgaXMgbmVl
ZGVkDQogaXMgdGhpcyBzYW1lIGNhcGFiaWxpdHkgZm9yIGludGVyYWN0aW5nIHdpdGggYW4gSWRl
bnRpdHkgUHJvdmlkZXIuIFRoaXMgd291bGQgZW5hYmxlIFJGQ3MgNzUyMSwgNzUyMiBhbmQgNzUy
MyB0byBiZSB1c2VmdWwgaW4gc2l0dWF0aW9uIHdoZXJlIHRoZSBJZGVudGl0eSBQcm92aWRlciBu
ZWVkcyB0byBiZSB0b2xkIHRoZSBpZGVudGl0eSBvZiB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2aWNl
LjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMC4wMDAxcHQ7IGZvbnQtc2l6
ZTogMTJwdDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZm9udC1mYW1p
bHk6IENhbGlicmk7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+
DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgZm9udC1mYW1pbHk6IENhbGlicmk7IiBjbGFzcz0iIj4NCkkg
YW0gbmV3IHRvIGludGVyYWN0aW5nIHdpdGggdGhlIElFVEYuIEkgYWxzbyBhbSBub3QgYW4gZXhw
ZXJ0IG9uIHRoZSBSRkNzIG9yIHByaW9yIGhpc3Rvcnkgb2YgdGhlIE9BdXRoIGdyb3VwIHJlbGF0
aXZlIHRvIHRoaXMgdG9waWMsIHNvIHBsZWFzZSBwb2ludCBtZSB0byBhbnkgZXhpc3Rpbmcgc29s
dXRpb24gaWYgdGhpcyBpcyBhIHNvbHZlZCBwcm9ibGVtLiBPdGhlcndpc2UsIEkgd291bGQgbGlr
ZSB0byBnZXQgZmVlZGJhY2sgb24gbXkgc3VnZ2VzdGlvbi48bzpwIGNsYXNzPSIiPjwvbzpwPjwv
ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIGZvbnQtZmFtaWx5OiBDYWxpYnJpOyIgY2xhc3M9IiI+
DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw
aW4gMGluDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDAuMDAwMXB0OyBm
b250LXNpemU6IDEycHQ7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZv
bnQtZmFtaWx5OiBDYWxpYnJpOyIgY2xhc3M9IiI+DQpUaGFua3MgWW91LDwvZGl2Pg0KPGRpdiBz
dHlsZT0ibWFyZ2luOiAwaW4gMGluDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGZvbnQtZmFtaWx5OiBDYWxpYnJpOyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9
IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0Ow0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmb250LWZhbWlseTogQ2FsaWJyaTsiIGNs
YXNzPSIiPg0KQW5kcmV3IEZyZWdseTxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0
eWxlPSJtYXJnaW46IDBpbiAwaW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgZm9udC1mYW1pbHk6IENhbGlicmk7IiBjbGFzcz0iIj4NClZlcmlzaWduIElu
Yy48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0
cHg7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmb250LXN0eWxlOiBub3Jt
YWw7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmb250LXZhcmlhbnQtY2Fw
czogbm9ybWFsOw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZm9udC13ZWln
aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z
cGFjZToNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5vcm1hbDsgd2lkb3dz
OiBhdXRvOyB3b3JkLXNwYWNpbmc6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAwcHg7IiBjbGFzcz0iIj4NCjwvZGl2Pg0KPHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6
IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3Jw
aGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh
bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3Bh
Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBk
aXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6
IENhbGlicmksDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzYW5zLXNlcmlm
OyBmb250LXNpemU6IDE0cHg7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBm
b250LXN0eWxlOiBub3JtYWw7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBm
b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdGFydDsgdGV4dC1pbmRlbnQ6
IDBweDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRleHQtdHJhbnNmb3Jt
OiBub25lOyB3aGl0ZS1zcGFjZToNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBmb250
LXN0eWxlOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt
YWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0
ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3
b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDog
bm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5PQXV0aA0KIG1haWxp
bmcgbGlzdDwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOw0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZm9udC12YXJpYW50LWNhcHM6IG5v
cm1hbDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZvbnQtd2VpZ2h0OiBu
b3JtYWw7IGxldHRlci1zcGFjaW5nOg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBub3JtYWw7IHdpZG93czogYXV0
bzsgd29yZC1zcGFjaW5nOg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMHB4
OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgMHB4OyIgY2xhc3M9IiI+DQo8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9
Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLA0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAx
NHB4Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZm9udC1zdHlsZTogbm9y
bWFsOw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZm9udC12YXJpYW50LWNh
cHM6IG5vcm1hbDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZvbnQtd2Vp
Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt
c3BhY2U6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBub3JtYWw7IHdpZG93
czogYXV0bzsgd29yZC1zcGFjaW5nOg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgMHB4OyIgY2xhc3M9IiI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyIHN0eWxl
PSJmb250LWZhbWlseTogQ2FsaWJyaSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGZvbnQtc3R5bGU6IG5vcm1hbDsNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzoN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5vcm1hbDsgb3JwaGFuczogYXV0
bzsgdGV4dC1hbGlnbjoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0YXJ0
OyB0ZXh0LWluZGVudDogMHB4Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzoNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13
aWR0aDoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDBweDsiIGNsYXNzPSIi
Pg0KPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL29hdXRoIiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0
cHg7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmb250LXN0eWxlOiBub3Jt
YWw7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmb250LXZhcmlhbnQtY2Fw
czogbm9ybWFsOw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZm9udC13ZWln
aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z
cGFjZToNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5vcm1hbDsgd2lkb3dz
OiBhdXRvOyB3b3JkLXNwYWNpbmc6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAwcHg7IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL29hdXRoPC9hPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xh
c3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv
c3Bhbj48YnI+DQo8ZmllbGRzZXQgY2xhc3M9Im1pbWVBdHRhY2htZW50SGVhZGVyIj48L2ZpZWxk
c2V0PiA8YnI+DQo8cHJlIHdyYXA9IiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KPGEgbW96LWRvLW5vdC1zZW5kPSJ0
cnVlIiBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86T0F1dGhA
aWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgY2xh
c3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9vYXV0aDwvYT48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Jsb2NrcXVvdGU+DQo8L3NwYW4+PC9ibG9ja3F1b3RlPg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_C8795E07F9D84CDEA1871EA7D9604E1Fverisigncom_--


From nobody Wed Apr 20 07:37:18 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC6012EF5A for ; Wed, 20 Apr 2016 07:37:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LK9gZj79DAGi for ; Wed, 20 Apr 2016 07:37:13 -0700 (PDT)
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 5ACE112EF6E for ; Wed, 20 Apr 2016 07:37:13 -0700 (PDT)
Received: by mail-qg0-x236.google.com with SMTP id c6so29511114qga.1 for ; Wed, 20 Apr 2016 07:37:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=hB0hhlVg/eqyBjB8UGKtqYpsYeIEySXs6QW7puYDQTc=; b=WoEOZ5Yhq4CYb/cDwikf7i0VIQ302HpkEqrNBH++E4m/U5kNJwXDr57U5+qfdFXuIR sF1w/lSew9P1pJ5BaoIDh2hv6+2ZCMb5RDcMG8cbY5jPoshTQFTvZ1SP9Vb7XfYXn43d H8k0AqiClhJ4fw0MlGggC/sZ2ukyJCadps7EeB1Kjp+VNTweMkGDI+M/FRgnLwDPzPZK i0AWczJjT1D9iUcLyNz7fkD9Mjz2xNENtr4sZLlESU2zw0CMxXQJctyM1tUOkV8/hYBp JK/5qdnbLk1wTKkga0b5pLPwvdO7TNbBuTwJSWU4hciSFYxDHiXFaNox0f4CXc62EUnj cB8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=hB0hhlVg/eqyBjB8UGKtqYpsYeIEySXs6QW7puYDQTc=; b=FphSbBO4OOg5FMkVLSxaCUUK/VyjEC9nE32Lh5C9CP0NYYvqD63I65XxjFoBwWpsNC LW6hTG+9sUiFAM/BN9qDpGU9sF9EJ5OBl5fgNKTWXy+ybxdl9t6oGcA8foXfD6Mst0a6 8dBb1TKCOisdenCY5i+mOQDO1wDEk1ceFLObIXXbvtxJi+zcb0aV8Am6+NFxLZLxcL1r x/RwYNPgwasXTFUW8yCo2UibejN9cJbY6I1pgGekFILdY9kPzQZgJe5W6NQ+eyMdhzhP HP6BDny9rpuQBQIt/M5bZ0e8MHa1Q4SHmXP8B8pP5vbPmrOcMLPXkj0/7P2DFXZzBDuw 1aPw==
X-Gm-Message-State: AOPr4FXaCrWbcbcKTxUTYusZNxeiRtkpqKXgn4p0rOFFtUJy74b2PNn6y1QtgNxTUalVoA==
X-Received: by 10.140.96.100 with SMTP id j91mr4727774qge.10.1461163032282; Wed, 20 Apr 2016 07:37:12 -0700 (PDT)
Received: from [192.168.8.100] ([181.202.34.28]) by smtp.gmail.com with ESMTPSA id m12sm12863698qke.30.2016.04.20.07.37.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Apr 2016 07:37:10 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_32819EE7-D6EB-4928-A0EE-65507C9B7D17"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: John Bradley 
In-Reply-To: 
Date: Wed, 20 Apr 2016 11:37:07 -0300
Message-Id: <05739E84-9CCA-44AC-A541-532B7E749047@ve7jtb.com>
References:   <8B748252-9AE2-4824-923B-00CD46CB8D68@verisign.com>  <5958E90F-EF8C-4641-96C1-A9077B450D53@verisign.com>  
To: "Fregly, Andrew" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Building on the protocol in the draft "OAuth 2.0 Token Exchange: An STS for the REST of Us" to include Authentication Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Apr 2016 14:37:17 -0000

--Apple-Mail=_32819EE7-D6EB-4928-A0EE-65507C9B7D17
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

For people using RFC 7521, 7522, 7523 they are taking an assertion and =
using a WS-* STS to transform it into one with the correct audience to =
use  in 7521.

I know that some people have just ignored the audience,  however that =
can have negative security consequences.  When exchanging the token you =
want to be certain that it is the entity that the token was issued to =
that is exchanging it.

The STS for the rest of us is a more general framework that should allow =
you to take a id_token or SAML assertion and securely exchange it for =
another assertion or access token.

I don=E2=80=99t understand the use case enough to say if that is the =
best thing for you, but yes that is the intent of that spec.

John B.

> On Apr 20, 2016, at 10:58 AM, Fregly, Andrew  =
wrote:
>=20
> Thank you again of your input Nat.=20
>=20
> First of all, I apologize for confusing the situation by referencing =
the wrong RFCs in a prior email. I transposed two digits. The RFCs I =
meant to reference where 7521-7523 (see below).
>=20
> I get that the original RFC for OAuth has the mechanism for client =
authentication being out of scope.  What is muddying the water for me is =
that RFCs 7521, 7522, and 7523 seem to specify the means by which a =
client can provide an authentication token to an Authorization Service. =
This purpose is stated at the top of the abstract for RFC 7521:
>=20
> "The intent of this specification is to provide a common framework for =
OAuth 2.0 to interwork with other identity systems using assertions and =
to provide alternative client authentication mechanisms.=E2=80=9D
>=20
> In our use case, we need to have users authenticated against identity =
providers that organizations use internally as the means for =
authenticating clients accessing our service. We need this because we =
believe this is the best means for proving a user is still a member of =
an organization at the time they authenticate. Most, perhaps all of =
these organizations, will internally use an Identity Provider that =
provides SAML authentication assertions. This led me to looking for a =
way to use authentication tokens produced by internal Identity Providers =
as a means for proving a client had been authenticated by the =
organization. A bit of investigation in how this might be done led me to =
OAuth RFCs 7521, 7522 and 7523. They  almost get me there. They specify =
what needs to be in an Authentication token that is given by a client to =
an Authorization Service. The gotcha was that these RFCs require an =
audience claim in the authentication token. This audience claim is used =
to identify the specific Authorization Service the token is meant for. =
For this audience claim to get filled in by some arbitrary =
organization=E2=80=99s Identity Provider, it seems the Identity Provider =
will need to be told who the Authorization Service is by the client =
initiating the authentication. I have therefore been looking for a =
standard that specifies how a client can tell the Identity Provider the =
identity of the Authorization Service. I was stuck for a bit on how the =
IETF OAuth working group could address this issue since authentication =
seemed to be out of scope for the group. Then I found the  IETF draft =
"OAuth 2.0 Token Exchange: An STS for the REST of Us=E2=80=9D. It =
defines a mechanism for telling a Security Token Service the audience =
for the token it is being asked to issue. I thought that would solve my =
problem since an intent of the draft seemed to be on generalizing the =
described approach to any type of Security Token Service. There was one =
gotcha in the draft though. It limited the type of STS to which the =
protocol applied to be just Authorization Services. For my use case, I =
needed the capability described in the draft, but applicable to Identity =
Providers too. If it were applicable to Identity Providers, there would =
then be a full set of existing RFCs and drafts that covered the =
functionality needed for our use case.=20
>=20
> There are a couple of possible actions that I have been contemplating =
relative to OAuth:
> Write extensions to RFCs 7521, 7522 and 7523 that eliminate the need =
for an audience claim in the authentication token if the Authorization =
Service has a trust relationship with the Identity Provider that issued =
the authentication token.
> Ask the authors of the =E2=80=9COAuth 2.0 Token Exchange: An STS for =
the REST of Us=E2=80=9D to explicitly state that the the approach =
described there-in is applicable to both Identity Providers and =
Authorization services.
> Before doing either of these steps, I want to make sure that I am not =
missing something in existing RFCs and drafts that would address our use =
case. I have only been looking at this issue for a few weeks, so I =
thought it would be best to go to the experts to get advice. This led to =
this email chain.=20
>=20
> Thanks to all following this chain for your time and consideration on =
this!
>=20
> Andy
>=20
> From: Nat Sakimura >
> Date: Tuesday, April 19, 2016 at 5:35 PM
> To: Andrew Fregly >, John Bradley >, "oauth@ietf.org " =
>
> Subject: Re: [OAUTH-WG] Building on the protocol in the draft "OAuth =
2.0 Token Exchange: An STS for the REST of Us" to include Authentication =
Tokens
>=20
>> Hi Andrew,=20
>>=20
>> In OAuth 2.0, the resource owner authentication /end user =
authentication is out of scope. What it deals with is "client =
authentication". They should not be mixed up. There is no end user =
identity nor authentication token in the OAuth. You cannot do end user =
authentication with pure OAuth. For that, you have to rely on something =
like OpenID Connect.=20
>>=20
>> As John noted, it is perfectly fine to chain the external =
authentication and the internal authorization. It is often done. It is =
just that the RFC6749 Authz server is an RP of OpenID Connect or SP of =
SAML. Nothing precludes it.=20
>>=20
>> If you really want to avoid the front channel re-auth with =
prompt=3Dnone, which is more secure and proper ways to do, but just to =
make sure that the user still exists in the authentication service, you =
can infer it by making a userinfo request to the userinfo endpoint of =
OpenID Connect. It would fail in various reasons, but would certainly =
fail if the user does not exist anymore. Other error conditions like the =
user revoked the access/refresh token etc. would cause the same =
invalid_token error though.=20
>>=20
>> Best,=20
>>=20
>> Nat
>>=20
>> P.S. I do not see why the RFCs you sited are relevant here. I guess =
you are talking about RFC7521-7523 ;-)
>>=20
>> RFC7251 AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for =
TLS
>> RFC7252 The Constrained Application Protocol (CoAP)
>> RFC7253 The OCB Authenticated-Encryption Algorithm
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> 2016=E5=B9=B44=E6=9C=8820=E6=97=A5(=E6=B0=B4) 5:34 Fregly, Andrew =
>:
>>> Thanks for your reply Nat.
>>>=20
>>> Does your approach match with an IETF OAuth RFC or Draft describing =
how an Authorization Service can accept and verify an authentication =
token provided by a client during the authorization process? If so, =
please point me to that. The only RFCs I have seen  that address this =
are RFCs 7251, 7252 and 7253, and they all have a requirement that an =
=E2=80=9Caudience=E2=80=9D claim corresponding to the Authorization =
Service is in the authentication token. Getting that claim into an =
authentication token provided by an Organization=E2=80=99s Identity =
provider seems to be my fundamental problem.
>>>=20
>>> Thanks,
>>>       Andy
>>>=20
>>> From: Nat Sakimura >
>>> Date: Tuesday, April 19, 2016 at 4:13 PM
>>> To: Andrew Fregly >, John Bradley >, "oauth@ietf.org " =
>
>>>=20
>>> Subject: Re: [OAUTH-WG] Building on the protocol in the draft "OAuth =
2.0 Token Exchange: An STS for the REST of Us" to include Authentication =
Tokens
>>>=20
>>>> Get OpenID Connect id_token by the authentication request with =
prompt=3Dnone and verifying the sub to be the same with what you =
expected seem to suffice your needs. Am I missing something?=20
>>>> On Wed, Apr 20, 2016 at 05:05 Fregly, Andrew > wrote:
>>>>> Thanks for your response John. I also got a good response from =
Brian Campbell and appreciate that. I will respond separately to =
Brian=E2=80=99s response as I think it would keep things clearer to do =
that.
>>>>>=20
>>>>> The problem we have for using OpenID Connect is that it combines =
the role of Authentication Service with the role of Authorization =
Service. Perhaps the following description of what we want to do will =
clarify why this won=E2=80=99t work for us:
>>>>>=20
>>>>> The basic problem statement is that we need to have a client =
application authorized by a Service Provider based on proof that a user =
is currently a member of some organization. This assumes the =
organization has previously established some level of authorized access =
with the Service Provider.=20
>>>>>=20
>>>>> Here is an example: Suppose I am a member of SomeOrg Inc. Suppose =
SomeOrg Inc. is doing research that requires it to gather data over the =
Internet from a number of data providers. The data providers require =
authentication and proof of organizational membership in order to =
authorize various levels of access to their data. The data providers do =
not consider having an account with them or a Public Identity Provider =
to be suitable for proving that I am still a member of SomeOrg at time =
of authentication. They would have no way of knowing whether or not my =
relationship with SomeOrg still exists at that time. The data providers =
would therefore like the Client software to authenticate me against =
SomeOrgs Identity Provider. This would be good proof that I am still a =
member of SomeOrg at the time I authenticate. This authentication would =
enable the data providers Authorization Server to grant me access =
appropriate to a member of SomeOrg.  Note that as a prerequisite to all =
of this, SomeOrg will have used an out-of-band process to set up a trust =
relationship for SomeOrg's Identity Provider with the data provider=E2=80=99=
s Authorization Service, and will have negotiated authorization claims =
to be granted to SomeOrgs members.
>>>>>=20
>>>>> What I am having difficulty with is in knitting together an =
approach based on the he OpenID Connect specifications, SAML =
specifications, and OAuth RFCs and drafts in a way that supports the =
above use case end-to-end. The OAuth RFCs and drafts almost get me =
there. What seems to be missing is a way of telling an Identity Provider =
the URL for the Authorization Service (the required Audience claim in an =
authentication assertion as defined in RFCs 7251, 7252 and 7253), and =
then a requirement that the Identity Providers put the supplied Audience =
Identifier into Authentication Tokens. Perhaps a little further =
back-and-forth with Brian will resolve this.
>>>>>=20
>>>>> I can go into deeper detail if needed. If this is off-topic for =
the OAuth working group, let me know.
>>>>>=20
>>>>> Thanks,
>>>>> Andrew Fregly
>>>>> Verisign Inc.
>>>>>=20
>>>>>=20
>>>>> From: John Bradley >
>>>>> Date: Tuesday, April 19, 2016 at 2:06 PM
>>>>> To: Andrew Fregly >
>>>>> Cc: "oauth@ietf.org " >
>>>>> Subject: Re: [OAUTH-WG] Building on the protocol in the draft =
=E2=80=9COAuth 2.0 Token Exchange: An STS for the REST of Us=E2=80=9D to =
include Authentication Tokens
>>>>>=20
>>>>>> Looking at OpenID Connect and it=E2=80=99s trust model for =
producing id_tokens that assert identity may help you.
>>>>>> http://openid.net/wg/connect/ 
>>>>>>=20
>>>>>> Unfortunately I can=E2=80=99t quite make out what you are trying =
to do.=20
>>>>>>=20
>>>>>> It sort of sounds like you want an id_token from a idP and then =
have the client exchange that assertion for another token?
>>>>>>=20
>>>>>> John B.
>>>>>>> On Apr 19, 2016, at 1:18 PM, Fregly, Andrew =
> wrote:
>>>>>>>=20
>>>>>>> I have a use case where a client application needs to =
authenticate with a dynamically determined Identity Provider that is =
separate from the Authorization Service that will be used issue an =
access token to the client. The use case also requires that as part of =
authorization, the client provides to the Authorization Service an =
authentication token signed by an Identity Provider that the =
Authorization Service has a trust relationship with. The trust =
relationship is verifiable based on the Authorization Service having =
recorded the public keys or certificates of trusted Identity Providers =
in a trust store, this allowing the Authorization Service to verify an =
Identity Provider=E2=80=99s signature on an authentication token. <>
>>>>>>> =20
>>>>>>> In looking at the various OAuth RFCs, particularly RFCs 7521, =
7522, and 7523, I see that they get me close in terms of supporting the =
use case. What is missing is a means for solving the following problem. =
These RFCs require that the Identity Provider put an Audience claim in =
the authentication token. The problem with this is that I do not see in =
the RFCs how the Identity Provider can be told who the Audience is to =
put into the authentication token. This leads me to the title of this =
message. The draft =E2=80=9COAuth 2.0 Token Exchange: An STS for the =
REST of Us=E2=80=9D defines a mechanism for identifying the Audience for =
an STS to put into a token it generates. That would solve my problem =
except that the draft limits the type of STS to being Authorization =
Servers. What is needed is this same capability for interacting with an =
Identity Provider. This would enable RFCs 7521, 7522 and 7523 to be =
useful in situation where the Identity Provider needs to be told the =
identity of the Authorization Service.
>>>>>>> =20
>>>>>>> I am new to interacting with the IETF. I also am not an expert =
on the RFCs or prior history of the OAuth group relative to this topic, =
so please point me to any existing solution if this is a solved problem. =
Otherwise, I would like to get feedback on my suggestion.
>>>>>>> =20
>>>>>>> Thanks You,
>>>>>>>=20
>>>>>>> Andrew Fregly
>>>>>>> Verisign Inc.
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing 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=_32819EE7-D6EB-4928-A0EE-65507C9B7D17
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

For people using RFC 7521, 7522, 7523 they are taking an =
assertion and using a WS-* STS to transform it into one with the correct =
audience to use  in 7521.

I know that some people have just ignored the audience, =
 however that can have negative security consequences.  When =
exchanging the token you want to be certain that it is the entity that =
the token was issued to that is exchanging it.

The STS for the rest of us is a more =
general framework that should allow you to take a id_token or SAML =
assertion and securely exchange it for another assertion or access =
token.

I =
don=E2=80=99t understand the use case enough to say if that is the best =
thing for you, but yes that is the intent of that spec.

John B.

On Apr 20, 2016, at 10:58 AM, Fregly, Andrew <afregly@verisign.com> wrote:




RFC 7521 - Assertion Framework for OAuth 2.0 Client =
Authentication and Authorization Grants






Thank you again of your input =
Nat. 







First of all, I apologize for confusing the =
situation by referencing the wrong RFCs in a prior email. I transposed =
two digits. The RFCs I meant to reference where 7521-7523 (see =
below).







I get that the original RFC for OAuth has the =
mechanism for client authentication being out of scope.  What is =
muddying the water for me is that RFCs 7521, 7522, and 7523 seem to =
specify the means by which a client can provide
 an authentication token to an Authorization Service. This purpose is =
stated at the top of the abstract for RFC 7521:







"The intent of this specification is to provide a =
common framework for OAuth
 2.0 to interwork with other identity systems using =
assertions and to provide alternative client authentication =
mechanisms.=E2=80=9D







In our use case, we need to have users authenticated =
against identity providers that organizations use internally as the =
means for authenticating clients accessing our service. We need this =
because we believe this is the best means for proving a user is
 still a member of an organization at the time they authenticate. Most, =
perhaps all of these organizations, will internally use an Identity =
Provider that provides SAML authentication assertions. This led me to =
looking for a way to use authentication tokens
 produced by internal Identity Providers as a means for proving a client =
had been authenticated by the organization. A bit of investigation in =
how this might be done led me to OAuth RFCs 7521, 7522 and 7523. They =
 almost get me there. They specify what needs
 to be in an Authentication token that is given by a client to an =
Authorization Service. The gotcha was that these RFCs require an =
audience claim in the authentication token. This audience claim is used =
to identify the specific Authorization Service the token
 is meant for. For this audience claim to get filled in by some =
arbitrary organization=E2=80=99s Identity Provider, it seems the =
Identity Provider will need to be told who the Authorization Service is =
by the client initiating the authentication. I have therefore been
 looking for a standard that specifies how a client can tell the =
Identity Provider the identity of the Authorization Service. I was stuck =
for a bit on how the IETF OAuth working group could address this issue =
since authentication seemed to be out of scope for
 the group. Then I found the  IETF draft "OAuth 2.0 Token =
Exchange: An STS for the REST of Us=E2=80=9D. It defines a mechanism for =
telling a Security Token Service the audience for the token it is being =
asked to issue. I thought that would solve my problem since an
 intent of the draft seemed to be on generalizing the described =
approach to any type of Security Token Service. There was one gotcha in =
the draft though. It limited the type of STS to which the protocol =
applied to be just Authorization Services. For my use
 case, I needed the capability described in the draft, but applicable to =
Identity Providers too. If it were applicable to Identity Providers, =
there would then be a full set of existing RFCs and drafts that covered =
the functionality needed for our use case. 







There are a couple of possible actions that I =
have been contemplating relative to OAuth:


    

  1. Write extensions to RFCs 7521, 7522 and 7523 that =
eliminate the need for an audience claim in the authentication token if =
the Authorization Service has a trust relationship with the Identity =
Provider that issued the authentication token.
  2. Ask =
the authors of the =E2=80=9COAuth 2.0 Token Exchange: An STS for the =
REST of Us=E2=80=9D to explicitly state that the the approach described =
there-in is applicable to both Identity Providers and Authorization =
services.


Before doing either of these steps, I want to =
make sure that I am not missing something in existing RFCs and drafts =
that would address our use case. I have only been looking at this issue =
for a few weeks, so I thought it would
 be best to go to the experts to get advice. This led to this email =
chain. 















Thanks to all following this chain for your =
time and consideration on this!







Andy










From: Nat Sakimura =
<sakimura@gmail.com>

Date: Tuesday, April =
19, 2016 at 5:35 PM

To: Andrew Fregly =
<afregly@verisign.com>, John Bradley <ve7jtb@ve7jtb.com>, =
"oauth@ietf.org" <oauth@ietf.org>

Subject: Re: =
[OAUTH-WG] Building on the protocol in the draft "OAuth 2.0 Token =
Exchange: An STS for the REST of Us" to include Authentication Tokens

















Hi Andrew, 









In OAuth 2.0, =
the resource owner authentication /end user authentication is out of =
scope. What it deals with is "client authentication". They should not be =
mixed up. There is no end user identity nor authentication token in
 the OAuth. You cannot do end user authentication with pure OAuth. For =
that, you have to rely on something like OpenID Connect. 





=




As John =
noted, it is perfectly fine to chain the external authentication and the =
internal authorization. It is often done. It is just that the RFC6749 =
Authz server is an RP of OpenID Connect or SP of SAML. Nothing precludes
 it. 



=




If you really =
want to avoid the front channel re-auth with prompt=3Dnone, which is =
more secure and proper ways to do, but just to make sure that the user =
still exists in the authentication service, you can infer it by making
 a userinfo request to the userinfo endpoint of OpenID Connect. It would =
fail in various reasons, but would certainly fail if the user does not =
exist anymore. Other error conditions like the user revoked the =
access/refresh token etc. would cause the same invalid_token
 error though. 









Best, 



=




Nat









P.S. I =
do not see why the RFCs you sited are relevant here. I guess you are =
talking about RFC7521-7523 ;-)






RFC7251 AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for =
TLS

RFC7252 The Constrained Application Protocol (CoAP)

RFC7253 The OCB Authenticated-Encryption Algorithm











































2016=E5=B9=B44=E6=9C=8820=E6=97=A5(=E6=B0=B4) =
5:34 Fregly, Andrew <afregly@verisign.com>:










Thanks for your reply Nat.







Does your approach match with an IETF OAuth RFC or Draft =
describing how an Authorization Service can accept and verify an =
authentication token provided by a client during the authorization =
process? If so, please point me to that. The only RFCs I have seen
 that address this are RFCs 7251, 7252 and 7253, and they all have a =
requirement that an =E2=80=9Caudience=E2=80=9D claim corresponding to =
the Authorization Service is in the authentication token. Getting that =
claim into an authentication token provided by an Organization=E2=80=99s
 Identity provider seems to be my fundamental problem.







Thanks,


      Andy

















From: Nat Sakimura =
<sakimura@gmail.com>

Date: Tuesday, April =
19, 2016 at 4:13 PM

To: Andrew Fregly =
<afregly@verisign.com>, John Bradley <ve7jtb@ve7jtb.com>, "oauth@ietf.org"
 <oauth@ietf.org>










Subject: Re: =
[OAUTH-WG] Building on the protocol in the draft "OAuth 2.0 Token =
Exchange: An STS for the REST of Us" to include Authentication Tokens


















Get OpenID Connect id_token by the authentication =
request with prompt=3Dnone and verifying the sub to be the same with =
what you expected seem to suffice your needs. Am I missing something?





On Wed, Apr 20, 2016 at 05:05 Fregly, Andrew =
<afregly@verisign.com> wrote:










Thanks for your response John. I also got a good =
response from Brian Campbell and appreciate that. I will respond =
separately to Brian=E2=80=99s response as I think it would keep things =
clearer to do that.







The problem we have for using OpenID Connect is that it =
combines the role of Authentication Service with the role of =
Authorization Service. Perhaps the following description of what we want =
to do will clarify why this won=E2=80=99t work for us:







The basic problem statement is that we need to have a =
client application authorized by a Service Provider based on proof that =
a user is currently a member of some organization. This assumes the =
organization has previously established some level of authorized
 access with the Service Provider. 







Here is an example: Suppose I am a member of SomeOrg =
Inc. Suppose SomeOrg Inc. is doing research that requires it to gather =
data over the Internet from a number of data providers. The data =
providers require authentication and proof of organizational membership
 in order to authorize various levels of access to their data. The data =
providers do not consider having an account with them or a Public =
Identity Provider to be suitable for proving that I am still a member of =
SomeOrg at time of authentication. They would
 have no way of knowing whether or not my relationship with SomeOrg =
still exists at that time. The data providers would therefore like the =
Client software to authenticate me against SomeOrgs Identity Provider. =
This would be good proof that I am still a member
 of SomeOrg at the time I authenticate. This authentication would enable =
the data providers Authorization Server to grant me access appropriate =
to a member of SomeOrg.  Note that as a prerequisite to all of =
this, SomeOrg will have used an out-of-band process
 to set up a trust relationship for SomeOrg's Identity Provider with the =
data provider=E2=80=99s Authorization Service, and will have negotiated =
authorization claims to be granted to SomeOrgs members.







What I am having difficulty with is in knitting together =
an approach based on the he OpenID Connect specifications, SAML =
specifications, and OAuth RFCs and drafts in a way that supports the =
above use case end-to-end. The OAuth RFCs and drafts almost get
 me there. What seems to be missing is a way of telling an Identity =
Provider the URL for the Authorization Service (the required Audience =
claim in an authentication assertion as defined in RFCs 7251, 7252 and =
7253), and then a requirement that the Identity
 Providers put the supplied Audience Identifier into Authentication =
Tokens. Perhaps a little further back-and-forth with Brian will resolve =
this.







I can go into deeper detail if needed. If this is =
off-topic for the OAuth working group, let me know.







Thanks,


Andrew Fregly


Verisign Inc.






















From: John Bradley =
<ve7jtb@ve7jtb.com>

Date: Tuesday, April =
19, 2016 at 2:06 PM

To: Andrew Fregly =
<afregly@verisign.com>

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

Subject: Re: =
[OAUTH-WG] Building on the protocol in the draft =E2=80=9COAuth 2.0 =
Token Exchange: An STS for the REST of Us=E2=80=9D to include =
Authentication Tokens


















Looking at OpenID Connect =
and it=E2=80=99s trust model for producing id_tokens that assert =
identity may help you.

http://openid.net/wg/connect/







Unfortunately I can=E2=80=99t quite make out what you =
are trying to do. 







It sort of sounds like you want an id_token from a idP =
and then have the client exchange that assertion for another =
token?







John B.






On Apr 19, 2016, at 1:18 PM, Fregly, Andrew <afregly@verisign.com> wrote:








I have a use case where a client =
application needs to authenticate with a dynamically determined Identity =
Provider that is separate from the Authorization Service
 that will be used issue an access token to the client. The use case =
also requires that as part of authorization, the client provides to the =
Authorization Service an authentication token signed by an Identity =
Provider that the Authorization Service has a trust
 relationship with. The trust relationship is verifiable based on the =
Authorization Service having recorded the public keys or certificates of =
trusted Identity Providers in a trust store, this allowing the =
Authorization Service to verify an Identity Provider=E2=80=99s
 signature on an authentication token.




 


In looking at =
the various OAuth RFCs, particularly RFCs 7521, 7522, and 7523, I see =
that they get me close in terms of supporting the use case. What is =
missing is a means for solving the
 following problem. These RFCs require that the Identity Provider put an =
Audience claim in the authentication token. The problem with this is =
that I do not see in the RFCs how the Identity Provider can be told who =
the Audience is to put into the authentication
 token. This leads me to the title of this message. The draft =E2=80=9COAu=
th 2.0 Token Exchange: An STS for the REST of Us=E2=80=9D defines a =
mechanism for identifying the Audience for an STS to put into a token it =
generates. That would solve my problem except that the draft
 limits the type of STS to being Authorization Servers. What is needed =
is this same capability for interacting with an Identity Provider. This =
would enable RFCs 7521, 7522 and 7523 to be useful in situation where =
the Identity Provider needs to be told the identity
 of the Authorization Service.


 


I am new to =
interacting with the IETF. I also am not an expert on the RFCs or prior =
history of the OAuth group relative to this topic, so please point me to =
any existing solution if this
 is a solved problem. Otherwise, I would like to get feedback on my =
suggestion.


 


Thanks =
You,







Andrew Fregly


Verisign =
Inc.









_______________________________________________

OAuth
 mailing 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=_32819EE7-D6EB-4928-A0EE-65507C9B7D17--


From nobody Wed Apr 20 10:36:38 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D97512EFB3 for ; Wed, 20 Apr 2016 10:36:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.895
X-Spam-Level: 
X-Spam-Status: No, score=-2.895 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.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mx.aol.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iw4VJGe6tIjU for ; Wed, 20 Apr 2016 10:36:33 -0700 (PDT)
Received: from omr-m012e.mx.aol.com (omr-m012e.mx.aol.com [204.29.186.12]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6F6912EFB2 for ; Wed, 20 Apr 2016 10:36:32 -0700 (PDT)
Received: from mtaout-aal02.mx.aol.com (mtaout-aal02.mx.aol.com [172.27.20.206]) by omr-m012e.mx.aol.com (Outbound Mail Relay) with ESMTP id C7B12380008B; Wed, 20 Apr 2016 13:36:31 -0400 (EDT)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aal02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id DB96A380000AA; Wed, 20 Apr 2016 13:36:30 -0400 (EDT)
To: "Fregly, Andrew" , John Bradley , "oauth@ietf.org" 
References:   <8B748252-9AE2-4824-923B-00CD46CB8D68@verisign.com> <571692A1.5070000@aol.com> <6101D0EB-E04B-4574-8899-ED8F4E631D67@verisign.com> <57177AD0.1090300@aol.com> 
From: George Fletcher 
Organization: AOL LLC
Message-ID: <5717BE1E.8070007@aol.com>
Date: Wed, 20 Apr 2016 13:36:30 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040709090904000307030209"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1461173791; bh=xn0f6p6bCbqqocGdcNbT1WLd5yK3G+C5y7/LWiUxOkc=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=hT70TJHR25fiYmr0Mg1B8HC4esntp4jbDPJ9YJHvcs1Cy5N+/G3Lk9pNsrve4jLxy XzE1xMP3qDbChToFGXhATUCQLPnP8/iiTwrAfn1Rj0XhuPQlALaDni8YCZCJkcjRb/ 1xBcr0LAVoCnO2kLPJyDLTlIJIidAComKLwMeLfI=
x-aol-sid: 3039ac1b14ce5717be1e0d98
X-AOL-IP: 10.172.102.179
Archived-At: 
Subject: Re: [OAUTH-WG] =?utf-8?q?Building_on_the_protocol_in_the_draft_?= =?utf-8?q?=E2=80=9COAuth_2=2E0_Token_Exchange=3A_An_STS_for_the_REST_of_U?= =?utf-8?q?s=E2=80=9D_to_include_Authentication_Tokens?=
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Apr 2016 17:36:36 -0000

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

Hi Andy,

Glad I guessed correctly:) If there are network or other limitations in 
how the client gets and uses tokens, that would be helpful in a diagram 
sense. As John points out in his response, not having an audience has 
possible security implications.

If I'm following your original thinking... it goes something like this...

1. Mobile app asks users to authenticate at "their" IdP
2. Mobile app gets back "authentication token" (likely some sort of SAML 
assertion)
3. Mobile app presents "authentication token" to Authorization Service
4. Authorization Service validate "authentication token" and returns an 
access_token
5. Mobile app invokes data provider passing the access_token
6. Data provider validates access_token (either locally or via an 
introspection endpoint on the AS)

In this flow there are really two tokens: the "authentication token" and 
the access_token. There should be an audience for both tokens. The 
audience of the "authentication token" should be the AS, and the 
audience of the access_token should be the data provider the client is 
going to use.

So, if there are no network firewall type limitations, it seems much 
simpler to just have the AS use the external IdPs as it's authentication 
mechanisms and the rest is just default OpenID Connect. Meaning that the 
Mobile app starts an OpenID Connect flow with the AS, the AS get the 
user authenticated via the user's IdP, the AS provides access and id 
tokens bask to the Mobile app (following the code or other flow).

Am I missing something?

Thanks,
George

On 4/20/16 10:31 AM, Fregly, Andrew wrote:
> Hi George,
>
> You fully captured one of the options we have been contemplating. I 
> didn’t propose this flow because I was looking for a way to solve our 
> our use case based on the existing RFCs and OpenID Connect 
> specifications with minimal new specification required. That led me to 
> the path described in the email response I sent out a little while ago 
> to Nat Sakimura’s response. Please take a look at that email and see 
> what you think.
>
> Given how well stated your summary of our needs was, do you still want 
> me to provide a diagram?
>
> Thanks,
>     Andy
>
> From: George Fletcher >
> Organization: AOL LLC
> Date: Wednesday, April 20, 2016 at 8:49 AM
> To: Andrew Fregly  >, John Bradley  >, "oauth@ietf.org " 
> >
> Subject: Re: [OAUTH-WG] Building on the protocol in the draft “OAuth 
> 2.0 Token Exchange: An STS for the REST of Us†to include 
> Authentication Tokens
>
>     I should probably just wait for the diagram... but not wanting to
>     wait... :)
>
>     If I understand correctly, the user is going to use a client and
>     the client will authenticate the user via some IdP using an
>     existing method (SAML, LDAP (?), OpenID Connect, etc). The desire
>     is to take that response and in some way present it to an
>     "Authorization Server" which will validate the "authentication
>     response" and return an access token for use at the data provider(s).
>
>     What if the Authorization Server also took on the role of the
>     OpenID Connect provider. This could work by having the client
>     start an OpenID Connect flow with Authorization Server (hints
>     could be provided as to which IdP the user wants to authenticate
>     at). The AS would look at the "idp hint" and either start and SP
>     SAML flow, or present UI for collecting LDAP credentials (I don't
>     recommend this) or chain to any other proprietary IdP flow. Once
>     the user successfully authenticates with the correct IdP, the AS
>     will finish the OpenID Connect flow allowing the client to obtain
>     an access token, refresh token and id_token. The AS could add to
>     the id_token a claim specifying which IdP the user used during the
>     authentication processed.
>
>     The IdP the user used for authentication could also be encoded in
>     the access_token (or returned as part of an introspection call).
>
>     This way whether the data providers are validating the
>     access_tokens locally or using introspection they can obtain the
>     IdP the user used and apply their own authorization rules.
>
>     The user is only required to do one authorization flow for the
>     client that is managed by the Authorization Server.
>
>     Thanks,
>     George
>
>     On 4/19/16 5:06 PM, Fregly, Andrew wrote:
>>     Thank you for your response George. It points me to some more
>>     research to do, such as looking at OpenID Connect support for
>>     both distributed and aggregated claims.
>>
>>     Below are replies to your questions/assertions based on my
>>     current understanding of the various protocols. Further research
>>     and advice will likely enrich this significantly.
>>
>>     Yes, what is required is a verifiable claim that the user is
>>     still a member of SomeOrg Inc. I have been operating under the
>>     assumption that the only way this can be done would be to have
>>     the user authenticated by the Identity Provider for SomeOrg.
>>     Perhaps the research into OpenID Connect support for distributed
>>     and aggregated claims will reveal an alternative. I foresee a
>>     challenge in dealing with Identity Provider’s for organizations
>>     using SAML assertions on top of Active Directory and LDAP, and
>>     which are not going to do any updating to support our needs.
>>
>>     We do not expect the user to first go to the data provider. We
>>     anticipate that the client application would provide a
>>     Authentication Token to an  Authorization Service service that
>>     then issues to the client an access token that the data provider
>>     will trust. One of our reasons for doing it this way is that we
>>     are trying to eliminate redirects to ease implementation of a
>>     native client. We are therefore requiring the client to handle
>>     authentication with the Identity Provider as a separate step from
>>     authorization.
>>
>>     It might help if I clarified that Verisign’s role in the scenario
>>     I described is to be just one of many data providers.
>>
>>     From: George Fletcher >
>>     Organization: AOL LLC
>>     Date: Tuesday, April 19, 2016 at 4:18 PM
>>     To: Andrew Fregly , John Bradley
>>     >, "oauth@ietf.org"
>>     >
>>     Subject: Re: [OAUTH-WG] Building on the protocol in the draft
>>     “OAuth 2.0 Token Exchange: An STS for the REST of Us†to include
>>     Authentication Tokens
>>
>>         So if I understand this correctly, what is really required is
>>         a verifiable claim that the user is still a member of SomeOrg
>>         Inc. OpenID Connect supports both distributed and aggregated
>>         claims that can be signed by the appropriate Identity
>>         Provider. The point being that I'm not sure an
>>         "authentication token" is required for this use case to
>>         succeed, it's just one kind of token that can be used.
>>
>>         Also, is the expected flow that the user will first go to the
>>         data provider and then be directed else where from there? If
>>         that is the case, the data provider can just be an OpenID
>>         Connect relying party and give the user an option of the list
>>         of supported IdPs to choose from. The user will then be
>>         redirected to SomeOrg Inc. IdP, authenticate and the data
>>         provider will have the authorization and recent
>>         authentication they can validate.
>>
>>         Is the user/data flow more complicated than this?
>>
>>         Thanks,
>>         George
>>
>>         On 4/19/16 4:05 PM, Fregly, Andrew wrote:
>>>         Thanks for your response John. I also got a good response
>>>         from Brian Campbell and appreciate that. I will respond
>>>         separately to Brian’s response as I think it would keep
>>>         things clearer to do that.
>>>
>>>         The problem we have for using OpenID Connect is that it
>>>         combines the role of Authentication Service with the role of
>>>         Authorization Service. Perhaps the following description of
>>>         what we want to do will clarify why this won’t work for us:
>>>
>>>         The basic problem statement is that we need to have a client
>>>         application authorized by a Service Provider based on proof
>>>         that a user is currently a member of some organization. This
>>>         assumes the organization has previously established some
>>>         level of authorized access with the Service Provider.
>>>
>>>         Here is an example: Suppose I am a member of SomeOrg Inc.
>>>         Suppose SomeOrg Inc. is doing research that requires it to
>>>         gather data over the Internet from a number of data
>>>         providers. The data providers require authentication and
>>>         proof of organizational membership in order to authorize
>>>         various levels of access to their data. The data providers
>>>         do not consider having an account with them or a Public
>>>         Identity Provider to be suitable for proving that I am still
>>>         a member of SomeOrg at time of authentication. They would
>>>         have no way of knowing whether or not my relationship with
>>>         SomeOrg still exists at that time. The data providers would
>>>         therefore like the Client software to authenticate me
>>>         against SomeOrgs Identity Provider. This would be good proof
>>>         that I am still a member of SomeOrg at the time I
>>>         authenticate. This authentication would enable the data
>>>         providers Authorization Server to grant me access
>>>         appropriate to a member of SomeOrg.  Note that as a
>>>         prerequisite to all of this, SomeOrg will have used an
>>>         out-of-band process to set up a trust relationship for
>>>         SomeOrg's Identity Provider with the data provider’s
>>>         Authorization Service, and will have negotiated
>>>         authorization claims to be granted to SomeOrgs members.
>>>
>>>         What I am having difficulty with is in knitting together an
>>>         approach based on the he OpenID Connect specifications, SAML
>>>         specifications, and OAuth RFCs and drafts in a way that
>>>         supports the above use case end-to-end. The OAuth RFCs and
>>>         drafts almost get me there. What seems to be missing is a
>>>         way of telling an Identity Provider the URL for the
>>>         Authorization Service (the required Audience claim in an
>>>         authentication assertion as defined in RFCs 7251, 7252 and
>>>         7253), and then a requirement that the Identity Providers
>>>         put the supplied Audience Identifier into Authentication
>>>         Tokens. Perhaps a little further back-and-forth with Brian
>>>         will resolve this.
>>>
>>>         I can go into deeper detail if needed. If this is off-topic
>>>         for the OAuth working group, let me know.
>>>
>>>         Thanks,
>>>         Andrew Fregly
>>>         Verisign Inc.
>>>
>>>
>>>         From: John Bradley 
>>>         Date: Tuesday, April 19, 2016 at 2:06 PM
>>>         To: Andrew Fregly 
>>>         Cc: "oauth@ietf.org" >
>>>         Subject: Re: [OAUTH-WG] Building on the protocol in the
>>>         draft “OAuth 2.0 Token Exchange: An STS for the REST of Usâ€
>>>         to include Authentication Tokens
>>>
>>>             Looking at OpenID Connect and it’s trust model for
>>>             producing id_tokens that assert identity may help you.
>>>             http://openid.net/wg/connect/
>>>
>>>             Unfortunately I can’t quite make out what you are trying
>>>             to do.
>>>
>>>             It sort of sounds like you want an id_token from a idP
>>>             and then have the client exchange that assertion for
>>>             another token?
>>>
>>>             John B.
>>>>             On Apr 19, 2016, at 1:18 PM, Fregly, Andrew
>>>>              wrote:
>>>>
>>>>             I have a use case where a client application needs to
>>>>             authenticate with a dynamically determined Identity
>>>>             Provider that is separate from the Authorization
>>>>             Service that will be used issue an access token to the
>>>>             client. The use case also requires that as part of
>>>>             authorization, the client provides to the Authorization
>>>>             Service an authentication token signed by an Identity
>>>>             Provider that the Authorization Service has a trust
>>>>             relationship with. The trust relationship is verifiable
>>>>             based on the Authorization Service having recorded the
>>>>             public keys or certificates of trusted Identity
>>>>             Providers in a trust store, this allowing the
>>>>             Authorization Service to verify an Identity Provider’s
>>>>             signature on an authentication token.
>>>>             In looking at the various OAuth RFCs, particularly RFCs
>>>>             7521, 7522, and 7523, I see that they get me close in
>>>>             terms of supporting the use case. What is missing is a
>>>>             means for solving the following problem. These RFCs
>>>>             require that the Identity Provider put an Audience
>>>>             claim in the authentication token. The problem with
>>>>             this is that I do not see in the RFCs how the Identity
>>>>             Provider can be told who the Audience is to put into
>>>>             the authentication token. This leads me to the title of
>>>>             this message. The draft “OAuth 2.0 Token Exchange: An
>>>>             STS for the REST of Us†defines a mechanism for
>>>>             identifying the Audience for an STS to put into a token
>>>>             it generates. That would solve my problem except that
>>>>             the draft limits the type of STS to being Authorization
>>>>             Servers. What is needed is this same capability for
>>>>             interacting with an Identity Provider. This would
>>>>             enable RFCs 7521, 7522 and 7523 to be useful in
>>>>             situation where the Identity Provider needs to be told
>>>>             the identity of the Authorization Service.
>>>>             I am new to interacting with the IETF. I also am not an
>>>>             expert on the RFCs or prior history of the OAuth group
>>>>             relative to this topic, so please point me to any
>>>>             existing solution if this is a solved problem.
>>>>             Otherwise, I would like to get feedback on my suggestion.
>>>>             Thanks You,
>>>>
>>>>             Andrew Fregly
>>>>             Verisign Inc.
>>>>             _______________________________________________
>>>>             OAuth mailing list
>>>>             OAuth@ietf.org 
>>>>             https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>>         _______________________________________________
>>>         OAuth mailing list
>>>         OAuth@ietf.orghttps://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


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


  
    
  
  
    Hi Andy,

      

      Glad I guessed correctly:) If there are network or other
      limitations in how the client gets and uses tokens, that would be
      helpful in a diagram sense. As John points out in his response,
      not having an audience has possible security implications.

      

      If I'm following your original thinking... it goes something like
      this...

      

      1. Mobile app asks users to authenticate at "their" IdP

      2. Mobile app gets back "authentication token" (likely some sort
      of SAML assertion)

      3. Mobile app presents "authentication token" to Authorization
      Service

      4. Authorization Service validate "authentication token" and
      returns an access_token

      5. Mobile app invokes data provider passing the access_token

      6. Data provider validates access_token (either locally or via an
      introspection endpoint on the AS)

      

      In this flow there are really two tokens: the "authentication
      token" and the access_token. There should be an audience for both
      tokens. The audience of the "authentication token" should be the
      AS, and the audience of the access_token should be the data
      provider the client is going to use.

      

      So, if there are no network firewall type limitations, it seems
      much simpler to just have the AS use the external IdPs as it's
      authentication mechanisms and the rest is just default OpenID
      Connect. Meaning that the Mobile app starts an OpenID Connect flow
      with the AS, the AS get the user authenticated via the user's IdP,
      the AS provides access and id tokens bask to the Mobile app
      (following the code or other flow).

      

      Am I missing something?

      

      Thanks,

      George

    

    
On 4/20/16 10:31 AM, Fregly, Andrew
      wrote:

    

    

      
      

        

          
Hi George,

          


          

          
You fully captured one of the options we have been
            contemplating. I didn’t propose this flow because I was
            looking for a way to solve our our use case based on the
            existing RFCs and OpenID Connect specifications with minimal
            new specification required. That led me to the path
            described in the email response I sent out a little while
            ago to Nat Sakimura’s response. Please take a look at that
            email and see what you think.

          


          

          
Given how well stated your summary of our needs was, do
            you still want me to provide a diagram?

          


          

          
Thanks,

          
    Andy

          

          

        

      

      


      

      
        

          From: George Fletcher
          <gffletch@aol.com>

          Organization: AOL LLC

          Date: Wednesday, April
          20, 2016 at 8:49 AM

          To: Andrew Fregly <afregly@verisign.com>,
          John Bradley <ve7jtb@ve7jtb.com>, "oauth@ietf.org"
          <oauth@ietf.org>

          Subject: Re: [OAUTH-WG]
          Building on the protocol in the draft “OAuth 2.0 Token
          Exchange: An STS for the REST of Us†to include Authentication
          Tokens

        

        


        

        

          

            
I should probably just
                wait for the diagram... but not wanting to wait... :)

                

                If I understand correctly, the user is going to use a
                client and the client will authenticate the user via
                some IdP using an existing method (SAML, LDAP (?),
                OpenID Connect, etc). The desire is to take that
                response and in some way present it to an "Authorization
                Server" which will validate the "authentication
                response" and return an access token for use at the data
                provider(s).

                

                What if the Authorization Server also took on the role
                of the OpenID Connect provider. This could work by
                having the client start an OpenID Connect flow with
                Authorization Server (hints could be provided as to
                which IdP the user wants to authenticate at). The AS
                would look at the "idp hint" and either start and SP
                SAML flow, or present UI for collecting LDAP credentials
                (I don't recommend this) or chain to any other
                proprietary IdP flow. Once the user successfully
                authenticates with the correct IdP, the AS will finish
                the OpenID Connect flow allowing the client to obtain an
                access token, refresh token and id_token. The AS could
                add to the id_token a claim specifying which IdP the
                user used during the authentication processed.

                

                The IdP the user used for authentication could also be
                encoded in the access_token (or returned as part of an
                introspection call).

                

                This way whether the data providers are validating the
                access_tokens locally or using introspection they can
                obtain the IdP the user used and apply their own
                authorization rules.

                

                The user is only required to do one authorization flow
                for the client that is managed by the Authorization
                Server.

                

                Thanks,

                George

              

              
On 4/19/16 5:06 PM, Fregly,
                Andrew wrote:

              

              

                

                  
Thank you for your response George. It points me
                    to some more research to do, such as looking at
                    OpenID Connect support for both distributed and
                    aggregated claims.

                  


                  

                  
Below are replies to your questions/assertions
                    based on my current understanding of the various
                    protocols. Further research and advice will likely
                    enrich this significantly.

                  


                  

                  
Yes, what is required is a verifiable claim that
                    the user is still a member of SomeOrg Inc. I have
                    been operating under the assumption that the only
                    way this can be done would be to have the user
                    authenticated by the Identity Provider for SomeOrg.
                    Perhaps the research into OpenID Connect support for
                    distributed and aggregated claims will reveal an
                    alternative. I foresee a challenge in dealing with
                    Identity Provider’s for organizations using SAML
                    assertions on top of Active Directory and LDAP, and
                    which are not going to do any updating to support
                    our needs.

                

                


                

                
We do not expect the user to first go to the data
                  provider. We anticipate that the client application
                  would provide a Authentication Token to an
                   Authorization Service service that then issues to the
                  client an access token that the data provider will
                  trust. One of our reasons for doing it this way is
                  that we are trying to eliminate redirects to ease
                  implementation of a native client. We are therefore
                  requiring the client to handle authentication with the
                  Identity Provider as a separate step from
                  authorization.

                


                

                
It might help if I clarified that Verisign’s role
                  in the scenario I described is to be just one of many
                  data providers.

                


                

                
                  

                    From: George
                    Fletcher <gffletch@aol.com>

                    Organization: AOL
                    LLC

                    Date: Tuesday,
                    April 19, 2016 at 4:18 PM

                    To: Andrew
                    Fregly <afregly@verisign.com>,
                    John Bradley <ve7jtb@ve7jtb.com>,

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

                    Subject: Re:
                    [OAUTH-WG] Building on the protocol in the draft
                    “OAuth 2.0 Token Exchange: An STS for the REST of
                    Us†to include Authentication Tokens

                  

                  


                  

                  

                    

                      
So if I
                          understand this correctly, what is really
                          required is a verifiable claim that the user
                          is still a member of SomeOrg Inc. OpenID
                          Connect supports both distributed and
                          aggregated claims that can be signed by the
                          appropriate Identity Provider. The point being
                          that I'm not sure an "authentication token" is
                          required for this use case to succeed, it's
                          just one kind of token that can be used.

                          

                          Also, is the expected flow that the user will
                          first go to the data provider and then be
                          directed else where from there? If that is the
                          case, the data provider can just be an OpenID
                          Connect relying party and give the user an
                          option of the list of supported IdPs to choose
                          from. The user will then be redirected to
                          SomeOrg Inc. IdP, authenticate and the data
                          provider will have the authorization and
                          recent authentication they can validate.

                          

                          Is the user/data flow more complicated than
                          this?

                          

                          Thanks,

                          George

                        

                        
On 4/19/16 4:05 PM,
                          Fregly, Andrew wrote:

                        

                        

                          

                            
Thanks for your response John. I also
                              got a good response from Brian Campbell
                              and appreciate that. I will respond
                              separately to Brian’s response as I think
                              it would keep things clearer to do that.

                            


                            

                            
The problem we have for using OpenID
                              Connect is that it combines the role of
                              Authentication Service with the role of
                              Authorization Service. Perhaps the
                              following description of what we want to
                              do will clarify why this won’t work for
                              us:

                            


                            

                            
The basic problem statement is that we
                              need to have a client application
                              authorized by a Service Provider based on
                              proof that a user is currently a member of
                              some organization. This assumes the
                              organization has previously established
                              some level of authorized access with the
                              Service Provider. 

                            


                            

                            
Here is an example: Suppose I am a
                              member of SomeOrg Inc. Suppose SomeOrg
                              Inc. is doing research that requires it to
                              gather data over the Internet from a
                              number of data providers. The data
                              providers require authentication and proof
                              of organizational membership in order to
                              authorize various levels of access to
                              their data. The data providers do not
                              consider having an account with them or a
                              Public Identity Provider to be suitable
                              for proving that I am still a member of
                              SomeOrg at time of authentication. They
                              would have no way of knowing whether or
                              not my relationship with SomeOrg still
                              exists at that time. The data providers
                              would therefore like the Client software
                              to authenticate me against SomeOrgs
                              Identity Provider. This would be good
                              proof that I am still a member of SomeOrg
                              at the time I authenticate. This
                              authentication would enable the data
                              providers Authorization Server to grant me
                              access appropriate to a member of SomeOrg.
                               Note that as a prerequisite to all of
                              this, SomeOrg will have used an
                              out-of-band process to set up a trust
                              relationship for SomeOrg's Identity
                              Provider with the data provider’s
                              Authorization Service, and will have
                              negotiated authorization claims to be
                              granted to SomeOrgs members.

                            


                            

                            
What I am having difficulty with is in
                              knitting together an approach based on the
                              he OpenID Connect specifications, SAML
                              specifications, and OAuth RFCs and drafts
                              in a way that supports the above use case
                              end-to-end. The OAuth RFCs and drafts
                              almost get me there. What seems to be
                              missing is a way of telling an Identity
                              Provider the URL for the Authorization
                              Service (the required Audience claim in an
                              authentication assertion as defined in
                              RFCs 7251, 7252 and 7253), and then a
                              requirement that the Identity Providers
                              put the supplied Audience Identifier into
                              Authentication Tokens. Perhaps a little
                              further back-and-forth with Brian will
                              resolve this.

                            


                            

                            
I can go into deeper detail if needed.
                              If this is off-topic for the OAuth working
                              group, let me know.

                            


                            

                            
Thanks,

                            
Andrew Fregly

                            
Verisign Inc.

                            


                            

                          

                          


                          

                          
                            

                              From: John
                              Bradley <ve7jtb@ve7jtb.com>

                              Date: Tuesday,
                              April 19, 2016 at 2:06 PM

                              To: Andrew
                              Fregly <afregly@verisign.com>

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

                              Subject: Re:
                              [OAUTH-WG] Building on the protocol in the
                              draft “OAuth 2.0 Token Exchange: An STS
                              for the REST of Us†to include
                              Authentication Tokens

                            

                            


                            

                            

                              

                                

                                  Looking at OpenID Connect and it’s
                                  trust model for producing id_tokens
                                  that assert identity may help you.
                                  
http://openid.net/wg/connect/

                                    


                                    

                                    
Unfortunately I can’t
                                      quite make out what you are trying
                                      to do. 

                                    


                                    

                                    
It sort of sounds like
                                      you want an id_token from a idP
                                      and then have the client exchange
                                      that assertion for another token?

                                    


                                    

                                    
John B.

                                      

                                        

                                          
On Apr 19, 2016,
                                            at 1:18 PM, Fregly, Andrew
                                            <afregly@verisign.com> wrote:

                                          

                                          

                                            

                                              

                                                I have
                                                  a use case where a
                                                  client application
                                                  needs to authenticate
                                                  with a dynamically
                                                  determined Identity
                                                  Provider that is
                                                  separate from the
                                                  Authorization Service
                                                  that will be used
                                                  issue an access token
                                                  to the client. The use
                                                  case also requires
                                                  that as part of
                                                  authorization, the
                                                  client provides to the
                                                  Authorization Service
                                                  an authentication
                                                  token signed by an
                                                  Identity Provider that
                                                  the Authorization
                                                  Service has a trust
                                                  relationship with. The
                                                  trust relationship is
                                                  verifiable based on
                                                  the Authorization
                                                  Service having
                                                  recorded the public
                                                  keys or certificates
                                                  of trusted Identity
                                                  Providers in a trust
                                                  store, this allowing
                                                  the Authorization
                                                  Service to verify an
                                                  Identity Provider’s
                                                  signature on an
                                                  authentication token.

                                              

                                                

                                              

                                                 

                                              

                                                In looking at the
                                                various OAuth RFCs,
                                                particularly RFCs 7521,
                                                7522, and 7523, I see
                                                that they get me close
                                                in terms of supporting
                                                the use case. What is
                                                missing is a means for
                                                solving the following
                                                problem. These RFCs
                                                require that the
                                                Identity Provider put an
                                                Audience claim in the
                                                authentication token.
                                                The problem with this is
                                                that I do not see in the
                                                RFCs how the Identity
                                                Provider can be told who
                                                the Audience is to put
                                                into the authentication
                                                token. This leads me to
                                                the title of this
                                                message. The draft
                                                “OAuth 2.0 Token
                                                Exchange: An STS for the
                                                REST of Us†defines a
                                                mechanism for
                                                identifying the Audience
                                                for an STS to put into a
                                                token it generates. That
                                                would solve my problem
                                                except that the draft
                                                limits the type of STS
                                                to being Authorization
                                                Servers. What is needed
                                                is this same capability
                                                for interacting with an
                                                Identity Provider. This
                                                would enable RFCs 7521,
                                                7522 and 7523 to be
                                                useful in situation
                                                where the Identity
                                                Provider needs to be
                                                told the identity of the
                                                Authorization Service.

                                              

                                                 

                                              

                                                I am new to interacting
                                                with the IETF. I also am
                                                not an expert on the
                                                RFCs or prior history of
                                                the OAuth group relative
                                                to this topic, so please
                                                point me to any existing
                                                solution if this is a
                                                solved problem.
                                                Otherwise, I would like
                                                to get feedback on my
                                                suggestion.

                                              

                                                 

                                              

                                                Thanks You,

                                              

                                                

                                              

                                              

                                                Andrew Fregly

                                              

                                                Verisign Inc.

                                            

                                            

                                            

                                            _______________________________________________

                                            OAuth mailing
                                              list

                                            OAuth@ietf.org

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

                                        

                                      

                                      

                                    

                                  

                                

                              

                            

                          

                          

                          

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


  


--------------040709090904000307030209--


From nobody Wed Apr 20 10:48:41 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3710C12E23A for ; Wed, 20 Apr 2016 10:48:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1JSK-HTMOS6 for ; Wed, 20 Apr 2016 10:48:37 -0700 (PDT)
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 E358612D81C for ; Wed, 20 Apr 2016 10:48:36 -0700 (PDT)
Received: by mail-oi0-x261.google.com with SMTP id u67so3315328oia.1 for ; Wed, 20 Apr 2016 10:48:36 -0700 (PDT)
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:user-agent :mime-version; bh=6lefrUHvYkbdaoD9YV1zSf3fk3/scglMA33WJob+k68=; b=oNKDIh4Ayxf0bddSJuuGd+NVF036Y54u0KCqejTD+rrKVhtIl0ntmAnxQLRXSy6iRU zdH7blcnk8eLzYo0qYY8x5zKmrJBbhMghNYglaG8jgp7lVf2lui6LCnnELYaSq0AOcnK mNp4WSNpW1Dl8hdMnwuHWR1WHBET9vDwPWwgL00AtCReDr/qn81J537tEe+R0K03iXBU WC6lTAaYNq4vYh25uiZrnHtfVRmcNrSs7rkWb1RNrS9vyU9q7bo24U/WQ9PQY9jqADJF nzYsWLV/8FltMHxptM1cacmdfj/3XGKiem08qWeqtGxShd78QM39yjwPtVC8EKw3ujOZ NZ1A==
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 :user-agent:mime-version; bh=6lefrUHvYkbdaoD9YV1zSf3fk3/scglMA33WJob+k68=; b=M9iZO+p/SkyXox1p41mJ6R8EH/uwjZLLNP4UK1Nh8uPO12+ah1KI6WeegZrxKT2yJh Nz3YcW207KgLbZDez13LIv/g/FJY9NmHTfb6Hj4be83avYZtVMflSDXG1zhCtB+6aV6K Yqbbga6tLc2+PtH6N/XKPxCgIXW74ZmRioGOgyWveoy+cV1LXSQjjuX0xFFBV0XEVYRU QZF8p1I0cqNGNDSGEPJFFseB9pT4HnQDfkKrGSDIQ+ASIkhnaS1+q9l5/xnccBq2Fc7N ZYPwA+Zlz2r0Bqs3+YLFub96JUAqPkmX8Go6kZWN7IETt70EHwlmozawR0MtMyBXhb/6 TShA==
X-Gm-Message-State: AOPr4FVrPDIxw2Q1l+dhHHc0uZLHKxGReaIgpIE9ZE5Yc7XUf12/G0ktohDg7PKHJQQ/QohKzucu5q9bv5gb2Ty6Ft1JWmWt
X-Received: by 10.55.39.149 with SMTP id n143mr13262106qkn.55.1461174516087; Wed, 20 Apr 2016 10:48:36 -0700 (PDT)
Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id u71sm1269974qku.8.2016.04.20.10.48.35 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 20 Apr 2016 10:48:36 -0700 (PDT)
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 u3KHmZWe026312 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Apr 2016 13:48:35 -0400
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 20 Apr 2016 13:48:34 -0400
From: "Fregly, Andrew" 
To: George Fletcher , John Bradley , "oauth@ietf.org" 
Thread-Topic: =?utf-8?B?W09BVVRILVdHXSBCdWlsZGluZyBvbiB0aGUgcHJvdG9jb2wgaW4gdGhlIGRy?= =?utf-8?B?YWZ0IOKAnE9BdXRoIDIuMCBUb2tlbiBFeGNoYW5nZTogQW4gU1RTIGZvciB0?= =?utf-8?B?aGUgUkVTVCBvZiBVc+KAnSB0byBpbmNsdWRlIEF1dGhlbnRpY2F0aW9uIFRv?= =?utf-8?Q?kens?=
Thread-Index: AQHRmnitgCv5cI6zuEydb4HTyF4ZfZ+RycMAgAFKdgD//9lbgIAAduEA///AUQA=
Date: Wed, 20 Apr 2016 17:48:34 +0000
Message-ID: 
References:   <8B748252-9AE2-4824-923B-00CD46CB8D68@verisign.com> <571692A1.5070000@aol.com> <6101D0EB-E04B-4574-8899-ED8F4E631D67@verisign.com> <57177AD0.1090300@aol.com>  <5717BE1E.8070007@aol.com>
In-Reply-To: <5717BE1E.8070007@aol.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.160212
x-originating-ip: [10.173.152.4]
Content-Type: multipart/alternative; boundary="_000_F56B643467B14263B46742BDC940B14Bverisigncom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] =?utf-8?q?Building_on_the_protocol_in_the_draft_?= =?utf-8?q?=E2=80=9COAuth_2=2E0_Token_Exchange=3A_An_STS_for_the_REST_of_U?= =?utf-8?q?s=E2=80=9D_to_include_Authentication_Tokens?=
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Apr 2016 17:48:40 -0000

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

QWxsLA0KDQpJIHdpbGwgY29tZSB1cCB3aXRoIGEgY29uc2lkZXJlZCByZXNwb25zZSB0byB0aGlz
IGJ5IHRvbW9ycm93IHNvbWUgdGltZS4gVGhpcyBpbnRlcmFjdGlvbiBoYXMgYmVlbiBleHRyZW1l
bHkgaGVscGZ1bCENCg0KQW5keQ0KDQpGcm9tOiBHZW9yZ2UgRmxldGNoZXIgPGdmZmxldGNoQGFv
bC5jb208bWFpbHRvOmdmZmxldGNoQGFvbC5jb20+Pg0KT3JnYW5pemF0aW9uOiBBT0wgTExDDQpE
YXRlOiBXZWRuZXNkYXksIEFwcmlsIDIwLCAyMDE2IGF0IDE6MzYgUE0NClRvOiBBbmRyZXcgRnJl
Z2x5IDxhZnJlZ2x5QHZlcmlzaWduLmNvbTxtYWlsdG86YWZyZWdseUB2ZXJpc2lnbi5jb20+Piwg
Sm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+
PiwgIm9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4iIDxvYXV0aEBpZXRmLm9y
ZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQnVpbGRp
bmcgb24gdGhlIHByb3RvY29sIGluIHRoZSBkcmFmdCDigJxPQXV0aCAyLjAgVG9rZW4gRXhjaGFu
Z2U6IEFuIFNUUyBmb3IgdGhlIFJFU1Qgb2YgVXPigJ0gdG8gaW5jbHVkZSBBdXRoZW50aWNhdGlv
biBUb2tlbnMNCg0KSGkgQW5keSwNCg0KR2xhZCBJIGd1ZXNzZWQgY29ycmVjdGx5OikgSWYgdGhl
cmUgYXJlIG5ldHdvcmsgb3Igb3RoZXIgbGltaXRhdGlvbnMgaW4gaG93IHRoZSBjbGllbnQgZ2V0
cyBhbmQgdXNlcyB0b2tlbnMsIHRoYXQgd291bGQgYmUgaGVscGZ1bCBpbiBhIGRpYWdyYW0gc2Vu
c2UuIEFzIEpvaG4gcG9pbnRzIG91dCBpbiBoaXMgcmVzcG9uc2UsIG5vdCBoYXZpbmcgYW4gYXVk
aWVuY2UgaGFzIHBvc3NpYmxlIHNlY3VyaXR5IGltcGxpY2F0aW9ucy4NCg0KSWYgSSdtIGZvbGxv
d2luZyB5b3VyIG9yaWdpbmFsIHRoaW5raW5nLi4uIGl0IGdvZXMgc29tZXRoaW5nIGxpa2UgdGhp
cy4uLg0KDQoxLiBNb2JpbGUgYXBwIGFza3MgdXNlcnMgdG8gYXV0aGVudGljYXRlIGF0ICJ0aGVp
ciIgSWRQDQoyLiBNb2JpbGUgYXBwIGdldHMgYmFjayAiYXV0aGVudGljYXRpb24gdG9rZW4iIChs
aWtlbHkgc29tZSBzb3J0IG9mIFNBTUwgYXNzZXJ0aW9uKQ0KMy4gTW9iaWxlIGFwcCBwcmVzZW50
cyAiYXV0aGVudGljYXRpb24gdG9rZW4iIHRvIEF1dGhvcml6YXRpb24gU2VydmljZQ0KNC4gQXV0
aG9yaXphdGlvbiBTZXJ2aWNlIHZhbGlkYXRlICJhdXRoZW50aWNhdGlvbiB0b2tlbiIgYW5kIHJl
dHVybnMgYW4gYWNjZXNzX3Rva2VuDQo1LiBNb2JpbGUgYXBwIGludm9rZXMgZGF0YSBwcm92aWRl
ciBwYXNzaW5nIHRoZSBhY2Nlc3NfdG9rZW4NCjYuIERhdGEgcHJvdmlkZXIgdmFsaWRhdGVzIGFj
Y2Vzc190b2tlbiAoZWl0aGVyIGxvY2FsbHkgb3IgdmlhIGFuIGludHJvc3BlY3Rpb24gZW5kcG9p
bnQgb24gdGhlIEFTKQ0KDQpJbiB0aGlzIGZsb3cgdGhlcmUgYXJlIHJlYWxseSB0d28gdG9rZW5z
OiB0aGUgImF1dGhlbnRpY2F0aW9uIHRva2VuIiBhbmQgdGhlIGFjY2Vzc190b2tlbi4gVGhlcmUg
c2hvdWxkIGJlIGFuIGF1ZGllbmNlIGZvciBib3RoIHRva2Vucy4gVGhlIGF1ZGllbmNlIG9mIHRo
ZSAiYXV0aGVudGljYXRpb24gdG9rZW4iIHNob3VsZCBiZSB0aGUgQVMsIGFuZCB0aGUgYXVkaWVu
Y2Ugb2YgdGhlIGFjY2Vzc190b2tlbiBzaG91bGQgYmUgdGhlIGRhdGEgcHJvdmlkZXIgdGhlIGNs
aWVudCBpcyBnb2luZyB0byB1c2UuDQoNClNvLCBpZiB0aGVyZSBhcmUgbm8gbmV0d29yayBmaXJl
d2FsbCB0eXBlIGxpbWl0YXRpb25zLCBpdCBzZWVtcyBtdWNoIHNpbXBsZXIgdG8ganVzdCBoYXZl
IHRoZSBBUyB1c2UgdGhlIGV4dGVybmFsIElkUHMgYXMgaXQncyBhdXRoZW50aWNhdGlvbiBtZWNo
YW5pc21zIGFuZCB0aGUgcmVzdCBpcyBqdXN0IGRlZmF1bHQgT3BlbklEIENvbm5lY3QuIE1lYW5p
bmcgdGhhdCB0aGUgTW9iaWxlIGFwcCBzdGFydHMgYW4gT3BlbklEIENvbm5lY3QgZmxvdyB3aXRo
IHRoZSBBUywgdGhlIEFTIGdldCB0aGUgdXNlciBhdXRoZW50aWNhdGVkIHZpYSB0aGUgdXNlcidz
IElkUCwgdGhlIEFTIHByb3ZpZGVzIGFjY2VzcyBhbmQgaWQgdG9rZW5zIGJhc2sgdG8gdGhlIE1v
YmlsZSBhcHAgKGZvbGxvd2luZyB0aGUgY29kZSBvciBvdGhlciBmbG93KS4NCg0KQW0gSSBtaXNz
aW5nIHNvbWV0aGluZz8NCg0KVGhhbmtzLA0KR2VvcmdlDQoNCk9uIDQvMjAvMTYgMTA6MzEgQU0s
IEZyZWdseSwgQW5kcmV3IHdyb3RlOg0KSGkgR2VvcmdlLA0KDQpZb3UgZnVsbHkgY2FwdHVyZWQg
b25lIG9mIHRoZSBvcHRpb25zIHdlIGhhdmUgYmVlbiBjb250ZW1wbGF0aW5nLiBJIGRpZG7igJl0
IHByb3Bvc2UgdGhpcyBmbG93IGJlY2F1c2UgSSB3YXMgbG9va2luZyBmb3IgYSB3YXkgdG8gc29s
dmUgb3VyIG91ciB1c2UgY2FzZSBiYXNlZCBvbiB0aGUgZXhpc3RpbmcgUkZDcyBhbmQgT3BlbklE
IENvbm5lY3Qgc3BlY2lmaWNhdGlvbnMgd2l0aCBtaW5pbWFsIG5ldyBzcGVjaWZpY2F0aW9uIHJl
cXVpcmVkLiBUaGF0IGxlZCBtZSB0byB0aGUgcGF0aCBkZXNjcmliZWQgaW4gdGhlIGVtYWlsIHJl
c3BvbnNlIEkgc2VudCBvdXQgYSBsaXR0bGUgd2hpbGUgYWdvIHRvIE5hdCBTYWtpbXVyYeKAmXMg
cmVzcG9uc2UuIFBsZWFzZSB0YWtlIGEgbG9vayBhdCB0aGF0IGVtYWlsIGFuZCBzZWUgd2hhdCB5
b3UgdGhpbmsuDQoNCkdpdmVuIGhvdyB3ZWxsIHN0YXRlZCB5b3VyIHN1bW1hcnkgb2Ygb3VyIG5l
ZWRzIHdhcywgZG8geW91IHN0aWxsIHdhbnQgbWUgdG8gcHJvdmlkZSBhIGRpYWdyYW0/DQoNClRo
YW5rcywNCiAgICBBbmR5DQoNCkZyb206IEdlb3JnZSBGbGV0Y2hlciA8Z2ZmbGV0Y2hAYW9sLmNv
bTxtYWlsdG86Z2ZmbGV0Y2hAYW9sLmNvbT4+DQpPcmdhbml6YXRpb246IEFPTCBMTEMNCkRhdGU6
IFdlZG5lc2RheSwgQXByaWwgMjAsIDIwMTYgYXQgODo0OSBBTQ0KVG86IEFuZHJldyBGcmVnbHkg
PDxtYWlsdG86YWZyZWdseUB2ZXJpc2lnbi5jb20+YWZyZWdseUB2ZXJpc2lnbi5jb208bWFpbHRv
OmFmcmVnbHlAdmVyaXNpZ24uY29tPj4sIEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208
bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4sICI8bWFpbHRvOm9hdXRoQGlldGYub3JnPm9hdXRo
QGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4iIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86
b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQnVpbGRpbmcgb24gdGhl
IHByb3RvY29sIGluIHRoZSBkcmFmdCDigJxPQXV0aCAyLjAgVG9rZW4gRXhjaGFuZ2U6IEFuIFNU
UyBmb3IgdGhlIFJFU1Qgb2YgVXPigJ0gdG8gaW5jbHVkZSBBdXRoZW50aWNhdGlvbiBUb2tlbnMN
Cg0KSSBzaG91bGQgcHJvYmFibHkganVzdCB3YWl0IGZvciB0aGUgZGlhZ3JhbS4uLiBidXQgbm90
IHdhbnRpbmcgdG8gd2FpdC4uLiA6KQ0KDQpJZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5LCB0aGUg
dXNlciBpcyBnb2luZyB0byB1c2UgYSBjbGllbnQgYW5kIHRoZSBjbGllbnQgd2lsbCBhdXRoZW50
aWNhdGUgdGhlIHVzZXIgdmlhIHNvbWUgSWRQIHVzaW5nIGFuIGV4aXN0aW5nIG1ldGhvZCAoU0FN
TCwgTERBUCAoPyksIE9wZW5JRCBDb25uZWN0LCBldGMpLiBUaGUgZGVzaXJlIGlzIHRvIHRha2Ug
dGhhdCByZXNwb25zZSBhbmQgaW4gc29tZSB3YXkgcHJlc2VudCBpdCB0byBhbiAiQXV0aG9yaXph
dGlvbiBTZXJ2ZXIiIHdoaWNoIHdpbGwgdmFsaWRhdGUgdGhlICJhdXRoZW50aWNhdGlvbiByZXNw
b25zZSIgYW5kIHJldHVybiBhbiBhY2Nlc3MgdG9rZW4gZm9yIHVzZSBhdCB0aGUgZGF0YSBwcm92
aWRlcihzKS4NCg0KV2hhdCBpZiB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgYWxzbyB0b29rIG9u
IHRoZSByb2xlIG9mIHRoZSBPcGVuSUQgQ29ubmVjdCBwcm92aWRlci4gVGhpcyBjb3VsZCB3b3Jr
IGJ5IGhhdmluZyB0aGUgY2xpZW50IHN0YXJ0IGFuIE9wZW5JRCBDb25uZWN0IGZsb3cgd2l0aCBB
dXRob3JpemF0aW9uIFNlcnZlciAoaGludHMgY291bGQgYmUgcHJvdmlkZWQgYXMgdG8gd2hpY2gg
SWRQIHRoZSB1c2VyIHdhbnRzIHRvIGF1dGhlbnRpY2F0ZSBhdCkuIFRoZSBBUyB3b3VsZCBsb29r
IGF0IHRoZSAiaWRwIGhpbnQiIGFuZCBlaXRoZXIgc3RhcnQgYW5kIFNQIFNBTUwgZmxvdywgb3Ig
cHJlc2VudCBVSSBmb3IgY29sbGVjdGluZyBMREFQIGNyZWRlbnRpYWxzIChJIGRvbid0IHJlY29t
bWVuZCB0aGlzKSBvciBjaGFpbiB0byBhbnkgb3RoZXIgcHJvcHJpZXRhcnkgSWRQIGZsb3cuIE9u
Y2UgdGhlIHVzZXIgc3VjY2Vzc2Z1bGx5IGF1dGhlbnRpY2F0ZXMgd2l0aCB0aGUgY29ycmVjdCBJ
ZFAsIHRoZSBBUyB3aWxsIGZpbmlzaCB0aGUgT3BlbklEIENvbm5lY3QgZmxvdyBhbGxvd2luZyB0
aGUgY2xpZW50IHRvIG9idGFpbiBhbiBhY2Nlc3MgdG9rZW4sIHJlZnJlc2ggdG9rZW4gYW5kIGlk
X3Rva2VuLiBUaGUgQVMgY291bGQgYWRkIHRvIHRoZSBpZF90b2tlbiBhIGNsYWltIHNwZWNpZnlp
bmcgd2hpY2ggSWRQIHRoZSB1c2VyIHVzZWQgZHVyaW5nIHRoZSBhdXRoZW50aWNhdGlvbiBwcm9j
ZXNzZWQuDQoNClRoZSBJZFAgdGhlIHVzZXIgdXNlZCBmb3IgYXV0aGVudGljYXRpb24gY291bGQg
YWxzbyBiZSBlbmNvZGVkIGluIHRoZSBhY2Nlc3NfdG9rZW4gKG9yIHJldHVybmVkIGFzIHBhcnQg
b2YgYW4gaW50cm9zcGVjdGlvbiBjYWxsKS4NCg0KVGhpcyB3YXkgd2hldGhlciB0aGUgZGF0YSBw
cm92aWRlcnMgYXJlIHZhbGlkYXRpbmcgdGhlIGFjY2Vzc190b2tlbnMgbG9jYWxseSBvciB1c2lu
ZyBpbnRyb3NwZWN0aW9uIHRoZXkgY2FuIG9idGFpbiB0aGUgSWRQIHRoZSB1c2VyIHVzZWQgYW5k
IGFwcGx5IHRoZWlyIG93biBhdXRob3JpemF0aW9uIHJ1bGVzLg0KDQpUaGUgdXNlciBpcyBvbmx5
IHJlcXVpcmVkIHRvIGRvIG9uZSBhdXRob3JpemF0aW9uIGZsb3cgZm9yIHRoZSBjbGllbnQgdGhh
dCBpcyBtYW5hZ2VkIGJ5IHRoZSBBdXRob3JpemF0aW9uIFNlcnZlci4NCg0KVGhhbmtzLA0KR2Vv
cmdlDQoNCk9uIDQvMTkvMTYgNTowNiBQTSwgRnJlZ2x5LCBBbmRyZXcgd3JvdGU6DQpUaGFuayB5
b3UgZm9yIHlvdXIgcmVzcG9uc2UgR2VvcmdlLiBJdCBwb2ludHMgbWUgdG8gc29tZSBtb3JlIHJl
c2VhcmNoIHRvIGRvLCBzdWNoIGFzIGxvb2tpbmcgYXQgT3BlbklEIENvbm5lY3Qgc3VwcG9ydCBm
b3IgYm90aCBkaXN0cmlidXRlZCBhbmQgYWdncmVnYXRlZCBjbGFpbXMuDQoNCkJlbG93IGFyZSBy
ZXBsaWVzIHRvIHlvdXIgcXVlc3Rpb25zL2Fzc2VydGlvbnMgYmFzZWQgb24gbXkgY3VycmVudCB1
bmRlcnN0YW5kaW5nIG9mIHRoZSB2YXJpb3VzIHByb3RvY29scy4gRnVydGhlciByZXNlYXJjaCBh
bmQgYWR2aWNlIHdpbGwgbGlrZWx5IGVucmljaCB0aGlzIHNpZ25pZmljYW50bHkuDQoNClllcywg
d2hhdCBpcyByZXF1aXJlZCBpcyBhIHZlcmlmaWFibGUgY2xhaW0gdGhhdCB0aGUgdXNlciBpcyBz
dGlsbCBhIG1lbWJlciBvZiBTb21lT3JnIEluYy4gSSBoYXZlIGJlZW4gb3BlcmF0aW5nIHVuZGVy
IHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlIG9ubHkgd2F5IHRoaXMgY2FuIGJlIGRvbmUgd291bGQg
YmUgdG8gaGF2ZSB0aGUgdXNlciBhdXRoZW50aWNhdGVkIGJ5IHRoZSBJZGVudGl0eSBQcm92aWRl
ciBmb3IgU29tZU9yZy4gUGVyaGFwcyB0aGUgcmVzZWFyY2ggaW50byBPcGVuSUQgQ29ubmVjdCBz
dXBwb3J0IGZvciBkaXN0cmlidXRlZCBhbmQgYWdncmVnYXRlZCBjbGFpbXMgd2lsbCByZXZlYWwg
YW4gYWx0ZXJuYXRpdmUuIEkgZm9yZXNlZSBhIGNoYWxsZW5nZSBpbiBkZWFsaW5nIHdpdGggSWRl
bnRpdHkgUHJvdmlkZXLigJlzIGZvciBvcmdhbml6YXRpb25zIHVzaW5nIFNBTUwgYXNzZXJ0aW9u
cyBvbiB0b3Agb2YgQWN0aXZlIERpcmVjdG9yeSBhbmQgTERBUCwgYW5kIHdoaWNoIGFyZSBub3Qg
Z29pbmcgdG8gZG8gYW55IHVwZGF0aW5nIHRvIHN1cHBvcnQgb3VyIG5lZWRzLg0KDQpXZSBkbyBu
b3QgZXhwZWN0IHRoZSB1c2VyIHRvIGZpcnN0IGdvIHRvIHRoZSBkYXRhIHByb3ZpZGVyLiBXZSBh
bnRpY2lwYXRlIHRoYXQgdGhlIGNsaWVudCBhcHBsaWNhdGlvbiB3b3VsZCBwcm92aWRlIGEgQXV0
aGVudGljYXRpb24gVG9rZW4gdG8gYW4gIEF1dGhvcml6YXRpb24gU2VydmljZSBzZXJ2aWNlIHRo
YXQgdGhlbiBpc3N1ZXMgdG8gdGhlIGNsaWVudCBhbiBhY2Nlc3MgdG9rZW4gdGhhdCB0aGUgZGF0
YSBwcm92aWRlciB3aWxsIHRydXN0LiBPbmUgb2Ygb3VyIHJlYXNvbnMgZm9yIGRvaW5nIGl0IHRo
aXMgd2F5IGlzIHRoYXQgd2UgYXJlIHRyeWluZyB0byBlbGltaW5hdGUgcmVkaXJlY3RzIHRvIGVh
c2UgaW1wbGVtZW50YXRpb24gb2YgYSBuYXRpdmUgY2xpZW50LiBXZSBhcmUgdGhlcmVmb3JlIHJl
cXVpcmluZyB0aGUgY2xpZW50IHRvIGhhbmRsZSBhdXRoZW50aWNhdGlvbiB3aXRoIHRoZSBJZGVu
dGl0eSBQcm92aWRlciBhcyBhIHNlcGFyYXRlIHN0ZXAgZnJvbSBhdXRob3JpemF0aW9uLg0KDQpJ
dCBtaWdodCBoZWxwIGlmIEkgY2xhcmlmaWVkIHRoYXQgVmVyaXNpZ27igJlzIHJvbGUgaW4gdGhl
IHNjZW5hcmlvIEkgZGVzY3JpYmVkIGlzIHRvIGJlIGp1c3Qgb25lIG9mIG1hbnkgZGF0YSBwcm92
aWRlcnMuDQoNCkZyb206IEdlb3JnZSBGbGV0Y2hlciA8Z2ZmbGV0Y2hAYW9sLmNvbTxtYWlsdG86
Z2ZmbGV0Y2hAYW9sLmNvbT4+DQpPcmdhbml6YXRpb246IEFPTCBMTEMNCkRhdGU6IFR1ZXNkYXks
IEFwcmlsIDE5LCAyMDE2IGF0IDQ6MTggUE0NClRvOiBBbmRyZXcgRnJlZ2x5IDxhZnJlZ2x5QHZl
cmlzaWduLmNvbTxtYWlsdG86YWZyZWdseUB2ZXJpc2lnbi5jb20+PiwgSm9obiBCcmFkbGV5IDx2
ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PiwgIm9hdXRoQGlldGYu
b3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4iIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhA
aWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQnVpbGRpbmcgb24gdGhlIHByb3Rv
Y29sIGluIHRoZSBkcmFmdCDigJxPQXV0aCAyLjAgVG9rZW4gRXhjaGFuZ2U6IEFuIFNUUyBmb3Ig
dGhlIFJFU1Qgb2YgVXPigJ0gdG8gaW5jbHVkZSBBdXRoZW50aWNhdGlvbiBUb2tlbnMNCg0KU28g
aWYgSSB1bmRlcnN0YW5kIHRoaXMgY29ycmVjdGx5LCB3aGF0IGlzIHJlYWxseSByZXF1aXJlZCBp
cyBhIHZlcmlmaWFibGUgY2xhaW0gdGhhdCB0aGUgdXNlciBpcyBzdGlsbCBhIG1lbWJlciBvZiBT
b21lT3JnIEluYy4gT3BlbklEIENvbm5lY3Qgc3VwcG9ydHMgYm90aCBkaXN0cmlidXRlZCBhbmQg
YWdncmVnYXRlZCBjbGFpbXMgdGhhdCBjYW4gYmUgc2lnbmVkIGJ5IHRoZSBhcHByb3ByaWF0ZSBJ
ZGVudGl0eSBQcm92aWRlci4gVGhlIHBvaW50IGJlaW5nIHRoYXQgSSdtIG5vdCBzdXJlIGFuICJh
dXRoZW50aWNhdGlvbiB0b2tlbiIgaXMgcmVxdWlyZWQgZm9yIHRoaXMgdXNlIGNhc2UgdG8gc3Vj
Y2VlZCwgaXQncyBqdXN0IG9uZSBraW5kIG9mIHRva2VuIHRoYXQgY2FuIGJlIHVzZWQuDQoNCkFs
c28sIGlzIHRoZSBleHBlY3RlZCBmbG93IHRoYXQgdGhlIHVzZXIgd2lsbCBmaXJzdCBnbyB0byB0
aGUgZGF0YSBwcm92aWRlciBhbmQgdGhlbiBiZSBkaXJlY3RlZCBlbHNlIHdoZXJlIGZyb20gdGhl
cmU/IElmIHRoYXQgaXMgdGhlIGNhc2UsIHRoZSBkYXRhIHByb3ZpZGVyIGNhbiBqdXN0IGJlIGFu
IE9wZW5JRCBDb25uZWN0IHJlbHlpbmcgcGFydHkgYW5kIGdpdmUgdGhlIHVzZXIgYW4gb3B0aW9u
IG9mIHRoZSBsaXN0IG9mIHN1cHBvcnRlZCBJZFBzIHRvIGNob29zZSBmcm9tLiBUaGUgdXNlciB3
aWxsIHRoZW4gYmUgcmVkaXJlY3RlZCB0byBTb21lT3JnIEluYy4gSWRQLCBhdXRoZW50aWNhdGUg
YW5kIHRoZSBkYXRhIHByb3ZpZGVyIHdpbGwgaGF2ZSB0aGUgYXV0aG9yaXphdGlvbiBhbmQgcmVj
ZW50IGF1dGhlbnRpY2F0aW9uIHRoZXkgY2FuIHZhbGlkYXRlLg0KDQpJcyB0aGUgdXNlci9kYXRh
IGZsb3cgbW9yZSBjb21wbGljYXRlZCB0aGFuIHRoaXM/DQoNClRoYW5rcywNCkdlb3JnZQ0KDQpP
biA0LzE5LzE2IDQ6MDUgUE0sIEZyZWdseSwgQW5kcmV3IHdyb3RlOg0KVGhhbmtzIGZvciB5b3Vy
IHJlc3BvbnNlIEpvaG4uIEkgYWxzbyBnb3QgYSBnb29kIHJlc3BvbnNlIGZyb20gQnJpYW4gQ2Ft
cGJlbGwgYW5kIGFwcHJlY2lhdGUgdGhhdC4gSSB3aWxsIHJlc3BvbmQgc2VwYXJhdGVseSB0byBC
cmlhbuKAmXMgcmVzcG9uc2UgYXMgSSB0aGluayBpdCB3b3VsZCBrZWVwIHRoaW5ncyBjbGVhcmVy
IHRvIGRvIHRoYXQuDQoNClRoZSBwcm9ibGVtIHdlIGhhdmUgZm9yIHVzaW5nIE9wZW5JRCBDb25u
ZWN0IGlzIHRoYXQgaXQgY29tYmluZXMgdGhlIHJvbGUgb2YgQXV0aGVudGljYXRpb24gU2Vydmlj
ZSB3aXRoIHRoZSByb2xlIG9mIEF1dGhvcml6YXRpb24gU2VydmljZS4gUGVyaGFwcyB0aGUgZm9s
bG93aW5nIGRlc2NyaXB0aW9uIG9mIHdoYXQgd2Ugd2FudCB0byBkbyB3aWxsIGNsYXJpZnkgd2h5
IHRoaXMgd29u4oCZdCB3b3JrIGZvciB1czoNCg0KVGhlIGJhc2ljIHByb2JsZW0gc3RhdGVtZW50
IGlzIHRoYXQgd2UgbmVlZCB0byBoYXZlIGEgY2xpZW50IGFwcGxpY2F0aW9uIGF1dGhvcml6ZWQg
YnkgYSBTZXJ2aWNlIFByb3ZpZGVyIGJhc2VkIG9uIHByb29mIHRoYXQgYSB1c2VyIGlzIGN1cnJl
bnRseSBhIG1lbWJlciBvZiBzb21lIG9yZ2FuaXphdGlvbi4gVGhpcyBhc3N1bWVzIHRoZSBvcmdh
bml6YXRpb24gaGFzIHByZXZpb3VzbHkgZXN0YWJsaXNoZWQgc29tZSBsZXZlbCBvZiBhdXRob3Jp
emVkIGFjY2VzcyB3aXRoIHRoZSBTZXJ2aWNlIFByb3ZpZGVyLg0KDQpIZXJlIGlzIGFuIGV4YW1w
bGU6IFN1cHBvc2UgSSBhbSBhIG1lbWJlciBvZiBTb21lT3JnIEluYy4gU3VwcG9zZSBTb21lT3Jn
IEluYy4gaXMgZG9pbmcgcmVzZWFyY2ggdGhhdCByZXF1aXJlcyBpdCB0byBnYXRoZXIgZGF0YSBv
dmVyIHRoZSBJbnRlcm5ldCBmcm9tIGEgbnVtYmVyIG9mIGRhdGEgcHJvdmlkZXJzLiBUaGUgZGF0
YSBwcm92aWRlcnMgcmVxdWlyZSBhdXRoZW50aWNhdGlvbiBhbmQgcHJvb2Ygb2Ygb3JnYW5pemF0
aW9uYWwgbWVtYmVyc2hpcCBpbiBvcmRlciB0byBhdXRob3JpemUgdmFyaW91cyBsZXZlbHMgb2Yg
YWNjZXNzIHRvIHRoZWlyIGRhdGEuIFRoZSBkYXRhIHByb3ZpZGVycyBkbyBub3QgY29uc2lkZXIg
aGF2aW5nIGFuIGFjY291bnQgd2l0aCB0aGVtIG9yIGEgUHVibGljIElkZW50aXR5IFByb3ZpZGVy
IHRvIGJlIHN1aXRhYmxlIGZvciBwcm92aW5nIHRoYXQgSSBhbSBzdGlsbCBhIG1lbWJlciBvZiBT
b21lT3JnIGF0IHRpbWUgb2YgYXV0aGVudGljYXRpb24uIFRoZXkgd291bGQgaGF2ZSBubyB3YXkg
b2Yga25vd2luZyB3aGV0aGVyIG9yIG5vdCBteSByZWxhdGlvbnNoaXAgd2l0aCBTb21lT3JnIHN0
aWxsIGV4aXN0cyBhdCB0aGF0IHRpbWUuIFRoZSBkYXRhIHByb3ZpZGVycyB3b3VsZCB0aGVyZWZv
cmUgbGlrZSB0aGUgQ2xpZW50IHNvZnR3YXJlIHRvIGF1dGhlbnRpY2F0ZSBtZSBhZ2FpbnN0IFNv
bWVPcmdzIElkZW50aXR5IFByb3ZpZGVyLiBUaGlzIHdvdWxkIGJlIGdvb2QgcHJvb2YgdGhhdCBJ
IGFtIHN0aWxsIGEgbWVtYmVyIG9mIFNvbWVPcmcgYXQgdGhlIHRpbWUgSSBhdXRoZW50aWNhdGUu
IFRoaXMgYXV0aGVudGljYXRpb24gd291bGQgZW5hYmxlIHRoZSBkYXRhIHByb3ZpZGVycyBBdXRo
b3JpemF0aW9uIFNlcnZlciB0byBncmFudCBtZSBhY2Nlc3MgYXBwcm9wcmlhdGUgdG8gYSBtZW1i
ZXIgb2YgU29tZU9yZy4gIE5vdGUgdGhhdCBhcyBhIHByZXJlcXVpc2l0ZSB0byBhbGwgb2YgdGhp
cywgU29tZU9yZyB3aWxsIGhhdmUgdXNlZCBhbiBvdXQtb2YtYmFuZCBwcm9jZXNzIHRvIHNldCB1
cCBhIHRydXN0IHJlbGF0aW9uc2hpcCBmb3IgU29tZU9yZydzIElkZW50aXR5IFByb3ZpZGVyIHdp
dGggdGhlIGRhdGEgcHJvdmlkZXLigJlzIEF1dGhvcml6YXRpb24gU2VydmljZSwgYW5kIHdpbGwg
aGF2ZSBuZWdvdGlhdGVkIGF1dGhvcml6YXRpb24gY2xhaW1zIHRvIGJlIGdyYW50ZWQgdG8gU29t
ZU9yZ3MgbWVtYmVycy4NCg0KV2hhdCBJIGFtIGhhdmluZyBkaWZmaWN1bHR5IHdpdGggaXMgaW4g
a25pdHRpbmcgdG9nZXRoZXIgYW4gYXBwcm9hY2ggYmFzZWQgb24gdGhlIGhlIE9wZW5JRCBDb25u
ZWN0IHNwZWNpZmljYXRpb25zLCBTQU1MIHNwZWNpZmljYXRpb25zLCBhbmQgT0F1dGggUkZDcyBh
bmQgZHJhZnRzIGluIGEgd2F5IHRoYXQgc3VwcG9ydHMgdGhlIGFib3ZlIHVzZSBjYXNlIGVuZC10
by1lbmQuIFRoZSBPQXV0aCBSRkNzIGFuZCBkcmFmdHMgYWxtb3N0IGdldCBtZSB0aGVyZS4gV2hh
dCBzZWVtcyB0byBiZSBtaXNzaW5nIGlzIGEgd2F5IG9mIHRlbGxpbmcgYW4gSWRlbnRpdHkgUHJv
dmlkZXIgdGhlIFVSTCBmb3IgdGhlIEF1dGhvcml6YXRpb24gU2VydmljZSAodGhlIHJlcXVpcmVk
IEF1ZGllbmNlIGNsYWltIGluIGFuIGF1dGhlbnRpY2F0aW9uIGFzc2VydGlvbiBhcyBkZWZpbmVk
IGluIFJGQ3MgNzI1MSwgNzI1MiBhbmQgNzI1MyksIGFuZCB0aGVuIGEgcmVxdWlyZW1lbnQgdGhh
dCB0aGUgSWRlbnRpdHkgUHJvdmlkZXJzIHB1dCB0aGUgc3VwcGxpZWQgQXVkaWVuY2UgSWRlbnRp
ZmllciBpbnRvIEF1dGhlbnRpY2F0aW9uIFRva2Vucy4gUGVyaGFwcyBhIGxpdHRsZSBmdXJ0aGVy
IGJhY2stYW5kLWZvcnRoIHdpdGggQnJpYW4gd2lsbCByZXNvbHZlIHRoaXMuDQoNCkkgY2FuIGdv
IGludG8gZGVlcGVyIGRldGFpbCBpZiBuZWVkZWQuIElmIHRoaXMgaXMgb2ZmLXRvcGljIGZvciB0
aGUgT0F1dGggd29ya2luZyBncm91cCwgbGV0IG1lIGtub3cuDQoNClRoYW5rcywNCkFuZHJldyBG
cmVnbHkNClZlcmlzaWduIEluYy4NCg0KDQpGcm9tOiBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdq
dGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBBcHJpbCAx
OSwgMjAxNiBhdCAyOjA2IFBNDQpUbzogQW5kcmV3IEZyZWdseSA8YWZyZWdseUB2ZXJpc2lnbi5j
b208bWFpbHRvOmFmcmVnbHlAdmVyaXNpZ24uY29tPj4NCkNjOiAiPG1haWx0bzpvYXV0aEBpZXRm
Lm9yZz5vYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IiA8b2F1dGhAaWV0Zi5v
cmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEJ1aWxk
aW5nIG9uIHRoZSBwcm90b2NvbCBpbiB0aGUgZHJhZnQg4oCcT0F1dGggMi4wIFRva2VuIEV4Y2hh
bmdlOiBBbiBTVFMgZm9yIHRoZSBSRVNUIG9mIFVz4oCdIHRvIGluY2x1ZGUgQXV0aGVudGljYXRp
b24gVG9rZW5zDQoNCkxvb2tpbmcgYXQgT3BlbklEIENvbm5lY3QgYW5kIGl04oCZcyB0cnVzdCBt
b2RlbCBmb3IgcHJvZHVjaW5nIGlkX3Rva2VucyB0aGF0IGFzc2VydCBpZGVudGl0eSBtYXkgaGVs
cCB5b3UuDQo8aHR0cDovL29wZW5pZC5uZXQvd2cvY29ubmVjdC8+aHR0cDovL29wZW5pZC5uZXQv
d2cvY29ubmVjdC8NCg0KVW5mb3J0dW5hdGVseSBJIGNhbuKAmXQgcXVpdGUgbWFrZSBvdXQgd2hh
dCB5b3UgYXJlIHRyeWluZyB0byBkby4NCg0KSXQgc29ydCBvZiBzb3VuZHMgbGlrZSB5b3Ugd2Fu
dCBhbiBpZF90b2tlbiBmcm9tIGEgaWRQIGFuZCB0aGVuIGhhdmUgdGhlIGNsaWVudCBleGNoYW5n
ZSB0aGF0IGFzc2VydGlvbiBmb3IgYW5vdGhlciB0b2tlbj8NCg0KSm9obiBCLg0KT24gQXByIDE5
LCAyMDE2LCBhdCAxOjE4IFBNLCBGcmVnbHksIEFuZHJldyA8PG1haWx0bzphZnJlZ2x5QHZlcmlz
aWduLmNvbT5hZnJlZ2x5QHZlcmlzaWduLmNvbTxtYWlsdG86YWZyZWdseUB2ZXJpc2lnbi5jb20+
PiB3cm90ZToNCg0KSSBoYXZlIGEgdXNlIGNhc2Ugd2hlcmUgYSBjbGllbnQgYXBwbGljYXRpb24g
bmVlZHMgdG8gYXV0aGVudGljYXRlIHdpdGggYSBkeW5hbWljYWxseSBkZXRlcm1pbmVkIElkZW50
aXR5IFByb3ZpZGVyIHRoYXQgaXMgc2VwYXJhdGUgZnJvbSB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2
aWNlIHRoYXQgd2lsbCBiZSB1c2VkIGlzc3VlIGFuIGFjY2VzcyB0b2tlbiB0byB0aGUgY2xpZW50
LiBUaGUgdXNlIGNhc2UgYWxzbyByZXF1aXJlcyB0aGF0IGFzIHBhcnQgb2YgYXV0aG9yaXphdGlv
biwgdGhlIGNsaWVudCBwcm92aWRlcyB0byB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2aWNlIGFuIGF1
dGhlbnRpY2F0aW9uIHRva2VuIHNpZ25lZCBieSBhbiBJZGVudGl0eSBQcm92aWRlciB0aGF0IHRo
ZSBBdXRob3JpemF0aW9uIFNlcnZpY2UgaGFzIGEgdHJ1c3QgcmVsYXRpb25zaGlwIHdpdGguIFRo
ZSB0cnVzdCByZWxhdGlvbnNoaXAgaXMgdmVyaWZpYWJsZSBiYXNlZCBvbiB0aGUgQXV0aG9yaXph
dGlvbiBTZXJ2aWNlIGhhdmluZyByZWNvcmRlZCB0aGUgcHVibGljIGtleXMgb3IgY2VydGlmaWNh
dGVzIG9mIHRydXN0ZWQgSWRlbnRpdHkgUHJvdmlkZXJzIGluIGEgdHJ1c3Qgc3RvcmUsIHRoaXMg
YWxsb3dpbmcgdGhlIEF1dGhvcml6YXRpb24gU2VydmljZSB0byB2ZXJpZnkgYW4gSWRlbnRpdHkg
UHJvdmlkZXLigJlzIHNpZ25hdHVyZSBvbiBhbiBhdXRoZW50aWNhdGlvbiB0b2tlbi4NCg0KSW4g
bG9va2luZyBhdCB0aGUgdmFyaW91cyBPQXV0aCBSRkNzLCBwYXJ0aWN1bGFybHkgUkZDcyA3NTIx
LCA3NTIyLCBhbmQgNzUyMywgSSBzZWUgdGhhdCB0aGV5IGdldCBtZSBjbG9zZSBpbiB0ZXJtcyBv
ZiBzdXBwb3J0aW5nIHRoZSB1c2UgY2FzZS4gV2hhdCBpcyBtaXNzaW5nIGlzIGEgbWVhbnMgZm9y
IHNvbHZpbmcgdGhlIGZvbGxvd2luZyBwcm9ibGVtLiBUaGVzZSBSRkNzIHJlcXVpcmUgdGhhdCB0
aGUgSWRlbnRpdHkgUHJvdmlkZXIgcHV0IGFuIEF1ZGllbmNlIGNsYWltIGluIHRoZSBhdXRoZW50
aWNhdGlvbiB0b2tlbi4gVGhlIHByb2JsZW0gd2l0aCB0aGlzIGlzIHRoYXQgSSBkbyBub3Qgc2Vl
IGluIHRoZSBSRkNzIGhvdyB0aGUgSWRlbnRpdHkgUHJvdmlkZXIgY2FuIGJlIHRvbGQgd2hvIHRo
ZSBBdWRpZW5jZSBpcyB0byBwdXQgaW50byB0aGUgYXV0aGVudGljYXRpb24gdG9rZW4uIFRoaXMg
bGVhZHMgbWUgdG8gdGhlIHRpdGxlIG9mIHRoaXMgbWVzc2FnZS4gVGhlIGRyYWZ0IOKAnE9BdXRo
IDIuMCBUb2tlbiBFeGNoYW5nZTogQW4gU1RTIGZvciB0aGUgUkVTVCBvZiBVc+KAnSBkZWZpbmVz
IGEgbWVjaGFuaXNtIGZvciBpZGVudGlmeWluZyB0aGUgQXVkaWVuY2UgZm9yIGFuIFNUUyB0byBw
dXQgaW50byBhIHRva2VuIGl0IGdlbmVyYXRlcy4gVGhhdCB3b3VsZCBzb2x2ZSBteSBwcm9ibGVt
IGV4Y2VwdCB0aGF0IHRoZSBkcmFmdCBsaW1pdHMgdGhlIHR5cGUgb2YgU1RTIHRvIGJlaW5nIEF1
dGhvcml6YXRpb24gU2VydmVycy4gV2hhdCBpcyBuZWVkZWQgaXMgdGhpcyBzYW1lIGNhcGFiaWxp
dHkgZm9yIGludGVyYWN0aW5nIHdpdGggYW4gSWRlbnRpdHkgUHJvdmlkZXIuIFRoaXMgd291bGQg
ZW5hYmxlIFJGQ3MgNzUyMSwgNzUyMiBhbmQgNzUyMyB0byBiZSB1c2VmdWwgaW4gc2l0dWF0aW9u
IHdoZXJlIHRoZSBJZGVudGl0eSBQcm92aWRlciBuZWVkcyB0byBiZSB0b2xkIHRoZSBpZGVudGl0
eSBvZiB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2aWNlLg0KDQpJIGFtIG5ldyB0byBpbnRlcmFjdGlu
ZyB3aXRoIHRoZSBJRVRGLiBJIGFsc28gYW0gbm90IGFuIGV4cGVydCBvbiB0aGUgUkZDcyBvciBw
cmlvciBoaXN0b3J5IG9mIHRoZSBPQXV0aCBncm91cCByZWxhdGl2ZSB0byB0aGlzIHRvcGljLCBz
byBwbGVhc2UgcG9pbnQgbWUgdG8gYW55IGV4aXN0aW5nIHNvbHV0aW9uIGlmIHRoaXMgaXMgYSBz
b2x2ZWQgcHJvYmxlbS4gT3RoZXJ3aXNlLCBJIHdvdWxkIGxpa2UgdG8gZ2V0IGZlZWRiYWNrIG9u
IG15IHN1Z2dlc3Rpb24uDQoNClRoYW5rcyBZb3UsDQoNCkFuZHJldyBGcmVnbHkNClZlcmlzaWdu
IEluYy4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpP
QXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4N
Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCg0KX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxp
bmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCg0KLS0NCkNoaWVmIEFyY2hp
dGVjdA0KSWRlbnRpdHkgU2VydmljZXMgRW5naW5lZXJpbmcgICAgIFdvcms6IGdlb3JnZS5mbGV0
Y2hlckB0ZWFtYW9sLmNvbTxtYWlsdG86Z2VvcmdlLmZsZXRjaGVyQHRlYW1hb2wuY29tPg0KQU9M
IEluYy4gICAgICAgICAgICAgICAgICAgICAgICAgIEFJTTogIGdmZmxldGNoDQpNb2JpbGU6ICsx
LTcwMy00NjItMzQ5NCAgICAgICAgICAgVHdpdHRlcjogaHR0cDovL3R3aXR0ZXIuY29tL2dmZmxl
dGNoDQpPZmZpY2U6ICsxLTcwMy0yNjUtMjU0NCAgICAgICAgICAgUGhvdG9zOiBodHRwOi8vZ2Vv
cmdlZmxldGNoZXIucGhvdG9ncmFwaHkNCg==

--_000_F56B643467B14263B46742BDC940B14Bverisigncom_
Content-Type: text/html; charset="utf-8"
Content-ID: <3692AF56A5676647BE26030AD5D8F04B@verisign.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8
ZGl2PkFsbCw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pkkgd2lsbCBjb21lIHVwIHdp
dGggYSBjb25zaWRlcmVkIHJlc3BvbnNlIHRvIHRoaXMgYnkgdG9tb3Jyb3cgc29tZSB0aW1lLiBU
aGlzIGludGVyYWN0aW9uIGhhcyBiZWVuIGV4dHJlbWVseSBoZWxwZnVsITwvZGl2Pg0KPGRpdj48
YnI+DQo8L2Rpdj4NCjxkaXY+QW5keTwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRMT09L
X1NJR05BVFVSRSI+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwv
ZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQt
ZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMnB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJs
YWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25l
OyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDog
MGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0g
bm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+
RnJvbTogPC9zcGFuPkdlb3JnZSBGbGV0Y2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdmZmxldGNo
QGFvbC5jb20iPmdmZmxldGNoQGFvbC5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250
LXdlaWdodDpib2xkIj5Pcmdhbml6YXRpb246IDwvc3Bhbj5BT0wgTExDPGJyPg0KPHNwYW4gc3R5
bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5XZWRuZXNkYXksIEFwcmlsIDIwLCAy
MDE2IGF0IDE6MzYgUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwv
c3Bhbj5BbmRyZXcgRnJlZ2x5ICZsdDs8YSBocmVmPSJtYWlsdG86YWZyZWdseUB2ZXJpc2lnbi5j
b20iPmFmcmVnbHlAdmVyaXNpZ24uY29tPC9hPiZndDssIEpvaG4gQnJhZGxleSAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIj52ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7LCAm
cXVvdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiZx
dW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwv
YT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bh
bj5SZTogW09BVVRILVdHXSBCdWlsZGluZyBvbiB0aGUgcHJvdG9jb2wgaW4gdGhlIGRyYWZ0IOKA
nE9BdXRoIDIuMCBUb2tlbiBFeGNoYW5nZTogQW4gU1RTIGZvciB0aGUgUkVTVCBvZiBVc+KAnSB0
byBpbmNsdWRlIEF1dGhlbnRpY2F0aW9uIFRva2Vuczxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8
L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RF
IiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBN
QVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXYgYmdjb2xvcj0iI0ZGRkZGRiIgdGV4dD0iIzAw
MDAwMCI+PGZvbnQgZmFjZT0iSGVsdmV0aWNhLEFyaWFsLHNhbnMtc2VyaWYiPkhpIEFuZHksPGJy
Pg0KPGJyPg0KR2xhZCBJIGd1ZXNzZWQgY29ycmVjdGx5OikgSWYgdGhlcmUgYXJlIG5ldHdvcmsg
b3Igb3RoZXIgbGltaXRhdGlvbnMgaW4gaG93IHRoZSBjbGllbnQgZ2V0cyBhbmQgdXNlcyB0b2tl
bnMsIHRoYXQgd291bGQgYmUgaGVscGZ1bCBpbiBhIGRpYWdyYW0gc2Vuc2UuIEFzIEpvaG4gcG9p
bnRzIG91dCBpbiBoaXMgcmVzcG9uc2UsIG5vdCBoYXZpbmcgYW4gYXVkaWVuY2UgaGFzIHBvc3Np
YmxlIHNlY3VyaXR5IGltcGxpY2F0aW9ucy48YnI+DQo8YnI+DQpJZiBJJ20gZm9sbG93aW5nIHlv
dXIgb3JpZ2luYWwgdGhpbmtpbmcuLi4gaXQgZ29lcyBzb21ldGhpbmcgbGlrZSB0aGlzLi4uPGJy
Pg0KPGJyPg0KMS4gTW9iaWxlIGFwcCBhc2tzIHVzZXJzIHRvIGF1dGhlbnRpY2F0ZSBhdCAmcXVv
dDt0aGVpciZxdW90OyBJZFA8YnI+DQoyLiBNb2JpbGUgYXBwIGdldHMgYmFjayAmcXVvdDthdXRo
ZW50aWNhdGlvbiB0b2tlbiZxdW90OyAobGlrZWx5IHNvbWUgc29ydCBvZiBTQU1MIGFzc2VydGlv
bik8YnI+DQozLiBNb2JpbGUgYXBwIHByZXNlbnRzICZxdW90O2F1dGhlbnRpY2F0aW9uIHRva2Vu
JnF1b3Q7IHRvIEF1dGhvcml6YXRpb24gU2VydmljZTxicj4NCjQuIEF1dGhvcml6YXRpb24gU2Vy
dmljZSB2YWxpZGF0ZSAmcXVvdDthdXRoZW50aWNhdGlvbiB0b2tlbiZxdW90OyBhbmQgcmV0dXJu
cyBhbiBhY2Nlc3NfdG9rZW48YnI+DQo1LiBNb2JpbGUgYXBwIGludm9rZXMgZGF0YSBwcm92aWRl
ciBwYXNzaW5nIHRoZSBhY2Nlc3NfdG9rZW48YnI+DQo2LiBEYXRhIHByb3ZpZGVyIHZhbGlkYXRl
cyBhY2Nlc3NfdG9rZW4gKGVpdGhlciBsb2NhbGx5IG9yIHZpYSBhbiBpbnRyb3NwZWN0aW9uIGVu
ZHBvaW50IG9uIHRoZSBBUyk8YnI+DQo8YnI+DQpJbiB0aGlzIGZsb3cgdGhlcmUgYXJlIHJlYWxs
eSB0d28gdG9rZW5zOiB0aGUgJnF1b3Q7YXV0aGVudGljYXRpb24gdG9rZW4mcXVvdDsgYW5kIHRo
ZSBhY2Nlc3NfdG9rZW4uIFRoZXJlIHNob3VsZCBiZSBhbiBhdWRpZW5jZSBmb3IgYm90aCB0b2tl
bnMuIFRoZSBhdWRpZW5jZSBvZiB0aGUgJnF1b3Q7YXV0aGVudGljYXRpb24gdG9rZW4mcXVvdDsg
c2hvdWxkIGJlIHRoZSBBUywgYW5kIHRoZSBhdWRpZW5jZSBvZiB0aGUgYWNjZXNzX3Rva2VuIHNo
b3VsZCBiZSB0aGUgZGF0YSBwcm92aWRlcg0KIHRoZSBjbGllbnQgaXMgZ29pbmcgdG8gdXNlLjxi
cj4NCjxicj4NClNvLCBpZiB0aGVyZSBhcmUgbm8gbmV0d29yayBmaXJld2FsbCB0eXBlIGxpbWl0
YXRpb25zLCBpdCBzZWVtcyBtdWNoIHNpbXBsZXIgdG8ganVzdCBoYXZlIHRoZSBBUyB1c2UgdGhl
IGV4dGVybmFsIElkUHMgYXMgaXQncyBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc21zIGFuZCB0aGUg
cmVzdCBpcyBqdXN0IGRlZmF1bHQgT3BlbklEIENvbm5lY3QuIE1lYW5pbmcgdGhhdCB0aGUgTW9i
aWxlIGFwcCBzdGFydHMgYW4gT3BlbklEIENvbm5lY3QgZmxvdyB3aXRoDQogdGhlIEFTLCB0aGUg
QVMgZ2V0IHRoZSB1c2VyIGF1dGhlbnRpY2F0ZWQgdmlhIHRoZSB1c2VyJ3MgSWRQLCB0aGUgQVMg
cHJvdmlkZXMgYWNjZXNzIGFuZCBpZCB0b2tlbnMgYmFzayB0byB0aGUgTW9iaWxlIGFwcCAoZm9s
bG93aW5nIHRoZSBjb2RlIG9yIG90aGVyIGZsb3cpLjxicj4NCjxicj4NCkFtIEkgbWlzc2luZyBz
b21ldGhpbmc/PGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCkdlb3JnZTxicj4NCjwvZm9udD48YnI+
DQo8ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPk9uIDQvMjAvMTYgMTA6MzEgQU0sIEZyZWds
eSwgQW5kcmV3IHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2l0ZT0ibWlkOkM4Nzk1
RTA3LUY5RDgtNENERS1BMTg3LTFFQTdEOTYwNEUxRkB2ZXJpc2lnbi5jb20iIHR5cGU9ImNpdGUi
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2PkhpIEdlb3JnZSw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+
DQo8ZGl2PllvdSBmdWxseSBjYXB0dXJlZCBvbmUgb2YgdGhlIG9wdGlvbnMgd2UgaGF2ZSBiZWVu
IGNvbnRlbXBsYXRpbmcuIEkgZGlkbuKAmXQgcHJvcG9zZSB0aGlzIGZsb3cgYmVjYXVzZSBJIHdh
cyBsb29raW5nIGZvciBhIHdheSB0byBzb2x2ZSBvdXIgb3VyIHVzZSBjYXNlIGJhc2VkIG9uIHRo
ZSBleGlzdGluZyBSRkNzIGFuZCBPcGVuSUQgQ29ubmVjdCBzcGVjaWZpY2F0aW9ucyB3aXRoIG1p
bmltYWwgbmV3IHNwZWNpZmljYXRpb24gcmVxdWlyZWQuDQogVGhhdCBsZWQgbWUgdG8gdGhlIHBh
dGggZGVzY3JpYmVkIGluIHRoZSBlbWFpbCByZXNwb25zZSBJIHNlbnQgb3V0IGEgbGl0dGxlIHdo
aWxlIGFnbyB0byBOYXQgU2FraW11cmHigJlzIHJlc3BvbnNlLiBQbGVhc2UgdGFrZSBhIGxvb2sg
YXQgdGhhdCBlbWFpbCBhbmQgc2VlIHdoYXQgeW91IHRoaW5rLjwvZGl2Pg0KPGRpdj48YnI+DQo8
L2Rpdj4NCjxkaXY+R2l2ZW4gaG93IHdlbGwgc3RhdGVkIHlvdXIgc3VtbWFyeSBvZiBvdXIgbmVl
ZHMgd2FzLCBkbyB5b3Ugc3RpbGwgd2FudCBtZSB0byBwcm92aWRlIGEgZGlhZ3JhbT88L2Rpdj4N
CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNw
OyBBbmR5PC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k
aXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1m
YW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjEycHQ7DQogICAgICAgICAgdGV4dC1hbGlnbjpsZWZ0
OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7DQogICAgICAgICAgQk9S
REVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6
DQogICAgICAgICAgMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYg
MXB0IHNvbGlkOw0KICAgICAgICAgIEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkct
VE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5H
ZW9yZ2UgRmxldGNoZXIgJmx0OzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRv
OmdmZmxldGNoQGFvbC5jb20iPmdmZmxldGNoQGFvbC5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0
eWxlPSJmb250LXdlaWdodDpib2xkIj5Pcmdhbml6YXRpb246IDwvc3Bhbj5BT0wgTExDPGJyPg0K
PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5XZWRuZXNkYXksIEFw
cmlsIDIwLCAyMDE2IGF0IDg6NDkgQU08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s
ZCI+VG86IDwvc3Bhbj5BbmRyZXcgRnJlZ2x5ICZsdDs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUi
IGhyZWY9Im1haWx0bzphZnJlZ2x5QHZlcmlzaWduLmNvbSI+PC9hPjxhIGNsYXNzPSJtb3otdHh0
LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzphZnJlZ2x5QHZlcmlzaWduLmNvbSI+YWZy
ZWdseUB2ZXJpc2lnbi5jb208L2E+Jmd0OywgSm9obiBCcmFkbGV5ICZsdDs8YSBtb3otZG8tbm90
LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSI+dmU3anRiQHZlN2p0
Yi5jb208L2E+Jmd0OywNCiAmcXVvdDs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1h
aWx0bzpvYXV0aEBpZXRmLm9yZyI+PC9hPjxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0
ZWQiIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+JnF1b3Q7
ICZsdDs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9y
ZyI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi
b2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtPQVVUSC1XR10gQnVpbGRpbmcgb24gdGhlIHByb3Rv
Y29sIGluIHRoZSBkcmFmdCDigJxPQXV0aCAyLjAgVG9rZW4gRXhjaGFuZ2U6IEFuIFNUUyBmb3Ig
dGhlIFJFU1Qgb2YgVXPigJ0gdG8gaW5jbHVkZSBBdXRoZW50aWNhdGlvbiBUb2tlbnM8YnI+DQo8
L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRU
UklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7
IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjANCiAgICAgICAgICAwIDAgNTsiPg0KPGRpdj4NCjxk
aXYgYmdjb2xvcj0iI0ZGRkZGRiIgdGV4dD0iIzAwMDAwMCI+PGZvbnQgZmFjZT0iSGVsdmV0aWNh
LEFyaWFsLHNhbnMtc2VyaWYiPkkgc2hvdWxkIHByb2JhYmx5IGp1c3Qgd2FpdCBmb3IgdGhlIGRp
YWdyYW0uLi4gYnV0IG5vdCB3YW50aW5nIHRvIHdhaXQuLi4gOik8YnI+DQo8YnI+DQpJZiBJIHVu
ZGVyc3RhbmQgY29ycmVjdGx5LCB0aGUgdXNlciBpcyBnb2luZyB0byB1c2UgYSBjbGllbnQgYW5k
IHRoZSBjbGllbnQgd2lsbCBhdXRoZW50aWNhdGUgdGhlIHVzZXIgdmlhIHNvbWUgSWRQIHVzaW5n
IGFuIGV4aXN0aW5nIG1ldGhvZCAoU0FNTCwgTERBUCAoPyksIE9wZW5JRCBDb25uZWN0LCBldGMp
LiBUaGUgZGVzaXJlIGlzIHRvIHRha2UgdGhhdCByZXNwb25zZSBhbmQgaW4gc29tZSB3YXkgcHJl
c2VudCBpdCB0byBhbiAmcXVvdDtBdXRob3JpemF0aW9uDQogU2VydmVyJnF1b3Q7IHdoaWNoIHdp
bGwgdmFsaWRhdGUgdGhlICZxdW90O2F1dGhlbnRpY2F0aW9uIHJlc3BvbnNlJnF1b3Q7IGFuZCBy
ZXR1cm4gYW4gYWNjZXNzIHRva2VuIGZvciB1c2UgYXQgdGhlIGRhdGEgcHJvdmlkZXIocykuPGJy
Pg0KPGJyPg0KV2hhdCBpZiB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgYWxzbyB0b29rIG9uIHRo
ZSByb2xlIG9mIHRoZSBPcGVuSUQgQ29ubmVjdCBwcm92aWRlci4gVGhpcyBjb3VsZCB3b3JrIGJ5
IGhhdmluZyB0aGUgY2xpZW50IHN0YXJ0IGFuIE9wZW5JRCBDb25uZWN0IGZsb3cgd2l0aCBBdXRo
b3JpemF0aW9uIFNlcnZlciAoaGludHMgY291bGQgYmUgcHJvdmlkZWQgYXMgdG8gd2hpY2ggSWRQ
IHRoZSB1c2VyIHdhbnRzIHRvIGF1dGhlbnRpY2F0ZSBhdCkuIFRoZQ0KIEFTIHdvdWxkIGxvb2sg
YXQgdGhlICZxdW90O2lkcCBoaW50JnF1b3Q7IGFuZCBlaXRoZXIgc3RhcnQgYW5kIFNQIFNBTUwg
Zmxvdywgb3IgcHJlc2VudCBVSSBmb3IgY29sbGVjdGluZyBMREFQIGNyZWRlbnRpYWxzIChJIGRv
bid0IHJlY29tbWVuZCB0aGlzKSBvciBjaGFpbiB0byBhbnkgb3RoZXIgcHJvcHJpZXRhcnkgSWRQ
IGZsb3cuIE9uY2UgdGhlIHVzZXIgc3VjY2Vzc2Z1bGx5IGF1dGhlbnRpY2F0ZXMgd2l0aCB0aGUg
Y29ycmVjdCBJZFAsIHRoZSBBUyB3aWxsDQogZmluaXNoIHRoZSBPcGVuSUQgQ29ubmVjdCBmbG93
IGFsbG93aW5nIHRoZSBjbGllbnQgdG8gb2J0YWluIGFuIGFjY2VzcyB0b2tlbiwgcmVmcmVzaCB0
b2tlbiBhbmQgaWRfdG9rZW4uIFRoZSBBUyBjb3VsZCBhZGQgdG8gdGhlIGlkX3Rva2VuIGEgY2xh
aW0gc3BlY2lmeWluZyB3aGljaCBJZFAgdGhlIHVzZXIgdXNlZCBkdXJpbmcgdGhlIGF1dGhlbnRp
Y2F0aW9uIHByb2Nlc3NlZC48YnI+DQo8YnI+DQpUaGUgSWRQIHRoZSB1c2VyIHVzZWQgZm9yIGF1
dGhlbnRpY2F0aW9uIGNvdWxkIGFsc28gYmUgZW5jb2RlZCBpbiB0aGUgYWNjZXNzX3Rva2VuIChv
ciByZXR1cm5lZCBhcyBwYXJ0IG9mIGFuIGludHJvc3BlY3Rpb24gY2FsbCkuPGJyPg0KPGJyPg0K
VGhpcyB3YXkgd2hldGhlciB0aGUgZGF0YSBwcm92aWRlcnMgYXJlIHZhbGlkYXRpbmcgdGhlIGFj
Y2Vzc190b2tlbnMgbG9jYWxseSBvciB1c2luZyBpbnRyb3NwZWN0aW9uIHRoZXkgY2FuIG9idGFp
biB0aGUgSWRQIHRoZSB1c2VyIHVzZWQgYW5kIGFwcGx5IHRoZWlyIG93biBhdXRob3JpemF0aW9u
IHJ1bGVzLjxicj4NCjxicj4NClRoZSB1c2VyIGlzIG9ubHkgcmVxdWlyZWQgdG8gZG8gb25lIGF1
dGhvcml6YXRpb24gZmxvdyBmb3IgdGhlIGNsaWVudCB0aGF0IGlzIG1hbmFnZWQgYnkgdGhlIEF1
dGhvcml6YXRpb24gU2VydmVyLjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpHZW9yZ2U8YnI+DQo8
L2ZvbnQ+PGJyPg0KPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij5PbiA0LzE5LzE2IDU6MDYg
UE0sIEZyZWdseSwgQW5kcmV3IHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2l0ZT0i
bWlkOjYxMDFEMEVCLUUwNEItNDU3NC04ODk5LUVEOEY0RTYzMUQ2N0B2ZXJpc2lnbi5jb20iIHR5
cGU9ImNpdGUiPg0KPGRpdj4NCjxkaXY+VGhhbmsgeW91IGZvciB5b3VyIHJlc3BvbnNlIEdlb3Jn
ZS4gSXQgcG9pbnRzIG1lIHRvIHNvbWUgbW9yZSByZXNlYXJjaCB0byBkbywgc3VjaCBhcyBsb29r
aW5nIGF0IE9wZW5JRCBDb25uZWN0IHN1cHBvcnQgZm9yIGJvdGggZGlzdHJpYnV0ZWQgYW5kIGFn
Z3JlZ2F0ZWQgY2xhaW1zLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QmVsb3cgYXJl
IHJlcGxpZXMgdG8geW91ciBxdWVzdGlvbnMvYXNzZXJ0aW9ucyBiYXNlZCBvbiBteSBjdXJyZW50
IHVuZGVyc3RhbmRpbmcgb2YgdGhlIHZhcmlvdXMgcHJvdG9jb2xzLiBGdXJ0aGVyIHJlc2VhcmNo
IGFuZCBhZHZpY2Ugd2lsbCBsaWtlbHkgZW5yaWNoIHRoaXMgc2lnbmlmaWNhbnRseS48L2Rpdj4N
CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Plllcywgd2hhdCBpcyByZXF1aXJlZCBpcyBhIHZlcmlm
aWFibGUgY2xhaW0gdGhhdCB0aGUgdXNlciBpcyBzdGlsbCBhIG1lbWJlciBvZiBTb21lT3JnIElu
Yy4gSSBoYXZlIGJlZW4gb3BlcmF0aW5nIHVuZGVyIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlIG9u
bHkgd2F5IHRoaXMgY2FuIGJlIGRvbmUgd291bGQgYmUgdG8gaGF2ZSB0aGUgdXNlciBhdXRoZW50
aWNhdGVkIGJ5IHRoZSBJZGVudGl0eSBQcm92aWRlciBmb3IgU29tZU9yZy4gUGVyaGFwcw0KIHRo
ZSByZXNlYXJjaCBpbnRvIE9wZW5JRCBDb25uZWN0IHN1cHBvcnQgZm9yIGRpc3RyaWJ1dGVkIGFu
ZCBhZ2dyZWdhdGVkIGNsYWltcyB3aWxsIHJldmVhbCBhbiBhbHRlcm5hdGl2ZS4gSSBmb3Jlc2Vl
IGEgY2hhbGxlbmdlIGluIGRlYWxpbmcgd2l0aCBJZGVudGl0eSBQcm92aWRlcuKAmXMgZm9yIG9y
Z2FuaXphdGlvbnMgdXNpbmcgU0FNTCBhc3NlcnRpb25zIG9uIHRvcCBvZiBBY3RpdmUgRGlyZWN0
b3J5IGFuZCBMREFQLCBhbmQgd2hpY2ggYXJlDQogbm90IGdvaW5nIHRvIGRvIGFueSB1cGRhdGlu
ZyB0byBzdXBwb3J0IG91ciBuZWVkcy48L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N
CjxkaXY+V2UgZG8gbm90IGV4cGVjdCB0aGUgdXNlciB0byBmaXJzdCBnbyB0byB0aGUgZGF0YSBw
cm92aWRlci4gV2UgYW50aWNpcGF0ZSB0aGF0IHRoZSBjbGllbnQgYXBwbGljYXRpb24gd291bGQg
cHJvdmlkZSBhIEF1dGhlbnRpY2F0aW9uIFRva2VuIHRvIGFuICZuYnNwO0F1dGhvcml6YXRpb24g
U2VydmljZSBzZXJ2aWNlIHRoYXQgdGhlbiBpc3N1ZXMgdG8gdGhlIGNsaWVudCBhbiBhY2Nlc3Mg
dG9rZW4gdGhhdCB0aGUgZGF0YSBwcm92aWRlciB3aWxsIHRydXN0Lg0KIE9uZSBvZiBvdXIgcmVh
c29ucyBmb3IgZG9pbmcgaXQgdGhpcyB3YXkgaXMgdGhhdCB3ZSBhcmUgdHJ5aW5nIHRvIGVsaW1p
bmF0ZSByZWRpcmVjdHMgdG8gZWFzZSBpbXBsZW1lbnRhdGlvbiBvZiBhIG5hdGl2ZSBjbGllbnQu
IFdlIGFyZSB0aGVyZWZvcmUgcmVxdWlyaW5nIHRoZSBjbGllbnQgdG8gaGFuZGxlIGF1dGhlbnRp
Y2F0aW9uIHdpdGggdGhlIElkZW50aXR5IFByb3ZpZGVyIGFzIGEgc2VwYXJhdGUgc3RlcCBmcm9t
IGF1dGhvcml6YXRpb24uPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JdCBtaWdodCBo
ZWxwIGlmIEkgY2xhcmlmaWVkIHRoYXQgVmVyaXNpZ27igJlzIHJvbGUgaW4gdGhlIHNjZW5hcmlv
IEkgZGVzY3JpYmVkIGlzIHRvIGJlIGp1c3Qgb25lIG9mIG1hbnkgZGF0YSBwcm92aWRlcnMuPC9k
aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4N
CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMnB0Ow0KICAgICAg
ICAgICAgICAgICAgICB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9N
OiBtZWRpdW0NCiAgICAgICAgICAgICAgICAgICAgbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBu
b25lOyBQQURESU5HLUJPVFRPTTogMGluOw0KICAgICAgICAgICAgICAgICAgICBQQURESU5HLUxF
RlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOg0KICAgICAgICAgICAgICAg
ICAgICAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsNCiAgICAg
ICAgICAgICAgICAgICAgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln
aHQ6Ym9sZCI+RnJvbTogPC9zcGFuPkdlb3JnZSBGbGV0Y2hlciAmbHQ7PGEgbW96LWRvLW5vdC1z
ZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86Z2ZmbGV0Y2hAYW9sLmNvbSI+Z2ZmbGV0Y2hAYW9sLmNv
bTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPk9yZ2FuaXphdGlv
bjogPC9zcGFuPkFPTCBMTEM8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0
ZTogPC9zcGFuPlR1ZXNkYXksIEFwcmlsIDE5LCAyMDE2IGF0IDQ6MTggUE08YnI+DQo8c3BhbiBz
dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5BbmRyZXcgRnJlZ2x5ICZsdDs8YSBt
b3otZG8tbm90LXNlbmQ9InRydWUiIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhy
ZWY9Im1haWx0bzphZnJlZ2x5QHZlcmlzaWduLmNvbSI+YWZyZWdseUB2ZXJpc2lnbi5jb208L2E+
Jmd0OywgSm9obiBCcmFkbGV5ICZsdDs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1h
aWx0bzp2ZTdqdGJAdmU3anRiLmNvbSI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0OywNCiAmcXVv
dDs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0
ZWQiIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+JnF1b3Q7
ICZsdDs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9y
ZyI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi
b2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtPQVVUSC1XR10gQnVpbGRpbmcgb24gdGhlIHByb3Rv
Y29sIGluIHRoZSBkcmFmdCDigJxPQXV0aCAyLjAgVG9rZW4gRXhjaGFuZ2U6IEFuIFNUUyBmb3Ig
dGhlIFJFU1Qgb2YgVXPigJ0gdG8gaW5jbHVkZSBBdXRoZW50aWNhdGlvbiBUb2tlbnM8YnI+DQo8
L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRU
UklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7
IFBBRERJTkc6MCAwIDANCiAgICAgICAgICAgICAgICAgICAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4N
CjxkaXY+DQo8ZGl2IGJnY29sb3I9IiNGRkZGRkYiIHRleHQ9IiMwMDAwMDAiPjxmb250IGZhY2U9
IkhlbHZldGljYSxBcmlhbCxzYW5zLXNlcmlmIj5TbyBpZiBJIHVuZGVyc3RhbmQgdGhpcyBjb3Jy
ZWN0bHksIHdoYXQgaXMgcmVhbGx5IHJlcXVpcmVkIGlzIGEgdmVyaWZpYWJsZSBjbGFpbSB0aGF0
IHRoZSB1c2VyIGlzIHN0aWxsIGEgbWVtYmVyIG9mIFNvbWVPcmcgSW5jLiBPcGVuSUQgQ29ubmVj
dCBzdXBwb3J0cyBib3RoIGRpc3RyaWJ1dGVkIGFuZCBhZ2dyZWdhdGVkDQogY2xhaW1zIHRoYXQg
Y2FuIGJlIHNpZ25lZCBieSB0aGUgYXBwcm9wcmlhdGUgSWRlbnRpdHkgUHJvdmlkZXIuIFRoZSBw
b2ludCBiZWluZyB0aGF0IEknbSBub3Qgc3VyZSBhbiAmcXVvdDthdXRoZW50aWNhdGlvbiB0b2tl
biZxdW90OyBpcyByZXF1aXJlZCBmb3IgdGhpcyB1c2UgY2FzZSB0byBzdWNjZWVkLCBpdCdzIGp1
c3Qgb25lIGtpbmQgb2YgdG9rZW4gdGhhdCBjYW4gYmUgdXNlZC48YnI+DQo8YnI+DQpBbHNvLCBp
cyB0aGUgZXhwZWN0ZWQgZmxvdyB0aGF0IHRoZSB1c2VyIHdpbGwgZmlyc3QgZ28gdG8gdGhlIGRh
dGEgcHJvdmlkZXIgYW5kIHRoZW4gYmUgZGlyZWN0ZWQgZWxzZSB3aGVyZSBmcm9tIHRoZXJlPyBJ
ZiB0aGF0IGlzIHRoZSBjYXNlLCB0aGUgZGF0YSBwcm92aWRlciBjYW4ganVzdCBiZSBhbiBPcGVu
SUQgQ29ubmVjdCByZWx5aW5nIHBhcnR5IGFuZCBnaXZlIHRoZSB1c2VyIGFuIG9wdGlvbiBvZiB0
aGUgbGlzdCBvZiBzdXBwb3J0ZWQgSWRQcw0KIHRvIGNob29zZSBmcm9tLiBUaGUgdXNlciB3aWxs
IHRoZW4gYmUgcmVkaXJlY3RlZCB0byBTb21lT3JnIEluYy4gSWRQLCBhdXRoZW50aWNhdGUgYW5k
IHRoZSBkYXRhIHByb3ZpZGVyIHdpbGwgaGF2ZSB0aGUgYXV0aG9yaXphdGlvbiBhbmQgcmVjZW50
IGF1dGhlbnRpY2F0aW9uIHRoZXkgY2FuIHZhbGlkYXRlLjxicj4NCjxicj4NCklzIHRoZSB1c2Vy
L2RhdGEgZmxvdyBtb3JlIGNvbXBsaWNhdGVkIHRoYW4gdGhpcz88YnI+DQo8YnI+DQpUaGFua3Ms
PGJyPg0KR2VvcmdlPGJyPg0KPC9mb250Pjxicj4NCjxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZp
eCI+T24gNC8xOS8xNiA0OjA1IFBNLCBGcmVnbHksIEFuZHJldyB3cm90ZTo8YnI+DQo8L2Rpdj4N
CjxibG9ja3F1b3RlIGNpdGU9Im1pZDo4Qjc0ODI1Mi05QUUyLTQ4MjQtOTIzQi0wMENENDZDQjhE
NjhAdmVyaXNpZ24uY29tIiB0eXBlPSJjaXRlIj4NCjxkaXY+DQo8ZGl2PlRoYW5rcyBmb3IgeW91
ciByZXNwb25zZSBKb2huLiBJIGFsc28gZ290IGEgZ29vZCByZXNwb25zZSBmcm9tIEJyaWFuIENh
bXBiZWxsIGFuZCBhcHByZWNpYXRlIHRoYXQuIEkgd2lsbCByZXNwb25kIHNlcGFyYXRlbHkgdG8g
QnJpYW7igJlzIHJlc3BvbnNlIGFzIEkgdGhpbmsgaXQgd291bGQga2VlcCB0aGluZ3MgY2xlYXJl
ciB0byBkbyB0aGF0LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlIHByb2JsZW0g
d2UgaGF2ZSBmb3IgdXNpbmcgT3BlbklEIENvbm5lY3QgaXMgdGhhdCBpdCBjb21iaW5lcyB0aGUg
cm9sZSBvZiBBdXRoZW50aWNhdGlvbiBTZXJ2aWNlIHdpdGggdGhlIHJvbGUgb2YgQXV0aG9yaXph
dGlvbiBTZXJ2aWNlLiBQZXJoYXBzIHRoZSBmb2xsb3dpbmcgZGVzY3JpcHRpb24gb2Ygd2hhdCB3
ZSB3YW50IHRvIGRvIHdpbGwgY2xhcmlmeSB3aHkgdGhpcyB3b27igJl0IHdvcmsgZm9yIHVzOjwv
ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlIGJhc2ljIHByb2JsZW0gc3RhdGVtZW50
IGlzIHRoYXQgd2UgbmVlZCB0byBoYXZlIGEgY2xpZW50IGFwcGxpY2F0aW9uIGF1dGhvcml6ZWQg
YnkgYSBTZXJ2aWNlIFByb3ZpZGVyIGJhc2VkIG9uIHByb29mIHRoYXQgYSB1c2VyIGlzIGN1cnJl
bnRseSBhIG1lbWJlciBvZiBzb21lIG9yZ2FuaXphdGlvbi4gVGhpcyBhc3N1bWVzIHRoZSBvcmdh
bml6YXRpb24gaGFzIHByZXZpb3VzbHkgZXN0YWJsaXNoZWQgc29tZSBsZXZlbCBvZiBhdXRob3Jp
emVkDQogYWNjZXNzIHdpdGggdGhlIFNlcnZpY2UgUHJvdmlkZXIuJm5ic3A7PC9kaXY+DQo8ZGl2
Pjxicj4NCjwvZGl2Pg0KPGRpdj5IZXJlIGlzIGFuIGV4YW1wbGU6IFN1cHBvc2UgSSBhbSBhIG1l
bWJlciBvZiBTb21lT3JnIEluYy4gU3VwcG9zZSBTb21lT3JnIEluYy4gaXMgZG9pbmcgcmVzZWFy
Y2ggdGhhdCByZXF1aXJlcyBpdCB0byBnYXRoZXIgZGF0YSBvdmVyIHRoZSBJbnRlcm5ldCBmcm9t
IGEgbnVtYmVyIG9mIGRhdGEgcHJvdmlkZXJzLiBUaGUgZGF0YSBwcm92aWRlcnMgcmVxdWlyZSBh
dXRoZW50aWNhdGlvbiBhbmQgcHJvb2Ygb2Ygb3JnYW5pemF0aW9uYWwgbWVtYmVyc2hpcA0KIGlu
IG9yZGVyIHRvIGF1dGhvcml6ZSB2YXJpb3VzIGxldmVscyBvZiBhY2Nlc3MgdG8gdGhlaXIgZGF0
YS4gVGhlIGRhdGEgcHJvdmlkZXJzIGRvIG5vdCBjb25zaWRlciBoYXZpbmcgYW4gYWNjb3VudCB3
aXRoIHRoZW0gb3IgYSBQdWJsaWMgSWRlbnRpdHkgUHJvdmlkZXIgdG8gYmUgc3VpdGFibGUgZm9y
IHByb3ZpbmcgdGhhdCBJIGFtIHN0aWxsIGEgbWVtYmVyIG9mIFNvbWVPcmcgYXQgdGltZSBvZiBh
dXRoZW50aWNhdGlvbi4gVGhleSB3b3VsZA0KIGhhdmUgbm8gd2F5IG9mIGtub3dpbmcgd2hldGhl
ciBvciBub3QgbXkgcmVsYXRpb25zaGlwIHdpdGggU29tZU9yZyBzdGlsbCBleGlzdHMgYXQgdGhh
dCB0aW1lLiBUaGUgZGF0YSBwcm92aWRlcnMgd291bGQgdGhlcmVmb3JlIGxpa2UgdGhlIENsaWVu
dCBzb2Z0d2FyZSB0byBhdXRoZW50aWNhdGUgbWUgYWdhaW5zdCBTb21lT3JncyBJZGVudGl0eSBQ
cm92aWRlci4gVGhpcyB3b3VsZCBiZSBnb29kIHByb29mIHRoYXQgSSBhbSBzdGlsbCBhIG1lbWJl
cg0KIG9mIFNvbWVPcmcgYXQgdGhlIHRpbWUgSSBhdXRoZW50aWNhdGUuIFRoaXMgYXV0aGVudGlj
YXRpb24gd291bGQgZW5hYmxlIHRoZSBkYXRhIHByb3ZpZGVycyBBdXRob3JpemF0aW9uIFNlcnZl
ciB0byBncmFudCBtZSBhY2Nlc3MgYXBwcm9wcmlhdGUgdG8gYSBtZW1iZXIgb2YgU29tZU9yZy4g
Jm5ic3A7Tm90ZSB0aGF0IGFzIGEgcHJlcmVxdWlzaXRlIHRvIGFsbCBvZiB0aGlzLCBTb21lT3Jn
IHdpbGwgaGF2ZSB1c2VkIGFuIG91dC1vZi1iYW5kIHByb2Nlc3MNCiB0byBzZXQgdXAgYSB0cnVz
dCByZWxhdGlvbnNoaXAgZm9yIFNvbWVPcmcncyBJZGVudGl0eSBQcm92aWRlciB3aXRoIHRoZSBk
YXRhIHByb3ZpZGVy4oCZcyBBdXRob3JpemF0aW9uIFNlcnZpY2UsIGFuZCB3aWxsIGhhdmUgbmVn
b3RpYXRlZCBhdXRob3JpemF0aW9uIGNsYWltcyB0byBiZSBncmFudGVkIHRvIFNvbWVPcmdzIG1l
bWJlcnMuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5XaGF0IEkgYW0gaGF2aW5nIGRp
ZmZpY3VsdHkgd2l0aCBpcyBpbiBrbml0dGluZyB0b2dldGhlciBhbiBhcHByb2FjaCBiYXNlZCBv
biB0aGUgaGUgT3BlbklEIENvbm5lY3Qgc3BlY2lmaWNhdGlvbnMsIFNBTUwgc3BlY2lmaWNhdGlv
bnMsIGFuZCBPQXV0aCBSRkNzIGFuZCBkcmFmdHMgaW4gYSB3YXkgdGhhdCBzdXBwb3J0cyB0aGUg
YWJvdmUgdXNlIGNhc2UgZW5kLXRvLWVuZC4gVGhlIE9BdXRoIFJGQ3MgYW5kIGRyYWZ0cyBhbG1v
c3QgZ2V0DQogbWUgdGhlcmUuIFdoYXQgc2VlbXMgdG8gYmUgbWlzc2luZyBpcyBhIHdheSBvZiB0
ZWxsaW5nIGFuIElkZW50aXR5IFByb3ZpZGVyIHRoZSBVUkwgZm9yIHRoZSBBdXRob3JpemF0aW9u
IFNlcnZpY2UgKHRoZSByZXF1aXJlZCBBdWRpZW5jZSBjbGFpbSBpbiBhbiBhdXRoZW50aWNhdGlv
biBhc3NlcnRpb24gYXMgZGVmaW5lZCBpbiBSRkNzIDcyNTEsIDcyNTIgYW5kIDcyNTMpLCBhbmQg
dGhlbiBhIHJlcXVpcmVtZW50IHRoYXQgdGhlIElkZW50aXR5DQogUHJvdmlkZXJzIHB1dCB0aGUg
c3VwcGxpZWQgQXVkaWVuY2UgSWRlbnRpZmllciBpbnRvIEF1dGhlbnRpY2F0aW9uIFRva2Vucy4g
UGVyaGFwcyBhIGxpdHRsZSBmdXJ0aGVyIGJhY2stYW5kLWZvcnRoIHdpdGggQnJpYW4gd2lsbCBy
ZXNvbHZlIHRoaXMuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIGNhbiBnbyBpbnRv
IGRlZXBlciBkZXRhaWwgaWYgbmVlZGVkLiBJZiB0aGlzIGlzIG9mZi10b3BpYyBmb3IgdGhlIE9B
dXRoIHdvcmtpbmcgZ3JvdXAsIGxldCBtZSBrbm93LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N
CjxkaXY+VGhhbmtzLDwvZGl2Pg0KPGRpdj5BbmRyZXcgRnJlZ2x5PC9kaXY+DQo8ZGl2PlZlcmlz
aWduIEluYy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k
aXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1m
YW1pbHk6Q2FsaWJyaTsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZvbnQtc2l6ZTox
MnB0OyB0ZXh0LWFsaWduOmxlZnQ7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb2xv
cjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElO
Ry1SSUdIVDoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDBpbjsgQk9SREVSLVRPUDog
I2I1YzRkZiAxcHQgc29saWQ7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCT1JERVIt
UklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDoNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFu
PkpvaG4gQnJhZGxleSAmbHQ7PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBjbGFzcz0ibW96LXR4
dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iPnZlN2p0
YkB2ZTdqdGIuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+
RGF0ZTogPC9zcGFuPlR1ZXNkYXksIEFwcmlsIDE5LCAyMDE2IGF0IDI6MDYgUE08YnI+DQo8c3Bh
biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5BbmRyZXcgRnJlZ2x5ICZsdDs8
YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQi
IGhyZWY9Im1haWx0bzphZnJlZ2x5QHZlcmlzaWduLmNvbSI+YWZyZWdseUB2ZXJpc2lnbi5jb208
L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPiZx
dW90OzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZp
YXRlZCIgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj48L2E+PGEgY2xhc3M9Im1vei10eHQt
bGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRm
Lm9yZzwvYT4mcXVvdDsgJmx0OzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRv
Om9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9
ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW09BVVRILVdHXSBCdWlsZGlu
ZyBvbiB0aGUgcHJvdG9jb2wgaW4gdGhlIGRyYWZ0IOKAnE9BdXRoIDIuMCBUb2tlbiBFeGNoYW5n
ZTogQW4gU1RTIGZvciB0aGUgUkVTVCBvZiBVc+KAnSB0byBpbmNsdWRlIEF1dGhlbnRpY2F0aW9u
IFRva2Vuczxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJN
QUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNi
NWM0ZGYgNSBzb2xpZDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBBRERJTkc6MCAw
IDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJy
ZWFrLXdvcmQ7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLXdlYmtpdC1uYnNw
LW1vZGU6IHNwYWNlOw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC13ZWJraXQt
bGluZS1icmVhazoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhZnRlci13aGl0
ZS1zcGFjZTsiIGNsYXNzPSIiPg0KTG9va2luZyBhdCBPcGVuSUQgQ29ubmVjdCBhbmQgaXTigJlz
IHRydXN0IG1vZGVsIGZvciBwcm9kdWNpbmcgaWRfdG9rZW5zIHRoYXQgYXNzZXJ0IGlkZW50aXR5
IG1heSBoZWxwIHlvdS4NCjxkaXYgY2xhc3M9IiI+PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBo
cmVmPSJodHRwOi8vb3BlbmlkLm5ldC93Zy9jb25uZWN0LyIgY2xhc3M9IiI+PC9hPjxhIGNsYXNz
PSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHA6Ly9vcGVuaWQubmV0L3dnL2Nvbm5l
Y3QvIj5odHRwOi8vb3BlbmlkLm5ldC93Zy9jb25uZWN0LzwvYT48YnIgY2xhc3M9IiI+DQo8ZGl2
IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5VbmZvcnR1bmF0
ZWx5IEkgY2Fu4oCZdCBxdWl0ZSBtYWtlIG91dCB3aGF0IHlvdSBhcmUgdHJ5aW5nIHRvIGRvLiZu
YnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh
c3M9IiI+SXQgc29ydCBvZiBzb3VuZHMgbGlrZSB5b3Ugd2FudCBhbiBpZF90b2tlbiBmcm9tIGEg
aWRQIGFuZCB0aGVuIGhhdmUgdGhlIGNsaWVudCBleGNoYW5nZSB0aGF0IGFzc2VydGlvbiBmb3Ig
YW5vdGhlciB0b2tlbj88L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+
DQo8ZGl2IGNsYXNzPSIiPkpvaG4gQi48YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUg
dHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIEFwciAxOSwgMjAxNiwgYXQg
MToxOCBQTSwgRnJlZ2x5LCBBbmRyZXcgJmx0OzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgY2xh
c3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOmFmcmVnbHlAdmVyaXNp
Z24uY29tIj48L2E+PGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFp
bHRvOmFmcmVnbHlAdmVyaXNpZ24uY29tIj5hZnJlZ2x5QHZlcmlzaWduLmNvbTwvYT4mZ3Q7IHdy
b3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYg
Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseToNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBDYWxpYnJpLCBzYW5zLXNlcmlmOw0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZvbnQtc2l6ZTogMTRweDsNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmb250LXN0eWxlOiBu
b3JtYWw7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZm9u
dC12YXJpYW50LWNhcHM6IG5vcm1hbDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBmb250LXdlaWdodDogbm9ybWFsOw0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIGxldHRlci1zcGFjaW5nOiBub3JtYWw7DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb3JwaGFuczogYXV0bzsgdGV4
dC1hbGlnbjoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBz
dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICB0ZXh0LXRyYW5zZm9ybTogbm9uZTsNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICB3aGl0ZS1zcGFjZTogbm9ybWFsOw0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdpZG93czogYXV0bzsNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3b3JkLXNwYWNpbmc6IDBw
eDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtd2Via2l0
LXRleHQtc3Ryb2tlLXdpZHRoOg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIDBweDsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDBpbiAwLjAwMDFwdDsg
Zm9udC1zaXplOg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgMTJwdDsgZm9udC1mYW1pbHk6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBDYWxpYnJpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl
Og0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAxMnB0
OyIgY2xhc3M9IiI+SSBoYXZlIGEgdXNlIGNhc2Ugd2hlcmUgYSBjbGllbnQgYXBwbGljYXRpb24g
bmVlZHMgdG8gYXV0aGVudGljYXRlIHdpdGggYSBkeW5hbWljYWxseSBkZXRlcm1pbmVkIElkZW50
aXR5IFByb3ZpZGVyIHRoYXQgaXMgc2VwYXJhdGUgZnJvbSB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2
aWNlIHRoYXQNCiB3aWxsIGJlIHVzZWQgaXNzdWUgYW4gYWNjZXNzIHRva2VuIHRvIHRoZSBjbGll
bnQuIFRoZSB1c2UgY2FzZSBhbHNvIHJlcXVpcmVzIHRoYXQgYXMgcGFydCBvZiBhdXRob3JpemF0
aW9uLCB0aGUgY2xpZW50IHByb3ZpZGVzIHRvIHRoZSBBdXRob3JpemF0aW9uIFNlcnZpY2UgYW4g
YXV0aGVudGljYXRpb24gdG9rZW4gc2lnbmVkIGJ5IGFuIElkZW50aXR5IFByb3ZpZGVyIHRoYXQg
dGhlIEF1dGhvcml6YXRpb24gU2VydmljZSBoYXMgYSB0cnVzdCByZWxhdGlvbnNoaXANCiB3aXRo
LiBUaGUgdHJ1c3QgcmVsYXRpb25zaGlwIGlzIHZlcmlmaWFibGUgYmFzZWQgb24gdGhlIEF1dGhv
cml6YXRpb24gU2VydmljZSBoYXZpbmcgcmVjb3JkZWQgdGhlIHB1YmxpYyBrZXlzIG9yIGNlcnRp
ZmljYXRlcyBvZiB0cnVzdGVkIElkZW50aXR5IFByb3ZpZGVycyBpbiBhIHRydXN0IHN0b3JlLCB0
aGlzIGFsbG93aW5nIHRoZSBBdXRob3JpemF0aW9uIFNlcnZpY2UgdG8gdmVyaWZ5IGFuIElkZW50
aXR5IFByb3ZpZGVy4oCZcyBzaWduYXR1cmUNCiBvbiBhbiBhdXRoZW50aWNhdGlvbiB0b2tlbi48
L3NwYW4+PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBuYW1lPSJPTEVfTElOSzUiIGNsYXNzPSIi
PjwvYT48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEycHQ7IGZvbnQt
ZmFtaWx5Og0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Q2FsaWJyaTsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5
bGU9Im1hcmdpbjogMGluDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIDEycHQ7IGZvbnQtZmFtaWx5Og0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2FsaWJyaTsiIGNsYXNzPSIiPg0K
PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwaW4gMC4w
MDAxcHQ7IGZvbnQtc2l6ZToNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIDEycHQ7IGZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgQ2FsaWJyaTsiIGNsYXNzPSIiPg0KSW4gbG9va2luZyBhdCB0
aGUgdmFyaW91cyBPQXV0aCBSRkNzLCBwYXJ0aWN1bGFybHkgUkZDcyA3NTIxLCA3NTIyLCBhbmQg
NzUyMywgSSBzZWUgdGhhdCB0aGV5IGdldCBtZSBjbG9zZSBpbiB0ZXJtcyBvZiBzdXBwb3J0aW5n
IHRoZSB1c2UgY2FzZS4gV2hhdCBpcyBtaXNzaW5nIGlzIGEgbWVhbnMgZm9yIHNvbHZpbmcgdGhl
IGZvbGxvd2luZyBwcm9ibGVtLiBUaGVzZSBSRkNzIHJlcXVpcmUgdGhhdCB0aGUgSWRlbnRpdHkg
UHJvdmlkZXIgcHV0IGFuDQogQXVkaWVuY2UgY2xhaW0gaW4gdGhlIGF1dGhlbnRpY2F0aW9uIHRv
a2VuLiBUaGUgcHJvYmxlbSB3aXRoIHRoaXMgaXMgdGhhdCBJIGRvIG5vdCBzZWUgaW4gdGhlIFJG
Q3MgaG93IHRoZSBJZGVudGl0eSBQcm92aWRlciBjYW4gYmUgdG9sZCB3aG8gdGhlIEF1ZGllbmNl
IGlzIHRvIHB1dCBpbnRvIHRoZSBhdXRoZW50aWNhdGlvbiB0b2tlbi4gVGhpcyBsZWFkcyBtZSB0
byB0aGUgdGl0bGUgb2YgdGhpcyBtZXNzYWdlLiBUaGUgZHJhZnQg4oCcT0F1dGgNCiAyLjAgVG9r
ZW4gRXhjaGFuZ2U6IEFuIFNUUyBmb3IgdGhlIFJFU1Qgb2YgVXPigJ0gZGVmaW5lcyBhIG1lY2hh
bmlzbSBmb3IgaWRlbnRpZnlpbmcgdGhlIEF1ZGllbmNlIGZvciBhbiBTVFMgdG8gcHV0IGludG8g
YSB0b2tlbiBpdCBnZW5lcmF0ZXMuIFRoYXQgd291bGQgc29sdmUgbXkgcHJvYmxlbSBleGNlcHQg
dGhhdCB0aGUgZHJhZnQgbGltaXRzIHRoZSB0eXBlIG9mIFNUUyB0byBiZWluZyBBdXRob3JpemF0
aW9uIFNlcnZlcnMuIFdoYXQgaXMgbmVlZGVkDQogaXMgdGhpcyBzYW1lIGNhcGFiaWxpdHkgZm9y
IGludGVyYWN0aW5nIHdpdGggYW4gSWRlbnRpdHkgUHJvdmlkZXIuIFRoaXMgd291bGQgZW5hYmxl
IFJGQ3MgNzUyMSwgNzUyMiBhbmQgNzUyMyB0byBiZSB1c2VmdWwgaW4gc2l0dWF0aW9uIHdoZXJl
IHRoZSBJZGVudGl0eSBQcm92aWRlciBuZWVkcyB0byBiZSB0b2xkIHRoZSBpZGVudGl0eSBvZiB0
aGUgQXV0aG9yaXphdGlvbiBTZXJ2aWNlLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2
IHN0eWxlPSJtYXJnaW46IDBpbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgMGluIDAuMDAwMXB0OyBmb250LXNpemU6DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAxMnB0OyBmb250LWZhbWlseToNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENhbGlicmk7IiBjbGFzcz0i
Ij4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46
IDBpbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMGlu
IDAuMDAwMXB0OyBmb250LXNpemU6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAxMnB0OyBmb250LWZhbWlseToNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIENhbGlicmk7IiBjbGFzcz0iIj4NCkkgYW0gbmV3IHRv
IGludGVyYWN0aW5nIHdpdGggdGhlIElFVEYuIEkgYWxzbyBhbSBub3QgYW4gZXhwZXJ0IG9uIHRo
ZSBSRkNzIG9yIHByaW9yIGhpc3Rvcnkgb2YgdGhlIE9BdXRoIGdyb3VwIHJlbGF0aXZlIHRvIHRo
aXMgdG9waWMsIHNvIHBsZWFzZSBwb2ludCBtZSB0byBhbnkgZXhpc3Rpbmcgc29sdXRpb24gaWYg
dGhpcyBpcyBhIHNvbHZlZCBwcm9ibGVtLiBPdGhlcndpc2UsIEkgd291bGQgbGlrZSB0byBnZXQg
ZmVlZGJhY2sgb24gbXkgc3VnZ2VzdGlvbi48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRp
diBzdHlsZT0ibWFyZ2luOiAwaW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMTJwdDsgZm9udC1mYW1pbHk6DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDYWxpYnJpOyIgY2xhc3M9
IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu
OiAwaW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDBp
biAwLjAwMDFwdDsgZm9udC1zaXplOg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgMTJwdDsgZm9udC1mYW1pbHk6DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBDYWxpYnJpOyIgY2xhc3M9IiI+DQpUaGFua3MgWW91
LDwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMTJwdDsgZm9udC1mYW1p
bHk6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDYWxp
YnJpOyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp
bjogMGluDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAw
aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZToNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIDEycHQ7IGZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2FsaWJyaTsiIGNsYXNzPSIiPg0KQW5kcmV3IEZy
ZWdseTxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMGluIDAuMDAw
MXB0OyBmb250LXNpemU6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAxMnB0OyBmb250LWZhbWlseToNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIENhbGlicmk7IiBjbGFzcz0iIj4NClZlcmlzaWduIEluYy48L2Rp
dj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2FsaWJyaSwgc2Fucy1zZXJpZjsNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmb250LXNpemU6IDE0cHg7DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZm9udC1zdHlsZTog
bm9ybWFsOw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZv
bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgZm9udC13ZWlnaHQ6IG5vcm1hbDsNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBsZXR0ZXItc3BhY2luZzogbm9ybWFsOw0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG9ycGhhbnM6IGF1dG87IHRl
eHQtYWxpZ246DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgdGV4dC10cmFuc2Zvcm06IG5vbmU7DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgd2hpdGUtc3BhY2U6IG5vcm1hbDsNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3aWRvd3M6IGF1dG87DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd29yZC1zcGFjaW5nOiAw
cHg7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLXdlYmtp
dC10ZXh0LXN0cm9rZS13aWR0aDoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAwcHg7IiBjbGFzcz0iIj4NCjwvZGl2Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5v
cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFu
czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm
b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu
ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNw
bGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2FsaWJyaSwgc2Fu
cy1zZXJpZjsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBm
b250LXNpemU6IDE0cHg7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgZm9udC1zdHlsZTogbm9ybWFsOw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZm9udC13ZWlnaHQ6IG5vcm1hbDsNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsZXR0ZXItc3BhY2lu
Zzogbm9ybWFsOw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGV4dC10cmFuc2Zvcm06IG5vbmU7DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd2hpdGUtc3BhY2U6
IG5vcm1hbDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3
aWRvd3M6IGF1dG87DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgd29yZC1zcGFjaW5nOiAwcHg7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDoNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBmb250
LXN0eWxlOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt
YWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0
ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3
b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDog
bm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5PQXV0aA0KIG1haWxp
bmcgbGlzdDwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIENhbGlicmksIHNhbnMtc2VyaWY7DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZm9udC1zaXplOiAxNHB4Ow0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZvbnQtc3R5bGU6
IG5vcm1hbDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBm
b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGZvbnQtd2VpZ2h0OiBub3JtYWw7DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvcnBoYW5zOiBhdXRvOyB0
ZXh0LWFsaWduOg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHRleHQtdHJhbnNmb3JtOiBub25lOw0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdoaXRlLXNwYWNlOiBub3JtYWw7DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd2lkb3dzOiBhdXRvOw0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdvcmQtc3BhY2luZzog
MHB4Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC13ZWJr
aXQtdGV4dC1zdHJva2Utd2lkdGg6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgMHB4OyIgY2xhc3M9IiI+DQo8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhy
ZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgc3R5bGU9ImZvbnQtZmFtaWx5Og0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENhbGlicmksIHNhbnMtc2VyaWY7
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZm9udC1zaXpl
OiAxNHB4Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZv
bnQtc3R5bGU6IG5vcm1hbDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOw0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIGZvbnQtd2VpZ2h0OiBub3JtYWw7DQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbGV0dGVyLXNwYWNpbmc6IG5vcm1h
bDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvcnBoYW5z
OiBhdXRvOyB0ZXh0LWFsaWduOg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4Ow0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHRleHQtdHJhbnNmb3JtOiBub25lOw0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdoaXRlLXNwYWNlOiBub3JtYWw7
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd2lkb3dzOiBh
dXRvOw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdvcmQt
c3BhY2luZzogMHB4Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgMHB4OyIgY2xhc3M9IiI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJy
IHN0eWxlPSJmb250LWZhbWlseToNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBDYWxpYnJpLCBzYW5zLXNlcmlmOw0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIGZvbnQtc2l6ZTogMTRweDsNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmb250LXN0eWxlOiBub3JtYWw7DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZm9udC12YXJpYW50LWNhcHM6
IG5vcm1hbDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBm
b250LXdlaWdodDogbm9ybWFsOw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGxldHRlci1zcGFjaW5nOiBub3JtYWw7DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjoNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdGFydDsgdGV4dC1pbmRl
bnQ6IDBweDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0
ZXh0LXRyYW5zZm9ybTogbm9uZTsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICB3aGl0ZS1zcGFjZTogbm9ybWFsOw0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHdpZG93czogYXV0bzsNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICB3b3JkLXNwYWNpbmc6IDBweDsNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtd2Via2l0LXRleHQtc3Ryb2tlLXdp
ZHRoOg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDBweDsi
IGNsYXNzPSIiPg0KPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiBzdHlsZT0iZm9udC1mYW1pbHk6DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2FsaWJyaSwgc2Fucy1z
ZXJpZjsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmb250
LXNpemU6IDE0cHg7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgZm9udC1zdHlsZTogbm9ybWFsOw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZm9udC13ZWlnaHQ6IG5vcm1hbDsNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsZXR0ZXItc3BhY2luZzog
bm9ybWFsOw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG9y
cGhhbnM6IGF1dG87IHRleHQtYWxpZ246DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGV4dC10cmFuc2Zvcm06IG5vbmU7DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd2hpdGUtc3BhY2U6IG5v
cm1hbDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3aWRv
d3M6IGF1dG87DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
d29yZC1zcGFjaW5nOiAwcHg7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDoNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAwcHg7IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k
aXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv
Y2txdW90ZT4NCjwvc3Bhbj48YnI+DQo8ZmllbGRzZXQgY2xhc3M9Im1pbWVBdHRhY2htZW50SGVh
ZGVyIj48L2ZpZWxkc2V0PiA8YnI+DQo8cHJlIHdyYXA9IiI+X19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KPGEgbW96LWRv
LW5vdC1zZW5kPSJ0cnVlIiBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJt
YWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxhIG1vei1kby1ub3Qtc2Vu
ZD0idHJ1ZSIgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aDwvYT48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxicj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+PC9ibG9ja3F1b3RlPg0KPGJyPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj48L2Jsb2NrcXVvdGU+DQo8YnI+DQo8
cHJlIGNsYXNzPSJtb3otc2lnbmF0dXJlIiBjb2xzPSI3MiI+LS0gDQpDaGllZiBBcmNoaXRlY3Qg
ICAgICAgICAgICAgICAgICAgDQpJZGVudGl0eSBTZXJ2aWNlcyBFbmdpbmVlcmluZyAgICAgV29y
azogPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOmdlb3Jn
ZS5mbGV0Y2hlckB0ZWFtYW9sLmNvbSI+Z2VvcmdlLmZsZXRjaGVyQHRlYW1hb2wuY29tPC9hPg0K
QU9MIEluYy4gICAgICAgICAgICAgICAgICAgICAgICAgIEFJTTogIGdmZmxldGNoDQpNb2JpbGU6
ICYjNDM7MS03MDMtNDYyLTM0OTQgICAgICAgICAgIFR3aXR0ZXI6IDxhIGNsYXNzPSJtb3otdHh0
LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHA6Ly90d2l0dGVyLmNvbS9nZmZsZXRjaCI+aHR0cDov
L3R3aXR0ZXIuY29tL2dmZmxldGNoPC9hPg0KT2ZmaWNlOiAmIzQzOzEtNzAzLTI2NS0yNTQ0ICAg
ICAgICAgICBQaG90b3M6IDxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0
dHA6Ly9nZW9yZ2VmbGV0Y2hlci5waG90b2dyYXBoeSI+aHR0cDovL2dlb3JnZWZsZXRjaGVyLnBo
b3RvZ3JhcGh5PC9hPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bh
bj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_F56B643467B14263B46742BDC940B14Bverisigncom_--


From nobody Wed Apr 20 12:25:39 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DCD12E3B3 for ; Wed, 20 Apr 2016 12:25:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltq8HU4AnuOe for ; Wed, 20 Apr 2016 12:25:36 -0700 (PDT)
Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F79B12D97E for ; Wed, 20 Apr 2016 12:25:36 -0700 (PDT)
Received: by mail-ig0-x22b.google.com with SMTP id g8so59479425igr.0 for ; Wed, 20 Apr 2016 12:25:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IghX+hGSP9pNjcE9avFbQvWPoGM4YN9T8RnOnJ8waQ4=; b=eY0BtFKx/9rHDB2c/XE1YkERaSFP2CmA1k3y52cGvl6wJJeUS3T9F/gPeec1OdnVll zXr0pto4bqnqlEIEDSELS51a6vFI5P6cOEujUd/egZfax28KBj4mt6CzMECwyI3qzZhb mc3N6PLmlvO8TXSULS0CQHkfNNYsbVttLaBCg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IghX+hGSP9pNjcE9avFbQvWPoGM4YN9T8RnOnJ8waQ4=; b=SPZBia8DhYC+kqANr9w0o120hgE+Bb5c7cf3xokGi0QH1k7pcRJk+Jac3AZtieGWZC 1cpmn6y2mBUhGofn45ijQN5eaos8fRfpoTQZocuYZWuMWa1ba0TFMflMYOl5mhg+qufD UuCZOrgA2Zm4euy1zIfDKo4Ezu/D4bzW2OyDYnU8sBpSHL6miy4r/IafwQ1Je8WdqdSk 7s8hDnU4ezPdNZlAj3KJR17mmHNyMuhfQAacg15y1kh+KNfcgsLxcLfSI3pm64QMpNcv aaSQl8RdzXjL1pVnY/5zYzjXuovYVXCL5YDMMBJ9l13RJrL+o85uRaoPnQlBd9J6mKe6 stvw==
X-Gm-Message-State: AOPr4FVhKHsB2dmjjS8vNhX6o+ZQ8v015JjPyiFr5Tr/TpNgepzunYNjGZLEnGa02Bcd9pksE9wuRTrao/KEC6/c
X-Received: by 10.50.108.131 with SMTP id hk3mr5665909igb.15.1461180335593; Wed, 20 Apr 2016 12:25:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.77.215 with HTTP; Wed, 20 Apr 2016 12:25:06 -0700 (PDT)
In-Reply-To: <97FB56BD-0990-4A46-AA98-B0E5C2A8994C@verisign.com>
References:    <97FB56BD-0990-4A46-AA98-B0E5C2A8994C@verisign.com>
From: Brian Campbell 
Date: Wed, 20 Apr 2016 13:25:06 -0600
Message-ID: 
To: "Fregly, Andrew" 
Content-Type: multipart/alternative; boundary=f46d0402ddeedb724f0530ef8ed3
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] =?utf-8?q?Building_on_the_protocol_in_the_draft_?= =?utf-8?q?=E2=80=9COAuth_2=2E0_Token_Exchange=3A_An_STS_for_the_REST_of_U?= =?utf-8?q?s=E2=80=9D_to_include_Authentication_Tokens?=
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Apr 2016 19:25:39 -0000

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

And that Identity Provider organization could also have it's own
authorization server that could act as an STS. That's all I was trying to
say. I'm not sure if that would help your case.

On Tue, Apr 19, 2016 at 2:19 PM, Fregly, Andrew 
wrote:

> Brian,
>
> Once again, thank you for your input. Per my prior response to John
> Bradley, our use case has the Identity Provider being provided by a
> different organization than the organization providing the Authorization
> Service.
>
> Thanks,
>      Andy
>
> From: Brian Campbell 
> Date: Tuesday, April 19, 2016 at 2:30 PM
> To: John Bradley 
> Cc: Andrew Fregly , "oauth@ietf.org"  >
> Subject: Re: [OAUTH-WG] Building on the protocol in the draft =E2=80=9COA=
uth 2.0
> Token Exchange: An STS for the REST of Us=E2=80=9D to include Authenticat=
ion Tokens
>
> The Token Exchange draft does put the Authorization Server (AS) in the
> role of STS because it's an extension of OAuth. But that shouldn't be
> viewed as limiting. An AS is often deployed as one part of an Identity
> Provider. OpenID Connect, as John mentioned, is one standard that combine=
s
> the roles. And many products/services/deployments have an AS as part of
> their overall Identity Provider offering, which might also have OpenID
> Connect, SAML, etc.
>
> On Tue, Apr 19, 2016 at 12:06 PM, John Bradley  wrote:
>
>> Looking at OpenID Connect and it=E2=80=99s trust model for producing id_=
tokens
>> that assert identity may help you.
>> http://openid.net/wg/connect/
>>
>> Unfortunately I can=E2=80=99t quite make out what you are trying to do.
>>
>> It sort of sounds like you want an id_token from a idP and then have the
>> client exchange that assertion for another token?
>>
>> John B.
>>
>> On Apr 19, 2016, at 1:18 PM, Fregly, Andrew  wrote=
:
>>
>> I have a use case where a client application needs to authenticate with =
a
>> dynamically determined Identity Provider that is separate from the
>> Authorization Service that will be used issue an access token to the
>> client. The use case also requires that as part of authorization, the
>> client provides to the Authorization Service an authentication token sig=
ned
>> by an Identity Provider that the Authorization Service has a trust
>> relationship with. The trust relationship is verifiable based on the
>> Authorization Service having recorded the public keys or certificates of
>> trusted Identity Providers in a trust store, this allowing the
>> Authorization Service to verify an Identity Provider=E2=80=99s signature=
 on an
>> authentication token.
>>
>> In looking at the various OAuth RFCs, particularly RFCs 7521, 7522, and
>> 7523, I see that they get me close in terms of supporting the use case.
>> What is missing is a means for solving the following problem. These RFCs
>> require that the Identity Provider put an Audience claim in the
>> authentication token. The problem with this is that I do not see in the
>> RFCs how the Identity Provider can be told who the Audience is to put in=
to
>> the authentication token. This leads me to the title of this message. Th=
e
>> draft =E2=80=9COAuth 2.0 Token Exchange: An STS for the REST of Us=E2=80=
=9D defines a
>> mechanism for identifying the Audience for an STS to put into a token it
>> generates. That would solve my problem except that the draft limits the
>> type of STS to being Authorization Servers. What is needed is this same
>> capability for interacting with an Identity Provider. This would enable
>> RFCs 7521, 7522 and 7523 to be useful in situation where the Identity
>> Provider needs to be told the identity of the Authorization Service.
>>
>> I am new to interacting with the IETF. I also am not an expert on the
>> RFCs or prior history of the OAuth group relative to this topic, so plea=
se
>> point me to any existing solution if this is a solved problem. Otherwise=
, I
>> would like to get feedback on my suggestion.
>>
>> Thanks You,
>>
>> Andrew Fregly
>> Verisign Inc.
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>

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


And that Identity Provider organization could also have it=
's own authorization server that could act as an STS. That's all I =
was trying to say. I'm not sure if that would help your case. 

On Tue, Apr 19, =
2016 at 2:19 PM, Fregly, Andrew <afregly@verisign.com> wr=
ote:











Brian,







Once again, thank you for your input. Per my prior response to John Br=
adley, our use case has the Identity Provider being provided by a different=
 organization than the organization providing the Authorization Service.=C2=
=A0







Thanks,


=C2=A0 =C2=A0 =C2=A0Andy



















From: Brian Campbell <bcampbell@pingidentit=
y.com>

Date: Tuesday, April 19, 2016 at 2:=
30 PM

To: John Bradley <ve7jtb@ve7jtb.com>

Cc: Andrew Fregly <afregly@verisign.com>, =
"oauth@ietf.org" <oauth@ietf.=
org>

Subject: Re: [OAUTH-WG] Building on=
 the protocol in the draft =E2=80=9COAuth 2.0 Token Exchange: An STS for th=
e REST of Us=E2=80=9D to include Authentication Tokens















The Token Exchange draft does put the Authorization Server=
 (AS) in the role of STS because it's an extension of OAuth. But that s=
houldn't be viewed as limiting. An AS is often deployed as one part of =
an Identity Provider. OpenID Connect, as John
 mentioned, is one standard that combines the roles. And many products/serv=
ices/deployments have an AS as part of their overall Identity Provider offe=
ring, which might also have OpenID Connect, SAML, etc.








On Tue, Apr 19, 2016 at 12:06 PM, John Bradley <=
span dir=3D"ltr">
<ve7jtb@ve7jtb.co=
m> wrote:




Looking at OpenID Connect and it=E2=80=
=99s trust model for producing id_tokens that assert identity may help you.

http://ope=
nid.net/wg/connect/







Unfortunately I can=E2=80=99t quite make out what you are trying to do=
.=C2=A0







It sort of sounds like you want an id_token from a idP and then have t=
he client exchange that assertion for another token?







John B.










On Apr 19, 2016, at 1:18 PM, Fregly, Andrew <afregly@verisign.com> wrote:















<=
span style=3D"font-size:12pt">I have a use case where a client application =
needs to authenticate with a dynamically determined Identity Provider that =
is separate from the Authorization Service
 that will be used issue an access token to the client. The use case also r=
equires that as part of authorization, the client provides to the Authoriza=
tion Service an authentication token signed by an Identity Provider that th=
e Authorization Service has a trust
 relationship with. The trust relationship is verifiable based on the Autho=
rization Service having recorded the public keys or certificates of trusted=
 Identity Providers in a trust store, this allowing the Authorization Servi=
ce to verify an Identity Provider=E2=80=99s
 signature on an authentication token.


<=
u>


<=
u>=C2=A0


I=
n looking at the various OAuth RFCs, particularly RFCs 7521, 7522, and 7523=
, I see that they get me close in terms of supporting the use case. What is=
 missing is a means for solving the
 following problem. These RFCs require that the Identity Provider put an Au=
dience claim in the authentication token. The problem with this is that I d=
o not see in the RFCs how the Identity Provider can be told who the Audienc=
e is to put into the authentication
 token. This leads me to the title of this message. The draft =E2=80=9COAut=
h 2.0 Token Exchange: An STS for the REST of Us=E2=80=9D defines a mechanis=
m for identifying the Audience for an STS to put into a token it generates.=
 That would solve my problem except that the draft
 limits the type of STS to being Authorization Servers. What is needed is t=
his same capability for interacting with an Identity Provider. This would e=
nable RFCs 7521, 7522 and 7523 to be useful in situation where the Identity=
 Provider needs to be told the identity
 of the Authorization Service.


<=
u>=C2=A0


I=
 am new to interacting with the IETF. I also am not an expert on the RFCs o=
r prior history of the OAuth group relative to this topic, so please point =
me to any existing solution if this
 is a solved problem. Otherwise, I would like to get feedback on my suggest=
ion.


<=
u>=C2=A0


T=
hanks You,


<=
br>



A=
ndrew Fregly


V=
erisign Inc.













_______________________________________________=


OAuth
 mailing list

OAuth@ietf.org

https://www.ietf.org/m=
ailman/listinfo/oauth















_______________________________________________

OAuth mailing list

OAuth@ietf.org

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


























--f46d0402ddeedb724f0530ef8ed3--


From nobody Fri Apr 22 07:20:51 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3089B12D9D7 for ; Fri, 22 Apr 2016 07:20:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.196
X-Spam-Level: 
X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BmNMhwe40Yj for ; Fri, 22 Apr 2016 07:20:47 -0700 (PDT)
Received: from mx2.uni-trier.de (mx2.uni-trier.de [136.199.224.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D83A12D60C for ; Fri, 22 Apr 2016 07:20:45 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.24,517,1454972400"; d="scan'208";a="18795106"
Received: from rzmail.uni-trier.de ([136.199.8.220]) by mx2i.uni-trier.de with ESMTP; 22 Apr 2016 16:20:43 +0200
Received: from [136.199.52.39] (infsec39.uni-trier.de [136.199.52.39]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by rzmail.uni-trier.de (Postfix) with ESMTPSA id ECB15403DA; Fri, 22 Apr 2016 16:20:43 +0200 (CEST)
From: Daniel Fett 
X-Enigmail-Draft-Status: N1110
To: oauth@ietf.org
Message-ID: <571A3339.706@uni-trier.de>
Date: Fri, 22 Apr 2016 16:20:41 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: Guido Schmitz , Ralf Kuesters 
Subject: [OAUTH-WG] State Leakage Attack
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Apr 2016 14:20:50 -0000

Hi all,

During our formal analysis of OAuth we found an attack that allows
CSRF. It is similar to the "code" leak described by Homakov in [1] and
therefore not really surprising. In this attack, the intention for an
attacker is to steal the "state" value instead of the "code" value.

Setting:

In the auth code grant, after authentication to the AS, the user is
redirected to some page on the Client. If this page leaks the
referrer, i.e., there is a link to the attacker's website or some
resource is loaded from the attacker, then the attacker can see not
only code but also state in the Referer header of the request.

The fact that code can leak was described in [1]. Since code is
single-use, it might be already redeemed in most cases when it is sent
to the attacker.

State, however, is not limited to a single use (by 6749 or others) and
therefore can be used by the attacker to mount a CSRF attack and
inject his own code into a (new) auth code grant.

We suggest
a) making state single use, and
b) highlighting to developers the importance of non-leaky redirection
endpoints, and to this end
c) recommending the use of "referrer policies" [2] to mitigate such attacks.

Could somebody confirm whether this attack is new?

Cheers,
Daniel, Guido, and Ralf

[1] http://homakov.blogspot.de/2014/02/how-i-hacked-github-again.html
[2] https://w3c.github.io/webappsec-referrer-policy/
-- 
Informationssicherheit und Kryptografie
Universität Trier - Tel. 0651 201 2847 - H436


From nobody Fri Apr 22 07:23:31 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E234412D8DB for ; Fri, 22 Apr 2016 07:23:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.196
X-Spam-Level: 
X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8pkcOHhcsO6 for ; Fri, 22 Apr 2016 07:23:30 -0700 (PDT)
Received: from mx2.uni-trier.de (mx2.uni-trier.de [136.199.224.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C049912D896 for ; Fri, 22 Apr 2016 07:23:29 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.24,517,1454972400"; d="scan'208";a="18795141"
Received: from rzmail.uni-trier.de ([136.199.8.220]) by mx2i.uni-trier.de with ESMTP; 22 Apr 2016 16:23:28 +0200
Received: from [136.199.52.39] (infsec39.uni-trier.de [136.199.52.39]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by rzmail.uni-trier.de (Postfix) with ESMTPSA id 424FD403DA; Fri, 22 Apr 2016 16:23:28 +0200 (CEST)
To: oauth@ietf.org
From: Daniel Fett 
Message-ID: <571A33E0.6070401@uni-trier.de>
Date: Fri, 22 Apr 2016 16:23:28 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: Guido Schmitz , Ralf Kuesters 
Subject: [OAUTH-WG] Multi-AS State Re-Use
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Apr 2016 14:23:31 -0000

Hi all,

Besides the state leakage attack we found that another important fact
regarding state is underspecified: Each state value should only be
used for one run of the protocol, in particular, each AS should see a
different state in multi-AS settings. Clients might be tempted to
generate state once and then re-use each time a user wants to
authorize.

If state is re-used, given a setup where one Client allows users to
authorize using two AS, a potentially malicious AS learns the state
value that is valid for authorization at an honest AS. I.e., each AS
can mount a CSRF attack on the user using the other AS.

Just as the attack in the other mail, this is not a big deal in
practice, but should be discussed somewhere.

Cheers,
Daniel, Guido, and Ralf
-- 
Informationssicherheit und Kryptografie
Universität Trier - Tel. 0651 201 2847 - H436


From nobody Fri Apr 22 07:30:26 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF6112DFE7 for ; Fri, 22 Apr 2016 07:30:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level: 
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adobe.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEJ_4exQyWYj for ; Fri, 22 Apr 2016 07:30:22 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0084.outbound.protection.outlook.com [65.55.169.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC09912E0D1 for ; Fri, 22 Apr 2016 07:30:21 -0700 (PDT)
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=QqFkKdDW67WY4eNuzt0jEHE3ZiuKFBYug90bVU5m7Zw=; b=vfI3NuVO+O/2pZ+1603fWnCbmybxjxw5Qbk+LI/eamRZezKxxSHyoPwyCOjtFmM00e4OOqqF9whzyhrNnCYjT/53xv1NcrB+1w004Ab4rqas+xKv4yC2QZTHfKpvU4KozRpa+ZOZka1h0NjmNxLE7r+mhE69/KSAK3Ws1UfeL/A=
Received: from BY1PR0201MB1030.namprd02.prod.outlook.com (10.161.203.148) by BY1PR0201MB1032.namprd02.prod.outlook.com (10.161.203.15) with Microsoft SMTP Server (TLS) id 15.1.466.19; Fri, 22 Apr 2016 14:30:18 +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.0466.023; Fri, 22 Apr 2016 14:30:18 +0000
From: Antonio Sanso 
To: Daniel Fett 
Thread-Topic: [OAUTH-WG] State Leakage Attack
Thread-Index: AQHRnKIvywI6UG5TCU6Okf4H3S2YDZ+WDboA
Date: Fri, 22 Apr 2016 14:30:17 +0000
Message-ID: <8E6CA392-96B3-4DBE-8167-9FDD972A31A8@adobe.com>
References: <571A3339.706@uni-trier.de>
In-Reply-To: <571A3339.706@uni-trier.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: uni-trier.de; dkim=none (message not signed) header.d=none;uni-trier.de; dmarc=none action=none header.from=adobe.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [192.147.117.11]
x-ms-office365-filtering-correlation-id: 9bac61a1-6480-4afd-5d63-08d36abaa0cd
x-microsoft-exchange-diagnostics: 1; BY1PR0201MB1032; 5:zoX02WEmnF0rK/K9Xmz5u14edVXltQlqvX/BTfbEv6BGJ9RAyWKpNrdtT3JY+sKhoqnh4ll8L3OTmWuGV5HqPAvaNaxJuxYovDjR0gSvmzRWLNyDbiHIHKzDrpBRvlOCmSXJZWfF5iAtpsjfqV0u1olI+7agQnsCm7MohctSf6jMvuWQ+8PVlqoNf6DZUoyg; 24:yZkUxgy/+bfZAOcwejSKq1A7NP9GWwZIISdyZ2fYmr8ayf8kniE1G4suxx9jYA+wXu5vkjoyMnwTSJ4slgHcUhWZzGyVPYdxIRXKsSlb4Qs=; 7:OsCgw4Xe+ac5hpRAmKsHvg4fVuM2OyQsoO5R2oJWOjrpWiWPr6dIZiyTL2TjuI69sPRJzLs6kxi4a00m363s5MninjOoNAuwviAjVwWIJ59DFOmQcB7z7XLMQ+jmqfzRgVLVa4zglUfYFVZIa9MWzCTLH6iZZLX3quSiKjQOG/6k5/nPf0WUInGjZ/g0ujX7+ZP9Z/JCV+f/cXEYcA4UA+gTTNF0PSSNgY6IWzqQ5T8=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0201MB1032;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(220618547472400);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BY1PR0201MB1032; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0201MB1032; 
x-forefront-prvs: 0920602B08
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(53754006)(24454002)(1096002)(1220700001)(586003)(102836003)(6116002)(4326007)(5004730100002)(36756003)(189998001)(86362001)(3846002)(2906002)(110136002)(92566002)(3660700001)(10400500002)(83716003)(10090500001)(50986999)(76176999)(87936001)(2900100001)(2950100001)(81166005)(33656002)(15975445007)(54356999)(19580405001)(77096005)(66066001)(106116001)(11100500001)(122556002)(5002640100001)(3280700002)(19580395003)(5008740100001)(82746002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0201MB1032; H:BY1PR0201MB1030.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <44F069524A17F34298CE76ABF8C40CF3@namprd02.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2016 14:30:17.8177 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0201MB1032
Archived-At: 
Cc: Guido Schmitz , "oauth@ietf.org" , Ralf Kuesters 
Subject: Re: [OAUTH-WG] State Leakage Attack
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Apr 2016 14:30:24 -0000

hi Daniel

On Apr 22, 2016, at 4:20 PM, Daniel Fett  wrote:

> Hi all,
>=20
> During our formal analysis of OAuth we found an attack that allows
> CSRF. It is similar to the "code" leak described by Homakov in [1] and
> therefore not really surprising. In this attack, the intention for an
> attacker is to steal the "state" value instead of the "code" value.
>=20
> Setting:
>=20
> In the auth code grant, after authentication to the AS, the user is
> redirected to some page on the Client. If this page leaks the
> referrer, i.e., there is a link to the attacker's website or some
> resource is loaded from the attacker, then the attacker can see not
> only code but also state in the Referer header of the request.
>=20
> The fact that code can leak was described in [1]. Since code is
> single-use, it might be already redeemed in most cases when it is sent
> to the attacker.

probably is not redeemed instead, just because the redirect_uri is not the =
correct one.
The mitigation that good implemented AS use (also Github) is to follow sect=
ion 4.1.3 the OAuth core specification [RFC6749], in particular:

"ensure that the "redirect_uri" parameter is present if the "redirect_uri" =
parameter was included in the initial authorization request as described in=
 Section 4.1.1, and if included ensure that their values are identical."

regards

antonio


> State, however, is not limited to a single use (by 6749 or others) and
> therefore can be used by the attacker to mount a CSRF attack and
> inject his own code into a (new) auth code grant.
>=20
> We suggest
> a) making state single use, and
> b) highlighting to developers the importance of non-leaky redirection
> endpoints, and to this end
> c) recommending the use of "referrer policies" [2] to mitigate such attac=
ks.
>=20
> Could somebody confirm whether this attack is new?
>=20
> Cheers,
> Daniel, Guido, and Ralf
>=20
> [1] http://homakov.blogspot.de/2014/02/how-i-hacked-github-again.html
> [2] https://w3c.github.io/webappsec-referrer-policy/
> --=20
> Informationssicherheit und Kryptografie
> Universit=E4t Trier - Tel. 0651 201 2847 - H436
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Fri Apr 22 07:35:35 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23D812E3A7 for ; Fri, 22 Apr 2016 07:35:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.196
X-Spam-Level: 
X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrIQycELwmx8 for ; Fri, 22 Apr 2016 07:35:32 -0700 (PDT)
Received: from mx1.uni-trier.de (mx1.uni-trier.de [136.199.224.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACAEE12E3C3 for ; Fri, 22 Apr 2016 07:35:28 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.24,517,1454972400"; d="scan'208";a="20020538"
Received: from rzmail.uni-trier.de ([136.199.8.220]) by mx1i.uni-trier.de with ESMTP; 22 Apr 2016 16:35:26 +0200
Received: from [136.199.52.39] (infsec39.uni-trier.de [136.199.52.39]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by rzmail.uni-trier.de (Postfix) with ESMTPSA id F3423403DA; Fri, 22 Apr 2016 16:35:26 +0200 (CEST)
To: Antonio Sanso 
References: <571A3339.706@uni-trier.de> <8E6CA392-96B3-4DBE-8167-9FDD972A31A8@adobe.com>
From: Daniel Fett 
Message-ID: <571A36AE.5020105@uni-trier.de>
Date: Fri, 22 Apr 2016 16:35:26 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <8E6CA392-96B3-4DBE-8167-9FDD972A31A8@adobe.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: Guido Schmitz , "oauth@ietf.org" , Ralf Kuesters 
Subject: Re: [OAUTH-WG] State Leakage Attack
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Apr 2016 14:35:34 -0000

Hi Antonio,

Am 22.04.2016 um 16:30 schrieb Antonio Sanso:
>> Hi all,
>>
>> During our formal analysis of OAuth we found an attack that allows
>> CSRF. It is similar to the "code" leak described by Homakov in [1] and
>> therefore not really surprising. In this attack, the intention for an
>> attacker is to steal the "state" value instead of the "code" value.
>>
>> Setting:
>>
>> In the auth code grant, after authentication to the AS, the user is
>> redirected to some page on the Client. If this page leaks the
>> referrer, i.e., there is a link to the attacker's website or some
>> resource is loaded from the attacker, then the attacker can see not
>> only code but also state in the Referer header of the request.
>>
>> The fact that code can leak was described in [1]. Since code is
>> single-use, it might be already redeemed in most cases when it is sent
>> to the attacker.
> 
> probably is not redeemed instead, just because the redirect_uri is not the correct one.
> The mitigation that good implemented AS use (also Github) is to follow section 4.1.3 the OAuth core specification [RFC6749], in particular:
> 
> "ensure that the "redirect_uri" parameter is present if the "redirect_uri" parameter was included in the initial authorization request as described in Section 4.1.1, and if included ensure that their values are identical."

The attack is not based on a manipulation of the redirect_uri. Instead,
a correct redirect_uri is used, but the page loaded from the
redirect_uri contains links or external resources (intentionally or not).

- Daniel



-- 
Informationssicherheit und Kryptografie
Universität Trier - Tel. 0651 201 2847 - H436


From nobody Fri Apr 22 07:40:09 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E3112DC91 for ; Fri, 22 Apr 2016 07:40:07 -0700 (PDT)
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 autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adobe.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxoo3osAJglQ for ; Fri, 22 Apr 2016 07:40:04 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0672.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:672]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5BED12DAB1 for ; Fri, 22 Apr 2016 07:40:03 -0700 (PDT)
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=L8fxp0E6cswi8o/eBAKUnKz9GpdTd+k7B9LxsRHUghs=; b=hYZvHr99onehF49vvkdGMr0s9NdKdhPJ5ZGBB6fQ8xLI5fNFs0OffYoE7Y3X7VRKiQ/I9R/DsH/F3WSp/53Cj1CbXNCOFpp6eQtayTU6FoRr8gx2Ka+V/oypdshkM7wmUBiB+xgu3O9oFzOqY6d71FB+N+xn5Om1JSkayYvLpos=
Received: from BY1PR0201MB1030.namprd02.prod.outlook.com (10.161.203.148) by BY1PR0201MB1029.namprd02.prod.outlook.com (10.161.203.147) with Microsoft SMTP Server (TLS) id 15.1.466.19; Fri, 22 Apr 2016 14:39:46 +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.0466.023; Fri, 22 Apr 2016 14:39:46 +0000
From: Antonio Sanso 
To: Daniel Fett 
Thread-Topic: [OAUTH-WG] State Leakage Attack
Thread-Index: AQHRnKIvywI6UG5TCU6Okf4H3S2YDZ+WDboAgAABbQCAAAE4AA==
Date: Fri, 22 Apr 2016 14:39:45 +0000
Message-ID: 
References: <571A3339.706@uni-trier.de> <8E6CA392-96B3-4DBE-8167-9FDD972A31A8@adobe.com> <571A36AE.5020105@uni-trier.de>
In-Reply-To: <571A36AE.5020105@uni-trier.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: uni-trier.de; dkim=none (message not signed) header.d=none;uni-trier.de; dmarc=none action=none header.from=adobe.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [192.147.117.12]
x-ms-office365-filtering-correlation-id: 67dd0486-d19c-40b8-561d-08d36abbf334
x-microsoft-exchange-diagnostics: 1; BY1PR0201MB1029; 5:zFvANlvOWBlhV8vQErz7ueUM9s8c/+JmR1Xs77Xy5TLPCxeI+CwVXwp0Y/nQEBaf0k0KURTWm43ttUnc+KXaRB7Fw2OhDcCcNglYoH39riuuZTUU43aSyjuydRzB1kUOcTCa6t6Mwj55NHmLv6vjsPB76u0dseyMvP6sQ9bCemILBLASov8ufYNKbvMio2HS; 24:7SQlq9euWvuhQTN6CEsG9B2Yz3AGBy7e3O/ewd35Klrnlfk+eVaPIVi9gkJFtt7H0/UOdjie4odZDoDQ5yKgAlIfJho9hl7TPg7g0zRtVJk=; 7:sWZhBq1M8KkdJE1t+RZEmjcznMkauNmMHWN6TDT+dDAaWfoIcOCpNeb0uvCZc7j8fZi4LOb1lmiKYFrfrXmB+DaKGdbKnEqGsBXzk4nfyUmv0RkQIq4na6daZy6m/EBX37y1ZzyoG9B6jFYYmhf4c3awOGtIKSMZ6M1OmnGxjUoZ41hbpAyZT4AHUImTW+TujD9rZfJInGftCQ8EPZgNPnbKScBghFruefPTD1WT6Ks=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0201MB1029;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(220618547472400);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BY1PR0201MB1029; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0201MB1029; 
x-forefront-prvs: 0920602B08
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(24454002)(53754006)(19617315012)(2950100001)(33656002)(5002640100001)(2900100001)(11100500001)(5008740100001)(77096005)(19580405001)(5004730100002)(586003)(19580395003)(66066001)(50986999)(4326007)(15975445007)(76176999)(16236675004)(54356999)(81166005)(3846002)(92566002)(82746002)(106116001)(3280700002)(189998001)(102836003)(87936001)(110136002)(122556002)(86362001)(10400500002)(2906002)(10090500001)(3660700001)(83716003)(36756003)(1220700001)(1096002)(6116002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0201MB1029; H:BY1PR0201MB1030.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DEC7CA6F5C6B406F97B80675D1A7D24Fadobecom_"
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2016 14:39:45.8437 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0201MB1029
Archived-At: 
Cc: Guido Schmitz , "oauth@ietf.org" , Ralf Kuesters 
Subject: Re: [OAUTH-WG] State Leakage Attack
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Apr 2016 14:40:07 -0000

--_000_DEC7CA6F5C6B406F97B80675D1A7D24Fadobecom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

hi Daniel

On Apr 22, 2016, at 4:35 PM, Daniel Fett > wrote:

Hi Antonio,

Am 22.04.2016 um 16:30 schrieb Antonio Sanso:
Hi all,

During our formal analysis of OAuth we found an attack that allows
CSRF. It is similar to the "code" leak described by Homakov in [1] and
therefore not really surprising. In this attack, the intention for an
attacker is to steal the "state" value instead of the "code" value.

Setting:

In the auth code grant, after authentication to the AS, the user is
redirected to some page on the Client. If this page leaks the
referrer, i.e., there is a link to the attacker's website or some
resource is loaded from the attacker, then the attacker can see not
only code but also state in the Referer header of the request.

The fact that code can leak was described in [1]. Since code is
single-use, it might be already redeemed in most cases when it is sent
to the attacker.

probably is not redeemed instead, just because the redirect_uri is not the =
correct one.
The mitigation that good implemented AS use (also Github) is to follow sect=
ion 4.1.3 the OAuth core specification [RFC6749], in particular:

"ensure that the "redirect_uri" parameter is present if the "redirect_uri" =
parameter was included in the initial authorization request as described in=
 Section 4.1.1, and if included ensure that their values are identical."

The attack is not based on a manipulation of the redirect_uri. Instead,
a correct redirect_uri is used, but the page loaded from the
redirect_uri contains links or external resources (intentionally or not).

right. so is not really [1] :) since there there is manipulation using /../=
../
Now the real question why a legit redirect_uri should contain links to mali=
cious external resources?

regards

antonio

[1] http://homakov.blogspot.ch/2014/02/how-i-hacked-github-again.html


- Daniel



--
Informationssicherheit und Kryptografie
Universit=E4t Trier - Tel. 0651 201 2847 - H436


--_000_DEC7CA6F5C6B406F97B80675D1A7D24Fadobecom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <476E798103A236458F2360315B19F54C@namprd02.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable






hi Daniel






On Apr 22, 2016, at 4:35 PM, Daniel Fett <fett@uni-trier.de> wrote:




Hi Antonio,



Am 22.04.2016 um 16:30 schrieb Antonio Sanso:




Hi all,



During our formal analysis of OAuth we found an attack that allows

CSRF. It is similar to the "code" leak described by Homakov in [1=
] and

therefore not really surprising. In this attack, the intention for an

attacker is to steal the "state" value instead of the "code&=
quot; value.



Setting:



In the auth code grant, after authentication to the AS, the user is

redirected to some page on the Client. If this page leaks the

referrer, i.e., there is a link to the attacker's website or some

resource is loaded from the attacker, then the attacker can see not

only code but also state in the Referer header of the request.



The fact that code can leak was described in [1]. Since code is

single-use, it might be already redeemed in most cases when it is sent

to the attacker.





probably is not redeemed instead, just because the redirect_uri is not the =
correct one.

The mitigation that good implemented AS use (also Github) is to follow sect=
ion 4.1.3 the OAuth core specification [RFC6749], in particular:



"ensure that the "redirect_uri" parameter is present if the =
"redirect_uri" parameter was included in the initial authorizatio=
n request as described in Section 4.1.1, and if included ensure that their =
values are identical."





The attack is not based on a manipulation of the redirect_uri. Instead,

a correct redirect_uri is used, but the page loaded from the

redirect_uri contains links or external resources (intentionally or not).








right. so is not really [1] :) since there there is manipulation using=
 /../../ 


Now the real question why a legit redirect_uri should contain links to=
 malicious external resources?







regards







antonio












- Daniel







-- 

Informationssicherheit und Kryptografie

Universit=E4t Trier - Tel. 0651 201 2847 - H436












--_000_DEC7CA6F5C6B406F97B80675D1A7D24Fadobecom_--


From nobody Fri Apr 22 07:40:42 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1459E12DC91 for ; Fri, 22 Apr 2016 07:40:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.196
X-Spam-Level: 
X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5Qv-gnhWQO2 for ; Fri, 22 Apr 2016 07:40:12 -0700 (PDT)
Received: from mx1.uni-trier.de (mx1.uni-trier.de [136.199.224.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B5ED12E56B for ; Fri, 22 Apr 2016 07:40:12 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.24,517,1454972400"; d="scan'208";a="20020625"
Received: from rzmail.uni-trier.de ([136.199.8.220]) by mx1i.uni-trier.de with ESMTP; 22 Apr 2016 16:40:06 +0200
Received: from [136.199.52.39] (infsec39.uni-trier.de [136.199.52.39]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by rzmail.uni-trier.de (Postfix) with ESMTPSA id D5C293FFF3; Fri, 22 Apr 2016 16:40:06 +0200 (CEST)
To: Antonio Sanso 
References: <571A3339.706@uni-trier.de> <8E6CA392-96B3-4DBE-8167-9FDD972A31A8@adobe.com> <571A36AE.5020105@uni-trier.de>
From: Daniel Fett 
Message-ID: <571A37C6.6040007@uni-trier.de>
Date: Fri, 22 Apr 2016 16:40:06 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <571A36AE.5020105@uni-trier.de>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: Guido Schmitz , "oauth@ietf.org" , Ralf Kuesters 
Subject: Re: [OAUTH-WG] State Leakage Attack
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Apr 2016 14:40:21 -0000

Am 22.04.2016 um 16:35 schrieb Daniel Fett:
> The attack is not based on a manipulation of the redirect_uri. Instead,
> a correct redirect_uri is used, but the page loaded from the
> redirect_uri contains links or external resources (intentionally or not).

(This of course describes our attack, not the one by Homakov.)


-- 
Informationssicherheit und Kryptografie
Universität Trier - Tel. 0651 201 2847 - H436


From nobody Fri Apr 22 07:42:46 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9BF12D95B for ; Fri, 22 Apr 2016 07:42:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.196
X-Spam-Level: 
X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UK01X2yPP1MT for ; Fri, 22 Apr 2016 07:42:43 -0700 (PDT)
Received: from mx1.uni-trier.de (mx1.uni-trier.de [136.199.224.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED18912E1D5 for ; Fri, 22 Apr 2016 07:42:42 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.24,517,1454972400"; d="scan'208";a="20020662"
Received: from rzmail.uni-trier.de ([136.199.8.220]) by mx1i.uni-trier.de with ESMTP; 22 Apr 2016 16:42:41 +0200
Received: from [136.199.52.39] (infsec39.uni-trier.de [136.199.52.39]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by rzmail.uni-trier.de (Postfix) with ESMTPSA id B3B013FFF3; Fri, 22 Apr 2016 16:42:40 +0200 (CEST)
To: Antonio Sanso 
References: <571A3339.706@uni-trier.de> <8E6CA392-96B3-4DBE-8167-9FDD972A31A8@adobe.com> <571A36AE.5020105@uni-trier.de> 
From: Daniel Fett 
Message-ID: <571A3860.90609@uni-trier.de>
Date: Fri, 22 Apr 2016 16:42:40 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: Guido Schmitz , "oauth@ietf.org" , Ralf Kuesters 
Subject: Re: [OAUTH-WG] State Leakage Attack
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Apr 2016 14:42:45 -0000

Am 22.04.2016 um 16:39 schrieb Antonio Sanso:
> hi Daniel
> 
> On Apr 22, 2016, at 4:35 PM, Daniel Fett  > wrote:
> 
>> Hi Antonio,
>>
>> Am 22.04.2016 um 16:30 schrieb Antonio Sanso:
>>>> Hi all,
>>>>
>>>> During our formal analysis of OAuth we found an attack that allows
>>>> CSRF. It is similar to the "code" leak described by Homakov in [1] and
>>>> therefore not really surprising. In this attack, the intention for an
>>>> attacker is to steal the "state" value instead of the "code" value.
>>>>
>>>> Setting:
>>>>
>>>> In the auth code grant, after authentication to the AS, the user is
>>>> redirected to some page on the Client. If this page leaks the
>>>> referrer, i.e., there is a link to the attacker's website or some
>>>> resource is loaded from the attacker, then the attacker can see not
>>>> only code but also state in the Referer header of the request.
>>>>
>>>> The fact that code can leak was described in [1]. Since code is
>>>> single-use, it might be already redeemed in most cases when it is sent
>>>> to the attacker.
>>>
>>> probably is not redeemed instead, just because the redirect_uri is
>>> not the correct one.
>>> The mitigation that good implemented AS use (also Github) is to
>>> follow section 4.1.3 the OAuth core specification [RFC6749], in
>>> particular:
>>>
>>> "ensure that the "redirect_uri" parameter is present if the
>>> "redirect_uri" parameter was included in the initial authorization
>>> request as described in Section 4.1.1, and if included ensure that
>>> their values are identical."
>>
>> The attack is not based on a manipulation of the redirect_uri. Instead,
>> a correct redirect_uri is used, but the page loaded from the
>> redirect_uri contains links or external resources (intentionally or not).
> 
> right. so is not really [1] :) since there there is manipulation using
> /../../ 

Of course.

> Now the real question why a legit redirect_uri should contain links to
> malicious external resources?

Well, why not? :)

Anyway, developers should be made aware that having external
resources/links on these pages is a bad idea.

- Daniel

-- 
Informationssicherheit und Kryptografie
Universität Trier - Tel. 0651 201 2847 - H436


From nobody Fri Apr 22 07:47:13 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8B912E7D8 for ; Fri, 22 Apr 2016 07:47:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adobe.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fldo7vYiOgJG for ; Fri, 22 Apr 2016 07:47:08 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0060.outbound.protection.outlook.com [207.46.100.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D78AA12E7D4 for ; Fri, 22 Apr 2016 07:47:08 -0700 (PDT)
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=ov8vBvr273Dp4jK29VjqYV6tWYJTA8RoxQ0/vyhqsZ8=; b=d5BIcJzWJfaQJFWgLcDBXXMIVIEd1OYfEiihmblEh/JiuIiGXMSm/3EPqZMOzvlo0nXwlCnPI1hiIKmGyi5UNRQjbKD9C4UOONnowvlkBxb8uodQFsrtBrNrjGlJLqAP72JAO20Fi+wwuD9vBtuNmIusx9rJYagJ+0UqAZLs/E4=
Received: from BY1PR0201MB1030.namprd02.prod.outlook.com (10.161.203.148) by BY1PR0201MB1032.namprd02.prod.outlook.com (10.161.203.15) with Microsoft SMTP Server (TLS) id 15.1.466.19; Fri, 22 Apr 2016 14:47:07 +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.0466.023; Fri, 22 Apr 2016 14:47:07 +0000
From: Antonio Sanso 
To: Daniel Fett 
Thread-Topic: [OAUTH-WG] State Leakage Attack
Thread-Index: AQHRnKIvywI6UG5TCU6Okf4H3S2YDZ+WDboAgAABbQCAAAE4AIAAAM0AgAABQgA=
Date: Fri, 22 Apr 2016 14:47:07 +0000
Message-ID: 
References: <571A3339.706@uni-trier.de> <8E6CA392-96B3-4DBE-8167-9FDD972A31A8@adobe.com> <571A36AE.5020105@uni-trier.de>  <571A3860.90609@uni-trier.de>
In-Reply-To: <571A3860.90609@uni-trier.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: uni-trier.de; dkim=none (message not signed) header.d=none;uni-trier.de; dmarc=none action=none header.from=adobe.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [192.147.117.12]
x-ms-office365-filtering-correlation-id: f462932c-eb88-48c5-6cc0-08d36abcfa6b
x-microsoft-exchange-diagnostics: 1; BY1PR0201MB1032; 5:ZFpGE6NQO6rZNt5F3DAbATSVvzfBlctgQbIZbGLVIQFi29yVAHvyHK7d1K7f0dtrOhE6RUtfQVRDX7Hq+qKL6BTn9bhuDBRucXNP4fAfg2Pi94V6s0o4y9OIeET4rGgwgc2mcGETBc3/PYIGETKEJDCsh/oSvDnndsxLeeHNLXiBT+EXVQBsTcAmNZeMn/mV; 24:ZgfZzpXV/IWYB7xwqWXxmCgJYzt8jY9GnApYh7d6BeS8mK011oLAL2PuZjW1coxOhfDYvH1qeogPG3rZpBx0v5LBPX0uaqNxWu15mnckgmY=; 7:pvfQL1+H6Y+Djd3F8TmrJdHeEnrlvVd7jONt9J+eO+Eo7IiXgKYnuZIlYuLXHdTjqkO5rg4RMUogdTNrih82i3WK7fbx/4+Yhl0hxsRZBgQ8AQ3yAJhc/HjghsHYMf56Ox3/bC+zGFXeugah9QDMjWEyOegNpS7EG8lOlJccAR+O3uTOSMrl07Tk/YNA49NOpYseDr2k2JuxDKh0rZXVZFGHlSDt+KB9v3EqxRqNTKU=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0201MB1032;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(220618547472400);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BY1PR0201MB1032; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0201MB1032; 
x-forefront-prvs: 0920602B08
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(53754006)(24454002)(93886004)(15975445007)(77096005)(66066001)(106116001)(54356999)(19580405001)(2950100001)(81166005)(2900100001)(50986999)(76176999)(87936001)(33656002)(122556002)(3280700002)(82746002)(19580395003)(5008740100001)(5002640100001)(11100500001)(102836003)(6116002)(4326007)(586003)(5004730100002)(36756003)(16236675004)(19617315012)(1096002)(1220700001)(10400500002)(3660700001)(92566002)(10090500001)(83716003)(189998001)(86362001)(3846002)(2906002)(110136002)(16410355001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0201MB1032; H:BY1PR0201MB1030.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_B1D76620C0D042CBA74456D1437E1DF1adobecom_"
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2016 14:47:07.5393 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0201MB1032
Archived-At: 
Cc: Guido Schmitz , "oauth@ietf.org" , Ralf Kuesters 
Subject: Re: [OAUTH-WG] State Leakage Attack
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Apr 2016 14:47:10 -0000

--_000_B1D76620C0D042CBA74456D1437E1DF1adobecom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable


On Apr 22, 2016, at 4:42 PM, Daniel Fett > wrote:

Am 22.04.2016 um 16:39 schrieb Antonio Sanso:
hi Daniel

On Apr 22, 2016, at 4:35 PM, Daniel Fett 
> wrote:

Hi Antonio,

Am 22.04.2016 um 16:30 schrieb Antonio Sanso:
Hi all,

During our formal analysis of OAuth we found an attack that allows
CSRF. It is similar to the "code" leak described by Homakov in [1] and
therefore not really surprising. In this attack, the intention for an
attacker is to steal the "state" value instead of the "code" value.

Setting:

In the auth code grant, after authentication to the AS, the user is
redirected to some page on the Client. If this page leaks the
referrer, i.e., there is a link to the attacker's website or some
resource is loaded from the attacker, then the attacker can see not
only code but also state in the Referer header of the request.

The fact that code can leak was described in [1]. Since code is
single-use, it might be already redeemed in most cases when it is sent
to the attacker.

probably is not redeemed instead, just because the redirect_uri is
not the correct one.
The mitigation that good implemented AS use (also Github) is to
follow section 4.1.3 the OAuth core specification [RFC6749], in
particular:

"ensure that the "redirect_uri" parameter is present if the
"redirect_uri" parameter was included in the initial authorization
request as described in Section 4.1.1, and if included ensure that
their values are identical."

The attack is not based on a manipulation of the redirect_uri. Instead,
a correct redirect_uri is used, but the page loaded from the
redirect_uri contains links or external resources (intentionally or not).

right. so is not really [1] :) since there there is manipulation using
/../../

Of course.

Now the real question why a legit redirect_uri should contain links to
malicious external resources?

Well, why not? :)

Anyway, developers should be made aware that having external
resources/links on these pages is a bad idea.

agree about the awareness.
It is more likely that such a page contains resource/links e.g. in the form=
 of