From nobody Wed Jul 1 03:35:36 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7408C1A871B for ; Wed, 1 Jul 2015 03:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OuwuSAno3djb for ; Wed, 1 Jul 2015 03:35:33 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c: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 7BA5E1A8718 for ; Wed, 1 Jul 2015 03:35:33 -0700 (PDT) Received: by wiar9 with SMTP id r9so64591046wia.1 for ; Wed, 01 Jul 2015 03:35:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=gh3o8gbwjZEEehCLIEeUeMj8rsjwR+2mSC6jyaQ4VQ4=; b=KOcUYRUTZHqUKb9VE2ntoOc87MLtD9lq5/7X+aRdxv8vCtRiNB0tmqdr/ycX2dvBko tNDDSi/8wM+BmgmDm1QoHxIfaUb5debAx2Tah0etxr6Op5cHwrlMU7pHf4BMFmrADTVf ChGxNuWnzr1NFFwthfcguY9TYBUWh4fb68yP9cqPRcC1MvxGNuN7xFu9jAASH8aw2xJ+ C0ODpQeQTcFlx+sfxB0R7po+9lNcyoD5z7fTbOKngcqT7froyrZkSdHXe0Do5luJHD8E kGPPPNPGFzpwmiMThB/HRC68G/50ImImTSj89RXnswgmpvSdKiTZw/un3nnQBc0Lbksb M4cw== X-Received: by 10.194.220.100 with SMTP id pv4mr50750924wjc.71.1435746932258; Wed, 01 Jul 2015 03:35:32 -0700 (PDT) Received: from [10.36.226.2] ([80.169.137.63]) by mx.google.com with ESMTPSA id v3sm2208223wja.31.2015.07.01.03.35.28 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Jul 2015 03:35:31 -0700 (PDT) Message-ID: <5593C270.7000008@gmail.com> Date: Wed, 01 Jul 2015 11:35:28 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Mike Jones , "Vivek Biswas -T (vibiswas - XORIANT CORPORATION at Cisco)" , "OAuth@ietf.org" References: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> <55928DB3.7090300@gmail.com> In-Reply-To: <55928DB3.7090300@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 10:35:35 -0000 Hmm... perhaps the clue is in the draft title, token-exchange, so may be it is a case of the given access token ("on_behalf_of" or "act_as" claim) being used to request a new security token. One can only guess though, does not seem like the authors are keen to answer the newbie questions... Cheers, Sergey On 30/06/15 13:38, Sergey Beryozkin wrote: > Hi, > Can you please explain what is the difference between On-Behalf-Of > semantics described in the draft-ietf-oauth-token-exchange-01 and the > implicit On-Behalf-Of semantics a client OAuth2 token possesses ? > > For example, draft-ietf-oauth-token-exchange-01 mentions: > > "Whereas, with on-behalf-of semantics, principal A still has its own > identity separate from B and it is explicitly understood that while B > may have delegated its rights to A, any actions taken are being taken by > A and not B. In a sense, A is an agent for B." > > This is a typical case with the authorization code flow where a client > application acts on-behalf-of the user who authorized this application ? > > Sorry if I'm missing something > > Cheers, Sergey > On 25/06/15 22:28, Mike Jones wrote: >> That’s what >> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 is about. >> >> Cheers, >> >> -- Mike >> >> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Vivek Biswas >> -T (vibiswas - XORIANT CORPORATION at Cisco) >> *Sent:* Thursday, June 25, 2015 2:20 PM >> *To:* OAuth@ietf.org >> *Subject:* [OAUTH-WG] JWT Token on-behalf of Use case >> >> Hi All, >> >> I am looking to solve a use-case similar to WS-Security On-Behalf-Of >> >> >> with OAuth JWT Token. >> >> Is there a standard claim which we can define within the OAuth JWT >> which denote the On-behalf-of User. >> >> For e.g., a Customer Representative trying to create token on behalf of >> a customer and trying to execute services specific for that specific >> customer. >> >> Regards, >> >> Vivek Biswas, >> CISSP >> >> *Cisco Systems, Inc * >> >> *Bldg. J, San Jose, USA,* >> >> *Phone: +1 408 527 9176* >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > From nobody Wed Jul 1 05:18:17 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691951A1E0F for ; Wed, 1 Jul 2015 05:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVQsDSvdU3Y9 for ; Wed, 1 Jul 2015 05:18:14 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B5861A1DBC for ; Wed, 1 Jul 2015 05:18:13 -0700 (PDT) X-AuditID: 1209190c-f79296d000000622-cf-5593da846321 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id B1.77.01570.48AD3955; Wed, 1 Jul 2015 08:18:12 -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 t61CICTi021969 for ; Wed, 1 Jul 2015 08:18:12 -0400 Received: from [192.168.128.56] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t61CI9tE031639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 1 Jul 2015 08:18:12 -0400 Message-ID: <5593DA7D.80401@mit.edu> Date: Wed, 01 Jul 2015 08:18:05 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: oauth@ietf.org References: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> <55928DB3.7090300@gmail.com> <5593C270.7000008@gmail.com> In-Reply-To: <5593C270.7000008@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMIsWRmVeSWpSXmKPExsUixG6nrttya3KowaonJhYn375ic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxomPk9gKFkhX9Oy+wNbAOF+si5GDQ0LAROLk3uguRk4gU0zi wr31bF2MXBxCAouZJGb1zmKHcI4ySkxoWcIC4bxnknj7tIMRpIVXQEXi55xeZhCbRUBVonny ASYQmw3Inr6mBcwWFYiSmPp4HQtEvaDEyZlPwGwRASGJ5zv7wGqEBcwltjTtZ4RYcJVR4seb y+wgCU4BTYk/zz+zgtjMArYSd+buZoaw5SWat85mnsAoMAvJ3FlIymYhKVvAyLyKUTYlt0o3 NzEzpzg1Wbc4OTEvL7VI11AvN7NELzWldBMjKCw5JXl2ML45qHSIUYCDUYmHV0BscqgQa2JZ cWXuIUZJDiYlUV7Gm0AhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrxfpgLleFMSK6tSi/JhUtIc LErivJt+8IUICaQnlqRmp6YWpBbBZGU4OJQkeCeDDBUsSk1PrUjLzClBSDNxcIIM5wEaPhek hre4IDG3ODMdIn+KUVFKnHctSEIAJJFRmgfXC0sbrxjFgV4R5v1yA6iKB5hy4LpfAQ1mAhr8 0n4SyOCSRISUVAOj+0O1DB+Vx/qFJqJOQZ/qWnpzy1h3/nh/7VNv2aWX4r8fm/r/972ZG77y vmWsSWSF51sn0a+X7Fw5HMxkc89wB2sfv/y2U9Vr1XQ7X7XYk89cZuiyzg/5vTNyq9ppkfol nz133g+q3DajdtGn5MSSy0pTlTT2rNvfrbKYP29xaYe53/PoT5ZKLMUZiYZazEXFiQBSuFb3 9gIAAA== Archived-At: Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 12:18:16 -0000 As it's written right now, it's a translation of some WS-* concepts into JWT format. It's not really OAuth-y (since the client has to understand the token format along with everyone else, and according to the authors the artifacts might not even be "OAuth tokens"), and that's my main issue with the document. Years ago, I proposed an OAuth-based token swap mechanism: https://tools.ietf.org/html/draft-richer-oauth-chain-00 This works without defining semantics of the tokens themselves, just like the rest of OAuth. I've proposed to the authors of the current draft that it should incorporate both semantic (using JWT) and syntactic (using a simple token-agnostic grant) token swap mechanisms, and that the two could be easily compatible. -- Justin On 7/1/2015 6:35 AM, Sergey Beryozkin wrote: > Hmm... perhaps the clue is in the draft title, token-exchange, so may > be it is a case of the given access token ("on_behalf_of" or "act_as" > claim) being used to request a new security token. One can only guess > though, does not seem like the authors are keen to answer the newbie > questions... > > Cheers, Sergey > > > On 30/06/15 13:38, Sergey Beryozkin wrote: >> Hi, >> Can you please explain what is the difference between On-Behalf-Of >> semantics described in the draft-ietf-oauth-token-exchange-01 and the >> implicit On-Behalf-Of semantics a client OAuth2 token possesses ? >> >> For example, draft-ietf-oauth-token-exchange-01 mentions: >> >> "Whereas, with on-behalf-of semantics, principal A still has its own >> identity separate from B and it is explicitly understood that while B >> may have delegated its rights to A, any actions taken are being taken by >> A and not B. In a sense, A is an agent for B." >> >> This is a typical case with the authorization code flow where a client >> application acts on-behalf-of the user who authorized this application ? >> >> Sorry if I'm missing something >> >> Cheers, Sergey >> On 25/06/15 22:28, Mike Jones wrote: >>> That’s what >>> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 is >>> about. >>> >>> Cheers, >>> >>> -- Mike >>> >>> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Vivek >>> Biswas >>> -T (vibiswas - XORIANT CORPORATION at Cisco) >>> *Sent:* Thursday, June 25, 2015 2:20 PM >>> *To:* OAuth@ietf.org >>> *Subject:* [OAUTH-WG] JWT Token on-behalf of Use case >>> >>> Hi All, >>> >>> I am looking to solve a use-case similar to WS-Security On-Behalf-Of >>> >>> >>> >>> with OAuth JWT Token. >>> >>> Is there a standard claim which we can define within the OAuth JWT >>> which denote the On-behalf-of User. >>> >>> For e.g., a Customer Representative trying to create token on behalf of >>> a customer and trying to execute services specific for that specific >>> customer. >>> >>> Regards, >>> >>> Vivek Biswas, >>> CISSP >>> >>> *Cisco Systems, Inc * >>> >>> *Bldg. J, San Jose, USA,* >>> >>> *Phone: +1 408 527 9176* >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing 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 Jul 1 06:07:16 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFDC51A87E2 for ; Wed, 1 Jul 2015 06:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKILI-gq6sZr for ; Wed, 1 Jul 2015 06:07:13 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 565801A87BB for ; Wed, 1 Jul 2015 06:07:13 -0700 (PDT) Received: by wgqq4 with SMTP id q4so36363340wgq.1 for ; Wed, 01 Jul 2015 06:07:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=EeDYW2UagDbSCmTncGLh5a8hBVbMWEwTNIJGwNxGOkg=; b=pfDt/fpUfshgRZq7BtCNWArf82say8v4UAYe13zmepLr7SPINI03cGvNA9LEv/LHy8 nCtW9Z32WX6S2MfJRyrz4rp8p19slBpCBL1m1XfZ9kB5ooiESGY5E7JeK59JGwxicP22 IgfZVlGXxMw1ZjUz+MNVraeHpisHtIk7eQpTyXH87A7COk3d8mmbosCMcgn8+RLM6MXc mYQlssXwT/gI81sX6jpUefetcvNRLvT8sMbd8BMDtgBY4bByG53rRgOYNvh5olAQDwlf H1e4FqYiPU5sVO4UsA/b5ZTcXGE+HB6Hkxq554xSCemuGE6S57AKy4kGh7GmOGitm3oB Xw7w== X-Received: by 10.180.215.101 with SMTP id oh5mr6485729wic.6.1435756032045; Wed, 01 Jul 2015 06:07:12 -0700 (PDT) Received: from [10.36.226.2] ([80.169.137.63]) by mx.google.com with ESMTPSA id p2sm3373424wix.11.2015.07.01.06.07.11 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Jul 2015 06:07:11 -0700 (PDT) Message-ID: <5593E5FD.3050403@gmail.com> Date: Wed, 01 Jul 2015 14:07:09 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: oauth@ietf.org References: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> <55928DB3.7090300@gmail.com> <5593C270.7000008@gmail.com> <5593DA7D.80401@mit.edu> In-Reply-To: <5593DA7D.80401@mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 13:07:15 -0000 Hi Justin https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much easier to read, that I can tell for sure, at least it is obvious why a given entity (RS1) may want to exchange the current token provided by a client for a new token. Definitely easily implementable... One thing I'm not sure in the draft-richer-oauth-chain-00 about is on behalf of whose entity RS1 will be acting once it starts accessing RS2, On Behalf Of RO, or may be On Behalf Of (RO + Client), or may be it is On Behalf Of RO + Act As Client ? The last one seems most logical to me... Thanks, Sergey On 01/07/15 13:18, Justin Richer wrote: > As it's written right now, it's a translation of some WS-* concepts into > JWT format. It's not really OAuth-y (since the client has to understand > the token format along with everyone else, and according to the authors > the artifacts might not even be "OAuth tokens"), and that's my main > issue with the document. Years ago, I proposed an OAuth-based token swap > mechanism: > > https://tools.ietf.org/html/draft-richer-oauth-chain-00 > > This works without defining semantics of the tokens themselves, just > like the rest of OAuth. I've proposed to the authors of the current > draft that it should incorporate both semantic (using JWT) and syntactic > (using a simple token-agnostic grant) token swap mechanisms, and that > the two could be easily compatible. > > -- Justin > > On 7/1/2015 6:35 AM, Sergey Beryozkin wrote: >> Hmm... perhaps the clue is in the draft title, token-exchange, so may >> be it is a case of the given access token ("on_behalf_of" or "act_as" >> claim) being used to request a new security token. One can only guess >> though, does not seem like the authors are keen to answer the newbie >> questions... >> >> Cheers, Sergey >> >> >> On 30/06/15 13:38, Sergey Beryozkin wrote: >>> Hi, >>> Can you please explain what is the difference between On-Behalf-Of >>> semantics described in the draft-ietf-oauth-token-exchange-01 and the >>> implicit On-Behalf-Of semantics a client OAuth2 token possesses ? >>> >>> For example, draft-ietf-oauth-token-exchange-01 mentions: >>> >>> "Whereas, with on-behalf-of semantics, principal A still has its own >>> identity separate from B and it is explicitly understood that while B >>> may have delegated its rights to A, any actions taken are being taken by >>> A and not B. In a sense, A is an agent for B." >>> >>> This is a typical case with the authorization code flow where a client >>> application acts on-behalf-of the user who authorized this application ? >>> >>> Sorry if I'm missing something >>> >>> Cheers, Sergey >>> On 25/06/15 22:28, Mike Jones wrote: >>>> That’s what >>>> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 is >>>> about. >>>> >>>> Cheers, >>>> >>>> -- Mike >>>> >>>> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Vivek >>>> Biswas >>>> -T (vibiswas - XORIANT CORPORATION at Cisco) >>>> *Sent:* Thursday, June 25, 2015 2:20 PM >>>> *To:* OAuth@ietf.org >>>> *Subject:* [OAUTH-WG] JWT Token on-behalf of Use case >>>> >>>> Hi All, >>>> >>>> I am looking to solve a use-case similar to WS-Security On-Behalf-Of >>>> >>>> >>>> >>>> with OAuth JWT Token. >>>> >>>> Is there a standard claim which we can define within the OAuth JWT >>>> which denote the On-behalf-of User. >>>> >>>> For e.g., a Customer Representative trying to create token on behalf of >>>> a customer and trying to execute services specific for that specific >>>> customer. >>>> >>>> Regards, >>>> >>>> Vivek Biswas, >>>> CISSP >>>> >>>> *Cisco Systems, Inc * >>>> >>>> *Bldg. J, San Jose, USA,* >>>> >>>> *Phone: +1 408 527 9176* >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@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 From nobody Wed Jul 1 08:02:16 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA971A8F4D for ; Wed, 1 Jul 2015 08:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5LfZekmICU2 for ; Wed, 1 Jul 2015 08:02:11 -0700 (PDT) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 895851A9066 for ; Wed, 1 Jul 2015 07:59:55 -0700 (PDT) Received: by igcur8 with SMTP id ur8so93577987igc.0 for ; Wed, 01 Jul 2015 07:59:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=YVhjMg0LZjKO3rhsklUzibc0mAJVfCJ/jX+STLerB8Y=; b=ISBa/ThuSyg94AiDjLoaw5NNhBIAFnIDzI1Vk2oXX37YxlqHXR6C2JzOIz/1Lnlw/1 nZ+5kBXCj8LQVonVAnUZ3dH2UeXJJp86UwNKinaN9s/+Ar6iQr3/YN77k9IfBqme6zTx Jy3L+Ei6xDjtqd5ckFS5iW0rYZ9lil/fUQ6K4PnyEAa+oD7NOnB0nj9glsKFIeoUnbse VXnsdJlRtaaqOAt1M/BMAGzCeuP6EvkzncMe+V2Yd+oyG//A8PHPThXxOR5b+EwAN37I OZITan9vF9aoPa48P7N+K5TtR8we7LW6u6sTW7m5Oh19cdCUcb0q6PY4a8j7he+Ys63q vjmA== X-Gm-Message-State: ALoCoQlNQ/A4+0ifYF0XT1HtYEFNgSq2y50ItQm6YSGcSAQYtjdiHoGl2XXTZONsQmcFEBjx2Unn X-Received: by 10.107.35.203 with SMTP id j194mr38651250ioj.45.1435762794852; Wed, 01 Jul 2015 07:59:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.64.209 with HTTP; Wed, 1 Jul 2015 07:59:25 -0700 (PDT) In-Reply-To: <5593E5FD.3050403@gmail.com> References: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> <55928DB3.7090300@gmail.com> <5593C270.7000008@gmail.com> <5593DA7D.80401@mit.edu> <5593E5FD.3050403@gmail.com> From: Brian Campbell Date: Wed, 1 Jul 2015 08:59:25 -0600 Message-ID: To: Sergey Beryozkin Content-Type: multipart/alternative; boundary=001a114044405eb3a90519d193db Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 15:02:15 -0000 --001a114044405eb3a90519d193db Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable One problem, I think, with token exchange is that it can be really simple (token in and token out) and really complicated (client X wants a token that says user A is doing something on behalf of user B) at the same time. I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in an attempt to simplify things and express what I envisioned as an OAuth based token exchange framework. Though it likely only muddied the waters :) On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin wrote: > Hi Justin > > https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much easier to > read, that I can tell for sure, at least it is obvious why a given entity > (RS1) may want to exchange the current token provided by a client for a n= ew > token. Definitely easily implementable... > > One thing I'm not sure in the draft-richer-oauth-chain-00 about is on > behalf of whose entity RS1 will be acting once it starts accessing RS2, O= n > Behalf Of RO, or may be On Behalf Of (RO + Client), or may be it is On > Behalf Of RO + Act As Client ? The last one seems most logical to me... > > Thanks, Sergey > > > On 01/07/15 13:18, Justin Richer wrote: > >> As it's written right now, it's a translation of some WS-* concepts into >> JWT format. It's not really OAuth-y (since the client has to understand >> the token format along with everyone else, and according to the authors >> the artifacts might not even be "OAuth tokens"), and that's my main >> issue with the document. Years ago, I proposed an OAuth-based token swap >> mechanism: >> >> https://tools.ietf.org/html/draft-richer-oauth-chain-00 >> >> This works without defining semantics of the tokens themselves, just >> like the rest of OAuth. I've proposed to the authors of the current >> draft that it should incorporate both semantic (using JWT) and syntactic >> (using a simple token-agnostic grant) token swap mechanisms, and that >> the two could be easily compatible. >> >> -- Justin >> >> On 7/1/2015 6:35 AM, Sergey Beryozkin wrote: >> >>> Hmm... perhaps the clue is in the draft title, token-exchange, so may >>> be it is a case of the given access token ("on_behalf_of" or "act_as" >>> claim) being used to request a new security token. One can only guess >>> though, does not seem like the authors are keen to answer the newbie >>> questions... >>> >>> Cheers, Sergey >>> >>> >>> On 30/06/15 13:38, Sergey Beryozkin wrote: >>> >>>> Hi, >>>> Can you please explain what is the difference between On-Behalf-Of >>>> semantics described in the draft-ietf-oauth-token-exchange-01 and the >>>> implicit On-Behalf-Of semantics a client OAuth2 token possesses ? >>>> >>>> For example, draft-ietf-oauth-token-exchange-01 mentions: >>>> >>>> "Whereas, with on-behalf-of semantics, principal A still has its own >>>> identity separate from B and it is explicitly understood that while B >>>> may have delegated its rights to A, any actions taken are being taken = by >>>> A and not B. In a sense, A is an agent for B." >>>> >>>> This is a typical case with the authorization code flow where a client >>>> application acts on-behalf-of the user who authorized this application= ? >>>> >>>> Sorry if I'm missing something >>>> >>>> Cheers, Sergey >>>> On 25/06/15 22:28, Mike Jones wrote: >>>> >>>>> That=E2=80=99s what >>>>> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 is >>>>> about. >>>>> >>>>> Cheers, >>>>> >>>>> -- Mike >>>>> >>>>> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Vivek >>>>> Biswas >>>>> -T (vibiswas - XORIANT CORPORATION at Cisco) >>>>> *Sent:* Thursday, June 25, 2015 2:20 PM >>>>> *To:* OAuth@ietf.org >>>>> *Subject:* [OAUTH-WG] JWT Token on-behalf of Use case >>>>> >>>>> Hi All, >>>>> >>>>> I am looking to solve a use-case similar to WS-Security On-Behalf-= Of >>>>> < >>>>> http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust-1= .4-errata01-os-complete.html#_Toc325658980 >>>>> > >>>>> >>>>> >>>>> with OAuth JWT Token. >>>>> >>>>> Is there a standard claim which we can define within the OAuth JWT >>>>> which denote the On-behalf-of User. >>>>> >>>>> For e.g., a Customer Representative trying to create token on behalf = of >>>>> a customer and trying to execute services specific for that specific >>>>> customer. >>>>> >>>>> Regards, >>>>> >>>>> Vivek Biswas, >>>>> CISSP >>>>> >>>>> *Cisco Systems, Inc * >>>>> >>>>> *Bldg. J, San Jose, USA,* >>>>> >>>>> *Phone: +1 408 527 9176* >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@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 > --001a114044405eb3a90519d193db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One problem, I think, with token exchange is that it = can be really simple (token in and token out) and really complicated (clien= t X wants a token that says user A is doing something on behalf of user B) = at the same time.

I put forth https://tools.ietf.org/html/draft-camp= bell-oauth-sts-01 in an attempt to simplify things and express what I e= nvisioned as an OAuth based token exchange framework. Though it likely only= muddied the waters :)

On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin <sber= yozkin@gmail.com> wrote:
Hi= Justin

https://tools.ietf.org/html/draft-richer-oaut= h-chain-00 is much easier to read, that I can tell for sure, at least i= t is obvious why a given entity (RS1) may want to exchange the current toke= n provided by a client for a new token. Definitely easily implementable...<= br>
One thing I'm not sure in the draft-richer-oauth-chain-00 about is on b= ehalf of whose entity RS1 will be acting once it starts accessing RS2, On B= ehalf Of RO, or may be On Behalf Of (RO + Client), or may be it is On Behal= f Of RO + Act As Client ? The last one seems most logical to me...

Thanks, Sergey


On 01/07/15 13:18, Justin Richer wrote:
As it's written right now, it's a translation of some WS-* concepts= into
JWT format. It's not really OAuth-y (since the client has to understand=
the token format along with everyone else, and according to the authors
the artifacts might not even be "OAuth tokens"), and that's m= y main
issue with the document. Years ago, I proposed an OAuth-based token swap mechanism:

https://tools.ietf.org/html/draft-richer-oaut= h-chain-00

This works without defining semantics of the tokens themselves, just
like the rest of OAuth. I've proposed to the authors of the current
draft that it should incorporate both semantic (using JWT) and syntactic (using a simple token-agnostic grant) token swap mechanisms, and that
the two could be easily compatible.

=C2=A0 -- Justin

On 7/1/2015 6:35 AM, Sergey Beryozkin wrote:
Hmm... perhaps the clue is in the draft title, token-exchange, so may
be it is a case of the given access token ("on_behalf_of" or &quo= t;act_as"
claim) being used to request a new security token. One can only guess
though, does not seem like the authors are keen to answer the newbie
questions...

Cheers, Sergey


On 30/06/15 13:38, Sergey Beryozkin wrote:
Hi,
Can you please explain what is the difference between On-Behalf-Of
semantics described in the draft-ietf-oauth-token-exchange-01 and the
implicit On-Behalf-Of semantics a client OAuth2 token possesses ?

For example, draft-ietf-oauth-token-exchange-01 mentions:

"Whereas, with on-behalf-of semantics, principal A still has its own identity separate from B and it is explicitly understood that while B
may have delegated its rights to A, any actions taken are being taken by A and not B. In a sense, A is an agent for B."

This is a typical case with the authorization code flow where a client
application acts on-behalf-of the user who authorized this application ?
Sorry if I'm missing something

Cheers, Sergey
On 25/06/15 22:28, Mike Jones wrote:
That=E2=80=99s what
https://tools.ietf.org/html/draft-ietf= -oauth-token-exchange-01 is
about.

Cheers,

-- Mike

*From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Vivek
Biswas
-T (vibiswas - XORIANT CORPORATION at Cisco)
*Sent:* Thursday, June 25, 2015 2:20 PM
*To:* OAuth@ietf.org
*Subject:* [OAUTH-WG] JWT Token on-behalf of Use case

Hi All,

=C2=A0 =C2=A0I am looking to solve a use-case similar to WS-Security On-Beh= alf-Of
<http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/w= s-trust-1.4-errata01-os-complete.html#_Toc325658980>


with OAuth JWT Token.

=C2=A0 =C2=A0Is there a standard claim which we can define within the OAuth= JWT
which denote the On-behalf-of User.

For e.g., a Customer Representative trying to create token on behalf of
a customer and trying to execute services specific for that specific
customer.

Regards,

Vivek Biswas,
CISSP

*Cisco Systems, Inc <http://www.cisco.com/>*

*Bldg. J, San Jose, USA,*

*Phone: +1 408 527 9176*



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

--001a114044405eb3a90519d193db-- From nobody Wed Jul 1 08:32:58 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210761A1A73 for ; Wed, 1 Jul 2015 08:32:56 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3q4OZrgo6SK for ; Wed, 1 Jul 2015 08:32:53 -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 89C551A8F51 for ; Wed, 1 Jul 2015 08:32:51 -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 t61FWnXR021299 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Jul 2015 15:32:49 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t61FWmei027199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 1 Jul 2015 15:32:48 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t61FWm87010489; Wed, 1 Jul 2015 15:32:48 GMT Received: from [10.0.1.20] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Jul 2015 08:32:48 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-6247120C-E105-480F-8055-BF1393EA82CF Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12F70) In-Reply-To: Date: Wed, 1 Jul 2015 08:32:43 -0700 Content-Transfer-Encoding: 7bit Message-Id: <4BCD0A9A-A4A3-44D1-A607-9159DE471002@oracle.com> References: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> <55928DB3.7090300@gmail.com> <5593C270.7000008@gmail.com> <5593DA7D.80401@mit.edu> <5593E5FD.3050403@gmail.com> To: Brian Campbell X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 15:32:56 -0000 --Apple-Mail-6247120C-E105-480F-8055-BF1393EA82CF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable After putting out the original proposal, I am not totally sure we need it. I= n many cases we architected around the issue.=20 https://tools.ietf.org/html/draft-hunt-oauth-chain-01 Question is token swap for cross domain chaining? Shouldn't in domain server= s be acting on internal policy mechanisms? Is there an interop need for the i= nternal case? I conclude this is a primarily a cross domain case that could also be used i= n internally. But internal is not the driver.=20 Based on the number of submissions, this seems to be a 1% case that everyone= has. Unfortunately that means we keep downgrading its priority.=20 Phil > On Jul 1, 2015, at 07:59, Brian Campbell wrot= e: >=20 > One problem, I think, with token exchange is that it can be really simple (= token in and token out) and really complicated (client X wants a token that s= ays user A is doing something on behalf of user B) at the same time.=20 >=20 > I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in an a= ttempt to simplify things and express what I envisioned as an OAuth based to= ken exchange framework. Though it likely only muddied the waters :)=20 >=20 >> On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin w= rote: >> Hi Justin >>=20 >> https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much easier to= read, that I can tell for sure, at least it is obvious why a given entity (= RS1) may want to exchange the current token provided by a client for a new t= oken. Definitely easily implementable... >>=20 >> One thing I'm not sure in the draft-richer-oauth-chain-00 about is on beh= alf of whose entity RS1 will be acting once it starts accessing RS2, On Beha= lf Of RO, or may be On Behalf Of (RO + Client), or may be it is On Behalf Of= RO + Act As Client ? The last one seems most logical to me... >>=20 >> Thanks, Sergey >>=20 >>=20 >>> On 01/07/15 13:18, Justin Richer wrote: >>> As it's written right now, it's a translation of some WS-* concepts into= >>> JWT format. It's not really OAuth-y (since the client has to understand >>> the token format along with everyone else, and according to the authors >>> the artifacts might not even be "OAuth tokens"), and that's my main >>> issue with the document. Years ago, I proposed an OAuth-based token swap= >>> mechanism: >>>=20 >>> https://tools.ietf.org/html/draft-richer-oauth-chain-00 >>>=20 >>> This works without defining semantics of the tokens themselves, just >>> like the rest of OAuth. I've proposed to the authors of the current >>> draft that it should incorporate both semantic (using JWT) and syntactic= >>> (using a simple token-agnostic grant) token swap mechanisms, and that >>> the two could be easily compatible. >>>=20 >>> -- Justin >>>=20 >>>> On 7/1/2015 6:35 AM, Sergey Beryozkin wrote: >>>> Hmm... perhaps the clue is in the draft title, token-exchange, so may >>>> be it is a case of the given access token ("on_behalf_of" or "act_as" >>>> claim) being used to request a new security token. One can only guess >>>> though, does not seem like the authors are keen to answer the newbie >>>> questions... >>>>=20 >>>> Cheers, Sergey >>>>=20 >>>>=20 >>>>> On 30/06/15 13:38, Sergey Beryozkin wrote: >>>>> Hi, >>>>> Can you please explain what is the difference between On-Behalf-Of >>>>> semantics described in the draft-ietf-oauth-token-exchange-01 and the >>>>> implicit On-Behalf-Of semantics a client OAuth2 token possesses ? >>>>>=20 >>>>> For example, draft-ietf-oauth-token-exchange-01 mentions: >>>>>=20 >>>>> "Whereas, with on-behalf-of semantics, principal A still has its own >>>>> identity separate from B and it is explicitly understood that while B >>>>> may have delegated its rights to A, any actions taken are being taken b= y >>>>> A and not B. In a sense, A is an agent for B." >>>>>=20 >>>>> This is a typical case with the authorization code flow where a client= >>>>> application acts on-behalf-of the user who authorized this application= ? >>>>>=20 >>>>> Sorry if I'm missing something >>>>>=20 >>>>> Cheers, Sergey >>>>>> On 25/06/15 22:28, Mike Jones wrote: >>>>>> That=E2=80=99s what >>>>>> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 is >>>>>> about. >>>>>>=20 >>>>>> Cheers, >>>>>>=20 >>>>>> -- Mike >>>>>>=20 >>>>>> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Vivek >>>>>> Biswas >>>>>> -T (vibiswas - XORIANT CORPORATION at Cisco) >>>>>> *Sent:* Thursday, June 25, 2015 2:20 PM >>>>>> *To:* OAuth@ietf.org >>>>>> *Subject:* [OAUTH-WG] JWT Token on-behalf of Use case >>>>>>=20 >>>>>> Hi All, >>>>>>=20 >>>>>> I am looking to solve a use-case similar to WS-Security On-Behalf-= Of >>>>>> >>>>>>=20 >>>>>>=20 >>>>>> with OAuth JWT Token. >>>>>>=20 >>>>>> Is there a standard claim which we can define within the OAuth JWT= >>>>>> which denote the On-behalf-of User. >>>>>>=20 >>>>>> For e.g., a Customer Representative trying to create token on behalf o= f >>>>>> a customer and trying to execute services specific for that specific >>>>>> customer. >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Vivek Biswas, >>>>>> CISSP >>>>>>=20 >>>>>> *Cisco Systems, Inc * >>>>>>=20 >>>>>> *Bldg. J, San Jose, USA,* >>>>>>=20 >>>>>> *Phone: +1 408 527 9176* >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=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-6247120C-E105-480F-8055-BF1393EA82CF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
After putting out the original proposa= l, I am not totally sure we need it. In many cases we architected around the= issue. 
https://tools.ietf.org/html/draft-hunt-oauth-chain-01

Question is token swap for cross domain chaining? Shoul= dn't in domain servers be acting on internal policy mechanisms? Is there an i= nterop need for the internal case?

I conclude this i= s a primarily a cross domain case that could also be used in internally. But= internal is not the driver. 

Based on the num= ber of submissions, this seems to be a 1% case that everyone has. Unfortunat= ely that means we keep downgrading its priority. 

Phil

On Jul 1, 2015, at 07:59, Brian Campbell <bcampbell@pingidentity.com> wrote:

=
One problem, I th= ink, with token exchange is that it can be really simple (token in and token= out) and really complicated (client X wants a token that says user A is doi= ng something on behalf of user B) at the same time.

I put fort= h https:= //tools.ietf.org/html/draft-campbell-oauth-sts-01 in an attempt to simpl= ify things and express what I envisioned as an OAuth based token exchange fr= amework. Though it likely only muddied the waters :)

On Wed, Jul 1, 2015 at 7:07 AM,= Sergey Beryozkin <sberyozkin@gmail.com> wrote:
Hi Justin

https://tools.ietf.org/html/draft-richer-oauth-= chain-00 is much easier to read, that I can tell for sure, at least it i= s obvious why a given entity (RS1) may want to exchange the current token pr= ovided by a client for a new token. Definitely easily implementable...

One thing I'm not sure in the draft-richer-oauth-chain-00 about is on behalf= of whose entity RS1 will be acting once it starts accessing RS2, On Behalf O= f RO, or may be On Behalf Of (RO + Client), or may be it is On Behalf Of RO += Act As Client ? The last one seems most logical to me...

Thanks, Sergey


On 01/07/15 13:18, Justin Richer wrote:
As it's written right now, it's a translation of some WS-* concepts into
= JWT format. It's not really OAuth-y (since the client has to understand
the token format along with everyone else, and according to the authors
the artifacts might not even be "OAuth tokens"), and that's my main
issue with the document. Years ago, I proposed an OAuth-based token swap
= mechanism:

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

This works without defining semantics of the tokens themselves, just
like the rest of OAuth. I've proposed to the authors of the current
draft that it should incorporate both semantic (using JWT) and syntactic
= (using a simple token-agnostic grant) token swap mechanisms, and that
the two could be easily compatible.

  -- Justin

On 7/1/2015 6:35 AM, Sergey Beryozkin wrote:
Hmm... perhaps the clue is in the draft title, token-exchange, so may
be it is a case of the given access token ("on_behalf_of" or "act_as"
claim) being used to request a new security token. One can only guess
though, does not seem like the authors are keen to answer the newbie
questions...

Cheers, Sergey


On 30/06/15 13:38, Sergey Beryozkin wrote:
Hi,
Can you please explain what is the difference between On-Behalf-Of
semantics described in the draft-ietf-oauth-token-exchange-01 and the
implicit On-Behalf-Of semantics a client OAuth2 token possesses ?

For example, draft-ietf-oauth-token-exchange-01 mentions:

"Whereas, with on-behalf-of semantics, principal A still has its own
identity separate from B and it is explicitly understood that while B
may have delegated its rights to A, any actions taken are being taken by
= A and not B. In a sense, A is an agent for B."

This is a typical case with the authorization code flow where a client
application acts on-behalf-of the user who authorized this application ?
=
Sorry if I'm missing something

Cheers, Sergey
On 25/06/15 22:28, Mike Jones wrote:
That=E2=80=99s what
https://tools.ietf.org/html/draft-ietf-o= auth-token-exchange-01 is
about.

Cheers,

-- Mike

*From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Vivek
Biswas
-T (vibiswas - XORIANT CORPORATION at Cisco)
*Sent:* Thursday, June 25, 2015 2:20 PM
*To:* OAuth@ietf.org=
*Subject:* [OAUTH-WG] JWT Token on-behalf of Use case

Hi All,

   I am looking to solve a use-case similar to WS-Security On-Beha= lf-Of
<http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-t= rust-1.4-errata01-os-complete.html#_Toc325658980>


with OAuth JWT Token.

   Is there a standard claim which we can define within the OAuth J= WT
which denote the On-behalf-of User.

For e.g., a Customer Representative trying to create token on behalf of
a customer and trying to execute services specific for that specific
customer.

Regards,

Vivek Biswas,
CISSP

*Cisco Systems, Inc <http://www.cisco.com/>*

*Bldg. J, San Jose, USA,*

*Phone: +1 408 527 9176*



_______________________________________________
OAuth mailing list
OAuth@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/mai= lman/listinfo/oauth
= --Apple-Mail-6247120C-E105-480F-8055-BF1393EA82CF-- From nobody Wed Jul 1 11:00:26 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBF7A1B2E80 for ; Wed, 1 Jul 2015 11:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNmP1fNP_8R1 for ; Wed, 1 Jul 2015 11:00:21 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0128.outbound.protection.outlook.com [207.46.100.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6D761B2E7D for ; Wed, 1 Jul 2015 11:00:21 -0700 (PDT) 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.201.16; Wed, 1 Jul 2015 18:00:19 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0201.000; Wed, 1 Jul 2015 18:00:19 +0000 From: Anthony Nadalin To: Justin Richer , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] JWT Token on-behalf of Use case Thread-Index: AdCvjKZzog4lHzdSReisaGHaz/hQ6gAARPxgAOj5XIAALgFuAAADlXeAAAvCDkA= Date: Wed, 1 Jul 2015 18:00:19 +0000 Message-ID: References: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> <55928DB3.7090300@gmail.com> <5593C270.7000008@gmail.com> <5593DA7D.80401@mit.edu> In-Reply-To: <5593DA7D.80401@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; x-originating-ip: [131.107.159.184] x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1235; 5:Azom+X5/woZVx6V853HVyhFj7jICQK2gwguOgAh42Xf1/BKxtCmh56crVTzkY19oFTLjoKSn0w/6EmibzHZ0Zt74NSYn7jELXemtzoN1vOHdEUMuoYflscbfmBJXuuV69Dj3K069X0GWGCtkADlX0w==; 24:Zke34g3h4qfSgXpXCXbiUJvy/RW1DXWbV+UUn3JkSzgmhX9OrDtR7ryPs3ZM9+pTZ9vvgPiArHL4Zs61vx3ShjGGQvsOKjR5HSfCVyVujeM=; 20:vCf8sSDHMmfnUvi9zy1KgoN+lm57cso9bqLzf8g14/YWpRk3YL4LS1eAR/YG56oA2oNd6bbLcw+lT568QxKJnA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1235; x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BN3PR0301MB1235; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1235; x-forefront-prvs: 0624A2429E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(479174004)(53754006)(377454003)(51704005)(2900100001)(74316001)(15975445007)(2950100001)(102836002)(77096005)(76176999)(62966003)(122556002)(2501003)(50986999)(54356999)(40100003)(107886002)(76576001)(5001770100001)(66066001)(33656002)(46102003)(5003600100002)(93886004)(87936001)(5001960100002)(86612001)(2656002)(86362001)(19580405001)(19580395003)(2171001)(189998001)(5002640100001)(77156002)(92566002)(99286002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1235; H:BN3PR0301MB1234.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: 01 Jul 2015 18:00:19.3590 (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: Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 18:00:24 -0000 Not quite, the actual tokens are still opaque, the requestor is just asking= for a token exchange , the requestor can specify the requested token type = it's up to the server to determine the actual token it will delever -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer Sent: Wednesday, July 1, 2015 5:18 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case As it's written right now, it's a translation of some WS-* concepts into JW= T format. It's not really OAuth-y (since the client has to understand the t= oken format along with everyone else, and according to the authors the arti= facts might not even be "OAuth tokens"), and that's my main issue with the = document. Years ago, I proposed an OAuth-based token swap mechanism: https://tools.ietf.org/html/draft-richer-oauth-chain-00 This works without defining semantics of the tokens themselves, just like t= he rest of OAuth. I've proposed to the authors of the current draft that it= should incorporate both semantic (using JWT) and syntactic (using a simple= token-agnostic grant) token swap mechanisms, and that the two could be eas= ily compatible. -- Justin On 7/1/2015 6:35 AM, Sergey Beryozkin wrote: > Hmm... perhaps the clue is in the draft title, token-exchange, so may=20 > be it is a case of the given access token ("on_behalf_of" or "act_as" > claim) being used to request a new security token. One can only guess=20 > though, does not seem like the authors are keen to answer the newbie=20 > questions... > > Cheers, Sergey > > > On 30/06/15 13:38, Sergey Beryozkin wrote: >> Hi, >> Can you please explain what is the difference between On-Behalf-Of=20 >> semantics described in the draft-ietf-oauth-token-exchange-01 and the=20 >> implicit On-Behalf-Of semantics a client OAuth2 token possesses ? >> >> For example, draft-ietf-oauth-token-exchange-01 mentions: >> >> "Whereas, with on-behalf-of semantics, principal A still has its own=20 >> identity separate from B and it is explicitly understood that while B=20 >> may have delegated its rights to A, any actions taken are being taken=20 >> by A and not B. In a sense, A is an agent for B." >> >> This is a typical case with the authorization code flow where a=20 >> client application acts on-behalf-of the user who authorized this applic= ation ? >> >> Sorry if I'm missing something >> >> Cheers, Sergey >> On 25/06/15 22:28, Mike Jones wrote: >>> That's what >>> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 is=20 >>> about. >>> >>> Cheers, >>> >>> -- Mike >>> >>> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Vivek=20 >>> Biswas -T (vibiswas - XORIANT CORPORATION at Cisco) >>> *Sent:* Thursday, June 25, 2015 2:20 PM >>> *To:* OAuth@ietf.org >>> *Subject:* [OAUTH-WG] JWT Token on-behalf of Use case >>> >>> Hi All, >>> >>> I am looking to solve a use-case similar to WS-Security=20 >>> On-Behalf-Of=20 >>> >> -1.4-errata01-os-complete.html#_Toc325658980> >>> >>> >>> with OAuth JWT Token. >>> >>> Is there a standard claim which we can define within the OAuth=20 >>> JWT which denote the On-behalf-of User. >>> >>> For e.g., a Customer Representative trying to create token on behalf=20 >>> of a customer and trying to execute services specific for that=20 >>> specific customer. >>> >>> Regards, >>> >>> Vivek Biswas, >>> CISSP >>> >>> *Cisco Systems, Inc * >>> >>> *Bldg. J, San Jose, USA,* >>> >>> *Phone: +1 408 527 9176* >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@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 From Lisa_Li1@symantec.com Mon Jun 29 19:18:04 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA9E1B2F25 for ; Mon, 29 Jun 2015 19:18:04 -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_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8eTg8Pc_So3 for ; Mon, 29 Jun 2015 19:18:01 -0700 (PDT) Received: from tus1smtoutpex01.symantec.com (tus1smtoutpex01.symantec.com [216.10.195.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB7FC1B2F2E for ; Mon, 29 Jun 2015 19:18:01 -0700 (PDT) X-AuditID: d80ac3f1-f79fd6d0000022fa-ed-5591fc594260 Received: from tus1smtintpin01.ges.symantec.com (tus1smtintpin01.ges.symantec.com [192.168.215.101]) by tus1smtoutpex01.symantec.com (Symantec Brightmail Gateway out) with SMTP id 76.44.08954.95CF1955; Tue, 30 Jun 2015 03:18:01 +0100 (BST) Received: from [155.64.220.138] (helo=TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM) by tus1smtintpin01.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1Z9l7Z-0009zy-6F for oauth@ietf.org; Tue, 30 Jun 2015 02:18:01 +0000 Received: from APJ1XCHEVSPIN36.SYMC.SYMANTEC.COM ([169.254.1.198]) by TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM ([155.64.220.138]) with mapi; Mon, 29 Jun 2015 19:17:34 -0700 From: Lisa Li1 To: "oauth@ietf.org" Date: Mon, 29 Jun 2015 19:18:00 -0700 Thread-Topic: Question about usage of OAuth between servers Thread-Index: AdCy13ifnh0LhdmHSDKMx0axfcfp0w== Message-ID: <47E83806AE926749BB17D1020685E6901903F0CC5F@APJ1XCHEVSPIN36.SYMC.SYMANTEC.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_47E83806AE926749BB17D1020685E6901903F0CC5FAPJ1XCHEVSPIN_"; type="multipart/alternative" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPIsWRmVeSWpSXmKPExsVyYMX1VN3IPxNDDb7eF7A4+fYVmwOjx5Il P5kCGKO4bFJSczLLUov07RK4Mg7v38hWcGoyY8WfPbOZGxg/dzB2MXJySAiYSKyfuALKFpO4 cG89WxcjF4eQwEdGiZ8PVjNCOL8ZJc7NesAEUiUksJJR4s13ZhCbTUBN4uzCxewgtoiAqsS+ o1fAbBYge9G2+2C2sICZxLZNN6BqrCWOrH3NCmHrSRxe/wTM5hWIkji3dRkbiM0IdMX3U2vA djELiEvcejKfCeI6EYmHF0+zQdiiEi8f/2OFqBeVuNO+HuxQZoFuRokrm++zQQwVlDg58wnL BEbhWUhmzUJWNwtJHURRvsS2+6fZIGwdiQW7P0HZ2hLLFr5mhrHPHHjMhCmuIzFz5w2oOYoS x49ehVq2lFGi7+xRVpii9svvGWGKpnQ/ZF/AyLuKUaaktNiwOLckv7SkILXCwFCvuDI3ERjR yXrJ+bmbGIFRfYPr8McdjEf3Oh5iFOBgVOLhDXw/MVSINbEMqPIQowrQuEcbVl9glGLJy89L VRLhZYoFSvOmJFZWpRblxxeV5qQWH2KU5mBREufVXtQcKiSQnliSmp2aWpBaBJNl4uCUamDM 5bhlU1tXa7jBdPLbV+9tS5P2MTfo7gve+CHvaXvT4qRZ2qt60/YXbNFauHzRWnuuCzxh/mZc j8vvfptTd2p5++kbpZWPE6oeHNlo0dZt98ZgS1TjpxzVrZqxPzZfcd+2bKn3vm0flM9x7LHk OLfl1Bw17ze1F5RW3Lu8rttqT2aS2rsl/u1aSizFGYmGWsxFxYkASiJyzfICAAA= Archived-At: X-Mailman-Approved-At: Thu, 02 Jul 2015 08:59:36 -0700 Subject: [OAUTH-WG] Question about usage of OAuth between servers X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 02:20:01 -0000 --_004_47E83806AE926749BB17D1020685E6901903F0CC5FAPJ1XCHEVSPIN_ Content-Type: multipart/alternative; boundary="_000_47E83806AE926749BB17D1020685E6901903F0CC5FAPJ1XCHEVSPIN_" --_000_47E83806AE926749BB17D1020685E6901903F0CC5FAPJ1XCHEVSPIN_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All This is Lisa. Our project is adopting OAuth 2 as authentication specification. For the client-server communication, OAuth token works fine. But we have so= me cases of server to server communication, usually it will be multiple tas= ks running in parallel or sequence or even in multiple threads. In this cas= e, we are not sure we should reuse the access token grant by end user or cr= eate another token? Moreover, if token is expired in 30 min, we are able to= do refresh but may meet some issue on the token consistency between each t= ask, thus it might be refreshed again and again... But with OAuth 1.0, since it will not expired and we don't have to do refre= sh, it will work fine. So for OAuth 2.0, what's your consideration for server to server communicat= ion scenario? Or do you have any suggestion here? Thanks. Lisa Li Principal Software Engineer Symantec Corporation Office: (010) 6272 5127 / Mobile: 189 1057 2219 Lisa_Li1@symantec.com [cid:image002.png@01D0B31E.0A6CFD10] This message (including any attachments) is intended only for the use of th= e individual or entity to which it is addressed and may contain information= that is non-public, proprietary, privileged, confidential, and exempt from= disclosure under applicable law or may constitute as attorney work product= . If you are not the intended recipient, you are hereby notified that any u= se, dissemination, distribution, or copying of this communication is strict= ly prohibited. If you have received this communication in error, notify us = immediately by telephone and (i) destroy this message if a facsimile or (ii= ) delete this message immediately if this is an electronic communication. --_000_47E83806AE926749BB17D1020685E6901903F0CC5FAPJ1XCHEVSPIN_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All

 

This is= Lisa.

Our project is adopting OAuth 2 = as authentication specification.

For th= e client-server communication, OAuth token works fine. But we have some cas= es of server to server communication, usually it will be multiple tasks run= ning in parallel or sequence or even in multiple threads. In this case, we = are not sure we should reuse the access token grant by end user or create a= nother token? Moreover, if token is expired in 30 min, we are able to do re= fresh but may meet some issue on the token consistency between each task, t= hus it might be refreshed again and again…

 

But with OAuth 1.0, sinc= e it will not expired and we don’t have to do refresh, it will work f= ine.

 

So for OAuth 2.0, what’s your consideration for server to serv= er communication scenario? Or do you have any suggestion here?

 

Thanks.

 

=  

Lisa Li

Principal Software Engineer

<= p class=3DMsoNormal>Symantec Corporation

 

= Office: (010) 6272 5127  /  Mobile: 189 1057 2219

Lisa_Li1@symantec.com

 

3D"Mac

 <= /p>

 

Thi= s message (including any attachments) is intended only for the use of the i= ndividual or entity to which it is addressed and may contain information th= at is non-public, proprietary, privileged, confidential, and exempt from di= sclosure under applicable law or may constitute as attorney work product. I= f you are not the intended recipient, you are hereby notified that any use,= dissemination, distribution, or copying of this communication is strictly = prohibited. If you have received this communication in error, notify us imm= ediately by telephone and (i) destroy this message if a facsimile or (ii) d= elete this message immediately if this is an electronic communication.

 

<= /div>= --_000_47E83806AE926749BB17D1020685E6901903F0CC5FAPJ1XCHEVSPIN_-- --_004_47E83806AE926749BB17D1020685E6901903F0CC5FAPJ1XCHEVSPIN_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=7040; creation-date="Tue, 30 Jun 2015 02:18:00 GMT"; modification-date="Tue, 30 Jun 2015 02:18:00 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAMUAAAAqCAYAAAADKp+nAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAABsASURBVHja 7V15XJPH1rbLd29rrXUFN2QHZXMBxQ3cQFwA0YAILqDihogiUlREUalSa12qtrXW1mu91FJMCAHC lo2EbAQ0YkREiqU010s1rU1tVJT5zgSBN5ElC1a89Y9jYn7vO3PmzDxnzjZDjz179vR4Ra/o70II oX+K10VF0XqbRrC9fLdURMaulSUfmqmQSHoyXCcHp/Xo8forQb2ivxsoetZeuPiteJY/qvz4k6Ly jbGPhPOD635KvcDKHGr9ZHaPHm++EtQr+ltS0byAHyS+QcPEqyNzrvkFovLAUER3GFvbo0ePN3qc 69HDlNV3sCdtoBWQmScZvgsnT/OUJaX060omyIOt3Aqe9qEm6IftNdsDkPtGB6gerjhzzpPu4qrm q+VdfakX7svXA1VXv6ULr8raWqfK6NgWmehDvAUhng1SmSfw/qausqlNS7Pmubi3jJHc18yT7eDq yQta048gizcksfETab0GGi4HneQ02wNMibc70bbvolq5J2vabE8y8COEMSsrq8c/B63uoqAXNPXT 1/ixSeMT3KHN1+jR0f+Uxu1QyHbvHnXzi68E1XtTfqlLOoAqDh65pwYFf0HwOomNM8rpb4boJuaI PsAMCa2ckCQyJhE30BWDqz6XOo87yr0xr9+wpj6ACvsMQcWkkEro45kJUCkU7jUphygcr3k/CyfN QHnDbIGv4S3v6k3vDUL8OQFIKZVad8TnvcqqRVWb4iiFk2bcB37hXQu9+2KOGI1KfOYjoV+Q4L/k zM9hfP/oFBQX0j8tGzUB5fQbqm4jp/8wJHJwRbzgsPmEBfJeWfTW+3nvmhouBx3kJJgzH8mFQrv2 eJVLJCNL129mlwcEo0IrR0SHdcOyH4W4s/zQ1S3b0lUK+RBj14tSLre7lrj3dMmSlSrhtNmo0Br6 GWjc2PJ7D0KXt2z/Fa83vK4f1tXNQgpFb1V9/eQGpdLuofJ+QMOdez4Aitd63CuXLRK6T39CeW8w og4crqYcWLD8kPCaLkL767zgZQd4FiNRBkw2bp/SdwgSjhiLxGsiY7Sfv1vASuLPWfBfnqUDosFA yL1NUQYAtZk3gwja4Pj4PwFQWLXHpzgyJlA0y/8RZ6gtosLCo4AMDOkrAxb2xXcGoDwYq8DRDZWH RfDuVVSROpLRT99+f0zgPB5l9B3S0kbRiDGIHxzmS5Bj77JNcXdovUyMk0Vncprl21gvkdi0xecd sXhFWUjYIzrI5mLP/k3zCQuOAvxS3hmIii0cUPG8heWKgoLBhjrB1SmHwyQLFz9gmdmhDGjz4rsm LevGGMqCOb0cu12OfYrO+MCM/INPCrlLA1Bk4AnBjcDkFI2b8ruysnJqF4DiDY4vqY4GWqi5fVrf oYjt4n5HzmKNJj77HwbreMX8YJQJwiCDoJufN5pgstk+/o/bA4U0KZnEcZ3SQIPnKADAruqXDGMu hM+yJSsf3+YJ2wXGTxfSj/IBFFhZ4PfwIuO0CYqtv2QCKLpMLm3IiePj96QtUED/5pc2xDzKhv4p sEjbHC/wzwSNLlm94TI830vPdfJmzb/+zeG7TUHUngPa7cNQoqlBse1nnUCB/7kcE/9dPkb80wWB BydyckNXk5L3GAuKutTUGYyRY+5nEhY5HUDBDQy9QnyunsUeK/Dxv08FQGgMCO8SQJnw3WBqAgVq CxT36+r8QTM1YKFpAMKAfvHz2pOJ/w9+ALqyJqrhYf2d2caA4tKmrXezYFF2xkdGW8DWZSxNoEBt gaLq5KmkYuCJ/JRHooy0FYEATM+6dPJ6fdZJWUz8Mi6sOQrMg0G8d0LZ0K40dtt/dAZFHZm6XDxx OrrYm6DNQfiiiMhqaOT/jAGFaGnEQb61c+tigU8WmFJgnq3T0NaJeyrztRYV3i3o8Jk31Oa5gQIc rtNq/gigxTwUDLZG9CHWevWTC3yyzUciKuy6RIDhcbCgrSt7PhC25WPovFNEb1W8CFBgx5q3YDED m4TNbePxZWH/Z5DlU6CYt/TFAjmURsVk6bpG6nk8G87MuU8ytQCB5ZAJa5Ix3L5LQHF5y7bbOoMC HuzHnT1fnk3QAlSwGzkTpv4JJpSbEabTu5y5C2qwWdLcbjpozTIvP3RPKlvc4lhVVo5kuU35ldZn sMZCYgyzQ5KA4BvlcQkxtIFmzgbTWwOdeV4LnFBlpcaCVKlUw3kLF9dTwQcgAiLH1AJdXhYhku1N DtWnn6rjp1bVfvgxdtQfZGM7m7A4sZ8hAKdRISkLMBAUr0tj40fisXTGB8+XdBMHTpr7zoS5ZHv7 /sqevWBiZ3Jie8121pYT+AjmRdPnIAphHjOB18LxnvKK/YcSGBOmPyG/SzDrYI5F8xf9hpRKe13W iSB4+SesITYaYKbAWmCCgikLX/PH9Y+OfG7U/APRYWzS2IQRWI46gUKtMeMTc3KJTIGJIwRHERhK NhQUtTS6e6HL+MdUghbOhnZFQUt/AOZMmp+rPHRsp3DUBEQmgCIbJlXkF1iiQmjQ84pVV59Ls2N5 eIEt3bpD5oL240zxkugSNWo3iiWVkUqDlqoyCJoPg63I0hFdP3oi3RBQ6EPisIhyOgEU2F/kLQz5 RZ8wsYbpdPhkIsvKsTGDsIsXmlqi8sS9THV/S8JZBSYWrbsIjIPjNA5Vf3ZmSWdtK6RSR97Mufcy CXOA1x7L0gFdiY79Hnh2/KtzGK0L+Otzi0smzdAwobLhuyh8jRRrfEMavxKfeKTYdlSrSQRCywdh Vhw6SiU+BwszjgMmVbNmvQh2aenEGaj63Pl1z3PwkshYG7qj6xNq36Et/DFg669I+TjX2LZr06gR QjBJyQR5YhMqZ+SYM88bFMIlK2TPgCJg0R0c1jVgt3+rOCA4lwFmUvP84Mgc18Ud3bqQtlYNmi++ SmFbO2mYvozBVuhyXEJhZ+2zp/mOZTuMbRk7pgLYqblzArBi+ueLSOwRB28JiK3N6kuI+sDiZHt4 NyqEEgcDhNmftyD4ajYhqoXDa5Jpc9BteoG/RmLP1DyOBYJofi4LFgXT0VXeIK+3f66giE2wyXUe pwGKQgDFjaMnC41tG0dfWJNnltAJ8qTB+HlzA/AuafGygEJZXW3H9yMhck+CiQmmIJhHfzYolU7q 3AWNbs+d6qPhJGPNL5xHwiHQkR21f3lbUko+AK7FbIc5yAMfQhIVu/BFZbs1F0lULCOP4DDhySke ORbVfPVNit6mSWraaI67J6IQQJEF5lFJ4BK8KCw7AkUefL/Yd/DV5z349kBR+fEnhV3RfsHYSemM QVatflLP/qgkJByGj8a+LKCoOfP1VoaNEyKaTkzY8cQRGwqbk7vw2Yc3f5GATjCTLwJAxJNnotq0 9OCO2q88+imPMdS2xfTCc0F3Hod4y6KHdgtQyJL2B/FdWm17vF1iP0OyNlqAB66X6bR7/3EO2IUt ziZecIOt0bWDh7OfKQHRAgW26+Gz4mUGBbaFS4KWPiJq2EIYF3WQZZp2aUt3BQV2SktWRzIZMG8t 1kO/YYhp7YxqzpyNJT57bd+BFK6ti4YJhcP8sv0fMTr0V058oQkKaD/HzgVJ4uNHdgtQwHY4onjG nJ8zCYk2MmyVQv8g1CCX2+khzH7F8xaIconh1d6mSDTFC9XRsuf/HUBRHp+4kWVDCPVC2+xhdojr H5j2svgUqvp6F5Ev6U8KIXeEQc73C0RgVtlqlH/Q6Q6McR6N1D6aloEoILhW2zIg0o2jJ1LyYeeh EpQnE8wn6c49n3YLUGAqWRuVj52kjIFmLZqBYzcK/Xgh/aDOTiaZ5sKfNhsRw3RU+C4mhWIb0/Z/ GRQwvgG3z12I40yY/oRKMB2x+VFoPgJVHf9s58sCiqrjp9Zx7Eero0HNlgNeG6Llq3OxA64dfhcE L5dmEQIL2Ics9fRBt7Ppi9vrQ5qQNJY3fiqiEN7LBH4FM+f9oaysDugWoJDtP7SEDYLIIGg4HA2Q rI0q0jUKVXny1GEGLIAMQtSJbWaHpHEJGW093yYoTMxeKp9CIZFOLI9L2Hpl9YabovGeCIdjKcRE FOy4JaRQpKquNn9ZQFEaHcstMLXUADbb1qWx5uz5xDZ3xx27kgXggxJ3x1z4rNh/KLcjM7M0bO09 jVwRvIfzPOLApQ/upFPD2ioa/UtBAWaSPd9n/m8ZhBobXPxVsmAx3jKddNCU74gWL+fnm5hrxp2d 3NCt1AuLdAEFFZdGWIz4vTRqC6V0I1CU/nQzbgdFEhk7/XmCAsbqfOt86s6rq9bncGfORVgR4ASo OqxNHD+YEYVm9ujmiVNnsXxeBlA0qFSjRT7+v1CJ+YNeA3HBH1LJZOZtvVMvFLoyR0/4k5iXwnyw Z/lVdRiU+fzMCYGDq0aeCgMDFygKQMEwPbwl7JlzKKwZPu3TtFkUttdcyiU89ydPXVTQaLh8f3CX gEIt1JCwLJyqb0nGYOcK7OPab7/f16nGFErHi+YEqDO4LRoGvvNJIX+oVCpzXUCBNWwmLsOG3cVQ kliMRDQzqzVdDQqcdKw9/fW06zt2ZZaEhiMmmJY4wkTpZaIRoWlVCENQwYDhqDxhz2/tFcl1R1DU nDkXLnTzUNcyteSYgIpJoYXtWQw4OVg0f1FVFsEnzVQn8tx+ldNoUzqQ6Xt8UqikoP/wZ2rHcP/Y N2WA36EL4epaFvgkXADTlTUbam+TaTu7BBSyxL1rCrTMH5yGl0TF5HXWYMWhTz5gDG99lzIAfBJo q2xDzPftnc/QBgWxXsdQYuBIz0DzsK4CBQC6nyQyJkEcEiYvdHRDzKG26hCr2lRoo9YITy4GSj7Y 4Nfjd/3c8PDhrPb46I6guLL7A37eAM3x8OzHNFYePJzY0Xv8ZSt38wkBBnVY38YFCcMitnV0PkdR JvUvCwlvzGqvClfP+cdJU1wuLnCbgm7uSPquAaHxRoFCwZOYMz19nhDLFHB5BnvCtAqVXG7WUQhP vCyiNJ+Q68C+CXPEmMbadPKq9t5rFxRGEAPa6ypQ1KSmzZaQQuU4646raTP6Dm27xBwXNPYZgnBh WxEoAnzYqOKDg//uLJzd3UABzzmIfQPlGscJcC3S5BmP5TyWRSdBFk+2o9vvxKrobHiXu3Dxjc76 vc0XhkhXrFXmAu9kMNUyuqCMHzv7PAsH9EPK4XoY1wiDQYErY4tmB2QwB1uDKfO0nBwGxh8zEcyA 3d7tZz9rp4i9/R6QCf4IdjC5pNDHSKUy1RkUJk1OHfZlDKV86Bc0udGgUIjLpon8glR0XPnazhkP LBvsSzCH2SLOqAmI67vw56qEPV821NT66DIJ3Q0UtWnpq0rVJT+tSrHp4FkYX5cqU45/UE12n9ay jcz+uEJh3O9yeoFrp2FglcriasLuPLGXLyoE6wRHu3DkMv3tfjrNOwWbblpgwmVDPEtHdGnrjm/0 Kgh8xgzauz+GYTGyMYMg3HwTC1SyJupCu1GnQye3c3ACp19rCA+bXYLF4Rc6KrB7xqeA97NA00oC l6DSoKXqT32paslKxF8QssoYUGAfoGRtNIcJ437G1gUg5ICvhQMKxS7uiDXVp+by+zso8lNnpsN7 emVjuxsoynft4+b2G6bhF+Hi0PKk5AQddpnX+EvCd+OdsllmeDwC+9FIGBGZqONO9RZi85zLd+w+ yfXworC9fe9eCV3RyZwvVa8VHoC5AFcREECpBgbsPKVTZ6O6bPoqg0GBjxQyPb01KkjV53EnTr8O Wr9/W++Ubdl2lShMrO059mMe15w5G9URE9qgwBWymeb2PzYolJ4NSiCF/gSC9exod9IFFPLU1BFF Ht4aNT3qcwR414QdgT1xWlXJ2o2ZdQm7pxsa6ehuoIBnhvF9A+uJplMmjh6O91AqpFKdzI9bqWne vDET71MJRX64Bq5ofpBUO7+hI0hs8Xx2OOfKJrr19Xkv6bZEOhMUFVUrmpUD/5dsiLneWYi3I0be 5nj7XczXPlUFjgvsInOfeV6lmiz2CfiNCCIczuPM8n+kksn66wOKPFNzrGVkLzpPQR5oZYdDq5kE kNMGWSLp+s1X689fiMFFj13BR3cCRV1ewUaJdrU0vvghJEza0c0r2sTw9K7IJTjq2McocBn/QE6j jXje89pktRx7n+M0riFD44zQYMQY5/FQweaNNAgUTQ1/ckiI48cEWxo70SXrN331TPbzs9NbBMQz ETjpB88KQldc7Ew7dNeMdlqPXnbq018mTycXtuRCR1ekZLB8u5KP7gIKbPoU+QfvZJvZt0YPm02f 8HXv68PD1X0pxcQyH9wOH8YEplnSX5WEu7Q5jp3b30zDDOQ7j0M/fZ/+kcGgUJRXzONOmP6QaJ/h K3C4s/2rtWvdL8clyHKI2xUwIHAe/6T65KmozpjvrqCgu0+zzxpuj6haguXOnPOgem/Ktw0S6cT/ OVD4kWqzCKYTDR+ldR73q7ygQK8TmLcupC2XTNR01nEZPT9oabGh53P0Jdn+gyQemFFEufIA4NL4 RMNBgU0o8dqNd4iXCWATSjhx+uPaNOqCluynUjVO4O2ryCQKE4AEzufv7fkfHZtPFii9G5SOK2Uy 26K5CxophErXpsyuiTpJxJ3i1SAkhaTKs/M2GTPR3QUU1alpU5kOY/8gZqRzsBIgheitoHD5hnh+ kJy4JvD5HNbkmaiezrL6K0Bx6/wFX6GHV9M1Sc2gsBuFpFt3HDQGFK+X7z1wrBgaIhPqWXCYrHR9 9InmZAyYTpslbh7q0FeLtgeHW7RyXa4uRyDJA83iWISyCHzQiek8DhcP2r9IUGDeryV/mCqwcdYY W3MyC08yPoYpAo1YsmLdrcqDhzfre7VLdwKFYHnEB3wbF42oEdfaCYnDIrYawsfVPQe4OGLZUlyK j+TaODfe+PjY3r8CFNLEvf68UV28U6i1ZUUVSTB5hiqDWBKMtQdogacL5w2OX+BJ7TO6Qphk6fYE nY6T5o2ZGMfBl181H0fFNy/MmIvu8MSRLxIUT8dnc2XT1iru8BGI8q7Js0k7nD0FcODSBp6jG+LO 8r1ZER23oUGpnPwygQJbBUW+pJvEKlfsmBaNnfSbnE73MFBTL+e7TtEoFSmAT+CFYYjy0JdKIjbQ NQ7NYZPeZQKqo2YeMQoUeNGLV0dqXsIFjRe7TlbV84TqKBR7lp+CeBNHFq6VGjOpXiGTDdOF+bLY +B18okOPqyvBhJK+v7PoRYNCnVBCyPJG4r48rvs09c6gBkcbpQhkMBlxEo9j5YgEvqQnsoQ9aXIa ze1lAEXtmXNjCxxdH2USQuo4esSZR7piqHwbGhqcJYGhCmJxKZYdLp6sp9OfqwlVnrh3DdvJ7VEG 8Xg1zsq7ez5USKVjjAbF1b0HTrLxKbrmpFz/pnomwcLQfTVnzq4qsHJ4QCUsEuxQFYeEcXUdQD1f uFI4aUYjhWiiQF/ZZrZPLsXEfwe27nhckWokOWknEPUtCKwjU71l8YmFQm8/xIGdAyuCtrLc6t9g 8pnQVsF4DyRbE0VVScqw39Gvu4KibENMSrHWyTmsZa8fOW7UJQ6XtsQzcaFeS5YZF/dZjERVJ0/v 0lpnQ42dY1V9vXNlcopbWVTMvwuc3NQ3URLL93Fo+XLcjh8MzlMQ6Y5YvEg0aUYD+b1BGlsRHewz zjgPjVvi8MVYAgc3VBYZvUpXwWHbXRASLsvRstsxMBi46nHSDCRaHIbES1ch8ZKVelNJ8HJ8HQtq qK21MgYUzXT/1i2/8pXrdhVNnfVfLvgbuNaJeBsFMWGE8za4XEbkPhVs2YQKlUJh2t1AAb/3LSYt uZzdR/OSidKpPqiWTCMZA4rqU6fXscAnJVY5YJCIlq9mEJWUYGn4lzdWRRo0v+o5XhaB+PjS5zET EWOYrfrqVyIgcC1VOSiz+iLexs541n3RLg77D1FozYuWovUbjjZw3Kf+phAK9boBpCb1worL+LRe G9dmYocWV6SS3zaQXn8HMTy9n7khsAvOUwyW7UxK5geG3i0GzZSJTxq2VTWL/Y5/9EHFYDYo28gK v2hQ1JPpTuwJ0569ZGJh6C14x9oYUDTUy+2F/kEPKYSjBOojzn6kJ8rKypY7ndJ79vuyENervW3E POO1g2WoLX/4LX+QFSrbGHtGl/u8dI+QXCSfxs4zubdp+xcKY3t6mB2YTstPGhDCe/Pavv1fqH0L bWA8pwuWu+rkHfA+6IcvzyaXrdl4twB2T+x3NN+W3sID7CZsb99GpURi291AcW3fgcPYDyLez1UI i+jagY/yjAFEi08asT4Xn8+hEEwoprUTqv7sdMvlBxkmw79gdnGltHpNgqJiD7dHV7fv1jmsrNcA xSHhZ7ngW2CkZwwYrlW/bopYIMirUbF3wMGyNVSIlckfflk2eWbTzePNFY/GEhZMe6BwcnuCrwhV P4fPUcPWbugZbbxzVB86PudK2Jo8HnbK8VU9ICv1YugMFE7jmnZdXH6OlQuAyyhQ9BvWMn78Jw3a AwU2nbi+CwW5hOdx9A9f5HYrjRrYJfmCc+fV1+RQCH0UDrJUH3HWAAUOy3fFfD89T5EPiqFs0kxU tmHzWX1q0/Sd9Ndk2xK/kc4joTzQhgUwMDWZWqKiUe6oYnMcW6VQTjFWiHdZnI/K12/6he86Wd12 Uz9WhhMsMrEvCSllMo2Lg6WxCXZFYyahwgHmTc9BX0LzEejG4eMCY8dwj8Wady1uJ0vk468GWhZs 78wZcxqVsmdBUffdxc+vjJ2sPtmG+cClNKVO45EwJDzAkL5Fy1b9WGTSKjMmLEbewsWP2jrXUXvq lOtlMOvyQDE0PW+JGLBzSpas+L2r8kSK6mqLUlIoyocdq5kn/L1kzgJ8xFkd7qWamn8jHmJj3Dw3 02ArxHXzQKJZ/uxfGMzD+v7xIYO2QyVP6Hlle9KRytgdnJKISM71g0fYtV+fC+gKARLzA/Vfn/Or OnGKeSlqC0e8ah1HDH0ZQiUr13Ku7T/IUsk1/8qO/Fza0Etx29mlq54+C5+V0Vs58iz64a4ah7Ky yv/6wcOsQhf321cXh6F6Fu+ZhXaHL9z4Y8Iejhj4bOJjHacqfidHduzkJEP6rDr+6b/K10a3jP8S jKvi0FFaW+fDhSsjrUrXbOBgan7+xub3OTdOfL6vC+eyZ8WHhw5dW9fKkyh8Ladq157iajJ5gtoK iYiMq4qKNXiO1QTy+yEpmSNLSj5Qfeykp6H8Pves4it66szyeNa1+1MCqk+d6vVKHt2bXgnhFb2i V6B4Ra+oY/p/VH8b3FEpSw8AAAAASUVORK5CYII= --_004_47E83806AE926749BB17D1020685E6901903F0CC5FAPJ1XCHEVSPIN_-- From nobody Thu Jul 2 09:28:16 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240541AD09D for ; Thu, 2 Jul 2015 09:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.191 X-Spam-Level: * X-Spam-Status: No, score=1.191 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NalTEU8VSTyj for ; Thu, 2 Jul 2015 09:28:11 -0700 (PDT) Received: from nm22-vm1.bullet.mail.bf1.yahoo.com (nm22-vm1.bullet.mail.bf1.yahoo.com [98.139.212.127]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C06F81AD04E for ; Thu, 2 Jul 2015 09:28:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1435854491; bh=2T41oxU66HXwFpnd5Otcjf5qdB94Sr9yqQ317E60950=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=IkxM619+SKsY/kCXCSDcNvUgTCAjb405oFtJqTlsOBbkfAGi/ufybJWY08/UEZ6UcrS6TQ63buuAOWOKS7hGcAj/kadkKeXz4+X0QOEQhd7fXYvXwVAoL1XfavP9P11EowLBs27nxaKAiDt8mocx4t0uLARejlKEMcyQ/kfXoRsyKrROX6sZLpHuq+5H+huF1LAbb+hVX5Cw548fZcTaLCp87ZjTuiQrqiio7MZy1UAJLlMLoCsHJSkgM60ywJILDcIEcSHIbdA/swDZLSxPBp2EqZgP/8Zmps1QTuIZJRaK+ssK5qdKW/Ufjp0U8KJHlYpSjR530s/gCs/8iViKzQ== Received: from [98.139.215.143] by nm22.bullet.mail.bf1.yahoo.com with NNFMP; 02 Jul 2015 16:28:11 -0000 Received: from [98.139.215.249] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 02 Jul 2015 16:28:10 -0000 Received: from [127.0.0.1] by omp1062.mail.bf1.yahoo.com with NNFMP; 02 Jul 2015 16:28:09 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 984770.4285.bm@omp1062.mail.bf1.yahoo.com X-YMail-OSG: dR8TnJsVM1k47_FSLVz4UMtKfeVigU7QFkmjzOM_DFIIl0CQYinWkHE33u.EBKl fYJ_YxtmLnmyr4mo9myXIRkcUCtPJdobWovbfqADTL_TXPlq0U6SJh6BwS81n1ih93KEoRwS0fam F8sKAwzaY3OEVzfu4YApZSyg_ODsqTbKZP7NSYMi5JSBit9vHjGRHq67oMK61apbA3L66_kvG0nZ _6d.z.EF0TbvVpeuNRM0F7ucVnMR6O2noUZQd0us8YG4QvWw0bJ5eoqXNTtxBkzvnW5yhk1u1Z_t UlfWsjEYC0igfjkqCOFmKPbOGhbaLaWcahZos1ztHBGy8.q6P6bPqf2azqJZT98UzCPoQ83d53vP OQ01Wi1fwfzyCuUHxfDCycnc8Ia1tKg34lJMFMk21k51CaHSMeD3Z2tnkVyk8nXEwsPR7vlbKoAY kNc1Yl5_8TDQ4sep_p_vclgSbnK8LGVrx8w7KTXne5Kl.hwdroLfA.JgYKIB3UzuHAd9V0pH3au8 Sq72q31xBx3iIZQ-- Received: by 76.13.27.48; Thu, 02 Jul 2015 16:28:10 +0000 Date: Thu, 2 Jul 2015 16:28:10 +0000 (UTC) From: Bill Mills To: Lisa Li1 , "oauth@ietf.org" Message-ID: <1314028769.1323699.1435854490299.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <47E83806AE926749BB17D1020685E6901903F0CC5F@APJ1XCHEVSPIN36.SYMC.SYMANTEC.COM> References: <47E83806AE926749BB17D1020685E6901903F0CC5F@APJ1XCHEVSPIN36.SYMC.SYMANTEC.COM> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1323698_1696041608.1435854490298" Archived-At: Subject: Re: [OAUTH-WG] Question about usage of OAuth between servers X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 16:28:13 -0000 ------=_Part_1323698_1696041608.1435854490298 Content-Type: multipart/alternative; boundary="----=_Part_1323697_1624763601.1435854490291" ------=_Part_1323697_1624763601.1435854490291 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Using Bearer tokens with refresh tokens is a valid use case for server-to-s= erver and has the same nice properties that is does for users, in that it a= pplies a single control point for revoking access. =C2=A0Using Bearer token= s has very different security properties than OAuth 1.0a and you should car= efully consider this. =C2=A0Look at the proof-of-posession work rather than= simple Bearer tokens.=20 On Thursday, July 2, 2015 9:10 AM, Lisa Li1 wr= ote: =20 Hi All =C2=A0This is Lisa. Our project is adopting OAuth 2 as au= thentication specification. For the client-server communication, OAuth toke= n works fine. But we have some cases of server to server communication, usu= ally it will be multiple tasks running in parallel or sequence or even in m= ultiple threads. In this case, we are not sure we should reuse the access t= oken grant by end user or create another token? Moreover, if token is expir= ed in 30 min, we are able to do refresh but may meet some issue on the toke= n consistency between each task, thus it might be refreshed again and again= =E2=80=A6 =C2=A0But with OAuth 1.0, since it will not expired and we don=E2= =80=99t have to do refresh, it will work fine. =C2=A0So for OAuth 2.0, what= =E2=80=99s your consideration for server to server communication scenario? = Or do you have any suggestion here? =C2=A0Thanks. =C2=A0 =C2=A0Lisa LiPrinc= ipal Software EngineerSymantec Corporation =C2=A0Office: (010) 6272 5127=C2= =A0 /=C2=A0 Mobile: 189 1057 2219Lisa_Li1@symantec.com =C2=A0 =C2=A0 =C2=A0= This message (including any attachments) is intended only for the use of th= e individual or entity to which it is addressed and may contain information= that is non-public, proprietary, privileged, confidential, and exempt from= disclosure under applicable law or may constitute as attorney work product= . If you are not the intended recipient, you are hereby notified that any u= se, dissemination, distribution, or copying of this communication is strict= ly prohibited. If you have received this communication in error, notify us = immediately by telephone and (i) destroy this message if a facsimile or (ii= ) delete this message immediately if this is an electronic communication. = =C2=A0 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------=_Part_1323697_1624763601.1435854490291 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Using Bearer tokens with refresh tokens is a valid= use case for server-to-server and has the same nice properties that is doe= s for users, in that it applies a single control point for revoking access.=  Using Bearer tokens has very different security properties than OAut= h 1.0a and you should carefully consider this.  Look at the proof-of-p= osession work rather than simple Bearer tokens.



On Thursday, July 2, 2015 9:10 AM, Lisa Li1 <Lisa_Li1@symantec.= com> wrote:


=
Hi All
&nbs= p;
This is Lisa.
Our project is adopting OAuth 2 as authenticat= ion specification.
For the clie= nt-server communication, OAuth token works fine. But we have some cases of = server to server communication, usually it will be multiple tasks running i= n parallel or sequence or even in multiple threads. In this case, we are no= t sure we should reuse the access token grant by end user or create another= token? Moreover, if token is expired in 30 min, we are able to do refresh = but may meet some issue on the token consistency between each task, thus it= might be refreshed again and again=E2=80=A6
 
But with OA= uth 1.0, since it will not expired and we don=E2=80=99t have to do refresh,= it will work fine.
 
So for OAuth 2.0, what=E2=80=99s you= r consideration for server to server communication scenario? Or do you have= any suggestion here?
 
Thanks.
 
 =
Lisa Li=
Principal Software Engineer
Symantec Corporation
 
Office: (010) 6272 5127  /  Mobile: 189 1057 2219
Lisa_= Li1@symantec.com
 
3D"Mac
 
 
This message (including any attachments) is= intended only for the use of the individual or entity to which it is addre= ssed and may contain information that is non-public, proprietary, privilege= d, confidential, and exempt from disclosure under applicable law or may con= stitute as attorney work product. If you are not the intended recipient, yo= u are hereby notified that any use, dissemination, distribution, or copying= of this communication is strictly prohibited. If you have received this co= mmunication in error, notify us immediately by telephone and (i) destroy th= is message if a facsimile or (ii) delete this message immediately if this i= s an electronic communication.<= /div>
 
<= br>_______________________________________________
OAuth mailing listOAuth@= ietf.org
https://www.ietf.org/mailman/listinfo/oauth


<= /div>
------=_Part_1323697_1624763601.1435854490291-- ------=_Part_1323698_1696041608.1435854490298 Content-Type: image/png Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=image002.png Content-ID: iVBORw0KGgoAAAANSUhEUgAAAMUAAAAqCAYAAAADKp+nAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAABsASURBVHja 7V15XJPH1rbLd29rrXUFN2QHZXMBxQ3cQFwA0YAILqDihogiUlREUalSa12qtrXW1mu91FJMCAHC lo2EbAQ0YkREiqU010s1rU1tVJT5zgSBN5ElC1a89Y9jYn7vO3PmzDxnzjZDjz179vR4Ra/o70II oX+K10VF0XqbRrC9fLdURMaulSUfmqmQSHoyXCcHp/Xo8forQb2ivxsoetZeuPiteJY/qvz4k6Ly jbGPhPOD635KvcDKHGr9ZHaPHm++EtQr+ltS0byAHyS+QcPEqyNzrvkFovLAUER3GFvbo0ePN3qc 69HDlNV3sCdtoBWQmScZvgsnT/OUJaX060omyIOt3Aqe9qEm6IftNdsDkPtGB6gerjhzzpPu4qrm q+VdfakX7svXA1VXv6ULr8raWqfK6NgWmehDvAUhng1SmSfw/qausqlNS7Pmubi3jJHc18yT7eDq yQta048gizcksfETab0GGi4HneQ02wNMibc70bbvolq5J2vabE8y8COEMSsrq8c/B63uoqAXNPXT 1/ixSeMT3KHN1+jR0f+Uxu1QyHbvHnXzi68E1XtTfqlLOoAqDh65pwYFf0HwOomNM8rpb4boJuaI PsAMCa2ckCQyJhE30BWDqz6XOo87yr0xr9+wpj6ACvsMQcWkkEro45kJUCkU7jUphygcr3k/CyfN QHnDbIGv4S3v6k3vDUL8OQFIKZVad8TnvcqqRVWb4iiFk2bcB37hXQu9+2KOGI1KfOYjoV+Q4L/k zM9hfP/oFBQX0j8tGzUB5fQbqm4jp/8wJHJwRbzgsPmEBfJeWfTW+3nvmhouBx3kJJgzH8mFQrv2 eJVLJCNL129mlwcEo0IrR0SHdcOyH4W4s/zQ1S3b0lUK+RBj14tSLre7lrj3dMmSlSrhtNmo0Br6 GWjc2PJ7D0KXt2z/Fa83vK4f1tXNQgpFb1V9/eQGpdLuofJ+QMOdez4Aitd63CuXLRK6T39CeW8w og4crqYcWLD8kPCaLkL767zgZQd4FiNRBkw2bp/SdwgSjhiLxGsiY7Sfv1vASuLPWfBfnqUDosFA yL1NUQYAtZk3gwja4Pj4PwFQWLXHpzgyJlA0y/8RZ6gtosLCo4AMDOkrAxb2xXcGoDwYq8DRDZWH RfDuVVSROpLRT99+f0zgPB5l9B3S0kbRiDGIHxzmS5Bj77JNcXdovUyMk0Vncprl21gvkdi0xecd sXhFWUjYIzrI5mLP/k3zCQuOAvxS3hmIii0cUPG8heWKgoLBhjrB1SmHwyQLFz9gmdmhDGjz4rsm LevGGMqCOb0cu12OfYrO+MCM/INPCrlLA1Bk4AnBjcDkFI2b8ruysnJqF4DiDY4vqY4GWqi5fVrf oYjt4n5HzmKNJj77HwbreMX8YJQJwiCDoJufN5pgstk+/o/bA4U0KZnEcZ3SQIPnKADAruqXDGMu hM+yJSsf3+YJ2wXGTxfSj/IBFFhZ4PfwIuO0CYqtv2QCKLpMLm3IiePj96QtUED/5pc2xDzKhv4p sEjbHC/wzwSNLlm94TI830vPdfJmzb/+zeG7TUHUngPa7cNQoqlBse1nnUCB/7kcE/9dPkb80wWB BydyckNXk5L3GAuKutTUGYyRY+5nEhY5HUDBDQy9QnyunsUeK/Dxv08FQGgMCO8SQJnw3WBqAgVq CxT36+r8QTM1YKFpAMKAfvHz2pOJ/w9+ALqyJqrhYf2d2caA4tKmrXezYFF2xkdGW8DWZSxNoEBt gaLq5KmkYuCJ/JRHooy0FYEATM+6dPJ6fdZJWUz8Mi6sOQrMg0G8d0LZ0K40dtt/dAZFHZm6XDxx OrrYm6DNQfiiiMhqaOT/jAGFaGnEQb61c+tigU8WmFJgnq3T0NaJeyrztRYV3i3o8Jk31Oa5gQIc rtNq/gigxTwUDLZG9CHWevWTC3yyzUciKuy6RIDhcbCgrSt7PhC25WPovFNEb1W8CFBgx5q3YDED m4TNbePxZWH/Z5DlU6CYt/TFAjmURsVk6bpG6nk8G87MuU8ytQCB5ZAJa5Ix3L5LQHF5y7bbOoMC HuzHnT1fnk3QAlSwGzkTpv4JJpSbEabTu5y5C2qwWdLcbjpozTIvP3RPKlvc4lhVVo5kuU35ldZn sMZCYgyzQ5KA4BvlcQkxtIFmzgbTWwOdeV4LnFBlpcaCVKlUw3kLF9dTwQcgAiLH1AJdXhYhku1N DtWnn6rjp1bVfvgxdtQfZGM7m7A4sZ8hAKdRISkLMBAUr0tj40fisXTGB8+XdBMHTpr7zoS5ZHv7 /sqevWBiZ3Jie8121pYT+AjmRdPnIAphHjOB18LxnvKK/YcSGBOmPyG/SzDrYI5F8xf9hpRKe13W iSB4+SesITYaYKbAWmCCgikLX/PH9Y+OfG7U/APRYWzS2IQRWI46gUKtMeMTc3KJTIGJIwRHERhK NhQUtTS6e6HL+MdUghbOhnZFQUt/AOZMmp+rPHRsp3DUBEQmgCIbJlXkF1iiQmjQ84pVV59Ls2N5 eIEt3bpD5oL240zxkugSNWo3iiWVkUqDlqoyCJoPg63I0hFdP3oi3RBQ6EPisIhyOgEU2F/kLQz5 RZ8wsYbpdPhkIsvKsTGDsIsXmlqi8sS9THV/S8JZBSYWrbsIjIPjNA5Vf3ZmSWdtK6RSR97Mufcy CXOA1x7L0gFdiY79Hnh2/KtzGK0L+Otzi0smzdAwobLhuyh8jRRrfEMavxKfeKTYdlSrSQRCywdh Vhw6SiU+BwszjgMmVbNmvQh2aenEGaj63Pl1z3PwkshYG7qj6xNq36Et/DFg669I+TjX2LZr06gR QjBJyQR5YhMqZ+SYM88bFMIlK2TPgCJg0R0c1jVgt3+rOCA4lwFmUvP84Mgc18Ud3bqQtlYNmi++ SmFbO2mYvozBVuhyXEJhZ+2zp/mOZTuMbRk7pgLYqblzArBi+ueLSOwRB28JiK3N6kuI+sDiZHt4 NyqEEgcDhNmftyD4ajYhqoXDa5Jpc9BteoG/RmLP1DyOBYJofi4LFgXT0VXeIK+3f66giE2wyXUe pwGKQgDFjaMnC41tG0dfWJNnltAJ8qTB+HlzA/AuafGygEJZXW3H9yMhck+CiQmmIJhHfzYolU7q 3AWNbs+d6qPhJGPNL5xHwiHQkR21f3lbUko+AK7FbIc5yAMfQhIVu/BFZbs1F0lULCOP4DDhySke ORbVfPVNit6mSWraaI67J6IQQJEF5lFJ4BK8KCw7AkUefL/Yd/DV5z349kBR+fEnhV3RfsHYSemM QVatflLP/qgkJByGj8a+LKCoOfP1VoaNEyKaTkzY8cQRGwqbk7vw2Yc3f5GATjCTLwJAxJNnotq0 9OCO2q88+imPMdS2xfTCc0F3Hod4y6KHdgtQyJL2B/FdWm17vF1iP0OyNlqAB66X6bR7/3EO2IUt ziZecIOt0bWDh7OfKQHRAgW26+Gz4mUGBbaFS4KWPiJq2EIYF3WQZZp2aUt3BQV2SktWRzIZMG8t 1kO/YYhp7YxqzpyNJT57bd+BFK6ti4YJhcP8sv0fMTr0V058oQkKaD/HzgVJ4uNHdgtQwHY4onjG nJ8zCYk2MmyVQv8g1CCX2+khzH7F8xaIconh1d6mSDTFC9XRsuf/HUBRHp+4kWVDCPVC2+xhdojr H5j2svgUqvp6F5Ev6U8KIXeEQc73C0RgVtlqlH/Q6Q6McR6N1D6aloEoILhW2zIg0o2jJ1LyYeeh EpQnE8wn6c49n3YLUGAqWRuVj52kjIFmLZqBYzcK/Xgh/aDOTiaZ5sKfNhsRw3RU+C4mhWIb0/Z/ GRQwvgG3z12I40yY/oRKMB2x+VFoPgJVHf9s58sCiqrjp9Zx7Eero0HNlgNeG6Llq3OxA64dfhcE L5dmEQIL2Ics9fRBt7Ppi9vrQ5qQNJY3fiqiEN7LBH4FM+f9oaysDugWoJDtP7SEDYLIIGg4HA2Q rI0q0jUKVXny1GEGLIAMQtSJbWaHpHEJGW093yYoTMxeKp9CIZFOLI9L2Hpl9YabovGeCIdjKcRE FOy4JaRQpKquNn9ZQFEaHcstMLXUADbb1qWx5uz5xDZ3xx27kgXggxJ3x1z4rNh/KLcjM7M0bO09 jVwRvIfzPOLApQ/upFPD2ioa/UtBAWaSPd9n/m8ZhBobXPxVsmAx3jKddNCU74gWL+fnm5hrxp2d 3NCt1AuLdAEFFZdGWIz4vTRqC6V0I1CU/nQzbgdFEhk7/XmCAsbqfOt86s6rq9bncGfORVgR4ASo OqxNHD+YEYVm9ujmiVNnsXxeBlA0qFSjRT7+v1CJ+YNeA3HBH1LJZOZtvVMvFLoyR0/4k5iXwnyw Z/lVdRiU+fzMCYGDq0aeCgMDFygKQMEwPbwl7JlzKKwZPu3TtFkUttdcyiU89ydPXVTQaLh8f3CX gEIt1JCwLJyqb0nGYOcK7OPab7/f16nGFErHi+YEqDO4LRoGvvNJIX+oVCpzXUCBNWwmLsOG3cVQ kliMRDQzqzVdDQqcdKw9/fW06zt2ZZaEhiMmmJY4wkTpZaIRoWlVCENQwYDhqDxhz2/tFcl1R1DU nDkXLnTzUNcyteSYgIpJoYXtWQw4OVg0f1FVFsEnzVQn8tx+ldNoUzqQ6Xt8UqikoP/wZ2rHcP/Y N2WA36EL4epaFvgkXADTlTUbam+TaTu7BBSyxL1rCrTMH5yGl0TF5HXWYMWhTz5gDG99lzIAfBJo q2xDzPftnc/QBgWxXsdQYuBIz0DzsK4CBQC6nyQyJkEcEiYvdHRDzKG26hCr2lRoo9YITy4GSj7Y 4Nfjd/3c8PDhrPb46I6guLL7A37eAM3x8OzHNFYePJzY0Xv8ZSt38wkBBnVY38YFCcMitnV0PkdR JvUvCwlvzGqvClfP+cdJU1wuLnCbgm7uSPquAaHxRoFCwZOYMz19nhDLFHB5BnvCtAqVXG7WUQhP vCyiNJ+Q68C+CXPEmMbadPKq9t5rFxRGEAPa6ypQ1KSmzZaQQuU4646raTP6Dm27xBwXNPYZgnBh WxEoAnzYqOKDg//uLJzd3UABzzmIfQPlGscJcC3S5BmP5TyWRSdBFk+2o9vvxKrobHiXu3Dxjc76 vc0XhkhXrFXmAu9kMNUyuqCMHzv7PAsH9EPK4XoY1wiDQYErY4tmB2QwB1uDKfO0nBwGxh8zEcyA 3d7tZz9rp4i9/R6QCf4IdjC5pNDHSKUy1RkUJk1OHfZlDKV86Bc0udGgUIjLpon8glR0XPnazhkP LBvsSzCH2SLOqAmI67vw56qEPV821NT66DIJ3Q0UtWnpq0rVJT+tSrHp4FkYX5cqU45/UE12n9ay jcz+uEJh3O9yeoFrp2FglcriasLuPLGXLyoE6wRHu3DkMv3tfjrNOwWbblpgwmVDPEtHdGnrjm/0 Kgh8xgzauz+GYTGyMYMg3HwTC1SyJupCu1GnQye3c3ACp19rCA+bXYLF4Rc6KrB7xqeA97NA00oC l6DSoKXqT32paslKxF8QssoYUGAfoGRtNIcJ437G1gUg5ICvhQMKxS7uiDXVp+by+zso8lNnpsN7 emVjuxsoynft4+b2G6bhF+Hi0PKk5AQddpnX+EvCd+OdsllmeDwC+9FIGBGZqONO9RZi85zLd+w+ yfXworC9fe9eCV3RyZwvVa8VHoC5AFcREECpBgbsPKVTZ6O6bPoqg0GBjxQyPb01KkjV53EnTr8O Wr9/W++Ubdl2lShMrO059mMe15w5G9URE9qgwBWymeb2PzYolJ4NSiCF/gSC9exod9IFFPLU1BFF Ht4aNT3qcwR414QdgT1xWlXJ2o2ZdQm7pxsa6ehuoIBnhvF9A+uJplMmjh6O91AqpFKdzI9bqWne vDET71MJRX64Bq5ofpBUO7+hI0hs8Xx2OOfKJrr19Xkv6bZEOhMUFVUrmpUD/5dsiLneWYi3I0be 5nj7XczXPlUFjgvsInOfeV6lmiz2CfiNCCIczuPM8n+kksn66wOKPFNzrGVkLzpPQR5oZYdDq5kE kNMGWSLp+s1X689fiMFFj13BR3cCRV1ewUaJdrU0vvghJEza0c0r2sTw9K7IJTjq2McocBn/QE6j jXje89pktRx7n+M0riFD44zQYMQY5/FQweaNNAgUTQ1/ckiI48cEWxo70SXrN331TPbzs9NbBMQz ETjpB88KQldc7Ew7dNeMdlqPXnbq018mTycXtuRCR1ekZLB8u5KP7gIKbPoU+QfvZJvZt0YPm02f 8HXv68PD1X0pxcQyH9wOH8YEplnSX5WEu7Q5jp3b30zDDOQ7j0M/fZ/+kcGgUJRXzONOmP6QaJ/h K3C4s/2rtWvdL8clyHKI2xUwIHAe/6T65KmozpjvrqCgu0+zzxpuj6haguXOnPOgem/Ktw0S6cT/ OVD4kWqzCKYTDR+ldR73q7ygQK8TmLcupC2XTNR01nEZPT9oabGh53P0Jdn+gyQemFFEufIA4NL4 RMNBgU0o8dqNd4iXCWATSjhx+uPaNOqCluynUjVO4O2ryCQKE4AEzufv7fkfHZtPFii9G5SOK2Uy 26K5CxophErXpsyuiTpJxJ3i1SAkhaTKs/M2GTPR3QUU1alpU5kOY/8gZqRzsBIgheitoHD5hnh+ kJy4JvD5HNbkmaiezrL6K0Bx6/wFX6GHV9M1Sc2gsBuFpFt3HDQGFK+X7z1wrBgaIhPqWXCYrHR9 9InmZAyYTpslbh7q0FeLtgeHW7RyXa4uRyDJA83iWISyCHzQiek8DhcP2r9IUGDeryV/mCqwcdYY W3MyC08yPoYpAo1YsmLdrcqDhzfre7VLdwKFYHnEB3wbF42oEdfaCYnDIrYawsfVPQe4OGLZUlyK j+TaODfe+PjY3r8CFNLEvf68UV28U6i1ZUUVSTB5hiqDWBKMtQdogacL5w2OX+BJ7TO6Qphk6fYE nY6T5o2ZGMfBl181H0fFNy/MmIvu8MSRLxIUT8dnc2XT1iru8BGI8q7Js0k7nD0FcODSBp6jG+LO 8r1ZER23oUGpnPwygQJbBUW+pJvEKlfsmBaNnfSbnE73MFBTL+e7TtEoFSmAT+CFYYjy0JdKIjbQ NQ7NYZPeZQKqo2YeMQoUeNGLV0dqXsIFjRe7TlbV84TqKBR7lp+CeBNHFq6VGjOpXiGTDdOF+bLY +B18okOPqyvBhJK+v7PoRYNCnVBCyPJG4r48rvs09c6gBkcbpQhkMBlxEo9j5YgEvqQnsoQ9aXIa ze1lAEXtmXNjCxxdH2USQuo4esSZR7piqHwbGhqcJYGhCmJxKZYdLp6sp9OfqwlVnrh3DdvJ7VEG 8Xg1zsq7ez5USKVjjAbF1b0HTrLxKbrmpFz/pnomwcLQfTVnzq4qsHJ4QCUsEuxQFYeEcXUdQD1f uFI4aUYjhWiiQF/ZZrZPLsXEfwe27nhckWokOWknEPUtCKwjU71l8YmFQm8/xIGdAyuCtrLc6t9g 8pnQVsF4DyRbE0VVScqw39Gvu4KibENMSrHWyTmsZa8fOW7UJQ6XtsQzcaFeS5YZF/dZjERVJ0/v 0lpnQ42dY1V9vXNlcopbWVTMvwuc3NQ3URLL93Fo+XLcjh8MzlMQ6Y5YvEg0aUYD+b1BGlsRHewz zjgPjVvi8MVYAgc3VBYZvUpXwWHbXRASLsvRstsxMBi46nHSDCRaHIbES1ch8ZKVelNJ8HJ8HQtq qK21MgYUzXT/1i2/8pXrdhVNnfVfLvgbuNaJeBsFMWGE8za4XEbkPhVs2YQKlUJh2t1AAb/3LSYt uZzdR/OSidKpPqiWTCMZA4rqU6fXscAnJVY5YJCIlq9mEJWUYGn4lzdWRRo0v+o5XhaB+PjS5zET EWOYrfrqVyIgcC1VOSiz+iLexs541n3RLg77D1FozYuWovUbjjZw3Kf+phAK9boBpCb1worL+LRe G9dmYocWV6SS3zaQXn8HMTy9n7khsAvOUwyW7UxK5geG3i0GzZSJTxq2VTWL/Y5/9EHFYDYo28gK v2hQ1JPpTuwJ0569ZGJh6C14x9oYUDTUy+2F/kEPKYSjBOojzn6kJ8rKypY7ndJ79vuyENervW3E POO1g2WoLX/4LX+QFSrbGHtGl/u8dI+QXCSfxs4zubdp+xcKY3t6mB2YTstPGhDCe/Pavv1fqH0L bWA8pwuWu+rkHfA+6IcvzyaXrdl4twB2T+x3NN+W3sID7CZsb99GpURi291AcW3fgcPYDyLez1UI i+jagY/yjAFEi08asT4Xn8+hEEwoprUTqv7sdMvlBxkmw79gdnGltHpNgqJiD7dHV7fv1jmsrNcA xSHhZ7ngW2CkZwwYrlW/bopYIMirUbF3wMGyNVSIlckfflk2eWbTzePNFY/GEhZMe6BwcnuCrwhV P4fPUcPWbugZbbxzVB86PudK2Jo8HnbK8VU9ICv1YugMFE7jmnZdXH6OlQuAyyhQ9BvWMn78Jw3a AwU2nbi+CwW5hOdx9A9f5HYrjRrYJfmCc+fV1+RQCH0UDrJUH3HWAAUOy3fFfD89T5EPiqFs0kxU tmHzWX1q0/Sd9Ndk2xK/kc4joTzQhgUwMDWZWqKiUe6oYnMcW6VQTjFWiHdZnI/K12/6he86Wd12 Uz9WhhMsMrEvCSllMo2Lg6WxCXZFYyahwgHmTc9BX0LzEejG4eMCY8dwj8Wady1uJ0vk468GWhZs 78wZcxqVsmdBUffdxc+vjJ2sPtmG+cClNKVO45EwJDzAkL5Fy1b9WGTSKjMmLEbewsWP2jrXUXvq lOtlMOvyQDE0PW+JGLBzSpas+L2r8kSK6mqLUlIoyocdq5kn/L1kzgJ8xFkd7qWamn8jHmJj3Dw3 02ArxHXzQKJZ/uxfGMzD+v7xIYO2QyVP6Hlle9KRytgdnJKISM71g0fYtV+fC+gKARLzA/Vfn/Or OnGKeSlqC0e8ah1HDH0ZQiUr13Ku7T/IUsk1/8qO/Fza0Etx29mlq54+C5+V0Vs58iz64a4ah7Ky yv/6wcOsQhf321cXh6F6Fu+ZhXaHL9z4Y8Iejhj4bOJjHacqfidHduzkJEP6rDr+6b/K10a3jP8S jKvi0FFaW+fDhSsjrUrXbOBgan7+xub3OTdOfL6vC+eyZ8WHhw5dW9fKkyh8Ladq157iajJ5gtoK iYiMq4qKNXiO1QTy+yEpmSNLSj5Qfeykp6H8Pves4it66szyeNa1+1MCqk+d6vVKHt2bXgnhFb2i V6B4Ra+oY/p/VH8b3FEpSw8AAAAASUVORK5CYII= ------=_Part_1323698_1696041608.1435854490298-- From nobody Thu Jul 2 09:34:18 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D671AD1A3 for ; Thu, 2 Jul 2015 09:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.944 X-Spam-Level: X-Spam-Status: No, score=-0.944 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VftTj1cCuVjY for ; Thu, 2 Jul 2015 09:34:13 -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 20BA41AD2D9 for ; Thu, 2 Jul 2015 09:33:55 -0700 (PDT) Received: from pps.filterd (m0074411.ppops.net [127.0.0.1]) by mx0a-0019e102.pphosted.com (8.15.0.59/8.14.7) with SMTP id t62GUFla008303 for ; Thu, 2 Jul 2015 11:33:54 -0500 Received: from mail-yk0-f170.google.com (mail-yk0-f170.google.com [209.85.160.170]) by mx0a-0019e102.pphosted.com with ESMTP id 1vd8npg133-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 02 Jul 2015 11:33:54 -0500 Received: by ykdr198 with SMTP id r198so72995515ykd.3 for ; Thu, 02 Jul 2015 09:33:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=jXdPYVNxZHH2lcLvP22HlhUrd1M6tpxy0QFzvvUBGug=; b=BJhDDVlEr5Cf1pXXZpTV9EKc1MgFB1Z1HmGbXaMBg7jnodPdzpxF+5ei8086ZWCZ0I 9C4rpHs8ZfDmJ9QgE3yMd730DHDovvCROP6zePuD+bGB8SpzTrc5AB2eQKEp++O/IBmE Im6ckJi1ifewve7I8/V9ndaaCRSE99CC5ba5jQwiLtNXfZCY46xgBMgI2h3PhyrVu693 /Mh9dquyvSiR8JRM9yNKUTLCskdg90ZzLvsyPYdnbC0iwzvQtXVjJwTgzC7tTcT8i3Ax p2wI5Vowzm7SRUGV7J53mEnAZfbQc1rGsIxxtJaw3yzSA76LZNFKMLuPrcXmFv9OWplE eo2Q== X-Gm-Message-State: ALoCoQlrlwCA2a4ZXbZ4tjTYqr3G5PIOYmKmdz7uuz9b08zVki5z2KgdLI/zDU+nfPxQBsvqBWkn4x8Y9wN8m1VYnwqltxCrPE1m/ljq2m3u6IlP4lh6Gfp9JTUvz4qZox/u3HgpfGJg X-Received: by 10.170.187.134 with SMTP id d128mr39534846yke.103.1435854833470; Thu, 02 Jul 2015 09:33:53 -0700 (PDT) X-Received: by 10.170.187.134 with SMTP id d128mr39534831yke.103.1435854833286; Thu, 02 Jul 2015 09:33:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.73.70 with HTTP; Thu, 2 Jul 2015 09:33:33 -0700 (PDT) In-Reply-To: <47E83806AE926749BB17D1020685E6901903F0CC5F@APJ1XCHEVSPIN36.SYMC.SYMANTEC.COM> References: <47E83806AE926749BB17D1020685E6901903F0CC5F@APJ1XCHEVSPIN36.SYMC.SYMANTEC.COM> From: Adam Lewis Date: Thu, 2 Jul 2015 11:33:33 -0500 Message-ID: To: Lisa Li1 Content-Type: multipart/related; boundary=001a1139cf2249d81c0519e7015a X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=1 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1507020257 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Question about usage of OAuth between servers X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 16:34:16 -0000 --001a1139cf2249d81c0519e7015a Content-Type: multipart/alternative; boundary=001a1139cf2249d8170519e70159 --001a1139cf2249d8170519e70159 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Lisa, Form the perspective of OAuth, there is ALWAYS a client (even if it is running on a server). Of your two servers, one is exposing an API (so this will be your RS), and the other server is a client of that API, so that will be your Client. So it is still a client-server communication. So it's a question then if whether or not the server (acting as an API client) is accessing the other server's API on it's own behalf or on behalf of an end user, and if acting on behalf of an end user, then how does the end user interact with the server (acting as the API client)? If the server acting as an API client is acting on its own behalf, then you want the client credential grant type (or possible a SAML or JWT assertion)= . If the server acting as an API client is acting on behalf of an end user and the end user is coming in through a browser, then you want the authorization code grant type. If the server acting as an API client is acting on behalf of an end user and the end user directly signs onto the server, then you might be stuck using the RO password grant type. authorization code and RO grant types give you a refresh token that you can use to refresh the access token. In the case of client credentials, the client stores a long term PSK or has a public private key pair used to request access tokens, so it will directly communicate with the token endpoint using those to get new access tokens. Does that make sense? adam On Mon, Jun 29, 2015 at 9:18 PM, Lisa Li1 wrote: > Hi All > > > > This is Lisa. > > Our project is adopting OAuth 2 as authentication specification. > > For the client-server communication, OAuth token works fine. But we have > some cases of server to server communication, usually it will be multiple > tasks running in parallel or sequence or even in multiple threads. In thi= s > case, we are not sure we should reuse the access token grant by end user = or > create another token? Moreover, if token is expired in 30 min, we are abl= e > to do refresh but may meet some issue on the token consistency between ea= ch > task, thus it might be refreshed again and again=E2=80=A6 > > > > But with OAuth 1.0, since it will not expired and we don=E2=80=99t have t= o do > refresh, it will work fine. > > > > So for OAuth 2.0, what=E2=80=99s your consideration for server to server > communication scenario? Or do you have any suggestion here? > > > > Thanks. > > > > > > *Lisa Li* > > Principal Software Engineer > > Symantec Corporation > > > > Office: (010) 6272 5127 / Mobile: 189 1057 2219 > > Lisa_Li1@symantec.com > > > > [image: Mac Pro 7 > HD:Users:megumi:Desktop:VERITAS_IDENTITY:ASSETS_DELIVERED:VERITAS_ESIG_RE= D_w_TM.png] > > > > > > This message (including any attachments) is intended only for the use of > the individual or entity to which it is addressed and may contain > information that is non-public, proprietary, privileged, confidential, an= d > exempt from disclosure under applicable law or may constitute as attorney > work product. If you are not the intended recipient, you are hereby > notified that any use, dissemination, distribution, or copying of this > communication is strictly prohibited. If you have received this > communication in error, notify us immediately by telephone and (i) destro= y > this message if a facsimile or (ii) delete this message immediately if th= is > is an electronic communication. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a1139cf2249d8170519e70159 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Lisa,

Form the perspective of OAuth,= there is ALWAYS a client (even if it is running on a server).=C2=A0 Of you= r two servers, one is exposing an API (so this will be your RS), and the ot= her server is a client of that API, so that will be your Client.=C2=A0 So i= t is still a client-server communication. =C2=A0

S= o it's a question then if whether or not the server (acting as an API c= lient) is accessing the other server's API on it's own behalf or on= behalf of an end user, and if acting on behalf of an end user, then how do= es the end user interact with the server (acting as the API client)?
<= div>
If the server acting as an API client is acting on its o= wn behalf, then you want the client credential grant type (or possible a SA= ML or JWT assertion).
If the server acting as an API client is ac= ting on behalf of an end user and the end user is coming in through a brows= er, then you want the authorization code grant type.
If the serve= r acting as an API client is acting on behalf of an end user and the end us= er directly signs onto the server, then you might be stuck using the RO pas= sword grant type.

authorization code and RO grant = types give you a refresh token that you can use to refresh the access token= .=C2=A0 In the case of client credentials, the client stores a long term PS= K or has a public private key pair used to request access tokens, so it wil= l directly communicate with the token endpoint using those to get new acces= s tokens.

Does that make sense?
adam

On Mon, J= un 29, 2015 at 9:18 PM, Lisa Li1 <Lisa_Li1@symantec.com>= wrote:

Hi All

=C2=A0

This is Li= sa.

Our project is adopting OAuth = 2 as authentication specification.

For the client-server communication, OAuth token works fine. But we have s= ome cases of server to server communication, usually it will be multiple ta= sks running in parallel or sequence or even in multiple threads. In this ca= se, we are not sure we should reuse the access token grant by end user or c= reate another token? Moreover, if token is expired in 30 min, we are able t= o do refresh but may meet some issue on the token consistency between each = task, thus it might be refreshed again and again=E2=80=A6

=

=C2=A0

But w= ith OAuth 1.0, since it will not expired and we don=E2=80=99t have to do re= fresh, it will work fine.

= =C2=A0

So for OAuth 2.0, what=E2=80=99s yo= ur consideration for server to server communication scenario? Or do you hav= e any suggestion here?

=C2= =A0

Thanks.

=C2=A0

=C2=A0

Lisa Li

Principal Software= Engineer

Symantec Corporation

=C2=A0

Office: (010) 6272 5127=C2=A0 /=C2= =A0 Mobile: 189 1057 2219

Lisa_Li1@symantec.com

=C2=A0

3D"Mac=

=C2=A0

T= his message (including any attachments) is intended only for the use of the= individual or entity to which it is addressed and may contain information = that is non-public, proprietary, privileged, confidential, and exempt from = disclosure under applicable law or may constitute as attorney work product.= If you are not the intended recipient, you are hereby notified that any us= e, dissemination, distribution, or copying of this communication is strictl= y prohibited. If you have received this communication in error, notify us i= mmediately by telephone and (i) destroy this message if a facsimile or (ii)= delete this message immediately if this is an electronic communication.

=C2=A0


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


--001a1139cf2249d8170519e70159-- --001a1139cf2249d81c0519e7015a Content-Type: image/png; name="image002.png" Content-Disposition: inline; filename="image002.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: bbd348f4aadd7be0_0.0.1 iVBORw0KGgoAAAANSUhEUgAAAMUAAAAqCAYAAAADKp+nAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAABsASURBVHja 7V15XJPH1rbLd29rrXUFN2QHZXMBxQ3cQFwA0YAILqDihogiUlREUalSa12qtrXW1mu91FJMCAHC lo2EbAQ0YkREiqU010s1rU1tVJT5zgSBN5ElC1a89Y9jYn7vO3PmzDxnzjZDjz179vR4Ra/o70II oX+K10VF0XqbRrC9fLdURMaulSUfmqmQSHoyXCcHp/Xo8forQb2ivxsoetZeuPiteJY/qvz4k6Ly jbGPhPOD635KvcDKHGr9ZHaPHm++EtQr+ltS0byAHyS+QcPEqyNzrvkFovLAUER3GFvbo0ePN3qc 69HDlNV3sCdtoBWQmScZvgsnT/OUJaX060omyIOt3Aqe9qEm6IftNdsDkPtGB6gerjhzzpPu4qrm q+VdfakX7svXA1VXv6ULr8raWqfK6NgWmehDvAUhng1SmSfw/qausqlNS7Pmubi3jJHc18yT7eDq yQta048gizcksfETab0GGi4HneQ02wNMibc70bbvolq5J2vabE8y8COEMSsrq8c/B63uoqAXNPXT 1/ixSeMT3KHN1+jR0f+Uxu1QyHbvHnXzi68E1XtTfqlLOoAqDh65pwYFf0HwOomNM8rpb4boJuaI PsAMCa2ckCQyJhE30BWDqz6XOo87yr0xr9+wpj6ACvsMQcWkkEro45kJUCkU7jUphygcr3k/CyfN QHnDbIGv4S3v6k3vDUL8OQFIKZVad8TnvcqqRVWb4iiFk2bcB37hXQu9+2KOGI1KfOYjoV+Q4L/k zM9hfP/oFBQX0j8tGzUB5fQbqm4jp/8wJHJwRbzgsPmEBfJeWfTW+3nvmhouBx3kJJgzH8mFQrv2 eJVLJCNL129mlwcEo0IrR0SHdcOyH4W4s/zQ1S3b0lUK+RBj14tSLre7lrj3dMmSlSrhtNmo0Br6 GWjc2PJ7D0KXt2z/Fa83vK4f1tXNQgpFb1V9/eQGpdLuofJ+QMOdez4Aitd63CuXLRK6T39CeW8w og4crqYcWLD8kPCaLkL767zgZQd4FiNRBkw2bp/SdwgSjhiLxGsiY7Sfv1vASuLPWfBfnqUDosFA yL1NUQYAtZk3gwja4Pj4PwFQWLXHpzgyJlA0y/8RZ6gtosLCo4AMDOkrAxb2xXcGoDwYq8DRDZWH RfDuVVSROpLRT99+f0zgPB5l9B3S0kbRiDGIHxzmS5Bj77JNcXdovUyMk0Vncprl21gvkdi0xecd sXhFWUjYIzrI5mLP/k3zCQuOAvxS3hmIii0cUPG8heWKgoLBhjrB1SmHwyQLFz9gmdmhDGjz4rsm LevGGMqCOb0cu12OfYrO+MCM/INPCrlLA1Bk4AnBjcDkFI2b8ruysnJqF4DiDY4vqY4GWqi5fVrf oYjt4n5HzmKNJj77HwbreMX8YJQJwiCDoJufN5pgstk+/o/bA4U0KZnEcZ3SQIPnKADAruqXDGMu hM+yJSsf3+YJ2wXGTxfSj/IBFFhZ4PfwIuO0CYqtv2QCKLpMLm3IiePj96QtUED/5pc2xDzKhv4p sEjbHC/wzwSNLlm94TI830vPdfJmzb/+zeG7TUHUngPa7cNQoqlBse1nnUCB/7kcE/9dPkb80wWB BydyckNXk5L3GAuKutTUGYyRY+5nEhY5HUDBDQy9QnyunsUeK/Dxv08FQGgMCO8SQJnw3WBqAgVq CxT36+r8QTM1YKFpAMKAfvHz2pOJ/w9+ALqyJqrhYf2d2caA4tKmrXezYFF2xkdGW8DWZSxNoEBt gaLq5KmkYuCJ/JRHooy0FYEATM+6dPJ6fdZJWUz8Mi6sOQrMg0G8d0LZ0K40dtt/dAZFHZm6XDxx OrrYm6DNQfiiiMhqaOT/jAGFaGnEQb61c+tigU8WmFJgnq3T0NaJeyrztRYV3i3o8Jk31Oa5gQIc rtNq/gigxTwUDLZG9CHWevWTC3yyzUciKuy6RIDhcbCgrSt7PhC25WPovFNEb1W8CFBgx5q3YDED m4TNbePxZWH/Z5DlU6CYt/TFAjmURsVk6bpG6nk8G87MuU8ytQCB5ZAJa5Ix3L5LQHF5y7bbOoMC HuzHnT1fnk3QAlSwGzkTpv4JJpSbEabTu5y5C2qwWdLcbjpozTIvP3RPKlvc4lhVVo5kuU35ldZn sMZCYgyzQ5KA4BvlcQkxtIFmzgbTWwOdeV4LnFBlpcaCVKlUw3kLF9dTwQcgAiLH1AJdXhYhku1N DtWnn6rjp1bVfvgxdtQfZGM7m7A4sZ8hAKdRISkLMBAUr0tj40fisXTGB8+XdBMHTpr7zoS5ZHv7 /sqevWBiZ3Jie8121pYT+AjmRdPnIAphHjOB18LxnvKK/YcSGBOmPyG/SzDrYI5F8xf9hpRKe13W iSB4+SesITYaYKbAWmCCgikLX/PH9Y+OfG7U/APRYWzS2IQRWI46gUKtMeMTc3KJTIGJIwRHERhK NhQUtTS6e6HL+MdUghbOhnZFQUt/AOZMmp+rPHRsp3DUBEQmgCIbJlXkF1iiQmjQ84pVV59Ls2N5 eIEt3bpD5oL240zxkugSNWo3iiWVkUqDlqoyCJoPg63I0hFdP3oi3RBQ6EPisIhyOgEU2F/kLQz5 RZ8wsYbpdPhkIsvKsTGDsIsXmlqi8sS9THV/S8JZBSYWrbsIjIPjNA5Vf3ZmSWdtK6RSR97Mufcy CXOA1x7L0gFdiY79Hnh2/KtzGK0L+Otzi0smzdAwobLhuyh8jRRrfEMavxKfeKTYdlSrSQRCywdh Vhw6SiU+BwszjgMmVbNmvQh2aenEGaj63Pl1z3PwkshYG7qj6xNq36Et/DFg669I+TjX2LZr06gR QjBJyQR5YhMqZ+SYM88bFMIlK2TPgCJg0R0c1jVgt3+rOCA4lwFmUvP84Mgc18Ud3bqQtlYNmi++ SmFbO2mYvozBVuhyXEJhZ+2zp/mOZTuMbRk7pgLYqblzArBi+ueLSOwRB28JiK3N6kuI+sDiZHt4 NyqEEgcDhNmftyD4ajYhqoXDa5Jpc9BteoG/RmLP1DyOBYJofi4LFgXT0VXeIK+3f66giE2wyXUe pwGKQgDFjaMnC41tG0dfWJNnltAJ8qTB+HlzA/AuafGygEJZXW3H9yMhck+CiQmmIJhHfzYolU7q 3AWNbs+d6qPhJGPNL5xHwiHQkR21f3lbUko+AK7FbIc5yAMfQhIVu/BFZbs1F0lULCOP4DDhySke ORbVfPVNit6mSWraaI67J6IQQJEF5lFJ4BK8KCw7AkUefL/Yd/DV5z349kBR+fEnhV3RfsHYSemM QVatflLP/qgkJByGj8a+LKCoOfP1VoaNEyKaTkzY8cQRGwqbk7vw2Yc3f5GATjCTLwJAxJNnotq0 9OCO2q88+imPMdS2xfTCc0F3Hod4y6KHdgtQyJL2B/FdWm17vF1iP0OyNlqAB66X6bR7/3EO2IUt ziZecIOt0bWDh7OfKQHRAgW26+Gz4mUGBbaFS4KWPiJq2EIYF3WQZZp2aUt3BQV2SktWRzIZMG8t 1kO/YYhp7YxqzpyNJT57bd+BFK6ti4YJhcP8sv0fMTr0V058oQkKaD/HzgVJ4uNHdgtQwHY4onjG nJ8zCYk2MmyVQv8g1CCX2+khzH7F8xaIconh1d6mSDTFC9XRsuf/HUBRHp+4kWVDCPVC2+xhdojr H5j2svgUqvp6F5Ev6U8KIXeEQc73C0RgVtlqlH/Q6Q6McR6N1D6aloEoILhW2zIg0o2jJ1LyYeeh EpQnE8wn6c49n3YLUGAqWRuVj52kjIFmLZqBYzcK/Xgh/aDOTiaZ5sKfNhsRw3RU+C4mhWIb0/Z/ GRQwvgG3z12I40yY/oRKMB2x+VFoPgJVHf9s58sCiqrjp9Zx7Eero0HNlgNeG6Llq3OxA64dfhcE L5dmEQIL2Ics9fRBt7Ppi9vrQ5qQNJY3fiqiEN7LBH4FM+f9oaysDugWoJDtP7SEDYLIIGg4HA2Q rI0q0jUKVXny1GEGLIAMQtSJbWaHpHEJGW093yYoTMxeKp9CIZFOLI9L2Hpl9YabovGeCIdjKcRE FOy4JaRQpKquNn9ZQFEaHcstMLXUADbb1qWx5uz5xDZ3xx27kgXggxJ3x1z4rNh/KLcjM7M0bO09 jVwRvIfzPOLApQ/upFPD2ioa/UtBAWaSPd9n/m8ZhBobXPxVsmAx3jKddNCU74gWL+fnm5hrxp2d 3NCt1AuLdAEFFZdGWIz4vTRqC6V0I1CU/nQzbgdFEhk7/XmCAsbqfOt86s6rq9bncGfORVgR4ASo OqxNHD+YEYVm9ujmiVNnsXxeBlA0qFSjRT7+v1CJ+YNeA3HBH1LJZOZtvVMvFLoyR0/4k5iXwnyw Z/lVdRiU+fzMCYGDq0aeCgMDFygKQMEwPbwl7JlzKKwZPu3TtFkUttdcyiU89ydPXVTQaLh8f3CX gEIt1JCwLJyqb0nGYOcK7OPab7/f16nGFErHi+YEqDO4LRoGvvNJIX+oVCpzXUCBNWwmLsOG3cVQ kliMRDQzqzVdDQqcdKw9/fW06zt2ZZaEhiMmmJY4wkTpZaIRoWlVCENQwYDhqDxhz2/tFcl1R1DU nDkXLnTzUNcyteSYgIpJoYXtWQw4OVg0f1FVFsEnzVQn8tx+ldNoUzqQ6Xt8UqikoP/wZ2rHcP/Y N2WA36EL4epaFvgkXADTlTUbam+TaTu7BBSyxL1rCrTMH5yGl0TF5HXWYMWhTz5gDG99lzIAfBJo q2xDzPftnc/QBgWxXsdQYuBIz0DzsK4CBQC6nyQyJkEcEiYvdHRDzKG26hCr2lRoo9YITy4GSj7Y 4Nfjd/3c8PDhrPb46I6guLL7A37eAM3x8OzHNFYePJzY0Xv8ZSt38wkBBnVY38YFCcMitnV0PkdR JvUvCwlvzGqvClfP+cdJU1wuLnCbgm7uSPquAaHxRoFCwZOYMz19nhDLFHB5BnvCtAqVXG7WUQhP vCyiNJ+Q68C+CXPEmMbadPKq9t5rFxRGEAPa6ypQ1KSmzZaQQuU4646raTP6Dm27xBwXNPYZgnBh WxEoAnzYqOKDg//uLJzd3UABzzmIfQPlGscJcC3S5BmP5TyWRSdBFk+2o9vvxKrobHiXu3Dxjc76 vc0XhkhXrFXmAu9kMNUyuqCMHzv7PAsH9EPK4XoY1wiDQYErY4tmB2QwB1uDKfO0nBwGxh8zEcyA 3d7tZz9rp4i9/R6QCf4IdjC5pNDHSKUy1RkUJk1OHfZlDKV86Bc0udGgUIjLpon8glR0XPnazhkP LBvsSzCH2SLOqAmI67vw56qEPV821NT66DIJ3Q0UtWnpq0rVJT+tSrHp4FkYX5cqU45/UE12n9ay jcz+uEJh3O9yeoFrp2FglcriasLuPLGXLyoE6wRHu3DkMv3tfjrNOwWbblpgwmVDPEtHdGnrjm/0 Kgh8xgzauz+GYTGyMYMg3HwTC1SyJupCu1GnQye3c3ACp19rCA+bXYLF4Rc6KrB7xqeA97NA00oC l6DSoKXqT32paslKxF8QssoYUGAfoGRtNIcJ437G1gUg5ICvhQMKxS7uiDXVp+by+zso8lNnpsN7 emVjuxsoynft4+b2G6bhF+Hi0PKk5AQddpnX+EvCd+OdsllmeDwC+9FIGBGZqONO9RZi85zLd+w+ yfXworC9fe9eCV3RyZwvVa8VHoC5AFcREECpBgbsPKVTZ6O6bPoqg0GBjxQyPb01KkjV53EnTr8O Wr9/W++Ubdl2lShMrO059mMe15w5G9URE9qgwBWymeb2PzYolJ4NSiCF/gSC9exod9IFFPLU1BFF Ht4aNT3qcwR414QdgT1xWlXJ2o2ZdQm7pxsa6ehuoIBnhvF9A+uJplMmjh6O91AqpFKdzI9bqWne vDET71MJRX64Bq5ofpBUO7+hI0hs8Xx2OOfKJrr19Xkv6bZEOhMUFVUrmpUD/5dsiLneWYi3I0be 5nj7XczXPlUFjgvsInOfeV6lmiz2CfiNCCIczuPM8n+kksn66wOKPFNzrGVkLzpPQR5oZYdDq5kE kNMGWSLp+s1X689fiMFFj13BR3cCRV1ewUaJdrU0vvghJEza0c0r2sTw9K7IJTjq2McocBn/QE6j jXje89pktRx7n+M0riFD44zQYMQY5/FQweaNNAgUTQ1/ckiI48cEWxo70SXrN331TPbzs9NbBMQz ETjpB88KQldc7Ew7dNeMdlqPXnbq018mTycXtuRCR1ekZLB8u5KP7gIKbPoU+QfvZJvZt0YPm02f 8HXv68PD1X0pxcQyH9wOH8YEplnSX5WEu7Q5jp3b30zDDOQ7j0M/fZ/+kcGgUJRXzONOmP6QaJ/h K3C4s/2rtWvdL8clyHKI2xUwIHAe/6T65KmozpjvrqCgu0+zzxpuj6haguXOnPOgem/Ktw0S6cT/ OVD4kWqzCKYTDR+ldR73q7ygQK8TmLcupC2XTNR01nEZPT9oabGh53P0Jdn+gyQemFFEufIA4NL4 RMNBgU0o8dqNd4iXCWATSjhx+uPaNOqCluynUjVO4O2ryCQKE4AEzufv7fkfHZtPFii9G5SOK2Uy 26K5CxophErXpsyuiTpJxJ3i1SAkhaTKs/M2GTPR3QUU1alpU5kOY/8gZqRzsBIgheitoHD5hnh+ kJy4JvD5HNbkmaiezrL6K0Bx6/wFX6GHV9M1Sc2gsBuFpFt3HDQGFK+X7z1wrBgaIhPqWXCYrHR9 9InmZAyYTpslbh7q0FeLtgeHW7RyXa4uRyDJA83iWISyCHzQiek8DhcP2r9IUGDeryV/mCqwcdYY W3MyC08yPoYpAo1YsmLdrcqDhzfre7VLdwKFYHnEB3wbF42oEdfaCYnDIrYawsfVPQe4OGLZUlyK j+TaODfe+PjY3r8CFNLEvf68UV28U6i1ZUUVSTB5hiqDWBKMtQdogacL5w2OX+BJ7TO6Qphk6fYE nY6T5o2ZGMfBl181H0fFNy/MmIvu8MSRLxIUT8dnc2XT1iru8BGI8q7Js0k7nD0FcODSBp6jG+LO 8r1ZER23oUGpnPwygQJbBUW+pJvEKlfsmBaNnfSbnE73MFBTL+e7TtEoFSmAT+CFYYjy0JdKIjbQ NQ7NYZPeZQKqo2YeMQoUeNGLV0dqXsIFjRe7TlbV84TqKBR7lp+CeBNHFq6VGjOpXiGTDdOF+bLY +B18okOPqyvBhJK+v7PoRYNCnVBCyPJG4r48rvs09c6gBkcbpQhkMBlxEo9j5YgEvqQnsoQ9aXIa ze1lAEXtmXNjCxxdH2USQuo4esSZR7piqHwbGhqcJYGhCmJxKZYdLp6sp9OfqwlVnrh3DdvJ7VEG 8Xg1zsq7ez5USKVjjAbF1b0HTrLxKbrmpFz/pnomwcLQfTVnzq4qsHJ4QCUsEuxQFYeEcXUdQD1f uFI4aUYjhWiiQF/ZZrZPLsXEfwe27nhckWokOWknEPUtCKwjU71l8YmFQm8/xIGdAyuCtrLc6t9g 8pnQVsF4DyRbE0VVScqw39Gvu4KibENMSrHWyTmsZa8fOW7UJQ6XtsQzcaFeS5YZF/dZjERVJ0/v 0lpnQ42dY1V9vXNlcopbWVTMvwuc3NQ3URLL93Fo+XLcjh8MzlMQ6Y5YvEg0aUYD+b1BGlsRHewz zjgPjVvi8MVYAgc3VBYZvUpXwWHbXRASLsvRstsxMBi46nHSDCRaHIbES1ch8ZKVelNJ8HJ8HQtq qK21MgYUzXT/1i2/8pXrdhVNnfVfLvgbuNaJeBsFMWGE8za4XEbkPhVs2YQKlUJh2t1AAb/3LSYt uZzdR/OSidKpPqiWTCMZA4rqU6fXscAnJVY5YJCIlq9mEJWUYGn4lzdWRRo0v+o5XhaB+PjS5zET EWOYrfrqVyIgcC1VOSiz+iLexs541n3RLg77D1FozYuWovUbjjZw3Kf+phAK9boBpCb1worL+LRe G9dmYocWV6SS3zaQXn8HMTy9n7khsAvOUwyW7UxK5geG3i0GzZSJTxq2VTWL/Y5/9EHFYDYo28gK v2hQ1JPpTuwJ0569ZGJh6C14x9oYUDTUy+2F/kEPKYSjBOojzn6kJ8rKypY7ndJ79vuyENervW3E POO1g2WoLX/4LX+QFSrbGHtGl/u8dI+QXCSfxs4zubdp+xcKY3t6mB2YTstPGhDCe/Pavv1fqH0L bWA8pwuWu+rkHfA+6IcvzyaXrdl4twB2T+x3NN+W3sID7CZsb99GpURi291AcW3fgcPYDyLez1UI i+jagY/yjAFEi08asT4Xn8+hEEwoprUTqv7sdMvlBxkmw79gdnGltHpNgqJiD7dHV7fv1jmsrNcA xSHhZ7ngW2CkZwwYrlW/bopYIMirUbF3wMGyNVSIlckfflk2eWbTzePNFY/GEhZMe6BwcnuCrwhV P4fPUcPWbugZbbxzVB86PudK2Jo8HnbK8VU9ICv1YugMFE7jmnZdXH6OlQuAyyhQ9BvWMn78Jw3a AwU2nbi+CwW5hOdx9A9f5HYrjRrYJfmCc+fV1+RQCH0UDrJUH3HWAAUOy3fFfD89T5EPiqFs0kxU tmHzWX1q0/Sd9Ndk2xK/kc4joTzQhgUwMDWZWqKiUe6oYnMcW6VQTjFWiHdZnI/K12/6he86Wd12 Uz9WhhMsMrEvCSllMo2Lg6WxCXZFYyahwgHmTc9BX0LzEejG4eMCY8dwj8Wady1uJ0vk468GWhZs 78wZcxqVsmdBUffdxc+vjJ2sPtmG+cClNKVO45EwJDzAkL5Fy1b9WGTSKjMmLEbewsWP2jrXUXvq lOtlMOvyQDE0PW+JGLBzSpas+L2r8kSK6mqLUlIoyocdq5kn/L1kzgJ8xFkd7qWamn8jHmJj3Dw3 02ArxHXzQKJZ/uxfGMzD+v7xIYO2QyVP6Hlle9KRytgdnJKISM71g0fYtV+fC+gKARLzA/Vfn/Or OnGKeSlqC0e8ah1HDH0ZQiUr13Ku7T/IUsk1/8qO/Fza0Etx29mlq54+C5+V0Vs58iz64a4ah7Ky yv/6wcOsQhf321cXh6F6Fu+ZhXaHL9z4Y8Iejhj4bOJjHacqfidHduzkJEP6rDr+6b/K10a3jP8S jKvi0FFaW+fDhSsjrUrXbOBgan7+xub3OTdOfL6vC+eyZ8WHhw5dW9fKkyh8Ladq157iajJ5gtoK iYiMq4qKNXiO1QTy+yEpmSNLSj5Qfeykp6H8Pves4it66szyeNa1+1MCqk+d6vVKHt2bXgnhFb2i V6B4Ra+oY/p/VH8b3FEpSw8AAAAASUVORK5CYII= --001a1139cf2249d81c0519e7015a-- From nobody Thu Jul 2 18:44:25 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0AA1AD371 for ; Thu, 2 Jul 2015 18:44: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G_mdx9URHYFL for ; Thu, 2 Jul 2015 18:44:21 -0700 (PDT) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6409B1AD36F for ; Thu, 2 Jul 2015 18:44:21 -0700 (PDT) Received: by qgat90 with SMTP id t90so22100840qga.0 for ; Thu, 02 Jul 2015 18:44:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=BNY5XT9RfD1GrkMVwJppM0H6Izrd6ngJ6O/z2V9qF/8=; b=TaS1q99xXdMFLPj3+w1hPmqi+nZqPhfce7E9TSPKppnaKBYpcw1bWLww7RbCXdFGlx +PUg+oiC9MT/B3B04Bd1W87AIRq2dYslEISgJa+lsoC4hC2cfHqhmf9dwW47NZ8aLiYw umgBq18Un1ovquuTWCVMQMBBiVIlzPGC74tFs3qrWpbr8PxgzaepioevRnUjoivJzBVE gfNHvqmnjokKkrhlbABTOrWOM+bE9REMNmWIzLvJwgHuartjwledEkecYgXxCVr9ak4k /NHFeULBq2fzbZ09GJ9JBUU6KAfVmvXGEBuuyK9ZCS+eUHSd3DUUe/yXIA4Jg6Bp8R/X vJeg== X-Gm-Message-State: ALoCoQkxeqTRAP75vwogNF3hxgnxTgMJ8/wKycpBxRFFI3g4uKUf0qdsarxg02bkuWcQjUwXiZVt X-Received: by 10.140.99.65 with SMTP id p59mr47462840qge.46.1435887860297; Thu, 02 Jul 2015 18:44:20 -0700 (PDT) Received: from [192.168.1.216] (181-163-55-223.baf.movistar.cl. [181.163.55.223]) by mx.google.com with ESMTPSA id 70sm3673633qhe.12.2015.07.02.18.44.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Jul 2015 18:44:19 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_616CED9A-EB18-4509-B4B9-49D61EB17123" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: John Bradley In-Reply-To: Date: Thu, 2 Jul 2015 22:19:03 -0300 Message-Id: <2A451AC4-6414-4318-B188-C944E205C7E1@ve7jtb.com> References: <47E83806AE926749BB17D1020685E6901903F0CC5F@APJ1XCHEVSPIN36.SYMC.SYMANTEC.COM> To: Adam Lewis X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Lisa Li1 , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Question about usage of OAuth between servers X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 01:44:24 -0000 --Apple-Mail=_616CED9A-EB18-4509-B4B9-49D61EB17123 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1=20 JB. > On Jul 2, 2015, at 1:33 PM, Adam Lewis = wrote: >=20 > Hi Lisa, >=20 > Form the perspective of OAuth, there is ALWAYS a client (even if it is = running on a server). Of your two servers, one is exposing an API (so = this will be your RS), and the other server is a client of that API, so = that will be your Client. So it is still a client-server communication. = =20 >=20 > So it's a question then if whether or not the server (acting as an API = client) is accessing the other server's API on it's own behalf or on = behalf of an end user, and if acting on behalf of an end user, then how = does the end user interact with the server (acting as the API client)? >=20 > If the server acting as an API client is acting on its own behalf, = then you want the client credential grant type (or possible a SAML or = JWT assertion). > If the server acting as an API client is acting on behalf of an end = user and the end user is coming in through a browser, then you want the = authorization code grant type. > If the server acting as an API client is acting on behalf of an end = user and the end user directly signs onto the server, then you might be = stuck using the RO password grant type. >=20 > authorization code and RO grant types give you a refresh token that = you can use to refresh the access token. In the case of client = credentials, the client stores a long term PSK or has a public private = key pair used to request access tokens, so it will directly communicate = with the token endpoint using those to get new access tokens. >=20 > Does that make sense? > adam >=20 > On Mon, Jun 29, 2015 at 9:18 PM, Lisa Li1 > wrote: > Hi All >=20 > =20 >=20 > This is Lisa. >=20 > Our project is adopting OAuth 2 as authentication specification. >=20 > For the client-server communication, OAuth token works fine. But we = have some cases of server to server communication, usually it will be = multiple tasks running in parallel or sequence or even in multiple = threads. In this case, we are not sure we should reuse the access token = grant by end user or create another token? Moreover, if token is expired = in 30 min, we are able to do refresh but may meet some issue on the = token consistency between each task, thus it might be refreshed again = and again=E2=80=A6 >=20 > =20 >=20 > But with OAuth 1.0, since it will not expired and we don=E2=80=99t = have to do refresh, it will work fine. >=20 > =20 >=20 > So for OAuth 2.0, what=E2=80=99s your consideration for server to = server communication scenario? Or do you have any suggestion here? >=20 > =20 >=20 > Thanks. >=20 > =20 >=20 > =20 >=20 > Lisa Li >=20 > Principal Software Engineer >=20 > Symantec Corporation >=20 > =20 >=20 > Office: (010) 6272 5127 / Mobile: 189 1057 2219 >=20 > Lisa_Li1@symantec.com > =20 >=20 > >=20 > =20 >=20 > =20 >=20 > This message (including any attachments) is intended only for the use = of the individual or entity to which it is addressed and may contain = information that is non-public, proprietary, privileged, confidential, = and exempt from disclosure under applicable law or may constitute as = attorney work product. If you are not the intended recipient, you are = hereby notified that any use, dissemination, distribution, or copying of = this communication is strictly prohibited. If you have received this = communication in error, notify us immediately by telephone and (i) = destroy this message if a facsimile or (ii) delete this message = immediately if this is an electronic communication. >=20 > =20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_616CED9A-EB18-4509-B4B9-49D61EB17123 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1 
JB.

On = Jul 2, 2015, at 1:33 PM, Adam Lewis <adam.lewis@motorolasolutions.com> wrote:

Hi Lisa,

Form the perspective of OAuth, there is ALWAYS a client (even = if it is running on a server).  Of your two servers, one is = exposing an API (so this will be your RS), and the other server is a = client of that API, so that will be your Client.  So it is still a = client-server communication.  

So it's a question then if whether or = not the server (acting as an API client) is accessing the other server's = API on it's own behalf or on behalf of an end user, and if acting on = behalf of an end user, then how does the end user interact with the = server (acting as the API client)?

If the server acting as an API client = is acting on its own behalf, then you want the client credential grant = type (or possible a SAML or JWT assertion).
If the = server acting as an API client is acting on behalf of an end user and = the end user is coming in through a browser, then you want the = authorization code grant type.
If the server acting = as an API client is acting on behalf of an end user and the end user = directly signs onto the server, then you might be stuck using the RO = password grant type.

authorization code and RO grant types give you a refresh = token that you can use to refresh the access token.  In the case of = client credentials, the client stores a long term PSK or has a public = private key pair used to request access tokens, so it will directly = communicate with the token endpoint using those to get new access = tokens.

Does = that make sense?
adam

On Mon, = Jun 29, 2015 at 9:18 PM, Lisa Li1 <Lisa_Li1@symantec.com> wrote:

Hi All

 

This is Lisa.

Our project is adopting OAuth = 2 as authentication specification.

For the client-server = communication, OAuth token works fine. But we have some cases of server = to server communication, usually it will be multiple tasks running in = parallel or sequence or even in multiple threads. In this case, we are = not sure we should reuse the access token grant by end user or create = another token? Moreover, if token is expired in 30 min, we are able to = do refresh but may meet some issue on the token consistency between each = task, thus it might be refreshed again and again=E2=80=A6

 

But = with OAuth 1.0, since it will not expired and we don=E2=80=99t have to = do refresh, it will work fine.

 

So for OAuth 2.0, what=E2=80=99s your consideration = for server to server communication scenario? Or do you have any = suggestion here?

 

Thanks.

 

 

Lisa Li

Principal Software Engineer

Symantec Corporation

 

Office: (010) 6272 5127  /  = Mobile: 189 1057 2219

Lisa_Li1@symantec.com

 

<image002.png>

 

 

This message (including any attachments) is intended = only for the use of the individual or entity to which it is addressed = and may contain information that is non-public, proprietary, privileged, = confidential, and exempt from disclosure under applicable law or may = constitute as attorney work product. If you are not the intended = recipient, you are hereby notified that any use, dissemination, = distribution, or copying of this communication is strictly prohibited. = If you have received this communication in error, notify us immediately = by telephone and (i) destroy this message if a facsimile or (ii) delete = this message immediately if this is an electronic = communication.

 


_______________________________________________
OAuth mailing 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=_616CED9A-EB18-4509-B4B9-49D61EB17123-- From nobody Fri Jul 3 12:01:02 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6D61A8893 for ; Fri, 3 Jul 2015 11:52:45 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6joPc0S1jFmo for ; Fri, 3 Jul 2015 11:52:42 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B214C1A1BE4 for ; Fri, 3 Jul 2015 11:52:42 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 44C0321AE7 for ; Fri, 3 Jul 2015 14:47:35 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Fri, 03 Jul 2015 14:47:35 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=muNPD SFegHDU/btawSqYlhVK5co=; b=2EIKrFoKpiukmJL4uuKbJFUgxTD9VkXjleZPU y6wlGYcevcRRlGDldskehgq6D3yMDwOsGI013VCgWq+mD+YKXjCg6/pxhrbpKuLs v17zP+dVyrdghVOzDEtBj3XWL4ZfALaS6cNHs9ABQskdn1Cjhae5MadSpbJypOC6 5ctKno= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=muNPDSFegHDU/btawSqYlhVK5co=; b=JdM8e F02Xnq6FrXlbHxwISfPC2S5PLXRRDNOWmMGK2G8sblw3BWtBcU/111rWZiezke9u ixPpOOCwdaGLX5Xnnad2iiIUNPUXs8HpTWz2/FqWepYMdEAv/jM5uWqChf2uS8GU 9+Vv7J2/8F23HBJtTywb7mnawURrVpf/c/+P2A= X-Sasl-enc: wyQZnFiLg4k/veLitHuKwK5lme/ZZZYnJ5tXSD1+Eob7 1435949254 Received: from sjc-alcoop-8818.cisco.com (unknown [128.107.241.161]) by mail.messagingengine.com (Postfix) with ESMTPA id DE4F7680119; Fri, 3 Jul 2015 14:47:31 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_7896CC47-4A52-4CAA-B5F1-C53B9EC182E8" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <07ABEE40-9755-4CE0-A3FB-4626C0444C61@mit.edu> Date: Fri, 3 Jul 2015 11:47:30 -0700 Message-Id: <043650B6-603F-443F-904C-52A265F44501@cooperw.in> References: <20150608164044.24189.13985.idtracker@ietfa.amsl.com> <07ABEE40-9755-4CE0-A3FB-4626C0444C61@mit.edu> To: Justin Richer X-Mailer: Apple Mail (2.1878.6) Archived-At: X-Mailman-Approved-At: Fri, 03 Jul 2015 12:01:00 -0700 Cc: draft-ietf-oauth-introspection@ietf.org, draft-ietf-oauth-introspection.ad@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-introspection.shepherd@ietf.org, IESG , "" Subject: Re: [OAUTH-WG] Alissa Cooper's Discuss on draft-ietf-oauth-introspection-09: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 18:52:45 -0000 --Apple-Mail=_7896CC47-4A52-4CAA-B5F1-C53B9EC182E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Justin, Thanks for addressing my comments. One more note below. On Jun 22, 2015, at 5:51 PM, Justin Richer wrote: > Alissa, >=20 > I=92ve uploaded a new draft that should address your comments below: >=20 > Draft: https://tools.ietf.org/html/draft-ietf-oauth-introspection-10 >=20 > Diff: = https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-introspection-10.tx= t >=20 > Please let me know if you have any further questions, > =97 Justin >=20 >> On Jun 11, 2015, at 5:00 PM, Justin Richer wrote: >>=20 >> Hi Alissa, thanks for your review. Responses are inline. >>=20 >>> On Jun 8, 2015, at 9:40 AM, Alissa Cooper wrote: >>>=20 >>> Alissa Cooper has entered the following ballot position for >>> draft-ietf-oauth-introspection-09: Discuss >>>=20 >>> When responding, please keep the subject line intact and reply to = all >>> email addresses included in the To and CC lines. (Feel free to cut = this >>> introductory paragraph, however.) >>>=20 >>>=20 >>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>> =3D Section 2.1 =3D >>> "The endpoint MAY allow other parameters to provide further context = to >>> the query. For instance, an authorization service may need to know >>> the IP address of the client accessing the protected resource in >>> order to determine the appropriateness of the token being = presented." >>>=20 >>> How does the protected resource know whether it needs to include = such >>> additional parameters or not? >>> What is meant by the "appropriateness" of >>> the token?=20 >>>=20 >>> In general if we're talking about a piece of data that could be = sensitive >>> like client IP address, it would be better for there to be specific >>> guidelines to direct protected resources as to when this information >>> needs to be sent. I note that Section 5 basically says such >>> considerations are out of scope, but if this specific example is to = be >>> provided here then they seem in scope to me. >>=20 >> We are trying to leave the door open to extensions and adaptations of = this protocol, specifically around the protected resource passing along = information about the client=92s request. The AS might be able to help = the RS detect funny business on the client=92s behalf (i.e., whether = it=92s appropriate for the client to presenting the token in this = context) if it has that information.=20 >>=20 >> The example isn=92t supposed to be normative or pull extra = considerations into scope of this protocol but instead to point out = where it could go. I think there are two more changes that could make this crystal clear.=20= In 2.1: s/The definition of any other parameters/The definition of this or any = other parameters/ In 5: s/such information could have additional privacy considerations/such = information could have additional privacy considerations that extension = specifications should detail./ Thanks, Alissa >>=20 >> Do you have a suggestion for rewording this? Perhaps it would be best = to move all of this language to the security considerations section, as = it=92s more guidance for what extensions to this spec would need to = think about as opposed to what pure implementations of this spec would = need. >>=20 >>>=20 >>> =3D Section 5 =3D >>> "One way to limit disclosure is to require >>> authorization to call the introspection endpoint and to limit calls >>> to only registered and trusted protected resource servers." >>>=20 >>> I thought Section 2.1 made authorization to call the introspection >>> endpoint mandatory. This makes it sound like it's optional. Which is = it? >>=20 >> Thanks for this catch. Authorization used to be optional, and it = looks like we missed updating this text. I=92ll fix that in the next = revision. >>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> =3D Section 1.1 =3D >>> There is no reference to RFC2119 here, which may be okay but most >>> documents include it if they use normative language (I think). >>>=20 >>=20 >> Not sure how that happened, this should have been included by the = xml2rfc tooling, I=92ll look into it. >>=20 >>> =3D Section 2 =3D >>> "The >>> definition of an active token is up to the authorization server, = but >>> this is commonly a token that has been issued by this authorization >>> server, is not expired, has not been revoked, and is within the >>> purview of the protected resource making the introspection call." >>>=20 >>> Is "within the purview" a term of art for OAuth 2.0? Is there a more >>> specific way to describe what is meant here? Also, I note that in = the >>> description of the "active" member in Section 2.2, this criterion is = not >>> listed. It seems like these should be aligned. >>=20 >> It is not a term of art in OAuth, and I can change that to =93is able = to be used at the protected resource=94 if that=92s clearer. I will also = add that to the list of checks about the active value, thanks. >>=20 >>>=20 >>> =3D Section 2.2 =3D >>> "Note that in order to avoid disclosing too much of the >>> authorization server's state to a third party, the authorization >>> server SHOULD NOT include any additional information about an >>> inactive token, including why the token is inactive." >>>=20 >>> Seems like this should be a MUST NOT unless there's some reason for >>> providing anything other than active set to false. Same comment = applies >>> in Section 4. >>=20 >> That=92s why it=92s SHOULD =97 which translates, roughly, to =93do it = this way unless you=92ve got a really, really good reason not to=94. >>=20 >>>=20 >>> =3D Section 2.3 =3D >>> It seems like there is another error condition and I'm wondering if = its >>> handling needs to be specified. Per my question in Section 2.1, if = it's >>> possible that the request is properly formed but is missing some >>> additional information that the authorization server needs to = evaluate >>> it, should there be an error condition specified for that case? >>>=20 >>=20 >> Not by this specification, since there isn=92t a mechanism for the = protected resource to figure out automatically what to do next. If = there=92s a future extension specifying this extra information, it can = define its own value. >>=20 >> =97 Justin >>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 --Apple-Mail=_7896CC47-4A52-4CAA-B5F1-C53B9EC182E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi Justin,

Thanks for = addressing my comments. One more note below.

On Jun = 22, 2015, at 5:51 PM, Justin Richer <jricher@mit.edu> wrote:

Alissa,

I=92ve uploaded a new draft that should address your comments = below:

Draft: https://tools.ietf.org/html/draft-ietf-oauth-introspection-10

Diff: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-introspe= ction-10.txt

Please let me know if you have any further = questions,
 =97 Justin

On Jun 11, 2015, at 5:00 PM, Justin Richer <jricher@MIT.EDU> = wrote:

Hi = Alissa, thanks for your review. Responses are inline.

On Jun 8, 2015, at 9:40 = AM, Alissa Cooper <alissa@cooperw.in> wrote:

Alissa Cooper has entered the following ballot position = for
draft-ietf-oauth-introspection-09: Discuss

When responding, please keep the subject line = intact and reply to all
email addresses included in the To = and CC lines. (Feel free to cut this
introductory = paragraph, however.)


Please = refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection= /



---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

=3D Section 2.1 =3D
"The endpoint MAY allow other parameters to provide further = context to
 the query.  For instance, an = authorization service may need to know
 the IP = address of the client accessing the protected resource in
=  order to determine the appropriateness of the token being = presented."

How does the protected resource = know whether it needs to include such
additional = parameters or not?
What is meant by the "appropriateness" = of
the token?

In general if = we're talking about a piece of data that could be sensitive
like client IP address, it would be better for there to be = specific
guidelines to direct protected resources as to = when this information
needs to be sent. I note that = Section 5 basically says such
considerations are out of = scope, but if this specific example is to be
provided here = then they seem in scope to me.

We are trying to leave the door open to extensions and = adaptations of this protocol, specifically around the protected resource = passing along information about the client=92s request. The AS might be = able to help the RS detect funny business on the client=92s behalf = (i.e., whether it=92s appropriate for the client to presenting the token = in this context) if it has that information.

The example isn=92t supposed to be normative or pull extra = considerations into scope of this protocol but instead to point out = where it could go.


I think there are two more changes that could make this = crystal clear. 

In 2.1:
s/The = definition of any other parameters/The definition of this or any other = parameters/

In 5:
s/such information = could have additional privacy considerations/such information could have = additional privacy considerations that extension specifications should = detail./

Thanks,
Alissa


Do you have a suggestion for rewording this? = Perhaps it would be best to move all of this language to the security = considerations section, as it=92s more guidance for what extensions to = this spec would need to think about as opposed to what pure = implementations of this spec would need.


=3D = Section 5 =3D
"One way to limit disclosure is to = require
 authorization to call the introspection = endpoint and to limit calls
 to only registered and = trusted protected resource servers."

I = thought Section 2.1 made authorization to call the introspection
endpoint mandatory. This makes it sound like it's optional. = Which is it?

Thanks for this = catch. Authorization used to be optional, and it looks like we missed = updating this text. I=92ll fix that in the next revision.



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

=3D Section 1.1 =3D
There is no reference to RFC2119 here, which may be okay but = most
documents include it if they use normative language = (I think).


Not = sure how that happened, this should have been included by the xml2rfc = tooling, I=92ll look into it.

=3D Section 2 =3D
"The
 definition of an active token is up to the = authorization server, but
 this is commonly a token = that has been issued by this authorization
 server, = is not expired, has not been revoked, and is within the
=  purview of the protected resource making the introspection = call."

Is "within the purview" a term of = art for OAuth 2.0? Is there a more
specific way to = describe what is meant here? Also, I note that in the
description of the "active" member in Section 2.2, this = criterion is not
listed. It seems like these should be = aligned.

It is not a term of = art in OAuth, and I can change that to =93is able to be used at the = protected resource=94 if that=92s clearer. I will also add that to the = list of checks about the active value, thanks.


=3D = Section 2.2 =3D
"Note that in order to avoid disclosing = too much of the
 authorization server's state to a = third party, the authorization
 server SHOULD NOT = include any additional information about an
=  inactive token, including why the token is inactive."

Seems like this should be a MUST NOT unless = there's some reason for
providing anything other than = active set to false. Same comment applies
in Section 4.

That=92s why it=92s SHOULD =97 = which translates, roughly, to =93do it this way unless you=92ve got a = really, really good reason not to=94.


=3D = Section 2.3 =3D
It seems like there is another error = condition and I'm wondering if its
handling needs to be = specified. Per my question in Section 2.1, if it's
possible = that the request is properly formed but is missing some
additional information that the authorization server needs to = evaluate
it, should there be an error condition specified = for that case?


Not by this specification, since there isn=92t a mechanism = for the protected resource to figure out automatically what to do next. = If there=92s a future extension specifying this extra information, it = can define its own value.

=97 Justin


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



= --Apple-Mail=_7896CC47-4A52-4CAA-B5F1-C53B9EC182E8-- From nobody Fri Jul 3 12:16:52 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E710F1A6F05; Fri, 3 Jul 2015 12:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOA7EccIMRXK; Fri, 3 Jul 2015 12:16:48 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBA041A6EF4; Fri, 3 Jul 2015 12:16:47 -0700 (PDT) X-AuditID: 1209190c-f79296d000000622-88-5596df9ecd71 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 91.2D.01570.E9FD6955; Fri, 3 Jul 2015 15:16:46 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t63JGjkv000330; Fri, 3 Jul 2015 15:16:45 -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 t63JGg7c006188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Jul 2015 15:16:43 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_94FD4245-A6CF-4B05-B975-939FC30198FA" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Justin Richer In-Reply-To: <043650B6-603F-443F-904C-52A265F44501@cooperw.in> Date: Fri, 3 Jul 2015 15:16:42 -0400 Message-Id: <2C13741E-8B0C-4723-9916-6B41ECDC00B8@mit.edu> References: <20150608164044.24189.13985.idtracker@ietfa.amsl.com> <07ABEE40-9755-4CE0-A3FB-4626C0444C61@mit.edu> <043650B6-603F-443F-904C-52A265F44501@cooperw.in> To: Alissa Cooper X-Mailer: Apple Mail (2.2098) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFKsWRmVeSWpSXmKPExsUixCmqrDvv/rRQg5bPahbTz/xltDi76Ta7 xYrl5RYvFu9ktpjxZyKzxe25K9ksTr59xebA7vHlyUsmjyVLfjIFMEVx2aSk5mSWpRbp2yVw Zdyfu4+xoHkRY8Wtu8dYGhgPdTF2MXJySAiYSHSd72KCsMUkLtxbz9bFyMUhJLCYSWLRsvNs IAkhgQ2MEg8mhUMkHjBJvOmfwA6SYBZIkPjydDnYJF4BPYlHTx+DxYUFCiQmn+sAa2YTUJWY vqYFbAOngJ3Ekmu/wGwWARWJvesOs4MMZRb4xiixYsVbVohBVhJXpr1lh9h8kVHi47oUEFsE aNDVYz+AhnIAnSor8XWr3ARGgVlIzpiF5AyIuLbEsoWvmSFsA4mnna9YMcX1Jd68m8O0gJFt FaNsSm6Vbm5iZk5xarJucXJiXl5qka6hXm5miV5qSukmRnCUSPLsYHxzUOkQowAHoxIP74XT U0OFWBPLiitzDzFKcjApifJOODgtVIgvKT+lMiOxOCO+qDQntfgQowQHs5II78fFQDnelMTK qtSifJiUNAeLkjjvph98IUIC6YklqdmpqQWpRTBZGQ4OJQneyHtAjYJFqempFWmZOSUIaSYO TpDhPEDDu0FqeIsLEnOLM9Mh8qcYFaXEeVlBEgIgiYzSPLheWBJ7xSgO9Iow7xmQKh5gAoTr fgU0mAlosIgp2OCSRISUVAOj9rI43nOLQvbsbC/7a77z5Lv54g7Gn0WvTjAUWV3cm31LNDRR 86iJWSifUuqrvNoL58Mze7ZPcopZLCjkf6zxv8jdfKkT9vvX7glaaxP8I3rltRD5gJDs6dVH K2e9rI3YWpIfHNJlKtMpl2XkxrxPREf6tCnP1Re7jbYKJih9nnCyoerdcWUlluKMREMt5qLi RADE7UukPQMAAA== Archived-At: Cc: draft-ietf-oauth-introspection@ietf.org, draft-ietf-oauth-introspection.ad@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-introspection.shepherd@ietf.org, IESG , "" Subject: Re: [OAUTH-WG] Alissa Cooper's Discuss on draft-ietf-oauth-introspection-09: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 19:16:52 -0000 --Apple-Mail=_94FD4245-A6CF-4B05-B975-939FC30198FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Alissa, Thanks for the wording suggestions. Both of those sound reasonable to = me, so I=92ll pull them into an updated draft shortly. I=92ll post back = here when it=92s been published. =97 Justin > On Jul 3, 2015, at 2:47 PM, Alissa Cooper wrote: >=20 > Hi Justin, >=20 > Thanks for addressing my comments. One more note below. >=20 > On Jun 22, 2015, at 5:51 PM, Justin Richer > wrote: >=20 >> Alissa, >>=20 >> I=92ve uploaded a new draft that should address your comments below: >>=20 >> Draft: https://tools.ietf.org/html/draft-ietf-oauth-introspection-10 = >>=20 >> Diff: = https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-introspection-10.tx= t = >>=20 >> Please let me know if you have any further questions, >> =97 Justin >>=20 >>> On Jun 11, 2015, at 5:00 PM, Justin Richer > wrote: >>>=20 >>> Hi Alissa, thanks for your review. Responses are inline. >>>=20 >>>> On Jun 8, 2015, at 9:40 AM, Alissa Cooper > wrote: >>>>=20 >>>> Alissa Cooper has entered the following ballot position for >>>> draft-ietf-oauth-introspection-09: Discuss >>>>=20 >>>> When responding, please keep the subject line intact and reply to = all >>>> email addresses included in the To and CC lines. (Feel free to cut = this >>>> introductory paragraph, however.) >>>>=20 >>>>=20 >>>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html = >>>> for more information about IESG DISCUSS and COMMENT positions. >>>>=20 >>>>=20 >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ = >>>>=20 >>>>=20 >>>>=20 >>>> = ---------------------------------------------------------------------- >>>> DISCUSS: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> =3D Section 2.1 =3D >>>> "The endpoint MAY allow other parameters to provide further context = to >>>> the query. For instance, an authorization service may need to = know >>>> the IP address of the client accessing the protected resource in >>>> order to determine the appropriateness of the token being = presented." >>>>=20 >>>> How does the protected resource know whether it needs to include = such >>>> additional parameters or not? >>>> What is meant by the "appropriateness" of >>>> the token?=20 >>>>=20 >>>> In general if we're talking about a piece of data that could be = sensitive >>>> like client IP address, it would be better for there to be specific >>>> guidelines to direct protected resources as to when this = information >>>> needs to be sent. I note that Section 5 basically says such >>>> considerations are out of scope, but if this specific example is to = be >>>> provided here then they seem in scope to me. >>>=20 >>> We are trying to leave the door open to extensions and adaptations = of this protocol, specifically around the protected resource passing = along information about the client=92s request. The AS might be able to = help the RS detect funny business on the client=92s behalf (i.e., = whether it=92s appropriate for the client to presenting the token in = this context) if it has that information.=20 >>>=20 >>> The example isn=92t supposed to be normative or pull extra = considerations into scope of this protocol but instead to point out = where it could go. >=20 >=20 > I think there are two more changes that could make this crystal clear.=20= >=20 > In 2.1: > s/The definition of any other parameters/The definition of this or any = other parameters/ >=20 > In 5: > s/such information could have additional privacy considerations/such = information could have additional privacy considerations that extension = specifications should detail./ >=20 > Thanks, > Alissa >=20 >>>=20 >>> Do you have a suggestion for rewording this? Perhaps it would be = best to move all of this language to the security considerations = section, as it=92s more guidance for what extensions to this spec would = need to think about as opposed to what pure implementations of this spec = would need. >>>=20 >>>>=20 >>>> =3D Section 5 =3D >>>> "One way to limit disclosure is to require >>>> authorization to call the introspection endpoint and to limit = calls >>>> to only registered and trusted protected resource servers." >>>>=20 >>>> I thought Section 2.1 made authorization to call the introspection >>>> endpoint mandatory. This makes it sound like it's optional. Which = is it? >>>=20 >>> Thanks for this catch. Authorization used to be optional, and it = looks like we missed updating this text. I=92ll fix that in the next = revision. >>>=20 >>>>=20 >>>>=20 >>>> = ---------------------------------------------------------------------- >>>> COMMENT: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> =3D Section 1.1 =3D >>>> There is no reference to RFC2119 here, which may be okay but most >>>> documents include it if they use normative language (I think). >>>>=20 >>>=20 >>> Not sure how that happened, this should have been included by the = xml2rfc tooling, I=92ll look into it. >>>=20 >>>> =3D Section 2 =3D >>>> "The >>>> definition of an active token is up to the authorization server, = but >>>> this is commonly a token that has been issued by this = authorization >>>> server, is not expired, has not been revoked, and is within the >>>> purview of the protected resource making the introspection call." >>>>=20 >>>> Is "within the purview" a term of art for OAuth 2.0? Is there a = more >>>> specific way to describe what is meant here? Also, I note that in = the >>>> description of the "active" member in Section 2.2, this criterion = is not >>>> listed. It seems like these should be aligned. >>>=20 >>> It is not a term of art in OAuth, and I can change that to =93is = able to be used at the protected resource=94 if that=92s clearer. I will = also add that to the list of checks about the active value, thanks. >>>=20 >>>>=20 >>>> =3D Section 2.2 =3D >>>> "Note that in order to avoid disclosing too much of the >>>> authorization server's state to a third party, the authorization >>>> server SHOULD NOT include any additional information about an >>>> inactive token, including why the token is inactive." >>>>=20 >>>> Seems like this should be a MUST NOT unless there's some reason for >>>> providing anything other than active set to false. Same comment = applies >>>> in Section 4. >>>=20 >>> That=92s why it=92s SHOULD =97 which translates, roughly, to =93do = it this way unless you=92ve got a really, really good reason not to=94. >>>=20 >>>>=20 >>>> =3D Section 2.3 =3D >>>> It seems like there is another error condition and I'm wondering if = its >>>> handling needs to be specified. Per my question in Section 2.1, if = it's >>>> possible that the request is properly formed but is missing some >>>> additional information that the authorization server needs to = evaluate >>>> it, should there be an error condition specified for that case? >>>>=20 >>>=20 >>> Not by this specification, since there isn=92t a mechanism for the = protected resource to figure out automatically what to do next. If = there=92s a future extension specifying this extra information, it can = define its own value. >>>=20 >>> =97 Justin >>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>=20 >=20 --Apple-Mail=_94FD4245-A6CF-4B05-B975-939FC30198FA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Alissa,

Thanks for the wording suggestions. Both of those sound = reasonable to me, so I=92ll pull them into an updated draft shortly. = I=92ll post back here when it=92s been published.
 =97 Justin

On Jul 3, 2015, at 2:47 PM, Alissa Cooper <alissa@cooperw.in> = wrote:

Hi Justin,

Thanks for addressing my comments. One more note = below.

On Jun 22, = 2015, at 5:51 PM, Justin Richer <jricher@mit.edu> wrote:

Alissa,

I=92ve uploaded a new draft that should = address your comments below:

Draft: https://tools.ietf.org/html/draft-ietf-oauth-introspection-10

Diff: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-introspe= ction-10.txt

Please let me know if you have any further = questions,
 =97 Justin

On Jun 11, 2015, at 5:00 PM, Justin Richer = <jricher@MIT.EDU> = wrote:

Hi = Alissa, thanks for your review. Responses are inline.

On Jun 8, 2015, at 9:40 = AM, Alissa Cooper <alissa@cooperw.in> wrote:

Alissa Cooper has entered the following ballot position = for
draft-ietf-oauth-introspection-09: Discuss

When responding, please keep the subject line = intact and reply to all
email addresses included in the To = and CC lines. (Feel free to cut this
introductory = paragraph, however.)


Please = refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection= /



---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

=3D Section 2.1 =3D
"The endpoint MAY allow other parameters to provide further = context to
 the query.  For instance, an = authorization service may need to know
 the IP = address of the client accessing the protected resource in
=  order to determine the appropriateness of the token being = presented."

How does the protected resource = know whether it needs to include such
additional = parameters or not?
What is meant by the "appropriateness" = of
the token?

In general if = we're talking about a piece of data that could be sensitive
like client IP address, it would be better for there to be = specific
guidelines to direct protected resources as to = when this information
needs to be sent. I note that = Section 5 basically says such
considerations are out of = scope, but if this specific example is to be
provided here = then they seem in scope to me.

We are trying to leave the door open to extensions and = adaptations of this protocol, specifically around the protected resource = passing along information about the client=92s request. The AS might be = able to help the RS detect funny business on the client=92s behalf = (i.e., whether it=92s appropriate for the client to presenting the token = in this context) if it has that information.

The example isn=92t supposed to be normative or pull extra = considerations into scope of this protocol but instead to point out = where it could go.

I = think there are two more changes that could make this crystal = clear. 

In = 2.1:
s/The definition of any other parameters/The = definition of this or any other parameters/

In 5:
s/such = information could have additional privacy considerations/such = information could have additional privacy considerations that extension = specifications should detail./

Thanks,
Alissa


Do you have a suggestion for rewording this? Perhaps it would = be best to move all of this language to the security considerations = section, as it=92s more guidance for what extensions to this spec would = need to think about as opposed to what pure implementations of this spec = would need.


=3D Section 5 =3D
"One way to = limit disclosure is to require
 authorization to = call the introspection endpoint and to limit calls
=  to only registered and trusted protected resource servers."

I thought Section 2.1 made authorization to = call the introspection
endpoint mandatory. This makes it = sound like it's optional. Which is it?

Thanks for this catch. Authorization used to be optional, and = it looks like we missed updating this text. I=92ll fix that in the next = revision.



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

=3D Section 1.1 =3D
There is no reference to RFC2119 here, which may be okay but = most
documents include it if they use normative language = (I think).


Not = sure how that happened, this should have been included by the xml2rfc = tooling, I=92ll look into it.

=3D Section 2 =3D
"The
 definition of an active token is up to the = authorization server, but
 this is commonly a token = that has been issued by this authorization
 server, = is not expired, has not been revoked, and is within the
=  purview of the protected resource making the introspection = call."

Is "within the purview" a term of = art for OAuth 2.0? Is there a more
specific way to = describe what is meant here? Also, I note that in the
description of the "active" member in Section 2.2, this = criterion is not
listed. It seems like these should be = aligned.

It is not a term of = art in OAuth, and I can change that to =93is able to be used at the = protected resource=94 if that=92s clearer. I will also add that to the = list of checks about the active value, thanks.


=3D = Section 2.2 =3D
"Note that in order to avoid disclosing = too much of the
 authorization server's state to a = third party, the authorization
 server SHOULD NOT = include any additional information about an
=  inactive token, including why the token is inactive."

Seems like this should be a MUST NOT unless = there's some reason for
providing anything other than = active set to false. Same comment applies
in Section 4.

That=92s why it=92s SHOULD =97 = which translates, roughly, to =93do it this way unless you=92ve got a = really, really good reason not to=94.


=3D = Section 2.3 =3D
It seems like there is another error = condition and I'm wondering if its
handling needs to be = specified. Per my question in Section 2.1, if it's
possible = that the request is properly formed but is missing some
additional information that the authorization server needs to = evaluate
it, should there be an error condition specified = for that case?


Not by this specification, since there isn=92t a mechanism = for the protected resource to figure out automatically what to do next. = If there=92s a future extension specifying this extra information, it = can define its own value.

=97 Justin


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




= --Apple-Mail=_94FD4245-A6CF-4B05-B975-939FC30198FA-- From nobody Fri Jul 3 17:59:38 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02CE41B31BD; Fri, 3 Jul 2015 17:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPjwP21NTT9A; Fri, 3 Jul 2015 17:59:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8761B31CC; Fri, 3 Jul 2015 17:59:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150704005932.26058.81396.idtracker@ietfa.amsl.com> Date: Fri, 03 Jul 2015 17:59:32 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-11.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2015 00:59:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : OAuth 2.0 Token Introspection Author : Justin Richer Filename : draft-ietf-oauth-introspection-11.txt Pages : 17 Date : 2015-07-03 Abstract: This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-introspection-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 3 18:01:38 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167BB1A8ADD; Fri, 3 Jul 2015 18:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvYMxZcRpCOC; Fri, 3 Jul 2015 18:01:34 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70B171A923A; Fri, 3 Jul 2015 18:01:32 -0700 (PDT) X-AuditID: 12074423-f79496d000001e58-cf-5597306bd7dd Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id A2.2E.07768.B6037955; Fri, 3 Jul 2015 21:01:31 -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 t6411Upk031183; Fri, 3 Jul 2015 21:01:30 -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 t6411RVh012059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Jul 2015 21:01:28 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_71BA4D47-0848-4A58-86D4-1D919D934F48" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Justin Richer In-Reply-To: <2C13741E-8B0C-4723-9916-6B41ECDC00B8@mit.edu> Date: Fri, 3 Jul 2015 21:01:27 -0400 Message-Id: <6A169EAB-83C5-4B9C-B8AE-4A4EE4EE4322@mit.edu> References: <20150608164044.24189.13985.idtracker@ietfa.amsl.com> <07ABEE40-9755-4CE0-A3FB-4626C0444C61@mit.edu> <043650B6-603F-443F-904C-52A265F44501@cooperw.in> <2C13741E-8B0C-4723-9916-6B41ECDC00B8@mit.edu> To: Alissa Cooper X-Mailer: Apple Mail (2.2098) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNKsWRmVeSWpSXmKPExsUixCmqrZttMD3U4PBSOYvpZ/4yWpzddJvd YsXycosXi3cyW8z4M5HZ4vbclWwWJ9++YnNg9/jy5CWTx5IlP5kCmKK4bFJSczLLUov07RK4 Mm7O3MlesGcLY8XuXy/ZGxj7ZzN2MXJySAiYSMx91M0EYYtJXLi3nq2LkYtDSGAxk8S8B3ug nA2MEosfn2SEcB4wSbSdfAbWziyQIPF7z1cwm1dAT+LR08fsILawQIHE5HMdbCA2m4CqxPQ1 LWArOAWsJf58uQxWzyKgIrG/eQYzxJxvjBLvZ+ZDzLGS+LelnRliWQOTxP33c8CGigANunrs B9BQDqBbZSW+bpWbwCgwC8kZs5CcARHXlli28DUzhG0g8bTzFSumuL7Em3dzmBYwsq1ilE3J rdLNTczMKU5N1i1OTszLSy3SNdPLzSzRS00p3cQIihN2F+UdjH8OKh1iFOBgVOLh/SA8PVSI NbGsuDL3EKMkB5OSKK+xJlCILyk/pTIjsTgjvqg0J7X4EKMEB7OSCK8xE1CONyWxsiq1KB8m Jc3BoiTOu+kHX4iQQHpiSWp2ampBahFMVoaDQ0mC95geUKNgUWp6akVaZk4JQpqJgxNkOA/Q 8FkgNbzFBYm5xZnpEPlTjIpS4rzbQBICIImM0jy4Xlgae8UoDvSKMK+wPlAVDzAFwnW/AhrM BDRYxHQayOCSRISUVANjV8A288MPZq+TCLT8y9uaPe/DKcmIkvdGl669WndXdK/KqXrLhGQ2 18Agjg6miYf2LDrdr7Oi3dfh4fWsy3+49+7ZlxxoaCvYlFE6iVVTZXldVjnzld0lJ+TbzbJc QxJF5jB0/W0RU97D0/bPXsQmjiFTyZ7x9JqdqhdzeqyfxNZt2JyfdEaJpTgj0VCLuag4EQCu kJdaPgMAAA== Archived-At: Cc: draft-ietf-oauth-introspection@ietf.org, draft-ietf-oauth-introspection.ad@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-introspection.shepherd@ietf.org, IESG , "" Subject: Re: [OAUTH-WG] Alissa Cooper's Discuss on draft-ietf-oauth-introspection-09: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2015 01:01:38 -0000 --Apple-Mail=_71BA4D47-0848-4A58-86D4-1D919D934F48 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Alissa, I=92ve incorporated your suggested wording changes into the latest = version of the document: Draft: https://tools.ietf.org/html/draft-ietf-oauth-introspection-11 Diff: = https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-introspection-11.tx= t Hopefully this will be sufficient to clear the DISCUSS. Thanks for your = thorough review and feedback! =97 Justin > On Jul 3, 2015, at 3:16 PM, Justin Richer wrote: >=20 > Hi Alissa, >=20 > Thanks for the wording suggestions. Both of those sound reasonable to = me, so I=92ll pull them into an updated draft shortly. I=92ll post back = here when it=92s been published. >=20 > =97 Justin >=20 >> On Jul 3, 2015, at 2:47 PM, Alissa Cooper > wrote: >>=20 >> Hi Justin, >>=20 >> Thanks for addressing my comments. One more note below. >>=20 >> On Jun 22, 2015, at 5:51 PM, Justin Richer > wrote: >>=20 >>> Alissa, >>>=20 >>> I=92ve uploaded a new draft that should address your comments below: >>>=20 >>> Draft: https://tools.ietf.org/html/draft-ietf-oauth-introspection-10 = >>>=20 >>> Diff: = https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-introspection-10.tx= t = >>>=20 >>> Please let me know if you have any further questions, >>> =97 Justin >>>=20 >>>> On Jun 11, 2015, at 5:00 PM, Justin Richer > wrote: >>>>=20 >>>> Hi Alissa, thanks for your review. Responses are inline. >>>>=20 >>>>> On Jun 8, 2015, at 9:40 AM, Alissa Cooper > wrote: >>>>>=20 >>>>> Alissa Cooper has entered the following ballot position for >>>>> draft-ietf-oauth-introspection-09: Discuss >>>>>=20 >>>>> When responding, please keep the subject line intact and reply to = all >>>>> email addresses included in the To and CC lines. (Feel free to cut = this >>>>> introductory paragraph, however.) >>>>>=20 >>>>>=20 >>>>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html = >>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>=20 >>>>>=20 >>>>> The document, along with other ballot positions, can be found = here: >>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ = >>>>>=20 >>>>>=20 >>>>>=20 >>>>> = ---------------------------------------------------------------------- >>>>> DISCUSS: >>>>> = ---------------------------------------------------------------------- >>>>>=20 >>>>> =3D Section 2.1 =3D >>>>> "The endpoint MAY allow other parameters to provide further = context to >>>>> the query. For instance, an authorization service may need to = know >>>>> the IP address of the client accessing the protected resource in >>>>> order to determine the appropriateness of the token being = presented." >>>>>=20 >>>>> How does the protected resource know whether it needs to include = such >>>>> additional parameters or not? >>>>> What is meant by the "appropriateness" of >>>>> the token?=20 >>>>>=20 >>>>> In general if we're talking about a piece of data that could be = sensitive >>>>> like client IP address, it would be better for there to be = specific >>>>> guidelines to direct protected resources as to when this = information >>>>> needs to be sent. I note that Section 5 basically says such >>>>> considerations are out of scope, but if this specific example is = to be >>>>> provided here then they seem in scope to me. >>>>=20 >>>> We are trying to leave the door open to extensions and adaptations = of this protocol, specifically around the protected resource passing = along information about the client=92s request. The AS might be able to = help the RS detect funny business on the client=92s behalf (i.e., = whether it=92s appropriate for the client to presenting the token in = this context) if it has that information.=20 >>>>=20 >>>> The example isn=92t supposed to be normative or pull extra = considerations into scope of this protocol but instead to point out = where it could go. >>=20 >>=20 >> I think there are two more changes that could make this crystal = clear.=20 >>=20 >> In 2.1: >> s/The definition of any other parameters/The definition of this or = any other parameters/ >>=20 >> In 5: >> s/such information could have additional privacy considerations/such = information could have additional privacy considerations that extension = specifications should detail./ >>=20 >> Thanks, >> Alissa >>=20 >>>>=20 >>>> Do you have a suggestion for rewording this? Perhaps it would be = best to move all of this language to the security considerations = section, as it=92s more guidance for what extensions to this spec would = need to think about as opposed to what pure implementations of this spec = would need. >>>>=20 >>>>>=20 >>>>> =3D Section 5 =3D >>>>> "One way to limit disclosure is to require >>>>> authorization to call the introspection endpoint and to limit = calls >>>>> to only registered and trusted protected resource servers." >>>>>=20 >>>>> I thought Section 2.1 made authorization to call the introspection >>>>> endpoint mandatory. This makes it sound like it's optional. Which = is it? >>>>=20 >>>> Thanks for this catch. Authorization used to be optional, and it = looks like we missed updating this text. I=92ll fix that in the next = revision. >>>>=20 >>>>>=20 >>>>>=20 >>>>> = ---------------------------------------------------------------------- >>>>> COMMENT: >>>>> = ---------------------------------------------------------------------- >>>>>=20 >>>>> =3D Section 1.1 =3D >>>>> There is no reference to RFC2119 here, which may be okay but most >>>>> documents include it if they use normative language (I think). >>>>>=20 >>>>=20 >>>> Not sure how that happened, this should have been included by the = xml2rfc tooling, I=92ll look into it. >>>>=20 >>>>> =3D Section 2 =3D >>>>> "The >>>>> definition of an active token is up to the authorization server, = but >>>>> this is commonly a token that has been issued by this = authorization >>>>> server, is not expired, has not been revoked, and is within the >>>>> purview of the protected resource making the introspection call." >>>>>=20 >>>>> Is "within the purview" a term of art for OAuth 2.0? Is there a = more >>>>> specific way to describe what is meant here? Also, I note that in = the >>>>> description of the "active" member in Section 2.2, this criterion = is not >>>>> listed. It seems like these should be aligned. >>>>=20 >>>> It is not a term of art in OAuth, and I can change that to =93is = able to be used at the protected resource=94 if that=92s clearer. I will = also add that to the list of checks about the active value, thanks. >>>>=20 >>>>>=20 >>>>> =3D Section 2.2 =3D >>>>> "Note that in order to avoid disclosing too much of the >>>>> authorization server's state to a third party, the authorization >>>>> server SHOULD NOT include any additional information about an >>>>> inactive token, including why the token is inactive." >>>>>=20 >>>>> Seems like this should be a MUST NOT unless there's some reason = for >>>>> providing anything other than active set to false. Same comment = applies >>>>> in Section 4. >>>>=20 >>>> That=92s why it=92s SHOULD =97 which translates, roughly, to =93do = it this way unless you=92ve got a really, really good reason not to=94. >>>>=20 >>>>>=20 >>>>> =3D Section 2.3 =3D >>>>> It seems like there is another error condition and I'm wondering = if its >>>>> handling needs to be specified. Per my question in Section 2.1, if = it's >>>>> possible that the request is properly formed but is missing some >>>>> additional information that the authorization server needs to = evaluate >>>>> it, should there be an error condition specified for that case? >>>>>=20 >>>>=20 >>>> Not by this specification, since there isn=92t a mechanism for the = protected resource to figure out automatically what to do next. If = there=92s a future extension specifying this extra information, it can = define its own value. >>>>=20 >>>> =97 Justin >>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_71BA4D47-0848-4A58-86D4-1D919D934F48 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Alissa,

I=92ve incorporated your suggested wording changes into the = latest version of the document:

Draft: https://tools.ietf.org/html/draft-ietf-oauth-introspection-11

Diff: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-introspe= ction-11.txt

Hopefully this will be sufficient to clear the DISCUSS. = Thanks for your thorough review and feedback!

 =97 Justin

On Jul 3, 2015, at 3:16 PM, = Justin Richer <jricher@MIT.EDU> wrote:

Hi Alissa,

Thanks for the wording suggestions. Both of those sound = reasonable to me, so I=92ll pull them into an updated draft shortly. = I=92ll post back here when it=92s been published.
 =97 Justin

On Jul 3, 2015, at 2:47 PM, Alissa Cooper = <alissa@cooperw.in> wrote:

Hi = Justin,

Thanks = for addressing my comments. One more note below.

On Jun 22, 2015, at 5:51 PM, Justin Richer = <jricher@mit.edu> = wrote:

Alissa,

I=92ve uploaded a new draft that should = address your comments below:

Draft: https://tools.ietf.org/html/draft-ietf-oauth-introspection-10

Diff: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-introspe= ction-10.txt

Please let me know if you have any further = questions,
 =97 Justin

On Jun 11, 2015, at 5:00 PM, Justin Richer = <jricher@MIT.EDU> = wrote:

Hi = Alissa, thanks for your review. Responses are inline.

On Jun 8, 2015, at 9:40 = AM, Alissa Cooper <alissa@cooperw.in> wrote:

Alissa Cooper has entered the following ballot position = for
draft-ietf-oauth-introspection-09: Discuss

When responding, please keep the subject line = intact and reply to all
email addresses included in the To = and CC lines. (Feel free to cut this
introductory = paragraph, however.)


Please = refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection= /



---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

=3D Section 2.1 =3D
"The endpoint MAY allow other parameters to provide further = context to
 the query.  For instance, an = authorization service may need to know
 the IP = address of the client accessing the protected resource in
=  order to determine the appropriateness of the token being = presented."

How does the protected resource = know whether it needs to include such
additional = parameters or not?
What is meant by the "appropriateness" = of
the token?

In general if = we're talking about a piece of data that could be sensitive
like client IP address, it would be better for there to be = specific
guidelines to direct protected resources as to = when this information
needs to be sent. I note that = Section 5 basically says such
considerations are out of = scope, but if this specific example is to be
provided here = then they seem in scope to me.

We are trying to leave the door open to extensions and = adaptations of this protocol, specifically around the protected resource = passing along information about the client=92s request. The AS might be = able to help the RS detect funny business on the client=92s behalf = (i.e., whether it=92s appropriate for the client to presenting the token = in this context) if it has that information.

The example isn=92t supposed to be normative or pull extra = considerations into scope of this protocol but instead to point out = where it could go.

I = think there are two more changes that could make this crystal = clear. 

In = 2.1:
s/The definition of any other parameters/The = definition of this or any other parameters/

In 5:
s/such = information could have additional privacy considerations/such = information could have additional privacy considerations that extension = specifications should detail./

Thanks,
Alissa


Do you have a suggestion for rewording this? Perhaps it would = be best to move all of this language to the security considerations = section, as it=92s more guidance for what extensions to this spec would = need to think about as opposed to what pure implementations of this spec = would need.


=3D Section 5 =3D
"One way to = limit disclosure is to require
 authorization to = call the introspection endpoint and to limit calls
=  to only registered and trusted protected resource servers."

I thought Section 2.1 made authorization to = call the introspection
endpoint mandatory. This makes it = sound like it's optional. Which is it?

Thanks for this catch. Authorization used to be optional, and = it looks like we missed updating this text. I=92ll fix that in the next = revision.



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

=3D Section 1.1 =3D
There is no reference to RFC2119 here, which may be okay but = most
documents include it if they use normative language = (I think).


Not = sure how that happened, this should have been included by the xml2rfc = tooling, I=92ll look into it.

=3D Section 2 =3D
"The
 definition of an active token is up to the = authorization server, but
 this is commonly a token = that has been issued by this authorization
 server, = is not expired, has not been revoked, and is within the
=  purview of the protected resource making the introspection = call."

Is "within the purview" a term of = art for OAuth 2.0? Is there a more
specific way to = describe what is meant here? Also, I note that in the
description of the "active" member in Section 2.2, this = criterion is not
listed. It seems like these should be = aligned.

It is not a term of = art in OAuth, and I can change that to =93is able to be used at the = protected resource=94 if that=92s clearer. I will also add that to the = list of checks about the active value, thanks.


=3D = Section 2.2 =3D
"Note that in order to avoid disclosing = too much of the
 authorization server's state to a = third party, the authorization
 server SHOULD NOT = include any additional information about an
=  inactive token, including why the token is inactive."

Seems like this should be a MUST NOT unless = there's some reason for
providing anything other than = active set to false. Same comment applies
in Section 4.

That=92s why it=92s SHOULD =97 = which translates, roughly, to =93do it this way unless you=92ve got a = really, really good reason not to=94.


=3D = Section 2.3 =3D
It seems like there is another error = condition and I'm wondering if its
handling needs to be = specified. Per my question in Section 2.1, if it's
possible = that the request is properly formed but is missing some
additional information that the authorization server needs to = evaluate
it, should there be an error condition specified = for that case?


Not by this specification, since there isn=92t a mechanism = for the protected resource to figure out automatically what to do next. = If there=92s a future extension specifying this extra information, it = can define its own value.

=97 Justin


_______________________________________________
OAuth mailing 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=_71BA4D47-0848-4A58-86D4-1D919D934F48-- From nobody Sun Jul 5 17:10:58 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCD91B29AC; Sun, 5 Jul 2015 17:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMktjoqe7pvw; Sun, 5 Jul 2015 17:10:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F721B29B8; Sun, 5 Jul 2015 17:10:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706001053.6288.97868.idtracker@ietfa.amsl.com> Date: Sun, 05 Jul 2015 17:10:53 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-13.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 00:10:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : Proof Key for Code Exchange by OAuth Public Clients Authors : Nat Sakimura John Bradley Naveen Agarwal Filename : draft-ietf-oauth-spop-13.txt Pages : 19 Date : 2015-07-05 Abstract: OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-spop-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-spop-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 5 20:19:53 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4CF71B2A61 for ; Sun, 5 Jul 2015 20:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-WiXedvgJHi for ; Sun, 5 Jul 2015 20:19:50 -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 0E5E61B2A5D for ; Sun, 5 Jul 2015 20:19:50 -0700 (PDT) Received: by obbnt2 with SMTP id nt2so17844521obb.0 for ; Sun, 05 Jul 2015 20:19:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/TJQ5/xrwTzdL4/Fze+EmQEdw2oQRqxrcZmHCU13hrQ=; b=qq8CHOyfaOPPGziHZoo8X0zoI9EicjtwaRhvRcopzpA7hqqrHt2N9sjv0aCd54UKQB zW17WNFNO6JiBmudPJ2C/LKO4shAw7s/MrWu3rP9jD0ul+Id9yeAtz6vygehE3DnR4le y1L+pOwdCvdXisJ0zR2zuyvqwqOIRFqTCcV71cEg/2h/S+56IDoND+juYKgk8hH+uSmU uqSYVwi05Y411D9wMbpKJaUwiidzu5k0kA51R5wBEeYdoTVE/gAgGEOAc8/kvndMBY1E W2P/g2+pJrG+ZjKS+TD6YLc9I9prUjODeucVBZ63wpqcoaQc/Dh+lgtMiia8i7htwZsT y85w== MIME-Version: 1.0 X-Received: by 10.202.240.215 with SMTP id o206mr43147195oih.94.1436152789571; Sun, 05 Jul 2015 20:19:49 -0700 (PDT) Received: by 10.182.96.66 with HTTP; Sun, 5 Jul 2015 20:19:49 -0700 (PDT) In-Reply-To: <2A451AC4-6414-4318-B188-C944E205C7E1@ve7jtb.com> References: <47E83806AE926749BB17D1020685E6901903F0CC5F@APJ1XCHEVSPIN36.SYMC.SYMANTEC.COM> <2A451AC4-6414-4318-B188-C944E205C7E1@ve7jtb.com> Date: Mon, 6 Jul 2015 12:19:49 +0900 Message-ID: From: Nat Sakimura To: John Bradley Content-Type: multipart/alternative; boundary=94eb2c09204edd9eac051a2c60a5 Archived-At: Cc: Lisa Li1 , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Question about usage of OAuth between servers X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 03:19:52 -0000 --94eb2c09204edd9eac051a2c60a5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Lisa, So, what are you trying to Authenticate? OAuth by itself does not authenticate an end-user. Or are you just concerned with authorization which is embodied in access and refresh tokens? Also, whether you should go to HoK or stay with bearer really depends on the risk that arises from a compromise. Nat 2015=E5=B9=B47=E6=9C=883=E6=97=A5=E9=87=91=E6=9B=9C=E6=97=A5=E3=80=81John B= radley=E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D=E3= =81=BE=E3=81=97=E3=81=9F: > +1 > JB. > > On Jul 2, 2015, at 1:33 PM, Adam Lewis > wrote= : > > Hi Lisa, > > Form the perspective of OAuth, there is ALWAYS a client (even if it is > running on a server). Of your two servers, one is exposing an API (so th= is > will be your RS), and the other server is a client of that API, so that > will be your Client. So it is still a client-server communication. > > So it's a question then if whether or not the server (acting as an API > client) is accessing the other server's API on it's own behalf or on beha= lf > of an end user, and if acting on behalf of an end user, then how does the > end user interact with the server (acting as the API client)? > > If the server acting as an API client is acting on its own behalf, then > you want the client credential grant type (or possible a SAML or JWT > assertion). > If the server acting as an API client is acting on behalf of an end user > and the end user is coming in through a browser, then you want the > authorization code grant type. > If the server acting as an API client is acting on behalf of an end user > and the end user directly signs onto the server, then you might be stuck > using the RO password grant type. > > authorization code and RO grant types give you a refresh token that you > can use to refresh the access token. In the case of client credentials, > the client stores a long term PSK or has a public private key pair used t= o > request access tokens, so it will directly communicate with the token > endpoint using those to get new access tokens. > > Does that make sense? > adam > > On Mon, Jun 29, 2015 at 9:18 PM, Lisa Li1 > wrote: > >> Hi All >> >> >> >> This is Lisa. >> >> Our project is adopting OAuth 2 as authentication specification. >> >> For the client-server communication, OAuth token works fine. But we have >> some cases of server to server communication, usually it will be multipl= e >> tasks running in parallel or sequence or even in multiple threads. In th= is >> case, we are not sure we should reuse the access token grant by end user= or >> create another token? Moreover, if token is expired in 30 min, we are ab= le >> to do refresh but may meet some issue on the token consistency between e= ach >> task, thus it might be refreshed again and again=E2=80=A6 >> >> >> >> But with OAuth 1.0, since it will not expired and we don=E2=80=99t have = to do >> refresh, it will work fine. >> >> >> >> So for OAuth 2.0, what=E2=80=99s your consideration for server to server >> communication scenario? Or do you have any suggestion here? >> >> >> >> Thanks. >> >> >> >> >> >> *Lisa Li* >> >> Principal Software Engineer >> >> Symantec Corporation >> >> >> >> Office: (010) 6272 5127 / Mobile: 189 1057 2219 >> >> Lisa_Li1@symantec.com >> >> >> >> >> >> >> >> >> >> >> This message (including any attachments) is intended only for the use of >> the individual or entity to which it is addressed and may contain >> information that is non-public, proprietary, privileged, confidential, a= nd >> exempt from disclosure under applicable law or may constitute as attorne= y >> work product. If you are not the intended recipient, you are hereby >> notified that any use, dissemination, distribution, or copying of this >> communication is strictly prohibited. If you have received this >> communication in error, notify us immediately by telephone and (i) destr= oy >> this message if a facsimile or (ii) delete this message immediately if t= his >> is an electronic communication. >> >> >> >> _______________________________________________ >> OAuth mailing 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 --94eb2c09204edd9eac051a2c60a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Lisa,=C2=A0

So, what are you trying to Authenticate?= =C2=A0
OAuth by itself does not authenticate an end-user.=C2=A0
Or are you just concerned with authorization which is embodied in = access and refresh tokens?=C2=A0

Also,=C2=A0whethe= r you should go to HoK or stay with bearer really depends on the risk that = arises from a compromise.=C2=A0

Nat
2015=E5=B9=B47=E6=9C=883=E6=97=A5=E9=87=91=E6=9B=9C=E6=97=A5=E3=80=81= John Bradley<ve7jtb@ve7jtb.com&= gt;=E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D=E3=81=BE=E3=81=97=E3=81=9F= :
+1= =C2=A0
JB.

On Jul 2, = 2015, at 1:33 PM, Adam Lewis <adam.l= ewis@motorolasolutions.com> wrote:

Hi= Lisa,

Form the perspective of OAuth, there is ALWAYS a = client (even if it is running on a server).=C2=A0 Of your two servers, one = is exposing an API (so this will be your RS), and the other server is a cli= ent of that API, so that will be your Client.=C2=A0 So it is still a client= -server communication. =C2=A0

So it's a questi= on then if whether or not the server (acting as an API client) is accessing= the other server's API on it's own behalf or on behalf of an end u= ser, and if acting on behalf of an end user, then how does the end user int= eract with the server (acting as the API client)?

= If the server acting as an API client is acting on its own behalf, then you= want the client credential grant type (or possible a SAML or JWT assertion= ).
If the server acting as an API client is acting on behalf of a= n end user and the end user is coming in through a browser, then you want t= he authorization code grant type.
If the server acting as an API = client is acting on behalf of an end user and the end user directly signs o= nto the server, then you might be stuck using the RO password grant type.

authorization code and RO grant types give you a re= fresh token that you can use to refresh the access token.=C2=A0 In the case= of client credentials, the client stores a long term PSK or has a public p= rivate key pair used to request access tokens, so it will directly communic= ate with the token endpoint using those to get new access tokens.

Does that make sense?
adam

On Mon, Jun 29, 2015 at 9:1= 8 PM, Lisa Li1 <Lisa_Li1@syma= ntec.com> wrote:

Hi A= ll

=C2=A0

This is Lisa.

Our p= roject is adopting OAuth 2 as authentication specification. <= /p>

For the client-server communication, OAuth token = works fine. But we have some cases of server to server communication, usual= ly it will be multiple tasks running in parallel or sequence or even in mul= tiple threads. In this case, we are not sure we should reuse the access tok= en grant by end user or create another token? Moreover, if token is expired= in 30 min, we are able to do refresh but may meet some issue on the token = consistency between each task, thus it might be refreshed again and again= =E2=80=A6

=C2=A0

<= p class=3D"MsoNormal">But with OAuth 1.0, since it will not expired and we = don=E2=80=99t have to do refresh, it will work fine.

=C2=A0

So for OAu= th 2.0, what=E2=80=99s your consideration for server to server communicatio= n scenario? Or do you have any suggestion here?

=C2=A0

Thanks.

=C2=A0

=C2=A0

Lisa L= i

Principal Software Engineer

Symantec Corporation

=C2=A0<= /u>

Office: (= 010) 6272 5127=C2=A0 /=C2=A0 Mobile: 189 1057 2219

=

Lisa_Li1@symantec.com

= =C2=A0

<image002.png>

= =C2=A0

=C2=A0

This m= essage (including any attachments) is intended only for the use of the indi= vidual or entity to which it is addressed and may contain information that = is non-public, proprietary, privileged, confidential, and exempt from discl= osure under applicable law or may constitute as attorney work product. If y= ou are not the intended recipient, you are hereby notified that any use, di= ssemination, distribution, or copying of this communication is strictly pro= hibited. If you have received this communication in error, notify us immedi= ately by telephone and (i) destroy this message if a facsimile or (ii) dele= te this message immediately if this is an electronic communication.<= span style=3D"font-size:8.0pt;font-family:"Helvetica","sans-= serif";color:#689fa4">

= =C2=A0


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


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


--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/<= /a>
@_nat_en

--94eb2c09204edd9eac051a2c60a5-- From nobody Mon Jul 6 04:33:14 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24571A010D for ; Mon, 6 Jul 2015 04:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rh17pQDs23zY for ; Mon, 6 Jul 2015 04:33:10 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 213771A014E for ; Mon, 6 Jul 2015 04:33:07 -0700 (PDT) Received: by wifm2 with SMTP id m2so26787448wif.1 for ; Mon, 06 Jul 2015 04:33:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=raMlbkuDj1ceRahXzdLfE6pifM1Q4Py0riJO3Yf2/qw=; b=fwt9s5Hkv5Rssm2UZIAIl/+fwmyB81+5I25VbUNjsKebswLy8VKyxrsVqjKkq6trI8 3GLGpZb0eztt6PWx+RfzCsWC99+5rUdXXcjrbypSCGO43gi+qWwRJr52/bUcJnM8+4Tp 9z3ML66cxuCXv00jcVz8vaNm95xngttZZvTj+vjVnEDJEcRdAXwtDU1Vy7Lbrd0xWnFu MhyXZold0paUoiX+LDRArRyo4QgorzxYzwfFEKYgcO/JLC3e7vZtXFS96I/b1/Vs5hIB s+aSmswiawIAHJjd02652l8MuK9Ole3qRhP7ZdFt+YxU64cA4+pnwD/B/jiqJUfAr7OK odPA== X-Received: by 10.180.108.142 with SMTP id hk14mr53625031wib.5.1436182385861; Mon, 06 Jul 2015 04:33:05 -0700 (PDT) Received: from [192.168.2.7] ([89.100.27.122]) by mx.google.com with ESMTPSA id x10sm27637996wjr.25.2015.07.06.04.33.04 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jul 2015 04:33:05 -0700 (PDT) Message-ID: <559A676F.3070008@gmail.com> Date: Mon, 06 Jul 2015 12:33:03 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Brian Campbell References: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> <55928DB3.7090300@gmail.com> <5593C270.7000008@gmail.com> <5593DA7D.80401@mit.edu> <5593E5FD.3050403@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 11:33:12 -0000 Hi Brian I've read the text, I like it is still pure OAuth2, with few extra parameters added to the access token request, and a key response property being 'access_token' as opposed to 'security_access_token' as in the draft-ietf-oauth-token-exchange-01. It appears draft-campbell-oauth-sts-01 can cover a draft-richer-oauth-chain-00 case with the on_behalf_of (and/or act_as ?) property being an original client token but not 100% sure given draft-richer-oauth-chain-00 covers a specific case. One thing I'm not sure about is what is the purpose of specifying a security_token_type of the returned access token Thanks, Sergey On 01/07/15 15:59, Brian Campbell wrote: > One problem, I think, with token exchange is that it can be really > simple (token in and token out) and really complicated (client X wants a > token that says user A is doing something on behalf of user B) at the > same time. > > I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in > an attempt to simplify things and express what I envisioned as an OAuth > based token exchange framework. Though it likely only muddied the waters :) > > On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin > wrote: > > Hi Justin > > https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much > easier to read, that I can tell for sure, at least it is obvious why > a given entity (RS1) may want to exchange the current token provided > by a client for a new token. Definitely easily implementable... > > One thing I'm not sure in the draft-richer-oauth-chain-00 about is > on behalf of whose entity RS1 will be acting once it starts > accessing RS2, On Behalf Of RO, or may be On Behalf Of (RO + > Client), or may be it is On Behalf Of RO + Act As Client ? The last > one seems most logical to me... > > Thanks, Sergey > > > On 01/07/15 13:18, Justin Richer wrote: > > As it's written right now, it's a translation of some WS-* > concepts into > JWT format. It's not really OAuth-y (since the client has to > understand > the token format along with everyone else, and according to the > authors > the artifacts might not even be "OAuth tokens"), and that's my main > issue with the document. Years ago, I proposed an OAuth-based > token swap > mechanism: > > https://tools.ietf.org/html/draft-richer-oauth-chain-00 > > This works without defining semantics of the tokens themselves, just > like the rest of OAuth. I've proposed to the authors of the current > draft that it should incorporate both semantic (using JWT) and > syntactic > (using a simple token-agnostic grant) token swap mechanisms, and > that > the two could be easily compatible. > > -- Justin > > On 7/1/2015 6:35 AM, Sergey Beryozkin wrote: > > Hmm... perhaps the clue is in the draft title, > token-exchange, so may > be it is a case of the given access token ("on_behalf_of" or > "act_as" > claim) being used to request a new security token. One can > only guess > though, does not seem like the authors are keen to answer > the newbie > questions... > > Cheers, Sergey > > > On 30/06/15 13:38, Sergey Beryozkin wrote: > > Hi, > Can you please explain what is the difference between > On-Behalf-Of > semantics described in the > draft-ietf-oauth-token-exchange-01 and the > implicit On-Behalf-Of semantics a client OAuth2 token > possesses ? > > For example, draft-ietf-oauth-token-exchange-01 mentions: > > "Whereas, with on-behalf-of semantics, principal A still > has its own > identity separate from B and it is explicitly understood > that while B > may have delegated its rights to A, any actions taken > are being taken by > A and not B. In a sense, A is an agent for B." > > This is a typical case with the authorization code flow > where a client > application acts on-behalf-of the user who authorized > this application ? > > Sorry if I'm missing something > > Cheers, Sergey > On 25/06/15 22:28, Mike Jones wrote: > > That’s what > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 > is > about. > > Cheers, > > -- Mike > > *From:*OAuth [mailto:oauth-bounces@ietf.org > ] *On Behalf Of *Vivek > Biswas > -T (vibiswas - XORIANT CORPORATION at Cisco) > *Sent:* Thursday, June 25, 2015 2:20 PM > *To:* OAuth@ietf.org > *Subject:* [OAUTH-WG] JWT Token on-behalf of Use case > > Hi All, > > I am looking to solve a use-case similar to > WS-Security On-Behalf-Of > > > > with OAuth JWT Token. > > Is there a standard claim which we can define > within the OAuth JWT > which denote the On-behalf-of User. > > For e.g., a Customer Representative trying to create > token on behalf of > a customer and trying to execute services specific > for that specific > customer. > > Regards, > > Vivek Biswas, > CISSP > > *Cisco Systems, Inc * > > *Bldg. J, San Jose, USA,* > > *Phone: +1 408 527 9176 * > > > > _______________________________________________ > OAuth mailing list > OAuth@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 > > From nobody Mon Jul 6 07:05:11 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5502B1A87BC for ; Mon, 6 Jul 2015 07:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChbybcujdtnH for ; Mon, 6 Jul 2015 07:05:07 -0700 (PDT) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A3801A87DB for ; Mon, 6 Jul 2015 07:05:02 -0700 (PDT) Received: by iecuq6 with SMTP id uq6so113756581iec.2 for ; Mon, 06 Jul 2015 07:05:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=7LMxN08RmTq72NzCwMBVS/1bhTo+1iwp0vimr4wBIpw=; b=ioSCMHCALIyz6HT5U9jIhIfyhZzjbEvUxy6g8zTQ4quQz8ZxtsVeN1avTvIATZMmEG xB6T+jyj0/kur5skKX7QNZgGR3b/1ggpZNdcGDrqP5gY+XYjpTdoU+vbHq6QYK2DfZAX amOUoFVj1X4lfnVS6Zvqa2eenQiwIPZmNZ2NFkLnEMG4c7O7ZVDySA+WCvL1PkejeTvp wVGxDpmMd4gZGu6NJCfZtQMJEskBG+YhcLhYn/lQNNU3/qGv74d5mf3oQjni838d0Znp z7OOGMpWs4WHX3sQYCGgWaDwEg0DrnI4gEKF4fRmgyMAa/AWYJErJ/W0+4J7EO135xmg b6SQ== X-Gm-Message-State: ALoCoQkIya8OJKUZZ/dr6zRptbw3hKTuAlXcS/nFOrbaWf4uSm+e1Ckim2R7PAzAS6uuR3i+uBVq X-Received: by 10.43.19.131 with SMTP id qk3mr36131953icb.15.1436191501339; Mon, 06 Jul 2015 07:05:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.64.209 with HTTP; Mon, 6 Jul 2015 07:04:31 -0700 (PDT) In-Reply-To: <559A676F.3070008@gmail.com> References: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> <55928DB3.7090300@gmail.com> <5593C270.7000008@gmail.com> <5593DA7D.80401@mit.edu> <5593E5FD.3050403@gmail.com> <559A676F.3070008@gmail.com> From: Brian Campbell Date: Mon, 6 Jul 2015 08:04:31 -0600 Message-ID: To: Sergey Beryozkin Content-Type: multipart/alternative; boundary=bcaec517cddc447279051a356423 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 14:05:10 -0000 --bcaec517cddc447279051a356423 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Sergey, The goal of draft-campbell-oauth-sts was to be consistent with OAuth 2.0 and thus hopefully familiar to developers and easy to understand and implement (especially from the client side). It's also intended to be flexible in order to accommodate a variety of use-cases including the chaining type cases that Justin's draft covers. Specifying a security_token_type of the returned token is just a way of providing more info to the client about the token (i.e. is this a JWT or a SAML token or something else) via a URI. It's not always needed but in STS style cases the tokens are not always opaque to the client and the parameter just provides info about the returned token. On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin wrote: > Hi Brian > > I've read the text, I like it is still pure OAuth2, with few extra > parameters added to the access token request, and a key response property > being 'access_token' as opposed to 'security_access_token' as in the > draft-ietf-oauth-token-exchange-01. > It appears draft-campbell-oauth-sts-01 can cover a > draft-richer-oauth-chain-00 case with the on_behalf_of (and/or act_as ?) > property being an original client token but not 100% sure given > draft-richer-oauth-chain-00 covers a specific case. > > One thing I'm not sure about is what is the purpose of specifying a > security_token_type of the returned access token > > Thanks, Sergey > > On 01/07/15 15:59, Brian Campbell wrote: > >> One problem, I think, with token exchange is that it can be really >> simple (token in and token out) and really complicated (client X wants a >> token that says user A is doing something on behalf of user B) at the >> same time. >> >> I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in >> an attempt to simplify things and express what I envisioned as an OAuth >> based token exchange framework. Though it likely only muddied the waters >> :) >> >> On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin > > wrote: >> >> Hi Justin >> >> https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much >> easier to read, that I can tell for sure, at least it is obvious why >> a given entity (RS1) may want to exchange the current token provided >> by a client for a new token. Definitely easily implementable... >> >> One thing I'm not sure in the draft-richer-oauth-chain-00 about is >> on behalf of whose entity RS1 will be acting once it starts >> accessing RS2, On Behalf Of RO, or may be On Behalf Of (RO + >> Client), or may be it is On Behalf Of RO + Act As Client ? The last >> one seems most logical to me... >> >> Thanks, Sergey >> >> >> On 01/07/15 13:18, Justin Richer wrote: >> >> As it's written right now, it's a translation of some WS-* >> concepts into >> JWT format. It's not really OAuth-y (since the client has to >> understand >> the token format along with everyone else, and according to the >> authors >> the artifacts might not even be "OAuth tokens"), and that's my >> main >> issue with the document. Years ago, I proposed an OAuth-based >> token swap >> mechanism: >> >> https://tools.ietf.org/html/draft-richer-oauth-chain-00 >> >> This works without defining semantics of the tokens themselves, >> just >> like the rest of OAuth. I've proposed to the authors of the >> current >> draft that it should incorporate both semantic (using JWT) and >> syntactic >> (using a simple token-agnostic grant) token swap mechanisms, and >> that >> the two could be easily compatible. >> >> -- Justin >> >> On 7/1/2015 6:35 AM, Sergey Beryozkin wrote: >> >> Hmm... perhaps the clue is in the draft title, >> token-exchange, so may >> be it is a case of the given access token ("on_behalf_of" or >> "act_as" >> claim) being used to request a new security token. One can >> only guess >> though, does not seem like the authors are keen to answer >> the newbie >> questions... >> >> Cheers, Sergey >> >> >> On 30/06/15 13:38, Sergey Beryozkin wrote: >> >> Hi, >> Can you please explain what is the difference between >> On-Behalf-Of >> semantics described in the >> draft-ietf-oauth-token-exchange-01 and the >> implicit On-Behalf-Of semantics a client OAuth2 token >> possesses ? >> >> For example, draft-ietf-oauth-token-exchange-01 mentions= : >> >> "Whereas, with on-behalf-of semantics, principal A still >> has its own >> identity separate from B and it is explicitly understood >> that while B >> may have delegated its rights to A, any actions taken >> are being taken by >> A and not B. In a sense, A is an agent for B." >> >> This is a typical case with the authorization code flow >> where a client >> application acts on-behalf-of the user who authorized >> this application ? >> >> Sorry if I'm missing something >> >> Cheers, Sergey >> On 25/06/15 22:28, Mike Jones wrote: >> >> That=E2=80=99s what >> >> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 >> is >> about. >> >> Cheers, >> >> -- Mike >> >> *From:*OAuth [mailto:oauth-bounces@ietf.org >> ] *On Behalf Of *Vive= k >> Biswas >> -T (vibiswas - XORIANT CORPORATION at Cisco) >> *Sent:* Thursday, June 25, 2015 2:20 PM >> *To:* OAuth@ietf.org >> *Subject:* [OAUTH-WG] JWT Token on-behalf of Use cas= e >> >> Hi All, >> >> I am looking to solve a use-case similar to >> WS-Security On-Behalf-Of >> < >> http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust-1.4-= errata01-os-complete.html#_Toc325658980 >> > >> >> >> with OAuth JWT Token. >> >> Is there a standard claim which we can define >> within the OAuth JWT >> which denote the On-behalf-of User. >> >> For e.g., a Customer Representative trying to create >> token on behalf of >> a customer and trying to execute services specific >> for that specific >> customer. >> >> Regards, >> >> Vivek Biswas, >> CISSP >> >> *Cisco Systems, Inc * >> >> *Bldg. J, San Jose, USA,* >> >> *Phone: +1 408 527 9176 >> * >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@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 >> >> >> > > --bcaec517cddc447279051a356423 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Sergey,

The goal of draft-campbe= ll-oauth-sts was to be consistent with OAuth 2.0 and thus hopefully familia= r to developers and easy to understand and implement (especially from the c= lient side). It's also intended to be flexible in order to accommodate = a variety of use-cases including the chaining type cases that Justin's = draft covers.

Specifying a security_token_type of the returned toke= n is just a way of providing more info to the client about the token (i.e. = is this a JWT or a SAML token or something else) via a URI. It's not al= ways needed but in STS style cases the tokens are not always opaque to the = client and the parameter just provides info about the returned token.=C2=A0=

On Mon= , Jul 6, 2015 at 5:33 AM, Sergey Beryozkin <sberyozkin@gmail.com>= ; wrote:
Hi Brian

I've read the text, I like it is still pure OAuth2, with few extra para= meters added to the access token request, and a key response property being= 'access_token' as opposed to 'security_access_token' as in= the draft-ietf-oauth-token-exchange-01.
It appears draft-campbell-oauth-sts-01 can cover a draft-richer-oauth-chain= -00 case with the on_behalf_of (and/or act_as ?) property being an original= client token but not 100% sure given draft-richer-oauth-chain-00 covers a = specific case.

One thing I'm not sure about is what is the purpose of specifying a sec= urity_token_type of the returned access token

Thanks, Sergey

On 01/07/15 15:59, Brian Campbell wrote:
One problem, I think, with token exchange is that it can be really
simple (token in and token out) and really complicated (client X wants a token that says user A is doing something on behalf of user B) at the
same time.

I put forth https://tools.ietf.org/html/draft= -campbell-oauth-sts-01 in
an attempt to simplify things and express what I envisioned as an OAuth
based token exchange framework. Though it likely only muddied the waters :)=

On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin <sberyozkin@gmail.com
<mailto:sberyo= zkin@gmail.com>> wrote:

=C2=A0 =C2=A0 Hi Justin

=C2=A0 =C2=A0 https://tools.ietf.org/html/dra= ft-richer-oauth-chain-00 is much
=C2=A0 =C2=A0 easier to read, that I can tell for sure, at least it is obvi= ous why
=C2=A0 =C2=A0 a given entity (RS1) may want to exchange the current token p= rovided
=C2=A0 =C2=A0 by a client for a new token. Definitely easily implementable.= ..

=C2=A0 =C2=A0 One thing I'm not sure in the draft-richer-oauth-chain-00= about is
=C2=A0 =C2=A0 on behalf of whose entity RS1 will be acting once it starts =C2=A0 =C2=A0 accessing RS2, On Behalf Of RO, or may be On Behalf Of (RO +<= br> =C2=A0 =C2=A0 Client), or may be it is On Behalf Of RO + Act As Client ? Th= e last
=C2=A0 =C2=A0 one seems most logical to me...

=C2=A0 =C2=A0 Thanks, Sergey


=C2=A0 =C2=A0 On 01/07/15 13:18, Justin Richer wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 As it's written right now, it's a trans= lation of some WS-*
=C2=A0 =C2=A0 =C2=A0 =C2=A0 concepts into
=C2=A0 =C2=A0 =C2=A0 =C2=A0 JWT format. It's not really OAuth-y (since = the client has to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 understand
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the token format along with everyone else, and = according to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 authors
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the artifacts might not even be "OAuth tok= ens"), and that's my main
=C2=A0 =C2=A0 =C2=A0 =C2=A0 issue with the document. Years ago, I proposed = an OAuth-based
=C2=A0 =C2=A0 =C2=A0 =C2=A0 token swap
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mechanism:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://tools.iet= f.org/html/draft-richer-oauth-chain-00

=C2=A0 =C2=A0 =C2=A0 =C2=A0 This works without defining semantics of the to= kens themselves, just
=C2=A0 =C2=A0 =C2=A0 =C2=A0 like the rest of OAuth. I've proposed to th= e authors of the current
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft that it should incorporate both semantic = (using JWT) and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 syntactic
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (using a simple token-agnostic grant) token swa= p mechanisms, and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the two could be easily compatible.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Justin

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On 7/1/2015 6:35 AM, Sergey Beryozkin wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hmm... perhaps the clue is in the= draft title,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 token-exchange, so may
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be it is a case of the given acce= ss token ("on_behalf_of" or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "act_as"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 claim) being used to request a ne= w security token. One can
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 only guess
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 though, does not seem like the au= thors are keen to answer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the newbie
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 questions...

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers, Sergey


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On 30/06/15 13:38, Sergey Beryozk= in wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Can you please expl= ain what is the difference between
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On-Behalf-Of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 semantics described= in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-oauth-to= ken-exchange-01 and the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 implicit On-Behalf-= Of semantics a client OAuth2 token
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 possesses ?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 For example, draft-= ietf-oauth-token-exchange-01 mentions:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Whereas, with= on-behalf-of semantics, principal A still
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 has its own
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 identity separate f= rom B and it is explicitly understood
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that while B
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 may have delegated = its rights to A, any actions taken
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 are being taken by<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A and not B. In a s= ense, A is an agent for B."

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This is a typical c= ase with the authorization code flow
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 where a client
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 application acts on= -behalf-of the user who authorized
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this application ?<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Sorry if I'm mi= ssing something

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers, Sergey
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On 25/06/15 22:28, = Mike Jones wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 That= =E2=80=99s what
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://tools.ietf.org/html/draft-ietf-oa= uth-token-exchange-01
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 about= .

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheer= s,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mi= ke

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <m= ailto:oauth-bou= nces@ietf.org>] *On Behalf Of *Vivek
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Biswa= s
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -T (v= ibiswas - XORIANT CORPORATION at Cisco)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *Sent= :* Thursday, June 25, 2015 2:20 PM
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *To:*= OAuth@ietf.org <= ;mailto:OAuth@ietf.org<= /a>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *Subj= ect:* [OAUTH-WG] JWT Token on-behalf of Use case

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi Al= l,

=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 am looking to solve a use-case similar to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 WS-Se= curity On-Behalf-Of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<= a href=3D"http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-tru= st-1.4-errata01-os-complete.html#_Toc325658980" rel=3D"noreferrer" target= =3D"_blank">http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-t= rust-1.4-errata01-os-complete.html#_Toc325658980>


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 with = OAuth JWT Token.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Is there a standard claim which we can define
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 withi= n the OAuth JWT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 which= denote the On-behalf-of User.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 For e= .g., a Customer Representative trying to create
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 token= on behalf of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a cus= tomer and trying to execute services specific
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for t= hat specific
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 custo= mer.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Regar= ds,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Vivek= Biswas,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CISSP=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *Cisc= o Systems, Inc <http://www.cisco.com/>*

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *Bldg= . J, San Jose, USA,*

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *Phon= e: +1 408 527 9176 <tel:%2B1%20408%20527%209176>*



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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 <mailt= o: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 =C2=A0 =C2=A0 OAuth mailing list
 =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 https://www.iet= f.org/mailman/listinfo/oauth


=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.org <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 OAuth mailing list
 =C2=A0 =C2=A0 OAuth@iet= f.org <mailto:OA= uth@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/oau= th





--bcaec517cddc447279051a356423-- From nobody Mon Jul 6 07:25:43 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A431A88A9; Mon, 6 Jul 2015 07:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c52FQZS1Lt9Q; Mon, 6 Jul 2015 07:25:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D101F1A8863; Mon, 6 Jul 2015 07:25:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706142538.15299.54601.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 07:25:38 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 14:25:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture Authors : Phil Hunt Justin Richer William Mills Prateek Mishra Hannes Tschofenig Filename : draft-ietf-oauth-pop-architecture-02.txt Pages : 21 Date : 2015-07-06 Abstract: The OAuth 2.0 bearer token specification, as defined in RFC 6750, allows any party in possession of a bearer token (a "bearer") to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens must to be protected from disclosure in transit and at rest. Some scenarios demand additional security protection whereby a client needs to demonstrate possession of cryptographic keying material when accessing a protected resource. This document motivates the development of the OAuth 2.0 proof-of-possession security mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-architecture-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 6 07:27:03 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0965A1A88B2 for ; Mon, 6 Jul 2015 07:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDfqCnNWvWXG for ; Mon, 6 Jul 2015 07:26:57 -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 B37CE1A8899 for ; Mon, 6 Jul 2015 07:26:47 -0700 (PDT) Received: from [192.168.131.129] ([195.149.223.251]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LsCAp-1Z1vSM3Cil-013rvU for ; Mon, 06 Jul 2015 16:26:45 +0200 Message-ID: <559A9025.6030404@gmx.net> Date: Mon, 06 Jul 2015 16:26:45 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wdQHbHuNIw9gEbNrcMrgOv68FnNJf8LEK" X-Provags-ID: V03:K0:rjASxRXd68uv7x254AIaZ6NIyd/ckDf2bKOxu4Buyrj9WNjtzR9 iqddCrgEoEvoKEiF9FaDgMT00K03Nmp12cIKnkq88aQ8ve6PGLteHer77xz/ljawvrxVy9h TBSCFm0Dzju01HyBtUc98/cO9nbduc8OSSRxSxFRuoh2N62q16euHcQky9mWTjuKnt8vNcf 5j/j7aPIU1hIKSt1uVfNA== X-UI-Out-Filterresults: notjunk:1;V01:K0:hR6IthnUB3k=:Nd483MuDP07YOuaMYqnIUw hraepGAXFgBGl+4jGlJNkP5tHpG+7Vu3i31YfyXfhDk2afEuXnwzOocAoDY3z1+2JO3nJRHd6 /bpuAn6XdAUtV/S2DCeDQRWo9UcRW3rdZzlhfYf/ryZPDO6X2oVfw6V8MCJGsS2X/8pygCL7g nf8unUGEtaUl0o4CC7MGveV6/Sc/CFYaKc++/nuzjj4MQtWtN1xwbAe4PS3ApqWEWTtqZG03f 1fkeAJ56J8wbZNJ0y9nD/kB/2tY7zYv3Z3lJGffZC+5qsMHo7EwFiTtMcDmCCkvY68ldiCRdF pA6s7CWabTiGvXOtUzGHcds1ib2zUr9Jxdl5pXEbYK70nacOrOf/su+SmygkJknyLBZ9I4UTG 9lJ8jq32WtkNbj/2IC8BpLGp67Zrr2g+N0fkZ/UcWdr63vACUIza3wmKMdFXC9dl9+576e1Ba +iASBKv7HmSa1Y9Fc3jjzLqXLdsJ+HZCYb1Tj41l+Q1o+10YdbnfiJ9eGIDx5K2gd1e4GF9LE uIEeH3MlyGsM/qXlCWCXs0yggrJQy7HeulOjQ5YkPSQY/X6YXwKFa4LSNUk//WWQHF5y1cV1A LSKlbjq5bUEM/g0tYYWKDX2KWLYQDRKA09d0okEWWyw+9WQPpjjhXxqad87PaiPfXsW2V8s7F J4kzSllPLgrqGTQSwYO1U8rxolz1DIekSkT8UKqyFKKzTfw== Archived-At: Subject: [OAUTH-WG] draft-ietf-oauth-pop-architecture-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 14:27:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wdQHbHuNIw9gEbNrcMrgOv68FnNJf8LEK Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I submitted version -02 of draft-ietf-oauth-pop-architecture to update references. Here is the document: https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-02 Ciao Hannes --wdQHbHuNIw9gEbNrcMrgOv68FnNJf8LEK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVmpAlAAoJEGhJURNOOiAtwk0H/0ZtvYxOcfY8ePU3jV08+gPw nc946P7RFFQrxlVBW7U7XZG6hgUBiC1fVX8dicM/LIpqd4SvbZDMNeMEzmdAJVZp MmRObZgNlXDdueiDtmlJms45RFwEEXfThcEjrah50IIUJ5NqOAg4P+rRLc/hgWYb lPa3K0yBjqu8bD7aECzmMZ2iKF3GO+/QWOwDR+fH5+l49/hWLJ8pmt9K8iLvPrHt gMonEp9WadDo+zHf+AJ8Foeb+4kV6iJzJsPRgXdndEEYLg+bj6TSFmXUoCyhRzVT sx03ndBNsR61jcAOzaMVieqwLQOWin2zuW2riYVKxGaFis2GWh0fgBU2YNiajkM= =4aiQ -----END PGP SIGNATURE----- --wdQHbHuNIw9gEbNrcMrgOv68FnNJf8LEK-- From nobody Mon Jul 6 08:11:53 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC971A8A29; Mon, 6 Jul 2015 08:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7nNpPBY5-La; Mon, 6 Jul 2015 08:11:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C7B1A8A4B; Mon, 6 Jul 2015 08:11:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706151148.24135.26125.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 08:11:48 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 15:11:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : Request by JWS ver.1.0 for OAuth 2.0 Authors : Nat Sakimura John Bradley Filename : draft-ietf-oauth-jwsreq-03.txt Pages : 10 Date : 2015-07-06 Abstract: The authorization request in OAuth 2.0 utilizes query parameter serialization. This specification defines the authorization request using JWT serialization. The request is sent through "request" parameter or by reference through "request_uri" parameter that points to the JWT, allowing the request to be optionally signed and encrypted. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 6 08:13:00 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251801A89FF for ; Mon, 6 Jul 2015 08:12: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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQwSS5HX5j-4 for ; Mon, 6 Jul 2015 08:12:56 -0700 (PDT) Received: from mail-qk0-f181.google.com (mail-qk0-f181.google.com [209.85.220.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53CCB1A8A63 for ; Mon, 6 Jul 2015 08:12:56 -0700 (PDT) Received: by qkbp125 with SMTP id p125so119073464qkb.2 for ; Mon, 06 Jul 2015 08:12:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=z/kSgUIgwCpkeJ3zb44i6r7bDNLGlGCgwJAeXyEcSJM=; b=ejTxhcop2bRtlACVMX4pn1O6KaDU+H0M+7mPdDKtXYpJNpGMP4AncntbdGqJpuB7EZ +Sq3nPamF7IUprvCR8nM83f41MHj3Y6WvHkAKkgx5RqMIcKZTqJJYdXXVfMRD5NBpwwS KxItdh9bVXTCo1zPuX+r6vP/XuLtk+QbtEXPXzGG6G4tWfJCYE74yD36bRmHvaKELGyQ wXRCKmLmAbnejKzjAn+p4xoqKlrzvIiCkajZF6qRgl2Vc8jhqFTg+imIQYjkDfP3BAQ/ G7EGNHXvNvWGgNUJ4LST+RKOVix1Iv3+/8PfBikIsbPoy1MF5ZV0bcM0zvSWIK7lf5UC ptJg== X-Gm-Message-State: ALoCoQnIa8bh756p5ag3fVeax5iqPqSHTwcOrOYY4vBNUmkZ9C4NTLPa+wleAcAH5FXak96WIRgD X-Received: by 10.140.150.78 with SMTP id 75mr56739130qhw.10.1436195575609; Mon, 06 Jul 2015 08:12:55 -0700 (PDT) Received: from [192.168.1.216] (186-106-155-84.baf.movistar.cl. [186.106.155.84]) by mx.google.com with ESMTPSA id b77sm9400700qkb.8.2015.07.06.08.12.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Jul 2015 08:12:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: John Bradley In-Reply-To: Date: Mon, 6 Jul 2015 12:12:34 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> <55928DB3.7090300@gmail.com> <5593C270.7000008@gmail.com> <5593DA7D.80401@mit.edu> <5593E5FD.3050403@gmail.com> <559A676F.3070008@gmail.com> To: Brian Campbell X-Mailer: Apple Mail (2.2102) Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 15:12:59 -0000 Yes unfortunately we haven=E2=80=99t made any progress on this since = accepting Mike=E2=80=99s first draft. =20 His proposal is basically for a new endpoint while Brian tired to fit it = into the existing token endpoint. I think draft-ietf-oauth-token-exchange-01 still has OnBehalfOf and = ActAs reversed compared to WS-Trust 1.4. see https://msdn.microsoft.com/en-us/library/ee748487.aspx for the short = explanation. I think Brian is closer in explaining it. In fairness because WS-Trust originally only had On-Behalf-Of the naming = and what people put in tokens is a bit muddled in many implementations. I think many times it is how WIF implemented it that people copied. It may be better to have new terms that are clear such as impersonation = and composite. The WG needs to decide if this is going to be an entirely new endpoint, = free of the Token endpoint semantics. There are plusses and minuses to = both options. Also while it is nice to be pure and talk about abstract security = tokens, it would be good to give some guidance on what a composite = security token would look like for interoperability. There are also issues around how this would work with proof of = possession security tokens, both as input and output. Perhaps we can make some progress on this in Prague. John B. =20 > On Jul 6, 2015, at 11:04 AM, Brian Campbell = wrote: >=20 > Thanks Sergey,=20 >=20 > The goal of draft-campbell-oauth-sts was to be consistent with OAuth = 2.0 and thus hopefully familiar to developers and easy to understand and = implement (especially from the client side). It's also intended to be = flexible in order to accommodate a variety of use-cases including the = chaining type cases that Justin's draft covers.=20 >=20 > Specifying a security_token_type of the returned token is just a way = of providing more info to the client about the token (i.e. is this a JWT = or a SAML token or something else) via a URI. It's not always needed but = in STS style cases the tokens are not always opaque to the client and = the parameter just provides info about the returned token. =20 >=20 > On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin = wrote: > Hi Brian >=20 > I've read the text, I like it is still pure OAuth2, with few extra = parameters added to the access token request, and a key response = property being 'access_token' as opposed to 'security_access_token' as = in the draft-ietf-oauth-token-exchange-01. > It appears draft-campbell-oauth-sts-01 can cover a = draft-richer-oauth-chain-00 case with the on_behalf_of (and/or act_as ?) = property being an original client token but not 100% sure given = draft-richer-oauth-chain-00 covers a specific case. >=20 > One thing I'm not sure about is what is the purpose of specifying a = security_token_type of the returned access token >=20 > Thanks, Sergey >=20 > On 01/07/15 15:59, Brian Campbell wrote: > One problem, I think, with token exchange is that it can be really > simple (token in and token out) and really complicated (client X wants = a > token that says user A is doing something on behalf of user B) at the > same time. >=20 > I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in > an attempt to simplify things and express what I envisioned as an = OAuth > based token exchange framework. Though it likely only muddied the = waters :) >=20 > On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin > wrote: >=20 > Hi Justin >=20 > https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much > easier to read, that I can tell for sure, at least it is obvious = why > a given entity (RS1) may want to exchange the current token = provided > by a client for a new token. Definitely easily implementable... >=20 > One thing I'm not sure in the draft-richer-oauth-chain-00 about is > on behalf of whose entity RS1 will be acting once it starts > accessing RS2, On Behalf Of RO, or may be On Behalf Of (RO + > Client), or may be it is On Behalf Of RO + Act As Client ? The = last > one seems most logical to me... >=20 > Thanks, Sergey >=20 >=20 > On 01/07/15 13:18, Justin Richer wrote: >=20 > As it's written right now, it's a translation of some WS-* > concepts into > JWT format. It's not really OAuth-y (since the client has to > understand > the token format along with everyone else, and according to = the > authors > the artifacts might not even be "OAuth tokens"), and that's my = main > issue with the document. Years ago, I proposed an OAuth-based > token swap > mechanism: >=20 > https://tools.ietf.org/html/draft-richer-oauth-chain-00 >=20 > This works without defining semantics of the tokens = themselves, just > like the rest of OAuth. I've proposed to the authors of the = current > draft that it should incorporate both semantic (using JWT) and > syntactic > (using a simple token-agnostic grant) token swap mechanisms, = and > that > the two could be easily compatible. >=20 > -- Justin >=20 > On 7/1/2015 6:35 AM, Sergey Beryozkin wrote: >=20 > Hmm... perhaps the clue is in the draft title, > token-exchange, so may > be it is a case of the given access token ("on_behalf_of" = or > "act_as" > claim) being used to request a new security token. One can > only guess > though, does not seem like the authors are keen to answer > the newbie > questions... >=20 > Cheers, Sergey >=20 >=20 > On 30/06/15 13:38, Sergey Beryozkin wrote: >=20 > Hi, > Can you please explain what is the difference between > On-Behalf-Of > semantics described in the > draft-ietf-oauth-token-exchange-01 and the > implicit On-Behalf-Of semantics a client OAuth2 token > possesses ? >=20 > For example, draft-ietf-oauth-token-exchange-01 = mentions: >=20 > "Whereas, with on-behalf-of semantics, principal A = still > has its own > identity separate from B and it is explicitly = understood > that while B > may have delegated its rights to A, any actions taken > are being taken by > A and not B. In a sense, A is an agent for B." >=20 > This is a typical case with the authorization code = flow > where a client > application acts on-behalf-of the user who authorized > this application ? >=20 > Sorry if I'm missing something >=20 > Cheers, Sergey > On 25/06/15 22:28, Mike Jones wrote: >=20 > That=E2=80=99s what > = https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 > is > about. >=20 > Cheers, >=20 > -- Mike >=20 > *From:*OAuth [mailto:oauth-bounces@ietf.org > ] *On Behalf Of = *Vivek > Biswas > -T (vibiswas - XORIANT CORPORATION at Cisco) > *Sent:* Thursday, June 25, 2015 2:20 PM > *To:* OAuth@ietf.org > *Subject:* [OAUTH-WG] JWT Token on-behalf of Use = case >=20 > Hi All, >=20 > I am looking to solve a use-case similar to > WS-Security On-Behalf-Of > = >=20 >=20 > with OAuth JWT Token. >=20 > Is there a standard claim which we can define > within the OAuth JWT > which denote the On-behalf-of User. >=20 > For e.g., a Customer Representative trying to = create > token on behalf of > a customer and trying to execute services specific > for that specific > customer. >=20 > Regards, >=20 > Vivek Biswas, > CISSP >=20 > *Cisco Systems, Inc * >=20 > *Bldg. J, San Jose, USA,* >=20 > *Phone: +1 408 527 9176 = * >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Jul 6 09:34:24 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725631B2FB0 for ; Mon, 6 Jul 2015 09:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dt0H9VATVDU4 for ; Mon, 6 Jul 2015 09:34:18 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0139.outbound.protection.outlook.com [207.46.100.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7BEE1B3001 for ; Mon, 6 Jul 2015 09:33:47 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.213.10; Mon, 6 Jul 2015 16:33:45 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0213.000; Mon, 6 Jul 2015 16:33:45 +0000 From: Mike Jones To: John Bradley , Brian Campbell Thread-Topic: [OAUTH-WG] JWT Token on-behalf of Use case Thread-Index: AdCvjKZzog4lHzdSReisaGHaz/hQ6gAARPxgAOj5XIAALgFuAAADlXeAAAG2sYAAA+u+gAD0P/SAAAVKOIAAAmBqAAACCAqQ Date: Mon, 6 Jul 2015 16:33:45 +0000 Message-ID: References: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> <55928DB3.7090300@gmail.com> <5593C270.7000008@gmail.com> <5593DA7D.80401@mit.edu> <5593E5FD.3050403@gmail.com> <559A676F.3070008@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ve7jtb.com; dkim=none (message not signed) header.d=none; x-originating-ip: [50.47.90.173] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:hb/4EFkz2nWzEn2SNmXn6Pa3Zq4D6YIZXG0mFZ4TqyCnaa1UP/2rNavpbIjANHrKhZGO1oPrd509STqQqsv+tvc6Ibwcv3aF5luiY6Ab6uAn23KD5lCq5/AcW8r/TlUNtnEU4moSuQIsqhe+9wIrJQ==; 24:IJ3seRQVtJxvy41a3tDsdDcRmkM/V4RqoWqMO0O1T4yBPJVjk6RPlOYcd1r8ipunQJ5lAFb9FqL5DjvD20A94oF1BqcYOm8qhW0i/Oqqpg0=; 20:aPyNBX64EGbq7qAvye1fwAYMPTJb2wegXjOFjhKWEkG+Su5+ULM/casH1KViKE/3dJLnd8YwJRwCpfl+xiJwjA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; by2pr03mb442: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 06290ECA9D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(69234005)(377454003)(51704005)(53754006)(164054003)(479174004)(3905003)(13464003)(24454002)(86362001)(5001960100002)(2950100001)(5002640100001)(50986999)(54356999)(76176999)(19580405001)(2656002)(189998001)(87936001)(15975445007)(5003600100002)(2900100001)(86612001)(77096005)(93886004)(102836002)(33656002)(76576001)(5001770100001)(92566002)(19580395003)(74316001)(77156002)(62966003)(561944003)(66066001)(122556002)(99286002)(46102003)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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 Jul 2015 16:33:45.7437 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 16:34:21 -0000 SXQgd291bGQgc3VycHJpc2UgbWUgaWYgb24tYmVoYWxmLW9mIGFuZCBhY3QtYXMgd2VyZSByZXZl cnNlZCB3aXRoIHJlc3BlY3QgV1MtVHJ1c3QsIGJlY2F1c2UgdGhlIGV4cGxhbmF0aW9ucyBvZiB0 aGUgdGVybXMgY2FtZSBkaXJlY3RseSBmcm9tIFdTLVRydXN0IDEuNC4gIEkgYWxzbyB0aGluayB0 aGUgY2hhbmNlcyBvZiB1cyByZWR1Y2luZyBjb25mdXNpb24gYnkgaW52ZW50aW5nIG5ldyB0ZXJt aW5vbG9neSwgcmF0aGVyIHRoYW4gYWRkaW5nIHRvIGl0LCB3b3VsZCBub3QgYmUgaW4gb3VyIGZh dm9yLiA6LS8NCg0KRllJLCB0aGUgYWN0aW9uIGl0ZW1zIG91dHN0YW5kaW5nIGZyb20gb3VyIGFk LWhvYyBtZWV0aW5nIG9uIHRoaXMgZHJhZnQgaW4gRGFsbGFzIGFyZToNCiAgLSBBbGxvd2luZyBz ZWN1cml0eSB0eXBlcyBvdGhlciB0aGFuIEpXVCB0byBhbHNvIGJlIHVzZWQgYXMgdGhlIGFjdF9h cyBhbmQgb25fYmVoYWxmX29mIHJlcXVlc3QgdmFsdWVzLg0KICAtIEZ1cnRoZXIgaW50ZWdyYXRp bmcgdGhlIG1lY2hhbmlzbSBpbnRvIHRoZSBleGlzdGluZyBPQXV0aCBlY29zeXN0ZW0gLSBhbGxv d2luZyB1c2Ugb2YgYWNjZXNzIHRva2VucyBvciByZWZyZXNoIHRva2VucyB3aGVuIGFwcHJvcHJp YXRlLg0KDQpJIHBsYW4gdG8gZG8gdGhlIGZpcnN0IHRvZGF5LiAgVGhlIHNlY29uZCBpcyBwcm9i YWJseSBtb3JlIHRoYW4gSSdsbCBnZXQgZG9uZSB0b2RheSBiZWZvcmUgdGhlIHN1Ym1pc3Npb24g Y3V0b2ZmLiAgSSBhZ3JlZSB3aXRoIEpvaG4gdGhhdCBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gaGF2 ZSBkaXNjdXNzaW9ucyBvbiB0aGlzIGluIFByYWd1ZSBvbiB0aGUgYmVzdCB3YXkgdG8gYWNoaWV2 ZSB0aGlzIGZ1cnRoZXIgaW50ZWdyYXRpb24uICBJJ2xsIHBsYW4gdG8gY29tZSBpbnRvIHRoZSBQ cmFndWUgbWVldGluZyB3aXRoIGEgY29uY3JldGUgcHJvcG9zYWwgZm9yIHJldmlldy4NCg0KCQkJ CUJlc3Qgd2lzaGVzLA0KCQkJCS0tIE1pa2UNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEpvaG4gQnJhZGxleQ0KU2VudDogTW9uZGF5LCBKdWx5IDA2LCAyMDE1IDg6MTMgQU0NClRvOiBC cmlhbiBDYW1wYmVsbA0KQ2M6IG9hdXRoDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBKV1QgVG9r ZW4gb24tYmVoYWxmIG9mIFVzZSBjYXNlDQoNClllcyB1bmZvcnR1bmF0ZWx5IHdlIGhhdmVu4oCZ dCBtYWRlIGFueSBwcm9ncmVzcyBvbiB0aGlzIHNpbmNlIGFjY2VwdGluZyBNaWtl4oCZcyBmaXJz dCBkcmFmdC4NCiANCkhpcyBwcm9wb3NhbCBpcyBiYXNpY2FsbHkgZm9yIGEgbmV3IGVuZHBvaW50 IHdoaWxlIEJyaWFuIHRpcmVkIHRvIGZpdCBpdCBpbnRvIHRoZSBleGlzdGluZyB0b2tlbiBlbmRw b2ludC4NCg0KSSB0aGluayBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTAxIHN0aWxs IGhhcyBPbkJlaGFsZk9mIGFuZCBBY3RBcyByZXZlcnNlZCBjb21wYXJlZCB0byBXUy1UcnVzdCAx LjQuDQpzZWUgaHR0cHM6Ly9tc2RuLm1pY3Jvc29mdC5jb20vZW4tdXMvbGlicmFyeS9lZTc0ODQ4 Ny5hc3B4IGZvciB0aGUgc2hvcnQgZXhwbGFuYXRpb24uDQoNCkkgdGhpbmsgQnJpYW4gaXMgY2xv c2VyIGluIGV4cGxhaW5pbmcgaXQuDQoNCkluIGZhaXJuZXNzIGJlY2F1c2UgV1MtVHJ1c3Qgb3Jp Z2luYWxseSBvbmx5IGhhZCBPbi1CZWhhbGYtT2YgdGhlIG5hbWluZyBhbmQgd2hhdCBwZW9wbGUg cHV0IGluIHRva2VucyBpcyBhIGJpdCBtdWRkbGVkIGluIG1hbnkgaW1wbGVtZW50YXRpb25zLg0K SSB0aGluayBtYW55IHRpbWVzIGl0IGlzIGhvdyBXSUYgaW1wbGVtZW50ZWQgaXQgdGhhdCBwZW9w bGUgY29waWVkLg0KDQpJdCBtYXkgYmUgYmV0dGVyIHRvIGhhdmUgbmV3IHRlcm1zIHRoYXQgYXJl IGNsZWFyIHN1Y2ggYXMgaW1wZXJzb25hdGlvbiBhbmQgY29tcG9zaXRlLg0KDQpUaGUgV0cgbmVl ZHMgdG8gZGVjaWRlIGlmIHRoaXMgaXMgZ29pbmcgdG8gYmUgYW4gZW50aXJlbHkgbmV3IGVuZHBv aW50LCBmcmVlIG9mIHRoZSBUb2tlbiBlbmRwb2ludCBzZW1hbnRpY3MuICAgVGhlcmUgYXJlIHBs dXNzZXMgYW5kIG1pbnVzZXMgdG8gYm90aCBvcHRpb25zLg0KDQpBbHNvIHdoaWxlIGl0IGlzIG5p Y2UgdG8gYmUgcHVyZSBhbmQgdGFsayBhYm91dCBhYnN0cmFjdCBzZWN1cml0eSB0b2tlbnMsIGl0 IHdvdWxkIGJlIGdvb2QgdG8gZ2l2ZSBzb21lIGd1aWRhbmNlIG9uIHdoYXQgYSBjb21wb3NpdGUg c2VjdXJpdHkgdG9rZW4gd291bGQgbG9vayBsaWtlIGZvciBpbnRlcm9wZXJhYmlsaXR5Lg0KDQpU aGVyZSBhcmUgYWxzbyBpc3N1ZXMgYXJvdW5kIGhvdyB0aGlzIHdvdWxkIHdvcmsgd2l0aCBwcm9v ZiBvZiBwb3NzZXNzaW9uIHNlY3VyaXR5IHRva2VucywgYm90aCBhcyBpbnB1dCBhbmQgb3V0cHV0 Lg0KDQpQZXJoYXBzIHdlIGNhbiBtYWtlIHNvbWUgcHJvZ3Jlc3Mgb24gdGhpcyBpbiBQcmFndWUu DQoNCkpvaG4gQi4NCg0KDQoNCiANCj4gT24gSnVsIDYsIDIwMTUsIGF0IDExOjA0IEFNLCBCcmlh biBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+IHdyb3RlOg0KPiANCj4gVGhh bmtzIFNlcmdleSwNCj4gDQo+IFRoZSBnb2FsIG9mIGRyYWZ0LWNhbXBiZWxsLW9hdXRoLXN0cyB3 YXMgdG8gYmUgY29uc2lzdGVudCB3aXRoIE9BdXRoIDIuMCBhbmQgdGh1cyBob3BlZnVsbHkgZmFt aWxpYXIgdG8gZGV2ZWxvcGVycyBhbmQgZWFzeSB0byB1bmRlcnN0YW5kIGFuZCBpbXBsZW1lbnQg KGVzcGVjaWFsbHkgZnJvbSB0aGUgY2xpZW50IHNpZGUpLiBJdCdzIGFsc28gaW50ZW5kZWQgdG8g YmUgZmxleGlibGUgaW4gb3JkZXIgdG8gYWNjb21tb2RhdGUgYSB2YXJpZXR5IG9mIHVzZS1jYXNl cyBpbmNsdWRpbmcgdGhlIGNoYWluaW5nIHR5cGUgY2FzZXMgdGhhdCBKdXN0aW4ncyBkcmFmdCBj b3ZlcnMuIA0KPiANCj4gU3BlY2lmeWluZyBhIHNlY3VyaXR5X3Rva2VuX3R5cGUgb2YgdGhlIHJl dHVybmVkIHRva2VuIGlzIGp1c3QgYSB3YXkgb2YgcHJvdmlkaW5nIG1vcmUgaW5mbyB0byB0aGUg Y2xpZW50IGFib3V0IHRoZSB0b2tlbiAoaS5lLiBpcyB0aGlzIGEgSldUIG9yIGEgU0FNTCB0b2tl biBvciBzb21ldGhpbmcgZWxzZSkgdmlhIGEgVVJJLiBJdCdzIG5vdCBhbHdheXMgbmVlZGVkIGJ1 dCBpbiBTVFMgc3R5bGUgY2FzZXMgdGhlIHRva2VucyBhcmUgbm90IGFsd2F5cyBvcGFxdWUgdG8g dGhlIGNsaWVudCBhbmQgdGhlIHBhcmFtZXRlciBqdXN0IHByb3ZpZGVzIGluZm8gYWJvdXQgdGhl IHJldHVybmVkIHRva2VuLiAgDQo+IA0KPiBPbiBNb24sIEp1bCA2LCAyMDE1IGF0IDU6MzMgQU0s IFNlcmdleSBCZXJ5b3praW4gPHNiZXJ5b3praW5AZ21haWwuY29tPiB3cm90ZToNCj4gSGkgQnJp YW4NCj4gDQo+IEkndmUgcmVhZCB0aGUgdGV4dCwgSSBsaWtlIGl0IGlzIHN0aWxsIHB1cmUgT0F1 dGgyLCB3aXRoIGZldyBleHRyYSBwYXJhbWV0ZXJzIGFkZGVkIHRvIHRoZSBhY2Nlc3MgdG9rZW4g cmVxdWVzdCwgYW5kIGEga2V5IHJlc3BvbnNlIHByb3BlcnR5IGJlaW5nICdhY2Nlc3NfdG9rZW4n IGFzIG9wcG9zZWQgdG8gJ3NlY3VyaXR5X2FjY2Vzc190b2tlbicgYXMgaW4gdGhlIGRyYWZ0LWll dGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMDEuDQo+IEl0IGFwcGVhcnMgZHJhZnQtY2FtcGJlbGwt b2F1dGgtc3RzLTAxIGNhbiBjb3ZlciBhIGRyYWZ0LXJpY2hlci1vYXV0aC1jaGFpbi0wMCBjYXNl IHdpdGggdGhlIG9uX2JlaGFsZl9vZiAoYW5kL29yIGFjdF9hcyA/KSBwcm9wZXJ0eSBiZWluZyBh biBvcmlnaW5hbCBjbGllbnQgdG9rZW4gYnV0IG5vdCAxMDAlIHN1cmUgZ2l2ZW4gZHJhZnQtcmlj aGVyLW9hdXRoLWNoYWluLTAwIGNvdmVycyBhIHNwZWNpZmljIGNhc2UuDQo+IA0KPiBPbmUgdGhp bmcgSSdtIG5vdCBzdXJlIGFib3V0IGlzIHdoYXQgaXMgdGhlIHB1cnBvc2Ugb2Ygc3BlY2lmeWlu ZyBhIA0KPiBzZWN1cml0eV90b2tlbl90eXBlIG9mIHRoZSByZXR1cm5lZCBhY2Nlc3MgdG9rZW4N Cj4gDQo+IFRoYW5rcywgU2VyZ2V5DQo+IA0KPiBPbiAwMS8wNy8xNSAxNTo1OSwgQnJpYW4gQ2Ft cGJlbGwgd3JvdGU6DQo+IE9uZSBwcm9ibGVtLCBJIHRoaW5rLCB3aXRoIHRva2VuIGV4Y2hhbmdl IGlzIHRoYXQgaXQgY2FuIGJlIHJlYWxseSANCj4gc2ltcGxlICh0b2tlbiBpbiBhbmQgdG9rZW4g b3V0KSBhbmQgcmVhbGx5IGNvbXBsaWNhdGVkIChjbGllbnQgWCB3YW50cyANCj4gYSB0b2tlbiB0 aGF0IHNheXMgdXNlciBBIGlzIGRvaW5nIHNvbWV0aGluZyBvbiBiZWhhbGYgb2YgdXNlciBCKSBh dCANCj4gdGhlIHNhbWUgdGltZS4NCj4gDQo+IEkgcHV0IGZvcnRoIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1jYW1wYmVsbC1vYXV0aC1zdHMtMDEgaW4gDQo+IGFuIGF0dGVtcHQg dG8gc2ltcGxpZnkgdGhpbmdzIGFuZCBleHByZXNzIHdoYXQgSSBlbnZpc2lvbmVkIGFzIGFuIA0K PiBPQXV0aCBiYXNlZCB0b2tlbiBleGNoYW5nZSBmcmFtZXdvcmsuIFRob3VnaCBpdCBsaWtlbHkg b25seSBtdWRkaWVkIA0KPiB0aGUgd2F0ZXJzIDopDQo+IA0KPiBPbiBXZWQsIEp1bCAxLCAyMDE1 IGF0IDc6MDcgQU0sIFNlcmdleSBCZXJ5b3praW4gPHNiZXJ5b3praW5AZ21haWwuY29tIA0KPiA8 bWFpbHRvOnNiZXJ5b3praW5AZ21haWwuY29tPj4gd3JvdGU6DQo+IA0KPiAgICAgSGkgSnVzdGlu DQo+IA0KPiAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJpY2hlci1vYXV0 aC1jaGFpbi0wMCBpcyBtdWNoDQo+ICAgICBlYXNpZXIgdG8gcmVhZCwgdGhhdCBJIGNhbiB0ZWxs IGZvciBzdXJlLCBhdCBsZWFzdCBpdCBpcyBvYnZpb3VzIHdoeQ0KPiAgICAgYSBnaXZlbiBlbnRp dHkgKFJTMSkgbWF5IHdhbnQgdG8gZXhjaGFuZ2UgdGhlIGN1cnJlbnQgdG9rZW4gcHJvdmlkZWQN Cj4gICAgIGJ5IGEgY2xpZW50IGZvciBhIG5ldyB0b2tlbi4gRGVmaW5pdGVseSBlYXNpbHkgaW1w bGVtZW50YWJsZS4uLg0KPiANCj4gICAgIE9uZSB0aGluZyBJJ20gbm90IHN1cmUgaW4gdGhlIGRy YWZ0LXJpY2hlci1vYXV0aC1jaGFpbi0wMCBhYm91dCBpcw0KPiAgICAgb24gYmVoYWxmIG9mIHdo b3NlIGVudGl0eSBSUzEgd2lsbCBiZSBhY3Rpbmcgb25jZSBpdCBzdGFydHMNCj4gICAgIGFjY2Vz c2luZyBSUzIsIE9uIEJlaGFsZiBPZiBSTywgb3IgbWF5IGJlIE9uIEJlaGFsZiBPZiAoUk8gKw0K PiAgICAgQ2xpZW50KSwgb3IgbWF5IGJlIGl0IGlzIE9uIEJlaGFsZiBPZiBSTyArIEFjdCBBcyBD bGllbnQgPyBUaGUgbGFzdA0KPiAgICAgb25lIHNlZW1zIG1vc3QgbG9naWNhbCB0byBtZS4uLg0K PiANCj4gICAgIFRoYW5rcywgU2VyZ2V5DQo+IA0KPiANCj4gICAgIE9uIDAxLzA3LzE1IDEzOjE4 LCBKdXN0aW4gUmljaGVyIHdyb3RlOg0KPiANCj4gICAgICAgICBBcyBpdCdzIHdyaXR0ZW4gcmln aHQgbm93LCBpdCdzIGEgdHJhbnNsYXRpb24gb2Ygc29tZSBXUy0qDQo+ICAgICAgICAgY29uY2Vw dHMgaW50bw0KPiAgICAgICAgIEpXVCBmb3JtYXQuIEl0J3Mgbm90IHJlYWxseSBPQXV0aC15IChz aW5jZSB0aGUgY2xpZW50IGhhcyB0bw0KPiAgICAgICAgIHVuZGVyc3RhbmQNCj4gICAgICAgICB0 aGUgdG9rZW4gZm9ybWF0IGFsb25nIHdpdGggZXZlcnlvbmUgZWxzZSwgYW5kIGFjY29yZGluZyB0 byB0aGUNCj4gICAgICAgICBhdXRob3JzDQo+ICAgICAgICAgdGhlIGFydGlmYWN0cyBtaWdodCBu b3QgZXZlbiBiZSAiT0F1dGggdG9rZW5zIiksIGFuZCB0aGF0J3MgbXkgbWFpbg0KPiAgICAgICAg IGlzc3VlIHdpdGggdGhlIGRvY3VtZW50LiBZZWFycyBhZ28sIEkgcHJvcG9zZWQgYW4gT0F1dGgt YmFzZWQNCj4gICAgICAgICB0b2tlbiBzd2FwDQo+ICAgICAgICAgbWVjaGFuaXNtOg0KPiANCj4g ICAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmljaGVyLW9hdXRoLWNo YWluLTAwDQo+IA0KPiAgICAgICAgIFRoaXMgd29ya3Mgd2l0aG91dCBkZWZpbmluZyBzZW1hbnRp Y3Mgb2YgdGhlIHRva2VucyB0aGVtc2VsdmVzLCBqdXN0DQo+ICAgICAgICAgbGlrZSB0aGUgcmVz dCBvZiBPQXV0aC4gSSd2ZSBwcm9wb3NlZCB0byB0aGUgYXV0aG9ycyBvZiB0aGUgY3VycmVudA0K PiAgICAgICAgIGRyYWZ0IHRoYXQgaXQgc2hvdWxkIGluY29ycG9yYXRlIGJvdGggc2VtYW50aWMg KHVzaW5nIEpXVCkgYW5kDQo+ICAgICAgICAgc3ludGFjdGljDQo+ICAgICAgICAgKHVzaW5nIGEg c2ltcGxlIHRva2VuLWFnbm9zdGljIGdyYW50KSB0b2tlbiBzd2FwIG1lY2hhbmlzbXMsIGFuZA0K PiAgICAgICAgIHRoYXQNCj4gICAgICAgICB0aGUgdHdvIGNvdWxkIGJlIGVhc2lseSBjb21wYXRp YmxlLg0KPiANCj4gICAgICAgICAgICAtLSBKdXN0aW4NCj4gDQo+ICAgICAgICAgT24gNy8xLzIw MTUgNjozNSBBTSwgU2VyZ2V5IEJlcnlvemtpbiB3cm90ZToNCj4gDQo+ICAgICAgICAgICAgIEht bS4uLiBwZXJoYXBzIHRoZSBjbHVlIGlzIGluIHRoZSBkcmFmdCB0aXRsZSwNCj4gICAgICAgICAg ICAgdG9rZW4tZXhjaGFuZ2UsIHNvIG1heQ0KPiAgICAgICAgICAgICBiZSBpdCBpcyBhIGNhc2Ug b2YgdGhlIGdpdmVuIGFjY2VzcyB0b2tlbiAoIm9uX2JlaGFsZl9vZiIgb3INCj4gICAgICAgICAg ICAgImFjdF9hcyINCj4gICAgICAgICAgICAgY2xhaW0pIGJlaW5nIHVzZWQgdG8gcmVxdWVzdCBh IG5ldyBzZWN1cml0eSB0b2tlbi4gT25lIGNhbg0KPiAgICAgICAgICAgICBvbmx5IGd1ZXNzDQo+ ICAgICAgICAgICAgIHRob3VnaCwgZG9lcyBub3Qgc2VlbSBsaWtlIHRoZSBhdXRob3JzIGFyZSBr ZWVuIHRvIGFuc3dlcg0KPiAgICAgICAgICAgICB0aGUgbmV3YmllDQo+ICAgICAgICAgICAgIHF1 ZXN0aW9ucy4uLg0KPiANCj4gICAgICAgICAgICAgQ2hlZXJzLCBTZXJnZXkNCj4gDQo+IA0KPiAg ICAgICAgICAgICBPbiAzMC8wNi8xNSAxMzozOCwgU2VyZ2V5IEJlcnlvemtpbiB3cm90ZToNCj4g DQo+ICAgICAgICAgICAgICAgICBIaSwNCj4gICAgICAgICAgICAgICAgIENhbiB5b3UgcGxlYXNl IGV4cGxhaW4gd2hhdCBpcyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuDQo+ICAgICAgICAgICAgICAg ICBPbi1CZWhhbGYtT2YNCj4gICAgICAgICAgICAgICAgIHNlbWFudGljcyBkZXNjcmliZWQgaW4g dGhlDQo+ICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTAx IGFuZCB0aGUNCj4gICAgICAgICAgICAgICAgIGltcGxpY2l0IE9uLUJlaGFsZi1PZiBzZW1hbnRp Y3MgYSBjbGllbnQgT0F1dGgyIHRva2VuDQo+ICAgICAgICAgICAgICAgICBwb3NzZXNzZXMgPw0K PiANCj4gICAgICAgICAgICAgICAgIEZvciBleGFtcGxlLCBkcmFmdC1pZXRmLW9hdXRoLXRva2Vu LWV4Y2hhbmdlLTAxIG1lbnRpb25zOg0KPiANCj4gICAgICAgICAgICAgICAgICJXaGVyZWFzLCB3 aXRoIG9uLWJlaGFsZi1vZiBzZW1hbnRpY3MsIHByaW5jaXBhbCBBIHN0aWxsDQo+ICAgICAgICAg ICAgICAgICBoYXMgaXRzIG93bg0KPiAgICAgICAgICAgICAgICAgaWRlbnRpdHkgc2VwYXJhdGUg ZnJvbSBCIGFuZCBpdCBpcyBleHBsaWNpdGx5IHVuZGVyc3Rvb2QNCj4gICAgICAgICAgICAgICAg IHRoYXQgd2hpbGUgQg0KPiAgICAgICAgICAgICAgICAgbWF5IGhhdmUgZGVsZWdhdGVkIGl0cyBy aWdodHMgdG8gQSwgYW55IGFjdGlvbnMgdGFrZW4NCj4gICAgICAgICAgICAgICAgIGFyZSBiZWlu ZyB0YWtlbiBieQ0KPiAgICAgICAgICAgICAgICAgQSBhbmQgbm90IEIuIEluIGEgc2Vuc2UsIEEg aXMgYW4gYWdlbnQgZm9yIEIuIg0KPiANCj4gICAgICAgICAgICAgICAgIFRoaXMgaXMgYSB0eXBp Y2FsIGNhc2Ugd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGZsb3cNCj4gICAgICAgICAgICAg ICAgIHdoZXJlIGEgY2xpZW50DQo+ICAgICAgICAgICAgICAgICBhcHBsaWNhdGlvbiBhY3RzIG9u LWJlaGFsZi1vZiB0aGUgdXNlciB3aG8gYXV0aG9yaXplZA0KPiAgICAgICAgICAgICAgICAgdGhp cyBhcHBsaWNhdGlvbiA/DQo+IA0KPiAgICAgICAgICAgICAgICAgU29ycnkgaWYgSSdtIG1pc3Np bmcgc29tZXRoaW5nDQo+IA0KPiAgICAgICAgICAgICAgICAgQ2hlZXJzLCBTZXJnZXkNCj4gICAg ICAgICAgICAgICAgIE9uIDI1LzA2LzE1IDIyOjI4LCBNaWtlIEpvbmVzIHdyb3RlOg0KPiANCj4g ICAgICAgICAgICAgICAgICAgICBUaGF04oCZcyB3aGF0DQo+ICAgICAgICAgICAgICAgICAgICAg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFu Z2UtMDENCj4gICAgICAgICAgICAgICAgICAgICBpcw0KPiAgICAgICAgICAgICAgICAgICAgIGFi b3V0Lg0KPiANCj4gICAgICAgICAgICAgICAgICAgICBDaGVlcnMsDQo+IA0KPiAgICAgICAgICAg ICAgICAgICAgIC0tIE1pa2UNCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgKkZyb206Kk9BdXRo IFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZw0KPiAgICAgICAgICAgICAgICAgICAgIDxt YWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz5dICpPbiBCZWhhbGYgT2YgKlZpdmVrDQo+ICAg ICAgICAgICAgICAgICAgICAgQmlzd2FzDQo+ICAgICAgICAgICAgICAgICAgICAgLVQgKHZpYmlz d2FzIC0gWE9SSUFOVCBDT1JQT1JBVElPTiBhdCBDaXNjbykNCj4gICAgICAgICAgICAgICAgICAg ICAqU2VudDoqIFRodXJzZGF5LCBKdW5lIDI1LCAyMDE1IDI6MjAgUE0NCj4gICAgICAgICAgICAg ICAgICAgICAqVG86KiBPQXV0aEBpZXRmLm9yZyA8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPiAg ICAgICAgICAgICAgICAgICAgICpTdWJqZWN0OiogW09BVVRILVdHXSBKV1QgVG9rZW4gb24tYmVo YWxmIG9mIFVzZSANCj4gY2FzZQ0KPiANCj4gICAgICAgICAgICAgICAgICAgICBIaSBBbGwsDQo+ IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICBJIGFtIGxvb2tpbmcgdG8gc29sdmUgYSB1c2Ut Y2FzZSBzaW1pbGFyIHRvDQo+ICAgICAgICAgICAgICAgICAgICAgV1MtU2VjdXJpdHkgT24tQmVo YWxmLU9mDQo+ICAgICAgICAgICAgICAgICAgICAgDQo+IDxodHRwOi8vZG9jcy5vYXNpcy1vcGVu Lm9yZy93cy1zeC93cy10cnVzdC92MS40L2VycmF0YTAxL29zL3dzLXRydXN0LTENCj4gLjQtZXJy YXRhMDEtb3MtY29tcGxldGUuaHRtbCNfVG9jMzI1NjU4OTgwPg0KPiANCj4gDQo+ICAgICAgICAg ICAgICAgICAgICAgd2l0aCBPQXV0aCBKV1QgVG9rZW4uDQo+IA0KPiAgICAgICAgICAgICAgICAg ICAgICAgICBJcyB0aGVyZSBhIHN0YW5kYXJkIGNsYWltIHdoaWNoIHdlIGNhbiBkZWZpbmUNCj4g ICAgICAgICAgICAgICAgICAgICB3aXRoaW4gdGhlIE9BdXRoIEpXVA0KPiAgICAgICAgICAgICAg ICAgICAgIHdoaWNoIGRlbm90ZSB0aGUgT24tYmVoYWxmLW9mIFVzZXIuDQo+IA0KPiAgICAgICAg ICAgICAgICAgICAgIEZvciBlLmcuLCBhIEN1c3RvbWVyIFJlcHJlc2VudGF0aXZlIHRyeWluZyB0 byBjcmVhdGUNCj4gICAgICAgICAgICAgICAgICAgICB0b2tlbiBvbiBiZWhhbGYgb2YNCj4gICAg ICAgICAgICAgICAgICAgICBhIGN1c3RvbWVyIGFuZCB0cnlpbmcgdG8gZXhlY3V0ZSBzZXJ2aWNl cyBzcGVjaWZpYw0KPiAgICAgICAgICAgICAgICAgICAgIGZvciB0aGF0IHNwZWNpZmljDQo+ICAg ICAgICAgICAgICAgICAgICAgY3VzdG9tZXIuDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgIFJl Z2FyZHMsDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgIFZpdmVrIEJpc3dhcywNCj4gICAgICAg ICAgICAgICAgICAgICBDSVNTUA0KPiANCj4gICAgICAgICAgICAgICAgICAgICAqQ2lzY28gU3lz dGVtcywgSW5jIDxodHRwOi8vd3d3LmNpc2NvLmNvbS8+Kg0KPiANCj4gICAgICAgICAgICAgICAg ICAgICAqQmxkZy4gSiwgU2FuIEpvc2UsIFVTQSwqDQo+IA0KPiAgICAgICAgICAgICAgICAgICAg ICpQaG9uZTogKzEgNDA4IDUyNyA5MTc2IA0KPiA8dGVsOiUyQjElMjA0MDglMjA1MjclMjA5MTc2 PioNCj4gDQo+IA0KPiANCj4gICAgICAgICAgICAgICAgICAgICBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAgICAgICAgICAgICAgICAgIE9BdXRo IG1haWxpbmcgbGlzdA0KPiAgICAgICAgICAgICAgICAgICAgIE9BdXRoQGlldGYub3JnIDxtYWls dG86T0F1dGhAaWV0Zi5vcmc+DQo+ICAgICAgICAgICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPiANCj4gDQo+IA0KPiAgICAgICAgICAgICBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAgICAg ICAgICBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gICAgICAgICAgICAgT0F1dGhAaWV0Zi5vcmcgPG1h aWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4gICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPiANCj4gDQo+ICAgICAgICAgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gICAgICAgICBPQXV0aCBtYWlsaW5n IGxpc3QNCj4gICAgICAgICBPQXV0aEBpZXRmLm9yZyA8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0K PiAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4g DQo+IA0KPiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gICAgIE9BdXRoIG1haWxpbmcgbGlzdA0KPiAgICAgT0F1dGhAaWV0Zi5vcmcgPG1haWx0 bzpPQXV0aEBpZXRmLm9yZz4NCj4gICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGgNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gT0F1dGhA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGgg bWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aA0K From nobody Mon Jul 6 10:01:51 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 130661ACCFF for ; Mon, 6 Jul 2015 10:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zofIdPu-Qbp for ; Mon, 6 Jul 2015 10:01:47 -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 67AA61B2FE5 for ; Mon, 6 Jul 2015 10:01:45 -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 t66H1i3K027724 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Jul 2015 17:01:44 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 t66H1iwG001360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Jul 2015 17:01:44 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t66H1ho9022818; Mon, 6 Jul 2015 17:01:43 GMT Received: from [192.168.1.9] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 06 Jul 2015 10:01:43 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Phil Hunt In-Reply-To: Date: Mon, 6 Jul 2015 10:01:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6A185D74-5E9E-4A01-BD1D-BAF44591F448@oracle.com> References: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> <55928DB3.7090300@gmail.com> <5593C270.7000008@gmail.com> <5593DA7D.80401@mit.edu> <5593E5FD.3050403@gmail.com> <559A676F.3070008@gmail.com> To: John Bradley X-Mailer: Apple Mail (2.2102) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 17:01:50 -0000 I agree. Changing the terms helps get us out of the perpetual confusion = around ActAs and OnBehalfOf. I like the idea of =E2=80=9Cimpersonation=E2=80=9D and =E2=80=9Ccomposite=E2= =80=9D instead. Phil @independentid www.independentid.com phil.hunt@oracle.com > On Jul 6, 2015, at 8:12 AM, John Bradley wrote: >=20 > Yes unfortunately we haven=E2=80=99t made any progress on this since = accepting Mike=E2=80=99s first draft. >=20 > His proposal is basically for a new endpoint while Brian tired to fit = it into the existing token endpoint. >=20 > I think draft-ietf-oauth-token-exchange-01 still has OnBehalfOf and = ActAs reversed compared to WS-Trust 1.4. > see https://msdn.microsoft.com/en-us/library/ee748487.aspx for the = short explanation. >=20 > I think Brian is closer in explaining it. >=20 > In fairness because WS-Trust originally only had On-Behalf-Of the = naming and what people put in tokens is a bit muddled in many = implementations. > I think many times it is how WIF implemented it that people copied. >=20 > It may be better to have new terms that are clear such as = impersonation and composite. >=20 > The WG needs to decide if this is going to be an entirely new = endpoint, free of the Token endpoint semantics. There are plusses and = minuses to both options. >=20 > Also while it is nice to be pure and talk about abstract security = tokens, it would be good to give some guidance on what a composite = security token would look like for interoperability. >=20 > There are also issues around how this would work with proof of = possession security tokens, both as input and output. >=20 > Perhaps we can make some progress on this in Prague. >=20 > John B. >=20 >=20 >=20 >=20 >> On Jul 6, 2015, at 11:04 AM, Brian Campbell = wrote: >>=20 >> Thanks Sergey,=20 >>=20 >> The goal of draft-campbell-oauth-sts was to be consistent with OAuth = 2.0 and thus hopefully familiar to developers and easy to understand and = implement (especially from the client side). It's also intended to be = flexible in order to accommodate a variety of use-cases including the = chaining type cases that Justin's draft covers.=20 >>=20 >> Specifying a security_token_type of the returned token is just a way = of providing more info to the client about the token (i.e. is this a JWT = or a SAML token or something else) via a URI. It's not always needed but = in STS style cases the tokens are not always opaque to the client and = the parameter just provides info about the returned token. =20 >>=20 >> On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin = wrote: >> Hi Brian >>=20 >> I've read the text, I like it is still pure OAuth2, with few extra = parameters added to the access token request, and a key response = property being 'access_token' as opposed to 'security_access_token' as = in the draft-ietf-oauth-token-exchange-01. >> It appears draft-campbell-oauth-sts-01 can cover a = draft-richer-oauth-chain-00 case with the on_behalf_of (and/or act_as ?) = property being an original client token but not 100% sure given = draft-richer-oauth-chain-00 covers a specific case. >>=20 >> One thing I'm not sure about is what is the purpose of specifying a = security_token_type of the returned access token >>=20 >> Thanks, Sergey >>=20 >> On 01/07/15 15:59, Brian Campbell wrote: >> One problem, I think, with token exchange is that it can be really >> simple (token in and token out) and really complicated (client X = wants a >> token that says user A is doing something on behalf of user B) at the >> same time. >>=20 >> I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 = in >> an attempt to simplify things and express what I envisioned as an = OAuth >> based token exchange framework. Though it likely only muddied the = waters :) >>=20 >> On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin = > > wrote: >>=20 >> Hi Justin >>=20 >> https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much >> easier to read, that I can tell for sure, at least it is obvious = why >> a given entity (RS1) may want to exchange the current token = provided >> by a client for a new token. Definitely easily implementable... >>=20 >> One thing I'm not sure in the draft-richer-oauth-chain-00 about is >> on behalf of whose entity RS1 will be acting once it starts >> accessing RS2, On Behalf Of RO, or may be On Behalf Of (RO + >> Client), or may be it is On Behalf Of RO + Act As Client ? The = last >> one seems most logical to me... >>=20 >> Thanks, Sergey >>=20 >>=20 >> On 01/07/15 13:18, Justin Richer wrote: >>=20 >> As it's written right now, it's a translation of some WS-* >> concepts into >> JWT format. It's not really OAuth-y (since the client has to >> understand >> the token format along with everyone else, and according to = the >> authors >> the artifacts might not even be "OAuth tokens"), and that's my = main >> issue with the document. Years ago, I proposed an OAuth-based >> token swap >> mechanism: >>=20 >> https://tools.ietf.org/html/draft-richer-oauth-chain-00 >>=20 >> This works without defining semantics of the tokens = themselves, just >> like the rest of OAuth. I've proposed to the authors of the = current >> draft that it should incorporate both semantic (using JWT) and >> syntactic >> (using a simple token-agnostic grant) token swap mechanisms, = and >> that >> the two could be easily compatible. >>=20 >> -- Justin >>=20 >> On 7/1/2015 6:35 AM, Sergey Beryozkin wrote: >>=20 >> Hmm... perhaps the clue is in the draft title, >> token-exchange, so may >> be it is a case of the given access token ("on_behalf_of" = or >> "act_as" >> claim) being used to request a new security token. One can >> only guess >> though, does not seem like the authors are keen to answer >> the newbie >> questions... >>=20 >> Cheers, Sergey >>=20 >>=20 >> On 30/06/15 13:38, Sergey Beryozkin wrote: >>=20 >> Hi, >> Can you please explain what is the difference between >> On-Behalf-Of >> semantics described in the >> draft-ietf-oauth-token-exchange-01 and the >> implicit On-Behalf-Of semantics a client OAuth2 token >> possesses ? >>=20 >> For example, draft-ietf-oauth-token-exchange-01 = mentions: >>=20 >> "Whereas, with on-behalf-of semantics, principal A = still >> has its own >> identity separate from B and it is explicitly = understood >> that while B >> may have delegated its rights to A, any actions taken >> are being taken by >> A and not B. In a sense, A is an agent for B." >>=20 >> This is a typical case with the authorization code = flow >> where a client >> application acts on-behalf-of the user who authorized >> this application ? >>=20 >> Sorry if I'm missing something >>=20 >> Cheers, Sergey >> On 25/06/15 22:28, Mike Jones wrote: >>=20 >> That=E2=80=99s what >> = https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 >> is >> about. >>=20 >> Cheers, >>=20 >> -- Mike >>=20 >> *From:*OAuth [mailto:oauth-bounces@ietf.org >> ] *On Behalf Of = *Vivek >> Biswas >> -T (vibiswas - XORIANT CORPORATION at Cisco) >> *Sent:* Thursday, June 25, 2015 2:20 PM >> *To:* OAuth@ietf.org >> *Subject:* [OAUTH-WG] JWT Token on-behalf of Use = case >>=20 >> Hi All, >>=20 >> I am looking to solve a use-case similar to >> WS-Security On-Behalf-Of >> = >>=20 >>=20 >> with OAuth JWT Token. >>=20 >> Is there a standard claim which we can define >> within the OAuth JWT >> which denote the On-behalf-of User. >>=20 >> For e.g., a Customer Representative trying to = create >> token on behalf of >> a customer and trying to execute services specific >> for that specific >> customer. >>=20 >> Regards, >>=20 >> Vivek Biswas, >> CISSP >>=20 >> *Cisco Systems, Inc * >>=20 >> *Bldg. J, San Jose, USA,* >>=20 >> *Phone: +1 408 527 9176 = * >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Jul 6 11:18:05 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5759C1A8706 for ; Mon, 6 Jul 2015 11:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKBfN5XHVM8h for ; Mon, 6 Jul 2015 11:18:02 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0109.outbound.protection.outlook.com [65.55.169.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 519851A8713 for ; Mon, 6 Jul 2015 11:18:02 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.213.10; Mon, 6 Jul 2015 18:18:00 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0213.000; Mon, 6 Jul 2015 18:18:00 +0000 From: Mike Jones To: Nat Sakimura , John Bradley Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-03.txt Thread-Index: AQHQt/431rtX+zHoI0OmuS1pCHHqmZ3Ov1kg Date: Mon, 6 Jul 2015 18:18:00 +0000 Message-ID: References: <20150706151148.24135.26125.idtracker@ietfa.amsl.com> In-Reply-To: <20150706151148.24135.26125.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sakimura.org; dkim=none (message not signed) header.d=none; x-originating-ip: [50.47.90.173] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:kbB8rydN4zAmmdd3GFUQOBifOCJjeWShZPtWw0uz8qkx3KQevfc5V0xNJUUCenPwx1LGbl9PJxBKcWI2HpeBvKqdLDsTqIzVblmrYyUxG/jOR9iKI2ggZd+Y00EmfIzBJ8J2empMMC8LEzcq+1baXw==; 24:SZww/ka0ve/V4o9OVecHRwH6aAqMASp9W9qwoc/3IXpE34KEvKZ2lvPqTLIwRAJv/1E+6x5O4/ApEG5LHwYdQewE27BcofU9e9E9WlfY8OE=; 20:xQ5P+1cu/I7I3uYTgkBbEfLspFemEpwkcsYW8IDaUy+Oyws68jqNCXXaPB1f4kxKWIc71focYzadFzfH/1+FPw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; by2pr03mb441: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 06290ECA9D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377424004)(377454003)(13464003)(164054003)(15975445007)(74316001)(76576001)(46102003)(77156002)(86362001)(87936001)(33656002)(19580395003)(230783001)(19580405001)(122556002)(102836002)(50986999)(2950100001)(40100003)(77096005)(2900100001)(54356999)(62966003)(86612001)(2656002)(76176999)(5002640100001)(189998001)(5003600100002)(92566002)(66066001)(106116001)(5001960100002)(99286002)(5001770100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.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: 06 Jul 2015 18:18:00.3941 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 18:18:04 -0000 The invalid_request_uri parameter has already been registered at http://www= .iana.org/assignments/oauth-parameters/oauth-parameters.xhtml by OpenID Con= nect Core, and so cannot be re-registered. invalid_request_format looks like a duplicate of the already registered inv= alid_request_object parameter. Please change to use the existing error nam= e. Please also try to reconcile invalid_request_params with existing JWS reque= st usage already specified by OpenID Connect Core. Thanks, -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of internet-drafts@ie= tf.org Sent: Monday, July 06, 2015 8:12 AM To: i-d-announce@ietf.org Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Group = of the IETF. Title : Request by JWS ver.1.0 for OAuth 2.0 Authors : Nat Sakimura John Bradley Filename : draft-ietf-oauth-jwsreq-03.txt Pages : 10 Date : 2015-07-06 Abstract: The authorization request in OAuth 2.0 utilizes query parameter serialization. This specification defines the authorization request using JWT serialization. The request is sent through "request" parameter or by reference through "request_uri" parameter that points to the JWT, allowing the request to be optionally signed and encrypted. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-jwsreq-03 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Jul 6 11:21:40 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A09E1B2C8C for ; Mon, 6 Jul 2015 11:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qb5HGJBJI1W7 for ; Mon, 6 Jul 2015 11:21:32 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0788.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::788]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4F0E1B2C18 for ; Mon, 6 Jul 2015 11:21:15 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.213.10; Mon, 6 Jul 2015 18:20:57 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0213.000; Mon, 6 Jul 2015 18:20:57 +0000 From: Mike Jones To: Nat Sakimura , Kepeng Li Thread-Topic: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-rjwtprof-04.txt Thread-Index: AQHQsh8sLdt+RGFn20CICbaGWE7Zs53OzCaA Date: Mon, 6 Jul 2015 18:20:57 +0000 Message-ID: References: <20150629034750.14270.34911.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-originating-ip: [50.47.90.173] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:pj2jwcVFNSdXRoGOup3rEiURDqsysUlZY/TsqdpXAI7XGu3A4uD8KBX6JZ3kCStVu+xBhzWnczxAACQQIp1aVbSNU6B+dS1sKck+WxVZbdrmQmV7wBsIJNdlPutwEg3HIMQWitZDrJ+hBN6Vy6NUBg==; 24:tnyFQ3nF36XUf+WJyTsK59StkWGTaKkmNlHBWGdPrm8NJ4czKulmbtc1xb66vjywvRoXqplPYGz+YJneOhgkiNdEj9iQtjItgVrmUZchH7A=; 20:MKu86hgSNhG5dCVUbwIfSYWL1GB/AaR/pDJUX5f4ssFhC8rPfl/10Bj/Fu2gxwiifhLvhYkxJ4WjzbMWuJbPWg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; by2pr03mb441: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 06290ECA9D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377424004)(377454003)(2473001)(22974007)(16601075003)(15975445007)(16236675004)(74316001)(76576001)(19609705001)(46102003)(19617315012)(77156002)(19273905006)(19300405004)(86362001)(87936001)(33656002)(19580395003)(230783001)(19580405001)(122556002)(102836002)(50986999)(2950100001)(40100003)(77096005)(2900100001)(54356999)(62966003)(86612001)(2420400003)(19625215002)(2656002)(76176999)(7110500001)(14971765001)(5002640100001)(189998001)(5003600100002)(92566002)(66066001)(106116001)(5001960100002)(99286002)(5001770100001)(563064011); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442168F350E2E051065BC00F5930BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2015 18:20:57.4604 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-rjwtprof-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 18:21:38 -0000 --_000_BY2PR03MB442168F350E2E051065BC00F5930BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGNsYWltIOKAnGF6cOKAnSBoYXMgYWxyZWFkeSBiZWVuIHJlZ2lzdGVyZWQgYnkgT3BlbklE IENvbm5lY3QgQ29yZSBhdCBodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2p3dC9qd3Qu eGh0bWwgYW5kIHNvIGNhbm5vdCBiZSByZS1yZWdpc3RlcmVkLiAgR2l2ZW4gdGhhdCBJIGJlbGll dmUgdGhlIGludGVuZGVkIHNlbWFudGljcyBhcmUgdGhlIHNhbWUsIHBsZWFzZSBjaXRlIHRoZSBl eGlzdGluZyBkZWZpbml0aW9uLCByYXRoZXIgdGhhbiByZXBlYXRpbmcgaXQuDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJlc3Qg d2lzaGVzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBOYXQgU2FraW11cmENClNlbnQ6IFN1bmRheSwgSnVuZSAy OCwgMjAxNSA4OjUzIFBNDQpUbzogb2F1dGg7IG9hdXRoLWNoYWlyc0B0b29scy5pZXRmLm9yZw0K U3ViamVjdDogW09BVVRILVdHXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh ZnQtc2FraW11cmEtb2F1dGgtcmp3dHByb2YtMDQudHh0DQoNCkhpDQoNCktlcGVuZyBhbmQgSSBy ZXYnZWQgdGhpcyBkaXNjdXNzaW9uIGRyYWZ0IHdoaWNoIGRlc2NyaWJlcyBzZW5kZXIgY29uZmly bWF0aW9uIG1ldGhvZA0KdXNpbmcgSldUIGFnYWluc3QgYSByZXNvdXJjZS4NCg0KSXQgaXMgcHJl dHR5IHNob3J0Lg0KDQpEZXJlayBhbmQgSGFubmVzLA0KDQpXZSB3b3VsZCBsaWtlIHRvIGhhdmUg c29tZXRpbWUgaW4gdGhlIE9BdXRoIFdHIHNlc3Npb24gdG8gZGlzY3VzcyBhYm91dCBpdC4NCkkg aG9wZSB5b3UgY2FuIGFsbG9jYXRlIGEgYml0IG9mIHRpbWUgZm9yIGl0Lg0KDQpCZXN0LA0KDQpO YXQNCg0KLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tDQpGcm9tOiA8aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+Pg0K RGF0ZTogMjAxNS0wNi0yOSAxMjo0NyBHTVQrMDk6MDANClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtc2FraW11cmEtb2F1dGgtcmp3dHByb2YtMDQudHh0DQpUbzog S2VwZW5nIExpIDxrZXBlbmcubGtwQGFsaWJhYmEtaW5jLmNvbTxtYWlsdG86a2VwZW5nLmxrcEBh bGliYWJhLWluYy5jb20+PiwgTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb208bWFpbHRv OnNha2ltdXJhQGdtYWlsLmNvbT4+DQoNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQt c2FraW11cmEtb2F1dGgtcmp3dHByb2YtMDQudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3Vi bWl0dGVkIGJ5IE5hdCBTYWtpbXVyYSBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5 Lg0KDQpOYW1lOiAgICAgICAgICAgZHJhZnQtc2FraW11cmEtb2F1dGgtcmp3dHByb2YNClJldmlz aW9uOiAgICAgICAwNA0KVGl0bGU6ICAgICAgICAgIFNlbmRlciBDb25zdHJhaW5lZCBKV1QgZm9y IE9BdXRoIDIuMA0KRG9jdW1lbnQgZGF0ZTogIDIwMTUtMDYtMjkNCkdyb3VwOiAgICAgICAgICBJ bmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgICA2DQpVUkw6ICAgICAgICAgICAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXNha2ltdXJhLW9hdXRo LXJqd3Rwcm9mLTA0LnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LXNha2ltdXJhLW9hdXRoLXJqd3Rwcm9mLw0KSHRtbGl6ZWQ6ICAgICAg IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWtpbXVyYS1vYXV0aC1yand0cHJv Zi0wNA0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k cmFmdC1zYWtpbXVyYS1vYXV0aC1yand0cHJvZi0wNA0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZGlz Y3Vzc2lvbiBkb2N1bWVudCBkZXNjcmliZXMgYSBtZXRob2QgdG8gaW5kaWNhdGUgYSBzZW5kZXIN CiAgIGNvbnN0cmFpbnQgd2l0aGluIEpXVC4gIEl0IGNvdWxkIHBvdGVudGlhbGx5IGJlIGluY29y cG9yYXRlZCBpbnRvDQogICBQT1BTIHNwZWMgW1BPUFNdLg0KDQoNCg0KDQoNClBsZWFzZSBub3Rl IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1 Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFi bGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCg0KVGhlIElFVEYg U2VjcmV0YXJpYXQNCg0KDQoNCi0tDQpOYXQgU2FraW11cmEgKD1uYXQpDQpDaGFpcm1hbiwgT3Bl bklEIEZvdW5kYXRpb24NCmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KQF9uYXRfZW4NCg== --_000_BY2PR03MB442168F350E2E051065BC00F5930BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5UaGUgY2xhaW0g4oCcYXpw4oCdIGhhcyBhbHJlYWR5IGJlZW4gcmVnaXN0ZXJlZCBieSBP cGVuSUQgQ29ubmVjdCBDb3JlIGF0DQo8YSBocmVmPSJodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2ln bm1lbnRzL2p3dC9qd3QueGh0bWwiPmh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvand0 L2p3dC54aHRtbDwvYT4gYW5kIHNvIGNhbm5vdCBiZSByZS1yZWdpc3RlcmVkLiZuYnNwOyBHaXZl biB0aGF0IEkgYmVsaWV2ZSB0aGUgaW50ZW5kZWQgc2VtYW50aWNzIGFyZSB0aGUgc2FtZSwgcGxl YXNlIGNpdGUgdGhlIGV4aXN0aW5nIGRlZmluaXRpb24sIHJhdGhlciB0aGFuIHJlcGVhdGluZyBp dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBCZXN0IHdpc2hlcyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10N CjxiPk9uIEJlaGFsZiBPZiA8L2I+TmF0IFNha2ltdXJhPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRh eSwgSnVuZSAyOCwgMjAxNSA4OjUzIFBNPGJyPg0KPGI+VG86PC9iPiBvYXV0aDsgb2F1dGgtY2hh aXJzQHRvb2xzLmlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtPQVVUSC1XR10gRndkOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNha2ltdXJhLW9hdXRoLXJqd3Rwcm9m LTA0LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LZXBlbmcgYW5kIEkgcmV2J2Vk IHRoaXMgZGlzY3Vzc2lvbiBkcmFmdCB3aGljaCBkZXNjcmliZXMgc2VuZGVyIGNvbmZpcm1hdGlv biBtZXRob2QmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPnVzaW5nIEpXVCBhZ2FpbnN0IGEgcmVzb3VyY2UuJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IGlzIHByZXR0eSBz aG9ydC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+RGVyZWsgYW5kIEhhbm5lcywmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2Ugd291bGQgbGlrZSB0byBoYXZlIHNvbWV0 aW1lIGluIHRoZSBPQXV0aCBXRyBzZXNzaW9uIHRvIGRpc2N1c3MgYWJvdXQgaXQuJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhvcGUg eW91IGNhbiBhbGxvY2F0ZSBhIGJpdCBvZiB0aW1lIGZvciBpdC4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCwmbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TmF0PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLTxi cj4NCkZyb206ICZsdDs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5p bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCkRhdGU6IDIwMTUtMDYtMjkgMTI6 NDcgR01UJiM0MzswOTowMDxicj4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtc2FraW11cmEtb2F1dGgtcmp3dHByb2YtMDQudHh0PGJyPg0KVG86IEtlcGVuZyBM aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtlcGVuZy5sa3BAYWxpYmFiYS1pbmMuY29tIj5rZXBlbmcu bGtwQGFsaWJhYmEtaW5jLmNvbTwvYT4mZ3Q7LCBOYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1h aWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iPnNha2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXNha2ltdXJhLW9h dXRoLXJqd3Rwcm9mLTA0LnR4dDxicj4NCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg YnkgTmF0IFNha2ltdXJhIGFuZCBwb3N0ZWQgdG8gdGhlPGJyPg0KSUVURiByZXBvc2l0b3J5Ljxi cj4NCjxicj4NCk5hbWU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtk cmFmdC1zYWtpbXVyYS1vYXV0aC1yand0cHJvZjxicj4NClJldmlzaW9uOiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzA0PGJyPg0KVGl0bGU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBTZW5kZXIgQ29uc3RyYWluZWQgSldUIGZvciBPQXV0aCAyLjA8YnI+DQpEb2N1bWVudCBk YXRlOiZuYnNwOyAyMDE1LTA2LTI5PGJyPg0KR3JvdXA6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248YnI+DQpQYWdlczombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDY8YnI+DQpVUkw6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LXNha2ltdXJhLW9hdXRoLXJqd3Rwcm9mLTA0LnR4dCIgdGFyZ2V0PSJfYmxh bmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXNha2ltdXJh LW9hdXRoLXJqd3Rwcm9mLTA0LnR4dDwvYT48YnI+DQpTdGF0dXM6Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LXNha2ltdXJhLW9hdXRoLXJqd3Rwcm9mLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNha2ltdXJhLW9hdXRoLXJqd3Rwcm9mLzwv YT48YnI+DQpIdG1saXplZDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2FraW11cmEtb2F1dGgtcmp3dHByb2YtMDQi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2FraW11 cmEtb2F1dGgtcmp3dHByb2YtMDQ8L2E+PGJyPg0KRGlmZjombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1zYWtpbXVyYS1vYXV0aC1yand0cHJvZi0wNCIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1zYWtpbXVyYS1vYXV0aC1yand0 cHJvZi0wNDwvYT48YnI+DQo8YnI+DQpBYnN0cmFjdDo8YnI+DQombmJzcDsgJm5ic3A7VGhpcyBk aXNjdXNzaW9uIGRvY3VtZW50IGRlc2NyaWJlcyBhIG1ldGhvZCB0byBpbmRpY2F0ZSBhIHNlbmRl cjxicj4NCiZuYnNwOyAmbmJzcDtjb25zdHJhaW50IHdpdGhpbiBKV1QuJm5ic3A7IEl0IGNvdWxk IHBvdGVudGlhbGx5IGJlIGluY29ycG9yYXRlZCBpbnRvPGJyPg0KJm5ic3A7ICZuYnNwO1BPUFMg c3BlYyBbUE9QU10uPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Yg c3VibWlzc2lvbjxicj4NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBh dmFpbGFibGUgYXQgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+DQp0b29scy5pZXRmLm9yZzwvYT4uPGJyPg0KPGJyPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNs ZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5hdCBTYWtpbXVyYSAo PW5hdCk8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGFpcm1h biwgT3BlbklEIEZvdW5kYXRpb248YnI+DQo8YSBocmVmPSJodHRwOi8vbmF0LnNha2ltdXJhLm9y Zy8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbmF0LnNha2ltdXJhLm9yZy88L2E+PGJyPg0KQF9u YXRfZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BY2PR03MB442168F350E2E051065BC00F5930BY2PR03MB442namprd_-- From nobody Mon Jul 6 11:29:33 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9197B1B2F02 for ; Mon, 6 Jul 2015 11:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJnXD0zkiHec for ; Mon, 6 Jul 2015 11:29:26 -0700 (PDT) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5417C1B2D35 for ; Mon, 6 Jul 2015 11:29:26 -0700 (PDT) Received: by ieqy10 with SMTP id y10so119436490ieq.0 for ; Mon, 06 Jul 2015 11:29:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8g60lBBmGvhA+YhDT+invGebRmWpXiexJ4+ecAP+UJ0=; b=K8GQqOzVXPTnHGW/zl4YBFIWBTEbF/y59waSKNnp9qthgCFS7t/Im+CAPomnhzQ6WJ j+blItljDTlEreTyLUIcmto68lGLJRdSxAtVCjbODjQP0pxa1Wyxu5+XPu6Nnq4GaVlV iR98JPLfPab1KlaIBh7tGi0C7toXK6OXTQnDlICxQyc3VEVmQGH74MPQ2bOguTx7FytJ 11Af7VhiiHQVgdJptZxYtDWTDsEx7Lwj8sdmWsi0isoBGrbB4mAoJfBhHPpAGhVxRy1f UQMWyht/N+y7JFTeogGtoJyM+kevyqN9ZMH0/n5kJ1FgXIzBrrQbB1kj67kk8BQjS1oQ MVOQ== X-Gm-Message-State: ALoCoQnywyy0HEjeJM8Z4R7VPE00D8DmNehhMZJ0VhA5pWeAuRrgUEhkzKz4GYw9k0lr3ZrNT9fm X-Received: by 10.107.128.72 with SMTP id b69mr354832iod.84.1436207365500; Mon, 06 Jul 2015 11:29:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.64.209 with HTTP; Mon, 6 Jul 2015 11:28:56 -0700 (PDT) In-Reply-To: References: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> <55928DB3.7090300@gmail.com> <5593C270.7000008@gmail.com> <5593DA7D.80401@mit.edu> <5593E5FD.3050403@gmail.com> <559A676F.3070008@gmail.com> From: Brian Campbell Date: Mon, 6 Jul 2015 12:28:56 -0600 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=001a113f96d0d880fd051a391502 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 18:29:32 -0000 --001a113f96d0d880fd051a391502 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Stating specific action items resulting from the ad-hoc meeting in Dallas like that suggests some clear consensus was reached, which is not at all the case. As I recall, several of us argued past one another for an hour or so and decided to adjourn in order to go to the bar (okay, and dinner too - but mostly beer). The impression about reversal of terms, I think, comes from the text in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 which hurts my head a little every-time I read it but does seems to confuse things. The MSDN link John gave is much more to the point than WS-Trust (I don't believe WS-Trust can be pointed to as a model of clarity). In the draft I wrote, I tried to take Mike's text and clarify a distinction between impersonation and delegation with https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 and then also be very explicit about act-as vs. on-behalf-of in the parameter definitions at https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in a manor that was consistent with WS-Trust and the MSDN explanation. I could see value in breaking with that shaky legacy and using new terms too. But I get the point of trying to keep with the old also and potential for even more confusing by using new terms. I wrote draft-campbell-oauth-sts last year in response to the call for adoption of jones-oauth-token-exchange (thread from the archive ). Though I didn't try and stand in the way and indicated a willingness to collaborate on things. With the expectation, of course, that the details would differ from the -00s and -01s as work progressed. Folks seemed genera= lly amenable to that at the time but little has happened since then. Phil's earlier point about the priory of this getting pushed down has some truth to it. But I still believe it's something that can provide a lot of value in standardizing, if we do so in a reasonable way. On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones wrote: > It would surprise me if on-behalf-of and act-as were reversed with respec= t > WS-Trust, because the explanations of the terms came directly from WS-Tru= st > 1.4. I also think the chances of us reducing confusion by inventing new > terminology, rather than adding to it, would not be in our favor. :-/ > > FYI, the action items outstanding from our ad-hoc meeting on this draft i= n > Dallas are: > - Allowing security types other than JWT to also be used as the act_as > and on_behalf_of request values. > - Further integrating the mechanism into the existing OAuth ecosystem - > allowing use of access tokens or refresh tokens when appropriate. > > I plan to do the first today. The second is probably more than I'll get > done today before the submission cutoff. I agree with John that it would > be useful to have discussions on this in Prague on the best way to achiev= e > this further integration. I'll plan to come into the Prague meeting with= a > concrete proposal for review. > > Best wishes, > -- Mike > > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley > Sent: Monday, July 06, 2015 8:13 AM > To: Brian Campbell > Cc: oauth > Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case > > Yes unfortunately we haven=E2=80=99t made any progress on this since acce= pting > Mike=E2=80=99s first draft. > > His proposal is basically for a new endpoint while Brian tired to fit it > into the existing token endpoint. > > I think draft-ietf-oauth-token-exchange-01 still has OnBehalfOf and ActAs > reversed compared to WS-Trust 1.4. > see https://msdn.microsoft.com/en-us/library/ee748487.aspx for the short > explanation. > > I think Brian is closer in explaining it. > > In fairness because WS-Trust originally only had On-Behalf-Of the naming > and what people put in tokens is a bit muddled in many implementations. > I think many times it is how WIF implemented it that people copied. > > It may be better to have new terms that are clear such as impersonation > and composite. > > The WG needs to decide if this is going to be an entirely new endpoint, > free of the Token endpoint semantics. There are plusses and minuses to > both options. > > Also while it is nice to be pure and talk about abstract security tokens, > it would be good to give some guidance on what a composite security token > would look like for interoperability. > > There are also issues around how this would work with proof of possession > security tokens, both as input and output. > > Perhaps we can make some progress on this in Prague. > > John B. > > > > > > On Jul 6, 2015, at 11:04 AM, Brian Campbell > wrote: > > > > Thanks Sergey, > > > > The goal of draft-campbell-oauth-sts was to be consistent with OAuth 2.= 0 > and thus hopefully familiar to developers and easy to understand and > implement (especially from the client side). It's also intended to be > flexible in order to accommodate a variety of use-cases including the > chaining type cases that Justin's draft covers. > > > > Specifying a security_token_type of the returned token is just a way of > providing more info to the client about the token (i.e. is this a JWT or = a > SAML token or something else) via a URI. It's not always needed but in ST= S > style cases the tokens are not always opaque to the client and the > parameter just provides info about the returned token. > > > > On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin > wrote: > > Hi Brian > > > > I've read the text, I like it is still pure OAuth2, with few extra > parameters added to the access token request, and a key response property > being 'access_token' as opposed to 'security_access_token' as in the > draft-ietf-oauth-token-exchange-01. > > It appears draft-campbell-oauth-sts-01 can cover a > draft-richer-oauth-chain-00 case with the on_behalf_of (and/or act_as ?) > property being an original client token but not 100% sure given > draft-richer-oauth-chain-00 covers a specific case. > > > > One thing I'm not sure about is what is the purpose of specifying a > > security_token_type of the returned access token > > > > Thanks, Sergey > > > > On 01/07/15 15:59, Brian Campbell wrote: > > One problem, I think, with token exchange is that it can be really > > simple (token in and token out) and really complicated (client X wants > > a token that says user A is doing something on behalf of user B) at > > the same time. > > > > I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in > > an attempt to simplify things and express what I envisioned as an > > OAuth based token exchange framework. Though it likely only muddied > > the waters :) > > > > On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin > > wrote: > > > > Hi Justin > > > > https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much > > easier to read, that I can tell for sure, at least it is obvious wh= y > > a given entity (RS1) may want to exchange the current token provide= d > > by a client for a new token. Definitely easily implementable... > > > > One thing I'm not sure in the draft-richer-oauth-chain-00 about is > > on behalf of whose entity RS1 will be acting once it starts > > accessing RS2, On Behalf Of RO, or may be On Behalf Of (RO + > > Client), or may be it is On Behalf Of RO + Act As Client ? The last > > one seems most logical to me... > > > > Thanks, Sergey > > > > > > On 01/07/15 13:18, Justin Richer wrote: > > > > As it's written right now, it's a translation of some WS-* > > concepts into > > JWT format. It's not really OAuth-y (since the client has to > > understand > > the token format along with everyone else, and according to the > > authors > > the artifacts might not even be "OAuth tokens"), and that's my > main > > issue with the document. Years ago, I proposed an OAuth-based > > token swap > > mechanism: > > > > https://tools.ietf.org/html/draft-richer-oauth-chain-00 > > > > This works without defining semantics of the tokens themselves, > just > > like the rest of OAuth. I've proposed to the authors of the > current > > draft that it should incorporate both semantic (using JWT) and > > syntactic > > (using a simple token-agnostic grant) token swap mechanisms, an= d > > that > > the two could be easily compatible. > > > > -- Justin > > > > On 7/1/2015 6:35 AM, Sergey Beryozkin wrote: > > > > Hmm... perhaps the clue is in the draft title, > > token-exchange, so may > > be it is a case of the given access token ("on_behalf_of" o= r > > "act_as" > > claim) being used to request a new security token. One can > > only guess > > though, does not seem like the authors are keen to answer > > the newbie > > questions... > > > > Cheers, Sergey > > > > > > On 30/06/15 13:38, Sergey Beryozkin wrote: > > > > Hi, > > Can you please explain what is the difference between > > On-Behalf-Of > > semantics described in the > > draft-ietf-oauth-token-exchange-01 and the > > implicit On-Behalf-Of semantics a client OAuth2 token > > possesses ? > > > > For example, draft-ietf-oauth-token-exchange-01 mention= s: > > > > "Whereas, with on-behalf-of semantics, principal A stil= l > > has its own > > identity separate from B and it is explicitly understoo= d > > that while B > > may have delegated its rights to A, any actions taken > > are being taken by > > A and not B. In a sense, A is an agent for B." > > > > This is a typical case with the authorization code flow > > where a client > > application acts on-behalf-of the user who authorized > > this application ? > > > > Sorry if I'm missing something > > > > Cheers, Sergey > > On 25/06/15 22:28, Mike Jones wrote: > > > > That=E2=80=99s what > > > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 > > is > > about. > > > > Cheers, > > > > -- Mike > > > > *From:*OAuth [mailto:oauth-bounces@ietf.org > > ] *On Behalf Of > *Vivek > > Biswas > > -T (vibiswas - XORIANT CORPORATION at Cisco) > > *Sent:* Thursday, June 25, 2015 2:20 PM > > *To:* OAuth@ietf.org > > *Subject:* [OAUTH-WG] JWT Token on-behalf of Use > > case > > > > Hi All, > > > > I am looking to solve a use-case similar to > > WS-Security On-Behalf-Of > > > > > .4-errata01-os-complete.html#_Toc325658980> > > > > > > with OAuth JWT Token. > > > > Is there a standard claim which we can define > > within the OAuth JWT > > which denote the On-behalf-of User. > > > > For e.g., a Customer Representative trying to creat= e > > token on behalf of > > a customer and trying to execute services specific > > for that specific > > customer. > > > > Regards, > > > > Vivek Biswas, > > CISSP > > > > *Cisco Systems, Inc * > > > > *Bldg. J, San Jose, USA,* > > > > *Phone: +1 408 527 9176 > > * > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@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 > --001a113f96d0d880fd051a391502 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stating specific action items resulting fro= m the ad-hoc meeting in Dallas like that suggests some clear consensus was = reached, which is not at all the case. As I recall, several of us argued pa= st one another for an hour or so and decided to adjourn in order to go to t= he bar (okay, and dinner too - but mostly beer).

The impressio= n about reversal of terms, I think, comes from the text in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-0= 1#section-1.3 which hurts my head a little every-time I read it but doe= s seems to confuse things. The MSDN link John gave is much mo= re to the point than WS-Trust (I don't believe WS-Trust can be pointed = to as a model of clarity).=C2=A0 In the draft I wrote, I tried to take Mike= 's text and clarify a distinction between impersonation and delegation = with https://tools.ietf.org/html/draft-campbell-oaut= h-sts-01#section-1.3 and then also be very explicit about act-as vs. on= -behalf-of in the parameter definitions at https://too= ls.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in a manor that = was consistent with WS-Trust and the MSDN explanation. I could see value in= breaking with that shaky legacy and using new terms too. But I get the poi= nt of trying to keep with the old also and potential for even more confusin= g by using new terms.

I wrote draft-campbell-oauth-sts last y= ear in response to the call for adoption of jones-oauth-token-exchange (thread from the archive). Though I didn't try and= stand in the way and indicated a willingness to collaborate on things. Wit= h the expectation, of course, that the details would differ from the -00s a= nd -01s as work progressed. Folks seemed generally ame= nable to that at the time but little has happened since then.

Phil's earlier point about the priory of this getting pushed d= own has some truth to it. But I still believe it's something that can p= rovide a lot of value in standardizing, if we do so in a reasonable way.







=

On Mon, Jul 6, 20= 15 at 10:33 AM, Mike Jones <Michael.Jones@microsoft.com><= /span> wrote:
It would surprise me if on-= behalf-of and act-as were reversed with respect WS-Trust, because the expla= nations of the terms came directly from WS-Trust 1.4.=C2=A0 I also think th= e chances of us reducing confusion by inventing new terminology, rather tha= n adding to it, would not be in our favor. :-/

FYI, the action items outstanding from our ad-hoc meeting on this draft in = Dallas are:
=C2=A0 - Allowing security types other than JWT to also be used as the act_= as and on_behalf_of request values.
=C2=A0 - Further integrating the mechanism into the existing OAuth ecosyste= m - allowing use of access tokens or refresh tokens when appropriate.

I plan to do the first today.=C2=A0 The second is probably more than I'= ll get done today before the submission cutoff.=C2=A0 I agree with John tha= t it would be useful to have discussions on this in Prague on the best way = to achieve this further integration.=C2=A0 I'll plan to come into the P= rague meeting with a concrete proposal for review.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Best wishes,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =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 John Bradley
Sent: Monday, July 06, 2015 8:13 AM
To: Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case

Yes unfortunately we haven=E2=80=99t made any progress on this since accept= ing Mike=E2=80=99s first draft.

His proposal is basically for a new endpoint while Brian tired to fit it in= to the existing token endpoint.

I think draft-ietf-oauth-token-exchange-01 still has OnBehalfOf and ActAs r= eversed compared to WS-Trust 1.4.
see https://msdn.microsoft.com/en-us/library/= ee748487.aspx for the short explanation.

I think Brian is closer in explaining it.

In fairness because WS-Trust originally only had On-Behalf-Of the naming an= d what people put in tokens is a bit muddled in many implementations.
I think many times it is how WIF implemented it that people copied.

It may be better to have new terms that are clear such as impersonation and= composite.

The WG needs to decide if this is going to be an entirely new endpoint, fre= e of the Token endpoint semantics.=C2=A0 =C2=A0There are plusses and minuse= s to both options.

Also while it is nice to be pure and talk about abstract security tokens, i= t would be good to give some guidance on what a composite security token wo= uld look like for interoperability.

There are also issues around how this would work with proof of possession s= ecurity tokens, both as input and output.

Perhaps we can make some progress on this in Prague.

John B.




> On Jul 6, 2015, at 11:04 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
>
> Thanks Sergey,
>
> The goal of draft-campbell-oauth-sts was to be consistent with OAuth 2= .0 and thus hopefully familiar to developers and easy to understand and imp= lement (especially from the client side). It's also intended to be flex= ible in order to accommodate a variety of use-cases including the chaining = type cases that Justin's draft covers.
>
> Specifying a security_token_type of the returned token is just a way o= f providing more info to the client about the token (i.e. is this a JWT or = a SAML token or something else) via a URI. It's not always needed but i= n STS style cases the tokens are not always opaque to the client and the pa= rameter just provides info about the returned token.
>
> On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin <sberyozkin@gmail.com> wrote:
> Hi Brian
>
> I've read the text, I like it is still pure OAuth2, with few extra= parameters added to the access token request, and a key response property = being 'access_token' as opposed to 'security_access_token' = as in the draft-ietf-oauth-token-exchange-01.
> It appears draft-campbell-oauth-sts-01 can cover a draft-richer-oauth-= chain-00 case with the on_behalf_of (and/or act_as ?) property being an ori= ginal client token but not 100% sure given draft-richer-oauth-chain-00 cove= rs a specific case.
>
> One thing I'm not sure about is what is the purpose of specifying = a
> security_token_type of the returned access token
>
> Thanks, Sergey
>
> On 01/07/15 15:59, Brian Campbell wrote:
> One problem, I think, with token exchange is that it can be really
> simple (token in and token out) and really complicated (client X wants=
> a token that says user A is doing something on behalf of user B) at > the same time.
>
> I put forth https://tools.ietf.org/html/= draft-campbell-oauth-sts-01 in
> an attempt to simplify things and express what I envisioned as an
> OAuth based token exchange framework. Though it likely only muddied > the waters :)
>
> On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin <sberyozkin@gmail.com
> <mailto:sberyozkin@gmail.co= m>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hi Justin
>
>=C2=A0 =C2=A0 =C2=A0https://tools.ietf.or= g/html/draft-richer-oauth-chain-00 is much
>=C2=A0 =C2=A0 =C2=A0easier to read, that I can tell for sure, at least = it is obvious why
>=C2=A0 =C2=A0 =C2=A0a given entity (RS1) may want to exchange the curre= nt token provided
>=C2=A0 =C2=A0 =C2=A0by a client for a new token. Definitely easily impl= ementable...
>
>=C2=A0 =C2=A0 =C2=A0One thing I'm not sure in the draft-richer-oaut= h-chain-00 about is
>=C2=A0 =C2=A0 =C2=A0on behalf of whose entity RS1 will be acting once i= t starts
>=C2=A0 =C2=A0 =C2=A0accessing RS2, On Behalf Of RO, or may be On Behalf= Of (RO +
>=C2=A0 =C2=A0 =C2=A0Client), or may be it is On Behalf Of RO + Act As C= lient ? The last
>=C2=A0 =C2=A0 =C2=A0one seems most logical to me...
>
>=C2=A0 =C2=A0 =C2=A0Thanks, Sergey
>
>
>=C2=A0 =C2=A0 =C2=A0On 01/07/15 13:18, Justin Richer wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0As it's written right now, it'= ;s a translation of some WS-*
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0concepts into
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0JWT format. It's not really OAuth= -y (since the client has to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0understand
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the token format along with everyone = else, and according to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0authors
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the artifacts might not even be "= ;OAuth tokens"), and that's my main
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0issue with the document. Years ago, I= proposed an OAuth-based
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0token swap
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mechanism:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https:/= /tools.ietf.org/html/draft-richer-oauth-chain-00
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This works without defining semantics= of the tokens themselves, just
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0like the rest of OAuth. I've prop= osed to the authors of the current
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft that it should incorporate both= semantic (using JWT) and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0syntactic
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(using a simple token-agnostic grant)= token swap mechanisms, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the two could be easily compatible. >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Justin
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 7/1/2015 6:35 AM, Sergey Beryozkin= wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hmm... perhaps the clue= is in the draft title,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0token-exchange, so may<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be it is a case of the = given access token ("on_behalf_of" or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"act_as"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0claim) being used to re= quest a new security token. One can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0only guess
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0though, does not seem l= ike the authors are keen to answer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the newbie
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0questions...
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Cheers, Sergey
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 30/06/15 13:38, Serg= ey Beryozkin wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Can you p= lease explain what is the difference between
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On-Behalf= -Of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0semantics= described in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-iet= f-oauth-token-exchange-01 and the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implicit = On-Behalf-Of semantics a client OAuth2 token
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0possesses= ?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0For examp= le, draft-ietf-oauth-token-exchange-01 mentions:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Whe= reas, with on-behalf-of semantics, principal A still
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0has its o= wn
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0identity = separate from B and it is explicitly understood
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that whil= e B
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0may have = delegated its rights to A, any actions taken
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0are being= taken by
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A and not= B. In a sense, A is an agent for B."
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This is a= typical case with the authorization code flow
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0where a c= lient
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0applicati= on acts on-behalf-of the user who authorized
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this appl= ication ?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sorry if = I'm missing something
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Cheers, S= ergey
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 25/06/= 15 22:28, Mike Jones wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0That=E2=80=99s what
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0https://tools.ietf.org/html/draf= t-ietf-oauth-token-exchange-01
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0about.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Cheers,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0-- Mike
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0*From:*OAuth [mailto:oauth-= bounces@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0<mailto:oauth-bounces@ie= tf.org>] *On Behalf Of *Vivek
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Biswas
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0-T (vibiswas - XORIANT CORPORATION at Cisco)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0*Sent:* Thursday, June 25, 2015 2:20 PM
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0*To:* 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*Subject:* [OAUTH-WG] JWT Token on-behalf of Use
> case
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Hi All,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0I am looking to solve a use-case similar to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0WS-Security On-Behalf-Of
>
> <http://docs.oasis-open= .org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust-1
> .4-errata01-os-complete.html#_Toc325658980>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0with OAuth JWT Token.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Is there a standard claim which we can define
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0within the OAuth JWT
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0which denote the On-behalf-of User.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0For e.g., a Customer Representative trying to create
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0token on behalf of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0a customer and trying to execute services specific
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0for that specific
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0customer.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Regards,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Vivek Biswas,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0CISSP
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0*Cisco Systems, Inc <http://www.cisco.com/>*
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0*Bldg. J, San Jose, USA,*
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0*Phone: +1 408 527 9176
> <tel:%2B1%20408%20527%209176>*
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0OAuth mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0OAuth@ietf.org <mailto:OAuth@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_______________________= ________________________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OAuth mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OAuth@ietf.org <mailto:= OAuth@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https= ://www.ietf.org/mailman/listinfo/oauth
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_____________________________________= __________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OAuth mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OAu= th@ietf.org <mailto:OAuth@ietf.org= >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.or= g/mailman/listinfo/oauth
>
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0OAuth mailing list
>=C2=A0 =C2=A0 =C2=A0OAuth@ietf.org <mailto:OAuth@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/list= info/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

--001a113f96d0d880fd051a391502-- From nobody Mon Jul 6 11:46:07 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40ADC1A92EB for ; Mon, 6 Jul 2015 11:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXfnAICp9XW2 for ; Mon, 6 Jul 2015 11:46:02 -0700 (PDT) Received: from mail-qk0-f170.google.com (mail-qk0-f170.google.com [209.85.220.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F17541B3023 for ; Mon, 6 Jul 2015 11:46:01 -0700 (PDT) Received: by qkhu186 with SMTP id u186so123803621qkh.0 for ; Mon, 06 Jul 2015 11:46:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=myPPfvxyAgjG2SJt5yMKHuFrD4R3vqM0wS00UPmqXpE=; b=kKyWybTMr/oKNHbMcc+P+geAC0bM93+1r3Iummbj+NrlHXqcs5XzODlwcKOmNYtcpN 20NzQsgSI/ceC3QxDkxX9kWLqEXehZgep3bwrfsRCtqf/QtgKqOl+S6jGMKt90w+sja9 MSiV+m5fMHs62BM+Gx/TuayWKQiw+g28/xBD6BdJTxVTOsyAnsZsPjlVAfxBEkz/tBx6 b8rfdntCACysQraWgqGSzxBHA7AYYAJVRzPR0VH65ZyflHCngFlnrNNU3MQdKb/THfxM joZ2uNYmTnJopys6PUNM7eRbPsW6wkWlY/Elbnsz7ZDFXWC5wiyTG7+aF5sXia3PhhZm yuQA== X-Gm-Message-State: ALoCoQlMQyey3VFV7xI9T1WdWruVPiT4WVEgBq730b+gMxNnuuklPSVZImdSEe2V4OsYJBicr70h X-Received: by 10.140.85.208 with SMTP id n74mr450776qgd.67.1436208361032; Mon, 06 Jul 2015 11:46:01 -0700 (PDT) Received: from [192.168.8.101] ([181.202.207.194]) by mx.google.com with ESMTPSA id 63sm9740403qkt.27.2015.07.06.11.45.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Jul 2015 11:46:00 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: text/plain; charset=utf-8 From: John Bradley In-Reply-To: Date: Mon, 6 Jul 2015 15:45:52 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4C05F5FB-5019-49AC-BD9D-62D0C3A61E01@ve7jtb.com> References: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> <55928DB3.7090300@gmail.com> <5593C270.7000008@gmail.com> <5593DA7D.80401@mit.edu> <5593E5FD.3050403@gmail.com> <559A676F.3070008@gmail.com> To: Michael Jones X-Mailer: Apple Mail (2.2102) Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 18:46:05 -0000 Mike, I have pointed this out several times. I understand that you disagree.=20= The WS-Trust spec is not as clear as it could be. I included the MSDN = note explaining how WIF interprets it. > https://msdn.microsoft.com/en-us/library/ee748487.aspx Given that there seems to be differing opinions on the semantics beyond = just me, can we agree that the terms are not as clear as one would hope? I may be wrong, but I suspect that I am not the only one. =20 We can discuss it at the F2F. John B. > On Jul 6, 2015, at 1:33 PM, Mike Jones = wrote: >=20 > It would surprise me if on-behalf-of and act-as were reversed with = respect WS-Trust, because the explanations of the terms came directly = from WS-Trust 1.4. I also think the chances of us reducing confusion by = inventing new terminology, rather than adding to it, would not be in our = favor. :-/ >=20 > FYI, the action items outstanding from our ad-hoc meeting on this = draft in Dallas are: > - Allowing security types other than JWT to also be used as the = act_as and on_behalf_of request values. > - Further integrating the mechanism into the existing OAuth ecosystem = - allowing use of access tokens or refresh tokens when appropriate. >=20 > I plan to do the first today. The second is probably more than I'll = get done today before the submission cutoff. I agree with John that it = would be useful to have discussions on this in Prague on the best way to = achieve this further integration. I'll plan to come into the Prague = meeting with a concrete proposal for review. >=20 > Best wishes, > -- Mike >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley > Sent: Monday, July 06, 2015 8:13 AM > To: Brian Campbell > Cc: oauth > Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case >=20 > Yes unfortunately we haven=E2=80=99t made any progress on this since = accepting Mike=E2=80=99s first draft. >=20 > His proposal is basically for a new endpoint while Brian tired to fit = it into the existing token endpoint. >=20 > I think draft-ietf-oauth-token-exchange-01 still has OnBehalfOf and = ActAs reversed compared to WS-Trust 1.4. > see https://msdn.microsoft.com/en-us/library/ee748487.aspx for the = short explanation. >=20 > I think Brian is closer in explaining it. >=20 > In fairness because WS-Trust originally only had On-Behalf-Of the = naming and what people put in tokens is a bit muddled in many = implementations. > I think many times it is how WIF implemented it that people copied. >=20 > It may be better to have new terms that are clear such as = impersonation and composite. >=20 > The WG needs to decide if this is going to be an entirely new = endpoint, free of the Token endpoint semantics. There are plusses and = minuses to both options. >=20 > Also while it is nice to be pure and talk about abstract security = tokens, it would be good to give some guidance on what a composite = security token would look like for interoperability. >=20 > There are also issues around how this would work with proof of = possession security tokens, both as input and output. >=20 > Perhaps we can make some progress on this in Prague. >=20 > John B. >=20 >=20 >=20 >=20 >> On Jul 6, 2015, at 11:04 AM, Brian Campbell = wrote: >>=20 >> Thanks Sergey, >>=20 >> The goal of draft-campbell-oauth-sts was to be consistent with OAuth = 2.0 and thus hopefully familiar to developers and easy to understand and = implement (especially from the client side). It's also intended to be = flexible in order to accommodate a variety of use-cases including the = chaining type cases that Justin's draft covers.=20 >>=20 >> Specifying a security_token_type of the returned token is just a way = of providing more info to the client about the token (i.e. is this a JWT = or a SAML token or something else) via a URI. It's not always needed but = in STS style cases the tokens are not always opaque to the client and = the parameter just provides info about the returned token. =20 >>=20 >> On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin = wrote: >> Hi Brian >>=20 >> I've read the text, I like it is still pure OAuth2, with few extra = parameters added to the access token request, and a key response = property being 'access_token' as opposed to 'security_access_token' as = in the draft-ietf-oauth-token-exchange-01. >> It appears draft-campbell-oauth-sts-01 can cover a = draft-richer-oauth-chain-00 case with the on_behalf_of (and/or act_as ?) = property being an original client token but not 100% sure given = draft-richer-oauth-chain-00 covers a specific case. >>=20 >> One thing I'm not sure about is what is the purpose of specifying a=20= >> security_token_type of the returned access token >>=20 >> Thanks, Sergey >>=20 >> On 01/07/15 15:59, Brian Campbell wrote: >> One problem, I think, with token exchange is that it can be really=20 >> simple (token in and token out) and really complicated (client X = wants=20 >> a token that says user A is doing something on behalf of user B) at=20= >> the same time. >>=20 >> I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 = in=20 >> an attempt to simplify things and express what I envisioned as an=20 >> OAuth based token exchange framework. Though it likely only muddied=20= >> the waters :) >>=20 >> On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin = > > wrote: >>=20 >> Hi Justin >>=20 >> https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much >> easier to read, that I can tell for sure, at least it is obvious = why >> a given entity (RS1) may want to exchange the current token = provided >> by a client for a new token. Definitely easily implementable... >>=20 >> One thing I'm not sure in the draft-richer-oauth-chain-00 about is >> on behalf of whose entity RS1 will be acting once it starts >> accessing RS2, On Behalf Of RO, or may be On Behalf Of (RO + >> Client), or may be it is On Behalf Of RO + Act As Client ? The = last >> one seems most logical to me... >>=20 >> Thanks, Sergey >>=20 >>=20 >> On 01/07/15 13:18, Justin Richer wrote: >>=20 >> As it's written right now, it's a translation of some WS-* >> concepts into >> JWT format. It's not really OAuth-y (since the client has to >> understand >> the token format along with everyone else, and according to = the >> authors >> the artifacts might not even be "OAuth tokens"), and that's my = main >> issue with the document. Years ago, I proposed an OAuth-based >> token swap >> mechanism: >>=20 >> https://tools.ietf.org/html/draft-richer-oauth-chain-00 >>=20 >> This works without defining semantics of the tokens = themselves, just >> like the rest of OAuth. I've proposed to the authors of the = current >> draft that it should incorporate both semantic (using JWT) and >> syntactic >> (using a simple token-agnostic grant) token swap mechanisms, = and >> that >> the two could be easily compatible. >>=20 >> -- Justin >>=20 >> On 7/1/2015 6:35 AM, Sergey Beryozkin wrote: >>=20 >> Hmm... perhaps the clue is in the draft title, >> token-exchange, so may >> be it is a case of the given access token ("on_behalf_of" = or >> "act_as" >> claim) being used to request a new security token. One can >> only guess >> though, does not seem like the authors are keen to answer >> the newbie >> questions... >>=20 >> Cheers, Sergey >>=20 >>=20 >> On 30/06/15 13:38, Sergey Beryozkin wrote: >>=20 >> Hi, >> Can you please explain what is the difference between >> On-Behalf-Of >> semantics described in the >> draft-ietf-oauth-token-exchange-01 and the >> implicit On-Behalf-Of semantics a client OAuth2 token >> possesses ? >>=20 >> For example, draft-ietf-oauth-token-exchange-01 = mentions: >>=20 >> "Whereas, with on-behalf-of semantics, principal A = still >> has its own >> identity separate from B and it is explicitly = understood >> that while B >> may have delegated its rights to A, any actions taken >> are being taken by >> A and not B. In a sense, A is an agent for B." >>=20 >> This is a typical case with the authorization code = flow >> where a client >> application acts on-behalf-of the user who authorized >> this application ? >>=20 >> Sorry if I'm missing something >>=20 >> Cheers, Sergey >> On 25/06/15 22:28, Mike Jones wrote: >>=20 >> That=E2=80=99s what >> = https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 >> is >> about. >>=20 >> Cheers, >>=20 >> -- Mike >>=20 >> *From:*OAuth [mailto:oauth-bounces@ietf.org >> ] *On Behalf Of = *Vivek >> Biswas >> -T (vibiswas - XORIANT CORPORATION at Cisco) >> *Sent:* Thursday, June 25, 2015 2:20 PM >> *To:* OAuth@ietf.org >> *Subject:* [OAUTH-WG] JWT Token on-behalf of Use=20= >> case >>=20 >> Hi All, >>=20 >> I am looking to solve a use-case similar to >> WS-Security On-Behalf-Of >>=20 >> = > .4-errata01-os-complete.html#_Toc325658980> >>=20 >>=20 >> with OAuth JWT Token. >>=20 >> Is there a standard claim which we can define >> within the OAuth JWT >> which denote the On-behalf-of User. >>=20 >> For e.g., a Customer Representative trying to = create >> token on behalf of >> a customer and trying to execute services specific >> for that specific >> customer. >>=20 >> Regards, >>=20 >> Vivek Biswas, >> CISSP >>=20 >> *Cisco Systems, Inc * >>=20 >> *Bldg. J, San Jose, USA,* >>=20 >> *Phone: +1 408 527 9176=20 >> * >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Jul 6 11:49:00 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550D31B3029 for ; Mon, 6 Jul 2015 11:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIk1VT_beO29 for ; Mon, 6 Jul 2015 11:48:53 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0116.outbound.protection.outlook.com [65.55.169.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 8820F1B301E for ; Mon, 6 Jul 2015 11:48:52 -0700 (PDT) Received: from BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) by BY2PR03MB090.namprd03.prod.outlook.com (10.255.241.158) with Microsoft SMTP Server (TLS) id 15.1.201.16; Mon, 6 Jul 2015 18:48:49 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.213.10; Mon, 6 Jul 2015 18:48:47 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0213.000; Mon, 6 Jul 2015 18:48:46 +0000 From: Mike Jones To: Brian Campbell Thread-Topic: [OAUTH-WG] JWT Token on-behalf of Use case Thread-Index: AdCvjKZzog4lHzdSReisaGHaz/hQ6gAARPxgAOj5XIAALgFuAAADlXeAAAG2sYAAA+u+gAD0P/SAAAVKOIAAAmBqAAACCAqQAATTnQAAAH6EcA== Date: Mon, 6 Jul 2015 18:48:46 +0000 Message-ID: References: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> <55928DB3.7090300@gmail.com> <5593C270.7000008@gmail.com> <5593DA7D.80401@mit.edu> <5593E5FD.3050403@gmail.com> <559A676F.3070008@gmail.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; x-originating-ip: [50.47.90.173] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:yGyH8OhdYbXZmne2Hi2nYhQ7H4zjf+mWSrOLbHi3WTOa/KXHdHgtHagekhCsCpH/xEg3qx4/SY+WwwD2karnO4picWLuW7f6ibMGbP96An9aHbu/X8gyoezkeX9YUBPavA2wZlU/nSJkFqfpCA1Acw==; 24:xiGrNb4pidRtHPUo2worgqy/IrPL3erhkMZsFkDZ4ZHgzFvdCI5QTZx3/xluR524aNzLq37v/lPEWJLjnkFJpTwq1BL5PdOlK+s+Nl/7oYU=; 20:HF7FDOtnrtj+xBEDJUJllyZ7D1basBg4/UyyjGYQ5R1ExYJAeeGze6zioPgICfPNOK1kW8r5NJd3OKT6GRqYGQ== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB090; by2pr03mb443: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 06290ECA9D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(479174004)(3905003)(377454003)(164054003)(24454002)(53754006)(13464003)(69234005)(51704005)(110136002)(19580405001)(92566002)(15975445007)(62966003)(86362001)(5003600100002)(189998001)(5001960100002)(19625215002)(77156002)(102836002)(2900100001)(2950100001)(54356999)(33656002)(16236675004)(76176999)(50986999)(77096005)(86612001)(66066001)(99286002)(46102003)(76576001)(74316001)(19300405004)(93886004)(40100003)(19609705001)(87936001)(561944003)(2656002)(5002640100001)(19580395003)(19617315012)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442D6CB1EB8C2C503710279F5930BY2PR03MB442namprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2015 18:48:46.8349 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 X-Microsoft-Exchange-Diagnostics: 1; BY2PR03MB090; 2:mMPGUWobE3fxPz2nHI/KqCsWPL2GUBxTMTasSFGuVxsHf+jNswfKdBNub0KdrWk2; 3:VIB7wCOy24fqWjPQvqrAyxugSvW+NwDycT3+1GAqHE7XRuJ9kyIQkK1qTq04qeRu9e09dHFHXMItUMT89a8L9tNzBfbP8fVfT/WXZdBIUawI0NYeYjc+xhmki6Bu7Qk4IQajyK7lNzanDpKmcPJJSA==; 25:5CINtKy0vbNum803YXcWiwjJ05UmECZxDNDpQK3ezTP1wT/IUmIfnNMq12o0k2dirPHBnGLyMCB3A6ZiD7FOsGKwVLnEEjGkAxqYE6V81y2QyR8q54LhJukpp5SA6pC0vGOM5nfMV0SN9s725074neZJ1ngJ0XQ19iluYTgBdYZ4w9fc2sAh+H/AQResGkjd2lIoYSfuk2wA9hqiLIeTRVPcFb4Prqo/tnqH+0+8sQFcfyZf5gIq0xBxliqHPgWK8ICtXAJSYrvtEFp0B6SwhQ== X-Microsoft-Exchange-Diagnostics: 1; BY2PR03MB090; 20:3IA8xY8k0gY81LLeTBRiqU2j50vvay1Vs8LXm4PRQ9VSI33qcjBwx1F7pCpZZB7B+L/uH7l7pYMsABFhza8EhT8KVKlYNmzxBx+RIe9FE5rYskjaf6rhLJhi/ATCavSqwE8vg4T3TDzGwCmNIc/nPh+PNrIvpVU0c91EHZbLto5RUrFQ3YkYV907yOPwQMVvs61v2Sfpt3FuCv56IDvJD84djTZ3H+F88pus9wFPFcusDJMwMh4owCPM65baNjNqElAxIS6M6krtDHYYl5Rhpxu+bdS5iAn/Yd20Gqrkz1SPuOA1iE+37uOXJOMAWmhDeJaTwWfImA2UNFfS6bBKSbtvf6eCx07K8i001muoqjd5Ko87DAjQuGjY+dD7kif88LpRjZ+U6km6gLEFA4TZ33Nuc19TQkcMiZo/7H306KTxCU0g7ospmeQUV9TuHuReMMri7FtXRzWHQLGWU/pBFdnp3zx+w36/wVXjIMGxPVh7SdcqXi5bh/yggm7W6pIQ; 23:0XzszOLBQxyWJI/TSSeCiHNfEVQ+oDpiQxkYldey0+gvgllPXsFHJr2IoDKt/Y0tQggZy8mj9om5/5HBqWYGydYuDS9IPPD+4+/VeqIoW/8PjQUtX5KsvQxBvZ4r5R45gT9JXZ5RXoGEuGvvx1qoTVqXoY+RcH3M3c2urrHPCg0kD9j9nHYGscWK0XL1+zeN3E5wlIH0YDOGqz6YiC7um602Nu/JQCLaG2Wmu/SnYJB5nyH3mSaKbEKfoLU5BKOF X-OriginatorOrg: microsoft.com Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 18:48:58 -0000 --_000_BY2PR03MB442D6CB1EB8C2C503710279F5930BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RmFpciBlbm91Z2gsIEJyaWFuLiAgRm9yIGNsYXJpdHksIG15IHNlbnNlIG9mIHRoZSBhY3Rpb24g aXRlbXMgaXMgdGhhdCBJIGFncmVlZCB0byBkbyB0aG9zZSBhY3Rpb25zIGJhc2VkIG9uIGZlZWRi YWNrIGF0IHRoZSBhZC1ob2MgbWVldGluZyBhbmQgdGhlbiBwZW9wbGUgd291bGQgcmV2aWV3IHRo ZSByZXN1bHQg4oCTIG5vdCB0aGF0IGV2ZXJ5dGhpbmcgd291bGQgYmUg4oCcZG9uZeKAnSBhZnRl ciB0YWtpbmcgdGhvc2UgYWN0aW9ucy4gIEnigJlsbCBzdGlsbCBwbGFuIHRvIGFjdCBvbiB0aGF0 IGZlZWRiYWNrLg0KDQpJ4oCZZCBiZSBnbGFkIHRvIHNpdCBkb3duIHdpdGggeW91IGFuZCBvdGhl cnMgaW4gUHJhZ3VlLCBCcmlhbiwgdG8gd29yayBvdXQgaG93IHRvIG1ha2Ugc3VyZSB5b3VyIHVz ZSBjYXNlcyBhcmUgY292ZXJlZCBhbmQgdGhlIGRyYWZ0IGlzIGFzIGNsZWFyIGFzIGl0IGNhbiBi ZSwgZ2l2ZW4gaXRzIHNvbWV3aGF0IGVzb3RlcmljIHN1YmplY3QgbWF0dGVyLiAgTm93IHRoYXQg SldUIGFuZCBKT1NFIGFuZCB0aGUgT0F1dGggQXNzZXJ0aW9ucyBzcGVjcyBhcmUgZG9uZSBhbmQg c2V2ZXJhbCBvdGhlcnMgYXJlIG5lYXJseSBkb25lLCBnZXR0aW5nIGJhY2sgdG8gdGhpcyBpcyBh IHByaW9yaXR5IGZvciBtZS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgQ2hlZXJzLA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBCcmlh biBDYW1wYmVsbCBbbWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tXQ0KU2VudDogTW9u ZGF5LCBKdWx5IDA2LCAyMDE1IDExOjI5IEFNDQpUbzogTWlrZSBKb25lcw0KQ2M6IEpvaG4gQnJh ZGxleTsgb2F1dGgNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEpXVCBUb2tlbiBvbi1iZWhhbGYg b2YgVXNlIGNhc2UNCg0KU3RhdGluZyBzcGVjaWZpYyBhY3Rpb24gaXRlbXMgcmVzdWx0aW5nIGZy b20gdGhlIGFkLWhvYyBtZWV0aW5nIGluIERhbGxhcyBsaWtlIHRoYXQgc3VnZ2VzdHMgc29tZSBj bGVhciBjb25zZW5zdXMgd2FzIHJlYWNoZWQsIHdoaWNoIGlzIG5vdCBhdCBhbGwgdGhlIGNhc2Uu IEFzIEkgcmVjYWxsLCBzZXZlcmFsIG9mIHVzIGFyZ3VlZCBwYXN0IG9uZSBhbm90aGVyIGZvciBh biBob3VyIG9yIHNvIGFuZCBkZWNpZGVkIHRvIGFkam91cm4gaW4gb3JkZXIgdG8gZ28gdG8gdGhl IGJhciAob2theSwgYW5kIGRpbm5lciB0b28gLSBidXQgbW9zdGx5IGJlZXIpLg0KVGhlIGltcHJl c3Npb24gYWJvdXQgcmV2ZXJzYWwgb2YgdGVybXMsIEkgdGhpbmssIGNvbWVzIGZyb20gdGhlIHRl eHQgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdG9rZW4t ZXhjaGFuZ2UtMDEjc2VjdGlvbi0xLjMgd2hpY2ggaHVydHMgbXkgaGVhZCBhIGxpdHRsZSBldmVy eS10aW1lIEkgcmVhZCBpdCBidXQgZG9lcyBzZWVtcyB0byBjb25mdXNlIHRoaW5ncy4gVGhlIE1T RE4gbGluazxodHRwczovL21zZG4ubWljcm9zb2Z0LmNvbS9lbi11cy9saWJyYXJ5L2VlNzQ4NDg3 LmFzcHg+IEpvaG4gZ2F2ZSBpcyBtdWNoIG1vcmUgdG8gdGhlIHBvaW50IHRoYW4gV1MtVHJ1c3Qg KEkgZG9uJ3QgYmVsaWV2ZSBXUy1UcnVzdCBjYW4gYmUgcG9pbnRlZCB0byBhcyBhIG1vZGVsIG9m IGNsYXJpdHkpLiAgSW4gdGhlIGRyYWZ0IEkgd3JvdGUsIEkgdHJpZWQgdG8gdGFrZSBNaWtlJ3Mg dGV4dCBhbmQgY2xhcmlmeSBhIGRpc3RpbmN0aW9uIGJldHdlZW4gaW1wZXJzb25hdGlvbiBhbmQg ZGVsZWdhdGlvbiB3aXRoIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW1wYmVs bC1vYXV0aC1zdHMtMDEjc2VjdGlvbi0xLjMgYW5kIHRoZW4gYWxzbyBiZSB2ZXJ5IGV4cGxpY2l0 IGFib3V0IGFjdC1hcyB2cy4gb24tYmVoYWxmLW9mIGluIHRoZSBwYXJhbWV0ZXIgZGVmaW5pdGlv bnMgYXQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhbXBiZWxsLW9hdXRoLXN0 cy0wMSNzZWN0aW9uLTIgaW4gYSBtYW5vciB0aGF0IHdhcyBjb25zaXN0ZW50IHdpdGggV1MtVHJ1 c3QgYW5kIHRoZSBNU0ROIGV4cGxhbmF0aW9uLiBJIGNvdWxkIHNlZSB2YWx1ZSBpbiBicmVha2lu ZyB3aXRoIHRoYXQgc2hha3kgbGVnYWN5IGFuZCB1c2luZyBuZXcgdGVybXMgdG9vLiBCdXQgSSBn ZXQgdGhlIHBvaW50IG9mIHRyeWluZyB0byBrZWVwIHdpdGggdGhlIG9sZCBhbHNvIGFuZCBwb3Rl bnRpYWwgZm9yIGV2ZW4gbW9yZSBjb25mdXNpbmcgYnkgdXNpbmcgbmV3IHRlcm1zLg0KSSB3cm90 ZSBkcmFmdC1jYW1wYmVsbC1vYXV0aC1zdHMgbGFzdCB5ZWFyIGluIHJlc3BvbnNlIHRvIHRoZSBj YWxsIGZvciBhZG9wdGlvbiBvZiBqb25lcy1vYXV0aC10b2tlbi1leGNoYW5nZSAodGhyZWFkIGZy b20gdGhlIGFyY2hpdmU8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0 aC9jdXJyZW50L21zZzEzMzA1Lmh0bWw+KS4gVGhvdWdoIEkgZGlkbid0IHRyeSBhbmQgc3RhbmQg aW4gdGhlIHdheSBhbmQgaW5kaWNhdGVkIGEgd2lsbGluZ25lc3MgdG8gY29sbGFib3JhdGUgb24g dGhpbmdzLiBXaXRoIHRoZSBleHBlY3RhdGlvbiwgb2YgY291cnNlLCB0aGF0IHRoZSBkZXRhaWxz IHdvdWxkIGRpZmZlciBmcm9tIHRoZSAtMDBzIGFuZCAtMDFzIGFzIHdvcmsgcHJvZ3Jlc3NlZC4g Rm9sa3Mgc2VlbWVkIGdlbmVyYWxseSBhbWVuYWJsZSB0byB0aGF0PGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxMzMwOC5odG1sPiBhdCB0aGUg dGltZSBidXQgbGl0dGxlIGhhcyBoYXBwZW5lZCBzaW5jZSB0aGVuLg0KUGhpbCdzIGVhcmxpZXIg cG9pbnQgYWJvdXQgdGhlIHByaW9yeSBvZiB0aGlzIGdldHRpbmcgcHVzaGVkIGRvd24gaGFzIHNv bWUgdHJ1dGggdG8gaXQuIEJ1dCBJIHN0aWxsIGJlbGlldmUgaXQncyBzb21ldGhpbmcgdGhhdCBj YW4gcHJvdmlkZSBhIGxvdCBvZiB2YWx1ZSBpbiBzdGFuZGFyZGl6aW5nLCBpZiB3ZSBkbyBzbyBp biBhIHJlYXNvbmFibGUgd2F5Lg0KDQoNCg0KDQoNCk9uIE1vbiwgSnVsIDYsIDIwMTUgYXQgMTA6 MzMgQU0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpJdCB3b3VsZCBzdXJwcmlzZSBtZSBp ZiBvbi1iZWhhbGYtb2YgYW5kIGFjdC1hcyB3ZXJlIHJldmVyc2VkIHdpdGggcmVzcGVjdCBXUy1U cnVzdCwgYmVjYXVzZSB0aGUgZXhwbGFuYXRpb25zIG9mIHRoZSB0ZXJtcyBjYW1lIGRpcmVjdGx5 IGZyb20gV1MtVHJ1c3QgMS40LiAgSSBhbHNvIHRoaW5rIHRoZSBjaGFuY2VzIG9mIHVzIHJlZHVj aW5nIGNvbmZ1c2lvbiBieSBpbnZlbnRpbmcgbmV3IHRlcm1pbm9sb2d5LCByYXRoZXIgdGhhbiBh ZGRpbmcgdG8gaXQsIHdvdWxkIG5vdCBiZSBpbiBvdXIgZmF2b3IuIDotLw0KDQpGWUksIHRoZSBh Y3Rpb24gaXRlbXMgb3V0c3RhbmRpbmcgZnJvbSBvdXIgYWQtaG9jIG1lZXRpbmcgb24gdGhpcyBk cmFmdCBpbiBEYWxsYXMgYXJlOg0KICAtIEFsbG93aW5nIHNlY3VyaXR5IHR5cGVzIG90aGVyIHRo YW4gSldUIHRvIGFsc28gYmUgdXNlZCBhcyB0aGUgYWN0X2FzIGFuZCBvbl9iZWhhbGZfb2YgcmVx dWVzdCB2YWx1ZXMuDQogIC0gRnVydGhlciBpbnRlZ3JhdGluZyB0aGUgbWVjaGFuaXNtIGludG8g dGhlIGV4aXN0aW5nIE9BdXRoIGVjb3N5c3RlbSAtIGFsbG93aW5nIHVzZSBvZiBhY2Nlc3MgdG9r ZW5zIG9yIHJlZnJlc2ggdG9rZW5zIHdoZW4gYXBwcm9wcmlhdGUuDQoNCkkgcGxhbiB0byBkbyB0 aGUgZmlyc3QgdG9kYXkuICBUaGUgc2Vjb25kIGlzIHByb2JhYmx5IG1vcmUgdGhhbiBJJ2xsIGdl dCBkb25lIHRvZGF5IGJlZm9yZSB0aGUgc3VibWlzc2lvbiBjdXRvZmYuICBJIGFncmVlIHdpdGgg Sm9obiB0aGF0IGl0IHdvdWxkIGJlIHVzZWZ1bCB0byBoYXZlIGRpc2N1c3Npb25zIG9uIHRoaXMg aW4gUHJhZ3VlIG9uIHRoZSBiZXN0IHdheSB0byBhY2hpZXZlIHRoaXMgZnVydGhlciBpbnRlZ3Jh dGlvbi4gIEknbGwgcGxhbiB0byBjb21lIGludG8gdGhlIFByYWd1ZSBtZWV0aW5nIHdpdGggYSBj b25jcmV0ZSBwcm9wb3NhbCBmb3IgcmV2aWV3Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEJlc3Qgd2lzaGVzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBN aWtlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9h dXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBC ZWhhbGYgT2YgSm9obiBCcmFkbGV5DQpTZW50OiBNb25kYXksIEp1bHkgMDYsIDIwMTUgODoxMyBB TQ0KVG86IEJyaWFuIENhbXBiZWxsDQpDYzogb2F1dGgNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0dd IEpXVCBUb2tlbiBvbi1iZWhhbGYgb2YgVXNlIGNhc2UNCg0KWWVzIHVuZm9ydHVuYXRlbHkgd2Ug aGF2ZW7igJl0IG1hZGUgYW55IHByb2dyZXNzIG9uIHRoaXMgc2luY2UgYWNjZXB0aW5nIE1pa2Xi gJlzIGZpcnN0IGRyYWZ0Lg0KDQpIaXMgcHJvcG9zYWwgaXMgYmFzaWNhbGx5IGZvciBhIG5ldyBl bmRwb2ludCB3aGlsZSBCcmlhbiB0aXJlZCB0byBmaXQgaXQgaW50byB0aGUgZXhpc3RpbmcgdG9r ZW4gZW5kcG9pbnQuDQoNCkkgdGhpbmsgZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZS0w MSBzdGlsbCBoYXMgT25CZWhhbGZPZiBhbmQgQWN0QXMgcmV2ZXJzZWQgY29tcGFyZWQgdG8gV1Mt VHJ1c3QgMS40Lg0Kc2VlIGh0dHBzOi8vbXNkbi5taWNyb3NvZnQuY29tL2VuLXVzL2xpYnJhcnkv ZWU3NDg0ODcuYXNweCBmb3IgdGhlIHNob3J0IGV4cGxhbmF0aW9uLg0KDQpJIHRoaW5rIEJyaWFu IGlzIGNsb3NlciBpbiBleHBsYWluaW5nIGl0Lg0KDQpJbiBmYWlybmVzcyBiZWNhdXNlIFdTLVRy dXN0IG9yaWdpbmFsbHkgb25seSBoYWQgT24tQmVoYWxmLU9mIHRoZSBuYW1pbmcgYW5kIHdoYXQg cGVvcGxlIHB1dCBpbiB0b2tlbnMgaXMgYSBiaXQgbXVkZGxlZCBpbiBtYW55IGltcGxlbWVudGF0 aW9ucy4NCkkgdGhpbmsgbWFueSB0aW1lcyBpdCBpcyBob3cgV0lGIGltcGxlbWVudGVkIGl0IHRo YXQgcGVvcGxlIGNvcGllZC4NCg0KSXQgbWF5IGJlIGJldHRlciB0byBoYXZlIG5ldyB0ZXJtcyB0 aGF0IGFyZSBjbGVhciBzdWNoIGFzIGltcGVyc29uYXRpb24gYW5kIGNvbXBvc2l0ZS4NCg0KVGhl IFdHIG5lZWRzIHRvIGRlY2lkZSBpZiB0aGlzIGlzIGdvaW5nIHRvIGJlIGFuIGVudGlyZWx5IG5l dyBlbmRwb2ludCwgZnJlZSBvZiB0aGUgVG9rZW4gZW5kcG9pbnQgc2VtYW50aWNzLiAgIFRoZXJl IGFyZSBwbHVzc2VzIGFuZCBtaW51c2VzIHRvIGJvdGggb3B0aW9ucy4NCg0KQWxzbyB3aGlsZSBp dCBpcyBuaWNlIHRvIGJlIHB1cmUgYW5kIHRhbGsgYWJvdXQgYWJzdHJhY3Qgc2VjdXJpdHkgdG9r ZW5zLCBpdCB3b3VsZCBiZSBnb29kIHRvIGdpdmUgc29tZSBndWlkYW5jZSBvbiB3aGF0IGEgY29t cG9zaXRlIHNlY3VyaXR5IHRva2VuIHdvdWxkIGxvb2sgbGlrZSBmb3IgaW50ZXJvcGVyYWJpbGl0 eS4NCg0KVGhlcmUgYXJlIGFsc28gaXNzdWVzIGFyb3VuZCBob3cgdGhpcyB3b3VsZCB3b3JrIHdp dGggcHJvb2Ygb2YgcG9zc2Vzc2lvbiBzZWN1cml0eSB0b2tlbnMsIGJvdGggYXMgaW5wdXQgYW5k IG91dHB1dC4NCg0KUGVyaGFwcyB3ZSBjYW4gbWFrZSBzb21lIHByb2dyZXNzIG9uIHRoaXMgaW4g UHJhZ3VlLg0KDQpKb2huIEIuDQoNCg0KDQoNCj4gT24gSnVsIDYsIDIwMTUsIGF0IDExOjA0IEFN LCBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1w YmVsbEBwaW5naWRlbnRpdHkuY29tPj4gd3JvdGU6DQo+DQo+IFRoYW5rcyBTZXJnZXksDQo+DQo+ IFRoZSBnb2FsIG9mIGRyYWZ0LWNhbXBiZWxsLW9hdXRoLXN0cyB3YXMgdG8gYmUgY29uc2lzdGVu dCB3aXRoIE9BdXRoIDIuMCBhbmQgdGh1cyBob3BlZnVsbHkgZmFtaWxpYXIgdG8gZGV2ZWxvcGVy cyBhbmQgZWFzeSB0byB1bmRlcnN0YW5kIGFuZCBpbXBsZW1lbnQgKGVzcGVjaWFsbHkgZnJvbSB0 aGUgY2xpZW50IHNpZGUpLiBJdCdzIGFsc28gaW50ZW5kZWQgdG8gYmUgZmxleGlibGUgaW4gb3Jk ZXIgdG8gYWNjb21tb2RhdGUgYSB2YXJpZXR5IG9mIHVzZS1jYXNlcyBpbmNsdWRpbmcgdGhlIGNo YWluaW5nIHR5cGUgY2FzZXMgdGhhdCBKdXN0aW4ncyBkcmFmdCBjb3ZlcnMuDQo+DQo+IFNwZWNp ZnlpbmcgYSBzZWN1cml0eV90b2tlbl90eXBlIG9mIHRoZSByZXR1cm5lZCB0b2tlbiBpcyBqdXN0 IGEgd2F5IG9mIHByb3ZpZGluZyBtb3JlIGluZm8gdG8gdGhlIGNsaWVudCBhYm91dCB0aGUgdG9r ZW4gKGkuZS4gaXMgdGhpcyBhIEpXVCBvciBhIFNBTUwgdG9rZW4gb3Igc29tZXRoaW5nIGVsc2Up IHZpYSBhIFVSSS4gSXQncyBub3QgYWx3YXlzIG5lZWRlZCBidXQgaW4gU1RTIHN0eWxlIGNhc2Vz IHRoZSB0b2tlbnMgYXJlIG5vdCBhbHdheXMgb3BhcXVlIHRvIHRoZSBjbGllbnQgYW5kIHRoZSBw YXJhbWV0ZXIganVzdCBwcm92aWRlcyBpbmZvIGFib3V0IHRoZSByZXR1cm5lZCB0b2tlbi4NCj4N Cj4gT24gTW9uLCBKdWwgNiwgMjAxNSBhdCA1OjMzIEFNLCBTZXJnZXkgQmVyeW96a2luIDxzYmVy eW96a2luQGdtYWlsLmNvbTxtYWlsdG86c2JlcnlvemtpbkBnbWFpbC5jb20+PiB3cm90ZToNCj4g SGkgQnJpYW4NCj4NCj4gSSd2ZSByZWFkIHRoZSB0ZXh0LCBJIGxpa2UgaXQgaXMgc3RpbGwgcHVy ZSBPQXV0aDIsIHdpdGggZmV3IGV4dHJhIHBhcmFtZXRlcnMgYWRkZWQgdG8gdGhlIGFjY2VzcyB0 b2tlbiByZXF1ZXN0LCBhbmQgYSBrZXkgcmVzcG9uc2UgcHJvcGVydHkgYmVpbmcgJ2FjY2Vzc190 b2tlbicgYXMgb3Bwb3NlZCB0byAnc2VjdXJpdHlfYWNjZXNzX3Rva2VuJyBhcyBpbiB0aGUgZHJh ZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZS0wMS4NCj4gSXQgYXBwZWFycyBkcmFmdC1jYW1w YmVsbC1vYXV0aC1zdHMtMDEgY2FuIGNvdmVyIGEgZHJhZnQtcmljaGVyLW9hdXRoLWNoYWluLTAw IGNhc2Ugd2l0aCB0aGUgb25fYmVoYWxmX29mIChhbmQvb3IgYWN0X2FzID8pIHByb3BlcnR5IGJl aW5nIGFuIG9yaWdpbmFsIGNsaWVudCB0b2tlbiBidXQgbm90IDEwMCUgc3VyZSBnaXZlbiBkcmFm dC1yaWNoZXItb2F1dGgtY2hhaW4tMDAgY292ZXJzIGEgc3BlY2lmaWMgY2FzZS4NCj4NCj4gT25l IHRoaW5nIEknbSBub3Qgc3VyZSBhYm91dCBpcyB3aGF0IGlzIHRoZSBwdXJwb3NlIG9mIHNwZWNp ZnlpbmcgYQ0KPiBzZWN1cml0eV90b2tlbl90eXBlIG9mIHRoZSByZXR1cm5lZCBhY2Nlc3MgdG9r ZW4NCj4NCj4gVGhhbmtzLCBTZXJnZXkNCj4NCj4gT24gMDEvMDcvMTUgMTU6NTksIEJyaWFuIENh bXBiZWxsIHdyb3RlOg0KPiBPbmUgcHJvYmxlbSwgSSB0aGluaywgd2l0aCB0b2tlbiBleGNoYW5n ZSBpcyB0aGF0IGl0IGNhbiBiZSByZWFsbHkNCj4gc2ltcGxlICh0b2tlbiBpbiBhbmQgdG9rZW4g b3V0KSBhbmQgcmVhbGx5IGNvbXBsaWNhdGVkIChjbGllbnQgWCB3YW50cw0KPiBhIHRva2VuIHRo YXQgc2F5cyB1c2VyIEEgaXMgZG9pbmcgc29tZXRoaW5nIG9uIGJlaGFsZiBvZiB1c2VyIEIpIGF0 DQo+IHRoZSBzYW1lIHRpbWUuDQo+DQo+IEkgcHV0IGZvcnRoIGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1jYW1wYmVsbC1vYXV0aC1zdHMtMDEgaW4NCj4gYW4gYXR0ZW1wdCB0byBz aW1wbGlmeSB0aGluZ3MgYW5kIGV4cHJlc3Mgd2hhdCBJIGVudmlzaW9uZWQgYXMgYW4NCj4gT0F1 dGggYmFzZWQgdG9rZW4gZXhjaGFuZ2UgZnJhbWV3b3JrLiBUaG91Z2ggaXQgbGlrZWx5IG9ubHkg bXVkZGllZA0KPiB0aGUgd2F0ZXJzIDopDQo+DQo+IE9uIFdlZCwgSnVsIDEsIDIwMTUgYXQgNzow NyBBTSwgU2VyZ2V5IEJlcnlvemtpbiA8c2JlcnlvemtpbkBnbWFpbC5jb208bWFpbHRvOnNiZXJ5 b3praW5AZ21haWwuY29tPg0KPiA8bWFpbHRvOnNiZXJ5b3praW5AZ21haWwuY29tPG1haWx0bzpz YmVyeW96a2luQGdtYWlsLmNvbT4+PiB3cm90ZToNCj4NCj4gICAgIEhpIEp1c3Rpbg0KPg0KPiAg ICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJpY2hlci1vYXV0aC1jaGFpbi0w MCBpcyBtdWNoDQo+ICAgICBlYXNpZXIgdG8gcmVhZCwgdGhhdCBJIGNhbiB0ZWxsIGZvciBzdXJl LCBhdCBsZWFzdCBpdCBpcyBvYnZpb3VzIHdoeQ0KPiAgICAgYSBnaXZlbiBlbnRpdHkgKFJTMSkg bWF5IHdhbnQgdG8gZXhjaGFuZ2UgdGhlIGN1cnJlbnQgdG9rZW4gcHJvdmlkZWQNCj4gICAgIGJ5 IGEgY2xpZW50IGZvciBhIG5ldyB0b2tlbi4gRGVmaW5pdGVseSBlYXNpbHkgaW1wbGVtZW50YWJs ZS4uLg0KPg0KPiAgICAgT25lIHRoaW5nIEknbSBub3Qgc3VyZSBpbiB0aGUgZHJhZnQtcmljaGVy LW9hdXRoLWNoYWluLTAwIGFib3V0IGlzDQo+ICAgICBvbiBiZWhhbGYgb2Ygd2hvc2UgZW50aXR5 IFJTMSB3aWxsIGJlIGFjdGluZyBvbmNlIGl0IHN0YXJ0cw0KPiAgICAgYWNjZXNzaW5nIFJTMiwg T24gQmVoYWxmIE9mIFJPLCBvciBtYXkgYmUgT24gQmVoYWxmIE9mIChSTyArDQo+ICAgICBDbGll bnQpLCBvciBtYXkgYmUgaXQgaXMgT24gQmVoYWxmIE9mIFJPICsgQWN0IEFzIENsaWVudCA/IFRo ZSBsYXN0DQo+ICAgICBvbmUgc2VlbXMgbW9zdCBsb2dpY2FsIHRvIG1lLi4uDQo+DQo+ICAgICBU aGFua3MsIFNlcmdleQ0KPg0KPg0KPiAgICAgT24gMDEvMDcvMTUgMTM6MTgsIEp1c3RpbiBSaWNo ZXIgd3JvdGU6DQo+DQo+ICAgICAgICAgQXMgaXQncyB3cml0dGVuIHJpZ2h0IG5vdywgaXQncyBh IHRyYW5zbGF0aW9uIG9mIHNvbWUgV1MtKg0KPiAgICAgICAgIGNvbmNlcHRzIGludG8NCj4gICAg ICAgICBKV1QgZm9ybWF0LiBJdCdzIG5vdCByZWFsbHkgT0F1dGgteSAoc2luY2UgdGhlIGNsaWVu dCBoYXMgdG8NCj4gICAgICAgICB1bmRlcnN0YW5kDQo+ICAgICAgICAgdGhlIHRva2VuIGZvcm1h dCBhbG9uZyB3aXRoIGV2ZXJ5b25lIGVsc2UsIGFuZCBhY2NvcmRpbmcgdG8gdGhlDQo+ICAgICAg ICAgYXV0aG9ycw0KPiAgICAgICAgIHRoZSBhcnRpZmFjdHMgbWlnaHQgbm90IGV2ZW4gYmUgIk9B dXRoIHRva2VucyIpLCBhbmQgdGhhdCdzIG15IG1haW4NCj4gICAgICAgICBpc3N1ZSB3aXRoIHRo ZSBkb2N1bWVudC4gWWVhcnMgYWdvLCBJIHByb3Bvc2VkIGFuIE9BdXRoLWJhc2VkDQo+ICAgICAg ICAgdG9rZW4gc3dhcA0KPiAgICAgICAgIG1lY2hhbmlzbToNCj4NCj4gICAgICAgICBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmljaGVyLW9hdXRoLWNoYWluLTAwDQo+DQo+ICAg ICAgICAgVGhpcyB3b3JrcyB3aXRob3V0IGRlZmluaW5nIHNlbWFudGljcyBvZiB0aGUgdG9rZW5z IHRoZW1zZWx2ZXMsIGp1c3QNCj4gICAgICAgICBsaWtlIHRoZSByZXN0IG9mIE9BdXRoLiBJJ3Zl IHByb3Bvc2VkIHRvIHRoZSBhdXRob3JzIG9mIHRoZSBjdXJyZW50DQo+ICAgICAgICAgZHJhZnQg dGhhdCBpdCBzaG91bGQgaW5jb3Jwb3JhdGUgYm90aCBzZW1hbnRpYyAodXNpbmcgSldUKSBhbmQN Cj4gICAgICAgICBzeW50YWN0aWMNCj4gICAgICAgICAodXNpbmcgYSBzaW1wbGUgdG9rZW4tYWdu b3N0aWMgZ3JhbnQpIHRva2VuIHN3YXAgbWVjaGFuaXNtcywgYW5kDQo+ICAgICAgICAgdGhhdA0K PiAgICAgICAgIHRoZSB0d28gY291bGQgYmUgZWFzaWx5IGNvbXBhdGlibGUuDQo+DQo+ICAgICAg ICAgICAgLS0gSnVzdGluDQo+DQo+ICAgICAgICAgT24gNy8xLzIwMTUgNjozNSBBTSwgU2VyZ2V5 IEJlcnlvemtpbiB3cm90ZToNCj4NCj4gICAgICAgICAgICAgSG1tLi4uIHBlcmhhcHMgdGhlIGNs dWUgaXMgaW4gdGhlIGRyYWZ0IHRpdGxlLA0KPiAgICAgICAgICAgICB0b2tlbi1leGNoYW5nZSwg c28gbWF5DQo+ICAgICAgICAgICAgIGJlIGl0IGlzIGEgY2FzZSBvZiB0aGUgZ2l2ZW4gYWNjZXNz IHRva2VuICgib25fYmVoYWxmX29mIiBvcg0KPiAgICAgICAgICAgICAiYWN0X2FzIg0KPiAgICAg ICAgICAgICBjbGFpbSkgYmVpbmcgdXNlZCB0byByZXF1ZXN0IGEgbmV3IHNlY3VyaXR5IHRva2Vu LiBPbmUgY2FuDQo+ICAgICAgICAgICAgIG9ubHkgZ3Vlc3MNCj4gICAgICAgICAgICAgdGhvdWdo LCBkb2VzIG5vdCBzZWVtIGxpa2UgdGhlIGF1dGhvcnMgYXJlIGtlZW4gdG8gYW5zd2VyDQo+ICAg ICAgICAgICAgIHRoZSBuZXdiaWUNCj4gICAgICAgICAgICAgcXVlc3Rpb25zLi4uDQo+DQo+ICAg ICAgICAgICAgIENoZWVycywgU2VyZ2V5DQo+DQo+DQo+ICAgICAgICAgICAgIE9uIDMwLzA2LzE1 IDEzOjM4LCBTZXJnZXkgQmVyeW96a2luIHdyb3RlOg0KPg0KPiAgICAgICAgICAgICAgICAgSGks DQo+ICAgICAgICAgICAgICAgICBDYW4geW91IHBsZWFzZSBleHBsYWluIHdoYXQgaXMgdGhlIGRp ZmZlcmVuY2UgYmV0d2Vlbg0KPiAgICAgICAgICAgICAgICAgT24tQmVoYWxmLU9mDQo+ICAgICAg ICAgICAgICAgICBzZW1hbnRpY3MgZGVzY3JpYmVkIGluIHRoZQ0KPiAgICAgICAgICAgICAgICAg ZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZS0wMSBhbmQgdGhlDQo+ICAgICAgICAgICAg ICAgICBpbXBsaWNpdCBPbi1CZWhhbGYtT2Ygc2VtYW50aWNzIGEgY2xpZW50IE9BdXRoMiB0b2tl bg0KPiAgICAgICAgICAgICAgICAgcG9zc2Vzc2VzID8NCj4NCj4gICAgICAgICAgICAgICAgIEZv ciBleGFtcGxlLCBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTAxIG1lbnRpb25zOg0K Pg0KPiAgICAgICAgICAgICAgICAgIldoZXJlYXMsIHdpdGggb24tYmVoYWxmLW9mIHNlbWFudGlj cywgcHJpbmNpcGFsIEEgc3RpbGwNCj4gICAgICAgICAgICAgICAgIGhhcyBpdHMgb3duDQo+ICAg ICAgICAgICAgICAgICBpZGVudGl0eSBzZXBhcmF0ZSBmcm9tIEIgYW5kIGl0IGlzIGV4cGxpY2l0 bHkgdW5kZXJzdG9vZA0KPiAgICAgICAgICAgICAgICAgdGhhdCB3aGlsZSBCDQo+ICAgICAgICAg ICAgICAgICBtYXkgaGF2ZSBkZWxlZ2F0ZWQgaXRzIHJpZ2h0cyB0byBBLCBhbnkgYWN0aW9ucyB0 YWtlbg0KPiAgICAgICAgICAgICAgICAgYXJlIGJlaW5nIHRha2VuIGJ5DQo+ICAgICAgICAgICAg ICAgICBBIGFuZCBub3QgQi4gSW4gYSBzZW5zZSwgQSBpcyBhbiBhZ2VudCBmb3IgQi4iDQo+DQo+ ICAgICAgICAgICAgICAgICBUaGlzIGlzIGEgdHlwaWNhbCBjYXNlIHdpdGggdGhlIGF1dGhvcml6 YXRpb24gY29kZSBmbG93DQo+ICAgICAgICAgICAgICAgICB3aGVyZSBhIGNsaWVudA0KPiAgICAg ICAgICAgICAgICAgYXBwbGljYXRpb24gYWN0cyBvbi1iZWhhbGYtb2YgdGhlIHVzZXIgd2hvIGF1 dGhvcml6ZWQNCj4gICAgICAgICAgICAgICAgIHRoaXMgYXBwbGljYXRpb24gPw0KPg0KPiAgICAg ICAgICAgICAgICAgU29ycnkgaWYgSSdtIG1pc3Npbmcgc29tZXRoaW5nDQo+DQo+ICAgICAgICAg ICAgICAgICBDaGVlcnMsIFNlcmdleQ0KPiAgICAgICAgICAgICAgICAgT24gMjUvMDYvMTUgMjI6 MjgsIE1pa2UgSm9uZXMgd3JvdGU6DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgVGhhdOKAmXMg d2hhdA0KPiAgICAgICAgICAgICAgICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTAxDQo+ICAgICAgICAgICAgICAgICAgICAg aXMNCj4gICAgICAgICAgICAgICAgICAgICBhYm91dC4NCj4NCj4gICAgICAgICAgICAgICAgICAg ICBDaGVlcnMsDQo+DQo+ICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KPg0KPiAgICAgICAg ICAgICAgICAgICAgICpGcm9tOipPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+DQo+ICAgICAgICAgICAgICAgICAgICAgPG1h aWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3Jn Pj5dICpPbiBCZWhhbGYgT2YgKlZpdmVrDQo+ICAgICAgICAgICAgICAgICAgICAgQmlzd2FzDQo+ ICAgICAgICAgICAgICAgICAgICAgLVQgKHZpYmlzd2FzIC0gWE9SSUFOVCBDT1JQT1JBVElPTiBh dCBDaXNjbykNCj4gICAgICAgICAgICAgICAgICAgICAqU2VudDoqIFRodXJzZGF5LCBKdW5lIDI1 LCAyMDE1IDI6MjAgUE0NCj4gICAgICAgICAgICAgICAgICAgICAqVG86KiBPQXV0aEBpZXRmLm9y ZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+IDxtYWlsdG86T0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9B dXRoQGlldGYub3JnPj4NCj4gICAgICAgICAgICAgICAgICAgICAqU3ViamVjdDoqIFtPQVVUSC1X R10gSldUIFRva2VuIG9uLWJlaGFsZiBvZiBVc2UNCj4gY2FzZQ0KPg0KPiAgICAgICAgICAgICAg ICAgICAgIEhpIEFsbCwNCj4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgSSBhbSBsb29raW5n IHRvIHNvbHZlIGEgdXNlLWNhc2Ugc2ltaWxhciB0bw0KPiAgICAgICAgICAgICAgICAgICAgIFdT LVNlY3VyaXR5IE9uLUJlaGFsZi1PZg0KPg0KPiA8aHR0cDovL2RvY3Mub2FzaXMtb3Blbi5vcmcv d3Mtc3gvd3MtdHJ1c3QvdjEuNC9lcnJhdGEwMS9vcy93cy10cnVzdC0xDQo+IC40LWVycmF0YTAx LW9zLWNvbXBsZXRlLmh0bWwjX1RvYzMyNTY1ODk4MD4NCj4NCj4NCj4gICAgICAgICAgICAgICAg ICAgICB3aXRoIE9BdXRoIEpXVCBUb2tlbi4NCj4NCj4gICAgICAgICAgICAgICAgICAgICAgICAg SXMgdGhlcmUgYSBzdGFuZGFyZCBjbGFpbSB3aGljaCB3ZSBjYW4gZGVmaW5lDQo+ICAgICAgICAg ICAgICAgICAgICAgd2l0aGluIHRoZSBPQXV0aCBKV1QNCj4gICAgICAgICAgICAgICAgICAgICB3 aGljaCBkZW5vdGUgdGhlIE9uLWJlaGFsZi1vZiBVc2VyLg0KPg0KPiAgICAgICAgICAgICAgICAg ICAgIEZvciBlLmcuLCBhIEN1c3RvbWVyIFJlcHJlc2VudGF0aXZlIHRyeWluZyB0byBjcmVhdGUN Cj4gICAgICAgICAgICAgICAgICAgICB0b2tlbiBvbiBiZWhhbGYgb2YNCj4gICAgICAgICAgICAg ICAgICAgICBhIGN1c3RvbWVyIGFuZCB0cnlpbmcgdG8gZXhlY3V0ZSBzZXJ2aWNlcyBzcGVjaWZp Yw0KPiAgICAgICAgICAgICAgICAgICAgIGZvciB0aGF0IHNwZWNpZmljDQo+ICAgICAgICAgICAg ICAgICAgICAgY3VzdG9tZXIuDQo+DQo+ICAgICAgICAgICAgICAgICAgICAgUmVnYXJkcywNCj4N Cj4gICAgICAgICAgICAgICAgICAgICBWaXZlayBCaXN3YXMsDQo+ICAgICAgICAgICAgICAgICAg ICAgQ0lTU1ANCj4NCj4gICAgICAgICAgICAgICAgICAgICAqQ2lzY28gU3lzdGVtcywgSW5jIDxo dHRwOi8vd3d3LmNpc2NvLmNvbS8+Kg0KPg0KPiAgICAgICAgICAgICAgICAgICAgICpCbGRnLiBK LCBTYW4gSm9zZSwgVVNBLCoNCj4NCj4gICAgICAgICAgICAgICAgICAgICAqUGhvbmU6ICsxIDQw OCA1MjcgOTE3Njx0ZWw6JTJCMSUyMDQwOCUyMDUyNyUyMDkxNzY+DQo+IDx0ZWw6JTJCMSUyMDQw OCUyMDUyNyUyMDkxNzY+Kg0KPg0KPg0KPg0KPiAgICAgICAgICAgICAgICAgICAgIF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAgICAgICAgICAgICAg ICAgICAgT0F1dGggbWFpbGluZyBsaXN0DQo+ICAgICAgICAgICAgICAgICAgICAgT0F1dGhAaWV0 Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPiA8bWFpbHRvOk9BdXRoQGlldGYub3JnPG1haWx0 bzpPQXV0aEBpZXRmLm9yZz4+DQo+ICAgICAgICAgICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPg0KPg0KPg0KPiAgICAgICAgICAgICBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAgICAgICAg ICBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gICAgICAgICAgICAgT0F1dGhAaWV0Zi5vcmc8bWFpbHRv Ok9BdXRoQGlldGYub3JnPiA8bWFpbHRvOk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRm Lm9yZz4+DQo+ICAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGgNCj4NCj4NCj4gICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiAgICAgICAgIE9BdXRoIG1haWxpbmcgbGlzdA0KPiAgICAgICAg IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4gPG1haWx0bzpPQXV0aEBpZXRm Lm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+Pg0KPiAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4NCj4NCj4gICAgIF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAgICBPQXV0aCBtYWlsaW5nIGxpc3QN Cj4gICAgIE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4gPG1haWx0bzpPQXV0 aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+Pg0KPiAgICAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPg0KPg0KPg0KPg0KPg0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPQXV0aCBtYWlsaW5nIGxp c3QNCj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGll dGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGgNCg0K --_000_BY2PR03MB442D6CB1EB8C2C503710279F5930BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5GYWlyIGVub3VnaCwgQnJpYW4uJm5ic3A7IEZvciBjbGFyaXR5LCBteSBzZW5zZSBvZiB0 aGUgYWN0aW9uIGl0ZW1zIGlzIHRoYXQgSSBhZ3JlZWQgdG8gZG8gdGhvc2UgYWN0aW9ucyBiYXNl ZCBvbiBmZWVkYmFjayBhdCB0aGUgYWQtaG9jIG1lZXRpbmcgYW5kIHRoZW4gcGVvcGxlDQogd291 bGQgcmV2aWV3IHRoZSByZXN1bHQg4oCTIG5vdCB0aGF0IGV2ZXJ5dGhpbmcgd291bGQgYmUg4oCc ZG9uZeKAnSBhZnRlciB0YWtpbmcgdGhvc2UgYWN0aW9ucy4mbmJzcDsgSeKAmWxsIHN0aWxsIHBs YW4gdG8gYWN0IG9uIHRoYXQgZmVlZGJhY2suPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J4oCZZCBiZSBnbGFkIHRvIHNp dCBkb3duIHdpdGggeW91IGFuZCBvdGhlcnMgaW4gUHJhZ3VlLCBCcmlhbiwgdG8gd29yayBvdXQg aG93IHRvIG1ha2Ugc3VyZSB5b3VyIHVzZSBjYXNlcyBhcmUgY292ZXJlZCBhbmQgdGhlIGRyYWZ0 IGlzIGFzIGNsZWFyIGFzIGl0IGNhbiBiZSwNCiBnaXZlbiBpdHMgc29tZXdoYXQgZXNvdGVyaWMg c3ViamVjdCBtYXR0ZXIuJm5ic3A7IE5vdyB0aGF0IEpXVCBhbmQgSk9TRSBhbmQgdGhlIE9BdXRo IEFzc2VydGlvbnMgc3BlY3MgYXJlIGRvbmUgYW5kIHNldmVyYWwgb3RoZXJzIGFyZSBuZWFybHkg ZG9uZSwgZ2V0dGluZyBiYWNrIHRvIHRoaXMgaXMgYSBwcmlvcml0eSBmb3IgbWUuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgQ2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4gQnJpYW4gQ2FtcGJlbGwgW21haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbV0NCjxi cj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1bHkgMDYsIDIwMTUgMTE6MjkgQU08YnI+DQo8Yj5U bzo8L2I+IE1pa2UgSm9uZXM8YnI+DQo8Yj5DYzo8L2I+IEpvaG4gQnJhZGxleTsgb2F1dGg8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gSldUIFRva2VuIG9uLWJlaGFsZiBvZiBV c2UgY2FzZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+U3RhdGluZyBzcGVjaWZpYyBh Y3Rpb24gaXRlbXMgcmVzdWx0aW5nIGZyb20gdGhlIGFkLWhvYyBtZWV0aW5nIGluIERhbGxhcyBs aWtlIHRoYXQgc3VnZ2VzdHMgc29tZSBjbGVhciBjb25zZW5zdXMgd2FzIHJlYWNoZWQsIHdoaWNo IGlzIG5vdCBhdCBhbGwgdGhlIGNhc2UuIEFzIEkgcmVjYWxsLCBzZXZlcmFsIG9mIHVzIGFyZ3Vl ZCBwYXN0IG9uZSBhbm90aGVyDQogZm9yIGFuIGhvdXIgb3Igc28gYW5kIGRlY2lkZWQgdG8gYWRq b3VybiBpbiBvcmRlciB0byBnbyB0byB0aGUgYmFyIChva2F5LCBhbmQgZGlubmVyIHRvbyAtIGJ1 dCBtb3N0bHkgYmVlcikuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhlIGltcHJlc3Npb24gYWJvdXQgcmV2 ZXJzYWwgb2YgdGVybXMsIEkgdGhpbmssIGNvbWVzIGZyb20gdGhlIHRleHQgaW4NCjxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hh bmdlLTAxI3NlY3Rpb24tMS4zIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZS0wMSNzZWN0aW9uLTEuMzwv YT4gd2hpY2ggaHVydHMgbXkgaGVhZCBhIGxpdHRsZSBldmVyeS10aW1lIEkgcmVhZCBpdCBidXQg ZG9lcyBzZWVtcyB0byBjb25mdXNlIHRoaW5ncy4gVGhlDQo8YSBocmVmPSJodHRwczovL21zZG4u bWljcm9zb2Z0LmNvbS9lbi11cy9saWJyYXJ5L2VlNzQ4NDg3LmFzcHgiIHRhcmdldD0iX2JsYW5r Ij4NCk1TRE4gbGluazwvYT4gSm9obiBnYXZlIGlzIG11Y2ggbW9yZSB0byB0aGUgcG9pbnQgdGhh biBXUy1UcnVzdCAoSSBkb24ndCBiZWxpZXZlIFdTLVRydXN0IGNhbiBiZSBwb2ludGVkIHRvIGFz IGEgbW9kZWwgb2YgY2xhcml0eSkuJm5ic3A7IEluIHRoZSBkcmFmdCBJIHdyb3RlLCBJIHRyaWVk IHRvIHRha2UgTWlrZSdzIHRleHQgYW5kIGNsYXJpZnkgYSBkaXN0aW5jdGlvbiBiZXR3ZWVuIGlt cGVyc29uYXRpb24gYW5kIGRlbGVnYXRpb24gd2l0aA0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWNhbXBiZWxsLW9hdXRoLXN0cy0wMSNzZWN0aW9uLTEuMyIgdGFy Z2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhbXBiZWxs LW9hdXRoLXN0cy0wMSNzZWN0aW9uLTEuMzwvYT4gYW5kIHRoZW4gYWxzbyBiZSB2ZXJ5IGV4cGxp Y2l0IGFib3V0IGFjdC1hcyB2cy4gb24tYmVoYWxmLW9mIGluIHRoZSBwYXJhbWV0ZXIgZGVmaW5p dGlvbnMgYXQNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW1w YmVsbC1vYXV0aC1zdHMtMDEjc2VjdGlvbi0yIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2FtcGJlbGwtb2F1dGgtc3RzLTAxI3NlY3Rpb24tMjwv YT4gaW4gYSBtYW5vciB0aGF0IHdhcyBjb25zaXN0ZW50IHdpdGggV1MtVHJ1c3QgYW5kIHRoZSBN U0ROIGV4cGxhbmF0aW9uLiBJIGNvdWxkIHNlZSB2YWx1ZSBpbiBicmVha2luZyB3aXRoIHRoYXQg c2hha3kgbGVnYWN5IGFuZCB1c2luZyBuZXcgdGVybXMgdG9vLiBCdXQgSSBnZXQgdGhlIHBvaW50 IG9mIHRyeWluZyB0byBrZWVwDQogd2l0aCB0aGUgb2xkIGFsc28gYW5kIHBvdGVudGlhbCBmb3Ig ZXZlbiBtb3JlIGNvbmZ1c2luZyBieSB1c2luZyBuZXcgdGVybXMuIDxvOnA+DQo8L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+SSB3cm90ZSBkcmFmdC1jYW1wYmVsbC1vYXV0aC1zdHMgbGFzdCB5ZWFyIGluIHJlc3BvbnNl IHRvIHRoZSBjYWxsIGZvciBhZG9wdGlvbiBvZiBqb25lcy1vYXV0aC10b2tlbi1leGNoYW5nZSAo PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJy ZW50L21zZzEzMzA1Lmh0bWwiIHRhcmdldD0iX2JsYW5rIj50aHJlYWQNCiBmcm9tIHRoZSBhcmNo aXZlPC9hPikuIFRob3VnaCBJIGRpZG4ndCB0cnkgYW5kIHN0YW5kIGluIHRoZSB3YXkgYW5kIGlu ZGljYXRlZCBhIHdpbGxpbmduZXNzIHRvIGNvbGxhYm9yYXRlIG9uIHRoaW5ncy4gV2l0aCB0aGUg ZXhwZWN0YXRpb24sIG9mIGNvdXJzZSwgdGhhdCB0aGUgZGV0YWlscyB3b3VsZCBkaWZmZXIgZnJv bSB0aGUgLTAwcyBhbmQgLTAxcyBhcyB3b3JrIHByb2dyZXNzZWQuIEZvbGtzIHNlZW1lZA0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50 L21zZzEzMzA4Lmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmdlbmVyYWxseSBhbWVuYWJsZSB0byB0 aGF0PC9hPiBhdCB0aGUgdGltZSBidXQgbGl0dGxlIGhhcyBoYXBwZW5lZCBzaW5jZSB0aGVuLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGhpbCdz IGVhcmxpZXIgcG9pbnQgYWJvdXQgdGhlIHByaW9yeSBvZiB0aGlzIGdldHRpbmcgcHVzaGVkIGRv d24gaGFzIHNvbWUgdHJ1dGggdG8gaXQuIEJ1dCBJIHN0aWxsIGJlbGlldmUgaXQncyBzb21ldGhp bmcgdGhhdCBjYW4gcHJvdmlkZSBhIGxvdCBvZiB2YWx1ZSBpbiBzdGFuZGFyZGl6aW5nLCBpZiB3 ZSBkbyBzbyBpbiBhIHJlYXNvbmFibGUgd2F5Lg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIE1vbiwgSnVsIDYsIDIwMTUgYXQgMTA6MzMgQU0sIE1pa2UgSm9uZXMg Jmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0i X2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHdvdWxkIHN1cnByaXNlIG1lIGlmIG9u LWJlaGFsZi1vZiBhbmQgYWN0LWFzIHdlcmUgcmV2ZXJzZWQgd2l0aCByZXNwZWN0IFdTLVRydXN0 LCBiZWNhdXNlIHRoZSBleHBsYW5hdGlvbnMgb2YgdGhlIHRlcm1zIGNhbWUgZGlyZWN0bHkgZnJv bSBXUy1UcnVzdCAxLjQuJm5ic3A7IEkgYWxzbyB0aGluayB0aGUgY2hhbmNlcyBvZiB1cyByZWR1 Y2luZyBjb25mdXNpb24gYnkgaW52ZW50aW5nIG5ldyB0ZXJtaW5vbG9neSwNCiByYXRoZXIgdGhh biBhZGRpbmcgdG8gaXQsIHdvdWxkIG5vdCBiZSBpbiBvdXIgZmF2b3IuIDotLzxicj4NCjxicj4N CkZZSSwgdGhlIGFjdGlvbiBpdGVtcyBvdXRzdGFuZGluZyBmcm9tIG91ciBhZC1ob2MgbWVldGlu ZyBvbiB0aGlzIGRyYWZ0IGluIERhbGxhcyBhcmU6PGJyPg0KJm5ic3A7IC0gQWxsb3dpbmcgc2Vj dXJpdHkgdHlwZXMgb3RoZXIgdGhhbiBKV1QgdG8gYWxzbyBiZSB1c2VkIGFzIHRoZSBhY3RfYXMg YW5kIG9uX2JlaGFsZl9vZiByZXF1ZXN0IHZhbHVlcy48YnI+DQombmJzcDsgLSBGdXJ0aGVyIGlu dGVncmF0aW5nIHRoZSBtZWNoYW5pc20gaW50byB0aGUgZXhpc3RpbmcgT0F1dGggZWNvc3lzdGVt IC0gYWxsb3dpbmcgdXNlIG9mIGFjY2VzcyB0b2tlbnMgb3IgcmVmcmVzaCB0b2tlbnMgd2hlbiBh cHByb3ByaWF0ZS48YnI+DQo8YnI+DQpJIHBsYW4gdG8gZG8gdGhlIGZpcnN0IHRvZGF5LiZuYnNw OyBUaGUgc2Vjb25kIGlzIHByb2JhYmx5IG1vcmUgdGhhbiBJJ2xsIGdldCBkb25lIHRvZGF5IGJl Zm9yZSB0aGUgc3VibWlzc2lvbiBjdXRvZmYuJm5ic3A7IEkgYWdyZWUgd2l0aCBKb2huIHRoYXQg aXQgd291bGQgYmUgdXNlZnVsIHRvIGhhdmUgZGlzY3Vzc2lvbnMgb24gdGhpcyBpbiBQcmFndWUg b24gdGhlIGJlc3Qgd2F5IHRvIGFjaGlldmUgdGhpcyBmdXJ0aGVyIGludGVncmF0aW9uLiZuYnNw OyBJJ2xsIHBsYW4NCiB0byBjb21lIGludG8gdGhlIFByYWd1ZSBtZWV0aW5nIHdpdGggYSBjb25j cmV0ZSBwcm9wb3NhbCBmb3IgcmV2aWV3Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBCZXN0IHdpc2hlcyw8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLS0gTWlr ZTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IE9BdXRoIFttYWlsdG86PGEg aHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPm9hdXRoLWJvdW5jZXNAaWV0Zi5v cmc8L2E+XSBPbiBCZWhhbGYgT2YgSm9obiBCcmFkbGV5PGJyPg0KU2VudDogTW9uZGF5LCBKdWx5 IDA2LCAyMDE1IDg6MTMgQU08YnI+DQpUbzogQnJpYW4gQ2FtcGJlbGw8YnI+DQpDYzogb2F1dGg8 YnI+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBKV1QgVG9rZW4gb24tYmVoYWxmIG9mIFVzZSBj YXNlPGJyPg0KPGJyPg0KWWVzIHVuZm9ydHVuYXRlbHkgd2UgaGF2ZW7igJl0IG1hZGUgYW55IHBy b2dyZXNzIG9uIHRoaXMgc2luY2UgYWNjZXB0aW5nIE1pa2XigJlzIGZpcnN0IGRyYWZ0Ljxicj4N Cjxicj4NCkhpcyBwcm9wb3NhbCBpcyBiYXNpY2FsbHkgZm9yIGEgbmV3IGVuZHBvaW50IHdoaWxl IEJyaWFuIHRpcmVkIHRvIGZpdCBpdCBpbnRvIHRoZSBleGlzdGluZyB0b2tlbiBlbmRwb2ludC48 YnI+DQo8YnI+DQpJIHRoaW5rIGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMDEgc3Rp bGwgaGFzIE9uQmVoYWxmT2YgYW5kIEFjdEFzIHJldmVyc2VkIGNvbXBhcmVkIHRvIFdTLVRydXN0 IDEuNC48YnI+DQpzZWUgPGEgaHJlZj0iaHR0cHM6Ly9tc2RuLm1pY3Jvc29mdC5jb20vZW4tdXMv bGlicmFyeS9lZTc0ODQ4Ny5hc3B4IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL21zZG4ubWlj cm9zb2Z0LmNvbS9lbi11cy9saWJyYXJ5L2VlNzQ4NDg3LmFzcHg8L2E+IGZvciB0aGUgc2hvcnQg ZXhwbGFuYXRpb24uPGJyPg0KPGJyPg0KSSB0aGluayBCcmlhbiBpcyBjbG9zZXIgaW4gZXhwbGFp bmluZyBpdC48YnI+DQo8YnI+DQpJbiBmYWlybmVzcyBiZWNhdXNlIFdTLVRydXN0IG9yaWdpbmFs bHkgb25seSBoYWQgT24tQmVoYWxmLU9mIHRoZSBuYW1pbmcgYW5kIHdoYXQgcGVvcGxlIHB1dCBp biB0b2tlbnMgaXMgYSBiaXQgbXVkZGxlZCBpbiBtYW55IGltcGxlbWVudGF0aW9ucy48YnI+DQpJ IHRoaW5rIG1hbnkgdGltZXMgaXQgaXMgaG93IFdJRiBpbXBsZW1lbnRlZCBpdCB0aGF0IHBlb3Bs ZSBjb3BpZWQuPGJyPg0KPGJyPg0KSXQgbWF5IGJlIGJldHRlciB0byBoYXZlIG5ldyB0ZXJtcyB0 aGF0IGFyZSBjbGVhciBzdWNoIGFzIGltcGVyc29uYXRpb24gYW5kIGNvbXBvc2l0ZS48YnI+DQo8 YnI+DQpUaGUgV0cgbmVlZHMgdG8gZGVjaWRlIGlmIHRoaXMgaXMgZ29pbmcgdG8gYmUgYW4gZW50 aXJlbHkgbmV3IGVuZHBvaW50LCBmcmVlIG9mIHRoZSBUb2tlbiBlbmRwb2ludCBzZW1hbnRpY3Mu Jm5ic3A7ICZuYnNwO1RoZXJlIGFyZSBwbHVzc2VzIGFuZCBtaW51c2VzIHRvIGJvdGggb3B0aW9u cy48YnI+DQo8YnI+DQpBbHNvIHdoaWxlIGl0IGlzIG5pY2UgdG8gYmUgcHVyZSBhbmQgdGFsayBh Ym91dCBhYnN0cmFjdCBzZWN1cml0eSB0b2tlbnMsIGl0IHdvdWxkIGJlIGdvb2QgdG8gZ2l2ZSBz b21lIGd1aWRhbmNlIG9uIHdoYXQgYSBjb21wb3NpdGUgc2VjdXJpdHkgdG9rZW4gd291bGQgbG9v ayBsaWtlIGZvciBpbnRlcm9wZXJhYmlsaXR5Ljxicj4NCjxicj4NClRoZXJlIGFyZSBhbHNvIGlz c3VlcyBhcm91bmQgaG93IHRoaXMgd291bGQgd29yayB3aXRoIHByb29mIG9mIHBvc3Nlc3Npb24g c2VjdXJpdHkgdG9rZW5zLCBib3RoIGFzIGlucHV0IGFuZCBvdXRwdXQuPGJyPg0KPGJyPg0KUGVy aGFwcyB3ZSBjYW4gbWFrZSBzb21lIHByb2dyZXNzIG9uIHRoaXMgaW4gUHJhZ3VlLjxicj4NCjxi cj4NCkpvaG4gQi48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQomZ3Q7IE9uIEp1bCA2LCAy MDE1LCBhdCAxMTowNCBBTSwgQnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2Ft cGJlbGxAcGluZ2lkZW50aXR5LmNvbSI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+Jmd0 OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGFua3MgU2VyZ2V5LDxicj4NCiZndDs8YnI+ DQomZ3Q7IFRoZSBnb2FsIG9mIGRyYWZ0LWNhbXBiZWxsLW9hdXRoLXN0cyB3YXMgdG8gYmUgY29u c2lzdGVudCB3aXRoIE9BdXRoIDIuMCBhbmQgdGh1cyBob3BlZnVsbHkgZmFtaWxpYXIgdG8gZGV2 ZWxvcGVycyBhbmQgZWFzeSB0byB1bmRlcnN0YW5kIGFuZCBpbXBsZW1lbnQgKGVzcGVjaWFsbHkg ZnJvbSB0aGUgY2xpZW50IHNpZGUpLiBJdCdzIGFsc28gaW50ZW5kZWQgdG8gYmUgZmxleGlibGUg aW4gb3JkZXIgdG8gYWNjb21tb2RhdGUgYSB2YXJpZXR5DQogb2YgdXNlLWNhc2VzIGluY2x1ZGlu ZyB0aGUgY2hhaW5pbmcgdHlwZSBjYXNlcyB0aGF0IEp1c3RpbidzIGRyYWZ0IGNvdmVycy48YnI+ DQomZ3Q7PGJyPg0KJmd0OyBTcGVjaWZ5aW5nIGEgc2VjdXJpdHlfdG9rZW5fdHlwZSBvZiB0aGUg cmV0dXJuZWQgdG9rZW4gaXMganVzdCBhIHdheSBvZiBwcm92aWRpbmcgbW9yZSBpbmZvIHRvIHRo ZSBjbGllbnQgYWJvdXQgdGhlIHRva2VuIChpLmUuIGlzIHRoaXMgYSBKV1Qgb3IgYSBTQU1MIHRv a2VuIG9yIHNvbWV0aGluZyBlbHNlKSB2aWEgYSBVUkkuIEl0J3Mgbm90IGFsd2F5cyBuZWVkZWQg YnV0IGluIFNUUyBzdHlsZSBjYXNlcyB0aGUgdG9rZW5zIGFyZSBub3QgYWx3YXlzDQogb3BhcXVl IHRvIHRoZSBjbGllbnQgYW5kIHRoZSBwYXJhbWV0ZXIganVzdCBwcm92aWRlcyBpbmZvIGFib3V0 IHRoZSByZXR1cm5lZCB0b2tlbi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiBNb24sIEp1bCA2LCAy MDE1IGF0IDU6MzMgQU0sIFNlcmdleSBCZXJ5b3praW4gJmx0OzxhIGhyZWY9Im1haWx0bzpzYmVy eW96a2luQGdtYWlsLmNvbSI+c2JlcnlvemtpbkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+ DQomZ3Q7IEhpIEJyaWFuPGJyPg0KJmd0Ozxicj4NCiZndDsgSSd2ZSByZWFkIHRoZSB0ZXh0LCBJ IGxpa2UgaXQgaXMgc3RpbGwgcHVyZSBPQXV0aDIsIHdpdGggZmV3IGV4dHJhIHBhcmFtZXRlcnMg YWRkZWQgdG8gdGhlIGFjY2VzcyB0b2tlbiByZXF1ZXN0LCBhbmQgYSBrZXkgcmVzcG9uc2UgcHJv cGVydHkgYmVpbmcgJ2FjY2Vzc190b2tlbicgYXMgb3Bwb3NlZCB0byAnc2VjdXJpdHlfYWNjZXNz X3Rva2VuJyBhcyBpbiB0aGUgZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZS0wMS48YnI+ DQomZ3Q7IEl0IGFwcGVhcnMgZHJhZnQtY2FtcGJlbGwtb2F1dGgtc3RzLTAxIGNhbiBjb3ZlciBh IGRyYWZ0LXJpY2hlci1vYXV0aC1jaGFpbi0wMCBjYXNlIHdpdGggdGhlIG9uX2JlaGFsZl9vZiAo YW5kL29yIGFjdF9hcyA/KSBwcm9wZXJ0eSBiZWluZyBhbiBvcmlnaW5hbCBjbGllbnQgdG9rZW4g YnV0IG5vdCAxMDAlIHN1cmUgZ2l2ZW4gZHJhZnQtcmljaGVyLW9hdXRoLWNoYWluLTAwIGNvdmVy cyBhIHNwZWNpZmljIGNhc2UuPGJyPg0KJmd0Ozxicj4NCiZndDsgT25lIHRoaW5nIEknbSBub3Qg c3VyZSBhYm91dCBpcyB3aGF0IGlzIHRoZSBwdXJwb3NlIG9mIHNwZWNpZnlpbmcgYTxicj4NCiZn dDsgc2VjdXJpdHlfdG9rZW5fdHlwZSBvZiB0aGUgcmV0dXJuZWQgYWNjZXNzIHRva2VuPGJyPg0K Jmd0Ozxicj4NCiZndDsgVGhhbmtzLCBTZXJnZXk8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiAwMS8w Ny8xNSAxNTo1OSwgQnJpYW4gQ2FtcGJlbGwgd3JvdGU6PGJyPg0KJmd0OyBPbmUgcHJvYmxlbSwg SSB0aGluaywgd2l0aCB0b2tlbiBleGNoYW5nZSBpcyB0aGF0IGl0IGNhbiBiZSByZWFsbHk8YnI+ DQomZ3Q7IHNpbXBsZSAodG9rZW4gaW4gYW5kIHRva2VuIG91dCkgYW5kIHJlYWxseSBjb21wbGlj YXRlZCAoY2xpZW50IFggd2FudHM8YnI+DQomZ3Q7IGEgdG9rZW4gdGhhdCBzYXlzIHVzZXIgQSBp cyBkb2luZyBzb21ldGhpbmcgb24gYmVoYWxmIG9mIHVzZXIgQikgYXQ8YnI+DQomZ3Q7IHRoZSBz YW1lIHRpbWUuPGJyPg0KJmd0Ozxicj4NCiZndDsgSSBwdXQgZm9ydGggPGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhbXBiZWxsLW9hdXRoLXN0cy0wMSIgdGFyZ2V0 PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhbXBiZWxsLW9h dXRoLXN0cy0wMTwvYT4gaW48YnI+DQomZ3Q7IGFuIGF0dGVtcHQgdG8gc2ltcGxpZnkgdGhpbmdz IGFuZCBleHByZXNzIHdoYXQgSSBlbnZpc2lvbmVkIGFzIGFuPGJyPg0KJmd0OyBPQXV0aCBiYXNl ZCB0b2tlbiBleGNoYW5nZSBmcmFtZXdvcmsuIFRob3VnaCBpdCBsaWtlbHkgb25seSBtdWRkaWVk PGJyPg0KJmd0OyB0aGUgd2F0ZXJzIDopPGJyPg0KJmd0Ozxicj4NCiZndDsgT24gV2VkLCBKdWwg MSwgMjAxNSBhdCA3OjA3IEFNLCBTZXJnZXkgQmVyeW96a2luICZsdDs8YSBocmVmPSJtYWlsdG86 c2JlcnlvemtpbkBnbWFpbC5jb20iPnNiZXJ5b3praW5AZ21haWwuY29tPC9hPjxicj4NCiZndDsg Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2JlcnlvemtpbkBnbWFpbC5jb20iPnNiZXJ5b3pr aW5AZ21haWwuY29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDtIaSBKdXN0aW48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJpY2hlci1v YXV0aC1jaGFpbi0wMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1yaWNoZXItb2F1dGgtY2hhaW4tMDA8L2E+IGlzIG11Y2g8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDtlYXNpZXIgdG8gcmVhZCwgdGhhdCBJIGNhbiB0ZWxsIGZvciBzdXJlLCBh dCBsZWFzdCBpdCBpcyBvYnZpb3VzIHdoeTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2Eg Z2l2ZW4gZW50aXR5IChSUzEpIG1heSB3YW50IHRvIGV4Y2hhbmdlIHRoZSBjdXJyZW50IHRva2Vu IHByb3ZpZGVkPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7YnkgYSBjbGllbnQgZm9yIGEg bmV3IHRva2VuLiBEZWZpbml0ZWx5IGVhc2lseSBpbXBsZW1lbnRhYmxlLi4uPGJyPg0KJmd0Ozxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO09uZSB0aGluZyBJJ20gbm90IHN1cmUgaW4gdGhl IGRyYWZ0LXJpY2hlci1vYXV0aC1jaGFpbi0wMCBhYm91dCBpczxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwO29uIGJlaGFsZiBvZiB3aG9zZSBlbnRpdHkgUlMxIHdpbGwgYmUgYWN0aW5nIG9u Y2UgaXQgc3RhcnRzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7YWNjZXNzaW5nIFJTMiwg T24gQmVoYWxmIE9mIFJPLCBvciBtYXkgYmUgT24gQmVoYWxmIE9mIChSTyAmIzQzOzxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwO0NsaWVudCksIG9yIG1heSBiZSBpdCBpcyBPbiBCZWhhbGYg T2YgUk8gJiM0MzsgQWN0IEFzIENsaWVudCA/IFRoZSBsYXN0PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7b25lIHNlZW1zIG1vc3QgbG9naWNhbCB0byBtZS4uLjxicj4NCiZndDs8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtUaGFua3MsIFNlcmdleTxicj4NCiZndDs8YnI+DQomZ3Q7 PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7T24gMDEvMDcvMTUgMTM6MTgsIEp1c3RpbiBS aWNoZXIgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7QXMgaXQncyB3cml0dGVuIHJpZ2h0IG5vdywgaXQncyBhIHRyYW5zbGF0aW9uIG9m IHNvbWUgV1MtKjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y29u Y2VwdHMgaW50bzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SldU IGZvcm1hdC4gSXQncyBub3QgcmVhbGx5IE9BdXRoLXkgKHNpbmNlIHRoZSBjbGllbnQgaGFzIHRv PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt1bmRlcnN0YW5kPGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0aGUgdG9rZW4gZm9ybWF0 IGFsb25nIHdpdGggZXZlcnlvbmUgZWxzZSwgYW5kIGFjY29yZGluZyB0byB0aGU8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2F1dGhvcnM8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3RoZSBhcnRpZmFjdHMgbWlnaHQgbm90IGV2ZW4g YmUgJnF1b3Q7T0F1dGggdG9rZW5zJnF1b3Q7KSwgYW5kIHRoYXQncyBteSBtYWluPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpc3N1ZSB3aXRoIHRoZSBkb2N1bWVu dC4gWWVhcnMgYWdvLCBJIHByb3Bvc2VkIGFuIE9BdXRoLWJhc2VkPGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0b2tlbiBzd2FwPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDttZWNoYW5pc206PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXJpY2hlci1vYXV0aC1jaGFpbi0wMCIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yaWNoZXItb2F1dGgtY2hhaW4tMDA8L2E+ PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhp cyB3b3JrcyB3aXRob3V0IGRlZmluaW5nIHNlbWFudGljcyBvZiB0aGUgdG9rZW5zIHRoZW1zZWx2 ZXMsIGp1c3Q8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2xpa2Ug dGhlIHJlc3Qgb2YgT0F1dGguIEkndmUgcHJvcG9zZWQgdG8gdGhlIGF1dGhvcnMgb2YgdGhlIGN1 cnJlbnQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0IHRo YXQgaXQgc2hvdWxkIGluY29ycG9yYXRlIGJvdGggc2VtYW50aWMgKHVzaW5nIEpXVCkgYW5kPGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzeW50YWN0aWM8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyh1c2luZyBhIHNpbXBsZSB0b2tl bi1hZ25vc3RpYyBncmFudCkgdG9rZW4gc3dhcCBtZWNoYW5pc21zLCBhbmQ8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3RoYXQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3RoZSB0d28gY291bGQgYmUgZWFzaWx5IGNvbXBhdGlibGUu PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAtLSBKdXN0aW48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtPbiA3LzEvMjAxNSA2OjM1IEFNLCBTZXJnZXkgQmVyeW96a2luIHdyb3RlOjxi cj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7SG1tLi4uIHBlcmhhcHMgdGhlIGNsdWUgaXMgaW4gdGhlIGRyYWZ0IHRpdGxlLDxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0 b2tlbi1leGNoYW5nZSwgc28gbWF5PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2JlIGl0IGlzIGEgY2FzZSBvZiB0aGUgZ2l2ZW4gYWNjZXNz IHRva2VuICgmcXVvdDtvbl9iZWhhbGZfb2YmcXVvdDsgb3I8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7YWN0X2FzJnF1b3Q7PGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Ns YWltKSBiZWluZyB1c2VkIHRvIHJlcXVlc3QgYSBuZXcgc2VjdXJpdHkgdG9rZW4uIE9uZSBjYW48 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 b25seSBndWVzczxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDt0aG91Z2gsIGRvZXMgbm90IHNlZW0gbGlrZSB0aGUgYXV0aG9ycyBhcmUga2Vl biB0byBhbnN3ZXI8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7dGhlIG5ld2JpZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtxdWVzdGlvbnMuLi48YnI+DQomZ3Q7PGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0NoZWVycywgU2Vy Z2V5PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7T24gMzAvMDYvMTUgMTM6MzgsIFNlcmdleSBCZXJ5b3pr aW4gd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0hpLDxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0NhbiB5 b3UgcGxlYXNlIGV4cGxhaW4gd2hhdCBpcyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7T24tQmVoYWxmLU9mPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c2VtYW50aWNzIGRlc2NyaWJlZCBpbiB0 aGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTAxIGFuZCB0 aGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtpbXBsaWNpdCBPbi1CZWhhbGYtT2Ygc2VtYW50aWNzIGEgY2xpZW50 IE9BdXRoMiB0b2tlbjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Bvc3Nlc3NlcyA/PGJyPg0KJmd0Ozxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO0ZvciBleGFtcGxlLCBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTAxIG1l bnRpb25zOjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtXaGVyZWFzLCB3aXRoIG9uLWJl aGFsZi1vZiBzZW1hbnRpY3MsIHByaW5jaXBhbCBBIHN0aWxsPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aGFzIGl0 cyBvd248YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtpZGVudGl0eSBzZXBhcmF0ZSBmcm9tIEIgYW5kIGl0IGlzIGV4 cGxpY2l0bHkgdW5kZXJzdG9vZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3RoYXQgd2hpbGUgQjxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO21heSBoYXZlIGRlbGVnYXRlZCBpdHMgcmlnaHRzIHRvIEEsIGFueSBhY3Rpb25zIHRha2Vu PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7YXJlIGJlaW5nIHRha2VuIGJ5PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QSBhbmQgbm90 IEIuIEluIGEgc2Vuc2UsIEEgaXMgYW4gYWdlbnQgZm9yIEIuJnF1b3Q7PGJyPg0KJmd0Ozxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO1RoaXMgaXMgYSB0eXBpY2FsIGNhc2Ugd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBj b2RlIGZsb3c8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt3aGVyZSBhIGNsaWVudDxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2FwcGxp Y2F0aW9uIGFjdHMgb24tYmVoYWxmLW9mIHRoZSB1c2VyIHdobyBhdXRob3JpemVkPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7dGhpcyBhcHBsaWNhdGlvbiA/PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1NvcnJ5IGlm IEknbSBtaXNzaW5nIHNvbWV0aGluZzxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtDaGVlcnMsIFNl cmdleTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO09uIDI1LzA2LzE1IDIyOjI4LCBNaWtlIEpvbmVzIHdyb3RlOjxi cj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RoYXTigJlzIHdoYXQ8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTAxIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2Ut MDE8L2E+PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpczxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7YWJvdXQuPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Q2hl ZXJzLDxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0tIE1pa2U8YnI+DQom Z3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsqRnJvbToqT0F1dGggW21haWx0bzo8YSBo cmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+b2F1dGgtYm91bmNlc0BpZXRmLm9y ZzwvYT48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDttYWlsdG86PGEgaHJlZj0ibWFp bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0 O10gKk9uIEJlaGFsZiBPZiAqVml2ZWs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0Jpc3dh czxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7LVQgKHZpYmlzd2FzIC0gWE9SSUFOVCBDT1JQ T1JBVElPTiBhdCBDaXNjbyk8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOypTZW50OiogVGh1 cnNkYXksIEp1bmUgMjUsIDIwMTUgMjoyMCBQTTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 KlRvOiogPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT4g Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3Jn PC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOypTdWJqZWN0OiogW09BVVRILVdH XSBKV1QgVG9rZW4gb24tYmVoYWxmIG9mIFVzZTxicj4NCiZndDsgY2FzZTxicj4NCiZndDs8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0hpIEFsbCw8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0kgYW0gbG9va2luZyB0byBzb2x2ZSBhIHVzZS1j YXNlIHNpbWlsYXIgdG88YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1dTLVNlY3VyaXR5IE9u LUJlaGFsZi1PZjxicj4NCiZndDs8YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJodHRwOi8vZG9jcy5v YXNpcy1vcGVuLm9yZy93cy1zeC93cy10cnVzdC92MS40L2VycmF0YTAxL29zL3dzLXRydXN0LTEi IHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZG9jcy5vYXNpcy1vcGVuLm9yZy93cy1zeC93cy10cnVz dC92MS40L2VycmF0YTAxL29zL3dzLXRydXN0LTE8L2E+PGJyPg0KJmd0OyAuNC1lcnJhdGEwMS1v cy1jb21wbGV0ZS5odG1sI19Ub2MzMjU2NTg5ODAmZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3dpdGggT0F1dGggSldUIFRva2VuLjxicj4NCiZndDs8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SXMgdGhlcmUgYSBzdGFu ZGFyZCBjbGFpbSB3aGljaCB3ZSBjYW4gZGVmaW5lPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDt3aXRoaW4gdGhlIE9BdXRoIEpXVDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7d2hpY2gg ZGVub3RlIHRoZSBPbi1iZWhhbGYtb2YgVXNlci48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtGb3IgZS5nLiwgYSBDdXN0b21lciBSZXByZXNlbnRhdGl2ZSB0cnlpbmcgdG8g Y3JlYXRlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0b2tlbiBvbiBiZWhhbGYgb2Y8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2EgY3VzdG9tZXIgYW5kIHRyeWluZyB0byBleGVjdXRl IHNlcnZpY2VzIHNwZWNpZmljPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtmb3IgdGhhdCBz cGVjaWZpYzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y3VzdG9tZXIuPGJyPg0KJmd0Ozxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UmVnYXJkcyw8YnI+DQomZ3Q7PGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtWaXZlayBCaXN3YXMsPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtDSVNTUDxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOypDaXNjbyBTeXN0 ZW1zLCBJbmMgJmx0OzxhIGhyZWY9Imh0dHA6Ly93d3cuY2lzY28uY29tLyIgdGFyZ2V0PSJfYmxh bmsiPmh0dHA6Ly93d3cuY2lzY28uY29tLzwvYT4mZ3Q7Kjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOypCbGRnLiBKLCBTYW4gSm9zZSwgVVNBLCo8YnI+DQomZ3Q7PGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsqUGhvbmU6IDxhIGhyZWY9InRlbDolMkIxJTIwNDA4JTIw NTI3JTIwOTE3NiI+JiM0MzsxIDQwOCA1MjcgOTE3NjwvYT48YnI+DQomZ3Q7ICZsdDs8YSBocmVm PSJ0ZWw6JTJCMSUyMDQwOCUyMDUyNyUyMDkxNzYiPnRlbDolMkIxJTIwNDA4JTIwNTI3JTIwOTE3 NjwvYT4mZ3Q7Kjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO09BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0 aEBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmci Pk9BdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxi cj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0ibWFpbHRvOk9B dXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWls dG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0Ozxi cj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Im1haWx0bzpPQXV0aEBp ZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOk9B dXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwO19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7T0F1dGggbWFpbGluZyBsaXN0 PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYu b3JnIj5PQXV0aEBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86T0F1dGhA aWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aDwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0 Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQomZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRv Ok9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCjxi cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K T0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5P QXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BY2PR03MB442D6CB1EB8C2C503710279F5930BY2PR03MB442namprd_-- From nobody Mon Jul 6 11:52:06 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD661B3026; Mon, 6 Jul 2015 11:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqCdrh6rVmTK; Mon, 6 Jul 2015 11:52:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 496481B3032; Mon, 6 Jul 2015 11:52:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706185201.14523.76395.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 11:52:01 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 18:52:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : Request by JWS ver.1.0 for OAuth 2.0 Authors : Nat Sakimura John Bradley Filename : draft-ietf-oauth-jwsreq-04.txt Pages : 9 Date : 2015-07-06 Abstract: The authorization request in OAuth 2.0 utilizes query parameter serialization. This specification defines the authorization request using JWT serialization. The request is sent through "request" parameter or by reference through "request_uri" parameter that points to the JWT, allowing the request to be optionally signed and encrypted. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 6 13:44:08 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E891B3219 for ; Mon, 6 Jul 2015 13:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtT53ee8Z-Uk for ; Mon, 6 Jul 2015 13:44:01 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0710.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::710]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2203B1B3228 for ; Mon, 6 Jul 2015 13:44:01 -0700 (PDT) Received: from BL2PR03MB434.namprd03.prod.outlook.com (10.141.92.22) by BL2PR03MB356.namprd03.prod.outlook.com (10.141.89.27) with Microsoft SMTP Server (TLS) id 15.1.207.12; Mon, 6 Jul 2015 20:43:46 +0000 Received: from CY1PR0301MB1243.namprd03.prod.outlook.com (10.161.212.153) by BL2PR03MB434.namprd03.prod.outlook.com (10.141.92.22) with Microsoft SMTP Server (TLS) id 15.1.207.12; Mon, 6 Jul 2015 20:43:26 +0000 Received: from CY1PR0301MB1243.namprd03.prod.outlook.com ([10.161.212.153]) by CY1PR0301MB1243.namprd03.prod.outlook.com ([10.161.212.153]) with mapi id 15.01.0207.004; Mon, 6 Jul 2015 20:43:26 +0000 From: Anthony Nadalin To: Brian Campbell , Mike Jones Thread-Topic: [OAUTH-WG] JWT Token on-behalf of Use case Thread-Index: AdCvjKZzog4lHzdSReisaGHaz/hQ6gAARPxgAOj5XIAALgFuAAADlXeAAAG2sYAAA+u+gAD0P/SAAAVKOIAAAmBqAAACCAqQAATTnQAAAC6oEA== Date: Mon, 6 Jul 2015 20:43:26 +0000 Message-ID: References: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> <55928DB3.7090300@gmail.com> <5593C270.7000008@gmail.com> <5593DA7D.80401@mit.edu> <5593E5FD.3050403@gmail.com> <559A676F.3070008@gmail.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; x-originating-ip: [131.107.159.183] x-microsoft-exchange-diagnostics: 1; BL2PR03MB434; 5:nrrqyhoYWYWiq+uj3NC06F9Dxan3N2Nb+7pwbnfIU2hMDCTtJkzi4/wMJn1eePIEC9csB4rag6h9DRxXeFfhpVESj0FZP9dpx+F7eIrg05A1FACjvvxBYywPfwFPjcjhcZqyOUQmPPqypNr70DVg/A==; 24:oxl9SNPLTP32/9yBBgSu+CQ5r4Gn3fNVp0T1LkTTCI/T2H3iFgSiZxLFdCjS7o880iyLOHvPjbACbB4dknnt1p+5d2DPGiXChyEBHuHUlLM=; 20:LuOW38hjqBO9XDy4GnR9U5w/PwtcZZbAgDyc6dwXf4vZ2qQO8OUViDW2czs0uzyA4gk80Nf1O6gH8B2fsMDQEw== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB434; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB356; x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BL2PR03MB434; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB434; x-forefront-prvs: 06290ECA9D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(13464003)(164054003)(479174004)(377454003)(51704005)(3905003)(53754006)(24454002)(33656002)(189998001)(19617315012)(76176999)(5002640100001)(15975445007)(2421001)(19609705001)(77156002)(19580395003)(74316001)(2561002)(5001960100002)(2950100001)(102836002)(86612001)(93886004)(77096005)(122556002)(19625215002)(50986999)(5003600100002)(2900100001)(5001770100001)(54356999)(16236675004)(87936001)(62966003)(86362001)(561944003)(19580405001)(92566002)(40100003)(2656002)(19300405004)(76576001)(99286002)(1511001)(66066001)(46102003)(42262002)(4001450100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB434; H:CY1PR0301MB1243.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB12437C5CFE06B7837375E5DBA6930CY1PR0301MB1243_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2015 20:43:26.3721 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB434 X-Microsoft-Exchange-Diagnostics: 1; BL2PR03MB356; 2:0Pff35NVix/25CoKHg1OR77GTSwN2liLYTyj6vBFQLh40/022sYK7gjZQ6zB5eOv; 3:/mKto3Xl5IKennQx0bQhNOrlMKfy+aw2jsyEekN61gzv9MFJ0MzeJbTDs5nKSwjvvkIKe7m3W4F9GQOAfZPtaBzsbw6XNJkLCw72QhKPGSqvG3ZQ+mV4UVOSR1sKI2mtSdLO3StBCY2LNtU0mo6PDQ==; 25:UzpKOkCttmO+aoOs+5btpFWDyOed/TdszFKvilAcFXRXTgPitYlC5+91fSml1dsgmfbt3lx5E1edmC9Xm7pIyFhHURhmPSJxLH/s5lyQewjG6CL2i2Gz52JqTjBBxejRhk3u2ZFSEwc1q8FjM/e2r9VUWlXsST3uBfosfjaSJw++On6yEm33gBklGI52mw5hdWriEHt7CiVQ0pA2F4Znhhl3NqrvtWpPIrTWyHuFPBnbtr7os4B+Vu9AWlJQoAL/nrma1Jo7arCbV+aS1R0htQ==; 23:1VZGsl61uIIRleO1gBLSbJB5jzqYKVdeeKr4eAQQT9d0AB/1Vp9Sym9knuL3fgfoN30iUlB0rmBsLO2VGoQ8zvumaoVsp0jYI/6szP5UD+QkkLGnyZdEN8LRxiQTGXXUIlFh6eYWBGOspZhV3VOlEr58mQSekjwZ1HZgUbEDBMMvo2bCL/JnDDFWYaMINf0xvxB/LXDJfLS9BYug5DsJnb3R8V05RW4tfQi1DmHzK/HQWBpsDGhwOUhB/jWg68JU X-OriginatorOrg: microsoft.com Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 20:44:07 -0000 --_000_CY1PR0301MB12437C5CFE06B7837375E5DBA6930CY1PR0301MB1243_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIFdTLVRydXN0IOKAnEFjdEFz4oCdIG1pbWljcyB0aGUgV2luZG93cyBLZXJiZXJvcyBQcm90 b2NvbCBUcmFuc2l0aW9uIChpbXBlcnNvbmF0aW9uKSAgZmVhdHVyZSBhcyB0aGlzIGVuYWJsZXMg YW4gYWNjb3VudCB0byBpbXBlcnNvbmF0ZSBhbm90aGVyIGFjY291bnQgZm9yIHRoZSBwdXJwb3Nl IG9mIHByb3ZpZGluZyBhY2Nlc3MgdG8gcmVzb3VyY2VzLiBJbiBhIHR5cGljYWwgc2NlbmFyaW8s IHRoZSBpbXBlcnNvbmF0aW5nIGFjY291bnQgd291bGQgYmUgYSBzZXJ2aWNlIGFjY291bnQgYXNz aWduZWQgdG8gYSB3ZWIgYXBwbGljYXRpb24gb3IgdGhlIGNvbXB1dGVyIGFjY291bnQgb2YgYSB3 ZWIgc2VydmVyLiBUaGUgaW1wZXJzb25hdGVkIGFjY291bnQgd291bGQgYmUgYSB1c2VyIGFjY291 bnQgcmVxdWlyaW5nIGFjY2VzcyB0byByZXNvdXJjZXMgKGUuZy4gZGF0YSBpbiBhbiBTUUwgZGF0 YWJhc2UpIHZpYSBhIHdlYiBhcHBsaWNhdGlvbi4gSW4gdGhpcyBzY2VuYXJpbywgU1FMIHNlcnZl ciB3b3VsZCBiZSBhY2Nlc3NlZCBieSB0aGUgaW1wZXJzb25hdGluZyAoc2VydmljZSBhY2NvdW50 KSBhY2NvdW50LCBob3dldmVyIGFjY2VzcyB3b3VsZCBiZSB1bmRlciB0aGUgY29udGV4dCBvZiB0 aGUgaW1wZXJzb25hdGVkICh1c2VyKSBhY2NvdW50Lg0KDQpXUy1UcnVzdCDigJxPbkJlaGFsZk9m 4oCdICBtaW1pY3MgdGhlIFdpbmRvd3MgS2VyYmVyb3MgQ29uc3RyYWluZWQgRGVsZWdhdGlvbiBm ZWF0dXJlLCB3aGljaCBsZXRzIHlvdSBsaW1pdCB0aGUgYmFjay1lbmQgc2VydmljZXMgZm9yIHdo aWNoIGEgZnJvbnQtZW5kIHNlcnZpY2UgY2FuIHJlcXVlc3QgdGlja2V0cyBvbiBiZWhhbGYgb2Yg YW5vdGhlciB1c2VyLiDigJxPbkJlaGFsZk9m4oCdICBhbGxvd3MgYSBzZWxlY3RlZCBzZXJ2aWNl cyBvbiBhIHNlcnZlciBjYW4gYmUgZ3JhbnRlZCBmb3IgYWNjZXNzIGJ5IHRoZSBpbXBlcnNvbmF0 aW5nIGFjY291bnQsIHdoaWxzdCBvdGhlciBzZXJ2aWNlcyBvbiB0aGUgc2FtZSBzZXJ2ZXIsIG9y IHNlcnZpY2VzIG9uIG90aGVyIHNlcnZlcnMgYXJlIGRlbmllZCBmb3IgYWNjZXNzLg0KDQpNYXli ZSBzb21lb25lIGNhbiBzdW1tYXJpemUgd2h5IHRoZXkgdGhpbmsgdGhlIHRleHQgZm9yIEFjdEFz IGFuZCBPbkJlaGFsZk9mIGluIFdTLVRydXN0IG9yIFdpbmRvd3MgS2VyYmVyb3MgaXMgd3Jvbmcg b3Igc3dhcHBlZCBhcyBJIGhhdmUgbm90IHNlZW4gYSBjbGVhciBleHBsYW5hdGlvbiBvdGhlciB0 aGFuIEpvaG4gc2F5aW5nIHRoYXQgQnJpYW4ga25vd3MgYW5kIEJyaWFuIHNheWluZyBKb2huIGtu b3dzLg0KDQpPdXIgdXNhZ2UgYW5kIHVzZSBjYXNlcyBhcmUgYmFzZWQgdXBvbiB0aGUgZGVwbG95 ZWQgc2VydmljZXMgb2YgV1MtVHJ1c3QgYW5kIEtlcmJlcm9zIHN1cHBvcnQgaW4gV2luZG93cyAo d29ya3N0YXRpb24gYW5kIHNlcnZlcikgYW5kIFhib3guDQoNCkZyb206IE9BdXRoIFttYWlsdG86 b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJyaWFuIENhbXBiZWxsDQpTZW50 OiBNb25kYXksIEp1bHkgNiwgMjAxNSAxMToyOSBBTQ0KVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbT4NCkNjOiBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW09BVVRILVdHXSBKV1QgVG9rZW4gb24tYmVoYWxmIG9mIFVzZSBjYXNlDQoNClN0YXRp bmcgc3BlY2lmaWMgYWN0aW9uIGl0ZW1zIHJlc3VsdGluZyBmcm9tIHRoZSBhZC1ob2MgbWVldGlu ZyBpbiBEYWxsYXMgbGlrZSB0aGF0IHN1Z2dlc3RzIHNvbWUgY2xlYXIgY29uc2Vuc3VzIHdhcyBy ZWFjaGVkLCB3aGljaCBpcyBub3QgYXQgYWxsIHRoZSBjYXNlLiBBcyBJIHJlY2FsbCwgc2V2ZXJh bCBvZiB1cyBhcmd1ZWQgcGFzdCBvbmUgYW5vdGhlciBmb3IgYW4gaG91ciBvciBzbyBhbmQgZGVj aWRlZCB0byBhZGpvdXJuIGluIG9yZGVyIHRvIGdvIHRvIHRoZSBiYXIgKG9rYXksIGFuZCBkaW5u ZXIgdG9vIC0gYnV0IG1vc3RseSBiZWVyKS4NClRoZSBpbXByZXNzaW9uIGFib3V0IHJldmVyc2Fs IG9mIHRlcm1zLCBJIHRoaW5rLCBjb21lcyBmcm9tIHRoZSB0ZXh0IGluIGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTAxI3NlY3Rpb24t MS4zIHdoaWNoIGh1cnRzIG15IGhlYWQgYSBsaXR0bGUgZXZlcnktdGltZSBJIHJlYWQgaXQgYnV0 IGRvZXMgc2VlbXMgdG8gY29uZnVzZSB0aGluZ3MuIFRoZSBNU0ROIGxpbms8aHR0cHM6Ly9tc2Ru Lm1pY3Jvc29mdC5jb20vZW4tdXMvbGlicmFyeS9lZTc0ODQ4Ny5hc3B4PiBKb2huIGdhdmUgaXMg bXVjaCBtb3JlIHRvIHRoZSBwb2ludCB0aGFuIFdTLVRydXN0IChJIGRvbid0IGJlbGlldmUgV1Mt VHJ1c3QgY2FuIGJlIHBvaW50ZWQgdG8gYXMgYSBtb2RlbCBvZiBjbGFyaXR5KS4gIEluIHRoZSBk cmFmdCBJIHdyb3RlLCBJIHRyaWVkIHRvIHRha2UgTWlrZSdzIHRleHQgYW5kIGNsYXJpZnkgYSBk aXN0aW5jdGlvbiBiZXR3ZWVuIGltcGVyc29uYXRpb24gYW5kIGRlbGVnYXRpb24gd2l0aCBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2FtcGJlbGwtb2F1dGgtc3RzLTAxI3NlY3Rp b24tMS4zIGFuZCB0aGVuIGFsc28gYmUgdmVyeSBleHBsaWNpdCBhYm91dCBhY3QtYXMgdnMuIG9u LWJlaGFsZi1vZiBpbiB0aGUgcGFyYW1ldGVyIGRlZmluaXRpb25zIGF0IGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW1wYmVsbC1vYXV0aC1zdHMtMDEjc2VjdGlvbi0yIGluIGEg bWFub3IgdGhhdCB3YXMgY29uc2lzdGVudCB3aXRoIFdTLVRydXN0IGFuZCB0aGUgTVNETiBleHBs YW5hdGlvbi4gSSBjb3VsZCBzZWUgdmFsdWUgaW4gYnJlYWtpbmcgd2l0aCB0aGF0IHNoYWt5IGxl Z2FjeSBhbmQgdXNpbmcgbmV3IHRlcm1zIHRvby4gQnV0IEkgZ2V0IHRoZSBwb2ludCBvZiB0cnlp bmcgdG8ga2VlcCB3aXRoIHRoZSBvbGQgYWxzbyBhbmQgcG90ZW50aWFsIGZvciBldmVuIG1vcmUg Y29uZnVzaW5nIGJ5IHVzaW5nIG5ldyB0ZXJtcy4NCkkgd3JvdGUgZHJhZnQtY2FtcGJlbGwtb2F1 dGgtc3RzIGxhc3QgeWVhciBpbiByZXNwb25zZSB0byB0aGUgY2FsbCBmb3IgYWRvcHRpb24gb2Yg am9uZXMtb2F1dGgtdG9rZW4tZXhjaGFuZ2UgKHRocmVhZCBmcm9tIHRoZSBhcmNoaXZlPGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxMzMwNS5o dG1sPikuIFRob3VnaCBJIGRpZG4ndCB0cnkgYW5kIHN0YW5kIGluIHRoZSB3YXkgYW5kIGluZGlj YXRlZCBhIHdpbGxpbmduZXNzIHRvIGNvbGxhYm9yYXRlIG9uIHRoaW5ncy4gV2l0aCB0aGUgZXhw ZWN0YXRpb24sIG9mIGNvdXJzZSwgdGhhdCB0aGUgZGV0YWlscyB3b3VsZCBkaWZmZXIgZnJvbSB0 aGUgLTAwcyBhbmQgLTAxcyBhcyB3b3JrIHByb2dyZXNzZWQuIEZvbGtzIHNlZW1lZCBnZW5lcmFs bHkgYW1lbmFibGUgdG8gdGhhdDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L29hdXRoL2N1cnJlbnQvbXNnMTMzMDguaHRtbD4gYXQgdGhlIHRpbWUgYnV0IGxpdHRsZSBoYXMg aGFwcGVuZWQgc2luY2UgdGhlbi4NClBoaWwncyBlYXJsaWVyIHBvaW50IGFib3V0IHRoZSBwcmlv cnkgb2YgdGhpcyBnZXR0aW5nIHB1c2hlZCBkb3duIGhhcyBzb21lIHRydXRoIHRvIGl0LiBCdXQg SSBzdGlsbCBiZWxpZXZlIGl0J3Mgc29tZXRoaW5nIHRoYXQgY2FuIHByb3ZpZGUgYSBsb3Qgb2Yg dmFsdWUgaW4gc3RhbmRhcmRpemluZywgaWYgd2UgZG8gc28gaW4gYSByZWFzb25hYmxlIHdheS4N Cg0KDQoNCg0KDQpPbiBNb24sIEp1bCA2LCAyMDE1IGF0IDEwOjMzIEFNLCBNaWtlIEpvbmVzIDxN aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbT4+IHdyb3RlOg0KSXQgd291bGQgc3VycHJpc2UgbWUgaWYgb24tYmVoYWxmLW9mIGFuZCBh Y3QtYXMgd2VyZSByZXZlcnNlZCB3aXRoIHJlc3BlY3QgV1MtVHJ1c3QsIGJlY2F1c2UgdGhlIGV4 cGxhbmF0aW9ucyBvZiB0aGUgdGVybXMgY2FtZSBkaXJlY3RseSBmcm9tIFdTLVRydXN0IDEuNC4g IEkgYWxzbyB0aGluayB0aGUgY2hhbmNlcyBvZiB1cyByZWR1Y2luZyBjb25mdXNpb24gYnkgaW52 ZW50aW5nIG5ldyB0ZXJtaW5vbG9neSwgcmF0aGVyIHRoYW4gYWRkaW5nIHRvIGl0LCB3b3VsZCBu b3QgYmUgaW4gb3VyIGZhdm9yLiA6LS8NCg0KRllJLCB0aGUgYWN0aW9uIGl0ZW1zIG91dHN0YW5k aW5nIGZyb20gb3VyIGFkLWhvYyBtZWV0aW5nIG9uIHRoaXMgZHJhZnQgaW4gRGFsbGFzIGFyZToN CiAgLSBBbGxvd2luZyBzZWN1cml0eSB0eXBlcyBvdGhlciB0aGFuIEpXVCB0byBhbHNvIGJlIHVz ZWQgYXMgdGhlIGFjdF9hcyBhbmQgb25fYmVoYWxmX29mIHJlcXVlc3QgdmFsdWVzLg0KICAtIEZ1 cnRoZXIgaW50ZWdyYXRpbmcgdGhlIG1lY2hhbmlzbSBpbnRvIHRoZSBleGlzdGluZyBPQXV0aCBl Y29zeXN0ZW0gLSBhbGxvd2luZyB1c2Ugb2YgYWNjZXNzIHRva2VucyBvciByZWZyZXNoIHRva2Vu cyB3aGVuIGFwcHJvcHJpYXRlLg0KDQpJIHBsYW4gdG8gZG8gdGhlIGZpcnN0IHRvZGF5LiAgVGhl IHNlY29uZCBpcyBwcm9iYWJseSBtb3JlIHRoYW4gSSdsbCBnZXQgZG9uZSB0b2RheSBiZWZvcmUg dGhlIHN1Ym1pc3Npb24gY3V0b2ZmLiAgSSBhZ3JlZSB3aXRoIEpvaG4gdGhhdCBpdCB3b3VsZCBi ZSB1c2VmdWwgdG8gaGF2ZSBkaXNjdXNzaW9ucyBvbiB0aGlzIGluIFByYWd1ZSBvbiB0aGUgYmVz dCB3YXkgdG8gYWNoaWV2ZSB0aGlzIGZ1cnRoZXIgaW50ZWdyYXRpb24uICBJJ2xsIHBsYW4gdG8g Y29tZSBpbnRvIHRoZSBQcmFndWUgbWVldGluZyB3aXRoIGEgY29uY3JldGUgcHJvcG9zYWwgZm9y IHJldmlldy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCZXN0IHdpc2hlcywN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEpvaG4gQnJhZGxl eQ0KU2VudDogTW9uZGF5LCBKdWx5IDA2LCAyMDE1IDg6MTMgQU0NClRvOiBCcmlhbiBDYW1wYmVs bA0KQ2M6IG9hdXRoDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBKV1QgVG9rZW4gb24tYmVoYWxm IG9mIFVzZSBjYXNlDQoNClllcyB1bmZvcnR1bmF0ZWx5IHdlIGhhdmVu4oCZdCBtYWRlIGFueSBw cm9ncmVzcyBvbiB0aGlzIHNpbmNlIGFjY2VwdGluZyBNaWtl4oCZcyBmaXJzdCBkcmFmdC4NCg0K SGlzIHByb3Bvc2FsIGlzIGJhc2ljYWxseSBmb3IgYSBuZXcgZW5kcG9pbnQgd2hpbGUgQnJpYW4g dGlyZWQgdG8gZml0IGl0IGludG8gdGhlIGV4aXN0aW5nIHRva2VuIGVuZHBvaW50Lg0KDQpJIHRo aW5rIGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMDEgc3RpbGwgaGFzIE9uQmVoYWxm T2YgYW5kIEFjdEFzIHJldmVyc2VkIGNvbXBhcmVkIHRvIFdTLVRydXN0IDEuNC4NCnNlZSBodHRw czovL21zZG4ubWljcm9zb2Z0LmNvbS9lbi11cy9saWJyYXJ5L2VlNzQ4NDg3LmFzcHggZm9yIHRo ZSBzaG9ydCBleHBsYW5hdGlvbi4NCg0KSSB0aGluayBCcmlhbiBpcyBjbG9zZXIgaW4gZXhwbGFp bmluZyBpdC4NCg0KSW4gZmFpcm5lc3MgYmVjYXVzZSBXUy1UcnVzdCBvcmlnaW5hbGx5IG9ubHkg aGFkIE9uLUJlaGFsZi1PZiB0aGUgbmFtaW5nIGFuZCB3aGF0IHBlb3BsZSBwdXQgaW4gdG9rZW5z IGlzIGEgYml0IG11ZGRsZWQgaW4gbWFueSBpbXBsZW1lbnRhdGlvbnMuDQpJIHRoaW5rIG1hbnkg dGltZXMgaXQgaXMgaG93IFdJRiBpbXBsZW1lbnRlZCBpdCB0aGF0IHBlb3BsZSBjb3BpZWQuDQoN Ckl0IG1heSBiZSBiZXR0ZXIgdG8gaGF2ZSBuZXcgdGVybXMgdGhhdCBhcmUgY2xlYXIgc3VjaCBh cyBpbXBlcnNvbmF0aW9uIGFuZCBjb21wb3NpdGUuDQoNClRoZSBXRyBuZWVkcyB0byBkZWNpZGUg aWYgdGhpcyBpcyBnb2luZyB0byBiZSBhbiBlbnRpcmVseSBuZXcgZW5kcG9pbnQsIGZyZWUgb2Yg dGhlIFRva2VuIGVuZHBvaW50IHNlbWFudGljcy4gICBUaGVyZSBhcmUgcGx1c3NlcyBhbmQgbWlu dXNlcyB0byBib3RoIG9wdGlvbnMuDQoNCkFsc28gd2hpbGUgaXQgaXMgbmljZSB0byBiZSBwdXJl IGFuZCB0YWxrIGFib3V0IGFic3RyYWN0IHNlY3VyaXR5IHRva2VucywgaXQgd291bGQgYmUgZ29v ZCB0byBnaXZlIHNvbWUgZ3VpZGFuY2Ugb24gd2hhdCBhIGNvbXBvc2l0ZSBzZWN1cml0eSB0b2tl biB3b3VsZCBsb29rIGxpa2UgZm9yIGludGVyb3BlcmFiaWxpdHkuDQoNClRoZXJlIGFyZSBhbHNv IGlzc3VlcyBhcm91bmQgaG93IHRoaXMgd291bGQgd29yayB3aXRoIHByb29mIG9mIHBvc3Nlc3Np b24gc2VjdXJpdHkgdG9rZW5zLCBib3RoIGFzIGlucHV0IGFuZCBvdXRwdXQuDQoNClBlcmhhcHMg d2UgY2FuIG1ha2Ugc29tZSBwcm9ncmVzcyBvbiB0aGlzIGluIFByYWd1ZS4NCg0KSm9obiBCLg0K DQoNCg0KDQo+IE9uIEp1bCA2LCAyMDE1LCBhdCAxMTowNCBBTSwgQnJpYW4gQ2FtcGJlbGwgPGJj YW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNv bT4+IHdyb3RlOg0KPg0KPiBUaGFua3MgU2VyZ2V5LA0KPg0KPiBUaGUgZ29hbCBvZiBkcmFmdC1j YW1wYmVsbC1vYXV0aC1zdHMgd2FzIHRvIGJlIGNvbnNpc3RlbnQgd2l0aCBPQXV0aCAyLjAgYW5k IHRodXMgaG9wZWZ1bGx5IGZhbWlsaWFyIHRvIGRldmVsb3BlcnMgYW5kIGVhc3kgdG8gdW5kZXJz dGFuZCBhbmQgaW1wbGVtZW50IChlc3BlY2lhbGx5IGZyb20gdGhlIGNsaWVudCBzaWRlKS4gSXQn cyBhbHNvIGludGVuZGVkIHRvIGJlIGZsZXhpYmxlIGluIG9yZGVyIHRvIGFjY29tbW9kYXRlIGEg dmFyaWV0eSBvZiB1c2UtY2FzZXMgaW5jbHVkaW5nIHRoZSBjaGFpbmluZyB0eXBlIGNhc2VzIHRo YXQgSnVzdGluJ3MgZHJhZnQgY292ZXJzLg0KPg0KPiBTcGVjaWZ5aW5nIGEgc2VjdXJpdHlfdG9r ZW5fdHlwZSBvZiB0aGUgcmV0dXJuZWQgdG9rZW4gaXMganVzdCBhIHdheSBvZiBwcm92aWRpbmcg bW9yZSBpbmZvIHRvIHRoZSBjbGllbnQgYWJvdXQgdGhlIHRva2VuIChpLmUuIGlzIHRoaXMgYSBK V1Qgb3IgYSBTQU1MIHRva2VuIG9yIHNvbWV0aGluZyBlbHNlKSB2aWEgYSBVUkkuIEl0J3Mgbm90 IGFsd2F5cyBuZWVkZWQgYnV0IGluIFNUUyBzdHlsZSBjYXNlcyB0aGUgdG9rZW5zIGFyZSBub3Qg YWx3YXlzIG9wYXF1ZSB0byB0aGUgY2xpZW50IGFuZCB0aGUgcGFyYW1ldGVyIGp1c3QgcHJvdmlk ZXMgaW5mbyBhYm91dCB0aGUgcmV0dXJuZWQgdG9rZW4uDQo+DQo+IE9uIE1vbiwgSnVsIDYsIDIw MTUgYXQgNTozMyBBTSwgU2VyZ2V5IEJlcnlvemtpbiA8c2JlcnlvemtpbkBnbWFpbC5jb208bWFp bHRvOnNiZXJ5b3praW5AZ21haWwuY29tPj4gd3JvdGU6DQo+IEhpIEJyaWFuDQo+DQo+IEkndmUg cmVhZCB0aGUgdGV4dCwgSSBsaWtlIGl0IGlzIHN0aWxsIHB1cmUgT0F1dGgyLCB3aXRoIGZldyBl eHRyYSBwYXJhbWV0ZXJzIGFkZGVkIHRvIHRoZSBhY2Nlc3MgdG9rZW4gcmVxdWVzdCwgYW5kIGEg a2V5IHJlc3BvbnNlIHByb3BlcnR5IGJlaW5nICdhY2Nlc3NfdG9rZW4nIGFzIG9wcG9zZWQgdG8g J3NlY3VyaXR5X2FjY2Vzc190b2tlbicgYXMgaW4gdGhlIGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4t ZXhjaGFuZ2UtMDEuDQo+IEl0IGFwcGVhcnMgZHJhZnQtY2FtcGJlbGwtb2F1dGgtc3RzLTAxIGNh biBjb3ZlciBhIGRyYWZ0LXJpY2hlci1vYXV0aC1jaGFpbi0wMCBjYXNlIHdpdGggdGhlIG9uX2Jl aGFsZl9vZiAoYW5kL29yIGFjdF9hcyA/KSBwcm9wZXJ0eSBiZWluZyBhbiBvcmlnaW5hbCBjbGll bnQgdG9rZW4gYnV0IG5vdCAxMDAlIHN1cmUgZ2l2ZW4gZHJhZnQtcmljaGVyLW9hdXRoLWNoYWlu LTAwIGNvdmVycyBhIHNwZWNpZmljIGNhc2UuDQo+DQo+IE9uZSB0aGluZyBJJ20gbm90IHN1cmUg YWJvdXQgaXMgd2hhdCBpcyB0aGUgcHVycG9zZSBvZiBzcGVjaWZ5aW5nIGENCj4gc2VjdXJpdHlf dG9rZW5fdHlwZSBvZiB0aGUgcmV0dXJuZWQgYWNjZXNzIHRva2VuDQo+DQo+IFRoYW5rcywgU2Vy Z2V5DQo+DQo+IE9uIDAxLzA3LzE1IDE1OjU5LCBCcmlhbiBDYW1wYmVsbCB3cm90ZToNCj4gT25l IHByb2JsZW0sIEkgdGhpbmssIHdpdGggdG9rZW4gZXhjaGFuZ2UgaXMgdGhhdCBpdCBjYW4gYmUg cmVhbGx5DQo+IHNpbXBsZSAodG9rZW4gaW4gYW5kIHRva2VuIG91dCkgYW5kIHJlYWxseSBjb21w bGljYXRlZCAoY2xpZW50IFggd2FudHMNCj4gYSB0b2tlbiB0aGF0IHNheXMgdXNlciBBIGlzIGRv aW5nIHNvbWV0aGluZyBvbiBiZWhhbGYgb2YgdXNlciBCKSBhdA0KPiB0aGUgc2FtZSB0aW1lLg0K Pg0KPiBJIHB1dCBmb3J0aCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2FtcGJl bGwtb2F1dGgtc3RzLTAxIGluDQo+IGFuIGF0dGVtcHQgdG8gc2ltcGxpZnkgdGhpbmdzIGFuZCBl eHByZXNzIHdoYXQgSSBlbnZpc2lvbmVkIGFzIGFuDQo+IE9BdXRoIGJhc2VkIHRva2VuIGV4Y2hh bmdlIGZyYW1ld29yay4gVGhvdWdoIGl0IGxpa2VseSBvbmx5IG11ZGRpZWQNCj4gdGhlIHdhdGVy cyA6KQ0KPg0KPiBPbiBXZWQsIEp1bCAxLCAyMDE1IGF0IDc6MDcgQU0sIFNlcmdleSBCZXJ5b3pr aW4gPHNiZXJ5b3praW5AZ21haWwuY29tPG1haWx0bzpzYmVyeW96a2luQGdtYWlsLmNvbT4NCj4g PG1haWx0bzpzYmVyeW96a2luQGdtYWlsLmNvbTxtYWlsdG86c2JlcnlvemtpbkBnbWFpbC5jb20+ Pj4gd3JvdGU6DQo+DQo+ICAgICBIaSBKdXN0aW4NCj4NCj4gICAgIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1yaWNoZXItb2F1dGgtY2hhaW4tMDAgaXMgbXVjaA0KPiAgICAgZWFz aWVyIHRvIHJlYWQsIHRoYXQgSSBjYW4gdGVsbCBmb3Igc3VyZSwgYXQgbGVhc3QgaXQgaXMgb2J2 aW91cyB3aHkNCj4gICAgIGEgZ2l2ZW4gZW50aXR5IChSUzEpIG1heSB3YW50IHRvIGV4Y2hhbmdl IHRoZSBjdXJyZW50IHRva2VuIHByb3ZpZGVkDQo+ICAgICBieSBhIGNsaWVudCBmb3IgYSBuZXcg dG9rZW4uIERlZmluaXRlbHkgZWFzaWx5IGltcGxlbWVudGFibGUuLi4NCj4NCj4gICAgIE9uZSB0 aGluZyBJJ20gbm90IHN1cmUgaW4gdGhlIGRyYWZ0LXJpY2hlci1vYXV0aC1jaGFpbi0wMCBhYm91 dCBpcw0KPiAgICAgb24gYmVoYWxmIG9mIHdob3NlIGVudGl0eSBSUzEgd2lsbCBiZSBhY3Rpbmcg b25jZSBpdCBzdGFydHMNCj4gICAgIGFjY2Vzc2luZyBSUzIsIE9uIEJlaGFsZiBPZiBSTywgb3Ig bWF5IGJlIE9uIEJlaGFsZiBPZiAoUk8gKw0KPiAgICAgQ2xpZW50KSwgb3IgbWF5IGJlIGl0IGlz IE9uIEJlaGFsZiBPZiBSTyArIEFjdCBBcyBDbGllbnQgPyBUaGUgbGFzdA0KPiAgICAgb25lIHNl ZW1zIG1vc3QgbG9naWNhbCB0byBtZS4uLg0KPg0KPiAgICAgVGhhbmtzLCBTZXJnZXkNCj4NCj4N Cj4gICAgIE9uIDAxLzA3LzE1IDEzOjE4LCBKdXN0aW4gUmljaGVyIHdyb3RlOg0KPg0KPiAgICAg ICAgIEFzIGl0J3Mgd3JpdHRlbiByaWdodCBub3csIGl0J3MgYSB0cmFuc2xhdGlvbiBvZiBzb21l IFdTLSoNCj4gICAgICAgICBjb25jZXB0cyBpbnRvDQo+ICAgICAgICAgSldUIGZvcm1hdC4gSXQn cyBub3QgcmVhbGx5IE9BdXRoLXkgKHNpbmNlIHRoZSBjbGllbnQgaGFzIHRvDQo+ICAgICAgICAg dW5kZXJzdGFuZA0KPiAgICAgICAgIHRoZSB0b2tlbiBmb3JtYXQgYWxvbmcgd2l0aCBldmVyeW9u ZSBlbHNlLCBhbmQgYWNjb3JkaW5nIHRvIHRoZQ0KPiAgICAgICAgIGF1dGhvcnMNCj4gICAgICAg ICB0aGUgYXJ0aWZhY3RzIG1pZ2h0IG5vdCBldmVuIGJlICJPQXV0aCB0b2tlbnMiKSwgYW5kIHRo YXQncyBteSBtYWluDQo+ICAgICAgICAgaXNzdWUgd2l0aCB0aGUgZG9jdW1lbnQuIFllYXJzIGFn bywgSSBwcm9wb3NlZCBhbiBPQXV0aC1iYXNlZA0KPiAgICAgICAgIHRva2VuIHN3YXANCj4gICAg ICAgICBtZWNoYW5pc206DQo+DQo+ICAgICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXJpY2hlci1vYXV0aC1jaGFpbi0wMA0KPg0KPiAgICAgICAgIFRoaXMgd29ya3Mgd2l0 aG91dCBkZWZpbmluZyBzZW1hbnRpY3Mgb2YgdGhlIHRva2VucyB0aGVtc2VsdmVzLCBqdXN0DQo+ ICAgICAgICAgbGlrZSB0aGUgcmVzdCBvZiBPQXV0aC4gSSd2ZSBwcm9wb3NlZCB0byB0aGUgYXV0 aG9ycyBvZiB0aGUgY3VycmVudA0KPiAgICAgICAgIGRyYWZ0IHRoYXQgaXQgc2hvdWxkIGluY29y cG9yYXRlIGJvdGggc2VtYW50aWMgKHVzaW5nIEpXVCkgYW5kDQo+ICAgICAgICAgc3ludGFjdGlj DQo+ICAgICAgICAgKHVzaW5nIGEgc2ltcGxlIHRva2VuLWFnbm9zdGljIGdyYW50KSB0b2tlbiBz d2FwIG1lY2hhbmlzbXMsIGFuZA0KPiAgICAgICAgIHRoYXQNCj4gICAgICAgICB0aGUgdHdvIGNv dWxkIGJlIGVhc2lseSBjb21wYXRpYmxlLg0KPg0KPiAgICAgICAgICAgIC0tIEp1c3Rpbg0KPg0K PiAgICAgICAgIE9uIDcvMS8yMDE1IDY6MzUgQU0sIFNlcmdleSBCZXJ5b3praW4gd3JvdGU6DQo+ DQo+ICAgICAgICAgICAgIEhtbS4uLiBwZXJoYXBzIHRoZSBjbHVlIGlzIGluIHRoZSBkcmFmdCB0 aXRsZSwNCj4gICAgICAgICAgICAgdG9rZW4tZXhjaGFuZ2UsIHNvIG1heQ0KPiAgICAgICAgICAg ICBiZSBpdCBpcyBhIGNhc2Ugb2YgdGhlIGdpdmVuIGFjY2VzcyB0b2tlbiAoIm9uX2JlaGFsZl9v ZiIgb3INCj4gICAgICAgICAgICAgImFjdF9hcyINCj4gICAgICAgICAgICAgY2xhaW0pIGJlaW5n IHVzZWQgdG8gcmVxdWVzdCBhIG5ldyBzZWN1cml0eSB0b2tlbi4gT25lIGNhbg0KPiAgICAgICAg ICAgICBvbmx5IGd1ZXNzDQo+ICAgICAgICAgICAgIHRob3VnaCwgZG9lcyBub3Qgc2VlbSBsaWtl IHRoZSBhdXRob3JzIGFyZSBrZWVuIHRvIGFuc3dlcg0KPiAgICAgICAgICAgICB0aGUgbmV3Ymll DQo+ICAgICAgICAgICAgIHF1ZXN0aW9ucy4uLg0KPg0KPiAgICAgICAgICAgICBDaGVlcnMsIFNl cmdleQ0KPg0KPg0KPiAgICAgICAgICAgICBPbiAzMC8wNi8xNSAxMzozOCwgU2VyZ2V5IEJlcnlv emtpbiB3cm90ZToNCj4NCj4gICAgICAgICAgICAgICAgIEhpLA0KPiAgICAgICAgICAgICAgICAg Q2FuIHlvdSBwbGVhc2UgZXhwbGFpbiB3aGF0IGlzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4NCj4g ICAgICAgICAgICAgICAgIE9uLUJlaGFsZi1PZg0KPiAgICAgICAgICAgICAgICAgc2VtYW50aWNz IGRlc2NyaWJlZCBpbiB0aGUNCj4gICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtb2F1dGgtdG9r ZW4tZXhjaGFuZ2UtMDEgYW5kIHRoZQ0KPiAgICAgICAgICAgICAgICAgaW1wbGljaXQgT24tQmVo YWxmLU9mIHNlbWFudGljcyBhIGNsaWVudCBPQXV0aDIgdG9rZW4NCj4gICAgICAgICAgICAgICAg IHBvc3Nlc3NlcyA/DQo+DQo+ICAgICAgICAgICAgICAgICBGb3IgZXhhbXBsZSwgZHJhZnQtaWV0 Zi1vYXV0aC10b2tlbi1leGNoYW5nZS0wMSBtZW50aW9uczoNCj4NCj4gICAgICAgICAgICAgICAg ICJXaGVyZWFzLCB3aXRoIG9uLWJlaGFsZi1vZiBzZW1hbnRpY3MsIHByaW5jaXBhbCBBIHN0aWxs DQo+ICAgICAgICAgICAgICAgICBoYXMgaXRzIG93bg0KPiAgICAgICAgICAgICAgICAgaWRlbnRp dHkgc2VwYXJhdGUgZnJvbSBCIGFuZCBpdCBpcyBleHBsaWNpdGx5IHVuZGVyc3Rvb2QNCj4gICAg ICAgICAgICAgICAgIHRoYXQgd2hpbGUgQg0KPiAgICAgICAgICAgICAgICAgbWF5IGhhdmUgZGVs ZWdhdGVkIGl0cyByaWdodHMgdG8gQSwgYW55IGFjdGlvbnMgdGFrZW4NCj4gICAgICAgICAgICAg ICAgIGFyZSBiZWluZyB0YWtlbiBieQ0KPiAgICAgICAgICAgICAgICAgQSBhbmQgbm90IEIuIElu IGEgc2Vuc2UsIEEgaXMgYW4gYWdlbnQgZm9yIEIuIg0KPg0KPiAgICAgICAgICAgICAgICAgVGhp cyBpcyBhIHR5cGljYWwgY2FzZSB3aXRoIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgZmxvdw0KPiAg ICAgICAgICAgICAgICAgd2hlcmUgYSBjbGllbnQNCj4gICAgICAgICAgICAgICAgIGFwcGxpY2F0 aW9uIGFjdHMgb24tYmVoYWxmLW9mIHRoZSB1c2VyIHdobyBhdXRob3JpemVkDQo+ICAgICAgICAg ICAgICAgICB0aGlzIGFwcGxpY2F0aW9uID8NCj4NCj4gICAgICAgICAgICAgICAgIFNvcnJ5IGlm IEknbSBtaXNzaW5nIHNvbWV0aGluZw0KPg0KPiAgICAgICAgICAgICAgICAgQ2hlZXJzLCBTZXJn ZXkNCj4gICAgICAgICAgICAgICAgIE9uIDI1LzA2LzE1IDIyOjI4LCBNaWtlIEpvbmVzIHdyb3Rl Og0KPg0KPiAgICAgICAgICAgICAgICAgICAgIFRoYXTigJlzIHdoYXQNCj4gICAgICAgICAgICAg ICAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC10b2tl bi1leGNoYW5nZS0wMQ0KPiAgICAgICAgICAgICAgICAgICAgIGlzDQo+ICAgICAgICAgICAgICAg ICAgICAgYWJvdXQuDQo+DQo+ICAgICAgICAgICAgICAgICAgICAgQ2hlZXJzLA0KPg0KPiAgICAg ICAgICAgICAgICAgICAgIC0tIE1pa2UNCj4NCj4gICAgICAgICAgICAgICAgICAgICAqRnJvbToq T0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2Vz QGlldGYub3JnPg0KPiAgICAgICAgICAgICAgICAgICAgIDxtYWlsdG86b2F1dGgtYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4+XSAqT24gQmVoYWxmIE9mICpW aXZlaw0KPiAgICAgICAgICAgICAgICAgICAgIEJpc3dhcw0KPiAgICAgICAgICAgICAgICAgICAg IC1UICh2aWJpc3dhcyAtIFhPUklBTlQgQ09SUE9SQVRJT04gYXQgQ2lzY28pDQo+ICAgICAgICAg ICAgICAgICAgICAgKlNlbnQ6KiBUaHVyc2RheSwgSnVuZSAyNSwgMjAxNSAyOjIwIFBNDQo+ICAg ICAgICAgICAgICAgICAgICAgKlRvOiogT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYu b3JnPiA8bWFpbHRvOk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4+DQo+ICAg ICAgICAgICAgICAgICAgICAgKlN1YmplY3Q6KiBbT0FVVEgtV0ddIEpXVCBUb2tlbiBvbi1iZWhh bGYgb2YgVXNlDQo+IGNhc2UNCj4NCj4gICAgICAgICAgICAgICAgICAgICBIaSBBbGwsDQo+DQo+ ICAgICAgICAgICAgICAgICAgICAgICAgIEkgYW0gbG9va2luZyB0byBzb2x2ZSBhIHVzZS1jYXNl IHNpbWlsYXIgdG8NCj4gICAgICAgICAgICAgICAgICAgICBXUy1TZWN1cml0eSBPbi1CZWhhbGYt T2YNCj4NCj4gPGh0dHA6Ly9kb2NzLm9hc2lzLW9wZW4ub3JnL3dzLXN4L3dzLXRydXN0L3YxLjQv ZXJyYXRhMDEvb3Mvd3MtdHJ1c3QtMQ0KPiAuNC1lcnJhdGEwMS1vcy1jb21wbGV0ZS5odG1sI19U b2MzMjU2NTg5ODA+DQo+DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgd2l0aCBPQXV0aCBKV1Qg VG9rZW4uDQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICAgIElzIHRoZXJlIGEgc3RhbmRhcmQg Y2xhaW0gd2hpY2ggd2UgY2FuIGRlZmluZQ0KPiAgICAgICAgICAgICAgICAgICAgIHdpdGhpbiB0 aGUgT0F1dGggSldUDQo+ICAgICAgICAgICAgICAgICAgICAgd2hpY2ggZGVub3RlIHRoZSBPbi1i ZWhhbGYtb2YgVXNlci4NCj4NCj4gICAgICAgICAgICAgICAgICAgICBGb3IgZS5nLiwgYSBDdXN0 b21lciBSZXByZXNlbnRhdGl2ZSB0cnlpbmcgdG8gY3JlYXRlDQo+ICAgICAgICAgICAgICAgICAg ICAgdG9rZW4gb24gYmVoYWxmIG9mDQo+ICAgICAgICAgICAgICAgICAgICAgYSBjdXN0b21lciBh bmQgdHJ5aW5nIHRvIGV4ZWN1dGUgc2VydmljZXMgc3BlY2lmaWMNCj4gICAgICAgICAgICAgICAg ICAgICBmb3IgdGhhdCBzcGVjaWZpYw0KPiAgICAgICAgICAgICAgICAgICAgIGN1c3RvbWVyLg0K Pg0KPiAgICAgICAgICAgICAgICAgICAgIFJlZ2FyZHMsDQo+DQo+ICAgICAgICAgICAgICAgICAg ICAgVml2ZWsgQmlzd2FzLA0KPiAgICAgICAgICAgICAgICAgICAgIENJU1NQDQo+DQo+ICAgICAg ICAgICAgICAgICAgICAgKkNpc2NvIFN5c3RlbXMsIEluYyA8aHR0cDovL3d3dy5jaXNjby5jb20v PioNCj4NCj4gICAgICAgICAgICAgICAgICAgICAqQmxkZy4gSiwgU2FuIEpvc2UsIFVTQSwqDQo+ DQo+ICAgICAgICAgICAgICAgICAgICAgKlBob25lOiArMSA0MDggNTI3IDkxNzY8dGVsOiUyQjEl MjA0MDglMjA1MjclMjA5MTc2Pg0KPiA8dGVsOiUyQjElMjA0MDglMjA1MjclMjA5MTc2PioNCj4N Cj4NCj4NCj4gICAgICAgICAgICAgICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiAgICAgICAgICAgICAgICAgICAgIE9BdXRoIG1haWxpbmcg bGlzdA0KPiAgICAgICAgICAgICAgICAgICAgIE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBp ZXRmLm9yZz4gPG1haWx0bzpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+Pg0K PiAgICAgICAgICAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGgNCj4NCj4NCj4NCj4gICAgICAgICAgICAgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gICAgICAgICAgICAgT0F1dGggbWFpbGluZyBsaXN0 DQo+ICAgICAgICAgICAgIE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4gPG1h aWx0bzpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+Pg0KPiAgICAgICAgICAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+DQo+DQo+ICAg ICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g ICAgICAgICBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gICAgICAgICBPQXV0aEBpZXRmLm9yZzxtYWls dG86T0F1dGhAaWV0Zi5vcmc+IDxtYWlsdG86T0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGll dGYub3JnPj4NCj4gICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoDQo+DQo+DQo+ICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiAgICAgT0F1dGggbWFpbGluZyBsaXN0DQo+ICAgICBPQXV0aEBpZXRmLm9y ZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+IDxtYWlsdG86T0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9B dXRoQGlldGYub3JnPj4NCj4gICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGgNCj4NCj4NCj4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGlldGYub3Jn PG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoN Cg== --_000_CY1PR0301MB12437C5CFE06B7837375E5DBA6930CY1PR0301MB1243_ 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 IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIFdTLVRydXN0IOKAnEFjdEFz4oCd IG1pbWljcyB0aGUgV2luZG93cyBLZXJiZXJvcyBQcm90b2NvbCBUcmFuc2l0aW9uIChpbXBlcnNv bmF0aW9uKSAmbmJzcDtmZWF0dXJlIGFzIHRoaXMgZW5hYmxlcyBhbiBhY2NvdW50IHRvIGltcGVy c29uYXRlIGFub3RoZXIgYWNjb3VudCBmb3IgdGhlDQogcHVycG9zZSBvZiBwcm92aWRpbmcgYWNj ZXNzIHRvIHJlc291cmNlcy4gSW4gYSB0eXBpY2FsIHNjZW5hcmlvLCB0aGUgaW1wZXJzb25hdGlu ZyBhY2NvdW50IHdvdWxkIGJlIGEgc2VydmljZSBhY2NvdW50IGFzc2lnbmVkIHRvIGEgd2ViIGFw cGxpY2F0aW9uIG9yIHRoZSBjb21wdXRlciBhY2NvdW50IG9mIGEgd2ViIHNlcnZlci4gVGhlIGlt cGVyc29uYXRlZCBhY2NvdW50IHdvdWxkIGJlIGEgdXNlciBhY2NvdW50IHJlcXVpcmluZyBhY2Nl c3MgdG8NCiByZXNvdXJjZXMgKGUuZy4gZGF0YSBpbiBhbiBTUUwgZGF0YWJhc2UpIHZpYSBhIHdl YiBhcHBsaWNhdGlvbi4gSW4gdGhpcyBzY2VuYXJpbywgU1FMIHNlcnZlciB3b3VsZCBiZSBhY2Nl c3NlZCBieSB0aGUgaW1wZXJzb25hdGluZyAoc2VydmljZSBhY2NvdW50KSBhY2NvdW50LCBob3dl dmVyIGFjY2VzcyB3b3VsZCBiZSB1bmRlciB0aGUgY29udGV4dCBvZiB0aGUgaW1wZXJzb25hdGVk ICh1c2VyKSBhY2NvdW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+V1MtVHJ1c3Qg4oCcT25CZWhhbGZPZuKAnSAmbmJzcDttaW1pY3MgdGhlIFdpbmRvd3MgS2Vy YmVyb3MgQ29uc3RyYWluZWQgRGVsZWdhdGlvbiBmZWF0dXJlLCB3aGljaCBsZXRzIHlvdSBsaW1p dCB0aGUgYmFjay1lbmQgc2VydmljZXMgZm9yIHdoaWNoIGEgZnJvbnQtZW5kIHNlcnZpY2UgY2Fu DQogcmVxdWVzdCB0aWNrZXRzIG9uIGJlaGFsZiBvZiBhbm90aGVyIHVzZXIuIOKAnE9uQmVoYWxm T2bigJ0gJm5ic3A7YWxsb3dzIGEgc2VsZWN0ZWQgc2VydmljZXMgb24gYSBzZXJ2ZXIgY2FuIGJl IGdyYW50ZWQgZm9yIGFjY2VzcyBieSB0aGUgaW1wZXJzb25hdGluZyBhY2NvdW50LCB3aGlsc3Qg b3RoZXIgc2VydmljZXMgb24gdGhlIHNhbWUgc2VydmVyLCBvciBzZXJ2aWNlcyBvbiBvdGhlciBz ZXJ2ZXJzIGFyZSBkZW5pZWQgZm9yIGFjY2Vzcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPk1heWJlIHNvbWVvbmUgY2FuIHN1bW1hcml6ZSB3aHkgdGhleSB0aGlu ayB0aGUgdGV4dCBmb3IgQWN0QXMgYW5kIE9uQmVoYWxmT2YgaW4gV1MtVHJ1c3Qgb3IgV2luZG93 cyBLZXJiZXJvcyBpcyB3cm9uZyBvciBzd2FwcGVkIGFzIEkgaGF2ZSBub3Qgc2VlbiBhIGNsZWFy IGV4cGxhbmF0aW9uDQogb3RoZXIgdGhhbiBKb2huIHNheWluZyB0aGF0IEJyaWFuIGtub3dzIGFu ZCBCcmlhbiBzYXlpbmcgSm9obiBrbm93cy4gPGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj4NCjxv OnA+PC9vOnA+PC9hPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk91ciB1c2FnZSBh bmQgdXNlIGNhc2VzIGFyZSBiYXNlZCB1cG9uIHRoZSBkZXBsb3llZCBzZXJ2aWNlcyBvZiBXUy1U cnVzdCBhbmQgS2VyYmVyb3Mgc3VwcG9ydCBpbiBXaW5kb3dzICh3b3Jrc3RhdGlvbiBhbmQgc2Vy dmVyKSBhbmQgWGJveC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYu b3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CcmlhbiBDYW1wYmVsbDxicj4NCjxiPlNlbnQ6PC9i PiBNb25kYXksIEp1bHkgNiwgMjAxNSAxMToyOSBBTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBKb25l cyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gb2F1 dGggJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRI LVdHXSBKV1QgVG9rZW4gb24tYmVoYWxmIG9mIFVzZSBjYXNlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij5TdGF0aW5nIHNwZWNpZmljIGFjdGlvbiBpdGVtcyByZXN1bHRpbmcgZnJvbSB0 aGUgYWQtaG9jIG1lZXRpbmcgaW4gRGFsbGFzIGxpa2UgdGhhdCBzdWdnZXN0cyBzb21lIGNsZWFy IGNvbnNlbnN1cyB3YXMgcmVhY2hlZCwgd2hpY2ggaXMgbm90IGF0IGFsbCB0aGUgY2FzZS4gQXMg SSByZWNhbGwsIHNldmVyYWwgb2YgdXMgYXJndWVkIHBhc3Qgb25lIGFub3RoZXINCiBmb3IgYW4g aG91ciBvciBzbyBhbmQgZGVjaWRlZCB0byBhZGpvdXJuIGluIG9yZGVyIHRvIGdvIHRvIHRoZSBi YXIgKG9rYXksIGFuZCBkaW5uZXIgdG9vIC0gYnV0IG1vc3RseSBiZWVyKS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij5UaGUgaW1wcmVzc2lvbiBhYm91dCByZXZlcnNhbCBvZiB0ZXJtcywgSSB0aGluaywgY29t ZXMgZnJvbSB0aGUgdGV4dCBpbg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMDEjc2VjdGlvbi0xLjMiIHRhcmdldD0i X2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXRv a2VuLWV4Y2hhbmdlLTAxI3NlY3Rpb24tMS4zPC9hPiB3aGljaCBodXJ0cyBteSBoZWFkIGEgbGl0 dGxlIGV2ZXJ5LXRpbWUgSSByZWFkIGl0IGJ1dCBkb2VzIHNlZW1zIHRvIGNvbmZ1c2UgdGhpbmdz LiBUaGUNCjxhIGhyZWY9Imh0dHBzOi8vbXNkbi5taWNyb3NvZnQuY29tL2VuLXVzL2xpYnJhcnkv ZWU3NDg0ODcuYXNweCIgdGFyZ2V0PSJfYmxhbmsiPg0KTVNETiBsaW5rPC9hPiBKb2huIGdhdmUg aXMgbXVjaCBtb3JlIHRvIHRoZSBwb2ludCB0aGFuIFdTLVRydXN0IChJIGRvbid0IGJlbGlldmUg V1MtVHJ1c3QgY2FuIGJlIHBvaW50ZWQgdG8gYXMgYSBtb2RlbCBvZiBjbGFyaXR5KS4mbmJzcDsg SW4gdGhlIGRyYWZ0IEkgd3JvdGUsIEkgdHJpZWQgdG8gdGFrZSBNaWtlJ3MgdGV4dCBhbmQgY2xh cmlmeSBhIGRpc3RpbmN0aW9uIGJldHdlZW4gaW1wZXJzb25hdGlvbiBhbmQgZGVsZWdhdGlvbiB3 aXRoDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2FtcGJlbGwt b2F1dGgtc3RzLTAxI3NlY3Rpb24tMS4zIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtY2FtcGJlbGwtb2F1dGgtc3RzLTAxI3NlY3Rpb24tMS4zPC9h PiBhbmQgdGhlbiBhbHNvIGJlIHZlcnkgZXhwbGljaXQgYWJvdXQgYWN0LWFzIHZzLiBvbi1iZWhh bGYtb2YgaW4gdGhlIHBhcmFtZXRlciBkZWZpbml0aW9ucyBhdA0KPGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhbXBiZWxsLW9hdXRoLXN0cy0wMSNzZWN0aW9uLTIi IHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW1w YmVsbC1vYXV0aC1zdHMtMDEjc2VjdGlvbi0yPC9hPiBpbiBhIG1hbm9yIHRoYXQgd2FzIGNvbnNp c3RlbnQgd2l0aCBXUy1UcnVzdCBhbmQgdGhlIE1TRE4gZXhwbGFuYXRpb24uIEkgY291bGQgc2Vl IHZhbHVlIGluIGJyZWFraW5nIHdpdGggdGhhdCBzaGFreSBsZWdhY3kgYW5kIHVzaW5nIG5ldyB0 ZXJtcyB0b28uIEJ1dCBJIGdldCB0aGUgcG9pbnQgb2YgdHJ5aW5nIHRvIGtlZXANCiB3aXRoIHRo ZSBvbGQgYWxzbyBhbmQgcG90ZW50aWFsIGZvciBldmVuIG1vcmUgY29uZnVzaW5nIGJ5IHVzaW5n IG5ldyB0ZXJtcy4gPG86cD4NCjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JIHdyb3RlIGRyYWZ0LWNhbXBiZWxsLW9h dXRoLXN0cyBsYXN0IHllYXIgaW4gcmVzcG9uc2UgdG8gdGhlIGNhbGwgZm9yIGFkb3B0aW9uIG9m IGpvbmVzLW9hdXRoLXRva2VuLWV4Y2hhbmdlICg8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTMzMDUuaHRtbCIgdGFyZ2V0PSJf YmxhbmsiPnRocmVhZA0KIGZyb20gdGhlIGFyY2hpdmU8L2E+KS4gVGhvdWdoIEkgZGlkbid0IHRy eSBhbmQgc3RhbmQgaW4gdGhlIHdheSBhbmQgaW5kaWNhdGVkIGEgd2lsbGluZ25lc3MgdG8gY29s bGFib3JhdGUgb24gdGhpbmdzLiBXaXRoIHRoZSBleHBlY3RhdGlvbiwgb2YgY291cnNlLCB0aGF0 IHRoZSBkZXRhaWxzIHdvdWxkIGRpZmZlciBmcm9tIHRoZSAtMDBzIGFuZCAtMDFzIGFzIHdvcmsg cHJvZ3Jlc3NlZC4gRm9sa3Mgc2VlbWVkDQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTMzMDguaHRtbCIgdGFyZ2V0PSJfYmxh bmsiPg0KZ2VuZXJhbGx5IGFtZW5hYmxlIHRvIHRoYXQ8L2E+IGF0IHRoZSB0aW1lIGJ1dCBsaXR0 bGUgaGFzIGhhcHBlbmVkIHNpbmNlIHRoZW4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QaGlsJ3MgZWFybGllciBwb2ludCBhYm91dCB0aGUgcHJp b3J5IG9mIHRoaXMgZ2V0dGluZyBwdXNoZWQgZG93biBoYXMgc29tZSB0cnV0aCB0byBpdC4gQnV0 IEkgc3RpbGwgYmVsaWV2ZSBpdCdzIHNvbWV0aGluZyB0aGF0IGNhbiBwcm92aWRlIGEgbG90IG9m IHZhbHVlIGluIHN0YW5kYXJkaXppbmcsIGlmIHdlIGRvIHNvIGluIGEgcmVhc29uYWJsZSB3YXku DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBKdWwgNiwg MjAxNSBhdCAxMDozMyBBTSwgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9z b2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkl0IHdvdWxkIHN1cnByaXNlIG1lIGlmIG9uLWJlaGFsZi1vZiBhbmQg YWN0LWFzIHdlcmUgcmV2ZXJzZWQgd2l0aCByZXNwZWN0IFdTLVRydXN0LCBiZWNhdXNlIHRoZSBl eHBsYW5hdGlvbnMgb2YgdGhlIHRlcm1zIGNhbWUgZGlyZWN0bHkgZnJvbSBXUy1UcnVzdCAxLjQu Jm5ic3A7IEkgYWxzbyB0aGluayB0aGUgY2hhbmNlcyBvZiB1cyByZWR1Y2luZyBjb25mdXNpb24g YnkgaW52ZW50aW5nIG5ldyB0ZXJtaW5vbG9neSwNCiByYXRoZXIgdGhhbiBhZGRpbmcgdG8gaXQs IHdvdWxkIG5vdCBiZSBpbiBvdXIgZmF2b3IuIDotLzxicj4NCjxicj4NCkZZSSwgdGhlIGFjdGlv biBpdGVtcyBvdXRzdGFuZGluZyBmcm9tIG91ciBhZC1ob2MgbWVldGluZyBvbiB0aGlzIGRyYWZ0 IGluIERhbGxhcyBhcmU6PGJyPg0KJm5ic3A7IC0gQWxsb3dpbmcgc2VjdXJpdHkgdHlwZXMgb3Ro ZXIgdGhhbiBKV1QgdG8gYWxzbyBiZSB1c2VkIGFzIHRoZSBhY3RfYXMgYW5kIG9uX2JlaGFsZl9v ZiByZXF1ZXN0IHZhbHVlcy48YnI+DQombmJzcDsgLSBGdXJ0aGVyIGludGVncmF0aW5nIHRoZSBt ZWNoYW5pc20gaW50byB0aGUgZXhpc3RpbmcgT0F1dGggZWNvc3lzdGVtIC0gYWxsb3dpbmcgdXNl IG9mIGFjY2VzcyB0b2tlbnMgb3IgcmVmcmVzaCB0b2tlbnMgd2hlbiBhcHByb3ByaWF0ZS48YnI+ DQo8YnI+DQpJIHBsYW4gdG8gZG8gdGhlIGZpcnN0IHRvZGF5LiZuYnNwOyBUaGUgc2Vjb25kIGlz IHByb2JhYmx5IG1vcmUgdGhhbiBJJ2xsIGdldCBkb25lIHRvZGF5IGJlZm9yZSB0aGUgc3VibWlz c2lvbiBjdXRvZmYuJm5ic3A7IEkgYWdyZWUgd2l0aCBKb2huIHRoYXQgaXQgd291bGQgYmUgdXNl ZnVsIHRvIGhhdmUgZGlzY3Vzc2lvbnMgb24gdGhpcyBpbiBQcmFndWUgb24gdGhlIGJlc3Qgd2F5 IHRvIGFjaGlldmUgdGhpcyBmdXJ0aGVyIGludGVncmF0aW9uLiZuYnNwOyBJJ2xsIHBsYW4NCiB0 byBjb21lIGludG8gdGhlIFByYWd1ZSBtZWV0aW5nIHdpdGggYSBjb25jcmV0ZSBwcm9wb3NhbCBm b3IgcmV2aWV3Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBCZXN0IHdpc2hlcyw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IE9BdXRoIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm9h dXRoLWJvdW5jZXNAaWV0Zi5vcmciPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhh bGYgT2YgSm9obiBCcmFkbGV5PGJyPg0KU2VudDogTW9uZGF5LCBKdWx5IDA2LCAyMDE1IDg6MTMg QU08YnI+DQpUbzogQnJpYW4gQ2FtcGJlbGw8YnI+DQpDYzogb2F1dGg8YnI+DQpTdWJqZWN0OiBS ZTogW09BVVRILVdHXSBKV1QgVG9rZW4gb24tYmVoYWxmIG9mIFVzZSBjYXNlPGJyPg0KPGJyPg0K WWVzIHVuZm9ydHVuYXRlbHkgd2UgaGF2ZW7igJl0IG1hZGUgYW55IHByb2dyZXNzIG9uIHRoaXMg c2luY2UgYWNjZXB0aW5nIE1pa2XigJlzIGZpcnN0IGRyYWZ0Ljxicj4NCjxicj4NCkhpcyBwcm9w b3NhbCBpcyBiYXNpY2FsbHkgZm9yIGEgbmV3IGVuZHBvaW50IHdoaWxlIEJyaWFuIHRpcmVkIHRv IGZpdCBpdCBpbnRvIHRoZSBleGlzdGluZyB0b2tlbiBlbmRwb2ludC48YnI+DQo8YnI+DQpJIHRo aW5rIGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMDEgc3RpbGwgaGFzIE9uQmVoYWxm T2YgYW5kIEFjdEFzIHJldmVyc2VkIGNvbXBhcmVkIHRvIFdTLVRydXN0IDEuNC48YnI+DQpzZWUg PGEgaHJlZj0iaHR0cHM6Ly9tc2RuLm1pY3Jvc29mdC5jb20vZW4tdXMvbGlicmFyeS9lZTc0ODQ4 Ny5hc3B4IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL21zZG4ubWljcm9zb2Z0LmNvbS9lbi11 cy9saWJyYXJ5L2VlNzQ4NDg3LmFzcHg8L2E+IGZvciB0aGUgc2hvcnQgZXhwbGFuYXRpb24uPGJy Pg0KPGJyPg0KSSB0aGluayBCcmlhbiBpcyBjbG9zZXIgaW4gZXhwbGFpbmluZyBpdC48YnI+DQo8 YnI+DQpJbiBmYWlybmVzcyBiZWNhdXNlIFdTLVRydXN0IG9yaWdpbmFsbHkgb25seSBoYWQgT24t QmVoYWxmLU9mIHRoZSBuYW1pbmcgYW5kIHdoYXQgcGVvcGxlIHB1dCBpbiB0b2tlbnMgaXMgYSBi aXQgbXVkZGxlZCBpbiBtYW55IGltcGxlbWVudGF0aW9ucy48YnI+DQpJIHRoaW5rIG1hbnkgdGlt ZXMgaXQgaXMgaG93IFdJRiBpbXBsZW1lbnRlZCBpdCB0aGF0IHBlb3BsZSBjb3BpZWQuPGJyPg0K PGJyPg0KSXQgbWF5IGJlIGJldHRlciB0byBoYXZlIG5ldyB0ZXJtcyB0aGF0IGFyZSBjbGVhciBz dWNoIGFzIGltcGVyc29uYXRpb24gYW5kIGNvbXBvc2l0ZS48YnI+DQo8YnI+DQpUaGUgV0cgbmVl ZHMgdG8gZGVjaWRlIGlmIHRoaXMgaXMgZ29pbmcgdG8gYmUgYW4gZW50aXJlbHkgbmV3IGVuZHBv aW50LCBmcmVlIG9mIHRoZSBUb2tlbiBlbmRwb2ludCBzZW1hbnRpY3MuJm5ic3A7ICZuYnNwO1Ro ZXJlIGFyZSBwbHVzc2VzIGFuZCBtaW51c2VzIHRvIGJvdGggb3B0aW9ucy48YnI+DQo8YnI+DQpB bHNvIHdoaWxlIGl0IGlzIG5pY2UgdG8gYmUgcHVyZSBhbmQgdGFsayBhYm91dCBhYnN0cmFjdCBz ZWN1cml0eSB0b2tlbnMsIGl0IHdvdWxkIGJlIGdvb2QgdG8gZ2l2ZSBzb21lIGd1aWRhbmNlIG9u IHdoYXQgYSBjb21wb3NpdGUgc2VjdXJpdHkgdG9rZW4gd291bGQgbG9vayBsaWtlIGZvciBpbnRl cm9wZXJhYmlsaXR5Ljxicj4NCjxicj4NClRoZXJlIGFyZSBhbHNvIGlzc3VlcyBhcm91bmQgaG93 IHRoaXMgd291bGQgd29yayB3aXRoIHByb29mIG9mIHBvc3Nlc3Npb24gc2VjdXJpdHkgdG9rZW5z LCBib3RoIGFzIGlucHV0IGFuZCBvdXRwdXQuPGJyPg0KPGJyPg0KUGVyaGFwcyB3ZSBjYW4gbWFr ZSBzb21lIHByb2dyZXNzIG9uIHRoaXMgaW4gUHJhZ3VlLjxicj4NCjxicj4NCkpvaG4gQi48YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQomZ3Q7IE9uIEp1bCA2LCAyMDE1LCBhdCAxMTowNCBB TSwgQnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50 aXR5LmNvbSI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQom Z3Q7PGJyPg0KJmd0OyBUaGFua3MgU2VyZ2V5LDxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBnb2Fs IG9mIGRyYWZ0LWNhbXBiZWxsLW9hdXRoLXN0cyB3YXMgdG8gYmUgY29uc2lzdGVudCB3aXRoIE9B dXRoIDIuMCBhbmQgdGh1cyBob3BlZnVsbHkgZmFtaWxpYXIgdG8gZGV2ZWxvcGVycyBhbmQgZWFz eSB0byB1bmRlcnN0YW5kIGFuZCBpbXBsZW1lbnQgKGVzcGVjaWFsbHkgZnJvbSB0aGUgY2xpZW50 IHNpZGUpLiBJdCdzIGFsc28gaW50ZW5kZWQgdG8gYmUgZmxleGlibGUgaW4gb3JkZXIgdG8gYWNj b21tb2RhdGUgYSB2YXJpZXR5DQogb2YgdXNlLWNhc2VzIGluY2x1ZGluZyB0aGUgY2hhaW5pbmcg dHlwZSBjYXNlcyB0aGF0IEp1c3RpbidzIGRyYWZ0IGNvdmVycy48YnI+DQomZ3Q7PGJyPg0KJmd0 OyBTcGVjaWZ5aW5nIGEgc2VjdXJpdHlfdG9rZW5fdHlwZSBvZiB0aGUgcmV0dXJuZWQgdG9rZW4g aXMganVzdCBhIHdheSBvZiBwcm92aWRpbmcgbW9yZSBpbmZvIHRvIHRoZSBjbGllbnQgYWJvdXQg dGhlIHRva2VuIChpLmUuIGlzIHRoaXMgYSBKV1Qgb3IgYSBTQU1MIHRva2VuIG9yIHNvbWV0aGlu ZyBlbHNlKSB2aWEgYSBVUkkuIEl0J3Mgbm90IGFsd2F5cyBuZWVkZWQgYnV0IGluIFNUUyBzdHls ZSBjYXNlcyB0aGUgdG9rZW5zIGFyZSBub3QgYWx3YXlzDQogb3BhcXVlIHRvIHRoZSBjbGllbnQg YW5kIHRoZSBwYXJhbWV0ZXIganVzdCBwcm92aWRlcyBpbmZvIGFib3V0IHRoZSByZXR1cm5lZCB0 b2tlbi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiBNb24sIEp1bCA2LCAyMDE1IGF0IDU6MzMgQU0s IFNlcmdleSBCZXJ5b3praW4gJmx0OzxhIGhyZWY9Im1haWx0bzpzYmVyeW96a2luQGdtYWlsLmNv bSI+c2JlcnlvemtpbkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IEhpIEJyaWFu PGJyPg0KJmd0Ozxicj4NCiZndDsgSSd2ZSByZWFkIHRoZSB0ZXh0LCBJIGxpa2UgaXQgaXMgc3Rp bGwgcHVyZSBPQXV0aDIsIHdpdGggZmV3IGV4dHJhIHBhcmFtZXRlcnMgYWRkZWQgdG8gdGhlIGFj Y2VzcyB0b2tlbiByZXF1ZXN0LCBhbmQgYSBrZXkgcmVzcG9uc2UgcHJvcGVydHkgYmVpbmcgJ2Fj Y2Vzc190b2tlbicgYXMgb3Bwb3NlZCB0byAnc2VjdXJpdHlfYWNjZXNzX3Rva2VuJyBhcyBpbiB0 aGUgZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZS0wMS48YnI+DQomZ3Q7IEl0IGFwcGVh cnMgZHJhZnQtY2FtcGJlbGwtb2F1dGgtc3RzLTAxIGNhbiBjb3ZlciBhIGRyYWZ0LXJpY2hlci1v YXV0aC1jaGFpbi0wMCBjYXNlIHdpdGggdGhlIG9uX2JlaGFsZl9vZiAoYW5kL29yIGFjdF9hcyA/ KSBwcm9wZXJ0eSBiZWluZyBhbiBvcmlnaW5hbCBjbGllbnQgdG9rZW4gYnV0IG5vdCAxMDAlIHN1 cmUgZ2l2ZW4gZHJhZnQtcmljaGVyLW9hdXRoLWNoYWluLTAwIGNvdmVycyBhIHNwZWNpZmljIGNh c2UuPGJyPg0KJmd0Ozxicj4NCiZndDsgT25lIHRoaW5nIEknbSBub3Qgc3VyZSBhYm91dCBpcyB3 aGF0IGlzIHRoZSBwdXJwb3NlIG9mIHNwZWNpZnlpbmcgYTxicj4NCiZndDsgc2VjdXJpdHlfdG9r ZW5fdHlwZSBvZiB0aGUgcmV0dXJuZWQgYWNjZXNzIHRva2VuPGJyPg0KJmd0Ozxicj4NCiZndDsg VGhhbmtzLCBTZXJnZXk8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiAwMS8wNy8xNSAxNTo1OSwgQnJp YW4gQ2FtcGJlbGwgd3JvdGU6PGJyPg0KJmd0OyBPbmUgcHJvYmxlbSwgSSB0aGluaywgd2l0aCB0 b2tlbiBleGNoYW5nZSBpcyB0aGF0IGl0IGNhbiBiZSByZWFsbHk8YnI+DQomZ3Q7IHNpbXBsZSAo dG9rZW4gaW4gYW5kIHRva2VuIG91dCkgYW5kIHJlYWxseSBjb21wbGljYXRlZCAoY2xpZW50IFgg d2FudHM8YnI+DQomZ3Q7IGEgdG9rZW4gdGhhdCBzYXlzIHVzZXIgQSBpcyBkb2luZyBzb21ldGhp bmcgb24gYmVoYWxmIG9mIHVzZXIgQikgYXQ8YnI+DQomZ3Q7IHRoZSBzYW1lIHRpbWUuPGJyPg0K Jmd0Ozxicj4NCiZndDsgSSBwdXQgZm9ydGggPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWNhbXBiZWxsLW9hdXRoLXN0cy0wMSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhbXBiZWxsLW9hdXRoLXN0cy0wMTwvYT4g aW48YnI+DQomZ3Q7IGFuIGF0dGVtcHQgdG8gc2ltcGxpZnkgdGhpbmdzIGFuZCBleHByZXNzIHdo YXQgSSBlbnZpc2lvbmVkIGFzIGFuPGJyPg0KJmd0OyBPQXV0aCBiYXNlZCB0b2tlbiBleGNoYW5n ZSBmcmFtZXdvcmsuIFRob3VnaCBpdCBsaWtlbHkgb25seSBtdWRkaWVkPGJyPg0KJmd0OyB0aGUg d2F0ZXJzIDopPGJyPg0KJmd0Ozxicj4NCiZndDsgT24gV2VkLCBKdWwgMSwgMjAxNSBhdCA3OjA3 IEFNLCBTZXJnZXkgQmVyeW96a2luICZsdDs8YSBocmVmPSJtYWlsdG86c2JlcnlvemtpbkBnbWFp bC5jb20iPnNiZXJ5b3praW5AZ21haWwuY29tPC9hPjxicj4NCiZndDsgJmx0O21haWx0bzo8YSBo cmVmPSJtYWlsdG86c2JlcnlvemtpbkBnbWFpbC5jb20iPnNiZXJ5b3praW5AZ21haWwuY29tPC9h PiZndDsmZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtI aSBKdXN0aW48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJpY2hlci1vYXV0aC1jaGFpbi0wMCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yaWNoZXIt b2F1dGgtY2hhaW4tMDA8L2E+IGlzIG11Y2g8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtl YXNpZXIgdG8gcmVhZCwgdGhhdCBJIGNhbiB0ZWxsIGZvciBzdXJlLCBhdCBsZWFzdCBpdCBpcyBv YnZpb3VzIHdoeTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2EgZ2l2ZW4gZW50aXR5IChS UzEpIG1heSB3YW50IHRvIGV4Y2hhbmdlIHRoZSBjdXJyZW50IHRva2VuIHByb3ZpZGVkPGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7YnkgYSBjbGllbnQgZm9yIGEgbmV3IHRva2VuLiBEZWZp bml0ZWx5IGVhc2lseSBpbXBsZW1lbnRhYmxlLi4uPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwO09uZSB0aGluZyBJJ20gbm90IHN1cmUgaW4gdGhlIGRyYWZ0LXJpY2hlci1v YXV0aC1jaGFpbi0wMCBhYm91dCBpczxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO29uIGJl aGFsZiBvZiB3aG9zZSBlbnRpdHkgUlMxIHdpbGwgYmUgYWN0aW5nIG9uY2UgaXQgc3RhcnRzPGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7YWNjZXNzaW5nIFJTMiwgT24gQmVoYWxmIE9mIFJP LCBvciBtYXkgYmUgT24gQmVoYWxmIE9mIChSTyAmIzQzOzxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwO0NsaWVudCksIG9yIG1heSBiZSBpdCBpcyBPbiBCZWhhbGYgT2YgUk8gJiM0MzsgQWN0 IEFzIENsaWVudCA/IFRoZSBsYXN0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7b25lIHNl ZW1zIG1vc3QgbG9naWNhbCB0byBtZS4uLjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDtUaGFua3MsIFNlcmdleTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7T24gMDEvMDcvMTUgMTM6MTgsIEp1c3RpbiBSaWNoZXIgd3JvdGU6PGJy Pg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QXMgaXQn cyB3cml0dGVuIHJpZ2h0IG5vdywgaXQncyBhIHRyYW5zbGF0aW9uIG9mIHNvbWUgV1MtKjxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y29uY2VwdHMgaW50bzxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SldUIGZvcm1hdC4gSXQncyBu b3QgcmVhbGx5IE9BdXRoLXkgKHNpbmNlIHRoZSBjbGllbnQgaGFzIHRvPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt1bmRlcnN0YW5kPGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0aGUgdG9rZW4gZm9ybWF0IGFsb25nIHdpdGggZXZl cnlvbmUgZWxzZSwgYW5kIGFjY29yZGluZyB0byB0aGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO2F1dGhvcnM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO3RoZSBhcnRpZmFjdHMgbWlnaHQgbm90IGV2ZW4gYmUgJnF1b3Q7T0F1dGgg dG9rZW5zJnF1b3Q7KSwgYW5kIHRoYXQncyBteSBtYWluPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtpc3N1ZSB3aXRoIHRoZSBkb2N1bWVudC4gWWVhcnMgYWdvLCBJ IHByb3Bvc2VkIGFuIE9BdXRoLWJhc2VkPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDt0b2tlbiBzd2FwPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDttZWNoYW5pc206PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXJpY2hlci1vYXV0aC1jaGFpbi0wMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1yaWNoZXItb2F1dGgtY2hhaW4tMDA8L2E+PGJyPg0KJmd0Ozxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhpcyB3b3JrcyB3aXRob3V0 IGRlZmluaW5nIHNlbWFudGljcyBvZiB0aGUgdG9rZW5zIHRoZW1zZWx2ZXMsIGp1c3Q8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2xpa2UgdGhlIHJlc3Qgb2YgT0F1 dGguIEkndmUgcHJvcG9zZWQgdG8gdGhlIGF1dGhvcnMgb2YgdGhlIGN1cnJlbnQ8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0IHRoYXQgaXQgc2hvdWxkIGlu Y29ycG9yYXRlIGJvdGggc2VtYW50aWMgKHVzaW5nIEpXVCkgYW5kPGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzeW50YWN0aWM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyh1c2luZyBhIHNpbXBsZSB0b2tlbi1hZ25vc3RpYyBncmFu dCkgdG9rZW4gc3dhcCBtZWNoYW5pc21zLCBhbmQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO3RoYXQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO3RoZSB0d28gY291bGQgYmUgZWFzaWx5IGNvbXBhdGlibGUuPGJyPg0KJmd0Ozxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtLSBKdXN0aW48 YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtPbiA3 LzEvMjAxNSA2OjM1IEFNLCBTZXJnZXkgQmVyeW96a2luIHdyb3RlOjxicj4NCiZndDs8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SG1tLi4u IHBlcmhhcHMgdGhlIGNsdWUgaXMgaW4gdGhlIGRyYWZ0IHRpdGxlLDxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0b2tlbi1leGNoYW5nZSwg c28gbWF5PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO2JlIGl0IGlzIGEgY2FzZSBvZiB0aGUgZ2l2ZW4gYWNjZXNzIHRva2VuICgmcXVvdDtv bl9iZWhhbGZfb2YmcXVvdDsgb3I8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7YWN0X2FzJnF1b3Q7PGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2NsYWltKSBiZWluZyB1c2Vk IHRvIHJlcXVlc3QgYSBuZXcgc2VjdXJpdHkgdG9rZW4uIE9uZSBjYW48YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7b25seSBndWVzczxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0aG91 Z2gsIGRvZXMgbm90IHNlZW0gbGlrZSB0aGUgYXV0aG9ycyBhcmUga2VlbiB0byBhbnN3ZXI8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dGhl IG5ld2JpZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtxdWVzdGlvbnMuLi48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0NoZWVycywgU2VyZ2V5PGJyPg0KJmd0Ozxi cj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7T24gMzAvMDYvMTUgMTM6MzgsIFNlcmdleSBCZXJ5b3praW4gd3JvdGU6PGJyPg0K Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO0hpLDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0NhbiB5b3UgcGxlYXNlIGV4cGxh aW4gd2hhdCBpcyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7T24tQmVoYWxm LU9mPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7c2VtYW50aWNzIGRlc2NyaWJlZCBpbiB0aGU8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTAxIGFuZCB0aGU8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtpbXBsaWNpdCBPbi1CZWhhbGYtT2Ygc2VtYW50aWNzIGEgY2xpZW50IE9BdXRoMiB0b2tlbjxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO3Bvc3Nlc3NlcyA/PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0ZvciBleGFt cGxlLCBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTAxIG1lbnRpb25zOjxicj4NCiZn dDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtXaGVyZWFzLCB3aXRoIG9uLWJlaGFsZi1vZiBzZW1hbnRp Y3MsIHByaW5jaXBhbCBBIHN0aWxsPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aGFzIGl0cyBvd248YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtpZGVudGl0eSBzZXBhcmF0ZSBmcm9tIEIgYW5kIGl0IGlzIGV4cGxpY2l0bHkgdW5kZXJz dG9vZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO3RoYXQgd2hpbGUgQjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO21heSBoYXZlIGRl bGVnYXRlZCBpdHMgcmlnaHRzIHRvIEEsIGFueSBhY3Rpb25zIHRha2VuPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 YXJlIGJlaW5nIHRha2VuIGJ5PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QSBhbmQgbm90IEIuIEluIGEgc2Vuc2Us IEEgaXMgYW4gYWdlbnQgZm9yIEIuJnF1b3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RoaXMg aXMgYSB0eXBpY2FsIGNhc2Ugd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGZsb3c8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDt3aGVyZSBhIGNsaWVudDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2FwcGxpY2F0aW9uIGFjdHMgb24t YmVoYWxmLW9mIHRoZSB1c2VyIHdobyBhdXRob3JpemVkPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dGhpcyBhcHBs aWNhdGlvbiA/PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1NvcnJ5IGlmIEknbSBtaXNzaW5nIHNv bWV0aGluZzxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtDaGVlcnMsIFNlcmdleTxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO09uIDI1LzA2LzE1IDIyOjI4LCBNaWtlIEpvbmVzIHdyb3RlOjxicj4NCiZndDs8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RoYXTigJlzIHdoYXQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9h dXRoLXRva2VuLWV4Y2hhbmdlLTAxIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMDE8L2E+PGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtpczxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YWJvdXQu PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Q2hlZXJzLDxicj4NCiZndDs8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0tIE1pa2U8YnI+DQomZ3Q7PGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsqRnJvbToqT0F1dGggW21haWx0bzo8YSBocmVmPSJtYWlsdG86b2F1 dGgtYm91bmNlc0BpZXRmLm9yZyI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmciPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0O10gKk9uIEJlaGFsZiBP ZiAqVml2ZWs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0Jpc3dhczxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7LVQgKHZpYmlzd2FzIC0gWE9SSUFOVCBDT1JQT1JBVElPTiBhdCBDaXNj byk8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOypTZW50OiogVGh1cnNkYXksIEp1bmUgMjUs IDIwMTUgMjoyMCBQTTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7KlRvOiogPGEgaHJlZj0i bWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBo cmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOypTdWJqZWN0OiogW09BVVRILVdHXSBKV1QgVG9rZW4gb24t YmVoYWxmIG9mIFVzZTxicj4NCiZndDsgY2FzZTxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO0hpIEFsbCw8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO0kgYW0gbG9va2luZyB0byBzb2x2ZSBhIHVzZS1jYXNlIHNpbWlsYXIgdG88 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1dTLVNlY3VyaXR5IE9uLUJlaGFsZi1PZjxicj4N CiZndDs8YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJodHRwOi8vZG9jcy5vYXNpcy1vcGVuLm9yZy93 cy1zeC93cy10cnVzdC92MS40L2VycmF0YTAxL29zL3dzLXRydXN0LTEiIHRhcmdldD0iX2JsYW5r Ij5odHRwOi8vZG9jcy5vYXNpcy1vcGVuLm9yZy93cy1zeC93cy10cnVzdC92MS40L2VycmF0YTAx L29zL3dzLXRydXN0LTE8L2E+PGJyPg0KJmd0OyAuNC1lcnJhdGEwMS1vcy1jb21wbGV0ZS5odG1s I19Ub2MzMjU2NTg5ODAmZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO3dpdGggT0F1dGggSldUIFRva2VuLjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SXMgdGhlcmUgYSBzdGFuZGFyZCBjbGFpbSB3aGlj aCB3ZSBjYW4gZGVmaW5lPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt3aXRoaW4gdGhlIE9B dXRoIEpXVDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7d2hpY2ggZGVub3RlIHRoZSBPbi1i ZWhhbGYtb2YgVXNlci48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtGb3Ig ZS5nLiwgYSBDdXN0b21lciBSZXByZXNlbnRhdGl2ZSB0cnlpbmcgdG8gY3JlYXRlPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDt0b2tlbiBvbiBiZWhhbGYgb2Y8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO2EgY3VzdG9tZXIgYW5kIHRyeWluZyB0byBleGVjdXRlIHNlcnZpY2VzIHNwZWNp ZmljPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtmb3IgdGhhdCBzcGVjaWZpYzxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y3VzdG9tZXIuPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7UmVnYXJkcyw8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtWaXZlayBCaXN3YXMsPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtDSVNTUDxicj4NCiZn dDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOypDaXNjbyBTeXN0ZW1zLCBJbmMgJmx0Ozxh IGhyZWY9Imh0dHA6Ly93d3cuY2lzY28uY29tLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cu Y2lzY28uY29tLzwvYT4mZ3Q7Kjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OypCbGRnLiBKLCBTYW4gSm9zZSwgVVNBLCo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsqUGhvbmU6IDxhIGhyZWY9InRlbDolMkIxJTIwNDA4JTIwNTI3JTIwOTE3NiI+JiM0 MzsxIDQwOCA1MjcgOTE3NjwvYT48YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJ0ZWw6JTJCMSUyMDQw OCUyMDUyNyUyMDkxNzYiPnRlbDolMkIxJTIwNDA4JTIwNTI3JTIwOTE3NjwvYT4mZ3Q7Kjxicj4N CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO09BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT4g Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3Jn PC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCiZndDs8YnI+DQom Z3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5P QXV0aEBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5v cmciPk9BdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhA aWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5P QXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aDwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwO19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7T0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRm Lm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRo QGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQom Z3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IE9B dXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn Ij5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwv YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY1PR0301MB12437C5CFE06B7837375E5DBA6930CY1PR0301MB1243_-- From nobody Mon Jul 6 14:18:55 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEFE61A03C7 for ; Mon, 6 Jul 2015 14:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDNNh7Fw0855 for ; Mon, 6 Jul 2015 14:18:48 -0700 (PDT) Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com [209.85.220.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 214FD1A01C6 for ; Mon, 6 Jul 2015 14:18:48 -0700 (PDT) Received: by qkbp125 with SMTP id p125so126783040qkb.2 for ; Mon, 06 Jul 2015 14:18: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:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Xo8fhm6MLxYdTYHVX8McH+nm2CbsItOlL3jcb0aAxYg=; b=iRWWA93lkyZb414ImQRC3uAz28cReeBHPbhAdo7M6FttF8YJ7TA8Jn9hJukgTPd1A1 PrrmczTj/D24QIjtIze6s9cJTTtm02GjGiv0QvaoyVSnsRX4yhmVrqEO6SuVu5XLFcUs gDXDCLtH/x9zW28IPKRUoXZoBhcxju1+2FpahVxQpdvq0icdAePqZqXX+GBOafmTnEzo KwvFL7w/9mByvHbaC1lR/+FXkDWiY7plonv2VoO5yhXDJ/q7HG7WWENmLLytBXL3x7MX VMeWo+7aX35JNkIXi7k02o/rrD3jrzpsK9UCbZxB5J1V7hlJdSpiY2S6uVBAdbkPdq/1 3Utw== X-Gm-Message-State: ALoCoQlEG5ER1gjCUo/Otv/0d1XTR+lInVmfMjbf+o3r4LIt3WxhBcvtlNrhEQM676y2aVUZrRjC X-Received: by 10.141.19.11 with SMTP id v11mr1700561qhd.44.1436217527281; Mon, 06 Jul 2015 14:18:47 -0700 (PDT) Received: from [192.168.8.101] ([181.202.207.194]) by mx.google.com with ESMTPSA id 47sm10045905qgt.15.2015.07.06.14.18.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Jul 2015 14:18:46 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_E675EF3F-443C-414B-A7D3-C5E58669D8D9" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: John Bradley In-Reply-To: Date: Mon, 6 Jul 2015 18:18:37 -0300 Message-Id: <4816587D-B585-4136-8587-5DA539A550D8@ve7jtb.com> References: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> <55928DB3.7090300@gmail.com> <5593C270.7000008@gmail.com> <5593DA7D.80401@mit.edu> <5593E5FD.3050403@gmail.com> <559A676F.3070008@gmail.com> To: Anthony Nadalin X-Mailer: Apple Mail (2.2102) Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 21:18:55 -0000 --Apple-Mail=_E675EF3F-443C-414B-A7D3-C5E58669D8D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I keep providing links to MS documentation that leads one to a different = conclusion for WIF. https://msdn.microsoft.com/en-us/library/ee748487.aspx = and = https://msdn.microsoft.com/en-us/library/ee517269.aspx An ActAs RST element indicates that the requestor wants a token that = contains claims about two distinct entities: the requestor, and an = external entity represented by the token in the ActAs element. An OnBehalfOf RST element indicates that the requestor wants a token = that contains claims only about one entity: the external entity = represented by the token in the OnBehalfOf element. That reflects my understanding that prior to WS-Trust 1.4 OnBehalfOf was = impersonation and in WS-Trust 1.4 was added to provide the composite = assertion. The JBOS docs and examples are also consistent with this = https://docs.jboss.org/author/display/JBWS/ActAs+WS-Trust+Scenario Or these: = https://thilinamb.wordpress.com/2009/08/21/identity-delegation-in-ws-trust= -1-4/ = http://blogs.msdn.com/b/alikl/archive/2011/03/15/windows-identity-foundati= on-wif-the-difference-between-actas-and-onbehalfof.aspx?Redirected=3Dtrue = https://www.netiq.com/documentation/netiqaccessmanager4/identityserverhelp= /data/ws-trust_usecases.html Given that you were one of the authors, you are as close to = authoritative as one could get. =20 However as far as I can tell there is some confusion that needs to be = resolved.=20 I agree we need the functionality of the two, and I don=E2=80=99t really = care what they are called as long as we are not confusing developers. John B. > On Jul 6, 2015, at 5:43 PM, Anthony Nadalin = wrote: >=20 > The WS-Trust =E2=80=9CActAs=E2=80=9D mimics the Windows Kerberos = Protocol Transition (impersonation) feature as this enables an account = to impersonate another account for the purpose of providing access to = resources. In a typical scenario, the impersonating account would be a = service account assigned to a web application or the computer account of = a web server. The impersonated account would be a user account requiring = access to resources (e.g. data in an SQL database) via a web = application. In this scenario, SQL server would be accessed by the = impersonating (service account) account, however access would be under = the context of the impersonated (user) account. > =20 > WS-Trust =E2=80=9COnBehalfOf=E2=80=9D mimics the Windows Kerberos = Constrained Delegation feature, which lets you limit the back-end = services for which a front-end service can request tickets on behalf of = another user. =E2=80=9COnBehalfOf=E2=80=9D allows a selected services = on a server can be granted for access by the impersonating account, = whilst other services on the same server, or services on other servers = are denied for access. > =20 > Maybe someone can summarize why they think the text for ActAs and = OnBehalfOf in WS-Trust or Windows Kerberos is wrong or swapped as I have = not seen a clear explanation other than John saying that Brian knows and = Brian saying John knows. <> > =20 > Our usage and use cases are based upon the deployed services of = WS-Trust and Kerberos support in Windows (workstation and server) and = Xbox. > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian = Campbell > Sent: Monday, July 6, 2015 11:29 AM > To: Mike Jones > Cc: oauth > Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case > =20 > Stating specific action items resulting from the ad-hoc meeting in = Dallas like that suggests some clear consensus was reached, which is not = at all the case. As I recall, several of us argued past one another for = an hour or so and decided to adjourn in order to go to the bar (okay, = and dinner too - but mostly beer). >=20 > The impression about reversal of terms, I think, comes from the text = in = https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3= = which hurts my head a little every-time I read it but does seems to = confuse things. The MSDN link = John gave is = much more to the point than WS-Trust (I don't believe WS-Trust can be = pointed to as a model of clarity). In the draft I wrote, I tried to = take Mike's text and clarify a distinction between impersonation and = delegation with = https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 = = and then also be very explicit about act-as vs. on-behalf-of in the = parameter definitions at = https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 = in a = manor that was consistent with WS-Trust and the MSDN explanation. I = could see value in breaking with that shaky legacy and using new terms = too. But I get the point of trying to keep with the old also and = potential for even more confusing by using new terms.=20 >=20 > I wrote draft-campbell-oauth-sts last year in response to the call for = adoption of jones-oauth-token-exchange (thread from the archive = ). = Though I didn't try and stand in the way and indicated a willingness to = collaborate on things. With the expectation, of course, that the details = would differ from the -00s and -01s as work progressed. Folks seemed = generally amenable to that = at = the time but little has happened since then. >=20 > Phil's earlier point about the priory of this getting pushed down has = some truth to it. But I still believe it's something that can provide a = lot of value in standardizing, if we do so in a reasonable way. > =20 >=20 >=20 >=20 >=20 > =20 >=20 > =20 > On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones = > = wrote: > It would surprise me if on-behalf-of and act-as were reversed with = respect WS-Trust, because the explanations of the terms came directly = from WS-Trust 1.4. I also think the chances of us reducing confusion by = inventing new terminology, rather than adding to it, would not be in our = favor. :-/ >=20 > FYI, the action items outstanding from our ad-hoc meeting on this = draft in Dallas are: > - Allowing security types other than JWT to also be used as the = act_as and on_behalf_of request values. > - Further integrating the mechanism into the existing OAuth = ecosystem - allowing use of access tokens or refresh tokens when = appropriate. >=20 > I plan to do the first today. The second is probably more than I'll = get done today before the submission cutoff. I agree with John that it = would be useful to have discussions on this in Prague on the best way to = achieve this further integration. I'll plan to come into the Prague = meeting with a concrete proposal for review. >=20 > Best wishes, > -- Mike >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org = ] On Behalf Of John Bradley > Sent: Monday, July 06, 2015 8:13 AM > To: Brian Campbell > Cc: oauth > Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case >=20 > Yes unfortunately we haven=E2=80=99t made any progress on this since = accepting Mike=E2=80=99s first draft. >=20 > His proposal is basically for a new endpoint while Brian tired to fit = it into the existing token endpoint. >=20 > I think draft-ietf-oauth-token-exchange-01 still has OnBehalfOf and = ActAs reversed compared to WS-Trust 1.4. > see https://msdn.microsoft.com/en-us/library/ee748487.aspx = for the short = explanation. >=20 > I think Brian is closer in explaining it. >=20 > In fairness because WS-Trust originally only had On-Behalf-Of the = naming and what people put in tokens is a bit muddled in many = implementations. > I think many times it is how WIF implemented it that people copied. >=20 > It may be better to have new terms that are clear such as = impersonation and composite. >=20 > The WG needs to decide if this is going to be an entirely new = endpoint, free of the Token endpoint semantics. There are plusses and = minuses to both options. >=20 > Also while it is nice to be pure and talk about abstract security = tokens, it would be good to give some guidance on what a composite = security token would look like for interoperability. >=20 > There are also issues around how this would work with proof of = possession security tokens, both as input and output. >=20 > Perhaps we can make some progress on this in Prague. >=20 > John B. >=20 >=20 >=20 >=20 > > On Jul 6, 2015, at 11:04 AM, Brian Campbell = > wrote: > > > > Thanks Sergey, > > > > The goal of draft-campbell-oauth-sts was to be consistent with OAuth = 2.0 and thus hopefully familiar to developers and easy to understand and = implement (especially from the client side). It's also intended to be = flexible in order to accommodate a variety of use-cases including the = chaining type cases that Justin's draft covers. > > > > Specifying a security_token_type of the returned token is just a way = of providing more info to the client about the token (i.e. is this a JWT = or a SAML token or something else) via a URI. It's not always needed but = in STS style cases the tokens are not always opaque to the client and = the parameter just provides info about the returned token. > > > > On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin = > wrote: > > Hi Brian > > > > I've read the text, I like it is still pure OAuth2, with few extra = parameters added to the access token request, and a key response = property being 'access_token' as opposed to 'security_access_token' as = in the draft-ietf-oauth-token-exchange-01. > > It appears draft-campbell-oauth-sts-01 can cover a = draft-richer-oauth-chain-00 case with the on_behalf_of (and/or act_as ?) = property being an original client token but not 100% sure given = draft-richer-oauth-chain-00 covers a specific case. > > > > One thing I'm not sure about is what is the purpose of specifying a > > security_token_type of the returned access token > > > > Thanks, Sergey > > > > On 01/07/15 15:59, Brian Campbell wrote: > > One problem, I think, with token exchange is that it can be really > > simple (token in and token out) and really complicated (client X = wants > > a token that says user A is doing something on behalf of user B) at > > the same time. > > > > I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 = in > > an attempt to simplify things and express what I envisioned as an > > OAuth based token exchange framework. Though it likely only muddied > > the waters :) > > > > On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin = > > >> wrote: > > > > Hi Justin > > > > https://tools.ietf.org/html/draft-richer-oauth-chain-00 = is much > > easier to read, that I can tell for sure, at least it is obvious = why > > a given entity (RS1) may want to exchange the current token = provided > > by a client for a new token. Definitely easily implementable... > > > > One thing I'm not sure in the draft-richer-oauth-chain-00 about = is > > on behalf of whose entity RS1 will be acting once it starts > > accessing RS2, On Behalf Of RO, or may be On Behalf Of (RO + > > Client), or may be it is On Behalf Of RO + Act As Client ? The = last > > one seems most logical to me... > > > > Thanks, Sergey > > > > > > On 01/07/15 13:18, Justin Richer wrote: > > > > As it's written right now, it's a translation of some WS-* > > concepts into > > JWT format. It's not really OAuth-y (since the client has to > > understand > > the token format along with everyone else, and according to = the > > authors > > the artifacts might not even be "OAuth tokens"), and that's = my main > > issue with the document. Years ago, I proposed an = OAuth-based > > token swap > > mechanism: > > > > https://tools.ietf.org/html/draft-richer-oauth-chain-00 = > > > > This works without defining semantics of the tokens = themselves, just > > like the rest of OAuth. I've proposed to the authors of the = current > > draft that it should incorporate both semantic (using JWT) = and > > syntactic > > (using a simple token-agnostic grant) token swap mechanisms, = and > > that > > the two could be easily compatible. > > > > -- Justin > > > > On 7/1/2015 6:35 AM, Sergey Beryozkin wrote: > > > > Hmm... perhaps the clue is in the draft title, > > token-exchange, so may > > be it is a case of the given access token = ("on_behalf_of" or > > "act_as" > > claim) being used to request a new security token. One = can > > only guess > > though, does not seem like the authors are keen to = answer > > the newbie > > questions... > > > > Cheers, Sergey > > > > > > On 30/06/15 13:38, Sergey Beryozkin wrote: > > > > Hi, > > Can you please explain what is the difference = between > > On-Behalf-Of > > semantics described in the > > draft-ietf-oauth-token-exchange-01 and the > > implicit On-Behalf-Of semantics a client OAuth2 = token > > possesses ? > > > > For example, draft-ietf-oauth-token-exchange-01 = mentions: > > > > "Whereas, with on-behalf-of semantics, principal A = still > > has its own > > identity separate from B and it is explicitly = understood > > that while B > > may have delegated its rights to A, any actions = taken > > are being taken by > > A and not B. In a sense, A is an agent for B." > > > > This is a typical case with the authorization code = flow > > where a client > > application acts on-behalf-of the user who = authorized > > this application ? > > > > Sorry if I'm missing something > > > > Cheers, Sergey > > On 25/06/15 22:28, Mike Jones wrote: > > > > That=E2=80=99s what > > = https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 = > > is > > about. > > > > Cheers, > > > > -- Mike > > > > *From:*OAuth [mailto:oauth-bounces@ietf.org = > > >] *On Behalf Of *Vivek > > Biswas > > -T (vibiswas - XORIANT CORPORATION at Cisco) > > *Sent:* Thursday, June 25, 2015 2:20 PM > > *To:* OAuth@ietf.org = > > > *Subject:* [OAUTH-WG] JWT Token on-behalf of Use > > case > > > > Hi All, > > > > I am looking to solve a use-case similar to > > WS-Security On-Behalf-Of > > > > = > > .4-errata01-os-complete.html#_Toc325658980> > > > > > > with OAuth JWT Token. > > > > Is there a standard claim which we can = define > > within the OAuth JWT > > which denote the On-behalf-of User. > > > > For e.g., a Customer Representative trying to = create > > token on behalf of > > a customer and trying to execute services = specific > > for that specific > > customer. > > > > Regards, > > > > Vivek Biswas, > > CISSP > > > > *Cisco Systems, Inc >* > > > > *Bldg. J, San Jose, USA,* > > > > *Phone: +1 408 527 9176 = > > >* > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@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 = >=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=_E675EF3F-443C-414B-A7D3-C5E58669D8D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I keep providing links to MS documentation that leads one to = a different conclusion for WIF.
https://msdn.microsoft.com/en-us/library/ee748487.aspx a= nd https://msdn.microsoft.com/en-us/library/ee517269.aspx
  • An ActAs RST element indicates that = the requestor wants a token that contains claims about two distinct = entities: the requestor, and an external entity represented by the token = in the ActAs element.

  • An OnBehalfOf RST = element indicates that the requestor wants a token that contains claims = only about one entity: the external entity represented by the token in = the OnBehalfOf element.

That reflects my understanding that prior to WS-Trust 1.4 = OnBehalfOf was impersonation and in WS-Trust 1.4 was added to provide = the composite assertion.

The JBOS docs and examples are also consistent with = this https://docs.jboss.org/author/display/JBWS/ActAs+WS-Trust+Scena= rio
Or these: https://thilinamb.wordpress.com/2009/08/21/identity-delegation-= in-ws-trust-1-4/
        =         http://blogs.msdn.com/b/alikl/archive/2011/03/15/windows-identi= ty-foundation-wif-the-difference-between-actas-and-onbehalfof.aspx?Redirec= ted=3Dtrue
          =       https://www.netiq.com/documentation/netiqaccessmanager4/identit= yserverhelp/data/ws-trust_usecases.html

Given that you were one of the authors, = you are as close to authoritative as one could get. =   

However as far as I can tell there is some confusion that = needs to be resolved. 

I agree we need the functionality of the two, and I don=E2=80=99= t really care what they are called as long as we are not confusing = developers.


John B.

On Jul 6, 2015, at 5:43 PM, = Anthony Nadalin <tonynad@microsoft.com> wrote:

The WS-Trust =E2=80=9CActAs=E2=80=9D = mimics the Windows Kerberos Protocol Transition (impersonation) =  feature as this enables an account to impersonate another account = for the purpose of providing access to resources. In a typical scenario, = the impersonating account would be a service account assigned to a web = application or the computer account of a web server. The impersonated = account would be a user account requiring access to resources (e.g. data = in an SQL database) via a web application. In this scenario, SQL server = would be accessed by the impersonating (service account) account, = however access would be under the context of the impersonated (user) = account.
 
WS-Trust =E2=80=9COnBehalfOf=E2=80=9D  mimics the = Windows Kerberos Constrained Delegation feature, which lets you limit = the back-end services for which a front-end service can request tickets = on behalf of another user. =E2=80=9COnBehalfOf=E2=80=9D  allows a = selected services on a server can be granted for access by the = impersonating account, whilst other services on the same server, or = services on other servers are denied for access.
 
Maybe someone can = summarize why they think the text for ActAs and OnBehalfOf in WS-Trust = or Windows Kerberos is wrong or swapped as I have not seen a clear = explanation other than John saying that Brian knows and Brian saying = John knows. 
 
Our= usage and use cases are based upon the deployed services of WS-Trust = and Kerberos support in Windows (workstation and server) and Xbox.
 
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf = Of Brian = Campbell
Sent: Monday, July 6, 2015 11:29 = AM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: oauth= <oauth@ietf.org>
Subject: Re: [OAUTH-WG] JWT Token = on-behalf of Use case
 

Stating specific action items = resulting from the ad-hoc meeting in Dallas like that suggests some = clear consensus was reached, which is not at all the case. As I recall, = several of us argued past one another for an hour or so and decided to = adjourn in order to go to the bar (okay, and dinner too - but mostly = beer).

The impression about reversal of terms, I think, comes = from the text in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#= section-1.3 which = hurts my head a little every-time I read it but does seems to confuse = things. The MSDN link John gave is much more to = the point than WS-Trust (I don't believe WS-Trust can be pointed to as a = model of clarity).  In the draft I wrote, I tried to take Mike's = text and clarify a distinction between impersonation and delegation = with https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section= -1.3 and then also = be very explicit about act-as vs. on-behalf-of in the parameter = definitions at https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section= -2 in a manor that = was consistent with WS-Trust and the MSDN explanation. I could see value = in breaking with that shaky legacy and using new terms too. But I get = the point of trying to keep with the old also and potential for even = more confusing by using new terms. 

I = wrote draft-campbell-oauth-sts last year in response to the call for = adoption of jones-oauth-token-exchange (thread from the archive). Though I didn't try and stand = in the way and indicated a willingness to collaborate on things. With = the expectation, of course, that the details would differ from the -00s = and -01s as work progressed. Folks seemed generally amenable to that at the time but little has = happened since then.

Phil's earlier point about the priory of = this getting pushed down has some truth to it. But I still believe it's = something that can provide a lot of value in standardizing, if we do so = in a reasonable way.

 



 

 
On Mon, Jul 6, 2015 = at 10:33 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
It would surprise me = if on-behalf-of and act-as were reversed with respect WS-Trust, because = the explanations of the terms came directly from WS-Trust 1.4.  I = also think the chances of us reducing confusion by inventing new = terminology, rather than adding to it, would not be in our favor. :-/

FYI, the action items outstanding from our = ad-hoc meeting on this draft in Dallas are:
  - = Allowing security types other than JWT to also be used as the act_as and = on_behalf_of request values.
  - Further integrating = the mechanism into the existing OAuth ecosystem - allowing use of access = tokens or refresh tokens when appropriate.

I = plan to do the first today.  The second is probably more than I'll = get done today before the submission cutoff.  I agree with John = that it would be useful to have discussions on this in Prague on the = best way to achieve this further integration.  I'll plan to come = into the Prague meeting with a concrete proposal for review.

            =                     = Best wishes,
            =                     -- = Mike

-----Original = Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On = Behalf Of John Bradley
Sent: Monday, July 06, 2015 8:13 = AM
To: Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case

Yes unfortunately we haven=E2=80=99t made any = progress on this since accepting Mike=E2=80=99s first draft.

His proposal is basically for a new endpoint = while Brian tired to fit it into the existing token endpoint.

I think draft-ietf-oauth-token-exchange-01 = still has OnBehalfOf and ActAs reversed compared to WS-Trust 1.4.
see https://msdn.microsoft.com/en-us/library/ee748487.aspx for the short = explanation.

I think Brian is closer in = explaining it.

In fairness because WS-Trust = originally only had On-Behalf-Of the naming and what people put in = tokens is a bit muddled in many implementations.
I think = many times it is how WIF implemented it that people copied.

It may be better to have new terms that are = clear such as impersonation and composite.

The WG needs to decide if this is going to be an entirely new = endpoint, free of the Token endpoint semantics.   There are = plusses and minuses to both options.

Also = while it is nice to be pure and talk about abstract security tokens, it = would be good to give some guidance on what a composite security token = would look like for interoperability.

There = are also issues around how this would work with proof of possession = security tokens, both as input and output.

Perhaps we can make some progress on this in Prague.

John B.




> On Jul 6, 2015, at 11:04 = AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
>> Thanks Sergey,
>
> = The goal of draft-campbell-oauth-sts was to be consistent with OAuth 2.0 = and thus hopefully familiar to developers and easy to understand and = implement (especially from the client side). It's also intended to be = flexible in order to accommodate a variety of use-cases including the = chaining type cases that Justin's draft covers.
>
> Specifying a security_token_type of the returned token = is just a way of providing more info to the client about the token (i.e. = is this a JWT or a SAML token or something else) via a URI. It's not = always needed but in STS style cases the tokens are not always opaque to = the client and the parameter just provides info about the returned = token.
>
> On Mon, Jul 6, 2015 at 5:33 = AM, Sergey Beryozkin <sberyozkin@gmail.com> wrote:
> Hi = Brian
>
> I've read the text, I like = it is still pure OAuth2, with few extra parameters added to the access = token request, and a key response property being 'access_token' as = opposed to 'security_access_token' as in the = draft-ietf-oauth-token-exchange-01.
> It appears = draft-campbell-oauth-sts-01 can cover a draft-richer-oauth-chain-00 case = with the on_behalf_of (and/or act_as ?) property being an original = client token but not 100% sure given draft-richer-oauth-chain-00 covers = a specific case.
>
> One thing I'm not = sure about is what is the purpose of specifying a
> = security_token_type of the returned access token
>
> Thanks, Sergey
>
> On = 01/07/15 15:59, Brian Campbell wrote:
> One problem, I = think, with token exchange is that it can be really
> = simple (token in and token out) and really complicated (client X = wants
> a token that says user A is doing something on = behalf of user B) at
> the same time.
>
> I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in
> an = attempt to simplify things and express what I envisioned as an
> OAuth based token exchange framework. Though it likely = only muddied
> the waters :)
>
> On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin <sberyozkin@gmail.com
> <mailto:sberyozkin@gmail.com>> wrote:
>
>     Hi Justin
>
>     https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much
>     easier to read, that I can tell for = sure, at least it is obvious why
>     a = given entity (RS1) may want to exchange the current token provided
>     by a client for a new token. = Definitely easily implementable...
>
>     One thing I'm not sure in the = draft-richer-oauth-chain-00 about is
>    =  on behalf of whose entity RS1 will be acting once it starts
>     accessing RS2, On Behalf Of RO, or = may be On Behalf Of (RO +
>     Client), = or may be it is On Behalf Of RO + Act As Client ? The last
>     one seems most logical to me...
>
>     Thanks, Sergey
>
>
>    =  On 01/07/15 13:18, Justin Richer wrote:
>
>         As it's written right = now, it's a translation of some WS-*
>    =      concepts into
>      =    JWT format. It's not really OAuth-y (since the client has = to
>         understand
>         the token format along = with everyone else, and according to the
>    =      authors
>      =    the artifacts might not even be "OAuth tokens"), and that's = my main
>         issue with = the document. Years ago, I proposed an OAuth-based
>         token swap
>         mechanism:
>
>         https://tools.ietf.org/html/draft-richer-oauth-chain-00
>
>         This = works without defining semantics of the tokens themselves, just
>         like the rest of OAuth. = I've proposed to the authors of the current
>  =        draft that it should incorporate both = semantic (using JWT) and
>        =  syntactic
>        =  (using a simple token-agnostic grant) token swap mechanisms, = and
>         that
>         the two could be easily = compatible.
>
>      =       -- Justin
>
> =        On 7/1/2015 6:35 AM, Sergey Beryozkin = wrote:
>
>        =      Hmm... perhaps the clue is in the draft title,
>            =  token-exchange, so may
>      =        be it is a case of the given access token = ("on_behalf_of" or
>          =    "act_as"
>        =      claim) being used to request a new security token. = One can
>            =  only guess
>          =    though, does not seem like the authors are keen to = answer
>            =  the newbie
>          =    questions...
>
>  =            Cheers, Sergey
>
>
>    =          On 30/06/15 13:38, Sergey Beryozkin = wrote:
>
>        =          Hi,
>    =              Can you please explain = what is the difference between
>      =            On-Behalf-Of
>                =  semantics described in the
>      =           =  draft-ietf-oauth-token-exchange-01 and the
>  =                implicit = On-Behalf-Of semantics a client OAuth2 token
>  =                possesses ?
>
>          =        For example, = draft-ietf-oauth-token-exchange-01 mentions:
>
>                =  "Whereas, with on-behalf-of semantics, principal A still
>                =  has its own
>          =        identity separate from B and it is explicitly = understood
>            =      that while B
>      =            may have delegated its rights = to A, any actions taken
>        =          are being taken by
>                =  A and not B. In a sense, A is an agent for B."
>>                =  This is a typical case with the authorization code flow
>                =  where a client
>        =          application acts on-behalf-of the user = who authorized
>          =        this application ?
>
>                =  Sorry if I'm missing something
>
>                =  Cheers, Sergey
>        =          On 25/06/15 22:28, Mike Jones = wrote:
>
>        =              That=E2=80=99s what
>                =      https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01<= /a>
>              =        is
>      =                about.
>
>          =            Cheers,
>
>                =      -- Mike
>
>  =                   =  *From:*OAuth [mailto:oauth-bounces@ietf.org
>    =                 =  <mailto:oauth-bounces@ietf.org>] *On Behalf Of *Vivek
>                =      Biswas
>        =              -T (vibiswas - XORIANT = CORPORATION at Cisco)
>        =              *Sent:* Thursday, June = 25, 2015 2:20 PM
>          =            *To:* OAuth@ietf.org <mailto:OAuth@ietf.org>
>  =                   =  *Subject:* [OAUTH-WG] JWT Token on-behalf of Use
> = case
>
>        =              Hi All,
>
>          =                I am looking to = solve a use-case similar to
>      =                WS-Security = On-Behalf-Of
>
> <http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-t= rust-1
> = .4-errata01-os-complete.html#_Toc325658980>
>
>
>          =            with OAuth JWT Token.
>
>          =                Is there a = standard claim which we can define
>    =                  within the = OAuth JWT
>            =          which denote the On-behalf-of User.
>
>          =            For e.g., a Customer = Representative trying to create
>      =                token on behalf = of
>              =        a customer and trying to execute services = specific
>            =          for that specific
>                =      customer.
>
>  =                   =  Regards,
>
>      =                Vivek Biswas,
>                =      CISSP
>
>  =                   =  *Cisco Systems, Inc <http://www.cisco.com/>*
>
>                =      *Bldg. J, San Jose, USA,*
>
>                =      *Phone: +1 408 527 9176
> <tel:%2B1%20408%20527%209176>*
>
>
>
>    =                 =  _______________________________________________
>                =      OAuth mailing list
>    =                  OAuth@ietf.org <mailto:OAuth@ietf.org>
>  =                    https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>            =  _______________________________________________
>             OAuth = mailing list
>            =  OAuth@ietf.org <mailto:OAuth@ietf.org>
>  =            https://www.ietf.org/mailman/listinfo/oauth
>
>
>    =      _______________________________________________
>         OAuth mailing list
>         OAuth@ietf.org <mailto:OAuth@ietf.org>
>  =        https://www.ietf.org/mailman/listinfo/oauth
>
>
>    =  _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>  =    https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
> = _______________________________________________
> OAuth = mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

= --Apple-Mail=_E675EF3F-443C-414B-A7D3-C5E58669D8D9-- From nobody Mon Jul 6 14:21:17 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7421A1A20 for ; Mon, 6 Jul 2015 14:21:10 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQykAKBTp3XF for ; Mon, 6 Jul 2015 14:21:04 -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 BEEFB1A03D5 for ; Mon, 6 Jul 2015 14:20:59 -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 t66LKwUj024974 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Jul 2015 21:20:59 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 t66LKwEV026744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Jul 2015 21:20:58 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t66LKwH9026373; Mon, 6 Jul 2015 21:20:58 GMT Received: from [10.97.54.140] (/24.244.23.177) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 06 Jul 2015 14:20:58 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-3B9B9226-D361-4B2A-A0C8-549A25EA1930 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12F70) In-Reply-To: Date: Mon, 6 Jul 2015 14:20:55 -0700 Content-Transfer-Encoding: 7bit Message-Id: <2BB85061-F141-478C-96B1-5086AFDA1F4F@oracle.com> References: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> <55928DB3.7090300@gmail.com> <5593C270.7000008@gmail.com> <5593DA7D.80401@mit.edu> <5593E5FD.3050403@gmail.com> <559A676F.3070008@gmail.com> To: Anthony Nadalin X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 21:21:11 -0000 --Apple-Mail-3B9B9226-D361-4B2A-A0C8-549A25EA1930 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think the original reasoning was sound, but the fact that so many remain c= onfused is good reason to go to new vocab. We could still have clarifying text that impersonate/composite is xxx and yy= y in kerberos etc.=20 Phil > On Jul 6, 2015, at 13:43, Anthony Nadalin wrote: >=20 > The WS-Trust =E2=80=9CActAs=E2=80=9D mimics the Windows Kerberos Protocol T= ransition (impersonation) feature as this enables an account to impersonate= another account for the purpose of providing access to resources. In a typi= cal scenario, the impersonating account would be a service account assigned t= o a web application or the computer account of a web server. The impersonate= d account would be a user account requiring access to resources (e.g. data i= n an SQL database) via a web application. In this scenario, SQL server would= be accessed by the impersonating (service account) account, however access w= ould be under the context of the impersonated (user) account. > =20 > WS-Trust =E2=80=9COnBehalfOf=E2=80=9D mimics the Windows Kerberos Constra= ined Delegation feature, which lets you limit the back-end services for whic= h a front-end service can request tickets on behalf of another user. =E2=80=9C= OnBehalfOf=E2=80=9D allows a selected services on a server can be granted f= or access by the impersonating account, whilst other services on the same se= rver, or services on other servers are denied for access. > =20 > Maybe someone can summarize why they think the text for ActAs and OnBehalf= Of in WS-Trust or Windows Kerberos is wrong or swapped as I have not seen a c= lear explanation other than John saying that Brian knows and Brian saying Jo= hn knows. > =20 > Our usage and use cases are based upon the deployed services of WS-Trust a= nd Kerberos support in Windows (workstation and server) and Xbox. > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell > Sent: Monday, July 6, 2015 11:29 AM > To: Mike Jones > Cc: oauth > Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case > =20 > Stating specific action items resulting from the ad-hoc meeting in Dallas l= ike that suggests some clear consensus was reached, which is not at all the c= ase. As I recall, several of us argued past one another for an hour or so an= d decided to adjourn in order to go to the bar (okay, and dinner too - but m= ostly beer). >=20 > The impression about reversal of terms, I think, comes from the text in ht= tps://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 whi= ch hurts my head a little every-time I read it but does seems to confuse thi= ngs. The MSDN link John gave is much more to the point than WS-Trust (I don'= t believe WS-Trust can be pointed to as a model of clarity). In the draft I= wrote, I tried to take Mike's text and clarify a distinction between impers= onation and delegation with https://tools.ietf.org/html/draft-campbell-oauth= -sts-01#section-1.3 and then also be very explicit about act-as vs. on-behal= f-of in the parameter definitions at https://tools.ietf.org/html/draft-campb= ell-oauth-sts-01#section-2 in a manor that was consistent with WS-Trust and t= he MSDN explanation. I could see value in breaking with that shaky legacy an= d using new terms too. But I get the point of trying to keep with the old al= so and potential for even more confusing by using new terms. >=20 > I wrote draft-campbell-oauth-sts last year in response to the call for ado= ption of jones-oauth-token-exchange (thread from the archive). Though I didn= 't try and stand in the way and indicated a willingness to collaborate on th= ings. With the expectation, of course, that the details would differ from th= e -00s and -01s as work progressed. Folks seemed generally amenable to that a= t the time but little has happened since then. >=20 > Phil's earlier point about the priory of this getting pushed down has some= truth to it. But I still believe it's something that can provide a lot of v= alue in standardizing, if we do so in a reasonable way. > =20 >=20 >=20 >=20 >=20 > =20 >=20 > =20 > On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones w= rote: > It would surprise me if on-behalf-of and act-as were reversed with respect= WS-Trust, because the explanations of the terms came directly from WS-Trust= 1.4. I also think the chances of us reducing confusion by inventing new te= rminology, rather than adding to it, would not be in our favor. :-/ >=20 > FYI, the action items outstanding from our ad-hoc meeting on this draft in= Dallas are: > - Allowing security types other than JWT to also be used as the act_as a= nd on_behalf_of request values. > - Further integrating the mechanism into the existing OAuth ecosystem - a= llowing use of access tokens or refresh tokens when appropriate. >=20 > I plan to do the first today. The second is probably more than I'll get d= one today before the submission cutoff. I agree with John that it would be u= seful to have discussions on this in Prague on the best way to achieve this f= urther integration. I'll plan to come into the Prague meeting with a concre= te proposal for review. >=20 > Best wishes, > -- Mike >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley > Sent: Monday, July 06, 2015 8:13 AM > To: Brian Campbell > Cc: oauth > Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case >=20 > Yes unfortunately we haven=E2=80=99t made any progress on this since accep= ting Mike=E2=80=99s first draft. >=20 > His proposal is basically for a new endpoint while Brian tired to fit it i= nto the existing token endpoint. >=20 > I think draft-ietf-oauth-token-exchange-01 still has OnBehalfOf and ActAs r= eversed compared to WS-Trust 1.4. > see https://msdn.microsoft.com/en-us/library/ee748487.aspx for the short e= xplanation. >=20 > I think Brian is closer in explaining it. >=20 > In fairness because WS-Trust originally only had On-Behalf-Of the naming a= nd what people put in tokens is a bit muddled in many implementations. > I think many times it is how WIF implemented it that people copied. >=20 > It may be better to have new terms that are clear such as impersonation an= d composite. >=20 > The WG needs to decide if this is going to be an entirely new endpoint, fr= ee of the Token endpoint semantics. There are plusses and minuses to both o= ptions. >=20 > Also while it is nice to be pure and talk about abstract security tokens, i= t would be good to give some guidance on what a composite security token wou= ld look like for interoperability. >=20 > There are also issues around how this would work with proof of possession s= ecurity tokens, both as input and output. >=20 > Perhaps we can make some progress on this in Prague. >=20 > John B. >=20 >=20 >=20 >=20 > > On Jul 6, 2015, at 11:04 AM, Brian Campbell = wrote: > > > > Thanks Sergey, > > > > The goal of draft-campbell-oauth-sts was to be consistent with OAuth 2.0= and thus hopefully familiar to developers and easy to understand and implem= ent (especially from the client side). It's also intended to be flexible in o= rder to accommodate a variety of use-cases including the chaining type cases= that Justin's draft covers. > > > > Specifying a security_token_type of the returned token is just a way of p= roviding more info to the client about the token (i.e. is this a JWT or a SA= ML token or something else) via a URI. It's not always needed but in STS sty= le cases the tokens are not always opaque to the client and the parameter ju= st provides info about the returned token. > > > > On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin w= rote: > > Hi Brian > > > > I've read the text, I like it is still pure OAuth2, with few extra param= eters added to the access token request, and a key response property being '= access_token' as opposed to 'security_access_token' as in the draft-ietf-oau= th-token-exchange-01. > > It appears draft-campbell-oauth-sts-01 can cover a draft-richer-oauth-ch= ain-00 case with the on_behalf_of (and/or act_as ?) property being an origin= al client token but not 100% sure given draft-richer-oauth-chain-00 covers a= specific case. > > > > One thing I'm not sure about is what is the purpose of specifying a > > security_token_type of the returned access token > > > > Thanks, Sergey > > > > On 01/07/15 15:59, Brian Campbell wrote: > > One problem, I think, with token exchange is that it can be really > > simple (token in and token out) and really complicated (client X wants > > a token that says user A is doing something on behalf of user B) at > > the same time. > > > > I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in > > an attempt to simplify things and express what I envisioned as an > > OAuth based token exchange framework. Though it likely only muddied > > the waters :) > > > > On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin > > wrote: > > > > Hi Justin > > > > https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much > > easier to read, that I can tell for sure, at least it is obvious why= > > a given entity (RS1) may want to exchange the current token provided= > > by a client for a new token. Definitely easily implementable... > > > > One thing I'm not sure in the draft-richer-oauth-chain-00 about is > > on behalf of whose entity RS1 will be acting once it starts > > accessing RS2, On Behalf Of RO, or may be On Behalf Of (RO + > > Client), or may be it is On Behalf Of RO + Act As Client ? The last > > one seems most logical to me... > > > > Thanks, Sergey > > > > > > On 01/07/15 13:18, Justin Richer wrote: > > > > As it's written right now, it's a translation of some WS-* > > concepts into > > JWT format. It's not really OAuth-y (since the client has to > > understand > > the token format along with everyone else, and according to the > > authors > > the artifacts might not even be "OAuth tokens"), and that's my m= ain > > issue with the document. Years ago, I proposed an OAuth-based > > token swap > > mechanism: > > > > https://tools.ietf.org/html/draft-richer-oauth-chain-00 > > > > This works without defining semantics of the tokens themselves, j= ust > > like the rest of OAuth. I've proposed to the authors of the curr= ent > > draft that it should incorporate both semantic (using JWT) and > > syntactic > > (using a simple token-agnostic grant) token swap mechanisms, and= > > that > > the two could be easily compatible. > > > > -- Justin > > > > On 7/1/2015 6:35 AM, Sergey Beryozkin wrote: > > > > Hmm... perhaps the clue is in the draft title, > > token-exchange, so may > > be it is a case of the given access token ("on_behalf_of" or= > > "act_as" > > claim) being used to request a new security token. One can > > only guess > > though, does not seem like the authors are keen to answer > > the newbie > > questions... > > > > Cheers, Sergey > > > > > > On 30/06/15 13:38, Sergey Beryozkin wrote: > > > > Hi, > > Can you please explain what is the difference between > > On-Behalf-Of > > semantics described in the > > draft-ietf-oauth-token-exchange-01 and the > > implicit On-Behalf-Of semantics a client OAuth2 token > > possesses ? > > > > For example, draft-ietf-oauth-token-exchange-01 mentions= : > > > > "Whereas, with on-behalf-of semantics, principal A still= > > has its own > > identity separate from B and it is explicitly understood= > > that while B > > may have delegated its rights to A, any actions taken > > are being taken by > > A and not B. In a sense, A is an agent for B." > > > > This is a typical case with the authorization code flow > > where a client > > application acts on-behalf-of the user who authorized > > this application ? > > > > Sorry if I'm missing something > > > > Cheers, Sergey > > On 25/06/15 22:28, Mike Jones wrote: > > > > That=E2=80=99s what > > https://tools.ietf.org/html/draft-ietf-oauth-token-e= xchange-01 > > is > > about. > > > > Cheers, > > > > -- Mike > > > > *From:*OAuth [mailto:oauth-bounces@ietf.org > > ] *On Behalf Of *Vive= k > > Biswas > > -T (vibiswas - XORIANT CORPORATION at Cisco) > > *Sent:* Thursday, June 25, 2015 2:20 PM > > *To:* OAuth@ietf.org > > *Subject:* [OAUTH-WG] JWT Token on-behalf of Use > > case > > > > Hi All, > > > > I am looking to solve a use-case similar to > > WS-Security On-Behalf-Of > > > > > .4-errata01-os-complete.html#_Toc325658980> > > > > > > with OAuth JWT Token. > > > > Is there a standard claim which we can define > > within the OAuth JWT > > which denote the On-behalf-of User. > > > > For e.g., a Customer Representative trying to create= > > token on behalf of > > a customer and trying to execute services specific > > for that specific > > customer. > > > > Regards, > > > > Vivek Biswas, > > CISSP > > > > *Cisco Systems, Inc * > > > > *Bldg. J, San Jose, USA,* > > > > *Phone: +1 408 527 9176 > > * > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@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 >=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-3B9B9226-D361-4B2A-A0C8-549A25EA1930 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I think the original reasoning was sou= nd, but the fact that so many remain confused is good reason to go to new vo= cab.

We could still have clarifying text that imper= sonate/composite is xxx and yyy in kerberos etc. 

Phil

On Jul 6, 2015, at 13:43, Anthony Nadalin <tonynad@microsoft.com> wrote:

The WS-Trust =E2=80=9CActAs=E2=80=9D mi= mics the Windows Kerberos Protocol Transition (impersonation)  feature a= s this enables an account to impersonate another account for the purpose of providing access to resources. In a typical scenario, the impers= onating account would be a service account assigned to a web application or t= he computer account of a web server. The impersonated account would be a use= r account requiring access to resources (e.g. data in an SQL database) via a web application. In this sce= nario, SQL server would be accessed by the impersonating (service account) a= ccount, however access would be under the context of the impersonated (user)= account.

 

WS-Trust =E2=80=9COnBehalfOf=E2=80=9D &= nbsp;mimics the Windows Kerberos Constrained Delegation feature, which lets y= ou limit the back-end services for which a front-end service can request tickets on behalf of another user. =E2=80=9COnBehalfOf=E2=80=9D &nb= sp;allows a selected services on a server can be granted for access by the i= mpersonating account, whilst other services on the same server, or services o= n other servers are denied for access.

 

Maybe someone can summarize why they th= ink the text for ActAs and OnBehalfOf in WS-Trust or Windows Kerberos is wro= ng or swapped as I have not seen a clear explanation other than John saying that Brian knows and Brian saying John knows.

 

Our usage and use cases are based upon t= he deployed services of WS-Trust and Kerberos support in Windows (workstatio= n and server) and Xbox.

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Monday, July 6, 2015 11:29 AM
To: Mike Jones <Mic= hael.Jones@microsoft.com>
Cc: oauth <oauth@ietf.org>= ;
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case

 

Stating specific actio= n items resulting from the ad-hoc meeting in Dallas like that suggests some c= lear consensus was reached, which is not at all the case. As I recall, sever= al of us argued past one another for an hour or so and decided to adjourn in order to go to the bar (okay, a= nd dinner too - but mostly beer).

The impression about r= eversal of terms, I think, comes from the text in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 which hurts my head a little every-time I read it but does seems to confu= se things. The MSDN link John gave is much more to the point than WS-Trust (I don't bel= ieve WS-Trust can be pointed to as a model of clarity).  In the draft I= wrote, I tried to take Mike's text and clarify a distinction between impers= onation and delegation with https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 and t= hen also be very explicit about act-as vs. on-behalf-of in the parameter def= initions at https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in a m= anor that was consistent with WS-Trust and the MSDN explanation. I could see= value in breaking with that shaky legacy and using new terms too. But I get= the point of trying to keep with the old also and potential for even more confusing by using new terms.=

I wrote draft-campbell= -oauth-sts last year in response to the call for adoption of jones-oauth-tok= en-exchange (thread from the archive). Though I didn't try and stand in the way and indicat= ed a willingness to collaborate on things. With the expectation, of course, t= hat the details would differ from the -00s and -01s as work progressed. Folk= s seemed generally amenable to that at the time but little has happened since the= n.

Phil's earlier point about the priory of this getting= pushed down has some truth to it. But I still believe it's something that c= an provide a lot of value in standardizing, if we do so in a reasonable way.=

 



 

 

On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones <Michael.Jones@mi= crosoft.com> wrote:

It would surprise me if on-behalf-of and act-as were r= eversed with respect WS-Trust, because the explanations of the terms came di= rectly from WS-Trust 1.4.  I also think the chances of us reducing conf= usion by inventing new terminology, rather than adding to it, would not be in our favor. :-/

FYI, the action items outstanding from our ad-hoc meeting on this draft in D= allas are:
  - Allowing security types other than JWT to also be used as the act_a= s and on_behalf_of request values.
  - Further integrating the mechanism into the existing OAuth ecosystem= - allowing use of access tokens or refresh tokens when appropriate.

I plan to do the first today.  The second is probably more than I'll ge= t done today before the submission cutoff.  I agree with John that it w= ould be useful to have discussions on this in Prague on the best way to achi= eve this further integration.  I'll plan to come into the Prague meeting with a concrete proposal for review.

                     =           Best wishes,
                     =           -- Mike


-----Original Message-----
From: OAuth [mailto:oauth-bounces@= ietf.org] On Behalf Of John Bradley
Sent: Monday, July 06, 2015 8:13 AM
To: Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case

Yes unfortunately we haven=E2=80=99t made any progress on this since accepti= ng Mike=E2=80=99s first draft.

His proposal is basically for a new endpoint while Brian tired to fit it int= o the existing token endpoint.

I think draft-ietf-oauth-token-exchange-01 still has OnBehalfOf and ActAs re= versed compared to WS-Trust 1.4.
see https://msdn.microsoft.com/en-us/library/ee748487.aspx for the short exp= lanation.

I think Brian is closer in explaining it.

In fairness because WS-Trust originally only had On-Behalf-Of the naming and= what people put in tokens is a bit muddled in many implementations.
I think many times it is how WIF implemented it that people copied.

It may be better to have new terms that are clear such as impersonation and c= omposite.

The WG needs to decide if this is going to be an entirely new endpoint, free= of the Token endpoint semantics.   There are plusses and minuses t= o both options.

Also while it is nice to be pure and talk about abstract security tokens, it= would be good to give some guidance on what a composite security token woul= d look like for interoperability.

There are also issues around how this would work with proof of possession se= curity tokens, both as input and output.

Perhaps we can make some progress on this in Prague.

John B.




> On Jul 6, 2015, at 11:04 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
>
> Thanks Sergey,
>
> The goal of draft-campbell-oauth-sts was to be consistent with OAuth 2.= 0 and thus hopefully familiar to developers and easy to understand and imple= ment (especially from the client side). It's also intended to be flexible in= order to accommodate a variety of use-cases including the chaining type cases that Justin's draft covers.<= br> >
> Specifying a security_token_type of the returned token is just a way of= providing more info to the client about the token (i.e. is this a JWT or a S= AML token or something else) via a URI. It's not always needed but in STS st= yle cases the tokens are not always opaque to the client and the parameter just provides info about the returne= d token.
>
> On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin <sberyozkin@gmail.com> wrote:
> Hi Brian
>
> I've read the text, I like it is still pure OAuth2, with few extra para= meters added to the access token request, and a key response property being '= access_token' as opposed to 'security_access_token' as in the draft-ietf-oau= th-token-exchange-01.
> It appears draft-campbell-oauth-sts-01 can cover a draft-richer-oauth-c= hain-00 case with the on_behalf_of (and/or act_as ?) property being an origi= nal client token but not 100% sure given draft-richer-oauth-chain-00 covers a= specific case.
>
> One thing I'm not sure about is what is the purpose of specifying a
= > security_token_type of the returned access token
>
> Thanks, Sergey
>
> On 01/07/15 15:59, Brian Campbell wrote:
> One problem, I think, with token exchange is that it can be really
> simple (token in and token out) and really complicated (client X wants<= br> > a token that says user A is doing something on behalf of user B) at
= > the same time.
>
> I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in
> an attempt to simplify things and express what I envisioned as an
> OAuth based token exchange framework. Though it likely only muddied
= > the waters :)
>
> On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin <sberyozkin@gmail.com
> <mailto:sberyozkin@gmail.com= >> wrote:
>
>     Hi Justin
>
>     https://tools.ietf.org/html/draft-richer-o= auth-chain-00 is much
>     easier to read, that I can tell for sure, at least i= t is obvious why
>     a given entity (RS1) may want to exchange the curren= t token provided
>     by a client for a new token. Definitely easily imple= mentable...
>
>     One thing I'm not sure in the draft-richer-oauth-cha= in-00 about is
>     on behalf of whose entity RS1 will be acting once it= starts
>     accessing RS2, On Behalf Of RO, or may be On Behalf O= f (RO +
>     Client), or may be it is On Behalf Of RO + Act As Cl= ient ? The last
>     one seems most logical to me...
>
>     Thanks, Sergey
>
>
>     On 01/07/15 13:18, Justin Richer wrote:
>
>         As it's written right now, it's a tran= slation of some WS-*
>         concepts into
>         JWT format. It's not really OAuth-y (s= ince the client has to
>         understand
>         the token format along with everyone e= lse, and according to the
>         authors
>         the artifacts might not even be "OAuth= tokens"), and that's my main
>         issue with the document. Years ago, I p= roposed an OAuth-based
>         token swap
>         mechanism:
>
>         https://tools.ietf.org/html/= draft-richer-oauth-chain-00
>
>         This works without defining semantics o= f the tokens themselves, just
>         like the rest of OAuth. I've proposed t= o the authors of the current
>         draft that it should incorporate both s= emantic (using JWT) and
>         syntactic
>         (using a simple token-agnostic grant) t= oken swap mechanisms, and
>         that
>         the two could be easily compatible. >
>            -- Justin
>
>         On 7/1/2015 6:35 AM, Sergey Beryozkin w= rote:
>
>             Hmm... perhaps the clue i= s in the draft title,
>             token-exchange, so may >             be it is a case of the g= iven access token ("on_behalf_of" or
>             "act_as"
>             claim) being used to req= uest a new security token. One can
>             only guess
>             though, does not seem li= ke the authors are keen to answer
>             the newbie
>             questions...
>
>             Cheers, Sergey
>
>
>             On 30/06/15 13:38, Serge= y Beryozkin wrote:
>
>                 Hi,
>                 Can you pl= ease explain what is the difference between
>                 On-Behalf-= Of
>                 semantics d= escribed in the
>                 draft-ietf= -oauth-token-exchange-01 and the
>                 implicit O= n-Behalf-Of semantics a client OAuth2 token
>                 possesses ?=
>
>                 For exampl= e, draft-ietf-oauth-token-exchange-01 mentions:
>
>                 "Whereas, w= ith on-behalf-of semantics, principal A still
>                 has its ow= n
>                 identity s= eparate from B and it is explicitly understood
>                 that while= B
>                 may have d= elegated its rights to A, any actions taken
>                 are being t= aken by
>                 A and not B= . In a sense, A is an agent for B."
>
>                 This is a t= ypical case with the authorization code flow
>                 where a cl= ient
>                 applicatio= n acts on-behalf-of the user who authorized
>                 this appli= cation ?
>
>                 Sorry if I= 'm missing something
>
>                 Cheers, Se= rgey
>                 On 25/06/1= 5 22:28, Mike Jones wrote:
>
>                    &n= bsp;That=E2=80=99s what
>                    &n= bsp;https://tools.ietf.org/html/draft-ietf-oauth-token-exch= ange-01
>                    &n= bsp;is
>                    &n= bsp;about.
>
>                    &n= bsp;Cheers,
>
>                    &n= bsp;-- Mike
>
>                    &n= bsp;*From:*OAuth [mailto:oauth-bou= nces@ietf.org
>                    &n= bsp;<mailto:oauth-bounces@ietf.= org>] *On Behalf Of *Vivek
>                    &n= bsp;Biswas
>                    &n= bsp;-T (vibiswas - XORIANT CORPORATION at Cisco)
>                    &n= bsp;*Sent:* Thursday, June 25, 2015 2:20 PM
>                    &n= bsp;*To:* OAuth@ietf.org <mailto:OAuth@ietf.org>
>                    &n= bsp;*Subject:* [OAUTH-WG] JWT Token on-behalf of Use
> case
>
>                    &n= bsp;Hi All,
>
>                    &n= bsp;    I am looking to solve a use-case similar to
>                    &n= bsp;WS-Security On-Behalf-Of
>
> <http://docs.oasis-open.org/ws-sx/ws-trust/v= 1.4/errata01/os/ws-trust-1
> .4-errata01-os-complete.html#_Toc325658980>
>
>
>                    &n= bsp;with OAuth JWT Token.
>
>                    &n= bsp;    Is there a standard claim which we can define
>                    &n= bsp;within the OAuth JWT
>                    &n= bsp;which denote the On-behalf-of User.
>
>                    &n= bsp;For e.g., a Customer Representative trying to create
>                    &n= bsp;token on behalf of
>                    &n= bsp;a customer and trying to execute services specific
>                    &n= bsp;for that specific
>                    &n= bsp;customer.
>
>                    &n= bsp;Regards,
>
>                    &n= bsp;Vivek Biswas,
>                    &n= bsp;CISSP
>
>                    &n= bsp;*Cisco Systems, Inc <http://www.cisco.com/>*
>
>                    &n= bsp;*Bldg. J, San Jose, USA,*
>
>                    &n= bsp;*Phone: +1 408 527 9176
> <tel:%2B1%20408%20527%209176= >*
>
>
>
>                    &n= bsp;_______________________________________________
>                    &n= bsp;OAuth mailing list
>                    &n= bsp;OAuth@ietf.org <mailto:OAuth@ietf.org>
>                    &n= bsp;https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>             ________________________= _______________________
>             OAuth mailing list
>             OAuth@ietf.org <mailto:OA= uth@ietf.org>
>             https://www.ietf.org/mailm= an/listinfo/oauth
>
>
>         ______________________________________= _________
>         OAuth mailing list
>         OAut= h@ietf.org <mailto:OAuth@ietf.org>
>         https://www.ietf.org/mailman/listinfo/oa= uth
>
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org= <mailto:OAuth@ietf.org>
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

 

____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-3B9B9226-D361-4B2A-A0C8-549A25EA1930-- From nobody Mon Jul 6 14:26:16 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0531A003B; Mon, 6 Jul 2015 14:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyISdyKiZEh6; Mon, 6 Jul 2015 14:26:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 928ED1A020B; Mon, 6 Jul 2015 14:26:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706212612.26406.27920.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 14:26:12 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-proof-of-possession-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 21:26:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) Authors : Michael B. Jones John Bradley Hannes Tschofenig Filename : draft-ietf-oauth-proof-of-possession-03.txt Pages : 13 Date : 2015-07-06 Abstract: This specification defines how to express a declaration in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular key and that the recipient can cryptographically confirm proof-of- possession of the key by the presenter. This property is also sometimes described as the presenter being a holder-of-key. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-proof-of-possession-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 6 14:33:27 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0B21A01C6 for ; Mon, 6 Jul 2015 14:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewViWdg7dkb8 for ; Mon, 6 Jul 2015 14:33:20 -0700 (PDT) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 515041A1A4B for ; Mon, 6 Jul 2015 14:33:18 -0700 (PDT) Received: by igrv9 with SMTP id v9so163479548igr.1 for ; Mon, 06 Jul 2015 14:33:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=npRhJlXvRp53EcIfMeG8UlouyII0g1vzaAWekBAIwxQ=; b=iiE5d1C9QKpoKhInmwWYiWP/NNjiCG2sD8Fzdol9g0vUl8/Hj8ykgPXaXak/kkgcJa mKCZ6e751mC0lgHNRYrZDC7B+9ygU7oXq0cxMEE6qKQgoM2l+3jZZsQxTO8uw8kfWfst F3yb9QyUFShr5e66BlkOQswoFpWVqQeEjTQVmqO5uEsxZ5f9vAhxweK9ERFbGmcZbzXd 3r2pF2OOqWWynXBexJlYcgbjVecCcfX15QvzmQawdWWdhC7gGpkf26/wBmJNOdsUls5y lzlMW8FNGBpxrAlEqHUioWhizr9iwWHfcExdROYgGJQYz9p8Hwm4m+3O60ZnOvEHmOkO j9zw== X-Gm-Message-State: ALoCoQnuxVBZqbwKb1ikKkZFMiudf7J2Kl5tGt91GvgQWmbf3hfqajLkcjCqYYTyQh4pBUmy/TQ4 X-Received: by 10.107.128.72 with SMTP id b69mr1362908iod.84.1436218397626; Mon, 06 Jul 2015 14:33:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.64.209 with HTTP; Mon, 6 Jul 2015 14:32:48 -0700 (PDT) In-Reply-To: References: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> <55928DB3.7090300@gmail.com> <5593C270.7000008@gmail.com> <5593DA7D.80401@mit.edu> <5593E5FD.3050403@gmail.com> <559A676F.3070008@gmail.com> From: Brian Campbell Date: Mon, 6 Jul 2015 15:32:48 -0600 Message-ID: To: Anthony Nadalin Content-Type: multipart/alternative; boundary=001a113f96d06931c6051a3ba7c6 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 21:33:26 -0000 --001a113f96d06931c6051a3ba7c6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable A natural usage of act-as or impersonation would suggest, to many people anyway, that the way you just used the terms is reversed. The bold text below from https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 uses 'impersonates' and "on-behalf-of" contrary to what you just wrote about Windows Kerb. That's where the assertion that the draft has them reversed from de facto usage in WS-Trust. Those semantics are not only one open issue that needs to be resolved, however, even if they occupy most of the discussion. 1.3. On-Behalf-Of vs. Impersonation Semantics When principal A acts on behalf of principal B, A is given all the rights that B has within some defined rights context. Whereas, *with* * on-behalf-of semantics, principal A still has its own identity* * separate from B and it is explicitly understood that while B may have* * delegated its rights to A, any actions taken are being taken by A and* * not B. In a sense, A is an agent for B.* On-behalf-of semantics are therefore different than impersonation semantics, with which it is sometimes confused. *When principal A* * impersonates principal B, then in so far as any entity receiving* * Claims is concerned, they are actually dealing with B. *It is true that some members of the identity system might have awareness that impersonation is going on but it is not a requirement. For all intents and purposes, when A is acting for B, A is B. On Mon, Jul 6, 2015 at 2:43 PM, Anthony Nadalin wrote: > The WS-Trust =E2=80=9CActAs=E2=80=9D mimics the Windows Kerberos Protoco= l Transition > (impersonation) feature as this enables an account to impersonate anothe= r > account for the purpose of providing access to resources. In a typical > scenario, the impersonating account would be a service account assigned t= o > a web application or the computer account of a web server. The impersonat= ed > account would be a user account requiring access to resources (e.g. data = in > an SQL database) via a web application. In this scenario, SQL server woul= d > be accessed by the impersonating (service account) account, however acces= s > would be under the context of the impersonated (user) account. > > > > WS-Trust =E2=80=9COnBehalfOf=E2=80=9D mimics the Windows Kerberos Constr= ained Delegation > feature, which lets you limit the back-end services for which a front-end > service can request tickets on behalf of another user. =E2=80=9COnBehalfO= f=E2=80=9D allows > a selected services on a server can be granted for access by the > impersonating account, whilst other services on the same server, or > services on other servers are denied for access. > > > > Maybe someone can summarize why they think the text for ActAs and > OnBehalfOf in WS-Trust or Windows Kerberos is wrong or swapped as I have > not seen a clear explanation other than John saying that Brian knows and > Brian saying John knows. > > > > Our usage and use cases are based upon the deployed services of WS-Trust > and Kerberos support in Windows (workstation and server) and Xbox. > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian > Campbell > *Sent:* Monday, July 6, 2015 11:29 AM > *To:* Mike Jones > *Cc:* oauth > > *Subject:* Re: [OAUTH-WG] JWT Token on-behalf of Use case > > > > Stating specific action items resulting from the ad-hoc meeting in Dallas > like that suggests some clear consensus was reached, which is not at all > the case. As I recall, several of us argued past one another for an hour = or > so and decided to adjourn in order to go to the bar (okay, and dinner too= - > but mostly beer). > > The impression about reversal of terms, I think, comes from the text in > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.= 3 > which hurts my head a little every-time I read it but does seems to confu= se > things. The MSDN link > John gave is > much more to the point than WS-Trust (I don't believe WS-Trust can be > pointed to as a model of clarity). In the draft I wrote, I tried to take > Mike's text and clarify a distinction between impersonation and delegatio= n > with https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 > and then also be very explicit about act-as vs. on-behalf-of in the > parameter definitions at > https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in a > manor that was consistent with WS-Trust and the MSDN explanation. I could > see value in breaking with that shaky legacy and using new terms too. But= I > get the point of trying to keep with the old also and potential for even > more confusing by using new terms. > > I wrote draft-campbell-oauth-sts last year in response to the call for > adoption of jones-oauth-token-exchange (thread from the archive > ). > Though I didn't try and stand in the way and indicated a willingness to > collaborate on things. With the expectation, of course, that the details > would differ from the -00s and -01s as work progressed. Folks seemed gene= rally > amenable to that > at > the time but little has happened since then. > > Phil's earlier point about the priory of this getting pushed down has som= e > truth to it. But I still believe it's something that can provide a lot of > value in standardizing, if we do so in a reasonable way. > > > > > > > > > > On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones > wrote: > > It would surprise me if on-behalf-of and act-as were reversed with respec= t > WS-Trust, because the explanations of the terms came directly from WS-Tru= st > 1.4. I also think the chances of us reducing confusion by inventing new > terminology, rather than adding to it, would not be in our favor. :-/ > > FYI, the action items outstanding from our ad-hoc meeting on this draft i= n > Dallas are: > - Allowing security types other than JWT to also be used as the act_as > and on_behalf_of request values. > - Further integrating the mechanism into the existing OAuth ecosystem - > allowing use of access tokens or refresh tokens when appropriate. > > I plan to do the first today. The second is probably more than I'll get > done today before the submission cutoff. I agree with John that it would > be useful to have discussions on this in Prague on the best way to achiev= e > this further integration. I'll plan to come into the Prague meeting with= a > concrete proposal for review. > > Best wishes, > -- Mike > > > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley > Sent: Monday, July 06, 2015 8:13 AM > To: Brian Campbell > Cc: oauth > Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case > > Yes unfortunately we haven=E2=80=99t made any progress on this since acce= pting > Mike=E2=80=99s first draft. > > His proposal is basically for a new endpoint while Brian tired to fit it > into the existing token endpoint. > > I think draft-ietf-oauth-token-exchange-01 still has OnBehalfOf and ActAs > reversed compared to WS-Trust 1.4. > see https://msdn.microsoft.com/en-us/library/ee748487.aspx for the short > explanation. > > I think Brian is closer in explaining it. > > In fairness because WS-Trust originally only had On-Behalf-Of the naming > and what people put in tokens is a bit muddled in many implementations. > I think many times it is how WIF implemented it that people copied. > > It may be better to have new terms that are clear such as impersonation > and composite. > > The WG needs to decide if this is going to be an entirely new endpoint, > free of the Token endpoint semantics. There are plusses and minuses to > both options. > > Also while it is nice to be pure and talk about abstract security tokens, > it would be good to give some guidance on what a composite security token > would look like for interoperability. > > There are also issues around how this would work with proof of possession > security tokens, both as input and output. > > Perhaps we can make some progress on this in Prague. > > John B. > > > > > > On Jul 6, 2015, at 11:04 AM, Brian Campbell > wrote: > > > > Thanks Sergey, > > > > The goal of draft-campbell-oauth-sts was to be consistent with OAuth 2.= 0 > and thus hopefully familiar to developers and easy to understand and > implement (especially from the client side). It's also intended to be > flexible in order to accommodate a variety of use-cases including the > chaining type cases that Justin's draft covers. > > > > Specifying a security_token_type of the returned token is just a way of > providing more info to the client about the token (i.e. is this a JWT or = a > SAML token or something else) via a URI. It's not always needed but in ST= S > style cases the tokens are not always opaque to the client and the > parameter just provides info about the returned token. > > > > On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin > wrote: > > Hi Brian > > > > I've read the text, I like it is still pure OAuth2, with few extra > parameters added to the access token request, and a key response property > being 'access_token' as opposed to 'security_access_token' as in the > draft-ietf-oauth-token-exchange-01. > > It appears draft-campbell-oauth-sts-01 can cover a > draft-richer-oauth-chain-00 case with the on_behalf_of (and/or act_as ?) > property being an original client token but not 100% sure given > draft-richer-oauth-chain-00 covers a specific case. > > > > One thing I'm not sure about is what is the purpose of specifying a > > security_token_type of the returned access token > > > > Thanks, Sergey > > > > On 01/07/15 15:59, Brian Campbell wrote: > > One problem, I think, with token exchange is that it can be really > > simple (token in and token out) and really complicated (client X wants > > a token that says user A is doing something on behalf of user B) at > > the same time. > > > > I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in > > an attempt to simplify things and express what I envisioned as an > > OAuth based token exchange framework. Though it likely only muddied > > the waters :) > > > > On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin > > wrote: > > > > Hi Justin > > > > https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much > > easier to read, that I can tell for sure, at least it is obvious wh= y > > a given entity (RS1) may want to exchange the current token provide= d > > by a client for a new token. Definitely easily implementable... > > > > One thing I'm not sure in the draft-richer-oauth-chain-00 about is > > on behalf of whose entity RS1 will be acting once it starts > > accessing RS2, On Behalf Of RO, or may be On Behalf Of (RO + > > Client), or may be it is On Behalf Of RO + Act As Client ? The last > > one seems most logical to me... > > > > Thanks, Sergey > > > > > > On 01/07/15 13:18, Justin Richer wrote: > > > > As it's written right now, it's a translation of some WS-* > > concepts into > > JWT format. It's not really OAuth-y (since the client has to > > understand > > the token format along with everyone else, and according to the > > authors > > the artifacts might not even be "OAuth tokens"), and that's my > main > > issue with the document. Years ago, I proposed an OAuth-based > > token swap > > mechanism: > > > > https://tools.ietf.org/html/draft-richer-oauth-chain-00 > > > > This works without defining semantics of the tokens themselves, > just > > like the rest of OAuth. I've proposed to the authors of the > current > > draft that it should incorporate both semantic (using JWT) and > > syntactic > > (using a simple token-agnostic grant) token swap mechanisms, an= d > > that > > the two could be easily compatible. > > > > -- Justin > > > > On 7/1/2015 6:35 AM, Sergey Beryozkin wrote: > > > > Hmm... perhaps the clue is in the draft title, > > token-exchange, so may > > be it is a case of the given access token ("on_behalf_of" o= r > > "act_as" > > claim) being used to request a new security token. One can > > only guess > > though, does not seem like the authors are keen to answer > > the newbie > > questions... > > > > Cheers, Sergey > > > > > > On 30/06/15 13:38, Sergey Beryozkin wrote: > > > > Hi, > > Can you please explain what is the difference between > > On-Behalf-Of > > semantics described in the > > draft-ietf-oauth-token-exchange-01 and the > > implicit On-Behalf-Of semantics a client OAuth2 token > > possesses ? > > > > For example, draft-ietf-oauth-token-exchange-01 mention= s: > > > > "Whereas, with on-behalf-of semantics, principal A stil= l > > has its own > > identity separate from B and it is explicitly understoo= d > > that while B > > may have delegated its rights to A, any actions taken > > are being taken by > > A and not B. In a sense, A is an agent for B." > > > > This is a typical case with the authorization code flow > > where a client > > application acts on-behalf-of the user who authorized > > this application ? > > > > Sorry if I'm missing something > > > > Cheers, Sergey > > On 25/06/15 22:28, Mike Jones wrote: > > > > That=E2=80=99s what > > > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 > > is > > about. > > > > Cheers, > > > > -- Mike > > > > *From:*OAuth [mailto:oauth-bounces@ietf.org > > ] *On Behalf Of > *Vivek > > Biswas > > -T (vibiswas - XORIANT CORPORATION at Cisco) > > *Sent:* Thursday, June 25, 2015 2:20 PM > > *To:* OAuth@ietf.org > > *Subject:* [OAUTH-WG] JWT Token on-behalf of Use > > case > > > > Hi All, > > > > I am looking to solve a use-case similar to > > WS-Security On-Behalf-Of > > > > > .4-errata01-os-complete.html#_Toc325658980> > > > > > > with OAuth JWT Token. > > > > Is there a standard claim which we can define > > within the OAuth JWT > > which denote the On-behalf-of User. > > > > For e.g., a Customer Representative trying to creat= e > > token on behalf of > > a customer and trying to execute services specific > > for that specific > > customer. > > > > Regards, > > > > Vivek Biswas, > > CISSP > > > > *Cisco Systems, Inc * > > > > *Bldg. J, San Jose, USA,* > > > > *Phone: +1 408 527 9176 > > >* > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@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 > > > --001a113f96d06931c6051a3ba7c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable





On Mon, Jul 6, = 2015 at 2:43 PM, Anthony Nadalin <tonynad@microsoft.com>= wrote:

The WS-Trust =E2=80=9CActAs=E2=80=9D = mimics the Windows Kerberos Protocol Transition (impersonation) =C2=A0featu= re as this enables an account to impersonate another account for the purpose of providing access to resources. In a typical scenario, the imper= sonating account would be a service account assigned to a web application o= r the computer account of a web server. The impersonated account would be a= user account requiring access to resources (e.g. data in an SQL database) via a web application. In this sc= enario, SQL server would be accessed by the impersonating (service account)= account, however access would be under the context of the impersonated (us= er) account.

=C2=A0

WS-Trust =E2=80=9COnBehalfOf=E2=80=9D= =C2=A0mimics the Windows Kerberos Constrained Delegation feature, which le= ts you limit the back-end services for which a front-end service can request tickets on behalf of another user. =E2=80=9COnBehalfOf=E2=80=9D = =C2=A0allows a selected services on a server can be granted for access by t= he impersonating account, whilst other services on the same server, or serv= ices on other servers are denied for access.

=C2=A0

Maybe someone can summarize why they = think the text for ActAs and OnBehalfOf in WS-Trust or Windows Kerberos is = wrong or swapped as I have not seen a clear explanation other than John saying that Brian knows and Brian saying John knows.

=C2=A0

Our usage and use cases are based upo= n the deployed services of WS-Trust and Kerberos support in Windows (workst= ation and server) and Xbox.

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Monday, July 6, 2015 11:29 AM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: oauth <oa= uth@ietf.org>


Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case

=C2=A0

Stating specific acti= on items resulting from the ad-hoc meeting in Dallas like that suggests som= e clear consensus was reached, which is not at all the case. As I recall, s= everal of us argued past one another for an hour or so and decided to adjourn in order to go to the bar (okay, = and dinner too - but mostly beer).

The impression about = reversal of terms, I think, comes from the text in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3<= /a> which hurts my head a little every-time I read it but does seems to con= fuse things. The MSDN link John gave is much more to the point than WS-Trust (I don'= t believe WS-Trust can be pointed to as a model of clarity).=C2=A0 In the d= raft I wrote, I tried to take Mike's text and clarify a distinction bet= ween impersonation and delegation with https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 and= then also be very explicit about act-as vs. on-behalf-of in the parameter = definitions at https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in a = manor that was consistent with WS-Trust and the MSDN explanation. I could s= ee value in breaking with that shaky legacy and using new terms too. But I = get the point of trying to keep with the old also and potential for even more confusing by using new terms= .

I wrote draft-campbel= l-oauth-sts last year in response to the call for adoption of jones-oauth-t= oken-exchange (thread from the archive). Though I didn't try and stand in the way and in= dicated a willingness to collaborate on things. With the expectation, of co= urse, that the details would differ from the -00s and -01s as work progress= ed. Folks seemed generally amenable to that at the time but little has happened since th= en.

Phil's earlier point about the priory of this ge= tting pushed down has some truth to it. But I still believe it's someth= ing that can provide a lot of value in standardizing, if we do so in a reas= onable way.

=C2=A0<= /p>



=C2=A0<= /p>

=C2=A0

On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

It would surprise me if on-behalf-of and act-as were= reversed with respect WS-Trust, because the explanations of the terms came= directly from WS-Trust 1.4.=C2=A0 I also think the chances of us reducing = confusion by inventing new terminology, rather than adding to it, would not be in our favor. :-/

FYI, the action items outstanding from our ad-hoc meeting on this draft in = Dallas are:
=C2=A0 - Allowing security types other than JWT to also be used as the act_= as and on_behalf_of request values.
=C2=A0 - Further integrating the mechanism into the existing OAuth ecosyste= m - allowing use of access tokens or refresh tokens when appropriate.

I plan to do the first today.=C2=A0 The second is probably more than I'= ll get done today before the submission cutoff.=C2=A0 I agree with John tha= t it would be useful to have discussions on this in Prague on the best way = to achieve this further integration.=C2=A0 I'll plan to come into the Prague meeting with a concrete proposal for review.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Best wishes,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =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 John Bradley
Sent: Monday, July 06, 2015 8:13 AM
To: Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case

Yes unfortunately we haven=E2=80=99t made any progress on this since accept= ing Mike=E2=80=99s first draft.

His proposal is basically for a new endpoint while Brian tired to fit it in= to the existing token endpoint.

I think draft-ietf-oauth-token-exchange-01 still has OnBehalfOf and ActAs r= eversed compared to WS-Trust 1.4.
see https://msdn.microsoft.com/en-us/library/ee748487.aspx for the short ex= planation.

I think Brian is closer in explaining it.

In fairness because WS-Trust originally only had On-Behalf-Of the naming an= d what people put in tokens is a bit muddled in many implementations.
I think many times it is how WIF implemented it that people copied.

It may be better to have new terms that are clear such as impersonation and= composite.

The WG needs to decide if this is going to be an entirely new endpoint, fre= e of the Token endpoint semantics.=C2=A0 =C2=A0There are plusses and minuse= s to both options.

Also while it is nice to be pure and talk about abstract security tokens, i= t would be good to give some guidance on what a composite security token wo= uld look like for interoperability.

There are also issues around how this would work with proof of possession s= ecurity tokens, both as input and output.

Perhaps we can make some progress on this in Prague.

John B.




> On Jul 6, 2015, at 11:04 AM, Brian Campbell <bcampbell@pingidentity.com>= ; wrote:
>
> Thanks Sergey,
>
> The goal of draft-campbell-oauth-sts was to be consistent with OAuth 2= .0 and thus hopefully familiar to developers and easy to understand and imp= lement (especially from the client side). It's also intended to be flex= ible in order to accommodate a variety of use-cases including the chaining type cases that Justin's draft cov= ers.
>
> Specifying a security_token_type of the returned token is just a way o= f providing more info to the client about the token (i.e. is this a JWT or = a SAML token or something else) via a URI. It's not always needed but i= n STS style cases the tokens are not always opaque to the client and the parameter just provides info about the return= ed token.
>
> On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin <sberyozkin@gmail.com> wrote= :
> Hi Brian
>
> I've read the text, I like it is still pure OAuth2, with few extra= parameters added to the access token request, and a key response property = being 'access_token' as opposed to 'security_access_token' = as in the draft-ietf-oauth-token-exchange-01.
> It appears draft-campbell-oauth-sts-01 can cover a draft-richer-oauth-= chain-00 case with the on_behalf_of (and/or act_as ?) property being an ori= ginal client token but not 100% sure given draft-richer-oauth-chain-00 cove= rs a specific case.
>
> One thing I'm not sure about is what is the purpose of specifying = a
> security_token_type of the returned access token
>
> Thanks, Sergey
>
> On 01/07/15 15:59, Brian Campbell wrote:
> One problem, I think, with token exchange is that it can be really
> simple (token in and token out) and really complicated (client X wants=
> a token that says user A is doing something on behalf of user B) at > the same time.
>
> I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in
> an attempt to simplify things and express what I envisioned as an
> OAuth based token exchange framework. Though it likely only muddied > the waters :)
>
> On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin <sberyozkin@gmail.com
> <mailto:s= beryozkin@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hi Justin
>
>=C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-richer= -oauth-chain-00 is much
>=C2=A0 =C2=A0 =C2=A0easier to read, that I can tell for sure, at least = it is obvious why
>=C2=A0 =C2=A0 =C2=A0a given entity (RS1) may want to exchange the curre= nt token provided
>=C2=A0 =C2=A0 =C2=A0by a client for a new token. Definitely easily impl= ementable...
>
>=C2=A0 =C2=A0 =C2=A0One thing I'm not sure in the draft-richer-oaut= h-chain-00 about is
>=C2=A0 =C2=A0 =C2=A0on behalf of whose entity RS1 will be acting once i= t starts
>=C2=A0 =C2=A0 =C2=A0accessing RS2, On Behalf Of RO, or may be On Behalf= Of (RO +
>=C2=A0 =C2=A0 =C2=A0Client), or may be it is On Behalf Of RO + Act As C= lient ? The last
>=C2=A0 =C2=A0 =C2=A0one seems most logical to me...
>
>=C2=A0 =C2=A0 =C2=A0Thanks, Sergey
>
>
>=C2=A0 =C2=A0 =C2=A0On 01/07/15 13:18, Justin Richer wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0As it's written right now, it'= ;s a translation of some WS-*
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0concepts into
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0JWT format. It's not really OAuth= -y (since the client has to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0understand
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the token format along with everyone = else, and according to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0authors
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the artifacts might not even be "= ;OAuth tokens"), and that's my main
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0issue with the document. Years ago, I= proposed an OAuth-based
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0token swap
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mechanism:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/htm= l/draft-richer-oauth-chain-00
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This works without defining semantics= of the tokens themselves, just
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0like the rest of OAuth. I've prop= osed to the authors of the current
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft that it should incorporate both= semantic (using JWT) and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0syntactic
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(using a simple token-agnostic grant)= token swap mechanisms, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the two could be easily compatible. >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Justin
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 7/1/2015 6:35 AM, Sergey Beryozkin= wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hmm... perhaps the clue= is in the draft title,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0token-exchange, so may<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be it is a case of the = given access token ("on_behalf_of" or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"act_as"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0claim) being used to re= quest a new security token. One can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0only guess
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0though, does not seem l= ike the authors are keen to answer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the newbie
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0questions...
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Cheers, Sergey
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 30/06/15 13:38, Serg= ey Beryozkin wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Can you p= lease explain what is the difference between
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On-Behalf= -Of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0semantics= described in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-iet= f-oauth-token-exchange-01 and the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implicit = On-Behalf-Of semantics a client OAuth2 token
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0possesses= ?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0For examp= le, draft-ietf-oauth-token-exchange-01 mentions:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Whe= reas, with on-behalf-of semantics, principal A still
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0has its o= wn
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0identity = separate from B and it is explicitly understood
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that whil= e B
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0may have = delegated its rights to A, any actions taken
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0are being= taken by
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A and not= B. In a sense, A is an agent for B."
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This is a= typical case with the authorization code flow
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0where a c= lient
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0applicati= on acts on-behalf-of the user who authorized
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this appl= ication ?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sorry if = I'm missing something
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Cheers, S= ergey
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 25/06/= 15 22:28, Mike Jones wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0That=E2=80=99s what
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0https://tools.ietf.org/html/draft-ietf-oauth-token-= exchange-01
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0about.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Cheers,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0-- Mike
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0*From:*OAuth [mailto:oauth-bounces@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0<mailto:oauth-bounces@ietf.org>] *On Behalf Of *Vivek
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Biswas
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0-T (vibiswas - XORIANT CORPORATION at Cisco)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0*Sent:* Thursday, June 25, 2015 2:20 PM
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0*To:* OAuth@ietf.= org <mailto:OAut= h@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0*Subject:* [OAUTH-WG] JWT Token on-behalf of Use
> case
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Hi All,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0I am looking to solve a use-case similar to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0WS-Security On-Behalf-Of
>
> <http://docs.oasis-open.org/ws-sx/ws-trust= /v1.4/errata01/os/ws-trust-1
> .4-errata01-os-complete.html#_Toc325658980>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0with OAuth JWT Token.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Is there a standard claim which we can define
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0within the OAuth JWT
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0which denote the On-behalf-of User.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0For e.g., a Customer Representative trying to create
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0token on behalf of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0a customer and trying to execute services specific
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0for that specific
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0customer.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Regards,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Vivek Biswas,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0CISSP
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0*Cisco Systems, Inc <http://www.cisco.com/>*
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0*Bldg. J, San Jose, USA,*
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0*Phone: +1 = 408 527 9176
> <tel:%2B1= %20408%20527%209176>*
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0OAuth mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0OAuth@ietf.org <mailto:OAuth@ietf= .org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_______________________= ________________________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OAuth mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OAuth@ietf.org <mailto:OAuth@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mai= lman/listinfo/oauth
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_____________________________________= __________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OAuth mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OAuth@ietf.org <mailto:OAuth@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/= oauth
>
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0OAuth mailing list
>=C2=A0 =C2=A0 =C2=A0OAuth@ietf.org <mailto:OAuth@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

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

=C2=A0


--001a113f96d06931c6051a3ba7c6-- From nobody Mon Jul 6 14:51:50 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4651A1A5F for ; Mon, 6 Jul 2015 14:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9ksaJsih3Ie for ; Mon, 6 Jul 2015 14:51:42 -0700 (PDT) Received: from mail-qk0-f169.google.com (mail-qk0-f169.google.com [209.85.220.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3858D1A1A6A for ; Mon, 6 Jul 2015 14:51:41 -0700 (PDT) Received: by qkhu186 with SMTP id u186so127476417qkh.0 for ; Mon, 06 Jul 2015 14:51:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=gZ/UlyGzC5RYaQDhBJEFkMMsPMJU+J7KjrHjoaDllWQ=; b=SRVINN+e60yKgyGuvUyJHIRCjJ8C1oxbFcpUHWuUz23NkwfXBQajsSB55DIxwvsnl8 i8Wqn80RO/UqMn9X6J5cwf1RnKOjIK0pf47N1m94WhZ1vzRV/XIb7ukfpWNKYoKm4cHZ D8i4QmlCEa/Cu5kYsSnWitJQ4tvxQB4YEogMdEBZ+qzgFMDRTbi+NiCmOQcof03U88wB 3trgWMa5gusCfb6ey7Qy1pJnGtpdO8LYcgjJGi+z/+t3znRlNtBuUcAPoGCaZq7PpHnS wgRbATdYX6hQFI+X1/0JEuECrpi/P4Jg5Fwp6SR6ia59kf9LE3NRN3Jp0ACtlIq365/r 6mrw== X-Gm-Message-State: ALoCoQlkcJrD2esaViG8IK8c3aHzznJJq43JMxqg+cmWzERfIQFtjao1NS3P61XNkL8boQnL/mPJ X-Received: by 10.55.25.12 with SMTP id k12mr1646629qkh.81.1436219500343; Mon, 06 Jul 2015 14:51:40 -0700 (PDT) Received: from [192.168.8.101] ([181.202.207.194]) by mx.google.com with ESMTPSA id x79sm9987624qha.10.2015.07.06.14.51.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Jul 2015 14:51:39 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_66D549B1-5173-4D19-ADDC-407D01DE6C77" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: John Bradley In-Reply-To: Date: Mon, 6 Jul 2015 18:51:32 -0300 Message-Id: <98C5F0C1-F5BF-4BC8-9C7E-98EEC44007AC@ve7jtb.com> References: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> <55928DB3.7090300@gmail.com> <5593C270.7000008@gmail.com> <5593DA7D.80401@mit.edu> <5593E5FD.3050403@gmail.com> <559A676F.3070008@gmail.com> To: Michael Jones X-Mailer: Apple Mail (2.2102) Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 21:51:48 -0000 --Apple-Mail=_66D549B1-5173-4D19-ADDC-407D01DE6C77 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sorry Mike, I was looking at an earlier version that had them reversed. I think = the wording can be improved but the composite vs delegation semantic is = correct now. However Tony now seems to disagree with that. I am going to walk away = slowly and let you sort out his last post:) We can discuss further in Prague. John B. > On Jul 6, 2015, at 3:48 PM, Mike Jones = wrote: >=20 > Fair enough, Brian. For clarity, my sense of the action items is that = I agreed to do those actions based on feedback at the ad-hoc meeting and = then people would review the result =E2=80=93 not that everything would = be =E2=80=9Cdone=E2=80=9D after taking those actions. I=E2=80=99ll = still plan to act on that feedback. > =20 > I=E2=80=99d be glad to sit down with you and others in Prague, Brian, = to work out how to make sure your use cases are covered and the draft is = as clear as it can be, given its somewhat esoteric subject matter. Now = that JWT and JOSE and the OAuth Assertions specs are done and several = others are nearly done, getting back to this is a priority for me. > =20 > Cheers, > -- Mike > =20 > From: Brian Campbell [mailto:bcampbell@pingidentity.com]=20 > Sent: Monday, July 06, 2015 11:29 AM > To: Mike Jones > Cc: John Bradley; oauth > Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case > =20 > Stating specific action items resulting from the ad-hoc meeting in = Dallas like that suggests some clear consensus was reached, which is not = at all the case. As I recall, several of us argued past one another for = an hour or so and decided to adjourn in order to go to the bar (okay, = and dinner too - but mostly beer). >=20 > The impression about reversal of terms, I think, comes from the text = in = https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3= = which hurts my head a little every-time I read it but does seems to = confuse things. The MSDN link = John gave is = much more to the point than WS-Trust (I don't believe WS-Trust can be = pointed to as a model of clarity). In the draft I wrote, I tried to = take Mike's text and clarify a distinction between impersonation and = delegation with = https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 = = and then also be very explicit about act-as vs. on-behalf-of in the = parameter definitions at = https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 = in a = manor that was consistent with WS-Trust and the MSDN explanation. I = could see value in breaking with that shaky legacy and using new terms = too. But I get the point of trying to keep with the old also and = potential for even more confusing by using new terms.=20 >=20 > I wrote draft-campbell-oauth-sts last year in response to the call for = adoption of jones-oauth-token-exchange (thread from the archive = ). = Though I didn't try and stand in the way and indicated a willingness to = collaborate on things. With the expectation, of course, that the details = would differ from the -00s and -01s as work progressed. Folks seemed = generally amenable to that = at = the time but little has happened since then. >=20 > Phil's earlier point about the priory of this getting pushed down has = some truth to it. But I still believe it's something that can provide a = lot of value in standardizing, if we do so in a reasonable way. > =20 >=20 >=20 >=20 >=20 > =20 >=20 > =20 > On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones = > = wrote: > It would surprise me if on-behalf-of and act-as were reversed with = respect WS-Trust, because the explanations of the terms came directly = from WS-Trust 1.4. I also think the chances of us reducing confusion by = inventing new terminology, rather than adding to it, would not be in our = favor. :-/ >=20 > FYI, the action items outstanding from our ad-hoc meeting on this = draft in Dallas are: > - Allowing security types other than JWT to also be used as the = act_as and on_behalf_of request values. > - Further integrating the mechanism into the existing OAuth = ecosystem - allowing use of access tokens or refresh tokens when = appropriate. >=20 > I plan to do the first today. The second is probably more than I'll = get done today before the submission cutoff. I agree with John that it = would be useful to have discussions on this in Prague on the best way to = achieve this further integration. I'll plan to come into the Prague = meeting with a concrete proposal for review. >=20 > Best wishes, > -- Mike >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org = ] On Behalf Of John Bradley > Sent: Monday, July 06, 2015 8:13 AM > To: Brian Campbell > Cc: oauth > Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case >=20 > Yes unfortunately we haven=E2=80=99t made any progress on this since = accepting Mike=E2=80=99s first draft. >=20 > His proposal is basically for a new endpoint while Brian tired to fit = it into the existing token endpoint. >=20 > I think draft-ietf-oauth-token-exchange-01 still has OnBehalfOf and = ActAs reversed compared to WS-Trust 1.4. > see https://msdn.microsoft.com/en-us/library/ee748487.aspx = for the short = explanation. >=20 > I think Brian is closer in explaining it. >=20 > In fairness because WS-Trust originally only had On-Behalf-Of the = naming and what people put in tokens is a bit muddled in many = implementations. > I think many times it is how WIF implemented it that people copied. >=20 > It may be better to have new terms that are clear such as = impersonation and composite. >=20 > The WG needs to decide if this is going to be an entirely new = endpoint, free of the Token endpoint semantics. There are plusses and = minuses to both options. >=20 > Also while it is nice to be pure and talk about abstract security = tokens, it would be good to give some guidance on what a composite = security token would look like for interoperability. >=20 > There are also issues around how this would work with proof of = possession security tokens, both as input and output. >=20 > Perhaps we can make some progress on this in Prague. >=20 > John B. >=20 >=20 >=20 >=20 > > On Jul 6, 2015, at 11:04 AM, Brian Campbell = > wrote: > > > > Thanks Sergey, > > > > The goal of draft-campbell-oauth-sts was to be consistent with OAuth = 2.0 and thus hopefully familiar to developers and easy to understand and = implement (especially from the client side). It's also intended to be = flexible in order to accommodate a variety of use-cases including the = chaining type cases that Justin's draft covers. > > > > Specifying a security_token_type of the returned token is just a way = of providing more info to the client about the token (i.e. is this a JWT = or a SAML token or something else) via a URI. It's not always needed but = in STS style cases the tokens are not always opaque to the client and = the parameter just provides info about the returned token. > > > > On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin = > wrote: > > Hi Brian > > > > I've read the text, I like it is still pure OAuth2, with few extra = parameters added to the access token request, and a key response = property being 'access_token' as opposed to 'security_access_token' as = in the draft-ietf-oauth-token-exchange-01. > > It appears draft-campbell-oauth-sts-01 can cover a = draft-richer-oauth-chain-00 case with the on_behalf_of (and/or act_as ?) = property being an original client token but not 100% sure given = draft-richer-oauth-chain-00 covers a specific case. > > > > One thing I'm not sure about is what is the purpose of specifying a > > security_token_type of the returned access token > > > > Thanks, Sergey > > > > On 01/07/15 15:59, Brian Campbell wrote: > > One problem, I think, with token exchange is that it can be really > > simple (token in and token out) and really complicated (client X = wants > > a token that says user A is doing something on behalf of user B) at > > the same time. > > > > I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 = in > > an attempt to simplify things and express what I envisioned as an > > OAuth based token exchange framework. Though it likely only muddied > > the waters :) > > > > On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin = > > >> wrote: > > > > Hi Justin > > > > https://tools.ietf.org/html/draft-richer-oauth-chain-00 = is much > > easier to read, that I can tell for sure, at least it is obvious = why > > a given entity (RS1) may want to exchange the current token = provided > > by a client for a new token. Definitely easily implementable... > > > > One thing I'm not sure in the draft-richer-oauth-chain-00 about = is > > on behalf of whose entity RS1 will be acting once it starts > > accessing RS2, On Behalf Of RO, or may be On Behalf Of (RO + > > Client), or may be it is On Behalf Of RO + Act As Client ? The = last > > one seems most logical to me... > > > > Thanks, Sergey > > > > > > On 01/07/15 13:18, Justin Richer wrote: > > > > As it's written right now, it's a translation of some WS-* > > concepts into > > JWT format. It's not really OAuth-y (since the client has to > > understand > > the token format along with everyone else, and according to = the > > authors > > the artifacts might not even be "OAuth tokens"), and that's = my main > > issue with the document. Years ago, I proposed an = OAuth-based > > token swap > > mechanism: > > > > https://tools.ietf.org/html/draft-richer-oauth-chain-00 = > > > > This works without defining semantics of the tokens = themselves, just > > like the rest of OAuth. I've proposed to the authors of the = current > > draft that it should incorporate both semantic (using JWT) = and > > syntactic > > (using a simple token-agnostic grant) token swap mechanisms, = and > > that > > the two could be easily compatible. > > > > -- Justin > > > > On 7/1/2015 6:35 AM, Sergey Beryozkin wrote: > > > > Hmm... perhaps the clue is in the draft title, > > token-exchange, so may > > be it is a case of the given access token = ("on_behalf_of" or > > "act_as" > > claim) being used to request a new security token. One = can > > only guess > > though, does not seem like the authors are keen to = answer > > the newbie > > questions... > > > > Cheers, Sergey > > > > > > On 30/06/15 13:38, Sergey Beryozkin wrote: > > > > Hi, > > Can you please explain what is the difference = between > > On-Behalf-Of > > semantics described in the > > draft-ietf-oauth-token-exchange-01 and the > > implicit On-Behalf-Of semantics a client OAuth2 = token > > possesses ? > > > > For example, draft-ietf-oauth-token-exchange-01 = mentions: > > > > "Whereas, with on-behalf-of semantics, principal A = still > > has its own > > identity separate from B and it is explicitly = understood > > that while B > > may have delegated its rights to A, any actions = taken > > are being taken by > > A and not B. In a sense, A is an agent for B." > > > > This is a typical case with the authorization code = flow > > where a client > > application acts on-behalf-of the user who = authorized > > this application ? > > > > Sorry if I'm missing something > > > > Cheers, Sergey > > On 25/06/15 22:28, Mike Jones wrote: > > > > That=E2=80=99s what > > = https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 = > > is > > about. > > > > Cheers, > > > > -- Mike > > > > *From:*OAuth [mailto:oauth-bounces@ietf.org = > > >] *On Behalf Of *Vivek > > Biswas > > -T (vibiswas - XORIANT CORPORATION at Cisco) > > *Sent:* Thursday, June 25, 2015 2:20 PM > > *To:* OAuth@ietf.org = > > > *Subject:* [OAUTH-WG] JWT Token on-behalf of Use > > case > > > > Hi All, > > > > I am looking to solve a use-case similar to > > WS-Security On-Behalf-Of > > > > = > > .4-errata01-os-complete.html#_Toc325658980> > > > > > > with OAuth JWT Token. > > > > Is there a standard claim which we can = define > > within the OAuth JWT > > which denote the On-behalf-of User. > > > > For e.g., a Customer Representative trying to = create > > token on behalf of > > a customer and trying to execute services = specific > > for that specific > > customer. > > > > Regards, > > > > Vivek Biswas, > > CISSP > > > > *Cisco Systems, Inc >* > > > > *Bldg. J, San Jose, USA,* > > > > *Phone: +1 408 527 9176 = > > >* > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@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 = >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_66D549B1-5173-4D19-ADDC-407D01DE6C77 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Sorry Mike,

I was looking at an earlier version that had them reversed. =   I think the wording can be improved but the composite vs = delegation semantic is correct now.

However Tony now seems to disagree with = that.   I am going to walk away slowly and let you sort out his = last post:)

We = can discuss further in Prague.

John B.

On Jul 6, 2015, at 3:48 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Fair enough, Brian.  For clarity, my = sense of the action items is that I agreed to do those actions based on = feedback at the ad-hoc meeting and then people would review the result = =E2=80=93 not that everything would be =E2=80=9Cdone=E2=80=9D after = taking those actions.  I=E2=80=99ll still plan to act on that = feedback.
 
I=E2=80=99d be glad to sit down with you and others in = Prague, Brian, to work out how to make sure your use cases are covered = and the draft is as clear as it can be, given its somewhat esoteric = subject matter.  Now that JWT and JOSE and the OAuth Assertions = specs are done and several others are nearly done, getting back to this = is a priority for me.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = Cheers,
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            -- = Mike
 
From: Brian = Campbell [mailto:bcampbell@pingidentity.com] 
Sent: Monday, July 06, 2015 11:29 = AM
To: Mike Jones
Cc: John = Bradley; oauth
Subject: Re: [OAUTH-WG] JWT Token = on-behalf of Use case
 

Stating specific action items = resulting from the ad-hoc meeting in Dallas like that suggests some = clear consensus was reached, which is not at all the case. As I recall, = several of us argued past one another for an hour or so and decided to = adjourn in order to go to the bar (okay, and dinner too - but mostly = beer).

The impression about reversal of terms, I think, comes = from the text in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#= section-1.3 which = hurts my head a little every-time I read it but does seems to confuse = things. The MSDN link John gave is much more to = the point than WS-Trust (I don't believe WS-Trust can be pointed to as a = model of clarity).  In the draft I wrote, I tried to take Mike's = text and clarify a distinction between impersonation and delegation = with https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section= -1.3 and then also = be very explicit about act-as vs. on-behalf-of in the parameter = definitions at https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section= -2 in a manor that = was consistent with WS-Trust and the MSDN explanation. I could see value = in breaking with that shaky legacy and using new terms too. But I get = the point of trying to keep with the old also and potential for even = more confusing by using new terms. 

I = wrote draft-campbell-oauth-sts last year in response to the call for = adoption of jones-oauth-token-exchange (thread from the archive). Though I didn't try and stand = in the way and indicated a willingness to collaborate on things. With = the expectation, of course, that the details would differ from the -00s = and -01s as work progressed. Folks seemed generally amenable to that at the time but little has = happened since then.

Phil's earlier point about the priory of = this getting pushed down has some truth to it. But I still believe it's = something that can provide a lot of value in standardizing, if we do so = in a reasonable way.

 



 

 
On Mon, Jul 6, 2015 = at 10:33 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
It = would surprise me if on-behalf-of and act-as were reversed with respect = WS-Trust, because the explanations of the terms came directly from = WS-Trust 1.4.  I also think the chances of us reducing confusion by = inventing new terminology, rather than adding to it, would not be in our = favor. :-/

FYI, the action items = outstanding from our ad-hoc meeting on this draft in Dallas are:
  - Allowing security types other than JWT to also be = used as the act_as and on_behalf_of request values.
  = - Further integrating the mechanism into the existing OAuth ecosystem - = allowing use of access tokens or refresh tokens when appropriate.

I plan to do the first today.  The second = is probably more than I'll get done today before the submission = cutoff.  I agree with John that it would be useful to have = discussions on this in Prague on the best way to achieve this further = integration.  I'll plan to come into the Prague meeting with a = concrete proposal for review.

    =                     =         Best wishes,
    =                     =         -- Mike

-----Original Message-----
From: OAuth = [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Monday, July 06, 2015 8:13 AM
To: Brian = Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] = JWT Token on-behalf of Use case

Yes = unfortunately we haven=E2=80=99t made any progress on this since = accepting Mike=E2=80=99s first draft.

His = proposal is basically for a new endpoint while Brian tired to fit it = into the existing token endpoint.

I think = draft-ietf-oauth-token-exchange-01 still has OnBehalfOf and ActAs = reversed compared to WS-Trust 1.4.
see https://msdn.microsoft.com/en-us/library/ee748487.aspx for the short = explanation.

I think Brian is closer in = explaining it.

In fairness because WS-Trust = originally only had On-Behalf-Of the naming and what people put in = tokens is a bit muddled in many implementations.
I think = many times it is how WIF implemented it that people copied.

It may be better to have new terms that are = clear such as impersonation and composite.

The WG needs to decide if this is going to be an entirely new = endpoint, free of the Token endpoint semantics.   There are = plusses and minuses to both options.

Also = while it is nice to be pure and talk about abstract security tokens, it = would be good to give some guidance on what a composite security token = would look like for interoperability.

There = are also issues around how this would work with proof of possession = security tokens, both as input and output.

Perhaps we can make some progress on this in Prague.

John B.




> On Jul 6, 2015, at 11:04 = AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
>> Thanks Sergey,
>
> = The goal of draft-campbell-oauth-sts was to be consistent with OAuth 2.0 = and thus hopefully familiar to developers and easy to understand and = implement (especially from the client side). It's also intended to be = flexible in order to accommodate a variety of use-cases including the = chaining type cases that Justin's draft covers.
>
> Specifying a security_token_type of the returned token = is just a way of providing more info to the client about the token (i.e. = is this a JWT or a SAML token or something else) via a URI. It's not = always needed but in STS style cases the tokens are not always opaque to = the client and the parameter just provides info about the returned = token.
>
> On Mon, Jul 6, 2015 at 5:33 = AM, Sergey Beryozkin <sberyozkin@gmail.com> wrote:
> Hi = Brian
>
> I've read the text, I like = it is still pure OAuth2, with few extra parameters added to the access = token request, and a key response property being 'access_token' as = opposed to 'security_access_token' as in the = draft-ietf-oauth-token-exchange-01.
> It appears = draft-campbell-oauth-sts-01 can cover a draft-richer-oauth-chain-00 case = with the on_behalf_of (and/or act_as ?) property being an original = client token but not 100% sure given draft-richer-oauth-chain-00 covers = a specific case.
>
> One thing I'm not = sure about is what is the purpose of specifying a
> = security_token_type of the returned access token
>
> Thanks, Sergey
>
> On = 01/07/15 15:59, Brian Campbell wrote:
> One problem, I = think, with token exchange is that it can be really
> = simple (token in and token out) and really complicated (client X = wants
> a token that says user A is doing something on = behalf of user B) at
> the same time.
>
> I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in
> an = attempt to simplify things and express what I envisioned as an
> OAuth based token exchange framework. Though it likely = only muddied
> the waters :)
>
> On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin <sberyozkin@gmail.com
> <mailto:sberyozkin@gmail.com>> wrote:
>
>     Hi Justin
>
>     https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much
>     easier to read, that I can tell for = sure, at least it is obvious why
>     a = given entity (RS1) may want to exchange the current token provided
>     by a client for a new token. = Definitely easily implementable...
>
>     One thing I'm not sure in the = draft-richer-oauth-chain-00 about is
>    =  on behalf of whose entity RS1 will be acting once it starts
>     accessing RS2, On Behalf Of RO, or = may be On Behalf Of (RO +
>     Client), = or may be it is On Behalf Of RO + Act As Client ? The last
>     one seems most logical to me...
>
>     Thanks, Sergey
>
>
>    =  On 01/07/15 13:18, Justin Richer wrote:
>
>         As it's written right = now, it's a translation of some WS-*
>    =      concepts into
>      =    JWT format. It's not really OAuth-y (since the client has = to
>         understand
>         the token format along = with everyone else, and according to the
>    =      authors
>      =    the artifacts might not even be "OAuth tokens"), and that's = my main
>         issue with = the document. Years ago, I proposed an OAuth-based
>         token swap
>         mechanism:
>
>         https://tools.ietf.org/html/draft-richer-oauth-chain-00
>
>         This = works without defining semantics of the tokens themselves, just
>         like the rest of OAuth. = I've proposed to the authors of the current
>  =        draft that it should incorporate both = semantic (using JWT) and
>        =  syntactic
>        =  (using a simple token-agnostic grant) token swap mechanisms, = and
>         that
>         the two could be easily = compatible.
>
>      =       -- Justin
>
> =        On 7/1/2015 6:35 AM, Sergey Beryozkin = wrote:
>
>        =      Hmm... perhaps the clue is in the draft title,
>            =  token-exchange, so may
>      =        be it is a case of the given access token = ("on_behalf_of" or
>          =    "act_as"
>        =      claim) being used to request a new security token. = One can
>            =  only guess
>          =    though, does not seem like the authors are keen to = answer
>            =  the newbie
>          =    questions...
>
>  =            Cheers, Sergey
>
>
>    =          On 30/06/15 13:38, Sergey Beryozkin = wrote:
>
>        =          Hi,
>    =              Can you please explain = what is the difference between
>      =            On-Behalf-Of
>                =  semantics described in the
>      =           =  draft-ietf-oauth-token-exchange-01 and the
>  =                implicit = On-Behalf-Of semantics a client OAuth2 token
>  =                possesses ?
>
>          =        For example, = draft-ietf-oauth-token-exchange-01 mentions:
>
>                =  "Whereas, with on-behalf-of semantics, principal A still
>                =  has its own
>          =        identity separate from B and it is explicitly = understood
>            =      that while B
>      =            may have delegated its rights = to A, any actions taken
>        =          are being taken by
>                =  A and not B. In a sense, A is an agent for B."
>>                =  This is a typical case with the authorization code flow
>                =  where a client
>        =          application acts on-behalf-of the user = who authorized
>          =        this application ?
>
>                =  Sorry if I'm missing something
>
>                =  Cheers, Sergey
>        =          On 25/06/15 22:28, Mike Jones = wrote:
>
>        =              That=E2=80=99s what
>                =      https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01<= /a>
>              =        is
>      =                about.
>
>          =            Cheers,
>
>                =      -- Mike
>
>  =                   =  *From:*OAuth [mailto:oauth-bounces@ietf.org
>    =                 =  <mailto:oauth-bounces@ietf.org>] *On Behalf Of *Vivek
>                =      Biswas
>        =              -T (vibiswas - XORIANT = CORPORATION at Cisco)
>        =              *Sent:* Thursday, June = 25, 2015 2:20 PM
>          =            *To:* OAuth@ietf.org <mailto:OAuth@ietf.org>
>  =                   =  *Subject:* [OAUTH-WG] JWT Token on-behalf of Use
> = case
>
>        =              Hi All,
>
>          =                I am looking to = solve a use-case similar to
>      =                WS-Security = On-Behalf-Of
>
> <http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-t= rust-1
> = .4-errata01-os-complete.html#_Toc325658980>
>
>
>          =            with OAuth JWT Token.
>
>          =                Is there a = standard claim which we can define
>    =                  within the = OAuth JWT
>            =          which denote the On-behalf-of User.
>
>          =            For e.g., a Customer = Representative trying to create
>      =                token on behalf = of
>              =        a customer and trying to execute services = specific
>            =          for that specific
>                =      customer.
>
>  =                   =  Regards,
>
>      =                Vivek Biswas,
>                =      CISSP
>
>  =                   =  *Cisco Systems, Inc <http://www.cisco.com/>*
>
>                =      *Bldg. J, San Jose, USA,*
>
>                =      *Phone: +1 408 527 9176
> <tel:%2B1%20408%20527%209176>*
>
>
>
>    =                 =  _______________________________________________
>                =      OAuth mailing list
>    =                  OAuth@ietf.org <mailto:OAuth@ietf.org>
>  =                    https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>            =  _______________________________________________
>             OAuth = mailing list
>            =  OAuth@ietf.org <mailto:OAuth@ietf.org>
>  =            https://www.ietf.org/mailman/listinfo/oauth
>
>
>    =      _______________________________________________
>         OAuth mailing list
>         OAuth@ietf.org <mailto:OAuth@ietf.org>
>  =        https://www.ietf.org/mailman/listinfo/oauth
>
>
>    =  _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>  =    https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
> = _______________________________________________
> OAuth = mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

= --Apple-Mail=_66D549B1-5173-4D19-ADDC-407D01DE6C77-- From nobody Mon Jul 6 14:56:14 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F38D1A1AA7 for ; Mon, 6 Jul 2015 14:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jI3bLJdgPWx1 for ; Mon, 6 Jul 2015 14:56:07 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0119.outbound.protection.outlook.com [65.55.169.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9B8B1A1A56 for ; Mon, 6 Jul 2015 14:56:06 -0700 (PDT) Received: from CY1PR0301MB1243.namprd03.prod.outlook.com (10.161.212.153) by BL2PR03MB433.namprd03.prod.outlook.com (10.141.92.19) with Microsoft SMTP Server (TLS) id 15.1.207.12; Mon, 6 Jul 2015 21:56:02 +0000 Received: from CY1PR0301MB1243.namprd03.prod.outlook.com ([10.161.212.153]) by CY1PR0301MB1243.namprd03.prod.outlook.com ([10.161.212.153]) with mapi id 15.01.0207.004; Mon, 6 Jul 2015 21:56:02 +0000 From: Anthony Nadalin To: Brian Campbell Thread-Topic: [OAUTH-WG] JWT Token on-behalf of Use case Thread-Index: AdCvjKZzog4lHzdSReisaGHaz/hQ6gAARPxgAOj5XIAALgFuAAADlXeAAAG2sYAAA+u+gAD0P/SAAAVKOIAAAmBqAAACCAqQAATTnQAAAC6oEAAGPT4AAAAhWTA= Date: Mon, 6 Jul 2015 21:56:01 +0000 Message-ID: References: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> <55928DB3.7090300@gmail.com> <5593C270.7000008@gmail.com> <5593DA7D.80401@mit.edu> <5593E5FD.3050403@gmail.com> <559A676F.3070008@gmail.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; x-originating-ip: [131.107.159.183] x-microsoft-exchange-diagnostics: 1; BL2PR03MB433; 5:wi86dKInl3CxkOBurhXUpJ22QRZitaP6ZWEKjrq7b+gGULIokSuaWOxIM20lET9RVIhM3e1fZYt0UOXCfvVP3YUH0jidxVbLxUGr5NZ2ZX15SEiWopqHxA6/PL/a2A/PN2lemFlt7CmVrulC/A14cQ==; 24:FEqvkL1uNJ/VOmv3L4aN5oug2nETaQQPfvfVE3yauoRGbS6uE56IyDqrFYs+pvEfh2NEgTIDZgBB1CcSbZkl3NEyyWOetkPVkkuKgwa/Xrw=; 20:a7bHMtdlyYfKJoTeLy+pYJ5haNdbARq9neVNV4gC2P3PooNpT1T3VlS9VFDbXjkMF2NJyXYq0ZQ+ihBvHD/XdA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB433; x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BL2PR03MB433; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB433; x-forefront-prvs: 06290ECA9D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(13464003)(479174004)(52314003)(3905003)(69234005)(164054003)(51704005)(377454003)(60444003)(24454002)(53754006)(5001960100002)(87936001)(19625215002)(77156002)(92566002)(2656002)(81156007)(33656002)(86362001)(122556002)(66066001)(40100003)(19300405004)(19609705001)(62966003)(46102003)(99286002)(74316001)(19580395003)(110136002)(5002640100001)(93886004)(5003600100002)(189998001)(561944003)(2950100001)(19580405001)(54356999)(16236675004)(86612001)(76176999)(2900100001)(77096005)(19617315012)(102836002)(50986999)(15975445007)(76576001)(42262002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB433; H:CY1PR0301MB1243.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB124389773FAD2B4983C0A480A6930CY1PR0301MB1243_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2015 21:56:01.9191 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB433 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 21:56:13 -0000 --_000_CY1PR0301MB124389773FAD2B4983C0A480A6930CY1PR0301MB1243_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hhdCBpcyB3cml0dGVuIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LW9hdXRoLXRva2VuLWV4Y2hhbmdlLTAxI3NlY3Rpb24tMS4zIGFuZCB0aGUgdGV4dCB0aGF0IGRl c2NyaWJlcyB0aGUgV2luZG93cyBLZXJiZXJvcyBzdXBwb3J0IGZvciBQcm90b2NvbCBUcmFuc2l0 aW9uIGFuZCBDb25zdHJhaW5lZCBEZWxlZ2F0aW9uIGFyZSBpbiBhbGlnbm1lbnQgbm90IHN1cmUg d2hhdCBtYWtlIHlvdSB0aGluayB0aGV5IGFyZSBub3QuDQoNCklmIHlvdSBhcmUgdHJ5aW5nIHRv IGRlc2NyaWJlIGRpZmZlcmVudCBmZWF0dXJlcyB0aGFuIFdpbmRvd3MgS2VyYmVyb3MgUHJvdG9j b2wgVHJhbnNpdGlvbi9Db25zdHJhaW5lZCBEZWxlZ2F0aW9uIHRoYXQgdGhlbiBJIHdvdWxkIGFn cmVlIHRoYXQgdGhlIHRleHQgbWF5IG5vdCBiZSBjb3JyZWN0IGJ1dCB0aGVuIGFnYWluIGl0IHdv dWxkIG5vdCBiZSBkZXNjcmliaW5nIHRoZSBXaW5kb3dzIEtlcmJlcm9zIFByb3RvY29sIFRyYW5z aXRpb24vQ29uc3RyYWluZWQgRGVsZWdhdGlvbi4gVGhlIHdheSB5b3UgaGF2ZSB0aGUgdGV4dCBk ZXNjcmliZXMgZGlmZmVyZW50IHNldCB1c2UgY2FzZSB0aGVuIHdoYXQgdGhlIGZlYXR1cmUgb2Yg IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hh bmdlLTAxI3NlY3Rpb24tMS4zIGRlc2NyaWJlcy4NCg0KRnJvbTogQnJpYW4gQ2FtcGJlbGwgW21h aWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbV0NClNlbnQ6IE1vbmRheSwgSnVseSA2LCAy MDE1IDI6MzMgUE0NClRvOiBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0LmNvbT4N CkNjOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+OyBvYXV0aCA8b2F1 dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBKV1QgVG9rZW4gb24tYmVoYWxm IG9mIFVzZSBjYXNlDQoNCkEgbmF0dXJhbCB1c2FnZSBvZiBhY3QtYXMgb3IgaW1wZXJzb25hdGlv bjxodHRwOi8vd3d3Lm94Zm9yZGRpY3Rpb25hcmllcy5jb20vdXMvZGVmaW5pdGlvbi9hbWVyaWNh bl9lbmdsaXNoL2ltcGVyc29uYXRlPiB3b3VsZCBzdWdnZXN0LCB0byBtYW55IHBlb3BsZSBhbnl3 YXksIHRoYXQgdGhlIHdheSB5b3UganVzdCB1c2VkIHRoZSB0ZXJtcyBpcyByZXZlcnNlZC4gVGhl IGJvbGQgdGV4dCBiZWxvdyBmcm9tIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTAxI3NlY3Rpb24tMS4zIHVzZXMgJ2ltcGVyc29uYXRl cycgYW5kICJvbi1iZWhhbGYtb2YiIGNvbnRyYXJ5IHRvIHdoYXQgeW91IGp1c3Qgd3JvdGUgYWJv dXQgV2luZG93cyBLZXJiLiBUaGF0J3Mgd2hlcmUgdGhlIGFzc2VydGlvbiB0aGF0IHRoZSBkcmFm dCBoYXMgdGhlbSByZXZlcnNlZCBmcm9tIGRlIGZhY3RvIHVzYWdlIGluIFdTLVRydXN0LiBUaG9z ZSBzZW1hbnRpY3MgYXJlIG5vdCBvbmx5IG9uZSBvcGVuIGlzc3VlIHRoYXQgbmVlZHMgdG8gYmUg cmVzb2x2ZWQsIGhvd2V2ZXIsIGV2ZW4gaWYgdGhleSBvY2N1cHkgbW9zdCBvZiB0aGUgZGlzY3Vz c2lvbi4NCg0KMS4zLiAgT24tQmVoYWxmLU9mIHZzLiBJbXBlcnNvbmF0aW9uIFNlbWFudGljcw0K DQogICBXaGVuIHByaW5jaXBhbCBBIGFjdHMgb24gYmVoYWxmIG9mIHByaW5jaXBhbCBCLCBBIGlz IGdpdmVuIGFsbCB0aGUNCiAgIHJpZ2h0cyB0aGF0IEIgaGFzIHdpdGhpbiBzb21lIGRlZmluZWQg cmlnaHRzIGNvbnRleHQuICBXaGVyZWFzLCB3aXRoDQogICBvbi1iZWhhbGYtb2Ygc2VtYW50aWNz LCBwcmluY2lwYWwgQSBzdGlsbCBoYXMgaXRzIG93biBpZGVudGl0eQ0KICAgc2VwYXJhdGUgZnJv bSBCIGFuZCBpdCBpcyBleHBsaWNpdGx5IHVuZGVyc3Rvb2QgdGhhdCB3aGlsZSBCIG1heSBoYXZl DQogICBkZWxlZ2F0ZWQgaXRzIHJpZ2h0cyB0byBBLCBhbnkgYWN0aW9ucyB0YWtlbiBhcmUgYmVp bmcgdGFrZW4gYnkgQSBhbmQNCiAgIG5vdCBCLiBJbiBhIHNlbnNlLCBBIGlzIGFuIGFnZW50IGZv ciBCLg0KDQogICBPbi1iZWhhbGYtb2Ygc2VtYW50aWNzIGFyZSB0aGVyZWZvcmUgZGlmZmVyZW50 IHRoYW4gaW1wZXJzb25hdGlvbg0KICAgc2VtYW50aWNzLCB3aXRoIHdoaWNoIGl0IGlzIHNvbWV0 aW1lcyBjb25mdXNlZC4gIFdoZW4gcHJpbmNpcGFsIEENCiAgIGltcGVyc29uYXRlcyBwcmluY2lw YWwgQiwgdGhlbiBpbiBzbyBmYXIgYXMgYW55IGVudGl0eSByZWNlaXZpbmcNCiAgIENsYWltcyBp cyBjb25jZXJuZWQsIHRoZXkgYXJlIGFjdHVhbGx5IGRlYWxpbmcgd2l0aCBCLiBJdCBpcyB0cnVl DQogICB0aGF0IHNvbWUgbWVtYmVycyBvZiB0aGUgaWRlbnRpdHkgc3lzdGVtIG1pZ2h0IGhhdmUg YXdhcmVuZXNzIHRoYXQNCiAgIGltcGVyc29uYXRpb24gaXMgZ29pbmcgb24gYnV0IGl0IGlzIG5v dCBhIHJlcXVpcmVtZW50LiAgRm9yIGFsbA0KICAgaW50ZW50cyBhbmQgcHVycG9zZXMsIHdoZW4g QSBpcyBhY3RpbmcgZm9yIEIsIEEgaXMgQi4NCg0KDQoNCg0KDQpPbiBNb24sIEp1bCA2LCAyMDE1 IGF0IDI6NDMgUE0sIEFudGhvbnkgTmFkYWxpbiA8dG9ueW5hZEBtaWNyb3NvZnQuY29tPG1haWx0 bzp0b255bmFkQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNClRoZSBXUy1UcnVzdCDigJxBY3RBc+KA nSBtaW1pY3MgdGhlIFdpbmRvd3MgS2VyYmVyb3MgUHJvdG9jb2wgVHJhbnNpdGlvbiAoaW1wZXJz b25hdGlvbikgIGZlYXR1cmUgYXMgdGhpcyBlbmFibGVzIGFuIGFjY291bnQgdG8gaW1wZXJzb25h dGUgYW5vdGhlciBhY2NvdW50IGZvciB0aGUgcHVycG9zZSBvZiBwcm92aWRpbmcgYWNjZXNzIHRv IHJlc291cmNlcy4gSW4gYSB0eXBpY2FsIHNjZW5hcmlvLCB0aGUgaW1wZXJzb25hdGluZyBhY2Nv dW50IHdvdWxkIGJlIGEgc2VydmljZSBhY2NvdW50IGFzc2lnbmVkIHRvIGEgd2ViIGFwcGxpY2F0 aW9uIG9yIHRoZSBjb21wdXRlciBhY2NvdW50IG9mIGEgd2ViIHNlcnZlci4gVGhlIGltcGVyc29u YXRlZCBhY2NvdW50IHdvdWxkIGJlIGEgdXNlciBhY2NvdW50IHJlcXVpcmluZyBhY2Nlc3MgdG8g cmVzb3VyY2VzIChlLmcuIGRhdGEgaW4gYW4gU1FMIGRhdGFiYXNlKSB2aWEgYSB3ZWIgYXBwbGlj YXRpb24uIEluIHRoaXMgc2NlbmFyaW8sIFNRTCBzZXJ2ZXIgd291bGQgYmUgYWNjZXNzZWQgYnkg dGhlIGltcGVyc29uYXRpbmcgKHNlcnZpY2UgYWNjb3VudCkgYWNjb3VudCwgaG93ZXZlciBhY2Nl c3Mgd291bGQgYmUgdW5kZXIgdGhlIGNvbnRleHQgb2YgdGhlIGltcGVyc29uYXRlZCAodXNlcikg YWNjb3VudC4NCg0KV1MtVHJ1c3Qg4oCcT25CZWhhbGZPZuKAnSAgbWltaWNzIHRoZSBXaW5kb3dz IEtlcmJlcm9zIENvbnN0cmFpbmVkIERlbGVnYXRpb24gZmVhdHVyZSwgd2hpY2ggbGV0cyB5b3Ug bGltaXQgdGhlIGJhY2stZW5kIHNlcnZpY2VzIGZvciB3aGljaCBhIGZyb250LWVuZCBzZXJ2aWNl IGNhbiByZXF1ZXN0IHRpY2tldHMgb24gYmVoYWxmIG9mIGFub3RoZXIgdXNlci4g4oCcT25CZWhh bGZPZuKAnSAgYWxsb3dzIGEgc2VsZWN0ZWQgc2VydmljZXMgb24gYSBzZXJ2ZXIgY2FuIGJlIGdy YW50ZWQgZm9yIGFjY2VzcyBieSB0aGUgaW1wZXJzb25hdGluZyBhY2NvdW50LCB3aGlsc3Qgb3Ro ZXIgc2VydmljZXMgb24gdGhlIHNhbWUgc2VydmVyLCBvciBzZXJ2aWNlcyBvbiBvdGhlciBzZXJ2 ZXJzIGFyZSBkZW5pZWQgZm9yIGFjY2Vzcy4NCg0KTWF5YmUgc29tZW9uZSBjYW4gc3VtbWFyaXpl IHdoeSB0aGV5IHRoaW5rIHRoZSB0ZXh0IGZvciBBY3RBcyBhbmQgT25CZWhhbGZPZiBpbiBXUy1U cnVzdCBvciBXaW5kb3dzIEtlcmJlcm9zIGlzIHdyb25nIG9yIHN3YXBwZWQgYXMgSSBoYXZlIG5v dCBzZWVuIGEgY2xlYXIgZXhwbGFuYXRpb24gb3RoZXIgdGhhbiBKb2huIHNheWluZyB0aGF0IEJy aWFuIGtub3dzIGFuZCBCcmlhbiBzYXlpbmcgSm9obiBrbm93cy4NCg0KT3VyIHVzYWdlIGFuZCB1 c2UgY2FzZXMgYXJlIGJhc2VkIHVwb24gdGhlIGRlcGxveWVkIHNlcnZpY2VzIG9mIFdTLVRydXN0 IGFuZCBLZXJiZXJvcyBzdXBwb3J0IGluIFdpbmRvd3MgKHdvcmtzdGF0aW9uIGFuZCBzZXJ2ZXIp IGFuZCBYYm94Lg0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgQnJpYW4gQ2FtcGJl bGwNClNlbnQ6IE1vbmRheSwgSnVseSA2LCAyMDE1IDExOjI5IEFNDQpUbzogTWlrZSBKb25lcyA8 TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29m dC5jb20+Pg0KQ2M6IG9hdXRoIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+ Pg0KDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBKV1QgVG9rZW4gb24tYmVoYWxmIG9mIFVzZSBj YXNlDQoNClN0YXRpbmcgc3BlY2lmaWMgYWN0aW9uIGl0ZW1zIHJlc3VsdGluZyBmcm9tIHRoZSBh ZC1ob2MgbWVldGluZyBpbiBEYWxsYXMgbGlrZSB0aGF0IHN1Z2dlc3RzIHNvbWUgY2xlYXIgY29u c2Vuc3VzIHdhcyByZWFjaGVkLCB3aGljaCBpcyBub3QgYXQgYWxsIHRoZSBjYXNlLiBBcyBJIHJl Y2FsbCwgc2V2ZXJhbCBvZiB1cyBhcmd1ZWQgcGFzdCBvbmUgYW5vdGhlciBmb3IgYW4gaG91ciBv ciBzbyBhbmQgZGVjaWRlZCB0byBhZGpvdXJuIGluIG9yZGVyIHRvIGdvIHRvIHRoZSBiYXIgKG9r YXksIGFuZCBkaW5uZXIgdG9vIC0gYnV0IG1vc3RseSBiZWVyKS4NClRoZSBpbXByZXNzaW9uIGFi b3V0IHJldmVyc2FsIG9mIHRlcm1zLCBJIHRoaW5rLCBjb21lcyBmcm9tIHRoZSB0ZXh0IGluIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdl LTAxI3NlY3Rpb24tMS4zIHdoaWNoIGh1cnRzIG15IGhlYWQgYSBsaXR0bGUgZXZlcnktdGltZSBJ IHJlYWQgaXQgYnV0IGRvZXMgc2VlbXMgdG8gY29uZnVzZSB0aGluZ3MuIFRoZSBNU0ROIGxpbms8 aHR0cHM6Ly9tc2RuLm1pY3Jvc29mdC5jb20vZW4tdXMvbGlicmFyeS9lZTc0ODQ4Ny5hc3B4PiBK b2huIGdhdmUgaXMgbXVjaCBtb3JlIHRvIHRoZSBwb2ludCB0aGFuIFdTLVRydXN0IChJIGRvbid0 IGJlbGlldmUgV1MtVHJ1c3QgY2FuIGJlIHBvaW50ZWQgdG8gYXMgYSBtb2RlbCBvZiBjbGFyaXR5 KS4gIEluIHRoZSBkcmFmdCBJIHdyb3RlLCBJIHRyaWVkIHRvIHRha2UgTWlrZSdzIHRleHQgYW5k IGNsYXJpZnkgYSBkaXN0aW5jdGlvbiBiZXR3ZWVuIGltcGVyc29uYXRpb24gYW5kIGRlbGVnYXRp b24gd2l0aCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2FtcGJlbGwtb2F1dGgt c3RzLTAxI3NlY3Rpb24tMS4zIGFuZCB0aGVuIGFsc28gYmUgdmVyeSBleHBsaWNpdCBhYm91dCBh Y3QtYXMgdnMuIG9uLWJlaGFsZi1vZiBpbiB0aGUgcGFyYW1ldGVyIGRlZmluaXRpb25zIGF0IGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW1wYmVsbC1vYXV0aC1zdHMtMDEjc2Vj dGlvbi0yIGluIGEgbWFub3IgdGhhdCB3YXMgY29uc2lzdGVudCB3aXRoIFdTLVRydXN0IGFuZCB0 aGUgTVNETiBleHBsYW5hdGlvbi4gSSBjb3VsZCBzZWUgdmFsdWUgaW4gYnJlYWtpbmcgd2l0aCB0 aGF0IHNoYWt5IGxlZ2FjeSBhbmQgdXNpbmcgbmV3IHRlcm1zIHRvby4gQnV0IEkgZ2V0IHRoZSBw b2ludCBvZiB0cnlpbmcgdG8ga2VlcCB3aXRoIHRoZSBvbGQgYWxzbyBhbmQgcG90ZW50aWFsIGZv ciBldmVuIG1vcmUgY29uZnVzaW5nIGJ5IHVzaW5nIG5ldyB0ZXJtcy4NCkkgd3JvdGUgZHJhZnQt Y2FtcGJlbGwtb2F1dGgtc3RzIGxhc3QgeWVhciBpbiByZXNwb25zZSB0byB0aGUgY2FsbCBmb3Ig YWRvcHRpb24gb2Ygam9uZXMtb2F1dGgtdG9rZW4tZXhjaGFuZ2UgKHRocmVhZCBmcm9tIHRoZSBh cmNoaXZlPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVu dC9tc2cxMzMwNS5odG1sPikuIFRob3VnaCBJIGRpZG4ndCB0cnkgYW5kIHN0YW5kIGluIHRoZSB3 YXkgYW5kIGluZGljYXRlZCBhIHdpbGxpbmduZXNzIHRvIGNvbGxhYm9yYXRlIG9uIHRoaW5ncy4g V2l0aCB0aGUgZXhwZWN0YXRpb24sIG9mIGNvdXJzZSwgdGhhdCB0aGUgZGV0YWlscyB3b3VsZCBk aWZmZXIgZnJvbSB0aGUgLTAwcyBhbmQgLTAxcyBhcyB3b3JrIHByb2dyZXNzZWQuIEZvbGtzIHNl ZW1lZCBnZW5lcmFsbHkgYW1lbmFibGUgdG8gdGhhdDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTMzMDguaHRtbD4gYXQgdGhlIHRpbWUgYnV0 IGxpdHRsZSBoYXMgaGFwcGVuZWQgc2luY2UgdGhlbi4NClBoaWwncyBlYXJsaWVyIHBvaW50IGFi b3V0IHRoZSBwcmlvcnkgb2YgdGhpcyBnZXR0aW5nIHB1c2hlZCBkb3duIGhhcyBzb21lIHRydXRo IHRvIGl0LiBCdXQgSSBzdGlsbCBiZWxpZXZlIGl0J3Mgc29tZXRoaW5nIHRoYXQgY2FuIHByb3Zp ZGUgYSBsb3Qgb2YgdmFsdWUgaW4gc3RhbmRhcmRpemluZywgaWYgd2UgZG8gc28gaW4gYSByZWFz b25hYmxlIHdheS4NCg0KDQoNCg0KT24gTW9uLCBKdWwgNiwgMjAxNSBhdCAxMDozMyBBTSwgTWlr ZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCkl0IHdvdWxkIHN1cnByaXNlIG1lIGlmIG9uLWJlaGFs Zi1vZiBhbmQgYWN0LWFzIHdlcmUgcmV2ZXJzZWQgd2l0aCByZXNwZWN0IFdTLVRydXN0LCBiZWNh dXNlIHRoZSBleHBsYW5hdGlvbnMgb2YgdGhlIHRlcm1zIGNhbWUgZGlyZWN0bHkgZnJvbSBXUy1U cnVzdCAxLjQuICBJIGFsc28gdGhpbmsgdGhlIGNoYW5jZXMgb2YgdXMgcmVkdWNpbmcgY29uZnVz aW9uIGJ5IGludmVudGluZyBuZXcgdGVybWlub2xvZ3ksIHJhdGhlciB0aGFuIGFkZGluZyB0byBp dCwgd291bGQgbm90IGJlIGluIG91ciBmYXZvci4gOi0vDQoNCkZZSSwgdGhlIGFjdGlvbiBpdGVt cyBvdXRzdGFuZGluZyBmcm9tIG91ciBhZC1ob2MgbWVldGluZyBvbiB0aGlzIGRyYWZ0IGluIERh bGxhcyBhcmU6DQogIC0gQWxsb3dpbmcgc2VjdXJpdHkgdHlwZXMgb3RoZXIgdGhhbiBKV1QgdG8g YWxzbyBiZSB1c2VkIGFzIHRoZSBhY3RfYXMgYW5kIG9uX2JlaGFsZl9vZiByZXF1ZXN0IHZhbHVl cy4NCiAgLSBGdXJ0aGVyIGludGVncmF0aW5nIHRoZSBtZWNoYW5pc20gaW50byB0aGUgZXhpc3Rp bmcgT0F1dGggZWNvc3lzdGVtIC0gYWxsb3dpbmcgdXNlIG9mIGFjY2VzcyB0b2tlbnMgb3IgcmVm cmVzaCB0b2tlbnMgd2hlbiBhcHByb3ByaWF0ZS4NCg0KSSBwbGFuIHRvIGRvIHRoZSBmaXJzdCB0 b2RheS4gIFRoZSBzZWNvbmQgaXMgcHJvYmFibHkgbW9yZSB0aGFuIEknbGwgZ2V0IGRvbmUgdG9k YXkgYmVmb3JlIHRoZSBzdWJtaXNzaW9uIGN1dG9mZi4gIEkgYWdyZWUgd2l0aCBKb2huIHRoYXQg aXQgd291bGQgYmUgdXNlZnVsIHRvIGhhdmUgZGlzY3Vzc2lvbnMgb24gdGhpcyBpbiBQcmFndWUg b24gdGhlIGJlc3Qgd2F5IHRvIGFjaGlldmUgdGhpcyBmdXJ0aGVyIGludGVncmF0aW9uLiAgSSds bCBwbGFuIHRvIGNvbWUgaW50byB0aGUgUHJhZ3VlIG1lZXRpbmcgd2l0aCBhIGNvbmNyZXRlIHBy b3Bvc2FsIGZvciByZXZpZXcuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQmVz dCB3aXNoZXMsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBK b2huIEJyYWRsZXkNClNlbnQ6IE1vbmRheSwgSnVseSAwNiwgMjAxNSA4OjEzIEFNDQpUbzogQnJp YW4gQ2FtcGJlbGwNCkNjOiBvYXV0aA0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gSldUIFRva2Vu IG9uLWJlaGFsZiBvZiBVc2UgY2FzZQ0KDQpZZXMgdW5mb3J0dW5hdGVseSB3ZSBoYXZlbuKAmXQg bWFkZSBhbnkgcHJvZ3Jlc3Mgb24gdGhpcyBzaW5jZSBhY2NlcHRpbmcgTWlrZeKAmXMgZmlyc3Qg ZHJhZnQuDQoNCkhpcyBwcm9wb3NhbCBpcyBiYXNpY2FsbHkgZm9yIGEgbmV3IGVuZHBvaW50IHdo aWxlIEJyaWFuIHRpcmVkIHRvIGZpdCBpdCBpbnRvIHRoZSBleGlzdGluZyB0b2tlbiBlbmRwb2lu dC4NCg0KSSB0aGluayBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTAxIHN0aWxsIGhh cyBPbkJlaGFsZk9mIGFuZCBBY3RBcyByZXZlcnNlZCBjb21wYXJlZCB0byBXUy1UcnVzdCAxLjQu DQpzZWUgaHR0cHM6Ly9tc2RuLm1pY3Jvc29mdC5jb20vZW4tdXMvbGlicmFyeS9lZTc0ODQ4Ny5h c3B4IGZvciB0aGUgc2hvcnQgZXhwbGFuYXRpb24uDQoNCkkgdGhpbmsgQnJpYW4gaXMgY2xvc2Vy IGluIGV4cGxhaW5pbmcgaXQuDQoNCkluIGZhaXJuZXNzIGJlY2F1c2UgV1MtVHJ1c3Qgb3JpZ2lu YWxseSBvbmx5IGhhZCBPbi1CZWhhbGYtT2YgdGhlIG5hbWluZyBhbmQgd2hhdCBwZW9wbGUgcHV0 IGluIHRva2VucyBpcyBhIGJpdCBtdWRkbGVkIGluIG1hbnkgaW1wbGVtZW50YXRpb25zLg0KSSB0 aGluayBtYW55IHRpbWVzIGl0IGlzIGhvdyBXSUYgaW1wbGVtZW50ZWQgaXQgdGhhdCBwZW9wbGUg Y29waWVkLg0KDQpJdCBtYXkgYmUgYmV0dGVyIHRvIGhhdmUgbmV3IHRlcm1zIHRoYXQgYXJlIGNs ZWFyIHN1Y2ggYXMgaW1wZXJzb25hdGlvbiBhbmQgY29tcG9zaXRlLg0KDQpUaGUgV0cgbmVlZHMg dG8gZGVjaWRlIGlmIHRoaXMgaXMgZ29pbmcgdG8gYmUgYW4gZW50aXJlbHkgbmV3IGVuZHBvaW50 LCBmcmVlIG9mIHRoZSBUb2tlbiBlbmRwb2ludCBzZW1hbnRpY3MuICAgVGhlcmUgYXJlIHBsdXNz ZXMgYW5kIG1pbnVzZXMgdG8gYm90aCBvcHRpb25zLg0KDQpBbHNvIHdoaWxlIGl0IGlzIG5pY2Ug dG8gYmUgcHVyZSBhbmQgdGFsayBhYm91dCBhYnN0cmFjdCBzZWN1cml0eSB0b2tlbnMsIGl0IHdv dWxkIGJlIGdvb2QgdG8gZ2l2ZSBzb21lIGd1aWRhbmNlIG9uIHdoYXQgYSBjb21wb3NpdGUgc2Vj dXJpdHkgdG9rZW4gd291bGQgbG9vayBsaWtlIGZvciBpbnRlcm9wZXJhYmlsaXR5Lg0KDQpUaGVy ZSBhcmUgYWxzbyBpc3N1ZXMgYXJvdW5kIGhvdyB0aGlzIHdvdWxkIHdvcmsgd2l0aCBwcm9vZiBv ZiBwb3NzZXNzaW9uIHNlY3VyaXR5IHRva2VucywgYm90aCBhcyBpbnB1dCBhbmQgb3V0cHV0Lg0K DQpQZXJoYXBzIHdlIGNhbiBtYWtlIHNvbWUgcHJvZ3Jlc3Mgb24gdGhpcyBpbiBQcmFndWUuDQoN CkpvaG4gQi4NCg0KDQoNCg0KPiBPbiBKdWwgNiwgMjAxNSwgYXQgMTE6MDQgQU0sIEJyaWFuIENh bXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdp ZGVudGl0eS5jb20+PiB3cm90ZToNCj4NCj4gVGhhbmtzIFNlcmdleSwNCj4NCj4gVGhlIGdvYWwg b2YgZHJhZnQtY2FtcGJlbGwtb2F1dGgtc3RzIHdhcyB0byBiZSBjb25zaXN0ZW50IHdpdGggT0F1 dGggMi4wIGFuZCB0aHVzIGhvcGVmdWxseSBmYW1pbGlhciB0byBkZXZlbG9wZXJzIGFuZCBlYXN5 IHRvIHVuZGVyc3RhbmQgYW5kIGltcGxlbWVudCAoZXNwZWNpYWxseSBmcm9tIHRoZSBjbGllbnQg c2lkZSkuIEl0J3MgYWxzbyBpbnRlbmRlZCB0byBiZSBmbGV4aWJsZSBpbiBvcmRlciB0byBhY2Nv bW1vZGF0ZSBhIHZhcmlldHkgb2YgdXNlLWNhc2VzIGluY2x1ZGluZyB0aGUgY2hhaW5pbmcgdHlw ZSBjYXNlcyB0aGF0IEp1c3RpbidzIGRyYWZ0IGNvdmVycy4NCj4NCj4gU3BlY2lmeWluZyBhIHNl Y3VyaXR5X3Rva2VuX3R5cGUgb2YgdGhlIHJldHVybmVkIHRva2VuIGlzIGp1c3QgYSB3YXkgb2Yg cHJvdmlkaW5nIG1vcmUgaW5mbyB0byB0aGUgY2xpZW50IGFib3V0IHRoZSB0b2tlbiAoaS5lLiBp cyB0aGlzIGEgSldUIG9yIGEgU0FNTCB0b2tlbiBvciBzb21ldGhpbmcgZWxzZSkgdmlhIGEgVVJJ LiBJdCdzIG5vdCBhbHdheXMgbmVlZGVkIGJ1dCBpbiBTVFMgc3R5bGUgY2FzZXMgdGhlIHRva2Vu cyBhcmUgbm90IGFsd2F5cyBvcGFxdWUgdG8gdGhlIGNsaWVudCBhbmQgdGhlIHBhcmFtZXRlciBq dXN0IHByb3ZpZGVzIGluZm8gYWJvdXQgdGhlIHJldHVybmVkIHRva2VuLg0KPg0KPiBPbiBNb24s IEp1bCA2LCAyMDE1IGF0IDU6MzMgQU0sIFNlcmdleSBCZXJ5b3praW4gPHNiZXJ5b3praW5AZ21h aWwuY29tPG1haWx0bzpzYmVyeW96a2luQGdtYWlsLmNvbT4+IHdyb3RlOg0KPiBIaSBCcmlhbg0K Pg0KPiBJJ3ZlIHJlYWQgdGhlIHRleHQsIEkgbGlrZSBpdCBpcyBzdGlsbCBwdXJlIE9BdXRoMiwg d2l0aCBmZXcgZXh0cmEgcGFyYW1ldGVycyBhZGRlZCB0byB0aGUgYWNjZXNzIHRva2VuIHJlcXVl c3QsIGFuZCBhIGtleSByZXNwb25zZSBwcm9wZXJ0eSBiZWluZyAnYWNjZXNzX3Rva2VuJyBhcyBv cHBvc2VkIHRvICdzZWN1cml0eV9hY2Nlc3NfdG9rZW4nIGFzIGluIHRoZSBkcmFmdC1pZXRmLW9h dXRoLXRva2VuLWV4Y2hhbmdlLTAxLg0KPiBJdCBhcHBlYXJzIGRyYWZ0LWNhbXBiZWxsLW9hdXRo LXN0cy0wMSBjYW4gY292ZXIgYSBkcmFmdC1yaWNoZXItb2F1dGgtY2hhaW4tMDAgY2FzZSB3aXRo IHRoZSBvbl9iZWhhbGZfb2YgKGFuZC9vciBhY3RfYXMgPykgcHJvcGVydHkgYmVpbmcgYW4gb3Jp Z2luYWwgY2xpZW50IHRva2VuIGJ1dCBub3QgMTAwJSBzdXJlIGdpdmVuIGRyYWZ0LXJpY2hlci1v YXV0aC1jaGFpbi0wMCBjb3ZlcnMgYSBzcGVjaWZpYyBjYXNlLg0KPg0KPiBPbmUgdGhpbmcgSSdt IG5vdCBzdXJlIGFib3V0IGlzIHdoYXQgaXMgdGhlIHB1cnBvc2Ugb2Ygc3BlY2lmeWluZyBhDQo+ IHNlY3VyaXR5X3Rva2VuX3R5cGUgb2YgdGhlIHJldHVybmVkIGFjY2VzcyB0b2tlbg0KPg0KPiBU aGFua3MsIFNlcmdleQ0KPg0KPiBPbiAwMS8wNy8xNSAxNTo1OSwgQnJpYW4gQ2FtcGJlbGwgd3Jv dGU6DQo+IE9uZSBwcm9ibGVtLCBJIHRoaW5rLCB3aXRoIHRva2VuIGV4Y2hhbmdlIGlzIHRoYXQg aXQgY2FuIGJlIHJlYWxseQ0KPiBzaW1wbGUgKHRva2VuIGluIGFuZCB0b2tlbiBvdXQpIGFuZCBy ZWFsbHkgY29tcGxpY2F0ZWQgKGNsaWVudCBYIHdhbnRzDQo+IGEgdG9rZW4gdGhhdCBzYXlzIHVz ZXIgQSBpcyBkb2luZyBzb21ldGhpbmcgb24gYmVoYWxmIG9mIHVzZXIgQikgYXQNCj4gdGhlIHNh bWUgdGltZS4NCj4NCj4gSSBwdXQgZm9ydGggaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWNhbXBiZWxsLW9hdXRoLXN0cy0wMSBpbg0KPiBhbiBhdHRlbXB0IHRvIHNpbXBsaWZ5IHRo aW5ncyBhbmQgZXhwcmVzcyB3aGF0IEkgZW52aXNpb25lZCBhcyBhbg0KPiBPQXV0aCBiYXNlZCB0 b2tlbiBleGNoYW5nZSBmcmFtZXdvcmsuIFRob3VnaCBpdCBsaWtlbHkgb25seSBtdWRkaWVkDQo+ IHRoZSB3YXRlcnMgOikNCj4NCj4gT24gV2VkLCBKdWwgMSwgMjAxNSBhdCA3OjA3IEFNLCBTZXJn ZXkgQmVyeW96a2luIDxzYmVyeW96a2luQGdtYWlsLmNvbTxtYWlsdG86c2JlcnlvemtpbkBnbWFp bC5jb20+DQo+IDxtYWlsdG86c2JlcnlvemtpbkBnbWFpbC5jb208bWFpbHRvOnNiZXJ5b3praW5A Z21haWwuY29tPj4+IHdyb3RlOg0KPg0KPiAgICAgSGkgSnVzdGluDQo+DQo+ICAgICBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmljaGVyLW9hdXRoLWNoYWluLTAwIGlzIG11Y2gN Cj4gICAgIGVhc2llciB0byByZWFkLCB0aGF0IEkgY2FuIHRlbGwgZm9yIHN1cmUsIGF0IGxlYXN0 IGl0IGlzIG9idmlvdXMgd2h5DQo+ICAgICBhIGdpdmVuIGVudGl0eSAoUlMxKSBtYXkgd2FudCB0 byBleGNoYW5nZSB0aGUgY3VycmVudCB0b2tlbiBwcm92aWRlZA0KPiAgICAgYnkgYSBjbGllbnQg Zm9yIGEgbmV3IHRva2VuLiBEZWZpbml0ZWx5IGVhc2lseSBpbXBsZW1lbnRhYmxlLi4uDQo+DQo+ ICAgICBPbmUgdGhpbmcgSSdtIG5vdCBzdXJlIGluIHRoZSBkcmFmdC1yaWNoZXItb2F1dGgtY2hh aW4tMDAgYWJvdXQgaXMNCj4gICAgIG9uIGJlaGFsZiBvZiB3aG9zZSBlbnRpdHkgUlMxIHdpbGwg YmUgYWN0aW5nIG9uY2UgaXQgc3RhcnRzDQo+ICAgICBhY2Nlc3NpbmcgUlMyLCBPbiBCZWhhbGYg T2YgUk8sIG9yIG1heSBiZSBPbiBCZWhhbGYgT2YgKFJPICsNCj4gICAgIENsaWVudCksIG9yIG1h eSBiZSBpdCBpcyBPbiBCZWhhbGYgT2YgUk8gKyBBY3QgQXMgQ2xpZW50ID8gVGhlIGxhc3QNCj4g ICAgIG9uZSBzZWVtcyBtb3N0IGxvZ2ljYWwgdG8gbWUuLi4NCj4NCj4gICAgIFRoYW5rcywgU2Vy Z2V5DQo+DQo+DQo+ICAgICBPbiAwMS8wNy8xNSAxMzoxOCwgSnVzdGluIFJpY2hlciB3cm90ZToN Cj4NCj4gICAgICAgICBBcyBpdCdzIHdyaXR0ZW4gcmlnaHQgbm93LCBpdCdzIGEgdHJhbnNsYXRp b24gb2Ygc29tZSBXUy0qDQo+ICAgICAgICAgY29uY2VwdHMgaW50bw0KPiAgICAgICAgIEpXVCBm b3JtYXQuIEl0J3Mgbm90IHJlYWxseSBPQXV0aC15IChzaW5jZSB0aGUgY2xpZW50IGhhcyB0bw0K PiAgICAgICAgIHVuZGVyc3RhbmQNCj4gICAgICAgICB0aGUgdG9rZW4gZm9ybWF0IGFsb25nIHdp dGggZXZlcnlvbmUgZWxzZSwgYW5kIGFjY29yZGluZyB0byB0aGUNCj4gICAgICAgICBhdXRob3Jz DQo+ICAgICAgICAgdGhlIGFydGlmYWN0cyBtaWdodCBub3QgZXZlbiBiZSAiT0F1dGggdG9rZW5z IiksIGFuZCB0aGF0J3MgbXkgbWFpbg0KPiAgICAgICAgIGlzc3VlIHdpdGggdGhlIGRvY3VtZW50 LiBZZWFycyBhZ28sIEkgcHJvcG9zZWQgYW4gT0F1dGgtYmFzZWQNCj4gICAgICAgICB0b2tlbiBz d2FwDQo+ICAgICAgICAgbWVjaGFuaXNtOg0KPg0KPiAgICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1yaWNoZXItb2F1dGgtY2hhaW4tMDANCj4NCj4gICAgICAgICBUaGlz IHdvcmtzIHdpdGhvdXQgZGVmaW5pbmcgc2VtYW50aWNzIG9mIHRoZSB0b2tlbnMgdGhlbXNlbHZl cywganVzdA0KPiAgICAgICAgIGxpa2UgdGhlIHJlc3Qgb2YgT0F1dGguIEkndmUgcHJvcG9zZWQg dG8gdGhlIGF1dGhvcnMgb2YgdGhlIGN1cnJlbnQNCj4gICAgICAgICBkcmFmdCB0aGF0IGl0IHNo b3VsZCBpbmNvcnBvcmF0ZSBib3RoIHNlbWFudGljICh1c2luZyBKV1QpIGFuZA0KPiAgICAgICAg IHN5bnRhY3RpYw0KPiAgICAgICAgICh1c2luZyBhIHNpbXBsZSB0b2tlbi1hZ25vc3RpYyBncmFu dCkgdG9rZW4gc3dhcCBtZWNoYW5pc21zLCBhbmQNCj4gICAgICAgICB0aGF0DQo+ICAgICAgICAg dGhlIHR3byBjb3VsZCBiZSBlYXNpbHkgY29tcGF0aWJsZS4NCj4NCj4gICAgICAgICAgICAtLSBK dXN0aW4NCj4NCj4gICAgICAgICBPbiA3LzEvMjAxNSA2OjM1IEFNLCBTZXJnZXkgQmVyeW96a2lu IHdyb3RlOg0KPg0KPiAgICAgICAgICAgICBIbW0uLi4gcGVyaGFwcyB0aGUgY2x1ZSBpcyBpbiB0 aGUgZHJhZnQgdGl0bGUsDQo+ICAgICAgICAgICAgIHRva2VuLWV4Y2hhbmdlLCBzbyBtYXkNCj4g ICAgICAgICAgICAgYmUgaXQgaXMgYSBjYXNlIG9mIHRoZSBnaXZlbiBhY2Nlc3MgdG9rZW4gKCJv bl9iZWhhbGZfb2YiIG9yDQo+ICAgICAgICAgICAgICJhY3RfYXMiDQo+ICAgICAgICAgICAgIGNs YWltKSBiZWluZyB1c2VkIHRvIHJlcXVlc3QgYSBuZXcgc2VjdXJpdHkgdG9rZW4uIE9uZSBjYW4N Cj4gICAgICAgICAgICAgb25seSBndWVzcw0KPiAgICAgICAgICAgICB0aG91Z2gsIGRvZXMgbm90 IHNlZW0gbGlrZSB0aGUgYXV0aG9ycyBhcmUga2VlbiB0byBhbnN3ZXINCj4gICAgICAgICAgICAg dGhlIG5ld2JpZQ0KPiAgICAgICAgICAgICBxdWVzdGlvbnMuLi4NCj4NCj4gICAgICAgICAgICAg Q2hlZXJzLCBTZXJnZXkNCj4NCj4NCj4gICAgICAgICAgICAgT24gMzAvMDYvMTUgMTM6MzgsIFNl cmdleSBCZXJ5b3praW4gd3JvdGU6DQo+DQo+ICAgICAgICAgICAgICAgICBIaSwNCj4gICAgICAg ICAgICAgICAgIENhbiB5b3UgcGxlYXNlIGV4cGxhaW4gd2hhdCBpcyB0aGUgZGlmZmVyZW5jZSBi ZXR3ZWVuDQo+ICAgICAgICAgICAgICAgICBPbi1CZWhhbGYtT2YNCj4gICAgICAgICAgICAgICAg IHNlbWFudGljcyBkZXNjcmliZWQgaW4gdGhlDQo+ICAgICAgICAgICAgICAgICBkcmFmdC1pZXRm LW9hdXRoLXRva2VuLWV4Y2hhbmdlLTAxIGFuZCB0aGUNCj4gICAgICAgICAgICAgICAgIGltcGxp Y2l0IE9uLUJlaGFsZi1PZiBzZW1hbnRpY3MgYSBjbGllbnQgT0F1dGgyIHRva2VuDQo+ICAgICAg ICAgICAgICAgICBwb3NzZXNzZXMgPw0KPg0KPiAgICAgICAgICAgICAgICAgRm9yIGV4YW1wbGUs IGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMDEgbWVudGlvbnM6DQo+DQo+ICAgICAg ICAgICAgICAgICAiV2hlcmVhcywgd2l0aCBvbi1iZWhhbGYtb2Ygc2VtYW50aWNzLCBwcmluY2lw YWwgQSBzdGlsbA0KPiAgICAgICAgICAgICAgICAgaGFzIGl0cyBvd24NCj4gICAgICAgICAgICAg ICAgIGlkZW50aXR5IHNlcGFyYXRlIGZyb20gQiBhbmQgaXQgaXMgZXhwbGljaXRseSB1bmRlcnN0 b29kDQo+ICAgICAgICAgICAgICAgICB0aGF0IHdoaWxlIEINCj4gICAgICAgICAgICAgICAgIG1h eSBoYXZlIGRlbGVnYXRlZCBpdHMgcmlnaHRzIHRvIEEsIGFueSBhY3Rpb25zIHRha2VuDQo+ICAg ICAgICAgICAgICAgICBhcmUgYmVpbmcgdGFrZW4gYnkNCj4gICAgICAgICAgICAgICAgIEEgYW5k IG5vdCBCLiBJbiBhIHNlbnNlLCBBIGlzIGFuIGFnZW50IGZvciBCLiINCj4NCj4gICAgICAgICAg ICAgICAgIFRoaXMgaXMgYSB0eXBpY2FsIGNhc2Ugd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBjb2Rl IGZsb3cNCj4gICAgICAgICAgICAgICAgIHdoZXJlIGEgY2xpZW50DQo+ICAgICAgICAgICAgICAg ICBhcHBsaWNhdGlvbiBhY3RzIG9uLWJlaGFsZi1vZiB0aGUgdXNlciB3aG8gYXV0aG9yaXplZA0K PiAgICAgICAgICAgICAgICAgdGhpcyBhcHBsaWNhdGlvbiA/DQo+DQo+ICAgICAgICAgICAgICAg ICBTb3JyeSBpZiBJJ20gbWlzc2luZyBzb21ldGhpbmcNCj4NCj4gICAgICAgICAgICAgICAgIENo ZWVycywgU2VyZ2V5DQo+ICAgICAgICAgICAgICAgICBPbiAyNS8wNi8xNSAyMjoyOCwgTWlrZSBK b25lcyB3cm90ZToNCj4NCj4gICAgICAgICAgICAgICAgICAgICBUaGF04oCZcyB3aGF0DQo+ICAg ICAgICAgICAgICAgICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt b2F1dGgtdG9rZW4tZXhjaGFuZ2UtMDENCj4gICAgICAgICAgICAgICAgICAgICBpcw0KPiAgICAg ICAgICAgICAgICAgICAgIGFib3V0Lg0KPg0KPiAgICAgICAgICAgICAgICAgICAgIENoZWVycywN Cj4NCj4gICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQo+DQo+ICAgICAgICAgICAgICAgICAg ICAgKkZyb206Kk9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1 dGgtYm91bmNlc0BpZXRmLm9yZz4NCj4gICAgICAgICAgICAgICAgICAgICA8bWFpbHRvOm9hdXRo LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+Pl0gKk9uIEJl aGFsZiBPZiAqVml2ZWsNCj4gICAgICAgICAgICAgICAgICAgICBCaXN3YXMNCj4gICAgICAgICAg ICAgICAgICAgICAtVCAodmliaXN3YXMgLSBYT1JJQU5UIENPUlBPUkFUSU9OIGF0IENpc2NvKQ0K PiAgICAgICAgICAgICAgICAgICAgICpTZW50OiogVGh1cnNkYXksIEp1bmUgMjUsIDIwMTUgMjoy MCBQTQ0KPiAgICAgICAgICAgICAgICAgICAgICpUbzoqIE9BdXRoQGlldGYub3JnPG1haWx0bzpP QXV0aEBpZXRmLm9yZz4gPG1haWx0bzpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5v cmc+Pg0KPiAgICAgICAgICAgICAgICAgICAgICpTdWJqZWN0OiogW09BVVRILVdHXSBKV1QgVG9r ZW4gb24tYmVoYWxmIG9mIFVzZQ0KPiBjYXNlDQo+DQo+ICAgICAgICAgICAgICAgICAgICAgSGkg QWxsLA0KPg0KPiAgICAgICAgICAgICAgICAgICAgICAgICBJIGFtIGxvb2tpbmcgdG8gc29sdmUg YSB1c2UtY2FzZSBzaW1pbGFyIHRvDQo+ICAgICAgICAgICAgICAgICAgICAgV1MtU2VjdXJpdHkg T24tQmVoYWxmLU9mDQo+DQo+IDxodHRwOi8vZG9jcy5vYXNpcy1vcGVuLm9yZy93cy1zeC93cy10 cnVzdC92MS40L2VycmF0YTAxL29zL3dzLXRydXN0LTENCj4gLjQtZXJyYXRhMDEtb3MtY29tcGxl dGUuaHRtbCNfVG9jMzI1NjU4OTgwPg0KPg0KPg0KPiAgICAgICAgICAgICAgICAgICAgIHdpdGgg T0F1dGggSldUIFRva2VuLg0KPg0KPiAgICAgICAgICAgICAgICAgICAgICAgICBJcyB0aGVyZSBh IHN0YW5kYXJkIGNsYWltIHdoaWNoIHdlIGNhbiBkZWZpbmUNCj4gICAgICAgICAgICAgICAgICAg ICB3aXRoaW4gdGhlIE9BdXRoIEpXVA0KPiAgICAgICAgICAgICAgICAgICAgIHdoaWNoIGRlbm90 ZSB0aGUgT24tYmVoYWxmLW9mIFVzZXIuDQo+DQo+ICAgICAgICAgICAgICAgICAgICAgRm9yIGUu Zy4sIGEgQ3VzdG9tZXIgUmVwcmVzZW50YXRpdmUgdHJ5aW5nIHRvIGNyZWF0ZQ0KPiAgICAgICAg ICAgICAgICAgICAgIHRva2VuIG9uIGJlaGFsZiBvZg0KPiAgICAgICAgICAgICAgICAgICAgIGEg Y3VzdG9tZXIgYW5kIHRyeWluZyB0byBleGVjdXRlIHNlcnZpY2VzIHNwZWNpZmljDQo+ICAgICAg ICAgICAgICAgICAgICAgZm9yIHRoYXQgc3BlY2lmaWMNCj4gICAgICAgICAgICAgICAgICAgICBj dXN0b21lci4NCj4NCj4gICAgICAgICAgICAgICAgICAgICBSZWdhcmRzLA0KPg0KPiAgICAgICAg ICAgICAgICAgICAgIFZpdmVrIEJpc3dhcywNCj4gICAgICAgICAgICAgICAgICAgICBDSVNTUA0K Pg0KPiAgICAgICAgICAgICAgICAgICAgICpDaXNjbyBTeXN0ZW1zLCBJbmMgPGh0dHA6Ly93d3cu Y2lzY28uY29tLz4qDQo+DQo+ICAgICAgICAgICAgICAgICAgICAgKkJsZGcuIEosIFNhbiBKb3Nl LCBVU0EsKg0KPg0KPiAgICAgICAgICAgICAgICAgICAgICpQaG9uZTogKzEgNDA4IDUyNyA5MTc2 PHRlbDolMkIxJTIwNDA4JTIwNTI3JTIwOTE3Nj4NCj4gPHRlbDolMkIxJTIwNDA4JTIwNTI3JTIw OTE3Nj4qDQo+DQo+DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gICAgICAgICAgICAgICAgICAgICBPQXV0 aCBtYWlsaW5nIGxpc3QNCj4gICAgICAgICAgICAgICAgICAgICBPQXV0aEBpZXRmLm9yZzxtYWls dG86T0F1dGhAaWV0Zi5vcmc+IDxtYWlsdG86T0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGll dGYub3JnPj4NCj4gICAgICAgICAgICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoDQo+DQo+DQo+DQo+ICAgICAgICAgICAgIF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAgICAgICAgICAgIE9BdXRoIG1h aWxpbmcgbGlzdA0KPiAgICAgICAgICAgICBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0 Zi5vcmc+IDxtYWlsdG86T0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPj4NCj4g ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K Pg0KPg0KPiAgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ICAgICAgICAgT0F1dGggbWFpbGluZyBsaXN0DQo+ICAgICAgICAgT0F1dGhAaWV0 Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPiA8bWFpbHRvOk9BdXRoQGlldGYub3JnPG1haWx0 bzpPQXV0aEBpZXRmLm9yZz4+DQo+ICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aA0KPg0KPg0KPiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gICAgIE9BdXRoIG1haWxpbmcgbGlzdA0KPiAgICAgT0F1 dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPiA8bWFpbHRvOk9BdXRoQGlldGYub3Jn PG1haWx0bzpPQXV0aEBpZXRmLm9yZz4+DQo+ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoDQo+DQo+DQo+DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiBPQXV0 aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFp bHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aA0KDQoNCg== --_000_CY1PR0301MB124389773FAD2B4983C0A480A6930CY1PR0301MB1243_ 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 dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XaGF0IGlzIHdy aXR0ZW4gaW4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LW9hdXRoLXRva2VuLWV4Y2hhbmdlLTAxI3NlY3Rpb24tMS4zIj4NCmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTAxI3NlY3Rpb24tMS4z PC9hPiBhbmQgdGhlIHRleHQgdGhhdCBkZXNjcmliZXMgdGhlIFdpbmRvd3MgS2VyYmVyb3Mgc3Vw cG9ydCBmb3INCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UHJvdG9jb2wg VHJhbnNpdGlvbjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+IGFuZCBDb25z dHJhaW5lZCBEZWxlZ2F0aW9uIGFyZSBpbiBhbGlnbm1lbnQgbm90IHN1cmUgd2hhdCBtYWtlIHlv dQ0KIHRoaW5rIHRoZXkgYXJlIG5vdC4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5JZiB5b3UgYXJlIHRyeWluZyB0byBkZXNjcmliZSBkaWZmZXJlbnQgZmVhdHVy ZXMgdGhhbiBXaW5kb3dzIEtlcmJlcm9zDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPlByb3RvY29sIFRyYW5zaXRpb248L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPi9Db25zdHJhaW5lZCBEZWxlZ2F0aW9uIHRoYXQgdGhlbiBJIHdvdWxkIGFncmVlIHRo YXQgdGhlIHRleHQgbWF5IG5vdA0KIGJlIGNvcnJlY3QgYnV0IHRoZW4gYWdhaW4gaXQgd291bGQg bm90IGJlIGRlc2NyaWJpbmcgdGhlIFdpbmRvd3MgS2VyYmVyb3MgPC9zcGFuPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlByb3RvY29sIFRyYW5zaXRpb248L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPi9Db25zdHJhaW5lZCBEZWxlZ2F0aW9uLiBUaGUgd2F5IHlv dSBoYXZlIHRoZSB0ZXh0IGRlc2NyaWJlcyBkaWZmZXJlbnQgc2V0DQogdXNlIGNhc2UgdGhlbiB3 aGF0IHRoZSBmZWF0dXJlIG9mICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTAxI3NlY3Rpb24tMS4zIj5odHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZS0w MSNzZWN0aW9uLTEuMzwvYT4gZGVzY3JpYmVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiBCcmlhbiBDYW1wYmVsbCBbbWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHku Y29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgSnVseSA2LCAyMDE1IDI6MzMgUE08YnI+ DQo8Yj5Ubzo8L2I+IEFudGhvbnkgTmFkYWxpbiAmbHQ7dG9ueW5hZEBtaWNyb3NvZnQuY29tJmd0 Ozxicj4NCjxiPkNjOjwvYj4gTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tJmd0Ozsgb2F1dGggJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW09BVVRILVdHXSBKV1QgVG9rZW4gb24tYmVoYWxmIG9mIFVzZSBjYXNlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgbmF0dXJhbCB1c2FnZSBvZiBh Y3QtYXMgb3IgPGEgaHJlZj0iaHR0cDovL3d3dy5veGZvcmRkaWN0aW9uYXJpZXMuY29tL3VzL2Rl ZmluaXRpb24vYW1lcmljYW5fZW5nbGlzaC9pbXBlcnNvbmF0ZSIgdGFyZ2V0PSJfYmxhbmsiPg0K aW1wZXJzb25hdGlvbjwvYT4gd291bGQgc3VnZ2VzdCwgdG8gbWFueSBwZW9wbGUgYW55d2F5LCB0 aGF0IHRoZSB3YXkgeW91IGp1c3QgdXNlZCB0aGUgdGVybXMgaXMgcmV2ZXJzZWQuIFRoZSBib2xk IHRleHQgYmVsb3cgZnJvbQ0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMDEjc2VjdGlvbi0xLjMiIHRhcmdldD0iX2Js YW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXRva2Vu LWV4Y2hhbmdlLTAxI3NlY3Rpb24tMS4zPC9hPiB1c2VzICdpbXBlcnNvbmF0ZXMnIGFuZCAmcXVv dDtvbi1iZWhhbGYtb2YmcXVvdDsgY29udHJhcnkgdG8gd2hhdCB5b3UganVzdCB3cm90ZSBhYm91 dCBXaW5kb3dzIEtlcmIuIFRoYXQncyB3aGVyZSB0aGUgYXNzZXJ0aW9uIHRoYXQgdGhlIGRyYWZ0 IGhhcyB0aGVtIHJldmVyc2VkIGZyb20gZGUgZmFjdG8gdXNhZ2UgaW4gV1MtVHJ1c3QuDQogVGhv c2Ugc2VtYW50aWNzIGFyZSBub3Qgb25seSBvbmUgb3BlbiBpc3N1ZSB0aGF0IG5lZWRzIHRvIGJl IHJlc29sdmVkLCBob3dldmVyLCBldmVuIGlmIHRoZXkgb2NjdXB5IG1vc3Qgb2YgdGhlIGRpc2N1 c3Npb24uJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzAuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEuMy4mbmJzcDsgT24tQmVoYWxmLU9mIHZz LiBJbXBlcnNvbmF0aW9uIFNlbWFudGljczxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyBXaGVuIHBy aW5jaXBhbCBBIGFjdHMgb24gYmVoYWxmIG9mIHByaW5jaXBhbCBCLCBBIGlzIGdpdmVuIGFsbCB0 aGU8YnI+DQombmJzcDsmbmJzcDsgcmlnaHRzIHRoYXQgQiBoYXMgd2l0aGluIHNvbWUgZGVmaW5l ZCByaWdodHMgY29udGV4dC4mbmJzcDsgV2hlcmVhcywgPGI+d2l0aDwvYj48YnI+DQo8Yj4mbmJz cDsmbmJzcDsgb24tYmVoYWxmLW9mIHNlbWFudGljcywgcHJpbmNpcGFsIEEgc3RpbGwgaGFzIGl0 cyBvd24gaWRlbnRpdHk8L2I+PGJyPg0KPGI+Jm5ic3A7Jm5ic3A7IHNlcGFyYXRlIGZyb20gQiBh bmQgaXQgaXMgZXhwbGljaXRseSB1bmRlcnN0b29kIHRoYXQgd2hpbGUgQiBtYXkgaGF2ZTwvYj48 YnI+DQo8Yj4mbmJzcDsmbmJzcDsgZGVsZWdhdGVkIGl0cyByaWdodHMgdG8gQSwgYW55IGFjdGlv bnMgdGFrZW4gYXJlIGJlaW5nIHRha2VuIGJ5IEEgYW5kPC9iPjxicj4NCjxiPiZuYnNwOyZuYnNw OyBub3QgQi4gSW4gYSBzZW5zZSwgQSBpcyBhbiBhZ2VudCBmb3IgQi48L2I+PGJyPg0KPGJyPg0K Jm5ic3A7Jm5ic3A7IE9uLWJlaGFsZi1vZiBzZW1hbnRpY3MgYXJlIHRoZXJlZm9yZSBkaWZmZXJl bnQgdGhhbiBpbXBlcnNvbmF0aW9uPGJyPg0KJm5ic3A7Jm5ic3A7IHNlbWFudGljcywgd2l0aCB3 aGljaCBpdCBpcyBzb21ldGltZXMgY29uZnVzZWQuJm5ic3A7IDxiPldoZW4gcHJpbmNpcGFsIEE8 L2I+PGJyPg0KPGI+Jm5ic3A7Jm5ic3A7IGltcGVyc29uYXRlcyBwcmluY2lwYWwgQiwgdGhlbiBp biBzbyBmYXIgYXMgYW55IGVudGl0eSByZWNlaXZpbmc8L2I+PGJyPg0KPGI+Jm5ic3A7Jm5ic3A7 IENsYWltcyBpcyBjb25jZXJuZWQsIHRoZXkgYXJlIGFjdHVhbGx5IGRlYWxpbmcgd2l0aCBCLiA8 L2I+SXQgaXMgdHJ1ZTxicj4NCiZuYnNwOyZuYnNwOyB0aGF0IHNvbWUgbWVtYmVycyBvZiB0aGUg aWRlbnRpdHkgc3lzdGVtIG1pZ2h0IGhhdmUgYXdhcmVuZXNzIHRoYXQ8YnI+DQombmJzcDsmbmJz cDsgaW1wZXJzb25hdGlvbiBpcyBnb2luZyBvbiBidXQgaXQgaXMgbm90IGEgcmVxdWlyZW1lbnQu Jm5ic3A7IEZvciBhbGw8YnI+DQombmJzcDsmbmJzcDsgaW50ZW50cyBhbmQgcHVycG9zZXMsIHdo ZW4gQSBpcyBhY3RpbmcgZm9yIEIsIEEgaXMgQi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEp1bCA2LCAyMDE1IGF0IDI6NDMg UE0sIEFudGhvbnkgTmFkYWxpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0 LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRvbnluYWRAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIFdTLVRydXN0IOKA nEFjdEFz4oCdIG1pbWljcyB0aGUgV2luZG93cyBLZXJiZXJvcyBQcm90b2NvbCBUcmFuc2l0aW9u IChpbXBlcnNvbmF0aW9uKSAmbmJzcDtmZWF0dXJlIGFzIHRoaXMNCiBlbmFibGVzIGFuIGFjY291 bnQgdG8gaW1wZXJzb25hdGUgYW5vdGhlciBhY2NvdW50IGZvciB0aGUgcHVycG9zZSBvZiBwcm92 aWRpbmcgYWNjZXNzIHRvIHJlc291cmNlcy4gSW4gYSB0eXBpY2FsIHNjZW5hcmlvLCB0aGUgaW1w ZXJzb25hdGluZyBhY2NvdW50IHdvdWxkIGJlIGEgc2VydmljZSBhY2NvdW50IGFzc2lnbmVkIHRv IGEgd2ViIGFwcGxpY2F0aW9uIG9yIHRoZSBjb21wdXRlciBhY2NvdW50IG9mIGEgd2ViIHNlcnZl ci4gVGhlIGltcGVyc29uYXRlZA0KIGFjY291bnQgd291bGQgYmUgYSB1c2VyIGFjY291bnQgcmVx dWlyaW5nIGFjY2VzcyB0byByZXNvdXJjZXMgKGUuZy4gZGF0YSBpbiBhbiBTUUwgZGF0YWJhc2Up IHZpYSBhIHdlYiBhcHBsaWNhdGlvbi4gSW4gdGhpcyBzY2VuYXJpbywgU1FMIHNlcnZlciB3b3Vs ZCBiZSBhY2Nlc3NlZCBieSB0aGUgaW1wZXJzb25hdGluZyAoc2VydmljZSBhY2NvdW50KSBhY2Nv dW50LCBob3dldmVyIGFjY2VzcyB3b3VsZCBiZSB1bmRlciB0aGUgY29udGV4dCBvZg0KIHRoZSBp bXBlcnNvbmF0ZWQgKHVzZXIpIGFjY291bnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+V1MtVHJ1c3Qg4oCcT25CZWhhbGZPZuKAnSAmbmJzcDttaW1pY3Mg dGhlIFdpbmRvd3MgS2VyYmVyb3MgQ29uc3RyYWluZWQgRGVsZWdhdGlvbiBmZWF0dXJlLCB3aGlj aCBsZXRzIHlvdSBsaW1pdA0KIHRoZSBiYWNrLWVuZCBzZXJ2aWNlcyBmb3Igd2hpY2ggYSBmcm9u dC1lbmQgc2VydmljZSBjYW4gcmVxdWVzdCB0aWNrZXRzIG9uIGJlaGFsZiBvZiBhbm90aGVyIHVz ZXIuIOKAnE9uQmVoYWxmT2bigJ0gJm5ic3A7YWxsb3dzIGEgc2VsZWN0ZWQgc2VydmljZXMgb24g YSBzZXJ2ZXIgY2FuIGJlIGdyYW50ZWQgZm9yIGFjY2VzcyBieSB0aGUgaW1wZXJzb25hdGluZyBh Y2NvdW50LCB3aGlsc3Qgb3RoZXIgc2VydmljZXMgb24gdGhlIHNhbWUgc2VydmVyLCBvciBzZXJ2 aWNlcw0KIG9uIG90aGVyIHNlcnZlcnMgYXJlIGRlbmllZCBmb3IgYWNjZXNzLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk1heWJlIHNvbWVvbmUgY2FuIHN1 bW1hcml6ZSB3aHkgdGhleSB0aGluayB0aGUgdGV4dCBmb3IgQWN0QXMgYW5kIE9uQmVoYWxmT2Yg aW4gV1MtVHJ1c3Qgb3IgV2luZG93cw0KIEtlcmJlcm9zIGlzIHdyb25nIG9yIHN3YXBwZWQgYXMg SSBoYXZlIG5vdCBzZWVuIGEgY2xlYXIgZXhwbGFuYXRpb24gb3RoZXIgdGhhbiBKb2huIHNheWlu ZyB0aGF0IEJyaWFuIGtub3dzIGFuZCBCcmlhbiBzYXlpbmcgSm9obiBrbm93cy4NCjwvc3Bhbj48 YSBuYW1lPSIxNGU2NTFjNDBlMWI1MjRmX19NYWlsRW5kQ29tcG9zZSI+PC9hPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+T3VyIHVzYWdlIGFuZCB1c2UgY2FzZXMgYXJl IGJhc2VkIHVwb24gdGhlIGRlcGxveWVkIHNlcnZpY2VzIG9mIFdTLVRydXN0IGFuZCBLZXJiZXJv cyBzdXBwb3J0IGluIFdpbmRvd3MNCiAod29ya3N0YXRpb24gYW5kIHNlcnZlcikgYW5kIFhib3gu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiBPQXV0aCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2Vz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPkJyaWFuIENhbXBiZWxsPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRh eSwgSnVseSA2LCAyMDE1IDExOjI5IEFNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVzICZsdDs8 YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFu ayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IG9h dXRoICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5v YXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1X R10gSldUIFRva2VuIG9uLWJlaGFsZiBvZiBVc2UgY2FzZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQi PlN0YXRpbmcgc3BlY2lmaWMgYWN0aW9uIGl0ZW1zIHJlc3VsdGluZyBmcm9tIHRoZSBhZC1ob2Mg bWVldGluZyBpbiBEYWxsYXMgbGlrZSB0aGF0IHN1Z2dlc3RzIHNvbWUgY2xlYXIgY29uc2Vuc3Vz IHdhcyByZWFjaGVkLCB3aGljaCBpcyBub3QgYXQgYWxsIHRoZSBjYXNlLiBBcyBJIHJlY2FsbCwg c2V2ZXJhbCBvZiB1cw0KIGFyZ3VlZCBwYXN0IG9uZSBhbm90aGVyIGZvciBhbiBob3VyIG9yIHNv IGFuZCBkZWNpZGVkIHRvIGFkam91cm4gaW4gb3JkZXIgdG8gZ28gdG8gdGhlIGJhciAob2theSwg YW5kIGRpbm5lciB0b28gLSBidXQgbW9zdGx5IGJlZXIpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFy Z2luLWJvdHRvbToxMi4wcHQiPlRoZSBpbXByZXNzaW9uIGFib3V0IHJldmVyc2FsIG9mIHRlcm1z LCBJIHRoaW5rLCBjb21lcyBmcm9tIHRoZSB0ZXh0IGluDQo8YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZS0wMSNzZWN0aW9u LTEuMyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMDEjc2VjdGlvbi0xLjM8L2E+IHdoaWNoIGh1cnRz IG15IGhlYWQgYSBsaXR0bGUgZXZlcnktdGltZSBJIHJlYWQgaXQgYnV0IGRvZXMgc2VlbXMgdG8g Y29uZnVzZSB0aGluZ3MuIFRoZQ0KPGEgaHJlZj0iaHR0cHM6Ly9tc2RuLm1pY3Jvc29mdC5jb20v ZW4tdXMvbGlicmFyeS9lZTc0ODQ4Ny5hc3B4IiB0YXJnZXQ9Il9ibGFuayI+DQpNU0ROIGxpbms8 L2E+IEpvaG4gZ2F2ZSBpcyBtdWNoIG1vcmUgdG8gdGhlIHBvaW50IHRoYW4gV1MtVHJ1c3QgKEkg ZG9uJ3QgYmVsaWV2ZSBXUy1UcnVzdCBjYW4gYmUgcG9pbnRlZCB0byBhcyBhIG1vZGVsIG9mIGNs YXJpdHkpLiZuYnNwOyBJbiB0aGUgZHJhZnQgSSB3cm90ZSwgSSB0cmllZCB0byB0YWtlIE1pa2Un cyB0ZXh0IGFuZCBjbGFyaWZ5IGEgZGlzdGluY3Rpb24gYmV0d2VlbiBpbXBlcnNvbmF0aW9uIGFu ZCBkZWxlZ2F0aW9uIHdpdGgNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1jYW1wYmVsbC1vYXV0aC1zdHMtMDEjc2VjdGlvbi0xLjMiIHRhcmdldD0iX2JsYW5rIj4N Cmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW1wYmVsbC1vYXV0aC1zdHMtMDEj c2VjdGlvbi0xLjM8L2E+IGFuZCB0aGVuIGFsc28gYmUgdmVyeSBleHBsaWNpdCBhYm91dCBhY3Qt YXMgdnMuIG9uLWJlaGFsZi1vZiBpbiB0aGUgcGFyYW1ldGVyIGRlZmluaXRpb25zIGF0DQo8YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2FtcGJlbGwtb2F1dGgtc3Rz LTAxI3NlY3Rpb24tMiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWNhbXBiZWxsLW9hdXRoLXN0cy0wMSNzZWN0aW9uLTI8L2E+IGluIGEgbWFub3Ig dGhhdCB3YXMgY29uc2lzdGVudCB3aXRoIFdTLVRydXN0IGFuZCB0aGUgTVNETiBleHBsYW5hdGlv bi4gSSBjb3VsZCBzZWUgdmFsdWUgaW4gYnJlYWtpbmcgd2l0aCB0aGF0IHNoYWt5IGxlZ2FjeSBh bmQgdXNpbmcgbmV3IHRlcm1zIHRvby4gQnV0IEkgZ2V0IHRoZSBwb2ludCBvZiB0cnlpbmcgdG8g a2VlcA0KIHdpdGggdGhlIG9sZCBhbHNvIGFuZCBwb3RlbnRpYWwgZm9yIGV2ZW4gbW9yZSBjb25m dXNpbmcgYnkgdXNpbmcgbmV3IHRlcm1zLiA8bzpwPg0KPC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJv dHRvbToxMi4wcHQiPkkgd3JvdGUgZHJhZnQtY2FtcGJlbGwtb2F1dGgtc3RzIGxhc3QgeWVhciBp biByZXNwb25zZSB0byB0aGUgY2FsbCBmb3IgYWRvcHRpb24gb2Ygam9uZXMtb2F1dGgtdG9rZW4t ZXhjaGFuZ2UgKDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv b2F1dGgvY3VycmVudC9tc2cxMzMwNS5odG1sIiB0YXJnZXQ9Il9ibGFuayI+dGhyZWFkDQogZnJv bSB0aGUgYXJjaGl2ZTwvYT4pLiBUaG91Z2ggSSBkaWRuJ3QgdHJ5IGFuZCBzdGFuZCBpbiB0aGUg d2F5IGFuZCBpbmRpY2F0ZWQgYSB3aWxsaW5nbmVzcyB0byBjb2xsYWJvcmF0ZSBvbiB0aGluZ3Mu IFdpdGggdGhlIGV4cGVjdGF0aW9uLCBvZiBjb3Vyc2UsIHRoYXQgdGhlIGRldGFpbHMgd291bGQg ZGlmZmVyIGZyb20gdGhlIC0wMHMgYW5kIC0wMXMgYXMgd29yayBwcm9ncmVzc2VkLiBGb2xrcyBz ZWVtZWQNCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1 dGgvY3VycmVudC9tc2cxMzMwOC5odG1sIiB0YXJnZXQ9Il9ibGFuayI+DQpnZW5lcmFsbHkgYW1l bmFibGUgdG8gdGhhdDwvYT4gYXQgdGhlIHRpbWUgYnV0IGxpdHRsZSBoYXMgaGFwcGVuZWQgc2lu Y2UgdGhlbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+UGhpbCdzIGVhcmxpZXIgcG9pbnQgYWJvdXQgdGhlIHByaW9yeSBvZiB0aGlzIGdldHRp bmcgcHVzaGVkIGRvd24gaGFzIHNvbWUgdHJ1dGggdG8gaXQuIEJ1dCBJIHN0aWxsIGJlbGlldmUg aXQncyBzb21ldGhpbmcgdGhhdCBjYW4gcHJvdmlkZSBhIGxvdCBvZiB2YWx1ZSBpbiBzdGFuZGFy ZGl6aW5nLCBpZiB3ZQ0KIGRvIHNvIGluIGEgcmVhc29uYWJsZSB3YXkuIDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4t Ym90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gTW9uLCBKdWwgNiwgMjAx NSBhdCAxMDozMyBBTSwgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdo dDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkl0IHdv dWxkIHN1cnByaXNlIG1lIGlmIG9uLWJlaGFsZi1vZiBhbmQgYWN0LWFzIHdlcmUgcmV2ZXJzZWQg d2l0aCByZXNwZWN0IFdTLVRydXN0LCBiZWNhdXNlIHRoZSBleHBsYW5hdGlvbnMgb2YgdGhlIHRl cm1zIGNhbWUgZGlyZWN0bHkgZnJvbSBXUy1UcnVzdCAxLjQuJm5ic3A7IEkgYWxzbyB0aGluayB0 aGUgY2hhbmNlcw0KIG9mIHVzIHJlZHVjaW5nIGNvbmZ1c2lvbiBieSBpbnZlbnRpbmcgbmV3IHRl cm1pbm9sb2d5LCByYXRoZXIgdGhhbiBhZGRpbmcgdG8gaXQsIHdvdWxkIG5vdCBiZSBpbiBvdXIg ZmF2b3IuIDotLzxicj4NCjxicj4NCkZZSSwgdGhlIGFjdGlvbiBpdGVtcyBvdXRzdGFuZGluZyBm cm9tIG91ciBhZC1ob2MgbWVldGluZyBvbiB0aGlzIGRyYWZ0IGluIERhbGxhcyBhcmU6PGJyPg0K Jm5ic3A7IC0gQWxsb3dpbmcgc2VjdXJpdHkgdHlwZXMgb3RoZXIgdGhhbiBKV1QgdG8gYWxzbyBi ZSB1c2VkIGFzIHRoZSBhY3RfYXMgYW5kIG9uX2JlaGFsZl9vZiByZXF1ZXN0IHZhbHVlcy48YnI+ DQombmJzcDsgLSBGdXJ0aGVyIGludGVncmF0aW5nIHRoZSBtZWNoYW5pc20gaW50byB0aGUgZXhp c3RpbmcgT0F1dGggZWNvc3lzdGVtIC0gYWxsb3dpbmcgdXNlIG9mIGFjY2VzcyB0b2tlbnMgb3Ig cmVmcmVzaCB0b2tlbnMgd2hlbiBhcHByb3ByaWF0ZS48YnI+DQo8YnI+DQpJIHBsYW4gdG8gZG8g dGhlIGZpcnN0IHRvZGF5LiZuYnNwOyBUaGUgc2Vjb25kIGlzIHByb2JhYmx5IG1vcmUgdGhhbiBJ J2xsIGdldCBkb25lIHRvZGF5IGJlZm9yZSB0aGUgc3VibWlzc2lvbiBjdXRvZmYuJm5ic3A7IEkg YWdyZWUgd2l0aCBKb2huIHRoYXQgaXQgd291bGQgYmUgdXNlZnVsIHRvIGhhdmUgZGlzY3Vzc2lv bnMgb24gdGhpcyBpbiBQcmFndWUgb24gdGhlIGJlc3Qgd2F5IHRvIGFjaGlldmUgdGhpcyBmdXJ0 aGVyIGludGVncmF0aW9uLiZuYnNwOyBJJ2xsIHBsYW4NCiB0byBjb21lIGludG8gdGhlIFByYWd1 ZSBtZWV0aW5nIHdpdGggYSBjb25jcmV0ZSBwcm9wb3NhbCBmb3IgcmV2aWV3Ljxicj4NCjxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBC ZXN0IHdpc2hlcyw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0K RnJvbTogT0F1dGggW21haWx0bzo8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYg T2YgSm9obiBCcmFkbGV5PGJyPg0KU2VudDogTW9uZGF5LCBKdWx5IDA2LCAyMDE1IDg6MTMgQU08 YnI+DQpUbzogQnJpYW4gQ2FtcGJlbGw8YnI+DQpDYzogb2F1dGg8YnI+DQpTdWJqZWN0OiBSZTog W09BVVRILVdHXSBKV1QgVG9rZW4gb24tYmVoYWxmIG9mIFVzZSBjYXNlPGJyPg0KPGJyPg0KWWVz IHVuZm9ydHVuYXRlbHkgd2UgaGF2ZW7igJl0IG1hZGUgYW55IHByb2dyZXNzIG9uIHRoaXMgc2lu Y2UgYWNjZXB0aW5nIE1pa2XigJlzIGZpcnN0IGRyYWZ0Ljxicj4NCjxicj4NCkhpcyBwcm9wb3Nh bCBpcyBiYXNpY2FsbHkgZm9yIGEgbmV3IGVuZHBvaW50IHdoaWxlIEJyaWFuIHRpcmVkIHRvIGZp dCBpdCBpbnRvIHRoZSBleGlzdGluZyB0b2tlbiBlbmRwb2ludC48YnI+DQo8YnI+DQpJIHRoaW5r IGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMDEgc3RpbGwgaGFzIE9uQmVoYWxmT2Yg YW5kIEFjdEFzIHJldmVyc2VkIGNvbXBhcmVkIHRvIFdTLVRydXN0IDEuNC48YnI+DQpzZWUgPGEg aHJlZj0iaHR0cHM6Ly9tc2RuLm1pY3Jvc29mdC5jb20vZW4tdXMvbGlicmFyeS9lZTc0ODQ4Ny5h c3B4IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL21zZG4ubWljcm9zb2Z0LmNvbS9lbi11cy9s aWJyYXJ5L2VlNzQ4NDg3LmFzcHg8L2E+IGZvciB0aGUgc2hvcnQgZXhwbGFuYXRpb24uPGJyPg0K PGJyPg0KSSB0aGluayBCcmlhbiBpcyBjbG9zZXIgaW4gZXhwbGFpbmluZyBpdC48YnI+DQo8YnI+ DQpJbiBmYWlybmVzcyBiZWNhdXNlIFdTLVRydXN0IG9yaWdpbmFsbHkgb25seSBoYWQgT24tQmVo YWxmLU9mIHRoZSBuYW1pbmcgYW5kIHdoYXQgcGVvcGxlIHB1dCBpbiB0b2tlbnMgaXMgYSBiaXQg bXVkZGxlZCBpbiBtYW55IGltcGxlbWVudGF0aW9ucy48YnI+DQpJIHRoaW5rIG1hbnkgdGltZXMg aXQgaXMgaG93IFdJRiBpbXBsZW1lbnRlZCBpdCB0aGF0IHBlb3BsZSBjb3BpZWQuPGJyPg0KPGJy Pg0KSXQgbWF5IGJlIGJldHRlciB0byBoYXZlIG5ldyB0ZXJtcyB0aGF0IGFyZSBjbGVhciBzdWNo IGFzIGltcGVyc29uYXRpb24gYW5kIGNvbXBvc2l0ZS48YnI+DQo8YnI+DQpUaGUgV0cgbmVlZHMg dG8gZGVjaWRlIGlmIHRoaXMgaXMgZ29pbmcgdG8gYmUgYW4gZW50aXJlbHkgbmV3IGVuZHBvaW50 LCBmcmVlIG9mIHRoZSBUb2tlbiBlbmRwb2ludCBzZW1hbnRpY3MuJm5ic3A7ICZuYnNwO1RoZXJl IGFyZSBwbHVzc2VzIGFuZCBtaW51c2VzIHRvIGJvdGggb3B0aW9ucy48YnI+DQo8YnI+DQpBbHNv IHdoaWxlIGl0IGlzIG5pY2UgdG8gYmUgcHVyZSBhbmQgdGFsayBhYm91dCBhYnN0cmFjdCBzZWN1 cml0eSB0b2tlbnMsIGl0IHdvdWxkIGJlIGdvb2QgdG8gZ2l2ZSBzb21lIGd1aWRhbmNlIG9uIHdo YXQgYSBjb21wb3NpdGUgc2VjdXJpdHkgdG9rZW4gd291bGQgbG9vayBsaWtlIGZvciBpbnRlcm9w ZXJhYmlsaXR5Ljxicj4NCjxicj4NClRoZXJlIGFyZSBhbHNvIGlzc3VlcyBhcm91bmQgaG93IHRo aXMgd291bGQgd29yayB3aXRoIHByb29mIG9mIHBvc3Nlc3Npb24gc2VjdXJpdHkgdG9rZW5zLCBi b3RoIGFzIGlucHV0IGFuZCBvdXRwdXQuPGJyPg0KPGJyPg0KUGVyaGFwcyB3ZSBjYW4gbWFrZSBz b21lIHByb2dyZXNzIG9uIHRoaXMgaW4gUHJhZ3VlLjxicj4NCjxicj4NCkpvaG4gQi48YnI+DQo8 YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQomZ3Q7IE9uIEp1bCA2LCAyMDE1LCBhdCAxMTowNCBBTSwg QnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5 LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDsg d3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhhbmtzIFNlcmdleSw8YnI+DQomZ3Q7PGJyPg0K Jmd0OyBUaGUgZ29hbCBvZiBkcmFmdC1jYW1wYmVsbC1vYXV0aC1zdHMgd2FzIHRvIGJlIGNvbnNp c3RlbnQgd2l0aCBPQXV0aCAyLjAgYW5kIHRodXMgaG9wZWZ1bGx5IGZhbWlsaWFyIHRvIGRldmVs b3BlcnMgYW5kIGVhc3kgdG8gdW5kZXJzdGFuZCBhbmQgaW1wbGVtZW50IChlc3BlY2lhbGx5IGZy b20gdGhlIGNsaWVudCBzaWRlKS4gSXQncyBhbHNvIGludGVuZGVkIHRvIGJlIGZsZXhpYmxlIGlu IG9yZGVyIHRvIGFjY29tbW9kYXRlIGEgdmFyaWV0eQ0KIG9mIHVzZS1jYXNlcyBpbmNsdWRpbmcg dGhlIGNoYWluaW5nIHR5cGUgY2FzZXMgdGhhdCBKdXN0aW4ncyBkcmFmdCBjb3ZlcnMuPGJyPg0K Jmd0Ozxicj4NCiZndDsgU3BlY2lmeWluZyBhIHNlY3VyaXR5X3Rva2VuX3R5cGUgb2YgdGhlIHJl dHVybmVkIHRva2VuIGlzIGp1c3QgYSB3YXkgb2YgcHJvdmlkaW5nIG1vcmUgaW5mbyB0byB0aGUg Y2xpZW50IGFib3V0IHRoZSB0b2tlbiAoaS5lLiBpcyB0aGlzIGEgSldUIG9yIGEgU0FNTCB0b2tl biBvciBzb21ldGhpbmcgZWxzZSkgdmlhIGEgVVJJLiBJdCdzIG5vdCBhbHdheXMgbmVlZGVkIGJ1 dCBpbiBTVFMgc3R5bGUgY2FzZXMgdGhlIHRva2VucyBhcmUgbm90IGFsd2F5cw0KIG9wYXF1ZSB0 byB0aGUgY2xpZW50IGFuZCB0aGUgcGFyYW1ldGVyIGp1c3QgcHJvdmlkZXMgaW5mbyBhYm91dCB0 aGUgcmV0dXJuZWQgdG9rZW4uPGJyPg0KJmd0Ozxicj4NCiZndDsgT24gTW9uLCBKdWwgNiwgMjAx NSBhdCA1OjMzIEFNLCBTZXJnZXkgQmVyeW96a2luICZsdDs8YSBocmVmPSJtYWlsdG86c2Jlcnlv emtpbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5zYmVyeW96a2luQGdtYWlsLmNvbTwvYT4m Z3Q7IHdyb3RlOjxicj4NCiZndDsgSGkgQnJpYW48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJJ3ZlIHJl YWQgdGhlIHRleHQsIEkgbGlrZSBpdCBpcyBzdGlsbCBwdXJlIE9BdXRoMiwgd2l0aCBmZXcgZXh0 cmEgcGFyYW1ldGVycyBhZGRlZCB0byB0aGUgYWNjZXNzIHRva2VuIHJlcXVlc3QsIGFuZCBhIGtl eSByZXNwb25zZSBwcm9wZXJ0eSBiZWluZyAnYWNjZXNzX3Rva2VuJyBhcyBvcHBvc2VkIHRvICdz ZWN1cml0eV9hY2Nlc3NfdG9rZW4nIGFzIGluIHRoZSBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4 Y2hhbmdlLTAxLjxicj4NCiZndDsgSXQgYXBwZWFycyBkcmFmdC1jYW1wYmVsbC1vYXV0aC1zdHMt MDEgY2FuIGNvdmVyIGEgZHJhZnQtcmljaGVyLW9hdXRoLWNoYWluLTAwIGNhc2Ugd2l0aCB0aGUg b25fYmVoYWxmX29mIChhbmQvb3IgYWN0X2FzID8pIHByb3BlcnR5IGJlaW5nIGFuIG9yaWdpbmFs IGNsaWVudCB0b2tlbiBidXQgbm90IDEwMCUgc3VyZSBnaXZlbiBkcmFmdC1yaWNoZXItb2F1dGgt Y2hhaW4tMDAgY292ZXJzIGEgc3BlY2lmaWMgY2FzZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbmUg dGhpbmcgSSdtIG5vdCBzdXJlIGFib3V0IGlzIHdoYXQgaXMgdGhlIHB1cnBvc2Ugb2Ygc3BlY2lm eWluZyBhPGJyPg0KJmd0OyBzZWN1cml0eV90b2tlbl90eXBlIG9mIHRoZSByZXR1cm5lZCBhY2Nl c3MgdG9rZW48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGFua3MsIFNlcmdleTxicj4NCiZndDs8YnI+ DQomZ3Q7IE9uIDAxLzA3LzE1IDE1OjU5LCBCcmlhbiBDYW1wYmVsbCB3cm90ZTo8YnI+DQomZ3Q7 IE9uZSBwcm9ibGVtLCBJIHRoaW5rLCB3aXRoIHRva2VuIGV4Y2hhbmdlIGlzIHRoYXQgaXQgY2Fu IGJlIHJlYWxseTxicj4NCiZndDsgc2ltcGxlICh0b2tlbiBpbiBhbmQgdG9rZW4gb3V0KSBhbmQg cmVhbGx5IGNvbXBsaWNhdGVkIChjbGllbnQgWCB3YW50czxicj4NCiZndDsgYSB0b2tlbiB0aGF0 IHNheXMgdXNlciBBIGlzIGRvaW5nIHNvbWV0aGluZyBvbiBiZWhhbGYgb2YgdXNlciBCKSBhdDxi cj4NCiZndDsgdGhlIHNhbWUgdGltZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIHB1dCBmb3J0aCA8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2FtcGJlbGwtb2F1dGgt c3RzLTAxIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtY2FtcGJlbGwtb2F1dGgtc3RzLTAxPC9hPiBpbjxicj4NCiZndDsgYW4gYXR0ZW1wdCB0byBz aW1wbGlmeSB0aGluZ3MgYW5kIGV4cHJlc3Mgd2hhdCBJIGVudmlzaW9uZWQgYXMgYW48YnI+DQom Z3Q7IE9BdXRoIGJhc2VkIHRva2VuIGV4Y2hhbmdlIGZyYW1ld29yay4gVGhvdWdoIGl0IGxpa2Vs eSBvbmx5IG11ZGRpZWQ8YnI+DQomZ3Q7IHRoZSB3YXRlcnMgOik8YnI+DQomZ3Q7PGJyPg0KJmd0 OyBPbiBXZWQsIEp1bCAxLCAyMDE1IGF0IDc6MDcgQU0sIFNlcmdleSBCZXJ5b3praW4gJmx0Ozxh IGhyZWY9Im1haWx0bzpzYmVyeW96a2luQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNiZXJ5 b3praW5AZ21haWwuY29tPC9hPjxicj4NCiZndDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86 c2JlcnlvemtpbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5zYmVyeW96a2luQGdtYWlsLmNv bTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7SGkgSnVzdGluPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yaWNoZXItb2F1dGgtY2hhaW4t MDAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmlj aGVyLW9hdXRoLWNoYWluLTAwPC9hPiBpcyBtdWNoPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ZWFzaWVyIHRvIHJlYWQsIHRoYXQgSSBjYW4gdGVsbCBmb3Igc3VyZSwgYXQgbGVhc3QgaXQg aXMgb2J2aW91cyB3aHk8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDthIGdpdmVuIGVudGl0 eSAoUlMxKSBtYXkgd2FudCB0byBleGNoYW5nZSB0aGUgY3VycmVudCB0b2tlbiBwcm92aWRlZDxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2J5IGEgY2xpZW50IGZvciBhIG5ldyB0b2tlbi4g RGVmaW5pdGVseSBlYXNpbHkgaW1wbGVtZW50YWJsZS4uLjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDtPbmUgdGhpbmcgSSdtIG5vdCBzdXJlIGluIHRoZSBkcmFmdC1yaWNo ZXItb2F1dGgtY2hhaW4tMDAgYWJvdXQgaXM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtv biBiZWhhbGYgb2Ygd2hvc2UgZW50aXR5IFJTMSB3aWxsIGJlIGFjdGluZyBvbmNlIGl0IHN0YXJ0 czxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2FjY2Vzc2luZyBSUzIsIE9uIEJlaGFsZiBP ZiBSTywgb3IgbWF5IGJlIE9uIEJlaGFsZiBPZiAoUk8gJiM0Mzs8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDtDbGllbnQpLCBvciBtYXkgYmUgaXQgaXMgT24gQmVoYWxmIE9mIFJPICYjNDM7 IEFjdCBBcyBDbGllbnQgPyBUaGUgbGFzdDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO29u ZSBzZWVtcyBtb3N0IGxvZ2ljYWwgdG8gbWUuLi48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7VGhhbmtzLCBTZXJnZXk8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwO09uIDAxLzA3LzE1IDEzOjE4LCBKdXN0aW4gUmljaGVyIHdyb3Rl Ojxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0Fz IGl0J3Mgd3JpdHRlbiByaWdodCBub3csIGl0J3MgYSB0cmFuc2xhdGlvbiBvZiBzb21lIFdTLSo8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2NvbmNlcHRzIGludG88 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0pXVCBmb3JtYXQuIEl0 J3Mgbm90IHJlYWxseSBPQXV0aC15IChzaW5jZSB0aGUgY2xpZW50IGhhcyB0bzxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dW5kZXJzdGFuZDxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dGhlIHRva2VuIGZvcm1hdCBhbG9uZyB3aXRo IGV2ZXJ5b25lIGVsc2UsIGFuZCBhY2NvcmRpbmcgdG8gdGhlPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthdXRob3JzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDt0aGUgYXJ0aWZhY3RzIG1pZ2h0IG5vdCBldmVuIGJlICZxdW90O09B dXRoIHRva2VucyZxdW90OyksIGFuZCB0aGF0J3MgbXkgbWFpbjxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aXNzdWUgd2l0aCB0aGUgZG9jdW1lbnQuIFllYXJzIGFn bywgSSBwcm9wb3NlZCBhbiBPQXV0aC1iYXNlZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7dG9rZW4gc3dhcDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7bWVjaGFuaXNtOjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1yaWNoZXItb2F1dGgtY2hhaW4tMDAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtcmljaGVyLW9hdXRoLWNoYWluLTAwPC9hPjxicj4NCiZndDs8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RoaXMgd29ya3Mgd2l0 aG91dCBkZWZpbmluZyBzZW1hbnRpY3Mgb2YgdGhlIHRva2VucyB0aGVtc2VsdmVzLCBqdXN0PGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtsaWtlIHRoZSByZXN0IG9m IE9BdXRoLiBJJ3ZlIHByb3Bvc2VkIHRvIHRoZSBhdXRob3JzIG9mIHRoZSBjdXJyZW50PGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdCB0aGF0IGl0IHNob3Vs ZCBpbmNvcnBvcmF0ZSBib3RoIHNlbWFudGljICh1c2luZyBKV1QpIGFuZDxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3ludGFjdGljPGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsodXNpbmcgYSBzaW1wbGUgdG9rZW4tYWdub3N0aWMg Z3JhbnQpIHRva2VuIHN3YXAgbWVjaGFuaXNtcywgYW5kPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDt0aGF0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDt0aGUgdHdvIGNvdWxkIGJlIGVhc2lseSBjb21wYXRpYmxlLjxicj4NCiZndDs8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLS0gSnVz dGluPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 T24gNy8xLzIwMTUgNjozNSBBTSwgU2VyZ2V5IEJlcnlvemtpbiB3cm90ZTo8YnI+DQomZ3Q7PGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0ht bS4uLiBwZXJoYXBzIHRoZSBjbHVlIGlzIGluIHRoZSBkcmFmdCB0aXRsZSw8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dG9rZW4tZXhjaGFu Z2UsIHNvIG1heTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtiZSBpdCBpcyBhIGNhc2Ugb2YgdGhlIGdpdmVuIGFjY2VzcyB0b2tlbiAoJnF1 b3Q7b25fYmVoYWxmX29mJnF1b3Q7IG9yPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O2FjdF9hcyZxdW90Ozxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjbGFpbSkgYmVpbmcg dXNlZCB0byByZXF1ZXN0IGEgbmV3IHNlY3VyaXR5IHRva2VuLiBPbmUgY2FuPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO29ubHkgZ3Vlc3M8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 dGhvdWdoLCBkb2VzIG5vdCBzZWVtIGxpa2UgdGhlIGF1dGhvcnMgYXJlIGtlZW4gdG8gYW5zd2Vy PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O3RoZSBuZXdiaWU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7cXVlc3Rpb25zLi4uPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtDaGVlcnMsIFNlcmdleTxicj4NCiZn dDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO09uIDMwLzA2LzE1IDEzOjM4LCBTZXJnZXkgQmVyeW96a2luIHdyb3RlOjxi cj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtIaSw8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtDYW4geW91IHBsZWFzZSBl eHBsYWluIHdoYXQgaXMgdGhlIGRpZmZlcmVuY2UgYmV0d2Vlbjxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO09uLUJl aGFsZi1PZjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3NlbWFudGljcyBkZXNjcmliZWQgaW4gdGhlPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZS0wMSBhbmQgdGhlPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7aW1wbGljaXQgT24tQmVoYWxmLU9mIHNlbWFudGljcyBhIGNsaWVudCBPQXV0aDIgdG9r ZW48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtwb3NzZXNzZXMgPzxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtGb3Ig ZXhhbXBsZSwgZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZS0wMSBtZW50aW9uczo8YnI+ DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7V2hlcmVhcywgd2l0aCBvbi1iZWhhbGYtb2Ygc2Vt YW50aWNzLCBwcmluY2lwYWwgQSBzdGlsbDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2hhcyBpdHMgb3duPGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7aWRlbnRpdHkgc2VwYXJhdGUgZnJvbSBCIGFuZCBpdCBpcyBleHBsaWNpdGx5IHVu ZGVyc3Rvb2Q8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0aGF0IHdoaWxlIEI8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDttYXkgaGF2 ZSBkZWxlZ2F0ZWQgaXRzIHJpZ2h0cyB0byBBLCBhbnkgYWN0aW9ucyB0YWtlbjxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO2FyZSBiZWluZyB0YWtlbiBieTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0EgYW5kIG5vdCBCLiBJbiBhIHNl bnNlLCBBIGlzIGFuIGFnZW50IGZvciBCLiZxdW90Ozxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtU aGlzIGlzIGEgdHlwaWNhbCBjYXNlIHdpdGggdGhlIGF1dGhvcml6YXRpb24gY29kZSBmbG93PGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7d2hlcmUgYSBjbGllbnQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthcHBsaWNhdGlvbiBhY3Rz IG9uLWJlaGFsZi1vZiB0aGUgdXNlciB3aG8gYXV0aG9yaXplZDxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3RoaXMg YXBwbGljYXRpb24gPzxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtTb3JyeSBpZiBJJ20gbWlzc2lu ZyBzb21ldGhpbmc8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Q2hlZXJzLCBTZXJnZXk8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtPbiAyNS8wNi8xNSAyMjoyOCwgTWlrZSBKb25lcyB3cm90ZTo8YnI+DQomZ3Q7PGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGF04oCZcyB3aGF0PGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1vYXV0aC10b2tlbi1leGNoYW5nZS0wMSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTAxPC9hPjxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aXM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Fi b3V0Ljxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0NoZWVycyw8YnI+DQom Z3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDstLSBNaWtlPGJyPg0KJmd0Ozxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7KkZyb206Kk9BdXRoIFttYWlsdG86PGEgaHJlZj0ibWFpbHRv Om9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGll dGYub3JnPC9hPjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O21haWx0bzo8YSBocmVm PSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoLWJv dW5jZXNAaWV0Zi5vcmc8L2E+Jmd0O10gKk9uIEJlaGFsZiBPZiAqVml2ZWs8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO0Jpc3dhczxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7LVQgKHZp Ymlzd2FzIC0gWE9SSUFOVCBDT1JQT1JBVElPTiBhdCBDaXNjbyk8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOypTZW50OiogVGh1cnNkYXksIEp1bmUgMjUsIDIwMTUgMjoyMCBQTTxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7KlRvOiogPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0i bWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7KlN1YmplY3Q6KiBbT0FVVEgtV0ddIEpX VCBUb2tlbiBvbi1iZWhhbGYgb2YgVXNlPGJyPg0KJmd0OyBjYXNlPGJyPg0KJmd0Ozxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7SGkgQWxsLDxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SSBhbSBsb29raW5nIHRvIHNvbHZlIGEgdXNlLWNhc2Ug c2ltaWxhciB0bzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7V1MtU2VjdXJpdHkgT24tQmVo YWxmLU9mPGJyPg0KJmd0Ozxicj4NCiZndDsgJmx0OzxhIGhyZWY9Imh0dHA6Ly9kb2NzLm9hc2lz LW9wZW4ub3JnL3dzLXN4L3dzLXRydXN0L3YxLjQvZXJyYXRhMDEvb3Mvd3MtdHJ1c3QtMSIgdGFy Z2V0PSJfYmxhbmsiPmh0dHA6Ly9kb2NzLm9hc2lzLW9wZW4ub3JnL3dzLXN4L3dzLXRydXN0L3Yx LjQvZXJyYXRhMDEvb3Mvd3MtdHJ1c3QtMTwvYT48YnI+DQomZ3Q7IC40LWVycmF0YTAxLW9zLWNv bXBsZXRlLmh0bWwjX1RvYzMyNTY1ODk4MCZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7d2l0aCBPQXV0aCBKV1QgVG9rZW4uPGJyPg0KJmd0Ozxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJcyB0aGVyZSBhIHN0YW5kYXJk IGNsYWltIHdoaWNoIHdlIGNhbiBkZWZpbmU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3dp dGhpbiB0aGUgT0F1dGggSldUPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt3aGljaCBkZW5v dGUgdGhlIE9uLWJlaGFsZi1vZiBVc2VyLjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO0ZvciBlLmcuLCBhIEN1c3RvbWVyIFJlcHJlc2VudGF0aXZlIHRyeWluZyB0byBjcmVh dGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Rva2VuIG9uIGJlaGFsZiBvZjxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7YSBjdXN0b21lciBhbmQgdHJ5aW5nIHRvIGV4ZWN1dGUgc2Vy dmljZXMgc3BlY2lmaWM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2ZvciB0aGF0IHNwZWNp ZmljPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjdXN0b21lci48YnI+DQomZ3Q7PGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtSZWdhcmRzLDxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO1ZpdmVrIEJpc3dhcyw8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0NJ U1NQPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7KkNpc2NvIFN5c3RlbXMs IEluYyAmbHQ7PGEgaHJlZj0iaHR0cDovL3d3dy5jaXNjby5jb20vIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cDovL3d3dy5jaXNjby5jb20vPC9hPiZndDsqPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7KkJsZGcuIEosIFNhbiBKb3NlLCBVU0EsKjxicj4NCiZndDs8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOypQaG9uZTogPGEgaHJlZj0idGVsOiUyQjElMjA0MDglMjA1Mjcl MjA5MTc2IiB0YXJnZXQ9Il9ibGFuayI+DQomIzQzOzEgNDA4IDUyNyA5MTc2PC9hPjxicj4NCiZn dDsgJmx0OzxhIGhyZWY9InRlbDolMkIxJTIwNDA4JTIwNTI3JTIwOTE3NiIgdGFyZ2V0PSJfYmxh bmsiPnRlbDolMkIxJTIwNDA4JTIwNTI3JTIwOTE3NjwvYT4mZ3Q7Kjxicj4NCiZndDs8YnI+DQom Z3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO09BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJl Zj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8 L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8 L2E+PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO09BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJtYWls dG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT4gJmx0 O21haWx0bzo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5P QXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7T0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5PQXV0aEBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86T0F1dGhA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0 Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7T0F1dGgg bWFpbGluZyBsaXN0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0ibWFpbHRv Ok9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+ICZsdDtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1 dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4N CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsg T0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4N Cjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_CY1PR0301MB124389773FAD2B4983C0A480A6930CY1PR0301MB1243_-- From nobody Mon Jul 6 14:59:45 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F20D1A1F70 for ; Mon, 6 Jul 2015 14:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gK-JpGzxY02X for ; Mon, 6 Jul 2015 14:59:36 -0700 (PDT) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7BE21A1A56 for ; Mon, 6 Jul 2015 14:59:35 -0700 (PDT) Received: by iebmu5 with SMTP id mu5so122356676ieb.1 for ; Mon, 06 Jul 2015 14:59:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=vbjm1r4zU8T48zgdsCdgKyJM4Ztq8ZXxOtgHR2SQrzo=; b=ThPkwOX21YFhw/kUcWU38qezK8OFjHNqzeGmjt8D2HtSz1KVuILBz4bCaxLPLX+DI6 FmiDUQ/W4i3KkrH9wiOxqHge/KAsgg5kUwTc25OtZsA77YIm+qndzMl1w4E34Qtuk0r5 xkMjLc9vGxmwJQ0ToFaLD+NjjKKryFwjNsXoZidvmwK2rbzZAo6RWc3BiUEOElacT1LI C0vsFIQuaL4VDtV+2Ir+dgboU2PtyXTHsw8kysFrtpyUph2f3hTRJyZmkBe6/uC3vz/o jTMh+YZ79QR/xSQta/JD7cziu8kX8Tx4/+4ekWjEamiDeoK+RfaEL4HBSbE60GOQRFxG daXg== X-Gm-Message-State: ALoCoQlFX8kj3ArSNfQm1l1nZEzCw5+XiNnSYpG+jgFxhbztbOXdNSqO2o6Un1fKIiU0DQvl9AtA X-Received: by 10.43.19.131 with SMTP id qk3mr38776794icb.15.1436219975254; Mon, 06 Jul 2015 14:59:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.64.209 with HTTP; Mon, 6 Jul 2015 14:59:05 -0700 (PDT) In-Reply-To: References: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> <55928DB3.7090300@gmail.com> <5593C270.7000008@gmail.com> <5593DA7D.80401@mit.edu> <5593E5FD.3050403@gmail.com> <559A676F.3070008@gmail.com> From: Brian Campbell Date: Mon, 6 Jul 2015 15:59:05 -0600 Message-ID: To: Anthony Nadalin Content-Type: multipart/alternative; boundary=bcaec517cddc71dfb9051a3c05bf Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 21:59:42 -0000 --bcaec517cddc71dfb9051a3c05bf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That doesn't even make sense. On Mon, Jul 6, 2015 at 3:56 PM, Anthony Nadalin wrote: > What is written in > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.= 3 > and the text that describes the Windows Kerberos support for Protocol > Transition and Constrained Delegation are in alignment not sure what make > you think they are not. > > > > If you are trying to describe different features than Windows Kerberos Pr= otocol > Transition/Constrained Delegation that then I would agree that the text > may not be correct but then again it would not be describing the Windows > Kerberos Protocol Transition/Constrained Delegation. The way you have the > text describes different set use case then what the feature of > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.= 3 > describes. > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Monday, July 6, 2015 2:33 PM > *To:* Anthony Nadalin > *Cc:* Mike Jones ; oauth > > *Subject:* Re: [OAUTH-WG] JWT Token on-behalf of Use case > > > > A natural usage of act-as or impersonation > > would suggest, to many people anyway, that the way you just used the term= s > is reversed. The bold text below from > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.= 3 > uses 'impersonates' and "on-behalf-of" contrary to what you just wrote > about Windows Kerb. That's where the assertion that the draft has them > reversed from de facto usage in WS-Trust. Those semantics are not only on= e > open issue that needs to be resolved, however, even if they occupy most o= f > the discussion. > > > > 1.3. On-Behalf-Of vs. Impersonation Semantics > > When principal A acts on behalf of principal B, A is given all the > rights that B has within some defined rights context. Whereas, *with* > * on-behalf-of semantics, principal A still has its own identity* > * separate from B and it is explicitly understood that while B may have= * > * delegated its rights to A, any actions taken are being taken by A and= * > * not B. In a sense, A is an agent for B.* > > On-behalf-of semantics are therefore different than impersonation > semantics, with which it is sometimes confused. *When principal A* > * impersonates principal B, then in so far as any entity receiving* > * Claims is concerned, they are actually dealing with B. *It is true > that some members of the identity system might have awareness that > impersonation is going on but it is not a requirement. For all > intents and purposes, when A is acting for B, A is B. > > > > > > > > > > > > On Mon, Jul 6, 2015 at 2:43 PM, Anthony Nadalin > wrote: > > The WS-Trust =E2=80=9CActAs=E2=80=9D mimics the Windows Kerberos Protoco= l Transition > (impersonation) feature as this enables an account to impersonate anothe= r > account for the purpose of providing access to resources. In a typical > scenario, the impersonating account would be a service account assigned t= o > a web application or the computer account of a web server. The impersonat= ed > account would be a user account requiring access to resources (e.g. data = in > an SQL database) via a web application. In this scenario, SQL server woul= d > be accessed by the impersonating (service account) account, however acces= s > would be under the context of the impersonated (user) account. > > > > WS-Trust =E2=80=9COnBehalfOf=E2=80=9D mimics the Windows Kerberos Constr= ained Delegation > feature, which lets you limit the back-end services for which a front-end > service can request tickets on behalf of another user. =E2=80=9COnBehalfO= f=E2=80=9D allows > a selected services on a server can be granted for access by the > impersonating account, whilst other services on the same server, or > services on other servers are denied for access. > > > > Maybe someone can summarize why they think the text for ActAs and > OnBehalfOf in WS-Trust or Windows Kerberos is wrong or swapped as I have > not seen a clear explanation other than John saying that Brian knows and > Brian saying John knows. > > > > Our usage and use cases are based upon the deployed services of WS-Trust > and Kerberos support in Windows (workstation and server) and Xbox. > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian > Campbell > *Sent:* Monday, July 6, 2015 11:29 AM > *To:* Mike Jones > *Cc:* oauth > > > *Subject:* Re: [OAUTH-WG] JWT Token on-behalf of Use case > > > > Stating specific action items resulting from the ad-hoc meeting in Dallas > like that suggests some clear consensus was reached, which is not at all > the case. As I recall, several of us argued past one another for an hour = or > so and decided to adjourn in order to go to the bar (okay, and dinner too= - > but mostly beer). > > The impression about reversal of terms, I think, comes from the text in > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.= 3 > which hurts my head a little every-time I read it but does seems to confu= se > things. The MSDN link > John gave is > much more to the point than WS-Trust (I don't believe WS-Trust can be > pointed to as a model of clarity). In the draft I wrote, I tried to take > Mike's text and clarify a distinction between impersonation and delegatio= n > with https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 > and then also be very explicit about act-as vs. on-behalf-of in the > parameter definitions at > https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in a > manor that was consistent with WS-Trust and the MSDN explanation. I could > see value in breaking with that shaky legacy and using new terms too. But= I > get the point of trying to keep with the old also and potential for even > more confusing by using new terms. > > I wrote draft-campbell-oauth-sts last year in response to the call for > adoption of jones-oauth-token-exchange (thread from the archive > ). > Though I didn't try and stand in the way and indicated a willingness to > collaborate on things. With the expectation, of course, that the details > would differ from the -00s and -01s as work progressed. Folks seemed gene= rally > amenable to that > at > the time but little has happened since then. > > Phil's earlier point about the priory of this getting pushed down has som= e > truth to it. But I still believe it's something that can provide a lot of > value in standardizing, if we do so in a reasonable way. > > > > > > > > > > On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones > wrote: > > It would surprise me if on-behalf-of and act-as were reversed with respec= t > WS-Trust, because the explanations of the terms came directly from WS-Tru= st > 1.4. I also think the chances of us reducing confusion by inventing new > terminology, rather than adding to it, would not be in our favor. :-/ > > FYI, the action items outstanding from our ad-hoc meeting on this draft i= n > Dallas are: > - Allowing security types other than JWT to also be used as the act_as > and on_behalf_of request values. > - Further integrating the mechanism into the existing OAuth ecosystem - > allowing use of access tokens or refresh tokens when appropriate. > > I plan to do the first today. The second is probably more than I'll get > done today before the submission cutoff. I agree with John that it would > be useful to have discussions on this in Prague on the best way to achiev= e > this further integration. I'll plan to come into the Prague meeting with= a > concrete proposal for review. > > Best wishes, > -- Mike > > > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley > Sent: Monday, July 06, 2015 8:13 AM > To: Brian Campbell > Cc: oauth > Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case > > Yes unfortunately we haven=E2=80=99t made any progress on this since acce= pting > Mike=E2=80=99s first draft. > > His proposal is basically for a new endpoint while Brian tired to fit it > into the existing token endpoint. > > I think draft-ietf-oauth-token-exchange-01 still has OnBehalfOf and ActAs > reversed compared to WS-Trust 1.4. > see https://msdn.microsoft.com/en-us/library/ee748487.aspx for the short > explanation. > > I think Brian is closer in explaining it. > > In fairness because WS-Trust originally only had On-Behalf-Of the naming > and what people put in tokens is a bit muddled in many implementations. > I think many times it is how WIF implemented it that people copied. > > It may be better to have new terms that are clear such as impersonation > and composite. > > The WG needs to decide if this is going to be an entirely new endpoint, > free of the Token endpoint semantics. There are plusses and minuses to > both options. > > Also while it is nice to be pure and talk about abstract security tokens, > it would be good to give some guidance on what a composite security token > would look like for interoperability. > > There are also issues around how this would work with proof of possession > security tokens, both as input and output. > > Perhaps we can make some progress on this in Prague. > > John B. > > > > > > On Jul 6, 2015, at 11:04 AM, Brian Campbell > wrote: > > > > Thanks Sergey, > > > > The goal of draft-campbell-oauth-sts was to be consistent with OAuth 2.= 0 > and thus hopefully familiar to developers and easy to understand and > implement (especially from the client side). It's also intended to be > flexible in order to accommodate a variety of use-cases including the > chaining type cases that Justin's draft covers. > > > > Specifying a security_token_type of the returned token is just a way of > providing more info to the client about the token (i.e. is this a JWT or = a > SAML token or something else) via a URI. It's not always needed but in ST= S > style cases the tokens are not always opaque to the client and the > parameter just provides info about the returned token. > > > > On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin > wrote: > > Hi Brian > > > > I've read the text, I like it is still pure OAuth2, with few extra > parameters added to the access token request, and a key response property > being 'access_token' as opposed to 'security_access_token' as in the > draft-ietf-oauth-token-exchange-01. > > It appears draft-campbell-oauth-sts-01 can cover a > draft-richer-oauth-chain-00 case with the on_behalf_of (and/or act_as ?) > property being an original client token but not 100% sure given > draft-richer-oauth-chain-00 covers a specific case. > > > > One thing I'm not sure about is what is the purpose of specifying a > > security_token_type of the returned access token > > > > Thanks, Sergey > > > > On 01/07/15 15:59, Brian Campbell wrote: > > One problem, I think, with token exchange is that it can be really > > simple (token in and token out) and really complicated (client X wants > > a token that says user A is doing something on behalf of user B) at > > the same time. > > > > I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in > > an attempt to simplify things and express what I envisioned as an > > OAuth based token exchange framework. Though it likely only muddied > > the waters :) > > > > On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin > > wrote: > > > > Hi Justin > > > > https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much > > easier to read, that I can tell for sure, at least it is obvious wh= y > > a given entity (RS1) may want to exchange the current token provide= d > > by a client for a new token. Definitely easily implementable... > > > > One thing I'm not sure in the draft-richer-oauth-chain-00 about is > > on behalf of whose entity RS1 will be acting once it starts > > accessing RS2, On Behalf Of RO, or may be On Behalf Of (RO + > > Client), or may be it is On Behalf Of RO + Act As Client ? The last > > one seems most logical to me... > > > > Thanks, Sergey > > > > > > On 01/07/15 13:18, Justin Richer wrote: > > > > As it's written right now, it's a translation of some WS-* > > concepts into > > JWT format. It's not really OAuth-y (since the client has to > > understand > > the token format along with everyone else, and according to the > > authors > > the artifacts might not even be "OAuth tokens"), and that's my > main > > issue with the document. Years ago, I proposed an OAuth-based > > token swap > > mechanism: > > > > https://tools.ietf.org/html/draft-richer-oauth-chain-00 > > > > This works without defining semantics of the tokens themselves, > just > > like the rest of OAuth. I've proposed to the authors of the > current > > draft that it should incorporate both semantic (using JWT) and > > syntactic > > (using a simple token-agnostic grant) token swap mechanisms, an= d > > that > > the two could be easily compatible. > > > > -- Justin > > > > On 7/1/2015 6:35 AM, Sergey Beryozkin wrote: > > > > Hmm... perhaps the clue is in the draft title, > > token-exchange, so may > > be it is a case of the given access token ("on_behalf_of" o= r > > "act_as" > > claim) being used to request a new security token. One can > > only guess > > though, does not seem like the authors are keen to answer > > the newbie > > questions... > > > > Cheers, Sergey > > > > > > On 30/06/15 13:38, Sergey Beryozkin wrote: > > > > Hi, > > Can you please explain what is the difference between > > On-Behalf-Of > > semantics described in the > > draft-ietf-oauth-token-exchange-01 and the > > implicit On-Behalf-Of semantics a client OAuth2 token > > possesses ? > > > > For example, draft-ietf-oauth-token-exchange-01 mention= s: > > > > "Whereas, with on-behalf-of semantics, principal A stil= l > > has its own > > identity separate from B and it is explicitly understoo= d > > that while B > > may have delegated its rights to A, any actions taken > > are being taken by > > A and not B. In a sense, A is an agent for B." > > > > This is a typical case with the authorization code flow > > where a client > > application acts on-behalf-of the user who authorized > > this application ? > > > > Sorry if I'm missing something > > > > Cheers, Sergey > > On 25/06/15 22:28, Mike Jones wrote: > > > > That=E2=80=99s what > > > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 > > is > > about. > > > > Cheers, > > > > -- Mike > > > > *From:*OAuth [mailto:oauth-bounces@ietf.org > > ] *On Behalf Of > *Vivek > > Biswas > > -T (vibiswas - XORIANT CORPORATION at Cisco) > > *Sent:* Thursday, June 25, 2015 2:20 PM > > *To:* OAuth@ietf.org > > *Subject:* [OAUTH-WG] JWT Token on-behalf of Use > > case > > > > Hi All, > > > > I am looking to solve a use-case similar to > > WS-Security On-Behalf-Of > > > > > .4-errata01-os-complete.html#_Toc325658980> > > > > > > with OAuth JWT Token. > > > > Is there a standard claim which we can define > > within the OAuth JWT > > which denote the On-behalf-of User. > > > > For e.g., a Customer Representative trying to creat= e > > token on behalf of > > a customer and trying to execute services specific > > for that specific > > customer. > > > > Regards, > > > > Vivek Biswas, > > CISSP > > > > *Cisco Systems, Inc * > > > > *Bldg. J, San Jose, USA,* > > > > *Phone: +1 408 527 9176 > > >* > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@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 > > > > > --bcaec517cddc71dfb9051a3c05bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That doesn't even make sense.

On Mon, Jul 6, 2015 at 3:56 PM,= Anthony Nadalin <tonynad@microsoft.com> wrote:

What is written in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3<= /a> and the text that describes the Windows Kerberos support for Protocol Transition and Constra= ined Delegation are in alignment not sure what make you think they are not.

=C2=A0

If you are trying to describe differe= nt features than Windows Kerberos Protocol Transition/Constrained= Delegation that then I would agree that the text may not be correct but then again it would not be describing the Windows Kerberos = Protocol Transition/Constrained Delega= tion. The way you have the text describes different set use case then what the feature of =C2=A0http= s://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 = describes.

=C2=A0

From: Brian Campbell [mailto:bcampbell@pingiden= tity.com]
Sent: Monday, July 6, 2015 2:33 PM
To: Anthony Nadalin <tonynad@microsoft.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>; oauth <oauth@ietf.org>


Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case

=C2=A0

=C2=A0

1.3.=C2=A0 On-Behalf-Of vs. Impersonation Semantics<= br>
=C2=A0=C2=A0 When principal A acts on behalf of principal B, A is given all= the
=C2=A0=C2=A0 rights that B has within some defined rights context.=C2=A0 Wh= ereas, with
=C2=A0=C2=A0 on-behalf-of semantics, principal A still has its own ident= ity
=C2=A0=C2=A0 separate from B and it is explicitly understood that while = B may have
=C2=A0=C2=A0 delegated its rights to A, any actions taken are being take= n by A and
=C2=A0=C2=A0 not B. In a sense, A is an agent for B.

=C2=A0=C2=A0 On-behalf-of semantics are therefore different than impersonat= ion
=C2=A0=C2=A0 semantics, with which it is sometimes confused.=C2=A0 When = principal A
=C2=A0=C2=A0 impersonates principal B, then in so far as any entity rece= iving
=C2=A0=C2=A0 Claims is concerned, they are actually dealing with B. = It is true
=C2=A0=C2=A0 that some members of the identity system might have awareness = that
=C2=A0=C2=A0 impersonation is going on but it is not a requirement.=C2=A0 F= or all
=C2=A0=C2=A0 intents and purposes, when A is acting for B, A is B.

=C2=A0

=C2=A0<= /p>

=C2=A0

=C2=A0<= /p>

=C2=A0

On Mon, Jul 6, 2015 at 2:43 PM, Anthony Nadalin <= tonynad@microsof= t.com> wrote:

The WS-Trust =E2=80=9CActAs=E2=80=9D = mimics the Windows Kerberos Protocol Transition (impersonation) =C2=A0featu= re as this enables an account to impersonate another account for the purpose of provi= ding access to resources. In a typical scenario, the impersonating account = would be a service account assigned to a web application or the computer ac= count of a web server. The impersonated account would be a user account requiring access to resources (e.g. data i= n an SQL database) via a web application. In this scenario, SQL server woul= d be accessed by the impersonating (service account) account, however acces= s would be under the context of the impersonated (user) account.

=C2=A0

WS-Trust =E2=80=9COnBehalfOf=E2=80=9D= =C2=A0mimics the Windows Kerberos Constrained Delegation feature, which le= ts you limit the back-end services for which a front-end service can request tickets on= behalf of another user. =E2=80=9COnBehalfOf=E2=80=9D =C2=A0allows a select= ed services on a server can be granted for access by the impersonating acco= unt, whilst other services on the same server, or services on other servers are denied for access.

=C2=A0

Maybe someone can summarize why they = think the text for ActAs and OnBehalfOf in WS-Trust or Windows Kerberos is wrong or swapped as I have not seen a clear explanation other = than John saying that Brian knows and Brian saying John knows.

=C2=A0

Our usage and use cases are based upo= n the deployed services of WS-Trust and Kerberos support in Windows (workstation and server) and Xbox.

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Monday, July 6, 2015 11:29 AM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: oauth <oa= uth@ietf.org>


Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case

=C2=A0

Stating specific acti= on items resulting from the ad-hoc meeting in Dallas like that suggests som= e clear consensus was reached, which is not at all the case. As I recall, s= everal of us argued past one another for an hour or so and decided to adjourn in order = to go to the bar (okay, and dinner too - but mostly beer).

The impression about = reversal of terms, I think, comes from the text in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3<= /a> which hurts my head a little every-time I read it but does seems to con= fuse things. The MSDN link John gave is much more to the point than WS-Trust (I don'= t believe WS-Trust can be pointed to as a model of clarity).=C2=A0 In the d= raft I wrote, I tried to take Mike's text and clarify a distinction bet= ween impersonation and delegation with https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 and= then also be very explicit about act-as vs. on-behalf-of in the parameter = definitions at https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in a = manor that was consistent with WS-Trust and the MSDN explanation. I could s= ee value in breaking with that shaky legacy and using new terms too. But I = get the point of trying to keep with the old also and potential for even more confusing by using new terms= .

I wrote draft-campbel= l-oauth-sts last year in response to the call for adoption of jones-oauth-t= oken-exchange (thread from the archive). Though I didn't try and stand in the way and in= dicated a willingness to collaborate on things. With the expectation, of co= urse, that the details would differ from the -00s and -01s as work progress= ed. Folks seemed generally amenable to that at the time but little has happened since th= en.

Phil's earlier point about the priory of this ge= tting pushed down has some truth to it. But I still believe it's someth= ing that can provide a lot of value in standardizing, if we do so in a reasonable way.

=C2=A0<= /p>

=C2=A0<= /p>

=C2=A0<= /p>

=C2=A0

On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

It would surprise me if on-behalf-of and act-as were= reversed with respect WS-Trust, because the explanations of the terms came= directly from WS-Trust 1.4.=C2=A0 I also think the chances of us reducing confusion by inventing new terminology, rather than adding = to it, would not be in our favor. :-/

FYI, the action items outstanding from our ad-hoc meeting on this draft in = Dallas are:
=C2=A0 - Allowing security types other than JWT to also be used as the act_= as and on_behalf_of request values.
=C2=A0 - Further integrating the mechanism into the existing OAuth ecosyste= m - allowing use of access tokens or refresh tokens when appropriate.

I plan to do the first today.=C2=A0 The second is probably more than I'= ll get done today before the submission cutoff.=C2=A0 I agree with John tha= t it would be useful to have discussions on this in Prague on the best way = to achieve this further integration.=C2=A0 I'll plan to come into the Prague meeting with a concrete proposal for review.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Best wishes,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =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 John Bradley
Sent: Monday, July 06, 2015 8:13 AM
To: Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case

Yes unfortunately we haven=E2=80=99t made any progress on this since accept= ing Mike=E2=80=99s first draft.

His proposal is basically for a new endpoint while Brian tired to fit it in= to the existing token endpoint.

I think draft-ietf-oauth-token-exchange-01 still has OnBehalfOf and ActAs r= eversed compared to WS-Trust 1.4.
see https://msdn.microsoft.com/en-us/library/ee748487.aspx for the short ex= planation.

I think Brian is closer in explaining it.

In fairness because WS-Trust originally only had On-Behalf-Of the naming an= d what people put in tokens is a bit muddled in many implementations.
I think many times it is how WIF implemented it that people copied.

It may be better to have new terms that are clear such as impersonation and= composite.

The WG needs to decide if this is going to be an entirely new endpoint, fre= e of the Token endpoint semantics.=C2=A0 =C2=A0There are plusses and minuse= s to both options.

Also while it is nice to be pure and talk about abstract security tokens, i= t would be good to give some guidance on what a composite security token wo= uld look like for interoperability.

There are also issues around how this would work with proof of possession s= ecurity tokens, both as input and output.

Perhaps we can make some progress on this in Prague.

John B.




> On Jul 6, 2015, at 11:04 AM, Brian Campbell <bcampbell@pingidentity.com>= ; wrote:
>
> Thanks Sergey,
>
> The goal of draft-campbell-oauth-sts was to be consistent with OAuth 2= .0 and thus hopefully familiar to developers and easy to understand and imp= lement (especially from the client side). It's also intended to be flex= ible in order to accommodate a variety of use-cases including the chaining type cases that Justin's draft cov= ers.
>
> Specifying a security_token_type of the returned token is just a way o= f providing more info to the client about the token (i.e. is this a JWT or = a SAML token or something else) via a URI. It's not always needed but i= n STS style cases the tokens are not always opaque to the client and the parameter just provides info about the return= ed token.
>
> On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin <sberyozkin@gmail.com> wrote= :
> Hi Brian
>
> I've read the text, I like it is still pure OAuth2, with few extra= parameters added to the access token request, and a key response property = being 'access_token' as opposed to 'security_access_token' = as in the draft-ietf-oauth-token-exchange-01.
> It appears draft-campbell-oauth-sts-01 can cover a draft-richer-oauth-= chain-00 case with the on_behalf_of (and/or act_as ?) property being an ori= ginal client token but not 100% sure given draft-richer-oauth-chain-00 cove= rs a specific case.
>
> One thing I'm not sure about is what is the purpose of specifying = a
> security_token_type of the returned access token
>
> Thanks, Sergey
>
> On 01/07/15 15:59, Brian Campbell wrote:
> One problem, I think, with token exchange is that it can be really
> simple (token in and token out) and really complicated (client X wants=
> a token that says user A is doing something on behalf of user B) at > the same time.
>
> I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in
> an attempt to simplify things and express what I envisioned as an
> OAuth based token exchange framework. Though it likely only muddied > the waters :)
>
> On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin <sberyozkin@gmail.com
> <mailto:s= beryozkin@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hi Justin
>
>=C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-richer= -oauth-chain-00 is much
>=C2=A0 =C2=A0 =C2=A0easier to read, that I can tell for sure, at least = it is obvious why
>=C2=A0 =C2=A0 =C2=A0a given entity (RS1) may want to exchange the curre= nt token provided
>=C2=A0 =C2=A0 =C2=A0by a client for a new token. Definitely easily impl= ementable...
>
>=C2=A0 =C2=A0 =C2=A0One thing I'm not sure in the draft-richer-oaut= h-chain-00 about is
>=C2=A0 =C2=A0 =C2=A0on behalf of whose entity RS1 will be acting once i= t starts
>=C2=A0 =C2=A0 =C2=A0accessing RS2, On Behalf Of RO, or may be On Behalf= Of (RO +
>=C2=A0 =C2=A0 =C2=A0Client), or may be it is On Behalf Of RO + Act As C= lient ? The last
>=C2=A0 =C2=A0 =C2=A0one seems most logical to me...
>
>=C2=A0 =C2=A0 =C2=A0Thanks, Sergey
>
>
>=C2=A0 =C2=A0 =C2=A0On 01/07/15 13:18, Justin Richer wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0As it's written right now, it'= ;s a translation of some WS-*
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0concepts into
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0JWT format. It's not really OAuth= -y (since the client has to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0understand
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the token format along with everyone = else, and according to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0authors
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the artifacts might not even be "= ;OAuth tokens"), and that's my main
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0issue with the document. Years ago, I= proposed an OAuth-based
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0token swap
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mechanism:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/htm= l/draft-richer-oauth-chain-00
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This works without defining semantics= of the tokens themselves, just
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0like the rest of OAuth. I've prop= osed to the authors of the current
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft that it should incorporate both= semantic (using JWT) and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0syntactic
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(using a simple token-agnostic grant)= token swap mechanisms, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the two could be easily compatible. >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Justin
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 7/1/2015 6:35 AM, Sergey Beryozkin= wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hmm... perhaps the clue= is in the draft title,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0token-exchange, so may<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be it is a case of the = given access token ("on_behalf_of" or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"act_as"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0claim) being used to re= quest a new security token. One can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0only guess
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0though, does not seem l= ike the authors are keen to answer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the newbie
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0questions...
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Cheers, Sergey
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 30/06/15 13:38, Serg= ey Beryozkin wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Can you p= lease explain what is the difference between
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On-Behalf= -Of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0semantics= described in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-iet= f-oauth-token-exchange-01 and the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implicit = On-Behalf-Of semantics a client OAuth2 token
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0possesses= ?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0For examp= le, draft-ietf-oauth-token-exchange-01 mentions:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Whe= reas, with on-behalf-of semantics, principal A still
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0has its o= wn
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0identity = separate from B and it is explicitly understood
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that whil= e B
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0may have = delegated its rights to A, any actions taken
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0are being= taken by
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A and not= B. In a sense, A is an agent for B."
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This is a= typical case with the authorization code flow
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0where a c= lient
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0applicati= on acts on-behalf-of the user who authorized
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this appl= ication ?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sorry if = I'm missing something
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Cheers, S= ergey
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 25/06/= 15 22:28, Mike Jones wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0That=E2=80=99s what
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0https://tools.ietf.org/html/draft-ietf-oauth-token-= exchange-01
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0about.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Cheers,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0-- Mike
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0*From:*OAuth [mailto:oauth-bounces@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0<mailto:oauth-bounces@ietf.org>] *On Behalf Of *Vivek
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Biswas
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0-T (vibiswas - XORIANT CORPORATION at Cisco)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0*Sent:* Thursday, June 25, 2015 2:20 PM
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0*To:* OAuth@ietf.= org <mailto:OAut= h@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0*Subject:* [OAUTH-WG] JWT Token on-behalf of Use
> case
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Hi All,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0I am looking to solve a use-case similar to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0WS-Security On-Behalf-Of
>
> <http://docs.oasis-open.org/ws-sx/ws-trust= /v1.4/errata01/os/ws-trust-1
> .4-errata01-os-complete.html#_Toc325658980>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0with OAuth JWT Token.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Is there a standard claim which we can define
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0within the OAuth JWT
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0which denote the On-behalf-of User.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0For e.g., a Customer Representative trying to create
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0token on behalf of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0a customer and trying to execute services specific
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0for that specific
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0customer.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Regards,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Vivek Biswas,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0CISSP
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0*Cisco Systems, Inc <http://www.cisco.com/>*
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0*Bldg. J, San Jose, USA,*
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0*Phone: +1 408 527 9176
> <tel:%2B1= %20408%20527%209176>*
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0OAuth mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0OAuth@ietf.org <mailto:OAuth@ietf= .org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_______________________= ________________________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OAuth mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OAuth@ietf.org <mailto:OAuth@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mai= lman/listinfo/oauth
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_____________________________________= __________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OAuth mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OAuth@ietf.org <mailto:OAuth@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/= oauth
>
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0OAuth mailing list
>=C2=A0 =C2=A0 =C2=A0OAuth@ietf.org <mailto:OAuth@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

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

=C2=A0

=C2=A0


A natural usage of act-as or impersonation would suggest, to many people anyway, that the wa= y you just used the terms is reversed. The bold text below from https://tools.ietf.org/html/draft-ietf-oauth-token-excha= nge-01#section-1.3 uses 'impersonates' and "on-behalf-of&q= uot; contrary to what you just wrote about Windows Kerb. That's where t= he assertion that the draft has them reversed from de facto usage in WS-Tru= st. Those semantics are not only one open issue that needs to be resolved, = however, even if they occupy most of the discussion.=C2=A0

<= div style=3D"margin-left:40px">1.3.=C2=A0 On-Behalf-Of vs. Impersonation Se= mantics

=C2=A0=C2=A0 When principal A acts on behalf of principal B,= A is given all the
=C2=A0=C2=A0 rights that B has within some defined r= ights context.=C2=A0 Whereas, with
=C2=A0=C2=A0 on-behalf-of s= emantics, principal A still has its own identity
=C2=A0=C2=A0 sep= arate from B and it is explicitly understood that while B may have
<= b>=C2=A0=C2=A0 delegated its rights to A, any actions taken are being taken= by A and
=C2=A0=C2=A0 not B. In a sense, A is an agent for B.

=C2=A0=C2=A0 On-behalf-of semantics are therefore different than i= mpersonation
=C2=A0=C2=A0 semantics, with which it is sometimes confused= .=C2=A0 When principal A
=C2=A0=C2=A0 impersonates principal B= , then in so far as any entity receiving
=C2=A0=C2=A0 Claims is c= oncerned, they are actually dealing with B. It is true
=C2=A0=C2=A0 = that some members of the identity system might have awareness that
=C2= =A0=C2=A0 impersonation is going on but it is not a requirement.=C2=A0 For = all
=C2=A0=C2=A0 intents and purposes, when A is acting for B, A is B.

--bcaec517cddc71dfb9051a3c05bf-- From nobody Mon Jul 6 15:19:24 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C5B1A1B65; Mon, 6 Jul 2015 15:19: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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxBXKzL0juyf; Mon, 6 Jul 2015 15:19:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B50DC1A86E8; Mon, 6 Jul 2015 15:19:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706221920.11174.17567.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 15:19:20 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 22:19:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : OAuth 2.0 Token Exchange Authors : Michael B. Jones Anthony Nadalin Filename : draft-ietf-oauth-token-exchange-02.txt Pages : 10 Date : 2015-07-06 Abstract: This specification defines how to request and obtain Security Tokens from OAuth Authorization Servers, including enabling one party to act on behalf of another or enabling one party to delegate authority to another. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 6 16:06:00 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94C101A0195; Mon, 6 Jul 2015 16:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJwlEsA-rfoH; Mon, 6 Jul 2015 16:05:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F1B1A0117; Mon, 6 Jul 2015 16:05:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706230550.12450.15077.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 16:05:50 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-14.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 23:05:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : Proof Key for Code Exchange by OAuth Public Clients Authors : Nat Sakimura John Bradley Naveen Agarwal Filename : draft-ietf-oauth-spop-14.txt Pages : 20 Date : 2015-07-06 Abstract: OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced "pixy"). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-spop-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-spop-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 6 17:04:16 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65DA61A00EE for ; Mon, 6 Jul 2015 17:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2stp0varxv8g for ; Mon, 6 Jul 2015 17:04:07 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB01F1A21AC for ; Mon, 6 Jul 2015 17:04:06 -0700 (PDT) X-AuditID: 1209190d-f796f6d000005314-75-559b1774ecbb Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 53.45.21268.5771B955; Mon, 6 Jul 2015 20:04:05 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t67044Nk017145 for ; Mon, 6 Jul 2015 20:04:04 -0400 Received: from [192.168.128.56] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t67042rh025935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 6 Jul 2015 20:04:04 -0400 Message-ID: <559B176F.90105@mit.edu> Date: Mon, 06 Jul 2015 20:03:59 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: oauth@ietf.org References: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> <55928DB3.7090300@gmail.com> <5593C270.7000008@gmail.com> <5593DA7D.80401@mit.edu> <5593E5FD.3050403@gmail.com> <559A676F.3070008@gmail.com> <2BB85061-F141-478C-96B1-5086AFDA1F4F@oracle.com> In-Reply-To: <2BB85061-F141-478C-96B1-5086AFDA1F4F@oracle.com> Content-Type: multipart/alternative; boundary="------------020202070200060409080503" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDIsWRmVeSWpSXmKPExsUixCmqrFsqPjvU4OFxTouTb1+xOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4//TZYwFa84xV7w4Id3A+HA6UxcjJ4eEgInE5qVrWCFsMYkL 99azdTFycQgJLGaSWPQOJAHiHGWUWPZ0L5TznkliVdsX5i5GDg5eARWJk2dlQLpZBFQlDm29 zg5iswHZ09e0gG0QFYiSmPp4HQuIzSsgKHFy5hMwW0RASOL5zj6wGmEBc4ktTfsZIeb/Z5WY 23SHDSTBKWAncW7PFrDzmAXCJDomTGefwMg/C8msWUhSELatxJ25u5khbHmJ5q2zoWxdiUXb VrAjiy9gZFvFKJuSW6Wbm5iZU5yarFucnJiXl1qka6SXm1mil5pSuokRHMiSvDsY3x1UOsQo wMGoxMMbUTMzVIg1say4MvcQoyQHk5Io7y3h2aFCfEn5KZUZicUZ8UWlOanFhxglOJiVRHjP vJwVKsSbklhZlVqUD5OS5mBREufd9IMvREggPbEkNTs1tSC1CCYrw8GhJMEbLQY0VLAoNT21 Ii0zpwQhzcTBCTKcB2i4FkgNb3FBYm5xZjpE/hSjopQ4732QhABIIqM0D64XlmheMYoDvSLM +18UqIoHmKTgul8BDWYCGrxcF+Tq4pJEhJRUA6PH5q/uTJ1hs24/zWD9uWu7ipvifvf4DvlJ hRd1T92Z2y24ydHcv1v8lwCrA3eDf2bIXKvbMYLFZcqvlEVW8Nfzavc1LGnjOX39tu/F25Pz lxut1ai9o1Tc27kuuHvBvS3fVNxfH7qh9Tv+TNx5wQN3dadc0znuZX//3uFEi2blWMOLIo+L WJRYijMSDbWYi4oTAV7q3DwPAwAA Archived-At: Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 00:04:14 -0000 This is a multi-part message in MIME format. --------------020202070200060409080503 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit +1 for this. Let's learn from the mistakes of the past instead of repeating them. "We've always done it this way" is a really, really poor reason for doing something. -- Justin On 7/6/2015 5:20 PM, Phil Hunt wrote: > I think the original reasoning was sound, but the fact that so many > remain confused is good reason to go to new vocab. > > We could still have clarifying text that impersonate/composite is xxx > and yyy in kerberos etc. > > Phil > > On Jul 6, 2015, at 13:43, Anthony Nadalin > wrote: > >> The WS-Trust “ActAs” mimics the Windows Kerberos Protocol Transition >> (impersonation) feature as this enables an account to impersonate >> another account for the purpose of providing access to resources. In >> a typical scenario, the impersonating account would be a service >> account assigned to a web application or the computer account of a >> web server. The impersonated account would be a user account >> requiring access to resources (e.g. data in an SQL database) via a >> web application. In this scenario, SQL server would be accessed by >> the impersonating (service account) account, however access would be >> under the context of the impersonated (user) account. >> >> WS-Trust “OnBehalfOf” mimics the Windows Kerberos Constrained >> Delegation feature, which lets you limit the back-end services for >> which a front-end service can request tickets on behalf of another >> user. “OnBehalfOf” allows a selected services on a server can be >> granted for access by the impersonating account, whilst other >> services on the same server, or services on other servers are denied >> for access. >> >> Maybe someone can summarize why they think the text for ActAs and >> OnBehalfOf in WS-Trust or Windows Kerberos is wrong or swapped as I >> have not seen a clear explanation other than John saying that Brian >> knows and Brian saying John knows. >> >> Our usage and use cases are based upon the deployed services of >> WS-Trust and Kerberos support in Windows (workstation and server) and >> Xbox. >> >> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian >> Campbell >> *Sent:* Monday, July 6, 2015 11:29 AM >> *To:* Mike Jones > > >> *Cc:* oauth > >> *Subject:* Re: [OAUTH-WG] JWT Token on-behalf of Use case >> >> Stating specific action items resulting from the ad-hoc meeting in >> Dallas like that suggests some clear consensus was reached, which is >> not at all the case. As I recall, several of us argued past one >> another for an hour or so and decided to adjourn in order to go to >> the bar (okay, and dinner too - but mostly beer). >> >> The impression about reversal of terms, I think, comes from the text >> in >> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 >> which hurts my head a little every-time I read it but does seems to >> confuse things. The MSDN link >> John gave is >> much more to the point than WS-Trust (I don't believe WS-Trust can be >> pointed to as a model of clarity). In the draft I wrote, I tried to >> take Mike's text and clarify a distinction between impersonation and >> delegation with >> https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 >> and then also be very explicit about act-as vs. on-behalf-of in the >> parameter definitions at >> https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in >> a manor that was consistent with WS-Trust and the MSDN explanation. I >> could see value in breaking with that shaky legacy and using new >> terms too. But I get the point of trying to keep with the old also >> and potential for even more confusing by using new terms. >> >> I wrote draft-campbell-oauth-sts last year in response to the call >> for adoption of jones-oauth-token-exchange (thread from the archive >> ). >> Though I didn't try and stand in the way and indicated a willingness >> to collaborate on things. With the expectation, of course, that the >> details would differ from the -00s and -01s as work progressed. Folks >> seemed generally amenable to that >> >> at the time but little has happened since then. >> >> Phil's earlier point about the priory of this getting pushed down has >> some truth to it. But I still believe it's something that can provide >> a lot of value in standardizing, if we do so in a reasonable way. >> >> >> >> On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones >> > wrote: >> >> It would surprise me if on-behalf-of and act-as were reversed >> with respect WS-Trust, because the explanations of the terms came >> directly from WS-Trust 1.4. I also think the chances of us >> reducing confusion by inventing new terminology, rather than >> adding to it, would not be in our favor. :-/ >> >> FYI, the action items outstanding from our ad-hoc meeting on this >> draft in Dallas are: >> - Allowing security types other than JWT to also be used as the >> act_as and on_behalf_of request values. >> - Further integrating the mechanism into the existing OAuth >> ecosystem - allowing use of access tokens or refresh tokens when >> appropriate. >> >> I plan to do the first today. The second is probably more than >> I'll get done today before the submission cutoff. I agree with >> John that it would be useful to have discussions on this in >> Prague on the best way to achieve this further integration. I'll >> plan to come into the Prague meeting with a concrete proposal for >> review. >> >> Best wishes, >> -- Mike >> >> >> -----Original Message----- >> From: OAuth [mailto:oauth-bounces@ietf.org >> ] On Behalf Of John Bradley >> Sent: Monday, July 06, 2015 8:13 AM >> To: Brian Campbell >> Cc: oauth >> Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case >> >> Yes unfortunately we haven’t made any progress on this since >> accepting Mike’s first draft. >> >> His proposal is basically for a new endpoint while Brian tired to >> fit it into the existing token endpoint. >> >> I think draft-ietf-oauth-token-exchange-01 still has OnBehalfOf >> and ActAs reversed compared to WS-Trust 1.4. >> see https://msdn.microsoft.com/en-us/library/ee748487.aspx for >> the short explanation. >> >> I think Brian is closer in explaining it. >> >> In fairness because WS-Trust originally only had On-Behalf-Of the >> naming and what people put in tokens is a bit muddled in many >> implementations. >> I think many times it is how WIF implemented it that people copied. >> >> It may be better to have new terms that are clear such as >> impersonation and composite. >> >> The WG needs to decide if this is going to be an entirely new >> endpoint, free of the Token endpoint semantics. There are >> plusses and minuses to both options. >> >> Also while it is nice to be pure and talk about abstract security >> tokens, it would be good to give some guidance on what a >> composite security token would look like for interoperability. >> >> There are also issues around how this would work with proof of >> possession security tokens, both as input and output. >> >> Perhaps we can make some progress on this in Prague. >> >> John B. >> >> >> >> >> > On Jul 6, 2015, at 11:04 AM, Brian Campbell >> > >> wrote: >> > >> > Thanks Sergey, >> > >> > The goal of draft-campbell-oauth-sts was to be consistent with >> OAuth 2.0 and thus hopefully familiar to developers and easy to >> understand and implement (especially from the client side). It's >> also intended to be flexible in order to accommodate a variety of >> use-cases including the chaining type cases that Justin's draft >> covers. >> > >> > Specifying a security_token_type of the returned token is just >> a way of providing more info to the client about the token (i.e. >> is this a JWT or a SAML token or something else) via a URI. It's >> not always needed but in STS style cases the tokens are not >> always opaque to the client and the parameter just provides info >> about the returned token. >> > >> > On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin >> > wrote: >> > Hi Brian >> > >> > I've read the text, I like it is still pure OAuth2, with few >> extra parameters added to the access token request, and a key >> response property being 'access_token' as opposed to >> 'security_access_token' as in the draft-ietf-oauth-token-exchange-01. >> > It appears draft-campbell-oauth-sts-01 can cover a >> draft-richer-oauth-chain-00 case with the on_behalf_of (and/or >> act_as ?) property being an original client token but not 100% >> sure given draft-richer-oauth-chain-00 covers a specific case. >> > >> > One thing I'm not sure about is what is the purpose of specifying a >> > security_token_type of the returned access token >> > >> > Thanks, Sergey >> > >> > On 01/07/15 15:59, Brian Campbell wrote: >> > One problem, I think, with token exchange is that it can be really >> > simple (token in and token out) and really complicated (client >> X wants >> > a token that says user A is doing something on behalf of user B) at >> > the same time. >> > >> > I put forth >> https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in >> > an attempt to simplify things and express what I envisioned as an >> > OAuth based token exchange framework. Though it likely only muddied >> > the waters :) >> > >> > On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin >> >> > >> wrote: >> > >> > Hi Justin >> > >> > https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much >> > easier to read, that I can tell for sure, at least it is >> obvious why >> > a given entity (RS1) may want to exchange the current token >> provided >> > by a client for a new token. Definitely easily implementable... >> > >> > One thing I'm not sure in the draft-richer-oauth-chain-00 >> about is >> > on behalf of whose entity RS1 will be acting once it starts >> > accessing RS2, On Behalf Of RO, or may be On Behalf Of (RO + >> > Client), or may be it is On Behalf Of RO + Act As Client ? >> The last >> > one seems most logical to me... >> > >> > Thanks, Sergey >> > >> > >> > On 01/07/15 13:18, Justin Richer wrote: >> > >> > As it's written right now, it's a translation of some WS-* >> > concepts into >> > JWT format. It's not really OAuth-y (since the client >> has to >> > understand >> > the token format along with everyone else, and >> according to the >> > authors >> > the artifacts might not even be "OAuth tokens"), and >> that's my main >> > issue with the document. Years ago, I proposed an >> OAuth-based >> > token swap >> > mechanism: >> > >> > https://tools.ietf.org/html/draft-richer-oauth-chain-00 >> > >> > This works without defining semantics of the tokens >> themselves, just >> > like the rest of OAuth. I've proposed to the authors of >> the current >> > draft that it should incorporate both semantic (using >> JWT) and >> > syntactic >> > (using a simple token-agnostic grant) token swap >> mechanisms, and >> > that >> > the two could be easily compatible. >> > >> > -- Justin >> > >> > On 7/1/2015 6:35 AM, Sergey Beryozkin wrote: >> > >> > Hmm... perhaps the clue is in the draft title, >> > token-exchange, so may >> > be it is a case of the given access token >> ("on_behalf_of" or >> > "act_as" >> > claim) being used to request a new security token. >> One can >> > only guess >> > though, does not seem like the authors are keen to >> answer >> > the newbie >> > questions... >> > >> > Cheers, Sergey >> > >> > >> > On 30/06/15 13:38, Sergey Beryozkin wrote: >> > >> > Hi, >> > Can you please explain what is the difference >> between >> > On-Behalf-Of >> > semantics described in the >> > draft-ietf-oauth-token-exchange-01 and the >> > implicit On-Behalf-Of semantics a client OAuth2 >> token >> > possesses ? >> > >> > For example, draft-ietf-oauth-token-exchange-01 >> mentions: >> > >> > "Whereas, with on-behalf-of semantics, >> principal A still >> > has its own >> > identity separate from B and it is explicitly >> understood >> > that while B >> > may have delegated its rights to A, any actions >> taken >> > are being taken by >> > A and not B. In a sense, A is an agent for B." >> > >> > This is a typical case with the authorization >> code flow >> > where a client >> > application acts on-behalf-of the user who >> authorized >> > this application ? >> > >> > Sorry if I'm missing something >> > >> > Cheers, Sergey >> > On 25/06/15 22:28, Mike Jones wrote: >> > >> > That’s what >> > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 >> > is >> > about. >> > >> > Cheers, >> > >> > -- Mike >> > >> > *From:*OAuth [mailto:oauth-bounces@ietf.org >> >> > > >] *On Behalf Of *Vivek >> > Biswas >> > -T (vibiswas - XORIANT CORPORATION at Cisco) >> > *Sent:* Thursday, June 25, 2015 2:20 PM >> > *To:* OAuth@ietf.org >> > > >> > *Subject:* [OAUTH-WG] JWT Token on-behalf >> of Use >> > case >> > >> > Hi All, >> > >> > I am looking to solve a use-case similar to >> > WS-Security On-Behalf-Of >> > >> > >> > > .4-errata01-os-complete.html#_Toc325658980> >> > >> > >> > with OAuth JWT Token. >> > >> > Is there a standard claim which we can >> define >> > within the OAuth JWT >> > which denote the On-behalf-of User. >> > >> > For e.g., a Customer Representative trying >> to create >> > token on behalf of >> > a customer and trying to execute services >> specific >> > for that specific >> > customer. >> > >> > Regards, >> > >> > Vivek Biswas, >> > CISSP >> > >> > *Cisco Systems, Inc * >> > >> > *Bldg. J, San Jose, USA,* >> > >> > *Phone: +1 408 527 9176 >> >> > * >> > >> > >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@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 > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------020202070200060409080503 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit +1 for this. Let's learn from the mistakes of the past instead of repeating them. "We've always done it this way" is a really, really poor reason for doing something.

 -- Justin

On 7/6/2015 5:20 PM, Phil Hunt wrote:
I think the original reasoning was sound, but the fact that so many remain confused is good reason to go to new vocab.

We could still have clarifying text that impersonate/composite is xxx and yyy in kerberos etc. 

Phil

On Jul 6, 2015, at 13:43, Anthony Nadalin <tonynad@microsoft.com> wrote:

The WS-Trust “ActAs” mimics the Windows Kerberos Protocol Transition (impersonation)  feature as this enables an account to impersonate another account for the purpose of providing access to resources. In a typical scenario, the impersonating account would be a service account assigned to a web application or the computer account of a web server. The impersonated account would be a user account requiring access to resources (e.g. data in an SQL database) via a web application. In this scenario, SQL server would be accessed by the impersonating (service account) account, however access would be under the context of the impersonated (user) account.

 

WS-Trust “OnBehalfOf”  mimics the Windows Kerberos Constrained Delegation feature, which lets you limit the back-end services for which a front-end service can request tickets on behalf of another user. “OnBehalfOf”  allows a selected services on a server can be granted for access by the impersonating account, whilst other services on the same server, or services on other servers are denied for access.

 

Maybe someone can summarize why they think the text for ActAs and OnBehalfOf in WS-Trust or Windows Kerberos is wrong or swapped as I have not seen a clear explanation other than John saying that Brian knows and Brian saying John knows.

 

Our usage and use cases are based upon the deployed services of WS-Trust and Kerberos support in Windows (workstation and server) and Xbox.

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Monday, July 6, 2015 11:29 AM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case

 

Stating specific action items resulting from the ad-hoc meeting in Dallas like that suggests some clear consensus was reached, which is not at all the case. As I recall, several of us argued past one another for an hour or so and decided to adjourn in order to go to the bar (okay, and dinner too - but mostly beer).

The impression about reversal of terms, I think, comes from the text in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 which hurts my head a little every-time I read it but does seems to confuse things. The MSDN link John gave is much more to the point than WS-Trust (I don't believe WS-Trust can be pointed to as a model of clarity).  In the draft I wrote, I tried to take Mike's text and clarify a distinction between impersonation and delegation with https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 and then also be very explicit about act-as vs. on-behalf-of in the parameter definitions at https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in a manor that was consistent with WS-Trust and the MSDN explanation. I could see value in breaking with that shaky legacy and using new terms too. But I get the point of trying to keep with the old also and potential for even more confusing by using new terms.

I wrote draft-campbell-oauth-sts last year in response to the call for adoption of jones-oauth-token-exchange (thread from the archive). Though I didn't try and stand in the way and indicated a willingness to collaborate on things. With the expectation, of course, that the details would differ from the -00s and -01s as work progressed. Folks seemed generally amenable to that at the time but little has happened since then.

Phil's earlier point about the priory of this getting pushed down has some truth to it. But I still believe it's something that can provide a lot of value in standardizing, if we do so in a reasonable way.

 



 

 

On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

It would surprise me if on-behalf-of and act-as were reversed with respect WS-Trust, because the explanations of the terms came directly from WS-Trust 1.4.  I also think the chances of us reducing confusion by inventing new terminology, rather than adding to it, would not be in our favor. :-/

FYI, the action items outstanding from our ad-hoc meeting on this draft in Dallas are:
  - Allowing security types other than JWT to also be used as the act_as and on_behalf_of request values.
  - Further integrating the mechanism into the existing OAuth ecosystem - allowing use of access tokens or refresh tokens when appropriate.

I plan to do the first today.  The second is probably more than I'll get done today before the submission cutoff.  I agree with John that it would be useful to have discussions on this in Prague on the best way to achieve this further integration.  I'll plan to come into the Prague meeting with a concrete proposal for review.

                                Best wishes,
                                -- Mike


-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Monday, July 06, 2015 8:13 AM
To: Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case

Yes unfortunately we haven’t made any progress on this since accepting Mike’s first draft.

His proposal is basically for a new endpoint while Brian tired to fit it into the existing token endpoint.

I think draft-ietf-oauth-token-exchange-01 still has OnBehalfOf and ActAs reversed compared to WS-Trust 1.4.
see https://msdn.microsoft.com/en-us/library/ee748487.aspx for the short explanation.

I think Brian is closer in explaining it.

In fairness because WS-Trust originally only had On-Behalf-Of the naming and what people put in tokens is a bit muddled in many implementations.
I think many times it is how WIF implemented it that people copied.

It may be better to have new terms that are clear such as impersonation and composite.

The WG needs to decide if this is going to be an entirely new endpoint, free of the Token endpoint semantics.   There are plusses and minuses to both options.

Also while it is nice to be pure and talk about abstract security tokens, it would be good to give some guidance on what a composite security token would look like for interoperability.

There are also issues around how this would work with proof of possession security tokens, both as input and output.

Perhaps we can make some progress on this in Prague.

John B.




> On Jul 6, 2015, at 11:04 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
>
> Thanks Sergey,
>
> The goal of draft-campbell-oauth-sts was to be consistent with OAuth 2.0 and thus hopefully familiar to developers and easy to understand and implement (especially from the client side). It's also intended to be flexible in order to accommodate a variety of use-cases including the chaining type cases that Justin's draft covers.
>
> Specifying a security_token_type of the returned token is just a way of providing more info to the client about the token (i.e. is this a JWT or a SAML token or something else) via a URI. It's not always needed but in STS style cases the tokens are not always opaque to the client and the parameter just provides info about the returned token.
>
> On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin <sberyozkin@gmail.com> wrote:
> Hi Brian
>
> I've read the text, I like it is still pure OAuth2, with few extra parameters added to the access token request, and a key response property being 'access_token' as opposed to 'security_access_token' as in the draft-ietf-oauth-token-exchange-01.
> It appears draft-campbell-oauth-sts-01 can cover a draft-richer-oauth-chain-00 case with the on_behalf_of (and/or act_as ?) property being an original client token but not 100% sure given draft-richer-oauth-chain-00 covers a specific case.
>
> One thing I'm not sure about is what is the purpose of specifying a
> security_token_type of the returned access token
>
> Thanks, Sergey
>
> On 01/07/15 15:59, Brian Campbell wrote:
> One problem, I think, with token exchange is that it can be really
> simple (token in and token out) and really complicated (client X wants
> a token that says user A is doing something on behalf of user B) at
> the same time.
>
> I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in
> an attempt to simplify things and express what I envisioned as an
> OAuth based token exchange framework. Though it likely only muddied
> the waters :)
>
> On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin <sberyozkin@gmail.com
> <mailto:sberyozkin@gmail.com>> wrote:
>
>     Hi Justin
>
>     https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much
>     easier to read, that I can tell for sure, at least it is obvious why
>     a given entity (RS1) may want to exchange the current token provided
>     by a client for a new token. Definitely easily implementable...
>
>     One thing I'm not sure in the draft-richer-oauth-chain-00 about is
>     on behalf of whose entity RS1 will be acting once it starts
>     accessing RS2, On Behalf Of RO, or may be On Behalf Of (RO +
>     Client), or may be it is On Behalf Of RO + Act As Client ? The last
>     one seems most logical to me...
>
>     Thanks, Sergey
>
>
>     On 01/07/15 13:18, Justin Richer wrote:
>
>         As it's written right now, it's a translation of some WS-*
>         concepts into
>         JWT format. It's not really OAuth-y (since the client has to
>         understand
>         the token format along with everyone else, and according to the
>         authors
>         the artifacts might not even be "OAuth tokens"), and that's my main
>         issue with the document. Years ago, I proposed an OAuth-based
>         token swap
>         mechanism:
>
>         https://tools.ietf.org/html/draft-richer-oauth-chain-00
>
>         This works without defining semantics of the tokens themselves, just
>         like the rest of OAuth. I've proposed to the authors of the current
>         draft that it should incorporate both semantic (using JWT) and
>         syntactic
>         (using a simple token-agnostic grant) token swap mechanisms, and
>         that
>         the two could be easily compatible.
>
>            -- Justin
>
>         On 7/1/2015 6:35 AM, Sergey Beryozkin wrote:
>
>             Hmm... perhaps the clue is in the draft title,
>             token-exchange, so may
>             be it is a case of the given access token ("on_behalf_of" or
>             "act_as"
>             claim) being used to request a new security token. One can
>             only guess
>             though, does not seem like the authors are keen to answer
>             the newbie
>             questions...
>
>             Cheers, Sergey
>
>
>             On 30/06/15 13:38, Sergey Beryozkin wrote:
>
>                 Hi,
>                 Can you please explain what is the difference between
>                 On-Behalf-Of
>                 semantics described in the
>                 draft-ietf-oauth-token-exchange-01 and the
>                 implicit On-Behalf-Of semantics a client OAuth2 token
>                 possesses ?
>
>                 For example, draft-ietf-oauth-token-exchange-01 mentions:
>
>                 "Whereas, with on-behalf-of semantics, principal A still
>                 has its own
>                 identity separate from B and it is explicitly understood
>                 that while B
>                 may have delegated its rights to A, any actions taken
>                 are being taken by
>                 A and not B. In a sense, A is an agent for B."
>
>                 This is a typical case with the authorization code flow
>                 where a client
>                 application acts on-behalf-of the user who authorized
>                 this application ?
>
>                 Sorry if I'm missing something
>
>                 Cheers, Sergey
>                 On 25/06/15 22:28, Mike Jones wrote:
>
>                     That’s what
>                     https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01
>                     is
>                     about.
>
>                     Cheers,
>
>                     -- Mike
>
>                     *From:*OAuth [mailto:oauth-bounces@ietf.org
>                     <mailto:oauth-bounces@ietf.org>] *On Behalf Of *Vivek
>                     Biswas
>                     -T (vibiswas - XORIANT CORPORATION at Cisco)
>                     *Sent:* Thursday, June 25, 2015 2:20 PM
>                     *To:* OAuth@ietf.org <mailto:OAuth@ietf.org>
>                     *Subject:* [OAUTH-WG] JWT Token on-behalf of Use
> case
>
>                     Hi All,
>
>                         I am looking to solve a use-case similar to
>                     WS-Security On-Behalf-Of
>
> <http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust-1
> .4-errata01-os-complete.html#_Toc325658980>
>
>
>                     with OAuth JWT Token.
>
>                         Is there a standard claim which we can define
>                     within the OAuth JWT
>                     which denote the On-behalf-of User.
>
>                     For e.g., a Customer Representative trying to create
>                     token on behalf of
>                     a customer and trying to execute services specific
>                     for that specific
>                     customer.
>
>                     Regards,
>
>                     Vivek Biswas,
>                     CISSP
>
>                     *Cisco Systems, Inc <http://www.cisco.com/>*
>
>                     *Bldg. J, San Jose, USA,*
>
>                     *Phone: +1 408 527 9176
> <tel:%2B1%20408%20527%209176>*
>
>
>
>                     _______________________________________________
>                     OAuth mailing list
>                     OAuth@ietf.org <mailto:OAuth@ietf.org>
>                     https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>             _______________________________________________
>             OAuth mailing list
>             OAuth@ietf.org <mailto:OAuth@ietf.org>
>             https://www.ietf.org/mailman/listinfo/oauth
>
>
>         _______________________________________________
>         OAuth mailing list
>         OAuth@ietf.org <mailto:OAuth@ietf.org>
>         https://www.ietf.org/mailman/listinfo/oauth
>
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

 

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


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

--------------020202070200060409080503-- From nobody Mon Jul 6 19:49:06 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73CCF1A8752; Mon, 6 Jul 2015 19:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfVlBl4CAqTB; Mon, 6 Jul 2015 19:49:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D99481A00B8; Mon, 6 Jul 2015 19:49:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150707024902.24716.2952.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 19:49:02 -0700 Archived-At: Cc: draft-ietf-oauth-spop@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-spop.shepherd@ietf.org, oauth@ietf.org, draft-ietf-oauth-spop.ad@ietf.org Subject: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-spop-14: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 02:49:04 -0000 Barry Leiba has entered the following ballot position for draft-ietf-oauth-spop-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Version -14 resolves my DISCUSS (and also some of my non-blocking comments). Thanks very much for considering these and working with me on them! ========================================= My comment about the IANA Considerations remains. While it's non-blocking, I still hope you will accept the change I suggest: -- Section 6.2 -- I have the same comment here as in the other OAuth document: please shift the focus away from telling IANA how to handle tracking of the expert review, and make the mailing list something that the designated expert(s) keep track of. Also, please give more instructions to the DEs about what they should consider when they're evaluating a request (for example, should they approve all requests, or are there criteria they should apply?). For the first, here's a text change that I suggest we move toward for this sort of thing: OLD NEW Additional code_challenge_method types for use with the authorization endpoint are registered using the Specification Required policy [RFC5226], which includes review of the request by one or more Designated Experts. The DEs will ensure there is at least a two-week review of the request on the oauth-ext-review@ietf.org mailing list, and that any discussion on that list converges before they respond to the request. To allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that an acceptable specification will be published. Discussion on the oauth-ext-review@ietf.org mailing list should use an appropriate subject, such as "Request for PKCE code_challenge_method: example"). The Designated Expert(s) should consider the discussion on the mailing list, as well as <> when evaluating registration requests. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. END ========================================= -- Section 7.2 -- I find the first first paragraph confusingly worded, and after discussion with the author I suggest this: NEW Clients MUST NOT downgrade to "plain" after trying the S256 method. Because servers are required to support S256, an error when S256 is presented can only mean that the server does not support PKCE at all. Otherwise, such an error could be indicative of a MITM attacker trying a downgrade attack. END ========================================= Finally, there is this comment, which is not a big deal and you should proceed as you think best: -- Section 2 -- There is no real distinction between STRING and ASCII(STRING), because STRING is already defined to be ASCII. Using "ASCII(xxx)" only adds clutter, and a suggest removing it. So, for example, that would result in changes such as this: OLD BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) == code_challenge NEW BASE64URL-ENCODE(SHA256(code_verifier)) == code_challenge END From nobody Mon Jul 6 21:23:19 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11441A1AC1 for ; Mon, 6 Jul 2015 21:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4ZaYWTVX6oY for ; Mon, 6 Jul 2015 21:23:17 -0700 (PDT) Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E9381A8795 for ; Mon, 6 Jul 2015 21:23:17 -0700 (PDT) Received: by igcsj18 with SMTP id sj18so251872475igc.1 for ; Mon, 06 Jul 2015 21:23:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=j07q7W/U2rWsC/WY05OyIq/Bzye8izrS8uNbeumXm1Y=; b=J3fBMHPKeMKKDWevxsc93XwQSznlL39mt+Hl7hwClYv36lKFu9UTmCGoXPjErmx1x1 ro4I/JiTJE00tgv6GQnme60gOyfxDcmxgCVLSG10TU4NAIcRfIsaTWcB6UY/iECVJfWD dfgKvhzITPwrrPZZXuPXi5IICwo4ytgcH4Zb4KFdebdw1NjR94y2YTAp0nQlqGrYivKl xez3OY1ib6XPGhhUYRkMVtdWxnrjDaS83z1wPmI7ElBTnZvWsgebwkJWB6YMlWkSy06/ LpRNh4rVBZH8o1iUdyqOrG6PT3GOPIDqXTFb0+wx6g7AmTPIAGDfI0KsKRf1DW7fIhIT 0wCw== X-Gm-Message-State: ALoCoQnVTAT/7KC+NfpUrDP8W2EHEhRc8NVd+J7gLVsCWdCTcCISVR8HnJVJ/LtfR/rCilOM4jbY X-Received: by 10.107.47.224 with SMTP id v93mr3056319iov.86.1436242997043; Mon, 06 Jul 2015 21:23:17 -0700 (PDT) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com. [209.85.213.182]) by smtp.gmail.com with ESMTPSA id n6sm11132553igv.17.2015.07.06.21.23.16 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jul 2015 21:23:16 -0700 (PDT) Received: by igcqs7 with SMTP id qs7so24728280igc.0 for ; Mon, 06 Jul 2015 21:23:15 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.171.232 with SMTP id ax8mr5689013igc.32.1436242995585; Mon, 06 Jul 2015 21:23:15 -0700 (PDT) Received: by 10.107.32.73 with HTTP; Mon, 6 Jul 2015 21:23:15 -0700 (PDT) Date: Mon, 6 Jul 2015 21:23:15 -0700 Message-ID: From: Aaron Parecki To: OAuth WG Content-Type: multipart/alternative; boundary=089e010d9566902e08051a4161cc Archived-At: Subject: [OAUTH-WG] invalid_scope in access token request X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 04:23:19 -0000 --089e010d9566902e08051a4161cc Content-Type: text/plain; charset=UTF-8 Section 5.2 lists the possible errors the authorization server can return for an access token request. In the list is "invalid_scope", which as I understand it, can only be returned for a "password" or "client_credentials" grant, since scope is not a parameter of an "authorization_code" grant. Because of this, I believe the phrase "or exceeds the scope granted by the resource owner." is unnecessary, since there is no initial grant by the resource owner. Am I reading this correctly, or is there some situation I am not thinking of? Thanks! ---- Aaron Parecki aaronparecki.com @aaronpk --089e010d9566902e08051a4161cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Section 5.2 lists the possible errors the authorizati= on server can return for an access token request. In the list is "inva= lid_scope", which as I understand it, can only be returned for a "= ;password" or "client_credentials" grant, since scope is not= a parameter of an "authorization_code" grant.=C2=A0
Because of this, I believe the phrase "or=C2=A0exceeds th= e scope granted by the resource owner." is unnecessary, since there is= no initial grant by the resource owner. Am I reading this correctly, or is= there some situation I am not thinking of? Thanks!

=
----
Aaron Parecki
=

--089e010d9566902e08051a4161cc-- From nobody Tue Jul 7 01:08:08 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F93F1A1A7C for ; Tue, 7 Jul 2015 01:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJKIwgnx2BeQ for ; Tue, 7 Jul 2015 01:08:05 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0080.outbound.protection.outlook.com [65.55.169.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A6F61A017A for ; Tue, 7 Jul 2015 01:08:04 -0700 (PDT) Received: from BY1PR0201MB1030.namprd02.prod.outlook.com (10.161.203.148) by BY1PR0201MB1030.namprd02.prod.outlook.com (10.161.203.148) with Microsoft SMTP Server (TLS) id 15.1.207.19; Tue, 7 Jul 2015 08:08: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.0207.004; Tue, 7 Jul 2015 08:08:03 +0000 From: Antonio Sanso To: Aaron Parecki Thread-Topic: [OAUTH-WG] invalid_scope in access token request Thread-Index: AQHQuGytQ3/JaE/ixkyN5+8QY0DqNp3PrDOA Date: Tue, 7 Jul 2015 08:08:03 +0000 Message-ID: <901C9552-290C-423C-B9A8-8204824A9131@adobe.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: parecki.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [192.147.117.11] x-microsoft-exchange-diagnostics: 1; BY1PR0201MB1030; 5:8wo97xpkflDpXZa2tgfIM7rM8UHNyD40HywsTFdY3JyF50ns5GtKRFZRl6go0GBenu3OG/6W8rjFqOsogYZ7+HoRxWzdL9VUdatLugxDnK/a9mP0pqZftetQf3U7jzEC/0ldi/HfjUz9VFYzMY+ySg==; 24:XJj0HroMSL4QJr2twRbhzvIciBifkIXhw9/Qemg+wxyDhZM8Iw8Zx6/4WUa6s5+i3/NdIzcFJ3v56Khayj3NyW9V67nC2KMGpwbSHQqtAzg=; 20:7p1EK537Hg2sHMimey5HbGTNRN9N95EtyJCpqScQSJx4kkvEgHMBkVtBhozwzNgV/SRdsfrTgvcmg/B4BGV5YA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0201MB1030; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BY1PR0201MB1030; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0201MB1030; x-forefront-prvs: 0630013541 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(377454003)(2950100001)(106116001)(33656002)(87936001)(86362001)(50986999)(19617315012)(551544002)(92566002)(15395725005)(2900100001)(16236675004)(40100003)(99286002)(19580395003)(82746002)(2656002)(19580405001)(122556002)(36756003)(66066001)(5002640100001)(5001960100002)(76176999)(110136002)(77096005)(54356999)(62966003)(83716003)(189998001)(46102003)(77156002)(102836002)(15975445007)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0201MB1030; H:BY1PR0201MB1030.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_901C9552290C423CB9A88204824A9131adobecom_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2015 08:08:03.1612 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0201MB1030 Archived-At: Cc: OAuth WG Subject: Re: [OAUTH-WG] invalid_scope in access token request X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 08:08:07 -0000 --_000_901C9552290C423CB9A88204824A9131adobecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable hi Aaron On Jul 7, 2015, at 6:23 AM, Aaron Parecki > wrote: Section 5.2 lists the possible errors the authorization server can return f= or an access token request. In the list is "invalid_scope", which as I unde= rstand it, can only be returned for a "password" or "client_credentials" gr= ant, since scope is not a parameter of an "authorization_code" grant. why not :) ? From https://tools.ietf.org/html/rfc6749#section-4.1.1 scope OPTIONAL. The scope of the access request as described by Section 3.3. regards antonio Because of this, I believe the phrase "or exceeds the scope granted by the = resource owner." is unnecessary, since there is no initial grant by the res= ource owner. Am I reading this correctly, or is there some situation I am n= ot thinking of? Thanks! ---- Aaron Parecki aaronparecki.com @aaronpk _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_901C9552290C423CB9A88204824A9131adobecom_ Content-Type: text/html; charset="us-ascii" Content-ID: <390ABF773B058B4E99F1464196E54798@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable hi Aaron

On Jul 7, 2015, at 6:23 AM, Aaron Parecki <aaron@parecki.com> wrote:

Section 5.2 lists the possible errors the authorization server can ret= urn for an access token request. In the list is "invalid_scope", = which as I understand it, can only be returned for a "password" o= r "client_credentials" grant, since scope is not a parameter of an "authorization_code" grant. 


 scope
         OPTIONAL.  The scope of the access request as described by
         Sectio=
n 3.3.
regards

antonio


Because of this, I believe the phrase "or exceeds the scope = granted by the resource owner." is unnecessary, since there is no init= ial grant by the resource owner. Am I reading this correctly, or is there s= ome situation I am not thinking of? Thanks!

----
Aaron Parecki
@aaronpk<= /div>

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

--_000_901C9552290C423CB9A88204824A9131adobecom_-- From nobody Tue Jul 7 07:42:54 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B231ACCF3 for ; Tue, 7 Jul 2015 07:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.478 X-Spam-Level: X-Spam-Status: No, score=0.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PmHWBKc09ny for ; Tue, 7 Jul 2015 07:42:52 -0700 (PDT) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 239AF1ACCED for ; Tue, 7 Jul 2015 07:42:52 -0700 (PDT) Received: by igh16 with SMTP id 16so54042811igh.0 for ; Tue, 07 Jul 2015 07:42: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:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=j2h6cpR1AS3NaZNLvCSHUhGh8h6ex5QZxJ7yEDx+zL8=; b=UYTcQ/6iAzBbm5c41rLETYlryyj39rZP6oCymVsNoW4mS3ARzR0vD2QD+BeC0+t0Gn c5dqbXIzRuhKAxr0V1lK3j8KmK08azGe4tnkoIar/a9ELJGkHfQNRNYYgBsfr4NLeHeD igkI8wFcn0Y+JkWkbiI6UuSHsNH9ZPklDotm8B6as3y+Cn/GMNUY+4a3xs/XJXpN4kVB etlg+A9BN776Ms6kSyVMnbNdjZD+gQegLNuoeTo6+/LTvjKy4aXVZZ5GTlB17MM02QK5 fhbZeqrIvB8Rn32KCG8IjajlRzWOUPyghlf3MR8IDkpYCjbQ64x1FrSiW59geCtXDzse lbMw== X-Gm-Message-State: ALoCoQnQjPiJUVH1TaNdpIFqHPBWApgGgJedcEynJBrHMp0RCUVnklReU8fAH/VFCnxX4OfDO9W+ X-Received: by 10.107.168.90 with SMTP id r87mr6998403ioe.4.1436280171520; Tue, 07 Jul 2015 07:42:51 -0700 (PDT) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com. [209.85.213.171]) by mx.google.com with ESMTPSA id j2sm14719295ioo.43.2015.07.07.07.42.49 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jul 2015 07:42:50 -0700 (PDT) Received: by igau2 with SMTP id u2so38309410iga.0 for ; Tue, 07 Jul 2015 07:42:49 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.171.232 with SMTP id ax8mr9300612igc.32.1436280169746; Tue, 07 Jul 2015 07:42:49 -0700 (PDT) Received: by 10.107.32.73 with HTTP; Tue, 7 Jul 2015 07:42:49 -0700 (PDT) In-Reply-To: <901C9552-290C-423C-B9A8-8204824A9131@adobe.com> References: <901C9552-290C-423C-B9A8-8204824A9131@adobe.com> Date: Tue, 7 Jul 2015 07:42:49 -0700 Message-ID: From: Aaron Parecki To: Antonio Sanso Content-Type: multipart/alternative; boundary=089e010d956650e4e9051a4a0967 Archived-At: Cc: OAuth WG Subject: Re: [OAUTH-WG] invalid_scope in access token request X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 14:42:53 -0000 --089e010d956650e4e9051a4a0967 Content-Type: text/plain; charset=UTF-8 Section 4.1.1 describes the parameters of the *authorization* request, not the token request. After the user approves the scope in the authorization request, the client exchanges the code for the access token. I'm talking about the token request, where there is no scope parameter listed, section 4.1.3 https://tools.ietf.org/html/rfc6749#section-4.1.3 ---- Aaron Parecki aaronparecki.com @aaronpk On Tue, Jul 7, 2015 at 1:08 AM, Antonio Sanso wrote: > hi Aaron > > On Jul 7, 2015, at 6:23 AM, Aaron Parecki wrote: > > Section 5.2 lists the possible errors the authorization server can > return for an access token request. In the list is "invalid_scope", which > as I understand it, can only be returned for a "password" or > "client_credentials" grant, since scope is not a parameter of an > "authorization_code" grant. > > > why not :) ? From https://tools.ietf.org/html/rfc6749#section-4.1.1 > > scope > OPTIONAL. The scope of the access request as described by > Section 3.3 . > > regards > > antonio > > > Because of this, I believe the phrase "or exceeds the scope granted by > the resource owner." is unnecessary, since there is no initial grant by the > resource owner. Am I reading this correctly, or is there some situation I > am not thinking of? Thanks! > > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --089e010d956650e4e9051a4a0967 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Section 4.1.1 describes the parameters of the *authorizati= on* request, not the token request. After the user approves the scope in th= e authorization request, the client exchanges the code for the access token= . I'm talking about the token request, where there is no scope paramete= r listed, section 4.1.3=C2=A0https://tools.ietf.org/html/rfc6749#section-4.1.3
=

----
Aaron Parecki

=

On Tue, Jul 7, 2015 at 1:08 AM, Antonio Sans= o <asanso@adobe.com> wrote:
hi Aaron

On Jul 7, 2015, at 6:23 AM, Aaron Parecki <aaron@parecki.com> wrote:

Section 5.2 lists the possible errors the authorization server can ret= urn for an access token request. In the list is "invalid_scope", = which as I understand it, can only be returned for a "password" o= r "client_credentials" grant, since scope is not a parameter of an "authorization_code" grant.=C2=A0

 

 scope
         OPTIONAL.  The scope of the access request as described by
         Section 3.3.
regards

antonio


Because of this, I believe the phrase "or=C2=A0exceeds the scope = granted by the resource owner." is unnecessary, since there is no init= ial grant by the resource owner. Am I reading this correctly, or is there s= ome situation I am not thinking of? Thanks!

----
Aaron Parecki
@aaronpk<= /div>

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


--089e010d956650e4e9051a4a0967-- From nobody Tue Jul 7 08:13:32 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F81C1ACD91 for ; Tue, 7 Jul 2015 08:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.145 X-Spam-Level: X-Spam-Status: No, score=-0.145 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZOO4D1t9QFs for ; Tue, 7 Jul 2015 08:13:28 -0700 (PDT) Received: from mail-qk0-f170.google.com (mail-qk0-f170.google.com [209.85.220.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F9D31ACDA3 for ; Tue, 7 Jul 2015 08:13:28 -0700 (PDT) Received: by qkeo142 with SMTP id o142so142011992qke.1 for ; Tue, 07 Jul 2015 08:13:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=XkfpLbkXf1tIIqD9o0DiMeLgkcqDWYl0bGiZolYVzAU=; b=fRMCCh2/+Xsx9/oUi2lY5iSQwoWrJn+0C0NMJRrzSViCBRJDyohJ/Za1BeWnYdDWY/ OIjGL9VDLDG/AgMnBmiceMwHt1tqpQ7o5ZesRCNLQ2LQMetlcTBcFbdaac8vMViqRzyS l7BHhJMGBhqS8IH8wxnhE6w4CzRYC+K2pLKMnppD7Ly3X1hpoFttnZMWicVB9eIvHeJ0 dCo519aGD/iQsn51m3D+n//QEon6cKfxl+9CjYOsMVGTox4eJvxj3iZ+XOJbyFWFRU27 dAyUIByT582g2bMwbsq7X/W+VRJ0fCBK1w95VSYS7NeePpLwKtE3wXhZGVlINj3zgk6s QBhQ== X-Gm-Message-State: ALoCoQnWIhaZhLAMQHT8JxsTuivQc0G1F4fLHFMYfKaeea8mjXxT6xeHb0n9wNhtcwQKaKWvs+7H X-Received: by 10.140.84.137 with SMTP id l9mr7632946qgd.94.1436282007477; Tue, 07 Jul 2015 08:13:27 -0700 (PDT) Received: from [192.168.8.102] ([181.202.145.27]) by mx.google.com with ESMTPSA id 197sm11240281qhq.23.2015.07.07.08.13.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Jul 2015 08:13:26 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_670D484C-9E01-4A97-8BFD-3F527C1F52B1" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: John Bradley In-Reply-To: Date: Tue, 7 Jul 2015 12:13:21 -0300 Message-Id: <9E357BFF-E272-48DD-84B1-CC81E3008AAD@ve7jtb.com> References: <901C9552-290C-423C-B9A8-8204824A9131@adobe.com> To: Aaron Parecki X-Mailer: Apple Mail (2.2102) Archived-At: Cc: OAuth WG Subject: Re: [OAUTH-WG] invalid_scope in access token request X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 15:13:30 -0000 --Apple-Mail=_670D484C-9E01-4A97-8BFD-3F527C1F52B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In sec 6 you can send scope to down scope a refresh token. In that case if the client asks for a scope that was not part of the = original code grant then you would return invalid_scope. It is not an error in the spec. Regards John B. > On Jul 7, 2015, at 11:42 AM, Aaron Parecki wrote: >=20 > Section 4.1.1 describes the parameters of the *authorization* request, = not the token request. After the user approves the scope in the = authorization request, the client exchanges the code for the access = token. I'm talking about the token request, where there is no scope = parameter listed, section 4.1.3 = https://tools.ietf.org/html/rfc6749#section-4.1.3 = >=20 > ---- > Aaron Parecki > aaronparecki.com > @aaronpk >=20 >=20 > On Tue, Jul 7, 2015 at 1:08 AM, Antonio Sanso > wrote: > hi Aaron >=20 > On Jul 7, 2015, at 6:23 AM, Aaron Parecki > wrote: >=20 >> Section 5.2 lists the possible errors the authorization server can = return for an access token request. In the list is "invalid_scope", = which as I understand it, can only be returned for a "password" or = "client_credentials" grant, since scope is not a parameter of an = "authorization_code" grant.=20 >=20 > why not :) ? =46rom https://tools.ietf.org/html/rfc6749#section-4.1.1 = =20 >=20 > scope > OPTIONAL. The scope of the access request as described by > Section 3.3 = . > regards >=20 > antonio >=20 >>=20 >> Because of this, I believe the phrase "or exceeds the scope granted = by the resource owner." is unnecessary, since there is no initial grant = by the resource owner. Am I reading this correctly, or is there some = situation I am not thinking of? Thanks! >>=20 >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >>=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=_670D484C-9E01-4A97-8BFD-3F527C1F52B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii In sec 6 you can send scope to down scope a refresh = token.

In that case = if the client asks for a scope that was not part of the original code = grant then you would  return invalid_scope.

It is not an error in the = spec.

Regards
John B.

On = Jul 7, 2015, at 11:42 AM, Aaron Parecki <aaron@parecki.com> = wrote:

Section 4.1.1 describes the parameters of the = *authorization* request, not the token request. After the user approves = the scope in the authorization request, the client exchanges the code = for the access token. I'm talking about the token request, where there = is no scope parameter listed, section 4.1.3 https://tools.ietf.org/html/rfc6749#section-4.1.3

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


On Tue, Jul 7, 2015 at 1:08 = AM, Antonio Sanso <asanso@adobe.com> wrote:
hi Aaron

On Jul 7, 2015, at 6:23 AM, Aaron Parecki <aaron@parecki.com> wrote:

Section 5.2 lists the possible errors the authorization = server can return for an access token request. In the list is = "invalid_scope", which as I understand it, can only be returned for a = "password" or "client_credentials" grant, since scope is not a parameter of an "authorization_code" grant. 

why not :) ? =46rom https://tools.ietf.org/html/rfc6749#section-4.1.1 

 scope
         OPTIONAL.  The scope of the access request as described by
         Section 3.3.
regards

antonio


Because of this, I believe the phrase "or exceeds = the scope granted by the resource owner." is unnecessary, since there is = no initial grant by the resource owner. Am I reading this correctly, or = is there some situation I am not thinking of? Thanks!

----
Aaron Parecki
aaronparecki.com
@aaronpk

 _______________________________________________
OAuth mailing 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=_670D484C-9E01-4A97-8BFD-3F527C1F52B1-- From nobody Tue Jul 7 08:18:13 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4B41A88EF for ; Tue, 7 Jul 2015 08:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.478 X-Spam-Level: X-Spam-Status: No, score=0.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RR0mS9yOpe_V for ; Tue, 7 Jul 2015 08:18:10 -0700 (PDT) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3202C1A88EC for ; Tue, 7 Jul 2015 08:18:10 -0700 (PDT) Received: by ieqy10 with SMTP id y10so136779628ieq.0 for ; Tue, 07 Jul 2015 08:18:09 -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:date :message-id:subject:from:to:cc:content-type; bh=hbYKvMTyIbPi50MtoHj0y2RrexVq66XJV9ztWuZbKFA=; b=d7T4eEQx8lFerx/DADoQshN7DzO1+ScvzK3Kz8ExtkwrCL7zYLj0wJ+M57cin+3DGM m529MR8oTxZQ1d3hIt3BRPSbOR+z2G5JRAxyaEbSCPsTYWYVJ7+AOSC9uiciBK2WpAJe 0XPOUdkzArfSuh8Di+nb9Rkdv/iJRElS5Ak2Q0/TutlzpvCCUHkcB2/KVK4GS27zxhNw ZH+E2pnpYdO1rtDFDSLXXOSMPivHNPiWzV2GXBlPRjc7GeV0Vzip3J92CXNd/ii9cBwX 8HbXizHUAS6EKDH8CkVuW9a+IvxDhN8UWf5jzbIaPtpqXHFzN9yVwNV8EnfI8mKt+oXr Cjdg== X-Gm-Message-State: ALoCoQmjYhjNzWIk8Uap2KY3W86kDUm6Jv/2UTOMqopKTZP7fCbA5gAeGgda5tCQ8c7tVJQIQtD2 X-Received: by 10.50.142.9 with SMTP id rs9mr49424061igb.17.1436282289653; Tue, 07 Jul 2015 08:18:09 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com. [209.85.223.172]) by mx.google.com with ESMTPSA id v3sm12048160igk.1.2015.07.07.08.18.08 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jul 2015 08:18:09 -0700 (PDT) Received: by iecuq6 with SMTP id uq6so136408665iec.2 for ; Tue, 07 Jul 2015 08:18:08 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.59.211 with SMTP id b19mr75970804igr.42.1436282288658; Tue, 07 Jul 2015 08:18:08 -0700 (PDT) Received: by 10.107.32.73 with HTTP; Tue, 7 Jul 2015 08:18:08 -0700 (PDT) In-Reply-To: <9E357BFF-E272-48DD-84B1-CC81E3008AAD@ve7jtb.com> References: <901C9552-290C-423C-B9A8-8204824A9131@adobe.com> <9E357BFF-E272-48DD-84B1-CC81E3008AAD@ve7jtb.com> Date: Tue, 7 Jul 2015 08:18:08 -0700 Message-ID: From: Aaron Parecki To: John Bradley Content-Type: multipart/alternative; boundary=047d7bd757589ce4b5051a4a876f Archived-At: Cc: OAuth WG Subject: Re: [OAUTH-WG] invalid_scope in access token request X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 15:18:12 -0000 --047d7bd757589ce4b5051a4a876f Content-Type: text/plain; charset=UTF-8 Thanks, the refresh grant was the case I was missing. ---- Aaron Parecki aaronparecki.com @aaronpk On Tue, Jul 7, 2015 at 8:13 AM, John Bradley wrote: > In sec 6 you can send scope to down scope a refresh token. > > In that case if the client asks for a scope that was not part of the > original code grant then you would return invalid_scope. > > It is not an error in the spec. > > Regards > John B. > > On Jul 7, 2015, at 11:42 AM, Aaron Parecki wrote: > > Section 4.1.1 describes the parameters of the *authorization* request, not > the token request. After the user approves the scope in the authorization > request, the client exchanges the code for the access token. I'm talking > about the token request, where there is no scope parameter listed, section > 4.1.3 https://tools.ietf.org/html/rfc6749#section-4.1.3 > > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > > On Tue, Jul 7, 2015 at 1:08 AM, Antonio Sanso wrote: > >> hi Aaron >> >> On Jul 7, 2015, at 6:23 AM, Aaron Parecki wrote: >> >> Section 5.2 lists the possible errors the authorization server can >> return for an access token request. In the list is "invalid_scope", which >> as I understand it, can only be returned for a "password" or >> "client_credentials" grant, since scope is not a parameter of an >> "authorization_code" grant. >> >> >> why not :) ? From https://tools.ietf.org/html/rfc6749#section-4.1.1 >> >> scope >> OPTIONAL. The scope of the access request as described by >> Section 3.3 . >> >> regards >> >> antonio >> >> >> Because of this, I believe the phrase "or exceeds the scope granted by >> the resource owner." is unnecessary, since there is no initial grant by the >> resource owner. Am I reading this correctly, or is there some situation I >> am not thinking of? Thanks! >> >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --047d7bd757589ce4b5051a4a876f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, the refresh grant was the case I was missing.= =C2=A0

----
Aaron Parecki
<= div>@aaronpk


On Tue, Jul 7, 2015 at 8:13 AM, John Bradley= <ve7jtb@ve7jtb.com> wrote:
In sec 6 you can send scope to down s= cope a refresh token.

In that case if the client asks fo= r a scope that was not part of the original code grant then you would =C2= =A0return invalid_scope.

It is not an error in the= spec.

Regards
John B.

On Jul 7, 2015, at = 11:42 AM, Aaron Parecki <aaron@parecki.com> wrote:

Sec= tion 4.1.1 describes the parameters of the *authorization* request, not the= token request. After the user approves the scope in the authorization requ= est, the client exchanges the code for the access token. I'm talking ab= out the token request, where there is no scope parameter listed, section 4.= 1.3=C2=A0https://tools.ietf.org/html/rfc6749#section-4.1.3

----
Aa= ron Parecki


On Tue, Jul 7, 2015 at 1:08 AM, Antonio Sans= o <asanso@adobe.com> wrote:
hi Aaron

On Jul 7, 2015, at 6:23 AM, Aaron Parecki <aaron@parecki.com> wrote:

Section 5.2 lists the possible errors the authorization server can ret= urn for an access token request. In the list is "invalid_scope", = which as I understand it, can only be returned for a "password" o= r "client_credentials" grant, since scope is not a parameter of an "authorization_code" grant.=C2=A0

 

 scope
         OPTIONAL.  The scope of the access request as described by
         Section 3.3.
regards

antonio


Because of this, I believe the phrase "or=C2=A0exceeds the scope = granted by the resource owner." is unnecessary, since there is no init= ial grant by the resource owner. Am I reading this correctly, or is there s= ome situation I am not thinking of? Thanks!

----
Aaron Parecki
@aaronpk<= /div>

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


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

--047d7bd757589ce4b5051a4a876f-- From nobody Tue Jul 7 09:10:08 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0831B1A8981; Tue, 7 Jul 2015 09:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHSEf6BzHjft; Tue, 7 Jul 2015 09:10:04 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B5C71A8F46; Tue, 7 Jul 2015 09:09:59 -0700 (PDT) Received: by oiyy130 with SMTP id y130so145265367oiy.0; Tue, 07 Jul 2015 09:09:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CNI8DnGsvklNK1PvsCV6XGfUPCFsb9q1rBPxn2pMvv0=; b=OgCuWeph5TVzxlh5GNJsHzR2O/XlF4BwA8ZI9Snjd0TKzY+eXYsvaFNaLlcKOT5DaZ vxWKQ6ZigaU9AQ0cQmpMSm9LW1zz5oz0Wf8SpinzeBxWeivQY3IXSDqqoWTep6jeb3XN jh9ExhD8MQlzOD1EXYguBjEK6tvG+qPjAMhZqc8i7Q95z3zCvbQIQjDz8w3G+ZNYgJxY J8GHUpL2AGyiCdb7g9QZR9IwcODJiGdDwk/ohkri7eGNcBX1sYUf2qNUUCBMMTe/8FGJ 2lpV26m1KTY2oPUXoYk/hL7IlAqsMPuYn/sw5TqO3oqj9saV5SHyfodinCCuL/t1bXkg GWZA== MIME-Version: 1.0 X-Received: by 10.202.64.195 with SMTP id n186mr4734882oia.53.1436285398562; Tue, 07 Jul 2015 09:09:58 -0700 (PDT) Received: by 10.182.96.66 with HTTP; Tue, 7 Jul 2015 09:09:58 -0700 (PDT) In-Reply-To: <20150707024902.24716.2952.idtracker@ietfa.amsl.com> References: <20150707024902.24716.2952.idtracker@ietfa.amsl.com> Date: Wed, 8 Jul 2015 01:09:58 +0900 Message-ID: From: Nat Sakimura To: Barry Leiba Content-Type: multipart/alternative; boundary=001a113dd1e6fa3cba051a4b404a Archived-At: Cc: draft-ietf-oauth-spop@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-spop.shepherd@ietf.org, The IESG , oauth , draft-ietf-oauth-spop.ad@ietf.org Subject: Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-spop-14: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 16:10:07 -0000 --001a113dd1e6fa3cba051a4b404a Content-Type: text/plain; charset=UTF-8 Thanks Barry, These are the issues that I wanted to discuss with John before making change. -- Section 6.2 -- John has partly addressed your IANA comment already. I needed to check if there was any reason for just doing partly. -- Section 7.2 -- is probably just my oversight. I will deal with it. -- Section 2 -- : I agree with you and I wanted to confirm it with John and other people to commit the change. Cheers, Nat 2015-07-07 11:49 GMT+09:00 Barry Leiba : > Barry Leiba has entered the following ballot position for > draft-ietf-oauth-spop-14: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Version -14 resolves my DISCUSS (and also some of my non-blocking > comments). Thanks very much for considering these and working with me on > them! > > ========================================= > My comment about the IANA Considerations remains. While it's > non-blocking, I still hope you will accept the change I suggest: > > -- Section 6.2 -- > I have the same comment here as in the other OAuth document: please shift > the focus away from telling IANA how to handle tracking of the expert > review, and make the mailing list something that the designated expert(s) > keep track of. Also, please give more instructions to the DEs about what > they should consider when they're evaluating a request (for example, > should they approve all requests, or are there criteria they should > apply?). > > For the first, here's a text change that I suggest we move toward for > this sort of thing: > > OLD > > > NEW > Additional code_challenge_method types for use with the authorization > endpoint are registered using the Specification Required policy > [RFC5226], which includes review of the request by one or more > Designated Experts. The DEs will ensure there is at least a two-week > review of the request on the oauth-ext-review@ietf.org mailing list, > and that any discussion on that list converges before they respond to > the request. To allow for the allocation of values prior to > publication, the Designated Expert(s) may approve registration once > they are satisfied that an acceptable specification will be > published. > > Discussion on the oauth-ext-review@ietf.org mailing list should use > an appropriate subject, such as "Request for PKCE > code_challenge_method: example"). > > The Designated Expert(s) should consider the discussion on the > mailing list, as well as <> when evaluating > registration requests. Denials should include an explanation > and, if applicable, suggestions as to how to make the request > successful. > END > > ========================================= > -- Section 7.2 -- > I find the first first paragraph confusingly worded, and after discussion > with the author I suggest this: > > NEW > Clients MUST NOT downgrade to "plain" after trying the S256 method. > Because servers are required to support S256, an error when S256 is > presented can only mean that the server does not support PKCE at all. > Otherwise, such an error could be indicative of a MITM attacker trying > a downgrade attack. > END > > ========================================= > Finally, there is this comment, which is not a big deal and you should > proceed as you think best: > > -- Section 2 -- > There is no real distinction between STRING and ASCII(STRING), because > STRING is already defined to be ASCII. Using "ASCII(xxx)" only adds > clutter, and a suggest removing it. > > So, for example, that would result in changes such as this: > > OLD > BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) == code_challenge > NEW > BASE64URL-ENCODE(SHA256(code_verifier)) == code_challenge > END > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a113dd1e6fa3cba051a4b404a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Barry,=C2=A0


Thes= e are the issues that I wanted to discuss with John before making change.= =C2=A0

-- Section 6= .2 --=C2=A0John has partly addressed your IANA comment already. I ne= eded=C2=A0
to check if there was any reason for just doing partly= .=C2=A0

-- Section = 7.2 -- is probably just my oversight. I will deal with it.=C2=A0
=

-- Section 2 -- : I agree with you and I wanted to conf= irm it with John and other people to commit the change.=C2=A0
<= div>
Cheers,=C2=A0
=
Nat
=

2015-07-07 11:49 = GMT+09:00 Barry Leiba <barryleiba@computer.org>:
Barry Leiba has entered the following ballot p= osition for
draft-ietf-oauth-spop-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-o= auth-spop/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Version -14 resolves my DISCUSS (and also some of my non-blocking
comments).=C2=A0 Thanks very much for considering these and working with me= on
them!

=C2=A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
My comment about the IANA Considerations remains.=C2=A0 While it's
non-blocking, I still hope you will accept the change I suggest:

-- Section 6.2 --
I have the same comment here as in the other OAuth document: please shift the focus away from telling IANA how to handle tracking of the expert
review, and make the mailing list something that the designated expert(s) keep track of.=C2=A0 Also, please give more instructions to the DEs about w= hat
they should consider when they're evaluating a request (for example, should they approve all requests, or are there criteria they should
apply?).

For the first, here's a text change that I suggest we move toward for this sort of thing:

OLD
<most of Section 6.2>

NEW
=C2=A0 =C2=A0Additional code_challenge_method types for use with the author= ization
=C2=A0 =C2=A0endpoint are registered using the Specification Required polic= y
=C2=A0 =C2=A0[RFC5226], which includes review of the request by one or more=
=C2=A0 =C2=A0Designated Experts.=C2=A0 The DEs will ensure there is at leas= t a two-week
=C2=A0 =C2=A0review of the request on the oauth-ext-review@ietf.org mailing list,
=C2=A0 =C2=A0and that any discussion on that list converges before they res= pond to
=C2=A0 =C2=A0the request.=C2=A0 To allow for the allocation of values prior= to
=C2=A0 =C2=A0publication, the Designated Expert(s) may approve registration= once
=C2=A0 =C2=A0they are satisfied that an acceptable specification will be published.

=C2=A0 =C2=A0Discussion on the oauth-ext-review@ietf.org mailing list should use
=C2=A0 =C2=A0an appropriate subject, such as "Request for PKCE
=C2=A0 =C2=A0code_challenge_method: example").

=C2=A0 =C2=A0The Designated Expert(s) should consider the discussion on the=
=C2=A0 =C2=A0mailing list, as well as <<these other things>> wh= en evaluating
=C2=A0 =C2=A0registration requests.=C2=A0 Denials should include an explana= tion
=C2=A0 =C2=A0and, if applicable, suggestions as to how to make the request<= br> =C2=A0 =C2=A0successful.
END

=C2=A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
-- Section 7.2 --
I find the first first paragraph confusingly worded, and after discussion with the author I suggest this:

NEW
Clients MUST NOT downgrade to "plain" after trying the S256 metho= d.
Because servers are required to support S256, an error when S256 is
presented can only mean that the server does not support PKCE at all.
Otherwise, such an error could be indicative of a MITM attacker trying
a downgrade attack.
END

=C2=A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Finally, there is this comment, which is not a big deal and you should
proceed as you think best:

-- Section 2 --
There is no real distinction between STRING and ASCII(STRING), because
STRING is already defined to be ASCII.=C2=A0 Using "ASCII(xxx)" o= nly adds
clutter, and a suggest removing it.

So, for example, that would result in changes such as this:

OLD
BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) =3D=3D code_challenge
NEW
BASE64URL-ENCODE(SHA256(code_verifier)) =3D=3D code_challenge
END


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



--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation<= br>http://nat.sakimu= ra.org/
@_nat_en
--001a113dd1e6fa3cba051a4b404a-- From nobody Tue Jul 7 09:35:56 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7E91ACE5F for ; Tue, 7 Jul 2015 09:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1q2W6fe0-ZsR for ; Tue, 7 Jul 2015 09:35:53 -0700 (PDT) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 117B61ACE58 for ; Tue, 7 Jul 2015 09:35:48 -0700 (PDT) Received: by ieqy10 with SMTP id y10so138419355ieq.0 for ; Tue, 07 Jul 2015 09:35: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:content-type; bh=alhFLPy78seOeQi4CkNQeExagKhIHcQ7GJJTZYpRSRI=; b=cVBQEidB3GpU0Ch7Gljf9eQycdnTTIigVBwM1hXZ2DqwTxCEH7GmF6tGzqDrn5VKcW K5TVmKfNKnGGk0xZZzwSoXU0VjB7gYdQZji9PVNLZLXySv0C/Ob6Eao/yYPQ0Up9Vdka FPePyE/Km95N87GIytlZfG0GQmqhciWNaA2ypz7YSLPa0npafltQegl1oVS7lUb5zp29 ommU8zXfyWITbBZM6WbMjz4zQHdMP36cA3wKK4Bb2C71xMRX1qCZMiWKLuRTQ0OwYVgg hmrR/kP1GWXRB8AT8OfZrbcItJsnpM4En71KshHrLYpxQTLM/iMxnFqx4kZn3wzFMqOl r4VA== X-Gm-Message-State: ALoCoQlhAyYd7PafpkWOwckQKtA+3O3iIPtxiZ+s2qX7x0T10A29yGePqk4MBZsNegNEdMN46yHb X-Received: by 10.50.50.98 with SMTP id b2mr9256899igo.42.1436286947399; Tue, 07 Jul 2015 09:35:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.64.209 with HTTP; Tue, 7 Jul 2015 09:35:18 -0700 (PDT) In-Reply-To: References: <20150707024902.24716.2952.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Tue, 7 Jul 2015 10:35:18 -0600 Message-ID: To: Nat Sakimura Content-Type: multipart/alternative; boundary=089e0122e7644bbb2a051a4b9d3f Archived-At: Cc: draft-ietf-oauth-spop@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-spop.shepherd@ietf.org, The IESG , Barry Leiba , oauth , draft-ietf-oauth-spop.ad@ietf.org Subject: Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-spop-14: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 16:35:55 -0000 --089e0122e7644bbb2a051a4b9d3f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Regarding the comment on Section 2, I had originally argued for the inclusion of ASCII(xxx) as I felt it was important to avoid potential ambiguity that was in the draft at the time (it wasn't 100% clear to me at the time if the code_verifier was to be base64url decoded as input into the hash or if the ASCII bytes were to be used). However, other content (particularly =C2=A74.1 ) has since changed and removed the potential for the ambiguity I thought might be there. Which is a long way of explaining that I'm okay with Barry's proposed change to Section 2, and occurrences of ASCII(...) throughout, despite it undoing something I'd previously requested. On Tue, Jul 7, 2015 at 10:09 AM, Nat Sakimura wrote: > Thanks Barry, > > > These are the issues that I wanted to discuss with John before making > change. > > -- Section 6.2 -- John has partly addressed your IANA comment already. I > needed > to check if there was any reason for just doing partly. > > -- Section 7.2 -- is probably just my oversight. I will deal with it. > > -- Section 2 -- : I agree with you and I wanted to confirm it with John > and other people to commit the change. > > Cheers, > > Nat > > 2015-07-07 11:49 GMT+09:00 Barry Leiba : > >> Barry Leiba has entered the following ballot position for >> draft-ietf-oauth-spop-14: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htm= l >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Version -14 resolves my DISCUSS (and also some of my non-blocking >> comments). Thanks very much for considering these and working with me o= n >> them! >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> My comment about the IANA Considerations remains. While it's >> non-blocking, I still hope you will accept the change I suggest: >> >> -- Section 6.2 -- >> I have the same comment here as in the other OAuth document: please shif= t >> the focus away from telling IANA how to handle tracking of the expert >> review, and make the mailing list something that the designated expert(s= ) >> keep track of. Also, please give more instructions to the DEs about wha= t >> they should consider when they're evaluating a request (for example, >> should they approve all requests, or are there criteria they should >> apply?). >> >> For the first, here's a text change that I suggest we move toward for >> this sort of thing: >> >> OLD >> >> >> NEW >> Additional code_challenge_method types for use with the authorization >> endpoint are registered using the Specification Required policy >> [RFC5226], which includes review of the request by one or more >> Designated Experts. The DEs will ensure there is at least a two-week >> review of the request on the oauth-ext-review@ietf.org mailing list, >> and that any discussion on that list converges before they respond to >> the request. To allow for the allocation of values prior to >> publication, the Designated Expert(s) may approve registration once >> they are satisfied that an acceptable specification will be >> published. >> >> Discussion on the oauth-ext-review@ietf.org mailing list should use >> an appropriate subject, such as "Request for PKCE >> code_challenge_method: example"). >> >> The Designated Expert(s) should consider the discussion on the >> mailing list, as well as <> when evaluating >> registration requests. Denials should include an explanation >> and, if applicable, suggestions as to how to make the request >> successful. >> END >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> -- Section 7.2 -- >> I find the first first paragraph confusingly worded, and after discussio= n >> with the author I suggest this: >> >> NEW >> Clients MUST NOT downgrade to "plain" after trying the S256 method. >> Because servers are required to support S256, an error when S256 is >> presented can only mean that the server does not support PKCE at all. >> Otherwise, such an error could be indicative of a MITM attacker trying >> a downgrade attack. >> END >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Finally, there is this comment, which is not a big deal and you should >> proceed as you think best: >> >> -- Section 2 -- >> There is no real distinction between STRING and ASCII(STRING), because >> STRING is already defined to be ASCII. Using "ASCII(xxx)" only adds >> clutter, and a suggest removing it. >> >> So, for example, that would result in changes such as this: >> >> OLD >> BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) =3D=3D code_challenge >> NEW >> BASE64URL-ENCODE(SHA256(code_verifier)) =3D=3D code_challenge >> END >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --089e0122e7644bbb2a051a4b9d3f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Regarding the comment on Section 2, I had originally = argued for the inclusion of ASCII(xxx) as I felt it was important to avoid = potential ambiguity that was in the draft at the time (it wasn't 100% c= lear to me at the time if the code_verifier was to be base64url decoded as = input into the hash or if the ASCII bytes were to be used). However, other = content (particularly =C2=A74.1) has since changed and removed the po= tential for the ambiguity I thought might be there.

Whic= h is a long way of explaining that I'm okay with Barry's proposed c= hange to Section 2, and occurrences of ASCII(...) throughout, despite it un= doing something I'd previously requested.=C2=A0

On Tue, Jul 7, 2015 at 1= 0:09 AM, Nat Sakimura <sakimura@gmail.com> wrote:
Thanks Barry,=C2=A0


These are the issues that I wanted to discuss with Joh= n before making change.=C2=A0

-- Section 6.2 --=C2=A0John has partly addressed your IAN= A comment already. I needed=C2=A0
to check if there was any reaso= n for just doing partly.=C2=A0

-- Section 7.2 -- is probably just my oversight. I will deal wi= th it.=C2=A0

-- Section 2 -- : I agree with y= ou and I wanted to confirm it with John and other people to commit the chan= ge.=C2=A0

=
Cheers,=C2=A0

Nat
2015-07-07 11:49 GMT+09:00 Barry Leiba <barryleiba@computer.org>:
= Barry Leiba has entered the following ballot position for
draft-ietf-oauth-spop-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-o= auth-spop/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Version -14 resolves my DISCUSS (and also some of my non-blocking
comments).=C2=A0 Thanks very much for considering these and working with me= on
them!

=C2=A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
My comment about the IANA Considerations remains.=C2=A0 While it's
non-blocking, I still hope you will accept the change I suggest:

-- Section 6.2 --
I have the same comment here as in the other OAuth document: please shift the focus away from telling IANA how to handle tracking of the expert
review, and make the mailing list something that the designated expert(s) keep track of.=C2=A0 Also, please give more instructions to the DEs about w= hat
they should consider when they're evaluating a request (for example, should they approve all requests, or are there criteria they should
apply?).

For the first, here's a text change that I suggest we move toward for this sort of thing:

OLD
<most of Section 6.2>

NEW
=C2=A0 =C2=A0Additional code_challenge_method types for use with the author= ization
=C2=A0 =C2=A0endpoint are registered using the Specification Required polic= y
=C2=A0 =C2=A0[RFC5226], which includes review of the request by one or more=
=C2=A0 =C2=A0Designated Experts.=C2=A0 The DEs will ensure there is at leas= t a two-week
=C2=A0 =C2=A0review of the request on the oauth-ext-review@ietf.org mailing list, =C2=A0 =C2=A0and that any discussion on that list converges before they res= pond to
=C2=A0 =C2=A0the request.=C2=A0 To allow for the allocation of values prior= to
=C2=A0 =C2=A0publication, the Designated Expert(s) may approve registration= once
=C2=A0 =C2=A0they are satisfied that an acceptable specification will be published.

=C2=A0 =C2=A0Discussion on the oauth-ext-review@ietf.org mailing list should use =C2=A0 =C2=A0an appropriate subject, such as "Request for PKCE
=C2=A0 =C2=A0code_challenge_method: example").

=C2=A0 =C2=A0The Designated Expert(s) should consider the discussion on the=
=C2=A0 =C2=A0mailing list, as well as <<these other things>> wh= en evaluating
=C2=A0 =C2=A0registration requests.=C2=A0 Denials should include an explana= tion
=C2=A0 =C2=A0and, if applicable, suggestions as to how to make the request<= br> =C2=A0 =C2=A0successful.
END

=C2=A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
-- Section 7.2 --
I find the first first paragraph confusingly worded, and after discussion with the author I suggest this:

NEW
Clients MUST NOT downgrade to "plain" after trying the S256 metho= d.
Because servers are required to support S256, an error when S256 is
presented can only mean that the server does not support PKCE at all.
Otherwise, such an error could be indicative of a MITM attacker trying
a downgrade attack.
END

=C2=A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Finally, there is this comment, which is not a big deal and you should
proceed as you think best:

-- Section 2 --
There is no real distinction between STRING and ASCII(STRING), because
STRING is already defined to be ASCII.=C2=A0 Using "ASCII(xxx)" o= nly adds
clutter, and a suggest removing it.

So, for example, that would result in changes such as this:

OLD
BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) =3D=3D code_challenge
NEW
BASE64URL-ENCODE(SHA256(code_verifier)) =3D=3D code_challenge
END


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



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

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


--089e0122e7644bbb2a051a4b9d3f-- From nobody Tue Jul 7 10:49:05 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA121ACEFC for ; Tue, 7 Jul 2015 10:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.754 X-Spam-Level: X-Spam-Status: No, score=-1.754 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvVQsxpIEUoH for ; Tue, 7 Jul 2015 10:49:01 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id B7AE01ACEFB for ; Tue, 7 Jul 2015 10:49:01 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 51FD3B2E020; Tue, 7 Jul 2015 13:49:02 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 378DF72E15D; Tue, 7 Jul 2015 13:49:02 -0400 (EDT) Received: from imshyb01.MITRE.ORG (129.83.29.2) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 7 Jul 2015 13:49:00 -0400 Received: from imshyb02.MITRE.ORG (129.83.29.3) by imshyb01.MITRE.ORG (129.83.29.2) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 7 Jul 2015 13:49:00 -0400 Received: from na01-bl2-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.1044.25 via Frontend Transport; Tue, 7 Jul 2015 13:49:00 -0400 Received: from BY2PR09MB0277.namprd09.prod.outlook.com (10.160.65.20) by BY2PR09MB0659.namprd09.prod.outlook.com (10.162.81.19) with Microsoft SMTP Server (TLS) id 15.1.201.16; Tue, 7 Jul 2015 17:49:00 +0000 Received: from BY2PR09MB0280.namprd09.prod.outlook.com (10.160.65.23) by BY2PR09MB0277.namprd09.prod.outlook.com (10.160.65.20) with Microsoft SMTP Server (TLS) id 15.1.213.14; Tue, 7 Jul 2015 17:48:59 +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.0207.004; Tue, 7 Jul 2015 17:48:59 +0000 From: "Kim, William G" To: Justin Richer , Nat Sakimura Thread-Topic: [OAUTH-WG] Same Origin Method Execution (SOME) Thread-Index: AQHQrrKNUGqwK9xwKk+RnZEBcYFkaZ28UYAAgAC6CYCABpXjAIAAAB8AgAADwwCADHShgA== Date: Tue, 7 Jul 2015 17:48:58 +0000 Message-ID: References: <51B1A21C-4893-403E-AE00-33F4B7827346@adobe.com> <14F3933F-C943-4B7E-8C92-11CB227FB1A7@mit.edu> In-Reply-To: <14F3933F-C943-4B7E-8C92-11CB227FB1A7@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.0.150423 authentication-results: mit.edu; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [192.160.51.86] x-microsoft-exchange-diagnostics: 1; BY2PR09MB0277; 5:tPuevez2BYPNLlq+H+Xkq75WVY3Vt8NU64ob6sONAdarccAcaym0+y3SzAQEGEiYQ4Vx6lfxr6yYGo7DrXbtYWx7reUwOzFuBhCGnhgszXeVgIYse2zMapIOpuj8pGRzN43yJnNZV6oZVRJY0tbapg==; 24:6jrf8ikXQUnQ4O0iP2019JcJ3UcfstOPfcvH+aT1y+Yrzsw3yNjwjbawGqO+hinsCroxgEB/zxJ6hzAZOWOCLDisW93YdcVNX+djctZ4M2k=; 20:0zLBAhDXXvwHm1iGDVd4/a+oR9/ErYBjkOLMhxXS76TcA9+B5CAkseXAw7ndyIT3SmEjLB7UNTrjQFqF4w3EZw== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR09MB0277; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR09MB0659; by2pr09mb0277: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BY2PR09MB0277; BCL:0; PCL:0; RULEID:; SRVR:BY2PR09MB0277; x-forefront-prvs: 0630013541 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(243025005)(377424004)(377454003)(99286002)(4001350100001)(86362001)(106116001)(19617315012)(2656002)(93886004)(2171001)(16297215004)(87936001)(19580405001)(19580395003)(5001770100001)(16236675004)(54356999)(50986999)(102836002)(15975445007)(76176999)(77096005)(2950100001)(46102003)(2900100001)(1600100001)(83506001)(77156002)(40100003)(66066001)(5001920100001)(92566002)(189998001)(36756003)(122556002)(5002640100001)(5001960100002)(62966003); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR09MB0277; H:BY2PR09MB0280.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D1C188FF8FADwkimmitreorg_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2015 17:48:58.6229 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR09MB0277 X-Microsoft-Exchange-Diagnostics: 1; BY2PR09MB0659; 2:QPhDChqaPsGUH7zqzk765eyOBpg69plesoSZ52JVONzzKGDASk1jATEUEQxD8DrY; 3:kh9xwetwuHD4jfON7tdWuRho3q9X9JkBHSNQGedrX79kcKitTCG2MvVgZwj+5NCVU1TROt2LcIA6zKOjPpRKDNXa6dZZtktoZ5VOyRFDYcoAr0GDU3NbNpGfgJ1bNmETQL3ikvla5XDuUq/LRLiPxQ==; 25:JQ5/cJfvMDTuTz7o+NETt2709dkHIzDGGQU/gOTbUQGt9NY2CXERFechEOPAd5AO+A5/EUkS7vJ0ukcitL5+rSzSSf9Dtc8JhJbQRUr+yVgPPNbvgG4LCQYlqgfgLM9LSXsrpRw387nfzKQxox0O1fJR58lJQnQiXJjvW14XTYyC4QcaNLdhATIcwsAy7mXvO/NXDx51WbdqL4WzFQVYfseHYymeAmzAWn0DFQnK3DlMH/WWTcLp9Lul8E3XJ54zvOFJ0EOsRjCrYlT2wq6g/Q==; 20:IScTAC9rmssaUoktkdjaedqZ9jNVKW7dsIKnj3kj3UmCMxE+81V6KDyRocls/kawZRFd5qhI6ZLBY+xVl6i6+Q==; 23:kqU+GVjVPoRREggzxCJMHkhYDBB/iggUuC3vP5iKRJl2TgWadNeSkPeUHM35YT1KJB3A6ZzRB45xAVXUpdCDBUXC2QSzOEJd6e1vTiZc9ul4IDqESj3D53wTT+ItW309sH/txZZ88jydvG5ReOjmCSCBhOGLkwsnBa7U9z5czQB+EruDxFaPHC9qSsscJBW1w6dnoml4h4148zu4KPsF/MRnMFkwvKoeJErGHtYi7lT6JJzYO6i47NVaWrTdAcBu X-OriginatorOrg: mitre.org Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Same Origin Method Execution (SOME) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 17:49:04 -0000 --_000_D1C188FF8FADwkimmitreorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29ycnkgdG8gZGlnIHRoaXMgYmFjayB1cCBidXQgYW0gSSBuYWl2ZSB0byB3b25kZXIgd2h5IGFu eW9uZSB3b3VsZCBldmVuIHVzZSBKU09OUC4gU291bmRzIGxpa2UgdGhlIGhhY2tpZXN0IGxlZ2l0 aW1hdGUgdGhpbmcgSSd2ZSBldmVyIHNlZW4sIGFuZCBhc2tpbmcgZm9yIHRyb3VibGUgdG8gdXNl IGl0Lg0KDQotV2lsbGlhbQ0KDQpGcm9tOiBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8 bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+DQpEYXRlOiBNb25kYXksIEp1bmUgMjksIDIwMTUgYXQg MTE6MzYgQU0NClRvOiBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86c2Fr aW11cmFAZ21haWwuY29tPj4NCkNjOiAiPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRm Lm9yZz4+IiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6 IFJlOiBbT0FVVEgtV0ddIFNhbWUgT3JpZ2luIE1ldGhvZCBFeGVjdXRpb24gKFNPTUUpDQoNClJp Z2h0LCBldmVuIHRob3VnaCBpdOKAmXMgbm90IGFuIE9BdXRoIHByb2JsZW0sIGl04oCZcyBhIHBy b2JsZW0gdGhhdCBpcyBtb3JlIGxpa2VseSB0byBjb21lIHVwIGFuZCBjYXVzZSBkYW1hZ2UgaW4g c2l0dWF0aW9ucyB0aGF0IE9BdXRoIGJyaW5ncyBhYm91dCAodGhlIHBvcC11cCByZWRpcmVjdCBw YWdlIHRoYXQgTmF0IG1lbnRpb25zKS4gU28sIGp1c3QgbGlrZSB0aGUgYWR2aWNlIHRvIHVzZSB0 aGUgc3lzdGVtIGJyb3dzZXIgb24gbW9iaWxlIHBsYXRmb3JtcywgSSB0aGluayBpdOKAmWQgYmUg Z29vZCB0byBoYXZlIGFjdHVhbCBhZHZpY2UgZm9yIGRldmVsb3BlcnMgc28gdGhhdCB0aGV5IGNh biBhdm9pZCBkb2luZyB0aGlzLg0KDQog4oCUIEp1c3Rpbg0KDQpPbiBKdW4gMjksIDIwMTUsIGF0 IDExOjIyIEFNLCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86c2FraW11 cmFAZ21haWwuY29tPj4gd3JvdGU6DQoNCnMvWWVhci9ZZWFoLw0KDQoyMDE1LTA2LTMwIDA6MjIg R01UKzA5OjAwIE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVy YUBnbWFpbC5jb20+PjoNClllYXIsIGZyb20gbXkgc2tpbW1pbmcgb2YgdGhlIHBhcGVyLCBpdCBy ZXF1aXJlcyBhIHBhZ2UgdGhhdCBleGVjdXRlcyBhcmJpdHJhcnkgY2FsbGJhY2sgZnVuY3Rpb24g Z2l2ZW4gYXMgYSBwYXJhbWV0ZXIuDQpJdCBpcyBhYnNvbHV0ZWx5IHN0dXBpZCB0byBkbyBpdCwg YnV0IGFwcGFyZW50bHkgdGhlcmUgYXJlIHN1Y2ggcGFnZXMuDQpQcmltZSBjYW5kaWRhdGUgaGFw cGVucyB0byBiZSBPQXV0aCBSZWRpcmVjdGlvbiBFbmRwb2ludC4NCkJ5IGl0c2VsZiwgaXQgcHJv YmFibHkgd2lsbCBub3QgZG8gbXVjaCBoYXJtIGJlY2F1c2UgeW91IGNhbm5vdCBkbyBtdWNoIHRo aW5ncyBpbiB0aGF0IHdpbmRvdyBpdHNlbGYsDQpidXQgaWYgdGhlIHdpbmRvdyBpcyBhIHBvcC11 cCBhbmQga2VlcHMgYSBwYXJlbnQgY29udGV4dCwgaXQgd2lsbCBlc3NlbnRpYWxseSBiZSBhYmxl IHRvDQpyZW1vdGUgY29udHJvbCB0aGUgcGFyZW50IHdpbmRvdyB0byBkbyBtdWNoIG1vcmUgaGFy bS4NCg0KU28sIGl0IGlzIG5vdCBPQXV0aCBwcm9ibGVtIHBlciBzZS4NCg0KSG93ZXZlciwgaXQg bWF5IGJlIHdvcnRod2hpbGUgdG8gdGVsbCB0aGUgZGV2ZWxvcGVycyB0byBtYWtlIHN1cmUgdGhh dCByZWRpcmVjdGlvbiBlbmRwb2ludA0KYWNjZXB0cyBvbmx5IHZhbGlkIG9hdXRoIHBheWxvYWQs IGFuZCBkbyBub3QgZXhlY3V0ZSBhbnl0aGluZyBpbiB0aGUgcGFyYW1ldGVyLg0KDQpOYXQNCg0K MjAxNS0wNi0yNSAxOTo0OCBHTVQrMDk6MDAgQW50b25pbyBTYW5zbyA8YXNhbnNvQGFkb2JlLmNv bTxtYWlsdG86YXNhbnNvQGFkb2JlLmNvbT4+Og0KaGkgSm9obg0KDQpPbiBKdW4gMjUsIDIwMTUs IGF0IDE6NDIgQU0sIEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0 YkB2ZTdqdGIuY29tPj4gd3JvdGU6DQoNClRoYW5rcyBmb3IgdGhlIGluZm8sDQoNCkFzIEkgcmVh ZCBpdCwgdGhpcyBpcyBhbiBhdHRhY2sgb24gSmF2YSBTY3JpcHQgY2FsbGJhY2tzLg0KDQpUaGUg aW5mb3JtYXRpb24gdHlpbmcgaXQgdG8gT0F1dGggaXMgbm90IGNsZWFyLg0KDQpJcyB0aGUgaXNz dWUgcmVsYXRpbmcgdG8gSlMgcGVvcGxlIHVzaW5nIHRoZSBpbXBsaWNpdCBmbG93IGFuZCB0aGUg SlMgbG9hZGVkIGZyb20gdGhlIGNsaWVudCBzb21laG93IGJlaW5nIHZ1bG5lcmFibGU/DQoNCk9y IGlzIHRoaXMgaGFwcGVuaW5nIGluIHRoZSBKUyBhZnRlciBhdXRob3JpemF0aW9uIGluIGNhbGxz IHRvIG90aGVyIHJlc291cmNlcyBmcm9tIHRoZSBzYW1lIG9yaWdpbiwgYW5kIGl0IGlzIGp1c3Qg Y29pbmNpZGVuY2UgdGhhdCBwZW9wbGUgYXJlIHVzaW5nIE9BdXRoLg0KDQppcyBtb3JlIHRoZSBz ZWNvbmQgb25lIDopIEV4dHJhcG9sYXRpbmcgZnJvbSB0aGUgd2hpdGUgcGFwZXIgWzBdDQoNCiJU aGUgbW9zdCBjb21tb24gdGVjaG5pcXVlIHRhc2tlZCB3aXRoIGZ1bCBsbGluZw0KdGhlIGFib3Zl IGRlc2NyaWJlZCBuZWVkIGlzIE9BdXRoLiBJbiBvcmRlciB0byBnYWluIGFjY2VzcyB0byB0aGly ZC1wYXJ0eSByZXNvdXJjZXMNCnVzaW5nIE9BdXRoLCB0aGUgc2VydmljZSBzaGFsbCB1dGlsaXpl IGEgdGhpcmQtcGFydHkgZW5kcG9pbnQgKE9BdXRoIGRpYWxvZykgdGhhdCB3aWxsDQphc2sgZm9y IHRoZSByZXNvdXJjZSBvd25lcidzIGFwcHJvdmFsLiBUaGUgcHJvYmxlbSB3aXRoIHRoaXMgcHJv Y2VzcyBpcyB0aGF0IHJlZGlyZWN0aW5nDQp0aGUgc2VydmljZSB0byBhbiBPQXV0aCBkaWFsb2cg bWVhbnMgbG9zaW5nIHRoZSBjb250ZW50IG9mIHRoZSBjdXJyZW50bHkgb3BlbiBzZXJ2aWNlDQpk b2N1bWVudC4gRm9yIG92ZXJjb21pbmcgdGhpcyBwcm9ibGVtLCBkZXZlbG9wZXJzIG9wZW4gYSBw b3AtdXAgd2luZG93IHRvIGRpc3BsYXkNCnRoZSBkaWFsb2cgaW4gYSBzaW5ndWxhciBicm93c2lu ZyBjb250ZXh0LiBPbmNlIHRoZSB1c2VyIHBlcm1pdHMgb3IgZGVuaWVzIGFjY2VzcyB0bw0KdGhl IHNlcnZpY2UsIHRoZSBPQXV0aCBkaWFsb2cgcG9wLXVwIHdpbGwgYmUgcmVkaXJlY3RlZCB0byBy ZW5kZXIgYSBjYWxsYmFjayBlbmRwb2ludA0KaG9zdGVkIG9uIHRoZSBzZXJ2aWNlIGRvbWFpbi4g VGhpcyBkb2N1bWVudCBzaG91bGQgZXZlbnR1YWxseSBub3RpZnkgdGhlIHNlcnZpY2UgdGhhdA0K dGhlIHByb2Nlc3MgaGFzIGJlZW4gY29tcGxldGVkLg0KRm9yIHRoZSBuZXcgcG9wLXVwIHdpbmRv dyB0byBub3RpZnkgdGhlIHNlcnZpY2Ugd2luZG93IHVwb24gYXBwcm92YWwsIGRlbmlhbCBvciBm b3INCml0IHRvIHRyYW5zZmVyIGFjY2VzcyB0b2tlbnMgb3Igc2ltaWxhciBkYXRhLCBkZXZlbG9w ZXJzIG1heSBpbXBsZW1lbnQgY2FsbGJhY2sgZW5kcG9pbnRzDQp0aGF0IHVzZSBhIHNjcmlwdCBy ZWZlcmVuY2luZyB0aGUgIm9wZW5lciIgd2luZG93IGZvciBleGVjdXRpbmcgYSBjYWxsYmFjayBt ZXRob2Qgb2YgdGhlDQpzZXJ2aWNlLiBXaGVuIGRldmVsb3BlcnMgYWxzbyBvcHRlZCBmb3IgcHJv dmlkaW5nIHRoZSBzZXJ2aWNlIHdpdGggdGhlIGRlY2lzaW9uIG9uIGhvdw0KdG8gImNhbGwgaXQg YmFjayIgdGhyb3VnaCBhIGNhbGxiYWNrIHBhcmFtZXRlciwgdGhlIGVudGlyZSBkb21haW4gYmVj b21lcyB2dWxuZXJhYmxlIHRvDQpTT01FLiINCg0KcmVnYXJkcw0KDQphbnRvbmlvDQoNClswXSBo dHRwOi8vZmlsZXMuYmVuaGF5YWsuY29tL1NhbWVfT3JpZ2luX01ldGhvZF9FeGVjdXRpb25fX3Bh cGVyLnBkZg0KDQoNClVuZGVyc3RhbmRpbmcgaWYgdGhlcmUgaXMgYW55IE9hdXRoIHNwZWNpZmlj IGFkdmljZSB0byBnaXZlIHdvdWxkIGJlIGhlbHBmdWwuICAgSSBzZWUgdGhlcmUgYXJlIHdheXMg dG8gcHJldmVudCB0aGUgU09NRSBleHBsb2l0Lg0KDQpSZWdhcmRzDQpKb2huIEIuDQoNCg0KT24g SnVuIDI0LCAyMDE1LCBhdCA0OjE4IFBNLCBBbnRvbmlvIFNhbnNvIDxhc2Fuc29AYWRvYmUuY29t PG1haWx0bzphc2Fuc29AYWRvYmUuY29tPj4gd3JvdGU6DQoNCmhpICosIGp1c3Qgc2hhcmluZy4N Cg0KTm90IGRpcmVjdGx5IHJlbGF0ZWQgdG8gT0F1dGggcGVyIHNlIGJ1dCBpdCBleHBsb2l0cyBz ZXZlcmFsIE9BdXRoIGNsaWVudCBlbmRwb2ludHMgZHVlIHRvIHNvbWUgY29tbW9uIGRldmVsb3Bl cnMgcGF0dGVybiBodHRwOi8vd3d3LmJlbmhheWFrLmNvbS8yMDE1LzA2L3NhbWUtb3JpZ2luLW1l dGhvZC1leGVjdXRpb24tc29tZS5odG1sIChjb25jcmV0ZSBleGFtcGxlIGluIGh0dHA6Ly93d3cu YmVuaGF5YWsuY29tLzIwMTUvMDUvc3RlYWxpbmctcHJpdmF0ZS1waG90by1hbGJ1bXMtZnJvbS1H b29nbGUuaHRtbCkNCg0KcmVnYXJkcw0KDQphbnRvbmlvDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRm Lm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86 T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoDQoNCg0KDQoNCi0tDQpOYXQgU2FraW11cmEgKD1uYXQpDQpDaGFpcm1hbiwgT3BlbklEIEZv dW5kYXRpb24NCmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KQF9uYXRfZW4NCg0KDQoNCi0tDQpO YXQgU2FraW11cmEgKD1uYXQpDQpDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24NCmh0dHA6Ly9u YXQuc2FraW11cmEub3JnLw0KQF9uYXRfZW4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1h aWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGgNCg0K --_000_D1C188FF8FADwkimmitreorg_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5Tb3JyeSB0byBk aWcgdGhpcyBiYWNrIHVwIGJ1dCBhbSBJIG5haXZlIHRvIHdvbmRlciB3aHkgYW55b25lIHdvdWxk IGV2ZW4gdXNlIEpTT05QLiBTb3VuZHMgbGlrZSB0aGUgaGFja2llc3QgbGVnaXRpbWF0ZSB0aGlu ZyBJJ3ZlIGV2ZXIgc2VlbiwgYW5kIGFza2luZyBmb3IgdHJvdWJsZSB0byB1c2UgaXQuPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4tV2lsbGlhbTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFj azsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsg UEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBp bjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5v bmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZy b206IDwvc3Bhbj5KdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQu ZWR1Ij5qcmljaGVyQG1pdC5lZHU8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5EYXRlOiA8L3NwYW4+TW9uZGF5LCBKdW5lIDI5LCAyMDE1IGF0IDExOjM2IEFNPGJy Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+TmF0IFNha2ltdXJh ICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIj5zYWtpbXVyYUBnbWFpbC5j b208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFu PiZxdW90OyZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3Jn PC9hPiZndDsmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhA aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJq ZWN0OiA8L3NwYW4+UmU6IFtPQVVUSC1XR10gU2FtZSBPcmlnaW4gTWV0aG9kIEV4ZWN1dGlvbiAo U09NRSk8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i d29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQt bGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClJpZ2h0LCBldmVuIHRo b3VnaCBpdOKAmXMgbm90IGFuIE9BdXRoIHByb2JsZW0sIGl04oCZcyBhIHByb2JsZW0gdGhhdCBp cyBtb3JlIGxpa2VseSB0byBjb21lIHVwIGFuZCBjYXVzZSBkYW1hZ2UgaW4gc2l0dWF0aW9ucyB0 aGF0IE9BdXRoIGJyaW5ncyBhYm91dCAodGhlIHBvcC11cCByZWRpcmVjdCBwYWdlIHRoYXQgTmF0 IG1lbnRpb25zKS4gU28sIGp1c3QgbGlrZSB0aGUgYWR2aWNlIHRvIHVzZSB0aGUgc3lzdGVtIGJy b3dzZXIgb24gbW9iaWxlIHBsYXRmb3JtcywNCiBJIHRoaW5rIGl04oCZZCBiZSBnb29kIHRvIGhh dmUgYWN0dWFsIGFkdmljZSBmb3IgZGV2ZWxvcGVycyBzbyB0aGF0IHRoZXkgY2FuIGF2b2lkIGRv aW5nIHRoaXMuDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4mbmJzcDvigJQgSnVzdGluPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ T24gSnVuIDI5LCAyMDE1LCBhdCAxMToyMiBBTSwgTmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJt YWlsdG86c2FraW11cmFAZ21haWwuY29tIiBjbGFzcz0iIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+ Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+cy9ZZWFyL1llYWgvPC9k aXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Z21haWxfcXVvdGUiPjIwMTUtMDYtMzAgMDoyMiBHTVQmIzQzOzA5OjAwIE5hdCBTYWtpbXVyYSA8 c3BhbiBkaXI9Imx0ciIgY2xhc3M9IiI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOnNha2ltdXJhQGdt YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPnNha2ltdXJhQGdtYWlsLmNvbTwvYT4m Z3Q7PC9zcGFuPjo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUi IHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRk aW5nLWxlZnQ6MWV4Ij4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5Z ZWFyLCBmcm9tIG15IHNraW1taW5nIG9mIHRoZSBwYXBlciwgaXQgcmVxdWlyZXMgYSBwYWdlIHRo YXQgZXhlY3V0ZXMgYXJiaXRyYXJ5IGNhbGxiYWNrIGZ1bmN0aW9uIGdpdmVuIGFzIGEgcGFyYW1l dGVyLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JdCBpcyBhYnNvbHV0ZWx5IHN0dXBpZCB0 byBkbyBpdCwgYnV0IGFwcGFyZW50bHkgdGhlcmUgYXJlIHN1Y2ggcGFnZXMuJm5ic3A7PC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPlByaW1lIGNhbmRpZGF0ZSBoYXBwZW5zIHRvIGJlIE9BdXRoIFJlZGly ZWN0aW9uIEVuZHBvaW50LiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5CeSBpdHNlbGYsIGl0 IHByb2JhYmx5IHdpbGwgbm90IGRvIG11Y2ggaGFybSBiZWNhdXNlIHlvdSBjYW5ub3QgZG8gbXVj aCB0aGluZ3MgaW4gdGhhdCB3aW5kb3cgaXRzZWxmLCZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5idXQgaWYgdGhlIHdpbmRvdyBpcyBhIHBvcC11cCBhbmQga2VlcHMgYSBwYXJlbnQgY29udGV4 dCwgaXQgd2lsbCBlc3NlbnRpYWxseSBiZSBhYmxlIHRvJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNz PSIiPnJlbW90ZSBjb250cm9sIHRoZSBwYXJlbnQgd2luZG93IHRvIGRvIG11Y2ggbW9yZSBoYXJt LiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+U28sIGl0IGlzIG5vdCBPQXV0aCBwcm9ibGVtIHBlciBzZS4mbmJzcDs8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkhvd2V2 ZXIsIGl0IG1heSBiZSB3b3J0aHdoaWxlIHRvIHRlbGwgdGhlIGRldmVsb3BlcnMgdG8gbWFrZSBz dXJlIHRoYXQgcmVkaXJlY3Rpb24gZW5kcG9pbnQmbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ YWNjZXB0cyBvbmx5IHZhbGlkIG9hdXRoIHBheWxvYWQsIGFuZCBkbyBub3QgZXhlY3V0ZSBhbnl0 aGluZyBpbiB0aGUgcGFyYW1ldGVyLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+TmF0PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJoNSI+PGJyIGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjIwMTUtMDYtMjUgMTk6NDggR01UJiM0 MzswOTowMCBBbnRvbmlvIFNhbnNvIDxzcGFuIGRpcj0ibHRyIiBjbGFzcz0iIj4NCiZsdDs8YSBo cmVmPSJtYWlsdG86YXNhbnNvQGFkb2JlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmFz YW5zb0BhZG9iZS5jb208L2E+Jmd0Ozwvc3Bhbj46PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg Y2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6 MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6 YnJlYWstd29yZCIgY2xhc3M9IiI+aGkgSm9obg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBKdW4gMjUs IDIwMTUsIGF0IDE6NDIgQU0sIEpvaG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0 YkB2ZTdqdGIuY29tIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+dmU3anRiQHZlN2p0Yi5jb208 L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNsYXNzPSIiPlRoYW5rcyBmb3IgdGhlIGluZm8sPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KQXMgSSByZWFkIGl0LCB0aGlzIGlzIGFuIGF0dGFjayBvbiBKYXZhIFNjcmlwdCBjYWxs YmFja3MuIDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZSBpbmZvcm1hdGlvbiB0eWlu ZyBpdCB0byBPQXV0aCBpcyBub3QgY2xlYXIuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K SXMgdGhlIGlzc3VlIHJlbGF0aW5nIHRvIEpTIHBlb3BsZSB1c2luZyB0aGUgaW1wbGljaXQgZmxv dyBhbmQgdGhlIEpTIGxvYWRlZCBmcm9tIHRoZSBjbGllbnQgc29tZWhvdyBiZWluZyB2dWxuZXJh YmxlPzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk9yIGlzIHRoaXMgaGFwcGVuaW5nIGlu IHRoZSBKUyBhZnRlciBhdXRob3JpemF0aW9uIGluIGNhbGxzIHRvIG90aGVyIHJlc291cmNlcyBm cm9tIHRoZSBzYW1lIG9yaWdpbiwgYW5kIGl0IGlzIGp1c3QgY29pbmNpZGVuY2UgdGhhdCBwZW9w bGUgYXJlIHVzaW5nIE9BdXRoLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L3NwYW4+aXMgbW9yZSB0aGUgc2Vjb25kIG9u ZSA6KSBFeHRyYXBvbGF0aW5nIGZyb20gdGhlIHdoaXRlIHBhcGVyIFswXTwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPiZxdW90O1RoZSBtb3N0IGNvbW1vbiB0ZWNobmlxdWUgdGFza2VkIHdpdGggZnVsIGxsaW5n PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPnRoZSBhYm92ZSBkZXNjcmliZWQgbmVlZCBpcyBPQXV0aC4g SW4gb3JkZXIgdG8gZ2FpbiBhY2Nlc3MgdG8gdGhpcmQtcGFydHkgcmVzb3VyY2VzPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPnVzaW5nIE9BdXRoLCB0aGUgc2VydmljZSBzaGFsbCB1dGlsaXplIGEgdGhp cmQtcGFydHkgZW5kcG9pbnQgKE9BdXRoIGRpYWxvZykgdGhhdCB3aWxsPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPmFzayBmb3IgdGhlIHJlc291cmNlIG93bmVyJ3MgYXBwcm92YWwuIFRoZSBwcm9ibGVt IHdpdGggdGhpcyBwcm9jZXNzIGlzIHRoYXQgcmVkaXJlY3Rpbmc8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+dGhlIHNlcnZpY2UgdG8gYW4gT0F1dGggZGlhbG9nIG1lYW5zIGxvc2luZyB0aGUgY29udGVu dCBvZiB0aGUgY3VycmVudGx5IG9wZW4gc2VydmljZTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5kb2N1 bWVudC4gRm9yIG92ZXJjb21pbmcgdGhpcyBwcm9ibGVtLCBkZXZlbG9wZXJzIG9wZW4gYSBwb3At dXAgd2luZG93IHRvIGRpc3BsYXk8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+dGhlIGRpYWxvZyBpbiBh IHNpbmd1bGFyIGJyb3dzaW5nIGNvbnRleHQuIE9uY2UgdGhlIHVzZXIgcGVybWl0cyBvciBkZW5p ZXMgYWNjZXNzIHRvPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPnRoZSBzZXJ2aWNlLCB0aGUgT0F1dGgg ZGlhbG9nIHBvcC11cCB3aWxsIGJlIHJlZGlyZWN0ZWQgdG8gcmVuZGVyIGEgY2FsbGJhY2sgZW5k cG9pbnQ8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+aG9zdGVkIG9uIHRoZSBzZXJ2aWNlIGRvbWFpbi4g VGhpcyBkb2N1bWVudCBzaG91bGQgZXZlbnR1YWxseSBub3RpZnkgdGhlIHNlcnZpY2UgdGhhdDwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj50aGUgcHJvY2VzcyBoYXMgYmVlbiBjb21wbGV0ZWQuPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPkZvciB0aGUgbmV3IHBvcC11cCB3aW5kb3cgdG8gbm90aWZ5IHRoZSBz ZXJ2aWNlIHdpbmRvdyB1cG9uIGFwcHJvdmFsLCBkZW5pYWwgb3IgZm9yPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPml0IHRvIHRyYW5zZmVyIGFjY2VzcyB0b2tlbnMgb3Igc2ltaWxhciBkYXRhLCBkZXZl bG9wZXJzIG1heSBpbXBsZW1lbnQgY2FsbGJhY2sgZW5kcG9pbnRzPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPnRoYXQgdXNlIGEgc2NyaXB0IHJlZmVyZW5jaW5nIHRoZSAmcXVvdDtvcGVuZXImcXVvdDsg d2luZG93IGZvciBleGVjdXRpbmcgYSBjYWxsYmFjayBtZXRob2Qgb2YgdGhlPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPnNlcnZpY2UuIFdoZW4gZGV2ZWxvcGVycyBhbHNvIG9wdGVkIGZvciBwcm92aWRp bmcgdGhlIHNlcnZpY2Ugd2l0aCB0aGUgZGVjaXNpb24gb24gaG93PC9kaXY+DQo8ZGl2IGNsYXNz PSIiPnRvICZxdW90O2NhbGwgaXQgYmFjayZxdW90OyB0aHJvdWdoIGEgY2FsbGJhY2sgcGFyYW1l dGVyLCB0aGUgZW50aXJlIGRvbWFpbiBiZWNvbWVzIHZ1bG5lcmFibGUgdG88L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+U09NRS4mcXVvdDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPnJlZ2FyZHM8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPmFudG9uaW88L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlswXSZuYnNwOzxhIGhyZWY9 Imh0dHA6Ly9maWxlcy5iZW5oYXlhay5jb20vU2FtZV9PcmlnaW5fTWV0aG9kX0V4ZWN1dGlvbl9f cGFwZXIucGRmIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cDovL2ZpbGVzLmJlbmhheWFr LmNvbS9TYW1lX09yaWdpbl9NZXRob2RfRXhlY3V0aW9uX19wYXBlci5wZGY8L2E+PC9kaXY+DQo8 c3BhbiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpVbmRlcnN0YW5kaW5n IGlmIHRoZXJlIGlzIGFueSBPYXV0aCBzcGVjaWZpYyBhZHZpY2UgdG8gZ2l2ZSB3b3VsZCBiZSBo ZWxwZnVsLiAmbmJzcDsmbmJzcDtJIHNlZSB0aGVyZSBhcmUgd2F5cyB0byBwcmV2ZW50IHRoZSBT T01FIGV4cGxvaXQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUmVnYXJkczxiciBjbGFz cz0iIj4NCkpvaG4gQi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5PbiBKdW4gMjQsIDIwMTUsIGF0IDQ6 MTggUE0sIEFudG9uaW8gU2Fuc28gJmx0OzxhIGhyZWY9Im1haWx0bzphc2Fuc29AYWRvYmUuY29t IiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+YXNhbnNvQGFkb2JlLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCmhpICosIGp1c3Qgc2hhcmluZy48YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpOb3QgZGlyZWN0bHkgcmVsYXRlZCB0byBPQXV0aCBwZXIg c2UgYnV0IGl0IGV4cGxvaXRzIHNldmVyYWwgT0F1dGggY2xpZW50IGVuZHBvaW50cyBkdWUgdG8g c29tZSBjb21tb24gZGV2ZWxvcGVycyBwYXR0ZXJuDQo8YSBocmVmPSJodHRwOi8vd3d3LmJlbmhh eWFrLmNvbS8yMDE1LzA2L3NhbWUtb3JpZ2luLW1ldGhvZC1leGVjdXRpb24tc29tZS5odG1sIiB0 YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+DQpodHRwOi8vd3d3LmJlbmhheWFrLmNvbS8yMDE1LzA2 L3NhbWUtb3JpZ2luLW1ldGhvZC1leGVjdXRpb24tc29tZS5odG1sPC9hPiAoY29uY3JldGUgZXhh bXBsZSBpbg0KPGEgaHJlZj0iaHR0cDovL3d3dy5iZW5oYXlhay5jb20vMjAxNS8wNS9zdGVhbGlu Zy1wcml2YXRlLXBob3RvLWFsYnVtcy1mcm9tLUdvb2dsZS5odG1sIiB0YXJnZXQ9Il9ibGFuayIg Y2xhc3M9IiI+DQpodHRwOi8vd3d3LmJlbmhheWFrLmNvbS8yMDE1LzA1L3N0ZWFsaW5nLXByaXZh dGUtcGhvdG8tYWxidW1zLWZyb20tR29vZ2xlLmh0bWw8L2E+KTxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCnJlZ2FyZHM8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQphbnRvbmlvPGJy IGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnIgY2xhc3M9IiI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVm PSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5PQXV0aEBp ZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnIgY2xhc3M9IiI+DQo8L2Js b2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+PC9kaXY+DQo8 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpPQXV0aCBt YWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5PQXV0aEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiBy ZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsZWFyPSJhbGwi IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8c3BhbiBjbGFzcz0iSE9FblpiIj48Zm9udCBjb2xvcj0iIzg4ODg4OCIgY2xhc3M9 IiI+LS0gPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5OYXQgU2FraW11cmEgKD1uYXQpDQo8 ZGl2IGNsYXNzPSIiPkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxiciBjbGFzcz0iIj4NCjxh IGhyZWY9Imh0dHA6Ly9uYXQuc2FraW11cmEub3JnLyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIi Pmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzwvYT48YnIgY2xhc3M9IiI+DQpAX25hdF9lbjwvZGl2 Pg0KPC9kaXY+DQo8L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 YnIgY2xhc3M9IiI+DQo8YnIgY2xlYXI9ImFsbCIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KLS0gPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxf c2lnbmF0dXJlIj5OYXQgU2FraW11cmEgKD1uYXQpDQo8ZGl2IGNsYXNzPSIiPkNoYWlybWFuLCBP cGVuSUQgRm91bmRhdGlvbjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHA6Ly9uYXQuc2FraW11 cmEub3JnLyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHA6Ly9uYXQuc2FraW11cmEub3Jn LzwvYT48YnIgY2xhc3M9IiI+DQpAX25hdF9lbjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0K T0F1dGggbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGll dGYub3JnIiBjbGFzcz0iIj5PQXV0aEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D1C188FF8FADwkimmitreorg_-- From nobody Tue Jul 7 12:18:50 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27D21A8783 for ; Tue, 7 Jul 2015 12:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8VDuJlxCFwP for ; Tue, 7 Jul 2015 12:18:48 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C5AC1A8731 for ; Tue, 7 Jul 2015 12:18:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id EFD562072F; Tue, 7 Jul 2015 15:18:27 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srVxEiFaYIG1; Tue, 7 Jul 2015 15:18:27 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-65-96-232-173.hsd1.ma.comcast.net [65.96.232.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 7 Jul 2015 15:18:27 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6956588C32; Tue, 7 Jul 2015 15:18:46 -0400 (EDT) From: Sam Hartman To: Justin Richer References: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> <55928DB3.7090300@gmail.com> <5593C270.7000008@gmail.com> <5593DA7D.80401@mit.edu> <5593E5FD.3050403@gmail.com> <559A676F.3070008@gmail.com> <2BB85061-F141-478C-96B1-5086AFDA1F4F@oracle.com> <559B176F.90105@mit.edu> Date: Tue, 07 Jul 2015 15:18:46 -0400 In-Reply-To: <559B176F.90105@mit.edu> (Justin Richer's message of "Mon, 06 Jul 2015 20:03:59 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 19:18:49 -0000 Speaking as someone who is reasonably familiar with Kerberos and the general concepts involved, I find both Microsoft/Kerberos technology ((constrained delegation/protocol transition) and the ws-trust text horribly confusing and would recommend against all of the above as examples of clarity. After several years I've finally gotten to a point where I understand the Kerberos terms, but that's simply by using them regularly, not because there was clarity. This may be a case where new terminology is worthwhile if you can find something that multiple people (especially new readers not overly familiar with the concepts) find to be clear. From nobody Tue Jul 7 12:43:35 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D62D1A8898 for ; Tue, 7 Jul 2015 12:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynk2pWle6zye for ; Tue, 7 Jul 2015 12:43:31 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 592F21A88A3 for ; Tue, 7 Jul 2015 12:43:31 -0700 (PDT) Received: by wgjx7 with SMTP id x7so176967868wgj.2 for ; Tue, 07 Jul 2015 12:43: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:content-type; bh=TmPJt4wuoxPIK7s+U51LUcZKvkDTiY7novUYZLx6nns=; b=UDpRcwO3lKlf5QRCP/Yepgz935n7U1Z6E3FjNXdtgKkvrhI2CZMs8UNgq28VkMMh5N JVlPC7dFQLqbnOECp+Or7m7eTNk6AlKdisM4RK8fnEM0dz4lNfAiOxd2XmsNzsv9/NDY X0PmCE5YBd21XaPehdOpnpjYr+t7pft2Sh787lidLa9Yy8x05gbCsK5eKWejwBlOy5+S RrqeFqkPXrH8xNwRMq4NuWHClnvJfjgIWxXC1CI++Fyyuwk0oVbLIU7a8sOnBQCGghUs sCQoAL6pMoQn6BochrvTKX5phv9WEHQkdSOixaT7dBH61MJufeVtUaWk4gzIlCV4HZTI zvpw== MIME-Version: 1.0 X-Received: by 10.180.9.75 with SMTP id x11mr63694943wia.80.1436298210094; Tue, 07 Jul 2015 12:43:30 -0700 (PDT) Received: by 10.28.31.194 with HTTP; Tue, 7 Jul 2015 12:43:29 -0700 (PDT) In-Reply-To: References: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> <55928DB3.7090300@gmail.com> <5593C270.7000008@gmail.com> <5593DA7D.80401@mit.edu> <5593E5FD.3050403@gmail.com> <559A676F.3070008@gmail.com> <2BB85061-F141-478C-96B1-5086AFDA1F4F@oracle.com> <559B176F.90105@mit.edu> Date: Tue, 7 Jul 2015 15:43:29 -0400 Message-ID: From: Kathleen Moriarty To: Sam Hartman Content-Type: multipart/alternative; boundary=001a11c241369ab657051a4e3c98 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 19:43:33 -0000 --001a11c241369ab657051a4e3c98 Content-Type: text/plain; charset=UTF-8 I'm just catching up on this tread, but would appreciate an in-room discussion on this topic that doesn't assume the adopted draft has the agreed upon approach as I am not reading that there is consensus on that approach in this thread at all. Could we see presentations on Mike's draft and Brian's? Justin, do you agree that Brian's draft covers the use case in our draft as was implied in this thread? I'd like to see a discussion guided by the chairs to see if we can find a go-forward plan. There seems to be differing opinions and maybe a pull towards simpler approaches that extend Oauth. Thank you. On Tue, Jul 7, 2015 at 3:18 PM, Sam Hartman wrote: > Speaking as someone who is reasonably familiar with Kerberos and the > general concepts involved, I find both Microsoft/Kerberos technology > ((constrained delegation/protocol transition) and the ws-trust text > horribly confusing and would recommend against all of the above as > examples of clarity. > After several years I've finally gotten to a point where I understand > the Kerberos terms, but that's simply by using them regularly, not > because there was clarity. > > > This may be a case where new terminology is worthwhile if you can find > something that multiple people (especially new readers not overly > familiar with the concepts) find to be clear. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Best regards, Kathleen --001a11c241369ab657051a4e3c98 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm just catching up on this tread, but would apprecia= te an in-room discussion on this topic that doesn't assume the adopted = draft has the agreed upon approach as I am not reading that there is consen= sus on that approach in this thread at all.

Could we see= presentations on Mike's draft and Brian's?=C2=A0 Justin, do you ag= ree that Brian's draft covers the use case in our draft as was implied = in this thread? =C2=A0

I'd like to see a discu= ssion guided by the chairs to see if we can find a go-forward plan.=C2=A0 T= here seems to be differing opinions and maybe a pull towards simpler approa= ches that extend Oauth.

Thank you.

On Tue, Jul 7, 2015 a= t 3:18 PM, Sam Hartman <hartmans-ietf@mit.edu> wrote:
Speaking as someone who is reasonably famil= iar with Kerberos and the
general concepts involved, I find both Microsoft/Kerberos technology
((constrained delegation/protocol transition) and the ws-trust text
horribly confusing and would recommend against all of the above as
examples of clarity.
After several years I've finally gotten to a point where I understand the Kerberos terms, but that's simply by using them regularly, not
because there was clarity.


This may be a case where new terminology is worthwhile if you can find
something that multiple people (especially new readers not overly
familiar with the concepts) find to be clear.

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



--
=

Best regards,
Kathleen
--001a11c241369ab657051a4e3c98-- From nobody Tue Jul 7 12:44:05 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D016C1A88A5 for ; Tue, 7 Jul 2015 12:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwBmkgI78IcC for ; Tue, 7 Jul 2015 12:44:02 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::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 0705C1A8898 for ; Tue, 7 Jul 2015 12:44:02 -0700 (PDT) Received: by wgfr2 with SMTP id r2so22162919wgf.1 for ; Tue, 07 Jul 2015 12:44:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a72PbpGCtLFdGYbzx/fnVrvcd3dHQIkAYwSYFloFgBs=; b=wiAZ42ltrPH8fcZWCOBrNhaw3IUfos+i7h/2I1FEhVlJrCdRu+uANuA6LvHRfWYSmf ujNGHn7wASjZ08X0Kgn4mW6EGhJNX9cF2ABHIaFL1Yy5JfAhtpHAeNhUyyMg0kSiV++7 w3oldyMCzMZIVdRadGSVrV1eZU7YGyn8V6dNc0K+q8QJY6nTeLaLFMVUoTuzUFcScX6w FjOn+5M7zsi4wz4CWBCUtsvBBb30YasSMSlTd8s7sCsRVch0ZXJIPBlMavhLiyVfSHoy vKZF914Xg6vBu+KcjEYPPFnySEOmcVJJrjigZomet3rvHCQ3Hhs75grpM6vOCnS4yd2Q M7ZA== MIME-Version: 1.0 X-Received: by 10.180.95.67 with SMTP id di3mr65722754wib.78.1436298240637; Tue, 07 Jul 2015 12:44:00 -0700 (PDT) Received: by 10.28.31.194 with HTTP; Tue, 7 Jul 2015 12:44:00 -0700 (PDT) In-Reply-To: References: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> <55928DB3.7090300@gmail.com> <5593C270.7000008@gmail.com> <5593DA7D.80401@mit.edu> <5593E5FD.3050403@gmail.com> <559A676F.3070008@gmail.com> <2BB85061-F141-478C-96B1-5086AFDA1F4F@oracle.com> <559B176F.90105@mit.edu> Date: Tue, 7 Jul 2015 15:44:00 -0400 Message-ID: From: Kathleen Moriarty To: Sam Hartman Content-Type: multipart/alternative; boundary=f46d044287e26cc1dc051a4e3ed0 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 19:44:05 -0000 --f46d044287e26cc1dc051a4e3ed0 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 7, 2015 at 3:43 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > I'm just catching up on this tread, but would appreciate an in-room > discussion on this topic that doesn't assume the adopted draft has the > agreed upon approach as I am not reading that there is consensus on that > approach in this thread at all. > > Could we see presentations on Mike's draft and Brian's? Justin, do you > agree that Brian's draft covers the use case in our draft as was implied in > this thread? > s/our/your/ :-) > > I'd like to see a discussion guided by the chairs to see if we can find a > go-forward plan. There seems to be differing opinions and maybe a pull > towards simpler approaches that extend Oauth. > > Thank you. > > On Tue, Jul 7, 2015 at 3:18 PM, Sam Hartman wrote: > >> Speaking as someone who is reasonably familiar with Kerberos and the >> general concepts involved, I find both Microsoft/Kerberos technology >> ((constrained delegation/protocol transition) and the ws-trust text >> horribly confusing and would recommend against all of the above as >> examples of clarity. >> After several years I've finally gotten to a point where I understand >> the Kerberos terms, but that's simply by using them regularly, not >> because there was clarity. >> >> >> This may be a case where new terminology is worthwhile if you can find >> something that multiple people (especially new readers not overly >> familiar with the concepts) find to be clear. >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > > -- > > Best regards, > Kathleen > -- Best regards, Kathleen --f46d044287e26cc1dc051a4e3ed0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 7, 2015 at 3:43 PM, Kathleen Moriarty <= ;kath= leen.moriarty.ietf@gmail.com> wrote:
I'm just catching up on this tread, but woul= d appreciate an in-room discussion on this topic that doesn't assume th= e adopted draft has the agreed upon approach as I am not reading that there= is consensus on that approach in this thread at all.

Co= uld we see presentations on Mike's draft and Brian's?=C2=A0 Justin,= do you agree that Brian's draft covers the use case in our draft as wa= s implied in this thread? =C2=A0
s/our/your/ := -)=C2=A0

I'd like to see a discussion guided by the chairs to see if we c= an find a go-forward plan.=C2=A0 There seems to be differing opinions and m= aybe a pull towards simpler approaches that extend Oauth.

Thank you.

On Tue, Jul 7, 2015 at 3:18 PM, Sam Har= tman <hartmans-ietf@mit.edu> wrote:
Speaking as someone who is reasonably familiar with Kerberos= and the
general concepts involved, I find both Microsoft/Kerberos technology
((constrained delegation/protocol transition) and the ws-trust text
horribly confusing and would recommend against all of the above as
examples of clarity.
After several years I've finally gotten to a point where I understand the Kerberos terms, but that's simply by using them regularly, not
because there was clarity.


This may be a case where new terminology is worthwhile if you can find
something that multiple people (especially new readers not overly
familiar with the concepts) find to be clear.

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



<= /div>--

Best regards,
Kathleen



--

Best regards,
Kath= leen
--f46d044287e26cc1dc051a4e3ed0-- From nobody Tue Jul 7 12:51:40 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A9D1A8902 for ; Tue, 7 Jul 2015 12:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQC03I90lgTL for ; Tue, 7 Jul 2015 12:51:36 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46FCB1A8907 for ; Tue, 7 Jul 2015 12:51:36 -0700 (PDT) X-AuditID: 1209190e-f79c76d000002631-a7-559c2dc7e5d3 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 96.64.09777.7CD2C955; Tue, 7 Jul 2015 15:51:35 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t67JpYT0026301; Tue, 7 Jul 2015 15:51:34 -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 t67JpWTM029391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Jul 2015 15:51:33 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_9E5D4639-F0DE-412F-97AA-F203B0EF191C" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Justin Richer In-Reply-To: Date: Tue, 7 Jul 2015 15:51:32 -0400 Message-Id: References: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> <55928DB3.7090300@gmail.com> <5593C270.7000008@gmail.com> <5593DA7D.80401@mit.edu> <5593E5FD.3050403@gmail.com> <559A676F.3070008@gmail.com> <2BB85061-F141-478C-96B1-5086AFDA1F4F@oracle.com> <559B176F.90105@mit.edu> To: Kathleen Moriarty X-Mailer: Apple Mail (2.2098) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBKsWRmVeSWpSXmKPExsUixCmqrHtcd06owc3vXBZf2x6wWTTszLc4 +fYVmwOzx85Zd9k9liz5yeSxcupp9gDmKC6blNSczLLUIn27BK6M/Zva2AsOm1QcOb+dtYGx QbeLkZNDQsBE4s3u6YwQtpjEhXvr2UBsIYHFTBIPHvl3MXIB2RsYJd4u/cEE4TxgktiytROs ilkgQWLRpXmsIDavgJ7Eo6eP2UFsYQFziS1N+8GmsgmoSkxf08IEYnMKBEp8238VzGYRUJE4 9OYHI8QcH4l15zaxQcyxkvj8+RrUFd/ZJDZ89waxRQQsJNY0fwOKcwBdKivxdavcBEaBWUiu mIXkCoi4tsSyha+ZIWxNif3dy1kwxTUkOr9NZF3AyLaKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI 11gvN7NELzWldBMjOAIk+XYwfj2odIhRgINRiYf3hsTsUCHWxLLiytxDjJIcTEqivMJqc0KF +JLyUyozEosz4otKc1KLDzFKcDArifD+VAXK8aYkVlalFuXDpKQ5WJTEeTf94AsREkhPLEnN Tk0tSC2CycpwcChJ8E7QAWoULEpNT61Iy8wpQUgzcXCCDOcBGn4VpIa3uCAxtzgzHSJ/ilFR Spz3IEhCACSRUZoH1wtLUK8YxYFeEeZ9BVLFA0xucN2vgAYzAQ1erjsLZHBJIkJKqoGRP/Fo fIwsq8X9/WrMR1jbRRlWnNff/LSBZ1H/XNMVa1+fvlNg+KjPP2n6obbQt/PkI+5Z/Ow0vKfv yit8LuF+VunPKyvvfWnePeHL81KG1hyZB1fftd6N5VyRWhVj5Kia3/BricPTOTcunMx6dIHz 1NHzi/fP/G+388Y+7wXG11r2BjZl5Ht+VWIpzkg01GIuKk4EAInbilIrAwAA Archived-At: Cc: "" Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 19:51:39 -0000 --Apple-Mail=_9E5D4639-F0DE-412F-97AA-F203B0EF191C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Kathleen, I agree that Brian=E2=80=99s approach covers the use case that drove my = original draft and effectively subsumes my approach. My standing contention with the document as it stands is and has always = been that it=E2=80=99s lacking a general syntactical approach and it = isn=E2=80=99t very OAuth-y. I would love to see a productive = conversation on this front. =E2=80=94 Justin > On Jul 7, 2015, at 3:43 PM, Kathleen Moriarty = wrote: >=20 > I'm just catching up on this tread, but would appreciate an in-room = discussion on this topic that doesn't assume the adopted draft has the = agreed upon approach as I am not reading that there is consensus on that = approach in this thread at all. >=20 > Could we see presentations on Mike's draft and Brian's? Justin, do = you agree that Brian's draft covers the use case in our draft as was = implied in this thread? =20 >=20 > I'd like to see a discussion guided by the chairs to see if we can = find a go-forward plan. There seems to be differing opinions and maybe = a pull towards simpler approaches that extend Oauth. >=20 > Thank you. >=20 > On Tue, Jul 7, 2015 at 3:18 PM, Sam Hartman > wrote: > Speaking as someone who is reasonably familiar with Kerberos and the > general concepts involved, I find both Microsoft/Kerberos technology > ((constrained delegation/protocol transition) and the ws-trust text > horribly confusing and would recommend against all of the above as > examples of clarity. > After several years I've finally gotten to a point where I understand > the Kerberos terms, but that's simply by using them regularly, not > because there was clarity. >=20 >=20 > This may be a case where new terminology is worthwhile if you can find > something that multiple people (especially new readers not overly > familiar with the concepts) find to be clear. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen --Apple-Mail=_9E5D4639-F0DE-412F-97AA-F203B0EF191C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Kathleen,

I= agree that Brian=E2=80=99s approach covers the use case that drove my = original draft and effectively subsumes my approach.

My standing contention = with the document as it stands is and has always been that it=E2=80=99s = lacking a general syntactical approach and it isn=E2=80=99t very = OAuth-y. I would love to see a productive conversation on this = front.

 =E2= =80=94 Justin

On Jul 7, 2015, at 3:43 PM, = Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

I'm just catching up on this = tread, but would appreciate an in-room discussion on this topic that = doesn't assume the adopted draft has the agreed upon approach as I am = not reading that there is consensus on that approach in this thread at = all.

Could we see = presentations on Mike's draft and Brian's?  Justin, do you agree = that Brian's draft covers the use case in our draft as was implied in = this thread?  

I'd like to see a discussion guided by the chairs to see if = we can find a go-forward plan.  There seems to be differing = opinions and maybe a pull towards simpler approaches that extend = Oauth.

Thank = you.

On Tue, Jul 7, 2015 at 3:18 PM, Sam Hartman <hartmans-ietf@mit.edu> = wrote:
Speaking as = someone who is reasonably familiar with Kerberos and the
general concepts involved, I find both Microsoft/Kerberos technology
((constrained delegation/protocol transition) and the ws-trust text
horribly confusing and would recommend against all of the above as
examples of clarity.
After several years I've finally gotten to a point where I understand
the Kerberos terms, but that's simply by using them regularly, not
because there was clarity.


This may be a case where new terminology is worthwhile if you can = find
something that multiple people (especially new readers not overly
familiar with the concepts) find to be clear.

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



--

Best regards,
Kathleen

= --Apple-Mail=_9E5D4639-F0DE-412F-97AA-F203B0EF191C-- From nobody Tue Jul 7 12:59:14 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C3F1A8997 for ; Tue, 7 Jul 2015 12:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3-nvKwyN4gA for ; Tue, 7 Jul 2015 12:59:10 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0780.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::780]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42B901A8996 for ; Tue, 7 Jul 2015 12:59:10 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.213.10; Tue, 7 Jul 2015 19:59:04 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0213.000; Tue, 7 Jul 2015 19:59:04 +0000 From: Mike Jones To: Justin Richer , Kathleen Moriarty Thread-Topic: [OAUTH-WG] JWT Token on-behalf of Use case Thread-Index: AdCvjKZzog4lHzdSReisaGHaz/hQ6gAARPxgAOj5XIAALgFuAAADlXeAAAG2sYAAA+u+gAD0P/SAAAVKOIAAAmBqAAACCAqQAATTnQAAAC6oEAAF0v+AAAWx7oAAKFbzmwAA2pqAAABH+QAAAB0XQA== Date: Tue, 7 Jul 2015 19:59:04 +0000 Message-ID: References: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> <55928DB3.7090300@gmail.com> <5593C270.7000008@gmail.com> <5593DA7D.80401@mit.edu> <5593E5FD.3050403@gmail.com> <559A676F.3070008@gmail.com> <2BB85061-F141-478C-96B1-5086AFDA1F4F@oracle.com> <559B176F.90105@mit.edu> In-Reply-To: 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; x-originating-ip: [2001:4898:80e8:ed31::2] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:uIZBH8Cxw8NHNRtB+i982Q/JPabbnKxXsfSfXjJSEDvVQvV4g7uL+w3xpyuU095F75fRUIiG68IZSh0/TKdd7ftrSxKXTE+kK4aSigdqMn8QRDwKpTsXB+OnEgHW2rQagb/pnMjiOOxH371sNNuVBw==; 24:Zu3ylSUanXs7+5VRX38ziD4VgBTyx2T8mVGaS4289oqGQQVErBt5BulP867dQYIRjlVwVBgxArCWMbZmprX+WR9/Djd89JtXBT26O7Op8U0=; 20:7oa3K6gvbPJ8cXeqL8lhPUYJVEomZ+3VnllycDNcN0/tsDEXrkq4c8oyLJnQejtlKi7s7ZPKR3IiPIUgQih2BA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; by2pr03mb441: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 0630013541 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(5002640100001)(5001960100002)(92566002)(99286002)(189998001)(5003600100002)(77096005)(19609705001)(46102003)(74316001)(19300405004)(19617315012)(16236675004)(93886004)(19580395003)(86612001)(62966003)(2950100001)(54356999)(2900100001)(40100003)(50986999)(76176999)(15975445007)(77156002)(2656002)(19625215002)(2171001)(102836002)(87936001)(19580405001)(86362001)(33656002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4422A0B7854AFC6CB336389F5920BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2015 19:59:04.4627 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 19:59:13 -0000 --_000_BY2PR03MB4422A0B7854AFC6CB336389F5920BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmWxsIHdyaXRlIGEgbm90ZSBsYXRlciB0b2RheSBkZXNjcmliaW5nIGhvdyB0aGUganVzdC1w dWJsaXNoZWQgdXBkYXRlIHRoYXQgbWFrZXMgdGhlIFRva2VuIEV4Y2hhbmdlIGRyYWZ0IHRva2Vu LXR5cGUgYWdub3N0aWMgYWxzbyBlbmFibGVzIGl0IHRvIGJlIHVzZWQgaW4gZnVsbHkg4oCcT0F1 dGh54oCdIGNhc2VzIOKAkyB3aGVyZSBzb21lIG9mIHRoZSB0b2tlbnMgdXNlZCBhcmUgT0F1dGgg YWNjZXNzIHRva2VucyBvciByZWZyZXNoIHRva2Vucy4NCg0KKFJpZ2h0IG5vdyBJ4oCZbSB3cml0 aW5nIHVwIHRoZSBjaGFuZ2VzIG1hZGUgdG8gZHJhZnQtaWV0Zi1vYXV0aC1wcm9vZi1vZi1wb3Nz ZXNzaW9uLCB0aGVuIHdpbGwgZ2V0IHRvIHRoZSBKV0sgVGh1bWJwcmludCBhbmQgVG9rZW4gRXhj aGFuZ2Ugd3JpdGUtdXBz4oCmKQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2hlZXJzLA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0K RnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg SnVzdGluIFJpY2hlcg0KU2VudDogVHVlc2RheSwgSnVseSAwNywgMjAxNSAxMjo1MiBQTQ0KVG86 IEthdGhsZWVuIE1vcmlhcnR5DQpDYzogPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtP QVVUSC1XR10gSldUIFRva2VuIG9uLWJlaGFsZiBvZiBVc2UgY2FzZQ0KDQpLYXRobGVlbiwNCg0K SSBhZ3JlZSB0aGF0IEJyaWFu4oCZcyBhcHByb2FjaCBjb3ZlcnMgdGhlIHVzZSBjYXNlIHRoYXQg ZHJvdmUgbXkgb3JpZ2luYWwgZHJhZnQgYW5kIGVmZmVjdGl2ZWx5IHN1YnN1bWVzIG15IGFwcHJv YWNoLg0KDQpNeSBzdGFuZGluZyBjb250ZW50aW9uIHdpdGggdGhlIGRvY3VtZW50IGFzIGl0IHN0 YW5kcyBpcyBhbmQgaGFzIGFsd2F5cyBiZWVuIHRoYXQgaXTigJlzIGxhY2tpbmcgYSBnZW5lcmFs IHN5bnRhY3RpY2FsIGFwcHJvYWNoIGFuZCBpdCBpc27igJl0IHZlcnkgT0F1dGgteS4gSSB3b3Vs ZCBsb3ZlIHRvIHNlZSBhIHByb2R1Y3RpdmUgY29udmVyc2F0aW9uIG9uIHRoaXMgZnJvbnQuDQoN CiDigJQgSnVzdGluDQoNCk9uIEp1bCA3LCAyMDE1LCBhdCAzOjQzIFBNLCBLYXRobGVlbiBNb3Jp YXJ0eSA8a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb208bWFpbHRvOmthdGhsZWVuLm1v cmlhcnR5LmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQoNCkknbSBqdXN0IGNhdGNoaW5nIHVwIG9u IHRoaXMgdHJlYWQsIGJ1dCB3b3VsZCBhcHByZWNpYXRlIGFuIGluLXJvb20gZGlzY3Vzc2lvbiBv biB0aGlzIHRvcGljIHRoYXQgZG9lc24ndCBhc3N1bWUgdGhlIGFkb3B0ZWQgZHJhZnQgaGFzIHRo ZSBhZ3JlZWQgdXBvbiBhcHByb2FjaCBhcyBJIGFtIG5vdCByZWFkaW5nIHRoYXQgdGhlcmUgaXMg Y29uc2Vuc3VzIG9uIHRoYXQgYXBwcm9hY2ggaW4gdGhpcyB0aHJlYWQgYXQgYWxsLg0KDQpDb3Vs ZCB3ZSBzZWUgcHJlc2VudGF0aW9ucyBvbiBNaWtlJ3MgZHJhZnQgYW5kIEJyaWFuJ3M/ICBKdXN0 aW4sIGRvIHlvdSBhZ3JlZSB0aGF0IEJyaWFuJ3MgZHJhZnQgY292ZXJzIHRoZSB1c2UgY2FzZSBp biBvdXIgZHJhZnQgYXMgd2FzIGltcGxpZWQgaW4gdGhpcyB0aHJlYWQ/DQoNCkknZCBsaWtlIHRv IHNlZSBhIGRpc2N1c3Npb24gZ3VpZGVkIGJ5IHRoZSBjaGFpcnMgdG8gc2VlIGlmIHdlIGNhbiBm aW5kIGEgZ28tZm9yd2FyZCBwbGFuLiAgVGhlcmUgc2VlbXMgdG8gYmUgZGlmZmVyaW5nIG9waW5p b25zIGFuZCBtYXliZSBhIHB1bGwgdG93YXJkcyBzaW1wbGVyIGFwcHJvYWNoZXMgdGhhdCBleHRl bmQgT2F1dGguDQoNClRoYW5rIHlvdS4NCg0KT24gVHVlLCBKdWwgNywgMjAxNSBhdCAzOjE4IFBN LCBTYW0gSGFydG1hbiA8aGFydG1hbnMtaWV0ZkBtaXQuZWR1PG1haWx0bzpoYXJ0bWFucy1pZXRm QG1pdC5lZHU+PiB3cm90ZToNClNwZWFraW5nIGFzIHNvbWVvbmUgd2hvIGlzIHJlYXNvbmFibHkg ZmFtaWxpYXIgd2l0aCBLZXJiZXJvcyBhbmQgdGhlDQpnZW5lcmFsIGNvbmNlcHRzIGludm9sdmVk LCBJIGZpbmQgYm90aCBNaWNyb3NvZnQvS2VyYmVyb3MgdGVjaG5vbG9neQ0KKChjb25zdHJhaW5l ZCBkZWxlZ2F0aW9uL3Byb3RvY29sIHRyYW5zaXRpb24pIGFuZCB0aGUgd3MtdHJ1c3QgdGV4dA0K aG9ycmlibHkgY29uZnVzaW5nIGFuZCB3b3VsZCByZWNvbW1lbmQgYWdhaW5zdCBhbGwgb2YgdGhl IGFib3ZlIGFzDQpleGFtcGxlcyBvZiBjbGFyaXR5Lg0KQWZ0ZXIgc2V2ZXJhbCB5ZWFycyBJJ3Zl IGZpbmFsbHkgZ290dGVuIHRvIGEgcG9pbnQgd2hlcmUgSSB1bmRlcnN0YW5kDQp0aGUgS2VyYmVy b3MgdGVybXMsIGJ1dCB0aGF0J3Mgc2ltcGx5IGJ5IHVzaW5nIHRoZW0gcmVndWxhcmx5LCBub3QN CmJlY2F1c2UgdGhlcmUgd2FzIGNsYXJpdHkuDQoNCg0KVGhpcyBtYXkgYmUgYSBjYXNlIHdoZXJl IG5ldyB0ZXJtaW5vbG9neSBpcyB3b3J0aHdoaWxlIGlmIHlvdSBjYW4gZmluZA0Kc29tZXRoaW5n IHRoYXQgbXVsdGlwbGUgcGVvcGxlIChlc3BlY2lhbGx5IG5ldyByZWFkZXJzIG5vdCBvdmVybHkN CmZhbWlsaWFyIHdpdGggdGhlIGNvbmNlcHRzKSBmaW5kIHRvIGJlIGNsZWFyLg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBs aXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQotLQ0KDQpCZXN0IHJlZ2FyZHMs DQpLYXRobGVlbg0KDQo= --_000_BY2PR03MB4422A0B7854AFC6CB336389F5920BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SeKAmWxsIHdyaXRlIGEgbm90ZSBsYXRlciB0b2RheSBk ZXNjcmliaW5nIGhvdyB0aGUganVzdC1wdWJsaXNoZWQgdXBkYXRlIHRoYXQgbWFrZXMgdGhlIFRv a2VuIEV4Y2hhbmdlIGRyYWZ0IHRva2VuLXR5cGUgYWdub3N0aWMgYWxzbyBlbmFibGVzIGl0IHRv IGJlIHVzZWQgaW4NCiBmdWxseSDigJxPQXV0aHnigJ0gY2FzZXMg4oCTIHdoZXJlIHNvbWUgb2Yg dGhlIHRva2VucyB1c2VkIGFyZSBPQXV0aCBhY2Nlc3MgdG9rZW5zIG9yIHJlZnJlc2ggdG9rZW5z LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+KFJpZ2h0IG5vdyBJ4oCZbSB3cml0aW5nIHVwIHRoZSBjaGFuZ2VzIG1hZGUg dG8gZHJhZnQtaWV0Zi1vYXV0aC1wcm9vZi1vZi1wb3NzZXNzaW9uLCB0aGVuIHdpbGwgZ2V0IHRv IHRoZSBKV0sgVGh1bWJwcmludCBhbmQgVG9rZW4gRXhjaGFuZ2Ugd3JpdGUtdXBz4oCmKTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENoZWVycyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkp1c3RpbiBSaWNoZXI8YnI+DQo8Yj5T ZW50OjwvYj4gVHVlc2RheSwgSnVseSAwNywgMjAxNSAxMjo1MiBQTTxicj4NCjxiPlRvOjwvYj4g S2F0aGxlZW4gTW9yaWFydHk8YnI+DQo8Yj5DYzo8L2I+ICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gSldUIFRva2VuIG9uLWJlaGFsZiBv ZiBVc2UgY2FzZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkthdGhsZWVuLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSBhZ3JlZSB0aGF0IEJyaWFu4oCZcyBhcHByb2FjaCBjb3ZlcnMgdGhlIHVzZSBjYXNlIHRoYXQg ZHJvdmUgbXkgb3JpZ2luYWwgZHJhZnQgYW5kIGVmZmVjdGl2ZWx5IHN1YnN1bWVzIG15IGFwcHJv YWNoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5NeSBzdGFuZGluZyBjb250ZW50aW9uIHdpdGggdGhlIGRvY3VtZW50IGFzIGl0IHN0YW5kcyBp cyBhbmQgaGFzIGFsd2F5cyBiZWVuIHRoYXQgaXTigJlzIGxhY2tpbmcgYSBnZW5lcmFsIHN5bnRh Y3RpY2FsIGFwcHJvYWNoIGFuZCBpdCBpc27igJl0IHZlcnkgT0F1dGgteS4gSSB3b3VsZCBsb3Zl IHRvIHNlZSBhIHByb2R1Y3RpdmUgY29udmVyc2F0aW9uIG9uIHRoaXMgZnJvbnQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO+KAlCBK dXN0aW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g SnVsIDcsIDIwMTUsIGF0IDM6NDMgUE0sIEthdGhsZWVuIE1vcmlhcnR5ICZsdDs8YSBocmVmPSJt YWlsdG86a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb20iPmthdGhsZWVuLm1vcmlhcnR5 LmlldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20ganVzdCBjYXRjaGluZyB1cCBvbiB0aGlzIHRyZWFkLCBi dXQgd291bGQgYXBwcmVjaWF0ZSBhbiBpbi1yb29tIGRpc2N1c3Npb24gb24gdGhpcyB0b3BpYyB0 aGF0IGRvZXNuJ3QgYXNzdW1lIHRoZSBhZG9wdGVkIGRyYWZ0IGhhcyB0aGUgYWdyZWVkIHVwb24g YXBwcm9hY2ggYXMgSSBhbSBub3QgcmVhZGluZyB0aGF0IHRoZXJlIGlzIGNvbnNlbnN1cyBvbiB0 aGF0IGFwcHJvYWNoIGluIHRoaXMgdGhyZWFkDQogYXQgYWxsLjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q291bGQgd2Ugc2VlIHByZXNlbnRhdGlvbnMgb24g TWlrZSdzIGRyYWZ0IGFuZCBCcmlhbidzPyZuYnNwOyBKdXN0aW4sIGRvIHlvdSBhZ3JlZSB0aGF0 IEJyaWFuJ3MgZHJhZnQgY292ZXJzIHRoZSB1c2UgY2FzZSBpbiBvdXIgZHJhZnQgYXMgd2FzIGlt cGxpZWQgaW4gdGhpcyB0aHJlYWQ/ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ2QgbGlrZSB0byBzZWUgYSBkaXNjdXNzaW9uIGd1 aWRlZCBieSB0aGUgY2hhaXJzIHRvIHNlZSBpZiB3ZSBjYW4gZmluZCBhIGdvLWZvcndhcmQgcGxh bi4mbmJzcDsgVGhlcmUgc2VlbXMgdG8gYmUgZGlmZmVyaW5nIG9waW5pb25zIGFuZCBtYXliZSBh IHB1bGwgdG93YXJkcyBzaW1wbGVyIGFwcHJvYWNoZXMgdGhhdCBleHRlbmQgT2F1dGguPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rIHlv dS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gVHVlLCBKdWwgNywgMjAxNSBhdCAzOjE4IFBNLCBTYW0gSGFydG1hbiAmbHQ7PGEgaHJlZj0i bWFpbHRvOmhhcnRtYW5zLWlldGZAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPmhhcnRtYW5zLWll dGZAbWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+U3BlYWtpbmcgYXMgc29tZW9uZSB3aG8gaXMgcmVhc29uYWJseSBmYW1pbGlhciB3aXRo IEtlcmJlcm9zIGFuZCB0aGU8YnI+DQpnZW5lcmFsIGNvbmNlcHRzIGludm9sdmVkLCBJIGZpbmQg Ym90aCBNaWNyb3NvZnQvS2VyYmVyb3MgdGVjaG5vbG9neTxicj4NCigoY29uc3RyYWluZWQgZGVs ZWdhdGlvbi9wcm90b2NvbCB0cmFuc2l0aW9uKSBhbmQgdGhlIHdzLXRydXN0IHRleHQ8YnI+DQpo b3JyaWJseSBjb25mdXNpbmcgYW5kIHdvdWxkIHJlY29tbWVuZCBhZ2FpbnN0IGFsbCBvZiB0aGUg YWJvdmUgYXM8YnI+DQpleGFtcGxlcyBvZiBjbGFyaXR5Ljxicj4NCkFmdGVyIHNldmVyYWwgeWVh cnMgSSd2ZSBmaW5hbGx5IGdvdHRlbiB0byBhIHBvaW50IHdoZXJlIEkgdW5kZXJzdGFuZDxicj4N CnRoZSBLZXJiZXJvcyB0ZXJtcywgYnV0IHRoYXQncyBzaW1wbHkgYnkgdXNpbmcgdGhlbSByZWd1 bGFybHksIG5vdDxicj4NCmJlY2F1c2UgdGhlcmUgd2FzIGNsYXJpdHkuPGJyPg0KPGJyPg0KPGJy Pg0KVGhpcyBtYXkgYmUgYSBjYXNlIHdoZXJlIG5ldyB0ZXJtaW5vbG9neSBpcyB3b3J0aHdoaWxl IGlmIHlvdSBjYW4gZmluZDxicj4NCnNvbWV0aGluZyB0aGF0IG11bHRpcGxlIHBlb3BsZSAoZXNw ZWNpYWxseSBuZXcgcmVhZGVycyBub3Qgb3Zlcmx5PGJyPg0KZmFtaWxpYXIgd2l0aCB0aGUgY29u Y2VwdHMpIGZpbmQgdG8gYmUgY2xlYXIuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N CjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCBy ZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+S2F0aGxlZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_BY2PR03MB4422A0B7854AFC6CB336389F5920BY2PR03MB442namprd_-- From nobody Tue Jul 7 13:23:09 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8C61A8AB8 for ; Tue, 7 Jul 2015 13:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KDvqxp3018c for ; Tue, 7 Jul 2015 13:23:07 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0124.outbound.protection.outlook.com [207.46.100.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58F9D1A8AB7 for ; Tue, 7 Jul 2015 13:23:07 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.213.10; Tue, 7 Jul 2015 20:23:06 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0213.000; Tue, 7 Jul 2015 20:23:06 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Proof-of-Possession Key Semantics for JWTs spec addressing WGLC comments Thread-Index: AdC48rb5Z6Z4jjfaQJG0cBsiuBv0rg== Date: Tue, 7 Jul 2015 20:23:05 +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; x-originating-ip: [2001:4898:80e8:ed31::2] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:0/xB5YW4mK0QrDMhkYQHsdO6MxgD7A5O17cZTUVbQSHZDE87SZ6Np+H9ZnMPi5yqN5SHclayntXvKbl8s5unvbQ9elMLyU7UOkakYjJcBNLncmkTJsz0F9w628nsH5vLRDPF7Mr1udJHEdJpqY9txg==; 24:jRGU9I+HMRYEPuN+gVlrHWwOMTw9ioBdHSfJDLx6MD7VhiDZ7L+DxQKul0J2gUvV/RIsPCcVXKognzljew/2HJEsUh1jxx4UvIoqZcCKn/0=; 20:5/Q2md7n85QSv7vseAkrjPyi6zGOg3mL4bdPAd46HODex5KIwIyhv1/9ZP4hGBBM1lStGPbd6x7k4nAE+dpJwQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; by2pr03mb442: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 0630013541 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(54164003)(86362001)(74316001)(110136002)(107886002)(19609705001)(5001960100002)(2501003)(2900100001)(16236675004)(230783001)(5003600100002)(15975445007)(102836002)(40100003)(46102003)(189998001)(99286002)(5002640100001)(62966003)(86612001)(450100001)(77156002)(92566002)(50986999)(77096005)(54356999)(19300405004)(2351001)(2656002)(33656002)(229853001)(19625215002)(19580395003)(87936001)(19617315012)(3826002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4423239C572063B794BE99BF5920BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2015 20:23:05.9587 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Subject: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing WGLC comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 20:23:09 -0000 --_000_BY2PR03MB4423239C572063B794BE99BF5920BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The editors have published draft-ietf-oauth-proof-of-possession-03, which address= es the working group last call comments received. Thanks to all of you who= provided feedback. The changes were: * Separated the jwk and jwe confirmation members; the former repres= ents a public key as a JWK and the latter represents a symmetric key as a J= WE encrypted JWK. * Changed the title to indicate that a proof-of-possession key is b= eing communicated. * Updated language that formerly assumed that the issuer was an OAu= th 2.0 authorization server. * Described ways that applications can choose to identify the prese= nter, including use of the iss, sub, and azp claims. * Harmonized the registry language with that used in JWT [RFC 7519<= http://tools.ietf.org/html/rfc7519>]. * Addressed other issues identified during working group last call. * Referenced the JWT and JOSE RFCs. The updated specification is available at: * https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-= 03 An HTML formatted version is also available at: * http://self-issued.info/docs/draft-ietf-oauth-proof-of-possession= -03.html -- Mike P.S. This note was also published at http://self-issued.info/?p=3D1406 and= as @selfissued. --_000_BY2PR03MB4423239C572063B794BE99BF5920BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The editors have published draft-ietf-oauth-proof-of-possession-03, which addresses the working gr= oup last call comments received.  Thanks to all of you who provided fe= edback.  The changes were:

·         Separated the jwk and jwe confirmation members; the former represents a public key as a JWK and th= e latter represents a symmetric key as a JWE encrypted JWK.

·         Changed the title to indicate that a proof-o= f-possession key is being communicated.

·         Updated language that formerly assumed that = the issuer was an OAuth 2.0 authorization server.

·         Described ways that applications can choose = to identify the presenter, including use of the iss, sub, and azp claims.

·         Harmonized the registry language with that u= sed in JWT [RFC 7519].

·         Addressed other issues identified during wor= king group last call.

·         Referenced the JWT and JOSE RFCs.=

 

The updated specification is available at:

·         https://tools.ietf.org/html/draft-ietf-= oauth-proof-of-possession-03

 

An HTML formatted version is also available at:=

·         http://self-issued.info/docs/draf= t-ietf-oauth-proof-of-possession-03.html

 

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

 

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

 

--_000_BY2PR03MB4423239C572063B794BE99BF5920BY2PR03MB442namprd_-- From nobody Tue Jul 7 13:40:56 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562031A8F34; Tue, 7 Jul 2015 13:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07VIGchw4Ml5; Tue, 7 Jul 2015 13:40:52 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::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 00B341A6FF2; Tue, 7 Jul 2015 13:40:51 -0700 (PDT) Received: by wgck11 with SMTP id k11so178348434wgc.0; Tue, 07 Jul 2015 13:40:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=x5b8/dB4xnOYQm2w7TD345cjC7dEqu4EqC8zGXjrGxE=; b=BaEmfSxP8W/dJ5Z0Loc+MYvCxSvmWfnpKu+yWLFnShaqvFMS/zHP/S5Yo8BspXR7/i 5tkPT2Fw5Mx+MIQLU8oEM0Or9R8Wc3u9hsm96Z9fltpC6egNFK1By8dHsZgnZuqh0Re9 erm183zY5QSfqkPURw6ceDeAw50xBajB3DNdfF3Iycmaho3mV10Z74MbbiOsoHN0d5DV 3yaZ3ur4ocA8fcLbfuRV+W0w5NQ1Z2n1u7jHgWmtWekKdG1nqLuvR2/WFuR6APQyjYWP KbFXgMWkI1QNTJT3oIwuliW9j2+SVZ0M5hWRvQq0rV9yAIe0Xv80Rp7Hvt3cahEz5oCx qLVQ== MIME-Version: 1.0 X-Received: by 10.194.91.193 with SMTP id cg1mr12313972wjb.86.1436301650766; Tue, 07 Jul 2015 13:40:50 -0700 (PDT) Received: by 10.28.31.194 with HTTP; Tue, 7 Jul 2015 13:40:50 -0700 (PDT) In-Reply-To: References: <20150707024902.24716.2952.idtracker@ietfa.amsl.com> Date: Tue, 7 Jul 2015 16:40:50 -0400 Message-ID: From: Kathleen Moriarty To: Brian Campbell Content-Type: multipart/alternative; boundary=047d7bd907bcaf2ee0051a4f0913 Archived-At: Cc: draft-ietf-oauth-spop@ietf.org, oauth , draft-ietf-oauth-spop.shepherd@ietf.org, The IESG , Barry Leiba , oauth-chairs@ietf.org, draft-ietf-oauth-spop.ad@ietf.org Subject: Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-spop-14: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 20:40:55 -0000 --047d7bd907bcaf2ee0051a4f0913 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for your responses on these comments. I can approve an updated draft to make this change and the one for IANA if that is the easiest path. The other option is to write this all up in an RFC editor note and I can send that with the approval. Making the direct updates may be simpler to avoid mistakes. Can you submit a new version? Thank you, Kathleen On Tue, Jul 7, 2015 at 12:35 PM, Brian Campbell wrote: > Regarding the comment on Section 2, I had originally argued for the > inclusion of ASCII(xxx) as I felt it was important to avoid potential > ambiguity that was in the draft at the time (it wasn't 100% clear to me a= t > the time if the code_verifier was to be base64url decoded as input into t= he > hash or if the ASCII bytes were to be used). However, other content > (particularly =C2=A74.1 > ) has > since changed and removed the potential for the ambiguity I thought might > be there. > > Which is a long way of explaining that I'm okay with Barry's proposed > change to Section 2, and occurrences of ASCII(...) throughout, despite it > undoing something I'd previously requested. > > On Tue, Jul 7, 2015 at 10:09 AM, Nat Sakimura wrote: > >> Thanks Barry, >> >> >> These are the issues that I wanted to discuss with John before making >> change. >> >> -- Section 6.2 -- John has partly addressed your IANA comment already. I >> needed >> to check if there was any reason for just doing partly. >> >> -- Section 7.2 -- is probably just my oversight. I will deal with it. >> >> -- Section 2 -- : I agree with you and I wanted to confirm it with John >> and other people to commit the change. >> >> Cheers, >> >> Nat >> >> 2015-07-07 11:49 GMT+09:00 Barry Leiba : >> >>> Barry Leiba has entered the following ballot position for >>> draft-ietf-oauth-spop-14: No Objection >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to >>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> Version -14 resolves my DISCUSS (and also some of my non-blocking >>> comments). Thanks very much for considering these and working with me = on >>> them! >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> My comment about the IANA Considerations remains. While it's >>> non-blocking, I still hope you will accept the change I suggest: >>> >>> -- Section 6.2 -- >>> I have the same comment here as in the other OAuth document: please shi= ft >>> the focus away from telling IANA how to handle tracking of the expert >>> review, and make the mailing list something that the designated expert(= s) >>> keep track of. Also, please give more instructions to the DEs about wh= at >>> they should consider when they're evaluating a request (for example, >>> should they approve all requests, or are there criteria they should >>> apply?). >>> >>> For the first, here's a text change that I suggest we move toward for >>> this sort of thing: >>> >>> OLD >>> >>> >>> NEW >>> Additional code_challenge_method types for use with the authorizatio= n >>> endpoint are registered using the Specification Required policy >>> [RFC5226], which includes review of the request by one or more >>> Designated Experts. The DEs will ensure there is at least a two-wee= k >>> review of the request on the oauth-ext-review@ietf.org mailing list, >>> and that any discussion on that list converges before they respond t= o >>> the request. To allow for the allocation of values prior to >>> publication, the Designated Expert(s) may approve registration once >>> they are satisfied that an acceptable specification will be >>> published. >>> >>> Discussion on the oauth-ext-review@ietf.org mailing list should use >>> an appropriate subject, such as "Request for PKCE >>> code_challenge_method: example"). >>> >>> The Designated Expert(s) should consider the discussion on the >>> mailing list, as well as <> when evaluating >>> registration requests. Denials should include an explanation >>> and, if applicable, suggestions as to how to make the request >>> successful. >>> END >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> -- Section 7.2 -- >>> I find the first first paragraph confusingly worded, and after discussi= on >>> with the author I suggest this: >>> >>> NEW >>> Clients MUST NOT downgrade to "plain" after trying the S256 method. >>> Because servers are required to support S256, an error when S256 is >>> presented can only mean that the server does not support PKCE at all. >>> Otherwise, such an error could be indicative of a MITM attacker trying >>> a downgrade attack. >>> END >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> Finally, there is this comment, which is not a big deal and you should >>> proceed as you think best: >>> >>> -- Section 2 -- >>> There is no real distinction between STRING and ASCII(STRING), because >>> STRING is already defined to be ASCII. Using "ASCII(xxx)" only adds >>> clutter, and a suggest removing it. >>> >>> So, for example, that would result in changes such as this: >>> >>> OLD >>> BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) =3D=3D code_challenge >>> NEW >>> BASE64URL-ENCODE(SHA256(code_verifier)) =3D=3D code_challenge >>> END >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> >> >> -- >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > --=20 Best regards, Kathleen --047d7bd907bcaf2ee0051a4f0913 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for your responses on these comments.

I can approve an updated draft to make this change and the one for IA= NA if that is the easiest path.=C2=A0 The other option is to write this all= up in an RFC editor note and I can send that with the approval.=C2=A0 Maki= ng the direct updates may be simpler to avoid mistakes.

Can you submit a new version?

Thank you,
Kathleen

On Tue, Jul 7, 2015 at 12:35 PM, Brian Campbell <bcampb= ell@pingidentity.com> wrote:
Regarding the comment on Section 2, I had originall= y argued for the inclusion of ASCII(xxx) as I felt it was important to avoi= d potential ambiguity that was in the draft at the time (it wasn't 100%= clear to me at the time if the code_verifier was to be base64url decoded a= s input into the hash or if the ASCII bytes were to be used). However, othe= r content (particularly =C2=A74.1) has since change= d and removed the potential for the ambiguity I thought might be there.
Which is a long way of explaining that I'm okay with Ba= rry's proposed change to Section 2, and occurrences of ASCII(...) throu= ghout, despite it undoing something I'd previously requested.=C2=A0

On Tue, Jul 7, 2015 at 10:09 AM, Nat Sa= kimura <sakimura@gmail.com> wrote:
Thanks Barry,=C2=A0


<= /div>
These are the issues that I wanted to discuss with John before ma= king change.=C2=A0

= -- Section 6.2 --=C2=A0John has partly addressed your IANA comment a= lready. I needed=C2=A0
to check if there was any reason for just = doing partly.=C2=A0

-- Section 7.2 -- is probably just my oversight. I will deal with it.=C2= =A0

-- Section 2 -- : I agree with you and I = wanted to confirm it with John and other people to commit the change.=C2=A0=

Cheers,=C2=A0

Nat

2015-07-07 11:49 GMT+09:00 Barry Leiba <barryleiba@computer.o= rg>:
Barry Leiba has entere= d the following ballot position for
draft-ietf-oauth-spop-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-o= auth-spop/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Version -14 resolves my DISCUSS (and also some of my non-blocking
comments).=C2=A0 Thanks very much for considering these and working with me= on
them!

=C2=A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
My comment about the IANA Considerations remains.=C2=A0 While it's
non-blocking, I still hope you will accept the change I suggest:

-- Section 6.2 --
I have the same comment here as in the other OAuth document: please shift the focus away from telling IANA how to handle tracking of the expert
review, and make the mailing list something that the designated expert(s) keep track of.=C2=A0 Also, please give more instructions to the DEs about w= hat
they should consider when they're evaluating a request (for example, should they approve all requests, or are there criteria they should
apply?).

For the first, here's a text change that I suggest we move toward for this sort of thing:

OLD
<most of Section 6.2>

NEW
=C2=A0 =C2=A0Additional code_challenge_method types for use with the author= ization
=C2=A0 =C2=A0endpoint are registered using the Specification Required polic= y
=C2=A0 =C2=A0[RFC5226], which includes review of the request by one or more=
=C2=A0 =C2=A0Designated Experts.=C2=A0 The DEs will ensure there is at leas= t a two-week
=C2=A0 =C2=A0review of the request on the oauth-ext-review@ietf.org mailing list, =C2=A0 =C2=A0and that any discussion on that list converges before they res= pond to
=C2=A0 =C2=A0the request.=C2=A0 To allow for the allocation of values prior= to
=C2=A0 =C2=A0publication, the Designated Expert(s) may approve registration= once
=C2=A0 =C2=A0they are satisfied that an acceptable specification will be published.

=C2=A0 =C2=A0Discussion on the oauth-ext-review@ietf.org mailing list should use =C2=A0 =C2=A0an appropriate subject, such as "Request for PKCE
=C2=A0 =C2=A0code_challenge_method: example").

=C2=A0 =C2=A0The Designated Expert(s) should consider the discussion on the=
=C2=A0 =C2=A0mailing list, as well as <<these other things>> wh= en evaluating
=C2=A0 =C2=A0registration requests.=C2=A0 Denials should include an explana= tion
=C2=A0 =C2=A0and, if applicable, suggestions as to how to make the request<= br> =C2=A0 =C2=A0successful.
END

=C2=A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
-- Section 7.2 --
I find the first first paragraph confusingly worded, and after discussion with the author I suggest this:

NEW
Clients MUST NOT downgrade to "plain" after trying the S256 metho= d.
Because servers are required to support S256, an error when S256 is
presented can only mean that the server does not support PKCE at all.
Otherwise, such an error could be indicative of a MITM attacker trying
a downgrade attack.
END

=C2=A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Finally, there is this comment, which is not a big deal and you should
proceed as you think best:

-- Section 2 --
There is no real distinction between STRING and ASCII(STRING), because
STRING is already defined to be ASCII.=C2=A0 Using "ASCII(xxx)" o= nly adds
clutter, and a suggest removing it.

So, for example, that would result in changes such as this:

OLD
BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) =3D=3D code_challenge
NEW
BASE64URL-ENCODE(SHA256(code_verifier)) =3D=3D code_challenge
END


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



<= font color=3D"#888888">--
Nat Sakimura (=3Dnat)
Chairman, Open= ID Foundation
htt= p://nat.sakimura.org/
@_nat_en

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





--
=

Best regards,
Kathleen
--047d7bd907bcaf2ee0051a4f0913-- From nobody Tue Jul 7 15:04:22 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7C01AD49F for ; Tue, 7 Jul 2015 15:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2siYiMB5CIX4 for ; Tue, 7 Jul 2015 15:04:19 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0769.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:769]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 578ED1AD49D for ; Tue, 7 Jul 2015 15:04:19 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.213.10; Tue, 7 Jul 2015 22:03:57 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0213.000; Tue, 7 Jul 2015 22:03:57 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth 2.0 Token Exchange -02 enabling use of any token type Thread-Index: AdC5ANG2UcHTxTZUQvWbWy8cFY9Ccw== Date: Tue, 7 Jul 2015 22:03:56 +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; x-originating-ip: [2001:4898:80e8:ed31::2] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:4inlDnVfgiqYNySL0EI9L4hqAmL1nQtG1bgGjcFjEFKxg8kwg+m7hq7czlwVU2kgxhv6wjZLLJvkkddFzrMDVhugpkNXcaCYnaGmR+fPkVM2fo5TTRQhRjkgbWPbdlvY/5Jmmf8R6DD2Tmx2oKmf4A==; 24:WmLHehIpbjzxjZbHbVIjL36VhAZBaaCgXQm9YGBCbmHyLNwGiSCWYt7dDMu2WFq7r8D2/e3NmxYOD5673AJOH8LNeKkFoAluGw8tLAOjlMo=; 20:ohmicXc6M3IuYTmj/PqZGBuRZ5FxS/Er07YzpZOj9pPEUKGr5b7QzrcJVS8nrxRlkMLim/iXfSpkgOJBeyFoQg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; by2pr03mb442: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 0630013541 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(77096005)(54356999)(50986999)(19300405004)(77156002)(92566002)(86612001)(450100001)(62966003)(19625215002)(19617315012)(87936001)(19580395003)(33656002)(2656002)(2351001)(2501003)(2900100001)(16236675004)(229853001)(86362001)(5001960100002)(110136002)(74316001)(107886002)(19609705001)(40100003)(102836002)(15975445007)(5002640100001)(46102003)(189998001)(99286002)(5003600100002)(3826002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442E408EAD89D8607CBEAA2F5920BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2015 22:03:57.0097 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Subject: [OAUTH-WG] OAuth 2.0 Token Exchange -02 enabling use of any token type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 22:04:21 -0000 --_000_BY2PR03MB442E408EAD89D8607CBEAA2F5920BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft -02 of the OAuth 2.0 Token Exchange specification has been published,= making the functionality token type independent. Formerly, only JSON Web = Tokens (JWTs) could be used in some contexts. This was a change requested = by working group participants during IETF 92 in Dallas. The specification is available at: * https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02 An HTML formatted version is also available at: * http://self-issued.info/docs/draft-ietf-oauth-token-exchange-02.h= tml -- Mike P.S. This note was also published at http://self-issued.info/?p=3D1412 and= as @selfissued. --_000_BY2PR03MB442E408EAD89D8607CBEAA2F5920BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Draft -02 of the OAuth 2.0 Token Exchange specificat= ion has been published, making the functionality token type independent.&nb= sp; Formerly, only JSON Web Tokens (JWTs) could be used in some contexts.&n= bsp; This was a change requested by working group participants during IETF 92 in Dallas.

 

The specification is available at:

·         https://tools.ietf.org/html/draft-ietf-oauth= -token-exchange-02

 

An HTML formatted version is also available at:=

·         http://self-issued.info/docs/draft-iet= f-oauth-token-exchange-02.html

 

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

 

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

 

--_000_BY2PR03MB442E408EAD89D8607CBEAA2F5920BY2PR03MB442namprd_-- From nobody Tue Jul 7 15:52:10 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD6A1B2A1E for ; Tue, 7 Jul 2015 15:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hp_IqaW5tVlx for ; Tue, 7 Jul 2015 15:52:06 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0109.outbound.protection.outlook.com [207.46.100.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A97E1B2A1D for ; Tue, 7 Jul 2015 15:52:06 -0700 (PDT) Received: from BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) by BY2PR03MB1143.namprd03.prod.outlook.com (10.242.239.21) with Microsoft SMTP Server (TLS) id 15.1.195.15; Tue, 7 Jul 2015 22:51:40 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.213.10; Tue, 7 Jul 2015 22:51:32 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0213.000; Tue, 7 Jul 2015 22:51:32 +0000 From: Mike Jones To: Brian Campbell , Justin Richer Thread-Topic: [OAUTH-WG] Token Chaining Use Case Thread-Index: AQHQZ/MY5K5Dp0IvikmgQJJzAhL8fZ0vVM6AgKHjaSA= Date: Tue, 7 Jul 2015 22:51:32 +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: pingidentity.com; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e8:ed31::2] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:v7dcZQwn7mNgLK6CnfXztSIOXZ/yO0qwmLM4FfDIccXJDlih9Uk6w8TR1ILaV7xKpF6drttLMUNf+lG8XAaF/VcU41BckrLlKoAVXlTIF8aCWxVnWhY+f/FS9ktcY3uP7Eb9JS11qpVSALmdFpdfXw==; 24:2DpDAmB8GEVip1jN6q04vaRMkt6qcK7Olal52bL2FpNzt1y9uhbDNN2Va7pQUtI0Ac06LLZoXQWDlvGoPiYJRwjt9IqewFvsT/Kgia6f8bA=; 20:NT0mVsRHxcCjOCjM87oJ2Ba9vokHH7R0B+Ddn3p6M14EFwjgyQ+XjA1HgFpiURoiqNOU/B9DB71IOfl8T4lfjQ== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB1143; by2pr03mb443: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 0630013541 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(24454002)(377454003)(189998001)(19580405001)(19625215002)(92566002)(40100003)(77096005)(15975445007)(77156002)(62966003)(102836002)(5001960100002)(16236675004)(33656002)(54356999)(5003600100002)(86362001)(76176999)(86612001)(50986999)(19300405004)(74316001)(46102003)(99286002)(2950100001)(2656002)(106116001)(19609705001)(5002640100001)(2171001)(2900100001)(87936001)(19580395003)(19617315012)(3826002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442F6D96703377B6673509AF5920BY2PR03MB442namprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2015 22:51:32.4689 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 X-Microsoft-Exchange-Diagnostics: 1; BY2PR03MB1143; 2:gXJ4aYmKRakEQiXFlEaQBQzKPKJfRFOY+X7R1w1TVwD52J4hKRRej/WXErRd8VF0; 3:ZE7md2Wz2icO0GQLPacZFgk1GL3XoabGs5tTsaz60IRsQMOofIciRjHZ+y3TwqKCpyuVMS3k8jp5wuqxR6MjgCmKpA54ulM2KEm6fEz4TKEqUPSb47/CIte20CNI6xTdKgJ1hKIRwCmf7xKhFDNG8g==; 20:PJ7YD4uwn/qhS+AfxAFAGO/XclyiUTaq9s7nnERi0Mc5g+dpNmxf/9of+R7ezFBankAAjwbNLyjwBcmd+uI+iHKb5uTZ177sW2mbs9J+pIFzh7n5RmAhsOGS9srHlgm6uL/+Cd1gdFim6m9zZV6DeLBcaPnD4C6otSccW9UkRJagXFaHxCjPd+jvwDJN7HUSYNFNn1oVYC45WPP8Qm5BP5iQMxMSDTznZXjkon/fkVm+XKfgOgF0/iAKIdo25dRqNPNp0A/d04l/ARYXZpJuD2M27/MEC7+qw0cDzqjsHLRtKauINV7FbyOUg2MjEyM1OsCSaV4rHTn6jszXrQcgQOLzjyZovQ0fTJ8EsZ2rgL5moyVpBMFh6Zw8KeW8w+L6wYA6gcmCv5S8gJmOEBAMsBIxnCyQWocdLtHgY1zJbKtvrZgMIu81FyD+ARLH2k+bmGM+KE9yp9J39ExkavXJld9M32M7ah3eL5fLtvUTYP8wBKq6sn5ceGTWqi2UDRiG X-Microsoft-Exchange-Diagnostics: 1; BY2PR03MB1143; 23://+3DPdpjiRW48dKOjtYwi4Npfhtez2RUIwTuQKbalChZP1HngXRf1RyQ9vPF1/ohWK/vflf3GnXDyJAbBxLAbD0Kt36s88aKeJ7fva5KasoaMtzW9PCyO1aG4NUyszVSGAbNgmafjGRr59x0RswMEHFpjlcpemkJtV2vrxJ2N2xyJ9dOXK8cEaRa4yQUKhC1OhJl/XIligAxgc7w269CtpVsSR/OH+rvzRd7iWRndX7hE9aTgXOtJrtPQA8JTX8 X-OriginatorOrg: microsoft.com Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Token Chaining Use Case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 22:52:09 -0000 --_000_BY2PR03MB442F6D96703377B6673509AF5920BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMganVzdCB1cGRhdGVkPGh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvLz9wPTE0MTI+LCBJIGJlbGll dmUgdGhhdCB0aGUgd29ya2luZyBncm91cCB0b2tlbiBleGNoYW5nZSBkcmFmdCBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZS0wMiBjYW4g bm93IGFsc28gc2VydmUgdGhlIOKAnE9BdXRoeeKAnSB0b2tlbiBleGNoYW5nZSB1c2UgY2FzZXMs IHN1Y2ggYXMgSnVzdGluIGFuZCBQaGls4oCZcyB0b2tlbiBjaGFpbmluZyB1c2UgY2FzZSwgYXMg d2VsbCBhcyBzdXBwb3J0IGdlbmVyYWwgdG9rZW4gZXhjaGFuZ2UsIGluY2x1ZGluZyBleGNoYW5n ZSBvZiBKV1QgYW5kIFNBTUwgdG9rZW5zLiAgVGhlIG1lY2hhbmlzbSB3b3VsZCBiZSB0aGUgc2Ft ZSBvbmUgdGhhdCBCcmlhbiBzdWdnZXN0ZWQgYmVsb3cg4oCTIGRlZmluaW5nIHNlY3VyaXR5IHRv a2VuIHR5cGUgdmFsdWVzIGZvciBPQXV0aCAyLjAgYWNjZXNzIHRva2VucyBhbmQgcmVmcmVzaCB0 b2tlbnMg4oCTIGVuYWJsaW5nIHRoZW0gdG8gYmUgdXNlZCBhcyBpbnB1dHMgYW5kIG91dHB1dHMg aW4gYW55IG9mIHRoZSB0b2tlbiBleGNoYW5nZXMuDQoNCkZvciBpbnN0YW5jZSwgYnkgdXNpbmcg 4oCcYWNjZXNzIHRva2Vu4oCdIGFzIHRoZSBpbnB1dCBzZWN1cml0eSB0b2tlbiB0eXBlLCBwcm92 aWRpbmcgbmV3IHNjb3BlIHZhbHVlcywgYW5kIHVzaW5nIOKAnGFjY2VzcyB0b2tlbuKAnSBhcyB0 aGUgb3V0cHV0IHNlY3VyaXR5IHRva2VuIHR5cGUsIHRva2VuIGNoYWluaW5nIGlzIGFjaGlldmVk Lg0KDQpOb3csIGEgcXVlc3Rpb24gZm9yIHRoZSB3b3JraW5nIGdyb3Vw4oCmICBXaGF0IHNob3Vs ZCB0aGUgc2VjdXJpdHkgdG9rZW4gdHlwZSB2YWx1ZXMgZm9yIGFjY2VzcyB0b2tlbiBhbmQgcmVm cmVzaCB0b2tlbiBiZT8gIFR3byBkaWZmZXJlbnQgY2hvaWNlcyBzZWVtIHRvIG1ha2Ugc2Vuc2Uu DQooMSkgIFVzZSB0aGUgdmFsdWVzIOKAnGFjY2Vzc190b2tlbuKAnSBhbmQg4oCccmVmcmVzaF90 b2tlbuKAnSwgd2hpY2ggYXJlIHVzZWQgaW4gUkZDIDY3NDkgdG9rZW4gcmVzcG9uc2UgdmFsdWVz Lg0KKDIpICBEZWZpbmUgbmV3IFVSTnMgZm9yIHRoaXMgdXNhZ2UsIHN1Y2ggYXMgdXJuOmlldGY6 cGFyYW1zOm9hdXRoOnRva2VuLXR5cGU6YWNjZXNzLXRva2VuIGFuZCB1cm46aWV0ZjpwYXJhbXM6 b2F1dGg6dG9rZW4tdHlwZTpyZWZyZXNoLXRva2VuLg0KDQpJ4oCZZCBwZXJzb25hbGx5IGJlIGZp bmUganVzdCB1c2luZyB0aGUgc2hvcnQgbmFtZXMgaW4gKDEpLg0KDQpJZiBwZW9wbGUgYWdyZWUg d2l0aCB0aGlzIGFwcHJvYWNoLCB3ZSBjYW4gZG9jdW1lbnQgdGhpcyB1c2FnZSBpbiB0aGUgLTAz IGRyYWZ0IGFuZCBwdWJsaXNoIGl0IGFzIHNvb24gYXMgdGhlIHN1Ym1pc3Npb24gdG9vbCByZW9w ZW5zIE1vbmRheSBtb3JuaW5nIGR1cmluZyBJRVRGIDkzLg0KDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpG cm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBC cmlhbiBDYW1wYmVsbA0KU2VudDogVGh1cnNkYXksIE1hcmNoIDI2LCAyMDE1IDM6MTUgUE0NClRv OiBKdXN0aW4gUmljaGVyDQpDYzogPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVU SC1XR10gVG9rZW4gQ2hhaW5pbmcgVXNlIENhc2UNCg0KVGhpcyBraW5kIG9mIHRva2VuIGV4Y2hh bmdlIG1pZ2h0IGludm9sdmUgZXhjaGFuZ2VzIG90aGVyIHRoYW4gc3dhcHBpbmcgYW4gQVQgZm9y IGFub3RoZXIgQVQgKGFuZCBkb3duc2NvcGluZyBpdCkuIEl0IG1pZ2h0IGJlIGFuIEFUIGZvciBh IHN0cnVjdHVyZWQgSldUIHNwZWNpZmljYWxseSB0YXJnZXRlZCBhdCBvbmUgb2YgdGhlIHRoZSBw YXJ0aWN1bGFyIHNlcnZpY2VzIHRoYXQgdGhlIG9yaWdpbmFsIFJTIG5lZWRzIHRvIGNhbGwuIE9y IGFuIEFUIG1pZ2h0IGJlIGV4Y2hhbmdlZCBmb3IgYSBTQU1MIGFzc2VydGlvbiB0byB1c2Ugd2l0 aCBsZWdhY3kgU09BUCBzZXJ2ZXJpZXMuICBBIGdvb2QgZ2VuZXJhbCB0b2tlbiBleGNoYW5nZSBt ZWNoYW5pc20gZW5hYmxlcyBsb3RzIG9mIHZhcmlhdGlvbnMgb2YgY2FzZXMgbGlrZSB0aGUgb25l IEp1c3RpbiBtZW50aW9uZWQuIEFuZCBtb3JlLiBJbiBmYWN0LCBJIHRoaW5rIGRvd25zY29waW5n IG1pZ2h0IGJlIGEgbWlub3JpdHkgdXNlIGNhc2Ugd2hlcmUgd2hhdCB0b2tlbiBleGNoYW5nZSBp cyBvZnRlbiBuZWVkIGZvciBpcyB0cmFuc2xhdGluZyB0b2tlbnMgZnJvbSB3aGF0IHlvdSBoYXZl IGludG8gd2hhdCB0aGUgcmVzb3VyY2UgeW91IG5lZWQgdG8gY2FsbCBjYW4gZGVhbCB3aXRoLg0K VGhlcmUgbmVlZCB0byBiZSB3YXlzIGZvciB0aGUgY2FsbGVyIHRvIHRlbGwgdGhlIEFTIGFib3V0 IHRoZSB0b2tlbiBpdCdzIGFza2luZyBmb3IgLSBieSB0eXBlIG9yIGJ5IHRoZSBhZGRyZXNzL2lk ZW50aWZpZXIgb2Ygd2hlcmUgaXQnbGwgYmUgdXNlZC4gVGhlcmUgbmVlZHMgdG8gYmUgd2F5cyBm b3IgdGhlIGNhbGxlciB0byBhdXRoZW50aWNhdGUgdG8gdGhlIEFTLiBBbmQgdGhlcmUgbmVlZHMg dG8gYmUgc29tZSB3YXkgb2YgZXhwcmVzc2luZyB0aGlzIGRlbGVnYXRpb24gdGhpbmcgKHRob3Vn aCBJJ20gc3RpbGwgbm90IHRvdGFsbHkgY29udmluY2VkIGl0IGNvdWxkbid0IGJlIGp1c3QgdGhl IHRva2VuIGlzIGFib3V0IHRoZSB1c2VyL3ByaW5jaXBhbCBhbmQgdGhlIGNhbGxlci9jbGllbnQg b2YgdGhlIGV4Y2hhbmdlIGlzIHdobyBpcyBiZWluZyBkZWxlZ2F0ZWQgdG8pLg0KSSByZWFsaXpl IGZldyAoYXBwcm9hY2hpbmcgemVybykgcGVvcGxlIGhhdmUgb3IgYXJlIGdvaW5nIHRvIHJlYWQg aXQgYnV0IEkgaGF2ZSBlbmRlYXZvcmVkIHRvIGNvdmVyIGFsbCB0aGVzZSB0aGluZ3MgaW4gdGhl IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhbXBiZWxsLW9hdXRoLXN0cy0wMiBk cmFmdC4gSXQncyBhbiBlYXJseSBkcmFmdCBzbyBub3Qgd2l0aG91dCBpdCBzb21lIHJvdWdoIGVk Z2VzIGJ1dCBjYW4gcHJvdmlkZSBzb21lIGd1aWRhbmNlIG9uIHdoYXQgaXMgbmVlZGVkIGFuZCBv ZmZlcnMgc29tZSBwcm90b2NvbCBzeW50YXggZm9yIGV4cHJlc3NpbmcgaXQuIEkgYmVsaWV2ZSBK dXN0aW4ncyB1c2UgY2FzZSB3b3VsZCBiZSBjb3ZlcmVkIGJ5IGl0IChkZWZpbmluZyBhIHNwZWNp ZmljIHRva2VuIHR5cGUgVVJJIGZvciBhbiBPQXV0aCBhY2Nlc3MgdG9rZW4gaXNzdWVkIGJ5IHRo ZSBBUyBpbiBxdWVzdGlvbiBtaWdodCBiZSBuZWVkZWQpIGFzIGFyZSBtYW55IG90aGVycy4NCg0K T24gVGh1LCBNYXIgMjYsIDIwMTUgYXQgMTozMSBQTSwgSnVzdGluIFJpY2hlciA8anJpY2hlckBt aXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PiB3cm90ZToNCkFzIHJlcXVlc3RlZCBhZnRl ciBsYXN0IG5pZ2h04oCZcyBpbmZvcm1hbCBtZWV0aW5nLCBoZXJlIGlzIHRoZSB0b2tlbiBjaGFp bmluZyB1c2UgY2FzZSB0aGF0IEkgd2FudCB0byBzZWUgcmVwcmVzZW50ZWQgaW4gdGhlIHRva2Vu IHN3YXAgZHJhZnQuDQoNCg0KWyBDbGllbnQgXSAgLT4gICBbIEEgXSAtPiBbIEIgXSAtPiBbIEMg XQ0KDQpBbiBPQXV0aCBjbGllbnQgZ2V0cyBhbiBhY2Nlc3MgdG9rZW4gQVQxLCBqdXN0IGxpa2Ug aXQgYWx3YXlzIHdvdWxkLCB3aXRoIHNjb3BlcyBbQSwgQiwgQ10gaW4gb3JkZXIgdG8gY2FsbCBz ZXJ2aWNlIEEsIHdoaWNoIHJlcXVpcmVzIGFsbCB0aHJlZSBzY29wZXMuIFNlcnZpY2UgQSAoYW4g UlMpIGFjY2VwdHMgdGhpcyB0b2tlbiBzaW5jZSBpdCBoYXMgaXRzIHNjb3BlLCBhbmQgdGhlbiBu ZWVkcyB0byBjYWxsIHNlcnZpY2UgQiBpbiB0dXJuLCB3aGljaCByZXF1aXJlcyBzY29wZXMgW0Is IENdLiBJdCBjb3VsZCBqdXN0IHJlLXNlbmQgdGhlIHRva2VuIGl0IGdvdCBpbiwgQVQxLCBidXQg dGhhdCB3b3VsZCBnaXZlIHRoZSBkb3duc3RyZWFtIFJTIHRoZSBhYmlsaXR5IHRvIGNhbGwgc2Vy dmljZXMgd2l0aCBzY29wZSBbIEEgXSBhbmQgaXQgc2hvdWxkIG5vdCBiZSBhbGxvd2VkIHRvIGRv IHRoYXQuIFRvIGxpbWl0IGV4cG9zdXJlLCBzZXJ2aWNlIEEgY2FsbHMgYSB0b2tlbiBzd2FwIGF0 IHRoZSBBUyB0byBjcmVhdGUgQVQyIHdpdGggc2NvcGVzIFsgQiwgQyBdLCBlZmZlY3RpdmVseSBh Y3RpbmcgYXMgYW4gT0F1dGggY2xpZW50IHJlcXVlc3RpbmcgYSBkb3duc2NvcGVkIHRva2VuIGJh c2VkIG9uIEFUMS4gU2VydmljZSBBIHRoZW4gYWN0cyBhcyBhbiBPQXV0aCBjbGllbnQgdG8gY2Fs bCBzZXJ2aWNlIEIsIG5vdyBhY3RpbmcgYXMgYW4gUlMgdG8gc2VydmljZSBB4oCZcyBjbGllbnQs IGFuZCBjYW4gZnVsZmlsbCB0aGUgcmVxdWVzdC4gQW5kIGl04oCZcyB0dXJ0bGVzIGFsbCB0aGUg d2F5IGRvd246IFNlcnZpY2UgQiBjYW4gYWxzbyBjYWxsIHNlcnZpY2UgQywgYW5kIG5vdyBCIGFj dHMgYXMgYSBjbGllbnQsIHJlcXVlc3RpbmcgQVQzIHdpdGggc2NvcGUgWyBDIF0gYmFzZWQgb24g QVQyLCBhbmQgc2VuZGluZyBBVDMgdG8gc2VydmljZSBDLiBUaGlzIHByZXZlbnRzIEMgZnJvbSBi ZWluZyBhYmxlIHRvIGNhbGwgQiBvciBBLCBib3RoIG9mIHdoaWNoIHdvdWxkIGhhdmUgYmVlbiBh dmFpbGFibGUgaWYgQVQxIGhhZCBiZWVuIHBhc3NlZCBhcm91bmQuIE5vdGUgdGhhdCBzZXJ2aWNl IEEgb3IgdGhlIENsaWVudCBjYW4gYWxzbyByZXF1ZXN0IGEgZG93bnNjb3BlZCB0b2tlbiB3aXRo IFsgQyBdIHRvIGNhbGwgc2VydmljZSBDIGRpcmVjdGx5IGFzIHdlbGwsIGFuZCBDIGRvZXNu4oCZ dCBoYXZlIHRvIGNhcmUgaG93IGl0IGdvdCB0aGVyZS4NCg0KDQpJbiBvdGhlciB3b3JkcywgaXQg bGV0cyB0aGUgY2xpZW50IHNvZnR3YXJlIGJlIHZlcnksIHZlcnkgZHVtYi4gSXQgZG9lc27igJl0 IGhhdmUgdG8gZG8gYW55IHNwZWNpYWwgcHJvY2Vzc2luZywgZG9lc27igJl0IGhhdmUgdG8ga25v dyB3aGF04oCZcyBpbiB0aGUgdG9rZW4sIGl0IGp1c3QgZm9sbG93cyB0aGUgcmVjaXBlIG9mIOKA nEkgZ290IGEgdG9rZW4sIEkgZ2V0IGFub3RoZXIgdG9rZW4gYmFzZWQgb24gdGhpcyB0byBjYWxs IHNvbWVvbmUgZWxzZeKAnS4gSXTigJlzIGFsc28gYW5hbG9nb3VzIHRvIHRoZSByZWZyZXNoIHRv a2VuIGZsb3csIGJ1dCB3aXRoIGFjY2VzcyB0b2tlbnMgZ29pbmcgaW4gYW5kIG91dC4gSeKAmXZl IGRlcGxveWVkIHRoaXMgc2V0dXAgc2V2ZXJhbCB0aW1lcyBpbiBkaWZmZXJlbnQgc2VydmljZSBk ZXBsb3ltZW50cy4gRXZlbiB0aG91Z2ggdGhlcmUgaXMgYSBwZXJmb3JtYW5jZSBoaXQgaW4gdGhl IGFkZGl0aW9uYWwgcm91bmQgdHJpcHMgKGFzIFBoaWwgYnJvdWdodCB1cCBpbiBhbm90aGVyIHRo cmVhZCksIGluIHRoZXNlIGNhc2VzIHRoZSBkZXNpcmUgdG8gaGF2ZSB0aGUgdG9rZW5zIGhvbGQg bGVhc3QgcHJpdmlsZWdlIGFjY2VzcyByaWdodHMgKHNtYWxsZXN0IHNldCBvZiBzY29wZXMgcGVy IHNlcnZpY2UpIG91dHdlaWdoZWQgYW55IHBlcmZvcm1hbmNlIGhpdCAod2hpY2ggd2FzIHNob3du IHRvIGJlIHJhdGhlciBzbWFsbCBpbiBwcmFjdGljZSkuDQoNCldoYXQgSSB3YW50IGlzIGZvciB0 aGUgdG9rZW4gc3dhcCBkcmFmdCB0byBkZWZpbmUgb3IgdXNlIGEgbWVjaGFuaXNtIHRoYXQgYWxs b3dzIHVzIHRvIGRvIHRoaXMuIEkgdGhpbmsgd2UgY2FuIGRvIHRoYXQgcHJldHR5IGVhc2lseSBi eSBhZGp1c3RpbmcgdGhlIHRva2VuIHN3YXAgc3ludGF4IGFuZCBsYW5ndWFnZSwgYW5kIGV4cGxp Y2l0bHkgY2FsbGluZyBvdXQgdGhlIHNlbWFudGljIHByb2Nlc3NpbmcgcG9ydGlvbiAodGhlIGN1 cnJlbnQgY29yZSBvZiB0aGUgZG9jdW1lbnQpIGZvciB3aGF0IGl0IGlzOiBhIHdheSBmb3IgYSB0 b2tlbiBpc3N1ZXIgdG8gY29tbXVuaWNhdGUgdG8gYSB0b2tlbiBzZXJ2aWNlIHNwZWNpZmljIGFj dGlvbnMuIEF0IGEgaGlnaCBsZXZlbCwgdGhlIHNwZWMgd291bGQgYmUgc29tZXRoaW5nIGxpa2U6 DQoNCg0KDQoxLiBIb3cgdG8gc3dhcCBhIHRva2VuIGF0IGFuIEFTDQogIDEuIFNlbmQgYSByZXF1 ZXN0IHRvIHRoZSB0b2tlbiBlbmRwb2ludCB3aXRoIGEgbmV3IGdyYW50IHR5cGUsIGFuZCBhIHRv a2VuIChvZiBhbnkgdHlwZS9mb3JtYXQvZmxhdm9yKSBvbiB0aGUgd2F5IGluDQogIDIuIEdldCBi YWNrIGEgbmV3IHRva2VuIGluIGEgdG9rZW4gcmVzcG9uc2UNCjIuIENvbW11bmljYXRpbmcgYWN0 IGFzIC8gb24gYmVoYWxmIG9mIHNlbWFudGljcyB2aWEgYSBKV1QgYXNzZXJ0aW9uDQogIDEuIEhv dyB0byBjcmVhdGUgKGFzIGFuIEFTL1JTL2NsaWVudC9vdGhlciBpc3N1ZXIpIGEgSldUIHdpdGgg YWN0LWFzIHNlbWFudGljcw0KICAyLiBXaGF0IHRvIGRvIChhcyBhbiBBUy9SUykgd2l0aCBhIEpX VCB3aXRoIGFjdC1hcyBzZW1hbnRpY3MNCiAgMy4gSG93IHRvIGNyZWF0ZSBhIEpXVCB3aXRoIG9u LWJlaGFsZi1vZiBzZW1lYW50aWNzDQogIDQuIFdoYXQgdG8gZG8gd2l0aCBhIEpXVCB3aXRoIG9u LWJlaGFsZi1vZi1zZW1hbnRpY3MNCiAgNS4gSG93IHRvIHBvc3NpYmx5IHJlcHJlc2VudCB0aGVz ZSBzZW1hbnRpY3Mgd2l0aCBzb21ldGhpbmcgb3RoZXIgdGhhbiBhIEpXVA0KDQoNCg0KU2VjdGlv biAyIHVzZXMgdGhlIHN5bnRheCBmcm9tIHNlY3Rpb24gMS4gT3RoZXIgYXBwbGljYXRpb25zLCBs aWtlIHRoZSBvbmUgSSBsYWlkIG91dCBhYm92ZSwgY2FuIHVzZSB0aGUgc3ludGF4IGZyb20gc2Vj dGlvbiAxIGFzIHdlbGwuIFRoaXMgd29ya3MgZm9yIHN0cnVjdHVyZWQsIHVuc3RydWN0dXJlZCwg c2VsZi1nZW5lcmF0ZWQsIGNyb3NzLWRvbWFpbiwgd2l0aGluLWRvbWFpbiwgYW5kIG90aGVyIHRv a2Vucy4NCg0KDQog4oCUIEp1c3Rpbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWls dG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoDQoNCg== --_000_BY2PR03MB442F6D96703377B6673509AF5920BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KdHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6IzAwMzM2Njt9DQpzcGFu LmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxhIGhyZWY9Imh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvLz9wPTE0MTIiPkFzIGp1c3Qg dXBkYXRlZDwvYT4sIEkgYmVsaWV2ZSB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIHRva2VuIGV4Y2hh bmdlIGRyYWZ0DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1vYXV0aC10b2tlbi1leGNoYW5nZS0wMiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMDI8L2E+IGNhbiBub3cgYWxzbyBzZXJ2ZSB0 aGUg4oCcT0F1dGh54oCdIHRva2VuIGV4Y2hhbmdlIHVzZSBjYXNlcywgc3VjaCBhcyBKdXN0aW4g YW5kIFBoaWzigJlzIHRva2VuIGNoYWluaW5nIHVzZSBjYXNlLCBhcyB3ZWxsDQogYXMgc3VwcG9y dCBnZW5lcmFsIHRva2VuIGV4Y2hhbmdlLCBpbmNsdWRpbmcgZXhjaGFuZ2Ugb2YgSldUIGFuZCBT QU1MIHRva2Vucy4mbmJzcDsgVGhlIG1lY2hhbmlzbSB3b3VsZCBiZSB0aGUgc2FtZSBvbmUgdGhh dCBCcmlhbiBzdWdnZXN0ZWQgYmVsb3cg4oCTIGRlZmluaW5nIHNlY3VyaXR5IHRva2VuIHR5cGUg dmFsdWVzIGZvciBPQXV0aCAyLjAgYWNjZXNzIHRva2VucyBhbmQgcmVmcmVzaCB0b2tlbnMg4oCT IGVuYWJsaW5nIHRoZW0gdG8gYmUgdXNlZCBhcw0KIGlucHV0cyBhbmQgb3V0cHV0cyBpbiBhbnkg b2YgdGhlIHRva2VuIGV4Y2hhbmdlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZvciBpbnN0YW5jZSwgYnkgdXNpbmcg 4oCcYWNjZXNzIHRva2Vu4oCdIGFzIHRoZSBpbnB1dCBzZWN1cml0eSB0b2tlbiB0eXBlLCBwcm92 aWRpbmcgbmV3IHNjb3BlIHZhbHVlcywgYW5kIHVzaW5nIOKAnGFjY2VzcyB0b2tlbuKAnSBhcyB0 aGUgb3V0cHV0IHNlY3VyaXR5IHRva2VuIHR5cGUsDQogdG9rZW4gY2hhaW5pbmcgaXMgYWNoaWV2 ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5Ob3csIGEgcXVlc3Rpb24gZm9yIHRoZSB3b3JraW5nIGdyb3Vw4oCmJm5i c3A7IFdoYXQgc2hvdWxkIHRoZSBzZWN1cml0eSB0b2tlbiB0eXBlIHZhbHVlcyBmb3IgYWNjZXNz IHRva2VuIGFuZCByZWZyZXNoIHRva2VuIGJlPyZuYnNwOyBUd28gZGlmZmVyZW50IGNob2ljZXMg c2VlbSB0byBtYWtlDQogc2Vuc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPigxKSZu YnNwOyBVc2UgdGhlIHZhbHVlcyDigJxhY2Nlc3NfdG9rZW7igJ0gYW5kIOKAnHJlZnJlc2hfdG9r ZW7igJ0sIHdoaWNoIGFyZSB1c2VkIGluIFJGQyA2NzQ5IHRva2VuIHJlc3BvbnNlIHZhbHVlcy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+KDIpJm5ic3A7IERlZmluZSBuZXcgVVJOcyBm b3IgdGhpcyB1c2FnZSwgc3VjaCBhcw0KPC9zcGFuPjx0dD48c3BhbiBsYW5nPSJFTiI+dXJuOmll dGY6cGFyYW1zOm9hdXRoOnRva2VuLXR5cGU6YWNjZXNzLXRva2VuPC9zcGFuPjwvdHQ+PHNwYW4g bGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4NCjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+YW5kDQo8L3NwYW4+PHR0 PjxzcGFuIGxhbmc9IkVOIj51cm46aWV0ZjpwYXJhbXM6b2F1dGg6dG9rZW4tdHlwZTpyZWZyZXNo LXRva2VuPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPknigJlkIHBlcnNvbmFsbHkgYmUgZmluZSBqdXN0IHVzaW5nIHRoZSBz aG9ydCBuYW1lcyBpbiAoMSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiBwZW9wbGUgYWdyZWUgd2l0aCB0aGlzIGFw cHJvYWNoLCB3ZSBjYW4gZG9jdW1lbnQgdGhpcyB1c2FnZSBpbiB0aGUgLTAzIGRyYWZ0IGFuZCBw dWJsaXNoIGl0IGFzIHNvb24gYXMgdGhlIHN1Ym1pc3Npb24gdG9vbCByZW9wZW5zIE1vbmRheSBt b3JuaW5nIGR1cmluZw0KIElFVEYgOTMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5CcmlhbiBDYW1wYmVsbDxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTWFy Y2ggMjYsIDIwMTUgMzoxNSBQTTxicj4NCjxiPlRvOjwvYj4gSnVzdGluIFJpY2hlcjxicj4NCjxi PkNjOjwvYj4gJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W09BVVRILVdHXSBUb2tlbiBDaGFpbmluZyBVc2UgQ2FzZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij5UaGlzIGtpbmQgb2YgdG9rZW4gZXhjaGFuZ2UgbWlnaHQgaW52b2x2ZSBleGNoYW5nZXMgb3Ro ZXIgdGhhbiBzd2FwcGluZyBhbiBBVCBmb3IgYW5vdGhlciBBVCAoYW5kIGRvd25zY29waW5nIGl0 KS4gSXQgbWlnaHQgYmUgYW4gQVQgZm9yIGEgc3RydWN0dXJlZCBKV1Qgc3BlY2lmaWNhbGx5IHRh cmdldGVkIGF0IG9uZSBvZiB0aGUgdGhlIHBhcnRpY3VsYXIgc2VydmljZXMNCiB0aGF0IHRoZSBv cmlnaW5hbCBSUyBuZWVkcyB0byBjYWxsLiBPciBhbiBBVCBtaWdodCBiZSBleGNoYW5nZWQgZm9y IGEgU0FNTCBhc3NlcnRpb24gdG8gdXNlIHdpdGggbGVnYWN5IFNPQVAgc2VydmVyaWVzLiZuYnNw OyBBIGdvb2QgZ2VuZXJhbCB0b2tlbiBleGNoYW5nZSBtZWNoYW5pc20gZW5hYmxlcyBsb3RzIG9m IHZhcmlhdGlvbnMgb2YgY2FzZXMgbGlrZSB0aGUgb25lIEp1c3RpbiBtZW50aW9uZWQuIEFuZCBt b3JlLiBJbiBmYWN0LCBJIHRoaW5rIGRvd25zY29waW5nDQogbWlnaHQgYmUgYSBtaW5vcml0eSB1 c2UgY2FzZSB3aGVyZSB3aGF0IHRva2VuIGV4Y2hhbmdlIGlzIG9mdGVuIG5lZWQgZm9yIGlzIHRy YW5zbGF0aW5nIHRva2VucyBmcm9tIHdoYXQgeW91IGhhdmUgaW50byB3aGF0IHRoZSByZXNvdXJj ZSB5b3UgbmVlZCB0byBjYWxsIGNhbiBkZWFsIHdpdGguDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5UaGVy ZSBuZWVkIHRvIGJlIHdheXMgZm9yIHRoZSBjYWxsZXIgdG8gdGVsbCB0aGUgQVMgYWJvdXQgdGhl IHRva2VuIGl0J3MgYXNraW5nIGZvciAtIGJ5IHR5cGUgb3IgYnkgdGhlIGFkZHJlc3MvaWRlbnRp ZmllciBvZiB3aGVyZSBpdCdsbCBiZSB1c2VkLiBUaGVyZSBuZWVkcyB0byBiZSB3YXlzIGZvciB0 aGUgY2FsbGVyIHRvIGF1dGhlbnRpY2F0ZSB0byB0aGUNCiBBUy4gQW5kIHRoZXJlIG5lZWRzIHRv IGJlIHNvbWUgd2F5IG9mIGV4cHJlc3NpbmcgdGhpcyBkZWxlZ2F0aW9uIHRoaW5nICh0aG91Z2gg SSdtIHN0aWxsIG5vdCB0b3RhbGx5IGNvbnZpbmNlZCBpdCBjb3VsZG4ndCBiZSBqdXN0IHRoZSB0 b2tlbiBpcyBhYm91dCB0aGUgdXNlci9wcmluY2lwYWwgYW5kIHRoZSBjYWxsZXIvY2xpZW50IG9m IHRoZSBleGNoYW5nZSBpcyB3aG8gaXMgYmVpbmcgZGVsZWdhdGVkIHRvKS4NCjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHJlYWxpemUgZmV3IChhcHByb2Fj aGluZyB6ZXJvKSBwZW9wbGUgaGF2ZSBvciBhcmUgZ29pbmcgdG8gcmVhZCBpdCBidXQgSSBoYXZl IGVuZGVhdm9yZWQgdG8gY292ZXIgYWxsIHRoZXNlIHRoaW5ncyBpbiB0aGUNCjxhIGhyZWY9Imh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhbXBiZWxsLW9hdXRoLXN0cy0wMiIgdGFy Z2V0PSJfYmxhbmsiPg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2FtcGJlbGwt b2F1dGgtc3RzLTAyPC9hPiBkcmFmdC4gSXQncyBhbiBlYXJseSBkcmFmdCBzbyBub3Qgd2l0aG91 dCBpdCBzb21lIHJvdWdoIGVkZ2VzIGJ1dCBjYW4gcHJvdmlkZSBzb21lIGd1aWRhbmNlIG9uIHdo YXQgaXMgbmVlZGVkIGFuZCBvZmZlcnMgc29tZSBwcm90b2NvbCBzeW50YXggZm9yIGV4cHJlc3Np bmcgaXQuIEkgYmVsaWV2ZSBKdXN0aW4ncyB1c2UgY2FzZSB3b3VsZCBiZQ0KIGNvdmVyZWQgYnkg aXQgKGRlZmluaW5nIGEgc3BlY2lmaWMgdG9rZW4gdHlwZSBVUkkgZm9yIGFuIE9BdXRoIGFjY2Vz cyB0b2tlbiBpc3N1ZWQgYnkgdGhlIEFTIGluIHF1ZXN0aW9uIG1pZ2h0IGJlIG5lZWRlZCkgYXMg YXJlIG1hbnkgb3RoZXJzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gVGh1LCBNYXIgMjYsIDIwMTUgYXQgMTozMSBQTSwgSnVzdGluIFJpY2hlciAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJA bWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5BcyByZXF1ZXN0ZWQgYWZ0ZXIgbGFzdCBu aWdodOKAmXMgaW5mb3JtYWwgbWVldGluZywgaGVyZSBpcyB0aGUgdG9rZW4gY2hhaW5pbmcgdXNl IGNhc2UgdGhhdCBJIHdhbnQgdG8gc2VlIHJlcHJlc2VudGVkIGluIHRoZSB0b2tlbiBzd2FwIGRy YWZ0Ljxicj4NCjxicj4NCjxicj4NClsgQ2xpZW50IF0mbmJzcDsgLSZndDsmbmJzcDsgJm5ic3A7 WyBBIF0gLSZndDsgWyBCIF0gLSZndDsgWyBDIF08YnI+DQo8YnI+DQpBbiBPQXV0aCBjbGllbnQg Z2V0cyBhbiBhY2Nlc3MgdG9rZW4gQVQxLCBqdXN0IGxpa2UgaXQgYWx3YXlzIHdvdWxkLCB3aXRo IHNjb3BlcyBbQSwgQiwgQ10gaW4gb3JkZXIgdG8gY2FsbCBzZXJ2aWNlIEEsIHdoaWNoIHJlcXVp cmVzIGFsbCB0aHJlZSBzY29wZXMuIFNlcnZpY2UgQSAoYW4gUlMpIGFjY2VwdHMgdGhpcyB0b2tl biBzaW5jZSBpdCBoYXMgaXRzIHNjb3BlLCBhbmQgdGhlbiBuZWVkcyB0byBjYWxsIHNlcnZpY2Ug QiBpbiB0dXJuLCB3aGljaA0KIHJlcXVpcmVzIHNjb3BlcyBbQiwgQ10uIEl0IGNvdWxkIGp1c3Qg cmUtc2VuZCB0aGUgdG9rZW4gaXQgZ290IGluLCBBVDEsIGJ1dCB0aGF0IHdvdWxkIGdpdmUgdGhl IGRvd25zdHJlYW0gUlMgdGhlIGFiaWxpdHkgdG8gY2FsbCBzZXJ2aWNlcyB3aXRoIHNjb3BlIFsg QSBdIGFuZCBpdCBzaG91bGQgbm90IGJlIGFsbG93ZWQgdG8gZG8gdGhhdC4gVG8gbGltaXQgZXhw b3N1cmUsIHNlcnZpY2UgQSBjYWxscyBhIHRva2VuIHN3YXAgYXQgdGhlIEFTIHRvDQogY3JlYXRl IEFUMiB3aXRoIHNjb3BlcyBbIEIsIEMgXSwgZWZmZWN0aXZlbHkgYWN0aW5nIGFzIGFuIE9BdXRo IGNsaWVudCByZXF1ZXN0aW5nIGEgZG93bnNjb3BlZCB0b2tlbiBiYXNlZCBvbiBBVDEuIFNlcnZp Y2UgQSB0aGVuIGFjdHMgYXMgYW4gT0F1dGggY2xpZW50IHRvIGNhbGwgc2VydmljZSBCLCBub3cg YWN0aW5nIGFzIGFuIFJTIHRvIHNlcnZpY2UgQeKAmXMgY2xpZW50LCBhbmQgY2FuIGZ1bGZpbGwg dGhlIHJlcXVlc3QuIEFuZCBpdOKAmXMgdHVydGxlcw0KIGFsbCB0aGUgd2F5IGRvd246IFNlcnZp Y2UgQiBjYW4gYWxzbyBjYWxsIHNlcnZpY2UgQywgYW5kIG5vdyBCIGFjdHMgYXMgYSBjbGllbnQs IHJlcXVlc3RpbmcgQVQzIHdpdGggc2NvcGUgWyBDIF0gYmFzZWQgb24gQVQyLCBhbmQgc2VuZGlu ZyBBVDMgdG8gc2VydmljZSBDLiBUaGlzIHByZXZlbnRzIEMgZnJvbSBiZWluZyBhYmxlIHRvIGNh bGwgQiBvciBBLCBib3RoIG9mIHdoaWNoIHdvdWxkIGhhdmUgYmVlbiBhdmFpbGFibGUgaWYgQVQx IGhhZA0KIGJlZW4gcGFzc2VkIGFyb3VuZC4gTm90ZSB0aGF0IHNlcnZpY2UgQSBvciB0aGUgQ2xp ZW50IGNhbiBhbHNvIHJlcXVlc3QgYSBkb3duc2NvcGVkIHRva2VuIHdpdGggWyBDIF0gdG8gY2Fs bCBzZXJ2aWNlIEMgZGlyZWN0bHkgYXMgd2VsbCwgYW5kIEMgZG9lc27igJl0IGhhdmUgdG8gY2Fy ZSBob3cgaXQgZ290IHRoZXJlLjxicj4NCjxicj4NCjxicj4NCkluIG90aGVyIHdvcmRzLCBpdCBs ZXRzIHRoZSBjbGllbnQgc29mdHdhcmUgYmUgdmVyeSwgdmVyeSBkdW1iLiBJdCBkb2VzbuKAmXQg aGF2ZSB0byBkbyBhbnkgc3BlY2lhbCBwcm9jZXNzaW5nLCBkb2VzbuKAmXQgaGF2ZSB0byBrbm93 IHdoYXTigJlzIGluIHRoZSB0b2tlbiwgaXQganVzdCBmb2xsb3dzIHRoZSByZWNpcGUgb2Yg4oCc SSBnb3QgYSB0b2tlbiwgSSBnZXQgYW5vdGhlciB0b2tlbiBiYXNlZCBvbiB0aGlzIHRvIGNhbGwg c29tZW9uZSBlbHNl4oCdLiBJdOKAmXMNCiBhbHNvIGFuYWxvZ291cyB0byB0aGUgcmVmcmVzaCB0 b2tlbiBmbG93LCBidXQgd2l0aCBhY2Nlc3MgdG9rZW5zIGdvaW5nIGluIGFuZCBvdXQuIEnigJl2 ZSBkZXBsb3llZCB0aGlzIHNldHVwIHNldmVyYWwgdGltZXMgaW4gZGlmZmVyZW50IHNlcnZpY2Ug ZGVwbG95bWVudHMuIEV2ZW4gdGhvdWdoIHRoZXJlIGlzIGEgcGVyZm9ybWFuY2UgaGl0IGluIHRo ZSBhZGRpdGlvbmFsIHJvdW5kIHRyaXBzIChhcyBQaGlsIGJyb3VnaHQgdXAgaW4gYW5vdGhlcg0K IHRocmVhZCksIGluIHRoZXNlIGNhc2VzIHRoZSBkZXNpcmUgdG8gaGF2ZSB0aGUgdG9rZW5zIGhv bGQgbGVhc3QgcHJpdmlsZWdlIGFjY2VzcyByaWdodHMgKHNtYWxsZXN0IHNldCBvZiBzY29wZXMg cGVyIHNlcnZpY2UpIG91dHdlaWdoZWQgYW55IHBlcmZvcm1hbmNlIGhpdCAod2hpY2ggd2FzIHNo b3duIHRvIGJlIHJhdGhlciBzbWFsbCBpbiBwcmFjdGljZSkuPGJyPg0KPGJyPg0KV2hhdCBJIHdh bnQgaXMgZm9yIHRoZSB0b2tlbiBzd2FwIGRyYWZ0IHRvIGRlZmluZSBvciB1c2UgYSBtZWNoYW5p c20gdGhhdCBhbGxvd3MgdXMgdG8gZG8gdGhpcy4gSSB0aGluayB3ZSBjYW4gZG8gdGhhdCBwcmV0 dHkgZWFzaWx5IGJ5IGFkanVzdGluZyB0aGUgdG9rZW4gc3dhcCBzeW50YXggYW5kIGxhbmd1YWdl LCBhbmQgZXhwbGljaXRseSBjYWxsaW5nIG91dCB0aGUgc2VtYW50aWMgcHJvY2Vzc2luZyBwb3J0 aW9uICh0aGUgY3VycmVudCBjb3JlDQogb2YgdGhlIGRvY3VtZW50KSBmb3Igd2hhdCBpdCBpczog YSB3YXkgZm9yIGEgdG9rZW4gaXNzdWVyIHRvIGNvbW11bmljYXRlIHRvIGEgdG9rZW4gc2Vydmlj ZSBzcGVjaWZpYyBhY3Rpb25zLiBBdCBhIGhpZ2ggbGV2ZWwsIHRoZSBzcGVjIHdvdWxkIGJlIHNv bWV0aGluZyBsaWtlOjxicj4NCjxicj4NCjxicj4NCjxicj4NCjEuIEhvdyB0byBzd2FwIGEgdG9r ZW4gYXQgYW4gQVM8YnI+DQombmJzcDsgMS4gU2VuZCBhIHJlcXVlc3QgdG8gdGhlIHRva2VuIGVu ZHBvaW50IHdpdGggYSBuZXcgZ3JhbnQgdHlwZSwgYW5kIGEgdG9rZW4gKG9mIGFueSB0eXBlL2Zv cm1hdC9mbGF2b3IpIG9uIHRoZSB3YXkgaW48YnI+DQombmJzcDsgMi4gR2V0IGJhY2sgYSBuZXcg dG9rZW4gaW4gYSB0b2tlbiByZXNwb25zZTxicj4NCjIuIENvbW11bmljYXRpbmcgYWN0IGFzIC8g b24gYmVoYWxmIG9mIHNlbWFudGljcyB2aWEgYSBKV1QgYXNzZXJ0aW9uPGJyPg0KJm5ic3A7IDEu IEhvdyB0byBjcmVhdGUgKGFzIGFuIEFTL1JTL2NsaWVudC9vdGhlciBpc3N1ZXIpIGEgSldUIHdp dGggYWN0LWFzIHNlbWFudGljczxicj4NCiZuYnNwOyAyLiBXaGF0IHRvIGRvIChhcyBhbiBBUy9S Uykgd2l0aCBhIEpXVCB3aXRoIGFjdC1hcyBzZW1hbnRpY3M8YnI+DQombmJzcDsgMy4gSG93IHRv IGNyZWF0ZSBhIEpXVCB3aXRoIG9uLWJlaGFsZi1vZiBzZW1lYW50aWNzPGJyPg0KJm5ic3A7IDQu IFdoYXQgdG8gZG8gd2l0aCBhIEpXVCB3aXRoIG9uLWJlaGFsZi1vZi1zZW1hbnRpY3M8YnI+DQom bmJzcDsgNS4gSG93IHRvIHBvc3NpYmx5IHJlcHJlc2VudCB0aGVzZSBzZW1hbnRpY3Mgd2l0aCBz b21ldGhpbmcgb3RoZXIgdGhhbiBhIEpXVDxicj4NCjxicj4NCjxicj4NCjxicj4NClNlY3Rpb24g MiB1c2VzIHRoZSBzeW50YXggZnJvbSBzZWN0aW9uIDEuIE90aGVyIGFwcGxpY2F0aW9ucywgbGlr ZSB0aGUgb25lIEkgbGFpZCBvdXQgYWJvdmUsIGNhbiB1c2UgdGhlIHN5bnRheCBmcm9tIHNlY3Rp b24gMSBhcyB3ZWxsLiBUaGlzIHdvcmtzIGZvciBzdHJ1Y3R1cmVkLCB1bnN0cnVjdHVyZWQsIHNl bGYtZ2VuZXJhdGVkLCBjcm9zcy1kb21haW4sIHdpdGhpbi1kb21haW4sIGFuZCBvdGhlciB0b2tl bnMuPGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxicj4NCjxzcGFuIGNs YXNzPSJob2VuemIiPiZuYnNwO+KAlCBKdXN0aW48L3NwYW4+PGJyPg0KPC9zcGFuPjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGgg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_BY2PR03MB442F6D96703377B6673509AF5920BY2PR03MB442namprd_-- From nobody Tue Jul 7 15:53:31 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D1D1B2A25 for ; Tue, 7 Jul 2015 15:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZ3a9JP7iFdj for ; Tue, 7 Jul 2015 15:53:26 -0700 (PDT) Received: from mail-qk0-f170.google.com (mail-qk0-f170.google.com [209.85.220.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13AD91B2A1E for ; Tue, 7 Jul 2015 15:53:23 -0700 (PDT) Received: by qkhu186 with SMTP id u186so151448150qkh.0 for ; Tue, 07 Jul 2015 15:53:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=WiC88R+NOnOJEj5O2vTBaVj3zWd6YRtHpZk9wY4YgLU=; b=ghDAPk5Py42L9VXH43gj3bEgXwigJT5/pOPpTPXjhXpcdMaiTwraGg389ONufY8Rql NcFLO+pVdOecPlpgNhSAMs93okPJ+yoMBF9b5S0I0QfD/M53LpTvEwjd2Lv/o1KaHosN dgh1CwW2TS7n+MEyLNDk3bEmVDfalBFUDZRdlHGKxW55UPC6QZi6IkGukYedxDnyj4vI +BGrxKk58sWzymqOCslnJ6lGx0BT420VYSiQNb5CFS3HWQ+N47fJlH7dd/0ooGnt/oy+ cYIQ4zVjSEg4BXnFTrUYFoSeYbFZDnVf4tAQXX57DUQ+HejUx90YNLDjgtjvTNJVZFGi Fjew== X-Gm-Message-State: ALoCoQmSoW2wvwfXNBCALwhqvyCJ+Dv73scBb001LITyjz3qJ+lOyEEKGJ+iL1lroPvb59PwVn4W X-Received: by 10.55.48.18 with SMTP id w18mr11097131qkw.34.1436309602194; Tue, 07 Jul 2015 15:53:22 -0700 (PDT) Received: from [192.168.1.34] (181-163-0-38.baf.movistar.cl. [181.163.0.38]) by smtp.gmail.com with ESMTPSA id 128sm90438qhg.45.2015.07.07.15.53.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Jul 2015 15:53:21 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_66D61172-406B-437E-8333-E50AE26BBE1D" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: John Bradley In-Reply-To: Date: Tue, 7 Jul 2015 19:53:00 -0300 Message-Id: <8DE357B8-63E0-4225-95E5-B97AE3916B6F@ve7jtb.com> References: <20150707024902.24716.2952.idtracker@ietfa.amsl.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.2102) Archived-At: Cc: Barry Leiba , draft-ietf-oauth-spop@ietf.org, oauth , draft-ietf-oauth-spop.shepherd@ietf.org, The IESG , oauth-chairs@ietf.org, draft-ietf-oauth-spop.ad@ietf.org Subject: Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-spop-14: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 22:53:29 -0000 --Apple-Mail=_66D61172-406B-437E-8333-E50AE26BBE1D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have a draft with Barry=E2=80=99s edits less the removal of = ASCII(string) ready to go. In JWS we used ASCII(string) to indicate that the output is a sequence = of octets, strings are not necessarily 8 characters bits and may have = null termination etc. However as Brian states other changes may have removed the need for = that. I admit saying "where STRING is a sequence of zero or more ASCII = characters.=E2=80=9D looks a bit circular. How about saying "where = STRING is a sequence of zero or more characters=E2=80=9D The ABNF in Sec 4.1 should keep people from going too wrong on its own. I think it is OK the way it is, but am willing to change it if people = feel strongly. Let me know if I should make that change or publish a draft without it, = addressing the other comments. John B. > On Jul 7, 2015, at 5:40 PM, Kathleen Moriarty = wrote: >=20 > Thanks for your responses on these comments. >=20 > I can approve an updated draft to make this change and the one for = IANA if that is the easiest path. The other option is to write this all = up in an RFC editor note and I can send that with the approval. Making = the direct updates may be simpler to avoid mistakes. >=20 > Can you submit a new version? >=20 > Thank you, > Kathleen >=20 > On Tue, Jul 7, 2015 at 12:35 PM, Brian Campbell = > wrote: > Regarding the comment on Section 2, I had originally argued for the = inclusion of ASCII(xxx) as I felt it was important to avoid potential = ambiguity that was in the draft at the time (it wasn't 100% clear to me = at the time if the code_verifier was to be base64url decoded as input = into the hash or if the ASCII bytes were to be used). However, other = content (particularly =C2=A74.1 = ) has = since changed and removed the potential for the ambiguity I thought = might be there.=20 >=20 > Which is a long way of explaining that I'm okay with Barry's proposed = change to Section 2, and occurrences of ASCII(...) throughout, despite = it undoing something I'd previously requested. =20 >=20 > On Tue, Jul 7, 2015 at 10:09 AM, Nat Sakimura > wrote: > Thanks Barry,=20 >=20 >=20 > These are the issues that I wanted to discuss with John before making = change.=20 >=20 > -- Section 6.2 -- John has partly addressed your IANA comment already. = I needed=20 > to check if there was any reason for just doing partly.=20 >=20 > -- Section 7.2 -- is probably just my oversight. I will deal with it.=20= >=20 > -- Section 2 -- : I agree with you and I wanted to confirm it with = John and other people to commit the change.=20 >=20 > Cheers,=20 >=20 > Nat >=20 > 2015-07-07 11:49 GMT+09:00 Barry Leiba >: > Barry Leiba has entered the following ballot position for > draft-ietf-oauth-spop-14: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html = > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ = >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Version -14 resolves my DISCUSS (and also some of my non-blocking > comments). Thanks very much for considering these and working with me = on > them! >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > My comment about the IANA Considerations remains. While it's > non-blocking, I still hope you will accept the change I suggest: >=20 > -- Section 6.2 -- > I have the same comment here as in the other OAuth document: please = shift > the focus away from telling IANA how to handle tracking of the expert > review, and make the mailing list something that the designated = expert(s) > keep track of. Also, please give more instructions to the DEs about = what > they should consider when they're evaluating a request (for example, > should they approve all requests, or are there criteria they should > apply?). >=20 > For the first, here's a text change that I suggest we move toward for > this sort of thing: >=20 > OLD > >=20 > NEW > Additional code_challenge_method types for use with the = authorization > endpoint are registered using the Specification Required policy > [RFC5226], which includes review of the request by one or more > Designated Experts. The DEs will ensure there is at least a = two-week > review of the request on the oauth-ext-review@ietf.org = mailing list, > and that any discussion on that list converges before they respond = to > the request. To allow for the allocation of values prior to > publication, the Designated Expert(s) may approve registration once > they are satisfied that an acceptable specification will be > published. >=20 > Discussion on the oauth-ext-review@ietf.org = mailing list should use > an appropriate subject, such as "Request for PKCE > code_challenge_method: example"). >=20 > The Designated Expert(s) should consider the discussion on the > mailing list, as well as <> when evaluating > registration requests. Denials should include an explanation > and, if applicable, suggestions as to how to make the request > successful. > END >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > -- Section 7.2 -- > I find the first first paragraph confusingly worded, and after = discussion > with the author I suggest this: >=20 > NEW > Clients MUST NOT downgrade to "plain" after trying the S256 method. > Because servers are required to support S256, an error when S256 is > presented can only mean that the server does not support PKCE at all. > Otherwise, such an error could be indicative of a MITM attacker trying > a downgrade attack. > END >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Finally, there is this comment, which is not a big deal and you should > proceed as you think best: >=20 > -- Section 2 -- > There is no real distinction between STRING and ASCII(STRING), because > STRING is already defined to be ASCII. Using "ASCII(xxx)" only adds > clutter, and a suggest removing it. >=20 > So, for example, that would result in changes such as this: >=20 > OLD > BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) =3D=3D code_challenge > NEW > BASE64URL-ENCODE(SHA256(code_verifier)) =3D=3D code_challenge > END >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen --Apple-Mail=_66D61172-406B-437E-8333-E50AE26BBE1D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I have a draft with Barry=E2=80=99s edits less the removal of = ASCII(string) ready to go.

In JWS we used ASCII(string) to indicate that the = output is a sequence of octets, strings are not necessarily 8 characters = bits and may have null termination etc.

However as Brian states other changes = may have removed the need for that.

I admit saying "where STRING is a = sequence of zero or more ASCII characters.=E2=80=9D looks a bit = circular.   How about saying "where STRING is a sequence of zero or = more characters=E2=80=9D

The ABNF in Sec 4.1 should keep people from going too wrong = on its own.

I = think it is OK the way it is, but am willing to change it if people feel = strongly.

Let = me know if I should make that change or publish a draft without it, = addressing the other comments.

John B.




On Jul 7, 2015, at 5:40 PM, = Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Thanks for your responses on these comments.
I can approve an updated draft to make = this change and the one for IANA if that is the easiest path.  The = other option is to write this all up in an RFC editor note and I can = send that with the approval.  Making the direct updates may be = simpler to avoid mistakes.

Can you submit a new version?

Thank you,
Kathleen

On Tue, Jul 7, 2015 at 12:35 PM, = Brian Campbell <bcampbell@pingidentity.com> wrote:
Regarding the comment on Section 2, I had = originally argued for the inclusion of ASCII(xxx) as I felt it was = important to avoid potential ambiguity that was in the draft at the time = (it wasn't 100% clear to me at the time if the code_verifier was to be = base64url decoded as input into the hash or if the ASCII bytes were to = be used). However, other content (particularly =C2=A74.1) has since changed and removed the = potential for the ambiguity I thought might be there.

Which is a long way of explaining that = I'm okay with Barry's proposed change to Section 2, and occurrences of = ASCII(...) throughout, despite it undoing something I'd previously = requested. 

On Tue, Jul 7, 2015 at 10:09 AM, Nat Sakimura = <sakimura@gmail.com> wrote:
Thanks Barry, 


These are the issues = that I wanted to discuss with John before making change. 

-- Section 6.2 -- John = has partly addressed your IANA comment already. I needed 
to check if there was any reason for just doing = partly. 

-- Section 7.2 -- = is probably just my oversight. I will deal with it. 

-- Section 2 -- : I agree with you = and I wanted to confirm it with John and other people to commit the = change. 

Cheers, 

Nat

2015-07-07 11:49 GMT+09:00 Barry Leiba <barryleiba@computer.org>:
Barry Leiba has = entered the following ballot position for
draft-ietf-oauth-spop-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut = this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/



= ----------------------------------------------------------------------
COMMENT:
= ----------------------------------------------------------------------

Version -14 resolves my DISCUSS (and also some of my non-blocking
comments).  Thanks very much for considering these and working with = me on
them!

  =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
My comment about the IANA Considerations remains.  While it's
non-blocking, I still hope you will accept the change I suggest:

-- Section 6.2 --
I have the same comment here as in the other OAuth document: please = shift
the focus away from telling IANA how to handle tracking of the expert
review, and make the mailing list something that the designated = expert(s)
keep track of.  Also, please give more instructions to the DEs = about what
they should consider when they're evaluating a request (for example,
should they approve all requests, or are there criteria they should
apply?).

For the first, here's a text change that I suggest we move toward for
this sort of thing:

OLD
<most of Section 6.2>

NEW
   Additional code_challenge_method types for use with the = authorization
   endpoint are registered using the Specification Required = policy
   [RFC5226], which includes review of the request by one or = more
   Designated Experts.  The DEs will ensure there is at = least a two-week
   review of the request on the oauth-ext-review@ietf.org mailing list,
   and that any discussion on that list converges before they = respond to
   the request.  To allow for the allocation of values = prior to
   publication, the Designated Expert(s) may approve = registration once
   they are satisfied that an acceptable specification will = be
published.

   Discussion on the oauth-ext-review@ietf.org mailing list should use
   an appropriate subject, such as "Request for PKCE
   code_challenge_method: example").

   The Designated Expert(s) should consider the discussion on = the
   mailing list, as well as <<these other things>> = when evaluating
   registration requests.  Denials should include an = explanation
   and, if applicable, suggestions as to how to make the = request
   successful.
END

  =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
-- Section 7.2 --
I find the first first paragraph confusingly worded, and after = discussion
with the author I suggest this:

NEW
Clients MUST NOT downgrade to "plain" after trying the S256 method.
Because servers are required to support S256, an error when S256 is
presented can only mean that the server does not support PKCE at all.
Otherwise, such an error could be indicative of a MITM attacker = trying
a downgrade attack.
END

  =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Finally, there is this comment, which is not a big deal and you = should
proceed as you think best:

-- Section 2 --
There is no real distinction between STRING and ASCII(STRING), = because
STRING is already defined to be ASCII.  Using "ASCII(xxx)" only = adds
clutter, and a suggest removing it.

So, for example, that would result in changes such as this:
=
OLD
BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) =3D=3D code_challenge
NEW
BASE64URL-ENCODE(SHA256(code_verifier)) =3D=3D code_challenge
END


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



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

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





--

Best regards,
Kathleen

= --Apple-Mail=_66D61172-406B-437E-8333-E50AE26BBE1D-- From nobody Tue Jul 7 15:58:47 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7410F1B2A05; Tue, 7 Jul 2015 15:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oss7S4Z4JYmO; Tue, 7 Jul 2015 15:58:42 -0700 (PDT) Received: from mail-vn0-x22a.google.com (mail-vn0-x22a.google.com [IPv6:2607:f8b0:400c:c0f::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 6D56C1B2A04; Tue, 7 Jul 2015 15:58:42 -0700 (PDT) Received: by vnbf7 with SMTP id f7so17723018vnb.0; Tue, 07 Jul 2015 15:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=97k2r+maxOedxzwxtpTrz5sAChrLLrwRGKvNcMQVXdo=; b=ijcwK9n4g0akS+xjtVqkgvxxHR/jttwFrXcdmgJvQmM8/SXrqP3JOliuhX9lIELw6w yrouHKuVb3RhE+FFTYM5f1Pj39hgNzFFnWKBqHH2OqSxxL8wkN0QMKKy3G5ZDM4XJtAu n09Jr5LEdb3RRTojzkjcyyd146uQtIyghFbhhK/xdC+Bfev9cicRTvyScz3teG2VRO2c JqCMZLE4W5zCPtrjRFBrbzKNPfAHIuCg68PTlXp63LNc3i7QSvm2sn9i08QrQARjiGx6 acFdQoFDOfyzoMS9CNcPvOSTjRQxG579Hxfww/f15MGPGqgX8dhRbkXGB1VChuv6RWq8 XGxw== MIME-Version: 1.0 X-Received: by 10.52.32.34 with SMTP id f2mr6853820vdi.11.1436309921694; Tue, 07 Jul 2015 15:58:41 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.88.196 with HTTP; Tue, 7 Jul 2015 15:58:41 -0700 (PDT) In-Reply-To: <8DE357B8-63E0-4225-95E5-B97AE3916B6F@ve7jtb.com> References: <20150707024902.24716.2952.idtracker@ietfa.amsl.com> <8DE357B8-63E0-4225-95E5-B97AE3916B6F@ve7jtb.com> Date: Tue, 7 Jul 2015 18:58:41 -0400 X-Google-Sender-Auth: GAKoMHeUOYR_c4A4j5R01rvZeg8 Message-ID: From: Barry Leiba To: John Bradley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: draft-ietf-oauth-spop@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-spop.shepherd@ietf.org, The IESG , oauth , draft-ietf-oauth-spop.ad@ietf.org Subject: Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-spop-14: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 22:58:43 -0000 > In JWS we used ASCII(string) to indicate that the output is a sequence of > octets, strings are not necessarily 8 characters bits and may have null > termination etc. > > However as Brian states other changes may have removed the need for that. > > I admit saying "where STRING is a sequence of zero or more ASCII > characters.=E2=80=9D looks a bit circular. How about saying "where STRI= NG is a > sequence of zero or more characters=E2=80=9D > > The ABNF in Sec 4.1 should keep people from going too wrong on its own. > > I think it is OK the way it is, but am willing to change it if people fee= l > strongly. As I've said, that one is the least important of all my comments, and you folks should do what you think best there. If you prefer to leave the "ASCII(x)" notation for consistency, clarity, or whatever else, I'm not going to say any more about it. And many thanks for dealing with the other changes I've suggested. Barry From nobody Tue Jul 7 16:47:20 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4D91A1A22 for ; Tue, 7 Jul 2015 16:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-5zadXwzWUU for ; Tue, 7 Jul 2015 16:47:15 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7CED1A014C for ; Tue, 7 Jul 2015 16:47:12 -0700 (PDT) X-AuditID: 12074425-f799a6d000007db3-60-559c64ff9454 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 7B.34.32179.FF46C955; Tue, 7 Jul 2015 19:47:11 -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 t67NlAf6012960; Tue, 7 Jul 2015 19:47:10 -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 t67Nl8pT032346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Jul 2015 19:47:09 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_FC5FD7A8-19AE-4DDA-892F-1FBE86DD1AA3" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Justin Richer In-Reply-To: Date: Tue, 7 Jul 2015 19:47:07 -0400 Message-Id: <826785C8-648D-4A1B-AD8D-E99D76117C67@mit.edu> References: To: Mike Jones X-Mailer: Apple Mail (2.2098) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLKsWRmVeSWpSXmKPExsUixG6novs/ZU6owfYLghar/99ktNg77ROL xcm3r9gcmD2WLPnJ5NG64y+7x92jF1kCmKO4bFJSczLLUov07RK4Ml5ufshY8Og4Y8WxKYsZ Gxinr2DsYuTkkBAwkTjzeTUrhC0mceHeerYuRi4OIYHFTBJLZy+CcjYwStw9M48FwnnAJHFl /XGwFmaBBIk5z86BjeIV0JN49PQxO4gtLKAvsXx7H1gNm4CqxPQ1LUwgNqdAtMTT9m1gNSwC KhKTvqyHmhMr8an1DRPEHCuJtz2zGSGWnWOU+LD1E1hCREBH4vHFb0AncQDdKivxdavcBEaB WUjOmIXkDIi4tsSyha+ZIWxNif3dy1kwxTUkOr9NZF3AyLaKUTYlt0o3NzEzpzg1Wbc4OTEv L7VI10IvN7NELzWldBMjOBZcVHcwTjikdIhRgINRiYf3Q+ScUCHWxLLiytxDjJIcTEqivF7J QCG+pPyUyozE4oz4otKc1OJDjBIczEoivAnuQDnelMTKqtSifJiUNAeLkjjvph98IUIC6Ykl qdmpqQWpRTBZGQ4OJQnemyBDBYtS01Mr0jJzShDSTBycIMN5gIY/SAIZXlyQmFucmQ6RP8Wo KCXOGwnSLACSyCjNg+uFpapXjOJArwjz7gOp4gGmObjuV0CDmYAGL9edBTK4JBEhJdXAOO16 5wwx4Y5z188WvjupnvT1xu2YPwLK5x0bd2yb22OxvPLjJEP5i4eSOoI5Zye2+Fn8Ofn/l+Cj k0bRatMjHHcE6fpOlPj7nmVrR01Z1fK3vDWvRcQinq8w4tMNnPp3I8eGZtPDoQp2dRpmH7Ls wzsWdj3Nz7HYpLZR9/q6HWIWLYxyM48kKrEUZyQaajEXFScCAOtUcHowAwAA Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Token Chaining Use Case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 23:47:19 -0000 --Apple-Mail=_FC5FD7A8-19AE-4DDA-892F-1FBE86DD1AA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This approach is not a good fit for my use cases, and it=E2=80=99s still = not OAuth-y at all. It requires a specially-formed security assertion = on the way in, which the client must understand and generate. I still = can=E2=80=99t take an arbitrary token I=E2=80=99ve been handed by = someone else and pass it off to be pushed forward. The new =E2=80=9C*_type= =E2=80=9D parameters seem to merely kick the can down the road instead = of addressing the problems with the current specification. I think that Brian=E2=80=99s approach works much better. It unrolls = important parameters, properly uses the token endpoint, and allows for = arbitrarily formatted input tokens.=20 When combined with Nat=E2=80=99s draft that specifies how to perform all = generic OAuth requests as JWTs (or even some of the upcoming PoP work if = we ever do that), you=E2=80=99ve pretty much got the draft below but = with much more flexibility and power.=20 =E2=80=94 Justin > On Jul 7, 2015, at 6:51 PM, Mike Jones = wrote: >=20 > As just updated , I believe that = the working group token exchange draft = https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02 = can now = also serve the =E2=80=9COAuthy=E2=80=9D token exchange use cases, such = as Justin and Phil=E2=80=99s token chaining use case, as well as support = general token exchange, including exchange of JWT and SAML tokens. The = mechanism would be the same one that Brian suggested below =E2=80=93 = defining security token type values for OAuth 2.0 access tokens and = refresh tokens =E2=80=93 enabling them to be used as inputs and outputs = in any of the token exchanges. > =20 > For instance, by using =E2=80=9Caccess token=E2=80=9D as the input = security token type, providing new scope values, and using =E2=80=9Caccess= token=E2=80=9D as the output security token type, token chaining is = achieved. > =20 > Now, a question for the working group=E2=80=A6 What should the = security token type values for access token and refresh token be? Two = different choices seem to make sense. > (1) Use the values =E2=80=9Caccess_token=E2=80=9D and = =E2=80=9Crefresh_token=E2=80=9D, which are used in RFC 6749 token = response values. > (2) Define new URNs for this usage, such as = urn:ietf:params:oauth:token-type:access-token and = urn:ietf:params:oauth:token-type:refresh-token. > =20 > I=E2=80=99d personally be fine just using the short names in (1). > =20 > If people agree with this approach, we can document this usage in the = -03 draft and publish it as soon as the submission tool reopens Monday = morning during IETF 93. > =20 > -- = Mike > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian = Campbell > Sent: Thursday, March 26, 2015 3:15 PM > To: Justin Richer > Cc: > Subject: Re: [OAUTH-WG] Token Chaining Use Case > =20 > This kind of token exchange might involve exchanges other than = swapping an AT for another AT (and downscoping it). It might be an AT = for a structured JWT specifically targeted at one of the the particular = services that the original RS needs to call. Or an AT might be exchanged = for a SAML assertion to use with legacy SOAP serveries. A good general = token exchange mechanism enables lots of variations of cases like the = one Justin mentioned. And more. In fact, I think downscoping might be a = minority use case where what token exchange is often need for is = translating tokens from what you have into what the resource you need to = call can deal with. >=20 > There need to be ways for the caller to tell the AS about the token = it's asking for - by type or by the address/identifier of where it'll be = used. There needs to be ways for the caller to authenticate to the AS. = And there needs to be some way of expressing this delegation thing = (though I'm still not totally convinced it couldn't be just the token is = about the user/principal and the caller/client of the exchange is who is = being delegated to). >=20 > I realize few (approaching zero) people have or are going to read it = but I have endeavored to cover all these things in the = http://tools.ietf.org/html/draft-campbell-oauth-sts-02 = draft. It's an = early draft so not without it some rough edges but can provide some = guidance on what is needed and offers some protocol syntax for = expressing it. I believe Justin's use case would be covered by it = (defining a specific token type URI for an OAuth access token issued by = the AS in question might be needed) as are many others. > =20 > On Thu, Mar 26, 2015 at 1:31 PM, Justin Richer > wrote: > As requested after last night=E2=80=99s informal meeting, here is the = token chaining use case that I want to see represented in the token swap = draft. >=20 >=20 > [ Client ] -> [ A ] -> [ B ] -> [ C ] >=20 > An OAuth client gets an access token AT1, just like it always would, = with scopes [A, B, C] in order to call service A, which requires all = three scopes. Service A (an RS) accepts this token since it has its = scope, and then needs to call service B in turn, which requires scopes = [B, C]. It could just re-send the token it got in, AT1, but that would = give the downstream RS the ability to call services with scope [ A ] and = it should not be allowed to do that. To limit exposure, service A calls = a token swap at the AS to create AT2 with scopes [ B, C ], effectively = acting as an OAuth client requesting a downscoped token based on AT1. = Service A then acts as an OAuth client to call service B, now acting as = an RS to service A=E2=80=99s client, and can fulfill the request. And = it=E2=80=99s turtles all the way down: Service B can also call service = C, and now B acts as a client, requesting AT3 with scope [ C ] based on = AT2, and sending AT3 to service C. This prevents C from being able to = call B or A, both of which would have been available if AT1 had been = passed around. Note that service A or the Client can also request a = downscoped token with [ C ] to call service C directly as well, and C = doesn=E2=80=99t have to care how it got there. >=20 >=20 > In other words, it lets the client software be very, very dumb. It = doesn=E2=80=99t have to do any special processing, doesn=E2=80=99t have = to know what=E2=80=99s in the token, it just follows the recipe of =E2=80=9C= I got a token, I get another token based on this to call someone = else=E2=80=9D. It=E2=80=99s also analogous to the refresh token flow, = but with access tokens going in and out. I=E2=80=99ve deployed this = setup several times in different service deployments. Even though there = is a performance hit in the additional round trips (as Phil brought up = in another thread), in these cases the desire to have the tokens hold = least privilege access rights (smallest set of scopes per service) = outweighed any performance hit (which was shown to be rather small in = practice). >=20 > What I want is for the token swap draft to define or use a mechanism = that allows us to do this. I think we can do that pretty easily by = adjusting the token swap syntax and language, and explicitly calling out = the semantic processing portion (the current core of the document) for = what it is: a way for a token issuer to communicate to a token service = specific actions. At a high level, the spec would be something like: >=20 >=20 >=20 > 1. How to swap a token at an AS > 1. Send a request to the token endpoint with a new grant type, and a = token (of any type/format/flavor) on the way in > 2. Get back a new token in a token response > 2. Communicating act as / on behalf of semantics via a JWT assertion > 1. How to create (as an AS/RS/client/other issuer) a JWT with act-as = semantics > 2. What to do (as an AS/RS) with a JWT with act-as semantics > 3. How to create a JWT with on-behalf-of semeantics > 4. What to do with a JWT with on-behalf-of-semantics > 5. How to possibly represent these semantics with something other = than a JWT >=20 >=20 >=20 > Section 2 uses the syntax from section 1. Other applications, like the = one I laid out above, can use the syntax from section 1 as well. This = works for structured, unstructured, self-generated, cross-domain, = within-domain, and other tokens. >=20 >=20 > =E2=80=94 Justin >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = > =20 --Apple-Mail=_FC5FD7A8-19AE-4DDA-892F-1FBE86DD1AA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This approach is not a good fit for my use cases, and it=E2=80=99= s still not  OAuth-y at all. It requires a specially-formed = security assertion on the way in, which the client must understand and = generate. I still can=E2=80=99t take an arbitrary token I=E2=80=99ve = been handed by someone else and pass it off to be pushed forward. The = new =E2=80=9C*_type=E2=80=9D parameters seem to merely kick the can down = the road instead of addressing the problems with the current = specification.

I think that Brian=E2=80=99s approach works much better. It = unrolls important parameters, properly uses the token endpoint, and = allows for arbitrarily formatted input tokens. 

When combined with = Nat=E2=80=99s draft that specifies how to perform all generic OAuth = requests as JWTs (or even some of the upcoming PoP work if we ever do = that), you=E2=80=99ve pretty much got the draft below but with much more = flexibility and power. 

 =E2=80=94 Justin

On Jul 7, 2015, at 6:51 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

As just = updated, I believe that the working group token exchange draft https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02<= /a> can now also serve the =E2=80=9COAuthy=E2=80=9D token exchange use = cases, such as Justin and Phil=E2=80=99s token chaining use case, as = well as support general token exchange, including exchange of JWT and SAML = tokens.  The mechanism would be the same one that Brian suggested = below =E2=80=93 defining security token type values for OAuth 2.0 access = tokens and refresh tokens =E2=80=93 enabling them to be used as inputs and outputs in any of the token exchanges.

 

For instance, by using =E2=80=9Caccess = token=E2=80=9D as the input security token type, providing new scope = values, and using =E2=80=9Caccess token=E2=80=9D as the output security = token type, token chaining is achieved.

 

Now, a question for the working = group=E2=80=A6  What should the security token type values for = access token and refresh token be?  Two different choices seem to = make sense.

(1)  Use the values = =E2=80=9Caccess_token=E2=80=9D and =E2=80=9Crefresh_token=E2=80=9D, = which are used in RFC 6749 token response values.

(2)  Define new URNs for this = usage, such as urn:ietf:params:oauth:token-type:access-token and urn:ietf:params:oauth:token-type:refresh-token.

 

I=E2=80=99d personally be fine just = using the short names in (1).

 

If people agree with this approach, we = can document this usage in the -03 draft and publish it as soon as the = submission tool reopens Monday morning during IETF 93.

 

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

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, March 26, 2015 3:15 PM
To: Justin Richer
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Token Chaining Use Case

 

This= kind of token exchange might involve exchanges other than swapping an = AT for another AT (and downscoping it). It might be an AT for a = structured JWT specifically targeted at one of the the particular = services that the original RS needs to call. Or an AT might be exchanged for a = SAML assertion to use with legacy SOAP serveries.  A good general = token exchange mechanism enables lots of variations of cases like the = one Justin mentioned. And more. In fact, I think downscoping might be a minority use case where what token exchange is often need = for is translating tokens from what you have into what the resource you = need to call can deal with.

There need = to be ways for the caller to tell the AS about the token it's asking for = - by type or by the address/identifier of where it'll be used. There = needs to be ways for the caller to authenticate to the AS. And there needs to be some way of expressing this delegation thing = (though I'm still not totally convinced it couldn't be just the token is = about the user/principal and the caller/client of the exchange is who is = being delegated to).

I realize few (approaching zero) people = have or are going to read it but I have endeavored to cover all these = things in the http://tools.ietf.org/html/draft-campbell-oauth-sts-02 draft. It's = an early draft so not without it some rough edges but can provide some = guidance on what is needed and offers some protocol syntax for = expressing it. I believe Justin's use case would be covered by it (defining a specific token type URI for an OAuth access = token issued by the AS in question might be needed) as are many = others.

 

On Thu, Mar 26, 2015 at 1:31 PM, = Justin Richer <jricher@mit.edu> wrote:

As requested after = last night=E2=80=99s informal meeting, here is the token chaining use = case that I want to see represented in the token swap draft.


[ Client ]  ->   [ A ] -> [ B ] -> [ C ]

An OAuth client gets an access token AT1, just like it always would, = with scopes [A, B, C] in order to call service A, which requires all = three scopes. Service A (an RS) accepts this token since it has its = scope, and then needs to call service B in turn, which requires scopes [B, C]. It could just re-send the token it got in, AT1, = but that would give the downstream RS the ability to call services with = scope [ A ] and it should not be allowed to do that. To limit exposure, = service A calls a token swap at the AS to create AT2 with scopes [ B, C ], effectively acting as an OAuth client = requesting a downscoped token based on AT1. Service A then acts as an = OAuth client to call service B, now acting as an RS to service A=E2=80=99s= client, and can fulfill the request. And it=E2=80=99s turtles all the way down: Service B can also call service C, and now B acts as = a client, requesting AT3 with scope [ C ] based on AT2, and sending AT3 = to service C. This prevents C from being able to call B or A, both of = which would have been available if AT1 had been passed around. Note that service A or the Client can also request = a downscoped token with [ C ] to call service C directly as well, and C = doesn=E2=80=99t have to care how it got there.


In other words, it lets the client software be very, very dumb. It = doesn=E2=80=99t have to do any special processing, doesn=E2=80=99t have = to know what=E2=80=99s in the token, it just follows the recipe of =E2=80=9C= I got a token, I get another token based on this to call someone = else=E2=80=9D. It=E2=80=99s also analogous to the refresh token flow, but with access tokens going = in and out. I=E2=80=99ve deployed this setup several times in different = service deployments. Even though there is a performance hit in the = additional round trips (as Phil brought up in another thread), in these cases the desire to have the tokens hold least = privilege access rights (smallest set of scopes per service) outweighed = any performance hit (which was shown to be rather small in practice).

What I want is for the token swap draft to define or use a mechanism = that allows us to do this. I think we can do that pretty easily by = adjusting the token swap syntax and language, and explicitly calling out = the semantic processing portion (the current core of the document) for what it is: a way for a token issuer to = communicate to a token service specific actions. At a high level, the = spec would be something like:



1. How to swap a token at an AS
  1. Send a request to the token endpoint with a new grant type, = and a token (of any type/format/flavor) on the way in
  2. Get back a new token in a token response
2. Communicating act as / on behalf of semantics via a JWT assertion
  1. How to create (as an AS/RS/client/other issuer) a JWT with = act-as semantics
  2. What to do (as an AS/RS) with a JWT with act-as semantics
  3. How to create a JWT with on-behalf-of semeantics
  4. What to do with a JWT with on-behalf-of-semantics
=   5. How to possibly represent these semantics with something other = than a JWT



Section 2 uses the syntax from section 1. Other applications, like the = one I laid out above, can use the syntax from section 1 as well. This = works for structured, unstructured, self-generated, cross-domain, = within-domain, and other tokens.


 =E2=80=94 Justin

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

 


= --Apple-Mail=_FC5FD7A8-19AE-4DDA-892F-1FBE86DD1AA3-- From nobody Tue Jul 7 16:54:42 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA2531B2A9A for ; Tue, 7 Jul 2015 16:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyrqMr6XBZxS for ; Tue, 7 Jul 2015 16:54:38 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0799.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::799]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7872C1B2A97 for ; Tue, 7 Jul 2015 16:54:37 -0700 (PDT) Received: from BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) by BY2PR03MB1143.namprd03.prod.outlook.com (10.242.239.21) with Microsoft SMTP Server (TLS) id 15.1.195.15; Tue, 7 Jul 2015 23:54:18 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.213.10; Tue, 7 Jul 2015 23:54:16 +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.0213.000; Tue, 7 Jul 2015 23:54:15 +0000 From: Anthony Nadalin To: Justin Richer , Mike Jones Thread-Topic: [OAUTH-WG] Token Chaining Use Case Thread-Index: AQHQZ/MZVBCVjU2GVU65tKvtXzLzTJ0vVM6AgKHqOwCAAA+IgIAAAY/Q Date: Tue, 7 Jul 2015 23:54:15 +0000 Message-ID: References: <826785C8-648D-4A1B-AD8D-E99D76117C67@mit.edu> In-Reply-To: <826785C8-648D-4A1B-AD8D-E99D76117C67@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; x-originating-ip: [2001:4898:80e0:ee43::3] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:9Mb9OhfEKOC6oA5OLg+xe9YujVPHlpgvHJfKystky+XGOsK1zNxgC40pVyr1PkFqA6JtPb1BQKmUHXMQdd2eCjXM2t/tNOxiZofzvgVZwAIKPKld8E4hW5OMfR+GWV3Ee+/wGLOoEerVN0o5aXTPUQ==; 24:WyUKqGgmdARAqhGI0e2CjxZihDC+/4XmbWev/uYKPj77BQ/MpU0o3W1bVGbE2OUhgr+rKavEpZ2AbmOgT2ixFGb7Xhdt2lDkQv81zrCoWcc=; 20:Pj5EFUqvW7iHrMAciWa40Kpla7ZQuHB10Toiyt/32rNqDci2WjL6LmsDbtV7rJWk5JzRilVuQVzAzbvBGsrfuw== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB1143; by2pr03mb443: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 0630013541 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(51444003)(24454002)(377454003)(2950100001)(2656002)(106116001)(93886004)(19300405004)(99286002)(76576001)(74316001)(46102003)(19617315012)(19580395003)(122556002)(5002640100001)(19609705001)(5001770100001)(87936001)(2900100001)(1511001)(2171001)(77156002)(62966003)(15975445007)(5001960100002)(102836002)(77096005)(92566002)(19625215002)(189998001)(40100003)(19580405001)(2561002)(76176999)(50986999)(54356999)(33656002)(16236675004)(86362001)(5003600100002)(3826002)(42262002)(4001450100001)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1234E538E77276C68164A6E4A6920BN3PR0301MB1234_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2015 23:54:15.5283 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 X-Microsoft-Exchange-Diagnostics: 1; BY2PR03MB1143; 2:ZHwpVjfIpa0281U/oHnCN8JiR6zwE9ng3hIItbPOrr7yq0kekcXhgyrnFq1RKnIM; 3:CkCTr7FepIu2ahrerbzMljAjL4qXvtTKXarDTjQROXqE0+eUlQNtEFB00B795rlwDw/SnJCwLnhdWuPaLaG66Kn0BSwsCjqP3XN68KrE8csdRivMiUIFsCxcpyi0Oq63gWujHvN90ZTzccp4gudKng==; 20:pLK51YVqvs4stRWazqbOWrmEENTC6plKibr0++BprxXYJgRaCBVcmLgel9JoJ77JhHCv8Zen+4Cq7kYy/6fn3ioufodA7lizYlaXg8OQo1oRxm1nV5MZNGPMxkXBPBwK3imU8xCpMblRRI9guxNgpHvBZ/qROmBTqijZIx1ZW0GTsNyEI1DKmBHA6j2nz6UJbn0+td6RUaV/gm7Q2SXStzYJ4cTL1TzBIP+CC0Lz/DWWwQHfJ+uyxBjpZSIteCQqZyBdblJfdtffzwRdaOUKCCT5VNzPJpeubWXLLo9+nBgLRlUYK2l+AaQWcXVPf1AVnGhtq2B1nvt/41LG8LfWXwKAOy9dpb+7xXv9Cm08WpA7ajdzLbY/oauSveHH3NlbeWT+YOOgQ0bQ4RdhoRBVqhv+o55mvvFzzT/QXVFxhh/ZruNcF+XEaUlGFrFuvyZKixIR0jvmYeHCTAV1G10yZFG6FI/l3V+HiDxeWv8cYArJgKbiBcOIfJmfsN4p32h8 X-Microsoft-Exchange-Diagnostics: 1; BY2PR03MB1143; 23:PAOn8OCGBTTK1ULGogPt+R4XgiMNfiYDhCpZ/5YwFbGmG7r3K89+5cJn85Fo7NaP4uUZXuxF13jrna4le37clyYlqr0TNp59I4IBo3Um2Oy53uNSctQkkxc9u2WJi9uekDJoe9cr/X+FvK6F93CdjukdQ+P8vm9LtWTcsOS78rlH8suL06/QmoeVxHbAL91WxzTjHMMLULrbDhG6Ey6AsQjWeFkXsrhNZuAfSdNfwmfHKZgfLbTODvyl0KWPYY4T X-OriginatorOrg: microsoft.com Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Token Chaining Use Case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 23:54:41 -0000 --_000_BN3PR0301MB1234E538E77276C68164A6E4A6920BN3PR0301MB1234_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gbm90IHN1cmUgaG93IEJyaWFu4oCZcyBhcHByb2FjaCBzb2x2ZXMgdGhlIGJhc2ljIGdl bmVyaWMgdG9rZW4gZXhjaGFuZ2UgdXNlIGNhc2UgdGhhdCB3ZSBoYXZlDQoNCkZyb206IE9BdXRo IFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEp1c3RpbiBSaWNo ZXINClNlbnQ6IFR1ZXNkYXksIEp1bHkgNywgMjAxNSA0OjQ3IFBNDQpUbzogTWlrZSBKb25lcyA8 TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPg0KQ2M6IDxvYXV0aEBpZXRmLm9yZz4gPG9hdXRo QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gVG9rZW4gQ2hhaW5pbmcgVXNlIENh c2UNCg0KVGhpcyBhcHByb2FjaCBpcyBub3QgYSBnb29kIGZpdCBmb3IgbXkgdXNlIGNhc2VzLCBh bmQgaXTigJlzIHN0aWxsIG5vdCAgT0F1dGgteSBhdCBhbGwuIEl0IHJlcXVpcmVzIGEgc3BlY2lh bGx5LWZvcm1lZCBzZWN1cml0eSBhc3NlcnRpb24gb24gdGhlIHdheSBpbiwgd2hpY2ggdGhlIGNs aWVudCBtdXN0IHVuZGVyc3RhbmQgYW5kIGdlbmVyYXRlLiBJIHN0aWxsIGNhbuKAmXQgdGFrZSBh biBhcmJpdHJhcnkgdG9rZW4gSeKAmXZlIGJlZW4gaGFuZGVkIGJ5IHNvbWVvbmUgZWxzZSBhbmQg cGFzcyBpdCBvZmYgdG8gYmUgcHVzaGVkIGZvcndhcmQuIFRoZSBuZXcg4oCcKl90eXBl4oCdIHBh cmFtZXRlcnMgc2VlbSB0byBtZXJlbHkga2ljayB0aGUgY2FuIGRvd24gdGhlIHJvYWQgaW5zdGVh ZCBvZiBhZGRyZXNzaW5nIHRoZSBwcm9ibGVtcyB3aXRoIHRoZSBjdXJyZW50IHNwZWNpZmljYXRp b24uDQoNCkkgdGhpbmsgdGhhdCBCcmlhbuKAmXMgYXBwcm9hY2ggd29ya3MgbXVjaCBiZXR0ZXIu IEl0IHVucm9sbHMgaW1wb3J0YW50IHBhcmFtZXRlcnMsIHByb3Blcmx5IHVzZXMgdGhlIHRva2Vu IGVuZHBvaW50LCBhbmQgYWxsb3dzIGZvciBhcmJpdHJhcmlseSBmb3JtYXR0ZWQgaW5wdXQgdG9r ZW5zLg0KDQpXaGVuIGNvbWJpbmVkIHdpdGggTmF04oCZcyBkcmFmdCB0aGF0IHNwZWNpZmllcyBo b3cgdG8gcGVyZm9ybSBhbGwgZ2VuZXJpYyBPQXV0aCByZXF1ZXN0cyBhcyBKV1RzIChvciBldmVu IHNvbWUgb2YgdGhlIHVwY29taW5nIFBvUCB3b3JrIGlmIHdlIGV2ZXIgZG8gdGhhdCksIHlvdeKA mXZlIHByZXR0eSBtdWNoIGdvdCB0aGUgZHJhZnQgYmVsb3cgYnV0IHdpdGggbXVjaCBtb3JlIGZs ZXhpYmlsaXR5IGFuZCBwb3dlci4NCg0KIOKAlCBKdXN0aW4NCg0KT24gSnVsIDcsIDIwMTUsIGF0 IDY6NTEgUE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86 TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQoNCkFzIGp1c3QgdXBkYXRlZDxo dHRwOi8vc2VsZi1pc3N1ZWQuaW5mby8/cD0xNDEyPiwgSSBiZWxpZXZlIHRoYXQgdGhlIHdvcmtp bmcgZ3JvdXAgdG9rZW4gZXhjaGFuZ2UgZHJhZnQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMDIgY2FuIG5vdyBhbHNvIHNlcnZlIHRo ZSDigJxPQXV0aHnigJ0gdG9rZW4gZXhjaGFuZ2UgdXNlIGNhc2VzLCBzdWNoIGFzIEp1c3RpbiBh bmQgUGhpbOKAmXMgdG9rZW4gY2hhaW5pbmcgdXNlIGNhc2UsIGFzIHdlbGwgYXMgc3VwcG9ydCBn ZW5lcmFsIHRva2VuIGV4Y2hhbmdlLCBpbmNsdWRpbmcgZXhjaGFuZ2Ugb2YgSldUIGFuZCBTQU1M IHRva2Vucy4gIFRoZSBtZWNoYW5pc20gd291bGQgYmUgdGhlIHNhbWUgb25lIHRoYXQgQnJpYW4g c3VnZ2VzdGVkIGJlbG93IOKAkyBkZWZpbmluZyBzZWN1cml0eSB0b2tlbiB0eXBlIHZhbHVlcyBm b3IgT0F1dGggMi4wIGFjY2VzcyB0b2tlbnMgYW5kIHJlZnJlc2ggdG9rZW5zIOKAkyBlbmFibGlu ZyB0aGVtIHRvIGJlIHVzZWQgYXMgaW5wdXRzIGFuZCBvdXRwdXRzIGluIGFueSBvZiB0aGUgdG9r ZW4gZXhjaGFuZ2VzLg0KDQpGb3IgaW5zdGFuY2UsIGJ5IHVzaW5nIOKAnGFjY2VzcyB0b2tlbuKA nSBhcyB0aGUgaW5wdXQgc2VjdXJpdHkgdG9rZW4gdHlwZSwgcHJvdmlkaW5nIG5ldyBzY29wZSB2 YWx1ZXMsIGFuZCB1c2luZyDigJxhY2Nlc3MgdG9rZW7igJ0gYXMgdGhlIG91dHB1dCBzZWN1cml0 eSB0b2tlbiB0eXBlLCB0b2tlbiBjaGFpbmluZyBpcyBhY2hpZXZlZC4NCg0KTm93LCBhIHF1ZXN0 aW9uIGZvciB0aGUgd29ya2luZyBncm91cOKApiAgV2hhdCBzaG91bGQgdGhlIHNlY3VyaXR5IHRv a2VuIHR5cGUgdmFsdWVzIGZvciBhY2Nlc3MgdG9rZW4gYW5kIHJlZnJlc2ggdG9rZW4gYmU/ICBU d28gZGlmZmVyZW50IGNob2ljZXMgc2VlbSB0byBtYWtlIHNlbnNlLg0KKDEpICBVc2UgdGhlIHZh bHVlcyDigJxhY2Nlc3NfdG9rZW7igJ0gYW5kIOKAnHJlZnJlc2hfdG9rZW7igJ0sIHdoaWNoIGFy ZSB1c2VkIGluIFJGQyA2NzQ5IHRva2VuIHJlc3BvbnNlIHZhbHVlcy4NCigyKSAgRGVmaW5lIG5l dyBVUk5zIGZvciB0aGlzIHVzYWdlLCBzdWNoIGFzIHVybjppZXRmOnBhcmFtczpvYXV0aDp0b2tl bi10eXBlOmFjY2Vzcy10b2tlbiBhbmQgdXJuOmlldGY6cGFyYW1zOm9hdXRoOnRva2VuLXR5cGU6 cmVmcmVzaC10b2tlbi4NCg0KSeKAmWQgcGVyc29uYWxseSBiZSBmaW5lIGp1c3QgdXNpbmcgdGhl IHNob3J0IG5hbWVzIGluICgxKS4NCg0KSWYgcGVvcGxlIGFncmVlIHdpdGggdGhpcyBhcHByb2Fj aCwgd2UgY2FuIGRvY3VtZW50IHRoaXMgdXNhZ2UgaW4gdGhlIC0wMyBkcmFmdCBhbmQgcHVibGlz aCBpdCBhcyBzb29uIGFzIHRoZSBzdWJtaXNzaW9uIHRvb2wgcmVvcGVucyBNb25kYXkgbW9ybmlu ZyBkdXJpbmcgSUVURiA5My4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogT0F1dGggW21haWx0 bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gQ2FtcGJlbGwNClNl bnQ6IFRodXJzZGF5LCBNYXJjaCAyNiwgMjAxNSAzOjE1IFBNDQpUbzogSnVzdGluIFJpY2hlcg0K Q2M6IDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6 IFtPQVVUSC1XR10gVG9rZW4gQ2hhaW5pbmcgVXNlIENhc2UNCg0KVGhpcyBraW5kIG9mIHRva2Vu IGV4Y2hhbmdlIG1pZ2h0IGludm9sdmUgZXhjaGFuZ2VzIG90aGVyIHRoYW4gc3dhcHBpbmcgYW4g QVQgZm9yIGFub3RoZXIgQVQgKGFuZCBkb3duc2NvcGluZyBpdCkuIEl0IG1pZ2h0IGJlIGFuIEFU IGZvciBhIHN0cnVjdHVyZWQgSldUIHNwZWNpZmljYWxseSB0YXJnZXRlZCBhdCBvbmUgb2YgdGhl IHRoZSBwYXJ0aWN1bGFyIHNlcnZpY2VzIHRoYXQgdGhlIG9yaWdpbmFsIFJTIG5lZWRzIHRvIGNh bGwuIE9yIGFuIEFUIG1pZ2h0IGJlIGV4Y2hhbmdlZCBmb3IgYSBTQU1MIGFzc2VydGlvbiB0byB1 c2Ugd2l0aCBsZWdhY3kgU09BUCBzZXJ2ZXJpZXMuICBBIGdvb2QgZ2VuZXJhbCB0b2tlbiBleGNo YW5nZSBtZWNoYW5pc20gZW5hYmxlcyBsb3RzIG9mIHZhcmlhdGlvbnMgb2YgY2FzZXMgbGlrZSB0 aGUgb25lIEp1c3RpbiBtZW50aW9uZWQuIEFuZCBtb3JlLiBJbiBmYWN0LCBJIHRoaW5rIGRvd25z Y29waW5nIG1pZ2h0IGJlIGEgbWlub3JpdHkgdXNlIGNhc2Ugd2hlcmUgd2hhdCB0b2tlbiBleGNo YW5nZSBpcyBvZnRlbiBuZWVkIGZvciBpcyB0cmFuc2xhdGluZyB0b2tlbnMgZnJvbSB3aGF0IHlv dSBoYXZlIGludG8gd2hhdCB0aGUgcmVzb3VyY2UgeW91IG5lZWQgdG8gY2FsbCBjYW4gZGVhbCB3 aXRoLg0KVGhlcmUgbmVlZCB0byBiZSB3YXlzIGZvciB0aGUgY2FsbGVyIHRvIHRlbGwgdGhlIEFT IGFib3V0IHRoZSB0b2tlbiBpdCdzIGFza2luZyBmb3IgLSBieSB0eXBlIG9yIGJ5IHRoZSBhZGRy ZXNzL2lkZW50aWZpZXIgb2Ygd2hlcmUgaXQnbGwgYmUgdXNlZC4gVGhlcmUgbmVlZHMgdG8gYmUg d2F5cyBmb3IgdGhlIGNhbGxlciB0byBhdXRoZW50aWNhdGUgdG8gdGhlIEFTLiBBbmQgdGhlcmUg bmVlZHMgdG8gYmUgc29tZSB3YXkgb2YgZXhwcmVzc2luZyB0aGlzIGRlbGVnYXRpb24gdGhpbmcg KHRob3VnaCBJJ20gc3RpbGwgbm90IHRvdGFsbHkgY29udmluY2VkIGl0IGNvdWxkbid0IGJlIGp1 c3QgdGhlIHRva2VuIGlzIGFib3V0IHRoZSB1c2VyL3ByaW5jaXBhbCBhbmQgdGhlIGNhbGxlci9j bGllbnQgb2YgdGhlIGV4Y2hhbmdlIGlzIHdobyBpcyBiZWluZyBkZWxlZ2F0ZWQgdG8pLg0KSSBy ZWFsaXplIGZldyAoYXBwcm9hY2hpbmcgemVybykgcGVvcGxlIGhhdmUgb3IgYXJlIGdvaW5nIHRv IHJlYWQgaXQgYnV0IEkgaGF2ZSBlbmRlYXZvcmVkIHRvIGNvdmVyIGFsbCB0aGVzZSB0aGluZ3Mg aW4gdGhlIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhbXBiZWxsLW9hdXRoLXN0 cy0wMiBkcmFmdC4gSXQncyBhbiBlYXJseSBkcmFmdCBzbyBub3Qgd2l0aG91dCBpdCBzb21lIHJv dWdoIGVkZ2VzIGJ1dCBjYW4gcHJvdmlkZSBzb21lIGd1aWRhbmNlIG9uIHdoYXQgaXMgbmVlZGVk IGFuZCBvZmZlcnMgc29tZSBwcm90b2NvbCBzeW50YXggZm9yIGV4cHJlc3NpbmcgaXQuIEkgYmVs aWV2ZSBKdXN0aW4ncyB1c2UgY2FzZSB3b3VsZCBiZSBjb3ZlcmVkIGJ5IGl0IChkZWZpbmluZyBh IHNwZWNpZmljIHRva2VuIHR5cGUgVVJJIGZvciBhbiBPQXV0aCBhY2Nlc3MgdG9rZW4gaXNzdWVk IGJ5IHRoZSBBUyBpbiBxdWVzdGlvbiBtaWdodCBiZSBuZWVkZWQpIGFzIGFyZSBtYW55IG90aGVy cy4NCg0KT24gVGh1LCBNYXIgMjYsIDIwMTUgYXQgMTozMSBQTSwgSnVzdGluIFJpY2hlciA8anJp Y2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PiB3cm90ZToNCkFzIHJlcXVlc3Rl ZCBhZnRlciBsYXN0IG5pZ2h04oCZcyBpbmZvcm1hbCBtZWV0aW5nLCBoZXJlIGlzIHRoZSB0b2tl biBjaGFpbmluZyB1c2UgY2FzZSB0aGF0IEkgd2FudCB0byBzZWUgcmVwcmVzZW50ZWQgaW4gdGhl IHRva2VuIHN3YXAgZHJhZnQuDQoNCg0KWyBDbGllbnQgXSAgLT4gICBbIEEgXSAtPiBbIEIgXSAt PiBbIEMgXQ0KDQpBbiBPQXV0aCBjbGllbnQgZ2V0cyBhbiBhY2Nlc3MgdG9rZW4gQVQxLCBqdXN0 IGxpa2UgaXQgYWx3YXlzIHdvdWxkLCB3aXRoIHNjb3BlcyBbQSwgQiwgQ10gaW4gb3JkZXIgdG8g Y2FsbCBzZXJ2aWNlIEEsIHdoaWNoIHJlcXVpcmVzIGFsbCB0aHJlZSBzY29wZXMuIFNlcnZpY2Ug QSAoYW4gUlMpIGFjY2VwdHMgdGhpcyB0b2tlbiBzaW5jZSBpdCBoYXMgaXRzIHNjb3BlLCBhbmQg dGhlbiBuZWVkcyB0byBjYWxsIHNlcnZpY2UgQiBpbiB0dXJuLCB3aGljaCByZXF1aXJlcyBzY29w ZXMgW0IsIENdLiBJdCBjb3VsZCBqdXN0IHJlLXNlbmQgdGhlIHRva2VuIGl0IGdvdCBpbiwgQVQx LCBidXQgdGhhdCB3b3VsZCBnaXZlIHRoZSBkb3duc3RyZWFtIFJTIHRoZSBhYmlsaXR5IHRvIGNh bGwgc2VydmljZXMgd2l0aCBzY29wZSBbIEEgXSBhbmQgaXQgc2hvdWxkIG5vdCBiZSBhbGxvd2Vk IHRvIGRvIHRoYXQuIFRvIGxpbWl0IGV4cG9zdXJlLCBzZXJ2aWNlIEEgY2FsbHMgYSB0b2tlbiBz d2FwIGF0IHRoZSBBUyB0byBjcmVhdGUgQVQyIHdpdGggc2NvcGVzIFsgQiwgQyBdLCBlZmZlY3Rp dmVseSBhY3RpbmcgYXMgYW4gT0F1dGggY2xpZW50IHJlcXVlc3RpbmcgYSBkb3duc2NvcGVkIHRv a2VuIGJhc2VkIG9uIEFUMS4gU2VydmljZSBBIHRoZW4gYWN0cyBhcyBhbiBPQXV0aCBjbGllbnQg dG8gY2FsbCBzZXJ2aWNlIEIsIG5vdyBhY3RpbmcgYXMgYW4gUlMgdG8gc2VydmljZSBB4oCZcyBj bGllbnQsIGFuZCBjYW4gZnVsZmlsbCB0aGUgcmVxdWVzdC4gQW5kIGl04oCZcyB0dXJ0bGVzIGFs bCB0aGUgd2F5IGRvd246IFNlcnZpY2UgQiBjYW4gYWxzbyBjYWxsIHNlcnZpY2UgQywgYW5kIG5v dyBCIGFjdHMgYXMgYSBjbGllbnQsIHJlcXVlc3RpbmcgQVQzIHdpdGggc2NvcGUgWyBDIF0gYmFz ZWQgb24gQVQyLCBhbmQgc2VuZGluZyBBVDMgdG8gc2VydmljZSBDLiBUaGlzIHByZXZlbnRzIEMg ZnJvbSBiZWluZyBhYmxlIHRvIGNhbGwgQiBvciBBLCBib3RoIG9mIHdoaWNoIHdvdWxkIGhhdmUg YmVlbiBhdmFpbGFibGUgaWYgQVQxIGhhZCBiZWVuIHBhc3NlZCBhcm91bmQuIE5vdGUgdGhhdCBz ZXJ2aWNlIEEgb3IgdGhlIENsaWVudCBjYW4gYWxzbyByZXF1ZXN0IGEgZG93bnNjb3BlZCB0b2tl biB3aXRoIFsgQyBdIHRvIGNhbGwgc2VydmljZSBDIGRpcmVjdGx5IGFzIHdlbGwsIGFuZCBDIGRv ZXNu4oCZdCBoYXZlIHRvIGNhcmUgaG93IGl0IGdvdCB0aGVyZS4NCg0KDQpJbiBvdGhlciB3b3Jk cywgaXQgbGV0cyB0aGUgY2xpZW50IHNvZnR3YXJlIGJlIHZlcnksIHZlcnkgZHVtYi4gSXQgZG9l c27igJl0IGhhdmUgdG8gZG8gYW55IHNwZWNpYWwgcHJvY2Vzc2luZywgZG9lc27igJl0IGhhdmUg dG8ga25vdyB3aGF04oCZcyBpbiB0aGUgdG9rZW4sIGl0IGp1c3QgZm9sbG93cyB0aGUgcmVjaXBl IG9mIOKAnEkgZ290IGEgdG9rZW4sIEkgZ2V0IGFub3RoZXIgdG9rZW4gYmFzZWQgb24gdGhpcyB0 byBjYWxsIHNvbWVvbmUgZWxzZeKAnS4gSXTigJlzIGFsc28gYW5hbG9nb3VzIHRvIHRoZSByZWZy ZXNoIHRva2VuIGZsb3csIGJ1dCB3aXRoIGFjY2VzcyB0b2tlbnMgZ29pbmcgaW4gYW5kIG91dC4g SeKAmXZlIGRlcGxveWVkIHRoaXMgc2V0dXAgc2V2ZXJhbCB0aW1lcyBpbiBkaWZmZXJlbnQgc2Vy dmljZSBkZXBsb3ltZW50cy4gRXZlbiB0aG91Z2ggdGhlcmUgaXMgYSBwZXJmb3JtYW5jZSBoaXQg aW4gdGhlIGFkZGl0aW9uYWwgcm91bmQgdHJpcHMgKGFzIFBoaWwgYnJvdWdodCB1cCBpbiBhbm90 aGVyIHRocmVhZCksIGluIHRoZXNlIGNhc2VzIHRoZSBkZXNpcmUgdG8gaGF2ZSB0aGUgdG9rZW5z IGhvbGQgbGVhc3QgcHJpdmlsZWdlIGFjY2VzcyByaWdodHMgKHNtYWxsZXN0IHNldCBvZiBzY29w ZXMgcGVyIHNlcnZpY2UpIG91dHdlaWdoZWQgYW55IHBlcmZvcm1hbmNlIGhpdCAod2hpY2ggd2Fz IHNob3duIHRvIGJlIHJhdGhlciBzbWFsbCBpbiBwcmFjdGljZSkuDQoNCldoYXQgSSB3YW50IGlz IGZvciB0aGUgdG9rZW4gc3dhcCBkcmFmdCB0byBkZWZpbmUgb3IgdXNlIGEgbWVjaGFuaXNtIHRo YXQgYWxsb3dzIHVzIHRvIGRvIHRoaXMuIEkgdGhpbmsgd2UgY2FuIGRvIHRoYXQgcHJldHR5IGVh c2lseSBieSBhZGp1c3RpbmcgdGhlIHRva2VuIHN3YXAgc3ludGF4IGFuZCBsYW5ndWFnZSwgYW5k IGV4cGxpY2l0bHkgY2FsbGluZyBvdXQgdGhlIHNlbWFudGljIHByb2Nlc3NpbmcgcG9ydGlvbiAo dGhlIGN1cnJlbnQgY29yZSBvZiB0aGUgZG9jdW1lbnQpIGZvciB3aGF0IGl0IGlzOiBhIHdheSBm b3IgYSB0b2tlbiBpc3N1ZXIgdG8gY29tbXVuaWNhdGUgdG8gYSB0b2tlbiBzZXJ2aWNlIHNwZWNp ZmljIGFjdGlvbnMuIEF0IGEgaGlnaCBsZXZlbCwgdGhlIHNwZWMgd291bGQgYmUgc29tZXRoaW5n IGxpa2U6DQoNCg0KDQoxLiBIb3cgdG8gc3dhcCBhIHRva2VuIGF0IGFuIEFTDQogIDEuIFNlbmQg YSByZXF1ZXN0IHRvIHRoZSB0b2tlbiBlbmRwb2ludCB3aXRoIGEgbmV3IGdyYW50IHR5cGUsIGFu ZCBhIHRva2VuIChvZiBhbnkgdHlwZS9mb3JtYXQvZmxhdm9yKSBvbiB0aGUgd2F5IGluDQogIDIu IEdldCBiYWNrIGEgbmV3IHRva2VuIGluIGEgdG9rZW4gcmVzcG9uc2UNCjIuIENvbW11bmljYXRp bmcgYWN0IGFzIC8gb24gYmVoYWxmIG9mIHNlbWFudGljcyB2aWEgYSBKV1QgYXNzZXJ0aW9uDQog IDEuIEhvdyB0byBjcmVhdGUgKGFzIGFuIEFTL1JTL2NsaWVudC9vdGhlciBpc3N1ZXIpIGEgSldU IHdpdGggYWN0LWFzIHNlbWFudGljcw0KICAyLiBXaGF0IHRvIGRvIChhcyBhbiBBUy9SUykgd2l0 aCBhIEpXVCB3aXRoIGFjdC1hcyBzZW1hbnRpY3MNCiAgMy4gSG93IHRvIGNyZWF0ZSBhIEpXVCB3 aXRoIG9uLWJlaGFsZi1vZiBzZW1lYW50aWNzDQogIDQuIFdoYXQgdG8gZG8gd2l0aCBhIEpXVCB3 aXRoIG9uLWJlaGFsZi1vZi1zZW1hbnRpY3MNCiAgNS4gSG93IHRvIHBvc3NpYmx5IHJlcHJlc2Vu dCB0aGVzZSBzZW1hbnRpY3Mgd2l0aCBzb21ldGhpbmcgb3RoZXIgdGhhbiBhIEpXVA0KDQoNCg0K U2VjdGlvbiAyIHVzZXMgdGhlIHN5bnRheCBmcm9tIHNlY3Rpb24gMS4gT3RoZXIgYXBwbGljYXRp b25zLCBsaWtlIHRoZSBvbmUgSSBsYWlkIG91dCBhYm92ZSwgY2FuIHVzZSB0aGUgc3ludGF4IGZy b20gc2VjdGlvbiAxIGFzIHdlbGwuIFRoaXMgd29ya3MgZm9yIHN0cnVjdHVyZWQsIHVuc3RydWN0 dXJlZCwgc2VsZi1nZW5lcmF0ZWQsIGNyb3NzLWRvbWFpbiwgd2l0aGluLWRvbWFpbiwgYW5kIG90 aGVyIHRva2Vucy4NCg0KDQog4oCUIEp1c3Rpbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9y ZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoDQoNCg0K --_000_BN3PR0301MB1234E538E77276C68164A6E4A6920BN3PR0301MB1234_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGlu aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw ZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnR0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOiMwMDMzNjY7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFu LmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ SeKAmW0gbm90IHN1cmUgaG93IEJyaWFu4oCZcyBhcHByb2FjaCBzb2x2ZXMgdGhlIGJhc2ljIGdl bmVyaWMgdG9rZW4gZXhjaGFuZ2UgdXNlIGNhc2UgdGhhdCB3ZSBoYXZlPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9h PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPkp1c3RpbiBSaWNoZXI8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVseSA3LCAyMDE1 IDQ6NDcgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXMgJmx0O01pY2hhZWwuSm9uZXNAbWlj cm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+ICZsdDtvYXV0aEBpZXRmLm9yZyZndDsgJmx0 O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBU b2tlbiBDaGFpbmluZyBVc2UgQ2FzZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoaXMgYXBwcm9hY2ggaXMgbm90IGEgZ29vZCBmaXQgZm9yIG15IHVzZSBj YXNlcywgYW5kIGl04oCZcyBzdGlsbCBub3QgJm5ic3A7T0F1dGgteSBhdCBhbGwuIEl0IHJlcXVp cmVzIGEgc3BlY2lhbGx5LWZvcm1lZCBzZWN1cml0eSBhc3NlcnRpb24gb24gdGhlIHdheSBpbiwg d2hpY2ggdGhlIGNsaWVudCBtdXN0IHVuZGVyc3RhbmQgYW5kIGdlbmVyYXRlLiBJIHN0aWxsIGNh buKAmXQgdGFrZSBhbiBhcmJpdHJhcnkgdG9rZW4NCiBJ4oCZdmUgYmVlbiBoYW5kZWQgYnkgc29t ZW9uZSBlbHNlIGFuZCBwYXNzIGl0IG9mZiB0byBiZSBwdXNoZWQgZm9yd2FyZC4gVGhlIG5ldyDi gJwqX3R5cGXigJ0gcGFyYW1ldGVycyBzZWVtIHRvIG1lcmVseSBraWNrIHRoZSBjYW4gZG93biB0 aGUgcm9hZCBpbnN0ZWFkIG9mIGFkZHJlc3NpbmcgdGhlIHByb2JsZW1zIHdpdGggdGhlIGN1cnJl bnQgc3BlY2lmaWNhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoYXQgQnJpYW7igJlzIGFwcHJvYWNoIHdvcmtzIG11Y2gg YmV0dGVyLiBJdCB1bnJvbGxzIGltcG9ydGFudCBwYXJhbWV0ZXJzLCBwcm9wZXJseSB1c2VzIHRo ZSB0b2tlbiBlbmRwb2ludCwgYW5kIGFsbG93cyBmb3IgYXJiaXRyYXJpbHkgZm9ybWF0dGVkIGlu cHV0IHRva2Vucy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+V2hlbiBjb21iaW5lZCB3aXRoIE5hdOKAmXMgZHJhZnQgdGhhdCBzcGVj aWZpZXMgaG93IHRvIHBlcmZvcm0gYWxsIGdlbmVyaWMgT0F1dGggcmVxdWVzdHMgYXMgSldUcyAo b3IgZXZlbiBzb21lIG9mIHRoZSB1cGNvbWluZyBQb1Agd29yayBpZiB3ZSBldmVyIGRvIHRoYXQp LCB5b3XigJl2ZSBwcmV0dHkgbXVjaCBnb3QgdGhlIGRyYWZ0IGJlbG93IGJ1dCB3aXRoIG11Y2gg bW9yZSBmbGV4aWJpbGl0eSBhbmQgcG93ZXIuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO+KAlCBKdXN0aW48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEp1bCA3LCAy MDE1LCBhdCA2OjUxIFBNLCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48YSBocmVmPSJodHRwOi8vc2VsZi1pc3N1ZWQuaW5m by8/cD0xNDEyIj5BcyBqdXN0IHVwZGF0ZWQ8L2E+LCBJIGJlbGlldmUgdGhhdCB0aGUgd29ya2lu ZyBncm91cCB0b2tlbiBleGNoYW5nZSBkcmFmdA0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMDIiPmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTAyPC9hPiBj YW4gbm93IGFsc28gc2VydmUgdGhlIOKAnE9BdXRoeeKAnSB0b2tlbiBleGNoYW5nZSB1c2UgY2Fz ZXMsIHN1Y2ggYXMgSnVzdGluIGFuZCBQaGls4oCZcyB0b2tlbiBjaGFpbmluZyB1c2UgY2FzZSwg YXMgd2VsbA0KIGFzIHN1cHBvcnQgZ2VuZXJhbCB0b2tlbiBleGNoYW5nZSwgaW5jbHVkaW5nIGV4 Y2hhbmdlIG9mIEpXVCBhbmQgU0FNTCB0b2tlbnMuJm5ic3A7IFRoZSBtZWNoYW5pc20gd291bGQg YmUgdGhlIHNhbWUgb25lIHRoYXQgQnJpYW4gc3VnZ2VzdGVkIGJlbG93IOKAkyBkZWZpbmluZyBz ZWN1cml0eSB0b2tlbiB0eXBlIHZhbHVlcyBmb3IgT0F1dGggMi4wIGFjY2VzcyB0b2tlbnMgYW5k IHJlZnJlc2ggdG9rZW5zIOKAkyBlbmFibGluZyB0aGVtIHRvIGJlIHVzZWQgYXMNCiBpbnB1dHMg YW5kIG91dHB1dHMgaW4gYW55IG9mIHRoZSB0b2tlbiBleGNoYW5nZXMuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Gb3IgaW5zdGFuY2UsIGJ5IHVzaW5nIOKAnGFj Y2VzcyB0b2tlbuKAnSBhcyB0aGUgaW5wdXQgc2VjdXJpdHkgdG9rZW4gdHlwZSwgcHJvdmlkaW5n IG5ldyBzY29wZSB2YWx1ZXMsIGFuZCB1c2luZyDigJxhY2Nlc3MgdG9rZW7igJ0gYXMgdGhlIG91 dHB1dCBzZWN1cml0eSB0b2tlbiB0eXBlLA0KIHRva2VuIGNoYWluaW5nIGlzIGFjaGlldmVkLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Tm93LCBhIHF1ZXN0aW9u IGZvciB0aGUgd29ya2luZyBncm91cOKApiZuYnNwOyBXaGF0IHNob3VsZCB0aGUgc2VjdXJpdHkg dG9rZW4gdHlwZSB2YWx1ZXMgZm9yIGFjY2VzcyB0b2tlbiBhbmQgcmVmcmVzaCB0b2tlbiBiZT8m bmJzcDsgVHdvIGRpZmZlcmVudCBjaG9pY2VzIHNlZW0gdG8gbWFrZQ0KIHNlbnNlLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4oMSkmbmJzcDsgVXNlIHRoZSB2YWx1ZXMg4oCcYWNjZXNzX3Rva2Vu4oCdIGFu ZCDigJxyZWZyZXNoX3Rva2Vu4oCdLCB3aGljaCBhcmUgdXNlZCBpbiBSRkMgNjc0OSB0b2tlbiBy ZXNwb25zZSB2YWx1ZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPigyKSZuYnNwOyBEZWZpbmUgbmV3IFVS TnMgZm9yIHRoaXMgdXNhZ2UsIHN1Y2ggYXMNCjwvc3Bhbj48dHQ+PHNwYW4gbGFuZz0iRU4iIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij51cm46aWV0ZjpwYXJhbXM6b2F1dGg6dG9rZW4tdHlwZTph Y2Nlc3MtdG9rZW48L3NwYW4+PC90dD48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5hbmQNCjwvc3Bh bj48dHQ+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij51cm46aWV0Zjpw YXJhbXM6b2F1dGg6dG9rZW4tdHlwZTpyZWZyZXNoLXRva2VuPC9zcGFuPjwvdHQ+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPknigJlkIHBlcnNvbmFsbHkgYmUgZmluZSBqdXN0IHVzaW5nIHRoZSBzaG9ydCBu YW1lcyBpbiAoMSkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5J ZiBwZW9wbGUgYWdyZWUgd2l0aCB0aGlzIGFwcHJvYWNoLCB3ZSBjYW4gZG9jdW1lbnQgdGhpcyB1 c2FnZSBpbiB0aGUgLTAzIGRyYWZ0IGFuZCBwdWJsaXNoIGl0IGFzIHNvb24gYXMgdGhlIHN1Ym1p c3Npb24gdG9vbCByZW9wZW5zIE1vbmRheSBtb3JuaW5nIGR1cmluZyBJRVRGDQogOTMuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj4gT0F1dGggWzxhIGhyZWY9Im1haWx0bzpv YXV0aC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5d DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJyaWFuIENhbXBiZWxsPGJyPg0KPGI+U2VudDo8L2I+IFRo dXJzZGF5LCBNYXJjaCAyNiwgMjAxNSAzOjE1IFBNPGJyPg0KPGI+VG86PC9iPiBKdXN0aW4gUmlj aGVyPGJyPg0KPGI+Q2M6PC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5v YXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0dd IFRva2VuIENoYWluaW5nIFVzZSBDYXNlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlRoaXMga2lu ZCBvZiB0b2tlbiBleGNoYW5nZSBtaWdodCBpbnZvbHZlIGV4Y2hhbmdlcyBvdGhlciB0aGFuIHN3 YXBwaW5nIGFuIEFUIGZvciBhbm90aGVyIEFUIChhbmQgZG93bnNjb3BpbmcgaXQpLiBJdCBtaWdo dCBiZSBhbiBBVCBmb3IgYSBzdHJ1Y3R1cmVkIEpXVCBzcGVjaWZpY2FsbHkgdGFyZ2V0ZWQgYXQg b25lIG9mIHRoZSB0aGUgcGFydGljdWxhciBzZXJ2aWNlcw0KIHRoYXQgdGhlIG9yaWdpbmFsIFJT IG5lZWRzIHRvIGNhbGwuIE9yIGFuIEFUIG1pZ2h0IGJlIGV4Y2hhbmdlZCBmb3IgYSBTQU1MIGFz c2VydGlvbiB0byB1c2Ugd2l0aCBsZWdhY3kgU09BUCBzZXJ2ZXJpZXMuJm5ic3A7IEEgZ29vZCBn ZW5lcmFsIHRva2VuIGV4Y2hhbmdlIG1lY2hhbmlzbSBlbmFibGVzIGxvdHMgb2YgdmFyaWF0aW9u cyBvZiBjYXNlcyBsaWtlIHRoZSBvbmUgSnVzdGluIG1lbnRpb25lZC4gQW5kIG1vcmUuIEluIGZh Y3QsIEkgdGhpbmsgZG93bnNjb3BpbmcNCiBtaWdodCBiZSBhIG1pbm9yaXR5IHVzZSBjYXNlIHdo ZXJlIHdoYXQgdG9rZW4gZXhjaGFuZ2UgaXMgb2Z0ZW4gbmVlZCBmb3IgaXMgdHJhbnNsYXRpbmcg dG9rZW5zIGZyb20gd2hhdCB5b3UgaGF2ZSBpbnRvIHdoYXQgdGhlIHJlc291cmNlIHlvdSBuZWVk IHRvIGNhbGwgY2FuIGRlYWwgd2l0aC4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlRoZXJlIG5lZWQgdG8g YmUgd2F5cyBmb3IgdGhlIGNhbGxlciB0byB0ZWxsIHRoZSBBUyBhYm91dCB0aGUgdG9rZW4gaXQn cyBhc2tpbmcgZm9yIC0gYnkgdHlwZSBvciBieSB0aGUgYWRkcmVzcy9pZGVudGlmaWVyIG9mIHdo ZXJlIGl0J2xsIGJlIHVzZWQuIFRoZXJlIG5lZWRzIHRvIGJlIHdheXMgZm9yIHRoZSBjYWxsZXIg dG8gYXV0aGVudGljYXRlIHRvIHRoZQ0KIEFTLiBBbmQgdGhlcmUgbmVlZHMgdG8gYmUgc29tZSB3 YXkgb2YgZXhwcmVzc2luZyB0aGlzIGRlbGVnYXRpb24gdGhpbmcgKHRob3VnaCBJJ20gc3RpbGwg bm90IHRvdGFsbHkgY29udmluY2VkIGl0IGNvdWxkbid0IGJlIGp1c3QgdGhlIHRva2VuIGlzIGFi b3V0IHRoZSB1c2VyL3ByaW5jaXBhbCBhbmQgdGhlIGNhbGxlci9jbGllbnQgb2YgdGhlIGV4Y2hh bmdlIGlzIHdobyBpcyBiZWluZyBkZWxlZ2F0ZWQgdG8pLg0KPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgcmVhbGl6ZSBmZXcgKGFwcHJvYWNoaW5nIHplcm8p IHBlb3BsZSBoYXZlIG9yIGFyZSBnb2luZyB0byByZWFkIGl0IGJ1dCBJIGhhdmUgZW5kZWF2b3Jl ZCB0byBjb3ZlciBhbGwgdGhlc2UgdGhpbmdzIGluIHRoZQ0KPGEgaHJlZj0iaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtY2FtcGJlbGwtb2F1dGgtc3RzLTAyIiB0YXJnZXQ9Il9ibGFu ayI+DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW1wYmVsbC1vYXV0aC1zdHMt MDI8L2E+IGRyYWZ0LiBJdCdzIGFuIGVhcmx5IGRyYWZ0IHNvIG5vdCB3aXRob3V0IGl0IHNvbWUg cm91Z2ggZWRnZXMgYnV0IGNhbiBwcm92aWRlIHNvbWUgZ3VpZGFuY2Ugb24gd2hhdCBpcyBuZWVk ZWQgYW5kIG9mZmVycyBzb21lIHByb3RvY29sIHN5bnRheCBmb3IgZXhwcmVzc2luZyBpdC4gSSBi ZWxpZXZlIEp1c3RpbidzIHVzZSBjYXNlIHdvdWxkIGJlDQogY292ZXJlZCBieSBpdCAoZGVmaW5p bmcgYSBzcGVjaWZpYyB0b2tlbiB0eXBlIFVSSSBmb3IgYW4gT0F1dGggYWNjZXNzIHRva2VuIGlz c3VlZCBieSB0aGUgQVMgaW4gcXVlc3Rpb24gbWlnaHQgYmUgbmVlZGVkKSBhcyBhcmUgbWFueSBv dGhlcnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBU aHUsIE1hciAyNiwgMjAxNSBhdCAxOjMxIFBNLCBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJt YWlsdG86anJpY2hlckBtaXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXQuZWR1PC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPkFzIHJlcXVlc3RlZCBhZnRlciBsYXN0IG5pZ2h04oCZcyBp bmZvcm1hbCBtZWV0aW5nLCBoZXJlIGlzIHRoZSB0b2tlbiBjaGFpbmluZyB1c2UgY2FzZSB0aGF0 IEkgd2FudCB0byBzZWUgcmVwcmVzZW50ZWQgaW4gdGhlIHRva2VuIHN3YXAgZHJhZnQuPGJyPg0K PGJyPg0KPGJyPg0KWyBDbGllbnQgXSZuYnNwOyAtJmd0OyZuYnNwOyAmbmJzcDtbIEEgXSAtJmd0 OyBbIEIgXSAtJmd0OyBbIEMgXTxicj4NCjxicj4NCkFuIE9BdXRoIGNsaWVudCBnZXRzIGFuIGFj Y2VzcyB0b2tlbiBBVDEsIGp1c3QgbGlrZSBpdCBhbHdheXMgd291bGQsIHdpdGggc2NvcGVzIFtB LCBCLCBDXSBpbiBvcmRlciB0byBjYWxsIHNlcnZpY2UgQSwgd2hpY2ggcmVxdWlyZXMgYWxsIHRo cmVlIHNjb3Blcy4gU2VydmljZSBBIChhbiBSUykgYWNjZXB0cyB0aGlzIHRva2VuIHNpbmNlIGl0 IGhhcyBpdHMgc2NvcGUsIGFuZCB0aGVuIG5lZWRzIHRvIGNhbGwgc2VydmljZSBCIGluIHR1cm4s IHdoaWNoDQogcmVxdWlyZXMgc2NvcGVzIFtCLCBDXS4gSXQgY291bGQganVzdCByZS1zZW5kIHRo ZSB0b2tlbiBpdCBnb3QgaW4sIEFUMSwgYnV0IHRoYXQgd291bGQgZ2l2ZSB0aGUgZG93bnN0cmVh bSBSUyB0aGUgYWJpbGl0eSB0byBjYWxsIHNlcnZpY2VzIHdpdGggc2NvcGUgWyBBIF0gYW5kIGl0 IHNob3VsZCBub3QgYmUgYWxsb3dlZCB0byBkbyB0aGF0LiBUbyBsaW1pdCBleHBvc3VyZSwgc2Vy dmljZSBBIGNhbGxzIGEgdG9rZW4gc3dhcCBhdCB0aGUgQVMgdG8NCiBjcmVhdGUgQVQyIHdpdGgg c2NvcGVzIFsgQiwgQyBdLCBlZmZlY3RpdmVseSBhY3RpbmcgYXMgYW4gT0F1dGggY2xpZW50IHJl cXVlc3RpbmcgYSBkb3duc2NvcGVkIHRva2VuIGJhc2VkIG9uIEFUMS4gU2VydmljZSBBIHRoZW4g YWN0cyBhcyBhbiBPQXV0aCBjbGllbnQgdG8gY2FsbCBzZXJ2aWNlIEIsIG5vdyBhY3RpbmcgYXMg YW4gUlMgdG8gc2VydmljZSBB4oCZcyBjbGllbnQsIGFuZCBjYW4gZnVsZmlsbCB0aGUgcmVxdWVz dC4gQW5kIGl04oCZcyB0dXJ0bGVzDQogYWxsIHRoZSB3YXkgZG93bjogU2VydmljZSBCIGNhbiBh bHNvIGNhbGwgc2VydmljZSBDLCBhbmQgbm93IEIgYWN0cyBhcyBhIGNsaWVudCwgcmVxdWVzdGlu ZyBBVDMgd2l0aCBzY29wZSBbIEMgXSBiYXNlZCBvbiBBVDIsIGFuZCBzZW5kaW5nIEFUMyB0byBz ZXJ2aWNlIEMuIFRoaXMgcHJldmVudHMgQyBmcm9tIGJlaW5nIGFibGUgdG8gY2FsbCBCIG9yIEEs IGJvdGggb2Ygd2hpY2ggd291bGQgaGF2ZSBiZWVuIGF2YWlsYWJsZSBpZiBBVDEgaGFkDQogYmVl biBwYXNzZWQgYXJvdW5kLiBOb3RlIHRoYXQgc2VydmljZSBBIG9yIHRoZSBDbGllbnQgY2FuIGFs c28gcmVxdWVzdCBhIGRvd25zY29wZWQgdG9rZW4gd2l0aCBbIEMgXSB0byBjYWxsIHNlcnZpY2Ug QyBkaXJlY3RseSBhcyB3ZWxsLCBhbmQgQyBkb2VzbuKAmXQgaGF2ZSB0byBjYXJlIGhvdyBpdCBn b3QgdGhlcmUuPGJyPg0KPGJyPg0KPGJyPg0KSW4gb3RoZXIgd29yZHMsIGl0IGxldHMgdGhlIGNs aWVudCBzb2Z0d2FyZSBiZSB2ZXJ5LCB2ZXJ5IGR1bWIuIEl0IGRvZXNu4oCZdCBoYXZlIHRvIGRv IGFueSBzcGVjaWFsIHByb2Nlc3NpbmcsIGRvZXNu4oCZdCBoYXZlIHRvIGtub3cgd2hhdOKAmXMg aW4gdGhlIHRva2VuLCBpdCBqdXN0IGZvbGxvd3MgdGhlIHJlY2lwZSBvZiDigJxJIGdvdCBhIHRv a2VuLCBJIGdldCBhbm90aGVyIHRva2VuIGJhc2VkIG9uIHRoaXMgdG8gY2FsbCBzb21lb25lIGVs c2XigJ0uIEl04oCZcw0KIGFsc28gYW5hbG9nb3VzIHRvIHRoZSByZWZyZXNoIHRva2VuIGZsb3cs IGJ1dCB3aXRoIGFjY2VzcyB0b2tlbnMgZ29pbmcgaW4gYW5kIG91dC4gSeKAmXZlIGRlcGxveWVk IHRoaXMgc2V0dXAgc2V2ZXJhbCB0aW1lcyBpbiBkaWZmZXJlbnQgc2VydmljZSBkZXBsb3ltZW50 cy4gRXZlbiB0aG91Z2ggdGhlcmUgaXMgYSBwZXJmb3JtYW5jZSBoaXQgaW4gdGhlIGFkZGl0aW9u YWwgcm91bmQgdHJpcHMgKGFzIFBoaWwgYnJvdWdodCB1cCBpbiBhbm90aGVyDQogdGhyZWFkKSwg aW4gdGhlc2UgY2FzZXMgdGhlIGRlc2lyZSB0byBoYXZlIHRoZSB0b2tlbnMgaG9sZCBsZWFzdCBw cml2aWxlZ2UgYWNjZXNzIHJpZ2h0cyAoc21hbGxlc3Qgc2V0IG9mIHNjb3BlcyBwZXIgc2Vydmlj ZSkgb3V0d2VpZ2hlZCBhbnkgcGVyZm9ybWFuY2UgaGl0ICh3aGljaCB3YXMgc2hvd24gdG8gYmUg cmF0aGVyIHNtYWxsIGluIHByYWN0aWNlKS48YnI+DQo8YnI+DQpXaGF0IEkgd2FudCBpcyBmb3Ig dGhlIHRva2VuIHN3YXAgZHJhZnQgdG8gZGVmaW5lIG9yIHVzZSBhIG1lY2hhbmlzbSB0aGF0IGFs bG93cyB1cyB0byBkbyB0aGlzLiBJIHRoaW5rIHdlIGNhbiBkbyB0aGF0IHByZXR0eSBlYXNpbHkg YnkgYWRqdXN0aW5nIHRoZSB0b2tlbiBzd2FwIHN5bnRheCBhbmQgbGFuZ3VhZ2UsIGFuZCBleHBs aWNpdGx5IGNhbGxpbmcgb3V0IHRoZSBzZW1hbnRpYyBwcm9jZXNzaW5nIHBvcnRpb24gKHRoZSBj dXJyZW50IGNvcmUNCiBvZiB0aGUgZG9jdW1lbnQpIGZvciB3aGF0IGl0IGlzOiBhIHdheSBmb3Ig YSB0b2tlbiBpc3N1ZXIgdG8gY29tbXVuaWNhdGUgdG8gYSB0b2tlbiBzZXJ2aWNlIHNwZWNpZmlj IGFjdGlvbnMuIEF0IGEgaGlnaCBsZXZlbCwgdGhlIHNwZWMgd291bGQgYmUgc29tZXRoaW5nIGxp a2U6PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KMS4gSG93IHRvIHN3YXAgYSB0b2tlbiBhdCBhbiBB Uzxicj4NCiZuYnNwOyAxLiBTZW5kIGEgcmVxdWVzdCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgd2l0 aCBhIG5ldyBncmFudCB0eXBlLCBhbmQgYSB0b2tlbiAob2YgYW55IHR5cGUvZm9ybWF0L2ZsYXZv cikgb24gdGhlIHdheSBpbjxicj4NCiZuYnNwOyAyLiBHZXQgYmFjayBhIG5ldyB0b2tlbiBpbiBh IHRva2VuIHJlc3BvbnNlPGJyPg0KMi4gQ29tbXVuaWNhdGluZyBhY3QgYXMgLyBvbiBiZWhhbGYg b2Ygc2VtYW50aWNzIHZpYSBhIEpXVCBhc3NlcnRpb248YnI+DQombmJzcDsgMS4gSG93IHRvIGNy ZWF0ZSAoYXMgYW4gQVMvUlMvY2xpZW50L290aGVyIGlzc3VlcikgYSBKV1Qgd2l0aCBhY3QtYXMg c2VtYW50aWNzPGJyPg0KJm5ic3A7IDIuIFdoYXQgdG8gZG8gKGFzIGFuIEFTL1JTKSB3aXRoIGEg SldUIHdpdGggYWN0LWFzIHNlbWFudGljczxicj4NCiZuYnNwOyAzLiBIb3cgdG8gY3JlYXRlIGEg SldUIHdpdGggb24tYmVoYWxmLW9mIHNlbWVhbnRpY3M8YnI+DQombmJzcDsgNC4gV2hhdCB0byBk byB3aXRoIGEgSldUIHdpdGggb24tYmVoYWxmLW9mLXNlbWFudGljczxicj4NCiZuYnNwOyA1LiBI b3cgdG8gcG9zc2libHkgcmVwcmVzZW50IHRoZXNlIHNlbWFudGljcyB3aXRoIHNvbWV0aGluZyBv dGhlciB0aGFuIGEgSldUPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KU2VjdGlvbiAyIHVzZXMgdGhl IHN5bnRheCBmcm9tIHNlY3Rpb24gMS4gT3RoZXIgYXBwbGljYXRpb25zLCBsaWtlIHRoZSBvbmUg SSBsYWlkIG91dCBhYm92ZSwgY2FuIHVzZSB0aGUgc3ludGF4IGZyb20gc2VjdGlvbiAxIGFzIHdl bGwuIFRoaXMgd29ya3MgZm9yIHN0cnVjdHVyZWQsIHVuc3RydWN0dXJlZCwgc2VsZi1nZW5lcmF0 ZWQsIGNyb3NzLWRvbWFpbiwgd2l0aGluLWRvbWFpbiwgYW5kIG90aGVyIHRva2Vucy48YnI+DQo8 c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56 YiI+Jm5ic3A74oCUIEp1c3Rpbjwvc3Bhbj48YnI+DQo8L3NwYW4+PGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BN3PR0301MB1234E538E77276C68164A6E4A6920BN3PR0301MB1234_-- From nobody Tue Jul 7 17:38:42 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245251B2C29 for ; Tue, 7 Jul 2015 17:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.367 X-Spam-Level: X-Spam-Status: No, score=-0.367 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhRN4ScGgykh for ; Tue, 7 Jul 2015 17:38:40 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FE851B2C28 for ; Tue, 7 Jul 2015 17:38:40 -0700 (PDT) Received: by qkeo142 with SMTP id o142so152746917qke.1 for ; Tue, 07 Jul 2015 17:38:39 -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:cc :content-type; bh=0YFIGFEGCzuDQeVS7NEVDyVxr5RJ+XZj+Fl/sWGpJmM=; b=ouyW9kuEEDLXAraDss23cLw7jSOZ7+VPpcR5UceeRuP0jNbqGvEk5ZTD21Jaf+KzsF 7pv5EIQ+3kCus2Wz4vGRMYABIy+1CkzzpNGoMB7HYq0jWPD8lFwTmqtmmRFvGloYVyBz 5jCS6/X6yb8yh/gN39RqL1B/HuEVT5eEMoIkxjn+aV+nEak2/whIFrQ0LtxRyqCBuItY LlD0FSR3BtJeh5394OdLz2Cu11/CL76PEBUQkgn4AZFinNo0ZPmkj6q9cPcIIzJ0KNTG rDswndCSPNM0YzLJCt987rrvInK1a62wSWt12dBagFWyEqMI50qH1H432Qa8nO1fmRHU +edw== 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:cc:content-type; bh=0YFIGFEGCzuDQeVS7NEVDyVxr5RJ+XZj+Fl/sWGpJmM=; b=foAVCFNahU3iEBBwXisnLTimtbYw/QkdcsndCSMrMwk2qXax6iLAJdCYx2/H4sINS+ rQJFrj3uyXVJe6fMvkhtPMLjdJ6SFn0WeDgz3CwFMBWAOtNZtRhQgquANjqqFjjRCqfN +yQkd13JC0HEu1P73LEWGXpNtnuauQlvZ+6yixOFofEJSNlux6H0LxAvYZTNVmK4royx wCD45/q8em/IN6BzmxRs8+ARfTJL+UF+Z6HGx49Kzen6Heuitu4ZOB/Yw3Z3ZcR2Uzh0 zhl4mYfRa/7a3yCiprHzFDAscKuI1+ta1hitq8Vc36Ntg9NveZDhSf0dkMoCtGLZQOI/ YzAg== X-Gm-Message-State: ALoCoQkB809urZdOUNZFe0TLv4Iz1HdeirDD7NFw2ZEeTK0uPaycl95k4hHS9CvOBiIqzWif8n9W X-Received: by 10.140.47.86 with SMTP id l80mr11463680qga.35.1436315919603; Tue, 07 Jul 2015 17:38:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.19.98 with HTTP; Tue, 7 Jul 2015 17:38:20 -0700 (PDT) In-Reply-To: <20150706230550.12450.15077.idtracker@ietfa.amsl.com> References: <20150706230550.12450.15077.idtracker@ietfa.amsl.com> From: William Denniss Date: Tue, 7 Jul 2015 17:38:20 -0700 Message-ID: Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary=001a11c172de2c94e7051a525c95 Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-14.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 00:38:42 -0000 --001a11c172de2c94e7051a525c95 Content-Type: text/plain; charset=UTF-8 In version 14, there's a typo on this line ("deso") in Section 7.2: `"plain" method deso not protect` Also, in the 1.1 Protocol Flow diagram, regarding the text: `+ t(code_verifier), t` I wonder if it makes more sense to represent as `+ t(code_verifier), "t"` (note the quotes on the second 't') given that it's a string representation of the method that's being sent? On Mon, Jul 6, 2015 at 4:05 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Authorization Protocol Working Group > of the IETF. > > Title : Proof Key for Code Exchange by OAuth Public > Clients > Authors : Nat Sakimura > John Bradley > Naveen Agarwal > Filename : draft-ietf-oauth-spop-14.txt > Pages : 20 > Date : 2015-07-06 > > Abstract: > OAuth 2.0 public clients utilizing the Authorization Code Grant are > susceptible to the authorization code interception attack. This > specification describes the attack as well as a technique to mitigate > against the threat through the use of Proof Key for Code Exchange > (PKCE, pronounced "pixy"). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-oauth-spop-14 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-spop-14 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a11c172de2c94e7051a525c95 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In version 14, there's a typo on this line ("deso= ") in Section 7.2:

`"plain" method deso not protect`

Also, in the 1.1 Protocol Flow diagram, regarding the text:
<= div>
`+ t(code_verifier), t`<= br>

I wonder if it make= s more sense to represent as `+ t(code_= verifier), "t"` (note the quotes on the second 't'= ) given that it's a string representation of the method that's bein= g sent?


On Mon, Jul 6, 2015 at 4:05 PM, <= ;internet-dra= fts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Web Authorization Protocol Working G= roup of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Proof Key for Code Exchange by OAuth Public Clients
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Nat = Sakimura
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Bradley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Naveen Agarwal
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-spop-14.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 20
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-07-06

Abstract:
=C2=A0 =C2=A0OAuth 2.0 public clients utilizing the Authorization Code Gran= t are
=C2=A0 =C2=A0susceptible to the authorization code interception attack.=C2= =A0 This
=C2=A0 =C2=A0specification describes the attack as well as a technique to m= itigate
=C2=A0 =C2=A0against the threat through the use of Proof Key for Code Excha= nge
=C2=A0 =C2=A0(PKCE, pronounced "pixy").


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-o= auth-spop/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-spo= p-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-oauth-spop-14


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

--001a11c172de2c94e7051a525c95-- From nobody Tue Jul 7 17:42:05 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330E21B2C2E for ; Tue, 7 Jul 2015 17:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MD1JQj6FB5Ei for ; Tue, 7 Jul 2015 17:41:59 -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 516821B2C1C for ; Tue, 7 Jul 2015 17:41:59 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.213.10; Wed, 8 Jul 2015 00:41:56 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0213.000; Wed, 8 Jul 2015 00:41:56 +0000 From: Mike Jones To: Justin Richer Thread-Topic: [OAUTH-WG] Token Chaining Use Case Thread-Index: AQHQZ/MY5K5Dp0IvikmgQJJzAhL8fZ0vVM6AgKHjaSCAABZagIAABdjQ Date: Wed, 8 Jul 2015 00:41:56 +0000 Message-ID: References: <826785C8-648D-4A1B-AD8D-E99D76117C67@mit.edu> In-Reply-To: <826785C8-648D-4A1B-AD8D-E99D76117C67@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; x-originating-ip: [2001:4898:80e8:ed31::2] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:MRiM4XIww5jD5RZdD2lp0HjNd5GOFIWCPLEhv4rU9VKUtGllVdFonv1dEst2M+9TNq5KOlIZy3sYXUbUBrWpFBJldLhuYvqNmDbb7ErkPaGuLMzYiChEXp13OGPTcPD9Jc1h06U/pZN4GGtTgmh2+A==; 24:VQQuXkgrNbHUhyf+V7eE0yIU5JvQKX8EuL+Lo33XldYqmUIbsFN9g8oFyWB2gmZ/T3/IgZmiM/vdI+L32fqJtQWmlcEo9fISvtuR+CBWuKU=; 20:y7TuNGXqzJGWfCYDPZEqWnQaRIlMm5HR7wuRXL+ehOchyTIcD39g30ejXuw44m/3LHBZxCjCOz7Hb6nEs46o3g== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; by2pr03mb442: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 0631F0BC3D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(377454003)(24454002)(51444003)(54356999)(77096005)(76176999)(50986999)(19300405004)(77156002)(106116001)(92566002)(62966003)(19625215002)(2171001)(19580405001)(87936001)(19617315012)(19580395003)(33656002)(2656002)(2900100001)(2950100001)(16236675004)(76576001)(86362001)(74316001)(110136002)(5001960100002)(19609705001)(40100003)(15975445007)(5002640100001)(46102003)(189998001)(122556002)(99286002)(102836002)(93886004)(5003600100002)(3826002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442AF9C598B811217B1161DF5910BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2015 00:41:56.5283 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Token Chaining Use Case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 00:42:04 -0000 --_000_BY2PR03MB442AF9C598B811217B1161DF5910BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmWxsIHN0YXJ0IGJ5IHNheWluZyB0aGF0IGlmIHlvdSBjb21wYXJlIGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW1wYmVsbC1vYXV0aC1zdHMtMDIgYW5kIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTAyLCB1bnN1 cnByaXNpbmdseSwgeW914oCZbGwgZmluZCBhIGxvdCBpbiBjb21tb24uICBCb3RoIGhhdmUgcmVx dWVzdHMgYW5kIHJlc3BvbnNlcyBmb3JtYXR0ZWQgdXNpbmcgSlNPTiBvYmplY3RzLCBib3RoIGhh dmUgaW5wdXQgYW5kIG91dHB1dCB0b2tlbnMsIGJvdGggaGF2ZSBzZWN1cml0eSB0b2tlbiB0eXBl IHBhcmFtZXRlcnMgZGVzY3JpYmluZyB0aGVpciBjb3JyZXNwb25kaW5nIGlucHV0cyBhbmQgb3V0 cHV0cy4gIEJvdGggY2FuIGNvbnZleSBhY3RfYXMgYW5kIG9uX2JlaGFsZl9vZiB0b2tlbnMuICBB bmQgZGVzcGl0ZSB3aGF0IHdhcyB3cml0dGVuIGJlbG93LCBib3RoIGRlZmluZSBhIG5ldyBncmFu dF90eXBlIHZhbHVlIHRoYXQgaXMgdXNlZCB0byBtYWtlIHRoaXMgbmV3IGtpbmQgb2YgcmVxdWVz dCBhdCB0aGUgVG9rZW4gRW5kcG9pbnQuDQoNClRoZSBwcmltYXJ5IHRoaW5nIHRoYXQgQnJpYW7i gJlzIGRyYWZ0IGlzIG1pc3Npbmcgc2VtYW50aWNhbGx5IGlzIHRoZSBhYmlsaXR5IGZvciB0aGUg cmVxdWVzdGVyIHRvIHNpZ24gdGhlIHNldCBvZiBpbnB1dCBwYXJhbWV0ZXJzLiAgVGhpcyBpcyBj cml0aWNhbCB0byBlc3RhYmxpc2hpbmcgcHJvcGVyIHRydXN0IHRvIGVuYWJsZSB0aGUgZXhjaGFu Z2UgdG8gb2NjdXIgaW4gbWFueSB1c2UgY2FzZXMuICBUaGF04oCZcyB3aHkgdGhlIFdHIGRyYWZ0 IHVzZXMgYSBKV1QgYXMgdGhlIHJlcXVlc3Qg4oCTIHNvIGEgc2lnbmF0dXJlIGNhbiBiZSBhcHBs aWVkIHRvIHRoZSByZXF1ZXN0LCB3aGVuIGFwcHJvcHJpYXRlLiAgKEFuZCB3aGVuIGl04oCZcyBu b3QgbmVlZGVkLCDigJxhbGfigJ06IOKAnG5vbmXigJ0gY2FuIGJlIHVzZWQuKQ0KDQpKdXN0aW4s IHlvdeKAmXJlIHJpZ2h0IHRoYXQgdGhlIGN1cnJlbnQgV0cgZHJhZnQgZG9lc27igJl0IGhhdmUg YSBzZXBhcmF0ZSDigJxpbnB1dCB0b2tlbuKAnSByZXF1ZXN0IHBhcmFtZXRlci4gIEluIHRoZSBj dXJyZW50IGRyYWZ0LCB0aGUgKG9wdGlvbmFsbHkpIHNpZ25lZCByZXF1ZXN0ICppcyogdGhlIGlu cHV0IHRva2VuLiAgVGhpbmtpbmcgc29tZSBtb3JlIGFib3V0IHRoZSB0b2tlbiBjaGFpbmluZyB1 c2UgY2FzZSB5b3XigJlyZSBpbnRlcmVzdGVkIGluLCBJIHNlZSB3aHkgeW91IHdhbnQgdG8gaGF2 ZSB0aGF0IHRva2VuIHRvIGJlIGEgc2VwYXJhdGUgZWxlbWVudCBpbiB0aGUgcmVxdWVzdC4gIEkg YmVsaWV2ZSB0aGUgYmVzdCB3YXkgdG8gYWNjb21wbGlzaCB0aGF0IGlzIHRvIGFkZCBhbiBvcHRp b25hbCBjbGFpbSB0byB0aGUgcmVxdWVzdCB0aGF0IHdvdWxkIGNvbnRhaW4gdGhhdCB0b2tlbi4g IChJIHRoaW5rIHRoZSBjbG9zZXN0IGVxdWl2YWxlbnQgaW4gQnJpYW7igJlzIGRyYWZ0IGlzIHRo ZSBwb3NzaWJpbGl0eSBvZiB1c2luZyBhbiBhY2Nlc3MgdG9rZW4gb3IgYXNzZXJ0aW9uIGFzIHRo ZSBjbGllbnQgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtLCBwb3NzaWJseSBwYXNzaW5nIGl0IGFz IGRlZmluZWQgaW4gUkZDIDY3NTAsIGFsdGhvdWdoIHRoZSBkcmFmdCBkb2VzbuKAmXQgc2F5IHRo YXQuKSAgUGFzc2luZyB0aGUgaW5wdXQgdG9rZW4gYXMgYSBjbGFpbSBsZXRzIGl0IGJlIHBhcnQg b2YgdGhlIHNpZ25lZCByZXF1ZXN0Lg0KDQpJdOKAmXMgY29tcGxldGVseSB1cCB0byB1cyB3aGVu IHVzaW5nIGEgZGlmZmVyZW50IGdyYW50X3R5cGUgdG8gZGVmaW5lIHdoYXQgdGhlIGlucHV0IGFu ZCBvdXRwdXQgcGFyYW1ldGVycyB3aGVuIHVzaW5nIHRoYXQgZ3JhbnRfdHlwZSBhcmUuICAoUkZD IDY3NDkgYWxyZWFkeSBoYXMgZGlmZmVyZW50IHNldHMsIGRlcGVuZGluZyB1cG9uIHRoZSBncmFu dF90eXBlIHVzZWQuKSAgSSBwZXJzb25hbGx5IGZpbmQgaXQgY2xlYW5lciB0byByZXR1cm4gdGhl IG91dHB1dCBzZWN1cml0eSB0b2tlbiB0aGF0IG1heSBub3QgYmUgYW4gYWNjZXNzIHRva2VuIGlu IGEg4oCcc2VjdXJpdHlfdG9rZW7igJ0gcGFyYW1ldGVyIHJhdGhlciB0aGFuIHJlcHVycG9zaW5n IHRoZSDigJxhY2Nlc3NfdG9rZW7igJ0gcGFyYW1ldGVyIHRvIGhvbGQgc29tZXRoaW5nIHRoYXTi gJlzIG5vdCBhbiBhY2Nlc3MgdG9rZW4sIGJ1dCBub3cgd2XigJlyZSBtb3JlIGRpc2N1c3Npbmcg c3ludGF4IHRoYW4gc2VtYW50aWNzLiAgU3RpbGwsIGlmIHNvbWV0aGluZyBpcyBkaWZmZXJlbnQs IGl04oCZcyBwcm9iYWJseSBsZXNzIGVycm9yIHByb25lIHRvIHVzZSBhIGRpZmZlcmVudCBzeW50 YXggZm9yIGl0Lg0KDQpJ4oCZbSBzeW1wYXRoZXRpYyB0byB5b3VyIGNvbW1lbnQgYWJvdXQgTmF0 4oCZcyBzaWduZWQgcmVxdWVzdHMgZHJhZnQsIGV4Y2VwdCB0aGF0IHRoZSByZXF1ZXN0cyB0aGF0 IGRyYWZ0IHNwZWNpZmllcyBhcmUgcmVxdWVzdHMgdG8gdGhlIGludGVyYWN0aXZlIEF1dGhvcml6 YXRpb24gRW5kcG9pbnQsIHdoZXJlYXMgdGhlIHJlcXVlc3RzIHdl4oCZcmUgZGVhbGluZyB3aXRo IGhlcmUgYXJlIHJlcXVlc3RzIHRvIHRoZSBub24taW50ZXJhY3RpdmUgVG9rZW4gRW5kcG9pbnQu ICBTdGlsbCwgdGhpbmtpbmcgb2YgdGhlIFRva2VuIEV4Y2hhbmdlIHJlcXVlc3RzIGFzIHNpZ25l ZCByZXF1ZXN0cyB0byB0aGUgVG9rZW4gRW5kcG9pbnQsIGp1c3QgbGlrZSBOYXTigJlzIGRyYWZ0 IG1ha2VzIHNpZ25lZCByZXF1ZXN0cyB0byB0aGUgQXV0aG9yaXphdGlvbiBFbmRwb2ludCwgaXMg cHJvYmFibHkgYSBnb29kIHVuaWZ5aW5nIG1lbnRhbCBmcmFtZXdvcmsgZm9yIGFsbCBvZiB1cyB0 byBjb25zaWRlciBhcHBseWluZyB0byB0aGlzIHByb2JsZW0gc3BhY2UuDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCZXN0 IHdpc2hlcywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IEp1c3RpbiBSaWNoZXIgW21haWx0bzpq cmljaGVyQG1pdC5lZHVdDQpTZW50OiBUdWVzZGF5LCBKdWx5IDA3LCAyMDE1IDQ6NDcgUE0NClRv OiBNaWtlIEpvbmVzDQpDYzogQnJpYW4gQ2FtcGJlbGw7IDxvYXV0aEBpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbT0FVVEgtV0ddIFRva2VuIENoYWluaW5nIFVzZSBDYXNlDQoNClRoaXMgYXBwcm9h Y2ggaXMgbm90IGEgZ29vZCBmaXQgZm9yIG15IHVzZSBjYXNlcywgYW5kIGl04oCZcyBzdGlsbCBu b3QgIE9BdXRoLXkgYXQgYWxsLiBJdCByZXF1aXJlcyBhIHNwZWNpYWxseS1mb3JtZWQgc2VjdXJp dHkgYXNzZXJ0aW9uIG9uIHRoZSB3YXkgaW4sIHdoaWNoIHRoZSBjbGllbnQgbXVzdCB1bmRlcnN0 YW5kIGFuZCBnZW5lcmF0ZS4gSSBzdGlsbCBjYW7igJl0IHRha2UgYW4gYXJiaXRyYXJ5IHRva2Vu IEnigJl2ZSBiZWVuIGhhbmRlZCBieSBzb21lb25lIGVsc2UgYW5kIHBhc3MgaXQgb2ZmIHRvIGJl IHB1c2hlZCBmb3J3YXJkLiBUaGUgbmV3IOKAnCpfdHlwZeKAnSBwYXJhbWV0ZXJzIHNlZW0gdG8g bWVyZWx5IGtpY2sgdGhlIGNhbiBkb3duIHRoZSByb2FkIGluc3RlYWQgb2YgYWRkcmVzc2luZyB0 aGUgcHJvYmxlbXMgd2l0aCB0aGUgY3VycmVudCBzcGVjaWZpY2F0aW9uLg0KDQpJIHRoaW5rIHRo YXQgQnJpYW7igJlzIGFwcHJvYWNoIHdvcmtzIG11Y2ggYmV0dGVyLiBJdCB1bnJvbGxzIGltcG9y dGFudCBwYXJhbWV0ZXJzLCBwcm9wZXJseSB1c2VzIHRoZSB0b2tlbiBlbmRwb2ludCwgYW5kIGFs bG93cyBmb3IgYXJiaXRyYXJpbHkgZm9ybWF0dGVkIGlucHV0IHRva2Vucy4NCg0KV2hlbiBjb21i aW5lZCB3aXRoIE5hdOKAmXMgZHJhZnQgdGhhdCBzcGVjaWZpZXMgaG93IHRvIHBlcmZvcm0gYWxs IGdlbmVyaWMgT0F1dGggcmVxdWVzdHMgYXMgSldUcyAob3IgZXZlbiBzb21lIG9mIHRoZSB1cGNv bWluZyBQb1Agd29yayBpZiB3ZSBldmVyIGRvIHRoYXQpLCB5b3XigJl2ZSBwcmV0dHkgbXVjaCBn b3QgdGhlIGRyYWZ0IGJlbG93IGJ1dCB3aXRoIG11Y2ggbW9yZSBmbGV4aWJpbGl0eSBhbmQgcG93 ZXIuDQoNCiDigJQgSnVzdGluDQoNCk9uIEp1bCA3LCAyMDE1LCBhdCA2OjUxIFBNLCBNaWtlIEpv bmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWlj cm9zb2Z0LmNvbT4+IHdyb3RlOg0KDQpBcyBqdXN0IHVwZGF0ZWQ8aHR0cDovL3NlbGYtaXNzdWVk LmluZm8vP3A9MTQxMj4sIEkgYmVsaWV2ZSB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIHRva2VuIGV4 Y2hhbmdlIGRyYWZ0IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRo LXRva2VuLWV4Y2hhbmdlLTAyIGNhbiBub3cgYWxzbyBzZXJ2ZSB0aGUg4oCcT0F1dGh54oCdIHRv a2VuIGV4Y2hhbmdlIHVzZSBjYXNlcywgc3VjaCBhcyBKdXN0aW4gYW5kIFBoaWzigJlzIHRva2Vu IGNoYWluaW5nIHVzZSBjYXNlLCBhcyB3ZWxsIGFzIHN1cHBvcnQgZ2VuZXJhbCB0b2tlbiBleGNo YW5nZSwgaW5jbHVkaW5nIGV4Y2hhbmdlIG9mIEpXVCBhbmQgU0FNTCB0b2tlbnMuICBUaGUgbWVj aGFuaXNtIHdvdWxkIGJlIHRoZSBzYW1lIG9uZSB0aGF0IEJyaWFuIHN1Z2dlc3RlZCBiZWxvdyDi gJMgZGVmaW5pbmcgc2VjdXJpdHkgdG9rZW4gdHlwZSB2YWx1ZXMgZm9yIE9BdXRoIDIuMCBhY2Nl c3MgdG9rZW5zIGFuZCByZWZyZXNoIHRva2VucyDigJMgZW5hYmxpbmcgdGhlbSB0byBiZSB1c2Vk IGFzIGlucHV0cyBhbmQgb3V0cHV0cyBpbiBhbnkgb2YgdGhlIHRva2VuIGV4Y2hhbmdlcy4NCg0K Rm9yIGluc3RhbmNlLCBieSB1c2luZyDigJxhY2Nlc3MgdG9rZW7igJ0gYXMgdGhlIGlucHV0IHNl Y3VyaXR5IHRva2VuIHR5cGUsIHByb3ZpZGluZyBuZXcgc2NvcGUgdmFsdWVzLCBhbmQgdXNpbmcg 4oCcYWNjZXNzIHRva2Vu4oCdIGFzIHRoZSBvdXRwdXQgc2VjdXJpdHkgdG9rZW4gdHlwZSwgdG9r ZW4gY2hhaW5pbmcgaXMgYWNoaWV2ZWQuDQoNCk5vdywgYSBxdWVzdGlvbiBmb3IgdGhlIHdvcmtp bmcgZ3JvdXDigKYgIFdoYXQgc2hvdWxkIHRoZSBzZWN1cml0eSB0b2tlbiB0eXBlIHZhbHVlcyBm b3IgYWNjZXNzIHRva2VuIGFuZCByZWZyZXNoIHRva2VuIGJlPyAgVHdvIGRpZmZlcmVudCBjaG9p Y2VzIHNlZW0gdG8gbWFrZSBzZW5zZS4NCigxKSAgVXNlIHRoZSB2YWx1ZXMg4oCcYWNjZXNzX3Rv a2Vu4oCdIGFuZCDigJxyZWZyZXNoX3Rva2Vu4oCdLCB3aGljaCBhcmUgdXNlZCBpbiBSRkMgNjc0 OSB0b2tlbiByZXNwb25zZSB2YWx1ZXMuDQooMikgIERlZmluZSBuZXcgVVJOcyBmb3IgdGhpcyB1 c2FnZSwgc3VjaCBhcyB1cm46aWV0ZjpwYXJhbXM6b2F1dGg6dG9rZW4tdHlwZTphY2Nlc3MtdG9r ZW4gYW5kIHVybjppZXRmOnBhcmFtczpvYXV0aDp0b2tlbi10eXBlOnJlZnJlc2gtdG9rZW4uDQoN CknigJlkIHBlcnNvbmFsbHkgYmUgZmluZSBqdXN0IHVzaW5nIHRoZSBzaG9ydCBuYW1lcyBpbiAo MSkuDQoNCklmIHBlb3BsZSBhZ3JlZSB3aXRoIHRoaXMgYXBwcm9hY2gsIHdlIGNhbiBkb2N1bWVu dCB0aGlzIHVzYWdlIGluIHRoZSAtMDMgZHJhZnQgYW5kIHB1Ymxpc2ggaXQgYXMgc29vbiBhcyB0 aGUgc3VibWlzc2lvbiB0b29sIHJlb3BlbnMgTW9uZGF5IG1vcm5pbmcgZHVyaW5nIElFVEYgOTMu DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJyaWFuIENhbXBiZWxsDQpTZW50OiBUaHVyc2RheSwgTWFy Y2ggMjYsIDIwMTUgMzoxNSBQTQ0KVG86IEp1c3RpbiBSaWNoZXINCkNjOiA8b2F1dGhAaWV0Zi5v cmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFRva2Vu IENoYWluaW5nIFVzZSBDYXNlDQoNClRoaXMga2luZCBvZiB0b2tlbiBleGNoYW5nZSBtaWdodCBp bnZvbHZlIGV4Y2hhbmdlcyBvdGhlciB0aGFuIHN3YXBwaW5nIGFuIEFUIGZvciBhbm90aGVyIEFU IChhbmQgZG93bnNjb3BpbmcgaXQpLiBJdCBtaWdodCBiZSBhbiBBVCBmb3IgYSBzdHJ1Y3R1cmVk IEpXVCBzcGVjaWZpY2FsbHkgdGFyZ2V0ZWQgYXQgb25lIG9mIHRoZSB0aGUgcGFydGljdWxhciBz ZXJ2aWNlcyB0aGF0IHRoZSBvcmlnaW5hbCBSUyBuZWVkcyB0byBjYWxsLiBPciBhbiBBVCBtaWdo dCBiZSBleGNoYW5nZWQgZm9yIGEgU0FNTCBhc3NlcnRpb24gdG8gdXNlIHdpdGggbGVnYWN5IFNP QVAgc2VydmVyaWVzLiAgQSBnb29kIGdlbmVyYWwgdG9rZW4gZXhjaGFuZ2UgbWVjaGFuaXNtIGVu YWJsZXMgbG90cyBvZiB2YXJpYXRpb25zIG9mIGNhc2VzIGxpa2UgdGhlIG9uZSBKdXN0aW4gbWVu dGlvbmVkLiBBbmQgbW9yZS4gSW4gZmFjdCwgSSB0aGluayBkb3duc2NvcGluZyBtaWdodCBiZSBh IG1pbm9yaXR5IHVzZSBjYXNlIHdoZXJlIHdoYXQgdG9rZW4gZXhjaGFuZ2UgaXMgb2Z0ZW4gbmVl ZCBmb3IgaXMgdHJhbnNsYXRpbmcgdG9rZW5zIGZyb20gd2hhdCB5b3UgaGF2ZSBpbnRvIHdoYXQg dGhlIHJlc291cmNlIHlvdSBuZWVkIHRvIGNhbGwgY2FuIGRlYWwgd2l0aC4NClRoZXJlIG5lZWQg dG8gYmUgd2F5cyBmb3IgdGhlIGNhbGxlciB0byB0ZWxsIHRoZSBBUyBhYm91dCB0aGUgdG9rZW4g aXQncyBhc2tpbmcgZm9yIC0gYnkgdHlwZSBvciBieSB0aGUgYWRkcmVzcy9pZGVudGlmaWVyIG9m IHdoZXJlIGl0J2xsIGJlIHVzZWQuIFRoZXJlIG5lZWRzIHRvIGJlIHdheXMgZm9yIHRoZSBjYWxs ZXIgdG8gYXV0aGVudGljYXRlIHRvIHRoZSBBUy4gQW5kIHRoZXJlIG5lZWRzIHRvIGJlIHNvbWUg d2F5IG9mIGV4cHJlc3NpbmcgdGhpcyBkZWxlZ2F0aW9uIHRoaW5nICh0aG91Z2ggSSdtIHN0aWxs IG5vdCB0b3RhbGx5IGNvbnZpbmNlZCBpdCBjb3VsZG4ndCBiZSBqdXN0IHRoZSB0b2tlbiBpcyBh Ym91dCB0aGUgdXNlci9wcmluY2lwYWwgYW5kIHRoZSBjYWxsZXIvY2xpZW50IG9mIHRoZSBleGNo YW5nZSBpcyB3aG8gaXMgYmVpbmcgZGVsZWdhdGVkIHRvKS4NCkkgcmVhbGl6ZSBmZXcgKGFwcHJv YWNoaW5nIHplcm8pIHBlb3BsZSBoYXZlIG9yIGFyZSBnb2luZyB0byByZWFkIGl0IGJ1dCBJIGhh dmUgZW5kZWF2b3JlZCB0byBjb3ZlciBhbGwgdGhlc2UgdGhpbmdzIGluIHRoZSBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW1wYmVsbC1vYXV0aC1zdHMtMDIgZHJhZnQuIEl0J3Mg YW4gZWFybHkgZHJhZnQgc28gbm90IHdpdGhvdXQgaXQgc29tZSByb3VnaCBlZGdlcyBidXQgY2Fu IHByb3ZpZGUgc29tZSBndWlkYW5jZSBvbiB3aGF0IGlzIG5lZWRlZCBhbmQgb2ZmZXJzIHNvbWUg cHJvdG9jb2wgc3ludGF4IGZvciBleHByZXNzaW5nIGl0LiBJIGJlbGlldmUgSnVzdGluJ3MgdXNl IGNhc2Ugd291bGQgYmUgY292ZXJlZCBieSBpdCAoZGVmaW5pbmcgYSBzcGVjaWZpYyB0b2tlbiB0 eXBlIFVSSSBmb3IgYW4gT0F1dGggYWNjZXNzIHRva2VuIGlzc3VlZCBieSB0aGUgQVMgaW4gcXVl c3Rpb24gbWlnaHQgYmUgbmVlZGVkKSBhcyBhcmUgbWFueSBvdGhlcnMuDQoNCk9uIFRodSwgTWFy IDI2LCAyMDE1IGF0IDE6MzEgUE0sIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWls dG86anJpY2hlckBtaXQuZWR1Pj4gd3JvdGU6DQpBcyByZXF1ZXN0ZWQgYWZ0ZXIgbGFzdCBuaWdo dOKAmXMgaW5mb3JtYWwgbWVldGluZywgaGVyZSBpcyB0aGUgdG9rZW4gY2hhaW5pbmcgdXNlIGNh c2UgdGhhdCBJIHdhbnQgdG8gc2VlIHJlcHJlc2VudGVkIGluIHRoZSB0b2tlbiBzd2FwIGRyYWZ0 Lg0KDQoNClsgQ2xpZW50IF0gIC0+ICAgWyBBIF0gLT4gWyBCIF0gLT4gWyBDIF0NCg0KQW4gT0F1 dGggY2xpZW50IGdldHMgYW4gYWNjZXNzIHRva2VuIEFUMSwganVzdCBsaWtlIGl0IGFsd2F5cyB3 b3VsZCwgd2l0aCBzY29wZXMgW0EsIEIsIENdIGluIG9yZGVyIHRvIGNhbGwgc2VydmljZSBBLCB3 aGljaCByZXF1aXJlcyBhbGwgdGhyZWUgc2NvcGVzLiBTZXJ2aWNlIEEgKGFuIFJTKSBhY2NlcHRz IHRoaXMgdG9rZW4gc2luY2UgaXQgaGFzIGl0cyBzY29wZSwgYW5kIHRoZW4gbmVlZHMgdG8gY2Fs bCBzZXJ2aWNlIEIgaW4gdHVybiwgd2hpY2ggcmVxdWlyZXMgc2NvcGVzIFtCLCBDXS4gSXQgY291 bGQganVzdCByZS1zZW5kIHRoZSB0b2tlbiBpdCBnb3QgaW4sIEFUMSwgYnV0IHRoYXQgd291bGQg Z2l2ZSB0aGUgZG93bnN0cmVhbSBSUyB0aGUgYWJpbGl0eSB0byBjYWxsIHNlcnZpY2VzIHdpdGgg c2NvcGUgWyBBIF0gYW5kIGl0IHNob3VsZCBub3QgYmUgYWxsb3dlZCB0byBkbyB0aGF0LiBUbyBs aW1pdCBleHBvc3VyZSwgc2VydmljZSBBIGNhbGxzIGEgdG9rZW4gc3dhcCBhdCB0aGUgQVMgdG8g Y3JlYXRlIEFUMiB3aXRoIHNjb3BlcyBbIEIsIEMgXSwgZWZmZWN0aXZlbHkgYWN0aW5nIGFzIGFu IE9BdXRoIGNsaWVudCByZXF1ZXN0aW5nIGEgZG93bnNjb3BlZCB0b2tlbiBiYXNlZCBvbiBBVDEu IFNlcnZpY2UgQSB0aGVuIGFjdHMgYXMgYW4gT0F1dGggY2xpZW50IHRvIGNhbGwgc2VydmljZSBC LCBub3cgYWN0aW5nIGFzIGFuIFJTIHRvIHNlcnZpY2UgQeKAmXMgY2xpZW50LCBhbmQgY2FuIGZ1 bGZpbGwgdGhlIHJlcXVlc3QuIEFuZCBpdOKAmXMgdHVydGxlcyBhbGwgdGhlIHdheSBkb3duOiBT ZXJ2aWNlIEIgY2FuIGFsc28gY2FsbCBzZXJ2aWNlIEMsIGFuZCBub3cgQiBhY3RzIGFzIGEgY2xp ZW50LCByZXF1ZXN0aW5nIEFUMyB3aXRoIHNjb3BlIFsgQyBdIGJhc2VkIG9uIEFUMiwgYW5kIHNl bmRpbmcgQVQzIHRvIHNlcnZpY2UgQy4gVGhpcyBwcmV2ZW50cyBDIGZyb20gYmVpbmcgYWJsZSB0 byBjYWxsIEIgb3IgQSwgYm90aCBvZiB3aGljaCB3b3VsZCBoYXZlIGJlZW4gYXZhaWxhYmxlIGlm IEFUMSBoYWQgYmVlbiBwYXNzZWQgYXJvdW5kLiBOb3RlIHRoYXQgc2VydmljZSBBIG9yIHRoZSBD bGllbnQgY2FuIGFsc28gcmVxdWVzdCBhIGRvd25zY29wZWQgdG9rZW4gd2l0aCBbIEMgXSB0byBj YWxsIHNlcnZpY2UgQyBkaXJlY3RseSBhcyB3ZWxsLCBhbmQgQyBkb2VzbuKAmXQgaGF2ZSB0byBj YXJlIGhvdyBpdCBnb3QgdGhlcmUuDQoNCg0KSW4gb3RoZXIgd29yZHMsIGl0IGxldHMgdGhlIGNs aWVudCBzb2Z0d2FyZSBiZSB2ZXJ5LCB2ZXJ5IGR1bWIuIEl0IGRvZXNu4oCZdCBoYXZlIHRvIGRv IGFueSBzcGVjaWFsIHByb2Nlc3NpbmcsIGRvZXNu4oCZdCBoYXZlIHRvIGtub3cgd2hhdOKAmXMg aW4gdGhlIHRva2VuLCBpdCBqdXN0IGZvbGxvd3MgdGhlIHJlY2lwZSBvZiDigJxJIGdvdCBhIHRv a2VuLCBJIGdldCBhbm90aGVyIHRva2VuIGJhc2VkIG9uIHRoaXMgdG8gY2FsbCBzb21lb25lIGVs c2XigJ0uIEl04oCZcyBhbHNvIGFuYWxvZ291cyB0byB0aGUgcmVmcmVzaCB0b2tlbiBmbG93LCBi dXQgd2l0aCBhY2Nlc3MgdG9rZW5zIGdvaW5nIGluIGFuZCBvdXQuIEnigJl2ZSBkZXBsb3llZCB0 aGlzIHNldHVwIHNldmVyYWwgdGltZXMgaW4gZGlmZmVyZW50IHNlcnZpY2UgZGVwbG95bWVudHMu IEV2ZW4gdGhvdWdoIHRoZXJlIGlzIGEgcGVyZm9ybWFuY2UgaGl0IGluIHRoZSBhZGRpdGlvbmFs IHJvdW5kIHRyaXBzIChhcyBQaGlsIGJyb3VnaHQgdXAgaW4gYW5vdGhlciB0aHJlYWQpLCBpbiB0 aGVzZSBjYXNlcyB0aGUgZGVzaXJlIHRvIGhhdmUgdGhlIHRva2VucyBob2xkIGxlYXN0IHByaXZp bGVnZSBhY2Nlc3MgcmlnaHRzIChzbWFsbGVzdCBzZXQgb2Ygc2NvcGVzIHBlciBzZXJ2aWNlKSBv dXR3ZWlnaGVkIGFueSBwZXJmb3JtYW5jZSBoaXQgKHdoaWNoIHdhcyBzaG93biB0byBiZSByYXRo ZXIgc21hbGwgaW4gcHJhY3RpY2UpLg0KDQpXaGF0IEkgd2FudCBpcyBmb3IgdGhlIHRva2VuIHN3 YXAgZHJhZnQgdG8gZGVmaW5lIG9yIHVzZSBhIG1lY2hhbmlzbSB0aGF0IGFsbG93cyB1cyB0byBk byB0aGlzLiBJIHRoaW5rIHdlIGNhbiBkbyB0aGF0IHByZXR0eSBlYXNpbHkgYnkgYWRqdXN0aW5n IHRoZSB0b2tlbiBzd2FwIHN5bnRheCBhbmQgbGFuZ3VhZ2UsIGFuZCBleHBsaWNpdGx5IGNhbGxp bmcgb3V0IHRoZSBzZW1hbnRpYyBwcm9jZXNzaW5nIHBvcnRpb24gKHRoZSBjdXJyZW50IGNvcmUg b2YgdGhlIGRvY3VtZW50KSBmb3Igd2hhdCBpdCBpczogYSB3YXkgZm9yIGEgdG9rZW4gaXNzdWVy IHRvIGNvbW11bmljYXRlIHRvIGEgdG9rZW4gc2VydmljZSBzcGVjaWZpYyBhY3Rpb25zLiBBdCBh IGhpZ2ggbGV2ZWwsIHRoZSBzcGVjIHdvdWxkIGJlIHNvbWV0aGluZyBsaWtlOg0KDQoNCg0KMS4g SG93IHRvIHN3YXAgYSB0b2tlbiBhdCBhbiBBUw0KICAxLiBTZW5kIGEgcmVxdWVzdCB0byB0aGUg dG9rZW4gZW5kcG9pbnQgd2l0aCBhIG5ldyBncmFudCB0eXBlLCBhbmQgYSB0b2tlbiAob2YgYW55 IHR5cGUvZm9ybWF0L2ZsYXZvcikgb24gdGhlIHdheSBpbg0KICAyLiBHZXQgYmFjayBhIG5ldyB0 b2tlbiBpbiBhIHRva2VuIHJlc3BvbnNlDQoyLiBDb21tdW5pY2F0aW5nIGFjdCBhcyAvIG9uIGJl aGFsZiBvZiBzZW1hbnRpY3MgdmlhIGEgSldUIGFzc2VydGlvbg0KICAxLiBIb3cgdG8gY3JlYXRl IChhcyBhbiBBUy9SUy9jbGllbnQvb3RoZXIgaXNzdWVyKSBhIEpXVCB3aXRoIGFjdC1hcyBzZW1h bnRpY3MNCiAgMi4gV2hhdCB0byBkbyAoYXMgYW4gQVMvUlMpIHdpdGggYSBKV1Qgd2l0aCBhY3Qt YXMgc2VtYW50aWNzDQogIDMuIEhvdyB0byBjcmVhdGUgYSBKV1Qgd2l0aCBvbi1iZWhhbGYtb2Yg c2VtZWFudGljcw0KICA0LiBXaGF0IHRvIGRvIHdpdGggYSBKV1Qgd2l0aCBvbi1iZWhhbGYtb2Yt c2VtYW50aWNzDQogIDUuIEhvdyB0byBwb3NzaWJseSByZXByZXNlbnQgdGhlc2Ugc2VtYW50aWNz IHdpdGggc29tZXRoaW5nIG90aGVyIHRoYW4gYSBKV1QNCg0KDQoNClNlY3Rpb24gMiB1c2VzIHRo ZSBzeW50YXggZnJvbSBzZWN0aW9uIDEuIE90aGVyIGFwcGxpY2F0aW9ucywgbGlrZSB0aGUgb25l IEkgbGFpZCBvdXQgYWJvdmUsIGNhbiB1c2UgdGhlIHN5bnRheCBmcm9tIHNlY3Rpb24gMSBhcyB3 ZWxsLiBUaGlzIHdvcmtzIGZvciBzdHJ1Y3R1cmVkLCB1bnN0cnVjdHVyZWQsIHNlbGYtZ2VuZXJh dGVkLCBjcm9zcy1kb21haW4sIHdpdGhpbi1kb21haW4sIGFuZCBvdGhlciB0b2tlbnMuDQoNCg0K IOKAlCBKdXN0aW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoN Cg== --_000_BY2PR03MB442AF9C598B811217B1161DF5910BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KdHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6IzAwMzM2Njt9DQpwLk1z b0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxlLW5h bWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bh bi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SeKAmWxsIHN0YXJ0IGJ5IHNheWlu ZyB0aGF0IGlmIHlvdSBjb21wYXJlDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtY2FtcGJlbGwtb2F1dGgtc3RzLTAyIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtY2FtcGJlbGwtb2F1dGgtc3RzLTAyPC9hPiBhbmQNCjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMDIiPmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTAyPC9h Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LA0KIHVu c3VycHJpc2luZ2x5LCB5b3XigJlsbCBmaW5kIGEgbG90IGluIGNvbW1vbi4mbmJzcDsgQm90aCBo YXZlIHJlcXVlc3RzIGFuZCByZXNwb25zZXMgZm9ybWF0dGVkIHVzaW5nIEpTT04gb2JqZWN0cywg Ym90aCBoYXZlIGlucHV0IGFuZCBvdXRwdXQgdG9rZW5zLCBib3RoIGhhdmUgc2VjdXJpdHkgdG9r ZW4gdHlwZSBwYXJhbWV0ZXJzIGRlc2NyaWJpbmcgdGhlaXIgY29ycmVzcG9uZGluZyBpbnB1dHMg YW5kIG91dHB1dHMuJm5ic3A7IEJvdGggY2FuIGNvbnZleSBhY3RfYXMNCiBhbmQgb25fYmVoYWxm X29mIHRva2Vucy4mbmJzcDsgQW5kIGRlc3BpdGUgd2hhdCB3YXMgd3JpdHRlbiBiZWxvdywgYm90 aCBkZWZpbmUgYSBuZXcgZ3JhbnRfdHlwZSB2YWx1ZSB0aGF0IGlzIHVzZWQgdG8gbWFrZSB0aGlz IG5ldyBraW5kIG9mIHJlcXVlc3QgYXQgdGhlIFRva2VuIEVuZHBvaW50LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhl IHByaW1hcnkgdGhpbmcgdGhhdCBCcmlhbuKAmXMgZHJhZnQgaXMgbWlzc2luZyBzZW1hbnRpY2Fs bHkgaXMgdGhlIGFiaWxpdHkgZm9yIHRoZSByZXF1ZXN0ZXIgdG8gc2lnbiB0aGUgc2V0IG9mIGlu cHV0IHBhcmFtZXRlcnMuJm5ic3A7IFRoaXMgaXMgY3JpdGljYWwgdG8gZXN0YWJsaXNoaW5nDQog cHJvcGVyIHRydXN0IHRvIGVuYWJsZSB0aGUgZXhjaGFuZ2UgdG8gb2NjdXIgaW4gbWFueSB1c2Ug Y2FzZXMuJm5ic3A7IFRoYXTigJlzIHdoeSB0aGUgV0cgZHJhZnQgdXNlcyBhIEpXVCBhcyB0aGUg cmVxdWVzdCDigJMgc28gYSBzaWduYXR1cmUgY2FuIGJlIGFwcGxpZWQgdG8gdGhlIHJlcXVlc3Qs IHdoZW4gYXBwcm9wcmlhdGUuJm5ic3A7IChBbmQgd2hlbiBpdOKAmXMgbm90IG5lZWRlZCwg4oCc YWxn4oCdOiDigJxub25l4oCdIGNhbiBiZSB1c2VkLik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkp1c3RpbiwgeW914oCZ cmUgcmlnaHQgdGhhdCB0aGUgY3VycmVudCBXRyBkcmFmdCBkb2VzbuKAmXQgaGF2ZSBhIHNlcGFy YXRlIOKAnGlucHV0IHRva2Vu4oCdIHJlcXVlc3QgcGFyYW1ldGVyLiZuYnNwOyBJbiB0aGUgY3Vy cmVudCBkcmFmdCwgdGhlIChvcHRpb25hbGx5KSBzaWduZWQgcmVxdWVzdA0KICo8Yj5pczwvYj4q IHRoZSBpbnB1dCB0b2tlbi4mbmJzcDsgVGhpbmtpbmcgc29tZSBtb3JlIGFib3V0IHRoZSB0b2tl biBjaGFpbmluZyB1c2UgY2FzZSB5b3XigJlyZSBpbnRlcmVzdGVkIGluLCBJIHNlZSB3aHkgeW91 IHdhbnQgdG8gaGF2ZSB0aGF0IHRva2VuIHRvIGJlIGEgc2VwYXJhdGUgZWxlbWVudCBpbiB0aGUg cmVxdWVzdC4mbmJzcDsgSSBiZWxpZXZlIHRoZSBiZXN0IHdheSB0byBhY2NvbXBsaXNoIHRoYXQg aXMgdG8gYWRkIGFuIG9wdGlvbmFsIGNsYWltIHRvDQogdGhlIHJlcXVlc3QgdGhhdCB3b3VsZCBj b250YWluIHRoYXQgdG9rZW4uJm5ic3A7IChJIHRoaW5rIHRoZSBjbG9zZXN0IGVxdWl2YWxlbnQg aW4gQnJpYW7igJlzIGRyYWZ0IGlzIHRoZSBwb3NzaWJpbGl0eSBvZiB1c2luZyBhbiBhY2Nlc3Mg dG9rZW4gb3IgYXNzZXJ0aW9uIGFzIHRoZSBjbGllbnQgYXV0aGVudGljYXRpb24gbWVjaGFuaXNt LCBwb3NzaWJseSBwYXNzaW5nIGl0IGFzIGRlZmluZWQgaW4gUkZDIDY3NTAsIGFsdGhvdWdoIHRo ZSBkcmFmdCBkb2VzbuKAmXQNCiBzYXkgdGhhdC4pJm5ic3A7IFBhc3NpbmcgdGhlIGlucHV0IHRv a2VuIGFzIGEgY2xhaW0gbGV0cyBpdCBiZSBwYXJ0IG9mIHRoZSBzaWduZWQgcmVxdWVzdC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkl04oCZcyBjb21wbGV0ZWx5IHVwIHRvIHVzIHdoZW4gdXNpbmcgYSBkaWZmZXJlbnQg Z3JhbnRfdHlwZSB0byBkZWZpbmUgd2hhdCB0aGUgaW5wdXQgYW5kIG91dHB1dCBwYXJhbWV0ZXJz IHdoZW4gdXNpbmcgdGhhdCBncmFudF90eXBlIGFyZS4mbmJzcDsgKFJGQyA2NzQ5IGFscmVhZHkN CiBoYXMgZGlmZmVyZW50IHNldHMsIGRlcGVuZGluZyB1cG9uIHRoZSBncmFudF90eXBlIHVzZWQu KSZuYnNwOyBJIHBlcnNvbmFsbHkgZmluZCBpdCBjbGVhbmVyIHRvIHJldHVybiB0aGUgb3V0cHV0 IHNlY3VyaXR5IHRva2VuIHRoYXQgbWF5IG5vdCBiZSBhbiBhY2Nlc3MgdG9rZW4gaW4gYSDigJxz ZWN1cml0eV90b2tlbuKAnSBwYXJhbWV0ZXIgcmF0aGVyIHRoYW4gcmVwdXJwb3NpbmcgdGhlIOKA nGFjY2Vzc190b2tlbuKAnSBwYXJhbWV0ZXIgdG8gaG9sZCBzb21ldGhpbmcNCiB0aGF04oCZcyBu b3QgYW4gYWNjZXNzIHRva2VuLCBidXQgbm93IHdl4oCZcmUgbW9yZSBkaXNjdXNzaW5nIHN5bnRh eCB0aGFuIHNlbWFudGljcy4mbmJzcDsgU3RpbGwsIGlmIHNvbWV0aGluZyBpcyBkaWZmZXJlbnQs IGl04oCZcyBwcm9iYWJseSBsZXNzIGVycm9yIHByb25lIHRvIHVzZSBhIGRpZmZlcmVudCBzeW50 YXggZm9yIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SeKAmW0gc3ltcGF0aGV0aWMgdG8geW91ciBjb21tZW50IGFi b3V0IE5hdOKAmXMgc2lnbmVkIHJlcXVlc3RzIGRyYWZ0LCBleGNlcHQgdGhhdCB0aGUgcmVxdWVz dHMgdGhhdCBkcmFmdCBzcGVjaWZpZXMgYXJlIHJlcXVlc3RzIHRvIHRoZSBpbnRlcmFjdGl2ZSBB dXRob3JpemF0aW9uDQogRW5kcG9pbnQsIHdoZXJlYXMgdGhlIHJlcXVlc3RzIHdl4oCZcmUgZGVh bGluZyB3aXRoIGhlcmUgYXJlIHJlcXVlc3RzIHRvIHRoZSBub24taW50ZXJhY3RpdmUgVG9rZW4g RW5kcG9pbnQuJm5ic3A7IFN0aWxsLCB0aGlua2luZyBvZiB0aGUgVG9rZW4gRXhjaGFuZ2UgcmVx dWVzdHMgYXMgc2lnbmVkIHJlcXVlc3RzIHRvIHRoZSBUb2tlbiBFbmRwb2ludCwganVzdCBsaWtl IE5hdOKAmXMgZHJhZnQgbWFrZXMgc2lnbmVkIHJlcXVlc3RzIHRvIHRoZSBBdXRob3JpemF0aW9u DQogRW5kcG9pbnQsIGlzIHByb2JhYmx5IGEgZ29vZCB1bmlmeWluZyBtZW50YWwgZnJhbWV3b3Jr IGZvciBhbGwgb2YgdXMgdG8gY29uc2lkZXIgYXBwbHlpbmcgdG8gdGhpcyBwcm9ibGVtIHNwYWNl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJlc3Qgd2lz aGVzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEp1c3RpbiBSaWNoZXIg W21haWx0bzpqcmljaGVyQG1pdC5lZHVdDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVs eSAwNywgMjAxNSA0OjQ3IFBNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVzPGJyPg0KPGI+Q2M6 PC9iPiBCcmlhbiBDYW1wYmVsbDsgJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW09BVVRILVdHXSBUb2tlbiBDaGFpbmluZyBVc2UgQ2FzZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgYXBwcm9hY2ggaXMgbm90 IGEgZ29vZCBmaXQgZm9yIG15IHVzZSBjYXNlcywgYW5kIGl04oCZcyBzdGlsbCBub3QgJm5ic3A7 T0F1dGgteSBhdCBhbGwuIEl0IHJlcXVpcmVzIGEgc3BlY2lhbGx5LWZvcm1lZCBzZWN1cml0eSBh c3NlcnRpb24gb24gdGhlIHdheSBpbiwgd2hpY2ggdGhlIGNsaWVudCBtdXN0IHVuZGVyc3RhbmQg YW5kIGdlbmVyYXRlLiBJIHN0aWxsIGNhbuKAmXQgdGFrZSBhbiBhcmJpdHJhcnkgdG9rZW4NCiBJ 4oCZdmUgYmVlbiBoYW5kZWQgYnkgc29tZW9uZSBlbHNlIGFuZCBwYXNzIGl0IG9mZiB0byBiZSBw dXNoZWQgZm9yd2FyZC4gVGhlIG5ldyDigJwqX3R5cGXigJ0gcGFyYW1ldGVycyBzZWVtIHRvIG1l cmVseSBraWNrIHRoZSBjYW4gZG93biB0aGUgcm9hZCBpbnN0ZWFkIG9mIGFkZHJlc3NpbmcgdGhl IHByb2JsZW1zIHdpdGggdGhlIGN1cnJlbnQgc3BlY2lmaWNhdGlvbi48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoYXQgQnJpYW7i gJlzIGFwcHJvYWNoIHdvcmtzIG11Y2ggYmV0dGVyLiBJdCB1bnJvbGxzIGltcG9ydGFudCBwYXJh bWV0ZXJzLCBwcm9wZXJseSB1c2VzIHRoZSB0b2tlbiBlbmRwb2ludCwgYW5kIGFsbG93cyBmb3Ig YXJiaXRyYXJpbHkgZm9ybWF0dGVkIGlucHV0IHRva2Vucy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hlbiBjb21iaW5lZCB3aXRo IE5hdOKAmXMgZHJhZnQgdGhhdCBzcGVjaWZpZXMgaG93IHRvIHBlcmZvcm0gYWxsIGdlbmVyaWMg T0F1dGggcmVxdWVzdHMgYXMgSldUcyAob3IgZXZlbiBzb21lIG9mIHRoZSB1cGNvbWluZyBQb1Ag d29yayBpZiB3ZSBldmVyIGRvIHRoYXQpLCB5b3XigJl2ZSBwcmV0dHkgbXVjaCBnb3QgdGhlIGRy YWZ0IGJlbG93IGJ1dCB3aXRoIG11Y2ggbW9yZSBmbGV4aWJpbGl0eSBhbmQgcG93ZXIuJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwO+KAlCBKdXN0aW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIEp1bCA3LCAyMDE1LCBhdCA2OjUxIFBNLCBNaWtlIEpvbmVzICZsdDs8 YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj5NaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48YSBocmVmPSJodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby8/cD0xNDEyIj5BcyBqdXN0IHVw ZGF0ZWQ8L2E+LCBJIGJlbGlldmUgdGhhdCB0aGUgd29ya2luZyBncm91cCB0b2tlbiBleGNoYW5n ZSBkcmFmdA0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt b2F1dGgtdG9rZW4tZXhjaGFuZ2UtMDIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTAyPC9hPiBjYW4gbm93IGFsc28gc2VydmUgdGhl IOKAnE9BdXRoeeKAnSB0b2tlbiBleGNoYW5nZSB1c2UgY2FzZXMsIHN1Y2ggYXMgSnVzdGluIGFu ZCBQaGls4oCZcyB0b2tlbiBjaGFpbmluZyB1c2UgY2FzZSwgYXMgd2VsbA0KIGFzIHN1cHBvcnQg Z2VuZXJhbCB0b2tlbiBleGNoYW5nZSwgaW5jbHVkaW5nIGV4Y2hhbmdlIG9mIEpXVCBhbmQgU0FN TCB0b2tlbnMuJm5ic3A7IFRoZSBtZWNoYW5pc20gd291bGQgYmUgdGhlIHNhbWUgb25lIHRoYXQg QnJpYW4gc3VnZ2VzdGVkIGJlbG93IOKAkyBkZWZpbmluZyBzZWN1cml0eSB0b2tlbiB0eXBlIHZh bHVlcyBmb3IgT0F1dGggMi4wIGFjY2VzcyB0b2tlbnMgYW5kIHJlZnJlc2ggdG9rZW5zIOKAkyBl bmFibGluZyB0aGVtIHRvIGJlIHVzZWQgYXMNCiBpbnB1dHMgYW5kIG91dHB1dHMgaW4gYW55IG9m IHRoZSB0b2tlbiBleGNoYW5nZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Gb3IgaW5zdGFuY2UsIGJ5IHVzaW5nIOKA nGFjY2VzcyB0b2tlbuKAnSBhcyB0aGUgaW5wdXQgc2VjdXJpdHkgdG9rZW4gdHlwZSwgcHJvdmlk aW5nIG5ldyBzY29wZSB2YWx1ZXMsIGFuZCB1c2luZyDigJxhY2Nlc3MgdG9rZW7igJ0gYXMgdGhl IG91dHB1dCBzZWN1cml0eSB0b2tlbiB0eXBlLA0KIHRva2VuIGNoYWluaW5nIGlzIGFjaGlldmVk Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Tm93LCBhIHF1ZXN0aW9uIGZvciB0aGUgd29ya2luZyBncm91cOKApiZuYnNw OyBXaGF0IHNob3VsZCB0aGUgc2VjdXJpdHkgdG9rZW4gdHlwZSB2YWx1ZXMgZm9yIGFjY2VzcyB0 b2tlbiBhbmQgcmVmcmVzaCB0b2tlbiBiZT8mbmJzcDsgVHdvIGRpZmZlcmVudCBjaG9pY2VzIHNl ZW0gdG8gbWFrZQ0KIHNlbnNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4oMSkmbmJz cDsgVXNlIHRoZSB2YWx1ZXMg4oCcYWNjZXNzX3Rva2Vu4oCdIGFuZCDigJxyZWZyZXNoX3Rva2Vu 4oCdLCB3aGljaCBhcmUgdXNlZCBpbiBSRkMgNjc0OSB0b2tlbiByZXNwb25zZSB2YWx1ZXMuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPigyKSZuYnNwOyBEZWZpbmUgbmV3IFVSTnMgZm9y IHRoaXMgdXNhZ2UsIHN1Y2ggYXMNCjwvc3Bhbj48dHQ+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij51cm46aWV0ZjpwYXJhbXM6b2F1dGg6dG9rZW4tdHlwZTphY2Nlc3Mt dG9rZW48L3NwYW4+PC90dD48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5hbmQNCjwvc3Bhbj48dHQ+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij51cm46aWV0ZjpwYXJhbXM6b2F1dGg6dG9rZW4tdHlwZTpyZWZyZXNoLXRva2VuPC9z cGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPknigJlkIHBlcnNvbmFsbHkgYmUgZmluZSBqdXN0IHVzaW5nIHRoZSBzaG9ydCBuYW1l cyBpbiAoMSkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5JZiBwZW9wbGUgYWdyZWUgd2l0aCB0aGlzIGFwcHJvYWNoLCB3 ZSBjYW4gZG9jdW1lbnQgdGhpcyB1c2FnZSBpbiB0aGUgLTAzIGRyYWZ0IGFuZCBwdWJsaXNoIGl0 IGFzIHNvb24gYXMgdGhlIHN1Ym1pc3Npb24gdG9vbCByZW9wZW5zIE1vbmRheSBtb3JuaW5nIGR1 cmluZw0KIElFVEYgOTMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g T0F1dGggWzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86b2F1 dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJyaWFuIENhbXBi ZWxsPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBNYXJjaCAyNiwgMjAxNSAzOjE1IFBNPGJy Pg0KPGI+VG86PC9iPiBKdXN0aW4gUmljaGVyPGJyPg0KPGI+Q2M6PC9iPiAmbHQ7PGEgaHJlZj0i bWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFRva2VuIENoYWluaW5nIFVzZSBDYXNlPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPlRoaXMga2luZCBvZiB0b2tlbiBleGNoYW5nZSBtaWdodCBpbnZvbHZl IGV4Y2hhbmdlcyBvdGhlciB0aGFuIHN3YXBwaW5nIGFuIEFUIGZvciBhbm90aGVyIEFUIChhbmQg ZG93bnNjb3BpbmcgaXQpLiBJdCBtaWdodCBiZSBhbiBBVCBmb3IgYSBzdHJ1Y3R1cmVkIEpXVCBz cGVjaWZpY2FsbHkgdGFyZ2V0ZWQgYXQgb25lIG9mIHRoZSB0aGUgcGFydGljdWxhciBzZXJ2aWNl cw0KIHRoYXQgdGhlIG9yaWdpbmFsIFJTIG5lZWRzIHRvIGNhbGwuIE9yIGFuIEFUIG1pZ2h0IGJl IGV4Y2hhbmdlZCBmb3IgYSBTQU1MIGFzc2VydGlvbiB0byB1c2Ugd2l0aCBsZWdhY3kgU09BUCBz ZXJ2ZXJpZXMuJm5ic3A7IEEgZ29vZCBnZW5lcmFsIHRva2VuIGV4Y2hhbmdlIG1lY2hhbmlzbSBl bmFibGVzIGxvdHMgb2YgdmFyaWF0aW9ucyBvZiBjYXNlcyBsaWtlIHRoZSBvbmUgSnVzdGluIG1l bnRpb25lZC4gQW5kIG1vcmUuIEluIGZhY3QsIEkgdGhpbmsgZG93bnNjb3BpbmcNCiBtaWdodCBi ZSBhIG1pbm9yaXR5IHVzZSBjYXNlIHdoZXJlIHdoYXQgdG9rZW4gZXhjaGFuZ2UgaXMgb2Z0ZW4g bmVlZCBmb3IgaXMgdHJhbnNsYXRpbmcgdG9rZW5zIGZyb20gd2hhdCB5b3UgaGF2ZSBpbnRvIHdo YXQgdGhlIHJlc291cmNlIHlvdSBuZWVkIHRvIGNhbGwgY2FuIGRlYWwgd2l0aC4NCjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPlRoZXJlIG5lZWQgdG8gYmUgd2F5cyBmb3IgdGhlIGNhbGxlciB0byB0ZWxsIHRo ZSBBUyBhYm91dCB0aGUgdG9rZW4gaXQncyBhc2tpbmcgZm9yIC0gYnkgdHlwZSBvciBieSB0aGUg YWRkcmVzcy9pZGVudGlmaWVyIG9mIHdoZXJlIGl0J2xsIGJlIHVzZWQuIFRoZXJlIG5lZWRzIHRv IGJlIHdheXMgZm9yIHRoZSBjYWxsZXIgdG8gYXV0aGVudGljYXRlIHRvIHRoZQ0KIEFTLiBBbmQg dGhlcmUgbmVlZHMgdG8gYmUgc29tZSB3YXkgb2YgZXhwcmVzc2luZyB0aGlzIGRlbGVnYXRpb24g dGhpbmcgKHRob3VnaCBJJ20gc3RpbGwgbm90IHRvdGFsbHkgY29udmluY2VkIGl0IGNvdWxkbid0 IGJlIGp1c3QgdGhlIHRva2VuIGlzIGFib3V0IHRoZSB1c2VyL3ByaW5jaXBhbCBhbmQgdGhlIGNh bGxlci9jbGllbnQgb2YgdGhlIGV4Y2hhbmdlIGlzIHdobyBpcyBiZWluZyBkZWxlZ2F0ZWQgdG8p Lg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgcmVhbGl6 ZSBmZXcgKGFwcHJvYWNoaW5nIHplcm8pIHBlb3BsZSBoYXZlIG9yIGFyZSBnb2luZyB0byByZWFk IGl0IGJ1dCBJIGhhdmUgZW5kZWF2b3JlZCB0byBjb3ZlciBhbGwgdGhlc2UgdGhpbmdzIGluIHRo ZQ0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2FtcGJlbGwtb2F1 dGgtc3RzLTAyIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1jYW1wYmVsbC1vYXV0aC1zdHMtMDI8L2E+IGRyYWZ0LiBJdCdzIGFuIGVhcmx5IGRyYWZ0 IHNvIG5vdCB3aXRob3V0IGl0IHNvbWUgcm91Z2ggZWRnZXMgYnV0IGNhbiBwcm92aWRlIHNvbWUg Z3VpZGFuY2Ugb24gd2hhdCBpcyBuZWVkZWQgYW5kIG9mZmVycyBzb21lIHByb3RvY29sIHN5bnRh eCBmb3IgZXhwcmVzc2luZyBpdC4gSSBiZWxpZXZlIEp1c3RpbidzIHVzZSBjYXNlIHdvdWxkIGJl DQogY292ZXJlZCBieSBpdCAoZGVmaW5pbmcgYSBzcGVjaWZpYyB0b2tlbiB0eXBlIFVSSSBmb3Ig YW4gT0F1dGggYWNjZXNzIHRva2VuIGlzc3VlZCBieSB0aGUgQVMgaW4gcXVlc3Rpb24gbWlnaHQg YmUgbmVlZGVkKSBhcyBhcmUgbWFueSBvdGhlcnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIE1hciAyNiwgMjAxNSBhdCAxOjMxIFBNLCBKdXN0 aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1IiB0YXJnZXQ9Il9i bGFuayI+anJpY2hlckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkFzIHJlcXVlc3Rl ZCBhZnRlciBsYXN0IG5pZ2h04oCZcyBpbmZvcm1hbCBtZWV0aW5nLCBoZXJlIGlzIHRoZSB0b2tl biBjaGFpbmluZyB1c2UgY2FzZSB0aGF0IEkgd2FudCB0byBzZWUgcmVwcmVzZW50ZWQgaW4gdGhl IHRva2VuIHN3YXAgZHJhZnQuPGJyPg0KPGJyPg0KPGJyPg0KWyBDbGllbnQgXSZuYnNwOyAtJmd0 OyZuYnNwOyAmbmJzcDtbIEEgXSAtJmd0OyBbIEIgXSAtJmd0OyBbIEMgXTxicj4NCjxicj4NCkFu IE9BdXRoIGNsaWVudCBnZXRzIGFuIGFjY2VzcyB0b2tlbiBBVDEsIGp1c3QgbGlrZSBpdCBhbHdh eXMgd291bGQsIHdpdGggc2NvcGVzIFtBLCBCLCBDXSBpbiBvcmRlciB0byBjYWxsIHNlcnZpY2Ug QSwgd2hpY2ggcmVxdWlyZXMgYWxsIHRocmVlIHNjb3Blcy4gU2VydmljZSBBIChhbiBSUykgYWNj ZXB0cyB0aGlzIHRva2VuIHNpbmNlIGl0IGhhcyBpdHMgc2NvcGUsIGFuZCB0aGVuIG5lZWRzIHRv IGNhbGwgc2VydmljZSBCIGluIHR1cm4sIHdoaWNoDQogcmVxdWlyZXMgc2NvcGVzIFtCLCBDXS4g SXQgY291bGQganVzdCByZS1zZW5kIHRoZSB0b2tlbiBpdCBnb3QgaW4sIEFUMSwgYnV0IHRoYXQg d291bGQgZ2l2ZSB0aGUgZG93bnN0cmVhbSBSUyB0aGUgYWJpbGl0eSB0byBjYWxsIHNlcnZpY2Vz IHdpdGggc2NvcGUgWyBBIF0gYW5kIGl0IHNob3VsZCBub3QgYmUgYWxsb3dlZCB0byBkbyB0aGF0 LiBUbyBsaW1pdCBleHBvc3VyZSwgc2VydmljZSBBIGNhbGxzIGEgdG9rZW4gc3dhcCBhdCB0aGUg QVMgdG8NCiBjcmVhdGUgQVQyIHdpdGggc2NvcGVzIFsgQiwgQyBdLCBlZmZlY3RpdmVseSBhY3Rp bmcgYXMgYW4gT0F1dGggY2xpZW50IHJlcXVlc3RpbmcgYSBkb3duc2NvcGVkIHRva2VuIGJhc2Vk IG9uIEFUMS4gU2VydmljZSBBIHRoZW4gYWN0cyBhcyBhbiBPQXV0aCBjbGllbnQgdG8gY2FsbCBz ZXJ2aWNlIEIsIG5vdyBhY3RpbmcgYXMgYW4gUlMgdG8gc2VydmljZSBB4oCZcyBjbGllbnQsIGFu ZCBjYW4gZnVsZmlsbCB0aGUgcmVxdWVzdC4gQW5kIGl04oCZcyB0dXJ0bGVzDQogYWxsIHRoZSB3 YXkgZG93bjogU2VydmljZSBCIGNhbiBhbHNvIGNhbGwgc2VydmljZSBDLCBhbmQgbm93IEIgYWN0 cyBhcyBhIGNsaWVudCwgcmVxdWVzdGluZyBBVDMgd2l0aCBzY29wZSBbIEMgXSBiYXNlZCBvbiBB VDIsIGFuZCBzZW5kaW5nIEFUMyB0byBzZXJ2aWNlIEMuIFRoaXMgcHJldmVudHMgQyBmcm9tIGJl aW5nIGFibGUgdG8gY2FsbCBCIG9yIEEsIGJvdGggb2Ygd2hpY2ggd291bGQgaGF2ZSBiZWVuIGF2 YWlsYWJsZSBpZiBBVDEgaGFkDQogYmVlbiBwYXNzZWQgYXJvdW5kLiBOb3RlIHRoYXQgc2Vydmlj ZSBBIG9yIHRoZSBDbGllbnQgY2FuIGFsc28gcmVxdWVzdCBhIGRvd25zY29wZWQgdG9rZW4gd2l0 aCBbIEMgXSB0byBjYWxsIHNlcnZpY2UgQyBkaXJlY3RseSBhcyB3ZWxsLCBhbmQgQyBkb2VzbuKA mXQgaGF2ZSB0byBjYXJlIGhvdyBpdCBnb3QgdGhlcmUuPGJyPg0KPGJyPg0KPGJyPg0KSW4gb3Ro ZXIgd29yZHMsIGl0IGxldHMgdGhlIGNsaWVudCBzb2Z0d2FyZSBiZSB2ZXJ5LCB2ZXJ5IGR1bWIu IEl0IGRvZXNu4oCZdCBoYXZlIHRvIGRvIGFueSBzcGVjaWFsIHByb2Nlc3NpbmcsIGRvZXNu4oCZ dCBoYXZlIHRvIGtub3cgd2hhdOKAmXMgaW4gdGhlIHRva2VuLCBpdCBqdXN0IGZvbGxvd3MgdGhl IHJlY2lwZSBvZiDigJxJIGdvdCBhIHRva2VuLCBJIGdldCBhbm90aGVyIHRva2VuIGJhc2VkIG9u IHRoaXMgdG8gY2FsbCBzb21lb25lIGVsc2XigJ0uIEl04oCZcw0KIGFsc28gYW5hbG9nb3VzIHRv IHRoZSByZWZyZXNoIHRva2VuIGZsb3csIGJ1dCB3aXRoIGFjY2VzcyB0b2tlbnMgZ29pbmcgaW4g YW5kIG91dC4gSeKAmXZlIGRlcGxveWVkIHRoaXMgc2V0dXAgc2V2ZXJhbCB0aW1lcyBpbiBkaWZm ZXJlbnQgc2VydmljZSBkZXBsb3ltZW50cy4gRXZlbiB0aG91Z2ggdGhlcmUgaXMgYSBwZXJmb3Jt YW5jZSBoaXQgaW4gdGhlIGFkZGl0aW9uYWwgcm91bmQgdHJpcHMgKGFzIFBoaWwgYnJvdWdodCB1 cCBpbiBhbm90aGVyDQogdGhyZWFkKSwgaW4gdGhlc2UgY2FzZXMgdGhlIGRlc2lyZSB0byBoYXZl IHRoZSB0b2tlbnMgaG9sZCBsZWFzdCBwcml2aWxlZ2UgYWNjZXNzIHJpZ2h0cyAoc21hbGxlc3Qg c2V0IG9mIHNjb3BlcyBwZXIgc2VydmljZSkgb3V0d2VpZ2hlZCBhbnkgcGVyZm9ybWFuY2UgaGl0 ICh3aGljaCB3YXMgc2hvd24gdG8gYmUgcmF0aGVyIHNtYWxsIGluIHByYWN0aWNlKS48YnI+DQo8 YnI+DQpXaGF0IEkgd2FudCBpcyBmb3IgdGhlIHRva2VuIHN3YXAgZHJhZnQgdG8gZGVmaW5lIG9y IHVzZSBhIG1lY2hhbmlzbSB0aGF0IGFsbG93cyB1cyB0byBkbyB0aGlzLiBJIHRoaW5rIHdlIGNh biBkbyB0aGF0IHByZXR0eSBlYXNpbHkgYnkgYWRqdXN0aW5nIHRoZSB0b2tlbiBzd2FwIHN5bnRh eCBhbmQgbGFuZ3VhZ2UsIGFuZCBleHBsaWNpdGx5IGNhbGxpbmcgb3V0IHRoZSBzZW1hbnRpYyBw cm9jZXNzaW5nIHBvcnRpb24gKHRoZSBjdXJyZW50IGNvcmUNCiBvZiB0aGUgZG9jdW1lbnQpIGZv ciB3aGF0IGl0IGlzOiBhIHdheSBmb3IgYSB0b2tlbiBpc3N1ZXIgdG8gY29tbXVuaWNhdGUgdG8g YSB0b2tlbiBzZXJ2aWNlIHNwZWNpZmljIGFjdGlvbnMuIEF0IGEgaGlnaCBsZXZlbCwgdGhlIHNw ZWMgd291bGQgYmUgc29tZXRoaW5nIGxpa2U6PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KMS4gSG93 IHRvIHN3YXAgYSB0b2tlbiBhdCBhbiBBUzxicj4NCiZuYnNwOyAxLiBTZW5kIGEgcmVxdWVzdCB0 byB0aGUgdG9rZW4gZW5kcG9pbnQgd2l0aCBhIG5ldyBncmFudCB0eXBlLCBhbmQgYSB0b2tlbiAo b2YgYW55IHR5cGUvZm9ybWF0L2ZsYXZvcikgb24gdGhlIHdheSBpbjxicj4NCiZuYnNwOyAyLiBH ZXQgYmFjayBhIG5ldyB0b2tlbiBpbiBhIHRva2VuIHJlc3BvbnNlPGJyPg0KMi4gQ29tbXVuaWNh dGluZyBhY3QgYXMgLyBvbiBiZWhhbGYgb2Ygc2VtYW50aWNzIHZpYSBhIEpXVCBhc3NlcnRpb248 YnI+DQombmJzcDsgMS4gSG93IHRvIGNyZWF0ZSAoYXMgYW4gQVMvUlMvY2xpZW50L290aGVyIGlz c3VlcikgYSBKV1Qgd2l0aCBhY3QtYXMgc2VtYW50aWNzPGJyPg0KJm5ic3A7IDIuIFdoYXQgdG8g ZG8gKGFzIGFuIEFTL1JTKSB3aXRoIGEgSldUIHdpdGggYWN0LWFzIHNlbWFudGljczxicj4NCiZu YnNwOyAzLiBIb3cgdG8gY3JlYXRlIGEgSldUIHdpdGggb24tYmVoYWxmLW9mIHNlbWVhbnRpY3M8 YnI+DQombmJzcDsgNC4gV2hhdCB0byBkbyB3aXRoIGEgSldUIHdpdGggb24tYmVoYWxmLW9mLXNl bWFudGljczxicj4NCiZuYnNwOyA1LiBIb3cgdG8gcG9zc2libHkgcmVwcmVzZW50IHRoZXNlIHNl bWFudGljcyB3aXRoIHNvbWV0aGluZyBvdGhlciB0aGFuIGEgSldUPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KU2VjdGlvbiAyIHVzZXMgdGhlIHN5bnRheCBmcm9tIHNlY3Rpb24gMS4gT3RoZXIgYXBw bGljYXRpb25zLCBsaWtlIHRoZSBvbmUgSSBsYWlkIG91dCBhYm92ZSwgY2FuIHVzZSB0aGUgc3lu dGF4IGZyb20gc2VjdGlvbiAxIGFzIHdlbGwuIFRoaXMgd29ya3MgZm9yIHN0cnVjdHVyZWQsIHVu c3RydWN0dXJlZCwgc2VsZi1nZW5lcmF0ZWQsIGNyb3NzLWRvbWFpbiwgd2l0aGluLWRvbWFpbiwg YW5kIG90aGVyIHRva2Vucy48YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0K PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+Jm5ic3A74oCUIEp1c3Rpbjwvc3Bhbj48YnI+DQo8 L3NwYW4+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0 Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_BY2PR03MB442AF9C598B811217B1161DF5910BY2PR03MB442namprd_-- From nobody Tue Jul 7 18:29:06 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 734621B2C95 for ; Tue, 7 Jul 2015 18:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXJ47ELpPL-d for ; Tue, 7 Jul 2015 18:29:03 -0700 (PDT) Received: from mail-qk0-f178.google.com (mail-qk0-f178.google.com [209.85.220.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E74461B2C94 for ; Tue, 7 Jul 2015 18:29:02 -0700 (PDT) Received: by qkbp125 with SMTP id p125so153246128qkb.2 for ; Tue, 07 Jul 2015 18:29:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=WJf9flU52PEWabQsSv2kLNUaXKi0FYP90TdZOz/xS/0=; b=M12BqNfx/tWItic0O60UmsFtG7EDpFCLtqMeuBaMPB3V9X7vw9Pv1SGjG/xfE3lvcf njeW9VfkozVUDxYgWXlYW05sgoXqVerfm6b41ihl1bGniUbJiXrXYN4Wyhh7uINB3vbW djfMWrcsw17yAwgnXyFWwD1P8jD3wSHKRotoVxWefFpqzc/B8tIFIDjon+H9faJJdu/i QACvYH1OPXGrlrMQV5rC1WWBVvxhLFDmsMMIOcx8EdQh6gWdFAZFGUdQoRuIwBfwgheQ 1mX5quOokk1xhRri7/r1UHsmxUKeJsvHycmL8Z2bex02cGOfQg6ncLSbTVHFQMceBNto tskA== X-Gm-Message-State: ALoCoQkzn2Norrj5mTAE/qZjz6T5u0hg37kEyJIfw1JnGLkDMbX1uqNnOrSgJ+temz7lxWQMKTKy X-Received: by 10.140.194.199 with SMTP id p190mr12492473qha.76.1436318941774; Tue, 07 Jul 2015 18:29:01 -0700 (PDT) Received: from [192.168.1.216] (181-163-0-38.baf.movistar.cl. [181.163.0.38]) by smtp.gmail.com with ESMTPSA id p52sm424738qge.25.2015.07.07.18.28.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Jul 2015 18:29:01 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_532BE63E-19B3-4868-84E9-FAF42E895238" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: John Bradley In-Reply-To: Date: Tue, 7 Jul 2015 22:28:46 -0300 Message-Id: <68C4B3E0-0A40-4035-A6B8-EB553573BE5D@ve7jtb.com> References: <20150706230550.12450.15077.idtracker@ietfa.amsl.com> To: William Denniss X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-14.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 01:29:05 -0000 --Apple-Mail=_532BE63E-19B3-4868-84E9-FAF42E895238 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks, I fixed my finger dyslexia for the next draft. I changed it to t_m rather than =E2=80=9Ct=E2=80=9D I think that is = clearer. If I were to do it the other way XML2RFC would have double = quotes in the text version. John B.=20 > On Jul 7, 2015, at 9:38 PM, William Denniss = wrote: >=20 > In version 14, there's a typo on this line ("deso") in Section 7.2: >=20 > `"plain" method deso not protect` >=20 > Also, in the 1.1 Protocol Flow diagram, regarding the text: >=20 > `+ t(code_verifier), t` >=20 > I wonder if it makes more sense to represent as `+ t(code_verifier), = "t"` (note the quotes on the second 't') given that it's a string = representation of the method that's being sent? >=20 >=20 > On Mon, Jul 6, 2015 at 4:05 PM, > wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Web Authorization Protocol Working = Group of the IETF. >=20 > Title : Proof Key for Code Exchange by OAuth Public = Clients > Authors : Nat Sakimura > John Bradley > Naveen Agarwal > Filename : draft-ietf-oauth-spop-14.txt > Pages : 20 > Date : 2015-07-06 >=20 > Abstract: > OAuth 2.0 public clients utilizing the Authorization Code Grant are > susceptible to the authorization code interception attack. This > specification describes the attack as well as a technique to = mitigate > against the threat through the use of Proof Key for Code Exchange > (PKCE, pronounced "pixy"). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ = >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-oauth-spop-14 = >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-spop-14 = >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org = . >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ = >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_532BE63E-19B3-4868-84E9-FAF42E895238 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks, I fixed my finger dyslexia for the next draft.

I changed it to t_m = rather than =E2=80=9Ct=E2=80=9D  I think that is clearer.  If = I were to do it the other way XML2RFC would have double quotes in the = text version.

John B. 
On Jul 7, 2015, at 9:38 PM, William Denniss = <wdenniss@google.com> wrote:

In version 14, there's a typo on this line ("deso") in = Section 7.2:

`"plain" method deso not = protect`

Also, in the 1.1 Protocol Flow diagram, = regarding the text:

`+ t(code_verifier), = t`

I wonder if it makes more sense = to represent as `+ = t(code_verifier), "t"` (note the quotes on the second 't') given = that it's a string representation of the method that's being sent?


On = Mon, Jul 6, 2015 at 4:05 PM, <internet-drafts@ietf.org> wrote:

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

        Title          =  : Proof Key for Code Exchange by OAuth Public Clients
=         Authors         : = Nat Sakimura
                    =       John Bradley
                    =       Naveen Agarwal
        Filename        : = draft-ietf-oauth-spop-14.txt
        Pages          =  : 20
        Date          =   : 2015-07-06

Abstract:
   OAuth 2.0 public clients utilizing the Authorization Code = Grant are
   susceptible to the authorization code interception = attack.  This
   specification describes the attack as well as a technique = to mitigate
   against the threat through the use of Proof Key for Code = Exchange
   (PKCE, pronounced "pixy").


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-spop-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-spop-14


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
OAuth mailing 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=_532BE63E-19B3-4868-84E9-FAF42E895238-- From nobody Tue Jul 7 22:52:13 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBBEB1B30E3 for ; Tue, 7 Jul 2015 22:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFogabVPUehh for ; Tue, 7 Jul 2015 22:52:10 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5C601B30E1 for ; Tue, 7 Jul 2015 22:52:09 -0700 (PDT) Received: by qkhu186 with SMTP id u186so156337391qkh.0 for ; Tue, 07 Jul 2015 22:52:09 -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:content-type; bh=DhhNkUHiVTk8Vyr5TZfSP2C1LFfHU7pPXrubvCoWsvs=; b=mBkfntauwpFZcOkC/LWBY5LGlmzUKvWMEUYBvQBj3C2BHgFKZqltMD6CZALqjLCf07 ZGm7fvaJhmZSGiHS7j7KM39+jQ57zbJcRpiq7hdIeOUiHHDw9Q1EXaI8JwHAeuWodUrd GcW+m5ukxeQBpx8A2x+yo+efBdwXRccwWRbWz2SPzaDIpvONe21G2Cn8wt5J8NhmTwSh VU4cn84adFeCU1ugX5LF1+kXoNkKElZQMo8nIwDoD0KQO3KKWOsyWdQCt3Keab1t3O3a fKyImziDtpkdRyXyN8MpOynwlg/YINz+tV8IhcIOqbVdRmQS4Pwtqr5ISg/ZJu8PjFBu 4BZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=DhhNkUHiVTk8Vyr5TZfSP2C1LFfHU7pPXrubvCoWsvs=; b=U9O6IayAm4lnUm9fJWDU3OTsE8bqVPT02EhrRY4yNmRUwq2Po9tZgukESh7SatRM7s ChQwOWBssAnmlzZYBKzDQfyFYsCDLphNSNfQUa3aK9Uqb0l7eWHrguSwvCzhchTzP+Cn rW0N35xwy3OJW0pd3YaaqBjGdyUUuqOpNhJIVFwH6fdtGr57ztPtqIqF3va2UpDLPM4b 9aSaFGAz7XSXy2Xo0Et4DNOc/gVjYW1UtmjIK9aYT3szK9BJ+gD5L0bGb7kx6mUAIwA2 03BKvsq5y/1VQr/nN66jFXsWtO9gWrDJYD5o2w8jnl67IoqtBtqhT/fu5UhuVLMyW6aZ QE0A== X-Gm-Message-State: ALoCoQlGs3xoSeSoNH2GZMASEFw+DbFT1g9HVVFPyoblZnWe04hch7uhBO6Q8EUIY+BFdUBiOnnn X-Received: by 10.140.47.86 with SMTP id l80mr13054427qga.35.1436334729021; Tue, 07 Jul 2015 22:52:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.19.98 with HTTP; Tue, 7 Jul 2015 22:51:49 -0700 (PDT) In-Reply-To: <68C4B3E0-0A40-4035-A6B8-EB553573BE5D@ve7jtb.com> References: <20150706230550.12450.15077.idtracker@ietfa.amsl.com> <68C4B3E0-0A40-4035-A6B8-EB553573BE5D@ve7jtb.com> From: William Denniss Date: Tue, 7 Jul 2015 22:51:49 -0700 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a11c172de4d855d051a56bd53 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-14.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 05:52:11 -0000 --001a11c172de4d855d051a56bd53 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable t_m works for me, I just think we should have some indication that it's the name of the transform. Will you also update where it is referenced in the description below Figure 2? On Tue, Jul 7, 2015 at 6:28 PM, John Bradley wrote: > Thanks, I fixed my finger dyslexia for the next draft. > > I changed it to t_m rather than =E2=80=9Ct=E2=80=9D I think that is clea= rer. If I were > to do it the other way XML2RFC would have double quotes in the text versi= on. > > John B. > > On Jul 7, 2015, at 9:38 PM, William Denniss wrote: > > In version 14, there's a typo on this line ("deso") in Section 7.2: > > `"plain" method deso not protect` > > Also, in the 1.1 Protocol Flow diagram, regarding the text: > > `+ t(code_verifier), t` > > I wonder if it makes more sense to represent as `+ t(code_verifier), "t"` > (note the quotes on the second 't') given that it's a string representati= on > of the method that's being sent? > > > On Mon, Jul 6, 2015 at 4:05 PM, wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Web Authorization Protocol Working >> Group of the IETF. >> >> Title : Proof Key for Code Exchange by OAuth Public >> Clients >> Authors : Nat Sakimura >> John Bradley >> Naveen Agarwal >> Filename : draft-ietf-oauth-spop-14.txt >> Pages : 20 >> Date : 2015-07-06 >> >> Abstract: >> OAuth 2.0 public clients utilizing the Authorization Code Grant are >> susceptible to the authorization code interception attack. This >> specification describes the attack as well as a technique to mitigate >> against the threat through the use of Proof Key for Code Exchange >> (PKCE, pronounced "pixy"). >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-oauth-spop-14 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-spop-14 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --001a11c172de4d855d051a56bd53 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
t_m works for me, I just think we should have some indicat= ion that it's the=C2=A0name=C2=A0of the transform. Will you also update= where it is referenced in the description below Figure 2?



On Tue, Jul 7, 2015 at 6:28 PM, John Bradley <ve7jtb@ve7jtb.com><= /span> wrote:
Thanks, I fixed my finger dyslexia for the next draft.

I changed it to t_m rather than =E2=80=9Ct=E2=80=9D =C2=A0I think t= hat is clearer.=C2=A0 If I were to do it the other way XML2RFC would have d= ouble quotes in the text version.

John B.=C2=A0

On Jul 7, 2015,= at 9:38 PM, William Denniss <wdenniss@google.com> wrote:

In version 14, there's a typo on this line ("deso") in = Section 7.2:

`"= plain" method deso not protect`

Al= so, in the 1.1 Protocol Flow diagram, regarding the text:

`+ t(code_verifier), t`

I wonder if it makes more sense to represent as `+ t(code_verifier), "t"` (n= ote the quotes on the second 't') given that it's a string repr= esentation of the method that's being sent?

On Mon, Jul 6,= 2015 at 4:05 PM, <internet-drafts@ietf.org> wrote:<= br>

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Web Authorization Protocol Working G= roup of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Proof Key for Code Exchange by OAuth Public Clients
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Nat = Sakimura
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Bradley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Naveen Agarwal
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-spop-14.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 20
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-07-06

Abstract:
=C2=A0 =C2=A0OAuth 2.0 public clients utilizing the Authorization Code Gran= t are
=C2=A0 =C2=A0susceptible to the authorization code interception attack.=C2= =A0 This
=C2=A0 =C2=A0specification describes the attack as well as a technique to m= itigate
=C2=A0 =C2=A0against the threat through the use of Proof Key for Code Excha= nge
=C2=A0 =C2=A0(PKCE, pronounced "pixy").


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-o= auth-spop/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-spo= p-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-oauth-spop-14


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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

--001a11c172de4d855d051a56bd53-- From nobody Wed Jul 8 02:26:35 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6DA01B29DA for ; Wed, 8 Jul 2015 02:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQQVX8OK29F7 for ; Wed, 8 Jul 2015 02:26:29 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::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 50B7D1B2C4E for ; Wed, 8 Jul 2015 02:26:29 -0700 (PDT) Received: by wgck11 with SMTP id k11so190321921wgc.0 for ; Wed, 08 Jul 2015 02:26:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=LZbZrsZxAxCEkfpqVCQV4nBkzGoWBW2zMjcUSdQKwdg=; b=sWQLGzyKt284MXHbVv1e0RB5GhIL/iULa32OYD7zYBpOI9I1MFc2TMmId+9MMEviIC n4Kz9j/GtyaRNKDsseT2R5RfexzDfHk065RnC6op+biwBix1pktMMGzOdp6pgovXzydr b/LdzjEaguKc7M02/HHTgrarXpv3TuyDtpOwmenrcF36tbozIpReXVEn3TDQr779uNVe 0C6BXZDnGyGlvl//u0xhoBgWX9O1I4e4i51ALeuWCjzBtqgtGO5ub/j5FYci+7G05puO QQkob/IKR6uKVa6vv2Z0C/HycJsIfdK3vjYJ0fj3z8TR2zW9/RFjLAh104B5PCXn4vRa itdQ== X-Received: by 10.194.89.72 with SMTP id bm8mr17916806wjb.116.1436347588002; Wed, 08 Jul 2015 02:26:28 -0700 (PDT) Received: from [10.36.226.2] ([80.169.137.63]) by smtp.googlemail.com with ESMTPSA id s11sm1869773wib.19.2015.07.08.02.26.26 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jul 2015 02:26:27 -0700 (PDT) Message-ID: <559CECB5.4000006@gmail.com> Date: Wed, 08 Jul 2015 10:26:13 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: oauth@ietf.org References: <826785C8-648D-4A1B-AD8D-E99D76117C67@mit.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OAUTH-WG] Token Chaining Use Case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 09:26:33 -0000 Hi, On 08/07/15 01:41, Mike Jones wrote: > I’ll start by saying that if you compare > https://tools.ietf.org/html/draft-campbell-oauth-sts-02 and > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02, > unsurprisingly, you’ll find a lot in common. Both have requests and > responses formatted using JSON objects, both have input and output > tokens, both have security token type parameters describing their > corresponding inputs and outputs. Both can convey act_as and > on_behalf_of tokens. And despite what was written below, both define a > new grant_type value that is used to make this new kind of request at > the Token Endpoint. > > The primary thing that Brian’s draft is missing semantically is the > ability for the requester to sign the set of input parameters. This is > critical to establishing proper trust to enable the exchange to occur in > many use cases. That’s why the WG draft uses a JWT as the request – so > a signature can be applied to the request, when appropriate. (And when > it’s not needed, “alg”: “none” can be used.) > The requester is a client talking to the token endpoint and this client needs to authenticate, why it needs to sign the token-exchange related parts too ? Thanks, Sergey > Justin, you’re right that the current WG draft doesn’t have a separate > “input token” request parameter. In the current draft, the (optionally) > signed request **is** the input token. Thinking some more about the > token chaining use case you’re interested in, I see why you want to have > that token to be a separate element in the request. I believe the best > way to accomplish that is to add an optional claim to the request that > would contain that token. (I think the closest equivalent in Brian’s > draft is the possibility of using an access token or assertion as the > client authentication mechanism, possibly passing it as defined in RFC > 6750, although the draft doesn’t say that.) Passing the input token as > a claim lets it be part of the signed request. > > It’s completely up to us when using a different grant_type to define > what the input and output parameters when using that grant_type are. > (RFC 6749 already has different sets, depending upon the grant_type > used.) I personally find it cleaner to return the output security token > that may not be an access token in a “security_token” parameter rather > than repurposing the “access_token” parameter to hold something that’s > not an access token, but now we’re more discussing syntax than > semantics. Still, if something is different, it’s probably less error > prone to use a different syntax for it. > > I’m sympathetic to your comment about Nat’s signed requests draft, > except that the requests that draft specifies are requests to the > interactive Authorization Endpoint, whereas the requests we’re dealing > with here are requests to the non-interactive Token Endpoint. Still, > thinking of the Token Exchange requests as signed requests to the Token > Endpoint, just like Nat’s draft makes signed requests to the > Authorization Endpoint, is probably a good unifying mental framework for > all of us to consider applying to this problem space. > > Best > wishes, > > -- Mike > > *From:*Justin Richer [mailto:jricher@mit.edu] > *Sent:* Tuesday, July 07, 2015 4:47 PM > *To:* Mike Jones > *Cc:* Brian Campbell; > *Subject:* Re: [OAUTH-WG] Token Chaining Use Case > > This approach is not a good fit for my use cases, and it’s still not > OAuth-y at all. It requires a specially-formed security assertion on > the way in, which the client must understand and generate. I still can’t > take an arbitrary token I’ve been handed by someone else and pass it off > to be pushed forward. The new “*_type” parameters seem to merely kick > the can down the road instead of addressing the problems with the > current specification. > > I think that Brian’s approach works much better. It unrolls important > parameters, properly uses the token endpoint, and allows for arbitrarily > formatted input tokens. > > When combined with Nat’s draft that specifies how to perform all generic > OAuth requests as JWTs (or even some of the upcoming PoP work if we ever > do that), you’ve pretty much got the draft below but with much more > flexibility and power. > > — Justin > > On Jul 7, 2015, at 6:51 PM, Mike Jones > wrote: > > As just updated , I believe that > the working group token exchange draft > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02 can > now also serve the “OAuthy” token exchange use cases, such as Justin > and Phil’s token chaining use case, as well as support general token > exchange, including exchange of JWT and SAML tokens. The mechanism > would be the same one that Brian suggested below – defining security > token type values for OAuth 2.0 access tokens and refresh tokens – > enabling them to be used as inputs and outputs in any of the token > exchanges. > > For instance, by using “access token” as the input security token > type, providing new scope values, and using “access token” as the > output security token type, token chaining is achieved. > > Now, a question for the working group… What should the security > token type values for access token and refresh token be? Two > different choices seem to make sense. > > (1) Use the values “access_token” and “refresh_token”, which are > used in RFC 6749 token response values. > > (2) Define new URNs for this usage, such as > urn:ietf:params:oauth:token-type:access-tokenand > urn:ietf:params:oauth:token-type:refresh-token. > > I’d personally be fine just using the short names in (1). > > If people agree with this approach, we can document this usage in > the -03 draft and publish it as soon as the submission tool reopens > Monday morning during IETF 93. > > -- Mike > > *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian > Campbell > *Sent:* Thursday, March 26, 2015 3:15 PM > *To:* Justin Richer > *Cc:* > > *Subject:* Re: [OAUTH-WG] Token Chaining Use Case > > This kind of token exchange might involve exchanges other than > swapping an AT for another AT (and downscoping it). It might be an > AT for a structured JWT specifically targeted at one of the the > particular services that the original RS needs to call. Or an AT > might be exchanged for a SAML assertion to use with legacy SOAP > serveries. A good general token exchange mechanism enables lots of > variations of cases like the one Justin mentioned. And more. In > fact, I think downscoping might be a minority use case where what > token exchange is often need for is translating tokens from what you > have into what the resource you need to call can deal with. > > There need to be ways for the caller to tell the AS about the token > it's asking for - by type or by the address/identifier of where > it'll be used. There needs to be ways for the caller to authenticate > to the AS. And there needs to be some way of expressing this > delegation thing (though I'm still not totally convinced it couldn't > be just the token is about the user/principal and the caller/client > of the exchange is who is being delegated to). > > I realize few (approaching zero) people have or are going to read it > but I have endeavored to cover all these things in the > http://tools.ietf.org/html/draft-campbell-oauth-sts-02 draft. It's > an early draft so not without it some rough edges but can provide > some guidance on what is needed and offers some protocol syntax for > expressing it. I believe Justin's use case would be covered by it > (defining a specific token type URI for an OAuth access token issued > by the AS in question might be needed) as are many others. > > On Thu, Mar 26, 2015 at 1:31 PM, Justin Richer > wrote: > > As requested after last night’s informal meeting, here is the token > chaining use case that I want to see represented in the token swap > draft. > > > [ Client ] -> [ A ] -> [ B ] -> [ C ] > > An OAuth client gets an access token AT1, just like it always would, > with scopes [A, B, C] in order to call service A, which requires all > three scopes. Service A (an RS) accepts this token since it has its > scope, and then needs to call service B in turn, which requires > scopes [B, C]. It could just re-send the token it got in, AT1, but > that would give the downstream RS the ability to call services with > scope [ A ] and it should not be allowed to do that. To limit > exposure, service A calls a token swap at the AS to create AT2 with > scopes [ B, C ], effectively acting as an OAuth client requesting a > downscoped token based on AT1. Service A then acts as an OAuth > client to call service B, now acting as an RS to service A’s client, > and can fulfill the request. And it’s turtles all the way down: > Service B can also call service C, and now B acts as a client, > requesting AT3 with scope [ C ] based on AT2, and sending AT3 to > service C. This prevents C from being able to call B or A, both of > which would have been available if AT1 had been passed around. Note > that service A or the Client can also request a downscoped token > with [ C ] to call service C directly as well, and C doesn’t have to > care how it got there. > > > In other words, it lets the client software be very, very dumb. It > doesn’t have to do any special processing, doesn’t have to know > what’s in the token, it just follows the recipe of “I got a token, I > get another token based on this to call someone else”. It’s also > analogous to the refresh token flow, but with access tokens going in > and out. I’ve deployed this setup several times in different service > deployments. Even though there is a performance hit in the > additional round trips (as Phil brought up in another thread), in > these cases the desire to have the tokens hold least privilege > access rights (smallest set of scopes per service) outweighed any > performance hit (which was shown to be rather small in practice). > > What I want is for the token swap draft to define or use a mechanism > that allows us to do this. I think we can do that pretty easily by > adjusting the token swap syntax and language, and explicitly calling > out the semantic processing portion (the current core of the > document) for what it is: a way for a token issuer to communicate to > a token service specific actions. At a high level, the spec would be > something like: > > > > 1. How to swap a token at an AS > 1. Send a request to the token endpoint with a new grant type, > and a token (of any type/format/flavor) on the way in > 2. Get back a new token in a token response > 2. Communicating act as / on behalf of semantics via a JWT assertion > 1. How to create (as an AS/RS/client/other issuer) a JWT with > act-as semantics > 2. What to do (as an AS/RS) with a JWT with act-as semantics > 3. How to create a JWT with on-behalf-of semeantics > 4. What to do with a JWT with on-behalf-of-semantics > 5. How to possibly represent these semantics with something other > than a JWT > > > > Section 2 uses the syntax from section 1. Other applications, like > the one I laid out above, can use the syntax from section 1 as well. > This works for structured, unstructured, self-generated, > cross-domain, within-domain, and other tokens. > > > — Justin > > _______________________________________________ > OAuth mailing 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/ Blog: http://sberyozkin.blogspot.com From nobody Wed Jul 8 04:41:04 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9D71B34B4 for ; Wed, 8 Jul 2015 04:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ajp9XrxZSbrb for ; Wed, 8 Jul 2015 04:40:58 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 480A91B34D0 for ; Wed, 8 Jul 2015 04:40:52 -0700 (PDT) X-AuditID: 1209190c-f79296d000000622-52-559d0c436643 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 45.80.01570.34C0D955; Wed, 8 Jul 2015 07:40:51 -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 t68BeoLm024586; Wed, 8 Jul 2015 07:40:50 -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 t68Bem3l010339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Jul 2015 07:40:49 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Justin Richer In-Reply-To: <559CECB5.4000006@gmail.com> Date: Wed, 8 Jul 2015 07:40:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <77FAD7D3-A1E5-43D9-926B-0DED4B311F74@mit.edu> References: <826785C8-648D-4A1B-AD8D-E99D76117C67@mit.edu> <559CECB5.4000006@gmail.com> To: Sergey Beryozkin X-Mailer: Apple Mail (2.2098) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IRYrdT0XXmmRtqsGyFoMXJt6/YLP4ttXdg 8tg56y67x5IlP5kCmKK4bFJSczLLUov07RK4MlZ+72IteFFScX5HL2sD45/ILkZODgkBE4nt XY8YIWwxiQv31rN1MXJxCAksZpJY/+sfE4SzgVFi5uwmRgjnAZPEzu/XWUFamAX0JHZc/wVm 8wLZj54+ZgexhQX0JZZv7wOLswmoSkxf08IEYnMKaEr8nd8Eto5FQEXi2dYvLF2MHEBz1CXa T7pAjNSWWLbwNTPESCuJo61P2SH2vmSSWPRlOth8EaCii69vsYP0SgjISnzdKjeBUXAWkotm IbloFpKxCxiZVzHKpuRW6eYmZuYUpybrFicn5uWlFuka6uVmluilppRuYgSFL6ckzw7GNweV DjEKcDAq8fB6xMwJFWJNLCuuzD3EKMnBpCTKG/cIKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmE 9zzn3FAh3pTEyqrUonyYlDQHi5I476YffCFCAumJJanZqakFqUUwWRkODiUJXhUuoEbBotT0 1Iq0zJwShDQTByfIcB6g4WbcIMOLCxJzizPTIfKnGHU5WhbfWMskxJKXn5cqJc6rAVIkAFKU UZoHNweWdl4xigO9JcwbAFLFA0xZcJNeAS1hAlqyXHcWyJKSRISUVANjG5+ia5iJ0n6l1XIe TZ2MMt17rireLpiQXhW80yZnRxGHyaP0PM/1f9/9lJn0/+TRa6k/3ytHfz61f3XiaguX8iyL L67L2lsSj5YLzw4S++r94/tGS/We1f1i8d6Vf9KsTr27utzj8VlxFdG7CmcfM3BuWM9gyCZW x6Xd2ffnzuLTU9qsP0UosRRnJBpqMRcVJwIAtp0MSRYDAAA= Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Token Chaining Use Case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 11:41:02 -0000 The HTTP *request* should be able to be covered by a JWT signature, and = that should be applicable to any interaction with the token endpoint. = I=92m aware that Nat=92s draft is talking about the authorization = endpoint, but the same logic could be applied here at the token = endpoint. It could actually even be easier there because we could simply = specify that the Content-Type of the input POST is application/jwt and = the payload of said JWT simply contains all the parameters to the token = endpoint. Orthogonal functionality that meshes well together. Brian=92s draft puts everything as a parameter, including the input = token (which can be arbitrary =97 the requester doesn=92t need to know = what=92s in the tokens at all). This could easily be turned wholesale = into an input JWT using the transform just described. The current draft is a weird halfway state where some input parameters = are in a JWT that=92s passed as an input parameter alongside other = things that are outside the JWT. I don=92t think that works particularly = well, and I think there=92s a better, simpler solution that solves all = of these use cases and then some. =97 Justin > On Jul 8, 2015, at 5:26 AM, Sergey Beryozkin = wrote: >=20 > Hi, > On 08/07/15 01:41, Mike Jones wrote: >> I=92ll start by saying that if you compare >> https://tools.ietf.org/html/draft-campbell-oauth-sts-02 and >> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02, >> unsurprisingly, you=92ll find a lot in common. Both have requests = and >> responses formatted using JSON objects, both have input and output >> tokens, both have security token type parameters describing their >> corresponding inputs and outputs. Both can convey act_as and >> on_behalf_of tokens. And despite what was written below, both define = a >> new grant_type value that is used to make this new kind of request at >> the Token Endpoint. >>=20 >> The primary thing that Brian=92s draft is missing semantically is the >> ability for the requester to sign the set of input parameters. This = is >> critical to establishing proper trust to enable the exchange to occur = in >> many use cases. That=92s why the WG draft uses a JWT as the request = =96 so >> a signature can be applied to the request, when appropriate. (And = when >> it=92s not needed, =93alg=94: =93none=94 can be used.) >>=20 >=20 > The requester is a client talking to the token endpoint and this = client needs to authenticate, why it needs to sign the token-exchange = related parts too ? >=20 > Thanks, Sergey >=20 >> Justin, you=92re right that the current WG draft doesn=92t have a = separate >> =93input token=94 request parameter. In the current draft, the = (optionally) >> signed request **is** the input token. Thinking some more about the >> token chaining use case you=92re interested in, I see why you want to = have >> that token to be a separate element in the request. I believe the = best >> way to accomplish that is to add an optional claim to the request = that >> would contain that token. (I think the closest equivalent in Brian=92s= >> draft is the possibility of using an access token or assertion as the >> client authentication mechanism, possibly passing it as defined in = RFC >> 6750, although the draft doesn=92t say that.) Passing the input = token as >> a claim lets it be part of the signed request. >>=20 >> It=92s completely up to us when using a different grant_type to = define >> what the input and output parameters when using that grant_type are. >> (RFC 6749 already has different sets, depending upon the grant_type >> used.) I personally find it cleaner to return the output security = token >> that may not be an access token in a =93security_token=94 parameter = rather >> than repurposing the =93access_token=94 parameter to hold something = that=92s >> not an access token, but now we=92re more discussing syntax than >> semantics. Still, if something is different, it=92s probably less = error >> prone to use a different syntax for it. >>=20 >> I=92m sympathetic to your comment about Nat=92s signed requests = draft, >> except that the requests that draft specifies are requests to the >> interactive Authorization Endpoint, whereas the requests we=92re = dealing >> with here are requests to the non-interactive Token Endpoint. Still, >> thinking of the Token Exchange requests as signed requests to the = Token >> Endpoint, just like Nat=92s draft makes signed requests to the >> Authorization Endpoint, is probably a good unifying mental framework = for >> all of us to consider applying to this problem space. >>=20 >> Best >> wishes, >>=20 >> -- = Mike >>=20 >> *From:*Justin Richer [mailto:jricher@mit.edu] >> *Sent:* Tuesday, July 07, 2015 4:47 PM >> *To:* Mike Jones >> *Cc:* Brian Campbell; >> *Subject:* Re: [OAUTH-WG] Token Chaining Use Case >>=20 >> This approach is not a good fit for my use cases, and it=92s still = not >> OAuth-y at all. It requires a specially-formed security assertion on >> the way in, which the client must understand and generate. I still = can=92t >> take an arbitrary token I=92ve been handed by someone else and pass = it off >> to be pushed forward. The new =93*_type=94 parameters seem to merely = kick >> the can down the road instead of addressing the problems with the >> current specification. >>=20 >> I think that Brian=92s approach works much better. It unrolls = important >> parameters, properly uses the token endpoint, and allows for = arbitrarily >> formatted input tokens. >>=20 >> When combined with Nat=92s draft that specifies how to perform all = generic >> OAuth requests as JWTs (or even some of the upcoming PoP work if we = ever >> do that), you=92ve pretty much got the draft below but with much more >> flexibility and power. >>=20 >> =97 Justin >>=20 >> On Jul 7, 2015, at 6:51 PM, Mike Jones = > > wrote: >>=20 >> As just updated , I believe = that >> the working group token exchange draft >> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02 can >> now also serve the =93OAuthy=94 token exchange use cases, such as = Justin >> and Phil=92s token chaining use case, as well as support general = token >> exchange, including exchange of JWT and SAML tokens. The = mechanism >> would be the same one that Brian suggested below =96 defining = security >> token type values for OAuth 2.0 access tokens and refresh tokens =96= >> enabling them to be used as inputs and outputs in any of the token >> exchanges. >>=20 >> For instance, by using =93access token=94 as the input security = token >> type, providing new scope values, and using =93access token=94 as = the >> output security token type, token chaining is achieved. >>=20 >> Now, a question for the working group=85 What should the security >> token type values for access token and refresh token be? Two >> different choices seem to make sense. >>=20 >> (1) Use the values =93access_token=94 and =93refresh_token=94, = which are >> used in RFC 6749 token response values. >>=20 >> (2) Define new URNs for this usage, such as >> urn:ietf:params:oauth:token-type:access-tokenand >> urn:ietf:params:oauth:token-type:refresh-token. >>=20 >> I=92d personally be fine just using the short names in (1). >>=20 >> If people agree with this approach, we can document this usage in >> the -03 draft and publish it as soon as the submission tool = reopens >> Monday morning during IETF 93. >>=20 >> = -- Mike >>=20 >> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian >> Campbell >> *Sent:* Thursday, March 26, 2015 3:15 PM >> *To:* Justin Richer >> *Cc:* > >> *Subject:* Re: [OAUTH-WG] Token Chaining Use Case >>=20 >> This kind of token exchange might involve exchanges other than >> swapping an AT for another AT (and downscoping it). It might be an >> AT for a structured JWT specifically targeted at one of the the >> particular services that the original RS needs to call. Or an AT >> might be exchanged for a SAML assertion to use with legacy SOAP >> serveries. A good general token exchange mechanism enables lots = of >> variations of cases like the one Justin mentioned. And more. In >> fact, I think downscoping might be a minority use case where what >> token exchange is often need for is translating tokens from what = you >> have into what the resource you need to call can deal with. >>=20 >> There need to be ways for the caller to tell the AS about the = token >> it's asking for - by type or by the address/identifier of where >> it'll be used. There needs to be ways for the caller to = authenticate >> to the AS. And there needs to be some way of expressing this >> delegation thing (though I'm still not totally convinced it = couldn't >> be just the token is about the user/principal and the = caller/client >> of the exchange is who is being delegated to). >>=20 >> I realize few (approaching zero) people have or are going to read = it >> but I have endeavored to cover all these things in the >> http://tools.ietf.org/html/draft-campbell-oauth-sts-02 draft. It's >> an early draft so not without it some rough edges but can provide >> some guidance on what is needed and offers some protocol syntax = for >> expressing it. I believe Justin's use case would be covered by it >> (defining a specific token type URI for an OAuth access token = issued >> by the AS in question might be needed) as are many others. >>=20 >> On Thu, Mar 26, 2015 at 1:31 PM, Justin Richer > > wrote: >>=20 >> As requested after last night=92s informal meeting, here is the = token >> chaining use case that I want to see represented in the token swap >> draft. >>=20 >>=20 >> [ Client ] -> [ A ] -> [ B ] -> [ C ] >>=20 >> An OAuth client gets an access token AT1, just like it always = would, >> with scopes [A, B, C] in order to call service A, which requires = all >> three scopes. Service A (an RS) accepts this token since it has = its >> scope, and then needs to call service B in turn, which requires >> scopes [B, C]. It could just re-send the token it got in, AT1, but >> that would give the downstream RS the ability to call services = with >> scope [ A ] and it should not be allowed to do that. To limit >> exposure, service A calls a token swap at the AS to create AT2 = with >> scopes [ B, C ], effectively acting as an OAuth client requesting = a >> downscoped token based on AT1. Service A then acts as an OAuth >> client to call service B, now acting as an RS to service A=92s = client, >> and can fulfill the request. And it=92s turtles all the way down: >> Service B can also call service C, and now B acts as a client, >> requesting AT3 with scope [ C ] based on AT2, and sending AT3 to >> service C. This prevents C from being able to call B or A, both of >> which would have been available if AT1 had been passed around. = Note >> that service A or the Client can also request a downscoped token >> with [ C ] to call service C directly as well, and C doesn=92t = have to >> care how it got there. >>=20 >>=20 >> In other words, it lets the client software be very, very dumb. It >> doesn=92t have to do any special processing, doesn=92t have to = know >> what=92s in the token, it just follows the recipe of =93I got a = token, I >> get another token based on this to call someone else=94. It=92s = also >> analogous to the refresh token flow, but with access tokens going = in >> and out. I=92ve deployed this setup several times in different = service >> deployments. Even though there is a performance hit in the >> additional round trips (as Phil brought up in another thread), in >> these cases the desire to have the tokens hold least privilege >> access rights (smallest set of scopes per service) outweighed any >> performance hit (which was shown to be rather small in practice). >>=20 >> What I want is for the token swap draft to define or use a = mechanism >> that allows us to do this. I think we can do that pretty easily by >> adjusting the token swap syntax and language, and explicitly = calling >> out the semantic processing portion (the current core of the >> document) for what it is: a way for a token issuer to communicate = to >> a token service specific actions. At a high level, the spec would = be >> something like: >>=20 >>=20 >>=20 >> 1. How to swap a token at an AS >> 1. Send a request to the token endpoint with a new grant type, >> and a token (of any type/format/flavor) on the way in >> 2. Get back a new token in a token response >> 2. Communicating act as / on behalf of semantics via a JWT = assertion >> 1. How to create (as an AS/RS/client/other issuer) a JWT with >> act-as semantics >> 2. What to do (as an AS/RS) with a JWT with act-as semantics >> 3. How to create a JWT with on-behalf-of semeantics >> 4. What to do with a JWT with on-behalf-of-semantics >> 5. How to possibly represent these semantics with something = other >> than a JWT >>=20 >>=20 >>=20 >> Section 2 uses the syntax from section 1. Other applications, like >> the one I laid out above, can use the syntax from section 1 as = well. >> This works for structured, unstructured, self-generated, >> cross-domain, within-domain, and other tokens. >>=20 >>=20 >> =97 Justin >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 >=20 > --=20 > Sergey Beryozkin >=20 > Talend Community Coders > http://coders.talend.com/ >=20 > Blog: http://sberyozkin.blogspot.com >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Jul 8 12:33:51 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C768F1A1EF7 for ; Wed, 8 Jul 2015 12:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qV_JRMmD3o8h for ; Wed, 8 Jul 2015 12:33:40 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C4471A1EFC for ; Wed, 8 Jul 2015 12:33:40 -0700 (PDT) Received: by iebmu5 with SMTP id mu5so162264391ieb.1 for ; Wed, 08 Jul 2015 12:33: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:content-type; bh=jLLr8H513aIGlpXanFsh2q3Y0+1FGj2138jY9glSTGk=; b=UMXLYJyuLtcxbPqoNwsjQN3YKahCbGG5vm9SfsNURcRf7XHJC0xv0kPGiM7/snt5jn z8uxQirrvhPgrFs/6F0rlkS3UNRUenGqPnjozprR8pIEyBg5w4s15aqTMQyFfjoFQy2f xs46xwuaQ+qXxn2+/4YJ3mcGe6yomGbRjTXfk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=jLLr8H513aIGlpXanFsh2q3Y0+1FGj2138jY9glSTGk=; b=VzzTECA1HjuJQSZ7V9bpCV2wyFjcsGSBjkRvtLVG5KLee0vlS+jkHVa/CH66PT+yXT 0V9w2aKr44o3wJRUQJf+4BWOam4exiBq+OpJpC2drBBxGT2dwLG4TW9xind14Oh11dw0 YBVwqUh1nSEIRsZMm5vK7bqN296n9doKw1R2J5AqB1I3rE6JQ6RP8kRVU/jAmqyd2ioT rp0o4ltA9pjTFS2TpwV5oev2gZcsvLaflKMP9wZQxU9JoOtugPZhh9HNKdlIkXVFhIgV MmpxwL6keNs1a1jubMVmkfnSmUx9b6BfjGeZ9L34mtZawLAsEbmK50iD4LWSdpt7n3QR dWOA== X-Gm-Message-State: ALoCoQn64wdzvZyy3jO1/uUxsxQR28cqPeL2142KzvoNLemuVLRMKed26rmhuWXFoe0x3R2JtWND X-Received: by 10.107.148.135 with SMTP id w129mr5828368iod.52.1436384019149; Wed, 08 Jul 2015 12:33:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.64.209 with HTTP; Wed, 8 Jul 2015 12:33:09 -0700 (PDT) In-Reply-To: References: <826785C8-648D-4A1B-AD8D-E99D76117C67@mit.edu> From: Brian Campbell Date: Wed, 8 Jul 2015 13:33:09 -0600 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=001a113ffdbc39151a051a623773 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Token Chaining Use Case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 19:33:45 -0000 --001a113ffdbc39151a051a623773 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There is a lot in common, yes. Fundamentally we're working to address the same needs, which should lead to some commonality. But I was also trying to be conciliatory in the work I did and make a good faith effort at establishing some commonality from which collaborative work could move forward. In retrospect I should probably have just outright opposed the adoption of draft-jones-oauth-token-exchange as a WG item. I thought trying to work with you would be more effective than working against you. At the time you seemed amenable to that and even proposed co-editing with. Hannes followed that indicating support for adding other co-authors (he didn't say it but kind of implied perhaps Justin and/or Phil based on prior related work). Since that time, however, there's been little willingness to consider changes to the draft (other than very trivial items). And Tony was added as a co-author, which to me (and I suspect many others) signals a complete lack of willingness to actually collaborate towards a solution that's acceptable to more than one contingent. There are differences in the drafts too. I won't list them all here but did want to call out that, contrary to what you said, the request in my draft is made up of regular old HTTP form-urlencoded POST parameters. Which is a simplification and efficiently improvement that seems to be preferred. On Tue, Jul 7, 2015 at 6:41 PM, Mike Jones wrote: > I=E2=80=99ll start by saying that if you compare > https://tools.ietf.org/html/draft-campbell-oauth-sts-02 and > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02, > unsurprisingly, you=E2=80=99ll find a lot in common. Both have requests = and > responses formatted using JSON objects, both have input and output tokens= , > both have security token type parameters describing their corresponding > inputs and outputs. Both can convey act_as and on_behalf_of tokens. And > despite what was written below, both define a new grant_type value that i= s > used to make this new kind of request at the Token Endpoint. > > > > The primary thing that Brian=E2=80=99s draft is missing semantically is t= he > ability for the requester to sign the set of input parameters. This is > critical to establishing proper trust to enable the exchange to occur in > many use cases. That=E2=80=99s why the WG draft uses a JWT as the reques= t =E2=80=93 so a > signature can be applied to the request, when appropriate. (And when it= =E2=80=99s > not needed, =E2=80=9Calg=E2=80=9D: =E2=80=9Cnone=E2=80=9D can be used.) > > > > Justin, you=E2=80=99re right that the current WG draft doesn=E2=80=99t ha= ve a separate > =E2=80=9Cinput token=E2=80=9D request parameter. In the current draft, t= he (optionally) > signed request **is** the input token. Thinking some more about the > token chaining use case you=E2=80=99re interested in, I see why you want = to have > that token to be a separate element in the request. I believe the best w= ay > to accomplish that is to add an optional claim to the request that would > contain that token. (I think the closest equivalent in Brian=E2=80=99s d= raft is > the possibility of using an access token or assertion as the client > authentication mechanism, possibly passing it as defined in RFC 6750, > although the draft doesn=E2=80=99t say that.) Passing the input token as= a claim > lets it be part of the signed request. > > > > It=E2=80=99s completely up to us when using a different grant_type to def= ine what > the input and output parameters when using that grant_type are. (RFC 674= 9 > already has different sets, depending upon the grant_type used.) I > personally find it cleaner to return the output security token that may n= ot > be an access token in a =E2=80=9Csecurity_token=E2=80=9D parameter rather= than repurposing > the =E2=80=9Caccess_token=E2=80=9D parameter to hold something that=E2=80= =99s not an access token, > but now we=E2=80=99re more discussing syntax than semantics. Still, if s= omething > is different, it=E2=80=99s probably less error prone to use a different s= yntax for > it. > > > > I=E2=80=99m sympathetic to your comment about Nat=E2=80=99s signed reques= ts draft, except > that the requests that draft specifies are requests to the interactive > Authorization Endpoint, whereas the requests we=E2=80=99re dealing with h= ere are > requests to the non-interactive Token Endpoint. Still, thinking of the > Token Exchange requests as signed requests to the Token Endpoint, just li= ke > Nat=E2=80=99s draft makes signed requests to the Authorization Endpoint, = is > probably a good unifying mental framework for all of us to consider > applying to this problem space. > > > > Best > wishes, > > -- Mike > > > > *From:* Justin Richer [mailto:jricher@mit.edu] > *Sent:* Tuesday, July 07, 2015 4:47 PM > *To:* Mike Jones > *Cc:* Brian Campbell; > > *Subject:* Re: [OAUTH-WG] Token Chaining Use Case > > > > This approach is not a good fit for my use cases, and it=E2=80=99s still = not > OAuth-y at all. It requires a specially-formed security assertion on the > way in, which the client must understand and generate. I still can=E2=80= =99t take > an arbitrary token I=E2=80=99ve been handed by someone else and pass it o= ff to be > pushed forward. The new =E2=80=9C*_type=E2=80=9D parameters seem to merel= y kick the can > down the road instead of addressing the problems with the current > specification. > > > > I think that Brian=E2=80=99s approach works much better. It unrolls impor= tant > parameters, properly uses the token endpoint, and allows for arbitrarily > formatted input tokens. > > > > When combined with Nat=E2=80=99s draft that specifies how to perform all = generic > OAuth requests as JWTs (or even some of the upcoming PoP work if we ever = do > that), you=E2=80=99ve pretty much got the draft below but with much more > flexibility and power. > > > > =E2=80=94 Justin > > > > On Jul 7, 2015, at 6:51 PM, Mike Jones > wrote: > > > > As just updated , I believe that the > working group token exchange draft > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02 can now > also serve the =E2=80=9COAuthy=E2=80=9D token exchange use cases, such as= Justin and Phil=E2=80=99s > token chaining use case, as well as support general token exchange, > including exchange of JWT and SAML tokens. The mechanism would be the sa= me > one that Brian suggested below =E2=80=93 defining security token type val= ues for > OAuth 2.0 access tokens and refresh tokens =E2=80=93 enabling them to be = used as > inputs and outputs in any of the token exchanges. > > > > For instance, by using =E2=80=9Caccess token=E2=80=9D as the input securi= ty token type, > providing new scope values, and using =E2=80=9Caccess token=E2=80=9D as t= he output security > token type, token chaining is achieved. > > > > Now, a question for the working group=E2=80=A6 What should the security = token > type values for access token and refresh token be? Two different choices > seem to make sense. > > (1) Use the values =E2=80=9Caccess_token=E2=80=9D and =E2=80=9Crefresh_t= oken=E2=80=9D, which are used in > RFC 6749 token response values. > > (2) Define new URNs for this usage, such as > urn:ietf:params:oauth:token-type:access-token and > urn:ietf:params:oauth:token-type:refresh-token. > > > > I=E2=80=99d personally be fine just using the short names in (1). > > > > If people agree with this approach, we can document this usage in the -03 > draft and publish it as soon as the submission tool reopens Monday mornin= g > during IETF 93. > > > > -- Mike > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org ] *O= n > Behalf Of *Brian Campbell > *Sent:* Thursday, March 26, 2015 3:15 PM > *To:* Justin Richer > *Cc:* > *Subject:* Re: [OAUTH-WG] Token Chaining Use Case > > > > This kind of token exchange might involve exchanges other than swapping a= n > AT for another AT (and downscoping it). It might be an AT for a structure= d > JWT specifically targeted at one of the the particular services that the > original RS needs to call. Or an AT might be exchanged for a SAML asserti= on > to use with legacy SOAP serveries. A good general token exchange mechani= sm > enables lots of variations of cases like the one Justin mentioned. And > more. In fact, I think downscoping might be a minority use case where wha= t > token exchange is often need for is translating tokens from what you have > into what the resource you need to call can deal with. > > There need to be ways for the caller to tell the AS about the token it's > asking for - by type or by the address/identifier of where it'll be used. > There needs to be ways for the caller to authenticate to the AS. And ther= e > needs to be some way of expressing this delegation thing (though I'm stil= l > not totally convinced it couldn't be just the token is about the > user/principal and the caller/client of the exchange is who is being > delegated to). > > I realize few (approaching zero) people have or are going to read it but = I > have endeavored to cover all these things in the > http://tools.ietf.org/html/draft-campbell-oauth-sts-02 draft. It's an > early draft so not without it some rough edges but can provide some > guidance on what is needed and offers some protocol syntax for expressing > it. I believe Justin's use case would be covered by it (defining a specif= ic > token type URI for an OAuth access token issued by the AS in question mig= ht > be needed) as are many others. > > > > On Thu, Mar 26, 2015 at 1:31 PM, Justin Richer wrote: > > As requested after last night=E2=80=99s informal meeting, here is the tok= en > chaining use case that I want to see represented in the token swap draft. > > > [ Client ] -> [ A ] -> [ B ] -> [ C ] > > An OAuth client gets an access token AT1, just like it always would, with > scopes [A, B, C] in order to call service A, which requires all three > scopes. Service A (an RS) accepts this token since it has its scope, and > then needs to call service B in turn, which requires scopes [B, C]. It > could just re-send the token it got in, AT1, but that would give the > downstream RS the ability to call services with scope [ A ] and it should > not be allowed to do that. To limit exposure, service A calls a token swa= p > at the AS to create AT2 with scopes [ B, C ], effectively acting as an > OAuth client requesting a downscoped token based on AT1. Service A then > acts as an OAuth client to call service B, now acting as an RS to service > A=E2=80=99s client, and can fulfill the request. And it=E2=80=99s turtles= all the way down: > Service B can also call service C, and now B acts as a client, requesting > AT3 with scope [ C ] based on AT2, and sending AT3 to service C. This > prevents C from being able to call B or A, both of which would have been > available if AT1 had been passed around. Note that service A or the Clien= t > can also request a downscoped token with [ C ] to call service C directly > as well, and C doesn=E2=80=99t have to care how it got there. > > > In other words, it lets the client software be very, very dumb. It doesn= =E2=80=99t > have to do any special processing, doesn=E2=80=99t have to know what=E2= =80=99s in the > token, it just follows the recipe of =E2=80=9CI got a token, I get anothe= r token > based on this to call someone else=E2=80=9D. It=E2=80=99s also analogous = to the refresh > token flow, but with access tokens going in and out. I=E2=80=99ve deploye= d this > setup several times in different service deployments. Even though there i= s > a performance hit in the additional round trips (as Phil brought up in > another thread), in these cases the desire to have the tokens hold least > privilege access rights (smallest set of scopes per service) outweighed a= ny > performance hit (which was shown to be rather small in practice). > > What I want is for the token swap draft to define or use a mechanism that > allows us to do this. I think we can do that pretty easily by adjusting t= he > token swap syntax and language, and explicitly calling out the semantic > processing portion (the current core of the document) for what it is: a w= ay > for a token issuer to communicate to a token service specific actions. At= a > high level, the spec would be something like: > > > > 1. How to swap a token at an AS > 1. Send a request to the token endpoint with a new grant type, and a > token (of any type/format/flavor) on the way in > 2. Get back a new token in a token response > 2. Communicating act as / on behalf of semantics via a JWT assertion > 1. How to create (as an AS/RS/client/other issuer) a JWT with act-as > semantics > 2. What to do (as an AS/RS) with a JWT with act-as semantics > 3. How to create a JWT with on-behalf-of semeantics > 4. What to do with a JWT with on-behalf-of-semantics > 5. How to possibly represent these semantics with something other than = a > JWT > > > > Section 2 uses the syntax from section 1. Other applications, like the on= e > I laid out above, can use the syntax from section 1 as well. This works f= or > structured, unstructured, self-generated, cross-domain, within-domain, an= d > other tokens. > > > =E2=80=94 Justin > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > --001a113ffdbc39151a051a623773 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There is a lot in common, yes. Fundamentally we'r= e working to address the same needs, which should lead to some commonality.= But I was also trying to be conciliatory in the work I did and make a good= faith effort at establishing some commonality from which collaborative wor= k could move forward. In retrospect I should probably have just outright op= posed the adoption of draft-jones-oauth-token-exchange as a WG item. I thou= ght trying to work with you would be more effective than working against yo= u. At the time you seemed amenable to that and even proposed co-editing wit= h. Hannes followed that indicating support for adding other co-authors (he = didn't say it but kind of implied perhaps Justin and/or Phil based on p= rior related work). Since that time, however, there's been little willi= ngness to consider changes to the draft (other than very trivial items). An= d Tony was added as a co-author, which to me (and I suspect many others) si= gnals a complete lack of willingness to actually collaborate towards a solu= tion that's acceptable to more than one contingent.

There= are differences in the drafts too. I won't list them all here but did = want to call out that, contrary to what you said, the request in my draft i= s made up of regular old HTTP form-urlencoded POST parameters. Which is a s= implification and efficiently improvement that seems to be preferred.=C2=A0= =C2=A0

On Tue, Jul 7, 2015 at 6:41 PM, Mike Jones <Michael.Jones@mic= rosoft.com> wrote:

I=E2=80=99ll start by say= ing that if you compare https://tools.ietf.org/html/draft-campbell-oauth-sts-02 and https://tools.ietf.org/= html/draft-ietf-oauth-token-exchange-02=C2=A0

The primary thing that Br= ian=E2=80=99s draft is missing semantically is the ability for the requeste= r to sign the set of input parameters.=C2=A0 This is critical to establishi= ng proper trust to enable the exchange to occur in many use cases.=C2=A0 That= =E2=80=99s why the WG draft uses a JWT as the request =E2=80=93 so a signat= ure can be applied to the request, when appropriate.=C2=A0 (And when it=E2= =80=99s not needed, =E2=80=9Calg=E2=80=9D: =E2=80=9Cnone=E2=80=9D can be us= ed.)

=C2=A0

Justin, you=E2=80=99re ri= ght that the current WG draft doesn=E2=80=99t have a separate =E2=80=9Cinpu= t token=E2=80=9D request parameter.=C2=A0 In the current draft, the (option= ally) signed request *is* the input token.=C2=A0 Thinking some more about the token chai= ning use case you=E2=80=99re interested in, I see why you want to have that= token to be a separate element in the request.=C2=A0 I believe the best wa= y to accomplish that is to add an optional claim to the request that would contain that token.=C2=A0 (I think the closest equi= valent in Brian=E2=80=99s draft is the possibility of using an access token= or assertion as the client authentication mechanism, possibly passing it a= s defined in RFC 6750, although the draft doesn=E2=80=99t say that.)=C2=A0 Passing the input token as a claim lets it be part of the= signed request.

=C2=A0

It=E2=80=99s completely u= p to us when using a different grant_type to define what the input and outp= ut parameters when using that grant_type are.=C2=A0 (RFC 6749 already has different sets, depending upon the grant_type used.)=C2=A0 I personall= y find it cleaner to return the output security token that may not be an ac= cess token in a =E2=80=9Csecurity_token=E2=80=9D parameter rather than repu= rposing the =E2=80=9Caccess_token=E2=80=9D parameter to hold something that=E2=80=99s not an access token, but now we=E2=80=99re more discussing = syntax than semantics.=C2=A0 Still, if something is different, it=E2=80=99s= probably less error prone to use a different syntax for it.<= /span>

=C2=A0

I=E2=80=99m sympathetic t= o your comment about Nat=E2=80=99s signed requests draft, except that the r= equests that draft specifies are requests to the interactive Authorization Endpoint, whereas the requests we=E2=80=99re dealing with here are request= s to the non-interactive Token Endpoint.=C2=A0 Still, thinking of the Token= Exchange requests as signed requests to the Token Endpoint, just like Nat= =E2=80=99s draft makes signed requests to the Authorization Endpoint, is probably a good unifying mental framework for all of us to co= nsider applying to this problem space.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Best wishes,<= u>

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

=C2=A0

From: Justin R= icher [mailto:jricher@= mit.edu]
Sent: Tuesday, July 07, 2015 4:47 PM
To: Mike Jones
Cc: Brian Campbell; <oauth@ietf.org>


Subject: Re: [OAUTH-WG] Token Chaining Use Case
<= /div>

=C2=A0

This approach is not a good fit for my use cases, an= d it=E2=80=99s still not =C2=A0OAuth-y at all. It requires a specially-form= ed security assertion on the way in, which the client must understand and g= enerate. I still can=E2=80=99t take an arbitrary token I=E2=80=99ve been handed by someone else and pass it off to be pushed forw= ard. The new =E2=80=9C*_type=E2=80=9D parameters seem to merely kick the ca= n down the road instead of addressing the problems with the current specifi= cation.

=C2=A0

I think that Brian=E2=80=99s approach works much bet= ter. It unrolls important parameters, properly uses the token endpoint, and= allows for arbitrarily formatted input tokens.=C2=A0

=C2=A0

When combined with Nat=E2=80=99s draft that specifie= s how to perform all generic OAuth requests as JWTs (or even some of the up= coming PoP work if we ever do that), you=E2=80=99ve pretty much got the dra= ft below but with much more flexibility and power.=C2=A0

=C2=A0

=C2=A0=E2=80=94 Justin

=C2=A0

On Jul 7, 2015, at 6:51 PM, Mike Jones <Michael.Jones@mic= rosoft.com> wrote:

=C2=A0

As just updated, I believe that = the working group token exchange draft https://tools.ietf.org/html/draft-ietf-oauth-token-exchan= ge-02 can now also serve the =E2=80=9COAuthy=E2=80=9D token exchange us= e cases, such as Justin and Phil=E2=80=99s token chaining use case, as well as support general token exchange, including exchange of JWT and SAML toke= ns.=C2=A0 The mechanism would be the same one that Brian suggested below = =E2=80=93 defining security token type values for OAuth 2.0 access tokens a= nd refresh tokens =E2=80=93 enabling them to be used as inputs and outputs in any of the token exchanges.

=C2=A0

For instance, by using = =E2=80=9Caccess token=E2=80=9D as the input security token type, providing = new scope values, and using =E2=80=9Caccess token=E2=80=9D as the output se= curity token type, token chaining is achieved.

=C2=A0

Now, a question for the w= orking group=E2=80=A6=C2=A0 What should the security token type values for = access token and refresh token be?=C2=A0 Two different choices seem to make sense.

(1)=C2=A0 Use the values = =E2=80=9Caccess_token=E2=80=9D and =E2=80=9Crefresh_token=E2=80=9D, which a= re used in RFC 6749 token response values.

(2)=C2=A0 Define new URNs= for this usage, such as urn:ietf:params:oau= th:token-type:access-token and urn:ietf:params:oau= th:token-type:refresh-token.<= u>

=C2=A0

I=E2=80=99d personally be= fine just using the short names in (1).

=C2=A0

If people agree with this= approach, we can document this usage in the -03 draft and publish it as so= on as the submission tool reopens Monday morning during IETF 93.

=C2=A0

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

=C2=A0

From: OAuth [<= a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_blank">mailto:oauth-bou= nces@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, March 26, 2015 3:15 PM
To: Justin Richer
Cc: <oauth@ie= tf.org>
Subject: Re: [OAUTH-WG] Token Chaining Use Case=

=C2=A0

This kind of token ex= change might involve exchanges other than swapping an AT for another AT (an= d downscoping it). It might be an AT for a structured JWT specifically targ= eted at one of the the particular services that the original RS needs to call. Or an AT might be exchanged for a SAML= assertion to use with legacy SOAP serveries.=C2=A0 A good general token ex= change mechanism enables lots of variations of cases like the one Justin me= ntioned. And more. In fact, I think downscoping might be a minority use case where what token exchange is often need for i= s translating tokens from what you have into what the resource you need to = call can deal with.

There need to be ways= for the caller to tell the AS about the token it's asking for - by typ= e or by the address/identifier of where it'll be used. There needs to b= e ways for the caller to authenticate to the AS. And there needs to be some way of expressing this delegation thing (th= ough I'm still not totally convinced it couldn't be just the token = is about the user/principal and the caller/client of the exchange is who is= being delegated to).

I realize few (approaching zero) people have or are = going to read it but I have endeavored to cover all these things in the http://tools.ietf.org/html/draft-campbell-oauth-sts-02 draft. It's = an early draft so not without it some rough edges but can provide some guid= ance on what is needed and offers some protocol syntax for expressing it. I= believe Justin's use case would be covered by it (defining a specific token type URI for an OAuth access toke= n issued by the AS in question might be needed) as are many others.<= u>

=C2=A0

On Thu, Mar 26, 2015 at 1:31 PM, Justin Richer <<= a href=3D"mailto:jricher@mit.edu" target=3D"_blank">jricher@mit.edu>= wrote:

As requested after la= st night=E2=80=99s informal meeting, here is the token chaining use case th= at I want to see represented in the token swap draft.


[ Client ]=C2=A0 ->=C2=A0 =C2=A0[ A ] -> [ B ] -> [ C ]

An OAuth client gets an access token AT1, just like it always would, with s= copes [A, B, C] in order to call service A, which requires all three scopes= . Service A (an RS) accepts this token since it has its scope, and then nee= ds to call service B in turn, which requires scopes [B, C]. It could just re-send the token it got in, AT1, bu= t that would give the downstream RS the ability to call services with scope= [ A ] and it should not be allowed to do that. To limit exposure, service = A calls a token swap at the AS to create AT2 with scopes [ B, C ], effectively acting as an OAuth client req= uesting a downscoped token based on AT1. Service A then acts as an OAuth cl= ient to call service B, now acting as an RS to service A=E2=80=99s client, = and can fulfill the request. And it=E2=80=99s turtles all the way down: Service B can also call service C, and now B acts as a c= lient, requesting AT3 with scope [ C ] based on AT2, and sending AT3 to ser= vice C. This prevents C from being able to call B or A, both of which would= have been available if AT1 had been passed around. Note that service A or the Client can also request a d= ownscoped token with [ C ] to call service C directly as well, and C doesn= =E2=80=99t have to care how it got there.


In other words, it lets the client software be very, very dumb. It doesn=E2= =80=99t have to do any special processing, doesn=E2=80=99t have to know wha= t=E2=80=99s in the token, it just follows the recipe of =E2=80=9CI got a to= ken, I get another token based on this to call someone else=E2=80=9D. It=E2= =80=99s also analogous to the refresh token flow, but with access tokens going in = and out. I=E2=80=99ve deployed this setup several times in different servic= e deployments. Even though there is a performance hit in the additional rou= nd trips (as Phil brought up in another thread), in these cases the desire to have the tokens hold least privilege= access rights (smallest set of scopes per service) outweighed any performa= nce hit (which was shown to be rather small in practice).

What I want is for the token swap draft to define or use a mechanism that a= llows us to do this. I think we can do that pretty easily by adjusting the = token swap syntax and language, and explicitly calling out the semantic pro= cessing portion (the current core of the document) for what it is: a way for a token issuer to communicate t= o a token service specific actions. At a high level, the spec would be some= thing like:



1. How to swap a token at an AS
=C2=A0 1. Send a request to the token endpoint with a new grant type, and a= token (of any type/format/flavor) on the way in
=C2=A0 2. Get back a new token in a token response
2. Communicating act as / on behalf of semantics via a JWT assertion
=C2=A0 1. How to create (as an AS/RS/client/other issuer) a JWT with act-as= semantics
=C2=A0 2. What to do (as an AS/RS) with a JWT with act-as semantics
=C2=A0 3. How to create a JWT with on-behalf-of semeantics
=C2=A0 4. What to do with a JWT with on-behalf-of-semantics
=C2=A0 5. How to possibly represent these semantics with something other th= an a JWT



Section 2 uses the syntax from section 1. Other applications, like the one = I laid out above, can use the syntax from section 1 as well. This works for= structured, unstructured, self-generated, cross-domain, within-domain, and= other tokens.


=C2=A0=E2=80=94 Justin

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

=C2=A0

=C2=A0


--001a113ffdbc39151a051a623773-- From nobody Wed Jul 8 12:34:47 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4C21A1BF4 for ; Wed, 8 Jul 2015 12:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyhFNEBFthFT for ; Wed, 8 Jul 2015 12:34:44 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62A371A1BCF for ; Wed, 8 Jul 2015 12:34:44 -0700 (PDT) Received: by igcqs7 with SMTP id qs7so64085488igc.0 for ; Wed, 08 Jul 2015 12:34:44 -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:content-type; bh=rux0Sw+D+NuhD27hSxzaKD7aZ3Cj2nVsLdAAkvLUmZs=; b=RCPjndb4nMnkZRbGEx6rwvjQ2K+xwMVr2RCzcRIx+TJmbOPMG8zX5hJqHP7uqIQDj9 78zMEeW5EUAOBsCg/o47WRHa3PbV1X8v2km37sSXrwtR2WNxRtvAvSp9xLHs29vRy3GA tuw7ye4cTGy26YE8LYj5MN1NRI0weP779YZrg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=rux0Sw+D+NuhD27hSxzaKD7aZ3Cj2nVsLdAAkvLUmZs=; b=avMi4vJ8T8h+E1dBx5bXO4F11KWZuT1G/uYez/mT5kc4Kgw1wShUYDuMHEI4qR9RDy d221+p5AahHeSjMPZZdXog3sdcvpkd69DhFPWrVOlTrl59Tty98QglNgMke5MiWgkVT2 JDRzu1ASuauJTxFa264CDH4OQ1Rg5OoxIlHLrbxdiCKcZufWLgsmQt9Rbh7jIewy41M+ ktUIPbsCriEir0QpoeHvMyVeqyD6wJi12eLB9ZkLGY8eYSnvzewtfzMSTlU7NSxSShRj 96Afh/SgIQPkay1BIZPU33M+wTc9xDP3V5HY3rl2+H9bA+SD1NPD6rqADVJBJwPocVju rOzQ== X-Gm-Message-State: ALoCoQnVAU928FBk7gaP27VLdZcyZPt5sbIxD21LcYC9AMo5x0WuwKM3g4zG/bc1Jnt3lwVrC6q6 X-Received: by 10.50.59.211 with SMTP id b19mr88496854igr.42.1436384083904; Wed, 08 Jul 2015 12:34:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.64.209 with HTTP; Wed, 8 Jul 2015 12:34:14 -0700 (PDT) In-Reply-To: <559CECB5.4000006@gmail.com> References: <826785C8-648D-4A1B-AD8D-E99D76117C67@mit.edu> <559CECB5.4000006@gmail.com> From: Brian Campbell Date: Wed, 8 Jul 2015 13:34:14 -0600 Message-ID: To: Sergey Beryozkin Content-Type: multipart/alternative; boundary=047d7bd75758155398051a623b86 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] Token Chaining Use Case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 19:34:46 -0000 --047d7bd75758155398051a623b86 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agree Sergey. That line of thinking is largely why https://tools.ietf.org/html/draft-campbell-oauth-sts utilizes normal OAuth client authentication. On Wed, Jul 8, 2015 at 3:26 AM, Sergey Beryozkin wrote: > > On 08/07/15 01:41, Mike Jones wrote: > >> [...] That=E2=80=99s why the WG draft uses a JWT as the request =E2=80= =93 so >> a signature can be applied to the request, when appropriate. (And when >> it=E2=80=99s not needed, =E2=80=9Calg=E2=80=9D: =E2=80=9Cnone=E2=80=9D c= an be used.) >> >> > The requester is a client talking to the token endpoint and this client > needs to authenticate, why it needs to sign the token-exchange related > parts too ? > > Thanks, Sergey > --047d7bd75758155398051a623b86 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agree Sergey. That line of thinking is largely why=20 https://tools.ietf.org/html/draft-campbell-oauth-sts utilizes n= ormal=20 OAuth client authentication.

On Wed, Jul 8, 2015 at 3:26 AM, Sergey Beryozkin <sberyozkin= @gmail.com> wrote:

On 08/07/15 01:41, Mike Jones wrote:
=C2=A0[...] That=E2=80=99s why the WG draft uses a JWT as the request =E2=80=93 so
a signature can be applied to the request, when appropriate.=C2=A0 (And whe= n
it=E2=80=99s not needed, =E2=80=9Calg=E2=80=9D: =E2=80=9Cnone=E2=80=9D can = be used.)


 The requester is a client talking to the token endpoint and this client nee= ds to authenticate, why it needs to sign the token-exchange related parts t= oo ?

Thanks, Sergey


=C2=A0 =C2=A0
=C2=A0
--047d7bd75758155398051a623b86-- From nobody Wed Jul 8 12:37:19 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA561A21B7 for ; Wed, 8 Jul 2015 12:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mSXNqyStoew for ; Wed, 8 Jul 2015 12:37:13 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001: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 DD1581A1BCF for ; Wed, 8 Jul 2015 12:37:12 -0700 (PDT) Received: by igrv9 with SMTP id v9so207866472igr.1 for ; Wed, 08 Jul 2015 12: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:content-type; bh=QcOC5zjGF1IbU9A7PtIPdOG8yxBk/GrHirY3TsU7k+M=; b=dFGCY9sG82FW4IhPDJHGW9u89gVW34J2cLILVvmfDeYhBv51YSA1VnoF3jbAJF0M25 RncyR0MiSw8bHCxzEGJTl+0jLxsiqvgfoHH90Gm3ExAY72HpnUqYhW+NH2e2a7zu08i0 Ivu/RKSOEjXAhgdxGa6Oe/7zABaFvmQWMSJjg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=QcOC5zjGF1IbU9A7PtIPdOG8yxBk/GrHirY3TsU7k+M=; b=ETAHqGxVvWGUArAvwPgwmZRWUhSQJzTUnR08ih5+weMec34N28dGq/2FC2ohnUTIk+ 5VR2AcGz/PW7p9apa9PGUeZ5vxsm0evN2/lFd7n+rCwYsi8+1IzynqXxiAlZMXDOqNiv jpmYGR/rIO2VLEaFGAAgF08MIrE+GQCk1mGid1wVNPNzqj/EViAYZbfq3bPbNAU0AcvV /AfNBcHplKv0p0CIo4Iklyxal3Q4ZtGk91MvnNanp33NvjHqmbUZfuil/88D/y+Zg+0Y HqdUqZd47aKcWW9g8p8Nm1qNlGKiLbLan4hTXyhNGYwtbt6tze2OVDPcxMoSnL7W3d6c gaew== X-Gm-Message-State: ALoCoQnanwRb8nuGX2yGDybTHbRfl4YgtD6QvYyqlS57pXKslQemB8XV/Voax3aiABfMNwGCD+FI X-Received: by 10.50.43.137 with SMTP id w9mr74315890igl.30.1436384232229; Wed, 08 Jul 2015 12:37:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.64.209 with HTTP; Wed, 8 Jul 2015 12:36:42 -0700 (PDT) In-Reply-To: <77FAD7D3-A1E5-43D9-926B-0DED4B311F74@mit.edu> References: <826785C8-648D-4A1B-AD8D-E99D76117C67@mit.edu> <559CECB5.4000006@gmail.com> <77FAD7D3-A1E5-43D9-926B-0DED4B311F74@mit.edu> From: Brian Campbell Date: Wed, 8 Jul 2015 13:36:42 -0600 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=e89a8f8388f5ec6e8c051a624318 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Token Chaining Use Case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 19:37:18 -0000 --e89a8f8388f5ec6e8c051a624318 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Probably goes without saying but I'm generally in agreement with Justin here. On Wed, Jul 8, 2015 at 5:40 AM, Justin Richer wrote: > The HTTP *request* should be able to be covered by a JWT signature, and > that should be applicable to any interaction with the token endpoint. I= =E2=80=99m > aware that Nat=E2=80=99s draft is talking about the authorization endpoin= t, but the > same logic could be applied here at the token endpoint. It could actually > even be easier there because we could simply specify that the Content-Typ= e > of the input POST is application/jwt and the payload of said JWT simply > contains all the parameters to the token endpoint. Orthogonal functionali= ty > that meshes well together. > > Brian=E2=80=99s draft puts everything as a parameter, including the input= token > (which can be arbitrary =E2=80=94 the requester doesn=E2=80=99t need to k= now what=E2=80=99s in the > tokens at all). This could easily be turned wholesale into an input JWT > using the transform just described. > > The current draft is a weird halfway state where some input parameters ar= e > in a JWT that=E2=80=99s passed as an input parameter alongside other thin= gs that > are outside the JWT. I don=E2=80=99t think that works particularly well, = and I > think there=E2=80=99s a better, simpler solution that solves all of these= use cases > and then some. > > =E2=80=94 Justin > > > > On Jul 8, 2015, at 5:26 AM, Sergey Beryozkin > wrote: > > > > Hi, > > On 08/07/15 01:41, Mike Jones wrote: > >> I=E2=80=99ll start by saying that if you compare > >> https://tools.ietf.org/html/draft-campbell-oauth-sts-02 and > >> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02, > >> unsurprisingly, you=E2=80=99ll find a lot in common. Both have reques= ts and > >> responses formatted using JSON objects, both have input and output > >> tokens, both have security token type parameters describing their > >> corresponding inputs and outputs. Both can convey act_as and > >> on_behalf_of tokens. And despite what was written below, both define = a > >> new grant_type value that is used to make this new kind of request at > >> the Token Endpoint. > >> > >> The primary thing that Brian=E2=80=99s draft is missing semantically i= s the > >> ability for the requester to sign the set of input parameters. This i= s > >> critical to establishing proper trust to enable the exchange to occur = in > >> many use cases. That=E2=80=99s why the WG draft uses a JWT as the req= uest =E2=80=93 so > >> a signature can be applied to the request, when appropriate. (And whe= n > >> it=E2=80=99s not needed, =E2=80=9Calg=E2=80=9D: =E2=80=9Cnone=E2=80=9D= can be used.) > >> > > > > The requester is a client talking to the token endpoint and this client > needs to authenticate, why it needs to sign the token-exchange related > parts too ? > > > > > > > Thanks, Sergey > > > >> Justin, you=E2=80=99re right that the current WG draft doesn=E2=80=99t= have a separate > >> =E2=80=9Cinput token=E2=80=9D request parameter. In the current draft= , the (optionally) > >> signed request **is** the input token. Thinking some more about the > >> token chaining use case you=E2=80=99re interested in, I see why you wa= nt to have > >> that token to be a separate element in the request. I believe the bes= t > >> way to accomplish that is to add an optional claim to the request that > >> would contain that token. (I think the closest equivalent in Brian=E2= =80=99s > >> draft is the possibility of using an access token or assertion as the > >> client authentication mechanism, possibly passing it as defined in RFC > >> 6750, although the draft doesn=E2=80=99t say that.) Passing the input= token as > >> a claim lets it be part of the signed request. > >> > >> It=E2=80=99s completely up to us when using a different grant_type to = define > >> what the input and output parameters when using that grant_type are. > >> (RFC 6749 already has different sets, depending upon the grant_type > >> used.) I personally find it cleaner to return the output security tok= en > >> that may not be an access token in a =E2=80=9Csecurity_token=E2=80=9D = parameter rather > >> than repurposing the =E2=80=9Caccess_token=E2=80=9D parameter to hold = something that=E2=80=99s > >> not an access token, but now we=E2=80=99re more discussing syntax than > >> semantics. Still, if something is different, it=E2=80=99s probably le= ss error > >> prone to use a different syntax for it. > >> > >> I=E2=80=99m sympathetic to your comment about Nat=E2=80=99s signed req= uests draft, > >> except that the requests that draft specifies are requests to the > >> interactive Authorization Endpoint, whereas the requests we=E2=80=99re= dealing > >> with here are requests to the non-interactive Token Endpoint. Still, > >> thinking of the Token Exchange requests as signed requests to the Toke= n > >> Endpoint, just like Nat=E2=80=99s draft makes signed requests to the > >> Authorization Endpoint, is probably a good unifying mental framework f= or > >> all of us to consider applying to this problem space. > >> > >> Best > >> wishes, > >> > >> -- Mik= e > >> > >> *From:*Justin Richer [mailto:jricher@mit.edu] > >> *Sent:* Tuesday, July 07, 2015 4:47 PM > >> *To:* Mike Jones > >> *Cc:* Brian Campbell; > >> *Subject:* Re: [OAUTH-WG] Token Chaining Use Case > >> > >> This approach is not a good fit for my use cases, and it=E2=80=99s sti= ll not > >> OAuth-y at all. It requires a specially-formed security assertion on > >> the way in, which the client must understand and generate. I still can= =E2=80=99t > >> take an arbitrary token I=E2=80=99ve been handed by someone else and p= ass it off > >> to be pushed forward. The new =E2=80=9C*_type=E2=80=9D parameters seem= to merely kick > >> the can down the road instead of addressing the problems with the > >> current specification. > >> > >> I think that Brian=E2=80=99s approach works much better. It unrolls im= portant > >> parameters, properly uses the token endpoint, and allows for arbitrari= ly > >> formatted input tokens. > >> > >> When combined with Nat=E2=80=99s draft that specifies how to perform a= ll generic > >> OAuth requests as JWTs (or even some of the upcoming PoP work if we ev= er > >> do that), you=E2=80=99ve pretty much got the draft below but with much= more > >> flexibility and power. > >> > >> =E2=80=94 Justin > >> > >> On Jul 7, 2015, at 6:51 PM, Mike Jones >> > wrote: > >> > >> As just updated , I believe that > >> the working group token exchange draft > >> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02 can > >> now also serve the =E2=80=9COAuthy=E2=80=9D token exchange use case= s, such as Justin > >> and Phil=E2=80=99s token chaining use case, as well as support gene= ral token > >> exchange, including exchange of JWT and SAML tokens. The mechanism > >> would be the same one that Brian suggested below =E2=80=93 defining= security > >> token type values for OAuth 2.0 access tokens and refresh tokens = =E2=80=93 > >> enabling them to be used as inputs and outputs in any of the token > >> exchanges. > >> > >> For instance, by using =E2=80=9Caccess token=E2=80=9D as the input = security token > >> type, providing new scope values, and using =E2=80=9Caccess token= =E2=80=9D as the > >> output security token type, token chaining is achieved. > >> > >> Now, a question for the working group=E2=80=A6 What should the sec= urity > >> token type values for access token and refresh token be? Two > >> different choices seem to make sense. > >> > >> (1) Use the values =E2=80=9Caccess_token=E2=80=9D and =E2=80=9Cref= resh_token=E2=80=9D, which are > >> used in RFC 6749 token response values. > >> > >> (2) Define new URNs for this usage, such as > >> urn:ietf:params:oauth:token-type:access-tokenand > >> urn:ietf:params:oauth:token-type:refresh-token. > >> > >> I=E2=80=99d personally be fine just using the short names in (1). > >> > >> If people agree with this approach, we can document this usage in > >> the -03 draft and publish it as soon as the submission tool reopens > >> Monday morning during IETF 93. > >> > >> -- > Mike > >> > >> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian > >> Campbell > >> *Sent:* Thursday, March 26, 2015 3:15 PM > >> *To:* Justin Richer > >> *Cc:* > > >> *Subject:* Re: [OAUTH-WG] Token Chaining Use Case > >> > >> This kind of token exchange might involve exchanges other than > >> swapping an AT for another AT (and downscoping it). It might be an > >> AT for a structured JWT specifically targeted at one of the the > >> particular services that the original RS needs to call. Or an AT > >> might be exchanged for a SAML assertion to use with legacy SOAP > >> serveries. A good general token exchange mechanism enables lots of > >> variations of cases like the one Justin mentioned. And more. In > >> fact, I think downscoping might be a minority use case where what > >> token exchange is often need for is translating tokens from what yo= u > >> have into what the resource you need to call can deal with. > >> > >> There need to be ways for the caller to tell the AS about the token > >> it's asking for - by type or by the address/identifier of where > >> it'll be used. There needs to be ways for the caller to authenticat= e > >> to the AS. And there needs to be some way of expressing this > >> delegation thing (though I'm still not totally convinced it couldn'= t > >> be just the token is about the user/principal and the caller/client > >> of the exchange is who is being delegated to). > >> > >> I realize few (approaching zero) people have or are going to read i= t > >> but I have endeavored to cover all these things in the > >> http://tools.ietf.org/html/draft-campbell-oauth-sts-02 draft. It's > >> an early draft so not without it some rough edges but can provide > >> some guidance on what is needed and offers some protocol syntax for > >> expressing it. I believe Justin's use case would be covered by it > >> (defining a specific token type URI for an OAuth access token issue= d > >> by the AS in question might be needed) as are many others. > >> > >> On Thu, Mar 26, 2015 at 1:31 PM, Justin Richer >> > wrote: > >> > >> As requested after last night=E2=80=99s informal meeting, here is t= he token > >> chaining use case that I want to see represented in the token swap > >> draft. > >> > >> > >> [ Client ] -> [ A ] -> [ B ] -> [ C ] > >> > >> An OAuth client gets an access token AT1, just like it always would= , > >> with scopes [A, B, C] in order to call service A, which requires al= l > >> three scopes. Service A (an RS) accepts this token since it has its > >> scope, and then needs to call service B in turn, which requires > >> scopes [B, C]. It could just re-send the token it got in, AT1, but > >> that would give the downstream RS the ability to call services with > >> scope [ A ] and it should not be allowed to do that. To limit > >> exposure, service A calls a token swap at the AS to create AT2 with > >> scopes [ B, C ], effectively acting as an OAuth client requesting a > >> downscoped token based on AT1. Service A then acts as an OAuth > >> client to call service B, now acting as an RS to service A=E2=80=99= s client, > >> and can fulfill the request. And it=E2=80=99s turtles all the way d= own: > >> Service B can also call service C, and now B acts as a client, > >> requesting AT3 with scope [ C ] based on AT2, and sending AT3 to > >> service C. This prevents C from being able to call B or A, both of > >> which would have been available if AT1 had been passed around. Note > >> that service A or the Client can also request a downscoped token > >> with [ C ] to call service C directly as well, and C doesn=E2=80=99= t have to > >> care how it got there. > >> > >> > >> In other words, it lets the client software be very, very dumb. It > >> doesn=E2=80=99t have to do any special processing, doesn=E2=80=99t = have to know > >> what=E2=80=99s in the token, it just follows the recipe of =E2=80= =9CI got a token, I > >> get another token based on this to call someone else=E2=80=9D. It= =E2=80=99s also > >> analogous to the refresh token flow, but with access tokens going i= n > >> and out. I=E2=80=99ve deployed this setup several times in differen= t service > >> deployments. Even though there is a performance hit in the > >> additional round trips (as Phil brought up in another thread), in > >> these cases the desire to have the tokens hold least privilege > >> access rights (smallest set of scopes per service) outweighed any > >> performance hit (which was shown to be rather small in practice). > >> > >> What I want is for the token swap draft to define or use a mechanis= m > >> that allows us to do this. I think we can do that pretty easily by > >> adjusting the token swap syntax and language, and explicitly callin= g > >> out the semantic processing portion (the current core of the > >> document) for what it is: a way for a token issuer to communicate t= o > >> a token service specific actions. At a high level, the spec would b= e > >> something like: > >> > >> > >> > >> 1. How to swap a token at an AS > >> 1. Send a request to the token endpoint with a new grant type, > >> and a token (of any type/format/flavor) on the way in > >> 2. Get back a new token in a token response > >> 2. Communicating act as / on behalf of semantics via a JWT assertio= n > >> 1. How to create (as an AS/RS/client/other issuer) a JWT with > >> act-as semantics > >> 2. What to do (as an AS/RS) with a JWT with act-as semantics > >> 3. How to create a JWT with on-behalf-of semeantics > >> 4. What to do with a JWT with on-behalf-of-semantics > >> 5. How to possibly represent these semantics with something othe= r > >> than a JWT > >> > >> > >> > >> Section 2 uses the syntax from section 1. Other applications, like > >> the one I laid out above, can use the syntax from section 1 as well= . > >> This works for structured, unstructured, self-generated, > >> cross-domain, within-domain, and other tokens. > >> > >> > >> =E2=80=94 Justin > >> > >> _______________________________________________ > >> OAuth mailing 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/ > > > > Blog: http://sberyozkin.blogspot.com > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --e89a8f8388f5ec6e8c051a624318 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Probably goes without saying but I'm generally in= agreement with Justin here.

=
On Wed, Jul 8, 2015 at 5:40 AM, Justin Richer <jr= icher@mit.edu> wrote:
The H= TTP *request* should be able to be covered by a JWT signature, and that sho= uld be applicable to any interaction with the token endpoint. I=E2=80=99m a= ware that Nat=E2=80=99s draft is talking about the authorization endpoint, = but the same logic could be applied here at the token endpoint. It could ac= tually even be easier there because we could simply specify that the Conten= t-Type of the input POST is application/jwt and the payload of said JWT sim= ply contains all the parameters to the token endpoint. Orthogonal functiona= lity that meshes well together.

Brian=E2=80=99s draft puts everything as a parameter, including the input t= oken (which can be arbitrary =E2=80=94 the requester doesn=E2=80=99t need t= o know what=E2=80=99s in the tokens at all). This could easily be turned wh= olesale into an input JWT using the transform just described.

The current draft is a weird halfway state where some input parameters are = in a JWT that=E2=80=99s passed as an input parameter alongside other things= that are outside the JWT. I don=E2=80=99t think that works particularly we= ll, and I think there=E2=80=99s a better, simpler solution that solves all = of these use cases and then some.

=C2=A0=E2=80=94 Justin


> On Jul 8, 2015, at 5:26 AM, Sergey Beryozkin <sberyozkin@gmail.com> wrote:
>
> Hi,
> On 08/07/15 01:41, Mike Jones wrote:
>> I=E2=80=99ll start by saying that if you compare
>> https://tools.ietf.org/html/draft-ca= mpbell-oauth-sts-02 and
>> https://tools.ietf.org/html/d= raft-ietf-oauth-token-exchange-02,
>> unsurprisingly, you=E2=80=99ll find a lot in common.=C2=A0 Both ha= ve requests and
>> responses formatted using JSON objects, both have input and output=
>> tokens, both have security token type parameters describing their<= br> >> corresponding inputs and outputs.=C2=A0 Both can convey act_as and=
>> on_behalf_of tokens.=C2=A0 And despite what was written below, bot= h define a
>> new grant_type value that is used to make this new kind of request= at
>> the Token Endpoint.
>>
>> The primary thing that Brian=E2=80=99s draft is missing semantical= ly is the
>> ability for the requester to sign the set of input parameters.=C2= =A0 This is
>> critical to establishing proper trust to enable the exchange to oc= cur in
>> many use cases.=C2=A0 That=E2=80=99s why the WG draft uses a JWT a= s the request =E2=80=93 so
>> a signature can be applied to the request, when appropriate.=C2=A0= (And when
>> it=E2=80=99s not needed, =E2=80=9Calg=E2=80=9D: =E2=80=9Cnone=E2= =80=9D can be used.)
>>
>
> The requester is a client talking to the token endpoint and this clien= t needs to authenticate, why it needs to sign the token-exchange related pa= rts too ?
>



> Thanks, Sergey
>
>> Justin, you=E2=80=99re right that the current WG draft doesn=E2=80= =99t have a separate
>> =E2=80=9Cinput token=E2=80=9D request parameter.=C2=A0 In the curr= ent draft, the (optionally)
>> signed request **is** the input token.=C2=A0 Thinking some more ab= out the
>> token chaining use case you=E2=80=99re interested in, I see why yo= u want to have
>> that token to be a separate element in the request.=C2=A0 I believ= e the best
>> way to accomplish that is to add an optional claim to the request = that
>> would contain that token.=C2=A0 (I think the closest equivalent in= Brian=E2=80=99s
>> draft is the possibility of using an access token or assertion as = the
>> client authentication mechanism, possibly passing it as defined in= RFC
>> 6750, although the draft doesn=E2=80=99t say that.)=C2=A0 Passing = the input token as
>> a claim lets it be part of the signed request.
>>
>> It=E2=80=99s completely up to us when using a different grant_type= to define
>> what the input and output parameters when using that grant_type ar= e.
>> (RFC 6749 already has different sets, depending upon the grant_typ= e
>> used.)=C2=A0 I personally find it cleaner to return the output sec= urity token
>> that may not be an access token in a =E2=80=9Csecurity_token=E2=80= =9D parameter rather
>> than repurposing the =E2=80=9Caccess_token=E2=80=9D parameter to h= old something that=E2=80=99s
>> not an access token, but now we=E2=80=99re more discussing syntax = than
>> semantics.=C2=A0 Still, if something is different, it=E2=80=99s pr= obably less error
>> prone to use a different syntax for it.
>>
>> I=E2=80=99m sympathetic to your comment about Nat=E2=80=99s signed= requests draft,
>> except that the requests that draft specifies are requests to the<= br> >> interactive Authorization Endpoint, whereas the requests we=E2=80= =99re dealing
>> with here are requests to the non-interactive Token Endpoint.=C2= =A0 Still,
>> thinking of the Token Exchange requests as signed requests to the = Token
>> Endpoint, just like Nat=E2=80=99s draft makes signed requests to t= he
>> Authorization Endpoint, is probably a good unifying mental framewo= rk for
>> all of us to consider applying to this problem space.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Best
>> wishes,
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0-- Mike
>>
>> *From:*Justin Richer [mailto:jr= icher@mit.edu]
>> *Sent:* Tuesday, July 07, 2015 4:47 PM
>> *To:* Mike Jones
>> *Cc:* Brian Campbell; <oauth@= ietf.org>
>> *Subject:* Re: [OAUTH-WG] Token Chaining Use Case
>>
>> This approach is not a good fit for my use cases, and it=E2=80=99s= still not
>>=C2=A0 OAuth-y at all. It requires a specially-formed security asse= rtion on
>> the way in, which the client must understand and generate. I still= can=E2=80=99t
>> take an arbitrary token I=E2=80=99ve been handed by someone else a= nd pass it off
>> to be pushed forward. The new =E2=80=9C*_type=E2=80=9D parameters = seem to merely kick
>> the can down the road instead of addressing the problems with the<= br> >> current specification.
>>
>> I think that Brian=E2=80=99s approach works much better. It unroll= s important
>> parameters, properly uses the token endpoint, and allows for arbit= rarily
>> formatted input tokens.
>>
>> When combined with Nat=E2=80=99s draft that specifies how to perfo= rm all generic
>> OAuth requests as JWTs (or even some of the upcoming PoP work if w= e ever
>> do that), you=E2=80=99ve pretty much got the draft below but with = much more
>> flexibility and power.
>>
>>=C2=A0 =E2=80=94 Justin
>>
>>=C2=A0 =C2=A0 On Jul 7, 2015, at 6:51 PM, Mike Jones <Michael.Jones@microsoft.com
>>=C2=A0 =C2=A0 <mailto:Michael.Jones@microsoft.com>> wrote:
>>
>>=C2=A0 =C2=A0 As just updated <http://self-issued.info/?= p=3D1412>, I believe that
>>=C2=A0 =C2=A0 the working group token exchange draft
>>=C2=A0 =C2=A0 https://tools.ie= tf.org/html/draft-ietf-oauth-token-exchange-02 can
>>=C2=A0 =C2=A0 now also serve the =E2=80=9COAuthy=E2=80=9D token exc= hange use cases, such as Justin
>>=C2=A0 =C2=A0 and Phil=E2=80=99s token chaining use case, as well a= s support general token
>>=C2=A0 =C2=A0 exchange, including exchange of JWT and SAML tokens.= =C2=A0 The mechanism
>>=C2=A0 =C2=A0 would be the same one that Brian suggested below =E2= =80=93 defining security
>>=C2=A0 =C2=A0 token type values for OAuth 2.0 access tokens and ref= resh tokens =E2=80=93
>>=C2=A0 =C2=A0 enabling them to be used as inputs and outputs in any= of the token
>>=C2=A0 =C2=A0 exchanges.
>>
>>=C2=A0 =C2=A0 For instance, by using =E2=80=9Caccess token=E2=80=9D= as the input security token
>>=C2=A0 =C2=A0 type, providing new scope values, and using =E2=80=9C= access token=E2=80=9D as the
>>=C2=A0 =C2=A0 output security token type, token chaining is achieve= d.
>>
>>=C2=A0 =C2=A0 Now, a question for the working group=E2=80=A6=C2=A0 = What should the security
>>=C2=A0 =C2=A0 token type values for access token and refresh token = be?=C2=A0 Two
>>=C2=A0 =C2=A0 different choices seem to make sense.
>>
>>=C2=A0 =C2=A0 (1)=C2=A0 Use the values =E2=80=9Caccess_token=E2=80= =9D and =E2=80=9Crefresh_token=E2=80=9D, which are
>>=C2=A0 =C2=A0 used in RFC 6749 token response values.
>>
>>=C2=A0 =C2=A0 (2)=C2=A0 Define new URNs for this usage, such as
>>=C2=A0 =C2=A0 urn:ietf:params:oauth:token-type:access-tokenand
>>=C2=A0 =C2=A0 urn:ietf:params:oauth:token-type:refresh-token.
>>
>>=C2=A0 =C2=A0 I=E2=80=99d personally be fine just using the short n= ames in (1).
>>
>>=C2=A0 =C2=A0 If people agree with this approach, we can document t= his usage in
>>=C2=A0 =C2=A0 the -03 draft and publish it as soon as the submissio= n tool reopens
>>=C2=A0 =C2=A0 Monday morning during IETF 93.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =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 =C2=A0 *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian
>>=C2=A0 =C2=A0 Campbell
>>=C2=A0 =C2=A0 *Sent:* Thursday, March 26, 2015 3:15 PM
>>=C2=A0 =C2=A0 *To:* Justin Richer
>>=C2=A0 =C2=A0 *Cc:* <oauth@iet= f.org <mailto:oauth@ietf.org&g= t;>
>>=C2=A0 =C2=A0 *Subject:* Re: [OAUTH-WG] Token Chaining Use Case
>>
>>=C2=A0 =C2=A0 This kind of token exchange might involve exchanges o= ther than
>>=C2=A0 =C2=A0 swapping an AT for another AT (and downscoping it). I= t might be an
>>=C2=A0 =C2=A0 AT for a structured JWT specifically targeted at one = of the the
>>=C2=A0 =C2=A0 particular services that the original RS needs to cal= l. Or an AT
>>=C2=A0 =C2=A0 might be exchanged for a SAML assertion to use with l= egacy SOAP
>>=C2=A0 =C2=A0 serveries.=C2=A0 A good general token exchange mechan= ism enables lots of
>>=C2=A0 =C2=A0 variations of cases like the one Justin mentioned. An= d more. In
>>=C2=A0 =C2=A0 fact, I think downscoping might be a minority use cas= e where what
>>=C2=A0 =C2=A0 token exchange is often need for is translating token= s from what you
>>=C2=A0 =C2=A0 have into what the resource you need to call can deal= with.
>>
>>=C2=A0 =C2=A0 There need to be ways for the caller to tell the AS a= bout the token
>>=C2=A0 =C2=A0 it's asking for - by type or by the address/ident= ifier of where
>>=C2=A0 =C2=A0 it'll be used. There needs to be ways for the cal= ler to authenticate
>>=C2=A0 =C2=A0 to the AS. And there needs to be some way of expressi= ng this
>>=C2=A0 =C2=A0 delegation thing (though I'm still not totally co= nvinced it couldn't
>>=C2=A0 =C2=A0 be just the token is about the user/principal and the= caller/client
>>=C2=A0 =C2=A0 of the exchange is who is being delegated to).
>>
>>=C2=A0 =C2=A0 I realize few (approaching zero) people have or are g= oing to read it
>>=C2=A0 =C2=A0 but I have endeavored to cover all these things in th= e
>>=C2=A0 =C2=A0 http://tools.ietf.org/ht= ml/draft-campbell-oauth-sts-02 draft. It's
>>=C2=A0 =C2=A0 an early draft so not without it some rough edges but= can provide
>>=C2=A0 =C2=A0 some guidance on what is needed and offers some proto= col syntax for
>>=C2=A0 =C2=A0 expressing it. I believe Justin's use case would = be covered by it
>>=C2=A0 =C2=A0 (defining a specific token type URI for an OAuth acce= ss token issued
>>=C2=A0 =C2=A0 by the AS in question might be needed) as are many ot= hers.
>>
>>=C2=A0 =C2=A0 On Thu, Mar 26, 2015 at 1:31 PM, Justin Richer <jricher@mit.edu
>>=C2=A0 =C2=A0 <mailto:jricher= @mit.edu>> wrote:
>>
>>=C2=A0 =C2=A0 As requested after last night=E2=80=99s informal meet= ing, here is the token
>>=C2=A0 =C2=A0 chaining use case that I want to see represented in t= he token swap
>>=C2=A0 =C2=A0 draft.
>>
>>
>>=C2=A0 =C2=A0 [ Client ]=C2=A0 ->=C2=A0 =C2=A0[ A ] -> [ B ] = -> [ C ]
>>
>>=C2=A0 =C2=A0 An OAuth client gets an access token AT1, just like i= t always would,
>>=C2=A0 =C2=A0 with scopes [A, B, C] in order to call service A, whi= ch requires all
>>=C2=A0 =C2=A0 three scopes. Service A (an RS) accepts this token si= nce it has its
>>=C2=A0 =C2=A0 scope, and then needs to call service B in turn, whic= h requires
>>=C2=A0 =C2=A0 scopes [B, C]. It could just re-send the token it got= in, AT1, but
>>=C2=A0 =C2=A0 that would give the downstream RS the ability to call= services with
>>=C2=A0 =C2=A0 scope [ A ] and it should not be allowed to do that. = To limit
>>=C2=A0 =C2=A0 exposure, service A calls a token swap at the AS to c= reate AT2 with
>>=C2=A0 =C2=A0 scopes [ B, C ], effectively acting as an OAuth clien= t requesting a
>>=C2=A0 =C2=A0 downscoped token based on AT1. Service A then acts as= an OAuth
>>=C2=A0 =C2=A0 client to call service B, now acting as an RS to serv= ice A=E2=80=99s client,
>>=C2=A0 =C2=A0 and can fulfill the request. And it=E2=80=99s turtles= all the way down:
>>=C2=A0 =C2=A0 Service B can also call service C, and now B acts as = a client,
>>=C2=A0 =C2=A0 requesting AT3 with scope [ C ] based on AT2, and sen= ding AT3 to
>>=C2=A0 =C2=A0 service C. This prevents C from being able to call B = or A, both of
>>=C2=A0 =C2=A0 which would have been available if AT1 had been passe= d around. Note
>>=C2=A0 =C2=A0 that service A or the Client can also request a downs= coped token
>>=C2=A0 =C2=A0 with [ C ] to call service C directly as well, and C = doesn=E2=80=99t have to
>>=C2=A0 =C2=A0 care how it got there.
>>
>>
>>=C2=A0 =C2=A0 In other words, it lets the client software be very, = very dumb. It
>>=C2=A0 =C2=A0 doesn=E2=80=99t have to do any special processing, do= esn=E2=80=99t have to know
>>=C2=A0 =C2=A0 what=E2=80=99s in the token, it just follows the reci= pe of =E2=80=9CI got a token, I
>>=C2=A0 =C2=A0 get another token based on this to call someone else= =E2=80=9D. It=E2=80=99s also
>>=C2=A0 =C2=A0 analogous to the refresh token flow, but with access = tokens going in
>>=C2=A0 =C2=A0 and out. I=E2=80=99ve deployed this setup several tim= es in different service
>>=C2=A0 =C2=A0 deployments. Even though there is a performance hit i= n the
>>=C2=A0 =C2=A0 additional round trips (as Phil brought up in another= thread), in
>>=C2=A0 =C2=A0 these cases the desire to have the tokens hold least = privilege
>>=C2=A0 =C2=A0 access rights (smallest set of scopes per service) ou= tweighed any
>>=C2=A0 =C2=A0 performance hit (which was shown to be rather small i= n practice).
>>
>>=C2=A0 =C2=A0 What I want is for the token swap draft to define or = use a mechanism
>>=C2=A0 =C2=A0 that allows us to do this. I think we can do that pre= tty easily by
>>=C2=A0 =C2=A0 adjusting the token swap syntax and language, and exp= licitly calling
>>=C2=A0 =C2=A0 out the semantic processing portion (the current core= of the
>>=C2=A0 =C2=A0 document) for what it is: a way for a token issuer to= communicate to
>>=C2=A0 =C2=A0 a token service specific actions. At a high level, th= e spec would be
>>=C2=A0 =C2=A0 something like:
>>
>>
>>
>>=C2=A0 =C2=A0 1. How to swap a token at an AS
>>=C2=A0 =C2=A0 =C2=A0 =C2=A01. Send a request to the token endpoint = with a new grant type,
>>=C2=A0 =C2=A0 and a token (of any type/format/flavor) on the way in=
>>=C2=A0 =C2=A0 =C2=A0 =C2=A02. Get back a new token in a token respo= nse
>>=C2=A0 =C2=A0 2. Communicating act as / on behalf of semantics via = a JWT assertion
>>=C2=A0 =C2=A0 =C2=A0 =C2=A01. How to create (as an AS/RS/client/oth= er issuer) a JWT with
>>=C2=A0 =C2=A0 act-as semantics
>>=C2=A0 =C2=A0 =C2=A0 =C2=A02. What to do (as an AS/RS) with a JWT w= ith act-as semantics
>>=C2=A0 =C2=A0 =C2=A0 =C2=A03. How to create a JWT with on-behalf-of= semeantics
>>=C2=A0 =C2=A0 =C2=A0 =C2=A04. What to do with a JWT with on-behalf-= of-semantics
>>=C2=A0 =C2=A0 =C2=A0 =C2=A05. How to possibly represent these seman= tics with something other
>>=C2=A0 =C2=A0 than a JWT
>>
>>
>>
>>=C2=A0 =C2=A0 Section 2 uses the syntax from section 1. Other appli= cations, like
>>=C2=A0 =C2=A0 the one I laid out above, can use the syntax from sec= tion 1 as well.
>>=C2=A0 =C2=A0 This works for structured, unstructured, self-generat= ed,
>>=C2=A0 =C2=A0 cross-domain, within-domain, and other tokens.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =E2=80=94 Justin
>>
>>=C2=A0 =C2=A0 _______________________________________________
>>=C2=A0 =C2=A0 OAuth mailing list
>>=C2=A0 =C2=A0 OAuth@ietf.org = <mailto:OAuth@ietf.org>
>>=C2=A0 =C2=A0 https://www.ietf.org/mailman/listin= fo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth<= br> >>
>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
> Blog: http://sberyozkin.blogspot.com
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

--e89a8f8388f5ec6e8c051a624318-- From nobody Wed Jul 8 13:54:03 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC201A87AD for ; Wed, 8 Jul 2015 13:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0FRaapPVJDF for ; Wed, 8 Jul 2015 13:53:57 -0700 (PDT) Received: from mail-qk0-f171.google.com (mail-qk0-f171.google.com [209.85.220.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BD441A87AA for ; Wed, 8 Jul 2015 13:53:57 -0700 (PDT) Received: by qkei195 with SMTP id i195so172522428qke.3 for ; Wed, 08 Jul 2015 13:53:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=BjJVpM3l7c0+8MUCtY6ziLyajKkQ5hgnYuFzYYUE6Xg=; b=dHgVWMmmUxw2Zf0Cx7kyP4pViHXRY0a8N0SzHRbS7ffVBVgZSrw6EPbeO6RnvUenvr WT8GDzJ5zyILMcVf6RXPOEY3XRwsCUDTNWBonJfMkzWlCfJ8tSsxLsDoGV8jLb50Rsev ItGu8Qz0IH3vgcljhK3/b6uK0DUrLY62PWVzjMICjdqeRU2DqGDWlz/gRdwDzHEU74Hp 1tN0hnVNZlXZPGpR1UCzNmF13zBih9vul4f3/ak50H7hMEC1jZ790K75oRlhFeL3qrSe gR8FxYEdx9O0SmXSyNAHUO+OHqEyyEAJtOnlRicC0ySwODxJ/XZPmlEA06P+eY/J0wGc +DYA== X-Gm-Message-State: ALoCoQnCmCstRLKLgo4wu/xu4yCKNtyJEw6+d8yOxp6jPw+okvOR0Q+o7JmzNwvC7YjXzlwpM+qj X-Received: by 10.140.235.19 with SMTP id g19mr20317392qhc.52.1436388836463; Wed, 08 Jul 2015 13:53:56 -0700 (PDT) Received: from [192.168.8.101] ([181.202.160.220]) by smtp.gmail.com with ESMTPSA id o65sm2186784qge.34.2015.07.08.13.53.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Jul 2015 13:53:55 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: John Bradley In-Reply-To: <77FAD7D3-A1E5-43D9-926B-0DED4B311F74@mit.edu> Date: Wed, 8 Jul 2015 17:53:45 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <742AD608-A1D3-4544-BECB-19149FE1B422@ve7jtb.com> References: <826785C8-648D-4A1B-AD8D-E99D76117C67@mit.edu> <559CECB5.4000006@gmail.com> <77FAD7D3-A1E5-43D9-926B-0DED4B311F74@mit.edu> To: Justin Richer X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Token Chaining Use Case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 20:54:01 -0000 We seem to be developing request signing for the RS as part of POP, = signed requests for the Authorization endpoint, and a option of = wrapping everything in a JWT for the token endpoint. The Authorization endpoint being accessed via a redirect is one case, = and the others are for direct access. In other things I have been tempted to just wrap everything inside the = JWT, but that is perhaps not a good example of how to build a REST API. Perhaps looking at the POP idea in Justin's draft of sending a detached = signature in a JWT is something that could be generalized for direct = communications beyond the RS. We probably want a strategy on how we want to deal with signed requests = across the various endpoints and with an eye to the upcoming token = binding specs where appropriate. I think everyone agrees that we need some token in token out = functionality that supports impersonation and composite output tokens = and can work with both bearer and pop types of output tokens. =20 We also seem to have some differing ideas. It is up to us to pull = those together. =20 John B. > On Jul 8, 2015, at 8:40 AM, Justin Richer wrote: >=20 > The HTTP *request* should be able to be covered by a JWT signature, = and that should be applicable to any interaction with the token = endpoint. I=92m aware that Nat=92s draft is talking about the = authorization endpoint, but the same logic could be applied here at the = token endpoint. It could actually even be easier there because we could = simply specify that the Content-Type of the input POST is = application/jwt and the payload of said JWT simply contains all the = parameters to the token endpoint. Orthogonal functionality that meshes = well together. >=20 > Brian=92s draft puts everything as a parameter, including the input = token (which can be arbitrary =97 the requester doesn=92t need to know = what=92s in the tokens at all). This could easily be turned wholesale = into an input JWT using the transform just described. >=20 > The current draft is a weird halfway state where some input parameters = are in a JWT that=92s passed as an input parameter alongside other = things that are outside the JWT. I don=92t think that works particularly = well, and I think there=92s a better, simpler solution that solves all = of these use cases and then some. >=20 > =97 Justin >=20 >=20 >> On Jul 8, 2015, at 5:26 AM, Sergey Beryozkin = wrote: >>=20 >> Hi, >> On 08/07/15 01:41, Mike Jones wrote: >>> I=92ll start by saying that if you compare >>> https://tools.ietf.org/html/draft-campbell-oauth-sts-02 and >>> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02, >>> unsurprisingly, you=92ll find a lot in common. Both have requests = and >>> responses formatted using JSON objects, both have input and output >>> tokens, both have security token type parameters describing their >>> corresponding inputs and outputs. Both can convey act_as and >>> on_behalf_of tokens. And despite what was written below, both = define a >>> new grant_type value that is used to make this new kind of request = at >>> the Token Endpoint. >>>=20 >>> The primary thing that Brian=92s draft is missing semantically is = the >>> ability for the requester to sign the set of input parameters. This = is >>> critical to establishing proper trust to enable the exchange to = occur in >>> many use cases. That=92s why the WG draft uses a JWT as the request = =96 so >>> a signature can be applied to the request, when appropriate. (And = when >>> it=92s not needed, =93alg=94: =93none=94 can be used.) >>>=20 >>=20 >> The requester is a client talking to the token endpoint and this = client needs to authenticate, why it needs to sign the token-exchange = related parts too ? >>=20 >=20 >=20 >=20 >> Thanks, Sergey >>=20 >>> Justin, you=92re right that the current WG draft doesn=92t have a = separate >>> =93input token=94 request parameter. In the current draft, the = (optionally) >>> signed request **is** the input token. Thinking some more about the >>> token chaining use case you=92re interested in, I see why you want = to have >>> that token to be a separate element in the request. I believe the = best >>> way to accomplish that is to add an optional claim to the request = that >>> would contain that token. (I think the closest equivalent in = Brian=92s >>> draft is the possibility of using an access token or assertion as = the >>> client authentication mechanism, possibly passing it as defined in = RFC >>> 6750, although the draft doesn=92t say that.) Passing the input = token as >>> a claim lets it be part of the signed request. >>>=20 >>> It=92s completely up to us when using a different grant_type to = define >>> what the input and output parameters when using that grant_type are. >>> (RFC 6749 already has different sets, depending upon the grant_type >>> used.) I personally find it cleaner to return the output security = token >>> that may not be an access token in a =93security_token=94 parameter = rather >>> than repurposing the =93access_token=94 parameter to hold something = that=92s >>> not an access token, but now we=92re more discussing syntax than >>> semantics. Still, if something is different, it=92s probably less = error >>> prone to use a different syntax for it. >>>=20 >>> I=92m sympathetic to your comment about Nat=92s signed requests = draft, >>> except that the requests that draft specifies are requests to the >>> interactive Authorization Endpoint, whereas the requests we=92re = dealing >>> with here are requests to the non-interactive Token Endpoint. = Still, >>> thinking of the Token Exchange requests as signed requests to the = Token >>> Endpoint, just like Nat=92s draft makes signed requests to the >>> Authorization Endpoint, is probably a good unifying mental framework = for >>> all of us to consider applying to this problem space. >>>=20 >>> Best >>> wishes, >>>=20 >>> -- = Mike >>>=20 >>> *From:*Justin Richer [mailto:jricher@mit.edu] >>> *Sent:* Tuesday, July 07, 2015 4:47 PM >>> *To:* Mike Jones >>> *Cc:* Brian Campbell; >>> *Subject:* Re: [OAUTH-WG] Token Chaining Use Case >>>=20 >>> This approach is not a good fit for my use cases, and it=92s still = not >>> OAuth-y at all. It requires a specially-formed security assertion on >>> the way in, which the client must understand and generate. I still = can=92t >>> take an arbitrary token I=92ve been handed by someone else and pass = it off >>> to be pushed forward. The new =93*_type=94 parameters seem to merely = kick >>> the can down the road instead of addressing the problems with the >>> current specification. >>>=20 >>> I think that Brian=92s approach works much better. It unrolls = important >>> parameters, properly uses the token endpoint, and allows for = arbitrarily >>> formatted input tokens. >>>=20 >>> When combined with Nat=92s draft that specifies how to perform all = generic >>> OAuth requests as JWTs (or even some of the upcoming PoP work if we = ever >>> do that), you=92ve pretty much got the draft below but with much = more >>> flexibility and power. >>>=20 >>> =97 Justin >>>=20 >>> On Jul 7, 2015, at 6:51 PM, Mike Jones = >> > wrote: >>>=20 >>> As just updated , I believe = that >>> the working group token exchange draft >>> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02 can >>> now also serve the =93OAuthy=94 token exchange use cases, such as = Justin >>> and Phil=92s token chaining use case, as well as support general = token >>> exchange, including exchange of JWT and SAML tokens. The = mechanism >>> would be the same one that Brian suggested below =96 defining = security >>> token type values for OAuth 2.0 access tokens and refresh tokens =96= >>> enabling them to be used as inputs and outputs in any of the token >>> exchanges. >>>=20 >>> For instance, by using =93access token=94 as the input security = token >>> type, providing new scope values, and using =93access token=94 as = the >>> output security token type, token chaining is achieved. >>>=20 >>> Now, a question for the working group=85 What should the security >>> token type values for access token and refresh token be? Two >>> different choices seem to make sense. >>>=20 >>> (1) Use the values =93access_token=94 and =93refresh_token=94, = which are >>> used in RFC 6749 token response values. >>>=20 >>> (2) Define new URNs for this usage, such as >>> urn:ietf:params:oauth:token-type:access-tokenand >>> urn:ietf:params:oauth:token-type:refresh-token. >>>=20 >>> I=92d personally be fine just using the short names in (1). >>>=20 >>> If people agree with this approach, we can document this usage in >>> the -03 draft and publish it as soon as the submission tool = reopens >>> Monday morning during IETF 93. >>>=20 >>> = -- Mike >>>=20 >>> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian >>> Campbell >>> *Sent:* Thursday, March 26, 2015 3:15 PM >>> *To:* Justin Richer >>> *Cc:* > >>> *Subject:* Re: [OAUTH-WG] Token Chaining Use Case >>>=20 >>> This kind of token exchange might involve exchanges other than >>> swapping an AT for another AT (and downscoping it). It might be an >>> AT for a structured JWT specifically targeted at one of the the >>> particular services that the original RS needs to call. Or an AT >>> might be exchanged for a SAML assertion to use with legacy SOAP >>> serveries. A good general token exchange mechanism enables lots = of >>> variations of cases like the one Justin mentioned. And more. In >>> fact, I think downscoping might be a minority use case where what >>> token exchange is often need for is translating tokens from what = you >>> have into what the resource you need to call can deal with. >>>=20 >>> There need to be ways for the caller to tell the AS about the = token >>> it's asking for - by type or by the address/identifier of where >>> it'll be used. There needs to be ways for the caller to = authenticate >>> to the AS. And there needs to be some way of expressing this >>> delegation thing (though I'm still not totally convinced it = couldn't >>> be just the token is about the user/principal and the = caller/client >>> of the exchange is who is being delegated to). >>>=20 >>> I realize few (approaching zero) people have or are going to read = it >>> but I have endeavored to cover all these things in the >>> http://tools.ietf.org/html/draft-campbell-oauth-sts-02 draft. It's >>> an early draft so not without it some rough edges but can provide >>> some guidance on what is needed and offers some protocol syntax = for >>> expressing it. I believe Justin's use case would be covered by it >>> (defining a specific token type URI for an OAuth access token = issued >>> by the AS in question might be needed) as are many others. >>>=20 >>> On Thu, Mar 26, 2015 at 1:31 PM, Justin Richer >> > wrote: >>>=20 >>> As requested after last night=92s informal meeting, here is the = token >>> chaining use case that I want to see represented in the token swap >>> draft. >>>=20 >>>=20 >>> [ Client ] -> [ A ] -> [ B ] -> [ C ] >>>=20 >>> An OAuth client gets an access token AT1, just like it always = would, >>> with scopes [A, B, C] in order to call service A, which requires = all >>> three scopes. Service A (an RS) accepts this token since it has = its >>> scope, and then needs to call service B in turn, which requires >>> scopes [B, C]. It could just re-send the token it got in, AT1, but >>> that would give the downstream RS the ability to call services = with >>> scope [ A ] and it should not be allowed to do that. To limit >>> exposure, service A calls a token swap at the AS to create AT2 = with >>> scopes [ B, C ], effectively acting as an OAuth client requesting = a >>> downscoped token based on AT1. Service A then acts as an OAuth >>> client to call service B, now acting as an RS to service A=92s = client, >>> and can fulfill the request. And it=92s turtles all the way down: >>> Service B can also call service C, and now B acts as a client, >>> requesting AT3 with scope [ C ] based on AT2, and sending AT3 to >>> service C. This prevents C from being able to call B or A, both of >>> which would have been available if AT1 had been passed around. = Note >>> that service A or the Client can also request a downscoped token >>> with [ C ] to call service C directly as well, and C doesn=92t = have to >>> care how it got there. >>>=20 >>>=20 >>> In other words, it lets the client software be very, very dumb. It >>> doesn=92t have to do any special processing, doesn=92t have to = know >>> what=92s in the token, it just follows the recipe of =93I got a = token, I >>> get another token based on this to call someone else=94. It=92s = also >>> analogous to the refresh token flow, but with access tokens going = in >>> and out. I=92ve deployed this setup several times in different = service >>> deployments. Even though there is a performance hit in the >>> additional round trips (as Phil brought up in another thread), in >>> these cases the desire to have the tokens hold least privilege >>> access rights (smallest set of scopes per service) outweighed any >>> performance hit (which was shown to be rather small in practice). >>>=20 >>> What I want is for the token swap draft to define or use a = mechanism >>> that allows us to do this. I think we can do that pretty easily by >>> adjusting the token swap syntax and language, and explicitly = calling >>> out the semantic processing portion (the current core of the >>> document) for what it is: a way for a token issuer to communicate = to >>> a token service specific actions. At a high level, the spec would = be >>> something like: >>>=20 >>>=20 >>>=20 >>> 1. How to swap a token at an AS >>> 1. Send a request to the token endpoint with a new grant type, >>> and a token (of any type/format/flavor) on the way in >>> 2. Get back a new token in a token response >>> 2. Communicating act as / on behalf of semantics via a JWT = assertion >>> 1. How to create (as an AS/RS/client/other issuer) a JWT with >>> act-as semantics >>> 2. What to do (as an AS/RS) with a JWT with act-as semantics >>> 3. How to create a JWT with on-behalf-of semeantics >>> 4. What to do with a JWT with on-behalf-of-semantics >>> 5. How to possibly represent these semantics with something = other >>> than a JWT >>>=20 >>>=20 >>>=20 >>> Section 2 uses the syntax from section 1. Other applications, like >>> the one I laid out above, can use the syntax from section 1 as = well. >>> This works for structured, unstructured, self-generated, >>> cross-domain, within-domain, and other tokens. >>>=20 >>>=20 >>> =97 Justin >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >>=20 >> --=20 >> Sergey Beryozkin >>=20 >> Talend Community Coders >> http://coders.talend.com/ >>=20 >> Blog: http://sberyozkin.blogspot.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 Wed Jul 8 15:10:14 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284FF1A8896 for ; Wed, 8 Jul 2015 15:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ER_ZorJPxu50 for ; Wed, 8 Jul 2015 15:10:06 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0120.outbound.protection.outlook.com [207.46.100.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 507B91A883C for ; Wed, 8 Jul 2015 15:10:06 -0700 (PDT) Received: from BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) by BY2PR03MB425.namprd03.prod.outlook.com (10.141.141.139) with Microsoft SMTP Server (TLS) id 15.1.207.12; Wed, 8 Jul 2015 22:10:05 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.213.10; Wed, 8 Jul 2015 22:09:59 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0213.000; Wed, 8 Jul 2015 22:09:59 +0000 From: Mike Jones To: Brian Campbell Thread-Topic: [OAUTH-WG] Token Chaining Use Case Thread-Index: AQHQZ/MY5K5Dp0IvikmgQJJzAhL8fZ0vVM6AgKHjaSCAABZagIAABdjQgAFFh4CAACahcA== Date: Wed, 8 Jul 2015 22:09:59 +0000 Message-ID: References: <826785C8-648D-4A1B-AD8D-E99D76117C67@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; x-originating-ip: [2001:4898:80e8:ed31::4] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:AuzeBKKj3Eq0cA/MWO9qK2EO9GyTzxZFyDkMXkKCY1pz19U0gVifDLeJOSVp9qDRaIjcBZNn9VZuUDTo/xSBaM+kn6APPlkgEROmq0fWh2S8wvjLtWKL9QRO4jh9d09DBy2nnogSjBKG3Ht9ZUxzng==; 24:pF1ljv+yOrjlqx/on99aGarYAs1ndETMrQbm21gT8SGhZUkSzozS8LH/IV48tWD8AIPMdWrJdWnqr1PGzZl84EXvXpa1/80OmEn515aWw+8=; 20:FLRFDznqD2Y6YjPdTnh1kGFELE4xR90rfWdRDbX5kwnOfwVET+HXeE6XyGS8NxxGFep7GQPrijBwZnBm8+qPaA== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB425; by2pr03mb443: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 0631F0BC3D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(377454003)(51444003)(24454002)(53754006)(110136002)(19625215002)(40100003)(92566002)(16236675004)(15975445007)(5001960100002)(102836002)(77156002)(189998001)(54356999)(5003600100002)(33656002)(62966003)(15395725005)(86362001)(76176999)(86612001)(50986999)(77096005)(19300405004)(74316001)(99286002)(76576001)(19580405001)(2656002)(2950100001)(93886004)(106116001)(46102003)(2900100001)(19609705001)(87936001)(5002640100001)(19617315012)(122556002)(19580395003)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4429DB920047BC96E894760F5910BY2PR03MB442namprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2015 22:09:59.6369 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 X-Microsoft-Exchange-Diagnostics: 1; BY2PR03MB425; 2:/YQhLJk6HpURbw620q5g/ljFT8cpKlij58kFmlgx7C1szIzdkkAf2VAhPqkyRkcf; 3:dJ1l/OwVwTiM2M+iV3j/HUqiOuPG/YGs8VimTSplYh4OEeA5x1gXMTOWSSU1f8YEAZLXYxlxK/rmigxNoNmotxW3u0gzlaVbBDwGvcCeDbK+M/M7eEM7SvbLKCfKrOIVTOOnhMs9N0Owa8XOupgQgw==; 25:QEAz8n7tiVvmugvF/V9TT2s7PKyVrCGrp0zb6uoWcLxSj71akxPxVfNM3Aype+y3INA8GnHbrAYwpzeXdPZKH/RrYeNr6EWN86XLE5om5eob0q+yKFEtvN4mVPrSl8gbhH4S3cnkoehVhWPt8siYhuf0tbk7rLBB/GBqQScaPvHMA09PIP0tCLVfGd/T63yIg+9WdAFZdtJq505j83PqRKZyM/p5eosSNvfxIAH9x/iia6u5+0mYhUZqI4MpK5rMc44TeejuIkwga9jqxHVPuQ== X-Microsoft-Exchange-Diagnostics: 1; BY2PR03MB425; 20:hhrB2HvaH5wbe13HgEn9JnD9iq1+SEB7CxQOdRTGBlr39gs4N+1noNbeLyDw3Qic5MmsTRrCa2Cvqt2NyEsG3uc8hh3qMFxlgvOvt/noMNLt4FhuTWdvJmQJgrUwibOSGHb+sPFIT7qm5nGo36mfjHh3uG7Nh04K979uZC3OcU1pqDhxxQWUyT1dTo6BUkSz2+uZ1LxTYMCvgbVa7MCX4gxB0hiDHTIC6cOMKounupK0g9yh6A48ESNBjzU8crO2bk3Im59eUAFGMCDJ/1E7vTSsrFeLFK1JXYGSwavvrMwB6UeGbQyCRQ4xCDSiQQXgjkgb+HVN5j3TJ9EflfsINvIcYu+enh6aOzbEAw2n6mM+LXLBJbxp3NSlAxybMQIv+UYldfHjtx2FmmEE5ggW9rwUEO6IAu3ZTib1c76ZotknJ7xIOKRwX6xKFr8es5bPb6VG7BYmJbADYy51BQkP6mY66SeGjcwgTTTnrzeEBZk04kUarhcajdjJ9b1Eo4qy; 23:Ew8ousNeiJ4Ytvq+DjTtT9fd3OzMo+0YX0Eayva7OVlZdsH9Z8Vw7zfwfnQXaVjs5g+k5/g0SETW5JgHdAK5N7OvlpYAx0xC+cX5gdzLB4s32vER/wZqEkDLOP9xvg+X9HpywsCSxE4Ff5gRJQpHcbkkTBYR37Ipr5dgG/oVgO4KP8ZoRIPCrETATdqLuuDVnZQs80wY9/ibD951bswM2j//EPYglsO1Y9ljx3a79n6UZrsVj+ev/1JRFPtbDSJu X-OriginatorOrg: microsoft.com Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Token Chaining Use Case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 22:10:13 -0000 --_000_BY2PR03MB4429DB920047BC96E894760F5910BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLiAgQWZ0ZXIgcmVhZGluZyBCcmlhbuKAmXMgbm90ZSwgaGUgYW5kIEkgc3Bva2Ugb24g dGhlIHBob25lIHRvIHRyeSB0byBjbGVhciBhIGZldyB0aGluZ3MgdXAgYW5kIHdvcmsgb24gYSBj b2xsYWJvcmF0aXZlIHBhdGggZm9yd2FyZC4gIEhlcmXigJlzIHNvbWUgb2Ygd2hhdCB3ZSB0YWxr ZWQgYWJvdXTigKYNCg0KRmlyc3QsIEnigJltIHNvcnJ5IHRoYXQgSSBtYXkgaGF2ZSBjb250cmli dXRlZCB0byB0aGUgaW1wcmVzc2lvbiB0aGF0IHRoZXJl4oCZcyBsaXR0bGUgd2lsbGluZ25lc3Mg b24gbXkgcGFydCB0byBjb25zaWRlciBjaGFuZ2VzIHRvIHRoZSBkcmFmdC4gIFRoYXTigJlzIG5v dCB0aGUgY2FzZSBhbmQgdGhlIHRydXRoIGlzIGFjdHVhbGx5IG11Y2ggc2ltcGxlciB0aGFuIHRo YXTigKYgIEnigJlkIGJlZW4gc3VwZXItYnVzeSBkb2luZyBvdGhlciB0aGluZ3MsIGluY2x1ZGlu ZyBmaW5pc2hpbmcgSldULCBKT1NFLCBPQXV0aCBBc3NlcnRpb25zLCBoZWxwaW5nIGRldmVsb3Ag YW5kIGxhdW5jaCB0aGUgT3BlbklEIENlcnRpZmljYXRpb24gcHJvZ3JhbTxodHRwOi8vb3Blbmlk Lm5ldC9jZXJ0aWZpY2F0aW9uLz4sIGFuZCBzZXZlcmFsIG90aGVyIHZhbHVhYmxlIHRoaW5ncywg YW5kIEkgc2ltcGx5IGhhZG7igJl0IGdpdmVuIHRva2VuIGV4Y2hhbmdlIGFueSBzaWduaWZpY2Fu dCBiYW5kd2lkdGggZm9yIGEgd2hpbGUgYXMgYSByZXN1bHQuICBOb3cgdGhhdCBtYW55IG9mIHRo b3NlIHRoaW5ncyBhcmUgZG9uZSwgSSBkbyBoYXZlIGJhbmR3aWR0aCB0byB3b3JrIG9uIGl0IG5v dy4NCg0KT25lIGNvbmNyZXRlIHRoaW5nIEJyaWFuIGFuZCBJIGFncmVlZCB0byBkbyBhcyBhIG5l eHQgc3RlcCBpcyB0byB3b3JrIG9uIGEgbGlzdCBvZiBpc3N1ZXMgYW5kIGNob2ljZXMgZm9yIHRo ZSB3b3JraW5nIGdyb3VwIHRvIGNvbnNpZGVyIHRvZ2V0aGVyLCB3aGljaCB3ZeKAmWxsIGpvaW50 bHkgcHJlc2VudCBpbiBQcmFndWUuICBIb3BlZnVsbHkgdGhhdCB3aWxsIGhlbHAgcmVkdWNlIHNv bWUgb2YgdGhlIGNvbmZ1c2lvbiBhbmQgcmVwbGFjZSBpdCB3aXRoIGEgY2xlYXIgYW4gYWN0aW9u YWJsZSBlbmdpbmVlcmluZyBhbmFseXNpcyBvZiB0aGUgb3B0aW9ucyBhdmFpbGFibGUgdG8gdXMu DQoNCkkga25vdyB3ZSBib3RoIHNoYXJlIHRoZSBnb2FsIG9mIGtlZXBpbmcgdGhpbmdzIGFzIHNp bXBsZSBhbmQgZWZmaWNpZW50IGFzIHBvc3NpYmxlLCB3aGlsZSBlbmFibGluZyBzdXBwb3J0IGZv ciB0aGUgdG9rZW4gZXhjaGFuZ2UgdXNlIGNhc2VzIHRoYXQgZGlmZmVyZW50IGFwcGxpY2F0aW9u cyBhY3R1YWxseSBuZWVkLg0KDQpPbmUgb3RoZXIgdGhpbmcgdGhhdCB3ZSBib3RoIHRoaW5rIHdv dWxkIGhlbHAgcGVvcGxlIGJldHRlciB1bmRlcnN0YW5kIGFuZCB1c2UgdGhlIHJlc3VsdGluZyBz cGVjIGlzIHRvIGhhdmUgYSBudW1iZXIgb2YgY2xlYXIsIGlsbHVzdHJhdGl2ZSBleGFtcGxlcy4g IEZhY2UgaXQsIHdoYXRldmVyIHlvdSBjYWxsIGl0IChkZWxlZ2F0aW9uLCBpbXBlcnNvbmF0aW9u LCBvbi1iZWhhbGYtb2YsIGFjdC1hcywgZXRjLiksIHNvbWUgb2YgdGhlIGNvbmNlcHRzIGFyZSBz dWJ0bGUsIGFuZCBzbyB0aGUgbW9yZSB3ZSBjYW4gc2hlZCBsaWdodCBvbiB0aGVtIHRocm91Z2gg Y29uY3JldGUgZXhhbXBsZXMsIHRoZSBlYXNpZXIgSSBzdXNwZWN0IHRoYXQgd2UgY2FuIG1ha2Ug aXQgZm9yIHBlb3BsZSB0byBib3RoIHVuZGVyc3RhbmQgd2hhdCB0aGV5IGFyZSBhbmQgaG93IHRo ZXkgYXBwbHkgdG8gdGhlaXIgdXNlIGNhc2VzLg0KDQpJ4oCZbSBsb29raW5nIGZvcndhcmQgdG8g c2VlaW5nIG1hbnkgb2YgeW91IGluIFByYWd1ZSBwcmV0dHkgc29vbiENCg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1p a2UNCg0KRnJvbTogQnJpYW4gQ2FtcGJlbGwgW21haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5 LmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgSnVseSAwOCwgMjAxNSAxMjozMyBQTQ0KVG86IE1pa2Ug Sm9uZXMNCkNjOiBKdXN0aW4gUmljaGVyOyA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog W09BVVRILVdHXSBUb2tlbiBDaGFpbmluZyBVc2UgQ2FzZQ0KDQpUaGVyZSBpcyBhIGxvdCBpbiBj b21tb24sIHllcy4gRnVuZGFtZW50YWxseSB3ZSdyZSB3b3JraW5nIHRvIGFkZHJlc3MgdGhlIHNh bWUgbmVlZHMsIHdoaWNoIHNob3VsZCBsZWFkIHRvIHNvbWUgY29tbW9uYWxpdHkuIEJ1dCBJIHdh cyBhbHNvIHRyeWluZyB0byBiZSBjb25jaWxpYXRvcnkgaW4gdGhlIHdvcmsgSSBkaWQgYW5kIG1h a2UgYSBnb29kIGZhaXRoIGVmZm9ydCBhdCBlc3RhYmxpc2hpbmcgc29tZSBjb21tb25hbGl0eSBm cm9tIHdoaWNoIGNvbGxhYm9yYXRpdmUgd29yayBjb3VsZCBtb3ZlIGZvcndhcmQuIEluIHJldHJv c3BlY3QgSSBzaG91bGQgcHJvYmFibHkgaGF2ZSBqdXN0IG91dHJpZ2h0IG9wcG9zZWQgdGhlIGFk b3B0aW9uIG9mIGRyYWZ0LWpvbmVzLW9hdXRoLXRva2VuLWV4Y2hhbmdlIGFzIGEgV0cgaXRlbS4g SSB0aG91Z2h0IHRyeWluZyB0byB3b3JrIHdpdGggeW91IHdvdWxkIGJlIG1vcmUgZWZmZWN0aXZl IHRoYW4gd29ya2luZyBhZ2FpbnN0IHlvdS4gQXQgdGhlIHRpbWUgeW91IHNlZW1lZCBhbWVuYWJs ZSB0byB0aGF0IGFuZCBldmVuIHByb3Bvc2VkIGNvLWVkaXRpbmcgd2l0aC4gSGFubmVzIGZvbGxv d2VkIHRoYXQgaW5kaWNhdGluZyBzdXBwb3J0IGZvciBhZGRpbmcgb3RoZXIgY28tYXV0aG9ycyAo aGUgZGlkbid0IHNheSBpdCBidXQga2luZCBvZiBpbXBsaWVkIHBlcmhhcHMgSnVzdGluIGFuZC9v ciBQaGlsIGJhc2VkIG9uIHByaW9yIHJlbGF0ZWQgd29yaykuIFNpbmNlIHRoYXQgdGltZSwgaG93 ZXZlciwgdGhlcmUncyBiZWVuIGxpdHRsZSB3aWxsaW5nbmVzcyB0byBjb25zaWRlciBjaGFuZ2Vz IHRvIHRoZSBkcmFmdCAob3RoZXIgdGhhbiB2ZXJ5IHRyaXZpYWwgaXRlbXMpLiBBbmQgVG9ueSB3 YXMgYWRkZWQgYXMgYSBjby1hdXRob3IsIHdoaWNoIHRvIG1lIChhbmQgSSBzdXNwZWN0IG1hbnkg b3RoZXJzKSBzaWduYWxzIGEgY29tcGxldGUgbGFjayBvZiB3aWxsaW5nbmVzcyB0byBhY3R1YWxs eSBjb2xsYWJvcmF0ZSB0b3dhcmRzIGEgc29sdXRpb24gdGhhdCdzIGFjY2VwdGFibGUgdG8gbW9y ZSB0aGFuIG9uZSBjb250aW5nZW50Lg0KVGhlcmUgYXJlIGRpZmZlcmVuY2VzIGluIHRoZSBkcmFm dHMgdG9vLiBJIHdvbid0IGxpc3QgdGhlbSBhbGwgaGVyZSBidXQgZGlkIHdhbnQgdG8gY2FsbCBv dXQgdGhhdCwgY29udHJhcnkgdG8gd2hhdCB5b3Ugc2FpZCwgdGhlIHJlcXVlc3QgaW4gbXkgZHJh ZnQgaXMgbWFkZSB1cCBvZiByZWd1bGFyIG9sZCBIVFRQIGZvcm0tdXJsZW5jb2RlZCBQT1NUIHBh cmFtZXRlcnMuIFdoaWNoIGlzIGEgc2ltcGxpZmljYXRpb24gYW5kIGVmZmljaWVudGx5IGltcHJv dmVtZW50IHRoYXQgc2VlbXMgdG8gYmUgcHJlZmVycmVkLg0KDQpPbiBUdWUsIEp1bCA3LCAyMDE1 IGF0IDY6NDEgUE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWls dG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpJ4oCZbGwgc3RhcnQgYnkg c2F5aW5nIHRoYXQgaWYgeW91IGNvbXBhcmUgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWNhbXBiZWxsLW9hdXRoLXN0cy0wMiBhbmQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMDIsIHVuc3VycHJpc2luZ2x5LCB5b3Xi gJlsbCBmaW5kIGEgbG90IGluIGNvbW1vbi4gIEJvdGggaGF2ZSByZXF1ZXN0cyBhbmQgcmVzcG9u c2VzIGZvcm1hdHRlZCB1c2luZyBKU09OIG9iamVjdHMsIGJvdGggaGF2ZSBpbnB1dCBhbmQgb3V0 cHV0IHRva2VucywgYm90aCBoYXZlIHNlY3VyaXR5IHRva2VuIHR5cGUgcGFyYW1ldGVycyBkZXNj cmliaW5nIHRoZWlyIGNvcnJlc3BvbmRpbmcgaW5wdXRzIGFuZCBvdXRwdXRzLiAgQm90aCBjYW4g Y29udmV5IGFjdF9hcyBhbmQgb25fYmVoYWxmX29mIHRva2Vucy4gIEFuZCBkZXNwaXRlIHdoYXQg d2FzIHdyaXR0ZW4gYmVsb3csIGJvdGggZGVmaW5lIGEgbmV3IGdyYW50X3R5cGUgdmFsdWUgdGhh dCBpcyB1c2VkIHRvIG1ha2UgdGhpcyBuZXcga2luZCBvZiByZXF1ZXN0IGF0IHRoZSBUb2tlbiBF bmRwb2ludC4NCg0KVGhlIHByaW1hcnkgdGhpbmcgdGhhdCBCcmlhbuKAmXMgZHJhZnQgaXMgbWlz c2luZyBzZW1hbnRpY2FsbHkgaXMgdGhlIGFiaWxpdHkgZm9yIHRoZSByZXF1ZXN0ZXIgdG8gc2ln biB0aGUgc2V0IG9mIGlucHV0IHBhcmFtZXRlcnMuICBUaGlzIGlzIGNyaXRpY2FsIHRvIGVzdGFi bGlzaGluZyBwcm9wZXIgdHJ1c3QgdG8gZW5hYmxlIHRoZSBleGNoYW5nZSB0byBvY2N1ciBpbiBt YW55IHVzZSBjYXNlcy4gIFRoYXTigJlzIHdoeSB0aGUgV0cgZHJhZnQgdXNlcyBhIEpXVCBhcyB0 aGUgcmVxdWVzdCDigJMgc28gYSBzaWduYXR1cmUgY2FuIGJlIGFwcGxpZWQgdG8gdGhlIHJlcXVl c3QsIHdoZW4gYXBwcm9wcmlhdGUuICAoQW5kIHdoZW4gaXTigJlzIG5vdCBuZWVkZWQsIOKAnGFs Z+KAnTog4oCcbm9uZeKAnSBjYW4gYmUgdXNlZC4pDQoNCkp1c3RpbiwgeW914oCZcmUgcmlnaHQg dGhhdCB0aGUgY3VycmVudCBXRyBkcmFmdCBkb2VzbuKAmXQgaGF2ZSBhIHNlcGFyYXRlIOKAnGlu cHV0IHRva2Vu4oCdIHJlcXVlc3QgcGFyYW1ldGVyLiAgSW4gdGhlIGN1cnJlbnQgZHJhZnQsIHRo ZSAob3B0aW9uYWxseSkgc2lnbmVkIHJlcXVlc3QgKmlzKiB0aGUgaW5wdXQgdG9rZW4uICBUaGlu a2luZyBzb21lIG1vcmUgYWJvdXQgdGhlIHRva2VuIGNoYWluaW5nIHVzZSBjYXNlIHlvdeKAmXJl IGludGVyZXN0ZWQgaW4sIEkgc2VlIHdoeSB5b3Ugd2FudCB0byBoYXZlIHRoYXQgdG9rZW4gdG8g YmUgYSBzZXBhcmF0ZSBlbGVtZW50IGluIHRoZSByZXF1ZXN0LiAgSSBiZWxpZXZlIHRoZSBiZXN0 IHdheSB0byBhY2NvbXBsaXNoIHRoYXQgaXMgdG8gYWRkIGFuIG9wdGlvbmFsIGNsYWltIHRvIHRo ZSByZXF1ZXN0IHRoYXQgd291bGQgY29udGFpbiB0aGF0IHRva2VuLiAgKEkgdGhpbmsgdGhlIGNs b3Nlc3QgZXF1aXZhbGVudCBpbiBCcmlhbuKAmXMgZHJhZnQgaXMgdGhlIHBvc3NpYmlsaXR5IG9m IHVzaW5nIGFuIGFjY2VzcyB0b2tlbiBvciBhc3NlcnRpb24gYXMgdGhlIGNsaWVudCBhdXRoZW50 aWNhdGlvbiBtZWNoYW5pc20sIHBvc3NpYmx5IHBhc3NpbmcgaXQgYXMgZGVmaW5lZCBpbiBSRkMg Njc1MCwgYWx0aG91Z2ggdGhlIGRyYWZ0IGRvZXNu4oCZdCBzYXkgdGhhdC4pICBQYXNzaW5nIHRo ZSBpbnB1dCB0b2tlbiBhcyBhIGNsYWltIGxldHMgaXQgYmUgcGFydCBvZiB0aGUgc2lnbmVkIHJl cXVlc3QuDQoNCkl04oCZcyBjb21wbGV0ZWx5IHVwIHRvIHVzIHdoZW4gdXNpbmcgYSBkaWZmZXJl bnQgZ3JhbnRfdHlwZSB0byBkZWZpbmUgd2hhdCB0aGUgaW5wdXQgYW5kIG91dHB1dCBwYXJhbWV0 ZXJzIHdoZW4gdXNpbmcgdGhhdCBncmFudF90eXBlIGFyZS4gIChSRkMgNjc0OSBhbHJlYWR5IGhh cyBkaWZmZXJlbnQgc2V0cywgZGVwZW5kaW5nIHVwb24gdGhlIGdyYW50X3R5cGUgdXNlZC4pICBJ IHBlcnNvbmFsbHkgZmluZCBpdCBjbGVhbmVyIHRvIHJldHVybiB0aGUgb3V0cHV0IHNlY3VyaXR5 IHRva2VuIHRoYXQgbWF5IG5vdCBiZSBhbiBhY2Nlc3MgdG9rZW4gaW4gYSDigJxzZWN1cml0eV90 b2tlbuKAnSBwYXJhbWV0ZXIgcmF0aGVyIHRoYW4gcmVwdXJwb3NpbmcgdGhlIOKAnGFjY2Vzc190 b2tlbuKAnSBwYXJhbWV0ZXIgdG8gaG9sZCBzb21ldGhpbmcgdGhhdOKAmXMgbm90IGFuIGFjY2Vz cyB0b2tlbiwgYnV0IG5vdyB3ZeKAmXJlIG1vcmUgZGlzY3Vzc2luZyBzeW50YXggdGhhbiBzZW1h bnRpY3MuICBTdGlsbCwgaWYgc29tZXRoaW5nIGlzIGRpZmZlcmVudCwgaXTigJlzIHByb2JhYmx5 IGxlc3MgZXJyb3IgcHJvbmUgdG8gdXNlIGEgZGlmZmVyZW50IHN5bnRheCBmb3IgaXQuDQoNCkni gJltIHN5bXBhdGhldGljIHRvIHlvdXIgY29tbWVudCBhYm91dCBOYXTigJlzIHNpZ25lZCByZXF1 ZXN0cyBkcmFmdCwgZXhjZXB0IHRoYXQgdGhlIHJlcXVlc3RzIHRoYXQgZHJhZnQgc3BlY2lmaWVz IGFyZSByZXF1ZXN0cyB0byB0aGUgaW50ZXJhY3RpdmUgQXV0aG9yaXphdGlvbiBFbmRwb2ludCwg d2hlcmVhcyB0aGUgcmVxdWVzdHMgd2XigJlyZSBkZWFsaW5nIHdpdGggaGVyZSBhcmUgcmVxdWVz dHMgdG8gdGhlIG5vbi1pbnRlcmFjdGl2ZSBUb2tlbiBFbmRwb2ludC4gIFN0aWxsLCB0aGlua2lu ZyBvZiB0aGUgVG9rZW4gRXhjaGFuZ2UgcmVxdWVzdHMgYXMgc2lnbmVkIHJlcXVlc3RzIHRvIHRo ZSBUb2tlbiBFbmRwb2ludCwganVzdCBsaWtlIE5hdOKAmXMgZHJhZnQgbWFrZXMgc2lnbmVkIHJl cXVlc3RzIHRvIHRoZSBBdXRob3JpemF0aW9uIEVuZHBvaW50LCBpcyBwcm9iYWJseSBhIGdvb2Qg dW5pZnlpbmcgbWVudGFsIGZyYW1ld29yayBmb3IgYWxsIG9mIHVzIHRvIGNvbnNpZGVyIGFwcGx5 aW5nIHRvIHRoaXMgcHJvYmxlbSBzcGFjZS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJlc3Qgd2lzaGVzLA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IC0tIE1pa2UNCg0KRnJvbTogSnVzdGluIFJpY2hlciBbbWFpbHRvOmpyaWNoZXJAbWl0LmVkdTxt YWlsdG86anJpY2hlckBtaXQuZWR1Pl0NClNlbnQ6IFR1ZXNkYXksIEp1bHkgMDcsIDIwMTUgNDo0 NyBQTQ0KVG86IE1pa2UgSm9uZXMNCkNjOiBCcmlhbiBDYW1wYmVsbDsgPG9hdXRoQGlldGYub3Jn PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQoNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFRva2Vu IENoYWluaW5nIFVzZSBDYXNlDQoNClRoaXMgYXBwcm9hY2ggaXMgbm90IGEgZ29vZCBmaXQgZm9y IG15IHVzZSBjYXNlcywgYW5kIGl04oCZcyBzdGlsbCBub3QgIE9BdXRoLXkgYXQgYWxsLiBJdCBy ZXF1aXJlcyBhIHNwZWNpYWxseS1mb3JtZWQgc2VjdXJpdHkgYXNzZXJ0aW9uIG9uIHRoZSB3YXkg aW4sIHdoaWNoIHRoZSBjbGllbnQgbXVzdCB1bmRlcnN0YW5kIGFuZCBnZW5lcmF0ZS4gSSBzdGls bCBjYW7igJl0IHRha2UgYW4gYXJiaXRyYXJ5IHRva2VuIEnigJl2ZSBiZWVuIGhhbmRlZCBieSBz b21lb25lIGVsc2UgYW5kIHBhc3MgaXQgb2ZmIHRvIGJlIHB1c2hlZCBmb3J3YXJkLiBUaGUgbmV3 IOKAnCpfdHlwZeKAnSBwYXJhbWV0ZXJzIHNlZW0gdG8gbWVyZWx5IGtpY2sgdGhlIGNhbiBkb3du IHRoZSByb2FkIGluc3RlYWQgb2YgYWRkcmVzc2luZyB0aGUgcHJvYmxlbXMgd2l0aCB0aGUgY3Vy cmVudCBzcGVjaWZpY2F0aW9uLg0KDQpJIHRoaW5rIHRoYXQgQnJpYW7igJlzIGFwcHJvYWNoIHdv cmtzIG11Y2ggYmV0dGVyLiBJdCB1bnJvbGxzIGltcG9ydGFudCBwYXJhbWV0ZXJzLCBwcm9wZXJs eSB1c2VzIHRoZSB0b2tlbiBlbmRwb2ludCwgYW5kIGFsbG93cyBmb3IgYXJiaXRyYXJpbHkgZm9y bWF0dGVkIGlucHV0IHRva2Vucy4NCg0KV2hlbiBjb21iaW5lZCB3aXRoIE5hdOKAmXMgZHJhZnQg dGhhdCBzcGVjaWZpZXMgaG93IHRvIHBlcmZvcm0gYWxsIGdlbmVyaWMgT0F1dGggcmVxdWVzdHMg YXMgSldUcyAob3IgZXZlbiBzb21lIG9mIHRoZSB1cGNvbWluZyBQb1Agd29yayBpZiB3ZSBldmVy IGRvIHRoYXQpLCB5b3XigJl2ZSBwcmV0dHkgbXVjaCBnb3QgdGhlIGRyYWZ0IGJlbG93IGJ1dCB3 aXRoIG11Y2ggbW9yZSBmbGV4aWJpbGl0eSBhbmQgcG93ZXIuDQoNCiDigJQgSnVzdGluDQoNCk9u IEp1bCA3LCAyMDE1LCBhdCA2OjUxIFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KDQpB cyBqdXN0IHVwZGF0ZWQ8aHR0cDovL3NlbGYtaXNzdWVkLmluZm8vP3A9MTQxMj4sIEkgYmVsaWV2 ZSB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIHRva2VuIGV4Y2hhbmdlIGRyYWZ0IGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTAyIGNhbiBu b3cgYWxzbyBzZXJ2ZSB0aGUg4oCcT0F1dGh54oCdIHRva2VuIGV4Y2hhbmdlIHVzZSBjYXNlcywg c3VjaCBhcyBKdXN0aW4gYW5kIFBoaWzigJlzIHRva2VuIGNoYWluaW5nIHVzZSBjYXNlLCBhcyB3 ZWxsIGFzIHN1cHBvcnQgZ2VuZXJhbCB0b2tlbiBleGNoYW5nZSwgaW5jbHVkaW5nIGV4Y2hhbmdl IG9mIEpXVCBhbmQgU0FNTCB0b2tlbnMuICBUaGUgbWVjaGFuaXNtIHdvdWxkIGJlIHRoZSBzYW1l IG9uZSB0aGF0IEJyaWFuIHN1Z2dlc3RlZCBiZWxvdyDigJMgZGVmaW5pbmcgc2VjdXJpdHkgdG9r ZW4gdHlwZSB2YWx1ZXMgZm9yIE9BdXRoIDIuMCBhY2Nlc3MgdG9rZW5zIGFuZCByZWZyZXNoIHRv a2VucyDigJMgZW5hYmxpbmcgdGhlbSB0byBiZSB1c2VkIGFzIGlucHV0cyBhbmQgb3V0cHV0cyBp biBhbnkgb2YgdGhlIHRva2VuIGV4Y2hhbmdlcy4NCg0KRm9yIGluc3RhbmNlLCBieSB1c2luZyDi gJxhY2Nlc3MgdG9rZW7igJ0gYXMgdGhlIGlucHV0IHNlY3VyaXR5IHRva2VuIHR5cGUsIHByb3Zp ZGluZyBuZXcgc2NvcGUgdmFsdWVzLCBhbmQgdXNpbmcg4oCcYWNjZXNzIHRva2Vu4oCdIGFzIHRo ZSBvdXRwdXQgc2VjdXJpdHkgdG9rZW4gdHlwZSwgdG9rZW4gY2hhaW5pbmcgaXMgYWNoaWV2ZWQu DQoNCk5vdywgYSBxdWVzdGlvbiBmb3IgdGhlIHdvcmtpbmcgZ3JvdXDigKYgIFdoYXQgc2hvdWxk IHRoZSBzZWN1cml0eSB0b2tlbiB0eXBlIHZhbHVlcyBmb3IgYWNjZXNzIHRva2VuIGFuZCByZWZy ZXNoIHRva2VuIGJlPyAgVHdvIGRpZmZlcmVudCBjaG9pY2VzIHNlZW0gdG8gbWFrZSBzZW5zZS4N CigxKSAgVXNlIHRoZSB2YWx1ZXMg4oCcYWNjZXNzX3Rva2Vu4oCdIGFuZCDigJxyZWZyZXNoX3Rv a2Vu4oCdLCB3aGljaCBhcmUgdXNlZCBpbiBSRkMgNjc0OSB0b2tlbiByZXNwb25zZSB2YWx1ZXMu DQooMikgIERlZmluZSBuZXcgVVJOcyBmb3IgdGhpcyB1c2FnZSwgc3VjaCBhcyB1cm46aWV0Zjpw YXJhbXM6b2F1dGg6dG9rZW4tdHlwZTphY2Nlc3MtdG9rZW4gYW5kIHVybjppZXRmOnBhcmFtczpv YXV0aDp0b2tlbi10eXBlOnJlZnJlc2gtdG9rZW4uDQoNCknigJlkIHBlcnNvbmFsbHkgYmUgZmlu ZSBqdXN0IHVzaW5nIHRoZSBzaG9ydCBuYW1lcyBpbiAoMSkuDQoNCklmIHBlb3BsZSBhZ3JlZSB3 aXRoIHRoaXMgYXBwcm9hY2gsIHdlIGNhbiBkb2N1bWVudCB0aGlzIHVzYWdlIGluIHRoZSAtMDMg ZHJhZnQgYW5kIHB1Ymxpc2ggaXQgYXMgc29vbiBhcyB0aGUgc3VibWlzc2lvbiB0b29sIHJlb3Bl bnMgTW9uZGF5IG1vcm5pbmcgZHVyaW5nIElFVEYgOTMuDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZy b206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJy aWFuIENhbXBiZWxsDQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMjYsIDIwMTUgMzoxNSBQTQ0KVG86 IEp1c3RpbiBSaWNoZXINCkNjOiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3Jn Pj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFRva2VuIENoYWluaW5nIFVzZSBDYXNlDQoNClRo aXMga2luZCBvZiB0b2tlbiBleGNoYW5nZSBtaWdodCBpbnZvbHZlIGV4Y2hhbmdlcyBvdGhlciB0 aGFuIHN3YXBwaW5nIGFuIEFUIGZvciBhbm90aGVyIEFUIChhbmQgZG93bnNjb3BpbmcgaXQpLiBJ dCBtaWdodCBiZSBhbiBBVCBmb3IgYSBzdHJ1Y3R1cmVkIEpXVCBzcGVjaWZpY2FsbHkgdGFyZ2V0 ZWQgYXQgb25lIG9mIHRoZSB0aGUgcGFydGljdWxhciBzZXJ2aWNlcyB0aGF0IHRoZSBvcmlnaW5h bCBSUyBuZWVkcyB0byBjYWxsLiBPciBhbiBBVCBtaWdodCBiZSBleGNoYW5nZWQgZm9yIGEgU0FN TCBhc3NlcnRpb24gdG8gdXNlIHdpdGggbGVnYWN5IFNPQVAgc2VydmVyaWVzLiAgQSBnb29kIGdl bmVyYWwgdG9rZW4gZXhjaGFuZ2UgbWVjaGFuaXNtIGVuYWJsZXMgbG90cyBvZiB2YXJpYXRpb25z IG9mIGNhc2VzIGxpa2UgdGhlIG9uZSBKdXN0aW4gbWVudGlvbmVkLiBBbmQgbW9yZS4gSW4gZmFj dCwgSSB0aGluayBkb3duc2NvcGluZyBtaWdodCBiZSBhIG1pbm9yaXR5IHVzZSBjYXNlIHdoZXJl IHdoYXQgdG9rZW4gZXhjaGFuZ2UgaXMgb2Z0ZW4gbmVlZCBmb3IgaXMgdHJhbnNsYXRpbmcgdG9r ZW5zIGZyb20gd2hhdCB5b3UgaGF2ZSBpbnRvIHdoYXQgdGhlIHJlc291cmNlIHlvdSBuZWVkIHRv IGNhbGwgY2FuIGRlYWwgd2l0aC4NClRoZXJlIG5lZWQgdG8gYmUgd2F5cyBmb3IgdGhlIGNhbGxl ciB0byB0ZWxsIHRoZSBBUyBhYm91dCB0aGUgdG9rZW4gaXQncyBhc2tpbmcgZm9yIC0gYnkgdHlw ZSBvciBieSB0aGUgYWRkcmVzcy9pZGVudGlmaWVyIG9mIHdoZXJlIGl0J2xsIGJlIHVzZWQuIFRo ZXJlIG5lZWRzIHRvIGJlIHdheXMgZm9yIHRoZSBjYWxsZXIgdG8gYXV0aGVudGljYXRlIHRvIHRo ZSBBUy4gQW5kIHRoZXJlIG5lZWRzIHRvIGJlIHNvbWUgd2F5IG9mIGV4cHJlc3NpbmcgdGhpcyBk ZWxlZ2F0aW9uIHRoaW5nICh0aG91Z2ggSSdtIHN0aWxsIG5vdCB0b3RhbGx5IGNvbnZpbmNlZCBp dCBjb3VsZG4ndCBiZSBqdXN0IHRoZSB0b2tlbiBpcyBhYm91dCB0aGUgdXNlci9wcmluY2lwYWwg YW5kIHRoZSBjYWxsZXIvY2xpZW50IG9mIHRoZSBleGNoYW5nZSBpcyB3aG8gaXMgYmVpbmcgZGVs ZWdhdGVkIHRvKS4NCkkgcmVhbGl6ZSBmZXcgKGFwcHJvYWNoaW5nIHplcm8pIHBlb3BsZSBoYXZl IG9yIGFyZSBnb2luZyB0byByZWFkIGl0IGJ1dCBJIGhhdmUgZW5kZWF2b3JlZCB0byBjb3ZlciBh bGwgdGhlc2UgdGhpbmdzIGluIHRoZSBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1j YW1wYmVsbC1vYXV0aC1zdHMtMDIgZHJhZnQuIEl0J3MgYW4gZWFybHkgZHJhZnQgc28gbm90IHdp dGhvdXQgaXQgc29tZSByb3VnaCBlZGdlcyBidXQgY2FuIHByb3ZpZGUgc29tZSBndWlkYW5jZSBv biB3aGF0IGlzIG5lZWRlZCBhbmQgb2ZmZXJzIHNvbWUgcHJvdG9jb2wgc3ludGF4IGZvciBleHBy ZXNzaW5nIGl0LiBJIGJlbGlldmUgSnVzdGluJ3MgdXNlIGNhc2Ugd291bGQgYmUgY292ZXJlZCBi eSBpdCAoZGVmaW5pbmcgYSBzcGVjaWZpYyB0b2tlbiB0eXBlIFVSSSBmb3IgYW4gT0F1dGggYWNj ZXNzIHRva2VuIGlzc3VlZCBieSB0aGUgQVMgaW4gcXVlc3Rpb24gbWlnaHQgYmUgbmVlZGVkKSBh cyBhcmUgbWFueSBvdGhlcnMuDQoNCk9uIFRodSwgTWFyIDI2LCAyMDE1IGF0IDE6MzEgUE0sIEp1 c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4gd3Jv dGU6DQpBcyByZXF1ZXN0ZWQgYWZ0ZXIgbGFzdCBuaWdodOKAmXMgaW5mb3JtYWwgbWVldGluZywg aGVyZSBpcyB0aGUgdG9rZW4gY2hhaW5pbmcgdXNlIGNhc2UgdGhhdCBJIHdhbnQgdG8gc2VlIHJl cHJlc2VudGVkIGluIHRoZSB0b2tlbiBzd2FwIGRyYWZ0Lg0KDQoNClsgQ2xpZW50IF0gIC0+ICAg WyBBIF0gLT4gWyBCIF0gLT4gWyBDIF0NCg0KQW4gT0F1dGggY2xpZW50IGdldHMgYW4gYWNjZXNz IHRva2VuIEFUMSwganVzdCBsaWtlIGl0IGFsd2F5cyB3b3VsZCwgd2l0aCBzY29wZXMgW0EsIEIs IENdIGluIG9yZGVyIHRvIGNhbGwgc2VydmljZSBBLCB3aGljaCByZXF1aXJlcyBhbGwgdGhyZWUg c2NvcGVzLiBTZXJ2aWNlIEEgKGFuIFJTKSBhY2NlcHRzIHRoaXMgdG9rZW4gc2luY2UgaXQgaGFz IGl0cyBzY29wZSwgYW5kIHRoZW4gbmVlZHMgdG8gY2FsbCBzZXJ2aWNlIEIgaW4gdHVybiwgd2hp Y2ggcmVxdWlyZXMgc2NvcGVzIFtCLCBDXS4gSXQgY291bGQganVzdCByZS1zZW5kIHRoZSB0b2tl biBpdCBnb3QgaW4sIEFUMSwgYnV0IHRoYXQgd291bGQgZ2l2ZSB0aGUgZG93bnN0cmVhbSBSUyB0 aGUgYWJpbGl0eSB0byBjYWxsIHNlcnZpY2VzIHdpdGggc2NvcGUgWyBBIF0gYW5kIGl0IHNob3Vs ZCBub3QgYmUgYWxsb3dlZCB0byBkbyB0aGF0LiBUbyBsaW1pdCBleHBvc3VyZSwgc2VydmljZSBB IGNhbGxzIGEgdG9rZW4gc3dhcCBhdCB0aGUgQVMgdG8gY3JlYXRlIEFUMiB3aXRoIHNjb3BlcyBb IEIsIEMgXSwgZWZmZWN0aXZlbHkgYWN0aW5nIGFzIGFuIE9BdXRoIGNsaWVudCByZXF1ZXN0aW5n IGEgZG93bnNjb3BlZCB0b2tlbiBiYXNlZCBvbiBBVDEuIFNlcnZpY2UgQSB0aGVuIGFjdHMgYXMg YW4gT0F1dGggY2xpZW50IHRvIGNhbGwgc2VydmljZSBCLCBub3cgYWN0aW5nIGFzIGFuIFJTIHRv IHNlcnZpY2UgQeKAmXMgY2xpZW50LCBhbmQgY2FuIGZ1bGZpbGwgdGhlIHJlcXVlc3QuIEFuZCBp dOKAmXMgdHVydGxlcyBhbGwgdGhlIHdheSBkb3duOiBTZXJ2aWNlIEIgY2FuIGFsc28gY2FsbCBz ZXJ2aWNlIEMsIGFuZCBub3cgQiBhY3RzIGFzIGEgY2xpZW50LCByZXF1ZXN0aW5nIEFUMyB3aXRo IHNjb3BlIFsgQyBdIGJhc2VkIG9uIEFUMiwgYW5kIHNlbmRpbmcgQVQzIHRvIHNlcnZpY2UgQy4g VGhpcyBwcmV2ZW50cyBDIGZyb20gYmVpbmcgYWJsZSB0byBjYWxsIEIgb3IgQSwgYm90aCBvZiB3 aGljaCB3b3VsZCBoYXZlIGJlZW4gYXZhaWxhYmxlIGlmIEFUMSBoYWQgYmVlbiBwYXNzZWQgYXJv dW5kLiBOb3RlIHRoYXQgc2VydmljZSBBIG9yIHRoZSBDbGllbnQgY2FuIGFsc28gcmVxdWVzdCBh IGRvd25zY29wZWQgdG9rZW4gd2l0aCBbIEMgXSB0byBjYWxsIHNlcnZpY2UgQyBkaXJlY3RseSBh cyB3ZWxsLCBhbmQgQyBkb2VzbuKAmXQgaGF2ZSB0byBjYXJlIGhvdyBpdCBnb3QgdGhlcmUuDQoN Cg0KSW4gb3RoZXIgd29yZHMsIGl0IGxldHMgdGhlIGNsaWVudCBzb2Z0d2FyZSBiZSB2ZXJ5LCB2 ZXJ5IGR1bWIuIEl0IGRvZXNu4oCZdCBoYXZlIHRvIGRvIGFueSBzcGVjaWFsIHByb2Nlc3Npbmcs IGRvZXNu4oCZdCBoYXZlIHRvIGtub3cgd2hhdOKAmXMgaW4gdGhlIHRva2VuLCBpdCBqdXN0IGZv bGxvd3MgdGhlIHJlY2lwZSBvZiDigJxJIGdvdCBhIHRva2VuLCBJIGdldCBhbm90aGVyIHRva2Vu IGJhc2VkIG9uIHRoaXMgdG8gY2FsbCBzb21lb25lIGVsc2XigJ0uIEl04oCZcyBhbHNvIGFuYWxv Z291cyB0byB0aGUgcmVmcmVzaCB0b2tlbiBmbG93LCBidXQgd2l0aCBhY2Nlc3MgdG9rZW5zIGdv aW5nIGluIGFuZCBvdXQuIEnigJl2ZSBkZXBsb3llZCB0aGlzIHNldHVwIHNldmVyYWwgdGltZXMg aW4gZGlmZmVyZW50IHNlcnZpY2UgZGVwbG95bWVudHMuIEV2ZW4gdGhvdWdoIHRoZXJlIGlzIGEg cGVyZm9ybWFuY2UgaGl0IGluIHRoZSBhZGRpdGlvbmFsIHJvdW5kIHRyaXBzIChhcyBQaGlsIGJy b3VnaHQgdXAgaW4gYW5vdGhlciB0aHJlYWQpLCBpbiB0aGVzZSBjYXNlcyB0aGUgZGVzaXJlIHRv IGhhdmUgdGhlIHRva2VucyBob2xkIGxlYXN0IHByaXZpbGVnZSBhY2Nlc3MgcmlnaHRzIChzbWFs bGVzdCBzZXQgb2Ygc2NvcGVzIHBlciBzZXJ2aWNlKSBvdXR3ZWlnaGVkIGFueSBwZXJmb3JtYW5j ZSBoaXQgKHdoaWNoIHdhcyBzaG93biB0byBiZSByYXRoZXIgc21hbGwgaW4gcHJhY3RpY2UpLg0K DQpXaGF0IEkgd2FudCBpcyBmb3IgdGhlIHRva2VuIHN3YXAgZHJhZnQgdG8gZGVmaW5lIG9yIHVz ZSBhIG1lY2hhbmlzbSB0aGF0IGFsbG93cyB1cyB0byBkbyB0aGlzLiBJIHRoaW5rIHdlIGNhbiBk byB0aGF0IHByZXR0eSBlYXNpbHkgYnkgYWRqdXN0aW5nIHRoZSB0b2tlbiBzd2FwIHN5bnRheCBh bmQgbGFuZ3VhZ2UsIGFuZCBleHBsaWNpdGx5IGNhbGxpbmcgb3V0IHRoZSBzZW1hbnRpYyBwcm9j ZXNzaW5nIHBvcnRpb24gKHRoZSBjdXJyZW50IGNvcmUgb2YgdGhlIGRvY3VtZW50KSBmb3Igd2hh dCBpdCBpczogYSB3YXkgZm9yIGEgdG9rZW4gaXNzdWVyIHRvIGNvbW11bmljYXRlIHRvIGEgdG9r ZW4gc2VydmljZSBzcGVjaWZpYyBhY3Rpb25zLiBBdCBhIGhpZ2ggbGV2ZWwsIHRoZSBzcGVjIHdv dWxkIGJlIHNvbWV0aGluZyBsaWtlOg0KDQoNCg0KMS4gSG93IHRvIHN3YXAgYSB0b2tlbiBhdCBh biBBUw0KICAxLiBTZW5kIGEgcmVxdWVzdCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgd2l0aCBhIG5l dyBncmFudCB0eXBlLCBhbmQgYSB0b2tlbiAob2YgYW55IHR5cGUvZm9ybWF0L2ZsYXZvcikgb24g dGhlIHdheSBpbg0KICAyLiBHZXQgYmFjayBhIG5ldyB0b2tlbiBpbiBhIHRva2VuIHJlc3BvbnNl DQoyLiBDb21tdW5pY2F0aW5nIGFjdCBhcyAvIG9uIGJlaGFsZiBvZiBzZW1hbnRpY3MgdmlhIGEg SldUIGFzc2VydGlvbg0KICAxLiBIb3cgdG8gY3JlYXRlIChhcyBhbiBBUy9SUy9jbGllbnQvb3Ro ZXIgaXNzdWVyKSBhIEpXVCB3aXRoIGFjdC1hcyBzZW1hbnRpY3MNCiAgMi4gV2hhdCB0byBkbyAo YXMgYW4gQVMvUlMpIHdpdGggYSBKV1Qgd2l0aCBhY3QtYXMgc2VtYW50aWNzDQogIDMuIEhvdyB0 byBjcmVhdGUgYSBKV1Qgd2l0aCBvbi1iZWhhbGYtb2Ygc2VtZWFudGljcw0KICA0LiBXaGF0IHRv IGRvIHdpdGggYSBKV1Qgd2l0aCBvbi1iZWhhbGYtb2Ytc2VtYW50aWNzDQogIDUuIEhvdyB0byBw b3NzaWJseSByZXByZXNlbnQgdGhlc2Ugc2VtYW50aWNzIHdpdGggc29tZXRoaW5nIG90aGVyIHRo YW4gYSBKV1QNCg0KDQoNClNlY3Rpb24gMiB1c2VzIHRoZSBzeW50YXggZnJvbSBzZWN0aW9uIDEu IE90aGVyIGFwcGxpY2F0aW9ucywgbGlrZSB0aGUgb25lIEkgbGFpZCBvdXQgYWJvdmUsIGNhbiB1 c2UgdGhlIHN5bnRheCBmcm9tIHNlY3Rpb24gMSBhcyB3ZWxsLiBUaGlzIHdvcmtzIGZvciBzdHJ1 Y3R1cmVkLCB1bnN0cnVjdHVyZWQsIHNlbGYtZ2VuZXJhdGVkLCBjcm9zcy1kb21haW4sIHdpdGhp bi1kb21haW4sIGFuZCBvdGhlciB0b2tlbnMuDQoNCg0KIOKAlCBKdXN0aW4NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlz dA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0K --_000_BY2PR03MB4429DB920047BC96E894760F5910BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnR0DQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNv QWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgYWxsLiZuYnNwOyBBZnRlciByZWFkaW5nIEJyaWFu 4oCZcyBub3RlLCBoZSBhbmQgSSBzcG9rZSBvbiB0aGUgcGhvbmUgdG8gdHJ5IHRvIGNsZWFyIGEg ZmV3IHRoaW5ncyB1cCBhbmQgd29yayBvbiBhIGNvbGxhYm9yYXRpdmUgcGF0aCBmb3J3YXJkLiZu YnNwOyBIZXJl4oCZcyBzb21lIG9mIHdoYXQNCiB3ZSB0YWxrZWQgYWJvdXTigKY8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkZpcnN0LCBJ4oCZbSBzb3JyeSB0aGF0IEkgbWF5IGhhdmUgY29udHJpYnV0ZWQgdG8gdGhlIGlt cHJlc3Npb24gdGhhdCB0aGVyZeKAmXMgbGl0dGxlIHdpbGxpbmduZXNzIG9uIG15IHBhcnQgdG8g Y29uc2lkZXIgY2hhbmdlcyB0byB0aGUgZHJhZnQuJm5ic3A7IFRoYXTigJlzIG5vdCB0aGUNCiBj YXNlIGFuZCB0aGUgdHJ1dGggaXMgYWN0dWFsbHkgbXVjaCBzaW1wbGVyIHRoYW4gdGhhdOKApiAm bmJzcDtJ4oCZZCBiZWVuIHN1cGVyLWJ1c3kgZG9pbmcgb3RoZXIgdGhpbmdzLCBpbmNsdWRpbmcg ZmluaXNoaW5nIEpXVCwgSk9TRSwgT0F1dGggQXNzZXJ0aW9ucywgaGVscGluZyBkZXZlbG9wIGFu ZCBsYXVuY2ggdGhlDQo8YSBocmVmPSJodHRwOi8vb3BlbmlkLm5ldC9jZXJ0aWZpY2F0aW9uLyI+ T3BlbklEIENlcnRpZmljYXRpb24gcHJvZ3JhbTwvYT4sIGFuZCBzZXZlcmFsIG90aGVyIHZhbHVh YmxlIHRoaW5ncywgYW5kIEkgc2ltcGx5IGhhZG7igJl0IGdpdmVuIHRva2VuIGV4Y2hhbmdlIGFu eSBzaWduaWZpY2FudCBiYW5kd2lkdGggZm9yIGEgd2hpbGUgYXMgYSByZXN1bHQuJm5ic3A7IE5v dyB0aGF0IG1hbnkgb2YgdGhvc2UgdGhpbmdzIGFyZSBkb25lLCBJIGRvIGhhdmUgYmFuZHdpZHRo DQogdG8gd29yayBvbiBpdCBub3cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PbmUgY29uY3JldGUgdGhpbmcgQnJpYW4g YW5kIEkgYWdyZWVkIHRvIGRvIGFzIGEgbmV4dCBzdGVwIGlzIHRvIHdvcmsgb24gYSBsaXN0IG9m IGlzc3VlcyBhbmQgY2hvaWNlcyBmb3IgdGhlIHdvcmtpbmcgZ3JvdXAgdG8gY29uc2lkZXIgdG9n ZXRoZXIsIHdoaWNoIHdl4oCZbGwNCiBqb2ludGx5IHByZXNlbnQgaW4gUHJhZ3VlLiZuYnNwOyBI b3BlZnVsbHkgdGhhdCB3aWxsIGhlbHAgcmVkdWNlIHNvbWUgb2YgdGhlIGNvbmZ1c2lvbiBhbmQg cmVwbGFjZSBpdCB3aXRoIGEgY2xlYXIgYW4gYWN0aW9uYWJsZSBlbmdpbmVlcmluZyBhbmFseXNp cyBvZiB0aGUgb3B0aW9ucyBhdmFpbGFibGUgdG8gdXMuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGtub3cgd2UgYm90 aCBzaGFyZSB0aGUgZ29hbCBvZiBrZWVwaW5nIHRoaW5ncyBhcyBzaW1wbGUgYW5kIGVmZmljaWVu dCBhcyBwb3NzaWJsZSwgd2hpbGUgZW5hYmxpbmcgc3VwcG9ydCBmb3IgdGhlIHRva2VuIGV4Y2hh bmdlIHVzZSBjYXNlcyB0aGF0IGRpZmZlcmVudA0KIGFwcGxpY2F0aW9ucyBhY3R1YWxseSBuZWVk LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+T25lIG90aGVyIHRoaW5nIHRoYXQgd2UgYm90aCB0aGluayB3b3VsZCBoZWxw IHBlb3BsZSBiZXR0ZXIgdW5kZXJzdGFuZCBhbmQgdXNlIHRoZSByZXN1bHRpbmcgc3BlYyBpcyB0 byBoYXZlIGEgbnVtYmVyIG9mIGNsZWFyLCBpbGx1c3RyYXRpdmUgZXhhbXBsZXMuJm5ic3A7IEZh Y2UNCiBpdCwgd2hhdGV2ZXIgeW91IGNhbGwgaXQgKGRlbGVnYXRpb24sIGltcGVyc29uYXRpb24s IG9uLWJlaGFsZi1vZiwgYWN0LWFzLCBldGMuKSwgc29tZSBvZiB0aGUgY29uY2VwdHMgYXJlIHN1 YnRsZSwgYW5kIHNvIHRoZSBtb3JlIHdlIGNhbiBzaGVkIGxpZ2h0IG9uIHRoZW0gdGhyb3VnaCBj b25jcmV0ZSBleGFtcGxlcywgdGhlIGVhc2llciBJIHN1c3BlY3QgdGhhdCB3ZSBjYW4gbWFrZSBp dCBmb3IgcGVvcGxlIHRvIGJvdGggdW5kZXJzdGFuZCB3aGF0DQogdGhleSBhcmUgYW5kIGhvdyB0 aGV5IGFwcGx5IHRvIHRoZWlyIHVzZSBjYXNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPknigJltIGxvb2tpbmcgZm9y d2FyZCB0byBzZWVpbmcgbWFueSBvZiB5b3UgaW4gUHJhZ3VlIHByZXR0eSBzb29uITxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEJyaWFuIENhbXBiZWxsIFttYWlsdG86 YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5 LCBKdWx5IDA4LCAyMDE1IDEyOjMzIFBNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVzPGJyPg0K PGI+Q2M6PC9iPiBKdXN0aW4gUmljaGVyOyAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFRva2VuIENoYWluaW5nIFVzZSBDYXNlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+VGhlcmUgaXMgYSBsb3QgaW4gY29tbW9uLCB5ZXMuIEZ1bmRhbWVudGFsbHkg d2UncmUgd29ya2luZyB0byBhZGRyZXNzIHRoZSBzYW1lIG5lZWRzLCB3aGljaCBzaG91bGQgbGVh ZCB0byBzb21lIGNvbW1vbmFsaXR5LiBCdXQgSSB3YXMgYWxzbyB0cnlpbmcgdG8gYmUgY29uY2ls aWF0b3J5IGluIHRoZSB3b3JrIEkgZGlkIGFuZCBtYWtlIGEgZ29vZCBmYWl0aCBlZmZvcnQNCiBh dCBlc3RhYmxpc2hpbmcgc29tZSBjb21tb25hbGl0eSBmcm9tIHdoaWNoIGNvbGxhYm9yYXRpdmUg d29yayBjb3VsZCBtb3ZlIGZvcndhcmQuIEluIHJldHJvc3BlY3QgSSBzaG91bGQgcHJvYmFibHkg aGF2ZSBqdXN0IG91dHJpZ2h0IG9wcG9zZWQgdGhlIGFkb3B0aW9uIG9mIGRyYWZ0LWpvbmVzLW9h dXRoLXRva2VuLWV4Y2hhbmdlIGFzIGEgV0cgaXRlbS4gSSB0aG91Z2h0IHRyeWluZyB0byB3b3Jr IHdpdGggeW91IHdvdWxkIGJlIG1vcmUgZWZmZWN0aXZlDQogdGhhbiB3b3JraW5nIGFnYWluc3Qg eW91LiBBdCB0aGUgdGltZSB5b3Ugc2VlbWVkIGFtZW5hYmxlIHRvIHRoYXQgYW5kIGV2ZW4gcHJv cG9zZWQgY28tZWRpdGluZyB3aXRoLiBIYW5uZXMgZm9sbG93ZWQgdGhhdCBpbmRpY2F0aW5nIHN1 cHBvcnQgZm9yIGFkZGluZyBvdGhlciBjby1hdXRob3JzIChoZSBkaWRuJ3Qgc2F5IGl0IGJ1dCBr aW5kIG9mIGltcGxpZWQgcGVyaGFwcyBKdXN0aW4gYW5kL29yIFBoaWwgYmFzZWQgb24gcHJpb3Ig cmVsYXRlZA0KIHdvcmspLiBTaW5jZSB0aGF0IHRpbWUsIGhvd2V2ZXIsIHRoZXJlJ3MgYmVlbiBs aXR0bGUgd2lsbGluZ25lc3MgdG8gY29uc2lkZXIgY2hhbmdlcyB0byB0aGUgZHJhZnQgKG90aGVy IHRoYW4gdmVyeSB0cml2aWFsIGl0ZW1zKS4gQW5kIFRvbnkgd2FzIGFkZGVkIGFzIGEgY28tYXV0 aG9yLCB3aGljaCB0byBtZSAoYW5kIEkgc3VzcGVjdCBtYW55IG90aGVycykgc2lnbmFscyBhIGNv bXBsZXRlIGxhY2sgb2Ygd2lsbGluZ25lc3MgdG8gYWN0dWFsbHkNCiBjb2xsYWJvcmF0ZSB0b3dh cmRzIGEgc29sdXRpb24gdGhhdCdzIGFjY2VwdGFibGUgdG8gbW9yZSB0aGFuIG9uZSBjb250aW5n ZW50LiA8bzpwPg0KPC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVy ZSBhcmUgZGlmZmVyZW5jZXMgaW4gdGhlIGRyYWZ0cyB0b28uIEkgd29uJ3QgbGlzdCB0aGVtIGFs bCBoZXJlIGJ1dCBkaWQgd2FudCB0byBjYWxsIG91dCB0aGF0LCBjb250cmFyeSB0byB3aGF0IHlv dSBzYWlkLCB0aGUgcmVxdWVzdCBpbiBteSBkcmFmdCBpcyBtYWRlIHVwIG9mIHJlZ3VsYXIgb2xk IEhUVFAgZm9ybS11cmxlbmNvZGVkIFBPU1QgcGFyYW1ldGVycy4gV2hpY2ggaXMgYSBzaW1wbGlm aWNhdGlvbg0KIGFuZCBlZmZpY2llbnRseSBpbXByb3ZlbWVudCB0aGF0IHNlZW1zIHRvIGJlIHBy ZWZlcnJlZC4mbmJzcDsgJm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gVHVlLCBKdWwgNywgMjAxNSBhdCA2OjQxIFBNLCBNaWtlIEpvbmVzICZs dDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9i bGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPknigJlsbCBzdGFydCBieSBzYXlpbmcgdGhh dCBpZiB5b3UgY29tcGFyZQ0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWNhbXBiZWxsLW9hdXRoLXN0cy0wMiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhbXBiZWxsLW9hdXRoLXN0cy0wMjwvYT4gYW5kIDxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4 Y2hhbmdlLTAyIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZS0wMjwvYT4sIHVuc3VycHJpc2luZ2x5LCB5 b3XigJlsbCBmaW5kIGEgbG90IGluIGNvbW1vbi4mbmJzcDsgQm90aCBoYXZlIHJlcXVlc3RzIGFu ZCByZXNwb25zZXMgZm9ybWF0dGVkIHVzaW5nIEpTT04gb2JqZWN0cywgYm90aCBoYXZlIGlucHV0 IGFuZCBvdXRwdXQgdG9rZW5zLCBib3RoIGhhdmUgc2VjdXJpdHkgdG9rZW4gdHlwZSBwYXJhbWV0 ZXJzIGRlc2NyaWJpbmcNCiB0aGVpciBjb3JyZXNwb25kaW5nIGlucHV0cyBhbmQgb3V0cHV0cy4m bmJzcDsgQm90aCBjYW4gY29udmV5IGFjdF9hcyBhbmQgb25fYmVoYWxmX29mIHRva2Vucy4mbmJz cDsgQW5kIGRlc3BpdGUgd2hhdCB3YXMgd3JpdHRlbiBiZWxvdywgYm90aCBkZWZpbmUgYSBuZXcg Z3JhbnRfdHlwZSB2YWx1ZSB0aGF0IGlzIHVzZWQgdG8gbWFrZSB0aGlzIG5ldyBraW5kIG9mIHJl cXVlc3QgYXQgdGhlIFRva2VuIEVuZHBvaW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBwcmltYXJ5IHRo aW5nIHRoYXQgQnJpYW7igJlzIGRyYWZ0IGlzIG1pc3Npbmcgc2VtYW50aWNhbGx5IGlzIHRoZSBh YmlsaXR5IGZvciB0aGUgcmVxdWVzdGVyIHRvDQogc2lnbiB0aGUgc2V0IG9mIGlucHV0IHBhcmFt ZXRlcnMuJm5ic3A7IFRoaXMgaXMgY3JpdGljYWwgdG8gZXN0YWJsaXNoaW5nIHByb3BlciB0cnVz dCB0byBlbmFibGUgdGhlIGV4Y2hhbmdlIHRvIG9jY3VyIGluIG1hbnkgdXNlIGNhc2VzLiZuYnNw OyBUaGF04oCZcyB3aHkgdGhlIFdHIGRyYWZ0IHVzZXMgYSBKV1QgYXMgdGhlIHJlcXVlc3Qg4oCT IHNvIGEgc2lnbmF0dXJlIGNhbiBiZSBhcHBsaWVkIHRvIHRoZSByZXF1ZXN0LCB3aGVuIGFwcHJv cHJpYXRlLiZuYnNwOyAoQW5kIHdoZW4NCiBpdOKAmXMgbm90IG5lZWRlZCwg4oCcYWxn4oCdOiDi gJxub25l4oCdIGNhbiBiZSB1c2VkLik8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5KdXN0aW4sIHlvdeKAmXJlIHJp Z2h0IHRoYXQgdGhlIGN1cnJlbnQgV0cgZHJhZnQgZG9lc27igJl0IGhhdmUgYSBzZXBhcmF0ZSDi gJxpbnB1dCB0b2tlbuKAnSByZXF1ZXN0IHBhcmFtZXRlci4mbmJzcDsNCiBJbiB0aGUgY3VycmVu dCBkcmFmdCwgdGhlIChvcHRpb25hbGx5KSBzaWduZWQgcmVxdWVzdCAqPGI+aXM8L2I+KiB0aGUg aW5wdXQgdG9rZW4uJm5ic3A7IFRoaW5raW5nIHNvbWUgbW9yZSBhYm91dCB0aGUgdG9rZW4gY2hh aW5pbmcgdXNlIGNhc2UgeW914oCZcmUgaW50ZXJlc3RlZCBpbiwgSSBzZWUgd2h5IHlvdSB3YW50 IHRvIGhhdmUgdGhhdCB0b2tlbiB0byBiZSBhIHNlcGFyYXRlIGVsZW1lbnQgaW4gdGhlIHJlcXVl c3QuJm5ic3A7IEkgYmVsaWV2ZSB0aGUgYmVzdA0KIHdheSB0byBhY2NvbXBsaXNoIHRoYXQgaXMg dG8gYWRkIGFuIG9wdGlvbmFsIGNsYWltIHRvIHRoZSByZXF1ZXN0IHRoYXQgd291bGQgY29udGFp biB0aGF0IHRva2VuLiZuYnNwOyAoSSB0aGluayB0aGUgY2xvc2VzdCBlcXVpdmFsZW50IGluIEJy aWFu4oCZcyBkcmFmdCBpcyB0aGUgcG9zc2liaWxpdHkgb2YgdXNpbmcgYW4gYWNjZXNzIHRva2Vu IG9yIGFzc2VydGlvbiBhcyB0aGUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSwgcG9z c2libHkgcGFzc2luZw0KIGl0IGFzIGRlZmluZWQgaW4gUkZDIDY3NTAsIGFsdGhvdWdoIHRoZSBk cmFmdCBkb2VzbuKAmXQgc2F5IHRoYXQuKSZuYnNwOyBQYXNzaW5nIHRoZSBpbnB1dCB0b2tlbiBh cyBhIGNsYWltIGxldHMgaXQgYmUgcGFydCBvZiB0aGUgc2lnbmVkIHJlcXVlc3QuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SXTigJlzIGNvbXBsZXRlbHkgdXAgdG8gdXMgd2hlbiB1c2luZyBhIGRpZmZlcmVudCBn cmFudF90eXBlIHRvIGRlZmluZSB3aGF0IHRoZSBpbnB1dCBhbmQgb3V0cHV0IHBhcmFtZXRlcnMN CiB3aGVuIHVzaW5nIHRoYXQgZ3JhbnRfdHlwZSBhcmUuJm5ic3A7IChSRkMgNjc0OSBhbHJlYWR5 IGhhcyBkaWZmZXJlbnQgc2V0cywgZGVwZW5kaW5nIHVwb24gdGhlIGdyYW50X3R5cGUgdXNlZC4p Jm5ic3A7IEkgcGVyc29uYWxseSBmaW5kIGl0IGNsZWFuZXIgdG8gcmV0dXJuIHRoZSBvdXRwdXQg c2VjdXJpdHkgdG9rZW4gdGhhdCBtYXkgbm90IGJlIGFuIGFjY2VzcyB0b2tlbiBpbiBhIOKAnHNl Y3VyaXR5X3Rva2Vu4oCdIHBhcmFtZXRlciByYXRoZXIgdGhhbiByZXB1cnBvc2luZw0KIHRoZSDi gJxhY2Nlc3NfdG9rZW7igJ0gcGFyYW1ldGVyIHRvIGhvbGQgc29tZXRoaW5nIHRoYXTigJlzIG5v dCBhbiBhY2Nlc3MgdG9rZW4sIGJ1dCBub3cgd2XigJlyZSBtb3JlIGRpc2N1c3Npbmcgc3ludGF4 IHRoYW4gc2VtYW50aWNzLiZuYnNwOyBTdGlsbCwgaWYgc29tZXRoaW5nIGlzIGRpZmZlcmVudCwg aXTigJlzIHByb2JhYmx5IGxlc3MgZXJyb3IgcHJvbmUgdG8gdXNlIGEgZGlmZmVyZW50IHN5bnRh eCBmb3IgaXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SeKAmW0gc3ltcGF0aGV0aWMgdG8geW91ciBjb21tZW50 IGFib3V0IE5hdOKAmXMgc2lnbmVkIHJlcXVlc3RzIGRyYWZ0LCBleGNlcHQgdGhhdCB0aGUgcmVx dWVzdHMgdGhhdA0KIGRyYWZ0IHNwZWNpZmllcyBhcmUgcmVxdWVzdHMgdG8gdGhlIGludGVyYWN0 aXZlIEF1dGhvcml6YXRpb24gRW5kcG9pbnQsIHdoZXJlYXMgdGhlIHJlcXVlc3RzIHdl4oCZcmUg ZGVhbGluZyB3aXRoIGhlcmUgYXJlIHJlcXVlc3RzIHRvIHRoZSBub24taW50ZXJhY3RpdmUgVG9r ZW4gRW5kcG9pbnQuJm5ic3A7IFN0aWxsLCB0aGlua2luZyBvZiB0aGUgVG9rZW4gRXhjaGFuZ2Ug cmVxdWVzdHMgYXMgc2lnbmVkIHJlcXVlc3RzIHRvIHRoZSBUb2tlbiBFbmRwb2ludCwNCiBqdXN0 IGxpa2UgTmF04oCZcyBkcmFmdCBtYWtlcyBzaWduZWQgcmVxdWVzdHMgdG8gdGhlIEF1dGhvcml6 YXRpb24gRW5kcG9pbnQsIGlzIHByb2JhYmx5IGEgZ29vZCB1bmlmeWluZyBtZW50YWwgZnJhbWV3 b3JrIGZvciBhbGwgb2YgdXMgdG8gY29uc2lkZXIgYXBwbHlpbmcgdG8gdGhpcyBwcm9ibGVtIHNw YWNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBC ZXN0IHdpc2hlcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBK dXN0aW4gUmljaGVyIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFy Z2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0LmVkdTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVl c2RheSwgSnVseSAwNywgMjAxNSA0OjQ3IFBNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVzPGJy Pg0KPGI+Q2M6PC9iPiBCcmlhbiBDYW1wYmVsbDsgJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPiZndDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBUb2tlbiBDaGFpbmluZyBVc2UgQ2FzZTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPlRoaXMgYXBwcm9hY2ggaXMgbm90IGEgZ29vZCBmaXQgZm9yIG15IHVzZSBj YXNlcywgYW5kIGl04oCZcyBzdGlsbCBub3QgJm5ic3A7T0F1dGgteSBhdCBhbGwuIEl0IHJlcXVp cmVzIGEgc3BlY2lhbGx5LWZvcm1lZCBzZWN1cml0eSBhc3NlcnRpb24gb24gdGhlIHdheSBpbiwg d2hpY2ggdGhlIGNsaWVudCBtdXN0IHVuZGVyc3RhbmQNCiBhbmQgZ2VuZXJhdGUuIEkgc3RpbGwg Y2Fu4oCZdCB0YWtlIGFuIGFyYml0cmFyeSB0b2tlbiBJ4oCZdmUgYmVlbiBoYW5kZWQgYnkgc29t ZW9uZSBlbHNlIGFuZCBwYXNzIGl0IG9mZiB0byBiZSBwdXNoZWQgZm9yd2FyZC4gVGhlIG5ldyDi gJwqX3R5cGXigJ0gcGFyYW1ldGVycyBzZWVtIHRvIG1lcmVseSBraWNrIHRoZSBjYW4gZG93biB0 aGUgcm9hZCBpbnN0ZWFkIG9mIGFkZHJlc3NpbmcgdGhlIHByb2JsZW1zIHdpdGggdGhlIGN1cnJl bnQgc3BlY2lmaWNhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+SSB0aGluayB0aGF0IEJyaWFu4oCZcyBhcHByb2FjaCB3b3JrcyBt dWNoIGJldHRlci4gSXQgdW5yb2xscyBpbXBvcnRhbnQgcGFyYW1ldGVycywgcHJvcGVybHkgdXNl cyB0aGUgdG9rZW4gZW5kcG9pbnQsIGFuZCBhbGxvd3MgZm9yIGFyYml0cmFyaWx5IGZvcm1hdHRl ZCBpbnB1dCB0b2tlbnMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5XaGVuIGNvbWJpbmVkIHdpdGggTmF04oCZcyBkcmFmdCB0 aGF0IHNwZWNpZmllcyBob3cgdG8gcGVyZm9ybSBhbGwgZ2VuZXJpYyBPQXV0aCByZXF1ZXN0cyBh cyBKV1RzIChvciBldmVuIHNvbWUgb2YgdGhlIHVwY29taW5nIFBvUCB3b3JrIGlmIHdlIGV2ZXIg ZG8gdGhhdCksIHlvdeKAmXZlIHByZXR0eSBtdWNoIGdvdA0KIHRoZSBkcmFmdCBiZWxvdyBidXQg d2l0aCBtdWNoIG1vcmUgZmxleGliaWxpdHkgYW5kIHBvd2VyLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A74oCUIEp1 c3RpbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPk9uIEp1bCA3LCAyMDE1LCBhdCA2OjUxIFBNLCBNaWtlIEpvbmVzICZsdDs8YSBocmVm PSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvLz9wPTE0 MTIiIHRhcmdldD0iX2JsYW5rIj5BcyBqdXN0IHVwZGF0ZWQ8L2E+LCBJIGJlbGlldmUgdGhhdCB0 aGUNCiB3b3JraW5nIGdyb3VwIHRva2VuIGV4Y2hhbmdlIGRyYWZ0IDxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTAyIiB0 YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1v YXV0aC10b2tlbi1leGNoYW5nZS0wMjwvYT4gY2FuIG5vdyBhbHNvIHNlcnZlIHRoZSDigJxPQXV0 aHnigJ0gdG9rZW4gZXhjaGFuZ2UgdXNlIGNhc2VzLCBzdWNoIGFzIEp1c3RpbiBhbmQgUGhpbOKA mXMgdG9rZW4gY2hhaW5pbmcgdXNlIGNhc2UsIGFzIHdlbGwgYXMgc3VwcG9ydCBnZW5lcmFsIHRv a2VuIGV4Y2hhbmdlLCBpbmNsdWRpbmcgZXhjaGFuZ2Ugb2YgSldUIGFuZCBTQU1MIHRva2Vucy4m bmJzcDsNCiBUaGUgbWVjaGFuaXNtIHdvdWxkIGJlIHRoZSBzYW1lIG9uZSB0aGF0IEJyaWFuIHN1 Z2dlc3RlZCBiZWxvdyDigJMgZGVmaW5pbmcgc2VjdXJpdHkgdG9rZW4gdHlwZSB2YWx1ZXMgZm9y IE9BdXRoIDIuMCBhY2Nlc3MgdG9rZW5zIGFuZCByZWZyZXNoIHRva2VucyDigJMgZW5hYmxpbmcg dGhlbSB0byBiZSB1c2VkIGFzIGlucHV0cyBhbmQgb3V0cHV0cyBpbiBhbnkgb2YgdGhlIHRva2Vu IGV4Y2hhbmdlcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Gb3IgaW5zdGFuY2UsIGJ5IHVzaW5nIOKAnGFjY2Vz cyB0b2tlbuKAnSBhcyB0aGUgaW5wdXQgc2VjdXJpdHkgdG9rZW4gdHlwZSwgcHJvdmlkaW5nIG5l dyBzY29wZSB2YWx1ZXMsDQogYW5kIHVzaW5nIOKAnGFjY2VzcyB0b2tlbuKAnSBhcyB0aGUgb3V0 cHV0IHNlY3VyaXR5IHRva2VuIHR5cGUsIHRva2VuIGNoYWluaW5nIGlzIGFjaGlldmVkLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPk5vdywgYSBxdWVzdGlvbiBmb3IgdGhlIHdvcmtpbmcgZ3JvdXDigKYmbmJzcDsg V2hhdCBzaG91bGQgdGhlIHNlY3VyaXR5IHRva2VuIHR5cGUgdmFsdWVzIGZvciBhY2Nlc3MgdG9r ZW4NCiBhbmQgcmVmcmVzaCB0b2tlbiBiZT8mbmJzcDsgVHdvIGRpZmZlcmVudCBjaG9pY2VzIHNl ZW0gdG8gbWFrZSBzZW5zZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4oMSkmbmJz cDsgVXNlIHRoZSB2YWx1ZXMg4oCcYWNjZXNzX3Rva2Vu4oCdIGFuZCDigJxyZWZyZXNoX3Rva2Vu 4oCdLCB3aGljaCBhcmUgdXNlZCBpbiBSRkMgNjc0OSB0b2tlbiByZXNwb25zZQ0KIHZhbHVlcy48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4oMikmbmJzcDsgRGVmaW5lIG5ldyBVUk5z IGZvciB0aGlzIHVzYWdlLCBzdWNoIGFzDQo8L3NwYW4+PHR0PjxzcGFuIGxhbmc9IkVOIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+dXJuOmlldGY6cGFyYW1zOm9hdXRoOnRva2VuLXR5cGU6YWNj ZXNzLXRva2VuPC9zcGFuPjwvdHQ+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+YW5kDQo8L3NwYW4+PHR0PjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+dXJuOmlldGY6cGFyYW1zOm9hdXRoOnRva2VuLXR5cGU6cmVmcmVzaC10b2tl bjwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4u PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SeKAmWQgcGVyc29uYWxseSBiZSBmaW5lIGp1c3QgdXNpbmcgdGhlIHNo b3J0IG5hbWVzIGluICgxKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiBwZW9wbGUgYWdyZWUgd2l0aCB0aGlz IGFwcHJvYWNoLCB3ZSBjYW4gZG9jdW1lbnQgdGhpcyB1c2FnZSBpbiB0aGUgLTAzIGRyYWZ0IGFu ZCBwdWJsaXNoIGl0IGFzDQogc29vbiBhcyB0aGUgc3VibWlzc2lvbiB0b29sIHJlb3BlbnMgTW9u ZGF5IG1vcm5pbmcgZHVyaW5nIElFVEYgOTMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBPQXV0aCBbPGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwv YT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJyaWFuIENhbXBiZWxsPGJyPg0KPGI+U2VudDo8L2I+ IFRodXJzZGF5LCBNYXJjaCAyNiwgMjAxNSAzOjE1IFBNPGJyPg0KPGI+VG86PC9iPiBKdXN0aW4g UmljaGVyPGJyPg0KPGI+Q2M6PC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW09BVVRILVdHXSBUb2tlbiBDaGFpbmluZyBVc2UgQ2FzZTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPlRoaXMga2luZCBvZiB0b2tlbiBl eGNoYW5nZSBtaWdodCBpbnZvbHZlIGV4Y2hhbmdlcyBvdGhlciB0aGFuIHN3YXBwaW5nIGFuIEFU IGZvciBhbm90aGVyIEFUIChhbmQgZG93bnNjb3BpbmcgaXQpLiBJdCBtaWdodCBiZSBhbiBBVCBm b3IgYSBzdHJ1Y3R1cmVkIEpXVCBzcGVjaWZpY2FsbHkgdGFyZ2V0ZWQgYXQgb25lDQogb2YgdGhl IHRoZSBwYXJ0aWN1bGFyIHNlcnZpY2VzIHRoYXQgdGhlIG9yaWdpbmFsIFJTIG5lZWRzIHRvIGNh bGwuIE9yIGFuIEFUIG1pZ2h0IGJlIGV4Y2hhbmdlZCBmb3IgYSBTQU1MIGFzc2VydGlvbiB0byB1 c2Ugd2l0aCBsZWdhY3kgU09BUCBzZXJ2ZXJpZXMuJm5ic3A7IEEgZ29vZCBnZW5lcmFsIHRva2Vu IGV4Y2hhbmdlIG1lY2hhbmlzbSBlbmFibGVzIGxvdHMgb2YgdmFyaWF0aW9ucyBvZiBjYXNlcyBs aWtlIHRoZSBvbmUgSnVzdGluIG1lbnRpb25lZC4NCiBBbmQgbW9yZS4gSW4gZmFjdCwgSSB0aGlu ayBkb3duc2NvcGluZyBtaWdodCBiZSBhIG1pbm9yaXR5IHVzZSBjYXNlIHdoZXJlIHdoYXQgdG9r ZW4gZXhjaGFuZ2UgaXMgb2Z0ZW4gbmVlZCBmb3IgaXMgdHJhbnNsYXRpbmcgdG9rZW5zIGZyb20g d2hhdCB5b3UgaGF2ZSBpbnRvIHdoYXQgdGhlIHJlc291cmNlIHlvdSBuZWVkIHRvIGNhbGwgY2Fu IGRlYWwgd2l0aC4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPlRo ZXJlIG5lZWQgdG8gYmUgd2F5cyBmb3IgdGhlIGNhbGxlciB0byB0ZWxsIHRoZSBBUyBhYm91dCB0 aGUgdG9rZW4gaXQncyBhc2tpbmcgZm9yIC0gYnkgdHlwZSBvciBieSB0aGUgYWRkcmVzcy9pZGVu dGlmaWVyIG9mIHdoZXJlIGl0J2xsIGJlIHVzZWQuIFRoZXJlIG5lZWRzIHRvIGJlIHdheXMgZm9y IHRoZSBjYWxsZXINCiB0byBhdXRoZW50aWNhdGUgdG8gdGhlIEFTLiBBbmQgdGhlcmUgbmVlZHMg dG8gYmUgc29tZSB3YXkgb2YgZXhwcmVzc2luZyB0aGlzIGRlbGVnYXRpb24gdGhpbmcgKHRob3Vn aCBJJ20gc3RpbGwgbm90IHRvdGFsbHkgY29udmluY2VkIGl0IGNvdWxkbid0IGJlIGp1c3QgdGhl IHRva2VuIGlzIGFib3V0IHRoZSB1c2VyL3ByaW5jaXBhbCBhbmQgdGhlIGNhbGxlci9jbGllbnQg b2YgdGhlIGV4Y2hhbmdlIGlzIHdobyBpcyBiZWluZyBkZWxlZ2F0ZWQNCiB0bykuIDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgcmVhbGl6ZSBmZXcgKGFw cHJvYWNoaW5nIHplcm8pIHBlb3BsZSBoYXZlIG9yIGFyZSBnb2luZyB0byByZWFkIGl0IGJ1dCBJ IGhhdmUgZW5kZWF2b3JlZCB0byBjb3ZlciBhbGwgdGhlc2UgdGhpbmdzIGluIHRoZQ0KPGEgaHJl Zj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2FtcGJlbGwtb2F1dGgtc3RzLTAy IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW1w YmVsbC1vYXV0aC1zdHMtMDI8L2E+IGRyYWZ0LiBJdCdzIGFuIGVhcmx5IGRyYWZ0IHNvIG5vdCB3 aXRob3V0IGl0IHNvbWUgcm91Z2ggZWRnZXMgYnV0IGNhbiBwcm92aWRlIHNvbWUgZ3VpZGFuY2Ug b24gd2hhdCBpcyBuZWVkZWQgYW5kIG9mZmVycyBzb21lIHByb3RvY29sIHN5bnRheCBmb3IgZXhw cmVzc2luZyBpdC4gSSBiZWxpZXZlIEp1c3RpbidzIHVzZSBjYXNlIHdvdWxkIGJlDQogY292ZXJl ZCBieSBpdCAoZGVmaW5pbmcgYSBzcGVjaWZpYyB0b2tlbiB0eXBlIFVSSSBmb3IgYW4gT0F1dGgg YWNjZXNzIHRva2VuIGlzc3VlZCBieSB0aGUgQVMgaW4gcXVlc3Rpb24gbWlnaHQgYmUgbmVlZGVk KSBhcyBhcmUgbWFueSBvdGhlcnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+T24gVGh1LCBNYXIgMjYsIDIwMTUgYXQgMTozMSBQTSwgSnVzdGluIFJp Y2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsi PmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206 MTIuMHB0Ij5BcyByZXF1ZXN0ZWQgYWZ0ZXIgbGFzdCBuaWdodOKAmXMgaW5mb3JtYWwgbWVldGlu ZywgaGVyZSBpcyB0aGUgdG9rZW4gY2hhaW5pbmcgdXNlIGNhc2UgdGhhdCBJIHdhbnQgdG8gc2Vl IHJlcHJlc2VudGVkIGluIHRoZSB0b2tlbiBzd2FwIGRyYWZ0Ljxicj4NCjxicj4NCjxicj4NClsg Q2xpZW50IF0mbmJzcDsgLSZndDsmbmJzcDsgJm5ic3A7WyBBIF0gLSZndDsgWyBCIF0gLSZndDsg WyBDIF08YnI+DQo8YnI+DQpBbiBPQXV0aCBjbGllbnQgZ2V0cyBhbiBhY2Nlc3MgdG9rZW4gQVQx LCBqdXN0IGxpa2UgaXQgYWx3YXlzIHdvdWxkLCB3aXRoIHNjb3BlcyBbQSwgQiwgQ10gaW4gb3Jk ZXIgdG8gY2FsbCBzZXJ2aWNlIEEsIHdoaWNoIHJlcXVpcmVzIGFsbCB0aHJlZSBzY29wZXMuIFNl cnZpY2UgQSAoYW4gUlMpIGFjY2VwdHMgdGhpcyB0b2tlbiBzaW5jZSBpdCBoYXMgaXRzIHNjb3Bl LCBhbmQgdGhlbiBuZWVkcyB0byBjYWxsIHNlcnZpY2UgQiBpbiB0dXJuLCB3aGljaA0KIHJlcXVp cmVzIHNjb3BlcyBbQiwgQ10uIEl0IGNvdWxkIGp1c3QgcmUtc2VuZCB0aGUgdG9rZW4gaXQgZ290 IGluLCBBVDEsIGJ1dCB0aGF0IHdvdWxkIGdpdmUgdGhlIGRvd25zdHJlYW0gUlMgdGhlIGFiaWxp dHkgdG8gY2FsbCBzZXJ2aWNlcyB3aXRoIHNjb3BlIFsgQSBdIGFuZCBpdCBzaG91bGQgbm90IGJl IGFsbG93ZWQgdG8gZG8gdGhhdC4gVG8gbGltaXQgZXhwb3N1cmUsIHNlcnZpY2UgQSBjYWxscyBh IHRva2VuIHN3YXAgYXQgdGhlIEFTIHRvDQogY3JlYXRlIEFUMiB3aXRoIHNjb3BlcyBbIEIsIEMg XSwgZWZmZWN0aXZlbHkgYWN0aW5nIGFzIGFuIE9BdXRoIGNsaWVudCByZXF1ZXN0aW5nIGEgZG93 bnNjb3BlZCB0b2tlbiBiYXNlZCBvbiBBVDEuIFNlcnZpY2UgQSB0aGVuIGFjdHMgYXMgYW4gT0F1 dGggY2xpZW50IHRvIGNhbGwgc2VydmljZSBCLCBub3cgYWN0aW5nIGFzIGFuIFJTIHRvIHNlcnZp Y2UgQeKAmXMgY2xpZW50LCBhbmQgY2FuIGZ1bGZpbGwgdGhlIHJlcXVlc3QuIEFuZCBpdOKAmXMg dHVydGxlcw0KIGFsbCB0aGUgd2F5IGRvd246IFNlcnZpY2UgQiBjYW4gYWxzbyBjYWxsIHNlcnZp Y2UgQywgYW5kIG5vdyBCIGFjdHMgYXMgYSBjbGllbnQsIHJlcXVlc3RpbmcgQVQzIHdpdGggc2Nv cGUgWyBDIF0gYmFzZWQgb24gQVQyLCBhbmQgc2VuZGluZyBBVDMgdG8gc2VydmljZSBDLiBUaGlz IHByZXZlbnRzIEMgZnJvbSBiZWluZyBhYmxlIHRvIGNhbGwgQiBvciBBLCBib3RoIG9mIHdoaWNo IHdvdWxkIGhhdmUgYmVlbiBhdmFpbGFibGUgaWYgQVQxIGhhZA0KIGJlZW4gcGFzc2VkIGFyb3Vu ZC4gTm90ZSB0aGF0IHNlcnZpY2UgQSBvciB0aGUgQ2xpZW50IGNhbiBhbHNvIHJlcXVlc3QgYSBk b3duc2NvcGVkIHRva2VuIHdpdGggWyBDIF0gdG8gY2FsbCBzZXJ2aWNlIEMgZGlyZWN0bHkgYXMg d2VsbCwgYW5kIEMgZG9lc27igJl0IGhhdmUgdG8gY2FyZSBob3cgaXQgZ290IHRoZXJlLjxicj4N Cjxicj4NCjxicj4NCkluIG90aGVyIHdvcmRzLCBpdCBsZXRzIHRoZSBjbGllbnQgc29mdHdhcmUg YmUgdmVyeSwgdmVyeSBkdW1iLiBJdCBkb2VzbuKAmXQgaGF2ZSB0byBkbyBhbnkgc3BlY2lhbCBw cm9jZXNzaW5nLCBkb2VzbuKAmXQgaGF2ZSB0byBrbm93IHdoYXTigJlzIGluIHRoZSB0b2tlbiwg aXQganVzdCBmb2xsb3dzIHRoZSByZWNpcGUgb2Yg4oCcSSBnb3QgYSB0b2tlbiwgSSBnZXQgYW5v dGhlciB0b2tlbiBiYXNlZCBvbiB0aGlzIHRvIGNhbGwgc29tZW9uZSBlbHNl4oCdLiBJdOKAmXMN CiBhbHNvIGFuYWxvZ291cyB0byB0aGUgcmVmcmVzaCB0b2tlbiBmbG93LCBidXQgd2l0aCBhY2Nl c3MgdG9rZW5zIGdvaW5nIGluIGFuZCBvdXQuIEnigJl2ZSBkZXBsb3llZCB0aGlzIHNldHVwIHNl dmVyYWwgdGltZXMgaW4gZGlmZmVyZW50IHNlcnZpY2UgZGVwbG95bWVudHMuIEV2ZW4gdGhvdWdo IHRoZXJlIGlzIGEgcGVyZm9ybWFuY2UgaGl0IGluIHRoZSBhZGRpdGlvbmFsIHJvdW5kIHRyaXBz IChhcyBQaGlsIGJyb3VnaHQgdXAgaW4gYW5vdGhlcg0KIHRocmVhZCksIGluIHRoZXNlIGNhc2Vz IHRoZSBkZXNpcmUgdG8gaGF2ZSB0aGUgdG9rZW5zIGhvbGQgbGVhc3QgcHJpdmlsZWdlIGFjY2Vz cyByaWdodHMgKHNtYWxsZXN0IHNldCBvZiBzY29wZXMgcGVyIHNlcnZpY2UpIG91dHdlaWdoZWQg YW55IHBlcmZvcm1hbmNlIGhpdCAod2hpY2ggd2FzIHNob3duIHRvIGJlIHJhdGhlciBzbWFsbCBp biBwcmFjdGljZSkuPGJyPg0KPGJyPg0KV2hhdCBJIHdhbnQgaXMgZm9yIHRoZSB0b2tlbiBzd2Fw IGRyYWZ0IHRvIGRlZmluZSBvciB1c2UgYSBtZWNoYW5pc20gdGhhdCBhbGxvd3MgdXMgdG8gZG8g dGhpcy4gSSB0aGluayB3ZSBjYW4gZG8gdGhhdCBwcmV0dHkgZWFzaWx5IGJ5IGFkanVzdGluZyB0 aGUgdG9rZW4gc3dhcCBzeW50YXggYW5kIGxhbmd1YWdlLCBhbmQgZXhwbGljaXRseSBjYWxsaW5n IG91dCB0aGUgc2VtYW50aWMgcHJvY2Vzc2luZyBwb3J0aW9uICh0aGUgY3VycmVudCBjb3JlDQog b2YgdGhlIGRvY3VtZW50KSBmb3Igd2hhdCBpdCBpczogYSB3YXkgZm9yIGEgdG9rZW4gaXNzdWVy IHRvIGNvbW11bmljYXRlIHRvIGEgdG9rZW4gc2VydmljZSBzcGVjaWZpYyBhY3Rpb25zLiBBdCBh IGhpZ2ggbGV2ZWwsIHRoZSBzcGVjIHdvdWxkIGJlIHNvbWV0aGluZyBsaWtlOjxicj4NCjxicj4N Cjxicj4NCjxicj4NCjEuIEhvdyB0byBzd2FwIGEgdG9rZW4gYXQgYW4gQVM8YnI+DQombmJzcDsg MS4gU2VuZCBhIHJlcXVlc3QgdG8gdGhlIHRva2VuIGVuZHBvaW50IHdpdGggYSBuZXcgZ3JhbnQg dHlwZSwgYW5kIGEgdG9rZW4gKG9mIGFueSB0eXBlL2Zvcm1hdC9mbGF2b3IpIG9uIHRoZSB3YXkg aW48YnI+DQombmJzcDsgMi4gR2V0IGJhY2sgYSBuZXcgdG9rZW4gaW4gYSB0b2tlbiByZXNwb25z ZTxicj4NCjIuIENvbW11bmljYXRpbmcgYWN0IGFzIC8gb24gYmVoYWxmIG9mIHNlbWFudGljcyB2 aWEgYSBKV1QgYXNzZXJ0aW9uPGJyPg0KJm5ic3A7IDEuIEhvdyB0byBjcmVhdGUgKGFzIGFuIEFT L1JTL2NsaWVudC9vdGhlciBpc3N1ZXIpIGEgSldUIHdpdGggYWN0LWFzIHNlbWFudGljczxicj4N CiZuYnNwOyAyLiBXaGF0IHRvIGRvIChhcyBhbiBBUy9SUykgd2l0aCBhIEpXVCB3aXRoIGFjdC1h cyBzZW1hbnRpY3M8YnI+DQombmJzcDsgMy4gSG93IHRvIGNyZWF0ZSBhIEpXVCB3aXRoIG9uLWJl aGFsZi1vZiBzZW1lYW50aWNzPGJyPg0KJm5ic3A7IDQuIFdoYXQgdG8gZG8gd2l0aCBhIEpXVCB3 aXRoIG9uLWJlaGFsZi1vZi1zZW1hbnRpY3M8YnI+DQombmJzcDsgNS4gSG93IHRvIHBvc3NpYmx5 IHJlcHJlc2VudCB0aGVzZSBzZW1hbnRpY3Mgd2l0aCBzb21ldGhpbmcgb3RoZXIgdGhhbiBhIEpX VDxicj4NCjxicj4NCjxicj4NCjxicj4NClNlY3Rpb24gMiB1c2VzIHRoZSBzeW50YXggZnJvbSBz ZWN0aW9uIDEuIE90aGVyIGFwcGxpY2F0aW9ucywgbGlrZSB0aGUgb25lIEkgbGFpZCBvdXQgYWJv dmUsIGNhbiB1c2UgdGhlIHN5bnRheCBmcm9tIHNlY3Rpb24gMSBhcyB3ZWxsLiBUaGlzIHdvcmtz IGZvciBzdHJ1Y3R1cmVkLCB1bnN0cnVjdHVyZWQsIHNlbGYtZ2VuZXJhdGVkLCBjcm9zcy1kb21h aW4sIHdpdGhpbi1kb21haW4sIGFuZCBvdGhlciB0b2tlbnMuPGJyPg0KPHNwYW4gc3R5bGU9ImNv bG9yOiM4ODg4ODgiPjxicj4NCjxicj4NCiZuYnNwO+KAlCBKdXN0aW48YnI+DQo8L3NwYW4+PGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpP QXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BY2PR03MB4429DB920047BC96E894760F5910BY2PR03MB442namprd_-- From nobody Wed Jul 8 19:23:49 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8001D1A010E for ; Wed, 8 Jul 2015 19:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqbXHF27XpoF for ; Wed, 8 Jul 2015 19:23:46 -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 40EDB1A89EB for ; Wed, 8 Jul 2015 19:22:43 -0700 (PDT) Received: by qkhu186 with SMTP id u186so177398356qkh.0 for ; Wed, 08 Jul 2015 19:22: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:content-type; bh=zUCXfIP/IL95o84FIyqjwbGilExCwsR5blQckwjVYGI=; b=O1q3kh9DdeirOVewN27wuLxkslS+PNZnrglOMai20wxG0jf3AdBTwfBVo0DixqjqZ2 ZpJJ7P9gXWniryi5qsbjsFS/qSsLPfkseVmPgubZ8nH9QRquC25RBxniU3M3Ltt6M1RU JtBiUlU5H18hE9xhpBgpbMyZ61E9SnwdeZfG7cB6zlqQgjv+HNO2jMi0yGwtLZoa4QFh bK21tNwI9YOFAWm7lDveVGq4bmvnJqqNieotdVI1SUpQrXTzHIQRISYkEFFwmu7HZxUp /b1vbwdRiNbDKLsztncrdA5FhXLuqSWIiqX3KaCPDctusFL0XUvvS6NMG1GUAOBF4w/c ABZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=zUCXfIP/IL95o84FIyqjwbGilExCwsR5blQckwjVYGI=; b=ASEdnpIkfX0IWvtUrkrV8mAw00WZ+RtDqK8GhLkz8tlWHhrMX8X/G2eZqgaH5/xl4I 6Rx/BQeEG9rPSqeYIP/SQIDMG654q4hhjwLy+8AF23eqy+YCfd/YZJOL59MlRGtTIImC acf+wuGXcr3mADE1U3zB0YR5TEwCXP/bEzwsWN03apz0wKuLpXNGTgk68pBKVBBFvN8/ kGBWi74qQrWQmNAKsruEonqBftIYENmNhmCPnvyD+FYKxMgcNZmJ8Ev2IeEvt7CxgvGr MNmGnG65fNwBhqa5bl0pfckKGvyuhgMYjMDHmm5uuRwD5ha2U4uhQVFR+2cPbrKG3aaZ 8pYA== X-Gm-Message-State: ALoCoQmCleTntzU5OdFsfzzsTXZ0Zq7HvxvPh2Z0SCNYdw0JpqC60HQf+4FMqPExQXpE9twwF4gU X-Received: by 10.140.100.146 with SMTP id s18mr10712580qge.36.1436408562348; Wed, 08 Jul 2015 19:22:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.19.98 with HTTP; Wed, 8 Jul 2015 19:22:22 -0700 (PDT) In-Reply-To: References: <20150706230550.12450.15077.idtracker@ietfa.amsl.com> <68C4B3E0-0A40-4035-A6B8-EB553573BE5D@ve7jtb.com> From: William Denniss Date: Wed, 8 Jul 2015 19:22:22 -0700 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a1134e3941cada0051a67ee50 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-14.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 02:23:48 -0000 --001a1134e3941cada0051a67ee50 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Following up the discussion on today's NAPPS call, I understand why plain is not presented as the recommended approach in the spec (though it still has some value over not doing PKCE at all, in that it mitigates against the current known attack where a rogue app registers the same custom URI scheme as another), but I feel that after all the back and forth the picture is a little confusing. In particular, 4.2 and 4.4.1 include some examples where plain is supported= : 4.2 > Clients SHOULD use the S256 transformation. The plain transformation is > for compatibility with existing deployments and for constrained > environments that can't use the S256 transformation. > 4.4.1. > If the client is capable of using "S256", it MUST use "S256", as "S256" i= s > Mandatory To Implement (MTI) on the server. Clients are permitted to use > "plain" only if they cannot support "S256" for some technical reason and > knows that the server supports "plain". But then 7.2 is very vocal that it MUST NOT be used for new implementations= : 7.2 > Because of this, "plain" SHOULD NOT be used, and exists only > for compatibility with deployed implementations where the request path > is already protected. The "plain" method MUST NOT be used in > new implementations. What if those new implementations are constrained, as indicated in 4.2 and 4.4.1? Also, while S256 is clearly indicated as MTI, little is said about "plain", although it's alluded to that it's not MTI in 4.4.1 ("and knows that the server supports "plain""). Should we be more explicit upfront that "plain" is optional for servers to support, if that's the intention? On Tue, Jul 7, 2015 at 10:51 PM, William Denniss wrote: > t_m works for me, I just think we should have some indication that it's > the name of the transform. Will you also update where it is referenced in > the description below Figure 2? > > > > On Tue, Jul 7, 2015 at 6:28 PM, John Bradley wrote: > >> Thanks, I fixed my finger dyslexia for the next draft. >> >> I changed it to t_m rather than =E2=80=9Ct=E2=80=9D I think that is cle= arer. If I were >> to do it the other way XML2RFC would have double quotes in the text vers= ion. >> >> John B. >> >> On Jul 7, 2015, at 9:38 PM, William Denniss wrote: >> >> In version 14, there's a typo on this line ("deso") in Section 7.2: >> >> `"plain" method deso not protect` >> >> Also, in the 1.1 Protocol Flow diagram, regarding the text: >> >> `+ t(code_verifier), t` >> >> I wonder if it makes more sense to represent as `+ t(code_verifier), "t"= ` >> (note the quotes on the second 't') given that it's a string representat= ion >> of the method that's being sent? >> >> >> On Mon, Jul 6, 2015 at 4:05 PM, wrote: >> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Web Authorization Protocol Working >>> Group of the IETF. >>> >>> Title : Proof Key for Code Exchange by OAuth Public >>> Clients >>> Authors : Nat Sakimura >>> John Bradley >>> Naveen Agarwal >>> Filename : draft-ietf-oauth-spop-14.txt >>> Pages : 20 >>> Date : 2015-07-06 >>> >>> Abstract: >>> OAuth 2.0 public clients utilizing the Authorization Code Grant are >>> susceptible to the authorization code interception attack. This >>> specification describes the attack as well as a technique to mitigat= e >>> against the threat through the use of Proof Key for Code Exchange >>> (PKCE, pronounced "pixy"). >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ >>> >>> There's also a htmlized version available at: >>> https://tools.ietf.org/html/draft-ietf-oauth-spop-14 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-spop-14 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > --001a1134e3941cada0051a67ee50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Following up the discussion on = today's NAPPS call, I understand why plain is not presented as the reco= mmended approach in the spec (though it still has some value over not doing= PKCE at all, in that it mitigates against the current known attack where a= rogue app registers the same custom URI scheme as another), but I feel tha= t after all the back and forth the picture is a little confusing.

In= particular, 4.2 and 4.4.1 include some examples where plain is supported:<= br>
4.2
Clients SHO= ULD use the S256 transformation.=C2=A0 The plain transformation is for comp= atibility with existing deployments and for constrained environments that c= an't use the S256 transformation.
=C2= =A0
4.4.1.
If the client is capable of usin= g "S256", it MUST use "S256", as "S256" is Ma= ndatory To Implement (MTI) on the server.=C2=A0Clients are=C2=A0permitted t= o use "plain" only if they cannot support "S256" for so= me=C2=A0technical reason and knows that the server supports "plain&quo= t;.

But then 7.2 is very vocal that it MUST NOT be used for= new implementations:

7.2
Because of this, "= ;plain" SHOULD NOT be used, and exists only for=C2=A0compatibility wit= h deployed implementations where the request path is=C2=A0already protected= .=C2=A0 The "plain" method MUST NOT be used in new=C2=A0implement= ations.

=C2=A0What if those new implementations are constrained, as indica= ted in 4.2 and 4.4.1?


Also, while S256 i= s clearly indicated as MTI, little is said about "plain", althoug= h it's alluded to that it's not MTI in 4.4.1 ("and knows that = the server supports "plain"").

Should we be more explicit upfront = that "plain" is optional for servers to support, if that's th= e intention?


On Tue, Jul 7, 2015 at 10:51 PM= , William Denniss <wdenniss@google.com> wrote:
t_m works for me, I just think we should have som= e indication that it's the=C2=A0name=C2=A0of the transform. Will you al= so update where it is referenced in the description below Figure 2?


On Tue, Jul 7, 2015 at 6:28 PM= , John Bradley <ve7jtb@ve7jtb.com> wrote:
Thanks, I fixed my finger dyslexia fo= r the next draft.

I changed it to t_m rather than =E2=80= =9Ct=E2=80=9D =C2=A0I think that is clearer.=C2=A0 If I were to do it the o= ther way XML2RFC would have double quotes in the text version.
John B.=C2=A0

On Jul 7, 2015, at 9:38 PM, William Denniss <wdenniss@google.com> wrote:

=
In version 14, there's a typo on this line ("= ;deso") in Section 7.2:

`"plain" method deso not protect`
<= br>
Also, in the 1.1 Protocol Flow diagram, regarding the text:

`+ t(code_verifier), t`

I wonder if it makes more sense to rep= resent as `+ t(code_verifier), "t&= quot;` (note the quotes on the second 't') given that it'= ;s a string representation of the method that's being sent?


On Mon, Jul 6, 2015 at 4:05 PM, <internet-drafts@ietf.org>= ; wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Web Authorization Protocol Working G= roup of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Proof Key for Code Exchange by OAuth Public Clients
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Nat = Sakimura
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Bradley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Naveen Agarwal
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-spop-14.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 20
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-07-06

Abstract:
=C2=A0 =C2=A0OAuth 2.0 public clients utilizing the Authorization Code Gran= t are
=C2=A0 =C2=A0susceptible to the authorization code interception attack.=C2= =A0 This
=C2=A0 =C2=A0specification describes the attack as well as a technique to m= itigate
=C2=A0 =C2=A0against the threat through the use of Proof Key for Code Excha= nge
=C2=A0 =C2=A0(PKCE, pronounced "pixy").


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-o= auth-spop/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-spo= p-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-oauth-spop-14


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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


--001a1134e3941cada0051a67ee50-- From nobody Thu Jul 9 11:20:33 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB651B2B16 for ; Thu, 9 Jul 2015 11:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-2aerIbwGS9 for ; Thu, 9 Jul 2015 11:20:27 -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 9CF9B1A1BCD for ; Thu, 9 Jul 2015 11:20:27 -0700 (PDT) Received: by igrv9 with SMTP id v9so229782702igr.1 for ; Thu, 09 Jul 2015 11:20:27 -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:content-type; bh=ZKXFGUeEjTuEYSfLaLgpoe357E2LYgqNy8xyPw1LXHk=; b=PAtt0p9/8nJNM01fEoKiwTw0t35QlVskhlQzKuE6sZhF/zyH8/GalpTELfUQworb+o kNxT+XIbK2KqOBAmDd7jp5ficThW+9ERixN6p2xLWreBCpCd9bhYpMpzrJddxdi+DrsL C6351Z5ou0J3ausXEn9ad9NoOrldMVb7jQqp4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ZKXFGUeEjTuEYSfLaLgpoe357E2LYgqNy8xyPw1LXHk=; b=LUH8SAN0B8qV9MMmdXPXJaeTFkhoY9J7GgFjBbIIQmoQ0hESjISVOsWi//kuR5KsV2 HSXcdedbFSoAQaGQy5lK7SD1T789t+MgfLFF90iD4I87pbWByv1uHWSRIbvTRwMX52rw WUPmwTCvV+G1d0Nf2kUtRPd9NjJvmctThIAn8POmkkpdv4a/nl1iM36DWC4iewPmuZs0 VfN3JPq8dVaO4MMvrKvebdhpVLPVBlX9xXXQBmWcfpdSqSgdAX6JyvnXAtwYCxB/v6s9 owP88vKfkH2hDjVp4eXe5ZLhraaNJt2PMBNdbNWpZ9RCpd5UcQ8u3gW+xoGlGd8+4fku 0C8A== X-Gm-Message-State: ALoCoQlV3Lrvhj4oMKB6i/wlv5+dBt+onDL6/8oLAnMKe7iayQwRcag9YKqFdaPalzG+hgjecNmt X-Received: by 10.107.165.206 with SMTP id o197mr29586472ioe.2.1436466027008; Thu, 09 Jul 2015 11:20:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Thu, 9 Jul 2015 11:19:57 -0700 (PDT) In-Reply-To: References: <20150706230550.12450.15077.idtracker@ietfa.amsl.com> <68C4B3E0-0A40-4035-A6B8-EB553573BE5D@ve7jtb.com> From: Brian Campbell Date: Thu, 9 Jul 2015 12:19:57 -0600 Message-ID: To: William Denniss Content-Type: multipart/alternative; boundary=001a1141507445b5d0051a754fbc Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-14.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 18:20:31 -0000 --001a1141507445b5d0051a754fbc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with William that it's a little confusing. I get that there's a desire to discourage using "plain" but perhaps the language (especially the MUST NOT in 7.2) should be lightened up just a bit? On Wed, Jul 8, 2015 at 8:22 PM, William Denniss wrote= : > Following up the discussion on today's NAPPS call, I understand why plain > is not presented as the recommended approach in the spec (though it still > has some value over not doing PKCE at all, in that it mitigates against t= he > current known attack where a rogue app registers the same custom URI sche= me > as another), but I feel that after all the back and forth the picture is = a > little confusing. > > In particular, 4.2 and 4.4.1 include some examples where plain is > supported: > > 4.2 >> Clients SHOULD use the S256 transformation. The plain transformation is >> for compatibility with existing deployments and for constrained >> environments that can't use the S256 transformation. >> > > > 4.4.1. >> If the client is capable of using "S256", it MUST use "S256", as "S256" >> is Mandatory To Implement (MTI) on the server. Clients are permitted to = use >> "plain" only if they cannot support "S256" for some technical reason and >> knows that the server supports "plain". > > > But then 7.2 is very vocal that it MUST NOT be used for new > implementations: > > 7.2 >> Because of this, "plain" SHOULD NOT be used, and exists only >> for compatibility with deployed implementations where the request path >> is already protected. The "plain" method MUST NOT be used in >> new implementations. > > > What if those new implementations are constrained, as indicated in 4.2 > and 4.4.1? > > > Also, while S256 is clearly indicated as MTI, little is said about > "plain", although it's alluded to that it's not MTI in 4.4.1 ("and knows > that the server supports "plain""). > > Should we be more explicit upfront that "plain" is optional for servers t= o > support, if that's the intention? > > > On Tue, Jul 7, 2015 at 10:51 PM, William Denniss > wrote: > >> t_m works for me, I just think we should have some indication that it's >> the name of the transform. Will you also update where it is referenced i= n >> the description below Figure 2? >> >> >> >> On Tue, Jul 7, 2015 at 6:28 PM, John Bradley wrote: >> >>> Thanks, I fixed my finger dyslexia for the next draft. >>> >>> I changed it to t_m rather than =E2=80=9Ct=E2=80=9D I think that is cl= earer. If I were >>> to do it the other way XML2RFC would have double quotes in the text ver= sion. >>> >>> John B. >>> >>> On Jul 7, 2015, at 9:38 PM, William Denniss wrote= : >>> >>> In version 14, there's a typo on this line ("deso") in Section 7.2: >>> >>> `"plain" method deso not protect` >>> >>> Also, in the 1.1 Protocol Flow diagram, regarding the text: >>> >>> `+ t(code_verifier), t` >>> >>> I wonder if it makes more sense to represent as `+ t(code_verifier), "t= "` >>> (note the quotes on the second 't') given that it's a string representa= tion >>> of the method that's being sent? >>> >>> >>> On Mon, Jul 6, 2015 at 4:05 PM, wrote: >>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Web Authorization Protocol Working >>>> Group of the IETF. >>>> >>>> Title : Proof Key for Code Exchange by OAuth Public >>>> Clients >>>> Authors : Nat Sakimura >>>> John Bradley >>>> Naveen Agarwal >>>> Filename : draft-ietf-oauth-spop-14.txt >>>> Pages : 20 >>>> Date : 2015-07-06 >>>> >>>> Abstract: >>>> OAuth 2.0 public clients utilizing the Authorization Code Grant are >>>> susceptible to the authorization code interception attack. This >>>> specification describes the attack as well as a technique to mitiga= te >>>> against the threat through the use of Proof Key for Code Exchange >>>> (PKCE, pronounced "pixy"). >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ >>>> >>>> There's also a htmlized version available at: >>>> https://tools.ietf.org/html/draft-ietf-oauth-spop-14 >>>> >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-spop-14 >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@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 > > --001a1141507445b5d0051a754fbc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with William that it's a little confusing. I g= et that there's a desire to discourage using "plain" but perh= aps the language (especially the MUST NOT in 7.2) should be lightened up ju= st a bit?

On Wed, Jul 8, 2015 at 8:22 PM, William Denniss <wdenniss@google.com<= /a>> wrote:
Following up the discussion on today's NAPPS c= all, I understand why plain is not presented as the recommended approach in= the spec (though it still has some value over not doing PKCE at all, in th= at it mitigates against the current known attack where a rogue app register= s the same custom URI scheme as another), but I feel that after all the bac= k and forth the picture is a little confusing.

In particular, 4.2 an= d 4.4.1 include some examples where plain is supported:

4.2
Clients SHOULD use the S256 tr= ansformation.=C2=A0 The plain transformation is for compatibility with exis= ting deployments and for constrained environments that can't use the S2= 56 transformation.
=C2=A0
4.4.1.
If the client is capable of using "S256",= it MUST use "S256", as "S256" is Mandatory To Implemen= t (MTI) on the server.=C2=A0Clients are=C2=A0permitted to use "plain&q= uot; only if they cannot support "S256" for some=C2=A0technical r= eason and knows that the server supports "plain".
But then 7.2 is very vocal that it MUST NOT be used for new implementation= s:

7.2
Because of this, "plain" SHOULD= NOT be used, and exists only for=C2=A0compatibility with deployed implemen= tations where the request path is=C2=A0already protected.=C2=A0 The "p= lain" method MUST NOT be used in new=C2=A0implementations.

=C2=A0What= if those new implementations are constrained, as indicated in 4.2 and 4.4.= 1?


Also, while S256 is clearly indicated= as MTI, little is said about "plain", although it's alluded = to that it's not MTI in 4.4.1 ("and knows that the server supports= "plain"").

Should we be more explicit upfront that "plain&qu= ot; is optional for servers to support, if that's the intention?
<= div>


On Tue, Jul 7, 2015 at 10:5= 1 PM, William Denniss <wdenniss@google.com> wrote:
t_m works for me, I just think we should have= some indication that it's the=C2=A0name=C2=A0of the transform. Will yo= u also update where it is referenced in the description below Figure 2?


On Tue, Jul 7, 2015 at 6:28 PM, John Bradley <ve7= jtb@ve7jtb.com> wrote:
Thanks, I fixed my finger dyslexia for the next draft.
I changed it to t_m rather than =E2=80=9Ct=E2=80=9D =C2=A0= I think that is clearer.=C2=A0 If I were to do it the other way XML2RFC wou= ld have double quotes in the text version.

John B.= =C2=A0

On Jul 7, 2015, at = 9:38 PM, William Denniss <wdenniss@google.com> wrote:

In version 14, there's a typo on this line ("deso") in Sec= tion 7.2:

`"pla= in" method deso not protect`

Also,= in the 1.1 Protocol Flow diagram, regarding the text:

=
`+ t(code_verifier), t`

I wonder if it makes more sense to represent as `+ t(code_verifier), "t"` (not= e the quotes on the second 't') given that it's a string repres= entation of the method that's being sent?


<= /div>
On Mon, Jul 6, 2= 015 at 4:05 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Web Authorization Protocol Working G= roup of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Proof Key for Code Exchange by OAuth Public Clients
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Nat = Sakimura
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Bradley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Naveen Agarwal
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-spop-14.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 20
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-07-06

Abstract:
=C2=A0 =C2=A0OAuth 2.0 public clients utilizing the Authorization Code Gran= t are
=C2=A0 =C2=A0susceptible to the authorization code interception attack.=C2= =A0 This
=C2=A0 =C2=A0specification describes the attack as well as a technique to m= itigate
=C2=A0 =C2=A0against the threat through the use of Proof Key for Code Excha= nge
=C2=A0 =C2=A0(PKCE, pronounced "pixy").


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-o= auth-spop/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-spo= p-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-oauth-spop-14


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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



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


--001a1141507445b5d0051a754fbc-- From nobody Thu Jul 9 11:46:22 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC681B2AE2 for ; Thu, 9 Jul 2015 11:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apju9n-t6y0c for ; Thu, 9 Jul 2015 11:46:17 -0700 (PDT) Received: from mail-qk0-f175.google.com (mail-qk0-f175.google.com [209.85.220.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 825B11B2B3D for ; Thu, 9 Jul 2015 11:46:17 -0700 (PDT) Received: by qkcl188 with SMTP id l188so8709673qkc.1 for ; Thu, 09 Jul 2015 11:46:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=5RuxiA1BVSAYOUd5BHdJnPe8+TwHwiNKLOjbgmaojbs=; b=UHMtRXIVEok8WmP9inQAPaUcvbkMdfds3f7tuD57b6E1iGI/XUYnVjf+OXJvUSgM+b qVusxrNNO3QL/6EBaEqYj88iAHNlfEAC9UUjdt9h41o7PRQIplxJBkdfLVpysklUtgvh UUCCeLmzFCEw4TBxxCJDXkPqPIeC8+ev6HWS6r8t+VS9jj0n2lwmdUsXPkw/u+EuUb8V 3dvj5NFUDxUdxQzqW3XgIIAbemAmFat7uouMj0IyWbF+dqSsZwCpiL6FRhYHT0yErZm8 KItP1/PjRoeKIlh664B7KNmLPxobfdm0pHilYthEekcHy81PmfT3Rd5i+0h63KJiJGas lIkw== X-Gm-Message-State: ALoCoQkSRLkA8YrRvNj7qQVR7Dh53XWwToRkORa6IomDDEJyRDbB8AXrdFJ4IyP7qGAoJtdVYPV5 X-Received: by 10.140.90.99 with SMTP id w90mr26809657qgd.57.1436467576689; Thu, 09 Jul 2015 11:46:16 -0700 (PDT) Received: from [192.168.1.216] (181-163-49-185.baf.movistar.cl. [181.163.49.185]) by smtp.gmail.com with ESMTPSA id i7sm4145438qge.32.2015.07.09.11.46.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 Jul 2015 11:46:16 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_109C7D9A-874F-4DB6-910B-DF1CB0FBF509" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: John Bradley In-Reply-To: Date: Thu, 9 Jul 2015 15:46:00 -0300 Message-Id: <0A42C02A-77C6-48DD-8BEC-52B31570FBAF@ve7jtb.com> References: <20150706230550.12450.15077.idtracker@ietfa.amsl.com> <68C4B3E0-0A40-4035-A6B8-EB553573BE5D@ve7jtb.com> To: Brian Campbell X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-14.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 18:46:20 -0000 --Apple-Mail=_109C7D9A-874F-4DB6-910B-DF1CB0FBF509 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have made some edits to make it consistent. They are checked into the = butbucket repo nat and I use, but we can=E2=80=99t update the official = draft during the freeze before the IETF meeting. https://bitbucket.org/Nat/oauth-spop > On Jul 9, 2015, at 3:19 PM, Brian Campbell = wrote: >=20 > I agree with William that it's a little confusing. I get that there's = a desire to discourage using "plain" but perhaps the language = (especially the MUST NOT in 7.2) should be lightened up just a bit?=20 >=20 > On Wed, Jul 8, 2015 at 8:22 PM, William Denniss > wrote: > Following up the discussion on today's NAPPS call, I understand why = plain is not presented as the recommended approach in the spec (though = it still has some value over not doing PKCE at all, in that it mitigates = against the current known attack where a rogue app registers the same = custom URI scheme as another), but I feel that after all the back and = forth the picture is a little confusing. >=20 > In particular, 4.2 and 4.4.1 include some examples where plain is = supported: >=20 > 4.2 > Clients SHOULD use the S256 transformation. The plain transformation = is for compatibility with existing deployments and for constrained = environments that can't use the S256 transformation. > =20 > 4.4.1. > If the client is capable of using "S256", it MUST use "S256", as = "S256" is Mandatory To Implement (MTI) on the server. Clients are = permitted to use "plain" only if they cannot support "S256" for some = technical reason and knows that the server supports "plain". >=20 > But then 7.2 is very vocal that it MUST NOT be used for new = implementations: >=20 > 7.2 > Because of this, "plain" SHOULD NOT be used, and exists only for = compatibility with deployed implementations where the request path is = already protected. The "plain" method MUST NOT be used in new = implementations. >=20 > What if those new implementations are constrained, as indicated in = 4.2 and 4.4.1? >=20 >=20 > Also, while S256 is clearly indicated as MTI, little is said about = "plain", although it's alluded to that it's not MTI in 4.4.1 ("and knows = that the server supports "plain""). >=20 > Should we be more explicit upfront that "plain" is optional for = servers to support, if that's the intention? >=20 >=20 > On Tue, Jul 7, 2015 at 10:51 PM, William Denniss > wrote: > t_m works for me, I just think we should have some indication that = it's the name of the transform. Will you also update where it is = referenced in the description below Figure 2? >=20 >=20 >=20 > On Tue, Jul 7, 2015 at 6:28 PM, John Bradley > wrote: > Thanks, I fixed my finger dyslexia for the next draft. >=20 > I changed it to t_m rather than =E2=80=9Ct=E2=80=9D I think that is = clearer. If I were to do it the other way XML2RFC would have double = quotes in the text version. >=20 > John B.=20 >=20 >> On Jul 7, 2015, at 9:38 PM, William Denniss > wrote: >>=20 >> In version 14, there's a typo on this line ("deso") in Section 7.2: >>=20 >> `"plain" method deso not protect` >>=20 >> Also, in the 1.1 Protocol Flow diagram, regarding the text: >>=20 >> `+ t(code_verifier), t` >>=20 >> I wonder if it makes more sense to represent as `+ t(code_verifier), = "t"` (note the quotes on the second 't') given that it's a string = representation of the method that's being sent? >>=20 >>=20 >> On Mon, Jul 6, 2015 at 4:05 PM, > wrote: >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Web Authorization Protocol Working = Group of the IETF. >>=20 >> Title : Proof Key for Code Exchange by OAuth Public = Clients >> Authors : Nat Sakimura >> John Bradley >> Naveen Agarwal >> Filename : draft-ietf-oauth-spop-14.txt >> Pages : 20 >> Date : 2015-07-06 >>=20 >> Abstract: >> OAuth 2.0 public clients utilizing the Authorization Code Grant = are >> susceptible to the authorization code interception attack. This >> specification describes the attack as well as a technique to = mitigate >> against the threat through the use of Proof Key for Code Exchange >> (PKCE, pronounced "pixy"). >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ = >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-oauth-spop-14 = >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-spop-14 = >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org = . >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ = >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 --Apple-Mail=_109C7D9A-874F-4DB6-910B-DF1CB0FBF509 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I have made some edits to make it consistent.  They are = checked into the butbucket repo nat and I use, but we can=E2=80=99t = update the official draft during the freeze before the IETF meeting.

https://bitbucket.org/Nat/oauth-spop

On Jul 9, 2015, at 3:19 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

I agree with William that it's a little confusing. I get that = there's a desire to discourage using "plain" but perhaps the language = (especially the MUST NOT in 7.2) should be lightened up just a bit?

On Wed, Jul 8, 2015 at 8:22 PM, William Denniss = <wdenniss@google.com> = wrote:
Following up the discussion on = today's NAPPS call, I understand why plain is not presented as the = recommended approach in the spec (though it still has some value over = not doing PKCE at all, in that it mitigates against the current known = attack where a rogue app registers the same custom URI scheme as = another), but I feel that after all the back and forth the picture is a = little confusing.

In particular, 4.2 and = 4.4.1 include some examples where plain is supported:

4.2
Clients SHOULD use the = S256 transformation.  The plain transformation is for compatibility = with existing deployments and for constrained environments that can't = use the S256 transformation.
 
4.4.1.
If the client is = capable of using "S256", it MUST use "S256", as "S256" is Mandatory To = Implement (MTI) on the server. Clients are permitted to use = "plain" only if they cannot support "S256" for some technical = reason and knows that the server supports "plain".

But then 7.2 is very vocal that it MUST NOT be used for new = implementations:

7.2
Because of this, = "plain" SHOULD NOT be used, and exists only for compatibility with = deployed implementations where the request path is already = protected.  The "plain" method MUST NOT be used in = new implementations.

 What if those new = implementations are constrained, as indicated in 4.2 and 4.4.1?


Also, while S256 is clearly indicated as MTI, = little is said about "plain", although it's alluded to that it's not MTI = in 4.4.1 ("and knows that the server supports "plain"").

Should we be more explicit upfront that "plain" is = optional for servers to support, if that's the intention?


On Tue, Jul 7, 2015 at 10:51 PM, William Denniss = <wdenniss@google.com> = wrote:
t_m works for = me, I just think we should have some indication that it's = the name of the transform. Will you also update where it is = referenced in the description below Figure 2?



On Tue, Jul 7, 2015 at 6:28 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Thanks, I fixed my finger dyslexia for the next draft.

I changed it to t_m = rather than =E2=80=9Ct=E2=80=9D  I think that is clearer.  If = I were to do it the other way XML2RFC would have double quotes in the = text version.

John B. 

On Jul 7, 2015, at 9:38 PM, William Denniss <wdenniss@google.com> wrote:

In version 14, there's a typo on = this line ("deso") in Section 7.2:

`"plain" method deso not protect`

Also, in the 1.1 Protocol Flow diagram, regarding the = text:

`+ t(code_verifier), t`

I wonder if it makes more = sense to represent as `+ = t(code_verifier), "t"` (note the quotes on the second 't') given = that it's a string representation of the method that's being sent?


On = Mon, Jul 6, 2015 at 4:05 PM, <internet-drafts@ietf.org> wrote:

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

        Title          =  : Proof Key for Code Exchange by OAuth Public Clients
=         Authors         : = Nat Sakimura
                    =       John Bradley
                    =       Naveen Agarwal
        Filename        : = draft-ietf-oauth-spop-14.txt
        Pages          =  : 20
        Date          =   : 2015-07-06

Abstract:
   OAuth 2.0 public clients utilizing the Authorization Code = Grant are
   susceptible to the authorization code interception = attack.  This
   specification describes the attack as well as a technique = to mitigate
   against the threat through the use of Proof Key for Code = Exchange
   (PKCE, pronounced "pixy").


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-spop-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-spop-14


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
OAuth mailing list
OAuth@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=_109C7D9A-874F-4DB6-910B-DF1CB0FBF509-- From nobody Thu Jul 9 14:09:50 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202C31A0218 for ; Thu, 9 Jul 2015 14:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdp71p-GmZCI for ; Thu, 9 Jul 2015 14:09:47 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0112.outbound.protection.outlook.com [207.46.100.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 744421A01EA for ; Thu, 9 Jul 2015 14:09:47 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.219.9; Thu, 9 Jul 2015 21:09:46 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0213.000; Thu, 9 Jul 2015 21:09:40 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Proposed OAuth agenda items Thread-Index: AdC6i4wV0B3ZqNYvS4eon8vrnWriUw== Date: Thu, 9 Jul 2015 21:09: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; x-originating-ip: [2001:4898:80e8:ed31::3] x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:noXqkpgLceiTZBllGktNr0AZNCro81q50Lkvk5LSIxa42qpjR8FkyNzowFCYPbOFe21rmrab77ziA6qV+kDan6arEYrLoBa3jZqqVpnYXAmOmootgsJ4dyxlN+hWKFXX9FQX6azAH7yef7qEc49JHg==; 24:7GnyXvaXOqF7oWP24Mq/eJM6KtZiKJnMllJ0IGb0OuFthgDVpWwryY7vazwfJfJS7UaPn6jkAY/ym/Yc72rGykfbhwtkW6Schkw1RdP9zHA=; 20:7fmNx8hSBB6093m69vg2NURLRoC1/iAzBD71p5+Yp7x5ZL1C1m3hKh7lf51fYDKFU+qXhsmM8Wt9JYH5doXx/w== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB444; by2pr03mb444: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; x-forefront-prvs: 0632519F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(2501003)(5003600100002)(92566002)(122556002)(450100001)(2656002)(76576001)(62966003)(77156002)(5001960100002)(19300405004)(189998001)(46102003)(107886002)(110136002)(5002640100001)(2900100001)(15975445007)(102836002)(40100003)(77096005)(99286002)(33656002)(16236675004)(19625215002)(86612001)(87936001)(19580395003)(50986999)(54356999)(2351001)(74316001)(229853001)(86362001)(19609705001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442CDD755F6724A2ADF9974F5900BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2015 21:09:40.0164 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444 Archived-At: Subject: [OAUTH-WG] Proposed OAuth agenda items X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 21:09:49 -0000 --_000_BY2PR03MB442CDD755F6724A2ADF9974F5900BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd like to see us cover the following topics during our meeting in Prague.= .. Issues and Choices for Token Exchange, Brian Campbell and Mike Jones, 30 mi= nutes Next steps to complete the POP documents, 30 minutes?: draft-ietf-oauth-pop-key-distribution, John Bradley?, 15 mi= nutes? draft-ietf-oauth-pop-architecture, Phil Hunt?, 10 minutes? draft-ietf-oauth-proof-of-possession, Mike Jones, 5 minutes= (or less) And if the authors would like to talk about the status of jwsreq, signed-ht= tp-request, etc., I'd welcome that as well. I'm assuming that introspection and spop are far enough along we won't need= working group time for them? See you in = Prague! -- Mike --_000_BY2PR03MB442CDD755F6724A2ADF9974F5900BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’d like to see us cover the following topics = during our meeting in Prague…

 

Issues and Choices for Token Exchange, Brian Campbel= l and Mike Jones, 30 minutes

 

Next steps to complete the POP documents, 30 minutes= ?:

        &nbs= p;       draft-ietf-oauth-pop-key-distributio= n, John Bradley?, 15 minutes?

        &nbs= p;       draft-ietf-oauth-pop-architecture, P= hil Hunt?, 10 minutes?

        &nbs= p;       draft-ietf-oauth-proof-of-possession= , Mike Jones, 5 minutes (or less)

 

And if the authors would like to talk about the stat= us of jwsreq, signed-http-request, etc., I’d welcome that as well.

 

I’m assuming that introspection and spop are f= ar enough along we won’t need working group time for them?=

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     See you in Prague!

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

 

--_000_BY2PR03MB442CDD755F6724A2ADF9974F5900BY2PR03MB442namprd_-- From nobody Thu Jul 9 16:20:48 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64041A6F13; Thu, 9 Jul 2015 16:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaOnJFDqqa7f; Thu, 9 Jul 2015 16:20:45 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 640DC1A6F0E; Thu, 9 Jul 2015 16:20:45 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B1689180206; Thu, 9 Jul 2015 16:17:07 -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: <20150709231707.B1689180206@rfc-editor.org> Date: Thu, 9 Jul 2015 16:17:07 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, oauth@ietf.org, rfc-editor@rfc-editor.org Subject: [OAUTH-WG] RFC 7591 on OAuth 2.0 Dynamic Client Registration Protocol X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 23:20:46 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7591 Title: OAuth 2.0 Dynamic Client Registration Protocol Author: J. Richer, Ed., M. Jones, J. Bradley, M. Machulak, P. Hunt Status: Standards Track Stream: IETF Date: July 2015 Mailbox: ietf@justin.richer.org, mbj@microsoft.com, ve7jtb@ve7jtb.com, maciej.machulak@gmail.com, phil.hunt@yahoo.com Pages: 39 Characters: 87811 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-oauth-dyn-reg-30.txt URL: https://www.rfc-editor.org/info/rfc7591 DOI: http://dx.doi.org/10.17487/RFC7591 This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. 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/rfc.html 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 Thu Jul 9 16:21:03 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1637B1A6F0E; Thu, 9 Jul 2015 16:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqA6EHwkECdX; Thu, 9 Jul 2015 16:20:52 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 18CDF1A6F34; Thu, 9 Jul 2015 16:20:52 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 6527C180471; Thu, 9 Jul 2015 16:17:14 -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: <20150709231714.6527C180471@rfc-editor.org> Date: Thu, 9 Jul 2015 16:17:14 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, oauth@ietf.org, rfc-editor@rfc-editor.org Subject: [OAUTH-WG] RFC 7592 on OAuth 2.0 Dynamic Client Registration Management Protocol X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 23:20:58 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7592 Title: OAuth 2.0 Dynamic Client Registration Management Protocol Author: J. Richer, Ed., M. Jones, J. Bradley, M. Machulak Status: Experimental Stream: IETF Date: July 2015 Mailbox: ietf@justin.richer.org, mbj@microsoft.com, ve7jtb@ve7jtb.com, maciej.machulak@gmail.com Pages: 18 Characters: 38044 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-oauth-dyn-reg-management-15.txt URL: https://www.rfc-editor.org/info/rfc7592 DOI: http://dx.doi.org/10.17487/RFC7592 This specification defines methods for management of OAuth 2.0 dynamic client registrations for use cases in which the properties of a registered client may need to be changed during the lifetime of the client. Not all authorization servers supporting dynamic client registration will support these management methods. This document is a product of the Web Authorization Protocol Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. 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/rfc.html 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 Thu Jul 9 16:29:53 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A79791A6F0E for ; Thu, 9 Jul 2015 16:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOhfhBtpEv5n for ; Thu, 9 Jul 2015 16:29:50 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0116.outbound.protection.outlook.com [65.55.169.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 D54141A6F27 for ; Thu, 9 Jul 2015 16:29:49 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.213.10; Thu, 9 Jul 2015 23:29:47 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0213.000; Thu, 9 Jul 2015 23:29:47 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth 2.0 Dynamic Client Registration Protocol is now RFC 7591 Thread-Index: AdC6nyQ3e43eC2v0Q3uWop7aZR7QRw== Date: Thu, 9 Jul 2015 23:29:47 +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; x-originating-ip: [2001:4898:80e8:ee31::2] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:iwW1qNeDD7wQknR7gOINsQCUWzS4tckojP54hjm888ZuGTemTCJJ/9ujreCOXtiyjzgXmO0cbUBDPrfwr9jdL3AAgGxN0Q5oNutL8/MVNQaqQrkR3etmyE5jW2o4cVKJa8l7+EazqVjfPRf99NWPeg==; 24:wOb7yETANWvr3bYV/X7uyNnDfyvj+zyXbnwsGyzX3AVjgV8q5FXipOVAlcBVbcmjfa3krsYzAcGcxmby3bbyQgk1EPlgdC/X/vYT2hd0Vfc=; 20:63hm/+d3Pi9Trb9wLQIPo8MvyQ/Ju+bTxUGeqChMtTjdJxz6Ah2xH2hqZnt9zgJtDtn0MN8+5BSm+NVIVH0JHQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; by2pr03mb441: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 0632519F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(19617315012)(40100003)(15975445007)(16236675004)(19580395003)(450100001)(74316001)(76576001)(19609705001)(46102003)(122556002)(87936001)(102836002)(2900100001)(2351001)(50986999)(54356999)(77156002)(2656002)(33656002)(19625215002)(229853001)(86362001)(62966003)(5001960100002)(86612001)(19300405004)(110136002)(5002640100001)(5003600100002)(77096005)(189998001)(558084003)(99286002)(107886002)(2501003)(92566002)(3826002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4429963C79E9B5993029ED0F5900BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2015 23:29:47.7943 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Subject: [OAUTH-WG] OAuth 2.0 Dynamic Client Registration Protocol is now RFC 7591 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 23:29:51 -0000 --_000_BY2PR03MB4429963C79E9B5993029ED0F5900BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The OAuth 2.0 Dynamic Client Registration Protocol specification is now RFC= 7591. I wrote more about this at = http://self-issued.info/?p=3D1414 and as @selfissued. Cheers, -- Mike --_000_BY2PR03MB4429963C79E9B5993029ED0F5900BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The OAuth 2.0 Dynamic Client Registration Protocol s= pecification is now RFC 7591.  I wr= ote more about this at http://self-issued.info/?p=3D= 1414 and as @selfissued.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; Cheers,

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

 

--_000_BY2PR03MB4429963C79E9B5993029ED0F5900BY2PR03MB442namprd_-- From nobody Thu Jul 9 17:27:03 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9203D1A016A for ; Thu, 9 Jul 2015 17:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.452 X-Spam-Level: X-Spam-Status: No, score=0.452 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bdqpdvf9RbCl for ; Thu, 9 Jul 2015 17:26:59 -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 60C231A0145 for ; Thu, 9 Jul 2015 17:26:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1436488018; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=bycCmfJC4F9M7sKtaQbwhCLenPHJoLhA3U39J3AFL2k=; b=qkDf1egW33Xo2tAqkzbfp6ZWeIhyvmiemG2G4l8LjYw2+nHxcbUe7AvfQvMV2qcAVFKpncIWx9UdAVxTeRKyVUhT2puCTm2lk1rmqL77wpQQXvqyA9/yztlNygeoI0peK3JJzi5w449U3XXRjPlVkoq6msSBrWmYKr86MRe9ESU= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R831e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03290; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=2; SR=0; Received: from 10.32.178.78(mailfrom:kepeng.lkp@alibaba-inc.com ip:182.92.253.16) by smtp.aliyun-inc.com(127.0.0.1); Fri, 10 Jul 2015 08:24:15 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Fri, 10 Jul 2015 08:24:10 +0800 From: "Kepeng Li" To: Mike Jones , "oauth@ietf.org" Message-ID: Thread-Topic: [OAUTH-WG] Proposed OAuth agenda items Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3519361455_3065291" Archived-At: Subject: Re: [OAUTH-WG] Proposed OAuth agenda items X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 00:27:01 -0000 > ´ËÓʼþʹÓà MIME ¸ñʽ¡£ÓÉÓÚÓʼþÔĶÁ³ÌÐò²»ÄÜʶ±ð ´Ë¸ñʽ£¬Òò´Ë£¬¿ÉÄÜÎÞ·¨Ê¶±ð¸ÃÓʼþµÄ·Ö²¿»ò²¿·ÖÄÚÈÝ¡£ --B_3519361455_3065291 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable I=A1=AFd like to add one short agenda item (5 min), to discuss the way forward: http://datatracker.ietf.org/doc/draft-sakimura-oauth-rjwtprof/ Thanks, Kind Regards Kepeng =B7=A2=BC=FE=C8=CB: Mike Jones =C8=D5=C6=DA: Friday, 10 July, 2015 5:09 am =D6=C1: "oauth@ietf.org" =D6=F7=CC=E2: [OAUTH-WG] Proposed OAuth agenda items I=A1=AFd like to see us cover the following topics during our meeting in Prague= =A1=AD =20 Issues and Choices for Token Exchange, Brian Campbell and Mike Jones, 30 minutes =20 Next steps to complete the POP documents, 30 minutes?: draft-ietf-oauth-pop-key-distribution, John Bradley?, 15 minutes? draft-ietf-oauth-pop-architecture, Phil Hunt?, 10 minutes? draft-ietf-oauth-proof-of-possession, Mike Jones, 5 minutes (or less) =20 And if the authors would like to talk about the status of jwsreq, signed-http-request, etc., I=A1=AFd welcome that as well. =20 I=A1=AFm assuming that introspection and spop are far enough along we won=A1=AFt ne= ed working group time for them? =20 See you in Prague! -- Mike =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --B_3519361455_3065291 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable
I’d like to add one short = agenda item (5 min), to discuss the way forward:

Thank= s,

Kind Regards
Kepeng

<= span style=3D"font-weight:bold">=B7=A2=BC=FE=C8=CB: Mike Jones <Michael.Jones@microsoft.com>
=C8=D5=C6=DA: Friday, 10 July, 2015 5:09 am
=D6=C1: "oauth= @ietf.org" <oauth@ietf.org>=D6=F7=CC=E2: [OAUTH-WG] Proposed OAuth agen= da items

I’d like to see us = cover the following topics during our meeting in Prague…

 

Issues and C= hoices for Token Exchange, Brian Campbell and Mike Jones, 30 minutes

 

Next s= teps to complete the POP documents, 30 minutes?:

           &n= bsp;    draft-ietf-oauth-pop-key-distribution, John Bradley?,= 15 minutes?

    &nbs= p;           draft-ietf-oa= uth-pop-architecture, Phil Hunt?, 10 minutes?

            = ;    draft-ietf-oauth-proof-of-possession, Mike Jones, 5 minu= tes (or less)

 

And if the authors would like to talk about the status of jws= req, signed-http-request, etc., I’d welcome that as well.

 

I’m a= ssuming that introspection and spop are far enough along we won’t need= working group time for them?

 =

       &nb= sp;            &= nbsp;            = ;            &nb= sp;            &= nbsp;     See you in Prague!

           &n= bsp;            =             &nbs= p;            &n= bsp;            =   -- Mike

 

_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/= mailman/listinfo/oauth --B_3519361455_3065291-- From nobody Fri Jul 10 08:29:43 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0F01A9248 for ; Fri, 10 Jul 2015 08:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G07_FQxpilVL for ; Fri, 10 Jul 2015 08:29:39 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c: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 CAB911B2850 for ; Fri, 10 Jul 2015 08:29:38 -0700 (PDT) Received: by wiwl6 with SMTP id l6so49774839wiw.0 for ; Fri, 10 Jul 2015 08:29:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UJcqB9YyTjN8UZ//SWgYjqsfACwk4evKyS4065TKZ0o=; b=0kuDlfRxWjW/JxIP3B3QroMJgST47LcM2JoJXRCX+574r2+83gs6HsVFwumVM6reFu HpCw+x3cYfPWLWNpd9qKy3XcxX8BDbtYFUbqPbJWJLJSN8zEuz75RrNDwqcyirZTy6oF ne7aXlDyZs3IKEhIG3K/1kZMm6DCYgAUrcCjd/wBpRoThMSwnUPVDL8nZnlULAyU5zPq duwATjU+MYJNqzjK8paaYpoCN3SXFFScavXofKwH1r6ftCybNOSe/F9RqCSQQkHLVeYJ GdDtzYbgcNo8b/ZZQxyIYorJsRdB/Ni0CMUufK8cTozrQNyAzmEyU7AYSBziQj0mwWKI jafw== MIME-Version: 1.0 X-Received: by 10.194.75.132 with SMTP id c4mr39793689wjw.80.1436542177463; Fri, 10 Jul 2015 08:29:37 -0700 (PDT) Received: by 10.28.31.194 with HTTP; Fri, 10 Jul 2015 08:29:37 -0700 (PDT) In-Reply-To: <0A42C02A-77C6-48DD-8BEC-52B31570FBAF@ve7jtb.com> References: <20150706230550.12450.15077.idtracker@ietfa.amsl.com> <68C4B3E0-0A40-4035-A6B8-EB553573BE5D@ve7jtb.com> <0A42C02A-77C6-48DD-8BEC-52B31570FBAF@ve7jtb.com> Date: Fri, 10 Jul 2015 11:29:37 -0400 Message-ID: From: Kathleen Moriarty To: John Bradley Content-Type: multipart/alternative; boundary=047d7bb04b7c315408051a870ad0 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-14.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 15:29:42 -0000 --047d7bb04b7c315408051a870ad0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable John, The updates were included in the version I approved for posting that also addressed Barry's discuss points, correct? Are we good with the current version to move forward: https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ Thank you, Kathleen On Thu, Jul 9, 2015 at 2:46 PM, John Bradley wrote: > I have made some edits to make it consistent. They are checked into the > butbucket repo nat and I use, but we can=E2=80=99t update the official dr= aft during > the freeze before the IETF meeting. > > https://bitbucket.org/Nat/oauth-spop > > On Jul 9, 2015, at 3:19 PM, Brian Campbell > wrote: > > I agree with William that it's a little confusing. I get that there's a > desire to discourage using "plain" but perhaps the language (especially t= he > MUST NOT in 7.2) should be lightened up just a bit? > > On Wed, Jul 8, 2015 at 8:22 PM, William Denniss > wrote: > >> Following up the discussion on today's NAPPS call, I understand why plai= n >> is not presented as the recommended approach in the spec (though it stil= l >> has some value over not doing PKCE at all, in that it mitigates against = the >> current known attack where a rogue app registers the same custom URI sch= eme >> as another), but I feel that after all the back and forth the picture is= a >> little confusing. >> >> In particular, 4.2 and 4.4.1 include some examples where plain is >> supported: >> >> 4.2 >>> Clients SHOULD use the S256 transformation. The plain transformation i= s >>> for compatibility with existing deployments and for constrained >>> environments that can't use the S256 transformation. >>> >> >> >> 4.4.1. >>> If the client is capable of using "S256", it MUST use "S256", as "S256" >>> is Mandatory To Implement (MTI) on the server. Clients are permitted to= use >>> "plain" only if they cannot support "S256" for some technical reason an= d >>> knows that the server supports "plain". >> >> >> But then 7.2 is very vocal that it MUST NOT be used for new >> implementations: >> >> 7.2 >>> Because of this, "plain" SHOULD NOT be used, and exists only >>> for compatibility with deployed implementations where the request path >>> is already protected. The "plain" method MUST NOT be used in >>> new implementations. >> >> >> What if those new implementations are constrained, as indicated in 4.2 >> and 4.4.1? >> >> >> Also, while S256 is clearly indicated as MTI, little is said about >> "plain", although it's alluded to that it's not MTI in 4.4.1 ("and knows >> that the server supports "plain""). >> >> Should we be more explicit upfront that "plain" is optional for servers >> to support, if that's the intention? >> >> >> On Tue, Jul 7, 2015 at 10:51 PM, William Denniss >> wrote: >> >>> t_m works for me, I just think we should have some indication that it's >>> the name of the transform. Will you also update where it is referenced = in >>> the description below Figure 2? >>> >>> >>> >>> On Tue, Jul 7, 2015 at 6:28 PM, John Bradley wrote: >>> >>>> Thanks, I fixed my finger dyslexia for the next draft. >>>> >>>> I changed it to t_m rather than =E2=80=9Ct=E2=80=9D I think that is c= learer. If I >>>> were to do it the other way XML2RFC would have double quotes in the te= xt >>>> version. >>>> >>>> John B. >>>> >>>> On Jul 7, 2015, at 9:38 PM, William Denniss >>>> wrote: >>>> >>>> In version 14, there's a typo on this line ("deso") in Section 7.2: >>>> >>>> `"plain" method deso not protect` >>>> >>>> Also, in the 1.1 Protocol Flow diagram, regarding the text: >>>> >>>> `+ t(code_verifier), t` >>>> >>>> I wonder if it makes more sense to represent as `+ t(code_verifier), >>>> "t"` (note the quotes on the second 't') given that it's a string >>>> representation of the method that's being sent? >>>> >>>> >>>> On Mon, Jul 6, 2015 at 4:05 PM, wrote: >>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> This draft is a work item of the Web Authorization Protocol Working >>>>> Group of the IETF. >>>>> >>>>> Title : Proof Key for Code Exchange by OAuth Public >>>>> Clients >>>>> Authors : Nat Sakimura >>>>> John Bradley >>>>> Naveen Agarwal >>>>> Filename : draft-ietf-oauth-spop-14.txt >>>>> Pages : 20 >>>>> Date : 2015-07-06 >>>>> >>>>> Abstract: >>>>> OAuth 2.0 public clients utilizing the Authorization Code Grant ar= e >>>>> susceptible to the authorization code interception attack. This >>>>> specification describes the attack as well as a technique to >>>>> mitigate >>>>> against the threat through the use of Proof Key for Code Exchange >>>>> (PKCE, pronounced "pixy"). >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ >>>>> >>>>> There's also a htmlized version available at: >>>>> https://tools.ietf.org/html/draft-ietf-oauth-spop-14 >>>>> >>>>> A diff from the previous version is available at: >>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-spop-14 >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission >>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Best regards, Kathleen --047d7bb04b7c315408051a870ad0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
John,

The updates were included in the = version I approved for posting that also addressed Barry's discuss poin= ts, correct?

Are we good with the current version = to move forward:

Thank you,
Kathleen
=

On Thu, Jul 9, 20= 15 at 2:46 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I have mad= e some edits to make it consistent.=C2=A0 They are checked into the butbuck= et repo nat and I use, but we can=E2=80=99t update the official draft durin= g the freeze before the IETF meeting.


On Jul 9, 2015, at 3:19 PM, Brian Campbell <bcampbell@pingidentity.c= om> wrote:

I agree with William that = it's a little confusing. I get that there's a desire to discourage = using "plain" but perhaps the language (especially the MUST NOT i= n 7.2) should be lightened up just a bit?

On Wed, Jul 8, 2015 at 8:22 PM, William = Denniss <wdenniss@google.com> wrote:
Following up the = discussion on today's NAPPS call, I understand why plain is not present= ed as the recommended approach in the spec (though it still has some value = over not doing PKCE at all, in that it mitigates against the current known = attack where a rogue app registers the same custom URI scheme as another), = but I feel that after all the back and forth the picture is a little confus= ing.

In particular, 4.2 and 4.4.1 include some examples where plain = is supported:

4.2<= br>Clients SHOULD use the S256 transformation.=C2=A0 The plain transformati= on is for compatibility with existing deployments and for constrained envir= onments that can't use the S256 transformation.
=C2=A0
4.4.1.
If the client is ca= pable of using "S256", it MUST use "S256", as "S25= 6" is Mandatory To Implement (MTI) on the server.=C2=A0Clients are=C2= =A0permitted to use "plain" only if they cannot support "S25= 6" for some=C2=A0technical reason and knows that the server supports &= quot;plain".

But then 7.2 is very vocal that it MUST N= OT be used for new implementations:

7.2
Because = of this, "plain" SHOULD NOT be used, and exists only for=C2=A0com= patibility with deployed implementations where the request path is=C2=A0alr= eady protected.=C2=A0 The "plain" method MUST NOT be used in new= =C2=A0implementations.

=C2=A0What if those new implementations are constra= ined, as indicated in 4.2 and 4.4.1?

Als= o, while S256 is clearly indicated as MTI, little is said about "plain= ", although it's alluded to that it's not MTI in 4.4.1 ("= and knows that the server supports "plain"").

Should we be more ex= plicit upfront that "plain" is optional for servers to support, i= f that's the intention?

<= /div>

On Tue= , Jul 7, 2015 at 10:51 PM, William Denniss <wdenniss@google.com><= /span> wrote:
t_m works for me, I just= think we should have some indication that it's the=C2=A0name=C2=A0of t= he transform. Will you also update where it is referenced in the descriptio= n below Figure 2?



On Tue, Jul 7, 2015 at 6:28= PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Thanks, I fixed my finger dyslexia= for the next draft.

I changed it to t_m rather than =E2= =80=9Ct=E2=80=9D =C2=A0I think that is clearer.=C2=A0 If I were to do it th= e other way XML2RFC would have double quotes in the text version.

John B.=C2=A0

<= div>On Jul 7, 2015, at 9:38 PM, William Denniss <wdenniss@google.com> wrote:
<= br>
In version 14, there's a typo on this line (&q= uot;deso") in Section 7.2:

`"plain" method deso not protect`

Also, in the 1.1 Protocol Flow diagram, regarding the text= :

`+ t(code_verifier), t`
<= /div>

I wonder if it makes more sense to = represent as `+ t(code_verifier), "= ;t"` (note the quotes on the second 't') given that it&= #39;s a string representation of the method that's being sent?

=

On Mon, Jul 6, 2015 at 4:05 PM, <internet-drafts@ietf.org= > wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Web Authorization Protocol Working G= roup of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Proof Key for Code Exchange by OAuth Public Clients
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Nat = Sakimura
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Bradley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Naveen Agarwal
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-spop-14.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 20
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-07-06

Abstract:
=C2=A0 =C2=A0OAuth 2.0 public clients utilizing the Authorization Code Gran= t are
=C2=A0 =C2=A0susceptible to the authorization code interception attack.=C2= =A0 This
=C2=A0 =C2=A0specification describes the attack as well as a technique to m= itigate
=C2=A0 =C2=A0against the threat through the use of Proof Key for Code Excha= nge
=C2=A0 =C2=A0(PKCE, pronounced "pixy").


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-o= auth-spop/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-spo= p-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-oauth-spop-14


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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



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




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




--

Best regards,
Ka= thleen
--047d7bb04b7c315408051a870ad0-- From nobody Fri Jul 10 08:32:42 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B371B29B5; Fri, 10 Jul 2015 08:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVA5W4JUdFQq; Fri, 10 Jul 2015 08:32:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C49901A9248; Fri, 10 Jul 2015 08:32:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150710153236.25916.45262.idtracker@ietfa.amsl.com> Date: Fri, 10 Jul 2015 08:32:36 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D ACTION:draft-ietf-oauth-spop-15.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 15:32:40 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : Proof Key for Code Exchange by OAuth Public Clients Author(s) : N. Sakimura, et al Filename : draft-ietf-oauth-spop Pages : 21 Date : 2015-07-10 OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced "pixy"). A URL for this Internet-Draft is: https://www.ietf.org/internet-drafts/draft-ietf-oauth-spop-15.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-oauth-spop"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2015-07-10083236.I-D@ietf.org> --NextPart-- From nobody Fri Jul 10 08:36:38 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4645A1B29E6 for ; Fri, 10 Jul 2015 08:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IueUSTjoJmxD for ; Fri, 10 Jul 2015 08:36:28 -0700 (PDT) Received: from mail-qk0-f177.google.com (mail-qk0-f177.google.com [209.85.220.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FEBC1B2850 for ; Fri, 10 Jul 2015 08:36:28 -0700 (PDT) Received: by qkhu186 with SMTP id u186so209375577qkh.0 for ; Fri, 10 Jul 2015 08:36:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=0FK3XIcoQbkA/oHFln/gY4Ddv9iFm5wcIYowNYz2uvc=; b=WWU47TlFVxU6OtWCpKhYZXQs583n5phlyYhEFvcDLxOBfAo15kyhyTO7g2fiPou/Qr JZQjBf/2qojWSyFA0WO4B/83s4HitRiNxtzw9An/XuU9Fm6+M3pz+6PHTiU1zhkmZgDs OhcKap++uZf9h7PwHeNGCm7+I+9bRfEPYT5OF5InwORJ3FrXhDQ4VJZJ46GeP/8LpmyM ov8pZt0EaFYOmvpcahoDp/5Cn0pCXo6cYlZwEROc4B1IZS/mAwBWqSqKIwil5iZ+l9Kf zmdI4QCzptEz+x+Adg5IEhCdecFYTYXotF1lacd9zo5uMdy+BnaEGZrJFd7m9zkA1t4R boSA== X-Gm-Message-State: ALoCoQnWf+JmDbcU//35VGHPmsimpSoSpIz8+5tKbBoKcz7IZSeRU2zs+WnMkvIPGAlJGfQaKXW8 X-Received: by 10.55.17.197 with SMTP id 66mr13884906qkr.90.1436542587548; Fri, 10 Jul 2015 08:36:27 -0700 (PDT) Received: from [192.168.1.216] (181-163-3-125.baf.movistar.cl. [181.163.3.125]) by smtp.gmail.com with ESMTPSA id h49sm5901767qgd.24.2015.07.10.08.36.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 10 Jul 2015 08:36:26 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_7FE08EE0-24AE-487C-9A00-75D90C7CDB34" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: John Bradley In-Reply-To: Date: Fri, 10 Jul 2015 12:36:18 -0300 Message-Id: References: <20150706230550.12450.15077.idtracker@ietfa.amsl.com> <68C4B3E0-0A40-4035-A6B8-EB553573BE5D@ve7jtb.com> <0A42C02A-77C6-48DD-8BEC-52B31570FBAF@ve7jtb.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-14.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 15:36:32 -0000 --Apple-Mail=_7FE08EE0-24AE-487C-9A00-75D90C7CDB34 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes I believe I I addressed these comments as part of Barry=E2=80=99s = discuss points. =20 They were comments on the changes that Barry introduced that caused a = inconsistency. I resolved that in 15. I think it is good to go. > On Jul 10, 2015, at 12:29 PM, Kathleen Moriarty = wrote: >=20 > John, >=20 > The updates were included in the version I approved for posting that = also addressed Barry's discuss points, correct? >=20 > Are we good with the current version to move forward: > https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ = >=20 > Thank you, > Kathleen >=20 > On Thu, Jul 9, 2015 at 2:46 PM, John Bradley > wrote: > I have made some edits to make it consistent. They are checked into = the butbucket repo nat and I use, but we can=E2=80=99t update the = official draft during the freeze before the IETF meeting. >=20 > https://bitbucket.org/Nat/oauth-spop = >=20 >> On Jul 9, 2015, at 3:19 PM, Brian Campbell = > wrote: >>=20 >> I agree with William that it's a little confusing. I get that there's = a desire to discourage using "plain" but perhaps the language = (especially the MUST NOT in 7.2) should be lightened up just a bit?=20 >>=20 >> On Wed, Jul 8, 2015 at 8:22 PM, William Denniss > wrote: >> Following up the discussion on today's NAPPS call, I understand why = plain is not presented as the recommended approach in the spec (though = it still has some value over not doing PKCE at all, in that it mitigates = against the current known attack where a rogue app registers the same = custom URI scheme as another), but I feel that after all the back and = forth the picture is a little confusing. >>=20 >> In particular, 4.2 and 4.4.1 include some examples where plain is = supported: >>=20 >> 4.2 >> Clients SHOULD use the S256 transformation. The plain transformation = is for compatibility with existing deployments and for constrained = environments that can't use the S256 transformation. >> =20 >> 4.4.1. >> If the client is capable of using "S256", it MUST use "S256", as = "S256" is Mandatory To Implement (MTI) on the server. Clients are = permitted to use "plain" only if they cannot support "S256" for some = technical reason and knows that the server supports "plain". >>=20 >> But then 7.2 is very vocal that it MUST NOT be used for new = implementations: >>=20 >> 7.2 >> Because of this, "plain" SHOULD NOT be used, and exists only for = compatibility with deployed implementations where the request path is = already protected. The "plain" method MUST NOT be used in new = implementations. >>=20 >> What if those new implementations are constrained, as indicated in = 4.2 and 4.4.1? >>=20 >>=20 >> Also, while S256 is clearly indicated as MTI, little is said about = "plain", although it's alluded to that it's not MTI in 4.4.1 ("and knows = that the server supports "plain""). >>=20 >> Should we be more explicit upfront that "plain" is optional for = servers to support, if that's the intention? >>=20 >>=20 >> On Tue, Jul 7, 2015 at 10:51 PM, William Denniss > wrote: >> t_m works for me, I just think we should have some indication that = it's the name of the transform. Will you also update where it is = referenced in the description below Figure 2? >>=20 >>=20 >>=20 >> On Tue, Jul 7, 2015 at 6:28 PM, John Bradley > wrote: >> Thanks, I fixed my finger dyslexia for the next draft. >>=20 >> I changed it to t_m rather than =E2=80=9Ct=E2=80=9D I think that is = clearer. If I were to do it the other way XML2RFC would have double = quotes in the text version. >>=20 >> John B.=20 >>=20 >>> On Jul 7, 2015, at 9:38 PM, William Denniss > wrote: >>>=20 >>> In version 14, there's a typo on this line ("deso") in Section 7.2: >>>=20 >>> `"plain" method deso not protect` >>>=20 >>> Also, in the 1.1 Protocol Flow diagram, regarding the text: >>>=20 >>> `+ t(code_verifier), t` >>>=20 >>> I wonder if it makes more sense to represent as `+ t(code_verifier), = "t"` (note the quotes on the second 't') given that it's a string = representation of the method that's being sent? >>>=20 >>>=20 >>> On Mon, Jul 6, 2015 at 4:05 PM, > wrote: >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>> This draft is a work item of the Web Authorization Protocol Working = Group of the IETF. >>>=20 >>> Title : Proof Key for Code Exchange by OAuth = Public Clients >>> Authors : Nat Sakimura >>> John Bradley >>> Naveen Agarwal >>> Filename : draft-ietf-oauth-spop-14.txt >>> Pages : 20 >>> Date : 2015-07-06 >>>=20 >>> Abstract: >>> OAuth 2.0 public clients utilizing the Authorization Code Grant = are >>> susceptible to the authorization code interception attack. This >>> specification describes the attack as well as a technique to = mitigate >>> against the threat through the use of Proof Key for Code Exchange >>> (PKCE, pronounced "pixy"). >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ = >>>=20 >>> There's also a htmlized version available at: >>> https://tools.ietf.org/html/draft-ietf-oauth-spop-14 = >>>=20 >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-spop-14 = >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org = . >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ = >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen --Apple-Mail=_7FE08EE0-24AE-487C-9A00-75D90C7CDB34 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yes I believe I I addressed these comments as part of = Barry=E2=80=99s discuss points.  
They were comments = on the changes that Barry introduced that caused a inconsistency.   = I resolved that in 15.

I think it is good to go.


On Jul 10, 2015, at 12:29 PM, = Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

John,

The = updates were included in the version I approved for posting that also = addressed Barry's discuss points, correct?

Are we good with the current version to = move forward:
https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/

Thank you,
Kathleen

On Thu, = Jul 9, 2015 at 2:46 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I have made some edits to make = it consistent.  They are checked into the butbucket repo nat and I = use, but we can=E2=80=99t update the official draft during the freeze = before the IETF meeting.

https://bitbucket.org/Nat/oauth-spop

On Jul = 9, 2015, at 3:19 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

I agree with = William that it's a little confusing. I get that there's a desire to = discourage using "plain" but perhaps the language (especially the MUST = NOT in 7.2) should be lightened up just a bit?

On Wed, = Jul 8, 2015 at 8:22 PM, William Denniss <wdenniss@google.com> wrote:
Following up the discussion on = today's NAPPS call, I understand why plain is not presented as the = recommended approach in the spec (though it still has some value over = not doing PKCE at all, in that it mitigates against the current known = attack where a rogue app registers the same custom URI scheme as = another), but I feel that after all the back and forth the picture is a = little confusing.

In particular, 4.2 and = 4.4.1 include some examples where plain is supported:

4.2
Clients SHOULD use the = S256 transformation.  The plain transformation is for compatibility = with existing deployments and for constrained environments that can't = use the S256 transformation.
 
4.4.1.
If the client is = capable of using "S256", it MUST use "S256", as "S256" is Mandatory To = Implement (MTI) on the server. Clients are permitted to use = "plain" only if they cannot support "S256" for some technical = reason and knows that the server supports "plain".

But then 7.2 is very vocal that it MUST NOT be used for new = implementations:

7.2
Because of this, = "plain" SHOULD NOT be used, and exists only for compatibility with = deployed implementations where the request path is already = protected.  The "plain" method MUST NOT be used in = new implementations.

 What if those new = implementations are constrained, as indicated in 4.2 and 4.4.1?


Also, while S256 is clearly indicated as MTI, = little is said about "plain", although it's alluded to that it's not MTI = in 4.4.1 ("and knows that the server supports "plain"").

Should we be more explicit upfront that "plain" is = optional for servers to support, if that's the intention?


On Tue, Jul 7, 2015 at 10:51 PM, William Denniss = <wdenniss@google.com> = wrote:
t_m works for = me, I just think we should have some indication that it's = the name of the transform. Will you also update where it is = referenced in the description below Figure 2?



On Tue, Jul 7, 2015 at 6:28 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Thanks, I fixed my finger dyslexia for the next draft.

I changed it to t_m = rather than =E2=80=9Ct=E2=80=9D  I think that is clearer.  If = I were to do it the other way XML2RFC would have double quotes in the = text version.

John B. 

On Jul 7, 2015, at 9:38 PM, William Denniss <wdenniss@google.com> wrote:

In version 14, there's a typo on = this line ("deso") in Section 7.2:

`"plain" method deso not protect`

Also, in the 1.1 Protocol Flow diagram, regarding the = text:

`+ t(code_verifier), t`

I wonder if it makes more = sense to represent as `+ = t(code_verifier), "t"` (note the quotes on the second 't') given = that it's a string representation of the method that's being sent?


On = Mon, Jul 6, 2015 at 4:05 PM, <internet-drafts@ietf.org> wrote:

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

        Title          =  : Proof Key for Code Exchange by OAuth Public Clients
=         Authors         : = Nat Sakimura
                    =       John Bradley
                    =       Naveen Agarwal
        Filename        : = draft-ietf-oauth-spop-14.txt
        Pages          =  : 20
        Date          =   : 2015-07-06

Abstract:
   OAuth 2.0 public clients utilizing the Authorization Code = Grant are
   susceptible to the authorization code interception = attack.  This
   specification describes the attack as well as a technique = to mitigate
   against the threat through the use of Proof Key for Code = Exchange
   (PKCE, pronounced "pixy").


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-spop-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-spop-14


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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




--

Best regards,
Kathleen

= --Apple-Mail=_7FE08EE0-24AE-487C-9A00-75D90C7CDB34-- From nobody Fri Jul 10 09:11:51 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8681B2CCD for ; Fri, 10 Jul 2015 09:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWxDZbU0e7ox for ; Fri, 10 Jul 2015 09:11:43 -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 B10D41B2CD9 for ; Fri, 10 Jul 2015 09:11:36 -0700 (PDT) Received: by igcqs7 with SMTP id qs7so16173841igc.0 for ; Fri, 10 Jul 2015 09:11: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:content-type; bh=4oXDa7WncpslRDQZa0L22ssb4dijKW7uaH06KjT3Uy8=; b=Q9+D/GsoJnqqq+yCUnQupz51vTS8+ObUtaWyWqEh9zlfN7ugy9+P+ppXsx2veDtuGR d98upfXpoXe172ZRsAXsCFhD4hqo8AAxpoueMd3nbGsAaVD3VAP/O5L7yxJ5Nzywq21T Ycn0BWfIHSFPncNFZ6F5qVqWq8Axzs7/IlLos= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=4oXDa7WncpslRDQZa0L22ssb4dijKW7uaH06KjT3Uy8=; b=Scbx0SsEWYzXWyq5cd0AVy7ECyQV1PBVETZZzR9d/RLQ2E307MkWSDEON5/l7ZTGpB P3M0bo6zrsj2Bc83Rlck099U3Iofgdf8pGbWZCiMW0SObcaPLXu1aomvVM0nyui9S2Yt 1DfQp2mrWZU4BeLKcF5GD74t0XNLKwhQegUnGFcx8QVoEEGv5lVAad04YAwdZbBGLmu+ fWxieTZg4RO8TnL6PMqxY7xcSOYZlMQJlEM6GUXwREpR059HIF4czRe+RFAA9ufn9hji rICj9OYW5b6TNtArTU8wv6KG1alcWV0kHvTHJAn0QmXh53f5eq/c5zqokqUXjyctDHQ3 lozA== X-Gm-Message-State: ALoCoQmnVmMYFXYcVbVJQWH6thYLO1mfcZjORtuMPMcroWWPq4S3Nq3JU+pMt3EuE0uZ1mYRfulp X-Received: by 10.107.159.66 with SMTP id i63mr34645391ioe.68.1436544696031; Fri, 10 Jul 2015 09:11:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Fri, 10 Jul 2015 09:11:06 -0700 (PDT) In-Reply-To: References: <20150706230550.12450.15077.idtracker@ietfa.amsl.com> <68C4B3E0-0A40-4035-A6B8-EB553573BE5D@ve7jtb.com> <0A42C02A-77C6-48DD-8BEC-52B31570FBAF@ve7jtb.com> From: Brian Campbell Date: Fri, 10 Jul 2015 10:11:06 -0600 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a1141b9604fb75b051a87a000 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-14.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 16:11:50 -0000 --001a1141b9604fb75b051a87a000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think -15 does address the inconsistency. On Fri, Jul 10, 2015 at 9:36 AM, John Bradley wrote: > Yes I believe I I addressed these comments as part of Barry=E2=80=99s dis= cuss > points. > They were comments on the changes that Barry introduced that caused a > inconsistency. I resolved that in 15. > > I think it is good to go. > > > On Jul 10, 2015, at 12:29 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > John, > > The updates were included in the version I approved for posting that also > addressed Barry's discuss points, correct? > > Are we good with the current version to move forward: > https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ > > Thank you, > Kathleen > > On Thu, Jul 9, 2015 at 2:46 PM, John Bradley wrote: > >> I have made some edits to make it consistent. They are checked into the >> butbucket repo nat and I use, but we can=E2=80=99t update the official d= raft during >> the freeze before the IETF meeting. >> >> https://bitbucket.org/Nat/oauth-spop >> >> On Jul 9, 2015, at 3:19 PM, Brian Campbell >> wrote: >> >> I agree with William that it's a little confusing. I get that there's a >> desire to discourage using "plain" but perhaps the language (especially = the >> MUST NOT in 7.2) should be lightened up just a bit? >> >> On Wed, Jul 8, 2015 at 8:22 PM, William Denniss >> wrote: >> >>> Following up the discussion on today's NAPPS call, I understand why >>> plain is not presented as the recommended approach in the spec (though = it >>> still has some value over not doing PKCE at all, in that it mitigates >>> against the current known attack where a rogue app registers the same >>> custom URI scheme as another), but I feel that after all the back and f= orth >>> the picture is a little confusing. >>> >>> In particular, 4.2 and 4.4.1 include some examples where plain is >>> supported: >>> >>> 4.2 >>>> Clients SHOULD use the S256 transformation. The plain transformation >>>> is for compatibility with existing deployments and for constrained >>>> environments that can't use the S256 transformation. >>>> >>> >>> >>> 4.4.1. >>>> If the client is capable of using "S256", it MUST use "S256", as "S256= " >>>> is Mandatory To Implement (MTI) on the server. Clients are permitted t= o use >>>> "plain" only if they cannot support "S256" for some technical reason a= nd >>>> knows that the server supports "plain". >>> >>> >>> But then 7.2 is very vocal that it MUST NOT be used for new >>> implementations: >>> >>> 7.2 >>>> Because of this, "plain" SHOULD NOT be used, and exists only >>>> for compatibility with deployed implementations where the request path >>>> is already protected. The "plain" method MUST NOT be used in >>>> new implementations. >>> >>> >>> What if those new implementations are constrained, as indicated in 4.2 >>> and 4.4.1? >>> >>> >>> Also, while S256 is clearly indicated as MTI, little is said about >>> "plain", although it's alluded to that it's not MTI in 4.4.1 ("and know= s >>> that the server supports "plain""). >>> >>> Should we be more explicit upfront that "plain" is optional for servers >>> to support, if that's the intention? >>> >>> >>> On Tue, Jul 7, 2015 at 10:51 PM, William Denniss >>> wrote: >>> >>>> t_m works for me, I just think we should have some indication that it'= s >>>> the name of the transform. Will you also update where it is referenced= in >>>> the description below Figure 2? >>>> >>>> >>>> >>>> On Tue, Jul 7, 2015 at 6:28 PM, John Bradley wrote= : >>>> >>>>> Thanks, I fixed my finger dyslexia for the next draft. >>>>> >>>>> I changed it to t_m rather than =E2=80=9Ct=E2=80=9D I think that is = clearer. If I >>>>> were to do it the other way XML2RFC would have double quotes in the t= ext >>>>> version. >>>>> >>>>> John B. >>>>> >>>>> On Jul 7, 2015, at 9:38 PM, William Denniss >>>>> wrote: >>>>> >>>>> In version 14, there's a typo on this line ("deso") in Section 7.2: >>>>> >>>>> `"plain" method deso not protect` >>>>> >>>>> Also, in the 1.1 Protocol Flow diagram, regarding the text: >>>>> >>>>> `+ t(code_verifier), t` >>>>> >>>>> I wonder if it makes more sense to represent as `+ t(code_verifier), >>>>> "t"` (note the quotes on the second 't') given that it's a string >>>>> representation of the method that's being sent? >>>>> >>>>> >>>>> On Mon, Jul 6, 2015 at 4:05 PM, wrote: >>>>> >>>>>> >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>> directories. >>>>>> This draft is a work item of the Web Authorization Protocol Working >>>>>> Group of the IETF. >>>>>> >>>>>> Title : Proof Key for Code Exchange by OAuth Publi= c >>>>>> Clients >>>>>> Authors : Nat Sakimura >>>>>> John Bradley >>>>>> Naveen Agarwal >>>>>> Filename : draft-ietf-oauth-spop-14.txt >>>>>> Pages : 20 >>>>>> Date : 2015-07-06 >>>>>> >>>>>> Abstract: >>>>>> OAuth 2.0 public clients utilizing the Authorization Code Grant a= re >>>>>> susceptible to the authorization code interception attack. This >>>>>> specification describes the attack as well as a technique to >>>>>> mitigate >>>>>> against the threat through the use of Proof Key for Code Exchange >>>>>> (PKCE, pronounced "pixy"). >>>>>> >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ >>>>>> >>>>>> There's also a htmlized version available at: >>>>>> https://tools.ietf.org/html/draft-ietf-oauth-spop-14 >>>>>> >>>>>> A diff from the previous version is available at: >>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-spop-14 >>>>>> >>>>>> >>>>>> Please note that it may take a couple of minutes from the time of >>>>>> submission >>>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@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 >> >> > > > -- > > Best regards, > Kathleen > > > --001a1141b9604fb75b051a87a000 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think -15 does address the inconsistency.
=

On Fri, Jul= 10, 2015 at 9:36 AM, John Bradley <ve7jtb@ve7jtb.com> wrote= :
Yes= I believe I I addressed these comments as part of Barry=E2=80=99s discuss = points. =C2=A0
They were comments on the changes that Barry introduced = that caused a inconsistency. =C2=A0 I resolved that in 15.

I think it is good to go.


On Jul 10, 2015, at 12:29 P= M, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
John,

The updates were included = in the version I approved for posting that also addressed Barry's discu= ss points, correct?

Are we good with the current v= ersion to move forward:

Thank you,
=
Kathleen

On Thu, Jul 9, 2015 at 2:46 PM, John Bradley <= ve7jtb@ve7jtb.com> wrote:
I have made some edits to make it consistent.=C2=A0 They are= checked into the butbucket repo nat and I use, but we can=E2=80=99t update= the official draft during the freeze before the IETF meeting.


On Jul 9, 2015, at 3:19 PM, Brian Campbell <bcampbell@ping= identity.com> wrote:

I agree with Wil= liam that it's a little confusing. I get that there's a desire to d= iscourage using "plain" but perhaps the language (especially the = MUST NOT in 7.2) should be lightened up just a bit?

On Wed, Jul 8, 2015 at 8:22 PM= , William Denniss <wdenniss@google.com> wrote:
Followin= g up the discussion on today's NAPPS call, I understand why plain is no= t presented as the recommended approach in the spec (though it still has so= me value over not doing PKCE at all, in that it mitigates against the curre= nt known attack where a rogue app registers the same custom URI scheme as a= nother), but I feel that after all the back and forth the picture is a litt= le confusing.

In particular, 4.2 and 4.4.1 include some examples whe= re plain is supported:

4.2
Clients SHOULD use the S256 transformation.=C2=A0 The plain tra= nsformation is for compatibility with existing deployments and for constrai= ned environments that can't use the S256 transformation.
=C2=A0
4.4.1.
If the cli= ent is capable of using "S256", it MUST use "S256", as = "S256" is Mandatory To Implement (MTI) on the server.=C2=A0Client= s are=C2=A0permitted to use "plain" only if they cannot support &= quot;S256" for some=C2=A0technical reason and knows that the server su= pports "plain".

But then 7.2 is very vocal that i= t MUST NOT be used for new implementations:

7.2
= Because of this, "plain" SHOULD NOT be used, and exists only for= =C2=A0compatibility with deployed implementations where the request path is= =C2=A0already protected.=C2=A0 The "plain" method MUST NOT be use= d in new=C2=A0implementations.

<= /div>
=C2=A0What if those new implementations are= constrained, as indicated in 4.2 and 4.4.1?


Also, while S256 is clearly indicated as MTI, little is said about &qu= ot;plain", although it's alluded to that it's not MTI in 4.4.1= ("and knows that the server supports "plain"").
<= div class=3D"gmail_extra">
Should we be= more explicit upfront that "plain" is optional for servers to su= pport, if that's the intention?


On Tue, Jul 7, 2015 at 10:51 PM, William Denniss <wdenniss@google.com<= /a>> wrote:
t_m works for me= , I just think we should have some indication that it's the=C2=A0name= =C2=A0of the transform. Will you also update where it is referenced in the = description below Figure 2?



On Tue, Jul 7, 2015= at 6:28 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Thanks, I fixed my finger = dyslexia for the next draft.

I changed it to t_m rather = than =E2=80=9Ct=E2=80=9D =C2=A0I think that is clearer.=C2=A0 If I were to = do it the other way XML2RFC would have double quotes in the text version.

John B.=C2=A0

On Jul 7, 2015, at 9:38 PM, William Denniss <wdenniss@google.com> wrote= :

In version 14, there's a typo on this = line ("deso") in Section 7.2:

`"plain" method deso not protect`
<= /div>

Also, in the 1.1 Protocol Flow diagram, regarding = the text:

`+ t(code_verifier), t`

I wonder if it makes more s= ense to represent as `+ t(code_verifier= ), "t"` (note the quotes on the second 't') given = that it's a string representation of the method that's being sent?<= div>

On Mon, Jul 6, 2015 at 4:05 PM, <internet-drafts@ietf= .org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Web Authorization Protocol Working G= roup of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Proof Key for Code Exchange by OAuth Public Clients
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Nat = Sakimura
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Bradley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Naveen Agarwal
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-spop-14.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 20
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-07-06

Abstract:
=C2=A0 =C2=A0OAuth 2.0 public clients utilizing the Authorization Code Gran= t are
=C2=A0 =C2=A0susceptible to the authorization code interception attack.=C2= =A0 This
=C2=A0 =C2=A0specification describes the attack as well as a technique to m= itigate
=C2=A0 =C2=A0against the threat through the use of Proof Key for Code Excha= nge
=C2=A0 =C2=A0(PKCE, pronounced "pixy").


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-o= auth-spop/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-spo= p-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-oauth-spop-14


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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



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




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




--

Best regards,
Kathleen

--001a1141b9604fb75b051a87a000-- From nobody Fri Jul 10 09:33:57 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5CC1AD49F for ; Fri, 10 Jul 2015 09:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaD3zckXnwEF for ; Fri, 10 Jul 2015 09:33:47 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75F4B1AD373 for ; Fri, 10 Jul 2015 09:33:46 -0700 (PDT) Received: by wiga1 with SMTP id a1so19974670wig.0 for ; Fri, 10 Jul 2015 09:33:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GyTJVL2DamHGRptpjAuSow9bmtygnRke3d1ncRZQ3ko=; b=oQS+wbZYAbi+c4kZsFpTaKDLzMeuxSskVVI56dIh+BxFN3GpRkaiRWhlifJ0t33FhF qtSllCCHD8h1VymWVIPguG7UflJAUxoN3GC96k9Lf45410m8Luqppso5l/d9CwubyWPL fc3LwpO845VSfQopk9Ezu+gUuJQQUXnZQ1MPHYTIRunm4EPN/vH6X1wMeb+ZVrXpcVTk z6paEwK+VNR92svg/ZizzgGBmQso9lRQww0yfy7lNyH0CE3ub9qGmSPizKD8xyJxezgg Ez+i2/WmAIbRzBXf9DsuIYDwc7VGF1Kij2YY4uC9012ZbS8uxXvIPyqRoyg+NL1mUgqp ji7g== MIME-Version: 1.0 X-Received: by 10.180.95.67 with SMTP id di3mr7610161wib.78.1436546025224; Fri, 10 Jul 2015 09:33:45 -0700 (PDT) Received: by 10.28.31.194 with HTTP; Fri, 10 Jul 2015 09:33:45 -0700 (PDT) In-Reply-To: References: <20150706230550.12450.15077.idtracker@ietfa.amsl.com> <68C4B3E0-0A40-4035-A6B8-EB553573BE5D@ve7jtb.com> <0A42C02A-77C6-48DD-8BEC-52B31570FBAF@ve7jtb.com> Date: Fri, 10 Jul 2015 12:33:45 -0400 Message-ID: From: Kathleen Moriarty To: Brian Campbell Content-Type: multipart/alternative; boundary=f46d044287e2898073051a87efda Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-14.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 16:33:53 -0000 --f46d044287e2898073051a87efda Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, Brian! William? Are you good with this version? On Fri, Jul 10, 2015 at 12:11 PM, Brian Campbell wrote: > I think -15 does address the inconsistency. > > On Fri, Jul 10, 2015 at 9:36 AM, John Bradley wrote: > >> Yes I believe I I addressed these comments as part of Barry=E2=80=99s di= scuss >> points. >> They were comments on the changes that Barry introduced that caused a >> inconsistency. I resolved that in 15. >> >> I think it is good to go. >> >> >> On Jul 10, 2015, at 12:29 PM, Kathleen Moriarty < >> kathleen.moriarty.ietf@gmail.com> wrote: >> >> John, >> >> The updates were included in the version I approved for posting that als= o >> addressed Barry's discuss points, correct? >> >> Are we good with the current version to move forward: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ >> >> Thank you, >> Kathleen >> >> On Thu, Jul 9, 2015 at 2:46 PM, John Bradley wrote: >> >>> I have made some edits to make it consistent. They are checked into th= e >>> butbucket repo nat and I use, but we can=E2=80=99t update the official = draft during >>> the freeze before the IETF meeting. >>> >>> https://bitbucket.org/Nat/oauth-spop >>> >>> On Jul 9, 2015, at 3:19 PM, Brian Campbell >>> wrote: >>> >>> I agree with William that it's a little confusing. I get that there's a >>> desire to discourage using "plain" but perhaps the language (especially= the >>> MUST NOT in 7.2) should be lightened up just a bit? >>> >>> On Wed, Jul 8, 2015 at 8:22 PM, William Denniss >>> wrote: >>> >>>> Following up the discussion on today's NAPPS call, I understand why >>>> plain is not presented as the recommended approach in the spec (though= it >>>> still has some value over not doing PKCE at all, in that it mitigates >>>> against the current known attack where a rogue app registers the same >>>> custom URI scheme as another), but I feel that after all the back and = forth >>>> the picture is a little confusing. >>>> >>>> In particular, 4.2 and 4.4.1 include some examples where plain is >>>> supported: >>>> >>>> 4.2 >>>>> Clients SHOULD use the S256 transformation. The plain transformation >>>>> is for compatibility with existing deployments and for constrained >>>>> environments that can't use the S256 transformation. >>>>> >>>> >>>> >>>> 4.4.1. >>>>> If the client is capable of using "S256", it MUST use "S256", as >>>>> "S256" is Mandatory To Implement (MTI) on the server. Clients are per= mitted >>>>> to use "plain" only if they cannot support "S256" for some technical = reason >>>>> and knows that the server supports "plain". >>>> >>>> >>>> But then 7.2 is very vocal that it MUST NOT be used for new >>>> implementations: >>>> >>>> 7.2 >>>>> Because of this, "plain" SHOULD NOT be used, and exists only >>>>> for compatibility with deployed implementations where the request pat= h >>>>> is already protected. The "plain" method MUST NOT be used in >>>>> new implementations. >>>> >>>> >>>> What if those new implementations are constrained, as indicated in 4.= 2 >>>> and 4.4.1? >>>> >>>> >>>> Also, while S256 is clearly indicated as MTI, little is said about >>>> "plain", although it's alluded to that it's not MTI in 4.4.1 ("and kno= ws >>>> that the server supports "plain""). >>>> >>>> Should we be more explicit upfront that "plain" is optional for server= s >>>> to support, if that's the intention? >>>> >>>> >>>> On Tue, Jul 7, 2015 at 10:51 PM, William Denniss >>>> wrote: >>>> >>>>> t_m works for me, I just think we should have some indication that >>>>> it's the name of the transform. Will you also update where it is refe= renced >>>>> in the description below Figure 2? >>>>> >>>>> >>>>> >>>>> On Tue, Jul 7, 2015 at 6:28 PM, John Bradley >>>>> wrote: >>>>> >>>>>> Thanks, I fixed my finger dyslexia for the next draft. >>>>>> >>>>>> I changed it to t_m rather than =E2=80=9Ct=E2=80=9D I think that is= clearer. If I >>>>>> were to do it the other way XML2RFC would have double quotes in the = text >>>>>> version. >>>>>> >>>>>> John B. >>>>>> >>>>>> On Jul 7, 2015, at 9:38 PM, William Denniss >>>>>> wrote: >>>>>> >>>>>> In version 14, there's a typo on this line ("deso") in Section 7.2: >>>>>> >>>>>> `"plain" method deso not protect` >>>>>> >>>>>> Also, in the 1.1 Protocol Flow diagram, regarding the text: >>>>>> >>>>>> `+ t(code_verifier), t` >>>>>> >>>>>> I wonder if it makes more sense to represent as `+ t(code_verifier), >>>>>> "t"` (note the quotes on the second 't') given that it's a string >>>>>> representation of the method that's being sent? >>>>>> >>>>>> >>>>>> On Mon, Jul 6, 2015 at 4:05 PM, wrote: >>>>>> >>>>>>> >>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>>> directories. >>>>>>> This draft is a work item of the Web Authorization Protocol Workin= g >>>>>>> Group of the IETF. >>>>>>> >>>>>>> Title : Proof Key for Code Exchange by OAuth >>>>>>> Public Clients >>>>>>> Authors : Nat Sakimura >>>>>>> John Bradley >>>>>>> Naveen Agarwal >>>>>>> Filename : draft-ietf-oauth-spop-14.txt >>>>>>> Pages : 20 >>>>>>> Date : 2015-07-06 >>>>>>> >>>>>>> Abstract: >>>>>>> OAuth 2.0 public clients utilizing the Authorization Code Grant >>>>>>> are >>>>>>> susceptible to the authorization code interception attack. This >>>>>>> specification describes the attack as well as a technique to >>>>>>> mitigate >>>>>>> against the threat through the use of Proof Key for Code Exchang= e >>>>>>> (PKCE, pronounced "pixy"). >>>>>>> >>>>>>> >>>>>>> The IETF datatracker status page for this draft is: >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ >>>>>>> >>>>>>> There's also a htmlized version available at: >>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-spop-14 >>>>>>> >>>>>>> A diff from the previous version is available at: >>>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-spop-14 >>>>>>> >>>>>>> >>>>>>> Please note that it may take a couple of minutes from the time of >>>>>>> submission >>>>>>> until the htmlized version and diff are available at tools.ietf.org= . >>>>>>> >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@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 >>> >>> >> >> >> -- >> >> Best regards, >> Kathleen >> >> >> > --=20 Best regards, Kathleen --f46d044287e2898073051a87efda Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, Brian!

William? Are you good wi= th this version?

On Fri, Jul 10, 2015 at 12:11 PM, Brian Campbell <bcam= pbell@pingidentity.com> wrote:
I think -15 does address the inconsistency.

On Fri, Jul 10, 2015 at 9:36 AM, John Brad= ley <ve7jtb@ve7jtb.com> wrote:
Yes I believe I I addressed these = comments as part of Barry=E2=80=99s discuss points. =C2=A0
They were co= mments on the changes that Barry introduced that caused a inconsistency. = =C2=A0 I resolved that in 15.

I think it is good t= o go.


On Jul 10, 2015, at 12:29 PM, Kathleen Moriarty <kathleen.moriarty.ietf= @gmail.com> wrote:

John,

The updates were included in the version I approved for posting that= also addressed Barry's discuss points, correct?

Are we good with the current version to move forward:

Thank you,
Kathleen

On Thu, Jul 9, 2015 at 2:46 PM, J= ohn Bradley <ve7jtb@ve7jtb.com> wrote:
I have made some edits to= make it consistent.=C2=A0 They are checked into the butbucket repo nat and= I use, but we can=E2=80=99t update the official draft during the freeze be= fore the IETF meeting.

https://bitbucket.org/Nat/oauth-spop<= /div>

On Jul 9, 2015,= at 3:19 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

I agree with William that it's a little confusing. I= get that there's a desire to discourage using "plain" but pe= rhaps the language (especially the MUST NOT in 7.2) should be lightened up = just a bit?

On Wed, Jul 8, 2015 at 8:22 PM, William Denniss <= wdenniss@google.co= m> wrote:
=
Following up the discussion on today's NAPPS= call, I understand why plain is not presented as the recommended approach = in the spec (though it still has some value over not doing PKCE at all, in = that it mitigates against the current known attack where a rogue app regist= ers the same custom URI scheme as another), but I feel that after all the b= ack and forth the picture is a little confusing.

In particular, 4.2 = and 4.4.1 include some examples where plain is supported:

4.2
Clients SHOULD use the S256 = transformation.=C2=A0 The plain transformation is for compatibility with ex= isting deployments and for constrained environments that can't use the = S256 transformation.
=C2=A0
4.4.1.
If the client is capable of using "S256"= , it MUST use "S256", as "S256" is Mandatory To Impleme= nt (MTI) on the server.=C2=A0Clients are=C2=A0permitted to use "plain&= quot; only if they cannot support "S256" for some=C2=A0technical = reason and knows that the server supports "plain".
But then 7.2 is very vocal that it MUST NOT be used for new implementatio= ns:

7.2
Because of this, "plain" SHOUL= D NOT be used, and exists only for=C2=A0compatibility with deployed impleme= ntations where the request path is=C2=A0already protected.=C2=A0 The "= plain" method MUST NOT be used in new=C2=A0implementations.

=C2=A0Wha= t if those new implementations are constrained, as indicated in 4.2 and 4.4= .1?


Also, while S256 is clearly indicate= d as MTI, little is said about "plain", although it's alluded= to that it's not MTI in 4.4.1 ("and knows that the server support= s "plain"").

Should we be more explicit upfront that "plain&q= uot; is optional for servers to support, if that's the intention?
=

<= br>
On Tue, Jul 7, 2015 at 10:51 PM, Willia= m Denniss <wdenniss@google.com> wrote:
t_m works for me, I just think we should have some indica= tion that it's the=C2=A0name=C2=A0of the transform. Will you also updat= e where it is referenced in the description below Figure 2?

<= div>

On Tue, Jul 7, 2015 at 6:28 PM, John Bradley <ve7jtb@ve7jtb.c= om> wrote:
Thanks, I fixed my finger dyslexia for the next draft.

=
I changed it to t_m rather than =E2=80=9Ct=E2=80=9D =C2=A0I think that= is clearer.=C2=A0 If I were to do it the other way XML2RFC would have doub= le quotes in the text version.

John B.=C2=A0
<= div>
On Jul 7, 2015, at 9:38 PM, Wil= liam Denniss <w= denniss@google.com> wrote:

In version= 14, there's a typo on this line ("deso") in Section 7.2:
`"plain" meth= od deso not protect`

Also, in the 1.1 P= rotocol Flow diagram, regarding the text:

`+ t(code_verifier), t`

<= /div>I wonder if it makes more sense to represent as `+ t(code_verifier), "t"` (note the quotes o= n the second 't') given that it's a string representation of th= e method that's being sent?


On Mon, Jul 6, 2015 at 4:05 PM= , <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Web Authorization Protocol Working G= roup of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Proof Key for Code Exchange by OAuth Public Clients
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Nat = Sakimura
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Bradley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Naveen Agarwal
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-spop-14.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 20
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-07-06

Abstract:
=C2=A0 =C2=A0OAuth 2.0 public clients utilizing the Authorization Code Gran= t are
=C2=A0 =C2=A0susceptible to the authorization code interception attack.=C2= =A0 This
=C2=A0 =C2=A0specification describes the attack as well as a technique to m= itigate
=C2=A0 =C2=A0against the threat through the use of Proof Key for Code Excha= nge
=C2=A0 =C2=A0(PKCE, pronounced "pixy").


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-o= auth-spop/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-spo= p-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-oauth-spop-14


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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



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




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




--

Best regards,
Kathleen




--
=

Best regards,
Kathleen
--f46d044287e2898073051a87efda-- From nobody Fri Jul 10 09:57:48 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BEBF1B2A4D for ; Fri, 10 Jul 2015 09:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4tZn3t-RDHY for ; Fri, 10 Jul 2015 09:57:42 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EF521B2A3E for ; Fri, 10 Jul 2015 09:57:42 -0700 (PDT) Received: by qkcl188 with SMTP id l188so27516998qkc.1 for ; Fri, 10 Jul 2015 09:57:41 -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:content-type; bh=RZa2v1sF7ZQKuC53ne/Khgex+UwulQ/ppQyKOlT6fB0=; b=QM/N4no/3qZeSnU4UON56PgXVlzWpd+aHovMECEqOdvtjpErCMIfJgo9QHyXtzYaoD 0vuxQYeC2MJeOaCBdGVSn9U4HQEtis/0892vZPJ2bS8rzoDA0ulOfWJo7oXW5OtXZkWK S80j7SC5+SanEGxcGjZ6tA9/dsojOBNl7T/vAaMueeJesvauV5eV/YyvddHLxO6wXeoo WCJePrL1qyTj2Nl2KYsIAa4kbunPSMHMnGspHcPx0t06IAxzkNernCDQtUhpQL/ba+8w aB3Q88bfhgo2CDSHTBwkT/5wm2fw0i9sauuISbwtgcb2OE6agBfILBhOkebEKgrGpA8n YvxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=RZa2v1sF7ZQKuC53ne/Khgex+UwulQ/ppQyKOlT6fB0=; b=UoZYXO3fCTn+wgNGrnvFgitGhe0iqDuUhPBgx+K+wcU+B0G4Ja1Rwxw+l+yUSufJxS 3jSZc2ipgcLRLWYnwJfp7kg9PxWiTln3ETiS8/v3/D7Iap0xEboaQRSFmhO4RXs12fYj Keo1aUoS2YElFk4ZGgZAZRnjRrlprM7Dma/PuCJOhHGNsqN1VMughFR2f3kcy+sxadOX BIZSqShFMcDBkk3cXkny+hZGKNu6fVM5nhgQ8fnVeDbmNShiiY6ev15Kk8W5L/NexJc6 BWg5keOK8FYFIbKl63ho9dbxSe06jpcWDePN0odJhVzbMPQyRhZDRt8UZpVoM4FPXqPJ oSeQ== X-Gm-Message-State: ALoCoQmWiqDJTlxIc4m+xiV0ZQ1AzVW+KNrj3tprJgCWmCCt0pCJ7AaNFDUHp2nyF1LzJH1ux0t1 X-Received: by 10.55.27.89 with SMTP id b86mr33677458qkb.20.1436547461600; Fri, 10 Jul 2015 09:57:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.19.98 with HTTP; Fri, 10 Jul 2015 09:57:22 -0700 (PDT) In-Reply-To: References: <20150706230550.12450.15077.idtracker@ietfa.amsl.com> <68C4B3E0-0A40-4035-A6B8-EB553573BE5D@ve7jtb.com> <0A42C02A-77C6-48DD-8BEC-52B31570FBAF@ve7jtb.com> From: William Denniss Date: Fri, 10 Jul 2015 09:57:22 -0700 Message-ID: To: Kathleen Moriarty Content-Type: multipart/alternative; boundary=001a1147e7b2270017051a88454a Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-14.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 16:57:45 -0000 --001a1147e7b2270017051a88454a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Looks good to me. I think it's a lot clearer now, thanks for the update John. Unrelated, I noticed a typo in "7.5. TLS security considerations", the word 'Curent'. On Fri, Jul 10, 2015 at 9:33 AM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Thanks, Brian! > > William? Are you good with this version? > > On Fri, Jul 10, 2015 at 12:11 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> I think -15 does address the inconsistency. >> >> On Fri, Jul 10, 2015 at 9:36 AM, John Bradley wrote: >> >>> Yes I believe I I addressed these comments as part of Barry=E2=80=99s d= iscuss >>> points. >>> They were comments on the changes that Barry introduced that caused a >>> inconsistency. I resolved that in 15. >>> >>> I think it is good to go. >>> >>> >>> On Jul 10, 2015, at 12:29 PM, Kathleen Moriarty < >>> kathleen.moriarty.ietf@gmail.com> wrote: >>> >>> John, >>> >>> The updates were included in the version I approved for posting that >>> also addressed Barry's discuss points, correct? >>> >>> Are we good with the current version to move forward: >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ >>> >>> Thank you, >>> Kathleen >>> >>> On Thu, Jul 9, 2015 at 2:46 PM, John Bradley wrote: >>> >>>> I have made some edits to make it consistent. They are checked into >>>> the butbucket repo nat and I use, but we can=E2=80=99t update the offi= cial draft >>>> during the freeze before the IETF meeting. >>>> >>>> https://bitbucket.org/Nat/oauth-spop >>>> >>>> On Jul 9, 2015, at 3:19 PM, Brian Campbell >>>> wrote: >>>> >>>> I agree with William that it's a little confusing. I get that there's = a >>>> desire to discourage using "plain" but perhaps the language (especiall= y the >>>> MUST NOT in 7.2) should be lightened up just a bit? >>>> >>>> On Wed, Jul 8, 2015 at 8:22 PM, William Denniss >>>> wrote: >>>> >>>>> Following up the discussion on today's NAPPS call, I understand why >>>>> plain is not presented as the recommended approach in the spec (thoug= h it >>>>> still has some value over not doing PKCE at all, in that it mitigates >>>>> against the current known attack where a rogue app registers the same >>>>> custom URI scheme as another), but I feel that after all the back and= forth >>>>> the picture is a little confusing. >>>>> >>>>> In particular, 4.2 and 4.4.1 include some examples where plain is >>>>> supported: >>>>> >>>>> 4.2 >>>>>> Clients SHOULD use the S256 transformation. The plain transformatio= n >>>>>> is for compatibility with existing deployments and for constrained >>>>>> environments that can't use the S256 transformation. >>>>>> >>>>> >>>>> >>>>> 4.4.1. >>>>>> If the client is capable of using "S256", it MUST use "S256", as >>>>>> "S256" is Mandatory To Implement (MTI) on the server. Clients are pe= rmitted >>>>>> to use "plain" only if they cannot support "S256" for some technical= reason >>>>>> and knows that the server supports "plain". >>>>> >>>>> >>>>> But then 7.2 is very vocal that it MUST NOT be used for new >>>>> implementations: >>>>> >>>>> 7.2 >>>>>> Because of this, "plain" SHOULD NOT be used, and exists only >>>>>> for compatibility with deployed implementations where the request pa= th >>>>>> is already protected. The "plain" method MUST NOT be used in >>>>>> new implementations. >>>>> >>>>> >>>>> What if those new implementations are constrained, as indicated in >>>>> 4.2 and 4.4.1? >>>>> >>>>> >>>>> Also, while S256 is clearly indicated as MTI, little is said about >>>>> "plain", although it's alluded to that it's not MTI in 4.4.1 ("and kn= ows >>>>> that the server supports "plain""). >>>>> >>>>> Should we be more explicit upfront that "plain" is optional for >>>>> servers to support, if that's the intention? >>>>> >>>>> >>>>> On Tue, Jul 7, 2015 at 10:51 PM, William Denniss >>>>> wrote: >>>>> >>>>>> t_m works for me, I just think we should have some indication that >>>>>> it's the name of the transform. Will you also update where it is ref= erenced >>>>>> in the description below Figure 2? >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jul 7, 2015 at 6:28 PM, John Bradley >>>>>> wrote: >>>>>> >>>>>>> Thanks, I fixed my finger dyslexia for the next draft. >>>>>>> >>>>>>> I changed it to t_m rather than =E2=80=9Ct=E2=80=9D I think that i= s clearer. If I >>>>>>> were to do it the other way XML2RFC would have double quotes in the= text >>>>>>> version. >>>>>>> >>>>>>> John B. >>>>>>> >>>>>>> On Jul 7, 2015, at 9:38 PM, William Denniss >>>>>>> wrote: >>>>>>> >>>>>>> In version 14, there's a typo on this line ("deso") in Section 7.2: >>>>>>> >>>>>>> `"plain" method deso not protect` >>>>>>> >>>>>>> Also, in the 1.1 Protocol Flow diagram, regarding the text: >>>>>>> >>>>>>> `+ t(code_verifier), t` >>>>>>> >>>>>>> I wonder if it makes more sense to represent as `+ >>>>>>> t(code_verifier), "t"` (note the quotes on the second 't') given >>>>>>> that it's a string representation of the method that's being sent? >>>>>>> >>>>>>> >>>>>>> On Mon, Jul 6, 2015 at 4:05 PM, wrote: >>>>>>> >>>>>>>> >>>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>>>> directories. >>>>>>>> This draft is a work item of the Web Authorization Protocol >>>>>>>> Working Group of the IETF. >>>>>>>> >>>>>>>> Title : Proof Key for Code Exchange by OAuth >>>>>>>> Public Clients >>>>>>>> Authors : Nat Sakimura >>>>>>>> John Bradley >>>>>>>> Naveen Agarwal >>>>>>>> Filename : draft-ietf-oauth-spop-14.txt >>>>>>>> Pages : 20 >>>>>>>> Date : 2015-07-06 >>>>>>>> >>>>>>>> Abstract: >>>>>>>> OAuth 2.0 public clients utilizing the Authorization Code Grant >>>>>>>> are >>>>>>>> susceptible to the authorization code interception attack. Thi= s >>>>>>>> specification describes the attack as well as a technique to >>>>>>>> mitigate >>>>>>>> against the threat through the use of Proof Key for Code Exchan= ge >>>>>>>> (PKCE, pronounced "pixy"). >>>>>>>> >>>>>>>> >>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ >>>>>>>> >>>>>>>> There's also a htmlized version available at: >>>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-spop-14 >>>>>>>> >>>>>>>> A diff from the previous version is available at: >>>>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-spop-14 >>>>>>>> >>>>>>>> >>>>>>>> Please note that it may take a couple of minutes from the time of >>>>>>>> submission >>>>>>>> until the htmlized version and diff are available at tools.ietf.or= g >>>>>>>> . >>>>>>>> >>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>> >>> >>> -- >>> >>> Best regards, >>> Kathleen >>> >>> >>> >> > > > -- > > Best regards, > Kathleen > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a1147e7b2270017051a88454a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Looks good to me. I think it's a lot clearer now, than= ks for the update John.

Unrelated, I noticed a typo in= =C2=A0&= quot;7.5.=C2=A0 TLS security considerations", the word 'Curent'= ;.

On Fri, Jul 10, 2015 at 9:33 AM, Kathleen Moriarty &l= t;kat= hleen.moriarty.ietf@gmail.com> wrote:
Thanks, Brian!

William? Are = you good with this version?

On Fri, Jul 10, 2015 at 12:11 = PM, Brian Campbell <bcampbell@pingidentity.com> wro= te:
I think -15 doe= s address the inconsistency.

On Fri, Jul 10, 2015 at 9:36 AM, John = Bradley <ve7jtb@ve7jtb.com> wrote:
Yes I believe I I addressed = these comments as part of Barry=E2=80=99s discuss points. =C2=A0
They w= ere comments on the changes that Barry introduced that caused a inconsisten= cy. =C2=A0 I resolved that in 15.

I think it is go= od to go.


On Jul 10, 2015, at 12:29 PM, Kathleen Moriarty <kathleen.moriarty.= ietf@gmail.com> wrote:

John,

=
The updates were included in the version I approved for posting = that also addressed Barry's discuss points, correct?

Are we good with the current version to move forward:

On Thu, Jul 9, 2015 at 2:46 PM= , John Bradley <ve7jtb@ve7jtb.com> wrote:
I have made some edits = to make it consistent.=C2=A0 They are checked into the butbucket repo nat a= nd I use, but we can=E2=80=99t update the official draft during the freeze = before the IETF meeting.



<= div>
I agree with William that it's a little confusing.= I get that there's a desire to discourage using "plain" but = perhaps the language (especially the MUST NOT in 7.2) should be lightened u= p just a bit?

On Wed, Jul 8, 2015 at 8:22 PM, William Denniss &l= t;wdenniss@google.= com> wrote:
Following up the discussion on today's NAP= PS call, I understand why plain is not presented as the recommended approac= h in the spec (though it still has some value over not doing PKCE at all, i= n that it mitigates against the current known attack where a rogue app regi= sters the same custom URI scheme as another), but I feel that after all the= back and forth the picture is a little confusing.

In particular, 4.= 2 and 4.4.1 include some examples where plain is supported:

4.2
Clients SHOULD use the S25= 6 transformation.=C2=A0 The plain transformation is for compatibility with = existing deployments and for constrained environments that can't use th= e S256 transformation.
=C2=A0
=
4.4.1.
If the client is capable of using "S256&quo= t;, it MUST use "S256", as "S256" is Mandatory To Imple= ment (MTI) on the server.=C2=A0Clients are=C2=A0permitted to use "plai= n" only if they cannot support "S256" for some=C2=A0technica= l reason and knows that the server supports "plain".
=
But then 7.2 is very vocal that it MUST NOT be used for new implementat= ions:

7.2
Because of this, "plain" SHO= ULD NOT be used, and exists only for=C2=A0compatibility with deployed imple= mentations where the request path is=C2=A0already protected.=C2=A0 The &quo= t;plain" method MUST NOT be used in new=C2=A0implementations.

=C2=A0W= hat if those new implementations are constrained, as indicated in 4.2 and 4= .4.1?


Also, while S256 is clearly indica= ted as MTI, little is said about "plain", although it's allud= ed to that it's not MTI in 4.4.1 ("and knows that the server suppo= rts "plain"").

Should we be more explicit upfront that "plain= " is optional for servers to support, if that's the intention?


On Tue, Jul 7, 2015 at 10:51 PM, Will= iam Denniss <wdenniss@google.com> wrote:
t_m works for me, I just think we should have some indi= cation that it's the=C2=A0name=C2=A0of the transform. Will you also upd= ate where it is referenced in the description below Figure 2?



On Tue, Jul 7, 2015 at 6:28 PM, John Bradley <ve7jtb@ve7j= tb.com> wrote:
Thanks, I fixed my finger dyslexia for the next draft.

I changed it to t_m rather than =E2=80=9Ct=E2=80=9D =C2=A0I think = that is clearer.=C2=A0 If I were to do it the other way XML2RFC would have = double quotes in the text version.

John B.=C2=A0

On Jul 7, 2015, at 9:38 PM,= William Denniss <wdenniss@google.com> wrote:

In ver= sion 14, there's a typo on this line ("deso") in Section 7.2:=

`"plain" = method deso not protect`

Also, in the 1= .1 Protocol Flow diagram, regarding the text:

`+ t(code_verifier), t`

I wonder if it makes more sense to represent as `+ t(code_verifier), "t"` (note the quot= es on the second 't') given that it's a string representation o= f the method that's being sent?


On Mon, Jul 6, 2015 at 4:0= 5 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Web Authorization Protocol Working G= roup of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Proof Key for Code Exchange by OAuth Public Clients
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Nat = Sakimura
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Bradley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Naveen Agarwal
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-spop-14.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 20
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-07-06

Abstract:
=C2=A0 =C2=A0OAuth 2.0 public clients utilizing the Authorization Code Gran= t are
=C2=A0 =C2=A0susceptible to the authorization code interception attack.=C2= =A0 This
=C2=A0 =C2=A0specification describes the attack as well as a technique to m= itigate
=C2=A0 =C2=A0against the threat through the use of Proof Key for Code Excha= nge
=C2=A0 =C2=A0(PKCE, pronounced "pixy").


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-o= auth-spop/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-spo= p-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-oauth-spop-14


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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



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




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




--

Best regards,
Kathleen




<= /div>--

Best regards,
Kathleen
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--001a1147e7b2270017051a88454a-- From nobody Fri Jul 10 09:59:16 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7881B2A5B for ; Fri, 10 Jul 2015 09:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMOyp_ibneN4 for ; Fri, 10 Jul 2015 09:59:09 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::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 A077E1B2A4B for ; Fri, 10 Jul 2015 09:59:07 -0700 (PDT) Received: by wgjx7 with SMTP id x7so253993706wgj.2 for ; Fri, 10 Jul 2015 09:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=C+PKIuefV3Q5ZmQDlSzpY7eP61VXFBa9eAvcb6+aBX0=; b=gIRIr7r78KEZdhUECcFC7r1RwYSCk+JNUQdfZUotalMTWkHtG2d5J0GjMtI1mNhReO IDZL0uVS2FFc4uIn7CuZTlGlwm9myjZNSQlJ9fEEvLZQv/QA5EEAjs+LQF02oVkEGX+h 5KPBxEVL/g4uOMuWS5u8Ofv0K5Ilf+vmx741L6oyj2CiBblN1ZhGz4w4Q0UxL0ID8ImH jj2E7oGr55XifsZDuUDekE4lSQ5FSDIS4yj74RboF06EF3RoVCHho8+VbwIkp1Nhggur 88ghnFfR4Q2yK8KoIH+cAFJh1p4Ks8CXtOW9Bc9h3sah/M71ZDBBEIobBc2PYL9lcjnM AOZg== MIME-Version: 1.0 X-Received: by 10.180.86.168 with SMTP id q8mr7577172wiz.80.1436547546437; Fri, 10 Jul 2015 09:59:06 -0700 (PDT) Received: by 10.28.31.194 with HTTP; Fri, 10 Jul 2015 09:59:06 -0700 (PDT) In-Reply-To: References: <20150706230550.12450.15077.idtracker@ietfa.amsl.com> <68C4B3E0-0A40-4035-A6B8-EB553573BE5D@ve7jtb.com> <0A42C02A-77C6-48DD-8BEC-52B31570FBAF@ve7jtb.com> Date: Fri, 10 Jul 2015 12:59:06 -0400 Message-ID: From: Kathleen Moriarty To: William Denniss Content-Type: multipart/alternative; boundary=bcaec5555030355e05051a884a2c Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-14.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 16:59:13 -0000 --bcaec5555030355e05051a884a2c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you all for your work on this draft! On Fri, Jul 10, 2015 at 12:57 PM, William Denniss wrote: > Looks good to me. I think it's a lot clearer now, thanks for the update > John. > > Unrelated, I noticed a typo in "7.5. TLS security considerations", the > word 'Curent'. > > On Fri, Jul 10, 2015 at 9:33 AM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >> Thanks, Brian! >> >> William? Are you good with this version? >> >> On Fri, Jul 10, 2015 at 12:11 PM, Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >>> I think -15 does address the inconsistency. >>> >>> On Fri, Jul 10, 2015 at 9:36 AM, John Bradley wrote= : >>> >>>> Yes I believe I I addressed these comments as part of Barry=E2=80=99s = discuss >>>> points. >>>> They were comments on the changes that Barry introduced that caused a >>>> inconsistency. I resolved that in 15. >>>> >>>> I think it is good to go. >>>> >>>> >>>> On Jul 10, 2015, at 12:29 PM, Kathleen Moriarty < >>>> kathleen.moriarty.ietf@gmail.com> wrote: >>>> >>>> John, >>>> >>>> The updates were included in the version I approved for posting that >>>> also addressed Barry's discuss points, correct? >>>> >>>> Are we good with the current version to move forward: >>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ >>>> >>>> Thank you, >>>> Kathleen >>>> >>>> On Thu, Jul 9, 2015 at 2:46 PM, John Bradley wrote= : >>>> >>>>> I have made some edits to make it consistent. They are checked into >>>>> the butbucket repo nat and I use, but we can=E2=80=99t update the off= icial draft >>>>> during the freeze before the IETF meeting. >>>>> >>>>> https://bitbucket.org/Nat/oauth-spop >>>>> >>>>> On Jul 9, 2015, at 3:19 PM, Brian Campbell >>>>> wrote: >>>>> >>>>> I agree with William that it's a little confusing. I get that there's >>>>> a desire to discourage using "plain" but perhaps the language (especi= ally >>>>> the MUST NOT in 7.2) should be lightened up just a bit? >>>>> >>>>> On Wed, Jul 8, 2015 at 8:22 PM, William Denniss >>>>> wrote: >>>>> >>>>>> Following up the discussion on today's NAPPS call, I understand why >>>>>> plain is not presented as the recommended approach in the spec (thou= gh it >>>>>> still has some value over not doing PKCE at all, in that it mitigate= s >>>>>> against the current known attack where a rogue app registers the sam= e >>>>>> custom URI scheme as another), but I feel that after all the back an= d forth >>>>>> the picture is a little confusing. >>>>>> >>>>>> In particular, 4.2 and 4.4.1 include some examples where plain is >>>>>> supported: >>>>>> >>>>>> 4.2 >>>>>>> Clients SHOULD use the S256 transformation. The plain >>>>>>> transformation is for compatibility with existing deployments and f= or >>>>>>> constrained environments that can't use the S256 transformation. >>>>>>> >>>>>> >>>>>> >>>>>> 4.4.1. >>>>>>> If the client is capable of using "S256", it MUST use "S256", as >>>>>>> "S256" is Mandatory To Implement (MTI) on the server. Clients are p= ermitted >>>>>>> to use "plain" only if they cannot support "S256" for some technica= l reason >>>>>>> and knows that the server supports "plain". >>>>>> >>>>>> >>>>>> But then 7.2 is very vocal that it MUST NOT be used for new >>>>>> implementations: >>>>>> >>>>>> 7.2 >>>>>>> Because of this, "plain" SHOULD NOT be used, and exists only >>>>>>> for compatibility with deployed implementations where the request p= ath >>>>>>> is already protected. The "plain" method MUST NOT be used in >>>>>>> new implementations. >>>>>> >>>>>> >>>>>> What if those new implementations are constrained, as indicated in >>>>>> 4.2 and 4.4.1? >>>>>> >>>>>> >>>>>> Also, while S256 is clearly indicated as MTI, little is said about >>>>>> "plain", although it's alluded to that it's not MTI in 4.4.1 ("and k= nows >>>>>> that the server supports "plain""). >>>>>> >>>>>> Should we be more explicit upfront that "plain" is optional for >>>>>> servers to support, if that's the intention? >>>>>> >>>>>> >>>>>> On Tue, Jul 7, 2015 at 10:51 PM, William Denniss >>>>> > wrote: >>>>>> >>>>>>> t_m works for me, I just think we should have some indication that >>>>>>> it's the name of the transform. Will you also update where it is re= ferenced >>>>>>> in the description below Figure 2? >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Jul 7, 2015 at 6:28 PM, John Bradley >>>>>>> wrote: >>>>>>> >>>>>>>> Thanks, I fixed my finger dyslexia for the next draft. >>>>>>>> >>>>>>>> I changed it to t_m rather than =E2=80=9Ct=E2=80=9D I think that = is clearer. If I >>>>>>>> were to do it the other way XML2RFC would have double quotes in th= e text >>>>>>>> version. >>>>>>>> >>>>>>>> John B. >>>>>>>> >>>>>>>> On Jul 7, 2015, at 9:38 PM, William Denniss >>>>>>>> wrote: >>>>>>>> >>>>>>>> In version 14, there's a typo on this line ("deso") in Section 7.2= : >>>>>>>> >>>>>>>> `"plain" method deso not protect` >>>>>>>> >>>>>>>> Also, in the 1.1 Protocol Flow diagram, regarding the text: >>>>>>>> >>>>>>>> `+ t(code_verifier), t` >>>>>>>> >>>>>>>> I wonder if it makes more sense to represent as `+ >>>>>>>> t(code_verifier), "t"` (note the quotes on the second 't') given >>>>>>>> that it's a string representation of the method that's being sent? >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Jul 6, 2015 at 4:05 PM, wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> A New Internet-Draft is available from the on-line Internet-Draft= s >>>>>>>>> directories. >>>>>>>>> This draft is a work item of the Web Authorization Protocol >>>>>>>>> Working Group of the IETF. >>>>>>>>> >>>>>>>>> Title : Proof Key for Code Exchange by OAuth >>>>>>>>> Public Clients >>>>>>>>> Authors : Nat Sakimura >>>>>>>>> John Bradley >>>>>>>>> Naveen Agarwal >>>>>>>>> Filename : draft-ietf-oauth-spop-14.txt >>>>>>>>> Pages : 20 >>>>>>>>> Date : 2015-07-06 >>>>>>>>> >>>>>>>>> Abstract: >>>>>>>>> OAuth 2.0 public clients utilizing the Authorization Code Gran= t >>>>>>>>> are >>>>>>>>> susceptible to the authorization code interception attack. Th= is >>>>>>>>> specification describes the attack as well as a technique to >>>>>>>>> mitigate >>>>>>>>> against the threat through the use of Proof Key for Code >>>>>>>>> Exchange >>>>>>>>> (PKCE, pronounced "pixy"). >>>>>>>>> >>>>>>>>> >>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ >>>>>>>>> >>>>>>>>> There's also a htmlized version available at: >>>>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-spop-14 >>>>>>>>> >>>>>>>>> A diff from the previous version is available at: >>>>>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-spop-14 >>>>>>>>> >>>>>>>>> >>>>>>>>> Please note that it may take a couple of minutes from the time of >>>>>>>>> submission >>>>>>>>> until the htmlized version and diff are available at >>>>>>>>> tools.ietf.org. >>>>>>>>> >>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@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 >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> Best regards, >>>> Kathleen >>>> >>>> >>>> >>> >> >> >> -- >> >> Best regards, >> Kathleen >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > --=20 Best regards, Kathleen --bcaec5555030355e05051a884a2c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you all for your work on this draft!

<= div>

On Fri, Jul 10, 2015 at 12:57 PM, William Denniss <= wdenniss@google.co= m> wrote:
= Looks good to me. I think it's a lot clearer now, thanks for the update= John.

Unrelated, I noticed a typo in=C2=A0"7.5.=C2=A0 T= LS security considerations", the word 'Curent'.

=
On Fri, Jul 10, 2015 at 9:33 AM, Kathleen Moriar= ty <kathleen.moriarty.ietf@gmail.com> wrote:<= br>
Thanks, Brian!

<= /div>
William? Are you good with this version?

On Fri, Jul 10, 2015= at 12:11 PM, Brian Campbell <bcampbell@pingidentity.com><= /span> wrote:
I thi= nk -15 does address the inconsistency.

On Fri, Jul 10, 2015 at 9:3= 6 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Yes I believe I I a= ddressed these comments as part of Barry=E2=80=99s discuss points. =C2=A0They were comments on the changes that Barry introduced that caused a in= consistency. =C2=A0 I resolved that in 15.

I think= it is good to go.


On Jul 10, 2015, at 12:29 PM, Kathleen Moriarty <kathleen.= moriarty.ietf@gmail.com> wrote:

John,=

The updates were included in the version I approved for= posting that also addressed Barry's discuss points, correct?

Are we good with the current version to move forward:
=

Thank you,
Kathleen

On Thu, Jul 9, 2015 a= t 2:46 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I have made so= me edits to make it consistent.=C2=A0 They are checked into the butbucket r= epo nat and I use, but we can=E2=80=99t update the official draft during th= e freeze before the IETF meeting.


On J= ul 9, 2015, at 3:19 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
I agree with William that it's a little c= onfusing. I get that there's a desire to discourage using "plain&q= uot; but perhaps the language (especially the MUST NOT in 7.2) should be li= ghtened up just a bit?

On Wed, Jul 8, 2015 at 8:22 PM, William Denniss <wdenn= iss@google.com> wrote:
Following up the discussion on toda= y's NAPPS call, I understand why plain is not presented as the recommen= ded approach in the spec (though it still has some value over not doing PKC= E at all, in that it mitigates against the current known attack where a rog= ue app registers the same custom URI scheme as another), but I feel that af= ter all the back and forth the picture is a little confusing.

In par= ticular, 4.2 and 4.4.1 include some examples where plain is supported:
<= br>
4.2
Clients SHOULD = use the S256 transformation.=C2=A0 The plain transformation is for compatib= ility with existing deployments and for constrained environments that can&#= 39;t use the S256 transformation.
=C2=A0
4.4.1.
If the client is capable of using &qu= ot;S256", it MUST use "S256", as "S256" is Mandato= ry To Implement (MTI) on the server.=C2=A0Clients are=C2=A0permitted to use= "plain" only if they cannot support "S256" for some=C2= =A0technical reason and knows that the server supports "plain".
But then 7.2 is very vocal that it MUST NOT be used for new = implementations:

7.2
Because of this, "plai= n" SHOULD NOT be used, and exists only for=C2=A0compatibility with dep= loyed implementations where the request path is=C2=A0already protected.=C2= =A0 The "plain" method MUST NOT be used in new=C2=A0implementatio= ns.

=C2=A0What if those new implementations are constrained, as indicated = in 4.2 and 4.4.1?


Also, while S256 is c= learly indicated as MTI, little is said about "plain", although i= t's alluded to that it's not MTI in 4.4.1 ("and knows that the= server supports "plain"").
=
Should we be more explicit upfront tha= t "plain" is optional for servers to support, if that's the i= ntention?


On Tue, Jul 7, 2015 at 1= 0:51 PM, William Denniss <wdenniss@google.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">
t_m works for me, I just think we should h= ave some indication that it's the=C2=A0name=C2=A0of the transform. Will= you also update where it is referenced in the description below Figure 2?<= div>

On Tue, Jul 7, 2015 at 6:28 PM, John Bradley <= ve7jtb@ve7jtb.com> wrote:
Thanks, I fixed my finger dyslexia for the next draft.=

I changed it to t_m rather than =E2=80=9Ct=E2=80=9D =C2= =A0I think that is clearer.=C2=A0 If I were to do it the other way XML2RFC = would have double quotes in the text version.

John= B.=C2=A0

On Jul 7, 2015, = at 9:38 PM, William Denniss <wdenniss@google.com> wrote:

In version 14, there's a typo on this line ("deso") in S= ection 7.2:

`"p= lain" method deso not protect`

Als= o, in the 1.1 Protocol Flow diagram, regarding the text:

`+ t(code_verifier), t`

I wonder if it makes more sense to represent as `+ t(code_verifier), "t"` (no= te the quotes on the second 't') given that it's a string repre= sentation of the method that's being sent?


=
On Mon, Jul 6, = 2015 at 4:05 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Web Authorization Protocol Working G= roup of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Proof Key for Code Exchange by OAuth Public Clients
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Nat = Sakimura
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Bradley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Naveen Agarwal
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-spop-14.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 20
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-07-06

Abstract:
=C2=A0 =C2=A0OAuth 2.0 public clients utilizing the Authorization Code Gran= t are
=C2=A0 =C2=A0susceptible to the authorization code interception attack.=C2= =A0 This
=C2=A0 =C2=A0specification describes the attack as well as a technique to m= itigate
=C2=A0 =C2=A0against the threat through the use of Proof Key for Code Excha= nge
=C2=A0 =C2=A0(PKCE, pronounced "pixy").


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-o= auth-spop/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-spo= p-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-oauth-spop-14


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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



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




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




--

Best regards,
Kathleen




<= /div>--

Be= st regards,
Kathleen
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth





--
=

Best regards,
Kathleen
--bcaec5555030355e05051a884a2c-- From nobody Fri Jul 10 13:48:49 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33EA21A00F9 for ; Fri, 10 Jul 2015 13:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYcLpeFb3DaB for ; Fri, 10 Jul 2015 13:48:45 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3EE11A0093 for ; Fri, 10 Jul 2015 13:48:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 81AD9E2035 for ; Fri, 10 Jul 2015 16:48:44 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 05441-08 for ; Fri, 10 Jul 2015 16:48:43 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 2BBFBE2034 for ; Fri, 10 Jul 2015 16:48:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1436561323; bh=tM1RJNTqQgw8eJkSVT6FGCYvbLoqA3cD1ire2LGDIjY=; h=From:To:Subject:Date; b=Tn5couYGANyNbD6D/Tc9kh6Uzu3AYspT3UVkls9yY4x9o/jTo5he+ZV2d7HeKAbC3 LkyUx2InIAraFekO4/+p6ioXA8W05wljYJ1Ov3FQiNmPbFeS94ggVDATFt0TSV09QA xLjL22nZJGYKmNESdmLWc0HX79GX/rfyvW38TByI= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t6AKmgNI028507; Fri, 10 Jul 2015 16:48:42 -0400 From: Derek Atkins To: oauth@ietf.org Date: Fri, 10 Jul 2015 16:48:42 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: [OAUTH-WG] Review of draft-ietf-oauth-pop-architecture X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 20:48:47 -0000 Hi, In performing my shephard review of draft-ietf-oauth-pop-architecture I found one issue that was bugging me: you talk about target naming "too late" in the draft. I.e., as I was reading through section 3.1 about token reuse I think it doesn't have enough detail about how you would prevent server A asking the client for a token for a resource of server B, and then server A acting as the client for server B? I.e., how do you prevent server A acting as a MITM between the client and server B? (This is sort of the same question that resulted in TLS channel bindings). I know this target (scope) protection exists, and it's even discussed a bit later in the document but it's not even mentioned as a possible threat in 3.1, which seems like a glaring ommission. I'll create a more formal shephard review but I'd suggest some additional text to at least mention this threat in 3.1; you can provide a pointer to the protections then, too. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Jul 10 13:55:11 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113D21A00F9 for ; Fri, 10 Jul 2015 13:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elTHoM8YbEQu for ; Fri, 10 Jul 2015 13:55:08 -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 629D01A00FF for ; Fri, 10 Jul 2015 13:55:08 -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 t6AKt7C6005555 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Jul 2015 20:55:07 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 t6AKt762026204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 10 Jul 2015 20:55:07 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t6AKt6qa023368; Fri, 10 Jul 2015 20:55:06 GMT Received: from [10.0.1.3] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 10 Jul 2015 13:55:06 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Phil Hunt In-Reply-To: Date: Fri, 10 Jul 2015 13:55:04 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: To: Derek Atkins X-Mailer: Apple Mail (2.2102) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-pop-architecture X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 20:55:10 -0000 Thanks Derek, I will take a look at this. Phil @independentid www.independentid.com phil.hunt@oracle.com > On Jul 10, 2015, at 1:48 PM, Derek Atkins wrote: > > Hi, > > In performing my shephard review of draft-ietf-oauth-pop-architecture I > found one issue that was bugging me: you talk about target naming "too > late" in the draft. I.e., as I was reading through section 3.1 about > token reuse I think it doesn't have enough detail about how you would > prevent server A asking the client for a token for a resource of server > B, and then server A acting as the client for server B? I.e., how do > you prevent server A acting as a MITM between the client and server B? > (This is sort of the same question that resulted in TLS channel > bindings). > > I know this target (scope) protection exists, and it's even discussed a > bit later in the document but it's not even mentioned as a possible > threat in 3.1, which seems like a glaring ommission. > > I'll create a more formal shephard review but I'd suggest some > additional text to at least mention this threat in 3.1; you can provide > a pointer to the protections then, too. > > -derek > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Jul 10 15:01:29 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB4A1A0399; Fri, 10 Jul 2015 15:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vwzqsf3RFLC2; Fri, 10 Jul 2015 15:01:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E5FD91B2D1B; Fri, 10 Jul 2015 15:01:22 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150710220122.24087.51327.idtracker@ietfa.amsl.com> Date: Fri, 10 Jul 2015 15:01:22 -0700 Archived-At: Cc: oauth chair , oauth mailing list , RFC Editor Subject: [OAUTH-WG] Protocol Action: 'Proof Key for Code Exchange by OAuth Public Clients' to Proposed Standard (draft-ietf-oauth-spop-15.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 22:01:28 -0000 The IESG has approved the following document: - 'Proof Key for Code Exchange by OAuth Public Clients' (draft-ietf-oauth-spop-15.txt) as Proposed Standard This document is the product of the Web Authorization Protocol Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ Technical Summary OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat. Working Group Summary The working group last call for this document was started soon after the document was adopted as a WG item. A substantial number of comments were received and the subsequent document versions addressed those comments. No difficult decisions had to be made by the chairs or the group. Document Quality PingIdentity, Google, and Deutsche Telekom have implementations of the plain code challenge method. Additional information on implementations can be found in the shepherd report. Review from an ABNF expert is requested. Specific questions are included in the shepherd writeup. Personnel Hannes Tschofenig is the document shepherd and the responsible area director is Kathleen Moriarty. IANA Note This document allocates three new parameters to the existing OAuth parameter registry (see Section 6.1) and creates a new registry called 'PKCE Code Challenge Method' registry, with expert review required, RFC5226. This document adds two values to the PKCE Code Challenge Method registry, as defined in Section 6.2.2. From nobody Mon Jul 13 06:57:43 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 145D61B2AFF for ; Mon, 13 Jul 2015 06:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56Qe7kbqA4xG for ; Mon, 13 Jul 2015 06:57:41 -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 7915C1B2AF6 for ; Mon, 13 Jul 2015 06:57:41 -0700 (PDT) Received: from [192.168.131.129] ([195.149.223.246]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lz3rc-1YsUgl2Dmi-014GDw for ; Mon, 13 Jul 2015 15:57:39 +0200 Message-ID: <55A3C3D5.1020507@gmx.net> Date: Mon, 13 Jul 2015 15:57:41 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="II9j7PQGO9uFAKvEjn2kKStEIS2V2tt9T" X-Provags-ID: V03:K0:uh9FYkVfoEiWx2pTWekZ9hfz68x9uVp6NCDpR4d3LPf+Xu6ISSB 86fYtxh4GmVEYm8kTFsCyWJZC5ID32a1ftF7uPO+WDQGhXZ5ZHZUqxW+5R37W3VEvYY8kau reyMM7uA6BgpWGfGFittA2e94WjqOYMnYVJrkzvQHIwKIHjezscbZeDGeNay9SP6xQOERk4 JpbLOywiclERzulEADASQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:cT+tYEcxVkg=:jrFQ9VplhahQkCiTnpi71L nUFoYIoe+kENcSc5FRS6dMV4In06zhB0lpkYQgpIxMevsm7fYTuUU4yRYN3M6ZW3Cafx0te56 taD/gRt5X7N+WDMvy87bUsmX03SnDGQZEmrjpBWLfJ/WKDtwfEllir385HeZ3RU3j8f93pAND dSRmVsK53E4f2YW2y+8vMz4mfdJVheaIz4e8a6g+v9sSFjC7PTaZRg8ZRWelMsbzSVJxwqUdZ dL+7ATxEKAIIuJP4NWphaT9teZRSfZBmk4+42xPcJsCI+wV2KbbjR4+wtXqjVX23BrTWqtWf2 8o2PZkHV8q2eIqerLao52G4bh/Dxw5Bt87iph1OXA8HHzCmh71K35N9lVo68X0sVJsDdXx/Ua /m3BsuAVncjOx3Py9uNPqFtgkqZQeBE8sKQI/RPFmSyw1Rm0Obz1McPzVMFgx5Tl5msjffnw3 0Mhj8RZnxYEIrjQuPTzyaYiPQMsei0Apvm0hHsO/hurm//Lp6+2Y2Wl9OmyHtG3rcckwidRM5 X2tDFzpEfNVqb9UtfBePL/vaxwROS85Cwwwj9xDjxIrn4TFzRi36NBZnBQIG/28yuVLRft4Ne HrRQO5rYpCSrByXjGZ9009u2+tVd7zhejnmjhxJBZu7gLv5APxNjRnRuMsdmbcEYIVRnEXD8P Xgt+eeDPvzLI6KDD6l9ICwZ5S//G37YbcArHJDNxIWYXaxw== Archived-At: Subject: [OAUTH-WG] Agenda X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 13:57:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --II9j7PQGO9uFAKvEjn2kKStEIS2V2tt9T Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, here is a proposal for the meeting agenda: https://www.ietf.org/proceedings/93/agenda/agenda-93-oauth Let me know if something needs to be correct or is missing. The priority is again with the working group items, namely * token exchange, * PoP, and * Request by JWS ver.1.0 for OAuth 2.0. For the token exchange discussion I put Brian on the spot. It would be great to make progres with these document so that we can keep our good pace. Ciao Hannes --II9j7PQGO9uFAKvEjn2kKStEIS2V2tt9T Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVo8PVAAoJEGhJURNOOiAtIHMH/Ry6JEfmOm5ZfImQe3+wcRrP oO2yjwR/N6xSMvA6NAKj5DOqbIF4JuGArmiQ7XIjK9d19kukpE8s590pft25SuSB IWBY/Mz2MOzs7ZA3WBqgMflmlTVJnjVW82C54iE7cIIUUJb4EybtczHLYdGgFIvG MXAQLJlcKaiuqH30TxUAiKLQYIvkUffgyXA5AHHbKsAzh+/NPYW3JLWFjIxu8/GF ptOWca6VX0YXBjWtjWewVr7kAts8tPMsw1xJ9TAr5Plz7TUPL8NNL5oeaozjGA30 6gpk7XaIF9xefAhhnWBIUoYy4qmdiiwug6i8gSapSejL2/x10188Cp4992m/gvc= =xWG/ -----END PGP SIGNATURE----- --II9j7PQGO9uFAKvEjn2kKStEIS2V2tt9T-- From nobody Mon Jul 13 07:54:36 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923F01B2B65 for ; Mon, 13 Jul 2015 07:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOufU8sWOArb for ; Mon, 13 Jul 2015 07:54:33 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0A361B2B5A for ; Mon, 13 Jul 2015 07:54:32 -0700 (PDT) Received: by wibud3 with SMTP id ud3so32097434wib.1 for ; Mon, 13 Jul 2015 07:54:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=sFrt6AjgO1S6efJKuC9jsNtEKUnFD2I1e2qZQRdgIZQ=; b=Th8uLEtv9ZKULRHNWaI/dstwLdH+RzGw5lmnq2dRV3jcdSv6M2OKY6kuaPGzrKFENk X7ZRiXJGpJp1xc0aXS3FctazPOqO+H0fU95/4rKyWfNeoIqhHsShGL4DI8afhpZb0WnH PFrtFPQX745kFrtHPfgQy4bUQOXSpLFKjSiBuZUvVr59NxnYHNCXgNo0a4+TIpxce0YW PPlzfgNx/YehJ6pTLp0q/y3/DgWBRaD1hJvd3OlS0uNcS0vblGnJ+xTb72DgQz8uCSdX Z1QldB6ujnAdhUAp8k+J/KSLhSVkkO3NbwgyT8xhfE1emkS1wJey5AAlzt0N3XFgBahN jnCQ== X-Gm-Message-State: ALoCoQl56qLV7MyQPz6Dgg6m9kZ34jIiwmpMJuMxTHkEcMlmvXXEem1CfIF3PD2N0NbKK+wmRPlO X-Received: by 10.180.23.66 with SMTP id k2mr23283062wif.85.1436799271427; Mon, 13 Jul 2015 07:54:31 -0700 (PDT) Received: from [10.207.202.19] (host86-187-41-172.range86-187.btcentralplus.com. [86.187.41.172]) by smtp.gmail.com with ESMTPSA id di7sm15039591wib.23.2015.07.13.07.54.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 Jul 2015 07:54:30 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: John Bradley In-Reply-To: <55A3C3D5.1020507@gmx.net> Date: Mon, 13 Jul 2015 09:54:28 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4B7C8B57-0291-4663-9844-23805DD09174@ve7jtb.com> References: <55A3C3D5.1020507@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Agenda X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 14:54:34 -0000 The other thing that came up as CIS was a desire for AS initiated = OAuth/OpenID Connect. =20 Connect has a really cumbersome workaround due to OAuth not supporting = it. I did make a proposal as part of = https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state-04 This is a bit related to request by JWT. We should discuss if this is something the WG should address. John B. > On Jul 13, 2015, at 8:57 AM, Hannes Tschofenig = wrote: >=20 > Hi all, >=20 > here is a proposal for the meeting agenda: > https://www.ietf.org/proceedings/93/agenda/agenda-93-oauth >=20 > Let me know if something needs to be correct or is missing. >=20 > The priority is again with the working group items, namely > * token exchange, > * PoP, and > * Request by JWS ver.1.0 for OAuth 2.0. >=20 > For the token exchange discussion I put Brian on the spot. >=20 > It would be great to make progres with these document so that we can > keep our good pace. >=20 > Ciao > Hannes >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Jul 13 07:56:04 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879D11B2B65 for ; Mon, 13 Jul 2015 07:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3DxNp6boy0z for ; Mon, 13 Jul 2015 07:56:02 -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 E93E11B2B5A for ; Mon, 13 Jul 2015 07:56:01 -0700 (PDT) Received: from [192.168.131.129] ([195.149.223.246]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MRSeC-1ZPdTj09U0-00Sg1m; Mon, 13 Jul 2015 16:55:59 +0200 Message-ID: <55A3D15C.7000202@gmx.net> Date: Mon, 13 Jul 2015 16:55:24 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: John Bradley References: <55A3C3D5.1020507@gmx.net> <4B7C8B57-0291-4663-9844-23805DD09174@ve7jtb.com> In-Reply-To: <4B7C8B57-0291-4663-9844-23805DD09174@ve7jtb.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LAD8C1i7HxFqP1KVOcksASaqXLXXh6Pqi" X-Provags-ID: V03:K0:qnOaCvRs15Qtxfjlz5kP0Yu58NiYkbMPODrToHtKUeeSnvFtHZg 5P5G3dBChaP7RtMmCyVoDfbXuPmlWlvW8fiy2ERxX8K9WlGK+dcy+8jAikQNrT4y2il2iZM M9UGV6B8kHyQp4tElqYejoGKObeNk0AwECw0QQ7VjXt8ry2U0Qz6f40nDBE65QcqY6tPI5h vNS/ZCftvI4l3Dh/D45Ew== X-UI-Out-Filterresults: notjunk:1;V01:K0:CJQI7gDZ2Nw=:h6exUoE/oRwumsgsgNVAaf vjikB4Qek/xkQ0o82lL6DEIjyCYIBxKN9PiRcI13Xi7U0+TSAaPmvIrm8Y9r+cwPZgw4h+m6M gRleEA3hOoLCHWXwZLpLAmrAswYkWNF7IkMWn/sXa7KtEJKx6dvyxGPool0JdstYD3JBaKOnP PKivkPR5MNThRGvlXlRROfMwys+m+w8nSIuLfGnm/g96yJwTqRAV0TU2vkZ6vMsZdLnq0BrwL ZDu5FPjEojYNvyg5HA/Y2xT0++PDX4prItBcSXgjf7du3LcbvJ7os7CL9w/w4RKUeljs0XQpz LRzEe9XiLbSs+RVlmsB0fb39miLA6VrYUuBPTRZ/lwIIqovoSy8oIvGuRAj1JIOCNtpkfXFKs 9XmyCHvKUS2mZc31w5Msdl8sVvaQCrrUFaJZiLSSfL/Mmn/4pRE46agsqi+oriHpIADpqo+J1 TZAzPACZOXI0fTER5ni5RWXXcSGMpXCy9W4ch5z8JYQnEDmWhqcl0D7Vf+lwsyE/ur6gRB7w5 Mzj1P5cMVQh4aiQX2Hsa4iMLXZ0V9iSy1S8LkEzp1JGzZtw3Qku8nTAmzFHCyJ4PofH2reuPj Q7HyqfYQlLVKACOKZm2Hsr6bZoX4RE8YrO+2GFEo1ISqKVrAFUTLvl5LjZiNohmDWFo2iMUwk r7MqtZX1ZElb8BwCqF9bwY1jSezBtFtyMlTv1lFICmEHs/g== Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Agenda X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 14:56:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LAD8C1i7HxFqP1KVOcksASaqXLXXh6Pqi Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Would 10 mins be OK for you to explain the story? On 07/13/2015 04:54 PM, John Bradley wrote: > I did make a proposal as part of https://tools.ietf.org/html/draft-brad= ley-oauth-jwt-encoded-state-04 --LAD8C1i7HxFqP1KVOcksASaqXLXXh6Pqi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVo9FcAAoJEGhJURNOOiAt2D0H/j4sBCNfbqmGNCLNrd5OrD2T l6y16y0ZJ2MfHADnefqOGDSTTN4DwfVdAD92m3LjOcDogbZlboJSVC+a9owVBn2S sDpCLTqZ9rbM8SPpqupvfs15V0WdmNN8op/obc5eKsgVS/zye8H5nM7jKZK56ORD AiM68PWpjEqJw8LLi+bLItJrutSmzGe46x7jXH6ObCJ4zxgfawDifHx6UIIUu23u SW8RE2jPoQaXYGlMln22ZH+mwd9hbQc+tMfGu9/ArBHQMoHPNgj9GPBO6JuoyvAd fgxL1Onb2QURemzRYvRTQDQghhvOBaHUOumb+WAIW+08OmQlgM0bObb+EEU/D6Q= =0Mef -----END PGP SIGNATURE----- --LAD8C1i7HxFqP1KVOcksASaqXLXXh6Pqi-- From nobody Mon Jul 13 07:56:44 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26BD21B2B65 for ; Mon, 13 Jul 2015 07:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSe-yhRAmkbs for ; Mon, 13 Jul 2015 07:56:42 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98A751B2B55 for ; Mon, 13 Jul 2015 07:56:41 -0700 (PDT) Received: by wicmz13 with SMTP id mz13so64317208wic.0 for ; Mon, 13 Jul 2015 07:56:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=f6T1WeqmXY6yIDYTktqwI+VaP0mNegQtpbpvNtNJBFQ=; b=gzXseWKTIlJamvCqUK626ofem+0fl0Vs30OYfnBwd2UH8GQil9tJLOxfl+SAP/KS6W SZgQ/u9x1DL7yxZXo55r1LF+NMLuaBzrW7b+/haWJUVXyqW9zEvGCkIX0gJvi9RtDTzJ +mGvBcKj/jV4+L74Ru+6N8lLN69ifv1yvvT/b8gs43bJ4ryvAEKHoZai5BW+Xf37p8ZG DRuJYLyJiMlnQk1lSSPCsKpcYgt7beHAeeJj+N9mDBeVVy1qVfhalLcw++VAyM59iSw0 1kUViio797N0sQAUWdRAQrZm04V/mQiMtYxbi118F3Cef9Q6UsrRp167zXRoZiL1uHli saYw== X-Gm-Message-State: ALoCoQmSS4HavTyPYnXTg//W27XKwd2qwKnp2y/2sKM5OczBoH55Kjjw8G28PmWB+yCdB7sweuac X-Received: by 10.180.198.44 with SMTP id iz12mr20429924wic.62.1436799400342; Mon, 13 Jul 2015 07:56:40 -0700 (PDT) Received: from [10.207.202.19] (host86-187-41-172.range86-187.btcentralplus.com. [86.187.41.172]) by smtp.gmail.com with ESMTPSA id gt10sm15058251wib.20.2015.07.13.07.56.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 Jul 2015 07:56:39 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: John Bradley In-Reply-To: <55A3D15C.7000202@gmx.net> Date: Mon, 13 Jul 2015 09:56:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6ED46853-A97D-49E3-8457-512E937D62F2@ve7jtb.com> References: <55A3C3D5.1020507@gmx.net> <4B7C8B57-0291-4663-9844-23805DD09174@ve7jtb.com> <55A3D15C.7000202@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Agenda X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 14:56:43 -0000 Yes thats fine. > On Jul 13, 2015, at 9:55 AM, Hannes Tschofenig = wrote: >=20 > Would 10 mins be OK for you to explain the story? >=20 > On 07/13/2015 04:54 PM, John Bradley wrote: >> I did make a proposal as part of = https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state-04 >=20 From nobody Wed Jul 15 12:47:06 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28FF11A1EF1 for ; Wed, 15 Jul 2015 12:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHM2Lh0dWYLW for ; Wed, 15 Jul 2015 12:47:02 -0700 (PDT) Received: from mail-oi0-f42.google.com (mail-oi0-f42.google.com [209.85.218.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47CD11A21AB for ; Wed, 15 Jul 2015 12:47:02 -0700 (PDT) Received: by oiab3 with SMTP id b3so35951959oia.1 for ; Wed, 15 Jul 2015 12:47:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=Jh8r74ndzfN8fh85kD5irjNklK6bUip3ttidm4L12SE=; b=ZWVAor0T6pFr5PENkpKnD6MsBZd1NcMlpsNZehRiPfeqOk1JBgl1cNVV6bqCopOTWI h1Zwh4L4QXGhgbKeIhFhQ4F3ThD8uvCwgK2K5DkTtxe+qQw5goPsVu5ePRcLIGkTvg2L CWTtox4skms402ZmtMXl56/u/iYSuTFmSElqBVWkyOmPkYPuRH+zaps08Su6gTQr8E4f AyXAkElnFuxIBtoekvchO4rbEhy0sH18iJQn3Sp+qnmyshFr7nvjcYLlMrVzOkwzpmaj nPKdLv+oaLE4u+LHnSdmjIlID9+Fh/Lc+a8FN5LSySV3mCeeOKyCAvWyGE2OK0NmghkG Xk6A== X-Gm-Message-State: ALoCoQlDVfE+TnsLcE9cWvvhlou6hkv2iE8EUI141E/fU3p7ET4HDkGiDGTOAov2BO35FqMcNMsm MIME-Version: 1.0 X-Received: by 10.60.34.164 with SMTP id a4mr5565292oej.56.1436989621500; Wed, 15 Jul 2015 12:47:01 -0700 (PDT) Received: by 10.76.68.162 with HTTP; Wed, 15 Jul 2015 12:47:01 -0700 (PDT) Date: Wed, 15 Jul 2015 12:47:01 -0700 Message-ID: From: Chuck Mortimore To: OAuth WG , Michael Jones Content-Type: multipart/alternative; boundary=089e013cc54aefae62051aef3753 Archived-At: Subject: [OAUTH-WG] Use of Token Exchange spec for API Federation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 19:47:04 -0000 --089e013cc54aefae62051aef3753 Content-Type: text/plain; charset=UTF-8 We're examining the use of the Token Exchange spec for API federation use-cases, and are looking for some feedback. The basic use-case is as follows: Developer wants to build an Application that is a composite of backend services that span multiple security domains. For example, it's a combination of Salesforce data and their own backend services. The application is authenticated by Salesforce, and developer wants to exchange our ID Token for a token in the second security domain so that login / credentials are not required for the second back-end service. To do this, we're planning to add configuration for multiple audiences in our service, allowing the developer to receive a mutli-party ID Token. We may also add custom claims to facilitate mapping of identity across the services. Having logged into Salesforce, and received an ID Token, the developer would then call a Token Exchange service in the second security domain and exchange this ID token for a token specific to that domain. This allows for simple API federation use-cases without converging both APIs / backends on a common token format. Questions / Feedback 1) In the spec, "sub" is a required field. However, the application may not yet know who the subject is in the second security domain ( it first has to exchange the token ) One option might be to place the client_id of the application as issued by the second security domain, but that seems a bit off. Any advice? Should this be an Optional field? 2) Speaking of client_ids, if we don't use the "sub" to transport them, we believe the second security domain would still appreciate this context. The Actor field is available, but construction of a full JWT just to transport the client_id seems like high overhead, and it may not even be aligned with the intent of that field. Should client_id be a claim here? 3) Speaking of Actors, It's not clear what actually states that the jwt included in the token is actually an approved actor. Is it intended that the act_as or on-behalf_of tokens include an azp authorized party clam as well? 4) "Implementations of the specification MUST implement support for using JWTs as the Security Tokens. Other Security Token types MAY be supported." This seems antithetical to the purpose of an STS. We believe this should be relaxed to a SHOULD Thanks for any feedback here --089e013cc54aefae62051aef3753 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We're examining the use of the Token Exchange spec for= API federation use-cases, and are looking for some feedback.

The basic use-case is as follows: =C2=A0Developer wants to build an A= pplication that is a composite of backend services that span multiple secur= ity domains. =C2=A0 For example, it's a combination of Salesforce data = and their own backend services. =C2=A0 =C2=A0 The application is authentica= ted by Salesforce, and developer wants to exchange our ID Token for a token= in the second security domain so that login / credentials are not required= for the second back-end service. =C2=A0=C2=A0

To = do this, we're planning to add configuration for multiple audiences in = our service, allowing the developer to receive a mutli-party ID Token. =C2= =A0 We may also add custom claims to facilitate mapping of identity across = the services. =C2=A0 Having logged into Salesforce, and received an ID Toke= n, the developer would then call a Token Exchange service in the second sec= urity domain and exchange this ID token for a token specific to that domain= . =C2=A0 This allows for simple API federation use-cases without converging= both APIs / backends on a common token format.

Qu= estions / Feedback

1) In the spec, "sub"= is a required field. =C2=A0 However, the application may not yet know who = the subject is in the second security domain ( it first has to exchange the= token ) =C2=A0 =C2=A0One option might be to place the client_id of the app= lication as issued by the second security domain, but that seems a bit off.= =C2=A0 Any advice? =C2=A0 Should this be an Optional field?

=
2) Speaking of client_ids, if we don't use the "sub&quo= t; to transport them, we believe the second security domain would still app= reciate this context. =C2=A0 The Actor field is available, but construction= of a full JWT just to transport the client_id seems like high overhead, an= d it may not even be aligned with the intent of that field. =C2=A0 =C2=A0Sh= ould client_id be a claim here?

3) Speaking of Act= ors, It's not clear what actually states that the jwt included in the t= oken is actually an approved actor. =C2=A0 =C2=A0Is it intended that the ac= t_as or on-behalf_of tokens include an azp authorized party clam as well?

4) "Implementations of the specification MUST = implement support for using JWTs as the Security Tokens.=C2=A0 Other Securi= ty Token types MAY be supported." =C2=A0 This seems antithetical to th= e purpose of an STS. =C2=A0 We believe this should be relaxed to a SHOULD

Thanks for any feedback here





--089e013cc54aefae62051aef3753-- From nobody Wed Jul 15 14:33:53 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C686D1B2CD7 for ; Wed, 15 Jul 2015 14:33:51 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2Yk_pgJ_g4x for ; Wed, 15 Jul 2015 14:33:48 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0778.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:778]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 211E51B2CD5 for ; Wed, 15 Jul 2015 14:33:48 -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=cvyQYAfuJAKZwHVh5UpvHdyXtJxw0RgQsCEW1K2y4HI=; b=VbNzWA6E40FKy4VnsAEn2fkZlTQuLQ+bNOrrerSiBugItuq52pNZDPzQH591JjSBYwnrq8EHxYIjM2KfeTISUTochnca+qNEyfvbN9dv0vLOkI66UMqF5SYpC7uHj83oNwdkRhJAWx9MrpEDIF0GFi8Dgp32n5YrpUllbpZpFbA= Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BL2PR03MB435.namprd03.prod.outlook.com (10.141.92.24) with Microsoft SMTP Server (TLS) id 15.1.225.13; Wed, 15 Jul 2015 21:27:21 +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.0213.000; Wed, 15 Jul 2015 21:27:21 +0000 From: Anthony Nadalin To: Chuck Mortimore , OAuth WG , Mike Jones Thread-Topic: [OAUTH-WG] Use of Token Exchange spec for API Federation Thread-Index: AQHQvzcLEviFbtT6HkCUwcAzix4q+53dCslg Date: Wed, 15 Jul 2015 21:27:20 +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: salesforce.com; dkim=none (message not signed) header.d=none; x-originating-ip: [131.107.159.185] x-microsoft-exchange-diagnostics: 1; BL2PR03MB435; 5:qcl/RTvWIhRlkOwpA45epDzx1HEv3nlvMDH074U8LKjVuV0F6JXPpoTAres8R3q3mF25MLFMUe5MWSMjmghE9gaIQmt5AcB1aUHCswV2k+AwDwv3LZ2qQWlPy1+oOV//jsytzGyVXguKTfUZ/9mHnw==; 24:LeDlpgSBzxjdNblplv9KpiGlepoX1WDnKv0wU4d54K0Y/065PpOMYtq2PXjiCNVQsDcpaZdQ00UpZP+4Bx5Cg/Vv0YomDc+9kpbm/arJz0g=; 20:VB5/1OvtmCjfSpC2PescUeJ87ToP9nyu0m4FbKKQGYNMOsfOPqw7uHy7w4bn+/7YqUEyTjGUGFm0suzaFt6daQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB435; x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) bl2pr03mb435: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BL2PR03MB435; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB435; x-forefront-prvs: 0638FD5066 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(106116001)(102836002)(87936001)(122556002)(33656002)(2656002)(46102003)(2950100001)(2900100001)(40100003)(5003600100002)(189998001)(5002640100001)(76576001)(15975445007)(5001960100002)(77096005)(107886002)(54356999)(16236675004)(2421001)(50986999)(86362001)(76176999)(5001770100001)(66066001)(77156002)(19300405004)(1511001)(19580395003)(62966003)(19580405001)(92566002)(74316001)(19625215002)(4001450100001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB435; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1234FF908932CE6BE450CCD9A69A0BN3PR0301MB1234_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2015 21:27:20.6529 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB435 Archived-At: Subject: Re: [OAUTH-WG] Use of Token Exchange spec for API Federation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 21:33:52 -0000 --_000_BN3PR0301MB1234FF908932CE6BE450CCD9A69A0BN3PR0301MB1234_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U28gaW4geW91ciBzY2VuYXJpbyB3aGVyZSB5b3UgaGF2ZSBjbGllbnQgKGMpLCB1c2VyICh1KSwg cmVzb3VyY2UgKHIpIGFuZCByZXNvdXJjZSAxKHIxKSBkb2VzIHRoZSBmbG93IGdvIGxpa2UgVS0+ Qy0+Ui1SMSBvciBVLT5DLT5SIGFuZCBVLT5DLT5SMSA/DQoNCkZyb206IE9BdXRoIFttYWlsdG86 b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENodWNrIE1vcnRpbW9yZQ0KU2Vu dDogV2VkbmVzZGF5LCBKdWx5IDE1LCAyMDE1IDEyOjQ3IFBNDQpUbzogT0F1dGggV0cgPG9hdXRo QGlldGYub3JnPjsgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPg0KU3Vi amVjdDogW09BVVRILVdHXSBVc2Ugb2YgVG9rZW4gRXhjaGFuZ2Ugc3BlYyBmb3IgQVBJIEZlZGVy YXRpb24NCg0KV2UncmUgZXhhbWluaW5nIHRoZSB1c2Ugb2YgdGhlIFRva2VuIEV4Y2hhbmdlIHNw ZWMgZm9yIEFQSSBmZWRlcmF0aW9uIHVzZS1jYXNlcywgYW5kIGFyZSBsb29raW5nIGZvciBzb21l IGZlZWRiYWNrLg0KDQpUaGUgYmFzaWMgdXNlLWNhc2UgaXMgYXMgZm9sbG93czogIERldmVsb3Bl ciB3YW50cyB0byBidWlsZCBhbiBBcHBsaWNhdGlvbiB0aGF0IGlzIGEgY29tcG9zaXRlIG9mIGJh Y2tlbmQgc2VydmljZXMgdGhhdCBzcGFuIG11bHRpcGxlIHNlY3VyaXR5IGRvbWFpbnMuICAgRm9y IGV4YW1wbGUsIGl0J3MgYSBjb21iaW5hdGlvbiBvZiBTYWxlc2ZvcmNlIGRhdGEgYW5kIHRoZWly IG93biBiYWNrZW5kIHNlcnZpY2VzLiAgICAgVGhlIGFwcGxpY2F0aW9uIGlzIGF1dGhlbnRpY2F0 ZWQgYnkgU2FsZXNmb3JjZSwgYW5kIGRldmVsb3BlciB3YW50cyB0byBleGNoYW5nZSBvdXIgSUQg VG9rZW4gZm9yIGEgdG9rZW4gaW4gdGhlIHNlY29uZCBzZWN1cml0eSBkb21haW4gc28gdGhhdCBs b2dpbiAvIGNyZWRlbnRpYWxzIGFyZSBub3QgcmVxdWlyZWQgZm9yIHRoZSBzZWNvbmQgYmFjay1l bmQgc2VydmljZS4NCg0KVG8gZG8gdGhpcywgd2UncmUgcGxhbm5pbmcgdG8gYWRkIGNvbmZpZ3Vy YXRpb24gZm9yIG11bHRpcGxlIGF1ZGllbmNlcyBpbiBvdXIgc2VydmljZSwgYWxsb3dpbmcgdGhl IGRldmVsb3BlciB0byByZWNlaXZlIGEgbXV0bGktcGFydHkgSUQgVG9rZW4uICAgV2UgbWF5IGFs c28gYWRkIGN1c3RvbSBjbGFpbXMgdG8gZmFjaWxpdGF0ZSBtYXBwaW5nIG9mIGlkZW50aXR5IGFj cm9zcyB0aGUgc2VydmljZXMuICAgSGF2aW5nIGxvZ2dlZCBpbnRvIFNhbGVzZm9yY2UsIGFuZCBy ZWNlaXZlZCBhbiBJRCBUb2tlbiwgdGhlIGRldmVsb3BlciB3b3VsZCB0aGVuIGNhbGwgYSBUb2tl biBFeGNoYW5nZSBzZXJ2aWNlIGluIHRoZSBzZWNvbmQgc2VjdXJpdHkgZG9tYWluIGFuZCBleGNo YW5nZSB0aGlzIElEIHRva2VuIGZvciBhIHRva2VuIHNwZWNpZmljIHRvIHRoYXQgZG9tYWluLiAg IFRoaXMgYWxsb3dzIGZvciBzaW1wbGUgQVBJIGZlZGVyYXRpb24gdXNlLWNhc2VzIHdpdGhvdXQg Y29udmVyZ2luZyBib3RoIEFQSXMgLyBiYWNrZW5kcyBvbiBhIGNvbW1vbiB0b2tlbiBmb3JtYXQu DQoNClF1ZXN0aW9ucyAvIEZlZWRiYWNrDQoNCjEpIEluIHRoZSBzcGVjLCAic3ViIiBpcyBhIHJl cXVpcmVkIGZpZWxkLiAgIEhvd2V2ZXIsIHRoZSBhcHBsaWNhdGlvbiBtYXkgbm90IHlldCBrbm93 IHdobyB0aGUgc3ViamVjdCBpcyBpbiB0aGUgc2Vjb25kIHNlY3VyaXR5IGRvbWFpbiAoIGl0IGZp cnN0IGhhcyB0byBleGNoYW5nZSB0aGUgdG9rZW4gKSAgICBPbmUgb3B0aW9uIG1pZ2h0IGJlIHRv IHBsYWNlIHRoZSBjbGllbnRfaWQgb2YgdGhlIGFwcGxpY2F0aW9uIGFzIGlzc3VlZCBieSB0aGUg c2Vjb25kIHNlY3VyaXR5IGRvbWFpbiwgYnV0IHRoYXQgc2VlbXMgYSBiaXQgb2ZmLiAgIEFueSBh ZHZpY2U/ICAgU2hvdWxkIHRoaXMgYmUgYW4gT3B0aW9uYWwgZmllbGQ/DQoNCjIpIFNwZWFraW5n IG9mIGNsaWVudF9pZHMsIGlmIHdlIGRvbid0IHVzZSB0aGUgInN1YiIgdG8gdHJhbnNwb3J0IHRo ZW0sIHdlIGJlbGlldmUgdGhlIHNlY29uZCBzZWN1cml0eSBkb21haW4gd291bGQgc3RpbGwgYXBw cmVjaWF0ZSB0aGlzIGNvbnRleHQuICAgVGhlIEFjdG9yIGZpZWxkIGlzIGF2YWlsYWJsZSwgYnV0 IGNvbnN0cnVjdGlvbiBvZiBhIGZ1bGwgSldUIGp1c3QgdG8gdHJhbnNwb3J0IHRoZSBjbGllbnRf aWQgc2VlbXMgbGlrZSBoaWdoIG92ZXJoZWFkLCBhbmQgaXQgbWF5IG5vdCBldmVuIGJlIGFsaWdu ZWQgd2l0aCB0aGUgaW50ZW50IG9mIHRoYXQgZmllbGQuICAgIFNob3VsZCBjbGllbnRfaWQgYmUg YSBjbGFpbSBoZXJlPw0KDQozKSBTcGVha2luZyBvZiBBY3RvcnMsIEl0J3Mgbm90IGNsZWFyIHdo YXQgYWN0dWFsbHkgc3RhdGVzIHRoYXQgdGhlIGp3dCBpbmNsdWRlZCBpbiB0aGUgdG9rZW4gaXMg YWN0dWFsbHkgYW4gYXBwcm92ZWQgYWN0b3IuICAgIElzIGl0IGludGVuZGVkIHRoYXQgdGhlIGFj dF9hcyBvciBvbi1iZWhhbGZfb2YgdG9rZW5zIGluY2x1ZGUgYW4gYXpwIGF1dGhvcml6ZWQgcGFy dHkgY2xhbSBhcyB3ZWxsPw0KDQo0KSAiSW1wbGVtZW50YXRpb25zIG9mIHRoZSBzcGVjaWZpY2F0 aW9uIE1VU1QgaW1wbGVtZW50IHN1cHBvcnQgZm9yIHVzaW5nIEpXVHMgYXMgdGhlIFNlY3VyaXR5 IFRva2Vucy4gIE90aGVyIFNlY3VyaXR5IFRva2VuIHR5cGVzIE1BWSBiZSBzdXBwb3J0ZWQuIiAg IFRoaXMgc2VlbXMgYW50aXRoZXRpY2FsIHRvIHRoZSBwdXJwb3NlIG9mIGFuIFNUUy4gICBXZSBi ZWxpZXZlIHRoaXMgc2hvdWxkIGJlIHJlbGF4ZWQgdG8gYSBTSE9VTEQNCg0KVGhhbmtzIGZvciBh bnkgZmVlZGJhY2sgaGVyZQ0KDQoNCg0KDQoNCg== --_000_BN3PR0301MB1234FF908932CE6BE450CCD9A69A0BN3PR0301MB1234_ 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 b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBs aS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5 bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIg dmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TbyBpbiB5b3VyIHNjZW5h cmlvIHdoZXJlIHlvdSBoYXZlIGNsaWVudCAoYyksIHVzZXIgKHUpLCByZXNvdXJjZSAocikgYW5k IHJlc291cmNlIDEocjEpIGRvZXMgdGhlIGZsb3cgZ28gbGlrZSBVLSZndDtDLSZndDtSLVIxIG9y IFUtJmd0O0MtJmd0O1IgYW5kIFUtJmd0O0MtJmd0O1IxID88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4gT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5DaHVjayBNb3J0aW1vcmU8YnI+DQo8Yj5TZW50OjwvYj4gV2Vk bmVzZGF5LCBKdWx5IDE1LCAyMDE1IDEyOjQ3IFBNPGJyPg0KPGI+VG86PC9iPiBPQXV0aCBXRyAm bHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7OyBNaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtPQVVUSC1XR10gVXNlIG9mIFRva2Vu IEV4Y2hhbmdlIHNwZWMgZm9yIEFQSSBGZWRlcmF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+V2UncmUgZXhhbWluaW5nIHRoZSB1c2Ugb2YgdGhlIFRva2VuIEV4Y2hh bmdlIHNwZWMgZm9yIEFQSSBmZWRlcmF0aW9uIHVzZS1jYXNlcywgYW5kIGFyZSBsb29raW5nIGZv ciBzb21lIGZlZWRiYWNrLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhlIGJhc2ljIHVzZS1jYXNlIGlzIGFzIGZvbGxvd3M6ICZuYnNwO0RldmVsb3BlciB3 YW50cyB0byBidWlsZCBhbiBBcHBsaWNhdGlvbiB0aGF0IGlzIGEgY29tcG9zaXRlIG9mIGJhY2tl bmQgc2VydmljZXMgdGhhdCBzcGFuIG11bHRpcGxlIHNlY3VyaXR5IGRvbWFpbnMuICZuYnNwOyBG b3IgZXhhbXBsZSwgaXQncyBhIGNvbWJpbmF0aW9uIG9mIFNhbGVzZm9yY2UgZGF0YSBhbmQgdGhl aXIgb3duIGJhY2tlbmQgc2VydmljZXMuDQogJm5ic3A7ICZuYnNwOyBUaGUgYXBwbGljYXRpb24g aXMgYXV0aGVudGljYXRlZCBieSBTYWxlc2ZvcmNlLCBhbmQgZGV2ZWxvcGVyIHdhbnRzIHRvIGV4 Y2hhbmdlIG91ciBJRCBUb2tlbiBmb3IgYSB0b2tlbiBpbiB0aGUgc2Vjb25kIHNlY3VyaXR5IGRv bWFpbiBzbyB0aGF0IGxvZ2luIC8gY3JlZGVudGlhbHMgYXJlIG5vdCByZXF1aXJlZCBmb3IgdGhl IHNlY29uZCBiYWNrLWVuZCBzZXJ2aWNlLiAmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG8gZG8gdGhpcywgd2UncmUgcGxh bm5pbmcgdG8gYWRkIGNvbmZpZ3VyYXRpb24gZm9yIG11bHRpcGxlIGF1ZGllbmNlcyBpbiBvdXIg c2VydmljZSwgYWxsb3dpbmcgdGhlIGRldmVsb3BlciB0byByZWNlaXZlIGEgbXV0bGktcGFydHkg SUQgVG9rZW4uICZuYnNwOyBXZSBtYXkgYWxzbyBhZGQgY3VzdG9tIGNsYWltcyB0byBmYWNpbGl0 YXRlIG1hcHBpbmcgb2YgaWRlbnRpdHkgYWNyb3NzIHRoZSBzZXJ2aWNlcy4gJm5ic3A7IEhhdmlu Zw0KIGxvZ2dlZCBpbnRvIFNhbGVzZm9yY2UsIGFuZCByZWNlaXZlZCBhbiBJRCBUb2tlbiwgdGhl IGRldmVsb3BlciB3b3VsZCB0aGVuIGNhbGwgYSBUb2tlbiBFeGNoYW5nZSBzZXJ2aWNlIGluIHRo ZSBzZWNvbmQgc2VjdXJpdHkgZG9tYWluIGFuZCBleGNoYW5nZSB0aGlzIElEIHRva2VuIGZvciBh IHRva2VuIHNwZWNpZmljIHRvIHRoYXQgZG9tYWluLiAmbmJzcDsgVGhpcyBhbGxvd3MgZm9yIHNp bXBsZSBBUEkgZmVkZXJhdGlvbiB1c2UtY2FzZXMgd2l0aG91dA0KIGNvbnZlcmdpbmcgYm90aCBB UElzIC8gYmFja2VuZHMgb24gYSBjb21tb24gdG9rZW4gZm9ybWF0LjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5RdWVzdGlvbnMgLyBGZWVkYmFj azxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4x KSBJbiB0aGUgc3BlYywgJnF1b3Q7c3ViJnF1b3Q7IGlzIGEgcmVxdWlyZWQgZmllbGQuICZuYnNw OyBIb3dldmVyLCB0aGUgYXBwbGljYXRpb24gbWF5IG5vdCB5ZXQga25vdyB3aG8gdGhlIHN1Ympl Y3QgaXMgaW4gdGhlIHNlY29uZCBzZWN1cml0eSBkb21haW4gKCBpdCBmaXJzdCBoYXMgdG8gZXhj aGFuZ2UgdGhlIHRva2VuICkgJm5ic3A7ICZuYnNwO09uZSBvcHRpb24gbWlnaHQgYmUgdG8gcGxh Y2UgdGhlIGNsaWVudF9pZCBvZiB0aGUgYXBwbGljYXRpb24NCiBhcyBpc3N1ZWQgYnkgdGhlIHNl Y29uZCBzZWN1cml0eSBkb21haW4sIGJ1dCB0aGF0IHNlZW1zIGEgYml0IG9mZi4gJm5ic3A7IEFu eSBhZHZpY2U/ICZuYnNwOyBTaG91bGQgdGhpcyBiZSBhbiBPcHRpb25hbCBmaWVsZD88bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MikgU3BlYWtp bmcgb2YgY2xpZW50X2lkcywgaWYgd2UgZG9uJ3QgdXNlIHRoZSAmcXVvdDtzdWImcXVvdDsgdG8g dHJhbnNwb3J0IHRoZW0sIHdlIGJlbGlldmUgdGhlIHNlY29uZCBzZWN1cml0eSBkb21haW4gd291 bGQgc3RpbGwgYXBwcmVjaWF0ZSB0aGlzIGNvbnRleHQuICZuYnNwOyBUaGUgQWN0b3IgZmllbGQg aXMgYXZhaWxhYmxlLCBidXQgY29uc3RydWN0aW9uIG9mIGEgZnVsbCBKV1QganVzdCB0byB0cmFu c3BvcnQgdGhlIGNsaWVudF9pZA0KIHNlZW1zIGxpa2UgaGlnaCBvdmVyaGVhZCwgYW5kIGl0IG1h eSBub3QgZXZlbiBiZSBhbGlnbmVkIHdpdGggdGhlIGludGVudCBvZiB0aGF0IGZpZWxkLiAmbmJz cDsgJm5ic3A7U2hvdWxkIGNsaWVudF9pZCBiZSBhIGNsYWltIGhlcmU/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMpIFNwZWFraW5nIG9mIEFj dG9ycywgSXQncyBub3QgY2xlYXIgd2hhdCBhY3R1YWxseSBzdGF0ZXMgdGhhdCB0aGUgand0IGlu Y2x1ZGVkIGluIHRoZSB0b2tlbiBpcyBhY3R1YWxseSBhbiBhcHByb3ZlZCBhY3Rvci4gJm5ic3A7 ICZuYnNwO0lzIGl0IGludGVuZGVkIHRoYXQgdGhlIGFjdF9hcyBvciBvbi1iZWhhbGZfb2YgdG9r ZW5zIGluY2x1ZGUgYW4gYXpwIGF1dGhvcml6ZWQgcGFydHkgY2xhbSBhcyB3ZWxsPzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj40KSAmcXVvdDtJ bXBsZW1lbnRhdGlvbnMgb2YgdGhlIHNwZWNpZmljYXRpb24gTVVTVCBpbXBsZW1lbnQgc3VwcG9y dCBmb3IgdXNpbmcgSldUcyBhcyB0aGUgU2VjdXJpdHkgVG9rZW5zLiZuYnNwOyBPdGhlciBTZWN1 cml0eSBUb2tlbiB0eXBlcyBNQVkgYmUgc3VwcG9ydGVkLiZxdW90OyAmbmJzcDsgVGhpcyBzZWVt cyBhbnRpdGhldGljYWwgdG8gdGhlIHB1cnBvc2Ugb2YgYW4gU1RTLiAmbmJzcDsgV2UgYmVsaWV2 ZSB0aGlzIHNob3VsZCBiZSByZWxheGVkDQogdG8gYSBTSE9VTEQ8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGZvciBhbnkgZmVlZGJh Y2sgaGVyZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN3PR0301MB1234FF908932CE6BE450CCD9A69A0BN3PR0301MB1234_-- From nobody Wed Jul 15 14:44:31 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37C471B2D25 for ; Wed, 15 Jul 2015 14:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tSLW14HKQxt for ; Wed, 15 Jul 2015 14:44:28 -0700 (PDT) Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com [209.85.218.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFEB41B2D20 for ; Wed, 15 Jul 2015 14:44:27 -0700 (PDT) Received: by oige126 with SMTP id e126so38035559oig.0 for ; Wed, 15 Jul 2015 14:44:27 -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:date :message-id:subject:from:to:cc:content-type; bh=9bM5BnxysVrVfePvi4HQDF0MyO8jZ4j3atUvPFbXtnE=; b=DYt/cf56LPF4JaarUfUrO+PIarQxlNyGo7LybjSAAp0206UmUA4Gt/kSIS7juLlrB5 VVVkoeacA4NTwvtQUbarK1+jtf+e0mfPrTmMFCbMdDyMoQdn4zNUg5CdFigaTEcW3ve6 grhKkih7yDixDs11pFn3MUHso76wbcHZvUP5Zz63alMJTmUuwbArVA/HaMiWqIFlaCmk pd7p4ZVe022YxwGXqKQ4fp+XsJDU2IyAgr6aagvxMfPrNORX5Q8J4Ih/bkQNIeJqEN9X dpF5gcpndY+V+9uztVfkiNXMpxy6OsoYWdsEQGlDeRyEPDcDxNHbHf28hdO8EcH4wAs+ f4/Q== X-Gm-Message-State: ALoCoQmzu+MSwNVGoE9HfI+OQNb2eCqJlb/cJ252DvJ3hobG/pMZIRSRqStSpGpbstbL6sWkJ5ad MIME-Version: 1.0 X-Received: by 10.202.90.5 with SMTP id o5mr5404000oib.79.1436996667108; Wed, 15 Jul 2015 14:44:27 -0700 (PDT) Received: by 10.76.68.162 with HTTP; Wed, 15 Jul 2015 14:44:27 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Jul 2015 14:44:27 -0700 Message-ID: From: Chuck Mortimore To: Anthony Nadalin Content-Type: multipart/alternative; boundary=001a113d468ee31972051af0dbcc Archived-At: Cc: OAuth WG Subject: Re: [OAUTH-WG] Use of Token Exchange spec for API Federation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 21:44:30 -0000 --001a113d468ee31972051af0dbcc Content-Type: text/plain; charset=UTF-8 User logs into Client and accesses Resource1 using AccessToken1 from TokenService1. Client then contacts TokenService2 and exchanges IDToken1 from TokenService1 for AccessToken2 from TokenService2. It then uses AccessToken2 to access Resource2. -cmort On Wed, Jul 15, 2015 at 2:27 PM, Anthony Nadalin wrote: > So in your scenario where you have client (c), user (u), resource (r) > and resource 1(r1) does the flow go like U->C->R-R1 or U->C->R and U->C->R1 > ? > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Chuck > Mortimore > *Sent:* Wednesday, July 15, 2015 12:47 PM > *To:* OAuth WG ; Mike Jones > *Subject:* [OAUTH-WG] Use of Token Exchange spec for API Federation > > > > We're examining the use of the Token Exchange spec for API federation > use-cases, and are looking for some feedback. > > > > The basic use-case is as follows: Developer wants to build an Application > that is a composite of backend services that span multiple security > domains. For example, it's a combination of Salesforce data and their own > backend services. The application is authenticated by Salesforce, and > developer wants to exchange our ID Token for a token in the second security > domain so that login / credentials are not required for the second back-end > service. > > > > To do this, we're planning to add configuration for multiple audiences in > our service, allowing the developer to receive a mutli-party ID Token. We > may also add custom claims to facilitate mapping of identity across the > services. Having logged into Salesforce, and received an ID Token, the > developer would then call a Token Exchange service in the second security > domain and exchange this ID token for a token specific to that domain. > This allows for simple API federation use-cases without converging both > APIs / backends on a common token format. > > > > Questions / Feedback > > > > 1) In the spec, "sub" is a required field. However, the application may > not yet know who the subject is in the second security domain ( it first > has to exchange the token ) One option might be to place the client_id > of the application as issued by the second security domain, but that seems > a bit off. Any advice? Should this be an Optional field? > > > > 2) Speaking of client_ids, if we don't use the "sub" to transport them, we > believe the second security domain would still appreciate this context. > The Actor field is available, but construction of a full JWT just to > transport the client_id seems like high overhead, and it may not even be > aligned with the intent of that field. Should client_id be a claim here? > > > > 3) Speaking of Actors, It's not clear what actually states that the jwt > included in the token is actually an approved actor. Is it intended that > the act_as or on-behalf_of tokens include an azp authorized party clam as > well? > > > > 4) "Implementations of the specification MUST implement support for using > JWTs as the Security Tokens. Other Security Token types MAY be supported." > This seems antithetical to the purpose of an STS. We believe this > should be relaxed to a SHOULD > > > > Thanks for any feedback here > > > > > > > > > > > --001a113d468ee31972051af0dbcc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
User logs into Client and accesses Resource1 using Ac= cessToken1 from TokenService1. =C2=A0=C2=A0

Client= then contacts TokenService2 and exchanges IDToken1 from TokenService1 for = AccessToken2 from TokenService2. =C2=A0 It then uses AccessToken2 to access= Resource2.

-cmort



On = Wed, Jul 15, 2015 at 2:27 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:

So in your scenario where you have cl= ient (c), user (u), resource (r) and resource 1(r1) does the flow go like U= ->C->R-R1 or U->C->R and U->C->R1 ?<= /p>

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Chuck Mortimore
Sent: Wednesday, July 15, 2015 12:47 PM
To: OAuth WG <oauth@ietf.org>; Mike Jones <Michael.Jones@microsoft.com> Subject: [OAUTH-WG] Use of Token Exchange spec for API Federation=

=C2=A0

We're examining the use of the Token Exchange sp= ec for API federation use-cases, and are looking for some feedback.<= u>

=C2=A0

The basic use-case is as follows: =C2=A0Developer wa= nts to build an Application that is a composite of backend services that sp= an multiple security domains. =C2=A0 For example, it's a combination of= Salesforce data and their own backend services. =C2=A0 =C2=A0 The application is authenticated by Salesforce, and develope= r wants to exchange our ID Token for a token in the second security domain = so that login / credentials are not required for the second back-end servic= e. =C2=A0=C2=A0

=C2=A0

To do this, we're planning to add configuration = for multiple audiences in our service, allowing the developer to receive a = mutli-party ID Token. =C2=A0 We may also add custom claims to facilitate ma= pping of identity across the services. =C2=A0 Having logged into Salesforce, and received an ID Token, the developer would then= call a Token Exchange service in the second security domain and exchange t= his ID token for a token specific to that domain. =C2=A0 This allows for si= mple API federation use-cases without converging both APIs / backends on a common token format.

=C2=A0

Questions / Feedback

=C2=A0

1) In the spec, "sub" is a required field.= =C2=A0 However, the application may not yet know who the subject is in the= second security domain ( it first has to exchange the token ) =C2=A0 =C2= =A0One option might be to place the client_id of the application as issued by the second security domain, but that seems a bit off. =C2=A0 = Any advice? =C2=A0 Should this be an Optional field?

=C2=A0

2) Speaking of client_ids, if we don't use the &= quot;sub" to transport them, we believe the second security domain wou= ld still appreciate this context. =C2=A0 The Actor field is available, but = construction of a full JWT just to transport the client_id seems like high overhead, and it may not even be aligned with the intent o= f that field. =C2=A0 =C2=A0Should client_id be a claim here?<= /p>

=C2=A0

3) Speaking of Actors, It's not clear what actua= lly states that the jwt included in the token is actually an approved actor= . =C2=A0 =C2=A0Is it intended that the act_as or on-behalf_of tokens includ= e an azp authorized party clam as well?

=C2=A0

4) "Implementations of the specification MUST i= mplement support for using JWTs as the Security Tokens.=C2=A0 Other Securit= y Token types MAY be supported." =C2=A0 This seems antithetical to the= purpose of an STS. =C2=A0 We believe this should be relaxed to a SHOULD

=C2=A0

Thanks for any feedback here

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0


--001a113d468ee31972051af0dbcc-- From nobody Wed Jul 15 15:08:23 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D021B2D8A for ; Wed, 15 Jul 2015 15:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.943 X-Spam-Level: X-Spam-Status: No, score=-0.943 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sn3BkFJympuh for ; Wed, 15 Jul 2015 15:08:20 -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 64E401B2D89 for ; Wed, 15 Jul 2015 15:08:20 -0700 (PDT) Received: from pps.filterd (m0074409.ppops.net [127.0.0.1]) by mx0a-0019e102.pphosted.com (8.15.0.59/8.14.7) with SMTP id t6FM4bsV012472 for ; Wed, 15 Jul 2015 17:08:18 -0500 Received: from mail-yk0-f176.google.com (mail-yk0-f176.google.com [209.85.160.176]) by mx0a-0019e102.pphosted.com with ESMTP id 1vnvy1r964-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 15 Jul 2015 17:08:18 -0500 Received: by ykax123 with SMTP id x123so49101164yka.1 for ; Wed, 15 Jul 2015 15:08:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ctKWV6Q5sBLKS0hkCyZf1Dc1lJaw9SdL9q+BhNth8R0=; b=Edc5M3cN9Y42CWuc6wfQKqT/KBLKFVa6bXsOteqiwWPq5pn/MXhAZfevLpXrKFdg11 med5SRzk6ZaoSajB0I2h2SqPYGkaxE/SZsqhNBhGGcl1Kxc++Eeshi1GR0zt//mWv3lC pSgfyDwrvhnOYfiTnGhkzcHv2EyXDeP6KPL8jqQ1tHTP3IhWkVIN/6EyBrhwUAfFdu/A 8yTyqcRazrgtErg0cJLZCt3CyKtESHIQ1OTo0CKluKzxTOBEYDDeoPhsk0d2Bx0X7KTX u+7N2HbI8JCnQus8m6BHFErqIWwK9RjrchMzkTRawmKH34w4rZxHmalrMJjDc1rrMcFb l4Bg== X-Gm-Message-State: ALoCoQkDQDa5qqd7FijtdnZKKapqhECRpwziEmHEpZXtdfVWxWleFRdHLZmWxirBCIiduQLQkesx6CZFM+lcP0yKyFFygYXB2WBhf1c9Kur3t+RKPnr8Xv6wdvXhMCPerXjXY3zj3mgj X-Received: by 10.170.187.134 with SMTP id d128mr6582506yke.103.1436998097265; Wed, 15 Jul 2015 15:08:17 -0700 (PDT) X-Received: by 10.170.187.134 with SMTP id d128mr6582494yke.103.1436998097148; Wed, 15 Jul 2015 15:08:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.214.194 with HTTP; Wed, 15 Jul 2015 15:07:57 -0700 (PDT) In-Reply-To: References: From: Adam Lewis Date: Wed, 15 Jul 2015 17:07:57 -0500 Message-ID: To: Chuck Mortimore Content-Type: multipart/alternative; boundary=001a1139cf221fcbca051af13144 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=1 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1507150292 Archived-At: Cc: OAuth WG Subject: Re: [OAUTH-WG] Use of Token Exchange spec for API Federation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 22:08:22 -0000 --001a1139cf221fcbca051af13144 Content-Type: text/plain; charset=UTF-8 Hi Chuck, Wouldn't the ACDC be a closer fit to what you are doing? Not saying token exchange couldn't work, but ACDC is specifically targeting your use case. -adma On Wed, Jul 15, 2015 at 4:44 PM, Chuck Mortimore wrote: > User logs into Client and accesses Resource1 using AccessToken1 from > TokenService1. > > Client then contacts TokenService2 and exchanges IDToken1 from > TokenService1 for AccessToken2 from TokenService2. It then uses > AccessToken2 to access Resource2. > > -cmort > > > > On Wed, Jul 15, 2015 at 2:27 PM, Anthony Nadalin > wrote: > >> So in your scenario where you have client (c), user (u), resource (r) >> and resource 1(r1) does the flow go like U->C->R-R1 or U->C->R and U->C->R1 >> ? >> >> >> >> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Chuck >> Mortimore >> *Sent:* Wednesday, July 15, 2015 12:47 PM >> *To:* OAuth WG ; Mike Jones >> *Subject:* [OAUTH-WG] Use of Token Exchange spec for API Federation >> >> >> >> We're examining the use of the Token Exchange spec for API federation >> use-cases, and are looking for some feedback. >> >> >> >> The basic use-case is as follows: Developer wants to build an >> Application that is a composite of backend services that span multiple >> security domains. For example, it's a combination of Salesforce data and >> their own backend services. The application is authenticated by >> Salesforce, and developer wants to exchange our ID Token for a token in the >> second security domain so that login / credentials are not required for the >> second back-end service. >> >> >> >> To do this, we're planning to add configuration for multiple audiences in >> our service, allowing the developer to receive a mutli-party ID Token. We >> may also add custom claims to facilitate mapping of identity across the >> services. Having logged into Salesforce, and received an ID Token, the >> developer would then call a Token Exchange service in the second security >> domain and exchange this ID token for a token specific to that domain. >> This allows for simple API federation use-cases without converging both >> APIs / backends on a common token format. >> >> >> >> Questions / Feedback >> >> >> >> 1) In the spec, "sub" is a required field. However, the application may >> not yet know who the subject is in the second security domain ( it first >> has to exchange the token ) One option might be to place the client_id >> of the application as issued by the second security domain, but that seems >> a bit off. Any advice? Should this be an Optional field? >> >> >> >> 2) Speaking of client_ids, if we don't use the "sub" to transport them, >> we believe the second security domain would still appreciate this context. >> The Actor field is available, but construction of a full JWT just to >> transport the client_id seems like high overhead, and it may not even be >> aligned with the intent of that field. Should client_id be a claim here? >> >> >> >> 3) Speaking of Actors, It's not clear what actually states that the jwt >> included in the token is actually an approved actor. Is it intended that >> the act_as or on-behalf_of tokens include an azp authorized party clam as >> well? >> >> >> >> 4) "Implementations of the specification MUST implement support for using >> JWTs as the Security Tokens. Other Security Token types MAY be supported." >> This seems antithetical to the purpose of an STS. We believe this >> should be relaxed to a SHOULD >> >> >> >> Thanks for any feedback here >> >> >> >> >> >> >> >> >> >> >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a1139cf221fcbca051af13144 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Chuck,

Wouldn't the ACDC be a closer fit to= what you are doing?=C2=A0 Not saying token exchange couldn't work, but= ACDC is specifically targeting your use case.

-ad= ma

On = Wed, Jul 15, 2015 at 4:44 PM, Chuck Mortimore <cmortimore@salesfor= ce.com> wrote:
User logs into Client and accesses Resource1 using AccessToken1 f= rom TokenService1. =C2=A0=C2=A0

Client then contac= ts TokenService2 and exchanges IDToken1 from TokenService1 for AccessToken2= from TokenService2. =C2=A0 It then uses AccessToken2 to access Resource2.<= /div>

-cmort



On Wed, Jul 15, 2015 at 2:27 PM, Anthony Nadalin <= span dir=3D"ltr"><tonynad@microsoft.com> wrote:

So in your scenario where you have cl= ient (c), user (u), resource (r) and resource 1(r1) does the flow go like U= ->C->R-R1 or U->C->R and U->C->R1 ?<= /p>

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Chuck Mortimore
Sent: Wednesday, July 15, 2015 12:47 PM
To: OAuth WG <oauth@ietf.org>; Mike Jones <Michael.Jones@microsoft.com> Subject: [OAUTH-WG] Use of Token Exchange spec for API Federation=

=C2=A0

We're examining the use of the Token Exchange sp= ec for API federation use-cases, and are looking for some feedback.<= u>

=C2=A0

The basic use-case is as follows: =C2=A0Developer wa= nts to build an Application that is a composite of backend services that sp= an multiple security domains. =C2=A0 For example, it's a combination of= Salesforce data and their own backend services. =C2=A0 =C2=A0 The application is authenticated by Salesforce, and develope= r wants to exchange our ID Token for a token in the second security domain = so that login / credentials are not required for the second back-end servic= e. =C2=A0=C2=A0

=C2=A0

To do this, we're planning to add configuration = for multiple audiences in our service, allowing the developer to receive a = mutli-party ID Token. =C2=A0 We may also add custom claims to facilitate ma= pping of identity across the services. =C2=A0 Having logged into Salesforce, and received an ID Token, the developer would then= call a Token Exchange service in the second security domain and exchange t= his ID token for a token specific to that domain. =C2=A0 This allows for si= mple API federation use-cases without converging both APIs / backends on a common token format.

=C2=A0

Questions / Feedback

=C2=A0

1) In the spec, "sub" is a required field.= =C2=A0 However, the application may not yet know who the subject is in the= second security domain ( it first has to exchange the token ) =C2=A0 =C2= =A0One option might be to place the client_id of the application as issued by the second security domain, but that seems a bit off. =C2=A0 = Any advice? =C2=A0 Should this be an Optional field?

=C2=A0

2) Speaking of client_ids, if we don't use the &= quot;sub" to transport them, we believe the second security domain wou= ld still appreciate this context. =C2=A0 The Actor field is available, but = construction of a full JWT just to transport the client_id seems like high overhead, and it may not even be aligned with the intent o= f that field. =C2=A0 =C2=A0Should client_id be a claim here?<= /p>

=C2=A0

3) Speaking of Actors, It's not clear what actua= lly states that the jwt included in the token is actually an approved actor= . =C2=A0 =C2=A0Is it intended that the act_as or on-behalf_of tokens includ= e an azp authorized party clam as well?

=C2=A0

4) "Implementations of the specification MUST i= mplement support for using JWTs as the Security Tokens.=C2=A0 Other Securit= y Token types MAY be supported." =C2=A0 This seems antithetical to the= purpose of an STS. =C2=A0 We believe this should be relaxed to a SHOULD

=C2=A0

Thanks for any feedback here

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0



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


--001a1139cf221fcbca051af13144-- From nobody Wed Jul 15 15:38:20 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481AB1B3580 for ; Wed, 15 Jul 2015 15:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FS2H3MClsl-2 for ; Wed, 15 Jul 2015 15:38:15 -0700 (PDT) Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31D0F1B351F for ; Wed, 15 Jul 2015 15:38:15 -0700 (PDT) Received: by oiab3 with SMTP id b3so38744926oia.1 for ; Wed, 15 Jul 2015 15:38:14 -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:date :message-id:subject:from:to:cc:content-type; bh=O2gXCYI4DQruNZV6h5/YD4N/AM6YLtOb9z9A8Awgtns=; b=Bbd92+7CYYnIhJ+UziaCh3lziGE1l9ZE3wacuvUQJA+BFY8QN6oLPddLIJW0FnlPTR YfvASUPydp6ZyOrglJQqtcyYf7sQFc08bowJ2LlCj6acYy3w0zLAPXq+7Ko6iDEieDZ+ kGPCw3tWGB7u884KE5tQCDwGFggDL+BStBNyvde32X1OVG6FrKb0FjMgTwyxHqpJ4yEJ 0pVcEIx4T1Ce+aWUN1hrmRaQYgkwSfvlxtqTwJl/zBpbwvcJYao/qtOlOwM06qLnyGhi y5WkOpx9QUSr6a7b8HiWl2LSLbU+A+e3Dl9WMiojDTzbtwZ97Dmh9U9ajvVms9X++6r7 l+UQ== X-Gm-Message-State: ALoCoQlobD6RviaARJ4ci0IDTZjOJpuQJSr8rN2BI+YejJ/G17FO1qWNlP83iKVtEp5TVaFQH8Ik MIME-Version: 1.0 X-Received: by 10.202.90.5 with SMTP id o5mr5557452oib.79.1436999894535; Wed, 15 Jul 2015 15:38:14 -0700 (PDT) Received: by 10.76.68.162 with HTTP; Wed, 15 Jul 2015 15:38:13 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Jul 2015 15:38:13 -0700 Message-ID: From: Chuck Mortimore To: Adam Lewis Content-Type: multipart/alternative; boundary=001a113d468e41b6ac051af19c6e Archived-At: Cc: OAuth WG Subject: Re: [OAUTH-WG] Use of Token Exchange spec for API Federation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 22:38:18 -0000 --001a113d468e41b6ac051af19c6e Content-Type: text/plain; charset=UTF-8 Thanks Adam - ACDC looks like it's targeted at our use-case. Potentially a little more difficult to layer on to our infrastructure, but looks workable. Does this spec live in OIDC Napps? If so, I'll head over there to ask a few questions -cmort On Wed, Jul 15, 2015 at 3:07 PM, Adam Lewis < adam.lewis@motorolasolutions.com> wrote: > Hi Chuck, > > Wouldn't the ACDC be a closer fit to what you are doing? Not saying token > exchange couldn't work, but ACDC is specifically targeting your use case. > > -adma > > On Wed, Jul 15, 2015 at 4:44 PM, Chuck Mortimore < > cmortimore@salesforce.com> wrote: > >> User logs into Client and accesses Resource1 using AccessToken1 from >> TokenService1. >> >> Client then contacts TokenService2 and exchanges IDToken1 from >> TokenService1 for AccessToken2 from TokenService2. It then uses >> AccessToken2 to access Resource2. >> >> -cmort >> >> >> >> On Wed, Jul 15, 2015 at 2:27 PM, Anthony Nadalin >> wrote: >> >>> So in your scenario where you have client (c), user (u), resource (r) >>> and resource 1(r1) does the flow go like U->C->R-R1 or U->C->R and U->C->R1 >>> ? >>> >>> >>> >>> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Chuck >>> Mortimore >>> *Sent:* Wednesday, July 15, 2015 12:47 PM >>> *To:* OAuth WG ; Mike Jones >> > >>> *Subject:* [OAUTH-WG] Use of Token Exchange spec for API Federation >>> >>> >>> >>> We're examining the use of the Token Exchange spec for API federation >>> use-cases, and are looking for some feedback. >>> >>> >>> >>> The basic use-case is as follows: Developer wants to build an >>> Application that is a composite of backend services that span multiple >>> security domains. For example, it's a combination of Salesforce data and >>> their own backend services. The application is authenticated by >>> Salesforce, and developer wants to exchange our ID Token for a token in the >>> second security domain so that login / credentials are not required for the >>> second back-end service. >>> >>> >>> >>> To do this, we're planning to add configuration for multiple audiences >>> in our service, allowing the developer to receive a mutli-party ID Token. >>> We may also add custom claims to facilitate mapping of identity across the >>> services. Having logged into Salesforce, and received an ID Token, the >>> developer would then call a Token Exchange service in the second security >>> domain and exchange this ID token for a token specific to that domain. >>> This allows for simple API federation use-cases without converging both >>> APIs / backends on a common token format. >>> >>> >>> >>> Questions / Feedback >>> >>> >>> >>> 1) In the spec, "sub" is a required field. However, the application >>> may not yet know who the subject is in the second security domain ( it >>> first has to exchange the token ) One option might be to place the >>> client_id of the application as issued by the second security domain, but >>> that seems a bit off. Any advice? Should this be an Optional field? >>> >>> >>> >>> 2) Speaking of client_ids, if we don't use the "sub" to transport them, >>> we believe the second security domain would still appreciate this context. >>> The Actor field is available, but construction of a full JWT just to >>> transport the client_id seems like high overhead, and it may not even be >>> aligned with the intent of that field. Should client_id be a claim here? >>> >>> >>> >>> 3) Speaking of Actors, It's not clear what actually states that the jwt >>> included in the token is actually an approved actor. Is it intended that >>> the act_as or on-behalf_of tokens include an azp authorized party clam as >>> well? >>> >>> >>> >>> 4) "Implementations of the specification MUST implement support for >>> using JWTs as the Security Tokens. Other Security Token types MAY be >>> supported." This seems antithetical to the purpose of an STS. We >>> believe this should be relaxed to a SHOULD >>> >>> >>> >>> Thanks for any feedback here >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > --001a113d468e41b6ac051af19c6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Adam - =C2=A0ACDC looks like it's targeted at o= ur use-case. =C2=A0 Potentially a little more difficult to layer on to our = infrastructure, but looks workable.

Does this spec live = in OIDC Napps? =C2=A0 If so, I'll head over there to ask a few question= s

-cmort
On Wed, Jul 15, 2015 at 3:07 PM, Adam Lewis <adam.lewis@motorolasolutions.com> wrote:
Hi Chuck,

Wouldn't= the ACDC be a closer fit to what you are doing?=C2=A0 Not saying token exc= hange couldn't work, but ACDC is specifically targeting your use case.<= /div>

-adma

On Wed, Jul 15, 2015 at 4:4= 4 PM, Chuck Mortimore <cmortimore@salesforce.com> wr= ote:
<= div dir=3D"ltr">
User logs into Client and accesses Resource1 using Acc= essToken1 from TokenService1. =C2=A0=C2=A0

Client = then contacts TokenService2 and exchanges IDToken1 from TokenService1 for A= ccessToken2 from TokenService2. =C2=A0 It then uses AccessToken2 to access = Resource2.

-cmort



On Wed, Jul 15, 2015 at 2:27 PM, Anthony Nadalin &l= t;tonynad@micros= oft.com> wrote:

So in your scenario where you have cl= ient (c), user (u), resource (r) and resource 1(r1) does the flow go like U= ->C->R-R1 or U->C->R and U->C->R1 ?<= /p>

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Chuck Mortimore
Sent: Wednesday, July 15, 2015 12:47 PM
To: OAuth WG <oauth@ietf.org>; Mike Jones <Michael.Jones@microsoft.com> Subject: [OAUTH-WG] Use of Token Exchange spec for API Federation=

=C2=A0

We're examining the use of the Token Exchange sp= ec for API federation use-cases, and are looking for some feedback.<= u>

=C2=A0

The basic use-case is as follows: =C2=A0Developer wa= nts to build an Application that is a composite of backend services that sp= an multiple security domains. =C2=A0 For example, it's a combination of= Salesforce data and their own backend services. =C2=A0 =C2=A0 The application is authenticated by Salesforce, and develope= r wants to exchange our ID Token for a token in the second security domain = so that login / credentials are not required for the second back-end servic= e. =C2=A0=C2=A0

=C2=A0

To do this, we're planning to add configuration = for multiple audiences in our service, allowing the developer to receive a = mutli-party ID Token. =C2=A0 We may also add custom claims to facilitate ma= pping of identity across the services. =C2=A0 Having logged into Salesforce, and received an ID Token, the developer would then= call a Token Exchange service in the second security domain and exchange t= his ID token for a token specific to that domain. =C2=A0 This allows for si= mple API federation use-cases without converging both APIs / backends on a common token format.

=C2=A0

Questions / Feedback

=C2=A0

1) In the spec, "sub" is a required field.= =C2=A0 However, the application may not yet know who the subject is in the= second security domain ( it first has to exchange the token ) =C2=A0 =C2= =A0One option might be to place the client_id of the application as issued by the second security domain, but that seems a bit off. =C2=A0 = Any advice? =C2=A0 Should this be an Optional field?

=C2=A0

2) Speaking of client_ids, if we don't use the &= quot;sub" to transport them, we believe the second security domain wou= ld still appreciate this context. =C2=A0 The Actor field is available, but = construction of a full JWT just to transport the client_id seems like high overhead, and it may not even be aligned with the intent o= f that field. =C2=A0 =C2=A0Should client_id be a claim here?<= /p>

=C2=A0

3) Speaking of Actors, It's not clear what actua= lly states that the jwt included in the token is actually an approved actor= . =C2=A0 =C2=A0Is it intended that the act_as or on-behalf_of tokens includ= e an azp authorized party clam as well?

=C2=A0

4) "Implementations of the specification MUST i= mplement support for using JWTs as the Security Tokens.=C2=A0 Other Securit= y Token types MAY be supported." =C2=A0 This seems antithetical to the= purpose of an STS. =C2=A0 We believe this should be relaxed to a SHOULD

=C2=A0

Thanks for any feedback here

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0



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



--001a113d468e41b6ac051af19c6e-- From nobody Wed Jul 15 17:09:47 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8291B29CA for ; Wed, 15 Jul 2015 17:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5stbRFBYQEg for ; Wed, 15 Jul 2015 17:09:41 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F4411B29B7 for ; Wed, 15 Jul 2015 17:09:41 -0700 (PDT) Received: by wibud3 with SMTP id ud3so2061756wib.1 for ; Wed, 15 Jul 2015 17:09:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=mlBa9QqOiMt0Kks5bC1E9onZFXnscm0IpMUZa//7sHA=; b=br00GAGNsKnuZKY5/NXY0VZFYojgoJhAxhrlx7adk76U5YvTa6RcxLYlIKtu0NTs8f +LVOq9jDe6LqFOmYU/yhrKNQf0U1GKK7ntjtSyCemgSeQNV7Fkd3+bY6x1potktiTsAb PvzXtjzUvArd7kU4pWI0Y5s15jA8bAbAQFWU/SbczOWxNBF/uvAHTR0SF89TjMm9uoBD uiAmlflHo1IfH5jbXnw0sFGYZFBptZcJywCGq4XE12qz9Sw7GH+mWbM6GRt9zAX+9W+F RHQu2YcS/xN2jK5O1GaF0Juc3k3bMzGMTycL1N0zgbhCG5LvyX8UcN00lR+Ac5xK+3fk 7DbQ== X-Gm-Message-State: ALoCoQn9UBmHX6PnQlBDIwRg9hcfFNGYoZw4vPuVW+fwi8ntpf889WfWZRfyNKLXsz8oCmjfIgOP X-Received: by 10.180.24.65 with SMTP id s1mr1201516wif.66.1437005380028; Wed, 15 Jul 2015 17:09:40 -0700 (PDT) Received: from [10.207.195.219] ([109.144.232.9]) by smtp.gmail.com with ESMTPSA id h9sm10226174wjx.20.2015.07.15.17.09.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Jul 2015 17:09:38 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_F33AA4BE-337D-43A3-BD4F-34D3E59F910A"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: John Bradley In-Reply-To: Date: Thu, 16 Jul 2015 01:09:36 +0100 Message-Id: <79D9834A-C018-412B-AC64-4E40BE6201EF@ve7jtb.com> References: To: Chuck Mortimore X-Mailer: Apple Mail (2.2102) Archived-At: Cc: OAuth WG Subject: Re: [OAUTH-WG] Use of Token Exchange spec for API Federation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 00:09:45 -0000 --Apple-Mail=_F33AA4BE-337D-43A3-BD4F-34D3E59F910A Content-Type: multipart/alternative; boundary="Apple-Mail=_2E52E2AE-BAA5-4CD9-B7B9-6BB635DC2874" --Apple-Mail=_2E52E2AE-BAA5-4CD9-B7B9-6BB635DC2874 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes it is a NAPPS thing. The pressure for it has been reduced by the release of the Safari view = controller and Chrome custom tabs. However it still has uses for IoT and some other places. It would be best if somehow that could align with the other token = exchange proposals. PKCE just went in to the RFC editor que, and ACDC waits to see if there = is enough demand. John B. > On Jul 15, 2015, at 11:38 PM, Chuck Mortimore = wrote: >=20 > Thanks Adam - ACDC looks like it's targeted at our use-case. = Potentially a little more difficult to layer on to our infrastructure, = but looks workable. >=20 > Does this spec live in OIDC Napps? If so, I'll head over there to = ask a few questions >=20 > -cmort >=20 > On Wed, Jul 15, 2015 at 3:07 PM, Adam Lewis = > wrote: > Hi Chuck, >=20 > Wouldn't the ACDC be a closer fit to what you are doing? Not saying = token exchange couldn't work, but ACDC is specifically targeting your = use case. >=20 > -adma >=20 > On Wed, Jul 15, 2015 at 4:44 PM, Chuck Mortimore = > wrote: > User logs into Client and accesses Resource1 using AccessToken1 from = TokenService1. =20 >=20 > Client then contacts TokenService2 and exchanges IDToken1 from = TokenService1 for AccessToken2 from TokenService2. It then uses = AccessToken2 to access Resource2. >=20 > -cmort >=20 >=20 >=20 > On Wed, Jul 15, 2015 at 2:27 PM, Anthony Nadalin = > wrote: > So in your scenario where you have client (c), user (u), resource (r) = and resource 1(r1) does the flow go like U->C->R-R1 or U->C->R and = U->C->R1 ? >=20 > =C2=A0 <> > From: OAuth [mailto:oauth-bounces@ietf.org = ] On Behalf Of Chuck Mortimore > Sent: Wednesday, July 15, 2015 12:47 PM > To: OAuth WG >; Mike Jones = > > Subject: [OAUTH-WG] Use of Token Exchange spec for API Federation >=20 > =20 >=20 > We're examining the use of the Token Exchange spec for API federation = use-cases, and are looking for some feedback. >=20 > =20 >=20 > The basic use-case is as follows: Developer wants to build an = Application that is a composite of backend services that span multiple = security domains. For example, it's a combination of Salesforce data = and their own backend services. The application is authenticated by = Salesforce, and developer wants to exchange our ID Token for a token in = the second security domain so that login / credentials are not required = for the second back-end service. =20 >=20 > =20 >=20 > To do this, we're planning to add configuration for multiple audiences = in our service, allowing the developer to receive a mutli-party ID = Token. We may also add custom claims to facilitate mapping of identity = across the services. Having logged into Salesforce, and received an ID = Token, the developer would then call a Token Exchange service in the = second security domain and exchange this ID token for a token specific = to that domain. This allows for simple API federation use-cases = without converging both APIs / backends on a common token format. >=20 > =20 >=20 > Questions / Feedback >=20 > =20 >=20 > 1) In the spec, "sub" is a required field. However, the application = may not yet know who the subject is in the second security domain ( it = first has to exchange the token ) One option might be to place the = client_id of the application as issued by the second security domain, = but that seems a bit off. Any advice? Should this be an Optional = field? >=20 > =20 >=20 > 2) Speaking of client_ids, if we don't use the "sub" to transport = them, we believe the second security domain would still appreciate this = context. The Actor field is available, but construction of a full JWT = just to transport the client_id seems like high overhead, and it may not = even be aligned with the intent of that field. Should client_id be a = claim here? >=20 > =20 >=20 > 3) Speaking of Actors, It's not clear what actually states that the = jwt included in the token is actually an approved actor. Is it = intended that the act_as or on-behalf_of tokens include an azp = authorized party clam as well? >=20 > =20 >=20 > 4) "Implementations of the specification MUST implement support for = using JWTs as the Security Tokens. Other Security Token types MAY be = supported." This seems antithetical to the purpose of an STS. We = believe this should be relaxed to a SHOULD >=20 > =20 >=20 > Thanks for any feedback here >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_2E52E2AE-BAA5-4CD9-B7B9-6BB635DC2874 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Yes it is a NAPPS thing.

The pressure for it has been reduced by = the release of the Safari view controller and Chrome custom = tabs.

However = it still has uses for IoT and some other places.

It would be best if somehow that could = align with the other token exchange proposals.

PKCE just went in to the RFC editor = que, and ACDC waits to see if there is enough demand.

John B.

On Jul 15, 2015, at 11:38 PM, Chuck Mortimore <cmortimore@salesforce.com> wrote:

Thanks Adam -  ACDC looks like it's targeted at our = use-case.   Potentially a little more difficult to layer on to our = infrastructure, but looks workable.

Does this spec live in OIDC Napps? =   If so, I'll head over there to ask a few questions

-cmort

On Wed, = Jul 15, 2015 at 3:07 PM, Adam Lewis <adam.lewis@motorolasolutions.com> wrote:
Hi Chuck,

Wouldn't the ACDC be = a closer fit to what you are doing?  Not saying token exchange = couldn't work, but ACDC is specifically targeting your use = case.

-adma

On Wed, Jul 15, = 2015 at 4:44 PM, Chuck Mortimore <cmortimore@salesforce.com> wrote:
User logs into Client and accesses Resource1 using = AccessToken1 from TokenService1.   

Client then contacts TokenService2 and = exchanges IDToken1 from TokenService1 for AccessToken2 from = TokenService2.   It then uses AccessToken2 to access = Resource2.

-cmort



On Wed, Jul 15, 2015 at 2:27 PM, Anthony Nadalin = <tonynad@microsoft.com> = wrote:

So in your scenario where you have client (c), user = (u), resource (r) and resource 1(r1) does the flow go like = U->C->R-R1 or U->C->R and U->C->R1 ?

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Chuck Mortimore
Sent: Wednesday, July 15, 2015 12:47 PM
To: OAuth WG <oauth@ietf.org>; Mike Jones <Michael.Jones@microsoft.com>
Subject: [OAUTH-WG] Use of Token Exchange spec for API = Federation

 

We're examining the use of the = Token Exchange spec for API federation use-cases, and are looking for = some feedback.

 

The basic use-case is as follows: =  Developer wants to build an Application that is a composite of = backend services that span multiple security domains.   For = example, it's a combination of Salesforce data and their own backend = services.     The application is authenticated by Salesforce, and = developer wants to exchange our ID Token for a token in the second = security domain so that login / credentials are not required for the = second back-end service.   

 

To do this, we're planning to add = configuration for multiple audiences in our service, allowing the = developer to receive a mutli-party ID Token.   We may also add = custom claims to facilitate mapping of identity across the services. =   Having logged into Salesforce, and received an ID Token, the developer would = then call a Token Exchange service in the second security domain and = exchange this ID token for a token specific to that domain.   This = allows for simple API federation use-cases without converging both APIs / backends on a common token format.

 

Questions / Feedback

 

1) In the spec, "sub" is a = required field.   However, the application may not yet know who the = subject is in the second security domain ( it first has to exchange the = token )    One option might be to place the client_id of the = application as issued by the second security domain, but that seems a bit off. =   Any advice?   Should this be an Optional field?

 

2) Speaking of client_ids, if we = don't use the "sub" to transport them, we believe the second security = domain would still appreciate this context.   The Actor field is = available, but construction of a full JWT just to transport the = client_id seems like high overhead, and it may not even be aligned with the = intent of that field.    Should client_id be a claim here?

 

3) Speaking of Actors, It's not = clear what actually states that the jwt included in the token is = actually an approved actor.    Is it intended that the act_as = or on-behalf_of tokens include an azp authorized party clam as well?

 

4) "Implementations of the = specification MUST implement support for using JWTs as the Security = Tokens.  Other Security Token types MAY be supported."   This = seems antithetical to the purpose of an STS.   We believe this = should be relaxed to a SHOULD

 

Thanks for any feedback here

 

 

 

 

 



_______________________________________________
OAuth mailing 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=_2E52E2AE-BAA5-4CD9-B7B9-6BB635DC2874-- --Apple-Mail=_F33AA4BE-337D-43A3-BD4F-34D3E59F910A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTA3MTYwMDA5MzdaMCMGCSqGSIb3DQEJBDEWBBTQpcnSZ0LHq6lke0zf7Nys Z4YJ9DCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQAaCEuFAZIIAffkMQkm8D0lS/zJmSUQ6z5IaMH79XmjVDoPVNNgOT2i Hm8AotBt3FL7BKTTfjOzQp8X2tGn0DJWMd6lk+uTkGec9ifd/qig0i+P6LwittddhvdQ8l65GrwT VzLkAdEsoLasXgMHE4mOzJwjTiZkLNkkE2+a+baIcXkwasI/NkiVQlHZ4QAjpCgyDNfc1sIMMlup QUZxoMel70CTDJLrBncGx+0ZkC5+cvPfreNQg+Q1UJ0TJZ9bRwlD+Z8eklxgAozOb1ZDDY/1Rr88 jkeh/5iUlMCtCAXhkcMdjAli9pTvZsl/zTVTnRFofRhHsTaYgWajoaC27iNsAAAAAAAA --Apple-Mail=_F33AA4BE-337D-43A3-BD4F-34D3E59F910A-- From nobody Wed Jul 15 17:54:27 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62AB1B2BB1 for ; Wed, 15 Jul 2015 17:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-D3j6ppn1dy for ; Wed, 15 Jul 2015 17:54:21 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0709.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:709]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F93D1B2BAF for ; Wed, 15 Jul 2015 17:54:21 -0700 (PDT) Received: from BY1PR0301MB1239.namprd03.prod.outlook.com (10.161.203.23) by BY1PR0301MB1176.namprd03.prod.outlook.com (10.160.195.147) with Microsoft SMTP Server (TLS) id 15.1.213.14; Thu, 16 Jul 2015 00:14:48 +0000 Received: from BLUPR03MB437.namprd03.prod.outlook.com (10.141.78.147) by BY1PR0301MB1239.namprd03.prod.outlook.com (10.161.203.23) with Microsoft SMTP Server (TLS) id 15.1.213.14; Thu, 16 Jul 2015 00:14:44 +0000 Received: from BLUPR03MB437.namprd03.prod.outlook.com ([10.141.78.147]) by BLUPR03MB437.namprd03.prod.outlook.com ([10.141.78.147]) with mapi id 15.01.0219.000; Thu, 16 Jul 2015 00:14:43 +0000 From: Mike Jones To: Chuck Mortimore , Anthony Nadalin Thread-Topic: [OAUTH-WG] Use of Token Exchange spec for API Federation Thread-Index: AQHQvzcGruLhiPPVYkaeX4g7XEW8Pp3dC6EAgAAEyYCAACgqoA== Date: Thu, 16 Jul 2015 00:14:43 +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: salesforce.com; dkim=none (message not signed) header.d=none; x-originating-ip: [50.47.90.173] x-microsoft-exchange-diagnostics: 1; BY1PR0301MB1239; 5:r7zZ3bgvLWzxTQuMJRrqibLAxKaH/miqZcSOP5PT/6VhNGQeeLjHJL5z9xeyYeGlJKnoeHJK0VQAPuTu4Mi/pWjzRGGJ0xM05FDp6FCnNcXoDd08dymyo0O975owDJycHheAdqJL6QtthFbUbeaKwg==; 24:nxJZ210AhpUgTKW4DRsdsffm2bfn7lDmv1S/1+GUhTxR6QdxYR9gZCLpJ7AckKtngVQ7JfAZTGuRJ7B0ocp1NB1OUpv9zi8/5tQhSjdsugs=; 20:GhkSm0UQ5VL3zh9E9M+42O6XrXT3jLcAI1/euNJEKsnXZN1s0LQEG/cOW5Pqi6s+mwLXg1hSs4hwb/ykw6fXRQ== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0301MB1239; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0301MB1176; by1pr0301mb1239: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY1PR0301MB1239; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0301MB1239; x-forefront-prvs: 0639027A9E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(52604005)(66066001)(2561002)(77156002)(15975445007)(5001960100002)(46102003)(5001770100001)(5003600100002)(16236675004)(86362001)(54356999)(102836002)(5002640100001)(2900100001)(77096005)(19580395003)(62966003)(19580405001)(2950100001)(40100003)(122556002)(76576001)(76176999)(189998001)(50986999)(2656002)(2421001)(106116001)(74316001)(19625215002)(92566002)(1511001)(99286002)(33656002)(19300405004)(87936001)(4001450100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB1239; H:BLUPR03MB437.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BLUPR03MB43719509D0527C7D7D5DB82F5990BLUPR03MB437namprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2015 00:14:43.9008 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0301MB1239 X-Microsoft-Exchange-Diagnostics: 1; BY1PR0301MB1176; 2:tH5R2FPOyHCRpH/zBz+yma/lpTNztZj9U9bZnCdk9pc0laGHKltoKR7kcTv1mtXx; 3:EyWiAwAnBx+2Anr1vLx6rl403bHaOoG7pS+dYXXDbSMxwCSGMoc98134VpQyAXQXL/3RA0h1BVGjTARHgDrlO/MIVFULU+RTBa+ZgoU6rzKZwenhgTIgyjDhurl8G1ckUGGvU2W3I7wKp/ZC1r0MiA==; 25:LMwI2vcFw1i2UKuBmphWvgLITnLHerwMr72BDYsLJxGluYHr6QGqv0QQhdCowQeVr5yRlOyCberf7EkslsR0gFxtOXJ2hibaF3zn0zxLbtxEs5z+iDWFNW3ukSBV5WS26wBkt3RQhTiJPVmiHREL4ftkzAykqqdowIjyBouOAa2EZ+NrlPzmS9TV48JAHQlNG93dPFlrxJ4CXpPsWtEpPnXkveLbs986NA1UenmfgwviR8SWk8aoeetJOIoHd4tEdR2xNpiPTrluUpBxxAF82w== X-Microsoft-Exchange-Diagnostics: 1; BY1PR0301MB1176; 20:pxWehxav0pqPzS879zigbqzYvbtlVM+qA0zA2x1YKf/oK93etRgFdWX2RLfrR4MJS2B5PQcTaitfWM4LksQXmcrMXb4FQciArKjuApQFP7VSlB2VOxe95Iq8YJQpAhid/9Km46m+IiQC70PAfJ+KU2/EarXSsJTC2v1y3ny9Ckk62OhV/kk8qk0imuqRoV+nKtX+cmK3zOB2Bv3xIbuL8DQGieZd6ht/wEtrAfna5IILABXlnCv91Z2ovKZLlI9R4WI1hZe1MEk2i/w13+W4CWS0uV5fK0TNKGwH+ArLfUh2Cu/zC8JgfmRZHmLB+fUM5sGFcFqVjbW0CyOOgTi9dAz7013Sxs+O+ishk83jwDC6h/QV1CLDODDGkvhTT4Ew2bFMrMktJqKC4loLkL50licDP8N03YnHWVQ26kT6+0sfTtBSmBbdQvZrMGdvmBDNZMQ8E0Ap7BRvo2RihYBmY9WzV752+4xDBs1UkDuJLTsi1igcWg50Md8j3xgK9Qg0; 23:5WJjgKqLtmUykZbyINPdH5AvBJb5UlLHX8RH2L2txQojk7uAtug09UKbUylwfRyhsGZKDEk/AeK6uMO1VMp6D6m162DgQizJbwPJw6NaJx24R1QJ0k+YYy2Flata5C8RLuvRVilr1k/DscNZMxpHE42TmDaJSspSVGT1ZnIacYq+s3OzFqioxy/IVB9CRoUKjXmkKbYixq6bkr9EH9STUs+A8wiao+D0IOqDgRcxbWGjkMQB0Gy/VfLK7gv6O0mc BY1PR0301MB1176: X-MS-Exchange-Organization-RulesExecuted X-OriginatorOrg: microsoft.com Archived-At: Cc: OAuth WG Subject: Re: [OAUTH-WG] Use of Token Exchange spec for API Federation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 00:54:25 -0000 --_000_BLUPR03MB43719509D0527C7D7D5DB82F5990BLUPR03MB437namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhc3N1bWUgdGhhdCBUb2tlblNlcnZpY2UxIGlzIGFuIE9wZW5JRCBDb25uZWN0IFByb3ZpZGVy LCBzaW5jZSBpdOKAmXMgaXNzdWluZyBib3RoIGFuIGFjY2VzcyB0b2tlbiBhbmQgYW4gSUQgVG9r ZW4sIGNvcnJlY3Q/DQoNCkkgYXNzdW1lIHRoYXQgeW91IHdhbnQgdGhlIGludGVyYWN0aW9uIHdp dGggVG9rZW5TZXJ2aWNlMiB0byBub3QgaW5jbHVkZSBhbnkgdXNlciBpbnRlcmFjdGlvbiDigJMg dGhhdCB0aGF04oCZcyB3aGVyZSB5b3XigJlyZSBkb2luZyB0aGUgVG9rZW4gRXhjaGFuZ2Ug4oCT IGNvcnJlY3Q/DQoNCkhvdyBkaWQgeW91IGVudmlzaW9uIHRoZSBDbGllbnQgYXV0aGVudGljYXRp bmcgdG8gVG9rZW5TZXJ2aWNlMj8gIElzIGl0IGEgcmVnaXN0ZXJlZCBPQXV0aCAyLjAgY2xpZW50 IGF0IFRva2VuU2VydmljZTIgdXNpbmcgYSBDbGllbnQgQXV0aGVudGljYXRpb24gbWV0aG9kPyAg SXMgaXQgc2lnbmluZyBhIHJlcXVlc3QgdG8gVG9rZW5TZXJ2aWNlMiBhbmQgVG9rZW5TZXJ2aWNl MiB2YWxpZGF0ZXMgYW5kIHRydXN0cyB0aGUgc2lnbmF0dXJlIGJ5IENsaWVudD8gIElzIG5vIGF1 dGhlbnRpY2F0aW9uIHBlcmZvcm1lZCBvdGhlciB0aGFuIGJlaW5nIGluIHBvc3Nlc3Npb24gb2Yg dGhlIElEIFRva2VuIHNlcnZpbmcgYXMgcHJvb2YgdGhhdCB0aGUgcmVxdWVzdGVyIGhhcyBuZWNl c3NhcnkgcmlnaHRzIHRvIGRvIHRoZSB0b2tlbiBleGNoYW5nZT8gIE9yIHNvbWUgY29tYmluYXRp b24gb2YgdGhlc2XigKY/DQoNCktub3dpbmcgeW91ciB1c2UgY2FzZSBpcyByZWFsbHkgdmFsdWFi bGUuICBUaGFua3MgZm9yIGRlc2NyaWJpbmcgaXQgZm9yIHVzLg0KDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZy b206IENodWNrIE1vcnRpbW9yZSBbbWFpbHRvOmNtb3J0aW1vcmVAc2FsZXNmb3JjZS5jb21dDQpT ZW50OiBXZWRuZXNkYXksIEp1bHkgMTUsIDIwMTUgMjo0NCBQTQ0KVG86IEFudGhvbnkgTmFkYWxp bg0KQ2M6IE9BdXRoIFdHOyBNaWtlIEpvbmVzDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBVc2Ug b2YgVG9rZW4gRXhjaGFuZ2Ugc3BlYyBmb3IgQVBJIEZlZGVyYXRpb24NCg0KVXNlciBsb2dzIGlu dG8gQ2xpZW50IGFuZCBhY2Nlc3NlcyBSZXNvdXJjZTEgdXNpbmcgQWNjZXNzVG9rZW4xIGZyb20g VG9rZW5TZXJ2aWNlMS4NCg0KQ2xpZW50IHRoZW4gY29udGFjdHMgVG9rZW5TZXJ2aWNlMiBhbmQg ZXhjaGFuZ2VzIElEVG9rZW4xIGZyb20gVG9rZW5TZXJ2aWNlMSBmb3IgQWNjZXNzVG9rZW4yIGZy b20gVG9rZW5TZXJ2aWNlMi4gICBJdCB0aGVuIHVzZXMgQWNjZXNzVG9rZW4yIHRvIGFjY2VzcyBS ZXNvdXJjZTIuDQoNCi1jbW9ydA0KDQoNCg0KT24gV2VkLCBKdWwgMTUsIDIwMTUgYXQgMjoyNyBQ TSwgQW50aG9ueSBOYWRhbGluIDx0b255bmFkQG1pY3Jvc29mdC5jb208bWFpbHRvOnRvbnluYWRA bWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KU28gaW4geW91ciBzY2VuYXJpbyB3aGVyZSB5b3UgaGF2 ZSBjbGllbnQgKGMpLCB1c2VyICh1KSwgcmVzb3VyY2UgKHIpIGFuZCByZXNvdXJjZSAxKHIxKSBk b2VzIHRoZSBmbG93IGdvIGxpa2UgVS0+Qy0+Ui1SMSBvciBVLT5DLT5SIGFuZCBVLT5DLT5SMSA/ DQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1 dGgtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBDaHVjayBNb3J0aW1vcmUNClNlbnQ6 IFdlZG5lc2RheSwgSnVseSAxNSwgMjAxNSAxMjo0NyBQTQ0KVG86IE9BdXRoIFdHIDxvYXV0aEBp ZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+PjsgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+Pg0KU3Vi amVjdDogW09BVVRILVdHXSBVc2Ugb2YgVG9rZW4gRXhjaGFuZ2Ugc3BlYyBmb3IgQVBJIEZlZGVy YXRpb24NCg0KV2UncmUgZXhhbWluaW5nIHRoZSB1c2Ugb2YgdGhlIFRva2VuIEV4Y2hhbmdlIHNw ZWMgZm9yIEFQSSBmZWRlcmF0aW9uIHVzZS1jYXNlcywgYW5kIGFyZSBsb29raW5nIGZvciBzb21l IGZlZWRiYWNrLg0KDQpUaGUgYmFzaWMgdXNlLWNhc2UgaXMgYXMgZm9sbG93czogIERldmVsb3Bl ciB3YW50cyB0byBidWlsZCBhbiBBcHBsaWNhdGlvbiB0aGF0IGlzIGEgY29tcG9zaXRlIG9mIGJh Y2tlbmQgc2VydmljZXMgdGhhdCBzcGFuIG11bHRpcGxlIHNlY3VyaXR5IGRvbWFpbnMuICAgRm9y IGV4YW1wbGUsIGl0J3MgYSBjb21iaW5hdGlvbiBvZiBTYWxlc2ZvcmNlIGRhdGEgYW5kIHRoZWly IG93biBiYWNrZW5kIHNlcnZpY2VzLiAgICAgVGhlIGFwcGxpY2F0aW9uIGlzIGF1dGhlbnRpY2F0 ZWQgYnkgU2FsZXNmb3JjZSwgYW5kIGRldmVsb3BlciB3YW50cyB0byBleGNoYW5nZSBvdXIgSUQg VG9rZW4gZm9yIGEgdG9rZW4gaW4gdGhlIHNlY29uZCBzZWN1cml0eSBkb21haW4gc28gdGhhdCBs b2dpbiAvIGNyZWRlbnRpYWxzIGFyZSBub3QgcmVxdWlyZWQgZm9yIHRoZSBzZWNvbmQgYmFjay1l bmQgc2VydmljZS4NCg0KVG8gZG8gdGhpcywgd2UncmUgcGxhbm5pbmcgdG8gYWRkIGNvbmZpZ3Vy YXRpb24gZm9yIG11bHRpcGxlIGF1ZGllbmNlcyBpbiBvdXIgc2VydmljZSwgYWxsb3dpbmcgdGhl IGRldmVsb3BlciB0byByZWNlaXZlIGEgbXV0bGktcGFydHkgSUQgVG9rZW4uICAgV2UgbWF5IGFs c28gYWRkIGN1c3RvbSBjbGFpbXMgdG8gZmFjaWxpdGF0ZSBtYXBwaW5nIG9mIGlkZW50aXR5IGFj cm9zcyB0aGUgc2VydmljZXMuICAgSGF2aW5nIGxvZ2dlZCBpbnRvIFNhbGVzZm9yY2UsIGFuZCBy ZWNlaXZlZCBhbiBJRCBUb2tlbiwgdGhlIGRldmVsb3BlciB3b3VsZCB0aGVuIGNhbGwgYSBUb2tl biBFeGNoYW5nZSBzZXJ2aWNlIGluIHRoZSBzZWNvbmQgc2VjdXJpdHkgZG9tYWluIGFuZCBleGNo YW5nZSB0aGlzIElEIHRva2VuIGZvciBhIHRva2VuIHNwZWNpZmljIHRvIHRoYXQgZG9tYWluLiAg IFRoaXMgYWxsb3dzIGZvciBzaW1wbGUgQVBJIGZlZGVyYXRpb24gdXNlLWNhc2VzIHdpdGhvdXQg Y29udmVyZ2luZyBib3RoIEFQSXMgLyBiYWNrZW5kcyBvbiBhIGNvbW1vbiB0b2tlbiBmb3JtYXQu DQoNClF1ZXN0aW9ucyAvIEZlZWRiYWNrDQoNCjEpIEluIHRoZSBzcGVjLCAic3ViIiBpcyBhIHJl cXVpcmVkIGZpZWxkLiAgIEhvd2V2ZXIsIHRoZSBhcHBsaWNhdGlvbiBtYXkgbm90IHlldCBrbm93 IHdobyB0aGUgc3ViamVjdCBpcyBpbiB0aGUgc2Vjb25kIHNlY3VyaXR5IGRvbWFpbiAoIGl0IGZp cnN0IGhhcyB0byBleGNoYW5nZSB0aGUgdG9rZW4gKSAgICBPbmUgb3B0aW9uIG1pZ2h0IGJlIHRv IHBsYWNlIHRoZSBjbGllbnRfaWQgb2YgdGhlIGFwcGxpY2F0aW9uIGFzIGlzc3VlZCBieSB0aGUg c2Vjb25kIHNlY3VyaXR5IGRvbWFpbiwgYnV0IHRoYXQgc2VlbXMgYSBiaXQgb2ZmLiAgIEFueSBh ZHZpY2U/ICAgU2hvdWxkIHRoaXMgYmUgYW4gT3B0aW9uYWwgZmllbGQ/DQoNCjIpIFNwZWFraW5n IG9mIGNsaWVudF9pZHMsIGlmIHdlIGRvbid0IHVzZSB0aGUgInN1YiIgdG8gdHJhbnNwb3J0IHRo ZW0sIHdlIGJlbGlldmUgdGhlIHNlY29uZCBzZWN1cml0eSBkb21haW4gd291bGQgc3RpbGwgYXBw cmVjaWF0ZSB0aGlzIGNvbnRleHQuICAgVGhlIEFjdG9yIGZpZWxkIGlzIGF2YWlsYWJsZSwgYnV0 IGNvbnN0cnVjdGlvbiBvZiBhIGZ1bGwgSldUIGp1c3QgdG8gdHJhbnNwb3J0IHRoZSBjbGllbnRf aWQgc2VlbXMgbGlrZSBoaWdoIG92ZXJoZWFkLCBhbmQgaXQgbWF5IG5vdCBldmVuIGJlIGFsaWdu ZWQgd2l0aCB0aGUgaW50ZW50IG9mIHRoYXQgZmllbGQuICAgIFNob3VsZCBjbGllbnRfaWQgYmUg YSBjbGFpbSBoZXJlPw0KDQozKSBTcGVha2luZyBvZiBBY3RvcnMsIEl0J3Mgbm90IGNsZWFyIHdo YXQgYWN0dWFsbHkgc3RhdGVzIHRoYXQgdGhlIGp3dCBpbmNsdWRlZCBpbiB0aGUgdG9rZW4gaXMg YWN0dWFsbHkgYW4gYXBwcm92ZWQgYWN0b3IuICAgIElzIGl0IGludGVuZGVkIHRoYXQgdGhlIGFj dF9hcyBvciBvbi1iZWhhbGZfb2YgdG9rZW5zIGluY2x1ZGUgYW4gYXpwIGF1dGhvcml6ZWQgcGFy dHkgY2xhbSBhcyB3ZWxsPw0KDQo0KSAiSW1wbGVtZW50YXRpb25zIG9mIHRoZSBzcGVjaWZpY2F0 aW9uIE1VU1QgaW1wbGVtZW50IHN1cHBvcnQgZm9yIHVzaW5nIEpXVHMgYXMgdGhlIFNlY3VyaXR5 IFRva2Vucy4gIE90aGVyIFNlY3VyaXR5IFRva2VuIHR5cGVzIE1BWSBiZSBzdXBwb3J0ZWQuIiAg IFRoaXMgc2VlbXMgYW50aXRoZXRpY2FsIHRvIHRoZSBwdXJwb3NlIG9mIGFuIFNUUy4gICBXZSBi ZWxpZXZlIHRoaXMgc2hvdWxkIGJlIHJlbGF4ZWQgdG8gYSBTSE9VTEQNCg0KVGhhbmtzIGZvciBh bnkgZmVlZGJhY2sgaGVyZQ0KDQoNCg0KDQoNCg0K --_000_BLUPR03MB43719509D0527C7D7D5DB82F5990BLUPR03MB437namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5JIGFzc3VtZSB0aGF0IFRva2VuU2VydmljZTEgaXMgYW4gT3BlbklEIENvbm5lY3QgUHJv dmlkZXIsIHNpbmNlIGl04oCZcyBpc3N1aW5nIGJvdGggYW4gYWNjZXNzIHRva2VuIGFuZCBhbiBJ RCBUb2tlbiwgY29ycmVjdD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYXNzdW1lIHRoYXQgeW91IHdhbnQgdGhlIGlu dGVyYWN0aW9uIHdpdGggVG9rZW5TZXJ2aWNlMiB0byBub3QgaW5jbHVkZSBhbnkgdXNlciBpbnRl cmFjdGlvbiDigJMgdGhhdCB0aGF04oCZcyB3aGVyZSB5b3XigJlyZSBkb2luZyB0aGUgVG9rZW4g RXhjaGFuZ2Ug4oCTIGNvcnJlY3Q/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ib3cgZGlkIHlvdSBlbnZpc2lvbiB0aGUg Q2xpZW50IGF1dGhlbnRpY2F0aW5nIHRvIFRva2VuU2VydmljZTI/Jm5ic3A7IElzIGl0IGEgcmVn aXN0ZXJlZCBPQXV0aCAyLjAgY2xpZW50IGF0IFRva2VuU2VydmljZTIgdXNpbmcgYSBDbGllbnQg QXV0aGVudGljYXRpb24gbWV0aG9kPyZuYnNwOw0KIElzIGl0IHNpZ25pbmcgYSByZXF1ZXN0IHRv IFRva2VuU2VydmljZTIgYW5kIFRva2VuU2VydmljZTIgdmFsaWRhdGVzIGFuZCB0cnVzdHMgdGhl IHNpZ25hdHVyZSBieSBDbGllbnQ/Jm5ic3A7IElzIG5vIGF1dGhlbnRpY2F0aW9uIHBlcmZvcm1l ZCBvdGhlciB0aGFuIGJlaW5nIGluIHBvc3Nlc3Npb24gb2YgdGhlIElEIFRva2VuIHNlcnZpbmcg YXMgcHJvb2YgdGhhdCB0aGUgcmVxdWVzdGVyIGhhcyBuZWNlc3NhcnkgcmlnaHRzIHRvIGRvIHRo ZSB0b2tlbg0KIGV4Y2hhbmdlPyZuYnNwOyBPciBzb21lIGNvbWJpbmF0aW9uIG9mIHRoZXNl4oCm PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+S25vd2luZyB5b3VyIHVzZSBjYXNlIGlzIHJlYWxseSB2YWx1YWJsZS4mbmJz cDsgVGhhbmtzIGZvciBkZXNjcmliaW5nIGl0IGZvciB1cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBDaHVj ayBNb3J0aW1vcmUgW21haWx0bzpjbW9ydGltb3JlQHNhbGVzZm9yY2UuY29tXQ0KPGJyPg0KPGI+ U2VudDo8L2I+IFdlZG5lc2RheSwgSnVseSAxNSwgMjAxNSAyOjQ0IFBNPGJyPg0KPGI+VG86PC9i PiBBbnRob255IE5hZGFsaW48YnI+DQo8Yj5DYzo8L2I+IE9BdXRoIFdHOyBNaWtlIEpvbmVzPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFVzZSBvZiBUb2tlbiBFeGNoYW5nZSBz cGVjIGZvciBBUEkgRmVkZXJhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Vc2VyIGxvZ3MgaW50byBDbGllbnQgYW5kIGFjY2Vzc2VzIFJlc291cmNlMSB1 c2luZyBBY2Nlc3NUb2tlbjEgZnJvbSBUb2tlblNlcnZpY2UxLiAmbmJzcDsmbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2xpZW50IHRo ZW4gY29udGFjdHMgVG9rZW5TZXJ2aWNlMiBhbmQgZXhjaGFuZ2VzIElEVG9rZW4xIGZyb20gVG9r ZW5TZXJ2aWNlMSBmb3IgQWNjZXNzVG9rZW4yIGZyb20gVG9rZW5TZXJ2aWNlMi4gJm5ic3A7IEl0 IHRoZW4gdXNlcyBBY2Nlc3NUb2tlbjIgdG8gYWNjZXNzIFJlc291cmNlMi48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LWNtb3J0PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQs IEp1bCAxNSwgMjAxNSBhdCAyOjI3IFBNLCBBbnRob255IE5hZGFsaW4gJmx0OzxhIGhyZWY9Im1h aWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj50b255bmFkQG1pY3Jv c29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+U28gaW4geW91ciBzY2VuYXJpbyB3aGVyZSB5b3UgaGF2ZSBjbGllbnQgKGMpLCB1c2Vy ICh1KSwgcmVzb3VyY2UgKHIpIGFuZCByZXNvdXJjZSAxKHIxKSBkb2VzIHRoZQ0KIGZsb3cgZ28g bGlrZSBVLSZndDtDLSZndDtSLVIxIG9yIFUtJmd0O0MtJmd0O1IgYW5kIFUtJmd0O0MtJmd0O1Ix ID88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIG5hbWU9 IjE0ZTkzYTMwMGU0MjU5NzVfX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gT0F1dGggW21haWx0bzo8 YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9h dXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5DaHVjayBNb3J0 aW1vcmU8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKdWx5IDE1LCAyMDE1IDEyOjQ3IFBN PGJyPg0KPGI+VG86PC9iPiBPQXV0aCBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0OzsgTWlrZSBKb25lcyAm bHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJf YmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVj dDo8L2I+IFtPQVVUSC1XR10gVXNlIG9mIFRva2VuIEV4Y2hhbmdlIHNwZWMgZm9yIEFQSSBGZWRl cmF0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+V2UncmUgZXhhbWluaW5nIHRoZSB1c2Ugb2YgdGhlIFRva2VuIEV4Y2hhbmdlIHNwZWMg Zm9yIEFQSSBmZWRlcmF0aW9uIHVzZS1jYXNlcywgYW5kIGFyZSBsb29raW5nIGZvciBzb21lIGZl ZWRiYWNrLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PlRoZSBiYXNpYyB1c2UtY2FzZSBpcyBhcyBmb2xsb3dzOiAmbmJzcDtEZXZlbG9wZXIgd2FudHMg dG8gYnVpbGQgYW4gQXBwbGljYXRpb24gdGhhdCBpcyBhIGNvbXBvc2l0ZSBvZiBiYWNrZW5kIHNl cnZpY2VzIHRoYXQgc3BhbiBtdWx0aXBsZSBzZWN1cml0eSBkb21haW5zLiAmbmJzcDsgRm9yIGV4 YW1wbGUsIGl0J3MgYSBjb21iaW5hdGlvbg0KIG9mIFNhbGVzZm9yY2UgZGF0YSBhbmQgdGhlaXIg b3duIGJhY2tlbmQgc2VydmljZXMuICZuYnNwOyAmbmJzcDsgVGhlIGFwcGxpY2F0aW9uIGlzIGF1 dGhlbnRpY2F0ZWQgYnkgU2FsZXNmb3JjZSwgYW5kIGRldmVsb3BlciB3YW50cyB0byBleGNoYW5n ZSBvdXIgSUQgVG9rZW4gZm9yIGEgdG9rZW4gaW4gdGhlIHNlY29uZCBzZWN1cml0eSBkb21haW4g c28gdGhhdCBsb2dpbiAvIGNyZWRlbnRpYWxzIGFyZSBub3QgcmVxdWlyZWQgZm9yIHRoZSBzZWNv bmQgYmFjay1lbmQNCiBzZXJ2aWNlLiAmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRvIGRvIHRoaXMsIHdlJ3JlIHBs YW5uaW5nIHRvIGFkZCBjb25maWd1cmF0aW9uIGZvciBtdWx0aXBsZSBhdWRpZW5jZXMgaW4gb3Vy IHNlcnZpY2UsIGFsbG93aW5nIHRoZSBkZXZlbG9wZXIgdG8gcmVjZWl2ZSBhIG11dGxpLXBhcnR5 IElEIFRva2VuLiAmbmJzcDsgV2UgbWF5IGFsc28gYWRkIGN1c3RvbSBjbGFpbXMNCiB0byBmYWNp bGl0YXRlIG1hcHBpbmcgb2YgaWRlbnRpdHkgYWNyb3NzIHRoZSBzZXJ2aWNlcy4gJm5ic3A7IEhh dmluZyBsb2dnZWQgaW50byBTYWxlc2ZvcmNlLCBhbmQgcmVjZWl2ZWQgYW4gSUQgVG9rZW4sIHRo ZSBkZXZlbG9wZXIgd291bGQgdGhlbiBjYWxsIGEgVG9rZW4gRXhjaGFuZ2Ugc2VydmljZSBpbiB0 aGUgc2Vjb25kIHNlY3VyaXR5IGRvbWFpbiBhbmQgZXhjaGFuZ2UgdGhpcyBJRCB0b2tlbiBmb3Ig YSB0b2tlbiBzcGVjaWZpYyB0byB0aGF0IGRvbWFpbi4NCiAmbmJzcDsgVGhpcyBhbGxvd3MgZm9y IHNpbXBsZSBBUEkgZmVkZXJhdGlvbiB1c2UtY2FzZXMgd2l0aG91dCBjb252ZXJnaW5nIGJvdGgg QVBJcyAvIGJhY2tlbmRzIG9uIGEgY29tbW9uIHRva2VuIGZvcm1hdC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlF1ZXN0aW9ucyAvIEZl ZWRiYWNrPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4xKSBJbiB0aGUgc3BlYywgJnF1b3Q7c3ViJnF1b3Q7IGlzIGEgcmVxdWlyZWQgZmll bGQuICZuYnNwOyBIb3dldmVyLCB0aGUgYXBwbGljYXRpb24gbWF5IG5vdCB5ZXQga25vdyB3aG8g dGhlIHN1YmplY3QgaXMgaW4gdGhlIHNlY29uZCBzZWN1cml0eSBkb21haW4gKCBpdCBmaXJzdCBo YXMgdG8gZXhjaGFuZ2UgdGhlIHRva2VuICkgJm5ic3A7DQogJm5ic3A7T25lIG9wdGlvbiBtaWdo dCBiZSB0byBwbGFjZSB0aGUgY2xpZW50X2lkIG9mIHRoZSBhcHBsaWNhdGlvbiBhcyBpc3N1ZWQg YnkgdGhlIHNlY29uZCBzZWN1cml0eSBkb21haW4sIGJ1dCB0aGF0IHNlZW1zIGEgYml0IG9mZi4g Jm5ic3A7IEFueSBhZHZpY2U/ICZuYnNwOyBTaG91bGQgdGhpcyBiZSBhbiBPcHRpb25hbCBmaWVs ZD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjIpIFNwZWFraW5nIG9mIGNsaWVudF9pZHMsIGlmIHdlIGRvbid0IHVzZSB0aGUgJnF1b3Q7 c3ViJnF1b3Q7IHRvIHRyYW5zcG9ydCB0aGVtLCB3ZSBiZWxpZXZlIHRoZSBzZWNvbmQgc2VjdXJp dHkgZG9tYWluIHdvdWxkIHN0aWxsIGFwcHJlY2lhdGUgdGhpcyBjb250ZXh0LiAmbmJzcDsgVGhl IEFjdG9yIGZpZWxkIGlzIGF2YWlsYWJsZSwNCiBidXQgY29uc3RydWN0aW9uIG9mIGEgZnVsbCBK V1QganVzdCB0byB0cmFuc3BvcnQgdGhlIGNsaWVudF9pZCBzZWVtcyBsaWtlIGhpZ2ggb3Zlcmhl YWQsIGFuZCBpdCBtYXkgbm90IGV2ZW4gYmUgYWxpZ25lZCB3aXRoIHRoZSBpbnRlbnQgb2YgdGhh dCBmaWVsZC4gJm5ic3A7ICZuYnNwO1Nob3VsZCBjbGllbnRfaWQgYmUgYSBjbGFpbSBoZXJlPzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ MykgU3BlYWtpbmcgb2YgQWN0b3JzLCBJdCdzIG5vdCBjbGVhciB3aGF0IGFjdHVhbGx5IHN0YXRl cyB0aGF0IHRoZSBqd3QgaW5jbHVkZWQgaW4gdGhlIHRva2VuIGlzIGFjdHVhbGx5IGFuIGFwcHJv dmVkIGFjdG9yLiAmbmJzcDsgJm5ic3A7SXMgaXQgaW50ZW5kZWQgdGhhdCB0aGUgYWN0X2FzIG9y IG9uLWJlaGFsZl9vZiB0b2tlbnMNCiBpbmNsdWRlIGFuIGF6cCBhdXRob3JpemVkIHBhcnR5IGNs YW0gYXMgd2VsbD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjQpICZxdW90O0ltcGxlbWVudGF0aW9ucyBvZiB0aGUgc3BlY2lmaWNhdGlv biBNVVNUIGltcGxlbWVudCBzdXBwb3J0IGZvciB1c2luZyBKV1RzIGFzIHRoZSBTZWN1cml0eSBU b2tlbnMuJm5ic3A7IE90aGVyIFNlY3VyaXR5IFRva2VuIHR5cGVzIE1BWSBiZSBzdXBwb3J0ZWQu JnF1b3Q7ICZuYnNwOyBUaGlzIHNlZW1zIGFudGl0aGV0aWNhbCB0bw0KIHRoZSBwdXJwb3NlIG9m IGFuIFNUUy4gJm5ic3A7IFdlIGJlbGlldmUgdGhpcyBzaG91bGQgYmUgcmVsYXhlZCB0byBhIFNI T1VMRDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+VGhhbmtzIGZvciBhbnkgZmVlZGJhY2sgaGVyZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BLUPR03MB43719509D0527C7D7D5DB82F5990BLUPR03MB437namprd_-- From nobody Wed Jul 15 17:57:41 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7345D1B2BE3 for ; Wed, 15 Jul 2015 17:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-XEpaD2MFOr for ; Wed, 15 Jul 2015 17:57:37 -0700 (PDT) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A77541B2BDD for ; Wed, 15 Jul 2015 17:57:37 -0700 (PDT) Received: by obbop1 with SMTP id op1so37625321obb.2 for ; Wed, 15 Jul 2015 17:57:37 -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:date :message-id:subject:from:to:cc:content-type; bh=TlAHCF3Ows8Df/Bh1tJ8mwiL4JXthgRMQtQg7AY23W4=; b=lOXI68vAu29XU2v5RzYPxbhV4JMVAOzXdJmrxfm1V7PUPXYAAS20aXNvO1OA68qC6A wucyzsnjIpFXmaWHfGgtFJn6ckvgVVXXiCd25S/w4ajr4E1CGOKuKYi35Tfr52DQJNoP 3yzR7h9KpfUlkOZbGMJ1F/3tI/Evp3Fk4XwnnD6y1Yj6L4ZZUoCH0ZgsDPHnXuI64KCH WYTU0AEr4qfkW57+uCRRGYyJXvJPkhOkrvf8q44N3vx5W1KpJhgHlkk3jMr4IMimdc1e +c0SVwzaFGX65hfBV3a5A792nzmZt5QIwxak+/V2k1VynU5cojj0KGdeQNiX5jBV9stL GcoA== X-Gm-Message-State: ALoCoQnfN3JWca/bSRmJN9EqbhrqhE3iX2g6YiWKa3XGf6UPNzxQn3Gx2y++f8xWHrY8uwkfkjjI MIME-Version: 1.0 X-Received: by 10.182.236.7 with SMTP id uq7mr6145710obc.42.1437008257005; Wed, 15 Jul 2015 17:57:37 -0700 (PDT) Received: by 10.76.68.162 with HTTP; Wed, 15 Jul 2015 17:57:36 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Jul 2015 17:57:36 -0700 Message-ID: From: Chuck Mortimore To: Mike Jones Content-Type: multipart/alternative; boundary=001a11c2f912b2e737051af38e7b Archived-At: Cc: OAuth WG Subject: Re: [OAUTH-WG] Use of Token Exchange spec for API Federation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 00:57:40 -0000 --001a11c2f912b2e737051af38e7b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 15, 2015 at 5:14 PM, Mike Jones wrote: > I assume that TokenService1 is an OpenID Connect Provider, since it=E2= =80=99s > issuing both an access token and an ID Token, correct? > Correct. > > > I assume that you want the interaction with TokenService2 to not include > any user interaction =E2=80=93 that that=E2=80=99s where you=E2=80=99re d= oing the Token Exchange =E2=80=93 > correct? > Correct. > > > How did you envision the Client authenticating to TokenService2? Is it a > registered OAuth 2.0 client at TokenService2 using a Client Authenticatio= n > method? Is it signing a request to TokenService2 and TokenService2 > validates and trusts the signature by Client? Is no authentication > performed other than being in possession of the ID Token serving as proof > that the requester has necessary rights to do the token exchange? Or som= e > combination of these=E2=80=A6? > We're thinking it may be a combination, but standard OAuth techniques will likely be the easiest for the third party service to digest. The most basic use-cases would probably just be possession of the ID token. I do like the ACDC addition of the PKCE to the token material to at least bind it to client though. > > > Knowing your use case is really valuable. Thanks for describing it for u= s. > > > > -- Mike > > > > *From:* Chuck Mortimore [mailto:cmortimore@salesforce.com] > *Sent:* Wednesday, July 15, 2015 2:44 PM > *To:* Anthony Nadalin > *Cc:* OAuth WG; Mike Jones > *Subject:* Re: [OAUTH-WG] Use of Token Exchange spec for API Federation > > > > User logs into Client and accesses Resource1 using AccessToken1 from > TokenService1. > > > > Client then contacts TokenService2 and exchanges IDToken1 from > TokenService1 for AccessToken2 from TokenService2. It then uses > AccessToken2 to access Resource2. > > > > -cmort > > > > > > > > On Wed, Jul 15, 2015 at 2:27 PM, Anthony Nadalin > wrote: > > So in your scenario where you have client (c), user (u), resource (r) and > resource 1(r1) does the flow go like U->C->R-R1 or U->C->R and U->C->R1 ? > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Chuck > Mortimore > *Sent:* Wednesday, July 15, 2015 12:47 PM > *To:* OAuth WG ; Mike Jones > *Subject:* [OAUTH-WG] Use of Token Exchange spec for API Federation > > > > We're examining the use of the Token Exchange spec for API federation > use-cases, and are looking for some feedback. > > > > The basic use-case is as follows: Developer wants to build an Applicatio= n > that is a composite of backend services that span multiple security > domains. For example, it's a combination of Salesforce data and their o= wn > backend services. The application is authenticated by Salesforce, and > developer wants to exchange our ID Token for a token in the second securi= ty > domain so that login / credentials are not required for the second back-e= nd > service. > > > > To do this, we're planning to add configuration for multiple audiences in > our service, allowing the developer to receive a mutli-party ID Token. = We > may also add custom claims to facilitate mapping of identity across the > services. Having logged into Salesforce, and received an ID Token, the > developer would then call a Token Exchange service in the second security > domain and exchange this ID token for a token specific to that domain. > This allows for simple API federation use-cases without converging both > APIs / backends on a common token format. > > > > Questions / Feedback > > > > 1) In the spec, "sub" is a required field. However, the application may > not yet know who the subject is in the second security domain ( it first > has to exchange the token ) One option might be to place the client_id > of the application as issued by the second security domain, but that seem= s > a bit off. Any advice? Should this be an Optional field? > > > > 2) Speaking of client_ids, if we don't use the "sub" to transport them, w= e > believe the second security domain would still appreciate this context. > The Actor field is available, but construction of a full JWT just to > transport the client_id seems like high overhead, and it may not even be > aligned with the intent of that field. Should client_id be a claim her= e? > > > > 3) Speaking of Actors, It's not clear what actually states that the jwt > included in the token is actually an approved actor. Is it intended th= at > the act_as or on-behalf_of tokens include an azp authorized party clam as > well? > > > > 4) "Implementations of the specification MUST implement support for using > JWTs as the Security Tokens. Other Security Token types MAY be supported= ." > This seems antithetical to the purpose of an STS. We believe this > should be relaxed to a SHOULD > > > > Thanks for any feedback here > > > > > > > > > > > > > --001a11c2f912b2e737051af38e7b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 15, 2015 at 5:14 PM, Mike Jones <Michael.Jones@microsoft= .com> wrote:

I assume that TokenServic= e1 is an OpenID Connect Provider, since it=E2=80=99s issuing both an access= token and an ID Token, correct?

Correct.
=C2=A0
=

=C2=A0

I assume that you want th= e interaction with TokenService2 to not include any user interaction =E2=80= =93 that that=E2=80=99s where you=E2=80=99re doing the Token Exchange =E2= =80=93 correct?


Corr= ect.
=C2=A0

=C2=A0

How did you envision the = Client authenticating to TokenService2?=C2=A0 Is it a registered OAuth 2.0 = client at TokenService2 using a Client Authentication method?=C2=A0 Is it signing a request to TokenService2 and TokenService2 validates and t= rusts the signature by Client?=C2=A0 Is no authentication performed other t= han being in possession of the ID Token serving as proof that the requester= has necessary rights to do the token exchange?=C2=A0 Or some combination of these=E2=80=A6?


We're thinking it may be a combinat= ion, but standard OAuth techniques will likely be the easiest for the third= party service to digest. =C2=A0 =C2=A0The most basic use-cases would proba= bly just be possession of the ID token. =C2=A0 I do like the ACDC addition = of the PKCE to the token material to at least bind it to client though.

=C2=A0

=C2=A0

Knowing your use case is = really valuable.=C2=A0 Thanks for describing it for us.

=C2=A0

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

=C2=A0

From: Chuck Mo= rtimore [mailto:cmortimore@salesforce.com]
Sent: Wednesday, July 15, 2015 2:44 PM
To: Anthony Nadalin
Cc: OAuth WG; Mike Jones
Subject: Re: [OAUTH-WG] Use of Token Exchange spec for API Federatio= n

=C2=A0

User logs into Client and accesses Resource1 using A= ccessToken1 from TokenService1. =C2=A0=C2=A0

=C2=A0

Client then contacts TokenService2 and exchanges IDT= oken1 from TokenService1 for AccessToken2 from TokenService2. =C2=A0 It the= n uses AccessToken2 to access Resource2.

=C2=A0

-cmort

=C2=A0

=C2=A0

=C2=A0

On Wed, Jul 15, 2015 at 2:27 PM, Anthony Nadalin <= ;tonynad@microso= ft.com> wrote:

So in your scenario where= you have client (c), user (u), resource (r) and resource 1(r1) does the flow go like U->C->R-R1 or U->C->R and U->C->R1 ?=

=C2=A0

From: OAuth = [mailto:oauth-b= ounces@ietf.org] On Behalf Of Chuck Mortimore
Sent: Wednesday, July 15, 2015 12:47 PM
To: OAuth WG <oauth@ietf.org>; Mike Jones <Michael.Jones@microsoft.com>
Subject: [OAUTH-WG] Use of Token Exchange spec for API Federation

=C2=A0

We're examining the use of the Token Exchange sp= ec for API federation use-cases, and are looking for some feedback.<= u>

=C2=A0

The basic use-case is as follows: =C2=A0Developer wa= nts to build an Application that is a composite of backend services that sp= an multiple security domains. =C2=A0 For example, it's a combination of Salesforce data and their own backend services. =C2=A0 =C2=A0 The appli= cation is authenticated by Salesforce, and developer wants to exchange our = ID Token for a token in the second security domain so that login / credenti= als are not required for the second back-end service. =C2=A0=C2=A0

=C2=A0

To do this, we're planning to add configuration = for multiple audiences in our service, allowing the developer to receive a = mutli-party ID Token. =C2=A0 We may also add custom claims to facilitate mapping of identity across the services. =C2=A0 Having logge= d into Salesforce, and received an ID Token, the developer would then call = a Token Exchange service in the second security domain and exchange this ID= token for a token specific to that domain. =C2=A0 This allows for simple API federation use-cases without converging = both APIs / backends on a common token format.

=C2=A0

Questions / Feedback

=C2=A0

1) In the spec, "sub" is a required field.= =C2=A0 However, the application may not yet know who the subject is in the= second security domain ( it first has to exchange the token ) =C2=A0 =C2=A0One option might be to place the client_id of the application as iss= ued by the second security domain, but that seems a bit off. =C2=A0 Any adv= ice? =C2=A0 Should this be an Optional field?

=C2=A0

2) Speaking of client_ids, if we don't use the &= quot;sub" to transport them, we believe the second security domain wou= ld still appreciate this context. =C2=A0 The Actor field is available, but construction of a full JWT just to transport the client_id seems like = high overhead, and it may not even be aligned with the intent of that field= . =C2=A0 =C2=A0Should client_id be a claim here?

=C2=A0

3) Speaking of Actors, It's not clear what actua= lly states that the jwt included in the token is actually an approved actor= . =C2=A0 =C2=A0Is it intended that the act_as or on-behalf_of tokens include an azp authorized party clam as well?

=C2=A0

4) "Implementations of the specification MUST i= mplement support for using JWTs as the Security Tokens.=C2=A0 Other Securit= y Token types MAY be supported." =C2=A0 This seems antithetical to the purpose of an STS. =C2=A0 We believe this should be relaxed to a SHOUL= D

=C2=A0

Thanks for any feedback here

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0


--001a11c2f912b2e737051af38e7b-- From nobody Wed Jul 15 18:39:25 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956701B2CCE for ; Wed, 15 Jul 2015 18:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.944 X-Spam-Level: X-Spam-Status: No, score=-0.944 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CEzMeWgJE0YM for ; Wed, 15 Jul 2015 18:39:05 -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 C2A381B2CEF for ; Wed, 15 Jul 2015 18:39:05 -0700 (PDT) Received: from pps.filterd (m0074413.ppops.net [127.0.0.1]) by mx0a-0019e102.pphosted.com (8.15.0.59/8.14.7) with SMTP id t6G1ZkUl013056 for ; Wed, 15 Jul 2015 20:39:04 -0500 Received: from mail-yk0-f181.google.com (mail-yk0-f181.google.com [209.85.160.181]) by mx0a-0019e102.pphosted.com with ESMTP id 1vp0fng6pe-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 15 Jul 2015 20:39:04 -0500 Received: by ykeo3 with SMTP id o3so52333494yke.0 for ; Wed, 15 Jul 2015 18:39:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=UGpBkOljwA/LooBudfzfzH0s+3M0SwQX+OwQ7pJYxQ0=; b=Eci7wHDiZXN5e8eOPZeaRdC2zQqkxJNW15e4Zy4fqd1+71gxTObBes/1OVslyzR5ab eio96FuvHR2IdvCZyXcK/LfSE2eD71E+ZGdVJp4fKGRtanj1sJUonmSpfxEywWI4Xd1m LEv+uUAozj5979oKngJMNsoZds1S6d3VXdRvVX2C23EvAxk44KTJZ23Uhm7kWrTogm6N 1ewIxRCBcKj8TulIIBRBQAyxg2JNU39M7N5UNUfO9q15q0GmAr4aehfpQ9TV4vE+2QKa P374uLrtlNssg3cEbTt8sgPnAbZaXfXtzgpNYJ4YWbaDKTcr0lr7J2FL3jns1A5mb0a2 ZDHQ== X-Gm-Message-State: ALoCoQms/Qh6JAo6lDgpeRg09ySfx0vdAWDMX+jGmxZSfGLf+i74JveJzrtlfzUN4ipdlPmUon5A+H/zT3Pb0Vl7F1LtBON9yPcI3fdNlCnpgvwpcgWXYLIoXwVtoxH86GF/+XX6Wafi X-Received: by 10.170.144.66 with SMTP id l63mr7376786ykc.122.1437010743200; Wed, 15 Jul 2015 18:39:03 -0700 (PDT) X-Received: by 10.170.144.66 with SMTP id l63mr7376780ykc.122.1437010743057; Wed, 15 Jul 2015 18:39:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.214.194 with HTTP; Wed, 15 Jul 2015 18:38:43 -0700 (PDT) In-Reply-To: References: From: Adam Lewis Date: Wed, 15 Jul 2015 20:38:43 -0500 Message-ID: To: Chuck Mortimore Content-Type: multipart/alternative; boundary=001a11396512e1104d051af422af X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=1 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1507160011 Archived-At: Cc: OAuth WG Subject: Re: [OAUTH-WG] Use of Token Exchange spec for API Federation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 01:39:08 -0000 --001a11396512e1104d051af422af Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Chuck, ACDC + PKCE is what we want to do as well. It is a perfect fit for first responders accessing APIs in foreign security domains. The custom tabs / safari view controller provides an extremely elegant means to do SSO across both native & web, utilizing session cookies in the browser. But ACDC is a bit more elegant from a UX vantage since it is all back-channel. Of course where user input it required than the custom tabs / view controller might be better since the user can hit the authorization endpoint and interact with the AS. This assuming that IdP discovery is seamless, and doesn't result in the user being confused by a NASCAR or dropdown list or other kludgy UI on the HTML returned from the foreign AS to the mobile's browser. I think that ACDC will be a better fit for enterprise scenarios where the RO is the enterprise (not the end user) vs. doing OIDC to the foreign AS authorization endpoint. My 2 cents. adam On Wed, Jul 15, 2015 at 7:57 PM, Chuck Mortimore wrote: > On Wed, Jul 15, 2015 at 5:14 PM, Mike Jones > wrote: > >> I assume that TokenService1 is an OpenID Connect Provider, since it=E2= =80=99s >> issuing both an access token and an ID Token, correct? >> > > Correct. > > >> >> >> I assume that you want the interaction with TokenService2 to not include >> any user interaction =E2=80=93 that that=E2=80=99s where you=E2=80=99re = doing the Token Exchange =E2=80=93 >> correct? >> > > Correct. > > >> >> >> How did you envision the Client authenticating to TokenService2? Is it = a >> registered OAuth 2.0 client at TokenService2 using a Client Authenticati= on >> method? Is it signing a request to TokenService2 and TokenService2 >> validates and trusts the signature by Client? Is no authentication >> performed other than being in possession of the ID Token serving as proo= f >> that the requester has necessary rights to do the token exchange? Or so= me >> combination of these=E2=80=A6? >> > > We're thinking it may be a combination, but standard OAuth techniques wil= l > likely be the easiest for the third party service to digest. The most > basic use-cases would probably just be possession of the ID token. I do > like the ACDC addition of the PKCE to the token material to at least bind > it to client though. > > > >> >> >> Knowing your use case is really valuable. Thanks for describing it for >> us. >> >> >> >> -- Mike >> >> >> >> *From:* Chuck Mortimore [mailto:cmortimore@salesforce.com] >> *Sent:* Wednesday, July 15, 2015 2:44 PM >> *To:* Anthony Nadalin >> *Cc:* OAuth WG; Mike Jones >> *Subject:* Re: [OAUTH-WG] Use of Token Exchange spec for API Federation >> >> >> >> User logs into Client and accesses Resource1 using AccessToken1 from >> TokenService1. >> >> >> >> Client then contacts TokenService2 and exchanges IDToken1 from >> TokenService1 for AccessToken2 from TokenService2. It then uses >> AccessToken2 to access Resource2. >> >> >> >> -cmort >> >> >> >> >> >> >> >> On Wed, Jul 15, 2015 at 2:27 PM, Anthony Nadalin >> wrote: >> >> So in your scenario where you have client (c), user (u), resource (r) an= d >> resource 1(r1) does the flow go like U->C->R-R1 or U->C->R and U->C->R1 = ? >> >> >> >> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Chuck >> Mortimore >> *Sent:* Wednesday, July 15, 2015 12:47 PM >> *To:* OAuth WG ; Mike Jones >> *Subject:* [OAUTH-WG] Use of Token Exchange spec for API Federation >> >> >> >> We're examining the use of the Token Exchange spec for API federation >> use-cases, and are looking for some feedback. >> >> >> >> The basic use-case is as follows: Developer wants to build an >> Application that is a composite of backend services that span multiple >> security domains. For example, it's a combination of Salesforce data a= nd >> their own backend services. The application is authenticated by >> Salesforce, and developer wants to exchange our ID Token for a token in = the >> second security domain so that login / credentials are not required for = the >> second back-end service. >> >> >> >> To do this, we're planning to add configuration for multiple audiences i= n >> our service, allowing the developer to receive a mutli-party ID Token. = We >> may also add custom claims to facilitate mapping of identity across the >> services. Having logged into Salesforce, and received an ID Token, the >> developer would then call a Token Exchange service in the second securit= y >> domain and exchange this ID token for a token specific to that domain. >> This allows for simple API federation use-cases without converging both >> APIs / backends on a common token format. >> >> >> >> Questions / Feedback >> >> >> >> 1) In the spec, "sub" is a required field. However, the application ma= y >> not yet know who the subject is in the second security domain ( it first >> has to exchange the token ) One option might be to place the client_i= d >> of the application as issued by the second security domain, but that see= ms >> a bit off. Any advice? Should this be an Optional field? >> >> >> >> 2) Speaking of client_ids, if we don't use the "sub" to transport them, >> we believe the second security domain would still appreciate this contex= t. >> The Actor field is available, but construction of a full JWT just to >> transport the client_id seems like high overhead, and it may not even be >> aligned with the intent of that field. Should client_id be a claim he= re? >> >> >> >> 3) Speaking of Actors, It's not clear what actually states that the jwt >> included in the token is actually an approved actor. Is it intended t= hat >> the act_as or on-behalf_of tokens include an azp authorized party clam a= s >> well? >> >> >> >> 4) "Implementations of the specification MUST implement support for usin= g >> JWTs as the Security Tokens. Other Security Token types MAY be supporte= d." >> This seems antithetical to the purpose of an STS. We believe this >> should be relaxed to a SHOULD >> >> >> >> Thanks for any feedback here >> >> >> >> >> >> >> >> >> >> >> >> >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a11396512e1104d051af422af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Chuck,

ACDC + PKCE is what we want t= o do as well.=C2=A0 It is a perfect fit for first responders accessing APIs= in foreign security domains. =C2=A0

The custom tabs / s= afari view controller provides an extremely elegant means to do SSO across = both native & web, utilizing session cookies in the browser. =C2=A0

But ACDC is a bit more elegant from a UX vantage sinc= e it is all back-channel. =C2=A0

Of course where u= ser input it required than the custom tabs / view controller might be bette= r since the user can hit the authorization endpoint and interact with the A= S.=C2=A0 This assuming that IdP discovery is seamless, and doesn't resu= lt in the user being confused by a NASCAR or dropdown list or other kludgy = UI on the HTML returned from the foreign AS to the mobile's browser.

I think that ACDC will be a better fit for enterpris= e scenarios where the RO is the enterprise (not the end user) vs. doing OID= C to the foreign AS authorization endpoint.

My 2 c= ents.
adam

On Wed, Jul 15, 2015 at 7:57 PM, Chuck Mortimore <cmortimore@salesforce.com> wrote:
On Wed, Jul 15, 2015 at 5:14 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I assume that TokenServic= e1 is an OpenID Connect Provider, since it=E2=80=99s issuing both an access= token and an ID Token, correct?

Correct.
=C2=A0
=

=C2=A0

I assume that you want th= e interaction with TokenService2 to not include any user interaction =E2=80= =93 that that=E2=80=99s where you=E2=80=99re doing the Token Exchange =E2= =80=93 correct?


Correct.
=C2=A0

=C2=A0

How did you envision the = Client authenticating to TokenService2?=C2=A0 Is it a registered OAuth 2.0 = client at TokenService2 using a Client Authentication method?=C2=A0 Is it signing a request to TokenService2 and TokenService2 validates and t= rusts the signature by Client?=C2=A0 Is no authentication performed other t= han being in possession of the ID Token serving as proof that the requester= has necessary rights to do the token exchange?=C2=A0 Or some combination of these=E2=80=A6?


We're thinking it may be a c= ombination, but standard OAuth techniques will likely be the easiest for th= e third party service to digest. =C2=A0 =C2=A0The most basic use-cases woul= d probably just be possession of the ID token. =C2=A0 I do like the ACDC ad= dition of the PKCE to the token material to at least bind it to client thou= gh.

=C2=A0

=C2=A0

Knowing your use case is = really valuable.=C2=A0 Thanks for describing it for us.

=C2=A0

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

=C2=A0

From: Chuck Mo= rtimore [mailto:cmortimore@salesforce.com]
Sent: Wednesday, July 15, 2015 2:44 PM
To: Anthony Nadalin
Cc: OAuth WG; Mike Jones
Subject: Re: [OAUTH-WG] Use of Token Exchange spec for API Federatio= n

=C2=A0

User logs into Client and accesses Resource1 using A= ccessToken1 from TokenService1. =C2=A0=C2=A0

=C2=A0

Client then contacts TokenService2 and exchanges IDT= oken1 from TokenService1 for AccessToken2 from TokenService2. =C2=A0 It the= n uses AccessToken2 to access Resource2.

=C2=A0

-cmort

=C2=A0

=C2=A0

=C2=A0

On Wed, Jul 15, 2015 at 2:27 PM, Anthony Nadalin <= ;tonynad@microso= ft.com> wrote:

So in your scenario where= you have client (c), user (u), resource (r) and resource 1(r1) does the flow go like U->C->R-R1 or U->C->R and U->C->R1 ?=

=C2=A0<= /u>

From: OAuth = [mailto:oauth-b= ounces@ietf.org] On Behalf Of Chuck Mortimore
Sent: Wednesday, July 15, 2015 12:47 PM
To: OAuth WG <oauth@ietf.org>; Mike Jones <Michael.Jones@microsoft.com>
Subject: [OAUTH-WG] Use of Token Exchange spec for API Federation

=C2=A0

We're examining the use of the Token Exchange sp= ec for API federation use-cases, and are looking for some feedback.<= u>

=C2=A0

The basic use-case is as follows: =C2=A0Developer wa= nts to build an Application that is a composite of backend services that sp= an multiple security domains. =C2=A0 For example, it's a combination of Salesforce data and their own backend services. =C2=A0 =C2=A0 The appli= cation is authenticated by Salesforce, and developer wants to exchange our = ID Token for a token in the second security domain so that login / credenti= als are not required for the second back-end service. =C2=A0=C2=A0

=C2=A0

To do this, we're planning to add configuration = for multiple audiences in our service, allowing the developer to receive a = mutli-party ID Token. =C2=A0 We may also add custom claims to facilitate mapping of identity across the services. =C2=A0 Having logge= d into Salesforce, and received an ID Token, the developer would then call = a Token Exchange service in the second security domain and exchange this ID= token for a token specific to that domain. =C2=A0 This allows for simple API federation use-cases without converging = both APIs / backends on a common token format.

=C2=A0

Questions / Feedback

=C2=A0

1) In the spec, "sub" is a required field.= =C2=A0 However, the application may not yet know who the subject is in the= second security domain ( it first has to exchange the token ) =C2=A0 =C2=A0One option might be to place the client_id of the application as iss= ued by the second security domain, but that seems a bit off. =C2=A0 Any adv= ice? =C2=A0 Should this be an Optional field?

=C2=A0

2) Speaking of client_ids, if we don't use the &= quot;sub" to transport them, we believe the second security domain wou= ld still appreciate this context. =C2=A0 The Actor field is available, but construction of a full JWT just to transport the client_id seems like = high overhead, and it may not even be aligned with the intent of that field= . =C2=A0 =C2=A0Should client_id be a claim here?

=C2=A0

3) Speaking of Actors, It's not clear what actua= lly states that the jwt included in the token is actually an approved actor= . =C2=A0 =C2=A0Is it intended that the act_as or on-behalf_of tokens include an azp authorized party clam as well?

=C2=A0

4) "Implementations of the specification MUST i= mplement support for using JWTs as the Security Tokens.=C2=A0 Other Securit= y Token types MAY be supported." =C2=A0 This seems antithetical to the purpose of an STS. =C2=A0 We believe this should be relaxed to a SHOUL= D

=C2=A0

Thanks for any feedback here

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0



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


--001a11396512e1104d051af422af-- From swathivk@gmail.com Wed Jul 15 04:36:12 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0C91A894F for ; Wed, 15 Jul 2015 04:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uk6xD5M6QMLN for ; Wed, 15 Jul 2015 04:36:11 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450: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 DD41C1A8938 for ; Wed, 15 Jul 2015 04:36:10 -0700 (PDT) Received: by wicmv11 with SMTP id mv11so38172078wic.1 for ; Wed, 15 Jul 2015 04:36:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=M2pvHoT1LZVyuB9U4G3gKhlkiEo9i9K6006fwZ0j7y8=; b=CfaP2Hkx/O7fVf/XaNOmCqt9msun+CLIBcHwK/dmHiGRiW8aTODg5yOoLpRr3vLKAs YMeWESr0HEV0vbDPr3J+z4WV2mDdJxtmws3i2yobKwslq3cFmskDA9suK3IF6D+9253b nJhRNRxaQqgBpecXX1PJSbYjumQkYyoZvlOGUSRLxfxM/mudopvDXCOIMt43KPY1Vc/4 OooOvRBMF5bEH9ttwznZFfsBFl4fah+HXG3rYs8au8VxmAjkYHyYP+r3/2e1/Y+dRnQc oHdmeOF53KL2w6RV8Z0KQhWwlosyWMCPulbW6dp5iP7qXEZaDalA/eWVQ0PTpRiNIsc/ 3+Lw== MIME-Version: 1.0 X-Received: by 10.180.72.35 with SMTP id a3mr41285709wiv.21.1436960169647; Wed, 15 Jul 2015 04:36:09 -0700 (PDT) Received: by 10.27.204.138 with HTTP; Wed, 15 Jul 2015 04:36:09 -0700 (PDT) Date: Wed, 15 Jul 2015 17:06:09 +0530 Message-ID: From: swathi vangala To: oauth@ietf.org Content-Type: multipart/alternative; boundary=001a11c2403e77e5be051ae85caa Archived-At: X-Mailman-Approved-At: Thu, 16 Jul 2015 08:13:27 -0700 Subject: [OAUTH-WG] Oauth 2.0 Installation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 11:41:56 -0000 --001a11c2403e77e5be051ae85caa Content-Type: text/plain; charset=UTF-8 Respected Sir/Madam, I am Swathi, trying to work on a project to connect with online e portals through a PHP application. I am trying to see Oauth 2.0 pitch in my use case as I need to connect to multiple portals from my web application. In this regard could you please guide me on how to install 2.0 in php with windows environment as a development to start with. I see that http://oauth.net/2/ website has the client libraries but if I click on the PHP link, I see some repositories but there is no clear installation procedure on how to utilize them. If a step by step procedure to do the setup and implementation of auth2 with PHP will be available it would be nothing like it for a beginner. -- Thanks in Advance Swathi --001a11c2403e77e5be051ae85caa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Respected Sir/Madam,

I am Swathi, tryin= g to work on a project to connect with online e portals through a PHP appli= cation. I am trying to see Oauth 2.0 pitch in my use case as I need to conn= ect to multiple portals from my web application.

I= n this regard could you please guide me on how to install 2.0 in php with w= indows environment as a development to start with.

I see that=C2=A0http://oauth.net/2/ we= bsite has the client libraries but if I click on the PHP link, I see some r= epositories but there is no clear installation procedure on how to utilize = them.

If a step by step procedure to do the setup = and implementation of auth2 with PHP will be available it would be nothing = like it for a beginner.

--=C2=A0
= Thanks in Advance
Swathi
--001a11c2403e77e5be051ae85caa-- From nobody Thu Jul 16 14:33:57 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1371A016A for ; Thu, 16 Jul 2015 14:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.643 X-Spam-Level: X-Spam-Status: No, score=-1.643 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQuqwZLEM0Uf for ; Thu, 16 Jul 2015 14:33:53 -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 2FCB51A1A6C for ; Thu, 16 Jul 2015 14:33:38 -0700 (PDT) Received: from pps.filterd (m0074416.ppops.net [127.0.0.1]) by mx0b-0019e102.pphosted.com (8.15.0.59/8.14.7) with SMTP id t6GLUGP9021345 for ; Thu, 16 Jul 2015 16:33:37 -0500 Received: from mail-yk0-f172.google.com (mail-yk0-f172.google.com [209.85.160.172]) by mx0b-0019e102.pphosted.com with ESMTP id 1vpm2p028h-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 16 Jul 2015 16:33:36 -0500 Received: by ykay190 with SMTP id y190so75189862yka.3 for ; Thu, 16 Jul 2015 14:33:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=cTMOotIwsthgCe7D8+AhIKKwtgs9cxDOsQtn+15MTxo=; b=WE5ypxfB74fjiqYffY8BcgjTvp7EZkkgZHvmujlBWfy3ItyJm4CxgTHy3+ZSODcilK jrvD068+KczsG1Xel5+WafZGz6L0DJttiwCBlm6GB2nzZE7u64dliTg6wgCxAPEYxS8d sdMc1WdDSymDd9BXWAoun3GDpM6lTXToA2Ll4KsroqZRnHB3Bdb0HkQvZqhy4yaB0sde S1bcY/2FQ+594N5+L+asdfObMx0alMlRcg1b6C7mcAYkHXA2cYH77NBudrabwODywXk+ WrIHhNcreg0wtmdpuSgEND24C6YDR3M7Qmuihtfx1QPEh5uu+ia2/Mm53zNOAUG6FaLI 3ifQ== X-Gm-Message-State: ALoCoQnT3j+EpYrD41Wbl+UAwFK5x1xXJI01ET6cziOYBM+qfAfWhL+oK3sbhtvkaxIqjKGNW3LOoEagxr+/PVGECjWWjDCtq5G5VIMMRdD0DjlKDWsQWBPs5c4Bk1FfUrdVwuykMqtn X-Received: by 10.170.155.133 with SMTP id w127mr5453091ykc.44.1437082416610; Thu, 16 Jul 2015 14:33:36 -0700 (PDT) X-Received: by 10.170.155.133 with SMTP id w127mr5453079ykc.44.1437082416472; Thu, 16 Jul 2015 14:33:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.214.194 with HTTP; Thu, 16 Jul 2015 14:33:17 -0700 (PDT) In-Reply-To: References: From: Adam Lewis Date: Thu, 16 Jul 2015 16:33:17 -0500 Message-ID: To: Chuck Mortimore Content-Type: multipart/alternative; boundary=001a1139e540f29b38051b04d2ab X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=1 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1507160327 Archived-At: Cc: OAuth WG Subject: Re: [OAUTH-WG] Use of Token Exchange spec for API Federation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 21:33:56 -0000 --001a1139e540f29b38051b04d2ab Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable btw can any of the Microsoft folks on the list give any indication if IE has plans to do something similar to custom tabs / safari view controller for windows devices? Maybe it's not something you can comment on, but at least let it be know the interest is out here :-) On Wed, Jul 15, 2015 at 8:38 PM, Adam Lewis < adam.lewis@motorolasolutions.com> wrote: > Hi Chuck, > > ACDC + PKCE is what we want to do as well. It is a perfect fit for first > responders accessing APIs in foreign security domains. > > The custom tabs / safari view controller provides an extremely elegant > means to do SSO across both native & web, utilizing session cookies in th= e > browser. > > But ACDC is a bit more elegant from a UX vantage since it is all > back-channel. > > Of course where user input it required than the custom tabs / view > controller might be better since the user can hit the authorization > endpoint and interact with the AS. This assuming that IdP discovery is > seamless, and doesn't result in the user being confused by a NASCAR or > dropdown list or other kludgy UI on the HTML returned from the foreign AS > to the mobile's browser. > > I think that ACDC will be a better fit for enterprise scenarios where the > RO is the enterprise (not the end user) vs. doing OIDC to the foreign AS > authorization endpoint. > > My 2 cents. > adam > > On Wed, Jul 15, 2015 at 7:57 PM, Chuck Mortimore < > cmortimore@salesforce.com> wrote: > >> On Wed, Jul 15, 2015 at 5:14 PM, Mike Jones >> wrote: >> >>> I assume that TokenService1 is an OpenID Connect Provider, since it=E2= =80=99s >>> issuing both an access token and an ID Token, correct? >>> >> >> Correct. >> >> >>> >>> >>> I assume that you want the interaction with TokenService2 to not includ= e >>> any user interaction =E2=80=93 that that=E2=80=99s where you=E2=80=99re= doing the Token Exchange =E2=80=93 >>> correct? >>> >> >> Correct. >> >> >>> >>> >>> How did you envision the Client authenticating to TokenService2? Is it >>> a registered OAuth 2.0 client at TokenService2 using a Client >>> Authentication method? Is it signing a request to TokenService2 and >>> TokenService2 validates and trusts the signature by Client? Is no >>> authentication performed other than being in possession of the ID Token >>> serving as proof that the requester has necessary rights to do the toke= n >>> exchange? Or some combination of these=E2=80=A6? >>> >> >> We're thinking it may be a combination, but standard OAuth techniques >> will likely be the easiest for the third party service to digest. The >> most basic use-cases would probably just be possession of the ID token. = I >> do like the ACDC addition of the PKCE to the token material to at least >> bind it to client though. >> >> >> >>> >>> >>> Knowing your use case is really valuable. Thanks for describing it for >>> us. >>> >>> >>> >>> -- Mike >>> >>> >>> >>> *From:* Chuck Mortimore [mailto:cmortimore@salesforce.com] >>> *Sent:* Wednesday, July 15, 2015 2:44 PM >>> *To:* Anthony Nadalin >>> *Cc:* OAuth WG; Mike Jones >>> *Subject:* Re: [OAUTH-WG] Use of Token Exchange spec for API Federation >>> >>> >>> >>> User logs into Client and accesses Resource1 using AccessToken1 from >>> TokenService1. >>> >>> >>> >>> Client then contacts TokenService2 and exchanges IDToken1 from >>> TokenService1 for AccessToken2 from TokenService2. It then uses >>> AccessToken2 to access Resource2. >>> >>> >>> >>> -cmort >>> >>> >>> >>> >>> >>> >>> >>> On Wed, Jul 15, 2015 at 2:27 PM, Anthony Nadalin >>> wrote: >>> >>> So in your scenario where you have client (c), user (u), resource (r) >>> and resource 1(r1) does the flow go like U->C->R-R1 or U->C->R and U->C= ->R1 >>> ? >>> >>> >>> >>> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Chuck >>> Mortimore >>> *Sent:* Wednesday, July 15, 2015 12:47 PM >>> *To:* OAuth WG ; Mike Jones >> > >>> *Subject:* [OAUTH-WG] Use of Token Exchange spec for API Federation >>> >>> >>> >>> We're examining the use of the Token Exchange spec for API federation >>> use-cases, and are looking for some feedback. >>> >>> >>> >>> The basic use-case is as follows: Developer wants to build an >>> Application that is a composite of backend services that span multiple >>> security domains. For example, it's a combination of Salesforce data = and >>> their own backend services. The application is authenticated by >>> Salesforce, and developer wants to exchange our ID Token for a token in= the >>> second security domain so that login / credentials are not required for= the >>> second back-end service. >>> >>> >>> >>> To do this, we're planning to add configuration for multiple audiences >>> in our service, allowing the developer to receive a mutli-party ID Toke= n. >>> We may also add custom claims to facilitate mapping of identity across = the >>> services. Having logged into Salesforce, and received an ID Token, th= e >>> developer would then call a Token Exchange service in the second securi= ty >>> domain and exchange this ID token for a token specific to that domain. >>> This allows for simple API federation use-cases without converging both >>> APIs / backends on a common token format. >>> >>> >>> >>> Questions / Feedback >>> >>> >>> >>> 1) In the spec, "sub" is a required field. However, the application >>> may not yet know who the subject is in the second security domain ( it >>> first has to exchange the token ) One option might be to place the >>> client_id of the application as issued by the second security domain, b= ut >>> that seems a bit off. Any advice? Should this be an Optional field? >>> >>> >>> >>> 2) Speaking of client_ids, if we don't use the "sub" to transport them, >>> we believe the second security domain would still appreciate this conte= xt. >>> The Actor field is available, but construction of a full JWT just to >>> transport the client_id seems like high overhead, and it may not even b= e >>> aligned with the intent of that field. Should client_id be a claim h= ere? >>> >>> >>> >>> 3) Speaking of Actors, It's not clear what actually states that the jwt >>> included in the token is actually an approved actor. Is it intended = that >>> the act_as or on-behalf_of tokens include an azp authorized party clam = as >>> well? >>> >>> >>> >>> 4) "Implementations of the specification MUST implement support for >>> using JWTs as the Security Tokens. Other Security Token types MAY be >>> supported." This seems antithetical to the purpose of an STS. We >>> believe this should be relaxed to a SHOULD >>> >>> >>> >>> Thanks for any feedback here >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > --001a1139e540f29b38051b04d2ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
btw can any of the Microsoft folks on the list give any in= dication if IE has plans to do something similar to custom tabs / safari vi= ew controller for windows devices?=C2=A0 Maybe it's not something you c= an comment on, but at least let it be know the interest is out here :-)

On Wed, Jul 15,= 2015 at 8:38 PM, Adam Lewis <adam.lewis@motorolasolutions.= com> wrote:
Hi Chuck,

ACDC + PKCE is what we want to do as well.= =C2=A0 It is a perfect fit for first responders accessing APIs in foreign s= ecurity domains. =C2=A0

The custom tabs / safari view co= ntroller provides an extremely elegant means to do SSO across both native &= amp; web, utilizing session cookies in the browser. =C2=A0

But ACDC is a bit more elegant from a UX vantage since it is all b= ack-channel. =C2=A0

Of course where user input it = required than the custom tabs / view controller might be better since the u= ser can hit the authorization endpoint and interact with the AS.=C2=A0 This= assuming that IdP discovery is seamless, and doesn't result in the use= r being confused by a NASCAR or dropdown list or other kludgy UI on the HTM= L returned from the foreign AS to the mobile's browser.

<= /div>
I think that ACDC will be a better fit for enterprise scenarios w= here the RO is the enterprise (not the end user) vs. doing OIDC to the fore= ign AS authorization endpoint.

My 2 cents.
adam
<= /div>

<= div class=3D"h5">On Wed, Jul 15, 2015 at 7:57 PM, Chuck Mortimore <cmortimore@salesforce.com> wrote:
On Wed, Jul 15, 2015 at 5:14 P= M, Mike Jones <Michael.Jones@microsoft.com> wrote:=

I assume that TokenServic= e1 is an OpenID Connect Provider, since it=E2=80=99s issuing both an access= token and an ID Token, correct?

Correct.
=C2=A0

=C2=A0

I assume that you want th= e interaction with TokenService2 to not include any user interaction =E2=80= =93 that that=E2=80=99s where you=E2=80=99re doing the Token Exchange =E2= =80=93 correct?


Correct.
=C2=A0

=

=C2=A0

How did you envision the = Client authenticating to TokenService2?=C2=A0 Is it a registered OAuth 2.0 = client at TokenService2 using a Client Authentication method?=C2=A0 Is it signing a request to TokenService2 and TokenService2 validates and t= rusts the signature by Client?=C2=A0 Is no authentication performed other t= han being in possession of the ID Token serving as proof that the requester= has necessary rights to do the token exchange?=C2=A0 Or some combination of these=E2=80=A6?


We're thinking it may be a c= ombination, but standard OAuth techniques will likely be the easiest for th= e third party service to digest. =C2=A0 =C2=A0The most basic use-cases woul= d probably just be possession of the ID token. =C2=A0 I do like the ACDC ad= dition of the PKCE to the token material to at least bind it to client thou= gh.

=C2=A0

=C2=A0

Knowing your use case is = really valuable.=C2=A0 Thanks for describing it for us.

=C2=A0

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

=C2=A0

From: Chuck Mo= rtimore [mailto:cmortimore@salesforce.com]
Sent: Wednesday, July 15, 2015 2:44 PM
To: Anthony Nadalin
Cc: OAuth WG; Mike Jones
Subject: Re: [OAUTH-WG] Use of Token Exchange spec for API Federatio= n

=C2=A0

User logs into Client and accesses Resource1 using A= ccessToken1 from TokenService1. =C2=A0=C2=A0

=C2=A0

Client then contacts TokenService2 and exchanges IDT= oken1 from TokenService1 for AccessToken2 from TokenService2. =C2=A0 It the= n uses AccessToken2 to access Resource2.

=C2=A0

-cmort

=C2=A0

=C2=A0

=C2=A0

On Wed, Jul 15, 2015 at 2:27 PM, Anthony Nadalin <= ;tonynad@microso= ft.com> wrote:

So in your scenario where= you have client (c), user (u), resource (r) and resource 1(r1) does the flow go like U->C->R-R1 or U->C->R and U->C->R1 ?=

=C2= =A0

From: OAuth = [mailto:oauth-b= ounces@ietf.org] On Behalf Of Chuck Mortimore
Sent: Wednesday, July 15, 2015 12:47 PM
To: OAuth WG <oauth@ietf.org>; Mike Jones <Michael.Jones@microsoft.com>
Subject: [OAUTH-WG] Use of Token Exchange spec for API Federation

=C2=A0

We're examining the use of the Token Exchange sp= ec for API federation use-cases, and are looking for some feedback.<= u>

=C2=A0

The basic use-case is as follows: =C2=A0Developer wa= nts to build an Application that is a composite of backend services that sp= an multiple security domains. =C2=A0 For example, it's a combination of Salesforce data and their own backend services. =C2=A0 =C2=A0 The appli= cation is authenticated by Salesforce, and developer wants to exchange our = ID Token for a token in the second security domain so that login / credenti= als are not required for the second back-end service. =C2=A0=C2=A0

=C2=A0

To do this, we're planning to add configuration = for multiple audiences in our service, allowing the developer to receive a = mutli-party ID Token. =C2=A0 We may also add custom claims to facilitate mapping of identity across the services. =C2=A0 Having logge= d into Salesforce, and received an ID Token, the developer would then call = a Token Exchange service in the second security domain and exchange this ID= token for a token specific to that domain. =C2=A0 This allows for simple API federation use-cases without converging = both APIs / backends on a common token format.

=C2=A0

Questions / Feedback

=C2=A0

1) In the spec, "sub" is a required field.= =C2=A0 However, the application may not yet know who the subject is in the= second security domain ( it first has to exchange the token ) =C2=A0 =C2=A0One option might be to place the client_id of the application as iss= ued by the second security domain, but that seems a bit off. =C2=A0 Any adv= ice? =C2=A0 Should this be an Optional field?

=C2=A0

2) Speaking of client_ids, if we don't use the &= quot;sub" to transport them, we believe the second security domain wou= ld still appreciate this context. =C2=A0 The Actor field is available, but construction of a full JWT just to transport the client_id seems like = high overhead, and it may not even be aligned with the intent of that field= . =C2=A0 =C2=A0Should client_id be a claim here?

=C2=A0

3) Speaking of Actors, It's not clear what actua= lly states that the jwt included in the token is actually an approved actor= . =C2=A0 =C2=A0Is it intended that the act_as or on-behalf_of tokens include an azp authorized party clam as well?

=C2=A0

4) "Implementations of the specification MUST i= mplement support for using JWTs as the Security Tokens.=C2=A0 Other Securit= y Token types MAY be supported." =C2=A0 This seems antithetical to the purpose of an STS. =C2=A0 We believe this should be relaxed to a SHOUL= D

=C2=A0

Thanks for any feedback here

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0



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



--001a1139e540f29b38051b04d2ab-- From nobody Thu Jul 16 15:33:34 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855191A9175 for ; Thu, 16 Jul 2015 15:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7itdCp-7tGI for ; Thu, 16 Jul 2015 15:33:32 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001: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 3C0441A9173 for ; Thu, 16 Jul 2015 15:33:32 -0700 (PDT) Received: by ietj16 with SMTP id j16so66026765iet.0 for ; Thu, 16 Jul 2015 15:33:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=x3so71gxUxH/O/auSKa/bJtmwSlpvKYXgaJGOCU9Po4=; b=ILuOC+3UKktpq3WqsT1myyMrsRVvc35wi88Yj0NxG11UeibtznVGpAOKPJbRA+jeNR o2gQiGRMi90YlC4RQCIEY3nYab6RgSc2+Wi4qNRNHhYzGB9kqMcB/Jp7BIcyZ0TN/O6f t4y7q1D57n3sNinB0+HvTtHn0K65wQhvCJd1Pswdk09tJbeJ9tFfeJLpNqnoeSDaZupM TP84JA8qq/0L1G4R7h4anI0NreGN27Kp17nPH+cap+NQphbhwVfAmvA6oqPEDJ4osYlW KQEc9NH79ybqDqddpmHY2zSvCglfFK/ktEJMp/AtOapXDNBX0O270ZuLrr5PKbQWj+SE AaKg== MIME-Version: 1.0 X-Received: by 10.50.253.36 with SMTP id zx4mr6959963igc.43.1437086011792; Thu, 16 Jul 2015 15:33:31 -0700 (PDT) Received: by 10.107.40.11 with HTTP; Thu, 16 Jul 2015 15:33:31 -0700 (PDT) Date: Thu, 16 Jul 2015 15:33:31 -0700 Message-ID: From: Malla Simhachalam To: oauth@ietf.org Content-Type: multipart/alternative; boundary=001a1134801e3ea651051b05a9bb Archived-At: Subject: [OAUTH-WG] Nesting Signatures and Encryption JWT Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 22:33:33 -0000 --001a1134801e3ea651051b05a9bb Content-Type: text/plain; charset=UTF-8 Hi, I am looking at the spec https://datatracker.ietf.org/doc/rfc7520/?include_text=1 for combining JWS and JWE use case, I could not find it obvious that a JSON document should be signed first and then encrypt or other way around.Are there any recommendations one over the other? Thanks for help. Malla --001a1134801e3ea651051b05a9bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I am looking at the spec <= a href=3D"https://datatracker.ietf.org/doc/rfc7520/?include_text=3D1">https= ://datatracker.ietf.org/doc/rfc7520/?include_text=3D1 for combining JWS= and JWE use case, I could not find it obvious that a JSON document should = be signed first and then encrypt or other way around.Are there any recommen= dations one over the other?

Thanks for help.
Malla
--001a1134801e3ea651051b05a9bb-- From nobody Thu Jul 16 15:45:14 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855491AC3F1 for ; Thu, 16 Jul 2015 15:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4qrbFjsrp8n for ; Thu, 16 Jul 2015 15:45:10 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0E511AC3E0 for ; Thu, 16 Jul 2015 15:45:09 -0700 (PDT) Received: by wgxm20 with SMTP id m20so69277142wgx.3 for ; Thu, 16 Jul 2015 15:45:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=xiGnVhlzDAjUJ/NNRiCxB4zuiOuBvwI/X+6yLbqoy7Y=; b=VaDrO2cHZ208eG5P116zO8L+hrgyDS8oOzgtjiAT9jG0/fGARy4M+iVlWfY4D/UmWc br14UmeXZnN1KuMVD2/ysaElheuFo083jzKDhnb55ntjtI6rbtJYB2WD7+vHqPKeQ5pQ Ys3xOJpCgcuVOQrJJApsMDk05STYJ2IegV7xWtvMs9vOv8QGBAZHhVFh+Fg4WO7aN9XQ b5543j7ICZrDXITyBZvyM6lHZnpXZwOzOUHwdMTng6Zh5KG0DAJARUdhWXWKKuTSai1A TNNurWJxHjqOjlIILUjq0viaUIOswcEx0MTxJavS3t0tjGSjIOyR8UTDk6AENTEngWYF xPHg== X-Gm-Message-State: ALoCoQnkj2g8GLqq3yJp5Zo+ux2qlJhQvO3WPw5Zcuaf4e/7H/d/dPt8alZojOPrYpPv///cakj8 X-Received: by 10.194.220.100 with SMTP id pv4mr24632829wjc.71.1437086708245; Thu, 16 Jul 2015 15:45:08 -0700 (PDT) Received: from [10.207.202.24] ([109.144.241.102]) by smtp.gmail.com with ESMTPSA id r19sm5463383wib.7.2015.07.16.15.45.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Jul 2015 15:45:07 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_FDF04225-370A-4BCC-807B-41BFD96E7F1A"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: John Bradley In-Reply-To: Date: Thu, 16 Jul 2015 23:45:06 +0100 Message-Id: References: To: Malla Simhachalam X-Mailer: Apple Mail (2.2102) Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Nesting Signatures and Encryption JWT Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 22:45:12 -0000 --Apple-Mail=_FDF04225-370A-4BCC-807B-41BFD96E7F1A Content-Type: multipart/alternative; boundary="Apple-Mail=_B795E684-3350-4A15-95A9-A45DBD5EFC20" --Apple-Mail=_B795E684-3350-4A15-95A9-A45DBD5EFC20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii https://tools.ietf.org/html/rfc7519#section-11.2 = It is in the JWT spec. You can do it both ways however you really need = a good reason not to sign then encrypt, and then after you have a good = reason you should still sign then encrypt because you probably have not = considered everything, There are probably some edge cases that are exceptions to the rule, but = they are rare. John B. > On Jul 16, 2015, at 11:33 PM, Malla Simhachalam = wrote: >=20 > Hi, >=20 > I am looking at the spec = https://datatracker.ietf.org/doc/rfc7520/?include_text=3D1 = for = combining JWS and JWE use case, I could not find it obvious that a JSON = document should be signed first and then encrypt or other way around.Are = there any recommendations one over the other? >=20 > Thanks for help. > Malla > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_B795E684-3350-4A15-95A9-A45DBD5EFC20 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii https://tools.ietf.org/html/rfc7519#section-11.2

It is in the JWT spec. =   You can do it both ways however you really need a good reason not = to sign then encrypt, and then after you have a good reason you should = still sign then encrypt because you probably have not considered = everything,

There are probably some edge cases that are exceptions to the = rule, but they are rare.

John B.


On Jul 16, 2015, at 11:33 PM, Malla Simhachalam <mallasimhachalam@gmail.com> wrote:

Hi,

I am looking at the spec https://datatracker.ietf.org/doc/rfc7520/?include_text=3D1 = for combining JWS and JWE use case, I could not find it obvious that a = JSON document should be signed first and then encrypt or other way = around.Are there any recommendations one over the other?
Thanks for help.
Malla
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_B795E684-3350-4A15-95A9-A45DBD5EFC20-- --Apple-Mail=_FDF04225-370A-4BCC-807B-41BFD96E7F1A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTA3MTYyMjQ1MDdaMCMGCSqGSIb3DQEJBDEWBBTp7mj3DYp12EYbKynFKhHE hBQoYzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBTr+w4IAomVsxIyy47dZz/TtK7tCtT4jwYahMmlmY4jEdzREiHm9KT ulnLFt1BAbXiTOmY7gWIXEJX8bmjER4zvQOqzVDlzB7QrUr8JicgEqjlKW8cUc0/JlMMl4YdIZbx nfNR9va1D1yU1ID2+lOZVYOY1KKDVW6AUKLD+lnWxKNmQDhFUtxKcfMfmtMbrArBIh0kvy8u6Te1 ShXviCGJlvGUNW7+xZqKrYXSV0lZbqKY0golbYYRXpDrQqKwNQQNUCQFvEdCbKIgLlGw8xm6adYx c+IpHCjyF4BvPiI70rm3kEAETdFUlADaRjgusIojoT6qkmmqf0VpZruJ+oDAAAAAAAAA --Apple-Mail=_FDF04225-370A-4BCC-807B-41BFD96E7F1A-- From nobody Thu Jul 16 23:27:18 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9C11B2D5C for ; Thu, 16 Jul 2015 23:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.091 X-Spam-Level: X-Spam-Status: No, score=-0.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wf7CWzc2HNlI for ; Thu, 16 Jul 2015 23:27:14 -0700 (PDT) Received: from nrifs02.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1FC41B2E17 for ; Thu, 16 Jul 2015 23:26:56 -0700 (PDT) Received: from nriea05.index.or.jp (unknown [172.19.246.40]) by nrifs02.index.or.jp (Postfix) with SMTP id EE9FC1968C1; Fri, 17 Jul 2015 15:26:55 +0900 (JST) Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea05.index.or.jp (unknown) with ESMTP id t6H6QtYD031913; Fri, 17 Jul 2015 15:26:55 +0900 Received: from nrims00b.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id t6H6QtlA004663; Fri, 17 Jul 2015 15:26:55 +0900 Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id t6H6Qti9004662; Fri, 17 Jul 2015 15:26:55 +0900 X-Authentication-Warning: nrims00b.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf12.index.or.jp ([172.100.25.21]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id t6H6QtHx004659; Fri, 17 Jul 2015 15:26:55 +0900 Received: from NatCFRZ4 (unknown [172.31.163.94]) by nrivpnfs02.index.or.jp (Postfix) with ESMTP id 0266458166; Fri, 17 Jul 2015 15:26:52 +0900 (JST) From: "Nat Sakimura" To: "'John Bradley'" , "'Malla Simhachalam'" References: In-Reply-To: Date: Fri, 17 Jul 2015 15:26:53 +0900 Message-ID: <00ba01d0c059$94379f80$bca6de80$@nri.co.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BB_01D0C0A5.0422F100" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQG19aW7mPQzV3EIyjBZq7shA1YVMQKE3BJjngCgXYA= Content-Language: ja X-MailAdviser: 20150401 Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Nesting Signatures and Encryption JWT Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 06:27:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00BB_01D0C0A5.0422F100 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Malla, Just to add one more thing: If you just want to "sign" for the sake of integrity protection, you really do not need to do it as all the algs in JWE are integrity protected. -- Nat Sakimura < n-sakimura@nri.co.jp> Nomura Research Institute, Ltd. PLEASE READ: The information contained in this e-mail is confidential and intended for the named recipient(s) only. If you are not an intended recipient of this e-mail, you are hereby notified that any review, dissemination, distribution or duplication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete your copy from your system. From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley Sent: Friday, July 17, 2015 7:45 AM To: Malla Simhachalam Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Nesting Signatures and Encryption JWT Tokens https://tools.ietf.org/html/rfc7519#section-11.2 It is in the JWT spec. You can do it both ways however you really need a good reason not to sign then encrypt, and then after you have a good reason you should still sign then encrypt because you probably have not considered everything, There are probably some edge cases that are exceptions to the rule, but they are rare. John B. On Jul 16, 2015, at 11:33 PM, Malla Simhachalam > wrote: Hi, I am looking at the spec https://datatracker.ietf.org/doc/rfc7520/?include_text=1 for combining JWS and JWE use case, I could not find it obvious that a JSON document should be signed first and then encrypt or other way around.Are there any recommendations one over the other? Thanks for help. Malla _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------=_NextPart_000_00BB_01D0C0A5.0422F100 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

H= i Malla,

<= o:p> 

J= ust to add one more thing:

I= f you just want to “sign” for the sake of integrity = protection, you really do not need to do it as all the algs in JWE are = integrity protected.

<= o:p> 

-- =

Nat = Sakimura <n-sakimura@nri.co.jp>

Nomura = Research Institute, Ltd.

 

PLEASE = READ:

The = information contained in this e-mail is confidential and intended for = the named recipient(s) only.

If you = are not an intended recipient of this e-mail, you are hereby notified = that any review, dissemination, distribution or duplication of this = message is strictly prohibited. If you have received this message in = error, please notify the sender immediately and delete your copy from = your system.

<= o:p> 

From:<= /b> OAuth = [mailto:oauth-bounces@ietf.org] On Behalf Of John = Bradley
Sent: Friday, July 17, 2015 7:45 AM
To: = Malla Simhachalam <mallasimhachalam@gmail.com>
Cc: = oauth@ietf.org
Subject: Re: [OAUTH-WG] Nesting Signatures and = Encryption JWT Tokens

 

https://tools.i= etf.org/html/rfc7519#section-11.2

 

It is in the JWT spec.   You = can do it both ways however you really need a good reason not to sign = then encrypt, and then after you have a good reason you should still = sign then encrypt because you probably have not considered = everything,

 

There are probably some edge cases = that are exceptions to the rule, but they are = rare.

 

John = B.

 

 

On Jul 16, 2015, at 11:33 PM, Malla = Simhachalam <mallasimhachalam@gmail.com= > wrote:

 

Hi,

I am looking at the = spec https= ://datatracker.ietf.org/doc/rfc7520/?include_text=3D1 for combining = JWS and JWE use case, I could not find it obvious that a JSON document = should be signed first and then encrypt or other way around.Are there = any recommendations one over the other?

Thanks for = help.

Malla

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

 

------=_NextPart_000_00BB_01D0C0A5.0422F100-- From nobody Fri Jul 17 06:09:49 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1B01B33AA for ; Fri, 17 Jul 2015 06:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Twgzy8BmAFXB for ; Fri, 17 Jul 2015 06:09:46 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::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 D2C071B339E for ; Fri, 17 Jul 2015 06:09:45 -0700 (PDT) Received: by ietj16 with SMTP id j16so76643060iet.0 for ; Fri, 17 Jul 2015 06:09:45 -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:content-type; bh=KO9yBtuc5sSAG7nh0F7bGafhk9lxJ1Js1KTA+9G4ZUM=; b=areHrBWSWu2AtKYzdTYj0CJYzLCgrKJBL8W464/c/Pz6le/WXB7Y9SljE1P7BTr7z5 v5kTRf4MFi1a1Zw2RDnf/BGQbw3izNvN2ninAxqW2lDgQ3Kd9fk1FerFCi9Alxv+Wu38 /xYlv4u2oaXItksn08owtNjjrbIUgd8qa2DPc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=KO9yBtuc5sSAG7nh0F7bGafhk9lxJ1Js1KTA+9G4ZUM=; b=e2B+jzS2FU/5Ji14OyKBhleBWWNQO7mMo7KtqLMImm9mzVEVF3bLhRY75Fk4Z7RWpR FUk8h1hcLYzMqH6J+e/w4I1/otxir4O3CRBIK99FcKwzbAIMAlk7dCG+Kr4fLwQzkhVf EihaFS8j4O42QE7XkmILWMMRkuxFLlEMYg4Y3VClHzrE4rJpzKn4FFNCy7dylq6BbV3H jX/Us+j/h5czVljfIDKEAfVppghJ9ZNapKweLnQhdCcFgZpjqwDU6NqNZXeNhcWWb3vH ozMsJsv6RJxHYi1nPzG72LwN2kY1jortvhM256F0FL3cj2dmM9XW84gReeoQISM0RD8t GlZw== X-Gm-Message-State: ALoCoQl7KqVWwe2smng8qMcIkOfbI9h3RwYTCCG4AeQxZCpckeKkQSrylt1nIiIg6S7rkbiKpbMt X-Received: by 10.50.67.179 with SMTP id o19mr9691597igt.63.1437138584954; Fri, 17 Jul 2015 06:09:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Fri, 17 Jul 2015 06:09:15 -0700 (PDT) In-Reply-To: <00ba01d0c059$94379f80$bca6de80$@nri.co.jp> References: <00ba01d0c059$94379f80$bca6de80$@nri.co.jp> From: Brian Campbell Date: Fri, 17 Jul 2015 06:09:15 -0700 Message-ID: To: Nat Sakimura Content-Type: multipart/alternative; boundary=047d7bdca610d9878d051b11e644 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] Nesting Signatures and Encryption JWT Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 13:09:48 -0000 --047d7bdca610d9878d051b11e644 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Though you want to be careful with that as the asymmetric algs in JWE don't provide authentication of the sender. On Thu, Jul 16, 2015 at 11:26 PM, Nat Sakimura wrote= : > Hi Malla, > > > > Just to add one more thing: > > If you just want to =E2=80=9Csign=E2=80=9D for the sake of integrity prot= ection, you > really do not need to do it as all the algs in JWE are integrity protecte= d. > > > > -- > > Nat Sakimura > > Nomura Research Institute, Ltd. > > > > PLEASE READ: > > The information contained in this e-mail is confidential and intended for > the named recipient(s) only. > > If you are not an intended recipient of this e-mail, you are hereby > notified that any review, dissemination, distribution or duplication of > this message is strictly prohibited. If you have received this message in > error, please notify the sender immediately and delete your copy from you= r > system. > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *John Bradley > *Sent:* Friday, July 17, 2015 7:45 AM > *To:* Malla Simhachalam > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Nesting Signatures and Encryption JWT Tokens > > > > https://tools.ietf.org/html/rfc7519#section-11.2 > > > > It is in the JWT spec. You can do it both ways however you really need = a > good reason not to sign then encrypt, and then after you have a good reas= on > you should still sign then encrypt because you probably have not consider= ed > everything, > > > > There are probably some edge cases that are exceptions to the rule, but > they are rare. > > > > John B. > > > > > > On Jul 16, 2015, at 11:33 PM, Malla Simhachalam < > mallasimhachalam@gmail.com> wrote: > > > > Hi, > > I am looking at the spec > https://datatracker.ietf.org/doc/rfc7520/?include_text=3D1 for combining > JWS and JWE use case, I could not find it obvious that a JSON document > should be signed first and then encrypt or other way around.Are there any > recommendations one over the other? > > Thanks for help. > > Malla > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --047d7bdca610d9878d051b11e644 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Though you want to be careful with that as the asymmetric = algs in JWE don't provide authentication of the sender.

On Thu, Jul 16, 2015 a= t 11:26 PM, Nat Sakimura <n-sakimura@nri.co.jp> wrote:

Hi Malla,

=C2=A0

Just to add one more t= hing:

If you just want to =E2=80=9Csign=E2=80=9D for the sake of integrity= protection, you really do not need to do it as all the algs in JWE are int= egrity protected.

=C2=A0

--

= Nat Sakimura <n-sakimura@nri.co.jp>

Nomura Research Institute, Ltd.

=C2=A0

PLEASE READ:=

The information conta= ined in this e-mail is confidential and intended for the named recipient(s)= only.

I= f you are not an intended recipient of this e-mail, you are hereby notified= that any review, dissemination, distribution or duplication of this messag= e is strictly prohibited. If you have received this message in error, pleas= e notify the sender immediately and delete your copy from your system.

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org= ] On Behalf Of John Bradley
Sent: Friday, July 17, 201= 5 7:45 AM
To: Malla Simhachalam <mallasimhachalam@gmail.com>
Cc: oauth@ietf.org=
Subject: Re: [OAUTH-WG] Nesting Signatures and Encryption JW= T Tokens

=C2=A0

https://tools.ietf.org/html/rfc751= 9#section-11.2

=C2=A0

It is in the JWT spec. =C2=A0 You can do it bot= h ways however you really need a good reason not to sign then encrypt, and = then after you have a good reason you should still sign then encrypt becaus= e you probably have not considered everything,

=C2=A0

There are pro= bably some edge cases that are exceptions to the rule, but they are rare.

=C2=A0

John B.

=C2=A0

=C2=A0

On Jul 16, 2015, at 11:33 PM, Malla Simhacha= lam <mal= lasimhachalam@gmail.com> wrote:

=C2=A0

<= div>

Hi,

I am looking at the sp= ec https://datatracker.ietf.org/doc/rfc7520/?include_text=3D1= for combining JWS and JWE use case, I could not find it obvious that a= JSON document should be signed first and then encrypt or other way around.= Are there any recommendations one over the other?

<= /div>

Thanks for help.=

Malla

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

=C2=A0<= /u>


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


--047d7bdca610d9878d051b11e644-- From nobody Fri Jul 17 07:02:10 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E14A1B33A5 for ; Fri, 17 Jul 2015 07:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwQDHuD5pcYO for ; Fri, 17 Jul 2015 07:02:06 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 314B71B33F7 for ; Fri, 17 Jul 2015 07:02:06 -0700 (PDT) Received: by wibud3 with SMTP id ud3so40120407wib.1 for ; Fri, 17 Jul 2015 07:02:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=kX0m5vHMO48dHQXdooNLw9aO7Ev/Y0wpqaWXIb+ITB0=; b=Przpk0U1U4CgvstLSGTD3a0jBZtoGY8N8ILjqKzs/G/8yTKpKtP3KWQxe6Yxh/Kh4H pnY8iv4T4TjIjaQ6GsBFi6PnuULCw+uZHmHu91ll+KqAkSRhoPEqP96s7fEhhXULZkpi ENy63pEF2G4TMTDMyTSwlr6woKy6tKgVBvJR0EbvnCAzy4m36NOXpKr1uuwR7wnxvvHe QTCA3rzsDVQB9figPy+sLvOfLm957c4B7rwbUfd/rjc5dTria/8Hpbz3f6i66s3tXwcU melZ7KPfidEUPchDPfWn1cdM1CQrtctIKebeGsgYbsRczBvA7/WU7OFblth6FahFXO0c cycg== X-Gm-Message-State: ALoCoQl5HnRr6ad8GW4wGy7PHHTHPqLoMfqcsflTRL7fTDkIoM0KG+mS458H8NWQ5BE0/s9ifDjy X-Received: by 10.194.77.179 with SMTP id t19mr31193359wjw.30.1437141724636; Fri, 17 Jul 2015 07:02:04 -0700 (PDT) Received: from [10.207.202.25] (host86-187-98-103.range86-187.btcentralplus.com. [86.187.98.103]) by smtp.gmail.com with ESMTPSA id m4sm18499691wjb.37.2015.07.17.07.02.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Jul 2015 07:02:02 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_EFE40074-7C4F-4EEB-9A2F-73BDC805C7A9"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: John Bradley In-Reply-To: Date: Fri, 17 Jul 2015 15:02:04 +0100 Message-Id: References: <00ba01d0c059$94379f80$bca6de80$@nri.co.jp> To: Brian Campbell X-Mailer: Apple Mail (2.2102) Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] Nesting Signatures and Encryption JWT Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 14:02:09 -0000 --Apple-Mail=_EFE40074-7C4F-4EEB-9A2F-73BDC805C7A9 Content-Type: multipart/alternative; boundary="Apple-Mail=_C485F263-E7BE-49FD-8A28-B293A4B092A7" --Apple-Mail=_C485F263-E7BE-49FD-8A28-B293A4B092A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 They provide integrity protection for the encryption, that is very = important for preventing padding oracle attacks. AES GCM and = AES_CBC_HMAC_SHA2 are = both examples of Authenticated Encryption = in the sense = that the received encryption is true and not that the sender is = identified. English speakers have a hard time with the subtle difference between = identification and authentication , so I wanted to be clear. That being said there is a special case where if the JWT ie encrypted = with a symmetric key known only to two parties and it is = =E2=80=9Cauthenticated=E2=80=9D and you didn=E2=80=99t create it, then = by a process of elimination it cold have only come from one party. = This is NOT a signature, however it is a useful trick that some people = use to only encrypt and while still knowing with relative certainty who = encrypted it. I should note that ECDH-SS rfc6278 a key agreement algorithm we didn=E2=80= =99t put in the base JWA spec also has the property of providing = encryption and authenticity based on the public keys of both sender and = receiver. (note this is easier for implementers to get wrong than ECDH-ES but that = is another debate:) Probably more than you wanted to know, but Nat started it:) John B. > On Jul 17, 2015, at 2:09 PM, Brian Campbell = wrote: >=20 > Though you want to be careful with that as the asymmetric algs in JWE = don't provide authentication of the sender.=20 >=20 > On Thu, Jul 16, 2015 at 11:26 PM, Nat Sakimura > wrote: > Hi Malla, <> > =20 >=20 > Just to add one more thing: >=20 > If you just want to =E2=80=9Csign=E2=80=9D for the sake of integrity = protection, you really do not need to do it as all the algs in JWE are = integrity protected. >=20 > =20 >=20 > -- >=20 > Nat Sakimura > >=20 > Nomura Research Institute, Ltd. >=20 > =20 >=20 > PLEASE READ: >=20 > The information contained in this e-mail is confidential and intended = for the named recipient(s) only. >=20 > If you are not an intended recipient of this e-mail, you are hereby = notified that any review, dissemination, distribution or duplication of = this message is strictly prohibited. If you have received this message = in error, please notify the sender immediately and delete your copy from = your system. >=20 > =20 >=20 > From: OAuth [mailto:oauth-bounces@ietf.org = ] On Behalf Of John Bradley > Sent: Friday, July 17, 2015 7:45 AM > To: Malla Simhachalam > > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Nesting Signatures and Encryption JWT Tokens >=20 > =20 >=20 > https://tools.ietf.org/html/rfc7519#section-11.2 = > =20 >=20 > It is in the JWT spec. You can do it both ways however you really = need a good reason not to sign then encrypt, and then after you have a = good reason you should still sign then encrypt because you probably have = not considered everything, >=20 > =20 >=20 > There are probably some edge cases that are exceptions to the rule, = but they are rare. >=20 > =20 >=20 > John B. >=20 > =20 >=20 > =20 >=20 > On Jul 16, 2015, at 11:33 PM, Malla Simhachalam = > wrote: >=20 > =20 >=20 > Hi, >=20 > I am looking at the spec = https://datatracker.ietf.org/doc/rfc7520/?include_text=3D1 = for = combining JWS and JWE use case, I could not find it obvious that a JSON = document should be signed first and then encrypt or other way around.Are = there any recommendations one over the other? >=20 > Thanks for help. >=20 > Malla >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = > =20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 --Apple-Mail=_C485F263-E7BE-49FD-8A28-B293A4B092A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 They provide integrity protection for the encryption, =  that is very important for preventing padding oracle attacks.

AES = GCM and AES_CBC_HMAC_SHA2 are both examples of Authenticated Encryption in the sense that the = received encryption is true and not that the sender is = identified.

English speakers have a hard time with the subtle difference = between identification and authentication , so I wanted to be = clear.

That = being said there is a special case where if the JWT ie encrypted with a = symmetric key known only to two parties and it is =E2=80=9Cauthenticated=E2= =80=9D and you didn=E2=80=99t create it, then by a process of = elimination it cold have only come from one party.   This is NOT a = signature,  however it is a useful trick that some people use to = only encrypt and while still knowing with relative certainty who = encrypted it.

I = should note that ECDH-SS rfc6278 a key agreement algorithm we didn=E2=80=99= t put in the base JWA spec also has the property of providing encryption = and authenticity based on the  public keys of both sender and = receiver.
(note this is easier for implementers to = get wrong than ECDH-ES but that is another debate:)

Probably more than you = wanted to know, but Nat started it:)

John B.

On Jul 17, 2015, at 2:09 PM, = Brian Campbell <bcampbell@pingidentity.com> wrote:

Though you want to be careful with that as the asymmetric = algs in JWE don't provide authentication of the sender.

On Thu, Jul 16, 2015 at 11:26 PM, Nat Sakimura = <n-sakimura@nri.co.jp> = wrote:

Hi Malla,

 

Just to add one more thing:

If you just want to =E2=80=9Csign=E2=80=9D= for the sake of integrity protection, you really do not need to do it = as all the algs in JWE are integrity protected.

 

--

Nat Sakimura = <n-sakimura@nri.co.jp>

Nomura Research = Institute, Ltd.

 

PLEASE READ:

The information = contained in this e-mail is confidential and intended for the named = recipient(s) only.

If you are not an = intended recipient of this e-mail, you are hereby notified that any = review, dissemination, distribution or duplication of this message is = strictly prohibited. If you have received this message in error, please = notify the sender immediately and delete your copy from your system.

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of = John Bradley
Sent: Friday, July 17, = 2015 7:45 AM
To: Malla Simhachalam = <mallasimhachalam@gmail.com>
Cc: oauth@ietf.org
Subject: = Re: [OAUTH-WG] Nesting Signatures and Encryption JWT Tokens

 

https://tools.ietf.org/html/rfc7519#section-11.2

 

It is in the JWT = spec.   You can do it both ways however you really need a good = reason not to sign then encrypt, and then after you have a good reason = you should still sign then encrypt because you probably have not = considered everything,

 

There are probably = some edge cases that are exceptions to the rule, but they are rare.

 

John B.

 

 

On Jul 16, 2015, at 11:33 PM, Malla Simhachalam <mallasimhachalam@gmail.com> wrote:

 

Hi,

I am = looking at the spec https://datatracker.ietf.org/doc/rfc7520/?include_text=3D1 = for combining JWS and JWE use case, I could not find it obvious that a = JSON document should be signed first and then encrypt or other way = around.Are there any recommendations one over the other?

Thanks for help.

Malla

_______________________________________________
OAuth mailing 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=_C485F263-E7BE-49FD-8A28-B293A4B092A7-- --Apple-Mail=_EFE40074-7C4F-4EEB-9A2F-73BDC805C7A9 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTA3MTcxNDAyMDRaMCMGCSqGSIb3DQEJBDEWBBQwse0pfcTaHc9jBxIJTLnt iSwvKjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQAa70ITlKqz68UO3VkrKzAF4nQK6/P11don3b7autLTHC3sNXCalCE3 XklzDgPNYUcPOA68+cMqUyBwu7MvFE38J7/F2edyRgUfZBA3SRSZCN5+yw61+lpUCjhZ6PC/9SPw C82NGJglBBqxBM1dqXhW6vxR3C43B2G67+ZY43S9Zl0cydqarBF17j7TIiBkSuuiGdokDYc3Cimg DntOCEfDRWFy4wsfqI7tz8/IftAkSaWTLpifpkYCJ2vLKjpGzvlEeXTY4HbgawheEZcqZlUCY+XL 85SxkFYEbdm1cdfmfaxsgA4u6pa6dAAUGS6H22dbfwXD9IThEeIEtPBggCJSAAAAAAAA --Apple-Mail=_EFE40074-7C4F-4EEB-9A2F-73BDC805C7A9-- From nobody Fri Jul 17 09:39:22 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104B81A906E for ; Fri, 17 Jul 2015 09:39:21 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9xX1WPk2DM5 for ; Fri, 17 Jul 2015 09:39:14 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0751.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::751]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C8111A906A for ; Fri, 17 Jul 2015 09:39:13 -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=ga1Gtnbe6SfdBazNx/gJ2oLosKYnmRVF5B3zVUpHn5Y=; b=YYkSVdMl8q0095o15OOhPoDbtdlMx4/NwL05kdGDt8J2U1D3X0Kc1XqIBoQLbZQP7uGBtbNBqA33JL1c84P9rFv2ZvG8uhVKNmeDp8FjkXtRCpO1ZbpwBD1pNsiAowu/ym+5AKt2Iczpop+5IfN8iImM1WpNCQ2QN/ib5uigEGM= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.213.10; Fri, 17 Jul 2015 16:38:54 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0213.021; Fri, 17 Jul 2015 16:38:54 +0000 From: Mike Jones To: John Bradley , Brian Campbell Thread-Topic: [OAUTH-WG] Nesting Signatures and Encryption JWT Tokens Thread-Index: AQHQwBd25ErrG2guLkGQKlKGrzBGN53esfAAgACBBYCAAHBrgIAADsIAgAArcDA= Date: Fri, 17 Jul 2015 16:38:54 +0000 Message-ID: References: <00ba01d0c059$94379f80$bca6de80$@nri.co.jp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ve7jtb.com; dkim=none (message not signed) header.d=none; x-originating-ip: [50.47.90.173] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:uee7UWzb8zghup44gabwzLar7e9Ok61yPf0XrXpGo4OwQyu277nSR7dxjjunRtFDIvbMJ1M0/gFg/VmUMll6HWRY3sbFBI1zfnK73YWd6UMutFVj3v10bJ7h+M+ZiaoBufGCpsxsL1k3TCzqN1WZhg==; 24:zG1kDMZmn8XaVM87Otn4Wp877fSgTnQz9zl/5aRzMC+hTAdRCoGf826sxf+JbNy44FdxAh7zRjU0TsCV3RHlWqCCE0oy6PaZQUVqFwStSko=; 20:cHaglZHc76F/SfJ/A4OqBpDEuysa66cOTO9njrfeQtia+GfcdpQRFfmx1vjn/ZrLozdBj4cam+o4uigd8Zsx0A== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; by2pr03mb442: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 06400060E1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(374574003)(365934003)(62966003)(86362001)(106116001)(86612001)(76176999)(93886004)(99286002)(54356999)(19625215002)(2656002)(5002640100001)(19580405001)(19580395003)(46102003)(50986999)(87936001)(189998001)(92566002)(5001960100002)(74316001)(19617315012)(76576001)(122556002)(102836002)(77096005)(33656002)(5001920100001)(15975445007)(5001770100001)(77156002)(19300405004)(19609705001)(5003600100002)(2900100001)(2950100001)(16236675004); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442DC66D8116A0AF1DBA460F5980BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2015 16:38:54.4854 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] Nesting Signatures and Encryption JWT Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 16:39:21 -0000 --_000_BY2PR03MB442DC66D8116A0AF1DBA460F5980BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgZm9yIOKAnEVDREgtU1MgcmZjNjI3OCAoYmVpbmcpIGVhc2llciBmb3IgaW1wbGVtZW50ZXJz IHRvIGdldCB3cm9uZyB0aGFuIEVDREgtRVPigJ0gdGhlIGdvb2QgbmV3cyBhYm91dCBjcnlwdG8g aXMgdGhhdCBpZiB5b3UgZ2V0IGl0IGV2ZW4gYSBsaXR0bGUgYml0IHdyb25nLCBpdCBkb2VzbuKA mXQgd29yayB3aXRoIG90aGVy4oCZcyBpbXBsZW1lbnRhdGlvbnMgYXQgYWxsLCBzbyB0aGlzIHNp dHVhdGlvbiB0ZW5kcyB0byBiZSBzZWxmLWNvcnJlY3RpbmcuDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENoZWVycywNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0t IE1pa2UNCg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgSm9obiBCcmFkbGV5DQpTZW50OiBGcmlkYXksIEp1bHkgMTcsIDIwMTUgNzowMiBB TQ0KVG86IEJyaWFuIENhbXBiZWxsDQpDYzogb2F1dGgNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0dd IE5lc3RpbmcgU2lnbmF0dXJlcyBhbmQgRW5jcnlwdGlvbiBKV1QgVG9rZW5zDQoNClRoZXkgcHJv dmlkZSBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBmb3IgdGhlIGVuY3J5cHRpb24sICB0aGF0IGlzIHZl cnkgaW1wb3J0YW50IGZvciBwcmV2ZW50aW5nIHBhZGRpbmcgb3JhY2xlIGF0dGFja3MuDQoNCkFF UyBHQ008aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9 aHR0cHMlM2ElMmYlMmZ0b29scy5pZXRmLm9yZyUyZmh0bWwlMmZyZmM3NTE4JTIzc2VjdGlvbi01 LjMmZGF0YT0wMSU3YzAxJTdjTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN2M1YmM5ZWRh MGU4ZGE0OTRlMTFiYjA4ZDI4ZWIwNTE5ZiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFk YjQ3JTdjMSZzZGF0YT1LbTRscllIdUZTbUl2WU9OdGl1c0ZvWkV0U1JvQWo0Umk4dWRJb2lBNU5r JTNkPiBhbmQgQUVTX0NCQ19ITUFDX1NIQTI8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ0b29scy5pZXRmLm9yZyUyZmh0bWwl MmZyZmM3NTE4JTIzc2VjdGlvbi01LjImZGF0YT0wMSU3YzAxJTdjTWljaGFlbC5Kb25lcyU0MG1p Y3Jvc29mdC5jb20lN2M1YmM5ZWRhMGU4ZGE0OTRlMTFiYjA4ZDI4ZWIwNTE5ZiU3YzcyZjk4OGJm ODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1JYVE5aFlONEx3NWJWVFhSY1N3Tmk0 UnpLbm9qSUtBQUlkdGY1M0pEQnZFJTNkPiBhcmUgYm90aCBleGFtcGxlcyBvZiBBdXRoZW50aWNh dGVkIEVuY3J5cHRpb248aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cHMlM2ElMmYlMmZlbi53aWtpcGVkaWEub3JnJTJmd2lraSUyZkF1dGhlbnRp Y2F0ZWRfZW5jcnlwdGlvbiZkYXRhPTAxJTdjMDElN2NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0 LmNvbSU3YzViYzllZGEwZThkYTQ5NGUxMWJiMDhkMjhlYjA1MTlmJTdjNzJmOTg4YmY4NmYxNDFh ZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPWVSVjV4Z2YxN0lXeXowajVRd2dEbXViRHc1cnFK bmVNYVl0Q0h1MUNMVnMlM2Q+IGluIHRoZSBzZW5zZSB0aGF0IHRoZSByZWNlaXZlZCBlbmNyeXB0 aW9uIGlzIHRydWUgYW5kIG5vdCB0aGF0IHRoZSBzZW5kZXIgaXMgaWRlbnRpZmllZC4NCg0KRW5n bGlzaCBzcGVha2VycyBoYXZlIGEgaGFyZCB0aW1lIHdpdGggdGhlIHN1YnRsZSBkaWZmZXJlbmNl IGJldHdlZW4gaWRlbnRpZmljYXRpb24gYW5kIGF1dGhlbnRpY2F0aW9uICwgc28gSSB3YW50ZWQg dG8gYmUgY2xlYXIuDQoNClRoYXQgYmVpbmcgc2FpZCB0aGVyZSBpcyBhIHNwZWNpYWwgY2FzZSB3 aGVyZSBpZiB0aGUgSldUIGllIGVuY3J5cHRlZCB3aXRoIGEgc3ltbWV0cmljIGtleSBrbm93biBv bmx5IHRvIHR3byBwYXJ0aWVzIGFuZCBpdCBpcyDigJxhdXRoZW50aWNhdGVk4oCdIGFuZCB5b3Ug ZGlkbuKAmXQgY3JlYXRlIGl0LCB0aGVuIGJ5IGEgcHJvY2VzcyBvZiBlbGltaW5hdGlvbiBpdCBj b2xkIGhhdmUgb25seSBjb21lIGZyb20gb25lIHBhcnR5LiAgIFRoaXMgaXMgTk9UIGEgc2lnbmF0 dXJlLCAgaG93ZXZlciBpdCBpcyBhIHVzZWZ1bCB0cmljayB0aGF0IHNvbWUgcGVvcGxlIHVzZSB0 byBvbmx5IGVuY3J5cHQgYW5kIHdoaWxlIHN0aWxsIGtub3dpbmcgd2l0aCByZWxhdGl2ZSBjZXJ0 YWludHkgd2hvIGVuY3J5cHRlZCBpdC4NCg0KSSBzaG91bGQgbm90ZSB0aGF0IEVDREgtU1MgcmZj NjI3OCBhIGtleSBhZ3JlZW1lbnQgYWxnb3JpdGhtIHdlIGRpZG7igJl0IHB1dCBpbiB0aGUgYmFz ZSBKV0Egc3BlYyBhbHNvIGhhcyB0aGUgcHJvcGVydHkgb2YgcHJvdmlkaW5nIGVuY3J5cHRpb24g YW5kIGF1dGhlbnRpY2l0eSBiYXNlZCBvbiB0aGUgIHB1YmxpYyBrZXlzIG9mIGJvdGggc2VuZGVy IGFuZCByZWNlaXZlci4NCihub3RlIHRoaXMgaXMgZWFzaWVyIGZvciBpbXBsZW1lbnRlcnMgdG8g Z2V0IHdyb25nIHRoYW4gRUNESC1FUyBidXQgdGhhdCBpcyBhbm90aGVyIGRlYmF0ZTopDQoNClBy b2JhYmx5IG1vcmUgdGhhbiB5b3Ugd2FudGVkIHRvIGtub3csIGJ1dCBOYXQgc3RhcnRlZCBpdDop DQoNCkpvaG4gQi4NCg0KDQpPbiBKdWwgMTcsIDIwMTUsIGF0IDI6MDkgUE0sIEJyaWFuIENhbXBi ZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVu dGl0eS5jb20+PiB3cm90ZToNCg0KVGhvdWdoIHlvdSB3YW50IHRvIGJlIGNhcmVmdWwgd2l0aCB0 aGF0IGFzIHRoZSBhc3ltbWV0cmljIGFsZ3MgaW4gSldFIGRvbid0IHByb3ZpZGUgYXV0aGVudGlj YXRpb24gb2YgdGhlIHNlbmRlci4NCg0KT24gVGh1LCBKdWwgMTYsIDIwMTUgYXQgMTE6MjYgUE0s IE5hdCBTYWtpbXVyYSA8bi1zYWtpbXVyYUBucmkuY28uanA8bWFpbHRvOm4tc2FraW11cmFAbnJp LmNvLmpwPj4gd3JvdGU6DQpIaSBNYWxsYSwNCg0KSnVzdCB0byBhZGQgb25lIG1vcmUgdGhpbmc6 DQpJZiB5b3UganVzdCB3YW50IHRvIOKAnHNpZ27igJ0gZm9yIHRoZSBzYWtlIG9mIGludGVncml0 eSBwcm90ZWN0aW9uLCB5b3UgcmVhbGx5IGRvIG5vdCBuZWVkIHRvIGRvIGl0IGFzIGFsbCB0aGUg YWxncyBpbiBKV0UgYXJlIGludGVncml0eSBwcm90ZWN0ZWQuDQoNCi0tDQpOYXQgU2FraW11cmEg PG4tc2FraW11cmFAbnJpLmNvLmpwPG1haWx0bzpuLXNha2ltdXJhQG5yaS5jby5qcD4+DQpOb211 cmEgUmVzZWFyY2ggSW5zdGl0dXRlLCBMdGQuDQoNClBMRUFTRSBSRUFEOg0KVGhlIGluZm9ybWF0 aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCBpcyBjb25maWRlbnRpYWwgYW5kIGludGVuZGVk IGZvciB0aGUgbmFtZWQgcmVjaXBpZW50KHMpIG9ubHkuDQpJZiB5b3UgYXJlIG5vdCBhbiBpbnRl bmRlZCByZWNpcGllbnQgb2YgdGhpcyBlLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRo YXQgYW55IHJldmlldywgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uIG9yIGR1cGxpY2F0aW9u IG9mIHRoaXMgbWVzc2FnZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1l ZGlhdGVseSBhbmQgZGVsZXRlIHlvdXIgY29weSBmcm9tIHlvdXIgc3lzdGVtLg0KDQpGcm9tOiBP QXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNA aWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgSm9obiBCcmFkbGV5DQpTZW50OiBGcmlkYXksIEp1bHkg MTcsIDIwMTUgNzo0NSBBTQ0KVG86IE1hbGxhIFNpbWhhY2hhbGFtIDxtYWxsYXNpbWhhY2hhbGFt QGdtYWlsLmNvbTxtYWlsdG86bWFsbGFzaW1oYWNoYWxhbUBnbWFpbC5jb20+Pg0KQ2M6IG9hdXRo QGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0dd IE5lc3RpbmcgU2lnbmF0dXJlcyBhbmQgRW5jcnlwdGlvbiBKV1QgVG9rZW5zDQoNCmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTE5I3NlY3Rpb24tMTEuMjxodHRwczovL25hMDEuc2Fm ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnRvb2xzLmll dGYub3JnJTJmaHRtbCUyZnJmYzc1MTklMjNzZWN0aW9uLTExLjImZGF0YT0wMSU3YzAxJTdjTWlj aGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN2M1YmM5ZWRhMGU4ZGE0OTRlMTFiYjA4ZDI4ZWIw NTE5ZiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1iSmpVYTlI JTJmaHNvUUdmam1aRUJRSXlZeHdaTmM1SGx0JTJiRHpyRWolMmJIRzcwJTNkPg0KDQpJdCBpcyBp biB0aGUgSldUIHNwZWMuICAgWW91IGNhbiBkbyBpdCBib3RoIHdheXMgaG93ZXZlciB5b3UgcmVh bGx5IG5lZWQgYSBnb29kIHJlYXNvbiBub3QgdG8gc2lnbiB0aGVuIGVuY3J5cHQsIGFuZCB0aGVu IGFmdGVyIHlvdSBoYXZlIGEgZ29vZCByZWFzb24geW91IHNob3VsZCBzdGlsbCBzaWduIHRoZW4g ZW5jcnlwdCBiZWNhdXNlIHlvdSBwcm9iYWJseSBoYXZlIG5vdCBjb25zaWRlcmVkIGV2ZXJ5dGhp bmcsDQoNClRoZXJlIGFyZSBwcm9iYWJseSBzb21lIGVkZ2UgY2FzZXMgdGhhdCBhcmUgZXhjZXB0 aW9ucyB0byB0aGUgcnVsZSwgYnV0IHRoZXkgYXJlIHJhcmUuDQoNCkpvaG4gQi4NCg0KDQpPbiBK dWwgMTYsIDIwMTUsIGF0IDExOjMzIFBNLCBNYWxsYSBTaW1oYWNoYWxhbSA8bWFsbGFzaW1oYWNo YWxhbUBnbWFpbC5jb208bWFpbHRvOm1hbGxhc2ltaGFjaGFsYW1AZ21haWwuY29tPj4gd3JvdGU6 DQoNCkhpLA0KSSBhbSBsb29raW5nIGF0IHRoZSBzcGVjIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL3JmYzc1MjAvP2luY2x1ZGVfdGV4dD0xPGh0dHBzOi8vbmEwMS5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmZGF0YXRyYWNrZXIuaWV0 Zi5vcmclMmZkb2MlMmZyZmM3NTIwJTJmJTNmaW5jbHVkZV90ZXh0JTNkMSZkYXRhPTAxJTdjMDEl N2NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3YzViYzllZGEwZThkYTQ5NGUxMWJiMDhk MjhlYjA1MTlmJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPTlY M2F1eVNuTDRYbFQlMmZSVyUyYkFPYUJHNXdYOGpyTmM4MkFaMEdvJTJiWklydU0lM2Q+IGZvciBj b21iaW5pbmcgSldTIGFuZCBKV0UgdXNlIGNhc2UsIEkgY291bGQgbm90IGZpbmQgaXQgb2J2aW91 cyB0aGF0IGEgSlNPTiBkb2N1bWVudCBzaG91bGQgYmUgc2lnbmVkIGZpcnN0IGFuZCB0aGVuIGVu Y3J5cHQgb3Igb3RoZXIgd2F5IGFyb3VuZC5BcmUgdGhlcmUgYW55IHJlY29tbWVuZGF0aW9ucyBv bmUgb3ZlciB0aGUgb3RoZXI/DQpUaGFua3MgZm9yIGhlbHAuDQpNYWxsYQ0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0K T0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4l MmZsaXN0aW5mbyUyZm9hdXRoJmRhdGE9MDElN2MwMSU3Y01pY2hhZWwuSm9uZXMlNDBtaWNyb3Nv ZnQuY29tJTdjNWJjOWVkYTBlOGRhNDk0ZTExYmIwOGQyOGViMDUxOWYlN2M3MmY5ODhiZjg2ZjE0 MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9bGRPblNhblFFUDZZT29IZGQzNlVyNmJXRW5R Z2ElMmZJTmxUTEF4NEJPRWVzJTNkPg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1h aWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGg8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91 cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0 aCZkYXRhPTAxJTdjMDElN2NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3YzViYzllZGEw ZThkYTQ5NGUxMWJiMDhkMjhlYjA1MTlmJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRi NDclN2MxJnNkYXRhPWxkT25TYW5RRVA2WU9vSGRkMzZVcjZiV0VuUWdhJTJmSU5sVExBeDRCT0Vl cyUzZD4NCg0KDQo= --_000_BY2PR03MB442DC66D8116A0AF1DBA460F5980BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4 IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEBNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUs IGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N CnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRl eHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFzIGZvciDigJw8L3NwYW4+ RUNESC1TUyByZmM2Mjc4IChiZWluZykgZWFzaWVyIGZvciBpbXBsZW1lbnRlcnMgdG8gZ2V0IHdy b25nIHRoYW4gRUNESC1FUzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij7igJ0NCiB0aGUgZ29vZCBuZXdzIGFib3V0IGNyeXB0byBpcyB0aGF0IGlmIHlvdSBnZXQgaXQg ZXZlbiBhIGxpdHRsZSBiaXQgd3JvbmcsIGl0IGRvZXNu4oCZdCB3b3JrIHdpdGggb3RoZXLigJlz IGltcGxlbWVudGF0aW9ucyBhdCBhbGwsIHNvIHRoaXMgc2l0dWF0aW9uIHRlbmRzIHRvIGJlIHNl bGYtY29ycmVjdGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDaGVlcnMsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4gT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5Kb2huIEJyYWRsZXk8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKdWx5IDE3LCAyMDE1 IDc6MDIgQU08YnI+DQo8Yj5Ubzo8L2I+IEJyaWFuIENhbXBiZWxsPGJyPg0KPGI+Q2M6PC9iPiBv YXV0aDxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBOZXN0aW5nIFNpZ25hdHVy ZXMgYW5kIEVuY3J5cHRpb24gSldUIFRva2VuczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZXkgcHJvdmlkZSBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBmb3Ig dGhlIGVuY3J5cHRpb24sICZuYnNwO3RoYXQgaXMgdmVyeSBpbXBvcnRhbnQgZm9yIHByZXZlbnRp bmcgcGFkZGluZyBvcmFjbGUgYXR0YWNrcy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlv bi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmdG9vbHMuaWV0Zi5vcmclMmZodG1sJTJm cmZjNzUxOCUyM3NlY3Rpb24tNS4zJmFtcDtkYXRhPTAxJTdjMDElN2NNaWNoYWVsLkpvbmVzJTQw bWljcm9zb2Z0LmNvbSU3YzViYzllZGEwZThkYTQ5NGUxMWJiMDhkMjhlYjA1MTlmJTdjNzJmOTg4 YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1LbTRscllIdUZTbUl2WU9O dGl1c0ZvWkV0U1JvQWo0Umk4dWRJb2lBNU5rJTNkIj5BRVMNCiBHQ008L2E+Jm5ic3A7YW5kJm5i c3A7PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29t Lz91cmw9aHR0cHMlM2ElMmYlMmZ0b29scy5pZXRmLm9yZyUyZmh0bWwlMmZyZmM3NTE4JTIzc2Vj dGlvbi01LjImYW1wO2RhdGE9MDElN2MwMSU3Y01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29t JTdjNWJjOWVkYTBlOGRhNDk0ZTExYmIwOGQyOGViMDUxOWYlN2M3MmY5ODhiZjg2ZjE0MWFmOTFh YjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPUlhUTloWU40THc1YlZUWFJjU3dOaTRSektub2pJ S0FBSWR0ZjUzSkRCdkUlM2QiPkFFU19DQkNfSE1BQ19TSEEyPC9hPiZuYnNwO2FyZQ0KIGJvdGgg ZXhhbXBsZXMgb2YmbmJzcDs8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZmVuLndpa2lwZWRpYS5vcmclMmZ3aWtp JTJmQXV0aGVudGljYXRlZF9lbmNyeXB0aW9uJmFtcDtkYXRhPTAxJTdjMDElN2NNaWNoYWVsLkpv bmVzJTQwbWljcm9zb2Z0LmNvbSU3YzViYzllZGEwZThkYTQ5NGUxMWJiMDhkMjhlYjA1MTlmJTdj NzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1lUlY1eGdmMTdJ V3l6MGo1UXdnRG11YkR3NXJxSm5lTWFZdENIdTFDTFZzJTNkIj5BdXRoZW50aWNhdGVkDQogRW5j cnlwdGlvbjwvYT4mbmJzcDtpbiB0aGUgc2Vuc2UgdGhhdCB0aGUgcmVjZWl2ZWQgZW5jcnlwdGlv biBpcyB0cnVlIGFuZCBub3QgdGhhdCB0aGUgc2VuZGVyIGlzIGlkZW50aWZpZWQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkVuZ2xpc2ggc3Bl YWtlcnMgaGF2ZSBhIGhhcmQgdGltZSB3aXRoIHRoZSBzdWJ0bGUgZGlmZmVyZW5jZSBiZXR3ZWVu IGlkZW50aWZpY2F0aW9uIGFuZCBhdXRoZW50aWNhdGlvbiAsIHNvIEkgd2FudGVkIHRvIGJlIGNs ZWFyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGF0IGJlaW5nIHNhaWQgdGhlcmUgaXMgYSBzcGVjaWFsIGNhc2Ugd2hlcmUgaWYgdGhlIEpX VCBpZSBlbmNyeXB0ZWQgd2l0aCBhIHN5bW1ldHJpYyBrZXkga25vd24gb25seSB0byB0d28gcGFy dGllcyBhbmQgaXQgaXMg4oCcYXV0aGVudGljYXRlZOKAnSBhbmQgeW91IGRpZG7igJl0IGNyZWF0 ZSBpdCwgdGhlbiBieSBhIHByb2Nlc3Mgb2YgZWxpbWluYXRpb24gaXQgY29sZCBoYXZlIG9ubHkg Y29tZSBmcm9tIG9uZSBwYXJ0eS4NCiAmbmJzcDsgVGhpcyBpcyBOT1QgYSBzaWduYXR1cmUsICZu YnNwO2hvd2V2ZXIgaXQgaXMgYSB1c2VmdWwgdHJpY2sgdGhhdCBzb21lIHBlb3BsZSB1c2UgdG8g b25seSBlbmNyeXB0IGFuZCB3aGlsZSBzdGlsbCBrbm93aW5nIHdpdGggcmVsYXRpdmUgY2VydGFp bnR5IHdobyBlbmNyeXB0ZWQgaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgc2hvdWxkIG5vdGUgdGhhdCBFQ0RILVNTIHJmYzYyNzggYSBr ZXkgYWdyZWVtZW50IGFsZ29yaXRobSB3ZSBkaWRu4oCZdCBwdXQgaW4gdGhlIGJhc2UgSldBIHNw ZWMgYWxzbyBoYXMgdGhlIHByb3BlcnR5IG9mIHByb3ZpZGluZyBlbmNyeXB0aW9uIGFuZCBhdXRo ZW50aWNpdHkgYmFzZWQgb24gdGhlICZuYnNwO3B1YmxpYyBrZXlzIG9mIGJvdGggc2VuZGVyIGFu ZCByZWNlaXZlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPihub3RlIHRoaXMgaXMgZWFzaWVyIGZvciBpbXBsZW1lbnRlcnMgdG8gZ2V0IHdyb25n IHRoYW4gRUNESC1FUyBidXQgdGhhdCBpcyBhbm90aGVyIGRlYmF0ZTopPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlByb2JhYmx5IG1vcmUgdGhh biB5b3Ugd2FudGVkIHRvIGtub3csIGJ1dCBOYXQgc3RhcnRlZCBpdDopPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvaG4gQi48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gSnVsIDE3 LCAyMDE1LCBhdCAyOjA5IFBNLCBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJj YW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhvdWdoIHlvdSB3YW50IHRvIGJlIGNhcmVmdWwgd2l0aCB0aGF0IGFzIHRoZSBhc3ltbWV0cmlj IGFsZ3MgaW4gSldFIGRvbid0IHByb3ZpZGUgYXV0aGVudGljYXRpb24gb2YgdGhlIHNlbmRlci4N CjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBK dWwgMTYsIDIwMTUgYXQgMTE6MjYgUE0sIE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0ibWFpbHRv Om4tc2FraW11cmFAbnJpLmNvLmpwIiB0YXJnZXQ9Il9ibGFuayI+bi1zYWtpbXVyYUBucmkuY28u anA8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48YSBuYW1lPSIxNGU5YWIyMjVkMWFlODlkX19NYWlsRW5kQ29tcG9zZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkpBIj5IaSBNYWxsYSwNCjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOkpBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpKQSI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpK QSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SkEi Pkp1c3QgdG8gYWRkIG9uZSBtb3JlIHRoaW5nOg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpKQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6SkEiPklmIHlvdSBqdXN0IHdhbnQgdG8g4oCcc2lnbuKAnSBmb3IgdGhlIHNh a2Ugb2YgaW50ZWdyaXR5IHByb3RlY3Rpb24sIHlvdSByZWFsbHkNCiBkbyBub3QgbmVlZCB0byBk byBpdCBhcyBhbGwgdGhlIGFsZ3MgaW4gSldFIGFyZSBpbnRlZ3JpdHkgcHJvdGVjdGVkLiA8L3Nw YW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkpBIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpKQSI+Jm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpKQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6SkEiPi0tDQo8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOkpBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhp YyZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkpBIj5OYXQgU2FraW11 cmEgJmx0Ozwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SkEiPjxhIGhy ZWY9Im1haWx0bzpuLXNha2ltdXJhQG5yaS5jby5qcCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90Oztj b2xvcjojMDU2M0MxIj5uLXNha2ltdXJhQG5yaS5jby5qcDwvc3Bhbj48L2E+PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90 Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkpBIj4mZ3Q7PC9zcGFuPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpKQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpKQSI+Tm9tdXJhIFJlc2VhcmNoIEluc3RpdHV0ZSwgTHRkLg0KPC9zcGFuPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpKQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpKQSI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpKQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90 Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkpBIj5QTEVBU0UgUkVBRDo8L3Nw YW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkpBIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6SkEiPlRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1h aWwgaXMgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBmb3IgdGhlIG5hbWVkIHJlY2lwaWVudChz KQ0KIG9ubHkuPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpKQSI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90Oztjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkpBIj5JZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRl ZCByZWNpcGllbnQgb2YgdGhpcyBlLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQg YW55DQogcmV2aWV3LCBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24gb3IgZHVwbGljYXRpb24g b2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVk aWF0ZWx5IGFuZCBkZWxldGUgeW91ciBjb3B5IGZyb20geW91ciBzeXN0ZW0uPC9zcGFuPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpKQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpKQSI+Jm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpKQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztt c28tZmFyZWFzdC1sYW5ndWFnZTpKQSI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpKQSI+DQogT0F1dGggW21haWx0bzo8YSBo cmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRo LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Kb2huIEJyYWRsZXk8 YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKdWx5IDE3LCAyMDE1IDc6NDUgQU08YnI+DQo8Yj5U bzo8L2I+IE1hbGxhIFNpbWhhY2hhbGFtICZsdDs8YSBocmVmPSJtYWlsdG86bWFsbGFzaW1oYWNo YWxhbUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWxsYXNpbWhhY2hhbGFtQGdtYWlsLmNv bTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtPQVVUSC1XR10gTmVzdGluZyBTaWduYXR1cmVzIGFuZCBFbmNyeXB0aW9uIEpXVCBUb2tl bnM8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkpBIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpKQSI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SkEiPjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmdG9vbHMuaWV0Zi5vcmcl MmZodG1sJTJmcmZjNzUxOSUyM3NlY3Rpb24tMTEuMiZhbXA7ZGF0YT0wMSU3YzAxJTdjTWljaGFl bC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN2M1YmM5ZWRhMGU4ZGE0OTRlMTFiYjA4ZDI4ZWIwNTE5 ZiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9YkpqVWE5 SCUyZmhzb1FHZmptWkVCUUl5WXh3Wk5jNUhsdCUyYkR6ckVqJTJiSEc3MCUzZCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTE5I3NlY3Rpb24tMTEuMjwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SkEiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkpBIj5JdCBpcyBpbiB0aGUgSldUIHNwZWMuICZuYnNw OyBZb3UgY2FuIGRvIGl0IGJvdGggd2F5cyBob3dldmVyIHlvdSByZWFsbHkgbmVlZCBhIGdvb2Qg cmVhc29uIG5vdCB0byBzaWduIHRoZW4gZW5jcnlwdCwgYW5kIHRoZW4gYWZ0ZXIgeW91IGhhdmUg YQ0KIGdvb2QgcmVhc29uIHlvdSBzaG91bGQgc3RpbGwgc2lnbiB0aGVuIGVuY3J5cHQgYmVjYXVz ZSB5b3UgcHJvYmFibHkgaGF2ZSBub3QgY29uc2lkZXJlZCBldmVyeXRoaW5nLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkpBIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpKQSI+VGhlcmUgYXJlIHByb2JhYmx5IHNvbWUgZWRnZSBjYXNl cyB0aGF0IGFyZSBleGNlcHRpb25zIHRvIHRoZSBydWxlLCBidXQgdGhleSBhcmUgcmFyZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpKQSI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SkEiPkpvaG4gQi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpKQSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6SkEiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpKQSI+T24gSnVsIDE2LCAyMDE1LCBhdCAxMTozMyBQTSwgTWFsbGEgU2ltaGFjaGFsYW0g Jmx0OzxhIGhyZWY9Im1haWx0bzptYWxsYXNpbWhhY2hhbGFtQGdtYWlsLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPm1hbGxhc2ltaGFjaGFsYW1AZ21haWwuY29tPC9hPiZndDsNCiB3cm90ZTo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkpBIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkpBIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOkpBIj5JIGFtIGxvb2tpbmcgYXQgdGhlIHNwZWMNCjxhIGhyZWY9Imh0dHBzOi8vbmEw MS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmZGF0 YXRyYWNrZXIuaWV0Zi5vcmclMmZkb2MlMmZyZmM3NTIwJTJmJTNmaW5jbHVkZV90ZXh0JTNkMSZh bXA7ZGF0YT0wMSU3YzAxJTdjTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN2M1YmM5ZWRh MGU4ZGE0OTRlMTFiYjA4ZDI4ZWIwNTE5ZiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFk YjQ3JTdjMSZhbXA7c2RhdGE9OVgzYXV5U25MNFhsVCUyZlJXJTJiQU9hQkc1d1g4anJOYzgyQVow R28lMmJaSXJ1TSUzZCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvcmZjNzUyMC8/aW5jbHVkZV90ZXh0PTE8L2E+IGZvciBjb21iaW5pbmcgSldTIGFu ZCBKV0UgdXNlIGNhc2UsIEkgY291bGQgbm90IGZpbmQgaXQgb2J2aW91cyB0aGF0IGEgSlNPTiBk b2N1bWVudCBzaG91bGQgYmUgc2lnbmVkIGZpcnN0IGFuZCB0aGVuIGVuY3J5cHQgb3Igb3RoZXIg d2F5IGFyb3VuZC5BcmUgdGhlcmUgYW55IHJlY29tbWVuZGF0aW9ucyBvbmUgb3ZlciB0aGUgb3Ro ZXI/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpKQSI+VGhhbmtzIGZvciBoZWxwLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SkEiPk1hbGxhPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpKQSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1 dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1o dHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmFt cDtkYXRhPTAxJTdjMDElN2NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3YzViYzllZGEw ZThkYTQ5NGUxMWJiMDhkMjhlYjA1MTlmJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRi NDclN2MxJmFtcDtzZGF0YT1sZE9uU2FuUUVQNllPb0hkZDM2VXI2YldFblFnYSUyZklObFRMQXg0 Qk9FZXMlM2QiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpKQSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91 cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0 aCZhbXA7ZGF0YT0wMSU3YzAxJTdjTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN2M1YmM5 ZWRhMGU4ZGE0OTRlMTFiYjA4ZDI4ZWIwNTE5ZiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2Qw MTFkYjQ3JTdjMSZhbXA7c2RhdGE9bGRPblNhblFFUDZZT29IZGQzNlVyNmJXRW5RZ2ElMmZJTmxU TEF4NEJPRWVzJTNkIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BY2PR03MB442DC66D8116A0AF1DBA460F5980BY2PR03MB442namprd_-- From nobody Fri Jul 17 10:38:09 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFB31A00F4 for ; Fri, 17 Jul 2015 10:38:08 -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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrXT4IX_yWAg for ; Fri, 17 Jul 2015 10:38:05 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29EA61A00F3 for ; Fri, 17 Jul 2015 10:38:02 -0700 (PDT) X-AuditID: 1209190c-f79296d000000622-a2-55a93d79ec7b Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 3D.0B.01570.97D39A55; Fri, 17 Jul 2015 13:38:01 -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 t6HHc0Xx013826; Fri, 17 Jul 2015 13:38:00 -0400 Received: from [10.173.113.71] ([209.117.45.10]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t6HHbvOw010242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Jul 2015 13:37:59 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_5EB9DD8F-3361-4525-96D3-C5B314D226A3" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Justin Richer In-Reply-To: Date: Fri, 17 Jul 2015 13:37:58 -0400 Message-Id: References: <00ba01d0c059$94379f80$bca6de80$@nri.co.jp> To: Mike Jones X-Mailer: Apple Mail (2.2102) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGKsWRmVeSWpSXmKPExsUixG6noltpuzLU4OlHIYvV/28yWuyd9onF 4uTbV2wWq+/+ZXNg8Viy5CeTR+uOv+wed49eZPG4fXsjSwBLFJdNSmpOZllqkb5dAldG55O7 LAXzvjNWLLq9nqWB8cpdxi5GTg4JAROJzcvmskDYYhIX7q1n62Lk4hASWMwksWneJXYIZyOj xPo9x1khnLVMEnuWtwM5HBzMAgkSi15KgXTzCuhJ9Jz7AjZVWMBF4tHKdcwgNpuAqsT0NS1M IDanQLTE8Qsn2EBsFqD4kl9drCA2s0AHo8T52wIQc6wkJq5Zzgyx6wuTxP1nL8GGigjoSDy+ +I0N4lRZia1vWpkmMArMQjhjFpIzZoGN1ZZYtvA1M4StKbG/ezkLpriGROe3iawLGNlWMcqm 5Fbp5iZm5hSnJusWJyfm5aUW6Rrq5WaW6KWmlG5iBEUHpyTPDsY3B5UOMQpwMCrx8Da4rggV Yk0sK67MPcQoycGkJMrrabIyVIgvKT+lMiOxOCO+qDQntfgQowQHs5II7wotoBxvSmJlVWpR PkxKmoNFSZx30w++ECGB9MSS1OzU1ILUIpisDAeHkgSvpg1Qo2BRanpqRVpmTglCmomDE2Q4 D9BwFpAa3uKCxNzizHSI/ClGRSlx3hvWQAkBkERGaR5cLyx5vWIUB3pFmHc9SDsPMPHBdb8C GswENLhz9QqQwSWJCCmpBkaOLqvvyozbZeQtGn6Wrbq+PHNdQfD+jys/lHAm6Qgt5pbN0iqM 3/37xmvO9WlXUxf5NFe8dcu+tEdsKu9Zzk9Sb0z0dKpE3+z5dlTk2Z2dt2ecEVzcXZOa/nTH xJuvHv7qem/4pvEx+4NJK25/5qidZ60/3Tdd3ejM7f2Hwme23+Cf9Lt3w+RgJZbijERDLeai 4kQAkKD07TkDAAA= Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Nesting Signatures and Encryption JWT Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 17:38:08 -0000 --Apple-Mail=_5EB9DD8F-3361-4525-96D3-C5B314D226A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Unless you=E2=80=99re implementing both halves with parallel wrongness, = in which case you=E2=80=99re completely screwed and have no idea. =E2=80=94 Justin > On Jul 17, 2015, at 12:38 PM, Mike Jones = wrote: >=20 > As for =E2=80=9CECDH-SS rfc6278 (being) easier for implementers to get = wrong than ECDH-ES=E2=80=9D the good news about crypto is that if you = get it even a little bit wrong, it doesn=E2=80=99t work with other=E2=80=99= s implementations at all, so this situation tends to be self-correcting. > =20 > Cheers, > -- Mike > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley > Sent: Friday, July 17, 2015 7:02 AM > To: Brian Campbell > Cc: oauth > Subject: Re: [OAUTH-WG] Nesting Signatures and Encryption JWT Tokens > =20 > They provide integrity protection for the encryption, that is very = important for preventing padding oracle attacks. > =20 > AES GCM = and = AES_CBC_HMAC_SHA2 = are = both examples of Authenticated Encryption = = in the sense that the received encryption is true and not that the = sender is identified. > =20 > English speakers have a hard time with the subtle difference between = identification and authentication , so I wanted to be clear. > =20 > That being said there is a special case where if the JWT ie encrypted = with a symmetric key known only to two parties and it is = =E2=80=9Cauthenticated=E2=80=9D and you didn=E2=80=99t create it, then = by a process of elimination it cold have only come from one party. = This is NOT a signature, however it is a useful trick that some people = use to only encrypt and while still knowing with relative certainty who = encrypted it. > =20 > I should note that ECDH-SS rfc6278 a key agreement algorithm we = didn=E2=80=99t put in the base JWA spec also has the property of = providing encryption and authenticity based on the public keys of both = sender and receiver. > (note this is easier for implementers to get wrong than ECDH-ES but = that is another debate:) > =20 > Probably more than you wanted to know, but Nat started it:) > =20 > John B. > =20 > =20 > On Jul 17, 2015, at 2:09 PM, Brian Campbell = > wrote: > =20 > Though you want to be careful with that as the asymmetric algs in JWE = don't provide authentication of the sender. > =20 > On Thu, Jul 16, 2015 at 11:26 PM, Nat Sakimura > wrote: > Hi Malla, <> > =20 > Just to add one more thing: > If you just want to =E2=80=9Csign=E2=80=9D for the sake of integrity = protection, you really do not need to do it as all the algs in JWE are = integrity protected. > =20 > -- > Nat Sakimura > > Nomura Research Institute, Ltd. > =20 > PLEASE READ: > The information contained in this e-mail is confidential and intended = for the named recipient(s) only. > If you are not an intended recipient of this e-mail, you are hereby = notified that any review, dissemination, distribution or duplication of = this message is strictly prohibited. If you have received this message = in error, please notify the sender immediately and delete your copy from = your system. > =20 > From: OAuth [mailto:oauth-bounces@ietf.org = ] On Behalf Of John Bradley > Sent: Friday, July 17, 2015 7:45 AM > To: Malla Simhachalam > > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Nesting Signatures and Encryption JWT Tokens > =20 > https://tools.ietf.org/html/rfc7519#section-11.2 = > =20 > It is in the JWT spec. You can do it both ways however you really = need a good reason not to sign then encrypt, and then after you have a = good reason you should still sign then encrypt because you probably have = not considered everything, > =20 > There are probably some edge cases that are exceptions to the rule, = but they are rare. > =20 > John B. > =20 > =20 > On Jul 16, 2015, at 11:33 PM, Malla Simhachalam = > wrote: > =20 > Hi, >=20 > I am looking at the = spechttps://datatracker.ietf.org/doc/rfc7520/?include_text=3D1 = for combining JWS and JWE use case, I could not find it = obvious that a JSON document should be signed first and then encrypt or = other way around.Are there any recommendations one over the other? >=20 > Thanks for help. > Malla > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = > =20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_5EB9DD8F-3361-4525-96D3-C5B314D226A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Unless you=E2=80=99re implementing both halves with parallel = wrongness, in which case you=E2=80=99re completely screwed and have no = idea.

 =E2=80=94 = Justin

On Jul 17, 2015, at 12:38 PM, Mike Jones = <Michael.Jones@microsoft.com> wrote:

As for =E2=80=9CECDH-SS rfc6278 = (being) easier for implementers to get wrong than ECDH-ES=E2=80=9D the good news about crypto is that if you get it even a little bit = wrong, it doesn=E2=80=99t work with other=E2=80=99s implementations at = all, so this situation tends to be self-correcting.

 

          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = Cheers,

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

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Friday, July 17, 2015 7:02 AM
To: Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] Nesting Signatures and = Encryption JWT Tokens

 

They provide integrity protection for the = encryption,  that is very important for preventing padding oracle = attacks.

 

AES GCM and AES_CBC_HMAC_SHA2 are both examples of Authenticated Encryption in the sense that the received encryption is true = and not that the sender is identified.

 

English speakers have a hard time = with the subtle difference between identification and authentication , = so I wanted to be clear.

 

That being said there is a = special case where if the JWT ie encrypted with a symmetric key known = only to two parties and it is =E2=80=9Cauthenticated=E2=80=9D and you = didn=E2=80=99t create it, then by a process of elimination it cold have = only come from one party.   This is NOT a signature,  however it is a useful trick that = some people use to only encrypt and while still knowing with relative = certainty who encrypted it.

 

I should note that ECDH-SS = rfc6278 a key agreement algorithm we didn=E2=80=99t put in the base JWA = spec also has the property of providing encryption and authenticity = based on the  public keys of both sender and receiver.

(note this is easier for = implementers to get wrong than ECDH-ES but that is another debate:)

 

Probably more than you wanted to = know, but Nat started it:)

 

John B.

 

 

On Jul 17, 2015, at 2:09 PM, = Brian Campbell <bcampbell@pingidentity.com> wrote:

 

Though you want to be careful = with that as the asymmetric algs in JWE don't provide authentication of = the sender.

 

On Thu, Jul 16, 2015 at 11:26 PM, = Nat Sakimura <n-sakimura@nri.co.jp> wrote:

Hi Malla,

 

Just to add one = more thing:

If you just want = to =E2=80=9Csign=E2=80=9D for the sake of integrity protection, you = really do not need to do it as all the algs in JWE are integrity protected. =

 

--

Nat = Sakimura <n-sakimura@nri.co.jp>

Nomura = Research Institute, Ltd.

 

PLEASE = READ:

The = information contained in this e-mail is confidential and intended for = the named recipient(s) only.

If you = are not an intended recipient of this e-mail, you are hereby notified = that any review, dissemination, distribution or duplication of this message is = strictly prohibited. If you have received this message in error, please = notify the sender immediately and delete your copy from your = system.

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Friday, July 17, 2015 7:45 AM
To: Malla Simhachalam <mallasimhachalam@gmail.com>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Nesting Signatures and = Encryption JWT Tokens

 

https://tools.ietf.org/html/rfc7519#section-11.2

 

It is in the JWT spec. =   You can do it both ways however you really need a good reason not = to sign then encrypt, and then after you have a good reason you should still sign then encrypt because you probably = have not considered everything,

 

There are probably some = edge cases that are exceptions to the rule, but they are rare.

 

John B.

 

 

On Jul 16, 2015, at 11:33 = PM, Malla Simhachalam <mallasimhachalam@gmail.com> wrote:

 

Hi,

I am looking at the spec https://datatracker.ietf.org/doc/rfc7520/?include_text=3D1 for = combining JWS and JWE use case, I could not find it obvious that a JSON = document should be signed first and then encrypt or other way around.Are = there any recommendations one over the other?

Thanks for help.

Malla

_______________________________________________
OAuth mailing list
OAuth@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=_5EB9DD8F-3361-4525-96D3-C5B314D226A3-- From nobody Fri Jul 17 10:39:00 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E39E31A1AD0 for ; Fri, 17 Jul 2015 10:38:58 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLr-hJD4AfEU for ; Fri, 17 Jul 2015 10:38:55 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0130.outbound.protection.outlook.com [65.55.169.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C63451A1A92 for ; Fri, 17 Jul 2015 10:38: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=q/sv06ZjdqhJ7JprrXFNxmTJvVoVA1etiAPfjWYguIk=; b=mQ4tghQajtdMAjQuLDEJ/yeP05Cc3reZwb4HGy1+FzXF5qk2HNSuGdxpq6fH4uz/YJtHCbob8ZXsawKD1TPes7MaixH0DLShpF39MEgkbkE6zkPmJsvmzIpgvuKs2gor5qsBRdXdoQ/XCutqKuTdKzFGXZcg01O22PPKOaohBhw= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.213.10; Fri, 17 Jul 2015 17:38:51 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0213.021; Fri, 17 Jul 2015 17:38:51 +0000 From: Mike Jones To: Justin Richer Thread-Topic: [OAUTH-WG] Nesting Signatures and Encryption JWT Tokens Thread-Index: AQHQwBd25ErrG2guLkGQKlKGrzBGN53esfAAgACBBYCAAHBrgIAADsIAgAArcDCAABDiAIAAACZQ Date: Fri, 17 Jul 2015 17:38:51 +0000 Message-ID: References: <00ba01d0c059$94379f80$bca6de80$@nri.co.jp> In-Reply-To: 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; x-originating-ip: [50.47.90.173] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:eKK0ipJOrqI7N1JTVdKea8bqPpx17W6K48/pjZtged6NdlS0nZ2NfuZ3x6fLvAEhiPAWqGLw+bbUpGDp2oh0L9OxSQH0P74HjzKuqFo+cXOb3pupsmBb/I19vWjFNdDwJ9j7JFwoUx3KvTlO0hXJPw==; 24:1PjoGcHIJyCSvnyTDbz/GxSShLtopRqPQSvQvmJWQjSSMU5hgsqLwFA/9I613aUqN+emEnDpBzCCGgiVUKr/79zC6XQePJmr2JTSkABdnYo=; 20:JgSrOqmc7BNLwk1ealaqdbGbp5m4E1mHyqW9dKeiFKPxbaHCUwjF31kHtY9to/GMmcmjvd82PGIxsGdwXmE61w== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; by2pr03mb442: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 06400060E1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(374574003)(365934003)(62966003)(106116001)(86362001)(86612001)(76176999)(93886004)(99286002)(54356999)(2656002)(19625215002)(5002640100001)(19580405001)(19580395003)(46102003)(50986999)(87936001)(189998001)(92566002)(5001960100002)(74316001)(19617315012)(110136002)(76576001)(2171001)(122556002)(102836002)(77096005)(5001920100001)(33656002)(15975445007)(77156002)(19300405004)(19609705001)(5003600100002)(2900100001)(2950100001)(16236675004); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442124786FA870CDD05C130F5980BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2015 17:38:51.6995 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Nesting Signatures and Encryption JWT Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 17:38:59 -0000 --_000_BY2PR03MB442124786FA870CDD05C130F5980BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdOKAmXMgd2hhdCB0ZXN0IHZlY3RvcnMgYW5kIGludGVyb3AgdGVzdGluZyBhcmUgZm9yIQ0K DQpGcm9tOiBKdXN0aW4gUmljaGVyIFttYWlsdG86anJpY2hlckBtaXQuZWR1XQ0KU2VudDogRnJp ZGF5LCBKdWx5IDE3LCAyMDE1IDEwOjM4IEFNDQpUbzogTWlrZSBKb25lcw0KQ2M6IEpvaG4gQnJh ZGxleTsgQnJpYW4gQ2FtcGJlbGw7IDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FV VEgtV0ddIE5lc3RpbmcgU2lnbmF0dXJlcyBhbmQgRW5jcnlwdGlvbiBKV1QgVG9rZW5zDQoNClVu bGVzcyB5b3XigJlyZSBpbXBsZW1lbnRpbmcgYm90aCBoYWx2ZXMgd2l0aCBwYXJhbGxlbCB3cm9u Z25lc3MsIGluIHdoaWNoIGNhc2UgeW914oCZcmUgY29tcGxldGVseSBzY3Jld2VkIGFuZCBoYXZl IG5vIGlkZWEuDQoNCiDigJQgSnVzdGluDQoNCk9uIEp1bCAxNywgMjAxNSwgYXQgMTI6MzggUE0s IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQoNCkFzIGZvciDigJxFQ0RILVNTIHJmYzYyNzgg KGJlaW5nKSBlYXNpZXIgZm9yIGltcGxlbWVudGVycyB0byBnZXQgd3JvbmcgdGhhbiBFQ0RILUVT 4oCdIHRoZSBnb29kIG5ld3MgYWJvdXQgY3J5cHRvIGlzIHRoYXQgaWYgeW91IGdldCBpdCBldmVu IGEgbGl0dGxlIGJpdCB3cm9uZywgaXQgZG9lc27igJl0IHdvcmsgd2l0aCBvdGhlcuKAmXMgaW1w bGVtZW50YXRpb25zIGF0IGFsbCwgc28gdGhpcyBzaXR1YXRpb24gdGVuZHMgdG8gYmUgc2VsZi1j b3JyZWN0aW5nLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBDaGVlcnMsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IE9BdXRoIFttYWls dG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvaG4gQnJhZGxleQ0KU2Vu dDogRnJpZGF5LCBKdWx5IDE3LCAyMDE1IDc6MDIgQU0NClRvOiBCcmlhbiBDYW1wYmVsbA0KQ2M6 IG9hdXRoDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBOZXN0aW5nIFNpZ25hdHVyZXMgYW5kIEVu Y3J5cHRpb24gSldUIFRva2Vucw0KDQpUaGV5IHByb3ZpZGUgaW50ZWdyaXR5IHByb3RlY3Rpb24g Zm9yIHRoZSBlbmNyeXB0aW9uLCAgdGhhdCBpcyB2ZXJ5IGltcG9ydGFudCBmb3IgcHJldmVudGlu ZyBwYWRkaW5nIG9yYWNsZSBhdHRhY2tzLg0KDQpBRVMgR0NNPGh0dHBzOi8vbmEwMS5zYWZlbGlu a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmdG9vbHMuaWV0Zi5v cmclMmZodG1sJTJmcmZjNzUxOCUyM3NlY3Rpb24tNS4zJmRhdGE9MDElN2MwMSU3Y01pY2hhZWwu Sm9uZXMlNDBtaWNyb3NvZnQuY29tJTdjNWJjOWVkYTBlOGRhNDk0ZTExYmIwOGQyOGViMDUxOWYl N2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9S200bHJZSHVGU21J dllPTnRpdXNGb1pFdFNSb0FqNFJpOHVkSW9pQTVOayUzZD4gYW5kIEFFU19DQkNfSE1BQ19TSEEy PGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz JTNhJTJmJTJmdG9vbHMuaWV0Zi5vcmclMmZodG1sJTJmcmZjNzUxOCUyM3NlY3Rpb24tNS4yJmRh dGE9MDElN2MwMSU3Y01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdjNWJjOWVkYTBlOGRh NDk0ZTExYmIwOGQyOGViMDUxOWYlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3 YzEmc2RhdGE9SWFROWhZTjRMdzViVlRYUmNTd05pNFJ6S25vaklLQUFJZHRmNTNKREJ2RSUzZD4g YXJlIGJvdGggZXhhbXBsZXMgb2YgQXV0aGVudGljYXRlZCBFbmNyeXB0aW9uPGh0dHBzOi8vbmEw MS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmZW4u d2lraXBlZGlhLm9yZyUyZndpa2klMmZBdXRoZW50aWNhdGVkX2VuY3J5cHRpb24mZGF0YT0wMSU3 YzAxJTdjTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN2M1YmM5ZWRhMGU4ZGE0OTRlMTFi YjA4ZDI4ZWIwNTE5ZiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0 YT1lUlY1eGdmMTdJV3l6MGo1UXdnRG11YkR3NXJxSm5lTWFZdENIdTFDTFZzJTNkPiBpbiB0aGUg c2Vuc2UgdGhhdCB0aGUgcmVjZWl2ZWQgZW5jcnlwdGlvbiBpcyB0cnVlIGFuZCBub3QgdGhhdCB0 aGUgc2VuZGVyIGlzIGlkZW50aWZpZWQuDQoNCkVuZ2xpc2ggc3BlYWtlcnMgaGF2ZSBhIGhhcmQg dGltZSB3aXRoIHRoZSBzdWJ0bGUgZGlmZmVyZW5jZSBiZXR3ZWVuIGlkZW50aWZpY2F0aW9uIGFu ZCBhdXRoZW50aWNhdGlvbiAsIHNvIEkgd2FudGVkIHRvIGJlIGNsZWFyLg0KDQpUaGF0IGJlaW5n IHNhaWQgdGhlcmUgaXMgYSBzcGVjaWFsIGNhc2Ugd2hlcmUgaWYgdGhlIEpXVCBpZSBlbmNyeXB0 ZWQgd2l0aCBhIHN5bW1ldHJpYyBrZXkga25vd24gb25seSB0byB0d28gcGFydGllcyBhbmQgaXQg aXMg4oCcYXV0aGVudGljYXRlZOKAnSBhbmQgeW91IGRpZG7igJl0IGNyZWF0ZSBpdCwgdGhlbiBi eSBhIHByb2Nlc3Mgb2YgZWxpbWluYXRpb24gaXQgY29sZCBoYXZlIG9ubHkgY29tZSBmcm9tIG9u ZSBwYXJ0eS4gICBUaGlzIGlzIE5PVCBhIHNpZ25hdHVyZSwgIGhvd2V2ZXIgaXQgaXMgYSB1c2Vm dWwgdHJpY2sgdGhhdCBzb21lIHBlb3BsZSB1c2UgdG8gb25seSBlbmNyeXB0IGFuZCB3aGlsZSBz dGlsbCBrbm93aW5nIHdpdGggcmVsYXRpdmUgY2VydGFpbnR5IHdobyBlbmNyeXB0ZWQgaXQuDQoN Ckkgc2hvdWxkIG5vdGUgdGhhdCBFQ0RILVNTIHJmYzYyNzggYSBrZXkgYWdyZWVtZW50IGFsZ29y aXRobSB3ZSBkaWRu4oCZdCBwdXQgaW4gdGhlIGJhc2UgSldBIHNwZWMgYWxzbyBoYXMgdGhlIHBy b3BlcnR5IG9mIHByb3ZpZGluZyBlbmNyeXB0aW9uIGFuZCBhdXRoZW50aWNpdHkgYmFzZWQgb24g dGhlICBwdWJsaWMga2V5cyBvZiBib3RoIHNlbmRlciBhbmQgcmVjZWl2ZXIuDQoobm90ZSB0aGlz IGlzIGVhc2llciBmb3IgaW1wbGVtZW50ZXJzIHRvIGdldCB3cm9uZyB0aGFuIEVDREgtRVMgYnV0 IHRoYXQgaXMgYW5vdGhlciBkZWJhdGU6KQ0KDQpQcm9iYWJseSBtb3JlIHRoYW4geW91IHdhbnRl ZCB0byBrbm93LCBidXQgTmF0IHN0YXJ0ZWQgaXQ6KQ0KDQpKb2huIEIuDQoNCg0KT24gSnVsIDE3 LCAyMDE1LCBhdCAyOjA5IFBNLCBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0 eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPj4gd3JvdGU6DQoNClRob3Vn aCB5b3Ugd2FudCB0byBiZSBjYXJlZnVsIHdpdGggdGhhdCBhcyB0aGUgYXN5bW1ldHJpYyBhbGdz IGluIEpXRSBkb24ndCBwcm92aWRlIGF1dGhlbnRpY2F0aW9uIG9mIHRoZSBzZW5kZXIuDQoNCk9u IFRodSwgSnVsIDE2LCAyMDE1IGF0IDExOjI2IFBNLCBOYXQgU2FraW11cmEgPG4tc2FraW11cmFA bnJpLmNvLmpwPG1haWx0bzpuLXNha2ltdXJhQG5yaS5jby5qcD4+IHdyb3RlOg0KSGkgTWFsbGEs DQoNCkp1c3QgdG8gYWRkIG9uZSBtb3JlIHRoaW5nOg0KSWYgeW91IGp1c3Qgd2FudCB0byDigJxz aWdu4oCdIGZvciB0aGUgc2FrZSBvZiBpbnRlZ3JpdHkgcHJvdGVjdGlvbiwgeW91IHJlYWxseSBk byBub3QgbmVlZCB0byBkbyBpdCBhcyBhbGwgdGhlIGFsZ3MgaW4gSldFIGFyZSBpbnRlZ3JpdHkg cHJvdGVjdGVkLg0KDQotLQ0KTmF0IFNha2ltdXJhIDxuLXNha2ltdXJhQG5yaS5jby5qcDxtYWls dG86bi1zYWtpbXVyYUBucmkuY28uanA+Pg0KTm9tdXJhIFJlc2VhcmNoIEluc3RpdHV0ZSwgTHRk Lg0KDQpQTEVBU0UgUkVBRDoNClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1h aWwgaXMgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBmb3IgdGhlIG5hbWVkIHJlY2lwaWVudChz KSBvbmx5Lg0KSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgZS1t YWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSByZXZpZXcsIGRpc3NlbWluYXRp b24sIGRpc3RyaWJ1dGlvbiBvciBkdXBsaWNhdGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgc3RyaWN0 bHkgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9y LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB5b3VyIGNv cHkgZnJvbSB5b3VyIHN5c3RlbS4NCg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEpv aG4gQnJhZGxleQ0KU2VudDogRnJpZGF5LCBKdWx5IDE3LCAyMDE1IDc6NDUgQU0NClRvOiBNYWxs YSBTaW1oYWNoYWxhbSA8bWFsbGFzaW1oYWNoYWxhbUBnbWFpbC5jb208bWFpbHRvOm1hbGxhc2lt aGFjaGFsYW1AZ21haWwuY29tPj4NCkNjOiBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBOZXN0aW5nIFNpZ25hdHVyZXMgYW5kIEVu Y3J5cHRpb24gSldUIFRva2Vucw0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzUx OSNzZWN0aW9uLTExLjI8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cHMlM2ElMmYlMmZ0b29scy5pZXRmLm9yZyUyZmh0bWwlMmZyZmM3NTE5JTIz c2VjdGlvbi0xMS4yJmRhdGE9MDElN2MwMSU3Y01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29t JTdjNWJjOWVkYTBlOGRhNDk0ZTExYmIwOGQyOGViMDUxOWYlN2M3MmY5ODhiZjg2ZjE0MWFmOTFh YjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9YkpqVWE5SCUyZmhzb1FHZmptWkVCUUl5WXh3Wk5jNUhs dCUyYkR6ckVqJTJiSEc3MCUzZD4NCg0KSXQgaXMgaW4gdGhlIEpXVCBzcGVjLiAgIFlvdSBjYW4g ZG8gaXQgYm90aCB3YXlzIGhvd2V2ZXIgeW91IHJlYWxseSBuZWVkIGEgZ29vZCByZWFzb24gbm90 IHRvIHNpZ24gdGhlbiBlbmNyeXB0LCBhbmQgdGhlbiBhZnRlciB5b3UgaGF2ZSBhIGdvb2QgcmVh c29uIHlvdSBzaG91bGQgc3RpbGwgc2lnbiB0aGVuIGVuY3J5cHQgYmVjYXVzZSB5b3UgcHJvYmFi bHkgaGF2ZSBub3QgY29uc2lkZXJlZCBldmVyeXRoaW5nLA0KDQpUaGVyZSBhcmUgcHJvYmFibHkg c29tZSBlZGdlIGNhc2VzIHRoYXQgYXJlIGV4Y2VwdGlvbnMgdG8gdGhlIHJ1bGUsIGJ1dCB0aGV5 IGFyZSByYXJlLg0KDQpKb2huIEIuDQoNCg0KT24gSnVsIDE2LCAyMDE1LCBhdCAxMTozMyBQTSwg TWFsbGEgU2ltaGFjaGFsYW0gPG1hbGxhc2ltaGFjaGFsYW1AZ21haWwuY29tPG1haWx0bzptYWxs YXNpbWhhY2hhbGFtQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpIaSwNCkkgYW0gbG9va2luZyBhdCB0 aGUgc3BlYyBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9yZmM3NTIwLz9pbmNsdWRl X3RleHQ9MTxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwcyUzYSUyZiUyZmRhdGF0cmFja2VyLmlldGYub3JnJTJmZG9jJTJmcmZjNzUyMCUyZiUz ZmluY2x1ZGVfdGV4dCUzZDEmZGF0YT0wMSU3YzAxJTdjTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29m dC5jb20lN2M1YmM5ZWRhMGU4ZGE0OTRlMTFiYjA4ZDI4ZWIwNTE5ZiU3YzcyZjk4OGJmODZmMTQx YWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT05WDNhdXlTbkw0WGxUJTJmUlclMmJBT2FCRzV3 WDhqck5jODJBWjBHbyUyYlpJcnVNJTNkPiBmb3IgY29tYmluaW5nIEpXUyBhbmQgSldFIHVzZSBj YXNlLCBJIGNvdWxkIG5vdCBmaW5kIGl0IG9idmlvdXMgdGhhdCBhIEpTT04gZG9jdW1lbnQgc2hv dWxkIGJlIHNpZ25lZCBmaXJzdCBhbmQgdGhlbiBlbmNyeXB0IG9yIG90aGVyIHdheSBhcm91bmQu QXJlIHRoZXJlIGFueSByZWNvbW1lbmRhdGlvbnMgb25lIG92ZXIgdGhlIG90aGVyPw0KVGhhbmtz IGZvciBoZWxwLg0KTWFsbGENCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0 aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8 aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZkYXRhPTAx JTdjMDElN2NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3YzViYzllZGEwZThkYTQ5NGUx MWJiMDhkMjhlYjA1MTlmJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNk YXRhPWxkT25TYW5RRVA2WU9vSGRkMzZVcjZiV0VuUWdhJTJmSU5sVExBeDRCT0VlcyUzZD4NCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGgg bWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0dHBzOi8vbmEwMS5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYu b3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmZGF0YT0wMSU3YzAxJTdjTWljaGFlbC5K b25lcyU0MG1pY3Jvc29mdC5jb20lN2M1YmM5ZWRhMGU4ZGE0OTRlMTFiYjA4ZDI4ZWIwNTE5ZiU3 YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1sZE9uU2FuUUVQNllP b0hkZDM2VXI2YldFblFnYSUyZklObFRMQXg0Qk9FZXMlM2Q+DQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1 dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo= --_000_BY2PR03MB442124786FA870CDD05C130F5980BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4 IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEBNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUs IGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4 dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1h aWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGF04oCZcyB3aGF0IHRlc3QgdmVjdG9ycyBh bmQgaW50ZXJvcCB0ZXN0aW5nIGFyZSBmb3IhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSnVzdGluIFJp Y2hlciBbbWFpbHRvOmpyaWNoZXJAbWl0LmVkdV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXks IEp1bHkgMTcsIDIwMTUgMTA6MzggQU08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXM8YnI+DQo8 Yj5DYzo8L2I+IEpvaG4gQnJhZGxleTsgQnJpYW4gQ2FtcGJlbGw7ICZsdDtvYXV0aEBpZXRmLm9y ZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gTmVzdGluZyBTaWduYXR1 cmVzIGFuZCBFbmNyeXB0aW9uIEpXVCBUb2tlbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Vbmxlc3MgeW914oCZcmUgaW1wbGVtZW50aW5nIGJvdGggaGFs dmVzIHdpdGggcGFyYWxsZWwgd3JvbmduZXNzLCBpbiB3aGljaCBjYXNlIHlvdeKAmXJlIGNvbXBs ZXRlbHkgc2NyZXdlZCBhbmQgaGF2ZSBubyBpZGVhLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A74oCUIEp1c3RpbjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gSnVsIDE3LCAyMDE1LCBhdCAx MjozOCBQTSwgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWlj cm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXMgZm9yIOKAnDwvc3Bhbj5FQ0RILVNTIHJm YzYyNzggKGJlaW5nKSBlYXNpZXIgZm9yIGltcGxlbWVudGVycyB0byBnZXQgd3JvbmcgdGhhbiBF Q0RILUVTPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnQ0KIHRo ZSBnb29kIG5ld3MgYWJvdXQgY3J5cHRvIGlzIHRoYXQgaWYgeW91IGdldCBpdCBldmVuIGEgbGl0 dGxlIGJpdCB3cm9uZywgaXQgZG9lc27igJl0IHdvcmsgd2l0aCBvdGhlcuKAmXMgaW1wbGVtZW50 YXRpb25zIGF0IGFsbCwgc28gdGhpcyBzaXR1YXRpb24gdGVuZHMgdG8gYmUgc2VsZi1jb3JyZWN0 aW5nLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENoZWVycyw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBPQXV0aCBb PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpvYXV0aC1ib3Vu Y2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Sm9obiBCcmFkbGV5PGJyPg0K PGI+U2VudDo8L2I+IEZyaWRheSwgSnVseSAxNywgMjAxNSA3OjAyIEFNPGJyPg0KPGI+VG86PC9i PiBCcmlhbiBDYW1wYmVsbDxicj4NCjxiPkNjOjwvYj4gb2F1dGg8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtPQVVUSC1XR10gTmVzdGluZyBTaWduYXR1cmVzIGFuZCBFbmNyeXB0aW9uIEpXVCBU b2tlbnM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGV5 IHByb3ZpZGUgaW50ZWdyaXR5IHByb3RlY3Rpb24gZm9yIHRoZSBlbmNyeXB0aW9uLCAmbmJzcDt0 aGF0IGlzIHZlcnkgaW1wb3J0YW50IGZvciBwcmV2ZW50aW5nIHBhZGRpbmcgb3JhY2xlIGF0dGFj a3MuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVm PSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw cyUzYSUyZiUyZnRvb2xzLmlldGYub3JnJTJmaHRtbCUyZnJmYzc1MTglMjNzZWN0aW9uLTUuMyZh bXA7ZGF0YT0wMSU3YzAxJTdjTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN2M1YmM5ZWRh MGU4ZGE0OTRlMTFiYjA4ZDI4ZWIwNTE5ZiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFk YjQ3JTdjMSZhbXA7c2RhdGE9S200bHJZSHVGU21JdllPTnRpdXNGb1pFdFNSb0FqNFJpOHVkSW9p QTVOayUzZCI+QUVTDQogR0NNPC9hPiZuYnNwO2FuZCZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vbmEw MS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmdG9v bHMuaWV0Zi5vcmclMmZodG1sJTJmcmZjNzUxOCUyM3NlY3Rpb24tNS4yJmFtcDtkYXRhPTAxJTdj MDElN2NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3YzViYzllZGEwZThkYTQ5NGUxMWJi MDhkMjhlYjA1MTlmJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtz ZGF0YT1JYVE5aFlONEx3NWJWVFhSY1N3Tmk0UnpLbm9qSUtBQUlkdGY1M0pEQnZFJTNkIj5BRVNf Q0JDX0hNQUNfU0hBMjwvYT4mbmJzcDthcmUNCiBib3RoIGV4YW1wbGVzIG9mJm5ic3A7PGEgaHJl Zj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0 cHMlM2ElMmYlMmZlbi53aWtpcGVkaWEub3JnJTJmd2lraSUyZkF1dGhlbnRpY2F0ZWRfZW5jcnlw dGlvbiZhbXA7ZGF0YT0wMSU3YzAxJTdjTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN2M1 YmM5ZWRhMGU4ZGE0OTRlMTFiYjA4ZDI4ZWIwNTE5ZiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3 Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9ZVJWNXhnZjE3SVd5ejBqNVF3Z0RtdWJEdzVycUpuZU1h WXRDSHUxQ0xWcyUzZCI+QXV0aGVudGljYXRlZA0KIEVuY3J5cHRpb248L2E+Jm5ic3A7aW4gdGhl IHNlbnNlIHRoYXQgdGhlIHJlY2VpdmVkIGVuY3J5cHRpb24gaXMgdHJ1ZSBhbmQgbm90IHRoYXQg dGhlIHNlbmRlciBpcyBpZGVudGlmaWVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FbmdsaXNoIHNwZWFrZXJzIGhhdmUgYSBoYXJkIHRpbWUg d2l0aCB0aGUgc3VidGxlIGRpZmZlcmVuY2UgYmV0d2VlbiBpZGVudGlmaWNhdGlvbiBhbmQgYXV0 aGVudGljYXRpb24gLCBzbyBJIHdhbnRlZCB0byBiZSBjbGVhci48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCBiZWluZyBzYWlkIHRoZXJl IGlzIGEgc3BlY2lhbCBjYXNlIHdoZXJlIGlmIHRoZSBKV1QgaWUgZW5jcnlwdGVkIHdpdGggYSBz eW1tZXRyaWMga2V5IGtub3duIG9ubHkgdG8gdHdvIHBhcnRpZXMgYW5kIGl0IGlzIOKAnGF1dGhl bnRpY2F0ZWTigJ0gYW5kIHlvdSBkaWRu4oCZdCBjcmVhdGUgaXQsIHRoZW4gYnkgYSBwcm9jZXNz IG9mIGVsaW1pbmF0aW9uIGl0IGNvbGQgaGF2ZSBvbmx5IGNvbWUgZnJvbSBvbmUgcGFydHkuDQog Jm5ic3A7IFRoaXMgaXMgTk9UIGEgc2lnbmF0dXJlLCAmbmJzcDtob3dldmVyIGl0IGlzIGEgdXNl ZnVsIHRyaWNrIHRoYXQgc29tZSBwZW9wbGUgdXNlIHRvIG9ubHkgZW5jcnlwdCBhbmQgd2hpbGUg c3RpbGwga25vd2luZyB3aXRoIHJlbGF0aXZlIGNlcnRhaW50eSB3aG8gZW5jcnlwdGVkIGl0Ljxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHNo b3VsZCBub3RlIHRoYXQgRUNESC1TUyByZmM2Mjc4IGEga2V5IGFncmVlbWVudCBhbGdvcml0aG0g d2UgZGlkbuKAmXQgcHV0IGluIHRoZSBiYXNlIEpXQSBzcGVjIGFsc28gaGFzIHRoZSBwcm9wZXJ0 eSBvZiBwcm92aWRpbmcgZW5jcnlwdGlvbiBhbmQgYXV0aGVudGljaXR5IGJhc2VkIG9uIHRoZSAm bmJzcDtwdWJsaWMga2V5cyBvZiBib3RoIHNlbmRlciBhbmQgcmVjZWl2ZXIuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4obm90ZSB0aGlzIGlzIGVh c2llciBmb3IgaW1wbGVtZW50ZXJzIHRvIGdldCB3cm9uZyB0aGFuIEVDREgtRVMgYnV0IHRoYXQg aXMgYW5vdGhlciBkZWJhdGU6KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Qcm9iYWJseSBtb3JlIHRoYW4geW91IHdhbnRlZCB0byBrbm93LCBi dXQgTmF0IHN0YXJ0ZWQgaXQ6KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Kb2huIEIuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEp1bCAxNywgMjAxNSwgYXQgMjowOSBQTSwgQnJp YW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNv bSI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRob3VnaCB5b3Ugd2FudCB0byBiZSBj YXJlZnVsIHdpdGggdGhhdCBhcyB0aGUgYXN5bW1ldHJpYyBhbGdzIGluIEpXRSBkb24ndCBwcm92 aWRlIGF1dGhlbnRpY2F0aW9uIG9mIHRoZSBzZW5kZXIuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgSnVsIDE2LCAyMDE1IGF0IDExOjI2IFBN LCBOYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpuLXNha2ltdXJhQG5yaS5jby5qcCIg dGFyZ2V0PSJfYmxhbmsiPm4tc2FraW11cmFAbnJpLmNvLmpwPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgbmFtZT0i MTRlOWFiMjI1ZDFhZTg5ZF9fTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpKQSI+SGkgTWFsbGEsDQo8L3Nw YW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SkEiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkpB Ij5KdXN0IHRvIGFkZCBvbmUgbW9yZSB0aGluZzoNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkpBIj5JZiB5b3UganVzdCB3YW50IHRvIOKAnHNpZ27i gJ0gZm9yIHRoZSBzYWtlIG9mIGludGVncml0eSBwcm90ZWN0aW9uLCB5b3UgcmVhbGx5DQogZG8g bm90IG5lZWQgdG8gZG8gaXQgYXMgYWxsIHRoZSBhbGdzIGluIEpXRSBhcmUgaW50ZWdyaXR5IHBy b3RlY3RlZC4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6SkEiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O01TIEdvdGhpYyZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkpBIj4t LQ0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpKQSI+TmF0IFNha2ltdXJhICZsdDs8 L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkpBIj48YSBocmVmPSJtYWls dG86bi1zYWtpbXVyYUBucmkuY28uanAiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7Y29sb3I6IzA1 NjNDMSI+bi1zYWtpbXVyYUBucmkuY28uanA8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpKQSI+Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6SkEiPk5vbXVyYSBSZXNlYXJjaCBJbnN0aXR1dGUsIEx0ZC4NCjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SkEiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpKQSI+UExFQVNFIFJFQUQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O01TIEdvdGhpYyZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkpB Ij5UaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgZS1tYWlsIGlzIGNvbmZpZGVudGlh bCBhbmQgaW50ZW5kZWQgZm9yIHRoZSBuYW1lZCByZWNpcGllbnQocykNCiBvbmx5Ljwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpKQSI+SWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVj aXBpZW50IG9mIHRoaXMgZS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueQ0K IHJldmlldywgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uIG9yIGR1cGxpY2F0aW9uIG9mIHRo aXMgbWVzc2FnZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVs eSBhbmQgZGVsZXRlIHlvdXIgY29weSBmcm9tIHlvdXIgc3lzdGVtLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SkEiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SkEiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SkEiPg0K IE9BdXRoIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+Sm9obiBCcmFkbGV5PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgSnVseSAxNywgMjAx NSA3OjQ1IEFNPGJyPg0KPGI+VG86PC9iPiBNYWxsYSBTaW1oYWNoYWxhbSAmbHQ7PGEgaHJlZj0i bWFpbHRvOm1hbGxhc2ltaGFjaGFsYW1AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFsbGFz aW1oYWNoYWxhbUBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFp bHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIE5lc3RpbmcgU2lnbmF0dXJlcyBhbmQg RW5jcnlwdGlvbiBKV1QgVG9rZW5zPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6SkEiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkpBIj48 YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwcyUzYSUyZiUyZnRvb2xzLmlldGYub3JnJTJmaHRtbCUyZnJmYzc1MTklMjNzZWN0aW9u LTExLjImYW1wO2RhdGE9MDElN2MwMSU3Y01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdj NWJjOWVkYTBlOGRhNDk0ZTExYmIwOGQyOGViMDUxOWYlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk N2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPWJKalVhOUglMmZoc29RR2ZqbVpFQlFJeVl4d1pOYzVI bHQlMmJEenJFaiUyYkhHNzAlM2QiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjNzUxOSNzZWN0aW9uLTExLjI8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOkpBIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpK QSI+SXQgaXMgaW4gdGhlIEpXVCBzcGVjLiAmbmJzcDsgWW91IGNhbiBkbyBpdCBib3RoIHdheXMg aG93ZXZlciB5b3UgcmVhbGx5IG5lZWQgYSBnb29kIHJlYXNvbiBub3QgdG8gc2lnbiB0aGVuIGVu Y3J5cHQsIGFuZCB0aGVuIGFmdGVyIHlvdSBoYXZlIGENCiBnb29kIHJlYXNvbiB5b3Ugc2hvdWxk IHN0aWxsIHNpZ24gdGhlbiBlbmNyeXB0IGJlY2F1c2UgeW91IHByb2JhYmx5IGhhdmUgbm90IGNv bnNpZGVyZWQgZXZlcnl0aGluZyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpKQSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SkEiPlRo ZXJlIGFyZSBwcm9iYWJseSBzb21lIGVkZ2UgY2FzZXMgdGhhdCBhcmUgZXhjZXB0aW9ucyB0byB0 aGUgcnVsZSwgYnV0IHRoZXkgYXJlIHJhcmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6SkEiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkpBIj5Kb2huIEIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SkEiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkpBIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SkEiPk9uIEp1bCAxNiwgMjAxNSwg YXQgMTE6MzMgUE0sIE1hbGxhIFNpbWhhY2hhbGFtICZsdDs8YSBocmVmPSJtYWlsdG86bWFsbGFz aW1oYWNoYWxhbUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWxsYXNpbWhhY2hhbGFtQGdt YWlsLmNvbTwvYT4mZ3Q7DQogd3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpK QSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpKQSI+SGksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4w cHQiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpKQSI+SSBhbSBsb29raW5nIGF0 IHRoZSBzcGVjDQo8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0 bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZmRhdGF0cmFja2VyLmlldGYub3JnJTJmZG9jJTJm cmZjNzUyMCUyZiUzZmluY2x1ZGVfdGV4dCUzZDEmYW1wO2RhdGE9MDElN2MwMSU3Y01pY2hhZWwu Sm9uZXMlNDBtaWNyb3NvZnQuY29tJTdjNWJjOWVkYTBlOGRhNDk0ZTExYmIwOGQyOGViMDUxOWYl N2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPTlYM2F1eVNu TDRYbFQlMmZSVyUyYkFPYUJHNXdYOGpyTmM4MkFaMEdvJTJiWklydU0lM2QiIHRhcmdldD0iX2Js YW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3JmYzc1MjAvP2luY2x1ZGVf dGV4dD0xPC9hPiBmb3IgY29tYmluaW5nIEpXUyBhbmQgSldFIHVzZSBjYXNlLCBJIGNvdWxkIG5v dCBmaW5kIGl0IG9idmlvdXMgdGhhdCBhIEpTT04gZG9jdW1lbnQgc2hvdWxkIGJlIHNpZ25lZCBm aXJzdCBhbmQgdGhlbiBlbmNyeXB0IG9yIG90aGVyIHdheSBhcm91bmQuQXJlIHRoZXJlIGFueSBy ZWNvbW1lbmRhdGlvbnMgb25lIG92ZXIgdGhlIG90aGVyPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6SkEiPlRoYW5rcyBmb3IgaGVscC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkpBIj5NYWxsYTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SkEiPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmcl MmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZhbXA7ZGF0YT0wMSU3YzAxJTdjTWljaGFlbC5K b25lcyU0MG1pY3Jvc29mdC5jb20lN2M1YmM5ZWRhMGU4ZGE0OTRlMTFiYjA4ZDI4ZWIwNTE5ZiU3 YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9bGRPblNhblFF UDZZT29IZGQzNlVyNmJXRW5RZ2ElMmZJTmxUTEF4NEJPRWVzJTNkIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SkEiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0 Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYu b3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmYW1wO2RhdGE9MDElN2MwMSU3Y01pY2hh ZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdjNWJjOWVkYTBlOGRhNDk0ZTExYmIwOGQyOGViMDUx OWYlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPWxkT25T YW5RRVA2WU9vSGRkMzZVcjZiV0VuUWdhJTJmSU5sVExBeDRCT0VlcyUzZCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0 Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BY2PR03MB442124786FA870CDD05C130F5980BY2PR03MB442namprd_-- From nobody Fri Jul 17 11:25:26 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE02B1AD0BB for ; Fri, 17 Jul 2015 11:25: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ns8nLLBQi_GD for ; Fri, 17 Jul 2015 11:25:19 -0700 (PDT) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2B961A01F0 for ; Fri, 17 Jul 2015 11:25:18 -0700 (PDT) Received: by wgmn9 with SMTP id n9so88349673wgm.0 for ; Fri, 17 Jul 2015 11:25:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Op7teJ+gfgMN+sOaSDugALiLTaLknPw/mp2P30mb4Fs=; b=Wr4je9I/CMZFlbWUp954eAXvKV8BgUonKddyk9DlTHkHj/sUvSwZzQkpwp1Ip20GLm Fm3NIDgucDYZcMrox4zNK9Uoo3FoAGo+1u419gLY3hWK2U/FOsJWs+zJTyw5WZXsMBpW A9WgAYZatYqcvbU+2KMzHyZqjtlsIsdKnOW93hvf8yb/oQ1Hjpl0F+JHFQAscT4jaTox gaZhgN+nMoKKr12donhQ5AOCt+OWULTG4iLle0of7JYYRoZOSPIQ+Tt6IQL1LF2lWBEa Yy4+lH6GPcq66LRPcdvyCLO0wlqgkgIatdXetuFJHztqzNb7zcn2EhNnMgPBD+2gM2D/ +3IA== X-Gm-Message-State: ALoCoQkfVCx8tMR/THKJw3WbqOUWKYTaFxt+aKFZDEW1q5JkHAAdq3xdO5fqLYCCy3SKW/HKH68T X-Received: by 10.181.11.229 with SMTP id el5mr19211100wid.40.1437157517469; Fri, 17 Jul 2015 11:25:17 -0700 (PDT) Received: from [10.207.197.245] (host86-187-118-217.range86-187.btcentralplus.com. [86.187.118.217]) by smtp.gmail.com with ESMTPSA id r19sm9561259wib.7.2015.07.17.11.25.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Jul 2015 11:25:15 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_7BBEC4B3-3FF7-4934-9B87-9D3AFDBD1070"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: John Bradley In-Reply-To: Date: Fri, 17 Jul 2015 19:25:10 +0100 Message-Id: References: <00ba01d0c059$94379f80$bca6de80$@nri.co.jp> To: Michael Jones X-Mailer: Apple Mail (2.2102) Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] Nesting Signatures and Encryption JWT Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 18:25:25 -0000 --Apple-Mail=_7BBEC4B3-3FF7-4934-9B87-9D3AFDBD1070 Content-Type: multipart/alternative; boundary="Apple-Mail=_BB5E3540-7CD9-49F1-A0DA-DE980DFE10D2" --Apple-Mail=_BB5E3540-7CD9-49F1-A0DA-DE980DFE10D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 No the issue is the entropy that needs to be added in SS because you are = not using a different ephemeral key each time. =20 The security considerations covers it. There is also the case where = you are encrypting to multiple recipients that breaks sender = identification. We taled about including SS and EE, but decided to keep the alg set = limited to the ones people are most likely to be deployed. =20 In IoT with small messages SS may have desirable properties, however no = one has asked for it yet. I was just noting that it is one way to do it but has some real security = considerations that would need addressing. John B. Extreme care must be used when using static-static Diffie-Hellman (either standard or cofactor) without the use of some per-message value in the ukm. As described in [RFC5753 = ], the ukm value (if present) will be embedded in an ECC-CMS-SharedInfo structure, and the DER encoding of this structure will be used as the 'SharedInfo' input to the key-derivation function of [X963 = ]. The purpose of this = input is to add a message-unique value to the key-distribution function so that two different sessions of static-static ECDH between a given pair of agents result in independent keys. If the ukm value is not used or is re-used, on the other hand, then the ECC-CMS-SharedInfo structure (and 'SharedInfo' input) will likely not vary from message to message. In this case, the two agents will re-use the same keying material across multiple messages. This is considered to be bad cryptographic practice and may open the sender to attacks on Diffie- Hellman (e.g., the 'small subgroup' attack [MenezesUstaoglu = ] or other, yet-undiscovered attacks). It is for these reasons that Section 2.1 = states that message = senders SHOULD include the ukm and SHOULD ensure that the value of ukm is unique to the message being sent. One way to ensure the uniqueness of the ukm is for the message sender to choose a 'sufficiently long' random string for each message (where, as a rule of thumb, a 'sufficiently long' string is one at least as long as the keys used by the key-wrap algorithm identified in the keyEncryptionAlgorithm field of the KeyAgreeRecipientInfo structure). However, other methods (such as a counter) are possible. Also, applications that cannot tolerate the inclusion of per-message information in the ukm (due to bandwidth requirements, for example) SHOULD NOT use static- static ECDH for a recipient without ascertaining that the recipient knows the private value associated with their certified Diffie- Hellman value. Static-static Diffie-Hellman, when used as described in this document, does not necessarily provide data-origin authentication. Consider, for example, the following sequence of events: Herzog & Khazan Informational [Page 12] RFC 6278 = Static-Static ECDH in CMS June 2011 o Alice sends an AuthEnvelopedData message to both Bob and Mallory. Furthermore, Alice uses a static-static DH method to transport the content-authenticated-encryption key to Bob, and some arbitrary method to transport the same key to Mallory. o Mallory intercepts the message and prevents Bob from receiving it. o Mallory recovers the content-authenticated-encryption key from the message received from Alice. Mallory then creates new plaintext of her choice, and encrypts it using the same authenticated- encryption algorithm and the same content-authenticated-encryption key used by Alice. o Mallory then replaces the EncryptedContentInfo and MessageAuthenticationCode fields of Alice's message with the values Mallory just generated. She may additionally remove her RecipientInfo value from Alice's message. o Mallory sends the modified message to Bob. o Bob receives the message, validates the static-static DH values, and decrypts/authenticates the message. At this point, Bob has received and validated a message that appears to have been sent by Alice, but whose content was chosen by Mallory. Mallory may not even be an apparent receiver of the modified message. Thus, this use of static-static Diffie-Hellman does not necessarily provide data-origin authentication. (We note that this example does not also contradict either confidentiality or data authentication: Alice's message was not received by anyone not intended by Alice, and Mallory's message was not modified before reaching Bob.) More generally, the data origin may not be authenticated unless: o it is a priori guaranteed that the message in question was sent to exactly one recipient, or o data-origin authentication is provided by some other mechanism (such as digital signatures). However, we also note that this lack of authentication is not a product of static-static ECDH per se, but is inherent in the way key- agreement schemes are used in the AuthenticatedData and AuthEnvelopedData structures of the CMS. When two parties are communicating using static-static ECDH as described in this document, and either party's asymmetric keys have been centrally generated, it is possible for that party's central Herzog & Khazan Informational [Page 13] RFC 6278 = Static-Static ECDH in CMS June 2011 infrastructure to decrypt the communication (for application-layer network monitoring or filtering, for example). By way of contrast: were ephemeral-static ECDH to be used instead, such decryption by the sender's infrastructure would not be possible (though it would remain possible for the infrastructure of any recipient). > On Jul 17, 2015, at 5:38 PM, Mike Jones = wrote: >=20 > As for =E2=80=9CECDH-SS rfc6278 (being) easier for implementers to get = wrong than ECDH-ES=E2=80=9D the good news about crypto is that if you = get it even a little bit wrong, it doesn=E2=80=99t work with other=E2=80=99= s implementations at all, so this situation tends to be self-correcting. > =20 > Cheers, > -- Mike > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley > Sent: Friday, July 17, 2015 7:02 AM > To: Brian Campbell > Cc: oauth > Subject: Re: [OAUTH-WG] Nesting Signatures and Encryption JWT Tokens > =20 > They provide integrity protection for the encryption, that is very = important for preventing padding oracle attacks. > =20 > AES GCM = and = AES_CBC_HMAC_SHA2 = are = both examples of Authenticated Encryption = = in the sense that the received encryption is true and not that the = sender is identified. > =20 > English speakers have a hard time with the subtle difference between = identification and authentication , so I wanted to be clear. > =20 > That being said there is a special case where if the JWT ie encrypted = with a symmetric key known only to two parties and it is = =E2=80=9Cauthenticated=E2=80=9D and you didn=E2=80=99t create it, then = by a process of elimination it cold have only come from one party. = This is NOT a signature, however it is a useful trick that some people = use to only encrypt and while still knowing with relative certainty who = encrypted it. > =20 > I should note that ECDH-SS rfc6278 a key agreement algorithm we = didn=E2=80=99t put in the base JWA spec also has the property of = providing encryption and authenticity based on the public keys of both = sender and receiver. > (note this is easier for implementers to get wrong than ECDH-ES but = that is another debate:) > =20 > Probably more than you wanted to know, but Nat started it:) > =20 > John B. > =20 > =20 > On Jul 17, 2015, at 2:09 PM, Brian Campbell = > wrote: > =20 > Though you want to be careful with that as the asymmetric algs in JWE = don't provide authentication of the sender. > =20 > On Thu, Jul 16, 2015 at 11:26 PM, Nat Sakimura > wrote: > Hi Malla, <> > =20 > Just to add one more thing: > If you just want to =E2=80=9Csign=E2=80=9D for the sake of integrity = protection, you really do not need to do it as all the algs in JWE are = integrity protected.=20 > =20 > -- > Nat Sakimura > > Nomura Research Institute, Ltd. > =20 > PLEASE READ: > The information contained in this e-mail is confidential and intended = for the named recipient(s) only. > If you are not an intended recipient of this e-mail, you are hereby = notified that any review, dissemination, distribution or duplication of = this message is strictly prohibited. If you have received this message = in error, please notify the sender immediately and delete your copy from = your system. > =20 > From: OAuth [mailto:oauth-bounces@ietf.org = ] On Behalf Of John Bradley > Sent: Friday, July 17, 2015 7:45 AM > To: Malla Simhachalam > > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Nesting Signatures and Encryption JWT Tokens > =20 > https://tools.ietf.org/html/rfc7519#section-11.2 = > =20 > It is in the JWT spec. You can do it both ways however you really = need a good reason not to sign then encrypt, and then after you have a = good reason you should still sign then encrypt because you probably have = not considered everything, > =20 > There are probably some edge cases that are exceptions to the rule, = but they are rare. > =20 > John B. > =20 > =20 > On Jul 16, 2015, at 11:33 PM, Malla Simhachalam = > wrote: > =20 > Hi, >=20 > I am looking at the spec = https://datatracker.ietf.org/doc/rfc7520/?include_text=3D1 = for combining JWS and JWE use case, I could not find it = obvious that a JSON document should be signed first and then encrypt or = other way around.Are there any recommendations one over the other? >=20 > Thanks for help. > Malla > _______________________________________________ > 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=_BB5E3540-7CD9-49F1-A0DA-DE980DFE10D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 No the issue is the entropy that needs to be added in SS = because you are not using a different ephemeral key each time. =  

The security = considerations covers it.   There is also the case where you are = encrypting to multiple recipients that breaks sender = identification.

We taled about including SS and EE, but decided to keep the = alg set limited to the ones people are most likely to be deployed. =    

In= IoT with small messages SS may have desirable properties, however no = one has asked for it yet.

I was just noting that it is one way to do it but has some = real security considerations that would need addressing.

John B.



Extreme care must be used =
when using static-static Diffie-Hellman
   (either standard or cofactor) without the use of some per-message
   value in the ukm.  As described in [RFC5753], the ukm value (if
   present) will be embedded in an ECC-CMS-SharedInfo structure, and the
   DER encoding of this structure will be used as the 'SharedInfo' input
   to the key-derivation function of [X963].  The purpose of this input
   is to add a message-unique value to the key-distribution function so
   that two different sessions of static-static ECDH between a given
   pair of agents result in independent keys.  If the ukm value is not
   used or is re-used, on the other hand, then the ECC-CMS-SharedInfo
   structure (and 'SharedInfo' input) will likely not vary from message
   to message.  In this case, the two agents will re-use the same keying
   material across multiple messages.  This is considered to be bad
   cryptographic practice and may open the sender to attacks on Diffie-
   Hellman (e.g., the 'small subgroup' attack [MenezesUstaoglu] or
   other, yet-undiscovered attacks).

   It is for these reasons that Section 2.1 states that message senders
   SHOULD include the ukm and SHOULD ensure that the value of ukm is
   unique to the message being sent.  One way to ensure the uniqueness
   of the ukm is for the message sender to choose a 'sufficiently long'
   random string for each message (where, as a rule of thumb, a
   'sufficiently long' string is one at least as long as the keys used
   by the key-wrap algorithm identified in the keyEncryptionAlgorithm
   field of the KeyAgreeRecipientInfo structure).  However, other
   methods (such as a counter) are possible.  Also, applications that
   cannot tolerate the inclusion of per-message information in the ukm
   (due to bandwidth requirements, for example) SHOULD NOT use static-
   static ECDH for a recipient without ascertaining that the recipient
   knows the private value associated with their certified Diffie-
   Hellman value.

   Static-static Diffie-Hellman, when used as described in this
   document, does not necessarily provide data-origin authentication.
   Consider, for example, the following sequence of events:





Herzog & =
Khazan               Informational                    [Page =
12]
 
RFC 6278                Static-Static ECDH in =
CMS              June 2011


   o  Alice sends an AuthEnvelopedData message to both Bob and Mallory.
      Furthermore, Alice uses a static-static DH method to transport the
      content-authenticated-encryption key to Bob, and some arbitrary
      method to transport the same key to Mallory.

   o  Mallory intercepts the message and prevents Bob from receiving it.

   o  Mallory recovers the content-authenticated-encryption key from the
      message received from Alice.  Mallory then creates new plaintext
      of her choice, and encrypts it using the same authenticated-
      encryption algorithm and the same content-authenticated-encryption
      key used by Alice.

   o  Mallory then replaces the EncryptedContentInfo and
      MessageAuthenticationCode fields of Alice's message with the
      values Mallory just generated.  She may additionally remove her
      RecipientInfo value from Alice's message.

   o  Mallory sends the modified message to Bob.

   o  Bob receives the message, validates the static-static DH values,
      and decrypts/authenticates the message.

   At this point, Bob has received and validated a message that appears
   to have been sent by Alice, but whose content was chosen by Mallory.
   Mallory may not even be an apparent receiver of the modified message.
   Thus, this use of static-static Diffie-Hellman does not necessarily
   provide data-origin authentication.  (We note that this example does
   not also contradict either confidentiality or data authentication:
   Alice's message was not received by anyone not intended by Alice, and
   Mallory's message was not modified before reaching Bob.)

   More generally, the data origin may not be authenticated unless:

   o  it is a priori guaranteed that the message in question was sent to
      exactly one recipient, or

   o  data-origin authentication is provided by some other mechanism
      (such as digital signatures).

   However, we also note that this lack of authentication is not a
   product of static-static ECDH per se, but is inherent in the way key-
   agreement schemes are used in the AuthenticatedData and
   AuthEnvelopedData structures of the CMS.

   When two parties are communicating using static-static ECDH as
   described in this document, and either party's asymmetric keys have
   been centrally generated, it is possible for that party's central



Herzog & =
Khazan               Informational                    [Page =
13]
 
RFC 6278                Static-Static ECDH in =
CMS              June 2011


   infrastructure to decrypt the communication (for application-layer
   network monitoring or filtering, for example).  By way of contrast:
   were ephemeral-static ECDH to be used instead, such decryption by the
   sender's infrastructure would not be possible (though it would remain
   possible for the infrastructure of any recipient).

On Jul 17, 2015, at 5:38 PM, Mike Jones = <Michael.Jones@microsoft.com> wrote:

As for =E2=80=9CECDH-SS rfc6278 = (being) easier for implementers to get wrong than ECDH-ES=E2=80=9D the good news about crypto is = that if you get it even a little bit wrong, it doesn=E2=80=99t work with = other=E2=80=99s implementations at all, so this situation tends to be = self-correcting.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = Cheers,
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            -- = Mike
 
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf = Of John Bradley
Sent: Friday, July 17, 2015 7:02 = AM
To: Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] Nesting = Signatures and Encryption JWT Tokens
 
They provide integrity protection for the encryption, =  that is very important for preventing padding oracle attacks.
 
AES GCM and AES_CBC_HMAC_SHA2 are both examples of Authenticated Encryption in the sense that the = received encryption is true and not that the sender is identified.
 
English speakers have a hard time with = the subtle difference between identification and authentication , so I = wanted to be clear.
 
That being said there is a special case where if the = JWT ie encrypted with a symmetric key known only to two parties and it = is =E2=80=9Cauthenticated=E2=80=9D and you didn=E2=80=99t create it, = then by a process of elimination it cold have only come from one party. =   This is NOT a signature,  however it is a useful trick that = some people use to only encrypt and while still knowing with relative = certainty who encrypted it.
 
I should note that ECDH-SS rfc6278 a key agreement = algorithm we didn=E2=80=99t put in the base JWA spec also has the = property of providing encryption and authenticity based on the =  public keys of both sender and receiver.
(note this is easier for implementers to get wrong than = ECDH-ES but that is another debate:)
 
Probably more than you wanted to know, but Nat = started it:)
 
John B.
 
 
On = Jul 17, 2015, at 2:09 PM, Brian Campbell <bcampbell@pingidentity.com>= wrote:
 
Though you want to be = careful with that as the asymmetric algs in JWE don't provide = authentication of the sender.
 
On Thu, Jul 16, 2015 at 11:26 PM, Nat Sakimura <n-sakimura@nri.co.jp> wrote:
Hi Malla,
 
Just to add one more thing:
If you just want to = =E2=80=9Csign=E2=80=9D for the sake of integrity protection, you really = do not need to do it as all the algs in JWE are integrity = protected. 
 
--
Nat Sakimura <n-sakimura@nri.co.jp>
Nomura Research Institute, Ltd.
 
PLEASE READ:
The information contained in this e-mail is = confidential and intended for the named recipient(s) only.
If you are not an intended = recipient of this e-mail, you are hereby notified that any review, = dissemination, distribution or duplication of this message is strictly = prohibited. If you have received this message in error, please notify = the sender immediately and delete your copy from your = system.
 
From: OAuth = [mailto:oauth-bounces@ietf.org] On Behalf = Of John Bradley
Sent: Friday, July 17, 2015 7:45 = AM
To: Malla Simhachalam <mallasimhachalam@gmail.com>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Nesting = Signatures and Encryption JWT Tokens
 
https://tools.ietf.org/html/rfc7519#section-11.2
 
It is in the JWT spec.   You = can do it both ways however you really need a good reason not to sign = then encrypt, and then after you have a good reason you should still = sign then encrypt because you probably have not considered = everything,
 
There are probably some edge cases = that are exceptions to the rule, but they are rare.
 
John B.
 
 
On = Jul 16, 2015, at 11:33 PM, Malla Simhachalam <mallasimhachalam@gmail.com> wrote:
 

Hi,

I am looking at = the spec https://datatracker.ietf.org/doc/rfc7520/?include_text=3D1<= span class=3D"Apple-converted-space"> for combining JWS and = JWE use case, I could not find it obvious that a JSON document should be = signed first and then encrypt or other way around.Are there any = recommendations one over the other?

Thanks for help.
Malla
_______________________________________________
OAuth mailing 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=_BB5E3540-7CD9-49F1-A0DA-DE980DFE10D2-- --Apple-Mail=_7BBEC4B3-3FF7-4934-9B87-9D3AFDBD1070 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTA3MTcxODI1MTFaMCMGCSqGSIb3DQEJBDEWBBTgKBT54wcev4mcBsLU5yaI 4RRzaDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQAtyroyg7DfEkGlVQlJ36BqNSnk3a8h73LS9JVyD6kd5pygZDsNUXDV EQfx3CR5bUAk7+/kSXslJmovxkIYwyRUctWw95V3k2/dbYUgHMWi6NLCDSM1beV6AnkKGjAnez18 0992lUf5T+GOHV/0M53KjbHN5CcPCL2d1QuLU98lXmfGs0DKJScL3QiBNamTq7/5RfnDusBmzieA SmIcJu4if5WuyowNcozEbEAA1w6LCG4+GRDNBZuAIdFa9ZlqL2a9ZVq/QPy4DiaqGbs6dETuUyVv mu0TurYvouYIkjYLVOdJgnliViiDdBhGqtsJVaV2EBt1smUrj7wFk5/n/cMnAAAAAAAA --Apple-Mail=_7BBEC4B3-3FF7-4934-9B87-9D3AFDBD1070-- From nobody Sat Jul 18 18:24:49 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 859341A1BBC for ; Sat, 18 Jul 2015 18:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJAZA4WQzs2f for ; Sat, 18 Jul 2015 18:24:45 -0700 (PDT) Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 392E31A1A24 for ; Sat, 18 Jul 2015 18:24:45 -0700 (PDT) Received: by iggf3 with SMTP id f3so60301717igg.1 for ; Sat, 18 Jul 2015 18:24:44 -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:date:message-id:subject:from:to :content-type; bh=X1OkKfWX0y5eZWG219DQQ7rmRJslBQe3RSiiMhS0nvM=; b=jffs60THzf+mutdy7kiuK+cnFHmJCDd8CFITQCUSdHvmEJJ0FqcXhU2SMplv6pn74K peEryWdgZ2gmdYitCze5OisvSovOIWAujz0TGX5904+uKFrd9MSGUlmVrkEwWSZ4koan TGsWAs2kxhixnZ47E08UAnJWob1LCydldUFgfzOPttYgNUuvTGsWZQVBUvk/fYNvUdod hsKq49+/3oKVBlVv8wGmSoaO0ekBelBcKwjnX44tLOUJGTC9SAxlafiQ7ffPxP2TBJEh 0VRPT4UXR1CQAFWAvK3Y+NQdxGA0sn3fntRDc9TeyBJ8ho8KO+X3CdWbKGaZ99V/WLsr oKFA== X-Gm-Message-State: ALoCoQmcj8nfIvV8tlcXrMzkI6UdmUwaSn43ZJP85V0DZqIVWcnwQj7XCAvOP8tNSdpN7rHbov0g X-Received: by 10.107.31.134 with SMTP id f128mr24918754iof.19.1437269084714; Sat, 18 Jul 2015 18:24:44 -0700 (PDT) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com. [209.85.213.180]) by smtp.gmail.com with ESMTPSA id j83sm10618577iod.25.2015.07.18.18.24.43 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Jul 2015 18:24:43 -0700 (PDT) Received: by igcqs7 with SMTP id qs7so60932878igc.0 for ; Sat, 18 Jul 2015 18:24:43 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.102.98 with SMTP id fn2mr4973180igb.55.1437269083529; Sat, 18 Jul 2015 18:24:43 -0700 (PDT) Received: by 10.107.20.84 with HTTP; Sat, 18 Jul 2015 18:24:43 -0700 (PDT) Date: Sat, 18 Jul 2015 18:24:43 -0700 Message-ID: From: Aaron Parecki To: Justin Richer , OAuth WG Content-Type: multipart/alternative; boundary=047d7b10caa72bacb5051b3049b7 Archived-At: Subject: [OAUTH-WG] broken links in draft-ietf-oauth-introspection-11 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 01:24:46 -0000 --047d7b10caa72bacb5051b3049b7 Content-Type: text/plain; charset=UTF-8 In section 2.2, https://tools.ietf.org/html/draft-ietf-oauth-introspection-11#section-2.2 the "scope" description references section 3.3 of RFC6749, but the hyperlink contains just the fragment #section-3.3 which then points to the current page. The same problem exists with the "token_type" parameter. Additionally, I believe the token type link should point to section 7.1 ( https://tools.ietf.org/html/rfc6749#section-7.1) which is where token types are defined. Thanks! ---- Aaron Parecki aaronparecki.com @aaronpk --047d7b10caa72bacb5051b3049b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In section 2.2,=C2=A0https://tools.ietf.or= g/html/draft-ietf-oauth-introspection-11#section-2.2 the "scope&qu= ot; description references section 3.3 of RFC6749, but the hyperlink contai= ns just the fragment #section-3.3 which then points to the current page. Th= e same problem exists with the "token_type" parameter. Additional= ly, I believe the token type link should point to section 7.1 (https://tools.ietf.org/html= /rfc6749#section-7.1) which is where token types are defined. Thanks!
----
Aaron Parecki

--047d7b10caa72bacb5051b3049b7-- From nobody Sat Jul 18 21:30:39 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14DDC1A1EF5 for ; Sat, 18 Jul 2015 21:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-15HhmDQ2eL for ; Sat, 18 Jul 2015 21:30:37 -0700 (PDT) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D75D81A7018 for ; Sat, 18 Jul 2015 21:30:36 -0700 (PDT) Received: by iebmu5 with SMTP id mu5so99181423ieb.1 for ; Sat, 18 Jul 2015 21:30:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=oMLg5Zf4gAzIhNbLaVz4ImTg/S/qHHe9Ps/DPOv1oNA=; b=dfCs0U+aRbePn2yuGvWsHeK81doM08tZPxIrzoWxDKZMlWZy9EMts3lFsk6RqpHHyT zFgmW2CJxZ5aK5o0rb354mEVG5lYJxzG+OdkaF8M9zWZwhtPhMCsAwPBrR8aBtAq22HA NVHK8gJKH6jGwjCsgSxzxiLjPuX+B0k+zrAxKPe6NcUs3yh6F+Io0bN9g6Xjx3EvisNc Ct6hKJIx2TkAVtNpDcBSy2GQJp7VybVytumQFnC8u5Bo3IQvi+F3pwn5848zJzIERTAA 54H4lsOBKIvVisA74WDqfT5LVTz6CNiql9XLbX1zPZjJdKZjKB5gMUNXbhmDSRf3FJeo /W8g== X-Gm-Message-State: ALoCoQkK78jeGo1pFtGgf/T5h46ikYVtXiSZ1BSxdMASVP76ngE4j8Yvcw04fK5YisYf6lGx0+gv X-Received: by 10.50.110.3 with SMTP id hw3mr6107031igb.20.1437280236030; Sat, 18 Jul 2015 21:30:36 -0700 (PDT) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com. [209.85.213.176]) by smtp.gmail.com with ESMTPSA id 8sm3624488iok.39.2015.07.18.21.30.35 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Jul 2015 21:30:35 -0700 (PDT) Received: by igvi1 with SMTP id i1so58055227igv.1 for ; Sat, 18 Jul 2015 21:30:34 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.138.73 with SMTP id qo9mr6142466igb.64.1437280234967; Sat, 18 Jul 2015 21:30:34 -0700 (PDT) Received: by 10.107.20.84 with HTTP; Sat, 18 Jul 2015 21:30:34 -0700 (PDT) Date: Sat, 18 Jul 2015 21:30:34 -0700 Message-ID: From: Aaron Parecki To: OAuth WG Content-Type: multipart/alternative; boundary=001a1134bae0d9262d051b32e13e Archived-At: Subject: [OAUTH-WG] Token introspection for public clients? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 04:30:38 -0000 --001a1134bae0d9262d051b32e13e Content-Type: text/plain; charset=UTF-8 The introspection draft states that the introspection endpoint MUST require authentication of clients. It mentions either client authentication (id+secret) or a separate bearer token. How are public clients expected to use the token introspection endpoint? I didn't see a note in the document about that at all. ---- Aaron Parecki aaronparecki.com @aaronpk --001a1134bae0d9262d051b32e13e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The introspection draft states that the introspection= endpoint MUST require authentication of clients. It mentions either client= authentication (id+secret) or a separate bearer token.

How are public clients expected to use the token introspection endpoi= nt? I didn't see a note in the document about that at all.

----
Aaron Pa= recki

--001a1134bae0d9262d051b32e13e-- From nobody Sat Jul 18 22:01:06 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 544121A86EE for ; Sat, 18 Jul 2015 22:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_HEX=1.122] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4IPb9CVz0MV for ; Sat, 18 Jul 2015 22:01:02 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0788.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::788]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29ABC1A86FC for ; Sat, 18 Jul 2015 22:01:02 -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=5mjsKl+tiRMyRPcNT2U4DS4RSbXrA0OgTlkO0Ght4g4=; b=c/o6+Ez5A/QrX/c2YrKNGPLJ0UcKrHQZnyG1QYpL0yj3wcvgHPC2xPwhrmREvbBYRojujuu/Syo2fqdPqSRIMexldqF8cWAEa9kqN8RkhiEY+opX8Ln4QQ+lcyXeiw8uW4vo9sYrAYawFSr3abCYaafj7OmVK9G/WhbuvCfg5wc= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.213.10; Sun, 19 Jul 2015 05:00:44 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0213.021; Sun, 19 Jul 2015 05:00:44 +0000 From: Mike Jones To: Aaron Parecki , OAuth WG Thread-Topic: [OAUTH-WG] Token introspection for public clients? Thread-Index: AQHQwdutT1eUj0lQB0+hBH85hKwyNJ3iO4ww Date: Sun, 19 Jul 2015 05:00:44 +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: parecki.com; dkim=none (message not signed) header.d=none; x-originating-ip: [12.130.119.130] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:3h4W9r/kkOrLbCtMrHJfiSZwgztVcklDK0wIZOKJD5KDkp3YFbw/7R5vs9DHzuBRGdTsv3F5JZyez30PB5RdcP0cMtyyaEQ18s4QPmSdgYBfNvejex5tUtPazVnwkIHVJm1/orr2lOpvGGEN5kDl9Q==; 24:bf6C6SNXdOuI7+aSXVEEnmdzCrrwUtw+fgPoYFAqAhEV3lRgqFdWMUNHUdVJCro5Lm4AbRvjnM+jfpUrB/9UzMj00QVySfMMgg3G3IkwNB4=; 20:bLiHzezsU9Q7wrFqUU0xCg5UxOw+Ljzyjas8/LBK3xI6zB9Y26zgXhP33pNq5C6AfxbtUCwXF8/0Fz0QueBgyA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; by2pr03mb442: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 0642A5E7BA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(19300405004)(19625215002)(122556002)(19609705001)(102836002)(15975445007)(2950100001)(40100003)(77156002)(5001770100001)(16236675004)(66066001)(2900100001)(5003600100002)(19580395003)(5002640100001)(19580405001)(54356999)(87936001)(2656002)(50986999)(46102003)(77096005)(33656002)(86362001)(76176999)(106116001)(62966003)(107886002)(19617315012)(76576001)(5001960100002)(189998001)(74316001)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB44228B5B192C12CA0014F92F5860BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2015 05:00:44.3286 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Subject: Re: [OAUTH-WG] Token introspection for public clients? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 05:01:04 -0000 --_000_BY2PR03MB44228B5B192C12CA0014F92F5860BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgYSBub3RlIGZvciB0aGUgdXBjb21pbmcgVG9rZW4gRXhjaGFuZ2UgZGlzY3Vzc2lvbiBpbiBQ cmFndWUsIEnigJlsbCBub3RlIHRoYXQgdGhpcyBzYW1lIHF1ZXN0aW9uIG1heSBhcHBseSB0aGVy ZS4gIFNwZWNpZmljYWxseSwgY2FuIHRoZSBwYXJ0eSByZXF1ZXN0aW5nIHRoZSBleGNoYW5nZSBi ZSBhIHB1YmxpYyBjbGllbnQ/ICAoQW5kIGRvZXMgaXQgaGF2ZSB0byBiZSBhbiBPQXV0aCBjbGll bnQgYXQgYWxsPykNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgQ2hlZXJzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBPQXV0aCBbbWFp bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBYXJvbiBQYXJlY2tpDQpT ZW50OiBTdW5kYXksIEp1bHkgMTksIDIwMTUgNjozMSBBTQ0KVG86IE9BdXRoIFdHDQpTdWJqZWN0 OiBbT0FVVEgtV0ddIFRva2VuIGludHJvc3BlY3Rpb24gZm9yIHB1YmxpYyBjbGllbnRzPw0KDQpU aGUgaW50cm9zcGVjdGlvbiBkcmFmdCBzdGF0ZXMgdGhhdCB0aGUgaW50cm9zcGVjdGlvbiBlbmRw b2ludCBNVVNUIHJlcXVpcmUgYXV0aGVudGljYXRpb24gb2YgY2xpZW50cy4gSXQgbWVudGlvbnMg ZWl0aGVyIGNsaWVudCBhdXRoZW50aWNhdGlvbiAoaWQrc2VjcmV0KSBvciBhIHNlcGFyYXRlIGJl YXJlciB0b2tlbi4NCg0KSG93IGFyZSBwdWJsaWMgY2xpZW50cyBleHBlY3RlZCB0byB1c2UgdGhl IHRva2VuIGludHJvc3BlY3Rpb24gZW5kcG9pbnQ/IEkgZGlkbid0IHNlZSBhIG5vdGUgaW4gdGhl IGRvY3VtZW50IGFib3V0IHRoYXQgYXQgYWxsLg0KDQotLS0tDQpBYXJvbiBQYXJlY2tpDQphYXJv bnBhcmVja2kuY29tPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHAlM2ElMmYlMmZhYXJvbnBhcmVja2kuY29tJmRhdGE9MDElN2MwMSU3Y01pY2hh ZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdjZjgyN2E4ZjgwYTM5NDE5YmE1ZTIwOGQyOGZmMmNl MTIlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9T0xXd2x2VVd5 WHoySFphR3lBU3ZBbFo5ZkVoSnQ2YTdBMyUyYmRmZGdVZFVZJTNkPg0KQGFhcm9ucGs8aHR0cHM6 Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUy ZnR3aXR0ZXIuY29tJTJmYWFyb25wayZkYXRhPTAxJTdjMDElN2NNaWNoYWVsLkpvbmVzJTQwbWlj cm9zb2Z0LmNvbSU3Y2Y4MjdhOGY4MGEzOTQxOWJhNWUyMDhkMjhmZjJjZTEyJTdjNzJmOTg4YmY4 NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPVU3UlhTdFlaMUhJTCUyYlRsTTk5JTJm WVc4VzlSUHc4YlRnSGdYY2p1dnlLMHQwJTNkPg0KDQo= --_000_BY2PR03MB44228B5B192C12CA0014F92F5860BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXMgYSBub3RlIGZvciB0 aGUgdXBjb21pbmcgVG9rZW4gRXhjaGFuZ2UgZGlzY3Vzc2lvbiBpbiBQcmFndWUsIEnigJlsbCBu b3RlIHRoYXQgdGhpcyBzYW1lIHF1ZXN0aW9uIG1heSBhcHBseSB0aGVyZS4mbmJzcDsgU3BlY2lm aWNhbGx5LCBjYW4gdGhlIHBhcnR5IHJlcXVlc3RpbmcgdGhlDQogZXhjaGFuZ2UgYmUgYSBwdWJs aWMgY2xpZW50PyZuYnNwOyAoQW5kIGRvZXMgaXQgaGF2ZSB0byBiZSBhbiBPQXV0aCBjbGllbnQg YXQgYWxsPyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDaGVlcnMsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmdd DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFhcm9uIFBhcmVja2k8YnI+DQo8Yj5TZW50OjwvYj4gU3Vu ZGF5LCBKdWx5IDE5LCAyMDE1IDY6MzEgQU08YnI+DQo8Yj5Ubzo8L2I+IE9BdXRoIFdHPGJyPg0K PGI+U3ViamVjdDo8L2I+IFtPQVVUSC1XR10gVG9rZW4gaW50cm9zcGVjdGlvbiBmb3IgcHVibGlj IGNsaWVudHM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo ZSBpbnRyb3NwZWN0aW9uIGRyYWZ0IHN0YXRlcyB0aGF0IHRoZSBpbnRyb3NwZWN0aW9uIGVuZHBv aW50IE1VU1QgcmVxdWlyZSBhdXRoZW50aWNhdGlvbiBvZiBjbGllbnRzLiBJdCBtZW50aW9ucyBl aXRoZXIgY2xpZW50IGF1dGhlbnRpY2F0aW9uIChpZCYjNDM7c2VjcmV0KSBvciBhIHNlcGFyYXRl IGJlYXJlciB0b2tlbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SG93IGFyZSBwdWJsaWMgY2xpZW50cyBleHBlY3RlZCB0byB1c2UgdGhlIHRv a2VuIGludHJvc3BlY3Rpb24gZW5kcG9pbnQ/IEkgZGlkbid0IHNlZSBhIG5vdGUgaW4gdGhlIGRv Y3VtZW50IGFib3V0IHRoYXQgYXQgYWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLS08bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFhcm9uIFBhcmVja2k8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBz Oi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYl MmZhYXJvbnBhcmVja2kuY29tJmFtcDtkYXRhPTAxJTdjMDElN2NNaWNoYWVsLkpvbmVzJTQwbWlj cm9zb2Z0LmNvbSU3Y2Y4MjdhOGY4MGEzOTQxOWJhNWUyMDhkMjhmZjJjZTEyJTdjNzJmOTg4YmY4 NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1PTFd3bHZVV3lYejJIWmFHeUFT dkFsWjlmRWhKdDZhN0EzJTJiZGZkZ1VkVVklM2QiIHRhcmdldD0iX2JsYW5rIj5hYXJvbnBhcmVj a2kuY29tPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cCUzYSUyZiUyZnR3aXR0ZXIuY29tJTJmYWFyb25wayZhbXA7ZGF0YT0wMSU3 YzAxJTdjTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN2NmODI3YThmODBhMzk0MTliYTVl MjA4ZDI4ZmYyY2UxMiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7 c2RhdGE9VTdSWFN0WVoxSElMJTJiVGxNOTklMmZZVzhXOVJQdzhiVGdIZ1hjanV2eUswdDAlM2Qi IHRhcmdldD0iX2JsYW5rIj5AYWFyb25wazwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BY2PR03MB44228B5B192C12CA0014F92F5860BY2PR03MB442namprd_-- From nobody Sat Jul 18 22:05:00 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3251A86FC for ; Sat, 18 Jul 2015 22:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTwq3807N1hM for ; Sat, 18 Jul 2015 22:04:58 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C66291A86F4 for ; Sat, 18 Jul 2015 22:04:57 -0700 (PDT) X-AuditID: 12074425-f799a6d000007db3-eb-55ab2ff80b36 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id B1.84.32179.8FF2BA55; Sun, 19 Jul 2015 01:04:56 -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 t6J54tBt030373; Sun, 19 Jul 2015 01:04:55 -0400 Received: from [10.55.4.208] ([31.30.2.5]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t6J54qKe030280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 19 Jul 2015 01:04:54 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_632690DD-7B4A-4656-A8B2-A5AC01825AF1" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Justin Richer In-Reply-To: Date: Sun, 19 Jul 2015 07:04:50 +0200 Message-Id: <0F2B6432-4D9E-4277-BFFE-5F0354A6D9B7@mit.edu> References: To: Aaron Parecki X-Mailer: Apple Mail (2.2102) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IR4hTV1v2hvzrUYMZuSYtzq9wsTr59xebA 5LFkyU8mj4aZaQFMUVw2Kak5mWWpRfp2CVwZL7YeZix4KVUxdelm9gbGM+JdjJwcEgImEq+O TGCFsMUkLtxbz9bFyMUhJLCYSWLa9P2sEM5GRolFZzexgVQJCSxnkpj5URDEZhZIkDi8fBkT iM0roCfRc+4LI4gtLGAvsXjlY7CpbAKqEtPXtIDVcAoESiza/hdsDgtQfMnaRUBxDqA56hLt J10gxlhJ3Jh+lhliVYDE/asrwVpFgMqvNbYxQhwqK7H1TSvTBEaBWUiumIXkCoi4tsSyha+Z IWxNif3dy1kwxTUkOr9NZF3AyLaKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI10IvN7NELzWldBMj KNTZXVR3ME44pHSIUYCDUYmH1+LLqlAh1sSy4srcQ4ySHExKorxKAqtDhfiS8lMqMxKLM+KL SnNSiw8xSnAwK4nw5jMC5XhTEiurUovyYVLSHCxK4rybfvCFCAmkJ5akZqemFqQWwWRlODiU JHij9YAaBYtS01Mr0jJzShDSTBycIMN5gIZ3gtTwFhck5hZnpkPkTzEqSonz1oMkBEASGaV5 cL2wVPSKURzoFWFePmBiEuIBpjG47ldAg5lABq9eATK4JBEhJdXAKLqlnyVBfk932N23awPb NiX3P3z6eqlqbpFzcMnVz73i7JGuMycXyirI18nJRW39/uX+x0sRKluzL9zxEpMq5OPyLkg/ 7tgrOjWzoLtVKH9m1PnFwiF+p7cz/9FduHNT0vKWrD8OnEvMN6QKa2qJnlc5JaKd+9OqPNml tvR5E2dcudW/Wx1KLMUZiYZazEXFiQAwzNDXIAMAAA== Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Token introspection for public clients? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 05:04:59 -0000 --Apple-Mail=_632690DD-7B4A-4656-A8B2-A5AC01825AF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Public clients can use the token-based auth mechanism, can=E2=80=99t = they? If you don=E2=80=99t have some form of authentication on the = introspection endpoint, you end up with a way for people to anonymously = and programmatically fish for valid token values.=20 =E2=80=94 Justin > On Jul 19, 2015, at 6:30 AM, Aaron Parecki wrote: >=20 > The introspection draft states that the introspection endpoint MUST = require authentication of clients. It mentions either client = authentication (id+secret) or a separate bearer token. >=20 > How are public clients expected to use the token introspection = endpoint? I didn't see a note in the document about that at all. >=20 > ---- > Aaron Parecki > aaronparecki.com > @aaronpk >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_632690DD-7B4A-4656-A8B2-A5AC01825AF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Public clients can use the token-based auth mechanism, = can=E2=80=99t they? If you don=E2=80=99t have some form of = authentication on the introspection endpoint, you end up with a way for = people to anonymously and programmatically fish for valid token = values. 

 =E2=80=94 Justin

On = Jul 19, 2015, at 6:30 AM, Aaron Parecki <aaron@parecki.com> = wrote:

The introspection = draft states that the introspection endpoint MUST require authentication = of clients. It mentions either client authentication (id+secret) or a = separate bearer token.

How are public clients expected to use the token = introspection endpoint? I didn't see a note in the document about that = at all.

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

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

= --Apple-Mail=_632690DD-7B4A-4656-A8B2-A5AC01825AF1-- From nobody Sat Jul 18 22:05:45 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6F81A8704 for ; Sat, 18 Jul 2015 22:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqQJFfu0irl5 for ; Sat, 18 Jul 2015 22:05:42 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC14B1A86F4 for ; Sat, 18 Jul 2015 22:05:41 -0700 (PDT) X-AuditID: 1209190f-f79716d000002ea2-1b-55ab30248999 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 72.CE.11938.4203BA55; Sun, 19 Jul 2015 01:05:40 -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 t6J55eO5030394; Sun, 19 Jul 2015 01:05:40 -0400 Received: from [10.55.4.208] ([31.30.2.5]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t6J54qKf030280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 19 Jul 2015 01:05:39 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_13D4BDC3-D26D-40B0-BCB0-C2A21EC95E53" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Justin Richer In-Reply-To: Date: Sun, 19 Jul 2015 07:05:38 +0200 Message-Id: References: To: Aaron Parecki X-Mailer: Apple Mail (2.2102) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42IR4hTV1lUxWB1q0D1f3+LcKjeLk29fsTkw eSxZ8pPJo2FmWgBTFJdNSmpOZllqkb5dAlfGk6eLmAsuS1a0nL/M2sD4XKyLkZNDQsBE4vuy 92wQtpjEhXvrgWwuDiGBxUwSs7fcYoFwNjJKTFlwECqznEni36HJYC3MAgkS67fvZgaxeQX0 JHrOfWEEsYUF7CQm/7rGDmKzCahKTF/TwgRicwoESuy88QqsngUo3nh4CWsXIwfQHHWJ9pMu EGOsJKb9WA02XkggQOLN6bWsILYIUPm1xjZGiEtlJba+aWWawCgwC8kVs5BcARHXlli28DUz hK0psb97OQumuIZE57eJrAsY2VYxyqbkVunmJmbmFKcm6xYnJ+blpRbpmujlZpbopaaUbmIE B7sk/w7GbweVDjEKcDAq8fBO+LYqVIg1say4MvcQoyQHk5Ior5LA6lAhvqT8lMqMxOKM+KLS nNTiQ4wSHMxKIrz5jEA53pTEyqrUonyYlDQHi5I476YffCFCAumJJanZqakFqUUwWRkODiUJ 3mg9oEbBotT01Iq0zJwShDQTByfIcB6g4Z0gNbzFBYm5xZnpEPlTjIpS4rz1IAkBkERGaR5c LywZvWIUB3pFmLcPpIoHmMjgul8BDWYCGbx6BcjgkkSElFQDo8M17u33/m7YX1MSbS+et1z5 2zYGRdkoh+jgVZy3JK9zifx3dzW53aG0xf/T9zev7V9vuHtE+UJGbUDP3qqCa58XL469oSi8 /pzf7YlrxG5OuSNYlDbxqtGNmdzBhze3MchKLFG/r6B2K+n8x/wPYj/menc2Whz9M21Xrazc S4N/Ty7YFFxnLlNiKc5INNRiLipOBACyaLJmIQMAAA== Archived-At: Cc: "" Subject: Re: [OAUTH-WG] broken links in draft-ietf-oauth-introspection-11 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 05:05:43 -0000 --Apple-Mail=_13D4BDC3-D26D-40B0-BCB0-C2A21EC95E53 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks, those are artifacts in the rendered XML, I=E2=80=99ll look into = fixing them. =E2=80=94 Justin > On Jul 19, 2015, at 3:24 AM, Aaron Parecki wrote: >=20 > In section 2.2, = https://tools.ietf.org/html/draft-ietf-oauth-introspection-11#section-2.2 = the "scope" description references section 3.3 of RFC6749, but the = hyperlink contains just the fragment #section-3.3 which then points to = the current page. The same problem exists with the "token_type" = parameter. Additionally, I believe the token type link should point to = section 7.1 (https://tools.ietf.org/html/rfc6749#section-7.1 = ) which is where token = types are defined. Thanks! >=20 > ---- > Aaron Parecki > aaronparecki.com > @aaronpk >=20 --Apple-Mail=_13D4BDC3-D26D-40B0-BCB0-C2A21EC95E53 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks, those are artifacts in the rendered XML, I=E2=80=99ll = look into fixing them.

 =E2=80=94 Justin

On = Jul 19, 2015, at 3:24 AM, Aaron Parecki <aaron@parecki.com> = wrote:

In section = 2.2, https://tools.ietf.org/html/draft-ietf-oauth-introspection-11#s= ection-2.2 the "scope" description references section 3.3 of = RFC6749, but the hyperlink contains just the fragment #section-3.3 which = then points to the current page. The same problem exists with the = "token_type" parameter. Additionally, I believe the token type link = should point to section 7.1 (https://tools.ietf.org/html/rfc6749#section-7.1) which is = where token types are defined. Thanks!

----
Aaron Parecki
aaronparecki.com
@aaronpk


= --Apple-Mail=_13D4BDC3-D26D-40B0-BCB0-C2A21EC95E53-- From nobody Sun Jul 19 03:58:39 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B721AC41D for ; Sun, 19 Jul 2015 03:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.478 X-Spam-Level: X-Spam-Status: No, score=-1.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URI_HEX=1.122] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-fTaj-B6YcY for ; Sun, 19 Jul 2015 03:58:36 -0700 (PDT) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54ADF1AC410 for ; Sun, 19 Jul 2015 03:58:36 -0700 (PDT) Received: by wgav7 with SMTP id v7so45515301wga.2 for ; Sun, 19 Jul 2015 03:58:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=ALdQBJFskar+e2SwFzHvJvtnYqpqO0UYqdLtQy2UG0k=; b=DvpK/5XoFQpFHmQ4DYAc+4mzRd8Jfnoqmdvf6b7ymjSuQg1CPUe1xCayx3KOnyuzAj 9Bs4f0a2KKSlwXn8cfO+xQyVaQOVHRm5xXWMyOCmHvGGPwIeFNGdE+4Z/LcU4nZlZ9HN cqMUkuHA8a6be9TZMA1EuUP+yBqEX7QP1/0KR7xymFE0cv6rg2c1NHXqUVcNNxwPdvnG bLEPOxC+pn8ll/kv36DV0RAhpzRsY/CbtqPSW7DK9+4aCxH4ZL2YcwQGD1yl3/Fu6gPQ wzPM9hnRUuUPckDxoihKptiDUIVRZz6UXfYBf39b04l0vpl8S6cbn5BkBoBBAS1BIKi0 PPAw== X-Gm-Message-State: ALoCoQlDum4upw33g+5qp0IZJXZQJQc/1nhk6P988upY8fSTZ0queaXRksCcHxSc5GlOJ1Nc47og X-Received: by 10.194.176.201 with SMTP id ck9mr45935907wjc.108.1437303514938; Sun, 19 Jul 2015 03:58:34 -0700 (PDT) Received: from ?IPv6:2001:67c:370:136:68f4:280:1597:61e? ([2001:67c:370:136:68f4:280:1597:61e]) by smtp.gmail.com with ESMTPSA id fb3sm6503713wib.21.2015.07.19.03.58.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 19 Jul 2015 03:58:33 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_E27C2063-739E-4024-8D63-9F38B9C12C16"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: John Bradley In-Reply-To: Date: Sun, 19 Jul 2015 12:58:30 +0200 Message-Id: References: To: Michael Jones X-Mailer: Apple Mail (2.2102) Archived-At: Cc: OAuth WG Subject: Re: [OAUTH-WG] Token introspection for public clients? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 10:58:38 -0000 --Apple-Mail=_E27C2063-739E-4024-8D63-9F38B9C12C16 Content-Type: multipart/alternative; boundary="Apple-Mail=_F7415100-093D-4084-9F0F-A510DD77995B" --Apple-Mail=_F7415100-093D-4084-9F0F-A510DD77995B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That is one of the place that using a POP mechanism may be useful. If = the client has established a key with the AS that issued the original = token say via PKCE then, then it may be possible to bind the token = being exchanged to the party exchanging it even if the exchanger has no = pre exchanged credentials with the token exchange endpoint. In the ACDC proposal part of profiling the assertion exchange was to = require that they be POP tokens using PKCE as the confirmation method. I would like to think that the ACDC use case is something that can be = addressed by the final token exchange spec. In OAuth and Connect we have three entities that receive tokens. =20 1, User agents: code, token, id_token (any of them might be PoP using = token binding)=20 2, Clients: code (pop via PKCE) Refresh tokens (pop via Token = binding?), access tokens (pop via the OAuth POP spec) , id_tokens = (token binding via browser) , jwt or other assertions (?) 3 Resource Server: Access tokens ( these might be bound to the Audience = of the token for exchange) To the original question. The client might use dynamic client = registration, or it might use PKCE. =20 In the PKCE case if the AT a POP token and the client uses it=E2=80=99s = POP key to prove it it=E2=80=99s identity then it should be able to = introspect the token. =20 Though from a spec point of view there are admittedly still some gaps in = doing that at the moment. John B. > On Jul 19, 2015, at 7:00 AM, Mike Jones = wrote: >=20 > As a note for the upcoming Token Exchange discussion in Prague, I=E2=80=99= ll note that this same question may apply there. Specifically, can the = party requesting the exchange be a public client? (And does it have to = be an OAuth client at all?) > =20 > Cheers, > -- Mike > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Aaron Parecki > Sent: Sunday, July 19, 2015 6:31 AM > To: OAuth WG > Subject: [OAUTH-WG] Token introspection for public clients? > =20 > The introspection draft states that the introspection endpoint MUST = require authentication of clients. It mentions either client = authentication (id+secret) or a separate bearer token. > =20 > How are public clients expected to use the token introspection = endpoint? I didn't see a note in the document about that at all. >=20 > ---- > Aaron Parecki > aaronparecki.com = > @aaronpk = > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_F7415100-093D-4084-9F0F-A510DD77995B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 That is one of the place that using a POP mechanism may be = useful.  If the client has established a key with the AS that = issued the original token say via PKCE then,  then it may be = possible to bind the token being exchanged to the party exchanging it = even if the exchanger has no pre exchanged credentials with the token = exchange endpoint.

In = the ACDC proposal part of profiling the assertion exchange was to = require that they be POP tokens using PKCE as the confirmation = method.

I = would like to think that the ACDC use case is something that can be = addressed by the final token exchange spec.

In OAuth and Connect we have three = entities that receive tokens.  
1, User = agents:  code, token, id_token (any of them might be PoP using = token binding) 
2, Clients:  code (pop = via PKCE) Refresh tokens (pop via Token binding?),  access tokens = (pop via the OAuth POP spec) , id_tokens (token binding via browser) =  ,  jwt or other assertions (?)
3 = Resource Server:  Access tokens ( these might be bound to the = Audience of the token for exchange)


To = the original question.   The client might use dynamic client = registration,  or it might use PKCE.  

 In the PKCE case if the AT a POP = token and the client uses it=E2=80=99s POP key to prove it it=E2=80=99s = identity then it should be able to introspect the token. =  
Though from a spec point of view there are = admittedly still some gaps in doing that at the moment.

John B.

On Jul 19, 2015, at 7:00 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

As a note for the upcoming Token Exchange = discussion in Prague, I=E2=80=99ll note that this same question may = apply there.  Specifically, can the party requesting the exchange = be a public client?  (And does it have to be an OAuth client at = all?)
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = Cheers,
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            -- = Mike
 
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf = Of Aaron = Parecki
Sent: Sunday, July 19, 2015 6:31 = AM
To: OAuth WG
Subject: [OAUTH-WG] Token = introspection for public clients?
 
The = introspection draft states that the introspection endpoint MUST require = authentication of clients. It mentions either client authentication = (id+secret) or a separate bearer token.
 
How are public clients expected to use = the token introspection endpoint? I didn't see a note in the document = about that at all.

----
Aaron Parecki
aaronparecki.com
@aaronpk
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_F7415100-093D-4084-9F0F-A510DD77995B-- --Apple-Mail=_E27C2063-739E-4024-8D63-9F38B9C12C16 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTA3MTkxMDU4MzFaMCMGCSqGSIb3DQEJBDEWBBS9bDrDZmL1Yst1yzNtWhlG 31JY7TCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCCF4OeWd3/Lk1XzbPE4HNn54q2HqgG6qyOXqgHWvqjOqtXSIcxbb4Y Ru9hLd5k5XaL4h5gIFLaGm/mXswiUOQMAVKFX3iZHJks0kRBKuqI3scendvqhp6HIu1ki+aaJmUm X7Xr4Ldm7FDIV58z+mcLKVOe19BmcSN7fRNzDn0/u9TmlqK8fVbcES7XeNeErFiMGIFkXs0JX+3d 6tOQxP+Nd4s2k3qzH5KvEfNVxVXfG1UD/siMlZRFIhYtXjC8jjrqTOuzwzYMrrXhomN0CasBDZT3 rmUl7vAFUxUd7OYuqJeeQZ+03AN5Ud5ZwLkY94XEBhHC2vv+JYsJl8pe27/2AAAAAAAA --Apple-Mail=_E27C2063-739E-4024-8D63-9F38B9C12C16-- From nobody Sun Jul 19 05:10:11 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1717B1ACD71 for ; Sun, 19 Jul 2015 05:10: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7MiCUCBc0q5 for ; Sun, 19 Jul 2015 05:10:08 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 801D81ACDB4 for ; Sun, 19 Jul 2015 05:09:43 -0700 (PDT) Received: by wicgb10 with SMTP id gb10so5795498wic.1 for ; Sun, 19 Jul 2015 05:09:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=jm+uUBK1gQU+q/L8xpSk+i/kA4RCMSLfCrSDcx8M6I8=; b=AHkJ7kbYQYW0PLtacCtnTJbGfFvZXsotqh5PffATgyDC9NikenGmIrjkRXeMnbJHXk ET1D/Mahg0Hm5F7d9X1nvx4UWc0BHFKEvujzUDNgVf9BBtP4HpFXI0mBkUDFh3Y+7MA3 Kbln2QJnT2cyyyHFLmZnDTgGu6RvTRlN9Qg/V89wwIkcmIBvayLLbd8Ek94nik041Luf keB6nY2BuEiWty8K+T9LY2CZgajKcpQQyfORJIfW8j517zq2Iyu7hSsXon5Nl0qx68RP FFbpcpp06QnXSy26ZcbX4t9qUDcB4CcfoiIpYs854/g8y2CvQRx0yy2Y0UShZe8v60Dm x1UQ== X-Gm-Message-State: ALoCoQmgLZQmI3KD0r11j5WWQREObHKNX4l5mH5+m4eNv3U3lxMbq4GyaOjYMACw762SYtSYQy3z X-Received: by 10.194.85.116 with SMTP id g20mr45913421wjz.154.1437307781968; Sun, 19 Jul 2015 05:09:41 -0700 (PDT) Received: from [10.6.0.171] ([62.212.85.119]) by smtp.gmail.com with ESMTPSA id di7sm6731035wib.23.2015.07.19.05.09.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 19 Jul 2015 05:09:40 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_DEB72135-21F8-40F3-9965-2CF4784BE17D"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: John Bradley In-Reply-To: Date: Sun, 19 Jul 2015 14:09:38 +0200 Message-Id: References: To: Justin Richer X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] broken links in draft-ietf-oauth-introspection-11 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 12:10:10 -0000 --Apple-Mail=_DEB72135-21F8-40F3-9965-2CF4784BE17D Content-Type: multipart/alternative; boundary="Apple-Mail=_C84B56C7-A022-41E6-9B08-534DB3E5DDE0" --Apple-Mail=_C84B56C7-A022-41E6-9B08-534DB3E5DDE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Remember tools is not using the XML to render the HTML directly, it is = marking up the text version. This bites me all the time as well. The text version needs to render to =E2=80=9CSection 3.3 of RFC 6749=E2=80= =9D to get Rfcmarkup tool = to render it correctly. =20 The trailing of OAuth 2.0 messes up Rfcmarkup. I am looking at fixing PIXE for the RFC editor so this happens to be a = current issue for me, as I did the same thing because that is what = produces the best HTML output from XML2RFC. What I have learned is to NOT format looking at the html output from = XML2RFC as it leads you in the wrong direction, output as text then run = through Rfcmarkup to see what the version on the document tracker will = look like. Hope this saves you some time. John B. > On Jul 19, 2015, at 7:05 AM, Justin Richer wrote: >=20 > Thanks, those are artifacts in the rendered XML, I=E2=80=99ll look = into fixing them. >=20 > =E2=80=94 Justin >=20 >> On Jul 19, 2015, at 3:24 AM, Aaron Parecki > wrote: >>=20 >> In section 2.2, = https://tools.ietf.org/html/draft-ietf-oauth-introspection-11#section-2.2 = the "scope" description references section 3.3 of RFC6749, but the = hyperlink contains just the fragment #section-3.3 which then points to = the current page. The same problem exists with the "token_type" = parameter. Additionally, I believe the token type link should point to = section 7.1 (https://tools.ietf.org/html/rfc6749#section-7.1 = ) which is where token = types are defined. Thanks! >>=20 >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_C84B56C7-A022-41E6-9B08-534DB3E5DDE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Remember tools is not using the XML to render the HTML = directly, it is marking up the text version.   This bites me all = the time as well.

The = text version needs to render to =E2=80=9CSection 3.3 of RFC 6749=E2=80=9D = to get Rfcmarkup tool to render it correctly. =   

The= trailing of OAuth 2.0 messes up Rfcmarkup.

I am looking at fixing PIXE for the RFC = editor so this happens to be a current issue for me, as I did the same = thing because that is what produces the best HTML output from = XML2RFC.

What = I have learned is to NOT format looking at the html output from XML2RFC = as it leads you in the wrong direction,  output as text then run = through Rfcmarkup to see what the version on the document tracker will = look like.

Hope = this saves you some time.

John B.


On Jul 19, 2015, at 7:05 AM, = Justin Richer <jricher@mit.edu> wrote:

Thanks, those = are artifacts in the rendered XML, I=E2=80=99ll look into fixing = them.

 =E2=80=94 = Justin

On Jul 19, 2015, at 3:24 AM, = Aaron Parecki <aaron@parecki.com> wrote:

In section = 2.2, https://tools.ietf.org/html/draft-ietf-oauth-introspection-11#s= ection-2.2 the "scope" description references section 3.3 of = RFC6749, but the hyperlink contains just the fragment #section-3.3 which = then points to the current page. The same problem exists with the = "token_type" parameter. Additionally, I believe the token type link = should point to section 7.1 (https://tools.ietf.org/html/rfc6749#section-7.1) which is = where token types are defined. Thanks!

----
Aaron Parecki
aaronparecki.com
@aaronpk


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

= --Apple-Mail=_C84B56C7-A022-41E6-9B08-534DB3E5DDE0-- --Apple-Mail=_DEB72135-21F8-40F3-9965-2CF4784BE17D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTA3MTkxMjA5MzhaMCMGCSqGSIb3DQEJBDEWBBRm3LSPgu/Z2whSGzvpQRGl QPkYdTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCDcXLpsrlGka4IXY9n1Umj5+kD+ovCm7zD/wT1aWse7VKjtYx0xR0M icubSqToGpjqyYSYVt7av0rayisFl44WU2bjB99gk/I8JNwVASIKaeWGvIHruyPf4U5C62LxhTtI 7K+CgMLLdk77PzNyDrWxvTUxKOEvV7spvztlLD7pV0hJyEuXYlZZzddGTZGSDRgd4oeNrn6o/GlD IQlPWWxc6W0fdONc8Jeleuz1/8/WbCfP9Lr0oIxpZuuUbW1QLl3d+iPHeFzZbnG4SCGP5wZzYy2b Sz7k+TTIQb/XXBYUetOyXt5g/9oZhShiWQDUQNvamkY1mMEhIx0/dYZ3bVTXAAAAAAAA --Apple-Mail=_DEB72135-21F8-40F3-9965-2CF4784BE17D-- From nobody Sun Jul 19 07:51:31 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 922271AD351 for ; Sun, 19 Jul 2015 07:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3McEXtG9nf7B for ; Sun, 19 Jul 2015 07:51:29 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::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 E26381AD350 for ; Sun, 19 Jul 2015 07:51:28 -0700 (PDT) Received: by iehx8 with SMTP id x8so23291543ieh.3 for ; Sun, 19 Jul 2015 07:51:28 -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:content-type; bh=LAmJoZ3WRC5xJwIwZGwCECLP7OV5DcbqcTqBXzEeLgY=; b=V69c3dXKMGyrsXdG9k9n2dfTW2xcVBVCkVGu/uhSgS+5B36AdQC4+YDUIANHOl/S7J p3xR+qeWW2L076Z3ir+NSjuqrBaTK+X8RRd4QCC8t0kgMjLC8bLOyVCrCDQCIVBfuh1W fOiqqA7fR/76H0AApaBBC/I5u3SaRsNFB1csU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=LAmJoZ3WRC5xJwIwZGwCECLP7OV5DcbqcTqBXzEeLgY=; b=aMxHC5F2tCA9pXnx8QeE/0Cg2KD+GhG447fdk/6GDkOw/Es0Pthpt2hLUot3w/JwUF uCSmNsDrNJrORfSNaQ7LE9gRSiA2sx5BxmmxcCoxEwmAg4EieqlllGl2pabyxtscatuH uoDHaqyHvWmNa1xxqY+y7Ll6PaeeiHh/X+IYsGmFjxWUS1kuW0eX2cbPEliImc0EZb6N lGs43uF8kszSivS+/xyLt5Gic+UzfTOdX8UJIb4s/hMb71t03jf4RQfZpXrLlMR/LgpW gYFrZb/VC8ccn6I7K8yftMtwXeIrdxj5tNpEKZ3FK9/uWd8O3ywxUwwoaFEaWEGSKaGn vjIA== X-Gm-Message-State: ALoCoQnVGQ+PHFDzNgn6khm7IvsIfJMc7MVu3vapZUMoKy1UIc5IvcgQCh41zVSxJ0Hdf36q5PpR X-Received: by 10.50.30.226 with SMTP id v2mr7713559igh.3.1437317488299; Sun, 19 Jul 2015 07:51:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Sun, 19 Jul 2015 07:50:58 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Sun, 19 Jul 2015 16:50:58 +0200 Message-ID: To: John Bradley , Barry Leiba Content-Type: multipart/alternative; boundary=047d7b86d50251f6dc051b3b8e41 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] broken links in draft-ietf-oauth-introspection-11 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 14:51:30 -0000 --047d7b86d50251f6dc051b3b8e41 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Barry explained the tools issue that causes this and how to work around it a while back on the JOSE list: http://www.ietf.org/mail-archive/web/jose/current/msg04571.html On Sun, Jul 19, 2015 at 2:09 PM, John Bradley wrote: > Remember tools is not using the XML to render the HTML directly, it is > marking up the text version. This bites me all the time as well. > > The text version needs to render to =E2=80=9CSection 3.3 of RFC 6749=E2= =80=9D to get Rfcmarkup > tool to render it > correctly. > > The trailing of OAuth 2.0 messes up Rfcmarkup. > > I am looking at fixing PIXE for the RFC editor so this happens to be a > current issue for me, as I did the same thing because that is what produc= es > the best HTML output from XML2RFC. > > What I have learned is to NOT format looking at the html output from > XML2RFC as it leads you in the wrong direction, output as text then run > through Rfcmarkup to see what the version on the document tracker will lo= ok > like. > > Hope this saves you some time. > > John B. > > > On Jul 19, 2015, at 7:05 AM, Justin Richer wrote: > > Thanks, those are artifacts in the rendered XML, I=E2=80=99ll look into f= ixing > them. > > =E2=80=94 Justin > > On Jul 19, 2015, at 3:24 AM, Aaron Parecki wrote: > > In section 2.2, > https://tools.ietf.org/html/draft-ietf-oauth-introspection-11#section-2.2 > the "scope" description references section 3.3 of RFC6749, but the > hyperlink contains just the fragment #section-3.3 which then points to th= e > current page. The same problem exists with the "token_type" parameter. > Additionally, I believe the token type link should point to section 7.1 ( > https://tools.ietf.org/html/rfc6749#section-7.1) which is where token > types are defined. Thanks! > > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --047d7b86d50251f6dc051b3b8e41 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Barry explained the tools issue that causes this and how t= o work around it a while back on the JOSE list: http://www.ietf.org/mail-a= rchive/web/jose/current/msg04571.html

On Sun, Jul 19, 2015 at 2:09 PM, John Bra= dley <ve7jtb@ve7jtb.com> wrote:
Remember tools is not using the X= ML to render the HTML directly, it is marking up the text version. =C2=A0 T= his bites me all the time as well.

The text version need= s to render to =E2=80=9CSection 3.3 of RFC 6749=E2=80=9D to get=C2=A0Rfcmark= up tool=C2=A0to render it correctly. =C2=A0=C2=A0

<= div>The trailing of OAuth 2.0 messes up Rfcmarkup.

I am looking at fixing PIXE for the RFC editor so this happens to be a cur= rent issue for me, as I did the same thing because that is what produces th= e best HTML output from XML2RFC.

What I have learn= ed is to NOT format looking at the html output from XML2RFC as it leads you= in the wrong direction, =C2=A0output as text then run through Rfcmarkup to= see what the version on the document tracker will look like.
Hope this saves you some time.

John B.=


On Jul 19, 2015, at 7:05 AM, Justin Richer <jricher@mit.edu> wrote= :

Thanks, those are artifacts in the rendered XML, I=E2=80=99ll l= ook into fixing them.

=C2=A0=E2=80=94 Justin
<= br>
On Jul 19, 2015, at 3:24 AM, Aaron P= arecki <aaron@par= ecki.com> wrote:

In section 2.2,= =C2=A0https://tools.ietf.org/html/draft-ietf-o= auth-introspection-11#section-2.2 the "scope" description ref= erences section 3.3 of RFC6749, but the hyperlink contains just the fragmen= t #section-3.3 which then points to the current page. The same problem exis= ts with the "token_type" parameter. Additionally, I believe the t= oken type link should point to section 7.1 (https://tools.ietf.org/html/= rfc6749#section-7.1) which is where token types are defined. Thanks!
----
Aaron Parecki


______________________= _________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailm= an/listinfo/oauth

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


--047d7b86d50251f6dc051b3b8e41-- From nobody Sun Jul 19 10:59:23 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECAF1B2AFB for ; Sun, 19 Jul 2015 10:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fwp6Wd6I3sDG for ; Sun, 19 Jul 2015 10:59:19 -0700 (PDT) Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com [209.85.213.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C3971B2AFA for ; Sun, 19 Jul 2015 10:59:19 -0700 (PDT) Received: by iggf3 with SMTP id f3so67794334igg.1 for ; Sun, 19 Jul 2015 10:59:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=ZbVUlHCEhF58b4MJ2ubwr+HObi7kx2cRARsiGFY5/SY=; b=XdKmg0ip49CSHF6cB/4XTKU74NjL82NQZ9MfjLiAkFXOjWgUeiPcvioWTJzMy46BVo RUrXSX8FV1ADMM+ug8S63cqmbBTUH0CffBOqTlCyyzsS7BtrUUSxHVpqwSHGfhqLrcAy 18svs94rZ9hpeI6nawERJkUoCWt58xNHLieyyLWffyh4QssF+RbfPkU/ika3ozNUueqo VYkMFqdhvsGPncOWz8FMlbio+boo19SFilM/uWFTXI1n209hNLgQxKhn1XiJipilfyct 7VeVG3FGPe8i/Zy4GNdUUvs7BTyHsrjdh441oDSz6/h9EgNj5KBg8ek3oH98VoXWxJDQ cgJw== X-Gm-Message-State: ALoCoQlhn5bcpp6bVDVWyMpNIFgHdFds/3HrvPQ0GlkhymzrTvQxK20t1PWdrZjuWsxEMX0/L+WU X-Received: by 10.107.13.201 with SMTP id 192mr30512999ion.70.1437328758640; Sun, 19 Jul 2015 10:59:18 -0700 (PDT) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com. [209.85.213.182]) by smtp.gmail.com with ESMTPSA id x3sm3631040igl.2.2015.07.19.10.59.17 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Jul 2015 10:59:17 -0700 (PDT) Received: by iggf3 with SMTP id f3so67794146igg.1 for ; Sun, 19 Jul 2015 10:59:17 -0700 (PDT) X-Received: by 10.107.28.67 with SMTP id c64mr8380306ioc.90.1437328757391; Sun, 19 Jul 2015 10:59:17 -0700 (PDT) MIME-Version: 1.0 References: <0F2B6432-4D9E-4277-BFFE-5F0354A6D9B7@mit.edu> In-Reply-To: <0F2B6432-4D9E-4277-BFFE-5F0354A6D9B7@mit.edu> From: Aaron Parecki Date: Sun, 19 Jul 2015 17:59:16 +0000 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=001a113fd404028b45051b3e2e9b Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Token introspection for public clients? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 17:59:21 -0000 --001a113fd404028b45051b3e2e9b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable How are public clients supposed to authenticate if there is no secret? Isn't "fishing for valid tokens" just as much of an issue at the resource server? I don't see how having the introspection endpoint require client authentication actually solves the fishing problem since attackers could just fish against the resource server. In fact, if the resource server queries the introspection endpoint to check if tokens are valid, then that effectively gives an attacker a way to fish for tokens using the resource server's credentials. --- Aaron Parecki http://aaronparecki.com On Sat, Jul 18, 2015 at 10:04 PM Justin Richer wrote: > Public clients can use the token-based auth mechanism, can=E2=80=99t they= ? If you > don=E2=80=99t have some form of authentication on the introspection endpo= int, you > end up with a way for people to anonymously and programmatically fish for > valid token values. > > =E2=80=94 Justin > > On Jul 19, 2015, at 6:30 AM, Aaron Parecki wrote: > > The introspection draft states that the introspection endpoint MUST > require authentication of clients. It mentions either client authenticati= on > (id+secret) or a separate bearer token. > > How are public clients expected to use the token introspection endpoint? = I > didn't see a note in the document about that at all. > > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --001a113fd404028b45051b3e2e9b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable How are public clients supposed to authenticate if there is no secret?
<= br>Isn't "fishing for valid tokens" just as much of an issue = at the resource server? I don't see how having the introspection endpoi= nt require client authentication actually solves the fishing problem since = attackers could just fish against the resource server. In fact, if the reso= urce server queries the introspection endpoint to check if tokens are valid= , then that effectively gives an attacker a way to fish for tokens using th= e resource server's credentials.

---
Aaron Parecki
http://aaronparecki.com

On Sat, Jul 18, 2015 at 10:04 PM Justin Richer <jricher@mit.edu> wrote= :
Pub= lic clients can use the token-based auth mechanism, can=E2=80=99t they? If = you don=E2=80=99t have some form of authentication on the introspection end= point, you end up with a way for people to anonymously and programmatically= fish for valid token values.=C2=A0

=C2=A0=E2=80=94 Just= in

On Jul 19, 2015, at 6:30 AM, Aaron Parecki <aaron@parecki.com> wrote:

=
The introspection dr= aft states that the introspection endpoint MUST require authentication of c= lients. It mentions either client authentication (id+secret) or a separate = bearer token.

How are public clients expected to u= se the token introspection endpoint? I didn't see a note in the documen= t about that at all.

=
----
Aaron Parecki=

_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth
--001a113fd404028b45051b3e2e9b-- From nobody Sun Jul 19 12:14:18 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10AE51B2BA8 for ; Sun, 19 Jul 2015 12:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RUDvDRQQZI6 for ; Sun, 19 Jul 2015 12:14:14 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC3A41A8907 for ; Sun, 19 Jul 2015 12:14:13 -0700 (PDT) X-AuditID: 1209190d-f796f6d000005314-29-55abf7041126 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id F8.D7.21268.407FBA55; Sun, 19 Jul 2015 15:14:12 -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 t6JJEBqE001680; Sun, 19 Jul 2015 15:14:12 -0400 Received: from [10.55.4.208] ([31.30.2.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t6JJE8k4008525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 19 Jul 2015 15:14:10 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_F27B395E-A956-4EAA-90AD-9863DDCD014E" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Justin Richer In-Reply-To: Date: Sun, 19 Jul 2015 21:14:05 +0200 Message-Id: References: <0F2B6432-4D9E-4277-BFFE-5F0354A6D9B7@mit.edu> To: Aaron Parecki X-Mailer: Apple Mail (2.2102) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42IRYrdT0WX5vjrU4MY/BYtzq9wsTr59xebA 5LFkyU8mj4aZaQFMUVw2Kak5mWWpRfp2CVwZ3x4EF3xJqOg4foS9gfFqUBcjJ4eEgIlE49+l jBC2mMSFe+vZuhi5OIQEFjNJnFy4iBXC2cgo8enEZGYIZwWTxLxlG5lBWpgFEiRWX3jADmLz CuhJ9Jz7AjZKWMBeYvHKx6wgNpuAqsT0NS1MIDanQKDE1pfbwOIsQPGXH94C2RxAc9Ql2k+6 QIyxknjz+zjU4iOMEiePnQDrFQGqv9bYBnWqrMTWN61MExgFZiE5YxaSMyDi2hLLFr5mhrA1 JfZ3L2fBFNeQ6Pw2kXUBI9sqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXSO93MwSvdSU0k2MoGDn lOTdwfjuoNIhRgEORiUe3gnfVoUKsSaWFVfmHmKU5GBSEuW94rw6VIgvKT+lMiOxOCO+qDQn tfgQowQHs5IIb2AgUI43JbGyKrUoHyYlzcGiJM676QdfiJBAemJJanZqakFqEUxWhoNDSYL3 zVegRsGi1PTUirTMnBKENBMHJ8hwHqDhAt9AhhcXJOYWZ6ZD5E8xKkqJ884EaRYASWSU5sH1 wpLRK0ZxoFeEeYVB2nmAiQyu+xXQYCagwZ2rV4AMLklESEk1MFqGrLU0TUt5bDh1avaX+hPX U4w4j/H/V7rGlmCh9Oh/+u+0DHXjrGifmRVe62Xsgz8UzL/3e+1T+TexcZ0y33fKMnak2X7a HZrEL+G8oyzz/X3/irMHbz2bneFQ8pD7cvJjPa7qNVG5fXXRrXw2s7YXcXs5btMOUSsLX68g 9lFv28GD/i2/lFiKMxINtZiLihMBRbhyHSEDAAA= Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Token introspection for public clients? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 19:14:17 -0000 --Apple-Mail=_F27B395E-A956-4EAA-90AD-9863DDCD014E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In the case of a =E2=80=9Cpublic client=E2=80=9D using a token, the = authorization is the token that the resource server uses to call the = introspection endpoint, along side the token that it is introspecting. = This is exactly how the UMA protocol works: the resource server has a = =E2=80=9CProtection API Token=E2=80=9D that it uses to call several = endpoints at the AS, including the introspection endpoint. In UMA, this = PAT is given to the resource server through a normal OAuth transaction = with an end user who facilitates the RS->AS introduction. And I think this is all actually a moot point because clients = shouldn=E2=80=99t be doing the introspection in the first place =E2=80=94 = the whole spec is there to support resource servers introspecting at the = auth server. So you probably don=E2=80=99t have =E2=80=9Cpublic client = resource servers=E2=80=9D out there. We simply re-used OAuth=E2=80=99s = existing client authentication mechanism, that doesn=E2=80=99t make them = clients. This decision is based on development and deployment experience = (as in, several people independently built it exactly this way). Do you = have a use case where you=E2=80=99ve got a protected resource that = can=E2=80=99t hold credentials (either a client secret or a = public/private keypair) to authenticate with, and can=E2=80=99t be = introduced using OAuth to the AS as in UMA? To your other point: An attacker has less of a chance of getting = information about a token by fishing at a protected resource with = tokens, since they=E2=80=99re not being returned information about the = token other than the fact that the token worked. (Or at least it seemed = to work because a result came back =E2=80=94 you could easily give a = suspected attacker valid-looking-but-fake data as one mitigation = mechanism.) The introspection response can give you information about = where else the token could be used, potentially. Additionally, the RS = really ought to be preventing data-fishing attacks like this just for = its own sake anyway. There are lots of techniques for doing this, but = they tend to be specific to the kind of API that=E2=80=99s being served. Requiring the resource server to authenticate with the authorization = server also allows you to do a few other useful things. Our = implementation, for example, limits the token information that is = returned to a particular AS. This allows us to have tokens that can be = used in multiple RS=E2=80=99s without those RS=E2=80=99s ever even = knowing the token is powerful enough to be used elsewhere. It prevents = information about the authorization from leaking to parties who have no = business knowing. Hope this helps clarify it, =E2=80=94 Justin > On Jul 19, 2015, at 7:59 PM, Aaron Parecki wrote: >=20 > How are public clients supposed to authenticate if there is no secret? >=20 > Isn't "fishing for valid tokens" just as much of an issue at the = resource server? I don't see how having the introspection endpoint = require client authentication actually solves the fishing problem since = attackers could just fish against the resource server. In fact, if the = resource server queries the introspection endpoint to check if tokens = are valid, then that effectively gives an attacker a way to fish for = tokens using the resource server's credentials.=20 >=20 > --- > Aaron Parecki > http://aaronparecki.com >=20 > On Sat, Jul 18, 2015 at 10:04 PM Justin Richer > wrote: > Public clients can use the token-based auth mechanism, can=E2=80=99t = they? If you don=E2=80=99t have some form of authentication on the = introspection endpoint, you end up with a way for people to anonymously = and programmatically fish for valid token values.=20 >=20 > =E2=80=94 Justin >=20 >=20 >> On Jul 19, 2015, at 6:30 AM, Aaron Parecki > wrote: >>=20 >=20 >> The introspection draft states that the introspection endpoint MUST = require authentication of clients. It mentions either client = authentication (id+secret) or a separate bearer token. >>=20 >> How are public clients expected to use the token introspection = endpoint? I didn't see a note in the document about that at all. >>=20 >=20 >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 --Apple-Mail=_F27B395E-A956-4EAA-90AD-9863DDCD014E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 In the case of a =E2=80=9Cpublic client=E2=80=9D using a = token, the authorization is the token that the resource server uses to = call the introspection endpoint, along side the token that it is = introspecting. This is exactly how the UMA protocol works: the resource = server has a =E2=80=9CProtection API Token=E2=80=9D that it uses to call = several endpoints at the AS, including the introspection endpoint. In = UMA, this PAT is given to the resource server through a normal OAuth = transaction with an end user who facilitates the RS->AS = introduction.

And I = think this is all actually a moot point because clients = shouldn=E2=80=99t be doing the introspection in the first place =E2=80=94 = the whole spec is there to support resource servers = introspecting at the auth server. So you probably don=E2=80=99t have = =E2=80=9Cpublic client resource servers=E2=80=9D out there. We simply = re-used OAuth=E2=80=99s existing client authentication mechanism, that = doesn=E2=80=99t make them clients. This decision is based on development = and deployment experience (as in, several people independently built it = exactly this way). Do you have a use case where you=E2=80=99ve got a = protected resource that can=E2=80=99t hold credentials (either a client = secret or a public/private keypair) to authenticate with, and can=E2=80=99= t be introduced using OAuth to the AS as in UMA?

To your other point: An attacker has = less of a chance of getting information about a token by fishing at a = protected resource with tokens, since they=E2=80=99re not being returned = information about the token other than the fact that the token worked. = (Or at least it seemed to work because a result came back =E2=80=94 you = could easily give a suspected attacker valid-looking-but-fake data as = one mitigation mechanism.) The introspection response can give you = information about where else the token could be used, potentially. = Additionally, the RS really ought to be preventing data-fishing attacks = like this just for its own sake anyway. There are lots of techniques for = doing this, but they tend to be specific to the kind of API that=E2=80=99s= being served.

Requiring the resource server to authenticate with the = authorization server also allows you to do a few other useful things. = Our implementation, for example, limits the token information that is = returned to a particular AS. This allows us to have tokens that can be = used in multiple RS=E2=80=99s without those RS=E2=80=99s ever even = knowing the token is powerful enough to be used elsewhere. It prevents = information about the authorization from leaking to parties who have no = business knowing.

Hope this helps clarify it,
 =E2=80=94= Justin

On Jul 19, 2015, at 7:59 PM, Aaron Parecki = <aaron@parecki.com> wrote:

How are public clients supposed to authenticate if there is = no secret?

Isn't "fishing for valid tokens" = just as much of an issue at the resource server? I don't see how having = the introspection endpoint require client authentication actually solves = the fishing problem since attackers could just fish against the resource = server. In fact, if the resource server queries the introspection = endpoint to check if tokens are valid, then that effectively gives an = attacker a way to fish for tokens using the resource server's = credentials.

---
Aaron = Parecki
http://aaronparecki.com

On Sat, Jul 18, 2015 at 10:04 PM Justin Richer = <jricher@mit.edu> wrote:
Public clients can use the token-based auth mechanism, = can=E2=80=99t they? If you don=E2=80=99t have some form of = authentication on the introspection endpoint, you end up with a way for = people to anonymously and programmatically fish for valid token = values. 

 =E2=80=94 Justin

On Jul = 19, 2015, at 6:30 AM, Aaron Parecki <aaron@parecki.com> wrote:

The introspection draft states = that the introspection endpoint MUST require authentication of clients. = It mentions either client authentication (id+secret) or a separate = bearer token.

How are public clients expected to use the token = introspection endpoint? I didn't see a note in the document about that = at all.

----
Aaron Parecki
aaronparecki.com
@aaronpk

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


= --Apple-Mail=_F27B395E-A956-4EAA-90AD-9863DDCD014E-- From nobody Sun Jul 19 13:43:49 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A13961B2C1C for ; Sun, 19 Jul 2015 13:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejkeUmsS80kF for ; Sun, 19 Jul 2015 13:43:46 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB17F1B2C1B for ; Sun, 19 Jul 2015 13:43:45 -0700 (PDT) X-AuditID: 1209190e-f79c76d000002631-a3-55ac0c00462c Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 7F.31.09777.00C0CA55; Sun, 19 Jul 2015 16:43:44 -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 t6JKhh7P007760; Sun, 19 Jul 2015 16:43:44 -0400 Received: from [10.55.4.208] ([31.30.2.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t6JKhebE027777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 19 Jul 2015 16:43:42 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_9634FCC5-6B6B-45DF-8B1B-590A59AABC58" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Justin Richer In-Reply-To: Date: Sun, 19 Jul 2015 22:43:37 +0200 Message-Id: <5B453523-6B93-46A8-B5F7-24886CBBED4B@mit.edu> References: To: Brian Campbell X-Mailer: Apple Mail (2.2102) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGKsWRmVeSWpSXmKPExsUixG6nosvAsybUYMYRdYtDiy+xWqz+f5PR 4uTbV2wWq+/+ZXNg8WhZ1cvssWTJTyaPu0cvsnjcvr2RJYAlissmJTUnsyy1SN8ugSujZcJK toIjXhUTWlcxNzDOdexi5OSQEDCR+LBmNyuELSZx4d56ti5GLg4hgcVMEk9bVkM5Gxklps8/ xw7hrGCSOL2jnw2khVkgQWLV25VgNq+AnkTPuS+MILawgKfE/YVvweJsAqoS09e0MIHYnAKB EnvXn2IHsVmA4m+6Wxgh5lRKnJ7Xzw4xx0ri4aeNUMu+MUr0L58J1iwioC9x++kcdohbZSW2 vmllmsAoMAvJHbOQ3AER15ZYtvA1M4StKbG/ezkLpriGROe3iawLGNlWMcqm5Fbp5iZm5hSn JusWJyfm5aUW6Rrr5WaW6KWmlG5iBEUHpyTfDsavB5UOMQpwMCrx8Ar8XR0qxJpYVlyZe4hR koNJSZT3ijNQiC8pP6UyI7E4I76oNCe1+BCjBAezkghvYCBQjjclsbIqtSgfJiXNwaIkzrvp B1+IkEB6YklqdmpqQWoRTFaGg0NJgleea02okGBRanpqRVpmTglCmomDE2Q4D9DwRpAa3uKC xNzizHSI/ClGRSlxXheQhABIIqM0D64XlrxeMYoDvSLMOxGkigeY+OC6XwENZgIa3Ll6Bcjg kkSElFQDY5euSpaMwqnSBcqXm04vsFBb17/R0arqZMsu+8pVE4JSdes9txw5tph54upJXQnX z2nkPuhcPP+nFIf8nHrtJztEpq22CxaaF3MvY9PLJ9Iry47wfQzrsItP/NMzwejTp6zWrI19 ZS+Xek8td9JYv07p2Bfl7eryMTyij5wetiwJ45/1/G9gmhJLcUaioRZzUXEiAGaNjrM5AwAA Archived-At: Cc: Barry Leiba , "" Subject: Re: [OAUTH-WG] broken links in draft-ietf-oauth-introspection-11 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 20:43:48 -0000 --Apple-Mail=_9634FCC5-6B6B-45DF-8B1B-590A59AABC58 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the pointers everyone, that should now be fixed in the copy = in GitHub. I=E2=80=99ll publish a new draft this week sometime, after = confirming the clearance of the final IESG DISCUSS. =E2=80=94 Justin > On Jul 19, 2015, at 4:50 PM, Brian Campbell = wrote: >=20 > Barry explained the tools issue that causes this and how to work = around it a while back on the JOSE list: = http://www.ietf.org/mail-archive/web/jose/current/msg04571.html = >=20 > On Sun, Jul 19, 2015 at 2:09 PM, John Bradley > wrote: > Remember tools is not using the XML to render the HTML directly, it is = marking up the text version. This bites me all the time as well. >=20 > The text version needs to render to =E2=80=9CSection 3.3 of RFC = 6749=E2=80=9D to get Rfcmarkup tool = to render it correctly. =20= >=20 > The trailing of OAuth 2.0 messes up Rfcmarkup. >=20 > I am looking at fixing PIXE for the RFC editor so this happens to be a = current issue for me, as I did the same thing because that is what = produces the best HTML output from XML2RFC. >=20 > What I have learned is to NOT format looking at the html output from = XML2RFC as it leads you in the wrong direction, output as text then run = through Rfcmarkup to see what the version on the document tracker will = look like. >=20 > Hope this saves you some time. >=20 > John B. >=20 >=20 >> On Jul 19, 2015, at 7:05 AM, Justin Richer > wrote: >>=20 >> Thanks, those are artifacts in the rendered XML, I=E2=80=99ll look = into fixing them. >>=20 >> =E2=80=94 Justin >>=20 >>> On Jul 19, 2015, at 3:24 AM, Aaron Parecki > wrote: >>>=20 >>> In section 2.2, = https://tools.ietf.org/html/draft-ietf-oauth-introspection-11#section-2.2 = the "scope" description references section 3.3 of RFC6749, but the = hyperlink contains just the fragment #section-3.3 which then points to = the current page. The same problem exists with the "token_type" = parameter. Additionally, I believe the token type link should point to = section 7.1 (https://tools.ietf.org/html/rfc6749#section-7.1 = ) which is where token = types are defined. Thanks! >>>=20 >>> ---- >>> Aaron Parecki >>> aaronparecki.com >>> @aaronpk >>>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 --Apple-Mail=_9634FCC5-6B6B-45DF-8B1B-590A59AABC58 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for the pointers everyone, that should now be fixed in = the copy in GitHub. I=E2=80=99ll publish a new draft this week sometime, = after confirming the clearance of the final IESG DISCUSS.

 =E2=80=94 = Justin

On Jul 19, 2015, at 4:50 PM, Brian Campbell = <bcampbell@pingidentity.com> wrote:

Barry explained the tools issue = that causes this and how to work around it a while back on the JOSE = list: http://www.ietf.org/mail-archive/web/jose/current/msg04571.html=

On Sun, Jul 19, 2015 at 2:09 PM, John Bradley = <ve7jtb@ve7jtb.com> wrote:
Remember tools is not using = the XML to render the HTML directly, it is marking up the text version. =   This bites me all the time as well.

The text version needs to render to = =E2=80=9CSection 3.3 of RFC 6749=E2=80=9D to get Rfcmarkup tool to render it correctly. =   

The= trailing of OAuth 2.0 messes up Rfcmarkup.

I am looking at fixing PIXE for the RFC = editor so this happens to be a current issue for me, as I did the same = thing because that is what produces the best HTML output from = XML2RFC.

What = I have learned is to NOT format looking at the html output from XML2RFC = as it leads you in the wrong direction,  output as text then run = through Rfcmarkup to see what the version on the document tracker will = look like.

Hope = this saves you some time.

John B.


On Jul 19, 2015, at 7:05 AM, Justin Richer = <jricher@mit.edu> wrote:

Thanks, = those are artifacts in the rendered XML, I=E2=80=99ll look into fixing = them.

 =E2=80=94 = Justin

On Jul 19, 2015, at 3:24 AM, = Aaron Parecki <aaron@parecki.com> wrote:

In section = 2.2, https://tools.ietf.org/html/draft-ietf-oauth-introspection-11#s= ection-2.2 the "scope" description references section 3.3 of = RFC6749, but the hyperlink contains just the fragment #section-3.3 which = then points to the current page. The same problem exists with the = "token_type" parameter. Additionally, I believe the token type link = should point to section 7.1 (https://tools.ietf.org/html/rfc6749#section-7.1) which = is where token types are defined. Thanks!

----
Aaron Parecki
aaronparecki.com
@aaronpk


_______________________________________= ________
OAuth mailing 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=_9634FCC5-6B6B-45DF-8B1B-590A59AABC58-- From nobody Sun Jul 19 15:04:08 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882011B2DAC for ; Sun, 19 Jul 2015 15:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4A7VGZqU-QQ4 for ; Sun, 19 Jul 2015 15:04:05 -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 D02CE1B2DAB for ; Sun, 19 Jul 2015 15:04:04 -0700 (PDT) Received: by qkfc129 with SMTP id c129so59792323qkf.1 for ; Sun, 19 Jul 2015 15:04:03 -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:content-type; bh=lfRUgli7THsefUXu6fZnJ5NH5VPBjMnVSDy4AJJ2QY8=; b=GFpCx1+T8ZB6B9Z+nb1Zgus+g57G7FMZElNkOlTs4mPppD0ifLZiZEI2Fc+6yEUuJ7 9T8IC+YuKYU/0B0i40KjlsKd0zLgNHcxgWkJZWrSQoUfd1IVjPXyy4manwkoKN2m1xIx YDS/AaUAFVtyrgpiFCse30z0AXWcLaR2DI+nOdpKlI0C6zOpu8kvvLqbO78NTe9nQMGS PIIzVOlqu1+RRw8Sj6kECTUkR+skjyNLlFfzNZ5fkrdZZ20Cmnx/n3VBArJSDYxgYhTp pvJSHHRwrHaWY+R20mGTx0bLk0Jsoa+HI5QHsNWOtI3iazmsvk896uW/iye1GScNmFc5 p5YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=lfRUgli7THsefUXu6fZnJ5NH5VPBjMnVSDy4AJJ2QY8=; b=fE7GEFmh3Zswl0lMEz68BpifwVsHHXE5RmKmfl0XtHzMEynFJH+ikeSCZ7CaB+qfgL u6xyqf/KY1SXe7/QWDauRnXAsFacvKCue9bB+y0M+/Wzh6ZGse+ymLL33k3XP0LOj9Ry JhfghKhUC+MAi/sra/GQJ/X6UlenbT4LQt+fWNW4WlW7imv5ZPNhpcFCrZ4U5GhQ/en/ HlmpI5JNqdfUaq6T90flirqDGQDVP9Pq7A+ESNi7peAfsYmyWmNOBSs7RY1NqDNes3b3 cr1GHXNOU0w+/tCtFivOP4enMVSO8dqVB42BCrdFzp0vebxd/syG95GLSq2g2pmYAfyo jt3A== X-Gm-Message-State: ALoCoQlCd9ehAY2HH4LZ/VTWPVTCIPX4M517yr4TpI+bfV3N7J2nBUaTXlwza/W5LCJOZhWzhIlT X-Received: by 10.141.28.147 with SMTP id f141mr36379157qhe.91.1437343443625; Sun, 19 Jul 2015 15:04:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.19.98 with HTTP; Sun, 19 Jul 2015 15:03:44 -0700 (PDT) In-Reply-To: References: <0F2B6432-4D9E-4277-BFFE-5F0354A6D9B7@mit.edu> From: William Denniss Date: Mon, 20 Jul 2015 00:03:44 +0200 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=001a114238b060de90051b419988 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Token introspection for public clients? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 22:04:07 -0000 --001a114238b060de90051b419988 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I see in earlier drafts that client authentication MUST was a SHOULD. Why not put it back to a SHOULD, and make these arguments in the Security Considerations? By the sound of it in some implementations there are good reasons for doing client authentication, but they may not apply to everyone, so do we need to be so prescriptive? An error response can be added for requests the server deems require client authentication. It wouldn't have to be an all-or-nothing policy choice either, a server could chose to reject requests from confidential clients where client authentication is not provided, but accept requests without client authentication from non-confidential clients. A server that has sufficiently high entropy in the tokens, abuse protection on the endpoint, and is not concerned about an unrelated party (that happens to have a token intended for a different party) learning the token metadata, could simply not require any client authentication at all. Apart from anything, it is really trivial to support non-confidential client usage, so why not? Perhaps there are some use-cases that will turn up in the future (especially since as defined the introspection response is extensible). One I can think of now is debugging: it's useful during development to be able to inspect the tokens you get back from the AS. Best, William On Sun, Jul 19, 2015 at 9:14 PM, Justin Richer wrote: > In the case of a =E2=80=9Cpublic client=E2=80=9D using a token, the autho= rization is the > token that the resource server uses to call the introspection endpoint, > along side the token that it is introspecting. This is exactly how the UM= A > protocol works: the resource server has a =E2=80=9CProtection API Token= =E2=80=9D that it > uses to call several endpoints at the AS, including the introspection > endpoint. In UMA, this PAT is given to the resource server through a norm= al > OAuth transaction with an end user who facilitates the RS->AS introductio= n. > > And I think this is all actually a moot point because *clients* shouldn= =E2=80=99t > be doing the introspection in the first place =E2=80=94 the whole spec is= there to > support *resource servers* introspecting at the auth server. So you > probably don=E2=80=99t have =E2=80=9Cpublic client resource servers=E2=80= =9D out there. We simply > re-used OAuth=E2=80=99s existing client authentication mechanism, that do= esn=E2=80=99t make > them clients. This decision is based on development and deployment > experience (as in, several people independently built it exactly this way= ). > Do you have a use case where you=E2=80=99ve got a protected resource that= can=E2=80=99t > hold credentials (either a client secret or a public/private keypair) to > authenticate with, and can=E2=80=99t be introduced using OAuth to the AS = as in UMA? > > To your other point: An attacker has less of a chance of getting > information about a token by fishing at a protected resource with tokens, > since they=E2=80=99re not being returned information about the token othe= r than the > fact that the token worked. (Or at least it seemed to work because a resu= lt > came back =E2=80=94 you could easily give a suspected attacker > valid-looking-but-fake data as one mitigation mechanism.) The introspecti= on > response can give you information about where else the token could be use= d, > potentially. Additionally, the RS really ought to be preventing > data-fishing attacks like this just for its own sake anyway. There are lo= ts > of techniques for doing this, but they tend to be specific to the kind of > API that=E2=80=99s being served. > > Requiring the resource server to authenticate with the authorization > server also allows you to do a few other useful things. Our implementatio= n, > for example, limits the token information that is returned to a particula= r > AS. This allows us to have tokens that can be used in multiple RS=E2=80= =99s without > those RS=E2=80=99s ever even knowing the token is powerful enough to be u= sed > elsewhere. It prevents information about the authorization from leaking t= o > parties who have no business knowing. > > Hope this helps clarify it, > =E2=80=94 Justin > > On Jul 19, 2015, at 7:59 PM, Aaron Parecki wrote: > > How are public clients supposed to authenticate if there is no secret? > > Isn't "fishing for valid tokens" just as much of an issue at the resource > server? I don't see how having the introspection endpoint require client > authentication actually solves the fishing problem since attackers could > just fish against the resource server. In fact, if the resource server > queries the introspection endpoint to check if tokens are valid, then tha= t > effectively gives an attacker a way to fish for tokens using the resource > server's credentials. > > --- > Aaron Parecki > http://aaronparecki.com > > On Sat, Jul 18, 2015 at 10:04 PM Justin Richer wrote: > >> Public clients can use the token-based auth mechanism, can=E2=80=99t the= y? If you >> don=E2=80=99t have some form of authentication on the introspection endp= oint, you >> end up with a way for people to anonymously and programmatically fish fo= r >> valid token values. >> >> =E2=80=94 Justin >> >> On Jul 19, 2015, at 6:30 AM, Aaron Parecki wrote: >> >> The introspection draft states that the introspection endpoint MUST >> require authentication of clients. It mentions either client authenticat= ion >> (id+secret) or a separate bearer token. >> >> How are public clients expected to use the token introspection endpoint? >> I didn't see a note in the document about that at all. >> >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a114238b060de90051b419988 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I see in earlier drafts that client authentication MUST wa= s a SHOULD.

Why not put it back to a SHOULD, and make th= ese arguments in the Security Considerations?=C2=A0 By the sound of it in s= ome implementations there are good reasons for doing client authentication,= but they may not apply to everyone, so do we need to be so prescriptive?= =C2=A0 An error response can be added for requests the server deems require= client authentication.

It wouldn't have to be= an all-or-nothing policy choice either, a server could chose to reject req= uests from confidential clients where client authentication is not provided= , but accept requests without client authentication from non-confidential c= lients.=C2=A0 A server that has sufficiently high entropy in the tokens, ab= use protection on the endpoint, and is not concerned about an unrelated par= ty (that happens to have a token intended for a different party) learning t= he token metadata, could simply not require any client authentication at al= l.

Apart from anything, it is really trivial to su= pport non-confidential client usage, so why not?=C2=A0 Perhaps there are so= me use-cases that will turn up in the future (especially since as defined t= he introspection response is extensible). One I can think of now is debuggi= ng: it's useful during development to be able to inspect the tokens you= get back from the AS.

Best,
William=


On Sun, Jul 19, 2015 at 9:14 PM, Justin Richer <jricher@mit.edu><= /span> wrote:
In the case of a =E2=80=9Cpublic client=E2=80=9D using a token, th= e authorization is the token that the resource server uses to call the intr= ospection endpoint, along side the token that it is introspecting. This is = exactly how the UMA protocol works: the resource server has a =E2=80=9CProt= ection API Token=E2=80=9D that it uses to call several endpoints at the AS,= including the introspection endpoint. In UMA, this PAT is given to the res= ource server through a normal OAuth transaction with an end user who facili= tates the RS->AS introduction.

And I think this is al= l actually a moot point because clients shouldn=E2=80=99t be doing t= he introspection in the first place =E2=80=94 the whole spec is there to su= pport resource servers introspecting at the auth server. So you prob= ably don=E2=80=99t have =E2=80=9Cpublic client resource servers=E2=80=9D ou= t there. We simply re-used OAuth=E2=80=99s existing client authentication m= echanism, that doesn=E2=80=99t make them clients. This decision is based on= development and deployment experience (as in, several people independently= built it exactly this way). Do you have a use case where you=E2=80=99ve go= t a protected resource that can=E2=80=99t hold credentials (either a client= secret or a public/private keypair) to authenticate with, and can=E2=80=99= t be introduced using OAuth to the AS as in UMA?

To your= other point: An attacker has less of a chance of getting information about= a token by fishing at a protected resource with tokens, since they=E2=80= =99re not being returned information about the token other than the fact th= at the token worked. (Or at least it seemed to work because a result came b= ack =E2=80=94 you could easily give a suspected attacker valid-looking-but-= fake data as one mitigation mechanism.) The introspection response can give= you information about where else the token could be used, potentially. Add= itionally, the RS really ought to be preventing data-fishing attacks like t= his just for its own sake anyway. There are lots of techniques for doing th= is, but they tend to be specific to the kind of API that=E2=80=99s being se= rved.

Requiring the resource server to authenticat= e with the authorization server also allows you to do a few other useful th= ings. Our implementation, for example, limits the token information that is= returned to a particular AS. This allows us to have tokens that can be use= d in multiple RS=E2=80=99s without those RS=E2=80=99s ever even knowing the= token is powerful enough to be used elsewhere. It prevents information abo= ut the authorization from leaking to parties who have no business knowing.<= /div>

Hope this helps clarify it,
=C2=A0=E2=80= =94 Justin

On Jul 19, 2015, at 7:59 PM, Aaron Parecki <aaron@parecki.com> wrote:

How are public clients supposed to authenticate i= f there is no secret?

Isn't "fishing for valid tokens"= just as much of an issue at the resource server? I don't see how havin= g the introspection endpoint require client authentication actually solves = the fishing problem since attackers could just fish against the resource se= rver. In fact, if the resource server queries the introspection endpoint to= check if tokens are valid, then that effectively gives an attacker a way t= o fish for tokens using the resource server's credentials.

---<= br>Aaron Parecki
http://aaronparecki.com

On Sat, Jul 18, 2015 at 10:04 PM Justin Richer <jricher@mit.edu> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Public cl= ients can use the token-based auth mechanism, can=E2=80=99t they? If you do= n=E2=80=99t have some form of authentication on the introspection endpoint,= you end up with a way for people to anonymously and programmatically fish = for valid token values.=C2=A0

=C2=A0=E2=80=94 Justin

= On Jul 19, 2015, at 6:30 AM, Aaron Parecki <aaron@parecki.com> wrote:

The introspection draft st= ates that the introspection endpoint MUST require authentication of clients= . It mentions either client authentication (id+secret) or a separate bearer= token.

How are public clients expected to use the= token introspection endpoint? I didn't see a note in the document abou= t that at all.

=
----
Aaron Parecki
<= div>aaronparecki.com=

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


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


--001a114238b060de90051b419988-- From nobody Sun Jul 19 22:01:45 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B561B2F9C for ; Sun, 19 Jul 2015 22:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bA8BJEDi0rFi for ; Sun, 19 Jul 2015 22:01:39 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB0721B2F9D for ; Sun, 19 Jul 2015 22:01:38 -0700 (PDT) X-AuditID: 1209190d-f796f6d000005314-c8-55ac80b00e97 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 0C.23.21268.1B08CA55; Mon, 20 Jul 2015 01:01:37 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t6K51adY008261; Mon, 20 Jul 2015 01:01:36 -0400 Received: from [10.55.4.208] ([31.30.2.5]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t6K51X7E004298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 20 Jul 2015 01:01:34 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_16215BF5-B8CB-4119-B8CA-03513E4071D0" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Justin Richer In-Reply-To: Date: Mon, 20 Jul 2015 07:01:30 +0200 Message-Id: <89B75723-0C59-4AF3-BC8E-166A63ED39EB@mit.edu> References: <0F2B6432-4D9E-4277-BFFE-5F0354A6D9B7@mit.edu> To: William Denniss X-Mailer: Apple Mail (2.2102) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBKsWRmVeSWpSXmKPExsUixCmqrLuxYU2owYH3LBbnVrlZnHz7is1i 05xmdgdmjwWbSj2WLPnJ5NEwMy2AOYrLJiU1J7MstUjfLoEr4+dOsYJlUxgrDjc8Y2tgXFvX xcjJISFgInF26Ql2CFtM4sK99WxdjFwcQgKLmSRuTbsE5WxklJi5chM7hLOcSaL12iRWkBZm gQSJTY8eM4HYvAJ6Ej3nvjCC2MIC9hKLVz4Gq2ETUJWYv/IWUA0HB6dAoETrS3uQMAtQuOPQ exaIMV4SJ+9PZ4YYYyUxZ9JPqMU7mCQmfNsBNl9EQFPi5dkDLBCnykpsfdPKNIFRYBaSM2Yh OQMiri2xbOFrZghbU2J/93IWTHENic5vE1kXMLKtYpRNya3SzU3MzClOTdYtTk7My0st0jXS y80s0UtNKd3ECI4ASd4djO8OKh1iFOBgVOLhFfi7OlSINbGsuDL3EKMkB5OSKG+z9JpQIb6k /JTKjMTijPii0pzU4kOMEhzMSiK8vPFAOd6UxMqq1KJ8mJQ0B4uSOO+mH3whQgLpiSWp2amp BalFMFkZDg4lCd6yeqBGwaLU9NSKtMycEoQ0EwcnyHAeoOHvQGp4iwsSc4sz0yHypxgVpcR5 94MkBEASGaV5cL2wBPWKURzoFWFeEWC6EuIBJje47ldAg5mABneuXgEyuCQRISXVwJi42abs 0vLg0OKSU+dsNRTXN11VYHz7qv54ynqrG/rzZ+X9FJU7bKz+fUray1liB3j6d6rOCcvLeXKm qXHmzdDntTvqb/1UCVTNe241K/DFbvMy5SyhLxYbRQ9K2mj8f7jO5cWFM9zLTrs2bLl1VeJS SOmTlx8spVu+VIr7LBe+6Ga0gDVK6ZsSS3FGoqEWc1FxIgAbIjLSKwMAAA== Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Token introspection for public clients? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 05:01:43 -0000 --Apple-Mail=_16215BF5-B8CB-4119-B8CA-03513E4071D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Because the target isn=E2=80=99t the client, it=E2=80=99s the protected = resource. We=E2=80=99re re-using OAuth=E2=80=99s client credentialing = mechanisms (optionally, you can use whatever you deem necessary), but = it=E2=80=99s not a client that=E2=80=99s doing it. That=E2=80=99s why it = was changed to a MUST =E2=80=94 there may be public clients out there = (which could also use RFC7591 to become non-public), but public resource = servers don=E2=80=99t make nearly as much sense. Additionally, the discussion for this was back in December during the = WGLC, and the time for normative changes to this particular spec is = largely over at this stage. =E2=80=94 Justin > On Jul 20, 2015, at 12:03 AM, William Denniss = wrote: >=20 > I see in earlier drafts that client authentication MUST was a SHOULD. >=20 > Why not put it back to a SHOULD, and make these arguments in the = Security Considerations? By the sound of it in some implementations = there are good reasons for doing client authentication, but they may not = apply to everyone, so do we need to be so prescriptive? An error = response can be added for requests the server deems require client = authentication. >=20 > It wouldn't have to be an all-or-nothing policy choice either, a = server could chose to reject requests from confidential clients where = client authentication is not provided, but accept requests without = client authentication from non-confidential clients. A server that has = sufficiently high entropy in the tokens, abuse protection on the = endpoint, and is not concerned about an unrelated party (that happens to = have a token intended for a different party) learning the token = metadata, could simply not require any client authentication at all. >=20 > Apart from anything, it is really trivial to support non-confidential = client usage, so why not? Perhaps there are some use-cases that will = turn up in the future (especially since as defined the introspection = response is extensible). One I can think of now is debugging: it's = useful during development to be able to inspect the tokens you get back = from the AS. >=20 > Best, > William >=20 >=20 > On Sun, Jul 19, 2015 at 9:14 PM, Justin Richer > wrote: > In the case of a =E2=80=9Cpublic client=E2=80=9D using a token, the = authorization is the token that the resource server uses to call the = introspection endpoint, along side the token that it is introspecting. = This is exactly how the UMA protocol works: the resource server has a = =E2=80=9CProtection API Token=E2=80=9D that it uses to call several = endpoints at the AS, including the introspection endpoint. In UMA, this = PAT is given to the resource server through a normal OAuth transaction = with an end user who facilitates the RS->AS introduction. >=20 > And I think this is all actually a moot point because clients = shouldn=E2=80=99t be doing the introspection in the first place =E2=80=94 = the whole spec is there to support resource servers introspecting at the = auth server. So you probably don=E2=80=99t have =E2=80=9Cpublic client = resource servers=E2=80=9D out there. We simply re-used OAuth=E2=80=99s = existing client authentication mechanism, that doesn=E2=80=99t make them = clients. This decision is based on development and deployment experience = (as in, several people independently built it exactly this way). Do you = have a use case where you=E2=80=99ve got a protected resource that = can=E2=80=99t hold credentials (either a client secret or a = public/private keypair) to authenticate with, and can=E2=80=99t be = introduced using OAuth to the AS as in UMA? >=20 > To your other point: An attacker has less of a chance of getting = information about a token by fishing at a protected resource with = tokens, since they=E2=80=99re not being returned information about the = token other than the fact that the token worked. (Or at least it seemed = to work because a result came back =E2=80=94 you could easily give a = suspected attacker valid-looking-but-fake data as one mitigation = mechanism.) The introspection response can give you information about = where else the token could be used, potentially. Additionally, the RS = really ought to be preventing data-fishing attacks like this just for = its own sake anyway. There are lots of techniques for doing this, but = they tend to be specific to the kind of API that=E2=80=99s being served. >=20 > Requiring the resource server to authenticate with the authorization = server also allows you to do a few other useful things. Our = implementation, for example, limits the token information that is = returned to a particular AS. This allows us to have tokens that can be = used in multiple RS=E2=80=99s without those RS=E2=80=99s ever even = knowing the token is powerful enough to be used elsewhere. It prevents = information about the authorization from leaking to parties who have no = business knowing. >=20 > Hope this helps clarify it, > =E2=80=94 Justin >=20 >> On Jul 19, 2015, at 7:59 PM, Aaron Parecki > wrote: >>=20 >> How are public clients supposed to authenticate if there is no = secret? >>=20 >> Isn't "fishing for valid tokens" just as much of an issue at the = resource server? I don't see how having the introspection endpoint = require client authentication actually solves the fishing problem since = attackers could just fish against the resource server. In fact, if the = resource server queries the introspection endpoint to check if tokens = are valid, then that effectively gives an attacker a way to fish for = tokens using the resource server's credentials.=20 >>=20 >> --- >> Aaron Parecki >> http://aaronparecki.com >>=20 >> On Sat, Jul 18, 2015 at 10:04 PM Justin Richer > wrote: >> Public clients can use the token-based auth mechanism, can=E2=80=99t = they? If you don=E2=80=99t have some form of authentication on the = introspection endpoint, you end up with a way for people to anonymously = and programmatically fish for valid token values.=20 >>=20 >> =E2=80=94 Justin >>=20 >>=20 >>> On Jul 19, 2015, at 6:30 AM, Aaron Parecki > wrote: >>>=20 >>=20 >>> The introspection draft states that the introspection endpoint MUST = require authentication of clients. It mentions either client = authentication (id+secret) or a separate bearer token. >>>=20 >>> How are public clients expected to use the token introspection = endpoint? I didn't see a note in the document about that at all. >>>=20 >>=20 >>> ---- >>> Aaron Parecki >>> aaronparecki.com >>> @aaronpk >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 --Apple-Mail=_16215BF5-B8CB-4119-B8CA-03513E4071D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Because the target isn=E2=80=99t the client, it=E2=80=99s the = protected resource. We=E2=80=99re re-using OAuth=E2=80=99s client = credentialing mechanisms (optionally, you can use whatever you deem = necessary), but it=E2=80=99s not a client that=E2=80=99s doing it. = That=E2=80=99s why it was changed to a MUST =E2=80=94 there may be = public clients out there (which could also use RFC7591 to become = non-public), but public resource servers don=E2=80=99t make nearly as = much sense.

Additionally, the discussion for this was back in December = during the WGLC, and the time for normative changes to this particular = spec is largely over at this stage.

 =E2=80=94 Justin

On Jul 20, 2015, at 12:03 AM, William Denniss <wdenniss@google.com>= wrote:

I see in earlier drafts that = client authentication MUST was a SHOULD.

Why not put it back to a SHOULD, and = make these arguments in the Security Considerations?  By the sound = of it in some implementations there are good reasons for doing client = authentication, but they may not apply to everyone, so do we need to be = so prescriptive?  An error response can be added for requests the = server deems require client authentication.

It wouldn't have to be an = all-or-nothing policy choice either, a server could chose to reject = requests from confidential clients where client authentication is not = provided, but accept requests without client authentication from = non-confidential clients.  A server that has sufficiently high = entropy in the tokens, abuse protection on the endpoint, and is not = concerned about an unrelated party (that happens to have a token = intended for a different party) learning the token metadata, could = simply not require any client authentication at all.

Apart from anything, it = is really trivial to support non-confidential client usage, so why = not?  Perhaps there are some use-cases that will turn up in the = future (especially since as defined the introspection response is = extensible). One I can think of now is debugging: it's useful during = development to be able to inspect the tokens you get back from the = AS.

Best,
William


On Sun, Jul 19, 2015 at 9:14 PM, Justin Richer = <jricher@mit.edu> wrote:
In the case of a =E2=80=9Cpublic= client=E2=80=9D using a token, the authorization is the token that the = resource server uses to call the introspection endpoint, along side the = token that it is introspecting. This is exactly how the UMA protocol = works: the resource server has a =E2=80=9CProtection API Token=E2=80=9D = that it uses to call several endpoints at the AS, including the = introspection endpoint. In UMA, this PAT is given to the resource server = through a normal OAuth transaction with an end user who facilitates the = RS->AS introduction.

And I think this is all actually a moot point because clients shouldn=E2=80=99t be doing the introspection in = the first place =E2=80=94 the whole spec is there to support resource servers introspecting at the auth server. So you = probably don=E2=80=99t have =E2=80=9Cpublic client resource servers=E2=80=9D= out there. We simply re-used OAuth=E2=80=99s existing client = authentication mechanism, that doesn=E2=80=99t make them clients. This = decision is based on development and deployment experience (as in, = several people independently built it exactly this way). Do you have a = use case where you=E2=80=99ve got a protected resource that can=E2=80=99t = hold credentials (either a client secret or a public/private keypair) to = authenticate with, and can=E2=80=99t be introduced using OAuth to the AS = as in UMA?

To your = other point: An attacker has less of a chance of getting information = about a token by fishing at a protected resource with tokens, since = they=E2=80=99re not being returned information about the token other = than the fact that the token worked. (Or at least it seemed to work = because a result came back =E2=80=94 you could easily give a suspected = attacker valid-looking-but-fake data as one mitigation mechanism.) The = introspection response can give you information about where else the = token could be used, potentially. Additionally, the RS really ought to = be preventing data-fishing attacks like this just for its own sake = anyway. There are lots of techniques for doing this, but they tend to be = specific to the kind of API that=E2=80=99s being served.

Requiring the resource = server to authenticate with the authorization server also allows you to = do a few other useful things. Our implementation, for example, limits = the token information that is returned to a particular AS. This allows = us to have tokens that can be used in multiple RS=E2=80=99s without = those RS=E2=80=99s ever even knowing the token is powerful enough to be = used elsewhere. It prevents information about the authorization from = leaking to parties who have no business knowing.

Hope this helps clarify it,
 =E2=80=94 Justin

On Jul 19, 2015, at 7:59 PM, Aaron Parecki <aaron@parecki.com> wrote:

How are public = clients supposed to authenticate if there is no secret?

Isn't "fishing for valid tokens" just as much of an issue at = the resource server? I don't see how having the introspection endpoint = require client authentication actually solves the fishing problem since = attackers could just fish against the resource server. In fact, if the = resource server queries the introspection endpoint to check if tokens = are valid, then that effectively gives an attacker a way to fish for = tokens using the resource server's credentials.

---
Aaron Parecki
http://aaronparecki.com

On Sat, Jul 18, 2015 at 10:04 PM = Justin Richer <jricher@mit.edu> wrote:
Public clients can use the token-based auth mechanism, = can=E2=80=99t they? If you don=E2=80=99t have some form of = authentication on the introspection endpoint, you end up with a way for = people to anonymously and programmatically fish for valid token = values. 

 =E2=80=94 Justin

On Jul = 19, 2015, at 6:30 AM, Aaron Parecki <aaron@parecki.com> wrote:

The introspection draft states = that the introspection endpoint MUST require authentication of clients. = It mentions either client authentication (id+secret) or a separate = bearer token.

How are public clients expected to use the token = introspection endpoint? I didn't see a note in the document about that = at all.

----
Aaron Parecki
aaronparecki.com
@aaronpk

_______________________________________________
OAuth = mailing 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=_16215BF5-B8CB-4119-B8CA-03513E4071D0-- From nobody Sun Jul 19 22:04:50 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045401B2FA1 for ; Sun, 19 Jul 2015 22:04:49 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGtXmIxNS88z for ; Sun, 19 Jul 2015 22:04:46 -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 E349E1B2FA3 for ; Sun, 19 Jul 2015 22:04:45 -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 t6K54g90004797 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 Jul 2015 05:04:44 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t6K54gqm000911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 20 Jul 2015 05:04:42 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t6K54euh014324; Mon, 20 Jul 2015 05:04:42 GMT Received: from dhcp-8995.meeting.ietf.org (/31.133.137.149) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 19 Jul 2015 22:04:21 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_065FCC06-CB22-4484-8007-6EDA4FEF363E" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Phil Hunt In-Reply-To: Date: Mon, 20 Jul 2015 07:04:13 +0200 Message-Id: <98D5C1F9-6375-4876-AA79-B60FD1E2CF55@oracle.com> References: <0F2B6432-4D9E-4277-BFFE-5F0354A6D9B7@mit.edu> To: William Denniss X-Mailer: Apple Mail (2.2102) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Token introspection for public clients? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 05:04:49 -0000 --Apple-Mail=_065FCC06-CB22-4484-8007-6EDA4FEF363E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Are you trying to use token introspection as evidence of authentication = of the user? Phil @independentid www.independentid.com phil.hunt@oracle.com > On Jul 20, 2015, at 12:03 AM, William Denniss = wrote: >=20 > I see in earlier drafts that client authentication MUST was a SHOULD. >=20 > Why not put it back to a SHOULD, and make these arguments in the = Security Considerations? By the sound of it in some implementations = there are good reasons for doing client authentication, but they may not = apply to everyone, so do we need to be so prescriptive? An error = response can be added for requests the server deems require client = authentication. >=20 > It wouldn't have to be an all-or-nothing policy choice either, a = server could chose to reject requests from confidential clients where = client authentication is not provided, but accept requests without = client authentication from non-confidential clients. A server that has = sufficiently high entropy in the tokens, abuse protection on the = endpoint, and is not concerned about an unrelated party (that happens to = have a token intended for a different party) learning the token = metadata, could simply not require any client authentication at all. >=20 > Apart from anything, it is really trivial to support non-confidential = client usage, so why not? Perhaps there are some use-cases that will = turn up in the future (especially since as defined the introspection = response is extensible). One I can think of now is debugging: it's = useful during development to be able to inspect the tokens you get back = from the AS. >=20 > Best, > William >=20 >=20 > On Sun, Jul 19, 2015 at 9:14 PM, Justin Richer > wrote: > In the case of a =E2=80=9Cpublic client=E2=80=9D using a token, the = authorization is the token that the resource server uses to call the = introspection endpoint, along side the token that it is introspecting. = This is exactly how the UMA protocol works: the resource server has a = =E2=80=9CProtection API Token=E2=80=9D that it uses to call several = endpoints at the AS, including the introspection endpoint. In UMA, this = PAT is given to the resource server through a normal OAuth transaction = with an end user who facilitates the RS->AS introduction. >=20 > And I think this is all actually a moot point because clients = shouldn=E2=80=99t be doing the introspection in the first place =E2=80=94 = the whole spec is there to support resource servers introspecting at the = auth server. So you probably don=E2=80=99t have =E2=80=9Cpublic client = resource servers=E2=80=9D out there. We simply re-used OAuth=E2=80=99s = existing client authentication mechanism, that doesn=E2=80=99t make them = clients. This decision is based on development and deployment experience = (as in, several people independently built it exactly this way). Do you = have a use case where you=E2=80=99ve got a protected resource that = can=E2=80=99t hold credentials (either a client secret or a = public/private keypair) to authenticate with, and can=E2=80=99t be = introduced using OAuth to the AS as in UMA? >=20 > To your other point: An attacker has less of a chance of getting = information about a token by fishing at a protected resource with = tokens, since they=E2=80=99re not being returned information about the = token other than the fact that the token worked. (Or at least it seemed = to work because a result came back =E2=80=94 you could easily give a = suspected attacker valid-looking-but-fake data as one mitigation = mechanism.) The introspection response can give you information about = where else the token could be used, potentially. Additionally, the RS = really ought to be preventing data-fishing attacks like this just for = its own sake anyway. There are lots of techniques for doing this, but = they tend to be specific to the kind of API that=E2=80=99s being served. >=20 > Requiring the resource server to authenticate with the authorization = server also allows you to do a few other useful things. Our = implementation, for example, limits the token information that is = returned to a particular AS. This allows us to have tokens that can be = used in multiple RS=E2=80=99s without those RS=E2=80=99s ever even = knowing the token is powerful enough to be used elsewhere. It prevents = information about the authorization from leaking to parties who have no = business knowing. >=20 > Hope this helps clarify it, > =E2=80=94 Justin >=20 >> On Jul 19, 2015, at 7:59 PM, Aaron Parecki > wrote: >>=20 >> How are public clients supposed to authenticate if there is no = secret? >>=20 >> Isn't "fishing for valid tokens" just as much of an issue at the = resource server? I don't see how having the introspection endpoint = require client authentication actually solves the fishing problem since = attackers could just fish against the resource server. In fact, if the = resource server queries the introspection endpoint to check if tokens = are valid, then that effectively gives an attacker a way to fish for = tokens using the resource server's credentials.=20 >>=20 >> --- >> Aaron Parecki >> http://aaronparecki.com >>=20 >> On Sat, Jul 18, 2015 at 10:04 PM Justin Richer > wrote: >> Public clients can use the token-based auth mechanism, can=E2=80=99t = they? If you don=E2=80=99t have some form of authentication on the = introspection endpoint, you end up with a way for people to anonymously = and programmatically fish for valid token values.=20 >>=20 >> =E2=80=94 Justin >>=20 >>=20 >>> On Jul 19, 2015, at 6:30 AM, Aaron Parecki > wrote: >>>=20 >>=20 >>> The introspection draft states that the introspection endpoint MUST = require authentication of clients. It mentions either client = authentication (id+secret) or a separate bearer token. >>>=20 >>> How are public clients expected to use the token introspection = endpoint? I didn't see a note in the document about that at all. >>>=20 >>=20 >>> ---- >>> Aaron Parecki >>> aaronparecki.com >>> @aaronpk >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_065FCC06-CB22-4484-8007-6EDA4FEF363E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Are you trying to use token introspection as evidence of = authentication of the user?


On Jul 20, 2015, at 12:03 AM, William Denniss <wdenniss@google.com>= wrote:

I see in earlier drafts that client = authentication MUST was a SHOULD.

Why not put it back to a SHOULD, and make these arguments in = the Security Considerations?  By the sound of it in some = implementations there are good reasons for doing client authentication, = but they may not apply to everyone, so do we need to be so = prescriptive?  An error response can be added for requests the = server deems require client authentication.

It wouldn't have to be an = all-or-nothing policy choice either, a server could chose to reject = requests from confidential clients where client authentication is not = provided, but accept requests without client authentication from = non-confidential clients.  A server that has sufficiently high = entropy in the tokens, abuse protection on the endpoint, and is not = concerned about an unrelated party (that happens to have a token = intended for a different party) learning the token metadata, could = simply not require any client authentication at all.

Apart from anything, it = is really trivial to support non-confidential client usage, so why = not?  Perhaps there are some use-cases that will turn up in the = future (especially since as defined the introspection response is = extensible). One I can think of now is debugging: it's useful during = development to be able to inspect the tokens you get back from the = AS.

Best,
William


On Sun, Jul 19, 2015 at 9:14 PM, Justin Richer = <jricher@mit.edu> wrote:
In the case of a =E2=80=9Cpublic= client=E2=80=9D using a token, the authorization is the token that the = resource server uses to call the introspection endpoint, along side the = token that it is introspecting. This is exactly how the UMA protocol = works: the resource server has a =E2=80=9CProtection API Token=E2=80=9D = that it uses to call several endpoints at the AS, including the = introspection endpoint. In UMA, this PAT is given to the resource server = through a normal OAuth transaction with an end user who facilitates the = RS->AS introduction.

And I think this is all actually a moot point because clients shouldn=E2=80=99t be doing the introspection in = the first place =E2=80=94 the whole spec is there to support resource servers introspecting at the auth server. So you = probably don=E2=80=99t have =E2=80=9Cpublic client resource servers=E2=80=9D= out there. We simply re-used OAuth=E2=80=99s existing client = authentication mechanism, that doesn=E2=80=99t make them clients. This = decision is based on development and deployment experience (as in, = several people independently built it exactly this way). Do you have a = use case where you=E2=80=99ve got a protected resource that can=E2=80=99t = hold credentials (either a client secret or a public/private keypair) to = authenticate with, and can=E2=80=99t be introduced using OAuth to the AS = as in UMA?

To your = other point: An attacker has less of a chance of getting information = about a token by fishing at a protected resource with tokens, since = they=E2=80=99re not being returned information about the token other = than the fact that the token worked. (Or at least it seemed to work = because a result came back =E2=80=94 you could easily give a suspected = attacker valid-looking-but-fake data as one mitigation mechanism.) The = introspection response can give you information about where else the = token could be used, potentially. Additionally, the RS really ought to = be preventing data-fishing attacks like this just for its own sake = anyway. There are lots of techniques for doing this, but they tend to be = specific to the kind of API that=E2=80=99s being served.

Requiring the resource = server to authenticate with the authorization server also allows you to = do a few other useful things. Our implementation, for example, limits = the token information that is returned to a particular AS. This allows = us to have tokens that can be used in multiple RS=E2=80=99s without = those RS=E2=80=99s ever even knowing the token is powerful enough to be = used elsewhere. It prevents information about the authorization from = leaking to parties who have no business knowing.

Hope this helps clarify it,
 =E2=80=94 Justin

On Jul 19, 2015, at 7:59 PM, Aaron Parecki <aaron@parecki.com> wrote:

How are public = clients supposed to authenticate if there is no secret?

Isn't "fishing for valid tokens" just as much of an issue at = the resource server? I don't see how having the introspection endpoint = require client authentication actually solves the fishing problem since = attackers could just fish against the resource server. In fact, if the = resource server queries the introspection endpoint to check if tokens = are valid, then that effectively gives an attacker a way to fish for = tokens using the resource server's credentials.

---
Aaron Parecki
http://aaronparecki.com

On Sat, Jul 18, 2015 at 10:04 PM = Justin Richer <jricher@mit.edu> wrote:
Public clients can use the token-based auth mechanism, = can=E2=80=99t they? If you don=E2=80=99t have some form of = authentication on the introspection endpoint, you end up with a way for = people to anonymously and programmatically fish for valid token = values. 

 =E2=80=94 Justin

On Jul = 19, 2015, at 6:30 AM, Aaron Parecki <aaron@parecki.com> wrote:

The introspection draft states = that the introspection endpoint MUST require authentication of clients. = It mentions either client authentication (id+secret) or a separate = bearer token.

How are public clients expected to use the token = introspection endpoint? I didn't see a note in the document about that = at all.

----
Aaron Parecki
aaronparecki.com
@aaronpk

_______________________________________________
OAuth = mailing list
OAuth@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=_065FCC06-CB22-4484-8007-6EDA4FEF363E-- From nobody Sun Jul 19 22:37:07 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1B41B2FBF for ; Sun, 19 Jul 2015 22:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 026tIIkZOvKq for ; Sun, 19 Jul 2015 22:37:03 -0700 (PDT) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6FF31A86EB for ; Sun, 19 Jul 2015 22:37:02 -0700 (PDT) Received: by wgkl9 with SMTP id l9so121621386wgk.1 for ; Sun, 19 Jul 2015 22:37:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type; bh=Zavt0S9AkggBox1zni30E076OgNxLBHoHxDeJyAoqzc=; b=Hq/DGjX/3V1Z2F9PETbXsSJtcJqZE8lYD/xKKZ61Y17NFnxC6xfljWpqtwgrPJv2N+ Kp631e5jwxXx565mHUTVtJhcAw6u8nfqhH4mdoI36aRKp53drZxEpAj5B8xhaqQ9ZWdo KW1rbSztvdUYkC+nsoCnv83k9JghIxxtor12GpZQVJcNqraf9kk1EHuvUeJemIIhhkiT 80gxZ4srN5fVVHn6/V7YOZlpxP6gvTlubUAKi01ysjNXMNrN9jGSgzSKnZ7uFsKoWX+b 4SiFeRX/2F4ycjqep3NmILclpQRUFUFqBr3I/JmfR+tDu6wThxU0UwwIPSfOq+znEqaD 3GfA== X-Gm-Message-State: ALoCoQmPZzDVqJ+JLq0ov9BkyRrV/mD4oXwRqQsV5Y/4mbrtGTls4/YtoQQ/2wiP2P265M6mmIyl X-Received: by 10.194.23.194 with SMTP id o2mr54196735wjf.63.1437370621299; Sun, 19 Jul 2015 22:37:01 -0700 (PDT) Received: from dominicks-mbp.fritz.box (p5DCC4634.dip0.t-ipconnect.de. [93.204.70.52]) by smtp.gmail.com with ESMTPSA id ez4sm9996662wid.14.2015.07.19.22.37.00 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 19 Jul 2015 22:37:00 -0700 (PDT) Date: Mon, 20 Jul 2015 07:36:59 +0200 From: Dominick Baier To: Justin Richer , William Denniss Message-ID: In-Reply-To: <89B75723-0C59-4AF3-BC8E-166A63ED39EB@mit.edu> References: <0F2B6432-4D9E-4277-BFFE-5F0354A6D9B7@mit.edu> <89B75723-0C59-4AF3-BC8E-166A63ED39EB@mit.edu> X-Mailer: Airmail (303) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="55ac88fb_595d822c_274" Archived-At: Cc: "=?utf-8?Q??=" Subject: Re: [OAUTH-WG] Token introspection for public clients? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 05:37:06 -0000 --55ac88fb_595d822c_274 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I totally agree with that - and that=E2=80=99s how we gonna implement it = in identity server. We are planning to introduce something called a =E2=80=9Cscope secret=E2=80= =9D - it=E2=80=99s like a client secret but for resources. =E2=80=94=C2=A0 cheers Dominick Baier On 20 Jul 2015 at 07:01:48, Justin Richer (jricher=40mit.edu) wrote: Because the target isn=E2=80=99t the client, it=E2=80=99s the protected r= esource. We=E2=80=99re re-using OAuth=E2=80=99s client credentialing mech= anisms (optionally, you can use whatever you deem necessary), but it=E2=80= =99s not a client that=E2=80=99s doing it. That=E2=80=99s why it was chan= ged to a MUST =E2=80=94 there may be public clients out there (which coul= d also use R=46C7591 to become non-public), but public resource servers d= on=E2=80=99t make nearly as much sense. Additionally, the discussion for this was back in December during the WGL= C, and the time for normative changes to this particular spec is largely = over at this stage. =C2=A0=E2=80=94 Justin On Jul 20, 2015, at 12:03 AM, William Denniss wro= te: I see in earlier drafts that client authentication MUST was a SHOULD. Why not put it back to a SHOULD, and make these arguments in the Security= Considerations=3F=C2=A0 By the sound of it in some implementations there= are good reasons for doing client authentication, but they may not apply= to everyone, so do we need to be so prescriptive=3F=C2=A0 An error respo= nse can be added for requests the server deems require client authenticat= ion. It wouldn't have to be an all-or-nothing policy choice either, a server c= ould chose to reject requests from confidential clients where client auth= entication is not provided, but accept requests without client authentica= tion from non-confidential clients.=C2=A0 A server that has sufficiently = high entropy in the tokens, abuse protection on the endpoint, and is not = concerned about an unrelated party (that happens to have a token intended= for a different party) learning the token metadata, could simply not req= uire any client authentication at all. Apart from anything, it is really trivial to support non-confidential cli= ent usage, so why not=3F=C2=A0 Perhaps there are some use-cases that will= turn up in the future (especially since as defined the introspection res= ponse is extensible). One I can think of now is debugging: it's useful du= ring development to be able to inspect the tokens you get back from the A= S. Best, William On Sun, Jul 19, 2015 at 9:14 PM, Justin Richer wrote:= In the case of a =E2=80=9Cpublic client=E2=80=9D using a token, the autho= rization is the token that the resource server uses to call the introspec= tion endpoint, along side the token that it is introspecting. This is exa= ctly how the UMA protocol works: the resource server has a =E2=80=9CProte= ction API Token=E2=80=9D that it uses to call several endpoints at the AS= , including the introspection endpoint. In UMA, this PAT is given to the = resource server through a normal OAuth transaction with an end user who f= acilitates the RS->AS introduction. And I think this is all actually a moot point because clients shouldn=E2=80= =99t be doing the introspection in the first place =E2=80=94 the whole sp= ec is there to support resource servers introspecting at the auth server.= So you probably don=E2=80=99t have =E2=80=9Cpublic client resource serve= rs=E2=80=9D out there. We simply re-used OAuth=E2=80=99s existing client = authentication mechanism, that doesn=E2=80=99t make them clients. This de= cision is based on development and deployment experience (as in, several = people independently built it exactly this way). Do you have a use case w= here you=E2=80=99ve got a protected resource that can=E2=80=99t hold cred= entials (either a client secret or a public/private keypair) to authentic= ate with, and can=E2=80=99t be introduced using OAuth to the AS as in UMA= =3F To your other point: An attacker has less of a chance of getting informat= ion about a token by fishing at a protected resource with tokens, since t= hey=E2=80=99re not being returned information about the token other than = the fact that the token worked. (Or at least it seemed to work because a = result came back =E2=80=94 you could easily give a suspected attacker val= id-looking-but-fake data as one mitigation mechanism.) The introspection = response can give you information about where else the token could be use= d, potentially. Additionally, the RS really ought to be preventing data-f= ishing attacks like this just for its own sake anyway. There are lots of = techniques for doing this, but they tend to be specific to the kind of AP= I that=E2=80=99s being served. Requiring the resource server to authenticate with the authorization serv= er also allows you to do a few other useful things. Our implementation, f= or example, limits the token information that is returned to a particular= AS. This allows us to have tokens that can be used in multiple RS=E2=80=99= s without those RS=E2=80=99s ever even knowing the token is powerful enou= gh to be used elsewhere. It prevents information about the authorization = from leaking to parties who have no business knowing. Hope this helps clarify it, =C2=A0=E2=80=94 Justin On Jul 19, 2015, at 7:59 PM, Aaron Parecki wrote: How are public clients supposed to authenticate if there is no secret=3F Isn't =22fishing for valid tokens=22 just as much of an issue at the reso= urce server=3F I don't see how having the introspection endpoint require = client authentication actually solves the fishing problem since attackers= could just fish against the resource server. In fact, if the resource se= rver queries the introspection endpoint to check if tokens are valid, the= n that effectively gives an attacker a way to fish for tokens using the r= esource server's credentials. --- Aaron Parecki http://aaronparecki.com On Sat, Jul 18, 2015 at 10:04 PM Justin Richer wrote:= Public clients can use the token-based auth mechanism, can=E2=80=99t they= =3F If you don=E2=80=99t have some form of authentication on the introspe= ction endpoint, you end up with a way for people to anonymously and progr= ammatically fish for valid token values.=C2=A0 =C2=A0=E2=80=94 Justin On Jul 19, 2015, at 6:30 AM, Aaron Parecki wrote: The introspection draft states that the introspection endpoint MUST requi= re authentication of clients. It mentions either client authentication (i= d+secret) or a separate bearer token. How are public clients expected to use the token introspection endpoint=3F= I didn't see a note in the document about that at all. ---- Aaron Parecki aaronparecki.com =40aaronpk =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F OAuth mailing list OAuth=40ietf.org https://www.ietf.org/mailman/listinfo/oauth =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F OAuth mailing list OAuth=40ietf.org https://www.ietf.org/mailman/listinfo/oauth =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =20 OAuth mailing list =20 OAuth=40ietf.org =20 https://www.ietf.org/mailman/listinfo/oauth =20 --55ac88fb_595d822c_274 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

… by Matias Woloski of Auth0.  Check it o= ut!

 

https://auth0.com/blog/2015/07/21/jwt-json-webtoken-logo/=

 

--_000_BY2PR03MB44204F1BA91EFCC95D66EB5F5840BY2PR03MB442namprd_-- From nobody Tue Jul 21 16:06:14 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731671B30F2 for ; Tue, 21 Jul 2015 16:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbkGU32fK7_L for ; Tue, 21 Jul 2015 16:06:08 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77D1B1B2EE5 for ; Tue, 21 Jul 2015 16:06:08 -0700 (PDT) Received: by qkdl129 with SMTP id l129so143341408qkd.0 for ; Tue, 21 Jul 2015 16:06:07 -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:content-type; bh=mKfSrC9Nka9DJ4cSLf/XHPmep8aAsJ/eswHodh57PNo=; b=nWNgLcZL7G+HFKraTYCL/r4ku24D6odCvThfWggasZ5Yl9f8nApKVtz7NBfGSaWSMo SxMUC2YqgcS55PqRV/YrxGOa/TT35gZE0M1cxqzqARHDRc+wlHGbPFe28lwnCJ2K8HFg 62BTat3le+g1GQkyVha6WZ85E6ZNndgwDfykWqJf2KJM5/4yRmxnbRonVEFeGKf7oRMu CBhlReULmFSR3xE1yqK7xGze8T/rp+u3T/h/OUel0R5/xIIDwgngiIYkGSAmj6ZuWoL2 vEoPcGGzht0DWpErlOJj2nvMfQ8B1tUajI4I14v7/K5/kEUlnZCbcCWr+qlot+wFPcKQ F3Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=mKfSrC9Nka9DJ4cSLf/XHPmep8aAsJ/eswHodh57PNo=; b=HycKYVcUElrg3tI41c7LTMaWeOQuopPF2MgUSjBfCvktugy4vjSIQVw/q06BtZamGZ KHgPgyy2UKoxCs5ZD9tfs0+wv9hOIQJyUrlamjXTBzVAtMKdFlL7LxTFsfvPUNnFtX/b hNvFPg3rO67JQh95hvYKYylOphYbXRnUdiu0fs/tA0jFTPR+wE6aHQXhVUXT6uukXfHu +Fynk2yLKXu3QYJupzU7hGPHhdQCTAdAT8zoNrz21xakrW9yEJ9hB8c9BP+rKXN+Omf0 4q+BJnv8oilCqeEndE1fLAB36xqB3ZypHeh/XWryeR6d03NKztRfpDc2q6MZxD0h8Lfw fyxw== X-Gm-Message-State: ALoCoQm7cx5fNkCgLXN0kcGWTZ1zpReSDrKP4eK6bQlDjhsBYNrn/gmc2hWK3UjhnjCFOUYegL5I X-Received: by 10.55.23.161 with SMTP id 33mr6279248qkx.48.1437519967530; Tue, 21 Jul 2015 16:06:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.19.98 with HTTP; Tue, 21 Jul 2015 16:05:47 -0700 (PDT) In-Reply-To: References: <0F2B6432-4D9E-4277-BFFE-5F0354A6D9B7@mit.edu> <89B75723-0C59-4AF3-BC8E-166A63ED39EB@mit.edu> From: William Denniss Date: Wed, 22 Jul 2015 01:05:47 +0200 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=001a11473bb205d942051b6ab3c4 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Token introspection for public clients? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 23:06:12 -0000 --001a11473bb205d942051b6ab3c4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We had a good sync on this topic offline on Monday, and it seemed the consensus was that if clients need to introspect access tokens they are doing something wrong. That said, looking only at the resource server use-case, I still think the MUST is problematic. The out of band authentication requirement when accompanied with the MUST makes the spec less useful. i.e. "the endpoint MUST also require some form of authorization to access this endpoint", but "The specifics of this authentication credentials are out of scope of this specification". This makes dynamic discovery which was mentioned as potentially applying to this spec virtually useless (you discovered the introspection endpoint, but how do you discover how to authenticate?). It also adds to general implementation complexity. Brian mentioned that in their implementation, they decided not to force authentication for introspection by resource servers as they were protecting the endpoint through other means, and wanted to reduce complexity for developers. The MUST here constrains that decision, one which I think should be left up to the provider. Lastly, the MUST is presented in the spec as being required to prevent token scanning, and yet there are other ways to mitigate that attack. If there are better reasons than token scanning for this remaining a MUST, then I think the spec should document them. Side note: If you prevent token scanning through other means, the main benefit of still requiring authentication seems to be preventing information leaking out to a client who is in possession of the access token but isn't the intended audience. This may or may not be an issue depending on the contents of the introspection response. Perhaps it would be good to mention this in the security considerations, as it's something that should be considered by implementors. Given the sensitivity of information revealed by the introspection endpoint varies, I don't think that this alone would mandate the MUST. On Tue, Jul 21, 2015 at 10:03 AM, Justin Richer wrote: > Just use the token at your target API and see if it works. Your client=E2= =80=99s > going to need to be able to get a new token if this one expires mid-sessi= on > anyway, so you=E2=80=99re not saving anything by doing an introspection r= equest. > > =E2=80=94 Justin > > On Jul 20, 2015, at 9:34 PM, Aaron Parecki wrote: > > I'm looking for a way to check if an existing token is still valid. > Imagine a client is holding on to a token between user sessions, for > example if it's making API requests for the user on a cron job. When the > user returns to the site, I want to check if the token is still valid, an= d > make them sign in again if not. > > Aaron > > On Mon, Jul 20, 2015 at 12:11 PM John Bradley wrote: > >> If you want the resource owner/user then get a id_token from the token >> endpoint. That saves another call to a introspection endpoint. >> >> Sent from my iPhone >> >> On Jul 20, 2015, at 7:49 PM, Aaron Parecki wrote: >> >> Okay, if the intent is for this endpoint to be used by the resource >> server, this all makes sense. I was under the impression that it could a= lso >> be used by clients to verify if the token is valid. Is there some other >> spec I could look at that is intended to be used by clients to verify if= a >> token is valid and find out the user ID associated with it? >> >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >> >> >> On Sun, Jul 19, 2015 at 10:01 PM, Justin Richer wrote: >> >>> Because the target isn=E2=80=99t the client, it=E2=80=99s the protected= resource. We=E2=80=99re >>> re-using OAuth=E2=80=99s client credentialing mechanisms (optionally, y= ou can use >>> whatever you deem necessary), but it=E2=80=99s not a client that=E2=80= =99s doing it. That=E2=80=99s >>> why it was changed to a MUST =E2=80=94 there may be public clients out = there (which >>> could also use RFC7591 to become non-public), but public resource serve= rs >>> don=E2=80=99t make nearly as much sense. >>> >>> Additionally, the discussion for this was back in December during the >>> WGLC, and the time for normative changes to this particular spec is lar= gely >>> over at this stage. >>> >>> =E2=80=94 Justin >>> >>> On Jul 20, 2015, at 12:03 AM, William Denniss >>> wrote: >>> >>> I see in earlier drafts that client authentication MUST was a SHOULD. >>> >>> Why not put it back to a SHOULD, and make these arguments in the >>> Security Considerations? By the sound of it in some implementations th= ere >>> are good reasons for doing client authentication, but they may not appl= y to >>> everyone, so do we need to be so prescriptive? An error response can b= e >>> added for requests the server deems require client authentication. >>> >>> It wouldn't have to be an all-or-nothing policy choice either, a server >>> could chose to reject requests from confidential clients where client >>> authentication is not provided, but accept requests without client >>> authentication from non-confidential clients. A server that has >>> sufficiently high entropy in the tokens, abuse protection on the endpoi= nt, >>> and is not concerned about an unrelated party (that happens to have a t= oken >>> intended for a different party) learning the token metadata, could simp= ly >>> not require any client authentication at all. >>> >>> Apart from anything, it is really trivial to support non-confidential >>> client usage, so why not? Perhaps there are some use-cases that will t= urn >>> up in the future (especially since as defined the introspection respons= e is >>> extensible). One I can think of now is debugging: it's useful during >>> development to be able to inspect the tokens you get back from the AS. >>> >>> Best, >>> William >>> >>> >>> On Sun, Jul 19, 2015 at 9:14 PM, Justin Richer wrote: >>> >>>> In the case of a =E2=80=9Cpublic client=E2=80=9D using a token, the au= thorization is >>>> the token that the resource server uses to call the introspection endp= oint, >>>> along side the token that it is introspecting. This is exactly how the= UMA >>>> protocol works: the resource server has a =E2=80=9CProtection API Toke= n=E2=80=9D that it >>>> uses to call several endpoints at the AS, including the introspection >>>> endpoint. In UMA, this PAT is given to the resource server through a n= ormal >>>> OAuth transaction with an end user who facilitates the RS->AS introduc= tion. >>>> >>>> And I think this is all actually a moot point because *clients* >>>> shouldn=E2=80=99t be doing the introspection in the first place =E2=80= =94 the whole spec is >>>> there to support *resource servers* introspecting at the auth server. >>>> So you probably don=E2=80=99t have =E2=80=9Cpublic client resource ser= vers=E2=80=9D out there. We >>>> simply re-used OAuth=E2=80=99s existing client authentication mechanis= m, that >>>> doesn=E2=80=99t make them clients. This decision is based on developme= nt and >>>> deployment experience (as in, several people independently built it ex= actly >>>> this way). Do you have a use case where you=E2=80=99ve got a protected= resource >>>> that can=E2=80=99t hold credentials (either a client secret or a publi= c/private >>>> keypair) to authenticate with, and can=E2=80=99t be introduced using O= Auth to the >>>> AS as in UMA? >>>> >>>> To your other point: An attacker has less of a chance of getting >>>> information about a token by fishing at a protected resource with toke= ns, >>>> since they=E2=80=99re not being returned information about the token o= ther than the >>>> fact that the token worked. (Or at least it seemed to work because a r= esult >>>> came back =E2=80=94 you could easily give a suspected attacker >>>> valid-looking-but-fake data as one mitigation mechanism.) The introspe= ction >>>> response can give you information about where else the token could be = used, >>>> potentially. Additionally, the RS really ought to be preventing >>>> data-fishing attacks like this just for its own sake anyway. There are= lots >>>> of techniques for doing this, but they tend to be specific to the kind= of >>>> API that=E2=80=99s being served. >>>> >>>> Requiring the resource server to authenticate with the authorization >>>> server also allows you to do a few other useful things. Our implementa= tion, >>>> for example, limits the token information that is returned to a partic= ular >>>> AS. This allows us to have tokens that can be used in multiple RS=E2= =80=99s without >>>> those RS=E2=80=99s ever even knowing the token is powerful enough to b= e used >>>> elsewhere. It prevents information about the authorization from leakin= g to >>>> parties who have no business knowing. >>>> >>>> Hope this helps clarify it, >>>> =E2=80=94 Justin >>>> >>>> On Jul 19, 2015, at 7:59 PM, Aaron Parecki wrote: >>>> >>>> How are public clients supposed to authenticate if there is no secret? >>>> >>>> Isn't "fishing for valid tokens" just as much of an issue at the >>>> resource server? I don't see how having the introspection endpoint req= uire >>>> client authentication actually solves the fishing problem since attack= ers >>>> could just fish against the resource server. In fact, if the resource >>>> server queries the introspection endpoint to check if tokens are valid= , >>>> then that effectively gives an attacker a way to fish for tokens using= the >>>> resource server's credentials. >>>> >>>> --- >>>> Aaron Parecki >>>> http://aaronparecki.com >>>> >>>> On Sat, Jul 18, 2015 at 10:04 PM Justin Richer wrote= : >>>> >>>>> Public clients can use the token-based auth mechanism, can=E2=80=99t = they? If >>>>> you don=E2=80=99t have some form of authentication on the introspecti= on endpoint, >>>>> you end up with a way for people to anonymously and programmatically = fish >>>>> for valid token values. >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> On Jul 19, 2015, at 6:30 AM, Aaron Parecki wrote: >>>>> >>>>> The introspection draft states that the introspection endpoint MUST >>>>> require authentication of clients. It mentions either client authenti= cation >>>>> (id+secret) or a separate bearer token. >>>>> >>>>> How are public clients expected to use the token introspection >>>>> endpoint? I didn't see a note in the document about that at all. >>>>> >>>>> ---- >>>>> Aaron Parecki >>>>> aaronparecki.com >>>>> @aaronpk >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@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 > > --001a11473bb205d942051b6ab3c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We had a good sync on this topic offline on Monday, and it= seemed the consensus was that if clients need to introspect access tokens = they are doing something wrong.

That said, looking only = at the resource server use-case, I still think the MUST is problematic.

The out of band authentication requirement when = accompanied with the MUST makes the spec less useful. =C2=A0i.e. "the = endpoint MUST also require some form of authorization to access this endpoi= nt", but "The specifics of this authentication credentials are ou= t of scope of this specification".=C2=A0 This makes dynamic discovery = which was mentioned as potentially applying to this spec virtually useless = (you discovered the introspection endpoint, but how do you discover how to = authenticate?). It also adds to general implementation complexity.

Brian mentioned that in their implementation, they decided= not to force authentication for introspection by resource servers as they = were protecting the endpoint through other means, and wanted to reduce comp= lexity for developers. The MUST here constrains that decision, one which I = think should be left up to the provider.

Lastly, t= he MUST is presented in the spec as being required to prevent token scannin= g, and yet there are other ways to mitigate that attack. If there are bette= r reasons than token scanning for this remaining a MUST, then I think the s= pec should document them.

Side note: If you preven= t token scanning through other means, the main benefit of still requiring a= uthentication seems to be preventing information leaking out to a client wh= o is in possession of the access token but isn't the intended audience.= This may or may not be an issue depending on the contents of the introspec= tion response. Perhaps it would be good to mention this in the security con= siderations, as it's something that should be considered by implementor= s.=C2=A0 Given the sensitivity of information revealed by the introspection= endpoint varies, I don't think that this alone would mandate the MUST.= =C2=A0



On Tue, Jul 21, 2015 at 10:03 A= M, Justin Richer <jricher@mit.edu> wrote:
=
Just use the token at your target API a= nd see if it works. Your client=E2=80=99s going to need to be able to get a= new token if this one expires mid-session anyway, so you=E2=80=99re not sa= ving anything by doing an introspection request.

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

On= Jul 20, 2015, at 9:34 PM, Aaron Parecki <aaron@parecki.com> wrote:

<= div>I'm looking for a way to check if an existing token is still = valid. Imagine a client is holding on to a token between user sessions, for= example if it's making API requests for the user on a cron job. When t= he user returns to the site, I want to check if the token is still valid, a= nd make them sign in again if not.

Aaron

On Mon, Jul 20, 2015 at 12:11 PM John Bradley <ve7jtb@ve7jtb.com&= gt; wrote:
If you w= ant the resource owner/user then get a id_token from the token endpoint.=C2= =A0 That saves another call to a introspection endpoint. =C2=A0=C2=A0
Sent from my iPhone

On= Jul 20, 2015, at 7:49 PM, Aaron Parecki <aaron@parecki.com> wrote:

Okay, if the inten= t is for this endpoint to be used by the resource server, this all makes se= nse. I was under the impression that it could also be used by clients to ve= rify if the token is valid. Is there some other spec I could look at that i= s intended to be used by clients to verify if a token is valid and find out= the user ID associated with it?

----
Aaron Parecki
aaronparecki.com


On Sun, Jul 19, 2015 at 10:01 PM, Justin Ric= her <jricher@mit.edu> wrote:
Because the target isn=E2=80=99t the client, it=E2= =80=99s the protected resource. We=E2=80=99re re-using OAuth=E2=80=99s clie= nt credentialing mechanisms (optionally, you can use whatever you deem nece= ssary), but it=E2=80=99s not a client that=E2=80=99s doing it. That=E2=80= =99s why it was changed to a MUST =E2=80=94 there may be public clients out= there (which could also use RFC7591 to become non-public), but public reso= urce servers don=E2=80=99t make nearly as much sense.

Ad= ditionally, the discussion for this was back in December during the WGLC, a= nd the time for normative changes to this particular spec is largely over a= t this stage.

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

On Jul 20, 2015, at 12:03 AM, William Denniss <wdenniss@google.com> wrote= :

I see in earlier drafts that client authen= tication MUST was a SHOULD.

Why not put it back to a SHO= ULD, and make these arguments in the Security Considerations?=C2=A0 By the = sound of it in some implementations there are good reasons for doing client= authentication, but they may not apply to everyone, so do we need to be so= prescriptive?=C2=A0 An error response can be added for requests the server= deems require client authentication.

It wouldn= 9;t have to be an all-or-nothing policy choice either, a server could chose= to reject requests from confidential clients where client authentication i= s not provided, but accept requests without client authentication from non-= confidential clients.=C2=A0 A server that has sufficiently high entropy in = the tokens, abuse protection on the endpoint, and is not concerned about an= unrelated party (that happens to have a token intended for a different par= ty) learning the token metadata, could simply not require any client authen= tication at all.

Apart from anything, it is really= trivial to support non-confidential client usage, so why not?=C2=A0 Perhap= s there are some use-cases that will turn up in the future (especially sinc= e as defined the introspection response is extensible). One I can think of = now is debugging: it's useful during development to be able to inspect = the tokens you get back from the AS.

Best,
William


On Sun, Jul 19, 2015 at 9:14 PM, Justin Richer <jricher@m= it.edu> wrote:
In the case of a =E2=80=9Cpublic client=E2=80=9D using a token, t= he authorization is the token that the resource server uses to call the int= rospection endpoint, along side the token that it is introspecting. This is= exactly how the UMA protocol works: the resource server has a =E2=80=9CPro= tection API Token=E2=80=9D that it uses to call several endpoints at the AS= , including the introspection endpoint. In UMA, this PAT is given to the re= source server through a normal OAuth transaction with an end user who facil= itates the RS->AS introduction.

And I think this is a= ll actually a moot point because clients shouldn=E2=80=99t be doing = the introspection in the first place =E2=80=94 the whole spec is there to s= upport resource servers introspecting at the auth server. So you pro= bably don=E2=80=99t have =E2=80=9Cpublic client resource servers=E2=80=9D o= ut there. We simply re-used OAuth=E2=80=99s existing client authentication = mechanism, that doesn=E2=80=99t make them clients. This decision is based o= n development and deployment experience (as in, several people independentl= y built it exactly this way). Do you have a use case where you=E2=80=99ve g= ot a protected resource that can=E2=80=99t hold credentials (either a clien= t secret or a public/private keypair) to authenticate with, and can=E2=80= =99t be introduced using OAuth to the AS as in UMA?

To y= our other point: An attacker has less of a chance of getting information ab= out a token by fishing at a protected resource with tokens, since they=E2= =80=99re not being returned information about the token other than the fact= that the token worked. (Or at least it seemed to work because a result cam= e back =E2=80=94 you could easily give a suspected attacker valid-looking-b= ut-fake data as one mitigation mechanism.) The introspection response can g= ive you information about where else the token could be used, potentially. = Additionally, the RS really ought to be preventing data-fishing attacks lik= e this just for its own sake anyway. There are lots of techniques for doing= this, but they tend to be specific to the kind of API that=E2=80=99s being= served.

Requiring the resource server to authenti= cate with the authorization server also allows you to do a few other useful= things. Our implementation, for example, limits the token information that= is returned to a particular AS. This allows us to have tokens that can be = used in multiple RS=E2=80=99s without those RS=E2=80=99s ever even knowing = the token is powerful enough to be used elsewhere. It prevents information = about the authorization from leaking to parties who have no business knowin= g.

Hope this helps clarify it,
=C2=A0=E2= =80=94 Justin

On Ju= l 19, 2015, at 7:59 PM, Aaron Parecki <aaron@parecki.com> wrote:

How are public clients supposed to authenticate if there is no secre= t?

Isn't "fishing for valid tokens" just as much of an= issue at the resource server? I don't see how having the introspection= endpoint require client authentication actually solves the fishing problem= since attackers could just fish against the resource server. In fact, if t= he resource server queries the introspection endpoint to check if tokens ar= e valid, then that effectively gives an attacker a way to fish for tokens u= sing the resource server's credentials.

---
Aaron Pareckihttp://aaron= parecki.com

On Sat, Jul 18, 201= 5 at 10:04 PM Justin Richer <jricher@mit.edu> wrote:
Public clients can use the token-based auth mecha= nism, can=E2=80=99t they? If you don=E2=80=99t have some form of authentica= tion on the introspection endpoint, you end up with a way for people to ano= nymously and programmatically fish for valid token values.=C2=A0

=C2=A0=E2=80=94 Justin

<= div>
On Jul 19, 2015, at 6:30 AM, Aaron Parec= ki <aaron@parecki= .com> wrote:

The introspection draft states that the introspection endpoint MUS= T require authentication of clients. It mentions either client authenticati= on (id+secret) or a separate bearer token.

How are= public clients expected to use the token introspection endpoint? I didn= 9;t see a note in the document about that at all.

= ----
Aaron Parecki

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


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




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


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


--001a11473bb205d942051b6ab3c4-- From nobody Wed Jul 22 00:44:33 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC7B1B2D4C for ; Wed, 22 Jul 2015 00:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.225 X-Spam-Level: X-Spam-Status: No, score=-0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_IMAGE_SPAM_HTML=0.81, DC_IMAGE_SPAM_TEXT=0.242, DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNWm7lsy8iVa for ; Wed, 22 Jul 2015 00:44:31 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c: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 688D51ACE2C for ; Wed, 22 Jul 2015 00:44:30 -0700 (PDT) Received: by wicgb10 with SMTP id gb10so85473139wic.1 for ; Wed, 22 Jul 2015 00:44:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=Y8uXdSjdU/rLL9Xg/QdHExW9X70fnoXkvR0oV1yl5tw=; b=0g2cqhHul545fnCCYjCT5+45+cCFJZNj4/2UCTxCqnplg9eezTZBxLy+djxN1eQ7RN ovkwgJNt84K+gp3uF/3Mzdli6gRenbFBmCbKO+tW44WvTrpPNVorCThDTljk8FPTk2cz 2lIxlr+R57zfK0CF5U9elCMeUI+x9QNdrGNSa6x0dYU1ghTP5aPem+1L/3sbEv9lO4GH fAHw4HX8tsEBk9Ww4DokfbiZIWMr0mYCwu12rxunE4pJRD4ULnWykk2LrOsBes5oczdv 9Y+9y+PlS6KcPqVpowvjrQJ0Uy6o7DNh5UBs+1x6+/SmZ/nS3xU5V+0ss0JRaTB6nAqr 2zaw== MIME-Version: 1.0 X-Received: by 10.194.120.198 with SMTP id le6mr2270331wjb.133.1437551069157; Wed, 22 Jul 2015 00:44:29 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.28.1.79 with HTTP; Wed, 22 Jul 2015 00:44:28 -0700 (PDT) Date: Wed, 22 Jul 2015 03:44:28 -0400 X-Google-Sender-Auth: bYZaQysc5iYrR26-wQBSg71s0Wc Message-ID: From: Barry Leiba To: oauth WG Content-Type: multipart/mixed; boundary=089e01160002d35017051b71f06d Archived-At: Subject: [OAUTH-WG] OAuth implementation fail X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 07:44:32 -0000 --089e01160002d35017051b71f06d Content-Type: text/plain; charset=UTF-8 Yesterday, someone sent me a link to some presentation slides that he'd posted to SlideShare. I looked at them, and wanted to download them as a PDF. In order to let me do that, SlideShare wants me to log in. It gives me the options to log in via LinkedIn or Facebook. As I'm one of the three people in the world without a Facebook account, I clicked "LinkedIn". That got me an OAuth authorization screen, image attached. Now, I don't know if this is SlideShare's fault for asking for too much, or LinkedIn's fault for not providing enough granularity for requests, but just LOOK at that list of what I'd be giving SlideShare access to. The first few make sense: read my profile (the whole thing or pieces of it, including contact information). But... access to my connections? I'm not sure they'd like my exposing their identities to SlideShare. Access to my private messages? EDIT MY PROFILE? Srsly? Of course, this isn't the fault of the OAuth protocol, really (though one might argue that there's not enough guidance provided). But, really, with implementations like this, I have to wonder what they're thinking. I clicked "Cancel", of course, and asked the slide creator to send me a PDF. Barry --089e01160002d35017051b71f06d Content-Type: image/png; name="SlideShare-LinkedIn-OAuth.png" Content-Disposition: attachment; filename="SlideShare-LinkedIn-OAuth.png" Content-Transfer-Encoding: base64 X-Attachment-Id: f_icego87g0 iVBORw0KGgoAAAANSUhEUgAAAXoAAAK8CAYAAADh+XSkAAAYI2lDQ1BJQ0MgUHJvZmlsZQAAWIWV eQdUFE2zds/OBliWJeeck2SWKDnnnBFYcs4ZlSgSVAQBRUAFFQQVDCQRE4KIIoIKGBAJBpIKCigC coeg7/e/97/nntvnzMyz1VU1T3dV90ztAMDBSo6ICEHRAhAaFhNlY6jD6+Tswot7B7CAE1AAEkCT vaMjtK2szMD/2JaHALR5fS656et/1vv/Njof32hvACArBHv5RHuHIrgRADS7d0RUDACYfkQuEB8T sYkXEcwYhRAEAEuxif23Mecm9trGMls6dja6CNYDgIJAJkf5A0Dc9M8b5+2P+CFGIH30YT6BYYhq JoI1vAPIPgCwdyI6u0JDwzfxPIJFvf7Dj///49Prr08y2f8v3h7LVqPQC4yOCCEn/h+n439voSGx f+7BjxyEgCgjm80xI/N2ITjcdBMTENwe5mVhiWB6BD8M9NnS38SvA2KN7Hf057yjdZE5A8wAoIAP Wc8Uwchcophjg+21d7AcOWrLFtFHWQTGGNvtYK+ocJsd/6g432h92z84wNfYbMdndliIxR98yi/Q wBjBSKahGpMC7By3eaI64wIdLBBMRHB/dLCt6Y7+aFKArsUfnahYm03Ogghe9IsysNnWgVlDo/+M C5byJm9xYEWwVkyAndG2LezkG+1k9oebj6+e/jYH2Mc3zH6HM4xkl47Njm1WRIjVjj58yjfE0GZ7 nuEr0XG2f2yfxSAJtj0P8EQQ2cRqmz+8HBFjZbfNDY0GZkAX6AFeEIscXiAcBIHAvrmWOeTXdo8B IIMo4A98geSO5I+F41ZPGHK2BUngM4J8QfRfO52tXl8Qh8jX/0q3z5LAb6s3bssiGHxEcCiaHa2B VkObIWct5JBDK6NV/tjx0vy5K1Yfq4c1whpgxf7y8EZYhyBHFAj877J/LDEfMQOYCcwgZgzzCpgi vb7ImDcZhv0dmQN4v+Vl57dHYHrUv5jzAnMwhtgZ7IzOC7Ge/qODFkZYk9A6aHWEP8IdzYxmB5Jo BWQk2mhNZGwkRPqfDGP/svhnLv99v01+/znGHTlRnEjaYeH1l7/uX61/e9H9jznyQa6m/9aEs+Hr cDd8D+6B2+EWwAvfgVvhXvjWJv6bCe+3MuHP3Wy2uAUjfgL/6MhclJmWWftvdyfvMIjaijeI8U2I 2VwQuuERiVGB/gExvNrIjuzLaxzmLbWLV05GlgTA5v6+vX18t9natyHmp//IfKcA2I3kOGX/P7Kg YwDUdQHAkvuPTNgVALZdAFx95h0bFbctQ2+eMAAPaJCVwQa4gQAQRcYkBxSBGtAC+sAEWAI74Azc kVkPAKEI63iwF6SBLJAHjoJicBKcBmfBBXAZXAMtoB3cAw/AY9APBsEbJDc+gFkwD5bBKgRBOIga YoDYIB5ICJKA5CBlSAPSh8wgG8gZ8oT8oTAoFtoLZUB5UCF0EqqEaqGr0A3oHtQDDUCvoHFoGvoG /ULBKAKKEcWFEkZJo5RR2ihTlB1qD8ofFYlKQmWijqBOoKpQl1DNqHuox6hB1BhqFrUEA5gKZob5 YElYGdaFLWEX2A+OgvfDuXAJXAXXw21IrJ/DY/AcvILGohnQvGhJJD+N0PZob3Qkej/6EPok+gK6 Gd2Jfo4eR8+jf2OoMZwYCYwqxhjjhPHHxGOyMCWYakwTpgtZUR8wy1gslhkrglVC1qYzNgibjD2E rcA2YO9iB7CT2CUcDseGk8Cp4yxxZFwMLgtXiruEu4N7hvuA+0lBRcFDIUdhQOFCEUaRTlFCUUdx m+IZxSeKVUpaSiFKVUpLSh/KRMp8ynOUbZRPKT9QruLp8CJ4dbwdPgifhj+Br8d34Ufw36moqPip VKisqQKpUqlOUF2hekg1TrVCoCeIE3QJboRYwhFCDeEu4RXhOzU1tTC1FrULdQz1Eepa6vvUo9Q/ iQxEKaIx0YeYQiwjNhOfEb/QUNII0WjTuNMk0ZTQXKd5SjNHS0krTKtLS6bdT1tGe4N2mHaJjoFO ls6SLpTuEF0dXQ/dFD2OXphen96HPpP+LP19+kkGmEGAQZfBmyGD4RxDF8MHRiyjCKMxYxBjHuNl xj7GeSZ6JgUmB6YEpjKmW0xjzDCzMLMxcwhzPvM15iHmXyxcLNosviw5LPUsz1h+sHKwarH6suay NrAOsv5i42XTZwtmK2BrYXvLjmYXZ7dmj2c/xd7FPsfByKHG4c2Ry3GN4zUnilOc04YzmfMsZy/n Ehc3lyFXBFcp132uOW5mbi3uIO4i7tvc0zwMPBo8gTxFPHd4ZniZeLV5Q3hP8HbyzvNx8hnxxfJV 8vXxrfKL8Nvzp/M38L8VwAsoC/gJFAl0CMwL8giaC+4VvCj4WohSSFkoQOi4ULfQD2ERYUfhg8It wlMirCLGIkkiF0VGRKlFNUUjRatEX4hhxZTFgsUqxPrFUeIk8QDxMvGnEigJRYlAiQqJgV2YXSq7 wnZV7RqWJEhqS8ZJXpQcl2KWMpNKl2qR+iItKO0iXSDdLf1bhiQTInNO5o0svayJbLpsm+w3OXE5 b7kyuRfy1PIG8inyrfILChIKvgqnFF6SGEjmpIOkDtK6opJilGK94rSSoJKnUrnSsDKjspXyIeWH KhgVHZUUlXaVFVVF1RjVa6pf1STVgtXq1KZ2i+z23X1u96Q6vzpZvVJ9TINXw1PjjMaYJp8mWbNK c0JLQMtHq1rrk7aYdpD2Je0vOjI6UTpNOj90VXX36d7Vg/UM9XL1+vTp9e31T+qPGvAb+BtcNJg3 JBkmG941whiZGhUYDRtzGXsb1xrPmyiZ7DPpNCWY2pqeNJ0wEzeLMmszR5mbmB8zH7EQsgizaLEE lsaWxyzfWolYRVrdtMZaW1mXWX+0kbXZa9Nty2DrYVtnu2ynY5dv98Ze1D7WvsOBxsHNodbhh6Oe Y6HjmJO00z6nx87szoHOrS44FweXapclV33XYtcPbiS3LLehPSJ7Evb0uLO7h7jf8qDxIHtc98R4 OnrWea6RLclV5CUvY69yr3lvXe/j3rM+Wj5FPtO+6r6Fvp/81P0K/ab81f2P+U8HaAaUBMwF6gae DFwIMgo6HfQj2DK4JngjxDGkIZQi1DP0Rhh9WHBYZzh3eEL4QIRERFbEWKRqZHHkfJRpVHU0FL0n ujWGEXnV6Y0VjT0QOx6nEVcW9zPeIf56Al1CWEJvonhiTuKnJIOk88noZO/kjr18e9P2ju/T3le5 H9rvtb8jRSAlM+VDqmHqhTR8WnDak3SZ9ML0xQzHjLZMrszUzMkDhgcuZhGzorKGD6odPJ2Nzg7M 7suRzynN+Z3rk/soTyavJG/tkPehR4dlD584vHHE70hfvmL+qaPYo2FHhwo0Cy4U0hUmFU4eMz/W XMRblFu0WOxR3FOiUHL6OP547PGxE2YnWksFS4+Wrp0MODlYplPWUM5ZnlP+o8Kn4tkprVP1p7lO 553+dSbwzMtKw8rmKuGqkrPYs3FnP55zONd9Xvl8bTV7dV71ek1YzdgFmwudtUq1tXWcdfkXURdj L05fcrvUf1nvcmu9ZH1lA3ND3hVwJfbKzFXPq0PXTK91XFe+Xt8o1FjexNCU2ww1JzbPtwS0jLU6 tw7cMLnR0abW1nRT6mZNO1972S2mW/m38bczb2/cSbqzdDfi7tw9/3uTHR4db+473X/Rad3Z12Xa 9fCBwYP73drddx6qP2zvUe258Uj5UctjxcfNvaTepiekJ019in3NT5Wetvar9LcN7B64/Uzz2b3n es8fvDB+8XjQYnBgyH7o5bDb8NhLn5dTr0JeLbyOe736JnUEM5L7lvZtySjnaNU7sXcNY4pjt8b1 xnsnbCfeTHpPzr6Pfr/2IfMj9ceSTzyfaqfkptqnDab7Z1xnPsxGzK7OZX2m+1z+RfRL41etr73z TvMfFqIWNr4d+s72vWZRYbFjyWppdDl0efVH7k+2nxdWlFe6fzn++rQav4ZbO7Eutt722/T3yEbo xkYEOYq89SoAIwfKzw+AbzUAUDsDwIDUcXjidv2102Bos+wAwAHSR2nDymhWDB5LgZOhcKbMwN8h YKnJxBZaPF0I/SNGElM5C2ANZuvjUOQ8yjXLo8WbzzcggBdUEXIWDhYJFXUT0xHnEl+QeLCrVDJY Sl2aWvqdTINsqpy1PJ/8Z4UbpAOK1kqcSh+U61USVLXV8GrPd5er+2js0vim2aK1V1tHh6DzTve2 Xp1+hUGB4X4jsrGmCavJgmmvWb15hUWlZbvVpA3Gls2O3Z7WAXZYc1x1Bi6UrkQ36j3oPUvuEx79 nnfJ172qvUt9cn0T/fz97QJ0AhWCxIP5QthCacLgsMXwiYj+yJtR56KPxKTEZsU1JaATfZPu7gX7 hPerphinuqbFph/JKM5MPqBwYDIr/6BVtlAOVS7IQx2iOyx6RCPf4qhjgUuhyzGnIodiuxLr4xYn TEsNT+qUaZSrVMifkjwtfkam0rQq4+zYeePqSzWztXR1QhdlL6ld1qs3b3C84nE14FrE9fjG/U3p zQdaslvzbuS3Fd8sb6++1Xi7687w3bF7Qx0N9/06WTsfdpU8iO/2e7inx/GR9WPTXsMnRn12TyP7 zwy8ek71QnpQd8h4WP+l8iuh18TXK2+mRl6+vTd69l3GmP+4/YTFpPl7yw+WH00+qUyxTI1N584o zIzNXphL+mz0heJL7VfDr5PzZxcSvrl/t1w0Xwpa7vh58FfLut7Gxk78ZWE0PI0ew0xi5ylgSkV8 AFU5YYwoThNP+4CejSGR8QWzHEs661t2EkcWZz83O48TbwFfO/+IwJLgstCM8BORs6JRYhriFOIv JE7vCpIkSf6WeiB9RMZRlkf2k1y9fJyCOgkidSnmKlkqMygPqZSquqpxqY0gWeCmwaYxrHlcy1Vb WHtVZ1D3qt4hfV+D3YZ0hh+N2o2LTeJMfc28zAMswi1DrbysLW3UbMXtOOyJDiiHZcdPTkPO913q XcvccvckuQd6OHnqkaW9WL0h7xmfQd9Ovyb/6oCSwMyg8GDnEK1QkTBqJBPGI0YjF6P5YjxiS+Pu xb9MmEycS1rZS7WPe79oCm8qNvVdWlN6fkZUpvsB+yyng4HZGTkVuZfzmg41H248cjX/8tHagvOF Z46VFRUX55fkHE8/kVgaftK/LLA8teLOabEzF6pEzhaee35+pYZ4gb1WoE4cyQOlyxr1eg3mV5yv hlzLun628XbTQPNoy1Tr9zb4Jku7xC2121p3lO7y3UPdm+jovt/UWdNV9uBo94GHST1Rj2Ie5/S2 9zE/3df/9hn7c80XdoN+Q6nD518+fbX4hn5E8q3ZaMS742M3x59NjE5OvJ/9iEGinzY9MEs3J/OZ 9EX4K83Xn/MfF4a/Pfp+Y7FyKWXZ4YfIj+Wf7StJv9RWCWt669M78ZeCZlEVsDtaDIPDLGCncTMU E5QLVHiCELU20YUmjfYS3QD9BqMQkz5zEMsB1tNsjexdHA85H3Dd5K7kSeDV4f3Fd47flH9WIFtQ RLBDyF1oRbhIREbkkai/GE6sRtxI/JNE1i7RXV2S3lJAqkJ6t/RLmVjk7aZBzkxuSj5DgVuhlWRD mlM8oMSj1IK8tUyppKgyq15U01Z7ttt79xf1ZA2cRpmmguaQVpI2t3arjqXOK90A3Q29Kn0rA0qD +4Z7jRSMZoyrTNxMWU2HzIrNbS1oLHosM6zUrBatG2yCbUVs39tV2u9xYHN44ZjvZOS04dzkEuIq 6PrWrWSPxZ5l9yIPIY9GT23P1+QEL36vl8g+EuBr6KfkrxJgHEgOCg0mh2iG0oaOhJ0PD40gRaxF 3o/KjbaKYYp5E3s6zideOP5jwqlE/cSRpJBkxuTne2/uu72/M+V+6o202vSSjIzM8AOuWfoHxbMx 2S9ySnNd8gTzVg+NHX5y5Eb+maP7C1wLVY+xH1spGiq+VnL8+OEThaWVJ6+XPSh/WTFzavUMdSVv lfxZo3Nu58Or99fkXDhUm1pHvqh0iXjp2+XP9StXCFe5r8ldt2pMbmps/tmqciOirfTmlfbWWzdv 99xZumfYcaPTtmupu6RH/tGL3sN9nv3Gz7Rf6AyFvCKOzE70zSwtrmzGf/t/uM2GVQTgWBpSoWYB YK8JQEEnUmcOInUnHgAragDsVABK2A+gCL0AUh3/+/yAkKcNFlABOsAKeIAIkAGqSG1sCVyAH1IT p4F8cArUg9vgKRgHi0jlyAnJQoaQBxQPFUCXoIfQRxQWJYoyQ0WjKpA6bwOp6+LgG/BvtCH6GHoC I4/JxrzDqmJLsatIhfWIQomihpKDsgBPhc+hwlMdJbATaqgVqNuJ6sQ2GmWam7RGtG/oYuhp6S8z 6DEMMNoxDjBZMj1j9mD+yVLKqs46yraPnYO9jcOdk5KznSuOW4H7O8813ig+Et8af7dAiWCA0G5h ovCYyHXRbDEvcW0J4V3EXauSX6TeSw/KNMkmy8nKjcpnK5AUvpJaFQuVEpV9VMxUZdRYdhPVpTTK tCS0D+v06H7VpzBgMmQz4jQWNFEwtTCLND9h0Wn5zVrAxtH2iF23A9pRzynLudeV2c1rT537e08s mc4L67Xk/cFnxHfGnybANLA46FPI7tCisC8RJpF10YSYyNjX8QYJrUmSydX7ePeXpTKnFWTgM9MO LB0Myp7NzTsUeqSpgO4Ye9HnktoTHieZy/orDp82PLNUlX+O8Xx29fKF4NpvF49e1m+gu7Jw7WPj VPNs66e2yfaFOyz3dO+7d3l22/ZoPpZ+IvZUcSDs+c9h9GvKkdPvGMZvfyBO7Z3V/tzwdfWb4qLB Mv7H4Z+PVqZ+fVh9tda4fvS314bM1v6xGX8cIAB6wAb4gDiQB+rACNgBTxAKkkEOKAW14AZ4DN6C eQgDsUMyW9FPhIqgK1Af9BlFg5JHuaAyUNdQH2Ae2AM+B8+hFdGZ6EGMGCYNM4LEvgwHcAG4QQp9 ilZKaco6vBj+EpUC1R2CFWGSOoFISSym4aO5gtSvb+ji6ZnpWxgcGD4z7mPCM51glmR+xBLOysJ6 ly2QnZH9Lkc4pyDnCFcptxMPK88r3go+H34ZASDwQvCiUKawm4gCUsvNiPWKX0eeYvmSGVJ7pWNk vGW15AhyffK5CqYkFtKC4iulbuVmlSrVQ2pJu+PUczRaNX9oy+v46ObpVes3G9w0vGl0y7jHZNwM ZS5u4WB5wKrFes5W0M7DvsJh1InfOcil2Q23x9H9pEeX5wC5w6vWO9sn0NfGz8jfOSA98G4wdYhX aHs4e0RS5NtonZjaOJr4iITHSXzJcXv795NSzqVxpBdl4g8kZ81lk3Mm8pIOy+Sjjr4tvFoUV6Jw /Fvp1bLYCtVTv85UV8mdrTj3qVqkJuDClTqWi+WX1es/Xym9pnK9r4ncvNpa1WbdDm7V3jG7u9Bx utPrgepDvkfox0+exD3F9uc+IzyvGvQYNn8V8qbm7acxngmr92kfb0+zzB79Ijz/5HvR8qEV41W5 tVPr738v7MQfDSgBLbL6+YAEUAS6wAq4I7Hfh6z8StAIHoJRZN0TIGFIC9oDJUNl0C1oHEWJRJ2M Kkb1w0ywL3wLzYlORc9gnDFPsLrYWzh13D0KM4q3lNF4GvwVKgcCTGihjiTKEn/SdNGW0sXSOzMY M5owWTObsCixirGR2D04EjljuLy47XgseM35zPnNBMwFbYQ8hKNFDovWiT0Un95FLakk5Sd9UmZI jl3eR6GBtKpkpfxENWe3swZG86jWmo6pbgYSwRaDdsPbRn3Gq6amZs0WUpaXrKVsmu107YccQ53x LpfcHNzpPKm8PHxcfd/7qwXkBX4MtgnpDTMPfxbpGjUVkxzHHT+a+CD57r6KFPvUX+mVmQ5ZPAfn c27lHTrsl29YwFb4uMivePl4RindyapyxYonp/0qoaryc8rnB2tiaznqHl5KqTe8In3NoDGluao1 v825neXW8J2ye873cZ3nHyh03+zRfzTcm9An3Q8PzD+fGhwYLngl8rrize+3+qO57x6P00zYT555 P/1R9lPw1JnphzMzc5jPnF9kvurNOy6Qv/l8t1rkX1xaOrzMuVz3Q+XHyR8rPx1/Nq8wr0StNK+s /tL6lfmrZ5W4art6fLV/jWJNay1h7era9DrfuvN64fqj9fXfsr99fh///fj37w3ZDd+NExu9m/GP 9pOX23p8QAQdADCjGxvfhQHAFQKwXrCxsVq1sbF+Fik2RgC4G7L9bWfrWUMLQPnmNx7wuPVX6r+/ sfwX5KTGzTb3gDwAAAIEaVRYdFhNTDpjb20uYWRvYmUueG1wAAAAAAA8eDp4bXBtZXRhIHhtbG5z Ong9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSJYTVAgQ29yZSA1LjQuMCI+CiAgIDxyZGY6UkRG IHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+ CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHhtbG5zOmV4 aWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20vZXhpZi8xLjAvIgogICAgICAgICAgICB4bWxuczp0aWZm PSJodHRwOi8vbnMuYWRvYmUuY29tL3RpZmYvMS4wLyI+CiAgICAgICAgIDxleGlmOlBpeGVsWURp bWVuc2lvbj45MjA8L2V4aWY6UGl4ZWxZRGltZW5zaW9uPgogICAgICAgICA8ZXhpZjpQaXhlbFhE aW1lbnNpb24+NzUzPC9leGlmOlBpeGVsWERpbWVuc2lvbj4KICAgICAgICAgPHRpZmY6T3JpZW50 YXRpb24+MTwvdGlmZjpPcmllbnRhdGlvbj4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgIDwv cmRmOlJERj4KPC94OnhtcG1ldGE+Cv3p9REAAEAASURBVHgB7L0LnJ1Vee//zOy9536/T2ZCJncI EBICGO4QvNCqrRe0aD9arW2x7d8W//491Z6j53zs6cEea7XH9tNabUX5IxyFoxZRtEVBERAJBBIS ciGZXCZzv9/2nj179v/3XXueyc4IGCQJ8d93Je+877suz1rvs9/3t571rGc9q+DQoUPZgoICy2az 4chkMkaIx+PGNfFFRUU2NzcX7slLID6/XCwWW4gj3fMTX1hYGNK8DGkEylMHebxe8pCfNOLzA2nk o22k+5FMJq24uDjUMTMzE4p4e8gPPY5EImGkezt4rtnZ2dBWCpHXn9XbTDr5qZPAPYG6yePtJp00 2kGax5OXa+II3mbylpaWhjLpdPq4NNpJOm3lmnoItMN55/eceVan722lTn9OL8O90yLO2+J0Pc55 4DS9PM9IXmhzOC3iSPPyTpd7DvJxJh8H9+Tx34g0D06L5/ffn7zcU450gl/n85Y2eN1eF+kE0rgm 3p8vvyzxlPVy3jbiCLSR/MR73V7G209ez8OZQJ785w2R839II19+u6ERvc/R+8wrkv9e+Hvp79VL fZ8LDh48GL6c/BfaP0peUIKfyeMVhgT94Z78VOzBPwryc/iHQbrX43QW3zsN/9B4MMpzz8dOOeri TLy3zQGeuv1jdFrEeV7o5X9cXHsbvKzT5kwcZw4PJSUlgQZlSSd4ndznx5Hm956P+ojzerzzoY35 9UCTfJzpDAB9Lwctb7eDIveUJ79fc6as18W918M1B/mhAW0O56/T4uxAm59GWQLpfoYWgfwEr4M6 oe1lOFMuv6ynUY78BOi8EA1vLzScN16/08rP4zT9vLgN1Act5wH3BO79PaEM5b3dXg/3HIvvcxRy 7wfp0KG885w45ynx3rbofT72DsMr/604R+/zMezg/fJ3xnnEO+WB6/A+8+LByPxE7oknbnEaBCDo H6DfQyw/+EvrjfCPxelxz7Wn+w/o9Lw9pHtj/To/D+3kQ+FwyZj8HNAkkEZwmt4G4rj2tj8ffWgQ 73mcjsfn10Mch8f52eMpS4AWNL293gYvSx7SuQfAeEYPPAv3HPl5oEl+aHmgfg7yLeYPeT14HsoC MNByOuTzZ+faD2hSjnZ4HPee19N5T5yW18OZg0BZv/drzvnPRz7ocpBGgL7T9Tivm3inT17uoUfc 4jTSKR+9z8c6MOcnZw74ln/2eHhHgO/8HtH7fOa+z3H/WHI/2TEw5Mf0j9g/Wr/nh+easp5GeX8Z iOPD8Q+PeL/mTFnyAD7kI3DPQYA+h8d5WdKI4z7/5eM6/zk8zWlxpk7iKUtebytnDs/r8eTjmjNl Pd2H/cQTvF5o5z+X10ce6Pi910W8Py80OKDpbSef1088eUkjePs9zs/k9/IhY94f+Oz1eTvJ73Gk 82zeKTpN8vpvSX7uva2Q9zqpl8Of08t7m8nnAXr+DMR5G8jr185f7+goQ7q3mXS/9jaQd3HIr5+2 eRni/d6vaZO3GzpOlzjngcd7+zhDhzzR+5z7fuGjvyP+m8FLDvjFkc9nfxc8zs/Of86LA78H+QjO f/J5HOnR+3zsfY77yw6DnKFcL5bs8l9o0v3HyWcu1/5h8QNwTzk+AKfvHxX18mNwLH4pyEO5xfSc 5uJ4r4Oz54GGH8Tlp/m9t4+z0/Q48tBmDspykEZ7oevP7/Hk55kIpBPynzlE6A9plPE0L8O9t9fB 1ttCXaT5b+W0OJOHeKfnbSXNy1GWdA6nQTmCt4U0ni3/eUIG/YGOP6+3CZpcOx3nC2VII5CWX87z Ln4+z+e84AwNDqdLHtpIgCbB85OW327Py5lAueh9jt7n8DLoz3/E9znOx+QfEIzgng+Ej5FrmOIf EXHcM0Qjj39wTsM/LD5O0rinLOlOm7NLXl6Xp+XXR5s4vG7PA23ivW7iCXz00PW6c7HHQMHbRlmu 89uUX4/He9uh42X82f2etuWn51/7s9Gexfko73VyJm9+Hr+GHs/FBK+DH7znd/D2eV5o0L58ev4s xDlvKMe9B8r7vbeZM/URT36vizJck55Pm7zEU7+neTmvh3ivJz+Oa/9Nufby/iykOS1vq7eBPKQ7 j6Hv5aBFgB75o/c59y3CE/9d4RXvk9/7u+T3+Xmdj87r/DTyc/jvQ958Wn5Nmeh9fmXe54UZVP/A +CEIfBz8eH6f/+OTl8APyMviP6zT8HunkX+fH0c85anDX5ZAWH8Wf7DeuVCGwNnL+5mXEEDzthKf /5JxT5oH7gmc/Tm5dlDwfLSZw9NIhy5x+eW9Xs7Qy8/jaeR3nnl5P3t7vC7OlEMa9fLk8XzE+W/g NEKD9Mefm3hvh5f1Mk7HP3aei2uC89/zOH3uvV2cuacdHk9Zj/cy1Ofp5E2lUgvlyOPto06uaQfx HOQnUJ7DfyfiSOOgDL876R4W53daXp5yxBG8HHT8t+HaaXDm3mnk3+fHEU956vC2eXucn34fvc/H BC74RvDfEl75b+P8gv8E4v23oJz/Fv67kSd6n3P8hE/OlwWgJ4IAI53xfs8PQHDw4hoi/sNw70z3 M3FOizMHgXQA2ctCk7rzGxUyzv8hnvzkoQx0KOPloAcQYqrogR8a/RyBdMp4We49cO20/Hm8rc4g zwtN8lCG9riuHrrE5R/kzQ8AF4FyzgfADusdAmUJ0CKQh7oIHkdZ2ur10T7ycXb6lOHwePJDm3TO pDkvA/H5P9Ag0KZ8Wt5eylIvh7fBn4M0p006tDwP5b3j9TxOizN5vT3Q8/LEke51+HPNN3fhmfye OshDec4EfyZoQMuD18M97fT8i8tTJv8gv9PizEEgD+31uqFJ3dDjnF83+Yn3Z6YMdCjj5cgfvc+5 7wVeccAjeAmP4E/0Pr/09zkOE11i5MUj8CIS+ID8hebM4Xk8nR+gvLw8AK2DRCgc/Yk4EHEg4kDE gZfNAfB4enraJicnA1azzgIcfjF8XixExIkArAkAOT2mAzqEqIRe1QNpdAxNTU1WXV3t0dE54kDE gYgDEQdOAQcQoCsrK8MB+ZGREevt7Q1A/3z4DIZzEMB3jjgZiQTsAXEChEn0oRLXBFQS5O/o6AgT hCEy+hNxIOJAxIGIA6eNAzU1NUGD0tXVFep0TQp4DT4joIPV4Dm4zhEQHKBHamdI4GDvUjxnB3wk +ZUrV0Ygf9p+0qiiiAMRByIO/DwHsMRbsmRJwGzHZ3IhlIPhgD9nx/ZCIlyC9zOJHPQOHBBioq61 tTXk/flqo5iIAxEHIg5EHDidHMCYo6GhIYA9ArkDPJgN4LuWBiwvJDGI9vMJNNRVNaRxDRHyMGSI QsSBiAMRByIOnBkcYK50sfS+IMULu8HvcKDL4fAegTOBzN4JONCfGY8WtSLiQMSBiAMRB5wDqHFQ qxMcq8FuJHuPy82yzmdwNY2L/CGX/hBfVVXlt9E54kDEgYgDEQfOEA5UVFQEoHdJHrDn2o8g0TND y0EggWuX6v050NFDLAoRByIORByIOHBmcQBsBrOR4pHufSEmAE8A14NTMyR49DwEMnP4EIBMpPtK 05Ap+hNxIOJAxIGIA2cEB8BmMBucBtxdkgfDMaIhLayMJRH1DBkIJHBNHGmLJfwz4umiRkQciDgQ cSDiQOAAGA1mo31xQZ04NDRBkF8M5GR0VQ4UAHuOKEQciDgQcSDiwJnJAcA9P4DhLrCD6UFf46I+ Z9fR+xCAM0cUIg5EHIg4EHHgzOeA47mDP/dhhylEfEd/HoME7j0+Avoz/8eNWhhxIOLAf1wO5IM7 2O2COvFBWHedDiziGntMElHXcM91FCIORByIOBBx4MzmAIJ5Pp7nt7bQF0sRCaiTkeC9QiTNB3ZE fyIORByIOHBGc8C1Mi6g5wvpcXTyRHBgYsk9GR3gKcwRhYgDEQciDkQcODM5AF47ViPZ5+M3LS7M l+CJAPDJ5Pr5/F6B9ChEHIg4EHEg4sCZxwGA3tc7uf8bB/wFqxua7T0C19heAvaECOwDG6I/L4ED AwMD1t/ff9y7w0vnggXvFi8jc0G8axwE3jXykMY1B++lv7CUe748xHkgv9NDNclqQRaOQGNxPhdo PC2/Pq7z8zt9z0M9BC/L/Ja308+ke/t93ou2kY5bcK7946QtHMS1tLRYbW0txaMQceCEOMD7xbvJ +zM1NRXO3IfviZfQD6j5h+gvan7aCdUWZfoPz4HBwUE7cuRIcJvB+0PgfeIFJABmgCL37PXLy0ic gzvX+fl5gb0c8eT3PYK5Jo7D83mdTtOlGz9Di/ecsoCsX4dK9Mfp+T10COTnoB5UnOSjLM/BwTVb vpFG8OclH4F0gj+fP4PXRzwH9Ds7O0PeCOwDG6I/v4ADvJe8b7w//j5yTeA+uCn2D2Mhcv7D8RcU IlGIOHCiHDh69KiVlZUFwANIw4s2D3YOlg6G/oI6aAKGDnYAnr+s1O108t9L0vPfT8q4gQFpfk1Z D+R3uu71j3zeNtJoh9/zffg1NLinnnzg9nR/Xs8DLa5pM21wWn7P2ct6m6BBJ9Dd3e1Njs4RB16U A/7O8n7xXnLwjXHPEfeXCypEcM8LycvHR0Ac11GIOHCiHAA0cbTk7xPleK8ANX/fHPTIw8G9p3FP Xi+Xf8+10+IawOXMi704H+WhwwvvoMy7THnq8zaQz6Vr8pEOLQL5uc7/Bnzk4XnIRxmnS/ziNMo7 Der1e8pQJ+2kDGcO2sPwOwoRB06EA7wzvFcErv1d8+ugo+dlI8FfNAr4h+Mv5YlUFuWJOAAHAEIC 79Vi0OPeX8L8PKFA3h8v68DrahfeR39fye7vLXQJvNhe1u/9DC2/zm+XxxPHNTQX06EcacT7EYjp D/m9TfnP5jTo+AjQJ46zd1Aezxka3nY/Ex+FiAO/iAP+DvP+8Y34iNnLBadmJBB4ufyD4t4/WF7O KEQcOFEOOPA5qPFe5QfiHRD93eIeACRw5p4jn4bnId1pEsdL7u+q53E6DqrPJ7AAtgQHVW+Xtykk 6o+3g3tvG9fEUxbaXoY4gufjvJhufpp/e5SBFs/CAR3/eEmLQsSBF+MA7xjvlQeueZ94j8I7yIXf 8LFgneAZKESmfAJOKDpHHHghDiBN8E7x8jlo8U4ROPM++XvnNPyeNM9LGjQ4CMSjTnSAJs5p5b+j 5AdAHUQpRxniqYfA2dtGPt594vLzeD7Kc3hZj+feD+I8eJu8DDQ58umgh/e6iKctlKMtXi7/mZx2 dI448HwcyH+X8t9Jf7fC5uD+QnHmhfehJgQpFEkWz8faKO6FONDY2GiTk5PhPeIF5L3KfxF5+TyQ 5unE8b4Byhy8dxzkpzzvpp8BRMoRiOOdJZ8fXtbTPT95KUc9nInn8Hr8nnKejzSCl4GG33PObwed HG0hD9fQI0CDZ4IGwXngZYn3g/KYXra2toa80Z+IA7+IA/7u+Pvm9/6+h8lYbjyClxGpiY+K4B/X L6ooSo844BwA6HnRMLN0cPMXjzOBM++cX/uZeMCPNMCRe+zgieMABP3ay3APcHLOL+f5OEMr/yOg rJfxctQFffIS5+nEE1wIcnohUn8AZfIA7JThPn+XH+KcJvzI5wnxtJny5CNQz5IlSyI7+sCN6M9L 4UD++8S7zDvJ+xr3l5hI//AgzEdBGpmiEHHgpXKA3ek5ohBxIOLAqecAWO14DdgTEBgcvwPQu+Ti vQHSiGfw86lvalRDxIGIAxEHIg78MhwApwF2AtcI6pwB/4DrPqz0XoCzJ5KZex9S/jINiMpEHIg4 EHEg4sCp5YCDOljNAYajInT8XtgzlgTXfwLwqHEc4LmPQsSBiAMRByIOnNkcALcdux2/OQegpzfg QPQn0nsHegOX8M/sx4taF3Eg4kDEgf/YHHAcB8MR3LknBPD3CCKJ8HvPzD1gH4WIAxEHIg5EHDgz OQBeExzswfL86zAZS6QHQN2V+sS5Uv97379X8TEbHBiynz76mO19do/19w3a1HRSXYbM17I5j37Z woS1trXZeeedZytWdlh58E6oFYhzsnMW7ampMXvwRw9aZXmFVRVVWklpmT27b5+96S1vsZ7eXrto 00Zra22x2Zkp+9IXvmCXXbpZnU+h/fihh9XwuD2xbbs9s2uPJbMzNlckfVQsYzUtFbZkaYslSjTz nEna5FjSktNyiJXBy2GxrVy+zMbGhnVdJk7E7PDRbouVJayhrsEmRiatsabJlrevtNe+5vXKU23F Or7/b/fbgUNH7MnHnrTJkfEw0jmy5ylnU3SOOBBxIOLAGcMBBPJ8sHdBHT09GP5zm4O7Pj5fwicu JpBPFCWsurrKfu3XrrfLL7vMnn56u23dus26uo7YTEr2wMon62M7cviw9fT0WNuuVtu4Yb2tWLFc gF8m+2K5cC0us4JC6fwFuEXlpXITKxvpWKFVVlVYXX29TSvPzl27bGXHUlu+ckWwJW5ublFfErPt O3bZ3GxGZnsN1jfUbzNzKcvG1Ump7tRE0koTFXqoEouXaYHN7JRNpqbkta3MpifmbGI4beND41ZW XmXFBdUy5J61qfEpa65vtpb6Vlu6ZKn9230C9/2H7ODhbj1LsfUNDFtlaYVdeumltnPnzjPmR40a EnHg/68ccI3Cr/Lz8QwEMNR0KfHz2H24Ovl/XDjP18pQy4Idfb40D/r7vQO+9xLxhCZrZ6ettLzY 0qm01dRW2rVbrrYNF24Q4D9jjz32U+vp67NUUpsvxLVwJJO2A889Zz1Hj1hzc3MA/BZJ6mVlpRoZ lFhRSamVycNhWnXW1NfYwUMH7eyz11ptTYOVJOLW19dt9QL+QnUwTAU3NtSqsygycL2hpsqKYgU2 npqQsajccRbHLTM2bQOTSbWfzqjeiqzYJgX2mZk5O3qoR94UK9WONrtw46W245lnbGjysMUTmrjI xKxz32H76Y+2Wmp6zqanNFLIxqyppd2qSsu18KXU1qxZEzquk//zRBQjDkQceDEOuKQaJNQXy3im pOUwPYB8TAJswNP5uFPZiXnn4gY13Lt2hg5nYWWsZ1jMLzIFsC+Q86a4VDRzM5aWeqSkqMxmMzNW WVlmF1280Vas6tBmE9229fGt1qVNJzJzWl1YnAi+cw4d7LSR4UGrrqu19vZ2m5hKWmNzq8WlVoln i6TiWSHf20ftvHPPtaRcs2ZUT1blY5L89+3dZ/1KGx0ds7raKvutG95iExOTdlQjhrHJcRubHrW+ wV4bGR22ObVxJqtViOmUduhpEOCXSB3UpRWaQ0Fl9M53vMumJ+dssH/YkrNpGxkZsla1Y6hv2NIC +dK4RhgVAveySquorLFRqXWS2aR9+9vfDm53F/Mmuo84EHHg5XHAASpIvyLlZ6c6PDwSNrFBIEQy ltmIJ52BZ9qG7XrOZUdxcZGtWb0qSNU0lmflWPyMJ+NBXCAH3KGPoO7SfQB8MnDBmQRvhBcgnk5A 3jp05AiUlBRZQZYl5SxTF0BK0i5NFksiX2PnrjvbnhM4b3vqKTtw4IB07SmNAipEOx50+kODI2FJ e8X6SgGzlrcXyX+JKI9qBDAoKb67q8sOq2MYHRI4y19KdXW1RgHFVibJuqSk3OprGyX1Vwr0awT0 YzY6PmZLNVLo1IjgSP9B1aPl6HNjlpxRW4vV4qJJW79ppUYaGfvSV/7Rzlt3sfX2d4WRCRL8+vUX afqAzsHsrW96m+3bd0BzCA9pzsHUgb3KRsdGJeHPWVVV1cn4PSIaEQciDpwgB/bvP2CdBw9JsNPI PQA8QIp4PC8inyCd05vN25izdhkfnwi4WCMcA1u9YzvZbQKjwWqvw/EcwCcuLKVy/Q6Ve0bvDbhH zzMzrj03Cwqt6zD6eF2L8UuWtFtRsbaCUzltVaW/An0B8rnnnhMOfJ385OFHpFt/RpO2U1ZeVmHD o6PqGATa8l8iB36WUGehTdmsVKqY793zr9ZzpMsykrbn0poUlkQ/3NevydGi0IbW1jarAPCLqi2r 6qo0mkgUxaxGwF9SXGKFxXPWN3HUZoTayZScammiuL2j3Xo1yVteXm11TTV2z73fspqqZj1oTFJ7 rZWWVameIrvhLTdYTXWddfUO2JVbrtHIY5kmMOKalP2+fefee8Lig8/85X/RM0Yh4kDEgZPFAfDl +UJ3T689u3tP+O6ELvO4lLP+K9C3e2aGYx5OHUf7pM7OCoA3bLhAuHfM48DJbj8YTp3gtoO8+1Qi Lp4P6Fx7cCnfC89qwnPnzqclpe8X2B+W1UyZdXSssHPOOc/ali5TBWbpmaRl5t2vFigCnfwb3/h6 u/KqK+0ZTWbu2LFDE7GStJUXHX48q8apJ+rt7rVu9dxjvf1WKXBVc2Xuw0RCsaRp7XSVkdWORhBH Ow9az8HDmqCtsfazltnSZcukq9fqXdFokxOo8ppS6xputkcfe8xSmqiNS3U0PDgj9VFMuvcJa1/S KvVTmTwrar9SdPuzBXb/vz8Y5hDo85YuXRo6phLp5usaGxTfasvOarMVy8+yvRqlRCHiQMSBU88B nCoeFsYAVEjyBRr5A5I1NTUS6OSkC2OOMzTMScOBJSIqp7RUyISRkdHg4K+tbUkA41PRdLAbrOZw 0OcaHIePwbzS9UZkdoDnGrGf3oFjz7P77FmZNQ729QY9ep/05gf2S8Wih7ha0jTgmJVufVbSeCJI 6zlPfoy46upq7NXXXWsbN14gixyZLG57MgB0TExJy8pmREAfm05Ze02dlcTlpzuMzvRHPffk1LSl ZCEzmcztap5IxGxCJp5bNQ8wNjxkKzRRigopnUypbJkta15lwx3T9uNHH7FMLGUT0z22XvUO9Q9a ekrPlC210uJySftpa1/ebtdff73df//9YZTRpvkD9Gt79j1rV1x5mdREFXbllZdqFFFkX/ziF0/F 7xPRjDgQcSCPA2DR2JhUspqTy4WsVUj1u05agkYJX2gVzvQwK3A9LJzbtevZALJpYWJ//4DmDZuP M10/mc/hGA64B2Cfl/DBbsKC90pu8vVH+dI9aUlZtCxtXWorJb0PDfXpQQ5aZ+cBe1qgXaee9vz1 F+ohtBF0KaaY8VAZPTHADK0ZSfsVsrjpOKtdnYPc1wq4CzVZYdMzVl9ebrV19dYg9Uptpcwf48Uq o05G+pkpuXztGxywcenpRsZGbHhsUNYyRTJ7LLKBo10yt0xbZW2d9P2FVqxRRm1Do7XXtwvwl1uP yo1pcne8b0oTusNWmC6xmH6ESc0T8GPsGBkT8JvUNEtt9cqVNqU6qisrLIP5ZneXfV8WQxNjE1al F23tmtWwIQoRByIOnGIOpNM5V86obAQdMqdulNXdrwbIwxrZrNvS9jbNSfaHtUHEgV8I0flqcuJP VnBp3ulRF4I69YHrAeg9k/cKDvL0BqRxXySLlKb6Bj1EgWHjXlejyQVJv50HDtrPpCppaGix5StW SvrXUEFHkQA+hhpGQIqUjKoGXT/mkXFFZmQhUyCb+Gp5yuxYvdaaK6qsRvr3Sun8y0rKpL+X/h29 u8pgsjk6MiLb+T47eKTTnju43wZGB214atwmpfMfG9WCJrWxsblJpp9J2cU32FLZ3s/qhUkofkS9 aUwPO9zfaymNEArmYrK5r7RpzRs8vfVJO7j/gBaC9Wn0MBk6qCrZ9N/9v+/UdVrSf6m1a25g48aN zsPoHHEg4sBp4gBg1SCQB4ccn05T1S+rGgD2rLPOWgB61FEuXb8swi9QGP4QAHj4BN8IYHcAes/g oE4DF2emQF1DpdU31QeTykEBZm19rV2y6SKbmZyWaWSv7dmz0xrbmqyyRNK46mSBEytTqQS0L5Tu Pq1GMKxITU9bRSxhlZrGbaistGpNzparYyhWJ0AHwcKsmKT9hEYAcamESusSVtXSYk1T7dayrM1a ly6x/Z3P2d4Dz9mR3h6bVR0ZSf87e7qtqrnBWttTdt76dTY6PW7jMsGsLJWFj+zpp6ZSstuX+l8N nJLFTlz2/lnpiSZT07Zflj5nqRfOpGesT5Y/Yas3PXdaK3QPHHnOSis1+ohCxIGIA6eRA7nNafLd pp/Gyl92VRidEMBYP1420RchELBW6YC8S/Rkp+7g1AzwDagvkPcE7r0gcVU1rGBN265nd9iDDzxo Cal+Np69zjZftMm+8Y1v2aFD+21V3xorlxlRYWE5YjzTKGHyNSOJPqUJ08mxcdu+datlpAaqkIVM rRY+lTDEUG/HpGqhdPESt03ONVVO4K3Rw5wmYQslgbMoCim8taLIqrQ6t6a2Wjb8lVa+b68913nA plPaFUvt7OnqVnmNQqTa2bRpg43J/HJiVCtgm9p1PWH90v0lpc8vU4eC5U5cHUpGdfT290nnP2gX XrDBpmVSOas20ZbMrNqhkc0zz2yHDVGIOBBxIOLACXEAwAVkF2PpCRV+iZkQ1F037yMHF95pQ5jZ QIrnoGE0ynsfl+whUFlUaEM9R2xKC5OGNSH79Lan7Xv3fd/6ZCmzZq0mQKX66Hxuj1QncksgYA+r wgS4qE+mpS6Zlk389m1PWc/hLqlR5rS6tSbosubm5JNGB1I/9WO2qQiZJCleqpOk1CkzcmWQlq6e WWwaXFVVaatXrbJ156yTSmWDnb/uXGuqq5N+X2aWeg7MKgc0ykhIz7/+vPMDy2YE7qVlZdqHs8Uq 1VEUavVtgeqbmpwy0jKaDJ6WPv7prU8EPzy4cyiSWimrUUmxVFDZGdYSRCHiQMSB08eBnDoCPPpV C+Coq8BPR9sBdbQQYCgBPCe4sB6Anga5Lgdw5/BegWtCQUqrUHFLIHXKm1//eiuTmVO91DfdPV32 qksukXqk2A7u2yO/MtKXyxwy0JNkjs094P/cnn2248knTZ4UTJp3K9LkaUogjs38rAA8pclZ9PuY SoZDEjVlZ2SVk0pOaqJ0VMe4/NNMaCI3KTv7WVsinfx6jSouENCvWb7camWn31pTr9FG1ka1GnZU 1jmt0tV3yAwTffyEyrJit7a21hpUVt2JODEnO36Zb8lyp0RO0+IC9kMHOi0hRkmYl61+pdXIPw4+ b6IQcSDiwOnjQMD3RZqF01f7yajpeI+SJ4Pii9FAIAevAXwX1skPlgenZj60AJyJpFfgHER+xXE/ PTpk+3ftsGf3HrCrrt5iV77qEnvdq18nm3RJ3DPTmpytslHpw0eGBq2+uT2APQsFWLF1+NBhe+Sh n9j0+LhZuYBTevf05ITF5E4hK/XMrMA2qV+1pGhaXYBGFtKppISyWenUZ8WrAqRvqXIA32Lp72dl xongD32k9o6lZ5nISCUzY3sPaSXdzKwVyzKnr7tH7gzK7Zy1a21GhLr7BmxSHUhM9OaUv1l6/6H+ fivSM5bqGZtq62XC1WgDmvgdGhqxalnfsCo2pQ7nV1GqeLGXIkqLOPArwYFfQWkevjpeuIbkVPMa 7AanqZc6XVjnPgC9gzwNoUcggUJcExgCcH9UdutzAsmxAZks6njVhRutsqLEHvvZI3JpkLB2LQbo euzRYJbYsfIc03LWsLJ1WqqRvVrhNjo0bFWyr2+oqraEQHZGHUS8UBOks1rQJOkeqR/0nUrIOqdI HiiDxQ1DERykaeCh/wUsxpI+XQY8ORXTfPuKZJnT1tJqBRdqQrdUbo87O21/z1GNQlK2d89uec9c Y61NzfKxM2WlVmFD0tPzfKhssLDJ6PxbWhl77RVXqdNK2+f+6fMmRwryhzNr5aozq3bOyuY/ChEH Ig5EHDgTOQBGe+cCsHsHQzzXcQd3z0QCGekRXN9D2lHp4pubWq2x9ogd3LPXLlx/gUwbR2zbE49L 111or5c6JyE7+l5ZwWRAYgHlrEAc9wP4vBmXNF+lTqNGQC9djaXUAZSUaeQgdQl5WQGblSSP75yM VDNlojWbSakN8sGjidgiSfIJ9VgJWcrk9E+ir3pwvcBKOepeuqRNPnDkzEzmlWOP/MQOD/Rbt3zm 4Lq4sWVJAPZp1V2nidxJgf6I/PAEBqn9OGxbf/75mmzeHX7HJaI1I8+Z0/KfzwiAeYUoRByIOBBx 4EzlgGthOOcDfwB6wBxQJ8GldzIS70BPxv7RpMB9tW28YNaeevwJmxoetiktgkpIpXLWiuXSd6OV qbJxpGXZsmelp09KosYpGL7pWQSBHb0wNTfZKgublJyJFcrUsSgm98McUreUSc+OAzQ2CcGxWIGu C6WXwZ6dydSiolKLyRGakiR9p8KELSvPcLlQoOcok0nTiuUdtloTxhmNNMpkyjmjOYAemV6ySCqp idpBqWUq5aQM+9xCPduo1E2DUtfc891vy5In53yoW5uTjKr9QyMDYWK4QS6ToxBxIOJAxIEzkQMI 4y6s+3X+fXBT7MAO2APqHIA896RxfPeHD8uz42G7fP35wfKl98ghK5ZTsRvffoN05gk7oM06Vqw6 2w4e7ZW3uXHt3tQoiV6bfWg5M/QAdFyN4pGSRVc5SxupZgTuJZroLBfAVskFAsudi7U5CX7g05Lu KTsn2/Yy6fVjktpxaBRs9OkEZA2jDNpDRBO4oQ5ZDamDYSesKi3oSvRKFy+3xJXqIEY0EYsnzG45 GcKHTlKWQEOS+PGb09TaZJdcvtn27dwt3X6fOqiknmHKDh05rPbF1JZ4cPVwJv7AUZsiDkQciDgA RqOdAbe5RmjnHvwkhMlYR34iSOCeMxkpxP20/MZ39Y/I/a9MLQW641KJVNWUW5M2BHlKE7SH5HXy rI7VsmrpllQvdwNI6uoAxqSymZJUXSlrHRZCJTUKwASyRNK9xHDViG5JHYzOYeGThgZI9sXo6DWB mta8AMuH52RJY9MyHZLOPqFFWdpdMGxKwg5VhVpui7O0jNo7I9CnQ8lgnqlnQGWUkifMYrW5Xiad DXK1MCp7foC+WHMG6svssssv14RvzN74lt/UZimd9l1tI1gudwqogaaT46ENKamTTixM2wP//G92 61DGWtThEJJaAdzR1mrveedmqzkxIi8/V9fP7CP/fNCSUrd98v2Xy9LpxELPg9+1G++ZtJvf/1q7 Pr5dNPrsTe+73q7pyC3+ODEqUa6IAxEHTicHHMNdO8PZcZx2BO+V9AK+RNd1O14wSNQC++SsJkxl acmesbXVlTJ6kcqmo4Nd/OyOr90toCyVC4S1sn5Rp4DZpFQ1qGFwW4yeBf8PmoMNC5iwhKmTiWNc AI0DtIxAHOdl2blCmxyftgnp71lVxkQsvnIGNPlbXj5NDyC1jXzfZ6TewRJHevX0HKod9RmSuovk DXNAjs6SmF8K7CcE8hXaxWo6qQleZbrkklfZBfIx//W7v6nNRvrCxiZhWZc6HvzZr+xYbu3LzrJS 7UZVpJFDXCOLw12y4hkfCZ3Wif1waevZN2m3q7nHha4D9uF9SRv/+DUnDLrHlX+JN0lNfn96SHMl UlV98iWUHelN2k/UWb6faZZ00v5+PGkbxrmJgP4lsDHKepo4kJNX9f3n1RekWBltMNrPBaUKlxAs OS0EVkzm3yshlJgvNitcwgSbLBysqM+5Y1+gcEZdOHbTKKwdwXUke/gRJmNdZYP0DuCTiLTLPWmh lxCTYnrwicF+e82Wyy2rbfiS2q6vZ2zGhrTJR5305uP9PZpEzcrFgYBeZRMC6vqGJnFP+qNMgRyj TVhSAJ0SYM9IAV+lHaOKmHRNMcSQOkcSPLtWDaXkm0b046JZIvv80alRHePyf6bJUzU+q1+LCdpa uWQoZd9ZeZdEgq8oL7fKuiqNGtLWWFZrtSXVNqTJ4GJ1GnXyPa/9yW2FbO7f9Ydt9r+/9C+yyR8R rdnQqXQsWxqYU6ChAs/dsWqNjclcEyuenq7Dwc3oCf+qzC+XNtn4LdflQH3oZ3bNJ/bZT6ZzaxKE vvbsgw/bN5+YxBeznX3+Mrv+6nXKe9Qe+Oous/OXW03nbruzr9Zu3pixBw4W2eaNCbvvG4esrEPz FNMFdvZ1l9mGZoFv70678/5uazn/HLvm/CXHmjg/mjgWsehqer/d97Wd9sDQnLXIu+ib3n6VIbS3 rKq3z8mz5+Y2rW7uypVJDu21+77cbdtkHbv56guP1TOkNn5tr21Tp9ZRV2HXXH+hnd0cbdCyiNPR 7ankAGCeh97ZGe1D8fSXLTu0T/GssBfQSZ1bIIOMgtVvsMRZVyy0JgfqOVR3wZbOoXN0xm57dtT2 DGuuMUwq5rCpoaTQblhVY1e2s++1ME2UKL2or1igfzovAHMHevAa/HYhnWcLTs0ANsCdM70AgR6B jNyHnkGqlOTMRNi+LyVCJXIxUCGd95FtO0Kfl5CknZJuG/07YJ0RcwH7GnmWxLkZK2TVh1hSZ7Ef hwxSv2iUoDzsCws4TyttVvp4FZY+Ht1M1prljXJKi6aGNfk7rIleFjwx8Tsq//KVdfJ2KZAqlcfJ GZVjA/Lzzj5XD6m2SddfrpED9vT4ymiVB7zndu+2x57ZYZUtbcHOv0KLoaamx8J7EgsTwKUaUWgV Lr2hOqSN6hQOH6wLvvfrtInKSwrpSfnF3yZVTcZGOnvtJxSeF4qf/eq9dv5jSMnzYd+IvbU3Zne+ MWP/+Fif3a3Dwzvik/auJ5X3wVzMRyvTdsuOGbt8erc98L4N9uz9O+1dovWhtrV2jRf6Ref0Xrv5 o4/b33u+g5P24Sf/1fZ+6jcsub3PPqD6Pnf+mL1nvr0f+MYez2m270G77abX240dR+zGTzxld3vK QfUCT37ftn/qBjtbWrkoRBw4XRxwoJ3tvN9mHvxv8qCrubwyWfcxh6dQIOu/ub4DZnv+1TIrX2dF V33CCkskkFAwh/MB6wDEO58dtlueGLZZff9lEiaxKCTbyERaC0LH7f99dsxuOq/GPnxRo9WXir5X TkWvYADcwS0CgJ9vTcm98D0n2pMhIP884Of3BmRERZ4W8E8JwLF9L4pXBJ1619GjoSNIiDH4pamo KheIoidPWqncGmDZUiyd+ow6gQJtCg5IMySaEcAn1TCsccakMz/adTS4I4Ct+L2plnRerknUQknY 9E698kA5pdWzdB5Z9aYzAvxpqSXicqo2o7ZVyC1Csbxeos+vKq0Oe9PWHdhvxb3dcpZWEJytHZQF 0O69e23kia1aDVsgG3r50Ncz5VaSYQykIY5eDtRG7Hu7//ARe9WrNtslr7rY7v3Od2DRiYfZSXsN 0nleOLetXlK7/O/r72/XldjNN11nLfvut6VfF0gi7efey1DiC2+70K6X9DBy/4/D/blyGHfnO9da S2m/7dnxrN29q1sjqrW2bRc/bsLec1l7Xk0vftl5344A8m89f43d+r519ujf/au9Ruqmbz521K6f B+mSfLCua7J+qZxG7vmurb5/3N5133ZNwhfZBjmb27Bqld38tga79eM/tg9Isk/Ohua8eAOi1IgD L5MD8/gcgDaLYLn7Wzb7s7+xWL029xBeZaV2LEhpC0IBTkb7Spvm2nCrkn32/1hqQqP86/7KCqqW BsyjKSkZftwukP/YT+U3vr4irPVhPnJGal+W0IxMysJPF8J7+8zWQRuRzvqvrmq16uKc2xhoLIwK uDnNARzHqhE8IwD8XAfsFmYGqxsayEFCfgYyecGEpOJYgTb3kPQ8KaDPyFnYcNcRTWyOSWIulumj pvukMwfwRUrMFpiL2cPSmc8I0IW16mClT0fyVyP6Fd/dd1RNKrQJSexsNEC+tIBbFGxAap+lWrm6 VC6CKzVyqBSQH9UiKEA+pkndSenhu+WIjNEAOv/mJUvkJE1TnfoxKpZVhxWuq1astCF5sKySnr5B 5dE5V0nNMzGRc68wJTVTmRZ9wSRejrRGFbBpWpPHrU0tlpXq5v4f3i/JvNwuvfRS+HfiIV5p2z+4 wUoYoYx323/750N2+/bdtm1sg224pNZqdh2yi2/55s/RC5OmlU124+Vrg9pnZD7HR95wmZ3dhohd b+9pE9B3jdmjWql8n/oIW9b+kqTo5HhOhXT39j12983HpPVbJc1f/zyal9vedrFGJtqy8Y2r7bfv f8Ju79Om6W1yaNfWbTc/tss+9tixxzjRSd9jJaKriAMvnQMuSINrmYFdNvvM7VZYp2+Wf4Ndlh3v DQJnoKw8fNdZCXKoiGcPPWyF2++wos1/KszKvbH3H5qwv/zZsC1pKJdmIWM9w8KkcX27AThVWzhD RWocfT5f3j5kF7eU2vvOr39FAX4x59C+oJkBx7n2zqeQSA8O+JzJSJoXAsgLNTFa21hvcVnQINWP COzRjad1nZA+vaKyXKCr1avS/syGYYRULy2NduGmC6VH107dqhgVDxY2A4PDsoiZtMNHurSj0z47 KtfHfbJnHxPIjkxMSoLvV28Us5UrV9t5ckx2liZJ8VZJmFQ6PmjYJzahTUoqK7SBeLE6INE7xJaE 8lE/p/avkn3/2tVrrE5OzJYtbdcoQfptdUB4rqRzwjIIkOdZ2bnmKW1oft93vxuGPSMjw8H0ErcL 7Ir15Vu/7Gw6sbMmp89uaze2W+zQQqxrghpkTjw7ZJ/9u0Oa5EzY1999pfXf1HpC9JIaIeVCqW2+ DD7M2Ws+v89u19UXrl47n3aCp9wIzz509TnW/9Erbfv71ti/vXm53Xn9suclcN/23lz80Jht40qd a8+DP7bXbJ/UxsettvfjV9s9z1/0eelFkREHfmkOBMTOK411XdcjQntJ7cKtuZ7nbG5EGxJJqxCy CqDRRjBaZyOjcC1hcGbXt2R6PRgIDWsY+pWdIzLxltm13Jnv75kQyOsjUX6AXRfzFR4D/FnNJ/7n H3Vb3xRD2Fc+gNMI5Y7nSPcI6h4WthIkAsBzyZ5C3jsQV1leIjNFrRAVSGa1LRPSLyzAjUCNFkpV CEQB+jn5rwm+3KWr519TU5O99Ya3atVqk+0WkAavlqof/zF9cogWE2jQnphAHcm8QJO0c1Oym5cj sQapDOrkpKxUm5C0Ni+x9VqN2yWpHnPNuDqM5ZLY2ZwkpsVWFbLDL5d0XqxRRSkdgFQw1WrXpRdf Ynt275IZqDZN0XOUKa1Uq1zVw4UNUmAGz8liqkGZjO7cuStY7VTq4V79mmvtkZ88auOaHxiXWehL CtN99p5PfSOYU/YMJe1uqTVw59bRlrIgx2sSuqNq0h64bx5EXwLxmktW2G9//akA8tC85sLaFy6t dmz+2F12dsghSUUbo3/zDcr/ZJ99+okjdn1b0rbdI4sgjQxuu2mdbXgeSrc//LhtTnRJ5dVtzyj9 redLTTS0M+TsqFOn07nHPnnweQpGUREHThEHXNOQTUnYPPQjaQpKJNl3yj/WcA6bqVcyLIJ4OLgN 94ChsG5YLl26HrdYdZsdHEvbkSntIS1hdc9RzKkF3g7yud5i/ikgJmDIEbJBGaI83T9lr172PMPg +RKn6wQ/HLvBNARYdPaO6cGOnsY447imABk9jvvaylLrG05rEla6eOneszqKBNLYyuPGt1YWNCWS 9NFUBMk7MDg3WqiRRH2JAHeMTUJkeaN+NWzWXS2VSn2DRghSp5RJJ4+XgQmpggrUmVbL7n2J/New YhY39XVVdRZfkasPFY7QOXiwzGRlGaNOqEz29PXVtVYtsC+XdD+njohluOwz+Zykdezpgwmpemfs 9HHPwDMg1RMYAdB58ZakZ+VxU6tpB7UV4WtevcXOkR76W//6rZDvpfy5vetY53C5OsFPvv811mFF 9p6NT9nfPzlpF//dE3ZuZcLOFT/u3r7femzFC5I/TiWSWGfvWSWg32d27tkaNTxfqTwd+zOSTgDo XNBE+jnX2Parv2vnPziueQR0P2Z/fMkae9M5Vda5PZcrv77LKwvtAw925xLU+f7j29dazdCE/faD e+zTD3OY/bbw/ieq55uPHbGPXK2OIAoRB06AA+Bo7gvMy6zvkkjcnedSyTV/6FvmaqHU7JRsvrdb trzR5EM9pCC2I7mTJ4P3Ql2jsoFc7pxLTwnoE+t+00YlxSO29o9NaeU8GKBA7+A9hd+HqHnLOcBe lewaSNp1AvrcM5AhV1+uCPeQ8nO4PSV/AHdwmklY18Z4RdQf7Oi5QORHsuUg+FCAawiUyudMqcBD xpZSl0gi53k0BGKDjkoBNlYu1VqN2tej3aMkjaN2ITd04rJJbxbgsoN7OoWnyCLt5rTE5qQDZxEV HiKzU5o8UYkmbSnIBGxVmVwDiy7298XSo1VrFj0j3dlZre2yzS8JC6OS2mwEO/wypZWr/hodjfJj w1aBqRmNTsRfnqdaHUBPjyRndUjsREUnIcurMJLg+Xh+RhjQ2Lx5sx3RBDOra++55x5ta1hiK5d1 BEse8v7iUGU3/sU77MYXybjhd26w8Tdrk3WZ4dTIFUN+uPWz6+zWvIiz33mDpd+ZFxEuhzWRnYv7 yAuobUpWXWfpzy4ud+z+7De/wdJvGJO30QkrkZRfor1+CWdrpXP67Z4vj8Y0dWrU5e2t22S09bNS 55TUqbyK3OrFonPEgZfDAXAxh42CWsDewzFVBOngRVbAXxAr02TrqARCfdT6lgOYe3ndF8yDPOob 0oJAHnqC3BwkxiECOesdRifvdelCZUPgTJ5wplJAXofui4P55bEyZMkZXiqOBoaQm/9UFac0BECX gA7mAviAv6twFlQ3gHn+oimfwSUzBdfIzvyKC9daa538P5Yqr0CarQHLJcWXSW2CdU1DQ50WN/WL 8Rjq53wiB8bpAdWjaNGSQF4mkCWqq1kbgAzIXcK0zCT5+aRR0kKsauWLK072q+pAklLRjI9PSDVU p7LF2lBkRiqXAmutb7RyTa5i+lSoSduCwoQ6kTLZvLORiFbijk6rhxZVWe2kUmlbJl19kXT5SenV 5pRf3Zr+8aMzB5GbnQboUTM11OX2p+ySFVCPVDnLO86ynTu2L3SAJ+uXCuD6SxEbs1tvvs9+n7Lx GrteUvgvHRLaqetE7d5La9UZLK5JHZXehyhEHPhlORCwbx5PjwEj1DAQ0fcdIskVcoZqjl3pVnNh VneOZQ4/JPwFfHN4HDA5h8X6znNAO6e1PGQRbCmTjDraLg70mqSlKAILhA9C8PA//PF2LYC8IpiJ hThEdF5Tq533AhX+gGRKU0SuqC6EdceWXC1k9Az5j5WX+NIvkeI5AHiE2zJhH6obcJ37sJUgYE5v QIQnUBX3gDxx9VI91MjmLiMgTSWz2o1pxKq0j+xrr73GUmJaVbV0ZCJcIX/zMJP9WHmamGhTHr83 M0jguo5L2mfxFSA6qziYVqy6igTCs+qVu7XVYFq6/ympebrljIytBJE3sYkflV/8sbFhWyvJEjt5 PFcWl8gPjsqOTYxoxJBbFZvRqICFEnCcFbosfEqq82CxFb9bfuCHot4KPR+Aj/XPiCZ0U9rZalJt KJZd7oicnp0Zodw2v63Nvj4k88arsYaJQsSBX2UOAK6ujvHn4IvMgTNnfbIvGAqKpAFYeoWlDzwQ BG3yB7wPYKxrlQySPPgtbA6Hvv94/XJLLLlAtLO2tDJuS7QYKmRGWheeBTAHJ6CTI5g7+7WwBQOV 8xu1C53KgHGhrQvtzsE7DQ9Q/zzPgLCZ68jI9fKCq25cQAfPiUN4pwOIuz6HhjKJCrB7Js7Ec8CI o5pMzQ70WIc255iRNL4ncdAy8upYLEn+mqsut+H+o2HiNF5UHiRtFkcVxtNyJVAqVUvWSqSWSWgV bFougjMl0olntXerdPFMkJZIVcJMNj5oUKuVVpdbZ88hG5oasYN9h2QHX26N2i5wuXaLeuJnffbc jt1hW8ByuWOYKZuWa+JaPZj0z9LVWwWuFCalApL0rg5mSjPzhVphm8qm1WunNHpgIpbXS2aVqgzn DEwKJwT0rMYt0EQyO1/FySOpgpx0FmdGiNnZl181P7l6ZrQoakXEgV+eA/q+wNW0dpL7PzdagdbA 2MZPiJxwiHhhDzj0c2EBOGXM0bzRCqo7bG5wfwBy8s4BIpyR4gXwGVzhimBaUt5cOmsV5/yaxSqa lKNQAmyh3byp0X5weEL28oqivlC5AEDqaUmMIkScjqAeyknzX3/7KqvTaCAH8tSmoGpzqhu1O1yr mKI5HpN7kRu/12l/dlGD/emF8pxL5pMUFgvr4DqCOgdpYYmO9waI/QQHegd9zsUCwQqBaJkWSrXO FMkmXROa0s/uOXDUipYtMbv0EvFAev5S2aXLSgZPk0V6jqB/149WpPj2pUtt6ODhsJH3rGa26fOy MUnZkspTYiA+anrlg0asDQuixtgvVr/SuLYSRPXT01NiI4P9MoOS/xpNrnYeOGB1coNQUVtpk1rh Gnpulc0InGf14zCmYJUsUvq0ejacprHiNqEfnc1OWHwVfjzlCx2aVEHULaVOGImEkcf8j3Hcj6k8 UYg4EHHg5XMAAGQubW7fvVYwvFfWMMKawfdaQ/nVNlh0TthsKNRCRg/ClXCr75nvMtaywRKX/j+W +dEtcn1wOKdCh2YAeHUY+qgB/rSku6xcIVRu+g2rvPS9WsCZcxMAWWziP3JJo/31o702gP18AHYV BOj9GulQQiPbqL538xK7tF1qUzqi+XaBG4vBe1b1HknLfclgmT26Ww4fhXv37h+3t62usiWVwtGT HFwDA6YTkPCJW/BeSQ9AcEAj0Q/SOjWZ2dTYZOVyHGYp+UdpaLN0XL7ni8attGWp9ff2Wa+k73NX nCMb9Trh53xPTC+oAI1G7dM6cqRLDJcaR35rNIUinzdiniR/1SywTgZfNtOTM3ao84DcLUyEhVCF E9qJSjb7qHmGlnbYtVddbQnZ6x/WtoGjXQetdLhYppXlYUQiY3+LaYSQ0aRERiZXsB7Ty2GNFOjU OWb1J9dB54ZXWBgxmqH348fKZxbNf16JgoeKQsSBiAMnhQOFdWstW1pnBWOHZaLQbefY92xgZo8N ZjfJCm+dvkpZtghUdbEoAPZS+666XiaWWuz0+Fds5tBWm9Ue03Pz3zka3DnhQmFti1Vt+i0B/Vss pkWJQciDpoKssu1DFzXasoqE/dOT/faIFlAlZV+PWlmAEA4N9G1lU7n9wauW2Ds2NGnxpSwT81oD yPs9jhoPjc3aPWNV9mS60jpTWuSp1bRI++fUl8gPV94y+Dwav+wlGAVuuZAOlsEvcJe4MBlLhAM8 Zwc2l/QBwqO9A7Z800YrbW6W1Kv8UsU06amKBdrTRTEJ+Fo5WdEoIJVduiR/sSbwR9XnpHp1r7gy KJBEnZa95OjEmMBVNvAC4jDKQp+kRiWR4AX4E9LRjwvYp2UBU1WulbeiWVdfZ43L2i0lhX1K2/uN 26xcIg9ZwYiGYhVaDCUdPjtNFaMikgfKqrJK5ZDNv0YqQ6MTWpGr1miyNy2TG34QsSW0k74GvXzO 7FKrypRIB8FBHufHS/kRpp76iv3X77Xbp/7TGrv9M1+xw1VX2ofed2UYZQQ6h39gn7zL7E8+uCV0 eC9Ee0orhk3mqXSKpzLs/sFX7Ivf3KqtHEttw+vfbe/Zss52f/V/2Pdaftc+tKXlVFYd0f4PzIEA s/pT2HiOJS652Wbu/08S/Ka1o1vGmtNjUo0kLfazA5Y5/91W2LoxqIRhV64cH2q40lydXAAsv1ar Y1dZSf9zNitnfzMDz9nM8FFLNKy2RPtG2S60W3Hb+UJ1qXcVwAAPXEPpzWtq7IKmUts3lLJHuiZs V++EnCxmbENjmV3eXmHtNQlb36LFmvjimi8TLvyPQHVA7kxufWbIfnhU26hasx2dwtWLMEc4s66x 2P7wgjornS/vxV7u2TGccz7IO90FFwjeG5DJQz74Dw2M2iG5vh2Vd7ix1GTYsBu/MNUC1fbGNk1W Dsgip1WbdqStWvAdi8n9MD4o1MvMqkuNSy0Sk5MgbOZn9COOTshPTaEWPmkSlbFERvbsyPUJ2dPH tPiqdkmrlYhWWi4niwTqra1LrEVx7ctk6ihdfUqTpWmpkyb1c41pFWtMLhXCwi2ZZJar0ygRXflf VKcKYyknAABAAElEQVSS0SKrfvvp1selulE9Au+wXaE6lJy5FR1SzhwJ3/YqETo9f3bdaFaayWq6 rhMNPfYPn/+prfnjG2TbK++Oe7tszO60Wy+4wH7/opyVzJQ8Qh7YS21bXoRo2m7/6Edt+qZP2Z9c cOqgfuCRv7O/uWuXXXTDe7Vgaqt98a6/t3TVLfZHWzbb5z7xWdtx5SftPPRgUYg4cIo4kBVQx9a+ Wd+6rOu+/wGW1uuQ8Ubf09K/D1jm4Y9p3kxWOBf+nsVXv1HAjtrDJWhG5vpO9X0XVLdbUVW7JVZc YSWI8orEvQkjffm8ne8hcg+BAAe4HwN8gaSyrK4tCcerl1eFRZUIfOByXBil/wrz9VJ+QTAG4Gft z3/Sbz/unhLWaf+OkaQWd0pURIekfG3Vcbv3TctsiUYNCxUHern2vNy/YDdCOW1yDQ00wbcwGUsC 0nt4cF1zTyHuyUQY0OrQ5w4dtcrmetu5/3DYmg87+Ou3XGNLahuttqLWitnmTzbvMVncMJw6xgQq 01aCkugDJzXxOTk2oe5AC7BkgI0ePqtJ0CIAvrlBw5oSq5CqhQ1CmCSlnkrtAxuvqLFCWfXULjnL iqqVpgnSUXmVHJDUv0+bgGeoV2AdVDd6ngI9NGq1A4cO2849ezUPoO0LdcypbfSwtCmbzfm6weyT 52XU4fqt0Okpzu8DI07gT88PbrM9tt7+57kCZ72vjpGP/8vn7bqLPmwroBGsko6ljR541L7xvcfV IdTbpa/7Tbt4eZntf/xeLaKS751HHrWedVusxQmN7rH7t/bauVdeuRC3+5Ef2Fj7Zrt4qco98k27 b+sRS9Sts+vetMVW0EdQ5mmz665cQ+26fdQeH6yz6y5dYwe2yvna6vfa72+5SCkX2La7brZtj+8x u2iLva7ubvviHTvts+9eF8pFfyIOnFQO6PsigBWgaGzVr+k7/IzNPvY3lpUaB7DPDh3UfhNS3VTW W2br39rsk/9ohQ3nWWHbZRZrXo90qO9JZpaS1MMmRsGAQjimziOstkRIk9CZldAXYF2diaxElJe6 QxehNJnia2iPTX3Yh3q+B/BrdrBDi0M6mDKtPxPaCrVHXs4e6NIKd0nve0a07wVrhWQl2N87KXU+ 9cn/l3qJ1yyrsH/Y0iqQz+nlwRpCrvZw+bL+uKCOlY1jNzwNfBXl49wUU1M+uHsmeocmORhj96V1 0ndvufhqeYRL2sqlbRrCYH+vlaTSvzTKqdDwpEx5AFz9C77jpRIhYO8eZ3GUekeAOJ2QO2A9a0pl s3KrUFMjdYt8y89KBUTHKw1Q8I+DK4Ny+ZKvqamVY7NaqVXk91529mPaoGRoDJ84Q5roleln0xKt jtUIo7rGyqXqCPa10rtPyBYfVVOLNgfHGyVqIkYYuDyY05kXA3ajtsGdMbr7P/3Tm+0v//steq6p kA+9vf8w4WFe9M+U3ffNTmt/7Uc1sskFOHDpO260njvutP/1z4/bZ98nQEXYmA8Dj/+L/ed/2WpV qzfZ8rQk6k89ZM/c9HFb+uhWO0KenT+0hw9stresAbEVymbtvrvutIdtuX1sS7tGDU/Z/7rtblv7 rgvMvv8J++LWcVuzaZONbb3b/uqh79vv3fJJO7fzh/a1O4TdAnradeDHd9jXtq6ziwT0F//uJ2xp OjfSsJ5Hwyralpb6UNX1b9tk3/v8j21UQO/PExKiPxEHTjoH9C0K7JHYC4urLP3k523u6E8BJctO y7xZXigLyqXHF+hnB5+0TN/jMrwQYNeskLWOdO7FMjYWiIctRhUfVDSz8j0ioOcbBux1IxfGLRZr l5PC2uX6/vX5CLAf6pqSVxAJlxIAWQSF9F6geot0XSj/WBiLNM0Ja9Ijtm1umR2ViXnn+Kwdlq8b LPPYlEQgZz2S4mfZjYmgqLKiQvuddTV284X11qpV8OAI2HiyA1iNQApWYz/vng2Im5f0c5MCrrSn AWTyAAHum5c024SsV/bv3m8z8v7Y0d5u/d19Wr0qcCzQ5OxZy2xAoFvf0qHOUqOB+ZEAWnB80wcf NxollEq1Uiz7d6uScb/MLKu0SCopB0Tj8p0w3T9hteotsbCZlY5+Tkwf0IKpWgF9z5FumT+WWr3m CIb6B4N9/fDoiHUf7dICrmJrVUdUL5cJJQL3QplzFkpCz4jx05LgR2WhgwUP1jp9WtCVwgJHDEGF o+qCL/xSDRXphPCjM6o62clK5kH6ATWpK/89Jx6m5fBNG3gsr1soErq65s32J+96yj5425fs/tdf ZNctrDOasm/fsdVKN/+BferdAmqFBz/zx/bVr/zA3v7pv7DDf/LHlhbov2WNi/PKIBcIb14Xty9/ /8eW3vIOG936Q/UbbfaGi44I8Mftoptusd+/AOD+dfv0H/2F3X7XU/Y/NufKO5W4ZuORgsJ9Wb0F Lfzo4/bhT9xp06vfah9503Kaov6Shu60PVOyTJjvZ0JC9CfiwMngAEibF4JwiRqn4zrNTXVY5rnv WmbbP+kjza1jyU4OyavhsDQA+saLZPIsAc2mj2iBZZ/UBgJYjdJzWggANSc1c0VgISeSHKqUuYP/ bonNstSpP9fuPTBmtzw5ZKOSAmMCbUq5qhbBjyZunviJvT32kFVNHba76j5o+4rW2FRKHnqlD8bV +pSWqjP5G6pipKC5g/XS9X94U4P92nLNFwrwc4m5PCcb7OGba19cos8X2oMLBJjgmTjngz7mOYSq +mrriK2QJ0dZ1wyP2JR6pqXLmtWTxqxem4sUVVfYUW0e3rJkVWASwySWK8AkPVqYEGVBVLN07X0C 7bT8O5dpVWWh6BfOaKgzPGBdAu0WbfzBXHZa2wlmZYqUmpi2o9pikNFBZVWNDXZ32xFZ2KACamhq sFLtxTquzcjjGlmw72tMPunxW5FVJ4GevlSqngEtdkpq8dOEJoAr5YO+cKrAhgc1tNIPzrMy3KHn wx/O4OCQfe5zn1OahG51EjArn2GBGS/2Z+qI1DbyQZMvsvP88qFRdulNtuXem+1rn73D1ryLzlQ9 QnqvPSOhY8W65QtUL96y3r76eVb3atRDWaSSBQVQLtvFr91sX/7sVnsmfYMN/nivZnneay17npK3 +0q7eN28dC74vm593L4QepoF8i948bM7brOxqivsM5og9g4hsXydrCC2vmCZKCHiwMvmAABByOFx 7hqxq3aFdPJ/YAUtGy3z6N/IM+XjfNnhezSNtrMzfBcymBjr1fer7ykhaZ6VsjownSzA6k4AFDoP wFffuaDZsppjtKGHbeY7N9nopv9s/7j7bNsvtUuVLPliRVLfSlDFtDoXsrYquds+VPwtO7d21gZk Hj471GX7sq3BvD4ItIAcKBe0A1rGI7vy96+vtz/aUG9LytVpIe17UN7nfVxP/yXPPCMHWAWm5Qvr kFywugHoAHky5PcODvoDmmxd0rpMvlmatA2p9O2S5KsaZOlSo0205bemWx3AmjVn59Q189J8oeyR 0IPRO+KTgqNOuvZK+Z6Z0soEtgGskUSPP/ouuSkuln49JYDHtYE05fKYWWnl2qC7SBJ6sNBR2+id q6SeqRPIz2lINaYtBqUR0opclaA+SeJz9LKS1uOiB60hTdZiPjmtemalWiqSHo3n4vehN+Z5i/VS EIinR2QUEu7DsC/XWYWIX/THEfLn8kGvzH7rgzfajz52p336Nr2YpZsUl5Oq4zgQmg89ew7ol8np 0nNRx9I8T2LNtbbGHrL7vn6XjR0xu+rmCwTOAvzjOpi07e5UvR3zSC/+vWDz6FZmq2yNfP0cJ7hr ruQE+wlvWnSOOPDSOJCHg6Gg7rPobhWYdE20X27xN2/SFoFfsTm2CZzs1kLHefUIwqS+WfaILtB+ E9mCnGMzB9NABGjN/Rd6QJdxvP6OHrbCB/5vO3/uXfZk5lrrnsJ8g28tl06Z9sIe+52SW2UtM2Fz w4M2LaFzx2yrclADhzdeunh59b2yrdL+/JIGnbVpUgB48kAv9zy6WCjB9ckKADwBLAPDHc+JD3Ek AvDcEEgA6DjQ9ZDGef++Q1ZeVCOPkkvlr0abc0uXHlNvVV5Zpi22DkqXJZ838guf0USniOlhAHku Bc4a0kCfpsQ01KrQxuB9MtcsEpAnJXkjOZcmtKejJPYarXRld6kEZpoC6zL10vpVdWh1qtQx1TXa 2k/O0+q1OndS7g4KR9Vry7e7zHekaZGKqFhDN1XEBiU0JSl10769u61WppmsisUR24xURThn44mz muxRA+SaQR2RzDmzAv5ZTf7SWNwaF6qjSohW5tjvBJteOCSWS5rXaPKF0LFeZpav/bH91fe7wHhJ H2vsIml5vnfHXdZzwbutZWqnfeOHWpsgHbvrxKcHe5Vx+aI6W+x1V9TZ5x56SA1db6+Taidhm61d 4H/7HY/ahndvtqk999oPZJ2JHt5mNROr40eH03Zd2Vb76qOShlT/sWZqo5dN19qsnMnlh6kjO9V1 lAaHdvnx0XXEgVPJAbAjhBx+SUIvsSJJ93PnvN1md9xmc0ce1n7JWqmf1i5S5EFiXyg0X3bhBBCF /yEv1nbqEYIAXpGdtk8U/LNdUbBN7sOvsIPWaANZzQnKeHt5TNtqVvzQNpYPavOgCeFMv/1werP1 FMrNNwJVwLo5W1ZTYhc1Fdu7zq21X+/g+8k1OjQroIw/zEKDTvqFAzpnMNsxHewG9IOvG2pFkiXQ G7hjHMCZI/QOybjtfbbTZmQj2tbeKtWY9PDycDt4VM+rYVP7Wk2IyIadidjcmleAXRVIfcImJOAk M9hzGhIVqXMoLJeELb14Vrr5KbkmLpMuuFiml3GZTJZqH1i8YWY1qYH9PGog9ootl/RfIvt49O/T UtVo1ZQ6AjlBUx2T0q33Do2GjQOqamsE8LM2oUVWMyNDdvTwAdGXO2XVnxLII62zXiEjUC9mxCFJ H8ydkM1678FD2kqsTvvTjmjCX6v0VI1yhLUA8OcXhyrbIHXJF3/wFDOfyp44XkJWzIo33WQXPfpx e3weZd/ywffaMx/7kv3XP/ppjnzVJvsv70Nfn7YV7XH72l1/bV+o/5T07sfJ2nbe615r8YfutOrN 11pDKLnc/vB3r9DE7m1206O3hZj6Te+a19e/1i6q2mpfu0WqI6XUt+uJx+gcPEzZj+642x6R2ue6 C3ITsaQMyrW0ZsdsxbGMXiA6Rxw49RyYx8gcdAprSqotsemPLXvO2yx9/59Ztu8JSY/SQmixJpOu AVcXt0qF+YZDQPIVyId7XYJvGHj/euwxe51UlAOxOutKdFhTwbC1anSAS5Ss8Mm0Ov+Z2Tb789n3 2JxMJwVKSMhh/4sPXlhn7xPIF8u6JifOUp8CeUT/dIR8gEfdjjcAcJuDUNDZ2Zl19QxSPIFCAL73 DKOyWf/bWz6m3aAOSZovska5HSiX1M3eqnXyddOypN2WLO3QvWzgpSLBz7u6iPC0uDEGUEvCpB7E C2zHju1yZ9xnI5LqxwYGbE6NqpC3tfKqCiuRiWVSknp9Xb32ftXIQaOBYulmJicnRUM+cTQhW64J 3TkxkIVZZQL+cW0/2NPXa8PaoQpG12rEUFEhz4w6H+g8YHv27pFVTUISv0YAdBBZjVaY7NVMeqFU O80tcrOr+lGfDMgH/aQmbnvkimFCuv8ajSDgA53fXdoz9YRCzw/spk98x/7wr//aNhyPzS9SPG0D PYPqJMtkIXS8VE2v7HMlxxEI9XzLfueWv7XLXPwngxaa9Axq9rRUv0318QiNOWqiql4d5HGUXuCm xz6pydz6hcndF8gWRUccOMUcCMCpOgJsCp/4l/rGOwW2Q/qepUjp34+0Op9hUWNyqJsDX/UFQaBX HKN1vv8QgAWlMfcniVXCqyKUMat1PAX6/nenG+0Dk79jj5ZepUxkFgEdgPv/3NJmf7TxmHAEPZIJ dCSnIzz99NOyOKwOOIWaekqGLmCGYzkKqaCm4ezATi+Q02HnpHk6gAsu3CQgrpIb4j7pvMfENDkD qq23uoZmq5IevUQgX6SJ0NBXijl6VEgGc8YMqhfNhkMXwIXBLa2NNiqQn5I0HboXqV7YuCRGuhjb LwueoeyIpOsmWUWxzEmqG20owr6zdChYyBQB+tpFCukdCx3aXKLelgmShDg9rYnVZeownuzuDaOM mDbyTcqcE3NLdDG8LOjwhyX1M/TDTDQmPT9zBaWigVuF9PRUmHcoYZh2oqFli/3eum/ZP3zlcfv8 +7FNP5GQsAZZDj1feD6Q3/31T9nf/LBT9u83Hg/yEJD74cWdhdOtVsd8oqHnB/9iB0qvsA8FC54T LRXlizhw8jgAUCE0Brh0zAQ8Jwe0GOSA/Nx02OxYv1SwOcOPF6oZCuAC2wnmQFg0wHQVCN2GICro 7+k05lDxAtJKkQp5a6rdPjh6oz1VqRH6/NxBIKJMac0HHhhJiQrIBzH+5hp6mjCeWo+T3l0j48I6 nc2C6oYbmOpSPaDpSn3SVqxeY6Xap3VsdFgr1LSrkxYWITnXCEhrGxoFhnIeJkAu1epXlF/QCs/L 0+pISiotE5CnBfhpqU+q1WnUa0IVKRy9OD0pm34XyZadFazFUstUCtALJX3T61YIdGu0IpZJVla5 Ncp3fLnaA1u75WdnWqOCGe0QVSV3ykXqUCpFK668FWrnplWrbPuzzygv9q7Sn0tlNCY9/JyGfIWy y58JnZA6Gk3IZjQCYTJXc+WWkcnUjPJmBP5sgPJSwsX/18ct8biGfKco1K/bbFsSV2pB1OZTVIMG BO2vtz/7OJO8UYg4cHo5wHcNaB6TiEOM4sATaci7nwgAHQykUdtImCTHfJdwXGMB8jnRIh1Y4oL7 Au1Kla5st87+frlymbCqwqRMvROyKEzYSKZE5yL7xtQF9k/J18jsUDtYuSUOoj+EhE0IxweG5a5F 2FeJOpvG6b96C2VRa8C/0xBCh6i6wGyuOVM3wjXnsDLWAZ5Gk8CZ4Cod0isF6nGB8NR4vWzQWX0l /a708Y1Se6RkBgkYI22zgkxK3fB7wHwsY/Avgwljic4ZZscFsNjS12uj8cOdxTYpr5VYxADUFVXV cn7WHCTuuGa4Y2LWHJ2EgB6b7lnlmRL4VomRMxyiOympe1o0RqVLS2gnrDqZcKbCdcwmZFq5fsVy a64qsyOy7Nn13D6ZZaVCG+Y08kgK8NNqc6EmiecKWOgl/daUJoE13zA9kQqujbNF4os6r5cW6m3D RScuPb802mYN515pv8Ws7ykM1WsuWJgQPoXVRKQjDvwcBwI8HgeS84CpE3hkgztRRQjxJSQK6HOp JEIq/NGZWF1zG45cLooD9PFl19rUxR+xP/vSdy2l1bft8WEbypTZ0Fy5Hc7U2ZAmXVMJTbwK+6Rq EA1oURh6XHOes0OjSTusfWfXNag9uSoEri8VL0TrZQbHbYR1pHrwG7Uv90F1A7jDPM4e6AUoSGYO PD6iZ98mn/STExN2ySWXBIke15/YsLIBCPnYqJtNRlKaZP32d7+jFaxjdsXll9mSJW1yHDYn1Qq+ 6aXz1nW1VtlWScc+rUnQmOpLCezZVYoRQYUckqVkulLMZK4anZgTyMvOXUqa0BEMj49KMk/ZqNRI uEnAfzwLp8p0DcjLblQbi9cGp2eV0l01SL9ft2KlXSoV1EFtZrKv66ht26mNwPVrnX/Rq2TTXy/T qQIbHNHmwHp36KwOamI2npmQaaZUQiWy/olCxIGIA688B5CWU6OabxN8YTWHKfR8pxCgHQBWIMr9 WTkCB5wOfxSDEJmQZ8l4h+2d06paLYAKnYcsAE2m30zyBoAHtCnDcazXoLcIcUNaITmYlK6HOsPf 0//HQZ6auXb89j1GwoIpEhzsuXbQdzUOhWKaqGRO+cEHtRpTvUSvHIVdd9114YlmBMSD2nYP6Xps Qj7kJXWjVqFzuPTyq+y+f/+eXXn5FXbu2rPVGchnvSRn9DNjcpK27WePW4tMJUula0+ltCoVB2UC 67TMKse0i1WZ1CkpOg5tUsLgi0nTMqlnmLAdlm0/uvm0pPIKjTbSWsEaF/hPayKiFH1/plyrb7VL vNRJFeqkDh3tDhO/69qW2rLqBnv9xZfaoPL2ynZ/RvX1y4laifTkh/oH5Venyia7C21E6wOWNdeE Dun0/3xRjREHIg78HAcAen3nKNmzGZ0XoSt4tTggwRMEbwjhOdwmH6qNarlPmHVrBvK5wJsD8oDt oRLdB2l+nlAgKGdm8k7J8UoGMBuB2APYzeEamuC90nsDB3wywCwkdAIEHnjgh9YmqZzNQ57atk2W Mzts+/btAlS5GhD3cCnAytI6ScarV68NVjkTsj3t7+uR5F5pfd1Hbd3KlbnKRa9I9Lu1ymykb9DK NCKolSUNk7EFTHBIsu+RlE/HUiZd+6xWwGmpU1ANzcwkQ4eAzpxtA0tkX4vTs3L9NjM65qTCmdGo ADPNtFbAsSfthOpqVWeS0WKtI909Vim1TKUmXGdlgbJck5ON8r0zJgucZtV/UFY3Z63RHrMaBTz7 2IPWotVyMuuRl8x+52F0jjgQceAV5AAwHvAJn1q54fdxrQmqnRBDzpy2gisHe3qGAPaANgGJPRwA O3NxgD3XKsUR7r13AOxJJ5o8Uk9LeM1hKPHkP/3BsZqzW9vAI8f2sDKWZrkU7wDvahzOKPa/9a1v 2rvf/R6B/6yt0uTm09tkziN9eolAclrA2iDAZIK2WZOkGfW2a1etyO3vKvfB9VoEtWr5WdLRaySk idgSMSc1Nmo7ntgmv/aZsBp2cmQ0DMGqGqRu0Z6wbC6eVtrEhDocSe1Mg+OmlBHBrAAeoJ+Rc7OY JmwzMpVMSHVUoPiMNitJaLa8OKHtBCc1vJONbFZbCI4IwNlcvFSdysHde23FcrkzlcuEyYGUrGxK rVp0a/UsdbLxtwLNJ8TS9ruXyzHYVMpG5DxtSvMAUYg4EHHgledAgFmBLE7HCjTPBl4/H7wGHOaP Aiek+aDKCZhNiflS4XL+OuTPlVEpSuZOfnbbzEAwl4755XxpqnpFAhjtAjpn8NzBnwYFoHdQd7An IwHQJ45eYdOmCwXkAlNNruJb/qqrrhIAz1hTU3PQmVfJ+2RSgLtUEv/kxLg1aTept/7mbyiPDPdF Cym9UPl75Kum7/Ahe3bHTpuQ6iaj1ahsFD4pXf7UpNQs2pQkIV17Jp4Km4UnFZeWSqWcBVSig1on q30gZ9SmQvVebCGS1MhhUmojYbt8VMjRgPTpCYH4tPTtxXJ3MCUb/L5ZSfJyjlYk800crHV2H7Tm hnprkp18gfxmpLVWoFj+MdiTKtUvD3YTdXZtW4smZmI2jJqJRRNRiDgQceAV5oBQQKialbkzbhCy wg7JdSEuH2zBLQKncIRrKX81D4c1DKBvZTL6CMR0ciDnkhCKQ5ELHeSfpxnuXf8jAbFYeFnM+pxX EO4du9WIoEIH08FvD8G80plCJNeegR6Be45f/43rZZoYsyotairXRt0V8gVfIr02nipjMiuC25DN 4OJgVq6CNSkbk66+CPSVTn9obMq279pqu3c8Y2OSrrNSsZRivTOXlESt4gXSL+kHGJOpZKnAmQVZ Gend8SmPM7SEJHqckKHbx79zSuVZ2JRUpfTsYfgEIY0EEpp4ZUXu8OCIlat8pSaAcWcwo51rSrUT VTKt1bQC/wmNIkq1OKJc6UJ/rUPNuWNgVVm/3JZiQ5+Wa4eK4nKr1hqBKEQciDjwCnMgALBAXtgz x0Ss5g5DAKd04dhFXA7XcgCcU2EgcubikeznEgiPuX+hcO5PyKPC5My7nr8N6hyuA9oFNU6DVt03 nNgKxBy9U/jXn59nB79dug+TsUTSA3CGIS7R0x4Kcl8tibpYzG2olqdKnWelVmHbPtwT8MyFcuiT Yw5qFi1YkvpGGncb6umxZ6TTP3zogI1r85JxmTuyEhZ3wpOqj1nhhACaXWBYRQv7UvyAkv5nFB9X egmbjatd6ocF6FL1oL5RHkw1s/M27glJ6XQqpRoNYAo5qrompR7CjLNQNAB69P9zcnyEa+WUJmmx FmIBxaTag1OkEbk9qNR8wpDUTTV1tUGKT8S0YKpgSD58aFkUIg5EHHhFOcB3zFHRJqlSE6AS0vBQ SZCsLoQQcAvEBS0hRpcB18A24mXrLQxBqiedMrkj3PAnxPOHFPIHPU8unkLSOAQdfaBFloy1VyV0 vPJWeRjJwBueleALLYkP3WE+sLsax3sGzsQVz8nqBmlak6Nis4Bdy2vVQbIICXNKzCOVLUjxVYqb EWhu2/aUde7daz1dXQJLDSnkKnh2elwWMqWympkKNveFMmHCqyWTId5IGgpNcTTMCcxJdZOVCohV q+wxy8+J32j09LgAxZ6fh0poFFGKF0qVHR6SxY5UOOWS7rG4CflQ50hNU6JOKy4TqqQmctinFn86 mgJWE2JaOjytzkErfHVNKCmU+wH9mLlXKURFfyIORBx4hTlQuPQKm936T0EtHFQ3QoUgZM+3CyzJ rYIF4BUpsHJTSwAfsM8VmAd1wHHhIycuB5aBXLjVH1fXhHsRlcCJwciauhIZbcyPLObrP90nMBoh 3XE7v37SFrYSzA1tcsn0ACRy0AkEsJeumvsccwT1XIsxAKjWXUliltZEzNXaUuvdu8+efuxnNiQL F+JKxSDMIdNyKcymuphG4Vo0mDGJDp0jPQFuhTNSl3CLLxs60znZ3BfLaf+crG3YOIAjFtoB+DLa 0GpaSeaokXCfUCzpPaVtCjH3rBfAz6luOiHmFUYlqSfkOG2wr9+q5b6hp29IG5FPB/85cXU+hQL5 0BuqQUwEF2t0MDkxLAsdNDs54M9xKPobcSDiwCvFgQAX9WusoH6lHI49JwwHbnOSdxC6dRfO+pOT 5HNSLnFBZaMzNHKSr9IoS0zoKbhWAPSD1E68jnANIPk99UmrIeFzfatcswgOA41QkOvTG8An8Bms Dp2cwBNrSa55zlzzdEEEIR/gvWDIKKmZCRD6sISsU8J+iyJWqF6tSKBdLE+TE1299uxPt9rOnz5m U/0DVsiqU5kmoqNnZrpcapQyDbUk+8uqBvfDAuqwaa/qnu+OUeWwyQgoH2aNxde0LH1mUNXIVcEc 6helKVr6+1iQ5ItFkwO/9eoJBPj/H3tvAh3VcaeLf8Z0Y1vt2K2ZsZRE4k0k5g0iRpo8xH8CnIdE AmIM4iDQICB4QcBhC2ITBmHABGPCFmG2Y5bDYsdmjGEAMWY5CPIQZACfIDKRmAElDykO0kykSZ6U 2K3Ybjn2//fVvdW63dpBQGOqdG7f2pfvXn31q1/VreKOlw/JSVFyuIiU9QdZ2/+pdBgyoSB5Slki rXM7ZZdI/A9JR1Ev9eSpU9wkjefaKtWRfNXL5aIfSwfnk43G/vSwnGZjjEHAIBAeCAhnPSxHDn7x iaysi5AvV4WALeImM1jcrO9cVqmke5mIFeqQS+7yjY/idxWbP+Q/8SMPSfwAoTOIbkZWd1pVJipO 5KNdMaSHlM8ovO6RIScqXrTryBWQ1HJwNQ6vLgSHzO+U6HWvwAgMJ+H+WdQen4h03CBEy4NEqDPv IrrtxwSwrnIqVHnxL3D17AX83ysl+KTuI3wuHxB8LgeU8GBYKUp9CfuF6MfqZYlj14eFTEVt4paJ WxqWzU3LCG5XUeXwckkYj/HrIqTMrUK5D85D/GiLlZY7N0fjlgs8XrCLhPHU9aior8qyyf+pNhri ObJumTT+s6yL/ViWZ34q18Oi1qkXNRDPt/3DHz+CN5J79AiRy6Tup0L2ChB5zl+R7Ra4bz131PxI /D+GW86ClC92jTEIGATuPQI2mT3cM1NOHIpVBEypniRtraqhl5A7yV/xs20XrqIASI5XK7apTxaC p+CpWFriWkt46JRIJG7hAWWnJE9DN+2K7L/A3P8di294RV1MQdkWlq2Id/eXHK40LlKs5nRdA/K5 aFbYWFG7CGlqlQ17AtqVEp9kKu7PBLGHZJjCyQge4eWWBjeIpHyj/Cpqfv0b/FmkZx4Y3kWWWDbI ROoXovrgUkZ+SMUtDx59xKP2gneJbtxPlLnMSST1R0WCdwuZk1Q/FbXNwwIwT2Zhrb7oIqMFGT08 Iqtw6EfSp26eqhu1i6WEuST9V+QgkijZH+crjz8pecgSzv/8rXREskxTOgy/7MPzqHxJ28AHzJ5c tPyPSAfwodSTk7Z+2fnSJdI9l2DKPK1aMuqWjqRBJHyqo6gS+li+nJW9nBVO5scgYBC4twjY7CB8 JHtmpazEp4U5QrJcTEIhlKoKqZ8ifYv0KM1bvCwqYJK9cBc7BNcT0epAoa9FPIxfqe8hJaHElUhy lzwU8dvEzkw16Us5JPtv/7UHk/p+9d6CYZdOjtZcTsKncK61MyR+EZCtSQR+9KR7BC4vZEQ9FFDS vnR6D8saevlaCV+RNH/8zyr8x6WL+LXsfeOX7YbdooP/WLYw/uzjerhFpeJ5TFakC9lzGSSR5+lQ DUK6PLKPHcDjosYR1bssfRS36O3dkif3veGKnse6PSYdgxxTKGc/8npM9r3xPPaEHC34hKh/POr+ uMT1yl42fyVfvP6lfI3LtF2kMyorLZEq/glfi/oroXT5cEokfZbHJ8dRAjcb+lRI/nMZUXA/+sdk sparfT7jRmfygHma1OPyhSznEj6XLRm6yCfWH9XKNseffBQWD9RUwiBgEGhE4KGov0PX/zUdcqap eFI8VHSjyJ4ER+JXQiUFS3GTy0S+RNcnv4Zu/6OvzL91weDusjIvMAVHCZ6ZqJysu0OCF2IUwv8C T0dH4I2sp/GkqG7syExwzwzbpomeldASPtvLS7G8jkRyp52Kfd5pdGK3kCi38KWG/be//BV+LVsg fCwE30UkYRKlbPioCJsHdP9Z1scz9aNyjBMVN/x27c+ffaIImLjLBpMKmy+47Ed6n26CMtfSPCqk y50u3SJhU6XCI/8Y9WHZLvQRWcrJiVZ+7MTeqxsvUdk8LiOFR8T+uXx4xU3Rav/rN3hSRgCf+f4o h/R2wRMejhhkFwMZcfBZeqQMrvJ5WHak5K6YTzzuQZ2cosTtjPlF7WfSAXwkk7afS9keWXPPtT9q MpdDQ2MMAgaBe4+A4nOL1OUfGV3/drTo6j/Cp5e3yWZnfxJhmwQv1RTyUPp5RfJCOULYlOzZITye +A9yUt0TIrw+hO909+Dta39A2e9EKFXcJIlJVNT7kOSZWeD6HPF/9Sh+MDQO3WW1TTgZcjU5nIYc rjU05HLFXoygLz17yzsJVUv5j0ocqmvqZZL119euy2Tr7/CpLKGUaU8hYapVRGIWYudk6RecNJUl jn/mhkOyRw0PGvGLpP+knB7lknweERUQyZf72HwunUIDV77IZC/nzh8RwqX+nTtleuQMWkrzXeWj pm6ypw0/XFIXP9gSiT9CJH8u3+dWxjwxqubmTTws+peIrtK7Scfile0MOMLoIp9Jy1SyqGVkywS5 S+Xkstbic7+cx6RMuv2SB1cJ8YDyz7mOX1bhMDrX93ym3hyFofkxCBgEwgQBxVuPPAlX8kw8MjRf 1tfL164kdnK01JFf0auVNiKFkwM/l3lCz9NpePJ/T5XFHFxU8hD+11OPYfG3o0QIFLmXCeV/XhE7 ewVeNuE/JPc+sY9j//d6IT3hL0U1TPGUhh2LdSnnPfjR5ZO3qaVR3ycJj7J9NEpHzwAdkT0CI9NQ 5GdEhrmEHD+WbQJu/vt/oJ67QMqeMm6SoBA6j9yjPtxD9Yzo3/nxEVUhPNGFyzCpT39IpHQSeIOo hXhk3xeiJvlKFwFayPQzEqroyrnnjBRu4Srk+qgQsJSuthzuJuqgblwvT72cqGCYl1uWSrJD4W7L 9bJt8f+r/r3o/B9TPN5VVC+fydxAhHQY3aRT+EQmYdkWqp94dq1HvvD9VF4Cn9T3ib98Cv/vtx/I Adhd4JN5gt/LF7MxovqJkPw/k4fJPfAfYs9ujEHAIHBPESAX0WgC05Xh6jnX3wxH1+6p8Bdvwyc3 ivDnP/1RFoTIvJ8IqA91kW9p3I8joucgPJ46T0i+8QMnSvXj//YJfEsO+M79P7/Fr2tlF11ZTCID fjwqQqxHBMe/kB1wZ/1/X0XW38lOlw5jzRfYowuH/922Eg/nRe4mVrxTWA9sasaKabGfxM9EWpXD BJSMb1z7D/z+g9/IodIfyTp4rtSRiVmRzOtlq18e1OHicOczzmFTFSMqGVmHLk7ZN156RclPVOJC 25JAgOV2BkxPaZr71HMHykf/iqoSTppaHYwidlZW/jiNyh6A0wScRLU6I2mA6PT5lW6tbC38iWxy 9giHclL/LjJq+IJnP8oD5Yw8J23Zjj8zD+YmH2DJdLF0dbKcU87BZachWnn5QEq2OviDxOX6fOYh f2rTIklrjEHAIHBvEQgleGdtVCcggp673zyR8Kfh8w//U66bssRGvrh/sjselgtC9vpjSGda8lPP yEdRkPHX+K/6Blz7/Seo/fjP+B9f6Yq4J7shUrQVj3A7F+EDy1jkrl1Bed0DBwmdfK15W+voWRXi oiR6zfpU1WijewTVGwhx/vJXv0KNbEjGY/o+la7uC5GkuXGYOkRXEv1ZiLtBJPlPPuYJUiJj85L8 WKBajil5CKsqoqWbE74Eifk/IiTLynC5JUma+bjE38117UK+n0mnQohJ7ozPi3UVJZFMtsrumb4P 8d9ymDeHaN1kIpUTsNwPxyNbH3PSllsfMD4PzOXjUZ2EdA4y7sBD0gHwlCkebfiZLLOUrkDptggY 6+6XStLOMo0xCBgEwg0BTbUW8araiSDYpZsszvirnnIUm1w0EkyRkWIoTUBucySjPxeG/PUTbnWp RPQUozoRuYdEV2H8EYq4p0Z3gJrsWRnWWXPXQx988IHMiVpfwpIAdQIdiW6fnCiVkJBwTxtiCjcI GAQMAk4ELI6yfITShMjl1+Z9zWON8fmRJdmYyhbq0xkibpugW+LpAMG3weTtjddYn8618XwQ7tNF gVRrYogBBWcadfAIpV16srKU5Okm+TMB3ZRsjTEIGAQMAuGEgJPMNYVr4m5aTypstaE+W9tbvzvL aC1me+O1lsfthpHkNYezPuRvCu+8B3avZCGa0BnARHTzTrI3xiBgEDAIGATCEwFyNIVzEr2eY6Wb hqQvC1A4MWoROSV5Grp5cYmOmtgUsjfGIGAQMAgYBMIXAZK8c2TB/W7I4wGip9ROQw9GpltNWNp+ KtD8GAQMAgYBg0BYIkAtDI1TcNdqHJJ9F834jMTIukfQkXg3xiBgEDAIGATCFwEK55q7eedF7uZd Eb220EGi1ytv6E+1Dd1a4g/fZpqaGQQMAgaBBxcBTfRasuf8KjmdRnG5hkZL9kygiZ0R2CsYqV6j ZO4GAYOAQSA8ESBfa5U7a6jJn3a1yFITu5bemUD3COwh9GocJjDGIGAQMAgYBMILAQrqWlXDmmnC 10K6+jJWE7kmeEbUvQM7AZ2I/sYYBAwCBgGDQHghoKV33rVwrnmbfoEzY1ltRlCeopv3y9bDNLpH UA7zYxAwCBgEDAJhh4DmbXK4VsPrdfUkfKW6ofTOiIxAgtfkzkQMM8YgYBAwCBgEwhcBcrVzNwOS Oy9yOS9F9FTdaHLnShu6NfmHb9NMzQwCBgGDgEGACGiBXBM8/ZoQPT0p0dPoHoCRjDEIGAQMAgaB +wMBLZzrOVfWWncASqInqZPo6anVNfSjXRP//dFUU0uDgEHAIPDgIaA1Mlo/7xTUGabEeN0TEB7a eenlOjqDBw8602KDgEHAIHB/IEDO1kbzObmbPE6jJHp6OC9GpPhPfT2NMxPlYX4MAgYBg4BBIKwQ IE/z0poYzdu8NyF65SkEr3sDnSisWmQqYxAwCBgEDAJNECBvUw3v1NMrP/5Qn0OC1xOy9fX1QRkw jjEGAYOAQcAgEJ4IkKN56RWTWkAnp6s5WE3weg0m3dyHnrodXnrz+vBsnqmVQcAgYBAwCCgyF1In sZPkaah6J4fTrws96aCn7hH0nYl5GAndxhgEDAIGAYNAeCKgyZ2czYucrnc3sPm9q1LbUJLnxUBG JLnzop8h+vB8uKZWBgGDgEGACJCjSfbkay3FO5GxltXYERnAiFTXUH1DO8V+vfrGmbBz7H5Ul1eg xsd9ddzwRsWge7QnOGvpePxSF7fty46IdWvV+H3wwQNPG9Ga5tGe+kjefjc8Hc+8aXH3uU9nPIvg PORZC7aBxyvPutFxn4Nlqh8WCPiqa1ArNYmOjgpwSlhU7DYroQVy3rVUr7NUqhvt0HdnJC3V67DO vPsqz2FaegaenTkfuQvz5JqPSS9k4ZnJG1BSrUvyYdfzGRg27oAQtxhfKSaMyED27jIdoendX4Zp I7IwZntp07BWfNpfnyxkjNtr1aeV/L70QZ3xLELyKNmWjWEjpqJE7adnPfvBMwpgba/XWYj6RLgo R7V6oTorT5PP/YDA5c1TkfFCtvBMNkq+ZM9fEzzv2mj+5l19MEVRn4YeNCR7GroZpsOVZ2f8yD94 7pS1KJdDymNTRmLJq69gRe5EJMnZ5A1VZ5D7whporo+IYIH2KiCR0CPppKTXkuEIQMKirXPOW4oV 7N/R+hhpngMwGTNJ33s7zyIkD5fbaz0X+/GqZ19X17lE76tA9swcZO/pmCAQ/MIY1/2HQDkOHa+S anuRnrMGCSGKg/uvPcE11hxNoqed3K319oyp9qNvi8x1BxCc9a27fOWXUC7JYzPWYO+MRDujZAxI G4zXJz+Lw1XncbhkFmYmhZThTsSOUydCPOn0wyc9tFKnCAlTY8PhWajxMZKEhqpdOl6fCGvYRxUR ScndkpqI9VIRmpQZVLdmVE1+qStTejx37o1kGSRqtztSygmq0W042vcsmiug1+StODO5uZC2/Gyc W3wOjvTyckTTqQQIhz+t8hxq5XlRNdgR3PWzcguIfPeaMz5frVJLeSKbj9NWOOvGV6n1MiwxtaU4 1vvfeh7BdZcybcm3JTx0vd3SrtZeIVV20PNp65m1FR5cU+1qsT7+etQwkncw5qZrztGp7v87OVpf muzZKtp5ddU9AT2py2Fk6k252oYR6Md7Z5qbxVdVdvEJUSHZRmL0c8/g7PYqJEXxtbHfMh1L1DK5 I+bDlbMDa9Jjle/Noi2YtvokZHAgxoXU4f1wU2zqn1n5SS6iJlo+Yy1KrEgSLQ6TVy3D+CSr/A7X x3cVuzZfweHjVjtYTPryvZjbX7enBod+uBLbzlXYNZCbNw5zFr+CEUkck/jx3otjsMk3GHOS/xub DlyBa/ganJwtL6CvHK+veBmHS+vstNKmSSuxcGxisyTC4eji4/VY8uY+DFKNLkdeeg6KG+KQf2gr kgijjVtJ4lQUrM+Ax1+JXUvysD9QhnS6yROxenkWoslUdnxf1gbsmNzTrgdwQcpaftxt5dsMo7Xn WQQya8Zy491FmP6WF9sP56FHM/n7Sg4ge+EbqBOpTLf3ZtEO5K4+Kn6WccUMxCur5qOvakhIIdWX kP3CSlTS+0AeBh/QGPlwYdtaLC+40pjAOxCrN7aQjx2ruqQAy5fsVCNTnTB+yCysXjDMGnmKZ5N3 T97RtOnyPEdZZNNWOP8Hzm5biVUFje9afMpUrHgpI/COV1/ei5ylBwMYADGYvG5l4P1uK1zXvfHu x+XdK7FY3suAETzyBY8kG1e/YLl4ysrG/ymJmDrpFXlPk9V76i8vwLCZO5GaNRG+02+g2H5AyZPk /85bjLx8/T8LpOXuwMI06/+Z5XXomdoVbLU+6n3Os5573UEMHlom7/Ba63/DTn+/38jR5G7Or9Lu nGOlZB/Y64aBn376aUBNw0SchNUrcDoTiB79+6jsilZnI3fzAVy+XhmQHKJTc3Bw/1oMcDJ1oHC/ ktTLK623pvbyFkyyST55+EikJXpQdPy8Rfo2UfgrTyBD1EQk+aQhYzA5Y6Dohyqwe2E2dtmKug7X p8Ei+XhRO40b3lvV7tiK+bhgDyNKti2zSD6mD2bkzsK4IRKnrgKbFr6MaxTT1QhEKlRxUpE8O6hB Pam2qEReZo4ieW/iYEyeNBKx0pqiPXmYtrt5VUNsT3YudThVquQV+MuvCsmzjApcKLc6Sn95KUrE J75/b5G6arBx9DRF8q7EZ/Di4nlIi3OhsvgNPPu8nnuwcK4NUsv4cP0ih76qASwgyLTnWQQlaMbh 98lzlWdTH1IEHyVJPkORvAszNu5QndrNY8vk+ZPkvUgTQhmdEiOqv/NY/ML8ZnWw/gY/4hPjBG0x 0vEmp/RBhGR++UfTLJJ39ZbntQiTh8QJpMxnVrP5qKqLui9noUXyyRlTMWf6GCTJIyw/vRW5eg6p 9hLG6Hdv+ETMyBooZTegcHseDlVKI9sKF6xPLcmySN7bG+OmT0RqjJRxbieenWzPW1WfxrMkeVcM Rk+fZZdRpd7vs9R/thWuGhP8U124QZE8O80ZOfMwLsXCI/eFDZZKVeo9QTpM9T81fCqWiNo1XrIo 2vMypm2z3lO/3/ofLTogJI/eSB/OtgPFe1YiV0geMb2RnGw9i8L8WYH/nY4+U1XzNusTgQS7LMaP HZICJUeqxF+OH03yvHfr1k3xOAV2kjwvpbqhhYT+6KOP4uOPP1ZSvI5Ef0r1nWncCWNEkj2DTdLN lxx/Q13M3+WNwYCUDIx7bhh6tDYOVJWpxY9XyAsjr8+MjfuQqZRu0zBo2ywsLhBJ2ibUU5u3hsQB RqTGIWPuG9j/9nk8nzQMt1Kf9Fffxty+lM6BvpiA3OPSlkofBojXtWISYh+8LVKR6q/ShqGvm3H8 EK6h9ijAl8mT1mCNSOs0N48tkn8K6ZCmb0D+KEuSHj8qRY1iSg7sw43JieihYjb+REuH4MIVFJ8r E9EoCtWljVLY5YuCQ1Iiblw8rxKk94tH9cUNOCYdgXfIIuxbkKKqMjS1HyJnZGF/xUG8Vz4G4xuF q8aCxGbpzIO8bEd7nkVz6Vr3UzMzXi9uiuQ8XUiez3rO6/swIp4vRyU2bWFb+2DzeyvRS3XsWUiN X4TZe67ix6fLBUPST6Nxx6Zg6foYZA/NAUTyXsPRSvU5PHNaSEmG9Hv2z0d3Rk9LQS/vLOQeqMDr x8uwY6z1LBpzksdXU6Yk6OTcvVgjuNOMkA59TObLEmj1VBe2r1FCh/N5Dk2OkA7rJPYXViC6pvXw zLQKrJcXwiUjsYMcibGQUcOQ8OIEbCt9A6cqMzC0lu+aPObJyzBzFB/cMAxN9koZR3G9xifvZuvh g0JXuUkONZXy3oiZ8oM8ZDLL9CHo652KXPm/kixRvmeNartTEh/UvyemZeahvGAnrokKTuHITGJG 4sDuaWqEkx5bh+nbr0p7ZuHoevm/k+Bru6di9oEq+3+nrsPPlEVcaEd9pqyah8vy3MtjJmKvjLi+ bIY8rQVzSvXUyNCQ+GlXDM4IlOhJ+DQkdvYKTKzdytJpPx6MWLUPBW9uwBKRhFJtKauhrgpFBVsx PXMCLlAaac345eWg5Jo8yyZ5K3Lf5yaKfGcbfwWOKQFD9KKMXyKSrVw3/V6RlMVU1tjyaQfr4xqM cTbJM5v4lIG82caD8btPSNtmwXe9FJcvnsahd7dgY6El4ehY1j0Oz9skzyH6hSPW8Dwqwo9rdl2v lfsRK1Icpfb6EE2WyiO6N4YqUemKGu2UXBTyE9VUvIBQee6KtM+PEhI+Boo6Q/6JS6RDEDNUVFyK G5XLI9LiSGUrud5cPVVQyz/teRYtp24xhNI2KnYKye9UcdJe3WuTvKB1/ZIapcD7FBrKy+xnW4YG WaJLU1utugllD/oRXS2NnkT21VQoMo4XAg2Qk4QnjZ2q3pHy0kr7HVHJAj/u+Cycee8A5ib4pOxi nDpWgI2rdyoCtCLJCIirDUSN8vzwxo7Ck5SNzevWSCcU1UZ4HK5dtOajPFERuCnvknp/r1fBE2t1 LDW1nE+wSivZPg25P9yBU5dL4YvPxhmZy5operu2wgMNclgsigC2TZmAV7cV4EJJOeIn75Q8d4q6 Q9qlhoxxSE9V/0VWSk8iZmYQ+wqU11gdHQPSJo8JqLG697RG8iOeHRh497on97PSy++tPdN21sd+ 7lzY0dy/UaAS97GFpE5VPPmcd3I67wGJnm2jgwFkf23XOvvObruvtkbAjpC1rD0xSCTXQaOyVRG1 lcXY9YOXUVhVh41HSjFghgwZWzKSB/uC2DjHy8a4bmtSyHqY+oUTSUGWbzYxaqJUXrCO1sfjDZ54 0v9NdgE3ZOg7Pf9Mk+KaeHj7BJGLpqbC/DwUNomsQ0MDIjFoeAyOiX75eqUQnnRssVlTMROiQhAd 6/XqPigSoc41ZLAaXdQqYohB3/hGmmeObnvFS0PIPkehpTXrbtezaDZl65768dmxCrcfxcy+2Tb2 Nh51J5E7lyO7YNPuf2YbhoSeVgcRyEWeqQqS7zxYjWC0xEPmUtbNyZF3NZCiiUXN94o6KDYosQe9 ZJQlGVjzwS2Gi7RrN6Lu9GuYfbpJ9srDnZCN/Ok1yNt+HiXnjqqLAa64Z7BlfQ56tBWuhgnBefea vBIzaqh+pOC1Uy4rPH7IPOQv6AcZZImRdzeoXVJmpOVRLh3QIDssUvXWVnq/Xj1nOa3foDxu7Zm2 pz6w+kZnyV86O7k7dM6VXK6IXjM/SZ4XDQmem+Owh6Af751nfPjx89k43BAjQ+6d9pDbyj0yNhkL fzAVhVN2BhNpc4V7ohRxVRaXwS9D8MD7Yg+b1fsr/6EWV8jw/p1FiFZhImW5XfBz2V5ElJTjw+ud UR9dR9HdLlYkLxNiy2eJ7j0GkZGRuKGGqDpS6/cZr7+NofLPJIoeiSh1FX2nr8HbojorXlQvKDiI w2/tU1Lu6OSeSHCL9HTgKN55+6Ba4TR6SKNUCRnO3xSpK8nBQLUymqKJiuV/saXv9wR1YAGEVbyg n/Y8i6AEHXHEYfWbi1CyROYVqg7i1WODrYl43QmIGuDA8oFqAQEfttvdgFrRL3hig9U2oSWG8ls1 533UzLUdUzqvm2J1JSc2+y6WiD6aJB+bMhFzn0uREZS8S+5SZI/IC0iMirYafolqqZfNgZJjLS4X XoE7MdGivRbD5Zna73JSzgasSH3KWuElObj90kaZyIhWKiw/Ekbl4eSo+agWlcv14nPY/+5RlMv8 z+K3UnBwhrwLrYZbakO71dZNRryZL+1E5gIfbspo6XLRGewvOC/zD6/hx0MS4SX2MufEKSknjnXl leLjRd9Y8bVeIfv/z8q2zd9bfKYKprbq02bh93cE8jh5mtzNi6p3mgCn06Ej0a7JnZHZE3S+cSM2 gblW4cei/ww1/FKWxkeOa80ICYk6XEaKl3DdIb7dOH3Qml1nmCdGrc3nW1cvkn5kdKRcUZLul8iR tdSTlpyRF7GT6sPyxPjKr6jhu3f4LIzvn4hoIXm3lH/siEWkLud/hpXE/vUgKUGJSqiU/yCPpIuM lLpKI/fPzcH0KXoiNyiRcnji+yFJbCWiqqGqYIBI6+7YfmqCrPg0/eLEzyrYHWmVUVTMf0pt/KI2 Oqcc8SR6+x+ussx6Fgzwl5/Bj1uSXtvzLHRRHb3Lao+k6FhMWTVLpSzekofLxCe2p6WiqywXh0fh HC3PF+UHMF3wWn5c/Fsx+pVxu611lsXnrupmq1Q3Lp1R3Wyv+BBJ387TGgx6MXdBlnSYQvICb/XF M+rdszpIN6KsFxQl9qQ4k1YX7RRB4DVsPFfXRniNrITqrUq7WSEdlyfSaqO8EOUH5mP6zGkynyJq OX5kNnQYzspQLVowGTRqGnbseiWgvmwr3G6O4yaCz+gMWZki37LI/0z3hGRkzsjD3nXP2HFctjro Ci472iUvCN47x3/aGLtdjizbab21Z6q/pO78+rSz2mERTRM67+Rz2Rh0wQAAQABJREFUXpq/6ad0 9KwpHVpyp52ReOfVucaNobOnqiyLt8/HmCWiVyy6hLOFJ7BxyVQ8u9pSeYzmygcxLSks4O6J55VO 8Cpyxy3Ce6KbPLt7jUz2kNgo2fE3EuMWDJR7FRZnzsKhi6LnLJIleuNXWpNJ06mn7lh9mGtrxpPQ R+l2646vxeuFxSINFSA3PRuFquMi4RcrSai5dvV9dqLK+tjSZ7HuiOigS87hVfmu4JgIm94hE4NG P0F1cMfJPIftI+ogxemeOPTVHBU3OPCBSI8hE1T9SrbnIHfbaaVf3rUkWyb3pIIyUTWUUr7H/k6g dCumbRYdbdFeTJi5VRFfULna0a5noSN39F5vEXD0MOSr512HxUsK4Ivsh5kpok0W1U3W5A2iR5bn /+4aZC2lGseL54e0INHbnVhdwVpsPFYqEyzDMI44SVtHvrgDJdfLcOHdZfZ7JHMoQ0JUg3b1PfbM 9KsrduCy6OgPbV4UeHeri08ICfoxVFbJ0OyeO0HeBXnHj2xA9urz4uOSfHu2ER6PyL4yuSyx646/ jOwfFSgd/Ts/5HJaeSFcz2CQdOjx/fl+A6uel/8BmX+5VnIJG1e8pt7v7tHeNsNV4qAfDwYMpzBw HtmCx+Xr5TLHI8tIZXUbTZSslx8q82o022ayXaVSprynz8uSXvGLzcpusmBARW7Pzy09U/n/7Uh9 ZCT0ZTTkbs3fJHkazd+8q3X0emWNVtcwEv00yesM6N8Zxh2bgQPr3PIPuxXlxUdlZcHRxmxlGdmM xfPtCVbRY5KwHaxIp/4wNWnGBrxYPx/rT1/FpqV5Ko/YxN6y8kQmNe1I0al5yJf/i1zRYW5bYcVh xNTpa7Cwr6W460h9VCHW57rK6vxRnYs7EUtyBmL6FvnoK1/WwzOCLFObk+7Gpu1nZGndSgwasq9J u1Q+0UMEl3pMk8lHxiu0M/fKuukdC5JtV3M3N/oOHyxkdUZUCf3s4bQH/fvHYb+sHEke5Zh4lUmz LbvmyZfJr6Gk4DVZSWHnFzcSezZl2Wnjkb9uIsYsfAPlx3eKdCxxROc7LvZ97D8XBS8HB9yTRm4d eRZ2SY5bcB5WZi3/IybNWIbU49NQJBO0+68PxpSX9kqnmSO65DNYvtASEEjyM9ZtUaufHAU1Wj09 MS7ZJe9cHY5tWYZBqUcxZdMW+ETffqz0qOj79bsYhyW71gRpcxozES3Pc4ukLjkoknd3sf3+pk6a Ck/hThyrOIPFRwbjjEj7by+vQ/aKo/IurLSTezFu+RoMorQf2Ua4KJaXvrMGmJmHotM7kXtaZyFr 2nflWCu6kibgxSFXrf8BxzyUN2UWVsgqHI+sCGst3NkmbU96bhnSi+crPBYH8JD/GVEhZVIQiM3G nlwfJskyycMyn6TecUkcP3wR8gPfXVgjJUvg0jlbd743ocZrew66hWfKCe6262OV6IqPC1I3hdbj fnVrlQ1JXq+l56Ss5u6Hbty48QU9GJGeWpJnAk30H374IZKSqBzofFNbLfuO1FHcdSEySvTuIjF0 1HCjomrpqT0yK9Nievky8WZNPdzSc3hEJaIJKrSszqgP8/T7pE51ohhySZ3sJWx+fh0pr1nol7mh deBEHXXGfhe/0PQisqXKNk3YAR/ZwK1Svl8Qfa874inZTE7pGYLTS32ruYGb+PKLzvaYdj2L9mTU gTicTK8l1tIBUz3XHJGEZtf0S02u1KlUum9pLbrHt2fTK8FQ3j1/g6gR5d21HpN8g8DVMIJXADH1 xa3UQPSmnubq11a4JGXdfFIO29jcO+7nnEINt4to/v+orfBQfOhmmdV1ImWJeis6Klbew5BYfvmf 4nsqfbNHwqMbJyJCInbceSvPFHewPh1vwd1NUVpaKpPkXqWyIdGTz7lyMqC+KS8v/4KeeiklCZ6E T+mefnR/9NFH+Lu/+7u7W3NTmkHAIGAQMAi0CwES/RNPPKH4mgkopJO/SfTk966azPURVCR2TfZM QGmflzEGAYOAQcAgEJ4IkNi1wM473eR0zeVdKb3TkxftjETDDoB2+jGyMQYBg4BBwCAQngiQo6my oVDOO920B6R6sr7e7kCTPEmfhmI/w0n2xhgEDAIGAYNAeCJAQucHUyR5GnK25m3yeheSupbeGUlL 93pSVpN+eDbP1MogYBAwCBgESOpaH080nFvYMKwLxXuSOUV9LdHrO6V5Xszgy244qml5YR9bz2Pu OoaC/jqtY6naF1vvga5jt11/HbOVe5sYNJ+WK21ucvVJ88HG1yBgELjDCJC/NYfzTs7WbhatJHpN 9iR8kjwj0Gi3Jn7l+SX88ZXskCPsMjDB3mK1uSYGH3PXXIwQP5917OG0I61/oRmSql1Ov3z9OSwz C6/b2yy3p/5tZ2wf26i3v207gYrxZT6erZ0QmGgGgXuOADmamhkK5jSU4snfWjPThZKg1sNrQtfD AHYAvLT/PW/NnaqA/VVH6DJhZ3Ghx9w5w5q1y2Ju5tfiLorNJmqfp9/eiS+wXrwd9W9Pzuo7sA5t avblPp6tPZiZOAaBcECAnK21L7TT0E2hnW61bpIWXnrWlj0BFfu80+iEynFXf+Q4sVo5Uk+ILPK2 z7rj0WRCvrf48VGrx9y145i31mFrx7FptlpFHXNn78/Sep6NoVrN09JxcFZMa3vl8Y3JgmzN5tHa 8WzqIyD5cEieXevlBhVjHAYBg8AtIKDVNORqzdtawieXd9WETsmeYj7/MWmYQPcGnUn0vpK9cijC QcRnrZFj6vQGLdzsaYPaKyRpkhy6IQc9VF+U49FWhByP9qocj2ZvW3BNjp2bvae+8bg8Vto+Ks5t H4F34wj3LKmTU3L6YP8WnsIzEgXHpjV+scg07TRBx9yhDHlypGF5yhgMwiUclu1cLROHFbLH/oDm jrGTCCWyh0ruHtmLRw65eFsOuYgWv7aPTZOj5DbnYdXxCqsI2Ws+rb9lbenXeYwbTr+BItkCQhk5 BOJtOQSC5TY1Phx6MQu73PNwdNUQ2Rys8Si4ZvNo8Xi29hzLV4l1k/NwPXoCtqwadkvPo2n9jY9B 4MFFgBzNS6twSPaatynZdyGZ697gkUceUWTPnoCGiXTCzoJQ71BXfuSMdSyZyljI4V1rr5K0lJ7g sXTPKpKXE9unz8OLk2QfF9mYbPfS7IBeGjx2LmT6z1dTqnYP1JOg/lrGqcA2krzYYlMd2xmLuyMm 6Jg76RSZX9052Rr4XA14jGFqHDeCqsDyKTtk/5WmpmT3IovkeSLSLpvk23EU3uXN02ySj0FaxjOy 90oFCu2zaAOqm5DinMe4FfmkY2A6niZRdVQ2xyoOid3orJOKN5RXKVTbzqP549nadSyfPLuzcuZA ZXHnz180tsbYDAIPDgJaxU6+JsnzouBOLlSaGkJBT0bgmbE8TlDrerQ/wzrNRPbBuDjZ+a7iDC5X zsIIbpLkK5Nj7KQE70iRhmvw+hRrB8IXd+21dlPEEAyQM1U5Eji8+QSm7M5qvjr2aCQ00Jssm4Kt yrC2NQ4NvBV3gGFj5JDqnfah3GPgSZedJhuuQk4UDOw/zm2GS44IyR+QjdZcA7F5fx56qcmAdhyF l1KHddypkJ3DITkuj+lmTMCuGc8qvNpc5eJ9RkYO9uZXY5Mxhrt2Fl+RnXSSm5WirW2oQgBpKQ/3 NNk6OOR4NjmWL7s9x/LJxmI75JSlOrfsDxNSnHEaBAwCt4YAeVqvtiG5U6Knxob+XSi9a7Gf2ZPk tchPN6V9Juo848ag5yihA4cLy9S9uviMkpCTnpVhvGwGdp3FiZphkONgDE/SGIyj0Fx11TESUMnb /Bk9aVjnkbxdGkmWe84PCuhBrJOenJVhf1AuB3vnyjmZ3FVxRYDkpW9rx1F4vpqrCpfknFl258Dc ZevlSXpvcLpbNum52Y1qmkg5cpD4tWvLr8Y8W80j5Hi29h/L50Z3OWUpKcHaPbSxNGMzCBgEbhUB cjWFcxoSPNXwvMjxagsEEjsj0UNHZC9A0qdfp0r0UonI5GFyKMYZlMthFz7R019497z4ejGaZ1C6 KcGKmkUO7QgIzspHH05dgTqRmPW5lnZQCzfScQx6RYXm1EL0DnrLtu1BRjabbMXU4cfvyvGIgXkJ e+/lVo7C88mZtjQ94oMLcrdzYjp0gGOtqmmlis0EdSgPu/0dPpavmXKNl0HAINAxBDR361RO3u6q HbzzYmSSPq87ZuSginFyaMSqc+/jbEkyCqm2iRuDvhzHC4nTVJbxBCTn8Xf1PMtbGL4PoiReQA/u IFd9WhDT3w1jHznbYlFKtRIzBntW9caqF16Wk4Hy8F5agaWu0nqXVo7C88hpVTTXy6ThCY1KDj0H 0WLB9zigo8fy3ePqmuINAvc9Alplo3mcbhpN/l1C1TRaP0+i12E6cmei0Xd4hmTHQ7tXqjNN056z D8cQEVLtjF56Htc0GUpMf/kl65SmhJ4ONQzPPtW18uPUHn1ohPbr4D1UfO1g8uaix/bvJ3u9J2NF bh8VvElO7WEnpSel0cpReG57yFAiZ4za/Z+k9OPs2yeaK+qe++mOtu1j+bhstlb2bW9s1T2vvKmA QeA+RoAcrTUz5G7tDnQAmvnZEzCiDqBdR9aE35k4eJIGy5SgNnFIT7b1tSLtP5/Fs92uYPboRTgl x6OVXDwgR9ntVJHHTRqoVDpu+5CDTVN4ROAl7PphNjbJqUG3YyqPrET25KlB15j0CXjHeShtBwvw yaw3TXTaPIymjlxUNauOyNxEO45Nc/OYO6apeANjZvDIulK888NZ2MRj/8Q4BjPKfc9+7OPZVH35 6No6lk8m37PHP4us5/c5OrB7VntTsEHgvkeA/O1Us4dyt1pOQyLnxYh6Xb1W4zABr843sRivzgAV bUzKhKDzUJMmb8CS4bI0R1awrJfj0XJXvCGyvwvpi3dgiq3C6DHqFUxOpKZelk+uWClH3PmQljVS nYcaYMCOfhzVIEv+qqqCrjrxk8OLRAQPplW6QrzEp7U4kZi5fpaaWyjZvhUlkiePTZuRIkxexaPw ZK38HmuuovEoPA+m7NqANInSUCFH1kmc3bKcMylZsKEJFGcf2xY44cd2B8Kt6OpXKeod7hat7c+j 8Xg2qa8cy5cuZN+gjuWbj+X8bkAOJw86lk+P2ngQuTEGAYNApyJA7qah0K7tD/GEKRJ5wEPsjEDi 59pM3v/4xz8iMTGxUyvDzC5vnqAOOp78egHGy0HHoUYdf8aZV2G0yFg5yqxpFNlioAZujxC+O7IZ 4g3NMTzd7Tk2rdo+Si7SG9X0SLcwbFbHj+ULw0aYKhkE7hME9AlTmrPJ25zL0x/AqlU3TpIn6TMy yZ76ehom6kxTfb1Mziots9aIe8dgRDMkz/LccrZrD7laM5HRrYe3ljZcwtQZts0c2eqsX3S0rEi6 j0yk1LeNJt1HrTFVNQiENwLUy2u1Ozmcdn1XQjvVNdowgOTOu1Pfo8M75+7D/rlywryd2bjF8qFR 52RscjEIGAQMAg8kAhTW9UUASO682AFQHR+Q6Enu9NSGPQIT6l5C+9/+3YNx615BkpwuHxnfB0mx huZvH1OTg0HAIPAgI6C1LprgeaewTv6mXRG9JnV6kNx5p+EXsewA6NeZJjopufGLzc7M2ORlEDAI GAQeQATI0+RtCuskeLr1pXidYr2T+Z0YaZLn3RiDgEHAIGAQCE8EtHCuSZ53Gk32AdWNltp1j+Bs js7E6WfsBgGDgEHAIBAeCJC3tUDOOzmbmhptutDBi4Eke6eeXvcGhug1XOZuEDAIGATCDwFytOZp 3snlTuFdnRlLQueSShre6Sb564R0G2MQMAgYBAwC4Y2AJndyNu2aw7vSQ0vx2vPjjz9Wkajn4aUT h3cTTe0MAgYBg8CDiYBTQCencyENL+2vTpgikTvJXk/QEjL90dSDCZ9ptUHAIGAQCH8ESO5aKKed Qnu3bt0CEr3S0dNTB2qlPv20JG/IPvwftKmhQcAg8OAioLUx5GxyOXmcWyBoXu+q90IgRAxkRJ1I w8bIxhgEDAIGAYNAeCJA7tZCOgme0r0W0MnnagZWEztJnnoduhmRhn7aHp5NNLUyCBgEDAIPNgJa iuednE0BXgvtvAcOHtFSuyZ23ulH0tcdwYMNpWm9QcAgYBAITwQUmQtn623m9Rp6crfS1DhFfh1I CV7P1rJZjGOMQcAgYBAwCIQnAloYJ1eTv7WAzg6AdvVlLKtOkndGon6Hbp0gPJtnamUQMAgYBAwC 1L7wIm/zTu7WfkraJ0T0oGFPQE/q6RmRRg8JlMP8GAQMAgYBg0DYIUCBnMK6Ftjp1hzOynbRKhod wDuJnzO3KoIQv5mMVVCYH4OAQcAgEJYIkLc1d/NOo/14Vx9MaeYnodPOi4G6hwjLlplKGQQMAgYB g4BCIFQrQwFeczgjdCW5a08GKE+J9MgjjyiiV72BSPXGGAQMAgYBg0B4IqBV7FovT97mEkveFYfz R0v0jMQENNTT09CPkr0xBgGDgEHAIBCeCJDHKbRryV7fWVtF9JrE6eBFoxOoCEaaV5iYH4OAQcAg EM4IaP7WwrlWwdOtVDfOyodGdvYMznjhbv/000+xefNmFBYWoq6uDk8++SS+853vICcnB48//ni4 V9/UzyBgEDAIdAgBCu3ka3I47RTYqaFRAjs9nKob5sxAp3+HSguDyNXV1fje976Hd999V5E8q/SH P/wBhw8fxvPPP4/f/va3YVBLUwWDgEHAINA5CJDDNWeT7LVWRtvVFghOqZ3sTzcnaJ3bFXdOde5O Ltu3b8dvfvObZgurrKxUkn6zgcbTIGAQMAjchwg4OZukrwmed3K6dayUNIwOXuwVaBhBS/b0v19M fX09iouLW63uz3/+czBeREREq/FuJbD68l4s3+PDi+tz0MPTmMO1Ixuw/mIEVqyfhu7iXXJsC17d chJ1KooLyRnzsXRGCqwkfpz60TJUpszHlL5RgUz8laex+C1gxUtD4Lu4F+uPVEiY9b0DI3lj+2BE VgaSot2BNJbFjwvbNuBwVb1Et+O7vUjNysaIJOZfiV1LduKG5NWgs5Pw5JRhyExLRCC32lJsXLIW xyrsWsf0wdwFizA0wa519Tmsyz8Dn1vnw5R1iEqZh4Vpbkl7EOmr5qNH7SXkrSjGlE2CUSBzq6bV ql1lliPwK/WOGoYVC4bZ+AQCxFKL9zavxabjV23PGIxePB8zU3uKuwa7XlwJ/6hlmNm/EUf4y7Fx zmvwTFqG9IYTgmNL5Q1GSShugkZs8mCMG5WCaHfb+T8fXYqX5ZktlWfmFnxezj+h6mktdRCrtN9X G4U560fi2Is7kbBgGUbEW3gSi+VvybsUwMmPs5uX4ZQrA6/M6Nf4XOyWm9uDi4AmdiKg+ZqET8me 7sC6SXrw0rueMSGNJnzluA9+ampqAttztlRdnqB1p9Q30Ql9gIqTyNl+qbF4+Qefvf0M3EIQJPkL P5qAXCH57sOnIn/dGiyZnoLigrXIGLcF1SqVH5VFV3HoUk1jHmLz15ah5JxFSjUlZ1BSWoP45D5I 5tUzDpWFbyD3hfm4psk6kNqP6+fOo6Q6woqb3BNR/qvYtDAbGy/XCtPU4VTxFdRExNnhfRAfUYXd +XnIedcmQWnDmPF5QvIxmLF8jdR7EQa5r2D93CxsvGjV019ThqLSK2jwxiA+NgaxsU8hNipOLhKX lFF6DvVSN19NKYor3lf2QBVti2rXdSA2jun1FYeExLhmSL4G69KfFZIvQ3rOMoXljCFuHF49H2M2 F0uOXsSiAoc3n4DPUVBtyVFpRwUS4qPQenmhuPVBQlwETu1Zi2dnHJA8286fz6zYfmbEp7i0CpGx goluW1QU4hN7o7tHMKq4itcL2XnT+HH5rYMol3ep8LqufQ2OSYdWF/2UIXkLJPNrI0CeppCuV0tq dby+q6ME+RUspXdeNHofY70Tmp3XfXEjievGtVZh3ZG1FueWwjyJWP3qYGQtXYlDY08gM9aPQyvW Aq6RWD02XoTJAiw/XYe05XuxUEuZSYkYkNgTw2ZuxcbCLKxJk5GG/N97XCE1kHWx2rhodfXDlLFZ gX/68WP7YUxmniKGXkkk12Dj7Z+B8WMp6YoZOwaR6VnSmVRhbpLlNWBUNsYn6DKyMMArHdJb5+Ab G4dT0oY61zN4+1gOoq3oSNrWDwlLMrBpxVaMO7USHlW/GExekINedpzAzV8jTbLr5GhHINxhcQ3P xtwZdj0d/qHWG0dWorDBixVv7sMAu1JJSVuR1HMZpm95GaeyTmDAsyOxfmEBSmqzMSDSyuHygTNA zFT0Fbf0KWi5PItgg3CT+OP6e5Gx8Dxu+gWjNvL312g8JaF6ZoOxcHa2VZGQ36HDXSg8dwW+GYnw +CtQZHP+WekoZiYlA9XS0UuaOcmxISmN80FHgHzmFMrJ5Zr82QGI29riQEckYLRTuifR0+ihgHKE +c+VK1fwySeftFpL9no//elPW41zO4GRfWdhRhyw7Qd7USKqnG3yDztnWzbIMzeKDsrvYEzRJG8X 5I4frNKUlAVL8W3Vwym8+yrLlCooQUnQzaR0RkY9akV/4IloJCK97YWV0ocbpaKiSeoJj68M+6UN acsnBEjeiuPGiOlTxVqKSi10Sr511T74fI1XMzVp0YtvXEN9HXz+xvTMK6jqKrUPRe9KpYbMC5C8 zrRH+kTEi+N6TS08ScOQhAb8+GKlFewvxf5SIHWypfpoT3k+re6yC7hZRjVRDCIFurbyt5M03hrq UO3zB+EjTmXiUwbLwOcSborLX35JSH0gVi9/BnXHz4uCijx/Xn77ICm28ZmphObngUdAC7fkbhpy tlLZCL+Tx7tSeqcHiV1H4kQsOwD2BPcTybOBH374YZsSPdv0u9/9jtHvkHEjc/0r2J/5MnKXigIh Yw1GOP85Xd6AFN5YATcSkr1oOHIJvtnSS7RpvMKIB5ExlB2HwyTOw1Atcju8OR1RV7AIz5yjXO2T 1UjUEnuxZDgl51LVCR1emIXDjjS0zlmeIpJoqZLFm5KtRKBqRoj0QrkP1mCgDstfyHLk4kL+oaNI ai83ydwAClYi47QjC7GmrzsgI49mRimOjqoxRRT6SjaHznG0kojnRVLOFdWZL10kaVF5VQpJv5hs 6+xbLQ8yjyMwF+RhcEFj7rQl5S6zO73Y1vMPSkYQjuLZTBlROIxr+BqcnC1SfHwKXDiJ69V+uC9K nEQZdcjowYU8XPfNEr8r4jdPqf8cyY3VIKAQINmTz0nsFGa1wE5uD5wwxUiU6Lj1AYmQbpI977zu F5OZmYmioiJ88MEHLVbZ6/Wq5ZctRuiMAE8y8nN6Y9IWN/JlKK5NYLJTewTuPpSISseV1k8rOAIh AQslS6WzoQ9ptw+WrBMVjIpQjwtvr8Hh0jOiox+CXiHEKnPPQhIZWJolxC4c7xf6SEhMRjS5U7Ji bsmTFmF8T2FIMb6aS3g1X3TZojYYMVzc4mepZlRw4MdffkWI04u5nEBUQrN0Hm/uQF+Vrx9+UdNE 2mUEErVm8csoYsgyFMzubVXKjuuhDjvUBEYRIQH+KlyQbIamWB1mgqikcHynkOUE+Ki2SV7UiE+r 5flk0l7yTp6IfOJGU1+Fd364FcXskNMy1LNqNX8rlf1LlAfj7UOzJB3tlnHrtnniMEKGGBcvyXyJ vAvJ01lmBDLF7z0h+eiLUhXpEIwxCLSEADmbBE9hnbytuVzclgcTakle6+h556VX4rSUeTj5f/Wr X8XkyZOxfPnyZjsoAjF9+nR8/etfv+PVjo4XopF/UouIreKiEoTACg7ibLWseHFK3tTJCjn1somW sX0Uuh2m/OL74hpo+wgDueIwQCRWzelJkdk4POWgtXJGezrSe3v2w4C+NmE5/GklZ/ZN7IekgI4+ ETOPHMXrtUJInihRfwDHDlwSCXkIowfMDZl8BeLgdfBwpBCX5q5AxOYszdSRTXZFeKVTkQybCW/M xoP4/hylHMRN6Ui7NwbAVy6qJHGPtlVY7tiBSMNO7NqzF6K5weh1MmFum/aU541JRJKosCyTCO/k E5i0u1HF1lr+upzAXUZzkR63NK25xnkwYHgMDm9fKWobmXtItEYd/Z+Lw/78lZKFC0tsv0B+xmIQ EARI6prgtVRPN4meVxct3pMAKeLT0E7DMG1XHvfJzzPPPINvfetbgfboarMtiYmJGDlypPa6o3cl s4WQdXRqNlKl1E0vLMLZ8hol1/mqS/Hq6DyUi4Q+J40TbR6kygRow/E87LpsEUp1yQHkFdTBm9Yn SOJvlAslmahRvIqyxd6cCdE1N4kSEh6fKNI9JVpEYcpi6WCKX8O0bedQS6Wy6NBLjqzB7D0VSM6d GkS0TfJt1kPmAK6Xqeua3HmJap/9IhoqxL+yXPnpsGuCVagZNGmeeF3BpBk7cK2WXZUf1SUFGDP3 DRF95zk60kiMnt4b5cePSgcwEKMdKqD2lReEMqJ7SmcdNDRrOf/QOkvjUFJeHtTua9fLA08tPrWf lcQ1EAm2hNCjv+julUlBglM4sH3NzSCgSd0pxZPv9NVVL8fRHlpNo3oBm/wZdr+ZBQsWYNmyZbhx 40ag6j169MDcuXMD7rtiIZMEmSgsPbQB7jnzsWqmY/VFzGBs3jQ/QJg9Rsmyy3KJszQb++30ruSp 2Ds72XaJ8tghResiPJx4LKpEfnrHVmY0k5VI1BGinz6IGwsS0SM1D5t9bszeshZZDn11Wu4GWSPv LEvq1YZxS77UH21bOD8oJvXwadSZl+7E9ClBQdIDjETBsWnBTY4egoKNDciZuxWzxx8NJIgdMg9b FgSPPHqkZMC7/So8WcOCJ5RbLW+CKE6aGtGgi+dRnK2cFph7aTF/Jg+8A0x3BYtnchTkNF6Zx9gH 9j+eeFnaioPwD+8XGAm65fsIPvWSIQOD6+7MwtgNAoIA+VvPt1Kyp11J+0KEQV9DsWfgWnqtzCfh c/sASsj3k/noo4+wePFivP8+1R2W+e53v4uXXnoJTzzxhPa6p3dfbY0lyfkjEK2U5U2ro+IogbLl OE1T3UEfkeSra5WYD09klKhY7mBZ7c7aj9pq0XuJ8Xu8Mu8QFpVqd+1NRIPA7SLwb//2b4rX7KWU AYLXpN9VL6EksZPUSfJaqr/dwu9Feu5zc+3aNfziF78Al1o6zcWLF7Fnzx48/fTT+OY3v4mvfe1r zuC7bldE2Uap7YnTRhadGyy685Y6pc4tqCO5yYRvtL2KpiPJTFyDwJcEAQrovLp166ZInnyuNTHk 9a7sAcj6nIil0Qn0EEBFssPCGRMul/zJT36Cn/3sZ6iQrx6rqqqaVJcfU+3btw+csI2Pj5evQJMx aNCguzIx26QyxsMgYBAwCHQSAiR18jjv5Gxe5HDu4ktOV1/GMpD6HAbSMIB2+umEnVSfO5INSf2t t97CuXMyUVhb2+aIhNsfaMn/l7/8JSZNmoRvfOMbd6RuJlODgEHAIHCnEdDkTsGd/E2S50WNjRLk SeT00IYRtTqHfiR7XuFquNf8m2++iZMnT7b5RayzDQSGnQJHAQRm5syZopIwSxqcGBm7QcAgcH8g QA5zGnK4FtiV3p6BujfgnRFI/OwAGJF3XuFqfv/73+O9997rEMk728KPxHg4SbkseWP7jTEIGAQM AvczAuQxLdFrblcnTNFTsz8byEC6tX84Ez3rya95b9dwy2LmZYxBwCBgELjfENCETg7jRc7WfrSr yVjtSRFf6+VpJ9FTvxPOhmvji4qKwrmKpm4GAYOAQeCOI0C+pnGq3nWhXbgMR0dgD0CCp9G9QjhL 87oR5m4QMAgYBB50BMjZmsO1NK8xUevotSeXWLI3UMp7Wy+vhwI6gbkbBAwCBgGDQHghQIFcczUF dy2g048moLrRHiR9RiLZU21Dd7iaP/3pT2pf+ZbOh+1IvbniJiUlJWy+mu1I3U1cg4BBwCBADucH r1xgQqHdqYZXX0lpMtc9AiEjyTtVOuEI42OPPYahQ4eGY9VMnQwCBgGDwF1FgMROLid3UwjWgjqF dvXBlJPgtY7eKfpraf+u1toUZhAwCBgEDALtQkATPIVzErxTUKddbVPsJHLlKaobEr0mey3xt6tE E8kgYBAwCBgE7ioCJHgK6eRy3nnpj6bo11WrZ1greugegeROXQ/9DNHf1WdmCjMIGAQMAh1CgEI5 hXQa2jVna7v65FX3BrpHYAJGJMlre4dKNZENAgYBg4BB4K4hQO6mIW+T3EPX0isdve4JSPicrSXB 0+gdLZnQGIOAQcAgYBAITwTI0Zq3WUPayedaYO9Ci3aQ2LmtpY6gEzgzCM9mmloZBAwCBoEHFwGt otHcTU6noZvSfhenBE9Cp5tfy2rDBHpYoP3M3SBgEDAIGATCBwEtsGvtjHZrSb8LGZ8ORtC9Aidh uSaTFw39jTEIGAQMAgaB8EaAQjk5nRd5nISvBHhaaJxHT9GtJ2HvV7UNVVCbN29WWxBzz/onn3wS 3/nOd5CTk4PHH3+cTTTGIGAQMAh8KRDQEjz5WmtgnNqaroxA9tcRKL1z219N8Pp+P6HB06O+//3v w7k1Ag84P3z4MC5fvozXX39dHSd4P7XJ1NUgYBAwCLSEAHmaxE5DOwV13snvSkdPkqdF9wK860BG pptx7iezffv2IJJ31r2yslJJ+k4/YzcIGAQMAvczAprUydW8yOFUvWv+DpwZywCqb3RvQMleEzwJ /34x9fX1KC4ubrW6P//5z8F4PGyks0315b1YvseHF9fnoIenMfdrRzZg/cUIrFg/Dd3Fu+TYFry6 5STqVBQXkjPmY+mMFFhJ/Dj1o2WoTJmPKX2jApn4K09j8VvAipeGwHdxL9YfqZAwfyDcG9sHI7Iy kBTtDvhZFj8ubNuAw1X1Et2OL1F8tVF4cdN8uIs24PXKgVgzObkxnb8c65YcxehV89Gj9hLyVhRj yiZpU0jWl7ctw9nYiViYHt+YtomtufK9SM3Kxogktq8Su5bsxA1pS4NujtuL5JRhyExLRKDI2lJs XLIWxyps1GL6YO6CRRiaYKFWXbQD649XwcV8VB3YSD9SFyzDiNg6SXsQ6W20p1rhWhbSAsEtahhW LBhmP5+QYOM0CIQJAuRtzd2av3lXWyAwgGJ/t27d1F33DnpClp3A/WJqamoCk8gt1fnjjz8GDwi/ EyY6oQ9QcRI52y81Zl99DrO3n4E7ebAi+Qs/moBcIfnuw6cif90aLJmeguKCtcgYtwXVKpUflUVX cehSTWMeYvPXlqHknEVCNSVnUFJag/jkPkjm1TMOlYVvIPeF+bimyTKQ2o/r586jpNyP2LgYxMbK FRWD+IQ4eMiF5VdQfOAKfIH4tNTjbOk51EtevppSFFe8r+xBUSRFyfErOFspRNiqscuvjrDqmtwT Uf6r2LQwGxsv10oBdThVfAU1EXF2eB/ER1Rhd34ect61SVcwHDM+T0g+BjOWrxHcFmGQ+wrWz83C xosWTjXXrwgmFYiMjbPaGPsUouJjEB3BrkLKaLM9gML1OhpxIlaSX0KiYNVqG02gQeDeIkDe1txN ztZuxe/0oEV7UtSnXatwGE77/WJI4rona63ObOMdMZ5ErH51MLKWrsShsSeQGevHoRVr5diXkVg9 Nh7+8gIsP12HtOV7sbC/La0nJWJAYk8Mm7kVGwuzsCZNRhrCKh5XSA1lC1JtXLS6+mHK2KyAxDt+ bD+MycxD4XUfeiU1pSXvkKmYO7mp5F2r8mrMW5fh0dTmKFeHBe6sZ8DRusXbPwPjx/a0Io0dg8j0 LOnMqjA3yfIaMCob4xN0PbIwwCsd4lvn4Bsbh1OCYZ3rGbx9LAf6CPekbf2QsCQDm1ZsxbhTK+Fy S4fjGoyFs7ObVkQ6rHa1R1K6hmdj7gy7nk1zMj4GgbBDQHOe5nFyuhbQ6ac+mNJEz9prgtct0Up9 7Q73+5UrV9o8KJwqqp/+9Kd3rCmRfWdhRhyw7Qd7USKqnG2iYZmzLRuRUuKNooPyOxhTNMnbtXDH D1ZpSsqCpfi2KukU3n2VZUoVlBDVPPX66v9bNBk++Hz25UzcVkGdER5UXj1qRb/iUdK2lTmXgzUa H26UioomqSc8vjLsFwzTlk8IkLwVz40R06eKtRSVajhCVZwP1aKuCbRR7B0x7Fsb6uuCcRK8OpZL R0o0cQ0Ct48ASZ1kz4vETjcvch39mhwOrvXxqhewewXtd/vVufM5fPjhh21K9ATgd7/73R2sjBuZ 61/B/syXkbsU8GasER2xllSlWJc3IIU3VsKNhGQvGo5cgm+29BJtGq8w0kFkDGXH4TCJ8zBUi7wO b05HNBxfiYzjDs/ha3BmdqLD485ZWX5dwSI8c45ytQ91ddSie7FkOCXnUtUJHl6YhcMhVZizPAVw l6pRQ7NkGyVqGtHIXyj3IY2oNpzEs5knHbk8g4JTOe0edUDmBlAgOJ12ZCHW9HUHZOTRfAcaHNO4 DAJ3HwG94kZL8uRvGr2DZVcGaEOdvHZrctdDAh0n3O+ZmZkoKirCBx980GJVvV4vvve977UY3ikB nmTk5/TGpC1u5M9oJNPAZGOTQkTfLSodV1q/lkmJEq/S2TAxaa8PlqwTFYjKqx4X3l6Dw6VnREc/ BL0c/QqDZe4ZriHLcHB6b0s6lbzcHiulSh76I9kH6+xDI3TMzfKRmIGlWULswvF+mTJNSExGNLlT ymJrkictwvieQrRifDWX8Gr+URyTOYkRw626eJpRIfllfqFSOoy58ZJRseQi6p09+2X0pPKUNroD ChuVb5s/fhlFCE4Fs3tblbITeDyG5NvEzkS4ZwhQeKXRC2ropnZGr6VX2xST3HWE0JqyZ7ifyP6r X/0qJk+ejOXLlzdbb7Z1+vTp+PrXvx7a1E53R8eLZC66ACedRiUIgRQcxNlqWXHilLz9FSgSjull Ex0r46PQ6zDlF98X10Dbh8wdhwGi39ecnhSZjcNTDlorV7SnI71HxOqWCYtU22j85ZfslSuNfoGC HF6WtZnCmsQR+b1nPwzo27zum51K38R+SAro6BMx88hRvF4r9fJEgWr8YwcuiVQ9JCjnG6VXxB0H r/CwTyaQqYmPFFJuFy03U21C7orwyiS15NBMeFDhxmEQCBMENEeT3MnZFNTJdZrw1RYIWo+jewXW nQmYmHeG30/mmWeewbe+9S3VWGe92fDExESMHDnS6X3H7Io6Q6CLTs1GqpS46YVFOFteoyRZX3Up Xh2dh3KR0OekxUqoB6kyAdlwPA+7Lls6++qSA8grqIM3rU8QiQXRs6gxvLcgh/dIHSOiwFEs312s UrM+L8vSSri+jdgAY4rO/HqZuq7JnVe1LfL76sS/slz5qTBpV7MmSAffTIyQ8PhEke7J3YjClMXS wRW/hmnbzqGWeneZayg5sgaz91QgOXeqWs3UTI6teDXfHqWjrwhpD9vbUptaKcEEGQTuFgKaw0ny 5HFyN/mOEj3VN+pTKq3fYaV0RN0b0B26t/HdqvztlLNgwQIsW7YMN27cCGTTo0cPzJ07N+C+KxYy R5CJwtJDG+CeMx+rZjpWh8QMxmZZ097djttjlCy7LJc4S7Ox3/ZzJU/F3tnJtkuU3gESbizAI3L4 j4sqkZ/ODqN9xh2fgT25FZiU/zIyDthpXAORvz9HjUb8bilL8t22cH5Qhunr9iJWuLjh3E5MP+cI khVGBcemNVc9R6RgazNNEYk6Ag0y+rmxIBE9UvOw2efG7C1rkVXQmDYtdwMWqs6Rfs1j0hjbsrlb bM8BpFFHXyrtmRKS6hbaFJKDcRoE7hgCWkVD3tYkT1U8SZ9+D/36179Wyh0SOj1otLjPBPTnx0W9 e4vK4T4yH330ERYvXoz336e6wzLf/e538dJLL+GJJ57QXvf07qutseRvfwSilbK6aXVUHCW2txyn aapb9PHVipRuDUEio6PCU3Mhknx1rRLz4YmMUt8B3GJrTTKDwJcGgdLSUnzlK19RfE3O5qU1MuRz tdcNLZrotcqGpE89DyPzul8M97m5du0afvGLX4BLLZ3m4sWL2LNnD55++ml885vfxNe+9jVn8F23 K6Jqo9T2xGkji/YHy+RsC/1N+/O40zFFd95Sp3inizb5GwTCFQHN4eRxSvJawtfcrYheV56RtdHS vXaH+53LJX/yk5/gZz/7GSoqKlBVVdWkyvyYat++fWpDs/j4ePkKMxmDBg26KxOzTSpjPAwCBgGD QCchoKV4nR0FdgrqJPyARK8j6V5Bkzx7Ay3p6wzC8U5Sf+utt3DunEzU1da2OQLh9gda8v/lL3+J SZMm4Rvf+EY4Ns3UySBgEDAItIkAeZqGBE8e18vjyeWK6HUETersAUIjt1nKPYzAvebffPNNnDx5 ss0vYp3VZOPZKXAUQAxmzpwpKgHnekdnbGM3CBgEDALhjQA5jYYkryV6upWwzh966hlaHcBE+qJf uJrf//73eO+99zpE8s628LP7wsJClJeXq/Y6w4zdIGAQMAjcDwhQUNcfvGrCp5+2B5ZX0oM9Ae9a ymcHQNGfGYSrYV15UMrtGm5ZrNt9u3mZ9AYBg4BB4G4iQFJ3y5fj5DDanZoZ1kMRvdbjkOQZyWlI 9uFsuDaeWx4YYxAwCBgEHmQEtERPwiePk/Q1p3fRSnstyfOuJ2MZkeE6zoMMomm7QcAgYBAIVwTI 2eRpLbRTQNdCO+9qm2KSO41W0TAyA7U0r4k/XBtp6mUQMAgYBB5kBMjRWvVM7taCO/3VRXLXzE+g 6OkkefrpDGg3xiBgEDAIGATCDwFN8LyTxynha+5WqhvN/lTgazUN79quJf7wa5qpkUHAIGAQMAiQ 0DWpa7vzrnav1BI9ewGSOi+SvHbrcAOnQcAgYBAwCIQfAuRoamfI3bST5OnmrpZUwasTpnRPwOoz It28a7WOMzz8mmhqZBAwCBgEHmwENEeT1Cmg8655nMioE6YovfPDIfYEjMQIOqHuIR5sGE3rDQIG AYNAeCOguZu1pCRPXtd73XSh1E72J6Hz/sknn6hIOpHuHcK7iaZ2BgGDgEHgwUWA/E2u5kV7t27d FNFrtbvavZIOMj/vegKWPQIT0K39HlwYTcsNAgYBg0D4IkAhnZxNQ7KnAK81M3QLv1vbWDICAzTh k+RJ/PRjRGMMAgYBg4BBIDwRIG/zJEDyNo3W0pC7yeNq1Q0DtE6eEZwErxMyjjEGAYOAQcAgEL4I UPtCLieP02he7+pU12hPRtARQ+10h4v505/+hJ/+9Kf4zW9+c9tV4hbFKSkpYXPM4G03yGRgEDAI PDAIkMe1FoaNDj3nO3CUIANJ7iR7JuDF3kFL9wwPN7N//34cOnQINTU1t121yMhItT/9xIkTbzsv k4FBwCBgELibCJCvNXfbOvnAGnr6B21qpivGAPYIvNPouw4Pl/s//dM/4bHHHsPf/u3f3laVuAMm if7dd9+9rXxMYoOAQcAgcC8QILmTpymsc1KWqydp11K+WkevHc4VNnoowEqHK9H/4Q9/UHsw//3f /z0ef/xxFBcXdxjjnj174lvf+hbOnz8PHmJyu6b68l4s3+PDi+tz0MPTmNu1Ixuw/mIEVqyfhu7i XXJsC17dchJ1KooLyRnzsXRGCqwkfpz60TJUpszHlL5RgUz8laex+C1gxUtD4Lu4F+uPVEiYPxDu je2DEVkZSIp2B/wsix8Xtm3A4ap6ia7jM04dolLmYWHyf+PV/AK4kydg4dhER1of3vvRWhyreQov rpL26Gx9Zdi4YiswZB7mpsU3xvdXYuOSg0hfNR89ai8hb0UxpmxypGuM2dTWQp7VRTuw/jjbaRu3 F6kZ2RihcZEyX5e6lOtmSbSouBSMe24Yutv4V7eBlb/6HF7OP6EKsNYtiFXa6quNwpxN89FL7NUl J7B+9VaU8IG5vEifPA9TRiXbzyv4ebq8vTEldxYy+8aqPM2PQeBuIEAe14tpuOqG5E+BnffA7pUk c340VV9fDx6irYmekWgPV8NDwf/93/8dY8eOVQd9t3cpKNvVr18/TJs2Db/61a/wX//1X6r3u912 Rif0ASpOImf7pcashEhmbz8jRDpYkfyFH01ArpB89+FTkb9uDZZMT0FxwVpkjNuCapXKj8qiqzh0 KVgl5a8tQ8m5MhWjpuQMSkprEJ/cRw45l6tnHCoL30DuC/NxzUF6ViX8uH7uvPh7ER8Xg9hYXk8h NioOSfFR8NWUoaj0Kgr37MSNxloLu13CptNXUC5h9Y48qy/uw7HSChzLP2rXVyeqw6nScyqur6YU xRXvB6XTsZq7t5RnzfXzKKn0Wm2UdsbiKjYtzUb27lIrG38dzhZfhStO4xCDywVbMSlzKi7XWlHa wsov7S8urUJkbJyNjeATFYX4xN7ozs6t+jSeXbgVvv7yvDZuwJLneuPY9peRvblYFVBduEw9z77T l2HzxjV4PrEO25ZOw0ZdAasa5tcgcMcQoPTO69NPP1V8TU2HnpjlvSsJnqTH3sAZwBrRHc46etaR 9SbRU+0yZ84cfP3rX0dBQQF8Ph+DmzWPPvoohg8fjszMTOzatQtXrlxpNt4teXoSsfrVwchauhKH xp5AZqwfh1asFSlwJFaPjYe/vADLT9chbfleLOxvS+tJiRiQ2BPDZm7FxsIsrEmLAEVFjyukBnKg gDYuWl39MGVsFoVPZcaP7YcxmXkovO5DryRbnLXD/ALHiEmzMDNBx7YD5Oa7LuUpU4HCEh962Glv XDpj+zvT+HB4zxUh1jg0VJzB2fJZGB/fGO7RMq6jrnYmrdxaz9OVkoHxY3ta6aW96ceWYfqWPJwd fgKDIuntxfgZWUiySxgv0nzeiBws3n4OZ15KQVtYTWH1XYOxcHa2nUPw7drxN8RjMPJnZ1itS8hD lK8Csw9cgm92T5wlHhkbsHCUVcdeCTLaKc3A7ktVmNtXVTA4Q+MyCHQyAuRwcrleYklepB+Fd3YA XfhDB0V9nkzCixFI8jRMzCvcDdU2//zP/6wk+5ycHHXQN9vhNHRzdc33v/99TJkyRXUIPBy8s01k 31mYEQds+8FelIgqZ5toHuZsywb/5W8UHZTfwZiiSd4u3B0/WKUpKQuW4tuqm0PQhq+yTKmCEqKC SZ55kMt8cpC6XzpAdoL6svIXlY6QZXKiC4cP6E6vFsd2X0VssjTEoR5C9XkcFvXFK6tewWQvsPuI LVlbGd3ab1t5NjhbCfRInwgqjEpqHJ25wwp3PKZMl3pfLIPT25lLE6wa6lDt8wdwUfjYCSITektp Z7Dx3dO4Vl2r0Og1eSfOnMoR4vegu2i7Ggo24J2iUlTXskQ3xu8/gTOznWqwW4PGpDIItAcBcpsm d6pvFLnbPM6wwFGCJHOSPY1OoNU34ay6cYJw4sQJfOMb38A//uM/qvuOHTtw7do1pYriubLUx5Pg k5OTFckfOXLEmbwT7W5krn8F+zNfRu5SodCMNRgR2yj1UsfrcNnlupGQ7EXDEUqJJNe2jLBsw0Fk DGXH4TCJ8zA02uG2rREyeNi/IhuFQUEu5B86qkiTRD8iaySKlx4U9U0KelS/j2MNcVgyvA9WFWvJ Xsj1wD4gZir6yuR17KQ+2J0v8Rcko0dQvh1zdDzPWKRK8w8Xi8Sc0HxZ3RNFhdZwCTcVWbeOla+O T+Mons1sbCdzdQ1fg5NC1tH9Z2FJRh1W7XkNRXus8rxxMgJYPgt9ZT5kwOwtGF33MnavzsNuKxjx KROxYkEWmkyX2OHmZhC4EwhoDYwWcinh0y+weyV7ABotvTNQXzrsTlSsM/PkaISjk5KSEkXq8+fP x759+1BaWopevXph/Pjx6N69O37+858rXRb3g2D8O2I8ycjP6Y1JW9zIn9Eo2YUIp46ifSgRlY4r rZ9WfjjCbCvrqvQQdLPefbBk3Rg1UgDqceHtNThcekZ08UPUBKKdSt3qZaBAddHcxAiHfO6GR4R/ S+r1w5uQglS8gWOi+hldWgAkTkBSrHOEUYl3jos4j53InnEGvgprkvSYqHvmhqiKnGW3br+VPGtQ LNUYlBwjWVt1CC2j9rrMZbj6KB37zTaw6q7CB+PtQ7ME+8b3wU1wlPFg0Iy1cvlRW10jcxaXsH/z G1j8Qg22n1ork+7xmLl+H2aKfqy6pgolF09g15438GylBye2DWumUw+trXEbBG4PAQrn5GstpGs1 PLmbfmodvVM9QzsDaNgr0M2hQLgbNuy73/0u/uIv/gLbtm1TE60TJ07EzJkzUVZWhvj4eDz11FN4 5513cOrUKUX6//AP/wBK9Xok09ltjI4XyVz07E4tbRTVAAUHcbZaVo44JW9/BYqEvHr1FOnTNr7A EhDLo/zi+2IZaIeKusUVhwGi39ejg6TIbByechCqM9GedmzSl8crIwmPqOdsv+Cb5OeJwojhXuRu 3onqyiqkLu+DSH/jiMEnK0+KpUHjcufLKEByFB68sPk1HHv7khD9kODstKv5wnQobiVPHyeiJYf+ 0paAcVjZdR07chWI7We3tQ2smImMsiIVNkEZSYAPu9KzcIjSvXTYkdGx6uobVYPBC2WyWSadxzyf h0HrDmCmdHbRsT0RLfMJ0TVnkFtYqbqN0BwDdTYWg0AnIaA5nHcnyevs1ZexDNS9gdbNMwL9nXfl CNOf3r1742/+5m/w3nvv4fr166isrFRLLseMGYPU1FS1tvRf/uVf1KQtl1FSnz9s2DB8+9vfxr/+ 67/ekVYp2TCErKNTs5G6+jw2vbAIntfnY4CsevFXl2LjlDyUi4S+J81akpc6Ng77t+dhV7+9aoll dckB5BXUwSuqFC1nstIsI0AksorGG6SVbmyWWxJdLyvFTVme6PM3VsrtjYHub9hBJI0aAxzfKYQe h819Rb69rvOQJZpvHxUpX5YVpqVoT5kAvYKiFW+gxDcESYGK6GAfbohkHSH+CgvxjiQRBhrQdp7S T6JBpOSb1VS/+FFXfh6vrpbOJ3EWRnASWGXMcirhlR7VL6twLu9Zi/1VMi+yK1iabhWrhgqUlJfD K9jourKX7p4Qj9Tn5FnsWYZD/XciM0mel68Gp45TzdMPUYL5aBlY7F6yFQN2zZKlrR745HmeKpRg WbnTBBLxNsYgcCcQIHdTKCdvO7Uw5Pau9GCAVubTzouJ9HDgTlSqM/PkSpunn34anFjlChy26Y9/ /CP4QRVX2IwaNQqnT5/GW2+9pdbKs11cUsk2cw19VVUVPvjgg86sUmNeZKogE4WlhzbAPWc+Vs10 rPKIGYzNsma7ux23xyhZdlkucWQp4X7bz5U8FXtnJ9uuCCVRB2UtDg8a8OOiSuSnWx2GDo+Q6CWy JHCS9rDvnD/Yx1U+kIsMJ1JwmmsnCpNGopc4/W4dVob9Mu+avq6fndK6RSYOkyWP5/GeLPVM0lWT ILdK14BtC+cHxU8XyTeg5vG3nedo6ZhQLMslX2jMJn7ILGxZ0EjikdLmbQunYZuOIiOdOes2OOZF pA2BzkVHasRqhVo1dAWLZ+qJaB3HK3MY/z973x4f5VXm/91+yHhh1E5Wm6wmWAlqgpK4kuwK/GzA JcFCkAASQKhtgAXCEgiXhiBQpEC5NZSbXPrhZi2WgkBYAjWBlaQKdJfw0QldiEpYJbhOXE20TqpO /vD3fM/MM3knhGu5TOx5Pp933vOe85xznvOd5Hue9zln3ncP0kY/i4L6Qukjv60PJGDi6nyZJN0Y u34l6mWinvPk61pR1jH4feZaom9DxKbuIQLqqDMUrdytXM5u/04I7686E2jIhpWYR0XmNTU14XOf +9w9NPPOmuaiKveLMmRDmxmScYZhaP+jjz6Kfv364ezZs4bcdYzskWPkXnqGdE6cOIG33nrrjn50 dWfWS1CgqTHofwe6ym6gDphIGkYVVsMAAEAASURBVDY6xsW8vs6d9m/r3R4CAX8TmhhPk0ksPvba 70u/K5c7GAa6vdattkXgzhHgOuTDDz9snFzjwYtnT64jx1HE0w/G3zVoH8o0hfwgWapOODNKEvTI +fgD2tie5GkiB0pPnWEcnfGcpnPMb7zxBgYOHGgWb7lIez/FHRvXkaMZYcKt6ERUsBf3DAGXO9YR drq2G/tdXYuJzbk/CJADyXEUkju5j4fmmUcgsFAzeHaSPrfnRKt4ZHHxypUr+PGPf3xdEzlYp5ff XpFl3//+98G2PvShD7UvttcWAYuARSDqESDR8yDfkb/bO+fmEQgchXOHjaZZ0Un60TbagoKCu7Y9 kg8CmjChfQQ72kZs7bEIWAQsAtciQIKnkLNJ8srhmm/iNvTiqUBhAV1/HiQ/lukrqoxCFH3wMQZ8 Ns+NPPpbNZe7doYOHXqr6lbPImARsAhEDQLkbfXoydnK6eRuQ/oSwxadoLtPqzkbUIlEzzOFT4mM xsVYY5z9sAhYBCwC73IE+CNRhp7J2Qy38+FmJHhyO+UhfiihaxCfeZwddIbgtRWLgEXAImARiE4E 2vM1Q+4qdN5N6IYETyHh8+BMQEVWZlrLtaI9WwQsAhYBi0D0IECe5kHhBhNytkZnDI/rTEAlpqnA s84Imh89Q7KWWAQsAhYBi4ATAY3Rk9zJ33pW/ja/jKUSCV69eQ3l6I4bjfM4G7Zpi4BFwCJgEYge BJS3yeX06snfXIw13j3NJOuTzHlW4azAilRW717L7NkiYBGwCFgEogcBJXlaxLTyN5/oy2vzgykm lOyZVtLnTEBhJSsWAYuARcAiEJ0IkLOdPwwld/Mgrxt+54ce9Nw1vqMkz2E5G4jOYVqrLAIWAYvA uxcBjbrwrE470SC3U8zz6JlQL55Er8rMZyUG9q1YBCwCFgGLQHQiQI6mc07+5pl8ruRPiw3Rk8wp SvbqzbMS83RWMEr2wyJgEbAIWASiCgHlbhrFRxWT08nfKl2UzDWDFVSBMwKveVixCFgELAIWgehG QLmbnE3+Vu/eLMYyU+M69N7Vo+eQWNF5Hd3DtNZZBCwCFoF3JwLcSul03PXJw8yP+GUs4dEwjs4M PGveuxM+O2qLgEXAIhDdCJCj6aQrbzutZVn4VYLOOLw+8YwK9OY7quxsyKYtAhYBi4BF4MEhQJ4m X5OreZDPuVuSaUZsjEfPhGZQ2Unwmv/ghmB7tghYBCwCFoEbIUBi56Fk/573vCe868aE5vlB5nd6 9CR3Htyyw3LnNp0bdfYgy2gjV5t1zz/tvnDhAp544gnw3bIjRoww743Vcap+Zxjbg8TV9m0RsAhE PwLkPZI8RTldrTZczg8KSV1DNgziM22C+JKvQX2tGG1nPnuZL/8+c+YMPvnJT5p3wHI8e/bswcWL F425fOXgvn378KlPfQqc7Y4fP27KUlNT0b9/f7z3ve+NtmFZeywCFgGLwC0hQI5WLifh04HlmQeJ X/iwi/GC//SnP4HPRaCQOFmoh3rBt9TjA1D6+c9/jm9961vgmSTOB/BnZGQY4neaU1NTA46zrq4O K1euNOM8ffo0PvKRj6B3795OVZu2CFgELAKdBgFyNYmeZwo9fDqv5G7mRcToOQswk4F9raCzRDSP uLm5Gb/4xS+MiZyk3nzzTUP0b731VoTZf/zjH824+DYW6lF+/etf43//93/x+c9/PjwjRlS6zQvf 2V1YvNOPp9cUooe7rfKFQ2ux5nRXLFkzBd0k21u+Ecs2voZmoxKD9NzZWFiQiWCVACqeX4SGzNmY lBEXbiTQcBzzvwMs+UYW/Kd3Yc2hy1IWCJd7EntjaF4u0uKDE3a4IJTweY9hzYJN8LYyQ/rMm43i iZmIDSs24ciGVVh/9HwoJwEj5s/GtP7J5tp3dh/W7DyPEYsXoV+4jwBObViKpiHzMDSpBa88txZe Ty6eLeiDsBW+apTsDGCh2O2S9DOlx0x7xgymRNHfFIeZ62ejJyv5arFuySqUXw6ik5g+Cgvm5wue fsFlKQ42QnByIcbTFfIuSbRKyM7vD9Z3V63F3sAwFOckmT7QJG0taGsrJqE3iubOw6CUINJnd6zE 9stxWLI8H/HBGvLZiM1P70H28tnoQXvYxgppo5b2xCAtKx8zp+aim+P7DVe1CYvAA0KAXK2haHK4 RmjI5SaoQwU9dPWWZ94OaNznAdl+S91ycByUijOtec4zY/kqrEvSV4A0/07P8SlyZ3D5NRRuPdPW hJDbjK0n4EofaEj+1PPjMEdIvtuQyShdvRILpmaipmwVcsdshM/UCqCh6jwOnBFGc0igqQ7e6jqT 0+g9AW9tI5LSe8sahBzJ3dFQuRtznpyNC23DC9f2Va3E+OJNuNL3KZSuW4sVcwbDu28V8grKQlNF I1bnjBeSr0NO4SJjV0GWCwdXzMaoDTXBPmukz8vnsLhoF/zhlgPwHj2Hemb4G1FZfV7GshTbvW0a /sZa1ITsDjTWoab2KmITuyMxMSF4xMUhKbUXuhmSP47HnyxBeXMvLFi9FqXLZiHWux9TR87DpYAL sUndkdI9GSmJkDZfR42vK1Jk7ClSP1bqN9dVo/JyS9A6wX3UWGnrcgIKFq+UMc3DANc5rCnKw7rT xNYP7/HXUV+zH4VbasMj4jiO1FajxeDYiBK24f8CltCexePQdPxFTJDvqqmthk1ZBB4oAiRzddIZ pWF0xhnOMb+MZYEqkvBI8hS6/ZwAWBbNQns1BEU7b7amwPCOCuvxFkfHrPl3fHanYsWygchbuBQH Rh/DyMQADoh3iphhWDE6CYH6Miw+3ozsxbtQ3Dfkraelol9qMgZP24R1lXlYmS2eqniL7ph2VoRC a8yNISnG9MGk0Xlhz3ns6D4YNbIElRf96JnmdDfrsWbF6/AMWYn9M1KDjaYkY3+iC7lFL+KULxeJ Z5aistWDJd/eI956UCUtbRPSkhdh6sZnUJF3DInaf/NhLCsfjJU5wrYUtVNsolmUg8WrkFOx1Exs 8lcXzOSnsXsgimfkt+WFUwEcWfICWj3DsG/vlNCdRjJKD8Zh1NASbD/djJXDpyDD6NfhlEww/b4h dz1Jbe03xrgRY+b8IO7NMY/j5fLCsLeetqUPUhbkYv2STRhTMQ9dBWreVjWXleDI8GMYyrFLc+7Q vZX/4jFwmluxvhAZpptkbNvcIt9VGRr8hYh1wmzssh8WgfuPgDrqetaQDc8mVu8kcZK8krsG8bXC /Tf91nv0eDzo1o0BkaCkpaWZwX3605/WLHPu0aOHmQT+8R//MZwfJ97kI488clfCNtpobMZ0FHQH tnxzF7wSytkiEZaZW/INcV2q2i9qAzFJST5UyZU00NTx1kV68drm9c5O593fUGdCQSlxkezjv/g6 vMLGReNDJB9qzJ2Sj2MH9gmx+1H1qhiZNStM8tpfj5ynwCDIxUb6r8KICaOwYmov1GwsgcNpV3Vz dzBGQjvpOIc56iU7jaRmazN8foZb/G0HdQJ1OChmZM8Z5QgnSb4rFfuP7MNCJ2YM17CKtNOh+Ouw l22JB94WkqGmC0OnTpZzrRC1ifwgMW8RCtKB9UXbHHcqwVbdcfJFimx+fh+89Y1gd66kfJyoOIyI uTSobj8tAg8EAfI0+ZsHIxqMUjBOrw78Q+qxk9jpCas3rATPcnq90SyPPvoo+svOGdrer18/fOYz nzG3Ljk5ORFmDxs2DB/84AeRkpJi9Dkubr1MTg7GoCOU39GFCyPXPAvP1f2Ys/AwPLkrMVS857DE eMKebzhPclLSPWitPHMN2bTpOFMeIcz9yB00GANDR27RbiB1FgZFMluokvioDhO0JZeb0e6geLpq Skt5jkOGdFVRfTWYKfNQ2vBFyBHSn7PkuOS5wvWpYAI2cb2xUO5q6CVXSCxKunAI+ziB8SNzkTsy L3yM2hoMnbC+23kHoDVdHduvxdecpRt22+E0IOSdiFacqg+GePx4BCPnP4sY3qlUygCd/cdmYuuc YfBXS1hsWj5yhwreY6bjlbO3NyFfY5/NsAjcRQTI0xR11plWJ57cbp5eqXswGb7QClTUaypGq/zh D3/Ad7/7XRw5csTMZKdOncLUqVMxc+ZMZGVl4fz586isrDTEnpmZiZ/+9KdYtmwZ6uvrzZCqq6vN Lp2vfe1r+PCHP3z3hulOR2lhL0zY6EJpQZsn3doh87BbxoubEZPdJxQ06MAUri2YmA3L2FBviWOr 99uCUy+vxMHaExKjzwouamoTjjUJzQqepc/TdYiTsNF1Z5fAVZwSR35Qpni2NcFaAbFw2ubJKJ/2 ArZfTIZHIlCG4EON08t2m7uaE7L4uw9pc0nuOnCeB+LlA9OlFc0TbuVs4HfEyUNt6cnnrUFjXLIs NEfMGlp87Vmavt6kEag/hwZ4UJTUFWdZMyCEL9/XxqndMbV0KbypkyO+gx7ZU7BfDn9TI67U16J8 527sWJgP1/YyCc11NDlea47NsQjcSwTI0eRrOrske147nfSH6LmzUL12XrMCZwNOAHoLcC+NvNO2 q6qq8PWvfx07duzA7373O8THx2PMmDGYP3++ibu/9NJLhtjZPrdevvzyy0bvG9/4BsaPH4+PfvSj 4E4c6uXn56OiouJOTemwXnySkGNMQkQYIi6ll/HETwZXXdvqBS6jSgi1Z7K4zyHxt60vm5z6029o kZyFnGK6o5/E99PM0QfTTNz7quxCcahJ0p3UR2itGa/URHqhgfpj4pU/IyEYN5L6Mk69H1ciq8Iv xNYgeUntwkGupFysyIrB3iKJnYuzfy3dyV3N8kWIubobhc+XAR6HhtzRxMrthVvIXQ9T6u6OATL8 g/vOtbOiDvOLn8FLtUEPvF1hx5fuOKRJSfk+x6J4SPNSLdvvDk+7OaPH8GeRE3MZc4pWyZgZvJfd UVvGYWBOMKTjjo1Dz4wsFG+ZZ8oam9oBbXLth0XgwSBAcidvk8MpJHzlcSkLFmoGC//85z+HFVhB KzIdTfLMM8/gV7/6lTEpMTER//Zv/4aPf/zjWLt2rfHq6en/8pe/NOXU4w+m5s6di+eeew6MzRcV FYFxe8583GZJT/9uiqGBdmQd3z8f/aWT9U/Ow0mJ+VLHL9sJl40oQb146DOzucDpRv/R3dF6VEg0 FCLwefehpKwZnuzeEd5mBNVISMIT4VtLUxRZIC4SUq5ZkS8LmvWmz6b6ahRO2y0x96dMXH7AhFmi eA4TCrbhQhN94QB83jKMKhKd9FnBRUrJdUrG3LVCps0SBLmOxPbBNrmrab7aTqP1ssS763HpYh0u hI96sdyNETMGyp3DKszZcQZNcicS8Ndjc8FsId4EfN0Zo79Ol23ZcZg0/zFp6wVM2VKNJgbXA3IH c2glZuy8jPQ5k4MLxW0VJBWLaVsmy4wnM25IUrKHycQsIZ1DtUFk2UZ5cHuop6NYmFa0Z4vAfUSA HM3YPA866jzI5RTj2fODGer2U1GJXX9AxckgGuXtt982ZtErHDBggAnHHDhwwHjpN7KXYZstW7bg K1/5CgYPHozGxkb8/ve/Nz+mulG9OyrTHSnhynFYeGAtXDNnY7nEfMOSMBAbZB95t1BGj+Gy7bJe dCREsDeUF5M+GbtmpIeuxONs55GywC20+1JVA0p1R0xIu9/cXZiJEtltUtjWXuoovLw8L9hMfBbK 1rWisGgTZow9HKoFJMoC7ca5Weba5W672wgqJEnoaBjyilVftj+GawYT3XLmYcSh8TgYdsbpu5/D /GntvXYPSg/sQVrf2dhQCMzYuBR5+0KNxfTGim8vumbxk8N3htOp7YQ7vn8JNvhd0pZsI5WbCpXs OWtRbCZUP7gV3ymuxFyU5sqdTkjflZSH0qni5W8tQe7WNs3swrUY69jt01ZiUxaBB4MAnXXyuQp3 F5LLmfd38miAv5LoeUFCZ6iGaRI/hWn+8KhXr15aP2rOXEilcHcNSZtxev7q9VblYx/7GLhAy0cn /PjHPzbV+OvZ+yWM+dJ3RqCrhJ06YG0pMjrGbb++zm3ZKztdfP4WiYkHwyfX1g2gyRf0aAOiE//A vFa/2NGCgEvG/U73MIoX7msKzjQMv9zRkMJtxCA2PraDUNW1SNoci8D9QoD8xY0m6pSTv0nySv5d lPFpkBI+01TgoRWZF20yZ84cYxIfYdBVNkTrncit2sntfRzfuHHj8KUvfelWq901PUM6N2ntVnRu 0kRksdz9xHPh87oiXnl8269xr6t2zwvcYseN7LwNA2THzvUm0ltu5W60ccudWUWLwO0hQB6jU07h mYeSvOF4iWEbj54KzNCZgBW1Mj16blmMZqGNXHDl4uqtChehH330UdCzt2IRsAhYBDorAtxdyBA2 nXVurCHJK58z3UUHZlhfZgEleObrrEDFaBfettgHk0X7t2TtswhYBO4VAuRrDbmzD3XUmTZEzwwK lbSQWytJ/pwhmLZiEbAIWAQsAtGJALlaQzW0UAlfnXTzrBslcs4IzrQSv1aKziFaqywCFgGLwLsb AXXQeVbnXHmbeeF3xhImKphMifHoEx51Rnh3w2hHbxGwCFgEohcB5W1yuIbhuVWe/E3CN6EbevJU pAIJXsmdlVhmxSJgEbAIWASiFwFyNYldiZ7kzoNczsMQPcM1Su5cseW1kn/0Ds1aZhGwCFgELAJE QB1yJXjmXUP0zKRHT9EZgEpWLAIWAYuARaBzIKDOua6z0mqdAIxHT1In0TNTwzXMY1qJv3MM1Vpp EbAIWATefQhoREbj805HnWXGjdeZgPAwzUO362gD7z7o7IgtAhYBi0DnQICcraJ8Tu4mj1OMR88M 50FFuv/66GJnI9qYPVsELAIWAYtA9CBAnuahkRjlbZ6vIXqT6fgJrVaKnuFYSywCFgGLgEWgIwTo sDMM74zTmzx+MJ5DgtcF2ZaW8DNlTVvUsWIRsAhYBCwC0YkAOZqH7phUB52cbtZgleB1Dyav+Rx6 xnZ4MN+KRcAiYBGwCEQvAobMhdRJ7CR5CkPv5HDmPcRMXugTzzgj6MzAynzCo/Xoo/cLtpZZBCwC FgEld3I2D3K6Pt0gxO9dwjtt6M2zkIp6K8A8S/T2D8kiYBGwCEQvAuRokj35Wr14p7VmMZYZSuZU ZLiG4Rum6fbr7htnRZu2CFgELAIWgehAQB1yntWrV8sMh+uFnqlEZYp69VoWbefS0tK7bpK+tequ N2wbtAhYBCwC9wgBJXhn8+q882w8enX1tYBkT+E1y3hEo7zyyit33SxL9HcdUtugRcAicI8RUI4m 4WsIh2flcvM8+puRuU4A99hW27xFwCJgEbAI3AEC5Gg9SPZO4ue1eTm4tstYDpW5IMvdNlRgHs9W bg0B39ldWLzTj6fXFKKH493WFw6txZrTXbFkzRR0k6a85RuxbONraDbNxiA9dzYWFmQiWCWAiucX oSFzNiZltL2oO9BwHPO/Ayz5Rhb8p3dhzaHLUjsQNsyT2BtD83KRFu8K5zkTPu8xrFmwCV6zY1b6 zJuN4omZiA0rNeHIhlVYf/R8KCcBI+bPxrT+yebad3Yf1uw8jxGLF6FfuI8ATm1YiqYh85BWvwvL D12Vd1cCMS6PjKUFzfK3JO9gR87cRRiaFBydv/4YFj9fjWzJGxTKUxOua2OgHutmvoAGd1fIAhI8 8jJ4f0szWgPym4+4wVgyd3AIO7ZE/JYiMHye9NmCV55bC68nF88W9EEYGV81SnYGsFCwdEl6dekJ +F0BaY/1qdWMuMxZKM5JYsZNvi+jYj8sAg8MAXI0uZvrq0w711jp2YefdcPCv/zlL+GZgJW4CEvX n2krt4ZAfEpv4PJrKNx6pq2CEMmMrSfgSh9oSP7U8+MwR0i+25DJKF29EgumZqKmbBVyx2yEz9QK oKHqPA6caWxrQ1KBpjp4q+tMXqP3BLy1jUhK7410Hsnd0VC5G3OenI0Lbdwfru+rWonxxZtwpe9T KF23FivmDIZ33yrkFZSFpopGrM4ZLyRfh5zCRcaugiwXDq6YjVEbaoJ91kifl89hcdEuCHeHJADv 0XOolwyXJxEpKd2RkpyAxprXUVXTjKTkZMlLRjdPkORZ6dROmWwun8e6QzqhBJu6oY0uNxJTP23a S+zaiKrq19Hokb66f9r019Y62wqg/vg5XKSR/kZUVp8XfJdiu7fNan9jLWpCWAYa61BVew6tngQk JSYgMfERJMZ1lyPY6s2/r6D99tMi8KAQUJLn+T3veY/hcTrsJHkeJnSjsZz3ve99+NOf/mS8eFUi 0dOrt3KLCLhTsWLZQOQtXIoDo49hZGIAB5asEhd3GFaMTkKgvgyLjzcje/EuFPcNeetpqeiXmozB 0zZhXWUeVmaL1yoc445p16d4sioxTMb0waTReWEvdezoPhg1sgSVwnA905zUV481K16HZ8hK7J+R GmxCyHd/ogu5RS/ilC8XiWeWorLVgyXf3iPeelAlLW0T0pIXYerGZ1CRdwyJ2n/zYSwrH4yVOYlB xZCd8Rm5KMoIZnU9/hoOZk3HtInBu4Fgrnz6a7G9BkhKTRAy3oMLM/qgpxnWzW0cWVAYbKYeKK8+ g6fnTkHPcMPtEmKTaVY+zFmKDxavQk7FUjPZ8q4gLCadgIlzC69p79a+r7a7rnCbNmERuI8IkKfV MadXz4gMhcTPtGFwKtCjJ+FTSOycFTSQb4newHLLH7EZ01HQHdjyzV3wSihni0RYZm7JNyGSS1X7 pZ2BmKQkH2rVlTTQ1PHWRXrxN+vU6bz7G+pMKCgl5IlqXf/F1+FFDIrGh0g+VOBOycexA/uE2P2o elWMzJoVJnmt2yPnKTB4cbGxST4l0JQwCium9kLNxhI4HGRVD539ErQREY+ivfhO75FWHseSxdOR iMso97Jd4f+b2tjWkt8024LWNge9rbCDFNXHSLgpHecwZ0ttUOMa0yTM5PNLmKntoOLd/r6CndtP i8DdR4Ckztg8+ZxncjrP5PWHeEHhhbI/C1Xx7pvzbmjRhZFrnoXn6n7MWXgYntyVGCrec1hiPGEv M5wnOSnpHrRWnnGERdpKr015gNb9yB00GANDR27RbiB1FgaFPPLIOm64HSZomUsC6prt6aopLeU5 DhnSVUX11WCmzENpwxchR+h6zpLjkucK1w8q3OjTj4MbziNxai7i5c5njMw7lTvfcKwy3NzGG7V+ vTIzH8T1xkK502ouK0GFxMe4jhApzVj8ZB5yR+oxrm0iuyvfV2Rv9soicLcR0HVVbZcOOjmd3G4W Y0n2elCJCvooBOZT2cptIuBOR2lhL0zY6EJpQZsnHVzs66gtP7wS0onJ7uNYVGynRw/ZxGyYT5e0 NxasHhVaTG3BqZdX4mDtCYnRZ4XCIaH6HXjWwRLp83Qd4iRsdN3ZJXAVp8SRH5QptygScqEExMJp myejfNoL2H4xGR6JXNySc+07g4NcCN5agimVHtRzLRllQqiDkXJTG9NlcqD+nUlAbgPc5k7rhCxI 70PaXE5qTrfegwXf3oYM9iG2BCScEytpr1Mloutb+L4i9O2FReDeIUDHnDxN7ubB0DtFHXkTulEl FlCZhVTWUA7zrdw+AvFJQo4xCY5dLeIfp/QynvjJ4KprW6OBy6gSQu2ZLO5zSPztnidXf/oNLZKz BEdiuqOfxPfTzNEH02bkS/7V0M6RNlV3Uh94xAN/pSYyLBSQ3S9zljwjROtGUl8JzJTtx5W2aibl r69Fg6SS2oWDXEm5WJEVg71FJdguzn5H9wLtmoL30G7J6o2Z8ydjxPBRWDDnKbHrKvZWNeDmNrZv 7U6u5U5r+SLEXN2NwufLAE+k1bHi5rt5xMYKyQdnldv5vu7EIlvHInA3EFBC51kjMsrfhs+1E16o 5840lXjmYeXOEDBzajuyju+fj/7S3Pon5+FkfaPxKf2+WiwbUYJ6kmA2Fzjd6D+6O1qPComeDZKz z7sPJWXN8GT3jvD4IxxO2Sni6ci3ljBJkZByzYp8bD9db/psqq9G4bTdEnN/ysTlB0yYJf2ew4SC bbjQRP88AJ+3DKMYDkqfhaEdhIMy5q5Fmkwg7YYodYMS6eU34CWxP61wOob2z8Sg7EwMyM5DUaZ4 zVuPwX8LNmq77+gc2wfb5E6r+er1rI5s/da+r8g69soicL8RIHcrf5PoKcrfPJvQje6s0XANlZin JK8NMD+aZerUqXjssceMiW+//TYmTZp0jbnr16/HRz7yEZNfU1ODtWvXXqNzVzPa75yRmPfCA2vh mjkby6fRAw9JwkBsWD87uCNEsnoMl22X9aKzMB97Qyox6ZOxa0Z66Cq4Myd0ET65hXZfEg+5VHfE hEr6zd2FmSjB+iWFbe2ljsLLy/OCE0d8FsrWtaKwaBNmjD0cbi9RFmg3zs0y1y53291GUCFJQkfD kFfcpq8VxTrEx7Z5zP6LsjVTpqEV/SN3qKQNGQVUl+GsbwoG3MxGbdycPW1RrIj84EVbYEZCMO3K u+XMw4hD43FQborahBZ3JLf2fXVU0+ZZBO4XAhqyIcnrXnouyip3/92lS5f+ygwqMlM9eVZQon/r rbckPJB2v2y+5X7S05X0glUefvhhrFu3Dp/97GeRk5MDn699fAR45JFHcOzYMfzP//wPJk+ejOZm iZc4hOR/v8Tf1Bj0vwNdEX+dALTRMW779XVuy17ZVeLzt4CkHdvR6qx48k2+ICYB0YnvUOe2erx9 5ZvaePtN3o0at/J93Y1+bBsWgdtFoLa2Fh6Px4RtSPTkc+6c1PCN2UcfZn1x8ZXwSfT06nnW8tvt /H7r//73vzc/+mK/HZE883/zm9/wZGa99iRvCu7jhzs2LiIM01HXt6LTUb3r5knsOT4Uf+5YRzzg +Eivu2O9e5h7UxvvYd83aPqufxc36MsWWQRuFwFytfI2nXS9Jqd3UTLXV1BpoZI7vX0eViwCFgGL gEUgOhEgsZPQNQzPa3I6+Zxc3oUfzOTBNJUpWoF5VI5G6d1bHjfQTj7wgQ+YnI7KnKrvf//7cTMd p75NWwQsAhaBaEWAHM2QDZ1ynnnNNHnchON//vOf/1UzWcC0Er6S/B//+MeojNFHK+jWLouARcAi cD8RePPNN/GhD33I7J+ns05yJ5+HHXgm1HvX1Vrm6aIs01YsAhYBi4BFIHoRoFNOztaIjPMRNsZx V9anJ69KemaMhwcbsGIRsAhYBCwC0YkA+Vs5nGdytl7TYvOsGyV7eu8keSpQ9FqJ32TaD4uARcAi YBGIKgTI0YzM0DGn0It3Rma68JkISuRUVCXOCHT/jdsfWqA1hfbDImARsAhYBKIKAfK0Rl+Uz5X0 jcNOa6lEL15Xa1mgT0JjmuVWLAIWAYuARSA6EdAwDUmenE2h407uZsSmixK6vmiEr6CiKPnzbIne QGI/LAIWAYtAVCKgPK0hHKeDTs/+Ic4EOhu8973vNUF8DeGwklaMytFZoywCFgGLgEXAeO3K1yR5 Hgy/04E3++uJETOpxHfG8nWCGuvRfJZZsQhYBCwCFoHoRYA8rbttSO708hmxYX74EQganiHJk+BV NHav1/ZsEbAIWAQsAtGHALlauZsETyHJk9vNIxCYoBJDNqpIBZI+85i2YhGwCFgELALRi4Byt1ro 5O0uesEzDyqT9HlYsQhYBCwCFoHoR0BDNsrjvKYo+RuPXodBcqd37zycyqpnzxYBi4BFwCIQPQiQ 0DUyQ6vaXz+kzM+ZgIo6MzCtykxbsQhYBCwCFoHoRID87Qyzt+duE3wnkfOgou6r1zAOK/CwYhGw CFgELALRjwC5m0KnXdPh0I2SvRI7r/mLKs2P/uFZCy0CFgGLwLsTAfI0RTmbaeYpnxuiV9YPZwrB czbgrhutYBKd5IOvCPzFL36B3/72t+FXC9J0PrsnNjYWn/jEJ8y5kwzHmmkRsAhYBG6IANdXNexO Hmdaz8ZpZ7hGhQW6j94Z79HyaD/znbGnT5/Gj3/8Y5w/fx7/+7//i7fffjtsNn8M9tGPftS8PDwj IwP/9E//ZAk/jI5NWAQsAp0VATrrenAMGonhBMBwfNijJ8k7t1RqfEdniWgHgB78q6++iqqqKuPJ 662M0+4//elPqK+vx+XLl3HmzBn07dsXX/3qV5GcnOxUs2mLgEXAItCpEFC+U4Lnmc46+ZtpQ/RK 6szgrMAzRd84paGdaB351atX8e1vfxs/+MEP0NLSYsykzR//+MfNwQe1cSxXrlzBL3/5S3PX8pvf /Abf//738dZbb6GgoMCEc+7O+BrxynNr4fXk4tmCPgg+Ik5a9lWjZGcAC7+RBZeknyk9Zrpr1U5F 0d8Uh2lP98JLaw4D7q6IEbvlBH+zPK/C34K4QaOAimNImbsIQ5Pcpqbv9C4s/o4fT68vRA/TWQAn NyxCRYz234QjG1Zh/dHzoZ4SMGL+bEzrH5zcAr4zWC22+CF9hDRiPAkYNCQPA9LiJKcR259ei7ip bX0iUI/NS16EF72xZHke4kP1IG1UPL8IDZmzMSmDdYMSaDiO+d8BloTGvrr0RER/cd0z8fWJgxEv 9vuqtmHN0ctaFXB50D83H0Md7QUL/dLXUlRiIJbMzYJBQ+xaN/MFNBA0wc7TtSv8Lc1oDcjfRNxg 0RNsF2xCPRsIaBcEPoD+IUx93mNYs2ITvM1SHuNBzsRZmDQ8Pdi+VrFni0CUIUBHnbxNZ50Ez2s9 DNHTrWehhmyc9lORhMlztArj8ST548eP489//rMxMykpCePHj8fnPvc58EFtaj89eoZ0Xn75Zfzs Zz8z+j/60Y+MzrRp0xAf30ZZdzxefyMqq8+jAeexve8+TEsLErK/sRY11dKqkF2gsQ41tVeRPeQx mQiUcVoRSOiFxPd7kJTSC66uLvhO70fVVQjRjUJsqx+Jn4jHxcvnsbnyMoYWpEpjAZz9zn7UCy9W XsxHD9NXI8qF1P1TJ0vbjVidk4/K1hjkFC7CgMSuuHT8RWxZMRsna5/F/hnpYkstqmrPSR9PISmW o25BfVUZlhe/Bt/mfRgb14iK2vPo52eZiJDpshGFqGpNwIpvO0neFKKh6jwOuBojib6pDl7H2J39 tTRdRUXZJlQebcC+8ilovPg6vA29MHF4d9NdY+1hrF+Yj4N5K7FrIsccEpmg1hzn5CVtT8hCP9ru ciMx9dPC8W4Z1xmUV19FYtYw9OsqGCcmwO1vxsma8+iW9TiShN8V+UDAjaQ4+Z58xzG+eBOShkxG aVYymmoFh63P4FRDECvt2p4tAtGGgDrnSvI8U5Tsw6Eb9dp1RnAORBtx5kVDmncip06dwpEjR8xE RZu+/OUvY8aMGfj7v/97k1ddXY2jR48iKysL//Iv/4JBgwaZkM369etNPT7drbKy0sTtc3NzhSSM W3znw5Pq2sLB4lXIqViKbmzN2S4VYgaieEZ+h/1MEwKmXHKfQdWhgVhYkBfW6zYkRiaSc/AL0bsD l1EVcn5PVtfJpCL1fEJ8oj0zPRGXDs0Wkvdgybf3oF9oDktL24S05EWYuvEZVOQdQz9jlwcjpI+e 2stomVhy8vCSeNZjpwYzg7g0YNlQIXn0QumBVQjNYVoreBa+dAcfs9GWHzF2Dj6yv6/374rBRa+j wT/F1InJzMXY0aFw2ug85JTT3hKcHHIMA0Lj8B7aLRh2R2LrZbx0vB79RidJ3TiMLCg0bdBtL68+ g6fnTmkbV6BWyjyYOLewLS+obT4vvLpbzgNROiM36MGnlCDOfxkz9p2BX76T4JTtqGCTFoEoQYC8 rQ4tz+Rs8qOK+cEUM1hIsmcFFZ0NopXoGabZuHFj+G6EZD59+nQ88sgj4fhUQ0ODmQwYw9dn9zz8 8MMoLCxETk6OGTPz9+zZA94d3A2hpzhm8SKk4xzmbCG5iKj7GLySuFgzfBIy8Pv9bUc7nYCEayT2 IGGONknKHAg0n8EVNll/Rkj9MaxY/Diaj76OJsnz1b0un72RlhhA1asyC2TNCpO8ttIjR7x3ubjY yBpBaXX2LeTmlThOWmow/GIIrrkW68ZMEZLvjQ3XI3lt7BbOzv6aGok7wy2his5CyVJ7vY2KRANe KmtGtmD89IQE1O88Zsbu7FagFWmRkJczl2k/mn0OzA3+wcHHyp0UcALrXj2OC74m85X1nPgiTlQU WpJvD6O9jioEyNHK0zyTy53Oexclcw3c6/tjNZSj5VE1qpAxDLv87ne/M1fdunUzC6u3Gn7hNsu8 vDz8/Oc/x09/+lP86le/AtsbOXLkOx6q4Za43li4bCByF5agYvgxDIpwB8lohzF+5ImIvmKGrMRr MxzhiYjS4IU7KRMxeA0XfQG4Tkv91MnI6OuRvBJc9E+XvHOSNyt4FyFVPBICulbikOEBDkhoY1IW S5sxZ+jgdmq98XJ/IfpAo+Hfg0ueCZVLzLud5u1fNqNkxDC43W5Zfwi2F5M1D2liKu9GrpVE9Bd7 D9ZcRVFaMvzeMtHrjq0St++RKOsWO1/AyYYpGJnY0VgjW4sV6xc/2XaHFCwdhrKKKYjvOx0Lcpux XNqr2hks8XSXO6/F05HBBQQrFoEoR4DkTqJXx12deEP06sXrjMBYNiuQ/HnozBBtY2TIhUIb09LS 0KNHj9sykZMDd95wJw4ntpMnT94VoqcRAXEp3RnTUdD9BNYs2Ie0uSQKdZt5HoiXD0wXT1HzxKEV 4rupuLtjqIRGTp85h8bjzUifyhBHV4yUvCNC8vGngXSdLK7xZkOtB67ilDjRgzIZB5eJQaaJiYuX oqc41ZQrp/dgfdk5nKz3Y2xiyOqEx7FzTRY2j52NOZN2oWxv/q17uRIek5XlYOPmMwZDZ5QEQz9S 5vIkI8Ms/DpUIpKNqBF7B6QnmNxT+14z5/kTpyO2Re5aRPYeqsNIHbfJ6fijScbKUFaGQB1GXmL6 QeTdGFCwSo4AmnyNqK89g70bdmP+k43YWrEKt/fX1XH/NtcicC8QUAddiZ2bT3hovnnDFIncSfZc oCV5UkiA0SpcWKV86EMfwmc+8xlzvh1b6VGynscj7qLIf//3f99O9VvQdWHk8kWIubobhc+XiXvt IDvZ0RHrll01YoMejtIbtO1GvyEJ8G5dioPNHgw14RU3+j7RHTWlS1EuC6+DQnlJfcVXL9tvwjzO Bv31tbJYjOACpClwo2d6qkyWwWNowXQT2mkOTRQ8jZibj26xyVi47ilpdD/m7AiFpEz9yA9/O5e/ /vQbkQpCq/3790G/vnL0z7wJyUuwxXvCePpxghf8tdheI2GlvOkoemIYxkydh4mZHgldXTvOdp2G LgXvWLeZVBV3NsuQzvacwXjchNpciI1PREZ2HkqXPy5lV9FyvUkz1Ko9WQQeJAL04NUpZ5pOO38g qs67idGrq8+zBvWZVk8+Wsn+D3/4g8GW/7CMy99IuAVTt1Y69UjynCgof/zjH51Fdycd2wfbCnuh +Wo79pNFRK/cSVy6WIcL4aM+Ih4fNCDsd4btSRKSNBLzGFK420SkR1+J3RvJREpowXLAhFmScw4T CrbhQhOZKgCfhD1GFe0Wt38Whjo3GUV040GG3CFEcFuo3J0i5JcrcfF9JXhFPP5IEQIf3R2tR0uw /WyjKfJ596FE4ume7N4RdwDtwvDhZqRbtDZexRVfA6401MNbtQv5xfslHDVdtpS6cKVK1lJkMfhp 2Y7Zr38WBshEMVZ2GHGc5d729oSbdSSaDd6RuNfJeonYLpNla9kiHPAGbQ/IDqojRxle6wVuyrFi EYhWBMKELk47iZ48zo0mSvpdnLtMWEhy10o6KCpHs9BmvQO5np1nz5418fxPf/rTyMzMRGpqqpnx WFcntOvVvb188QbbVeiWMw8jDo3HQVlbDQpdyHOYP41hE6d4ZDfLHsduFomlxAXvNpxa7qTe4nHv R2BIn3BfrsTesvgrMe6sx9r2tcdnoWxdKwqLNmHG2MPhJhJlgXaj7D1vk1DMpi0DXSU8v/fl11G0 vHu4Dy1OK1iKnOp87Ji2Cf0qSsLrASzvMXwlFtTPxnLZErk3VCEmfTJ2hXYSBbOu7S+kKvErGW/N Jkx4MpyDpKzpYu9gWSvw49TL58G1DOcchdjeGCPV9sq20mlpoUnQVJe1C+Ott7XF72ZH8WzsaMsy qRGrZSvs6GdRUF+ILcX52BIuT8DE1fmR/YXLbMIiEB0IkLvVSSfBkw/VQSef/514uXIO/kCKhM64 Dq/1NoDD4I+KevXqFR0jcliRnk5qAxISEjBr1ixD4I5iM9Camhrs2rULb775pnnuDcNSjM0XFRWh T58+5nEJK1euNHF61qX+354w5sydLeLTuz2ID8Yq7ukw/U2N/B2SSFf5fULncocD/iY0Mf7kEtsl zGPFIhDtCHi9Xnzwgx8Me/MM25DoyeV0ZM0+eg5CvXb1bnlmHmcJnQiibbDcK89dNwy5/PrXv77G PC5E8EdT3/zmNw3Rnzhxwuys4WTGH1VRWF+3VXInzt+mMOYsLvp9FHdsXESo5j52/Y67crljZTJ8 x83YBiwC9w0B8rUhdOE8evS6h57cTQ7vwg8KSVFdfXrzPLRMz/fN6lvs6B//8R9B8masnjNadnb2 NQ8p4y9j/+Ef/sHE8L/4xS+GH3TGmD7r/eQnPwkTPcM5ViwCFgGLQGdDQJ1xcjW5m9c8SP7Me0gz OAMwg14880j6PJjH62iUr3zlK+E7EX1iJe3tSDh4kn737t3Nr2A5Jj4G4Yc//GEYEP6q1opFwCJg EehsCJC3eShnk8+Vt423zwFRgUIyZCZDG0qYRknyolEYluHiKoXPnn/llVdw4cKF8G3L9WwmAPyh 1EsvvWR+KEU9brP8/Oc/f70qNt8iYBGwCEQtAuQ0krs67LxWDqfRD+mGei3gmcTPOI9REJLnBBCN Qg998uTJ5rk2tI8Lqd/61rfwxhtvmLBMRzZzYZl6fHQCH1VM4RbLMWPGmMWMjurYPIuARcAiEM0I kLeVu3mmaB7PJkZP5ie5k9CZ5sFCzg7RLLzbYJx++PDh+N73vge+eITbKPnCET68jL+WJYnruLjo yh9Z8fHEfAYOhXvw+cwbvoiEk54Vi4BFwCLQ2RBwRmXI3eRGXZQl/3UxH0Jwyv4cIAmP3rLGeVgp WuUDH/iAecYNJ6eDBw8asudza7ilMi4uzizCckslY1d8Bn1jY2P4lobbkRiXHz169DWLuNE6XmuX RcAiYBFoj4CG2En4PMjn/I2U8rrZXskLVWAFkibj9EwzP9o9+w9/+MOGrLmT5vDhw2aRlTb7fD5z tAeFY+JzcYYNG4b+/fvfnefQt+/EXlsELAIWgfuEADmcTrsSOzlOhXldSIiqoAW8Vm+e6c4g3FPP EAxDOdwyybdN1dXVRcTq6cF/6lOfwoABA9C7d2987GMfA98ja8UiYBGwCHR2BEjoFJI8IxhK9jyb X8Y6B0hvngWspJMAf5AUjb+Mddpt0xYBi4BF4N2KANceud6o3E2ip5POqAy53DzUjORO0RmAhSR5 zX+3gmfHbRGwCFgEOgMC5GrlbPI4SZ5nTYdfJaiDIfuzkAuyTHeW0I3ab88WAYuAReDdhoByNvma 66tK8MSBPB7eT8gLHpwVKFRUz575ViwCFgGLgEUgOhFoT+y0kl4+iT+C6NVzZwUnsSvhR+fwrFUW AYuARcAiQJ7W0A3RIMnTUdfwu3mVIDfWM5MHhYF8CvefswErFgGLgEXAIhC9CJCnnU45uVzJnxOA XAcfcaCKHArT9PBJ9BSnh28y7IdFwCJgEbAIRA0C6rmTuynkbB7kd/L4Q/TeqaREzzMXYnlwJrAk HzXfpTXEImARsAhcFwHyuD6jjAuy+nBKcrqJ1ZDMqfTnP//ZED5b0hmCZ01ftwdbYBGwCFgELAIP HAEN2dBRJ8Ert8t1lzCRM01FjdHzzEN34jzwUXRgAB9kxrdEvRMbOWa+IJy/rmXaikXAImAR6EwI 0BnXaAw5W9dXSfQ8zGKsbsGhIoVkpxWjmfj4BEo+U/748ePw+/13/L107drVPL3yqaeeMi8lueOG bEWLgEXAIvAAEFDvXYmd/K28TnO6MI5DIaErwfOaFXhN5Wgl+61bt6KiooLmXiN8kxTvUK5cuWJC UtcoODJaWlpQVVWFP/3pT+Z59o4im7QIWAQsAp0GASV4Ej89e/I388I/mOIFDyrw8ZZMq5D0o1H4 4LKOJDMzE6NGjTJEX11djSNHjhiPn7czfCPVL3/5S/NC8fZ1z5071z7rjq/9DWew7psrUXWVE6kH aUNGoWBCLnqYl04HcGrLWhy82gJZPQn14UJi+kCMGZ6JeJd224QjG1Zh/dHzoYwEjJg/G9P6Jwev A/VYN3M3+i1eiox4rQNcqVyLvYFhKM5JvLYflwf98/IxNO3al4X7qrZhzdHLbQ1RN1d0M0K6gQas W7AfOctnowdtbKrFuhWrUF7bLBcxSMvKx8ypuegWfrF2AN7ybVi28TVQAzEJGDN3Hib1T5KLACqe X4SGzNmYpO0zt+E45n8HWPKNLPNycZ/3GNas2ASv6cKDnImzMGl4evjF4zcqZ1vPSFsLQ22JwTfE 03d2H9bsPI8RixehX/hLkO9qw1I0DZmHoUkcWKO0sTb8nXhSH0fxnHzBPzxo0bFiEbi/COjGGeVt p4dvnHiSHw8KCZ1pVb6/pt5+b3o34qwZGxuLJ554Al/4whfMEypHjBhhXhFI7/6rX/0qZs6cicLC QvMAIGc9pjkD3g3xe3chd9JSVLkGYsnqlVgxZxiajr6IqSNX4orpIICL1a/D6+uK9PTe5kjp3hUV O1dhfME+BINQjVidM14IpQ45hYtQKu0UZLlwcMVsjNpQEzQz0IJTl8/hVGNk2Kq5rhqVl2USETKN 7CcZcYHzWF+cj3Vnm64ZauNFsanBE7YpEaK7MB/5O2pDus2oqK1Gi5mbGlEytgTl/i/IGNeidPE4 NB1/ERPGbBQ6pQRw8rlRmCMknzZhHjZsXomnh3iwd0UhphyqN+UNVedx4Eyj0daPQFMdvNV1wUvf cYwv3gR/38koXbcWC57ohfKtzyBfx3+TcrZVo20JQd8Mz8aaE/AKnouLdoW+A5ohk9XRc6gPQVyx IF++kxYULF6JDavnIa3pNcx/cgo6gFOHZM8WgXuOAImdx3ve8x7zLhF2qJEY8nr4McUkQopWINlr jEfLjEKUf/CtUp/4xCeMlRxLYmIiUlNT0dTUZB5jzMcU8/jP//xP/Md//Mc9GE0jNhfvB9Jn4cTy rFD7qdjVtzsGjnwGe73TUZwWzPb0zcXY0SHvXLLG9PUgt/h1XAnkwXV0KSpbPVjy7T3iXQb109I2 IS15EaZufAYVeccwKDaYH74BCF6K5+xGTDAiZ3Ii+hk9CrE5eUKwV1GUEWpA68k5JtNh0+g85JSz vxKcHHIMA0TdHfKl/RePgdPNivWFyDAGJGPb5hYMnlaGBr9MpM3HsLy6FTnLXg7307MgFYmucZix dT98w6ezMbiDPkabBXI3qXLh6G5JDkTpjNxgrykliPNfxox9Z+CfkY4rNymXW1NtCpcO3RzPRNVv Poxl5YOxUu6IjIRtrEelDDpHJp2RKcG2e+6IQ/2g2TjV4EdGrAzIikXgASDgDLOT2HmQw//yl78Y Tn+IZEglLeAtABV4TQ9XKz0A2++oS3r5tFmF4+HeUu6o4duodNZLT09Xlbt7brqMSmnx6UIl+VDz 7nScOFImJN9GBv5w2Caoc6WOIZoExLr8qHpVQihZs8IkH2oFPXKeAgMfFxuv9chV55qzRodMQQua ZBJwd20jwQj91gjlcH/edncN7rjuptrm5/fBW98Iv1RzJeXjRMVhcIiXKo9J+UB8vd1k0nPiHpQd mA5HpCmie+dFbEovuTyBda8exwVfk/jWQM+JL0ofMpFI+mblbW3dKp4SH0oYhRVTe6FGJjdv5I2S NOcGg1jlz69FhbcOTRw0krGr4hiKHN9rW782ZRG4PwgoTyt/k8N5MEJDL78LSZ4ZKlTUUA7zSPZ3 K6ShfdzL88WLF80spn3Qk+eCLGc2jo3C8fK9svdC/A0McyQgPuQs+y/uw6iiPXB7xBeW3T0poxeh ONsDSaK1rAQDyyKtSJuzKEyCng7JOA4ZHuBAtXjkKZF19SrsgEoG+2kum4fHq+mL+9HcHFwzWDCk 7U5C63V8TkR/6e9gTbv+YjOxdU4d5pfuxpzq3cGqnu6YKPaPNTF3CR3FeNDRdMLnZsMRHOm4XyC+ 73QsyG3G8p0voGqndjEQxYunS0zcddPy9u3eDM9swUoiPEgbvgg5W/MwZ8lxnFiTacYQnP7iMG3z PDQuWIU1cucVsgjZE2ahaHR6h2Ntb4O9tgjcCwTowDqFHM48TgDkPROv0dmAZ43Rq5fPM4/OItxT /+///u/413/9VzPIS5cu4dSpU2ay8nq95rWB//d//2deOXgvxuRyCyuCi6xyEpZzJ2Xi2fniB3YN 4MDCF3CyvhnFsjgrG30kvPMUSvNChNtyFa88twk1hyQskT3w+jwYuIpT4ngOyqRH7Vg4lSuV1tY2 V9T0k5qLhexHOD4gi6Ypqem49bXDRtRIfwPSE6T5yP56ZE/Bfjn8TY24Ul+L8p27sUNi+q7tZehh mDFIj2qXOfsbcPZiC1Iy2F4HwrucGJ0e3BhQsEqOAJp8jaivPYO9G3ZLTLwRWytWoYdMXTcqj7hr aIMkslMnnjXBooC0O23zZJRPewHbLybDI1+fVuf3Wbo3EwF/E3wNl3Hq6H7s2PkMGl3bUDo8FOqJ 7MFeWQTuKwLK50r+vH5It0/yzIPCAop6+p2J6Gnrj3/8Y2M/vXjusOEvft///vebEA7H9Pbbb+Of /umfzI+kjOJd/HAlShxa9pi8VNUQbNUlHnj/TNmn38d46vRlVTwJqUhLCx19B2PaRCHvBi5OupHU l574/tDirdYQwhFCZctJcdJSiEcj6dSPU5X02tvEk9wH/aT/fn37YEDf2yF56c8rC5TSVJxbyTfY rnfLOAzM2WYI0B0bh54ZWSjeMs8UNjYFxP7HZGI5jFO+NjuYuiRrD/MX7gkTpz/SVNSffiNUwY/t OYPx+BbeIbkQG5+IjOw8lC5/XK6vokV+N3Hj8lAz5nSLeDqquJJysSIrBnuLSrD9qpmzBYttGDho HLwCuMsdi24p6Rg7dylypN4Fn8yGViwCDwgBJXd2T4InlyvRG2edbr1mMM14NisxXMNrJf0HZP9t dUsy5ztjv/KVr5h6XETm4uyXvvQlM5ajR4+itrYWn/zkJ7Fw4UJMnDgRH//4x8Pjv63OrqfsSsY0 IQjvxinYfrrBcLG/qQGvLBiHcqnjJPowU4faik+WmHQoRj5AwgHAOUwo2IYLTfQnA/B5yyQMtNss 9A6lu+pOxhiZG8qLl+Ksjzp+eF9dhYNCnoP6ODzmdmsBotihMOTT2ngVV3wNuNJQD2/VLuRzYTl1 umwtjCT6lOxhhsiXHaoNknZA+i5nXF42k8qk4E7LRbak1zw5TxYquZ4QwKXT2zB151Uk5o2TSc+N /qO7o/WoEOlZTm6Q8e1DSVkzPNm9pVTKn5DyskU44A2WB/yytfHoCdHsJRPPzcpNk+GPW8IzrB1M ZMxdizSZtHUucqdkyvpIM0qeL4OB23wnJ3BK1LvFMu5jxSLw4BCgE+vkc6cl5gdTGpMnqVORMwDJ 38wEnSRsw0cYDBo0yOyfJ3lTSPR8121cXBxI8gcOHMALL7yA5557Do8++ihGjhxpFmk3bdqEX//6 105c3lE6Y+4uzEQJ1i+Zgr3aUvdhmJl73pAwszqihYCJ8h7GyYYpGJqYhbJ1rSgs2oQZYw9rK0iU BdqNc3Wh14WR6zei/uuFEs7IC+ukT10b2umiAYdw0Y0TLgk71WzChCfb1JKypkt/g6+JP7uSxLsC 5JXsAABAAElEQVSeehlztpYgd2ubfnbhWow1k0Icig+sBGaWYPGk8WGFtLxnsWJisrnuMXwlFtTP xnIJ9yhOMemTsUt21FB6jH4WBfWF2CLbQbeYHH4kYOLq/OA6xk3Kzeh1wSL+5ngGw27hjiSRhAWr hyGvOIS/TOIrVk/GlOIXMb76xbBiYuZ0lI7mErkVi8CDQ4CcrWRP7nY66ebl4MzgQUUezlmB12+9 9VZUvhxcd87wEQaPP/648dA/8pGPdIg0f/36/e9/Hxs3bsRjjz2GL3/5y0aPj0747ne/izfffNNc 19TUdFj/jjKlbZ+/RW7zPYhtF/q49fYYnw6GBQLSTvx12mEM24RwbqBz633ehqZ48r4mLjjESHgl 9poJgS35JZ7tlxiN2x0nx7VtM8ZvNrDI9BffweIB4+FNjPG4pLyDLYw3K4/s8dbwjKzT/irYBvFm 2Oo6X0n7SvbaInDPEODLwbmrUMPtdHKV03k2++jVg6cVzOQ1yZ5xHl5Hu3z4wx82E9Ef/vAH8Lie 8Fex3EN/8uRJXLhwIaz229/+Npy+qwlhtfiOmO22OmF8WlYDbyK3onOTJu6s2CVj7ICcnY25JZ59 IxgMWTortEszHn6jLm5WHtncreEZWaf91d1oo32b9toi8M4QoFPOpxow/E6iZ/hduTy864ZdqEfP NEleZ4doJfuxY8filVdewW9+8xvs2rXLDJK230gaGxvNM21+8YtfXKPWt2/fa/JshkXAImAR6AwI kNjJ1eRubjhRR51Ou3l6pZPgmUnhTEBxlpmMKPrgFkqGahiS+dnPfnbHlrENxvfHjBlzx23YihYB i4BF4EEhoARP55wE73TUmf478Wz/SjJ3CiuR6FmJacbo+RiBziRcYN29e3eEye973/uwatUqWM89 AhZ7YRGwCHRyBH7yk5+YGD15m5xN7taHUzKvi4ZnOE4Svs4IVGash3lMd2bhQJOSkjBr1izzoLPO PBZru0XAImARaI8AOY6eO0XJ3pk2MXr13EnqWkF33rByZyZ6zmpchJ02bZp5iqWCYRCxHxYBi4BF 4G8AAQ25k6vJcbplXocWfsMUM0j4XK3VUA7TFJJ/ZxSSPLdg5ufnmx9SdcYxWJstAhYBi8DNECBH K29Tl2mnA99FvXUqktj52AA+7UzzWcHZwM06jJZyzmr8RSyfTU+P3opFwCJgEfhbRYD8Tc4muTsd c15ThNu7mD3zvCCh85qP+lVlVtbbAup0FvniF7+Ihx9+GAkJjkcBdBbjrZ0WAYuAReA2ECBP89DQ tF7rBGAWY3nBg0TPvZi64Z79kPiV9G+j3weu+tnPfvaB22ANsAhYBCwC9xMBOuVK7nTYGas3DjyZ n+L04nnNmYFlnTFsQ/utWAQsAhaBdwsC6sGTrzUCQydd+dvE6BnHUQXOBu9973vDCqr4bgHMjtMi YBGwCHQ2BMjTJHYK03TUeeYEYLx8kjwTOgvwrIVU5rUG9Dvb4K29FgGLgEXg3YCAkjq5mgc5XB81 z2uzvdIZ09HZgHlK8BrgfzcAZsdoEbAIWAQ6KwLkbeVu5e8w0ZPcedD1Z6bODurpc3awYhGwCFgE LALRi4DyODmcnM1riiF/zWAmM/RalXmtYZ3oHaK1zCJgEbAIvHsRIF9TlOzJ5c70QyRyzaSixuiZ pmhQP3hlPy0CFgGLgEUg2hAgj5PseZDgec2DuymZ14VE7izUeLzTw9e8aBuctcciYBGwCFgEgr93 Ig7OqAyvw/voWaCibyThtZI7JwErFgGLgEXAIhC9CNB7p9CDV4+e0RndS/+QErkqtB8KK6lO+zJ7 bRGwCFgELAIPHgHlaN1A44zIGMKnAhM8t4/VK8lzErBiEbAIWAQsAtGJgMbi1ZtXPmdkhnnmp1T6 iyoOQRWdsZ72zzaOzqEGrfrzn/+M733ve6iqqgq/N7Fbt27mNYE9e/YMh6SieQzWNouARcAicDsI hEM0EopXktd3yJLLuzgJnWkV9fJJ/M58LY/GM0l+3bp1OHbsmCF5tZHvk/3pT3+KZcuWITk5WbPv 2flK5VrsDQxDcU4Szu5Yie2X47BkeT7iwz02YvPTe5C9fDaadyzCAQzGyoI+4VLAj4rnl+Jk11FY OTEO6xbsR87yyajfsBQHGwE3XIjxdAVaWtAqbwHz++Mwc/1s9HQFm7hUvhFrqoGnlxeih8kLtnf9 utPRIG0Hhs/D0CS3aaTJewzLV2yCtznYZmL6MDw9fwp6BotvOi7Tb1Mt1q1YhfJaNhKDtKx8zJya i26hNoItOz+DdlZiIJbMzZJxBsV3dh/W7DyPEYsXoV98aJAI4JTY3DSENrtwastaHLwcMlaqxXi6 Y+SEcciI11Yc/fjOYFlpGVzp41A82vmKTD+OPC/2Nj5isOvWVI1nSo+ZiuF7Wune39SGt1ewXrbx NZgRenph0pzpGJmRGOqsEUc2rMX6o+fNtSf1cRTPyW9nU8djVmuvnN6Fxc/tRwMNiElA9hP5mDa6 TwibBmxesAn1VA5oDRoYQP+5i8x36ZPvcY1+jzEe5EychUnD08PYai177twIkKPJ1cZ7Dz3jhmny uFl7dW7L4VC1gEqdbUH24sWLqKmpiSB5HZO8GxeVlZXXlN2Lr7e5rhqVl1ukaT+8x19Hfc1+FG6p bevKLwRQW40W+eeMSwygpmwXvP62YjSdx7rj5+FOI2E0o8LouhCb1B0p3ZORItk11a+jxtcVKcmS l9oLscp/aMB2IZ762tdwsEZmBSM3qxtA/fFzuBiywXd6LfKKN+FC4uNYsnolShdPhqvmMGaMHIdT PjZ483EBjSgZW4Jy/xekjbXSxjg0HX8RE8ZsRFPQqGs/hYDXyLi9x2WCcSg11pyA9/I5LC7aJT2r BOA9eg71JiOAi4LHFSH39PTecshkXnsY85/Mw2ZnQ6Gq/sY6VNWeR+XOF3FJm+NZ+l8vONRLGb+b gOjV1F5FbGJ3JCYmBI+4OCQJ3t0Eb1/lIswRrDOmLsKGdSvx9dRmbFk4BevOBo2vWJAvJN+CgsUr sWH1PKQ1vSY2TUGoONjzdcbMQu+O6ZiwZD9c2ZNRKt/D008ki81LkbvgeJDX/c04WSOTiCcBSWpf 4iOIS0pGUpxMcL7jGC/fo7+v1F+3Fgue6IXyrc8gf0NNsG/7+TeDAHlciV49eV7Tu2dZ+MUjHLGu 3DLdWbx42qryhz/8wbw4Ra/bn5ubm81E1j7/rl/HuBETcgG7iuNNd6+5rARHhh/DULr1QhLukE/V rf84eDZKWW0j0vrGGVN8p8vQiu4Ykc7rxpCuCxnDpyDDaNThlJBcv2/MxiTxZp3iFw+uBh6kJTSj cscZFPXNle5uVlfYMsaYJexWj8VLTiAmaxFem6t3GanYdqQXSoYWYvHG4zixvA9uNi7/RdoBrFhf iAxjYjK2bW7B4GllaPAXIrYDR9t7aLfYIaTaehkvHa9Hv9FJZmgx8qYwI82Hsaxc7n5yQh6z2KwS kCEMGJ6PsSlB3bGjR+HIgjysL34RIypKHHdTUsPFL4VyGZUyw/ZICxpz6cyJYDa/IApPMQNRPCPf XEZ+iPe/8xxicteieHjwLrFnyiaZYHKx48xVFGUI/gJAjhDsyJBNPXfEoX7QbJxq8CMjBMD1xoym MyjZdxnpc7ZhZXZwvGlpqejXHchd+IJMyllIM2Z6MHFuIXpGGmeuLry6W84DUTojN/jXllKCOP9l zNh3Bv4Z1qvvALJOm6UkrwOgw05HnSEd8rr5wRQLqaizgpI8ZwPm67U2Eq1nvh2LA7yevP322xGT 2fX07ma+RFeQmLcIBenA+qJtDo801Is7FZMkelD1nXOhu28/yl8WLy1zXDgUc409DNdIZkBu0dvL qZcPA1mzsOQbo4CruyK9RyrfoC6L/RdPSCggBgsnKMkzV8SVhGlThWVq6kzfNxuXO050RTY/vw/e +kZGE6SJfJyoOIwQr5ryto8GvFTWjGwJzzw9IQH1O485PH+ZKRNGYcXUXqiRSTHi7qetAfMehbZL NwZNeEouz6ORYEUI77Y8SE+NwcF950IlTSjfcR6J6bTbgWtrM3xivN/vbztMsRvd5HtrLVuLV6pq 4WtiJy6M3XsMJ2ZIgVArp+ny59eiwluHJvNdJWNXxTEUhQG4/pib5K6wFY+hKETy0pQRd8ZsHDtS 5sDQj2afwzZjZ9D+2JReUucE1r16HBd8TWZUPSe+KN9BYcjNCDVqT50eAfI0hfxniD0Uhid3m0MV SOoaxGcFKnNG6Cwkz1XnS5cumX9G2t+R/PznPwe9fhWfz4fy8nLU1dWZ/aeaf7fPfjyCkfOfRQw9 0koJp6iHGuqo3/jHxbncEwyd+M/jgPDamOH8J71N8ddiu0SIJo4Wby1pMNKFKl6qbri9Roxtcr8R cmqdlWOTe8vlG6FwCQM4NxhXbCa2zhkGf/VuzJmWj9yhgzFwzHS8clbDSc6WpS1vGby8i8mIQ89M maTwGk42OAhXqqUNX4QcuT2as+S4lPM+5cbiSkxFouifFQ/6WvFgaN44mbj2B8M3vjdQ3todXx/C MXIioLCHExg/Mhe5I/PCx6itwTBcvxkbMSK1BTtWlGD82DwMHDQYU57bB58xOw7TNku4puV1rCme jTxpY+CgcVj9ak14GrnRmBu8Mtmja5iQL726CANzhmHUmMmYUjAbFSFsYuU7XiwhKqd9uSODIa74 vtOxILcXqna+gBlPjsdgsW9UwVqcDRrIAVr5G0KAnE0hbyvhq/Nunl6pMR3dfaPevVbsDFhwDL/9 7W9vGLr5v//7v4iJgAT/zW9+E0899RQ+9rGPXfPm9Ls27oAQhzsdG8Ujnlq6FN7UyeF/YPbhThuM JCG2Cgk4xzUfM55cTkoHsY2bGOQ7vZ9RIux4ejKqPC3imYu8egx+Cfnccmvi8V9Prpw+I6GMx8D1 2rNUusm4emRPwX45/E2NuFJfi/Kdu7FjYT5c28swMjGSpk/te810O3/idMS2XDbpvYfqMNJ4x+ZS CNIt5DkZ5dNewPaLyfCIy9wRhQe15bPpsqxYeJCR2NHoA/CkZKI/dqNcFidG1JYBqeOQluiciIjF QLx8YLr03IaLyx1qzy13OWv2YJrEjXyNV+E9fQzbZYzjG9w4tmWwTLaZKN2bKXdeTfA1XJZw237s 2PkMGl3bUDo8ETcac9dYDS8FRxMvd3gL4gbL1FOHxSv2o75J7JHxN8nd15Jv70GGmBS20KWBQTcG FKySI4AmX6OsPZzB3g27ZZ2gEVsrVqFHGCib6OwI0EknB5LDmabwTC7n8RAzWMiDM4HOACzUWYEN RLvwheb9+/dHnCyWXU+ys7PxD//wD9crvuf5PYY/i5yYy5hTtEoIyPmPnIRJWTGo3LoLL0kIx5M7 ODKmfEuW+XFwg4Qh0kdhwYxxGDF6soRAHpPFgcM4aRZQb6kRBEMuzXjltJPwWFcWYE9fhawGXzNp dDQu75Zx4oEGQ1XuWPHSM7JQvGWeMaKRJOUU3onUiMeeNx1FTwzDmKnzMDHTg2YhxitOPUm7knKx QrDaW1SC7WJO5HQRqew9KuSNBHTtUImTbxyGDvGgfMOL2Pydq+if1xuxnLycIjtVYuX2xi3krodp TmweJR7yZsaRhFjjE5MxaPRsLBwilRsa0OzdZjx4rwzV5Y5Ft5R0jJ27VO5IIGEUmY5vMuZu6Qyd yV1N6LtzxydjQP8+6Jfei8spDhG7JN7PyUftC96N+bE9ZzAeN5sAZDE+PhEZ2XkoXf641L2KlhvO kI7mbbJTIEBSd8ndODmcok67OuuG6DWOw0ySOw+dFZjuDMIx/PM//zP69u1rBtzeZu6lHzp0KD74 wQ9iypQp5tiyZYtR+/73v49Zs2aZvPb17u51LKZtmSzkS787UtJkIRGXX0OlkNek4Yzx3qb4XsfB VmBmYT4G9M3EoP5yjM5Hf2nmpUOOHT83azY+CwvSJaJRmo/NVRKPF6IKyC6hA8+Nww6xbeaczA5a uHZcKdnDJIAtoSrp23CKeL3e8uBWRU+7uNCVqj1yJ9ILT08cjH79s4TQMjF2quCEcyjvICCfMXct 0qSGDDcswrXGa/YJyV6pr8dJCXXM2XcVaYXTQ1tMw6rhRKuMLW34KMH9BGokbDNC3OJrbmhkYdgr 7V26WIcL4aMefrfoy3vnD8r2Rq/EyCl+Xy0qKiUhzgbvFpLExpLnyyTGz9IAfN4TOCWpbuKt32zM Lgm9ZQujr39ynizeNpn6TQ01KBnzTMS4udJPuyLtq5M+3ej/RHdZQ5Dtu97gpM3v8chRLjj3Ajfl WPnbQoAOOfmahK+ePEdILjcPNSPB8yBZMpOzAs/G5Zc8nSWiHRa+AvFrX/sa/uu//gtXrrT5gpzd SPKf+tSnzBjPndMFuOCIGKvncbfE6XFxu7tTXIm5KM09hjl0Nh3iSuoj3v6LKI8bJXvFHQXXSfL/ 1ITTQ+UX6L3GDMOAiLriseYloGrfCfgKUsN3Ce3rsgl6qcJ7RgYs34fA87Nl//VsHAzl0TN+evNa DDL72CXscZNxuZLEe5wqdy9bS5C7NdwIsgvXYmzETiE/Tsnic8yQlWH7jHZsb4zxAHtlD3p2kiQi JAkLVg+TLaCy8BwS7gLiQu14zZCQTXbhSvktQ3DHSjhbEi6z60YqcMCJfYRQX0Rl2jCzcyWgZaYC UTmH+dMi/164kFt6YA/Grl+J+kklmPPk60bbfCQMxIb1stNJqq5YLfF02fUzvvrFcHli5nSUjo7D kTE3HvO0tD4o3rtSZtYSLJ7UNqqk3MkSZtoV/q5ipeUdsgawI9xDMDFi9T7Zb/8sCuoLsaU4H0GX hmUJmLja+ZuOdhXtZadEgNxNniZnq8OuHG7Osr9c8oNErwX8JWwg5NqQJP/4xz/is5/9bKcAgGP5 zne+gw0bNoTt5S9i58+fj5SUFJPHHRSUH/3oR1i4cCHGjh2LcePGhW99TaH9MLHlJj/95hi59Y+9 YZjkunAxft3EcMg7aOO6jUdHAdcgzK4idzDME2kV4+PNhpgZwmp3MxOpep0rv8T4+SfrlhCQLg9c R7XDbK4RmO9RJrH4jva1dljLZnYmBM6fP4+HH37YmKxEzwtOALzuQnff6earV89bAPXkWd5ZhLZ+ 5CMfiTC3q7h773vf+8J5jGVSeAdAYXyfOppvMu2HiS139MPS24KG8et33Mht9XjflQ2BX7dXxsev v2503WqOgjsleG2CawR/41+BDvVdfVZHnWfyuPK2IXqSOUmdBfTeleiZr0RPxWgXbq/8/e9/b7ZP 0qN3yptvvokf/vCHZjwf+tCHTJye5SR2hnM+/OEPm3E769i0RcAiYBHoLAg4nXVNK9Gb6/r6+r+S 6BmuIbGT1DkjUJT033rrLaSm3sEC4X1AiXckjMfz1oVkfvbsWXkETLudEyE7Hn30UbNY+//+3/9D 9+7dDcHfBxNtFxYBi4BF4J4iUFtbaxxXcjj5m047uVGddLMYq8xPS1jAa56pqLcD99TKO2yc9v3g Bz/AoUOHDNHzoWY3Ej7vhsdrr72GrKwsDBs2DJ/+9KdvVMWWWQQsAhaBqEdAOVyjMzwrj9N48/RK zgJcfHXGdrSi08OPttFyMXXbtm345S9/eVum8Zk3hw8fBu9UJk2aBHr6ViwCFgGLQGdGwBmXZyib vE7Pnhz+EL1isj8veKZXTCWtxDPzo1E2bdp02ySv4+BzcRjqOXHiRNSOT221Z4uARcAicCMEDJkL V5OvmeYGEw3jsJ55qJnGdMj+3GxPZZI986nMIxqFYZh3Iozl/8///I/ZPvpO2rF1LQIWAYvAg0SA zjg5m5EZEr0z7E4+F24PuvY0kuEaXpPgqcwz86gYjXLkyJF3bBa3WH7gAx94x+3YBiwCFgGLwINC gLzNDTXkbYpGacjdxpFXMtfAvVOBSlrxQQ3gRv0+yOfW3MguW2YRsAhYBB4EAhquIY8zrWutXUj0 GprRTBpIRRVnWvPs2SJgEbAIWASiAwHyuEZhaBG9e6eYGD0VeJDQWUEracjGOQE4K9u0RcAiYBGw CDx4BMjfGpXhWUPyutnG7KOnmVRUcSoyzxK9ImPPFgGLgEUg+hCgU06eVmKns65Cbjf76JlgAUM4 GsZRr57KlugVMnu2CFgELALRiYAh9NBmGhI+yZ8hHJ7Ny8GpQDJ3/mhKV3Cp5JwdonOI1iqLgEXA IvDuRYBhdx4keDrr73//+812S/I6r82rBP8/e18CWFVxvf+xJRESWQICUeQJmCAQoSaoAW1Cf5bQ mlj9BamBtglWgVZClVAFaX+EvyK4hFqDC7gAtRAXUhfSNkErSVuIS9LKIkIq+BAbQNkTJXmo/M83 952XlxCySJCnzsB9d5YzM2e+e+83556Z90IyJ9kzQwsIGdMkeWvRf3tvIDtyi4BFIPARIIeTp9VA J58zj8Y7J4D2ugBLIX5ZSl02Sv7Mt0Qf+BfaamgRsAh8exFQvlZjnbzOOA+WtSc0jJDMafYz6Gyg pG9dNwYW+2ERsAhYBAIaAfXAkNMZaOEzz/frlZwBGNR6Z6EeWmYE7IdFwCJgEbAIBBQCNM7J12qk +1v2zDOLsf7uGcZZwKCWPvdk2mARsAhYBCwCgYmAcjjP/iSv2rbVWYBnWu5K8hTwr6wVvilnLlIU FBSYnznWvyH7TRmbHYdFwCLw7UOABM9fraS7htytgdxuFmOZSeudJK/kzkpMU+ibFjih8SeK7777 bjO5EZxx48aZLUnftLHa8VgELALffATUYKcBq9ytXM7RG9eNYXyve8af3HVW+Kb56PlnB+fOnWt+ e58gPP7442YW5F+cOvU/EO7BukcX4k8fyp8zFNCdECSng+gZfxtuHx2ER+YuwnYtkpKe/eJxw09/ iPOdv1kOz65X8H/yZ29/M6MfnvjV77ArtBNkSxS6yh8wr/rkII55pO2eP8TcGT+Etwr2vLUUc56q wq/vz8AAzZS2t7ywEPev74S590/G+ZLekJ+Du3P+KtowdEDstdPxm1/EO+14tuPBXy3DyDl3YXgv I2A+PlizEM94foTbk/pjz/qluP+FHZJfO4CufWKQPO5aDO3FcfqHBrAI6oqEcRORPJR/MHsXnpi9 BO9JW8e0OSmPjf8hUkZfDF9rBzbiwdn3In+HV+vzYnDrjDuQeJEz0D1Fi3H/nz+U0Ug7pnupWeVB wozfIrnPQan7PJLmTceAAyWYObcUN/1eMPI17ujrjGurv/ISPxHnegI2aREICATUWCdX8+eK9ScQ aMCT+Nsyg0IU0IMFGlj2TfHR00XD36Anmfft29e8xXCc/CMkjzzyCPLz83XYp3D24N3iv2OLpyv6 9zsPffrwOAd9evbD0P5Cbp6DWFu6CR36xSA2Vo6B5+GtFxfhxpRJeOuA063nwFaUFgvpBIWiz8VR 6D9wIPp02osiaXdv1364qF8ULpJ6fnyOXhfFADv+iozHSmp131OMaY+9iqDYqwzJr3tgAjKF5M+/ ehKy71uA2VPiUfrivbj2hhzsYS2ZQNbtKMO6vVW1bUjs4NZirNnh/B3evRtexYaNe9Gfuhv9+2HX mmXITJsuY65TjQ0aLDbs6eTIxg5ET88m/P72iXiQg606iMLSMuzt1M9bHoP+nT7Ek9kzkfGsl3Rl DNenzhSSPw+/mLNA9L4Do4LKcP+t4/Dg+r2mw73vlolOO9CtTz8f3j37n4dencjm0sfGYnwiulXt 3YjSHa+beH1NzbjeBfr4rhmvm2B9cb86ONevZ9MWgUBAgDyt3he16NVoN4a8bsNRIZ5J+BRioL/n mxAOHDgA/n49t5COHTsWd9xxB37/+9+Df1RXJ7gNGzbghhtuOOXheoQnk2+cil9eVM9sZMuGDLsi 9RfjMNTbU6pY8zOTMzDrsWK8eme8sd6dop5I+UWGE90O5BeX4NczJmOQt16dU+jFmH/3VRj3m7uQ 9+O/IKWPB3lz75UL+CPM/3F/eLa/iDmvHMToOUtx+wha0xKGXoyRFw/ED3+5CA+uGYcFCSa31pJ2 ktJGKDo4pjI6cEgd4nDTj8f55FJ/HIfrU2ZizbtVGDTUf/pxGug64lqk/nigk/jx9eiWNA55JR/i Vi8AI6+biFQfVuMwsqtMSE8Xo+rH/VAoYzjY4Qf4Y34Genn1GfpoHC6afS1+L29GNxTeJTrJJNTh Ktw+baJXwu8keIcqVctbUWOhw9UTcesvvHo2JmjLLAIBhgCJngd5m3xW3zg3v15Jnf132GicFf1J P8DG1mx1Dh8+jJdffhkrVqzAk08+ieeffx4RERG4+eabMWTIEDOZXX755ebvxza70UYESSdV8ndp PfIGwbcIPepU8Teag/rjpin9gPVb4Z/tLy+eCAmf4NjJBKS02/Cp+IU082jWUmwQV86j4mH51aMT 0U3K3it6Xj6vwk1K8pJiCOp/lamzYatjHTu5TX8adbxiVbu2GlfQRT1PJHkj4i8sYzggk0aosbad BuhXrA1VeG+juGiGDkRo1VY8I2MYPWeCj+QduSAkT5kk0Y3YZfAQ15Ygt0dAUqyrHMBqm20iRnPm mLjFqmSWrm2jypmXm6hriy0CZxoBNczJ2SR55XDNN/smacVTgIEFNP156J8T5PnrGiorK/GXv/wF zz77LGjVM/zhD38wY7v++usxadIklJWV4X/+539wwQUXtMowO4nB/MzciVhTp7UOyM57CUNPYlSe f7G4Xo6V4APhPPrSv1wIQsr9/w/PpPwfMn8DdL12gfio/Trs0NVnhde2H4SLYrvi2AslqJoSV5vt F6v7TtdV9Hwe1yZy4vALF9+GRDW5/bJlWQEHX7wDPyimXV2Fgwd5L3XF7KtpOW80k9Cfbh+HP/nV YfRXc/hms9HY4v7TgE9MXGF9xCO/bnsVRnNUx/6Kn6T81VcM/AAvFmaoLe+Xf5KorA3gxbtw7St1 y5Pue07ePE4ygdUVtSmLwBlDgLytFj35XDmd3E3SN791Q+1ouTNwNtAfxmFFHhT8OoZPP/0Uf/7z n/H000/j448/9g2B+bTqOWa6agYPHoyzzjqr1cb5iRjHdJHcenEnP4swSNYGRIUGWQs48K74pDvE 4Hw/XvYp3JJIaCyyM6JxY04Qsn9xsa+mb7HTl6ORKmwQl06H0XEnJcVjdV4jOIAYzL5PXDCmCfHr /3EB/rTxVfHRfx+D6ukvSyLAxdfiN+OE2IXjPbJketHFsejlxYKtxd54B1IHCtFKqNpbgruzXxI3 1VYkX007Xaz/Blwunu1lspTbFbf2l4ZKpRVx7zz1jLy9SNQj/4JkfaNF9CxrJ/j+b/HitOg61+jU F+fNsOyHReC0IkCiV4Knu53rjuRt5W6fRU8t1InPuJI8K38dAycrkvwTTzyBQ4cOnTAEvp6/9957 BpzWfphJXqFdxXoODWrAgvaqUocQq5D/wiZZCYwz8qx/KqFXf/HfiBnuELHTUs+LhMBefB5r98iO F3/L27MDRcJxg0i0JDsJdfuvwro1wtCjnXbMTpQO/TBS/Ps6hKHdJuJPNz3v7JzRTBWXc9eBcRg5 vGHfN4l8+MVxGOrz0V+MX77wEh45IFqE9jTrGPnPlYhV/X2/FsUVtbFM0v3QVdhcltglHopuMpM2 i9wb0JHvGR06dZVJRVpooLxO5zZhEQgwBJSv1VVDI9ZH8mK8G6InwTPojEABCqo1r+UBNrZG1eEO mgcffNDMbA0JDhgwANOmTUOPHj0aKj6lPHLFu1s34gNxB1R5SCFOCOp6HgYY9pVJ5l2xRyXuEXJ9 66l78cyH4q544oetQvSGqGu7NZ33SpiIhPl/x+/T7kDoI9MxUnYAefbItsWbZmK7WOhPje4jcj1x A338t9+Fkct/a7ZYbnj2XvxJ2kqKO887CufEPnx8KG4UGWmd8jqJOj74OiVOwpT7WkP/i2XSIXeL PjfN+i6K5v8Okx8NwvyfxqFbkAcb/rwImU/tQGzmYuPm2tJAkyfPIvZbwSUCndC69RnIeRHHdmzF e7tkk2aVH3hyDQdxt5QNFoEARsDfelePDL0z6sLxuW5I6uqf53hI9P5O/QAe4wmqvfrqq+bLUCcU eDNI7vPnzzdbLE8mcyr59EtveOz/cGO9Rugzf/7ntLSPCZlOxqNaLhbyr+5bWM+froX+567Orhf/ rJPF6zrWRaonfpO3EEG/mo55v/TbnXLeVXjo99O96wLi4/99Drb/THYApY3ztRw7ZSFuHa7vBzK4 BszmUBnTH4p2ITuJE0bzQwNNyQzSCcfk7eO9GRdjQMJMPFQVhGk592Lci7Xtjs5cKN9J0L4a1qlW 2okFSbv0Hz16+/Q6RfTDj6aPfuMSTLmpTpGY+T/Ci/mTGxpyPUGbtAicOQTUR0/OZpxnNdSNtb9j xw7JdxZg1dznLKAVOVNwQTM6Wl79Azxw98Zrr72G++67D0eOHDlBWw743HPPNdsquY/+2xqqDux1 7G9PJ/QyzvITkTiwZ69j8YZ2FX96rbV9ouRXlCO7YfYcMGY+Qrv1FBfLV9Sv7cYi8DVAgF8C7dy5 s+FtcjatevIdF2PpkTGuGxaQ2HnWQCESPsmfR6CH6upq/O1vf8Ojjz7aIMlzbBdeeCFmzZp12iz5 QMdI9TNEqYmTnLv1CjB3hfjDTjYpnWQINtsi8K1BgFytQd01POvfGDF/M5YZSvaMK+mrb56kH+ih oqICL7zwAvbs2XOCqhwbd9ZMnToVF1100QnlNsMiYBGwCHydESBn04rXQO7mQe4z/M4PPWi5k9Tp 31GSZ0X/BrShQDlTZ34hijPXpZdeii5dutRRjQMdKD8hMGXKFFx88cV1xlVH0CYsAhYBi8DXFAH1 uvCsRjuHQm5nMD9qxoha8SR6FWY+K5H4AzVw/YCWfLdu3fCDH/zA/I1Efjnq6NGjZtLq168f0tLS 8J3vfOcb83MOgXotrF4WAYvAmUFAjXPyN4108rmSPzUyRE8yZ1CyV2uelZins4IRCrAPumpWrVpl SDwkJMT8jg31508dcOH1l7/8JS677DJj8QeY6lYdi4BFwCLQKggod7Mxbkohp5O/NZjtlRTSwLgK cEZg2r9c5QLhTJcSf77go48+Muo8/PDDmD59OlJTU40Lh9b8JZdcYi35QLhYVgeLgEXgtCOg3E3O Jn+rdS/E7zA/Mxivb72zolr4p13LFnbAmYs/VqaTERdk75Y/JlJeXg7+js3w4cMtybcQUytuEbAI fD0R4FZKf+OcP4WgnG6c7/5EzgIGnRl41rxAG/7mzZuxfft2oyt9VGFhYbjiiisQHh4e0OsKgYaj 1cciYBH4eiOghK687T8alvn+lKC/Ja+/eEYBTgINVfZv6EzF6Zsnuffq1QtXXnklrrvuOvTu3ftM qWP7tQhYBCwCZwQB9ciQq3mQz/VLU/R4GIueERbyTHL3J3jNPyPaN9Ep/9brr3/9a0PyJHwbLAIW AYvAtxEBEjsPcjc5m9you24M0fODzK8CBImCPOgOobBWCDQA77rrrkBTyepjEbAIWAS+cgSUw9mx cjo5nIHntv6kru4bOvFJ7tyLzrxvyp8TNKO2HxYBi4BF4BuGADlauZxGO/lb+dx4avTLUCR1CjDw R+tVkEJa4RuGjR2ORcAiYBH4RiBAnlYLngNSC5/czaOOj57kzgp07PPM4F/ZZNgPi4BFwCJgEQg4 BMjV5HAGcrhuqiGXG6JXk59nCmigha+Er3n2bBGwCFgELAKBhQB5mgf5WzmcaVrzPJtvxtJ9o4Kc EVSQQiR/ltlgEbAIWAQsAoGJgL+xzrgSPM802H0/akb11ewn8VNYXTmW6APz4lqtLAIWAYsAESCh k6+Vt9VHzzKfRa+s77+7RmcEMxsI8dtgEbAIWAQsAoGJAAmeQcmecRI8830WvbI/XTZagYKapqAN FgGLgEXAIhCYCJCjyde6NZ5pcrnuqmxLy52FmsE0K3A24ATArZY822ARsAhYBCwCgYsAyZ28TQ5n UNc7+dv8KUEWMiihU4CVmOZZKxoh+2ERsAhYBCwCAYUAOZrbKcnlusbKNINx3/BDiVx99Ezz4J/n YyWSvQ0WAYuARcAiELgIkOT9Xe/8vRvyuI/olciZQWGm6b5h8K8YuEO0mlkELAIWgW8vAvTCMJCv 1XAnl6vRbnz0Sub1V2wpRGEbLAIWAYuARSBwEaBxrjzOMw+18Mnj5kfNlPVJ9LrThoJ02zCtFn/g DtNqZhGwCFgEvr0IKNGrZc/1VfI6g+FyhYaZzGAFJXadFaxVryjZs0XAImARCEwEyNfqcqeGSv6M m29CKbGr9c4KOiNwhtDdOKxgg0XAImARsAgEFgI01NVVQ82U8NVIN791o0SuBE9BnR04CWgl5ttg EbAIWAQsAoGFgFrvPKtxrrzNPN/fjKXaFDCZ4pv3eDxmJDojBNawrDYWAYuARcAioAgob5PD1Q2v ++pJ+L6fKaYgBUjwSu6sRMveBouARcAiYBEIXATI1SR2JXqSOw9yOQ9D9HTdKLlzpw3TJHiSvw0W AYuARcAiENgIqEGuBE9tTyB6Ziqp6wxAIRssAhYBi4BF4OuBgBrnuuZKrXUCMBY9SZ1Ez0x11zCP cSX+r8dQrZYWAYuAReDbh4B6ZNQ/72+os8z4ZnQmIDyM89DtOtrAtw86O2KLgEXAIvD1QICcrUH5 nNxNHmcwFj0z/A8K0vynv57BvxGTYT8sAhYBi4BFIKAQIE/zUE+M8jbPJxC9yRSC19lAKwXUiKwy FgGLgEXAInACAuRtuuH9/fQmjx/055DgdUH2k08+qdMAZWywCFgELAIWgcBEgBzNQ3dMqoFOTie/ m2/GMsH98zzz4O/Q07fDQ3+8PjY2NjBHaLWyCFgELALfcgSWL19uuJtkT5JnoOudcZ7bMkJCZ0Jn BD1zJuAfI2HaBouARcAiYBEITASU3MnZPMjp+usGXn5vb9w2dN3wYCEFSe48mGeJPjAvrtXKImAR sAgQAXI0yZ58TWKnZ8Y/ONtqvIIsoCDdNXTfMM4KuvvGv6KNWwQsAhYBi0BgIKAGOc9q1atmhsM1 oWcKUZhBrXots2eLgEXAImARCDwElOD9NVNPDM/Gvqepz6AFJHtNs0zLTab9sAhYBCwCFoGAQkA5 moTPOLlc/fZU1Oy6aYrMdQIIqJFZZSwCFgGLgEXAIECO1kPJngWM82ivMwEz6cuhMBdkuduGAszj 2QaLgEXAImARCEwEyNHkbq6vMu6/xkrL3vdbNyysqanxuWlYiYuwugMnMIdntbIIWAQsAhYBJXme g4ODDY/TYCfJ8zCuG0ZI6GeddRaOHj1qrHgVYj6tehssAhYBi4BFIDARIE+rYU6rnh4ZBhI/42Z7 pW6fJOEzkNg5K1BI0yZiPywCFgGLgEUgIBEgX9MVTz7nmV4adc23ZYKBJK/sz0IVDMgRWaUsAhYB i4BFoA4Cuq6qmbrmalw3SugkfCV9CvDHcUj8zFPLXhuwZ4uARcAiYBEIHATI4+RpcjcPut4ZfJzO hAoxruROYXXlMN8Gi4BFwCJgEQhMBJTQeSaf81D+Zp5vlZUJtdwZpxDPPGywCFgELAIWgcBFgNyt /E2SZ1D+5tnso9edNequoRDzlOS1AebbYBGwCFgELAKBhYC6bEjyupeei7LK3W01QrWV3FlJZwPm +8swbYNFwCJgEbAIBA4C5Gg1zHkmhyufmzQ/lMhVgOqr+c+zlgfOsKwmFgGLgEXAIuCPALmah3po NE2Z9sxkhv4JKi1Ucqf5r/vs/Ru1cYuARcAiYBEIDATUSFeSZ5qcTj4nl7fnBzN5ME6Tn0ErMI/C pytExsUhXBrfX1KC8tPViW3XImARsAh8gxEgR9M3T6OcZ6YZJ49zY01bsr7+3IGSPEmfgQL+C7St idPUeSuwrrQUK3NykCPHSomvXbUYqZHeXiKno2BdKUpLCzAnvjV7rttW3CxHj3VrV+BLdxMZh6Sk JCTFx9VtvCWpuFky3nVYt24tFk9tuJ0vo+v0xS9j3dq1WFuw+MuPr944UuXarRVdtc3piwtEb0mv eggNa16vga8qmToPBWsF07UvY9aXUUyvidSfzvr101/VOGw/FoEmECCh8wtTJHkGGug8GMjr5rdu 1HrXGYGFJHnmK+kzr7VC6gMvIz0h4oTmwlwxyFy6CpUjxyK/dzi6B1OkO4JOkGy9jKDQYJhuwoIR 9iWbjU/LRFaiS2q7gVjR/Uu1E4ow+dkJ/guXsTcUvoyuYeHhCJaxBYeFf+nx1ddlSJTL6Ipgp82w 8DDzkxnBrgjzdlZf/kyl44dEobuMHaJV6Je6ibzXRMYZzvqeeukzNTDbr0WgHgIkdWO5ez0y/Akb Bp/rhuY9BZihFj3PTKuPh+WtF+KREucl+Ro3Vi9ZhiJ3GJInTUJClFBtsAvp8+KRv3wzisq6Cznt Q8luv97jUzE1JhyVuzdheW4xjOtnfwlKvH6fSLGuw+Gkk9KmwiVNussWIb/Erw2/6O7NZSjrvh/Y t83rOoqUNoVojSspDmlTYxBWuR9ly3Ol1YbDySeISKRNTxEdhCU8lSjKW4jiU/BPtYauHEFkZKQz kPJyn7ssLikNcZHh8OzfjTUy1vpqxgnuMdHhcK9ZhKoaj9R3bqRKpyXfp0lL+3EywZQIhohLkuvl AirdWLS8iSkwMh5Tk2IEKw/2u8uQ63fRqLM0KW2WS5NpiJELWykyy/1kjBJx8UiLiZaLvgbuqhqf Xo1FImVsSTG9pdv9cq8sP+m9ctI2RO/pKQlwLrMbeQuXO/h5cRDHpNGb9c39KeMQX6X3nhWs5H7b L2m5HA2GpvWTMU+NlmdFmt20Brkn3GRNlPMaxUUiSMZftmb5CfdopOCdFB0B1FSivGwN8uu131R5 g4Oyma2KAPmaB41z8jY5m0a6crmx6JXstUCJXdM6AbSqZtJYze5tmOt9+IuLg7CqIB3hwTWoKBci CR+CuJgYoZMa7OsN5MtDkPbQKmSMcPnUyMjUaCXyMkZhftA8LM1O9FKQlsk5PR3pRTkYO2O5X6YT 7R0ZgxgSUU04emMhes+5B9nJkq4X0jOmoihnImYsr/s0zlu1Dokuh/QAF7JK1yEucyRmYw4K7kn2 vpU4jSWnpGDT6vmYOLcJwqvXtyZPVVeZzjBV3CzpMd1NkzXbVmPkhCIsfvkexEToGAQuGWvZyjsx eWGxyMXhoVUPYISOUbBsKsy5ZymSVd5POH1SOnImjkU9CI1EmriDMhKj/KWROcuNZSK/qDwe96zM FnTrh3RMSi/CxLEzDLFOlfsj3Xd/pNcXbiAdiXkrFiORBoaG9AzMcq/HjLHTTjqxqyjP8bMW454U 3qe1IWV8KlZnjcGayDnIGe+MaVveeEyYL1iuzJB3VAnuQnn5k7tklWLlRqa8DRLx2tC0fklzlmJW crRf/+mYuq8Md46ZbNpqqpyuvfExQuLeMF7GX1G2EtdMXig50r+4UxNpLWkYn45M0X2y6F7eZDlA t17KEKlfudmnkzZlz62HADlaSZ6t0sJnno/w6Z9XP7wSur4GcALgofmto5ZHqNsJwa5E8cGLb75g FZY+FInV8ydj1KgxmLa85MSuUh+qQ/J1BYKcV3OZH/wDf19fgyshBamaaMG5tolgJKROOqFmuXt3 3bya3di9OwmrsmtJvlaPYEQnZ+GBpLpVWivVqK5SGDdnhY/kIWQwY8JczFrhR/K+BoIRMz7L+LXT HppTS/JfStEa3/Xm21rq1AaughDiJB/J16Cy0nvdKD9nlunVpxpTfolgVwJMk2mL/Ui+eYrGzZpT S/JirdZ2OwJTm+PUj59Xh+Rrr3N3JGetQvjCEnkfdUKEK07mzEiH5JnV2yU0Kf96O1NEjXtbPZIX 8ab0k/6z/EjeixqCu8cga/FUmYUaL+eaTy3J116niJjxWCHjN/17Sb6ywo19lc5YwuS5ndOMckqH h3d33HrdW8916GhhP/0RIGerJc84g3pkDOkzgxGa/bpaS0tefwmNca1I2VMPJZi7ZH3twy8NhnV3 IXpEIjKyV6JUFkXTIk/sZRZf6U2oQdmy8YiNzUDZPr21T5Tft34ZRo4ciZwyfdTCMaSx1VbnefNr SPrJGS9txEo/3mzRM8lPgtHlM8ZifN42J1dcURmyvlCWkuqzPt2F2UaP2KxCeJ8TxKXPqddKC5Nf RtfgKIxPjnI6qtyGLLH4SiDumiglGrEwBa/xOWVeZcIQM/oWjPZa/5Cx5cTGIjYjz0deTWtdgWWx IzEydpmvTveIISdUixwtLiNDtPtQmDUSoybnokKlgkM15pz3rcd40TPWpycQMSQJs0brTVMjb168 PzJrr1vdFnypGCHZmkoheHHbZY0chTtzdezimAoN98mdLDJrUoLXkq5EYXasuc7ZhW6vuExSszah 3HvvhPWNRlKCq7ap4AhZvE+SN1gnyy0ukfqhKf3YvxNqsD5H+o/NgtubE9a7N5oqT4n33g9ybbPr XSdXTBK4JqTtV5SXYVF2HrZVVKBCSN8tF6ipctYtlwmskhhX7Pfd/95G7akVESB/0yDnQc5moIVP 7jbGOgmdBwPNfApSgGf1+7Qu0cvFXz5NbspYLCtcj23ufT5LyigRFoVJXivOpL0fQXrPVZYjexHd JyVYVuz2F/GLC0nnLjLp8ooqv/wWROXmX+n1MVSor1fmFSVr/5Z6q3KiI+khSNMynW3Lz3VE89eg wjcvBflXP/V4C3RlZ/vKxc/KSLz4vXmWoG9XKzNinAz57B0Z5XMJVJavx3KWlMxHids3EJ9sQ5Ea 8aE7V2ET9nurNFSzfNE05JW4UeMJQ2KW7LRamY5aZ0Ldlt0leY7/u7yijrEQFOzFVFwES8x1K8Yy abOxsGhaNorK94ulESUut1LkpNeOvbF6WlZ7mSuglzl3+SafXsGhYSjZXOGIh7mQPMQZlfNCIhOp uHzEqSGhEpvzih05v8+m9KvtX9YFzMXJx9jY8Rg/Xo4Zs9F4eQlc3b2dBbuQKeMvLU33vXEEyxtH f73v5S6IkjfirKwUREXIpMz1MXnr9jRRztaXz5ggb+mjMOoax5XkNzwbbUUEyNE8yNskdnK4Blr2 bZXMKRASEmLIXoWYx0PTWvHUzqlYvGoVXn55FXpvnoYJY8dglFjN4zNXQvkj2DXkhK2AHmWIoCAf OemCYIP6eJ9776lBkUYzg3Vm8ZNqIMuvtImop4lyv2JZuG1RaKGu3WPSMSeufg+V2LdvnzkqaLVJ fHfVZ35CLdDfV6uZ6NPtkhDt3SFTCTfNxZOFIIcaZTo9mUSz86evuAeJsj5jNubU7JN+W4a7755s pMfc1V7iD3YhxqwFyOaCErepETXCO5GK8ZJXfmIjTennMYvidetFyuQdI2tb3LjVVLl/zTrXvkLu g91V2D5/ArLy1qNCfVqmQjBcMcl4aHGazPmNl/u3b+OnFwF1sZOvadHzoOFO1zw9NebbUcykAH2M rKC+Hl2UZVmrhcjeiHS5EBHhQuLUWjcN1199j27l7hP8lb7+g6OQOS9VHJhpmDra5csOlAipwuNj ALGEUtKMapFpsvtGJ4oGHlB//cMjRyNNdgxNnz7dd0xNPYGZ/as0I16B1XnqmpBdTrPmgdsrlNoq txVhzJgxGDNtDSrl5vB4qrCt6C2fdRoWGeescURORbTXr9yMTpslMj0h0itXgazYURg7NhvuZtVs QChMdjolMT8SKdG9GxCozYqK8E4a++i2GoOxOXVdirWSTcSExFO9/sapskur9jILusVrsLvGr37l TuSt3uaXIW9Ym9Y7byl1ciHWc+P6+d5ipP/kVFZOwj3ZWcjMzES2XN/Gy+NkMvd2KK68ubz2Y+bC Xelc+91yP4xYsRZZ4jINkx1B4+UNPHNZLT7de0fK+k7j5Ww9frpskFi6FEsXz5FlfRtOJwLkaVr1 NN6rq6sNj9NbQ073/QSCumdI8urjoVKspJvwW0XJ8oVY705xdqoIaWesLEVGvYbdZUWSU/e2mJ9b hJSsRCPpSsxEqROtV/P0J72PXt2OfDOUC9nyBa/VmfOxLSkbUfLEuxIyULpukrx8+B5/FC2ZW7d+ vVRYlKxXRNXLrAhHZlm9vCaSdXX1YI0sdofFlyKBr+wRifLFrOUo2TYJyaJoWFSy6DnaT0+gArlY szkNUfTTc4KV1/vMen3W7UO8IPXKm5MsrxBCjGbNCGQWFCCzO7fVtizkrt6MZON2ctw/iVlN1zeL i+yoewIKpN/u0m9t0CmwNqd+bP6SIiSZXV7BGJGxEnUuM9zInVtsqpTJq6qLN4OEmgo3SoorZM0i 0ecm2SxbGhsKTek3Vybu5MwRUlU2CmSWYp1cHL3L6POfWy4TeiPleXBhRLLcaOK6ypHdYjVSW+vv cwOb+BIn922YLHivlC/yUR8tr9y/3zECGinnmEbL2lu0i7Ewvzdxpm1obQTI1crd6o5X8je/Xqmz AF00KkiB02LRy+hmy3a4om1qTvgPtwZuWUQdOzvfP9OJ58+WhcJC1K6/cnfGiWJfOqemXs36aRbL K+z+emJM7i4X/7Ivn1/wKsaEGbWuKH+S57bF2c7z76vhRPhUnTxUVlbVFtZ25uTVTzPXq6vv9d37 +j1jfqFP15iUWVgz4U6ZeL1AykOrDZblZWFarvhYJ09DkZZ7Syv1IsgbYJ1LUD/tlfc/eWr8xuEt yF8ue969YwgzJC9uJFXJFYOp/g00EK+pkv3dyycjp8hdp7RGGwGt1DpFJrFc3BJOt8EOyVfKepFX zBWTcmKF+jnFszFj5XpfnVr4KpCXWfvFuaIyt6/mbvd6iZdgp3Yk6ytFDdzurNCkfrnT6oxZrx63 R47lJNNEefHcCVi53s2uJPiRfFkexszIxcKJ2bKg7b0wwWGCkTP91siOreyJC5ssZ6tVsshugjSj Q3Yy7GdrI0Du9j+Uz03eBx98cJwzAQPJnZlM8yDRU/jIkSO48cYbW1svebuWL3KMdr7ogSa+lBQ3 dZ58qcMlOnhQtmgiZOea355wt7zy1z5Yra9oc1qMRHw8v3Tjcb4o5K3CL21F8muV8mWUkkViQTen qTMgEylfmomjv1qmsrJFJ345LC5JvjAl43CXf4kvFDVzPElpaWL1CX4NfGGrmU3Ii2CSfGFKWnGX 1/nC1cnry5fi0mLk+jhfwDu5XGMlzhfrwoOC5DKXN/3FsMaaOqGsGfpFyheeZOeSW6yQsIrl8oWp eo00WS5uubgYyBecG/xyIb+wNTo63DTa0Beymiqvp41NngYEnnjiCXTu3NlwuBrpSvQ05Nvs3LlT zsd9XTOuB8me/h1uj5o4caJP5kxE4matQk6Ky9u1WJI18kqpJkxlGTJGcbugDRYBi4BF4NuHwJNP PomwsDBjqJPoGWi0K7e39XfPMJNpEjzjKqjCZxK+kvnZKPS5e2pJnl+Dz7IkfyYvje3bImAROMMI kNxpwdcneeXu9tSPCR4qqAuyzDP+HZkZznwowewJY+SnBRwXCWevyv35KLZm/Jm/NFYDi4BFIGAQ INmTu2m00yPDuPk9emrIhD+xm0KvEOOBE8pRLNsCbbAIWAQsAhYBBwHlaCV25vrzuSF6f3OfFjyF ORvQstcKJmI/LAIWAYuARSDgENDNMzyTw8nfejZGO901Gligbht142iZPVsELAIWAYtAYCJAY10P akhy50Hi5556s4+eBM+DmRo4IzDw7J+v5fZsEbAIWAQsAoGBAEmdQcmdZzXiGTdEr2ROQlc3Divx G7FGyLtdh3k2WAQsAhYBi0BgIUBDnVytLhs13jW/Lc16Mj8FKOgfKETi59kGi4BFwCJgEQhMBJS7 yeXka7XmGefhW4xVS55WvQrpkLQRTduzRcAiYBGwCAQOAuRtBj/2qAAAQABJREFUNch5VuteNTRf mFJzn2Tv74/X2cASvcJlzxYBi4BFIPAQIEcrT/NMLvc33s3fjCWhq/uGWyuZ1t03SvatNbSS0vta qynbjkWg2QjExd7epKy9N5uEyAq0MgLNuS9b0iXJnURP3mZcjXhD9GrF64xw9OhRI0Ty56EzQ0s6 tLIWAYuARcAi8NUgoAa6Ejs30vDQfPMXpkjk/mSvC7RUUb809dWoa3uxCFgELAIWgZYioF4Zcjnj NNqD5Xez1Xg3Pno19XlWpz7jaslbsm8p7FbeImARsAh8dQj4CN1L9ORx/mS6kn77IPkNbQ0sJLlr Jc2nsA0WAYuARcAiEJgIkLvVSCfB0+WuBjr53PfrlVSfJK9fkqKg5mncZNgPi4BFwCJgEQgoBGiM K9GTx2nAq9HOs/lmLDVWq52ZugCrZn99C7+1R1jtfhOZM99EdWs33EB7e4pW46GCPQ2U1Ga5i/Jw 34siU70HD6XnYuuXVUzqP7fgXnTskOg7Jsxci62HavsKtFh1tecruQ6BNm6rj0Xg64yAIXPhbq6v kre5KMtA7jaeGn+TXwtJ9LpaS2HKnNZQvRcrHjh4WrvQxg9tXY2Z7hP/bqmWm7MQe0gXxqrwB/lL 996/mllHpKlE9dZ/omNYGt5wpeBAZSE+PcZjNX47pgqX9EhEobuBP2LaVKOnvdyD58KSsWRrIOp2 2gdvO7AIfG0RUGOcXE3+ZpqHWvW+36MnyfsL0b/DtFY4vQgE4fM2Vdj29tvY8PouhAwcimsSzkeI 6dQD99tb8Pe39wr59sSlCYPg6iLrCof2YMOeIPQN+QBrXg/FNWNCsU3Tf69G1/PPxvDLB6GL04i0 8TYO9xqE4JBQDKrWdQkPtr7+Nt7cehA9XRch3ttnr2HDMRrdpHcPyPd7tr4nur2L6pA+uObaYb42 D7nfw5qi7ZLfCUMvH4ahrlAHpuoP8PPou7Bs02qMGyiTRfokTFkRiqyckTKGodjx1lT0u3YdDrw9 yjvGKrzx4jq8IeTfd9hQJOrY5Y2g8MW3zLiGJgxF/LBepn3iUd2rGw6//i62VXfCd6mTe4vgsBdw DcW4BMpVYevbVejVy4M1BRuALv0x+lrBQ0qo987qXhg60NHXYNNlADof2gKRxKGiLTjkcsZ5aCvb 3SX1++C7YwahF/Gsj/0NA7zjkDITPNhQsA7FWw+gl4znmgSn3PQruAbv2YJtIYPwo2HdUC26vCzt d3b1x1BR+xB6YaBLr4+2Z88WAYtAYwjQiudB3uaZ3K15xtpnZWYwqMuGfnoKMugrgUmcto8gfIIl iBv+B+wRkkz//s244sEtprcND07FoOF3QBwp2PDMHRjc417jSqneswFx0amIuPAO3Pf2AfGy+KU3 7sNT378Nd71+wNFY2hwrbRTv8bdUPSicmYxLrvwtth06gNnSZ7cb1hq3hfvFm3HJMx+Yuj2xE9cN vwUbDlWh8Kd34MKwPCEjIaS3V0vft6BQ2qx+ey3iLkzBc14r/dDrhXhhwr1C8kF4LiEVUwb+Uqz5 32BvxhLMPBRkyO86IWInyESQkILvXf8mQkKqkMqxP/aeuI3ewwR5I7juRSFrmcx+MDwNE4xOHvw9 /TZc0icNt7y4BYULfotBYoVHRD+CN7a+LdilYXaRjLv6AH4idSL63Ay3dPTS9bchYthqo/ueglsQ 53NfSXuCTVzBLuwsWotHRTb3sUK8IeNyFzwu7d4mY5SJKOs2DAhrGHtnHPrJ8SRjRPI/0aVXEJZ8 /xYfrnuKHhGcUgXzu/D3rVWCYSG6CYZL3hYX15Sb0e/Cm/ETn17a3pk9V29988wqYHu3CDQDARrk NNbVYGdaOZzVxUPTvo7lrrMAV27Voc8J4PQGDzrgGmyovAUusRiniUXbbfgT2DplAaq7jMIL/0lB Iq28G/qjMO8RryvFsfpe+M9qU1a9da1RUdMbznsZcY9twLyEUULE6/Afaf+aYaESd0bCdYHrsoG1 HxfiMjFz56UPRcceQmrukYgKGYxBcNoXGxm50seP2P+U4YgNuwUvb03GaHkrWLB6OaaNofWcCGT/ E4eqnbb3bH0LI8YkS+IDLFnXFyUFwyTuQdRgYNmY84WE38armx3ZapGdsm4wSj7+LYaKHj+7PAjd bt2FjV1W44WRM3HgGcfqHy26n3vlcmy99g7jVhqU8zBKpwxA9dZBeCE6V8axxIzjmurXkCmW9Dxp J0q6mCZvFT+TCQfX9kesjO/lrYm41G981CJkJDBC3krip9yBZcteQ/UztwmmB/DzC1ch6x95uP1y sfxnJqJvhxTcX5CGh9meBMXaJLwfHM8v1l2B9ZUyHrmWPxvTR3C9A89tHSn9dkUwxuLflTfLdRY3 UcLNGPH4w3g1fQCwIFneWFLwB74xBEwQYyDrt/jRM4UBo5FVxCLQEALqeSF/M86geYybL0wp85PQ GedBIZ0hKHi6w7HBAxy3gHRE180IOdcI2dJlsSFrprOYKST7LkgWDB6EHZ+KeBKwCXXTUdemAnmr 4ZbFxQ3PLMOx+xPh8kqaU/Uxcxol/nKzWCokyLD3kDn5fQxGlFimJoScj9uFrMnndEn0enu5d5E1 GbdKnvC0E8Q9pKSvzVXLG8Ct7wB9u3hQnHUHop8YatwdbsnHyGREeSuHCNl9WjQS7xeI8LV9fC6R LuJOisNBM8lVS6OTZDKsDaHo7CXInsNEQd8kNRiXKj7imlHda+vVjzkLsWa+8i7KZl2Z4h1jCmaK +Aax7k/EvrYdjuf4yCtksvTmdRmEx7yYoVr0v3+Umcy50P3SOk5sOo5QXHrrYB9utS2eyZjcf+lj z6QCtm+LQLMQqO+VoQGvHM4G2pPcNVNnAqZDQkIM0TOP7pvTHc72WrimH3E7rKdrg77uC4WAH78X WxbQP/wBruihFr24nLyEprr5p0Ncw5GFBXhafN97HhZL+j9KKCotXyaAWJ67bkNfmTRIXtvEEu4r 1uqht1Wm/lncGcK/XYQEX0pPQzqmo+Q/N5uJ4LnLU4xbhDVc4rpwX7gWh9JT8fD9oYgLS8SgCWPx ixRgVI9kXHfXvchPd/Tp0usi8QP5uZRkzIWvHwMRHxSik5gk9uwSTE4lyITHicb71uGbQRppkm8z j721HNd4J4s9Wz9AjUv0PrT9BOy1mZCQnnS0+4UDKJZ+L/Pm+MYkY+vlJ8Xo4T0Et17mGU66xtx8 hjWw3VsEmkZAXezqkSFv0yPDs+FwfqhFTyEldfrpGZhHy/70hiAcabMQf5DFQxJu8bJHxFpPloVW D0g2icMGwCWssK2gEPTcVytZNaqULNA+/T387qcLkDt4KkarZeutE9KrJ47jn2KhyoKrLGxWb12H UeLXZ3/+oSfewdRl4jOX4C4qlMmjLy6TyaBmj7g7xsgCoot1xf0iHFXtJewQ10jkZS5DRMJq9Jyy 0Oy4KV12M7LFBVDxn99hqJD2Hu8YuPCLdxbiOe/YX5p5M67L+gCRN1yDrRm5sjbgTEKFjy0ABifW Wsr+Sp4kTt3vf0Z1X4vfiZy+nWx5cIPR4ZCsL6SLZS307AuH9oiPX95KRksOr0lIl24IEQv8J1fW X+fQKlUofmat0dV1ufiB3lngHY9gVrAauRiMy+rhD1mUHT1BvGFZMhHLxEk9Rv1W9NM3AW3ani0C FoEmESCP02hXy17PrMiy9iRxCjChgWnma2XNP93nW4enGBcILe2/fJhodrf89q7BshCZginS+aAJ 6fjFyJcxKkEI8xngyJC6GtVPDxQ/+SC8hqEzh59oKHYZhi2vTJKFXlks9Taz4JXlxq+8tW6zWJ9x CzpmOJmOTBA6z0xHerLk0+Ab/D1k3TIYM6+cjvjKJdJGEOIXrEbJM8tloVT89yO/h1+4gOIVr8lE NRjL/nG7475gk6LHv54ei0u8Y+TY//ofWSeQN5KnbklBXI/XKGXePv66y/HXh0jaN9eFdDDlJ/vI vfkW5HqN0ttWP474XlJ3zE247ubb0C9skWk3VbhZLfy+Y/piiizo9hLf/rT/3Is1sljazVt/xP33 YpKsFUAAqoO1vIFlyoQ6SeoMHXgFSp6+RhbWnWtGvR57K7cBXIOQ+NhyLJA3o35hzviox86TDcTm WwQsAo0ioBxOktfdN6zAdJudO3fWMrxk0rpnASvpJFBZWYmJEyc22klzCxv/KVix7MSCDekSqrxj mq2urhJiCxLipytD/MjVQeJaakaP4oPpKK6eEkO+J5GnNSlHiFiwjbVZfUjeNurLmLrC1dzuKYFf NgoxOvr3Je3Tr818OZwx+Jd742xLovXL2S/HHiJ9NGfIvpbFBXRV2INYVLkQLsHvBN0Fx0PSYUPt 1h0H5ZxxnTg2X28nRMw1k9moMVy3Fv0Te3sNQ/xAbvPk4mwyCm9djievldmolUNzfg628XuzlRWy zVkEBIHm3JfNAWrp0qUIDQ31cTeJngY7PTTkcmPRk9iZwTMD49x1Q9Kn8FcXhAi9pOnfpyELX0bz SN794uMYdP0q4C5xlTTGkI2Rr69PEiLJqF4wdWvzGiZCGZO4hpoMbKsBofqTXgMiJ8nyiE//HbN4 26DunDgb6lBaqzuOhq/JSTr1ZTdG8D4h9x/wg+/fhazHZyKkaAHuXPc9lBa0Psn7+rMRi8A3FAFy NQ1zcjcP8rax5L3c7vtTgjp+sj8FdIH2qyV61eLUz10GjkTu6lGIHyNb976NIaQXSv7xsKxzBO7g B6YvwpZhW/Dm27twKOEubH7s0lqXVuCqbTWzCAQcAsrZ5GuurzKt3G0setWYCR6cFRgoyJlBffUq 93U5dxko37wc+HXR9nToGSrf1g30SS4IrmHDzHE6ELBtWgS+LQjUJ3aOWz0ydYhe2Z8VWKBBCV/T 9mwRsAhYBCwCgYUAeZpGOcmdgWca6po2f0qQ/nj17VCIjnwG/SU0k7AfFgGLgEXAIhCQCJDo/Y1y 8rmSv9d3X9dxz1FQgBY+iZ7B38I3GfbDImARsAhYBAIGAbXcyd0M5GweJHzyeFta7xSigB5ciOXx dfXPBwz6VhGLgEXAIvAVIUAep3eGgQuy+uOU5PX2zCTzqxB/+kDT6uPR2YKypxpaa9/oqeph61sE 6iNg7836iNj01w0BddnQUCdvK5dL2snggBinoProeeZBy94Gi4BFwCJgEQhMBEjqxnIXDidn6/oq iZ6HWYylP54JCjKoJc804zZYBCwCFgGLQOAiQK5WUueZxK+8Tq3b1vflqJtGiZ/CluwD9wJbzSwC FgGLgCKgBE/iV88M84yPnkJM8KAAf96ScQ0kfRssAhYBi4BFIDAR0I0zytv+Fj4N9bb05fhvo2Rc hQNzSAGoVWQcIgNQLauSReCbgUAk4vwfMHnekpKS5A/x2KAIkNh5BAcHy29VOb97op4YGuptdaGV C7HqwKcAK9Ftw4NlpyXEzUNpaSlWzUs6afPx8wpEpgAnl/CrGjcH6xpqL97p54F4P9l60Xkvr0NB I3rUE6+TnPdQDh56QDT0jmdeI/3UqWgTgYWAXD/eP7wn/Y+Xv+R90fTg4jBv8WJMtYzVKFTx8x5A zkPzjEzqvBUoXZmDrKws5Mh1WjGnWczQaPvfhEJytrrZSew8yO2ffPIJPv30U7QloVOIBbTkWcgz 0/TxaKXTBUZNvYYj4+IR7zd9F+cvR97KXJT7yUXGncyCDvL+mUE/YUaL87EsbyVW7/bPFyvBrx// khPiYkE0JBoZ6ZgZnioZRf2B+DUSJ/ra8PVAgH+msmxlNrKys5GtR36+V/lIxMfHN/j2FtnQDVJ/ yHIfxcf73wtBiI6JwQl/k6V+vTrpk+tQR8wv0ZhuDd6bvN8buGf53J3wzJwwJr+OG4nGCY5NQibP F58w3RsOMfdSE6NQuWklYmNjsXpbDaKSU61lLxgpTyt/k8N50Hinld+eJM8MDRRUVw7zSPbq1FeZ 1jw7f/+VLSZh6dosRMsfoTBhXxmyxkzG/oQkpMikvb4kEotzEoDKYIQZmRp5IO/E5IXF3gqNnOJG IyVlNHqvX4iEe9ZidDgQ7DSCmooyzLhmsrdypZzjRY9sRAe5kTMyGzGr7sEIl6MUZe8U2WKkYsXa TER59aiR6WX3trr9x89ZhWzpqDI4DI5YBVbOuAYLS+rK2VTgIVCRn4t8f8tCVEyasxRZydE+ZTfl ZWHi/EqsWJeNKO9NXJQZi8pJBUiO6m7kKvfJ7F9VhFFjZ2POUsmPdvKBfVidOReurGxEiGRE9jrM yxyJ2d5bed6qUiSGrkfsmGlSGif3Yw4iK1ZjfrmrQR1WlWajJi8TE+YXw9x3yUBmbA4m1dNthrf9 uFkrkJPiQmWNPEtG90oUZk/G7Fxg3qrF8ofhzR0rfWt+jN/9LjaNuwgzxi5B0gqRdR4CZiJnYh5S VmbCU5iJsbPDsGpdFnrvLsRIjn/VOiQHFSF2iQcFWcnwIbEpD2MmzsesFeuQ4gWyovAxbHJN8LUt fw4DNfvlAZOZwVPpxur5C0U3oHw/n9cwyOP8rQ802P2Demc4AZDTzd5JnQ14pgCJX903PPM43WHq 0llC8vvkT/DFIjZrNSq7xyBz6XQEhcqdKDMSg7HXKwqRMT4L2+QmjUkY3Uy1guR2cNowrch9XJid gazV2xAcEYMkr6vFgxgsJsmHVWDZxLHAQ3OE5CEPpeiUkQePyGYtTpObcqqQvDysWdJG3mZfyyco IyRfUZiN8RxPcARGi1/RhsBGQKgZyUvXYd0671GwFPGR05EpJL+vTC3JSkSnZGI6zU1zW8m9sCwb r0evMCTPSSBDrnlNdyFSEYmcKvlC8mVCgrGxcu9WdkdyVjrm37kMFfIqWJYzw0fyRGfNJjcg9/8s th+fZIyfzf9qf3IdRCws1EvOQZLQ4KdbnpfkWRQUxAI5NnM8WdhUGYbEqbPEWk8zJF+WM17yM7BN tE9Ikr9yNitF7vdKLBMrOjarCMGuBCRNElkh+bJllM1GRbALKWmVcO+Tv5kclSCDjoNLugh2RclU FYdoSezb9D6WzhKSFyMuU9ri89c9OgVLxXdlVBKtylbn4MX9o0zbm/KyBcc81MjQzFBKFmLsqLFY KJNw0pwVyBzRHRVFeciXejbUIkAeV4teub2t+nXUH09xFjKopX86iZ4PFjAQcdHB8kqWDzFKgPy5 WOOWmzdc5moPy53Ai71+0WyUlOejfLfmtuzsTBbrxXopQT478QZ+czgicTxi5KbatOwaLJKbKdLV 3ZRGT1qFVVNjTDysr7iN5Kat2bQGc/OljfnZMulw+mgouLFIzKTy/DXYL8V+Q2lI2OYFCAIV5Zux ebP3KHejf+oIobxKrJnsWJJz5xaJpmJJ9nYIyL16LuYuysWFcS4xgsvE0s9HidzDJW4Rkxsjhfk1 Zcg2b5/5WGRu7t6ILNlk7olKd4kI1oZiab9SqC0mRRYdk3nfufFu6EUn1aG2psT8brJg1vTqVrcH 1tiHJWY8+VhS5JaByHhKZiN7dRFCR9+DgrX3IEqkgoNDZRwVEgtDeuk6rEoNw+qcTMxeUi4tADHp K1GwKgmb8nIwY3Y+1pSR6SMxPY21+XT3RlJaknzKhLb9XEQGy/OVny1vxXzMF8FNid7hApMUuFdj 8tzl6BgdIVU3Yf78XMFxPtbUf8Bk4p2VHCUT7zJcM2O5tGCDEjqR0PVVtfKNsU6zXjMYpz+Mleiu YVpJv7Wg5GvjurUrxEHC4NyVNVVHeZnl9Yx06AR5PhpmT1PQcJG3qpwqa6MtiVW64Zaq0akrxAaR m9z0VYP9VftRKUf5pm0oK/vQvO56PLW6NtaFo65X6cYEbVlAIMD7cNP8yZg82XtMm4vtst2Y91T5 STQMCgo3JaF886whuTUQKmtq6/tuB7EqJJxYYxHWu4Uv4ychNaa7cN56/LsJHfSe9+N507bqZhL1 PnxPibfSgOliJScnICJMdF2/HpvI5NQ1dxGyclaiqMyNcFcMkjOysXR6OeZm5aCwqAyecBcSUzKw WN7A89eUyXiikJzgwr71+SgTV2tCagKCxbWTv93QOSr3nwRJM0YgPEw6FR46iZRYYBGiVAUWTV5U b0Tf7iQNc38+90fDfGFKLXeSOgUZSP6nw20TJK+YwWHhiJY+4sTS4YPlXv8wtrnlbTUhRbzfLJgF uU+wr7z2UjuPBAsbD3xoQruPQFJqGtLSeDRvsYb3WMX6OzH2zkJh+CjMERdNxX62VoUieegnTi5C 7+goRHY/hE1usW9ikh1dpR+XDMLTuFq29OuEQO+6yhav2SQZEZj0QKopmD4rQc77UF5skr4PdbnM S4oUl8sccw/zxljv3m1cMfOSKBqHSebmFuIzNYMRER3na0Mjy4ukz+7RZh2oJG8hTq6D82SEiSzX uaaOdmkTTZy7I90oFIfUeKkjE9Sn4WyrAtnXTMC0/CqYF1rRP/WhxcjKiEHe5AkYJetW5P/wSzKR kzUJnrzJuGbUSBRJpnkDl40Pbnls6Psvz5uP9eXybiIurMrNJSgpXgO31I1JcXbQxE2fBJekd26u fc4libJt+6WBIZhn4E4V96k05veARYqOZWWCj8BsQy0C5GzlcJ79jXSzj54ZJHtuo/Tfg0l3Diur xV/b5JePFecXyY0iN1lpKXLGR8ti6HrkywMzO3ul5LuQKfmlOSkIq5RXt2nLvaZ7zQk2ut9191PG ye0ek4KszAxkZPDIRBKfAbEz6J5puJ42IXeOvL6u3FQpLtJ0BC9aIjetV6fSTETUbJPX3UWYm5NX q2tmopmstAW5x234piFQLPeEuCQiEjLNtsvxsmNg2+pFkLvTBI/HsY2L596JIrcHiVkrUZqdLM4O JxTPzkHZvmDJ57bNHPG5V8qCIhda5U1RqkanP4D6W3LLF+UZUhR/JpZwRjipDvnYtK1SDI90aTvL tzDs7VrueUc3TfufXYlZRp8R3WtQtGQulogrqVImtCzvMxjEm1n88UM205UUZbYzlspzIJ5xrPl/ OeLbD0ZyjrMVNUHaKFtDRUtQJuTOibBMnusSWkUSytevkc9iZK8sQ7ArUfp1nv/KbeKuyS03MuYB lVj+7GwYvDLZdqYxpPyfq94xIzAiJhEx4U41++n8bI1ytRruxEXz2uzYseN4Qz54WvYkek4ClXI3 Tpw4sRXxjBSLO05Wy91Ynit3gy/I1jGxhiLkQcitk+8TOCOR+NRURFS6kSs++doQidTUGFS4c1Hs n10rYGPfMAQiubUyLEJcDw1f87ipDyAzDsiZMEMoTdbyC0oxoqoQsbLrhCFOFlbDI4Tec8WHb3L4 wW2+QoglXrLz5aeiQEjOU5iFa8T3reFkOpi2ZeLIb8bNWLsz506EpUbW00cs/FR5MstER1EpLj5O LHFqK/d7miyaistyueivIZ5vtEHiZlku/nTNbOocKWsPkcLSleWib/1x11Y2z12FPHfNGFNtrW9n bOnSpTj77LMNZ9P9ToOd7ndyu3HnkOjVYlf2J1Rq5TNOor/xxhsZtcEiYBE4GQLyxbx12XzDq5St i7KtNrgGhVmybbKWF09Ws05+3PSl5m0XcCM7dixy65SeeiJ+3ssQNZEVe43dsXLqcAZECyT6jh07 GqInj/M3zHSjDYne/HqlP8Grj16tfP+ygBiRVcIiEKgIiHtlZEYJZiXJ22qw+JrzZiO3pOXKlpSs QV5YOdxr5rc6yVOb4uXZyCkPsyTf8ksTsDVomJPY6bbhWeNUmPE2brfbZ9HrKFiJRM9KjB85csRa 9AqOPVsELAIWgQBD4IknnpAvkoYZ3lZvjP44Jbm8fX3Hvc4IFKavhxY94zZYBCwCFgGLQGAiQDKn 5c7AuHK2xs1XXknudNkYp70QOytQkCSv8cAcntXKImARsAhYBNTlTt4mufv/jA3R8f2FKSZI+Nxi SYJn0F+tZEUbLAIWAYuARSAwESBHK29TQ8bJ52qwt2VEEyT2GvnihApoBf8GAnOYViuLgEXAIvDt RUBdNMrd5HQGpmntt/W34EnoTHNrjgZW0NcCzbNni4BFwCJgEQgcBNRgVz+9ptXSb0vGZ4ICOitw Edb/54mZb4NFwCJgEbAIBDYCNMrJ6Tz0d8uMAa8mPq14f0LXRVjrtgnsC2u1swhYBCwCasGTr9UD 4++taU8Bsr8KkOz59VkleD1bKC0CFgGLgEUgMBEgT5PYGRinoc4z+d346EnyjOgswLMWUphpythg EbAIWAQsAoGJgJI6uZoHOVx/ap5ps71SffN03+hswDwleBK+DRYBi4BFwCIQ2AiQt5W7lb99RE9y 50HTn5k6O6ilz9nBBouARcAiYBEIXASUx8nh5GymGQz5awYzmaFpFWZa3TqBO0SrmUXAImAR+PYi QL5mULInl/vHzWIsMzWQ1NWpzzx16mv5qZ51AtHZ5lTbs/VbjoBO5v7X/WStfFuvV0swOhl2Nt8i 8FUhwPvVn+z1uaWfnhzenh/MJPFSWP3xTKuFr3mtoTT78Fw2BV907y8/ei8t8u3Cnr9SHNru246g Nx5r1uXk9XrwwQdxySWX+N72mKf3yzf1/Pbbb+NXv/pVszCyQhaBM42AGufK2XwuGfibN14ud5z3 TNCaVyuP5M64VmitgbC9L8L7yXdzye5y2PNXjgPxb+51pdx3vvMdn7WgVsM3/Tx06NBmY9Raz4Zt xyLwZRGg8cXADTXkcT6ftOYZ+AybnykmoeuOG1Pi92GI2ev/8cs+pehxfYMQkmf7x+35K8ehJRdQ SV1vpm/LuSUYWVmLwJlEQJ9Rkjw5VQ11PqvGHU8BnQH8LXitwHJOAq0ZjLfmuLiL5N9xez4jOLTk eiqxt6SOlbUIWAS+OgTI0eRqYzgLuTNOPifhM898lUr9O1RLBSnEB5zp+r9tfKrq06Knb94QiD2f GRxacBEt0bcALCtqETgDCJDDydXkbSV5um747DKvvT+hM65BrXytrPmtcxZ/kuNSsuczhUMLLqQl +haAZUUtAmcAAXI3uZqHkj7j5HESvtleyQdZCV0JnhVp9nN24NGaweeuEbY37ht7/spxaMn1tETf ErSsrEXgq0dAOZw8bojda+ErdxuiV7X8H2h/617LW+vcxhj0Xh897NmZ7L5aHFpyLf3vi5bUs7IW AYvAV4MACZ6HBhrsNNRp3fP5NUSvQjorKMlzNmCZprWRUz0fP/65NCELsULyLTl/cfwzzL/tB0jq 2QE1Bz7CT+4twba28rMNkn/nlNFIdXXAljdLMedAP/xxTA/U/NeNkTmbuPDQon5aqtfXU775V1Hv A70/mnc+hi2vPoulf/obPv5U+uoYgf+dfBuuGdrD3Hi8r5rXzinKHfsAT92Xg4oeP8Ktk65AaAv6 bT5CVvKbhMDRTudg+8U34PNO3b/0sNp8VoO+G55B54Pbv3QbLamoJE+C53NFkmcgdzPdVgX4MPNQ UldhTbek06ZkzbxjdtuIZAvO6DkY3z8vBMEd2uHsnj0w+SKPVJdJQwYXGhos+UE4u4MHEb1C5NwO PYLlNx+O1XDdt0X9fCvkm7pIfuW8F3hvtORcsmgS5i0tQMVh7tg6hmOHd+LZ+27F3avfa1E7Le23 vnybzz7Fu+/uxrsb9xijpX55Y2k/CGz0W4TAhxeOxucdu53SiI+3D8bOYamn1EZLK/P5ZCDJK+Ez jxxvfr1SV2d1941aW1qxpR02JW923YiQtt+cM/363xvVE2f7Gm+PS787EHhHiONzIRNd1PxCthkd cxLVYulDJoIvevbF0z+LwkVhnOU+x4fvufGjpz7G726JxkXS4Ia//Q0zjw7Fs4k9EXT0EGY+/Ca+ +7Pv4rpzO0hZKWa+VWnAop7Hj/fAPb8cjO+e2wn4zIOP9x7Aokfewt/ayGp3LxeeTr0QF3Vri5qj 1Xhz039w20sfGtXSbrgCaReFGf0/3PsRlr9Yihd3y2w7eAieTToP/US3msoj+HN+Eea/00766Yns Xw7BZefKxEad//uR9FOKV2XaumJULO5M6IEe7aXO0U/w5r+34LY/7/W+uTQfVx+UTURIhnpPNOfc dv9aLCohwZ+LGY/cjysiOuLwO39C2uw/4N1nFuO979+L/h0O4vXnXsQ/P/gUnTt3RvSVibgsKhxt 929DwWs70ffyAaj4x2v412Fg4GWjkRTT19wvbdocxuv5Um+r1Ot+Pq5M/B6iep1l9KvY+Br+vOZf ONyxMy65MgmjhvRCuw5AEMfXydlo4FxD5+ZnvLHxNAHLt7Y4KSnJjH3fvn14/fXXG8QhNDQUw4cP R1BQEMrLy+F2u33Pe4MV6mVqH3v27EFpaWm90tZJku/GjBljGtuxYwe2bNli4l+IlwDyPLdt1wY/ jDoHnYLaYevHVdhYcUTG0Py+j7czd17zK5yCJJ9R9c0zzqDPLe9x3/ZK3vScCfTmpyBnBVr0bKB1 g6BFwGg6N/f8eSjSIzsbNXbt+Ah9+p2DHhdE4H8+exevitPfh7+5Er6UTAIXouDWYUIstSMYdPFF KJv2OYrPCkP/nu1x9qCeGHn0HAw7j9NIOwz0dMEPo88xdf7boUJ07Gjy6aJZeEccknrpzzYHocfZ ofjddA+G3HcEBb+WfrSbjmfh6oRL0V0ehlcuGInZMY7uLB50dl/cO6k9/rTiU5T9/MLayatjd6T/ PBnBj/4Jx5MuQ1If9kPsgzDowr7STzWGvNwBj1xzvpA/UO0Bzg4PwtVXXYYjpXnI+kgG2Vw8pX5z g5Ij5Rlv6vzffzkPf5fkX2B4eDt8+umnCBlwNRYvuBC7atojIvhTPH/LNKwWEtfwj38UYt9dj+J/ qsuwIr8QyNcSYOPr/8DhOx9DamQNcqf9CgW+eq/jH6+9gF8+9CQi3rgHv1mx1VeJdcrS78XMeL97 QXTXh6A54/A1ZiN1EMjKyjJpEvDJiP6KK67AHXfcYYg+Pz8fjz/+ODgxNDdoH0VFRaeN6PkHlrSf lStX+ohedUzoF44nx0YjNLg9Vr/7Ee74y1bsPEA/ZOAF3tecVEnqjHMSU6ue2hozh2TOgzc/C3no A8F4awdj0UtfLTl/cWEUhhmurMTCGX/De1Qq6BykXlkjRru/jrS6vRpL5IofX+CQ/Ce7cet1v8VP Vr9vCs/uNwAdd+438bBzeuDqHiHeSsG4ctS5EGMe8OzByjXHfHp+cawbwr6oFoKtRMEflmPRvypN nePtPsPIG/o5JO/5WPr5DV76kBYt0C+qH66Ldkj+vX+swnnzN6KaBWLFrkw835B89Udb8JPrlmP9 QRYE46orvoOhPZ3JZNemjbinoBy7DlZil3yDOGN4V0Py8HyEl5/9O9a+fxAfHTqE7pHdBAeZFJqL K7tqZuC90NyDTX522HkYXL3DUFNTg+rqahw9ehShffrhogHno+PxT9DWNQgXfOenWPLiCsxKPNdo ckQmgbZys5pwwU/xxxdewKJpV5jkpn//F5+//4pD8hf8rym7+38vkLJj2OzehJWG5F2YteQ5PLs4 A7x8m1b8BR+b2vxwSL6549D731fdRlqEQM+ePREWFobg4GB0794dZ511VovqB4Lw+V3OQreOQQhq 1xa9xDXcOcTYxYGgWoM60CAnXyvhk/QZeC+bHzVTi41kz0xa9jxTkHlMt2Ywhjx989K+2WrZxJkP adqoc+BQcXv8dM5InC3WLN/Jh8V9B23W/psiJtC2d4bH5HFceV6oyT/83514qUsvHH/ubbyTeAEG y+vYJ9s+wOHLe4oL4DxcdkxsZM9RafMsXDb8HJCaq//7IV6RV7h2chg9j+/Gy+8ewLAr+2DMz9JM u+ZDFpc7fO7dgvrJHrx0dg+8cPuDyPjcgzbtB+NvSwcase1vvo/2WysQOW61aHYcC383E8OlJOSc QUJcg3zt9ejzBQr+W43BF4SgT/QluDNaijzVKCl7Hwv//QXSLu2KzjLJjfvpOaYOx7bmrzvRRt5Q +NbRHFx9nTUjotZvM0QFp+M41saZ5A5WySQs95EaEFVVB3H0szbo0qUbRo50ofTxpzHp2qd9zeqN yYxzhw1CW5kcupxzvlPOayAPHEMH1zC0k8njwh8vwPOpbfH50a24y5S4MX/SOBMzH8fWY/fRK31p vc99GTZy2hAoLCxEVFSUIfu//OUvqKiQN+OvWXhmQwXi+3VDRFgIntu0G5v3OoZdIA5Dedp59h2D XTmcZ98+eirPGYGCrKTuGr4CMN2awffNWP6gmbAyf+umsfMXx8KREkn3CcNZuGSo9+GX1Nnnn4fr PnvTlOiHl/MleRzvfPQJMED83J06ol1wKI53OBc9vEYj9r2Ddz4ZjhGdQtFH8t57vRzSOAa4wk1T WzbuQJt2MovzFYF6Hh+KO/6nj0wCx/DOP0vwkudC3Pm93k63Hby9HpO3o+AwJPxsNH4ztBM+/NcO VQueDp3QvlMknrwrFudhv/xzwuEdG/Dw+koM6NsN53UNwcc7D+PDNuVYLy4kiHdtgLiozgkKQdxV l2Ka+BEL/+lG/85fIKRrDww+Lwydz+2LX908AC/+QRYc2/FNqXE8TblPq6YjvFFaEvrKD4LhpQrs /PMr+OiqVHSl0XDkHczOfBCHcT7+3/zR+L9H/iJsPgpzfzMBwW89jJlP/dtMCISa4XhNtfkr9jWf HXEymOdxCju1/8K8KXgqyrDqlW0YdNUQHKJUhysw94EJ6IGD2L17Hyq/6Iz+Z9EikMCG5WjpWJzK 9rOlCNC3fs8995hqfKujpUlXCfmE3MK3PE1TiOXMa8yo8JfndaRLkNzUqVMn9OnTB926dcOBAwew a9cufPLJJ3WuNY1VvmG4XC7ZuBGKjRs3Nslr1Z7PMfWld8wYPGLIffH5cfmVgLbGwv9cnrGaY5+b jSHt2jqm5Rdyf9Uc49uv9yY2Nb+aD+KghhKxIY7K5Yy3V3JXIVagIIFXS17LWk9lAcKQkQDUjPPx SwdgkCHnoyh4qQj/+kwmnuO9cMvYoUK6MglcF4Zdqpy8KfiHvA37sXBEOELOvRhFd3ZHTedzYOxg cbHkvX0IA8urMOI7jtX/YelmHI4Sojd9VeKNPwlxduLqu6Pv8d7tHbeJ+M0//LQzfjTcS/JS/qFb JpQ4mSDOGYw1d3RHj/7OwvHxkCP4mHONtJn88xtw3pFO+E5vetg/x1/XHsKl53ZH5/P6YVTUQfSX CewckXvvwCFc8t2L0Uek3tv8Ngo2d8DPLulh9Oh66SUYd7ksBHv24aXC9xB8zndM2zVfiLXBbasc vkzWTeIqYs0NjT189dvgvXNW5GiMwl+x9vAruP22Xfj+yF7Y/JciIXnxWF2Vjj7tncmvQ5dzEXz4 Paz+k7yR1Q9yc7Jf+e8EiXTs3tfED73yIJ6P+BE+WLkcm+TloU38D5Ag3p8V//0nCl+/BDHH30LO MyXS2TV4bOEQmZYlfEqed9p0GrSfpxOBXr16gb55hsWLFxsf/d13342EhARs2rQJTz75JKZMmYKB A523XS7YPvLII8bnr0am6kdO4ttBRkYGYmJijAHwN9lAce+992L0aNlWnZqKAQMGqLhM8ruxdOlS 8E2Ck0fXrl1x9dVXY9y4cYiIiDBydCW+IK7BpsKhrNFGZFnZh7j5+Y145NohSI85D1v2VuH+v+/A r7/bD4N6OvzhPvgpFv7jfTz9r/+iqppra19t4LNHrubZn/h537clmTNCAc62Su48a5zlrRmcXTe0 PMlKjZ+5fXLG5d79rAd3YPKzm7Hk5XIseeEVFO11XATDBg8W4vNqeIwecNVX3lDW/xn3vOF4as87 P0IsYfrZKvHc755AsWyBeuyN3d6KldiyvgJbKqqc9Ee7cB9XzWW29um58x2UGN/7WUgcPRSDOzn9 h5zrQvKm5/HcNufVrr+X5A+/vxEZi8swbskGfMRWZdJwSP4oCpc+j/uWrMZL70udoDDEDXdI/vCH 72LuY6/hj286C1cDhgzzkryQ/hv/QtZLpXhPJg4EdcePkh2SR9VHWJW/vVbPZuDqDLJ5n7xxmnvQ QKipORtTnrobo7jQcXgrXhGSJ8quUZOx4OcXoX2vS3C1PG/H3vkjZs5cgPe7OA/f317eIPOT15cr Vdmn3ntdunTA590uxT2TRkpLh/Dn5Q7JDxqfhZ8O6IFr/u//MFJegNbnPuSQfIfBmHlXCs76op3x 16Njx2aPQcfaPHSsVEsRiI6ORlZWlo/kWT8yMhLp6enGn+/fHnnp/PPPR1pamu9vItAttGDBAsTH x+P222835M2/H1BQUID3338f55xzDqZPn24mlY5y3ZOTk3HjjTea/O3bt5vJhOfrr7/ev6sWxUnu D1872EfyrOzq2hG3XnEBonuFtait1hAmTjwYNO5/Nj9TzBubpM5ZgA8WD02fjpteqFP6MN6QJs9f CNHfN/9JzKs6gLbtg9Be/N/tOoTgC/lCwrRbs3GL+NXbdugoLf4ZmbLNsk1IqHDzH9En54jkB6Pt WZ2xJOdpPPJsL/xyqFjnx6pQ/NfNKA/rjvbBZ+HzN19Fn1dXGiu4Q2g4Pp+/BI8cPYw20kfQ2T0J m/xz9G3b7jAm/Xohvhs3BP1lm99Ta7cKecjOpA5noV2nrjie9SieuHgwEiJk2+PhPVi2fg/aSn77 rf9EzNgS3JjsQrDpfxO2Cul36NgGGbMfxdSB5+FGcRcd+e9/kLehCu1E578/tByPfNoDN17dE8FB n2HLv9/AP/aGiV5n4XsT/4krrxiGwV3bo+bgHiz95y4Hl2CueThrFE3ha+6IZn7oPcEbx7TfxJm/ pPdJUAQmZz+NtCP78an45dvLlsew4LbmlbpGlqAnPLAS11dV4Yv2neVV2rlBPR6Pea3Pzb3O93of 7EpBbu5PTJrlfa6cgufi0uRLWMfQoVMXdGx/3Fhtng4uZDz2DG46ckSM9yCEnx1i8j/73IX5ublG b77OH5N7vbnjaCY8VuxLIECr/o033pD1mi6GsC+88EIMGTLEuFX8myPJ33TTTbKmM9JcQ5L8kiVL zLXlxMDFXu7+eeCBB7Bz505j8d91113Giv/JT35idtL87//+L84++2xs3rwZTz31lNnuSTfOzTff jO9973v+3bUo/vcdB1BQ/rEs2HZA0sBzcMm5ndGvW0ezgNuihlpBmDzNNyHyNuPqIuPzymAWY3nj a/B/kFmRlfzLVe5UzrSQm/uwUa6t+NaDheCkkpB9sHQt53bBaB8qZC2uGg6ljSzWyZ0gFng7o1pQ sLg3mC9W+XHZTN3u8BE8/rd9sj1W5Lr0xv9v7/yDq7que/+F6IdRLWh66QtQ85B5HekP4JmpcDvg qS1Cn8QfmE4CQ4p5U8NMao1TzDiGOjZuBjI1uJ4C7RgcBpcZQzugKWPhFngzhnmATGpppqAER6Kp lBe4GCpwipIIOSJCTPLWZ1+ty9E1PySD8SXsNTp377P32muv8z3nfvc6+5y7VWBEjm7BsBINGzU2 lA+z92eHF1nkZ/3ZrY7V24pwZjOLie0X2QDx3nfTajRfCs1O6Nf6HlZQaPP/9+n//fAD/fAHNuDY 3H6B6eIvD3KHf65X/3Doh+G4ZRFsEYOV+Vdkvv3yVJf+0S4aKLrIBrJfDbM7K5uT/2VRj/7xOz8M /Q8vGGfz+/b6lPnMjzGavndajfaWzTDzs9AGJAY1gMgMSpk7tKzfdgy5eAdwBvnBNYD4RXOz1Odb MxfefbqvwG4nr1zSxd7MG13Yyk4N2pRTV1cGY+yyMadL6hcvAwf7tCHfa3eezNf+ymz+3GzSD8fn F/p9Ni120QgffdpR7n2yz4bcLA1K8eNTQQCy/sEPfhCInXMJ0UNOnMekMPfOdAuEfuTIEW23O7kf //jH4S2esrKyoPrggw+GyJ7rBaIjikd+53d+JxD82LGZKdZ//dd/VVNTU7iGeIawefPmWyL6b/3f H+rYmZ+pdIS9ymhT0BD99YRjZNBiwEH+67/+Sx988EH2Grxeu8GWO25c8wTspP6dx0ZYvRJwiJYA yud2vCFfBv+iD7bTm+lxKsNbLNASb9/cKDXdz1kkb1/PjF5Irb0ZIbIfWB5oLqGX2R8+vEi/hHiJ /O2dexsmYET+9CsDpaCYO4Kr9guMfLP7Cf+G8+YHdxX99cOHGekm2g23geCXXKxF1q/14/WkvzRf CwrM30T/tlJ06P9zwV4GBzs75h1+29s+Zi+8RWMHy/GG/qmxN4N++Ssj/VB+tZ9wPAl/b4Trzc5R st4JMVl2szxtuKaQ5AXn7bimIO3BCBetC6TtxJ70K9mf63p6u69ftxvTT45AW1tbaPyR3dVB3NcT Bn0euv72b/+2mPJJpVJhegbOYmBAKGPLFdolp6PpK3nNQba3It/9z8wPOrovXdEJm7O/nrDM+8SJ EwOPcleB8B/M4Fqmmm6XOHdjj+N0jPhuhIexKLDDF4IvJ+AwgrJPXfKLdjucgtwRSPJOpZBghtwD HdL5J+4/Y8rI9xrHAbl6P8n6G/Xv9kjNaNavbHnG5ID+rtdPMDFIXNEdjHAdOFl/kvRW23NtfpJ+ b7XdYLC5l3XgCd5gyRUI9WbCNeGSzHuZp/xalUi8trY2TMesWLFCzz77rIjIu7q6wq+q+VHVmjVr 9NOf/jTwFQ948Y03a3hIS2DA/h/8wR+E6SIiaa6nP/7jP/ZuPlGafLvmCi+VXEfgUt5t540gfi0M pzY3N+v3f//3bxvRc6070cPX9OmczrGG1ysBGiBIGQUQRgQU2fey6xzH0IvNbpS7CwGuDS6Yeym9 u87Qnfd26tSpgmRzZdq0ablFn3if5yoHDhwIr0+yLALEDdHzMPZf/uVfwps09Pf000/r8OHDQW+x zd0TsKLHYPDee++JX+r+4R/+YbiGv/vd74ZXLf/kT/7kE/v1SRvCqfymgDuV2ymQu9+tQPh+18t3 ln3j98wylnQamL+f8JOjAYq3U7LTNRZ5humFmN5xHIZyPu8lck8OZkPBKOp+eggwxbJnz54wx/17 v/d7+qM/+qMQ0b/11lthzhsC54Erm8vZs2dVVlYW7gbq6+tD5M8rmhA+G6T4H//xH2E6yNt8Winf HwSu5bkE7/3z+ilTS7dLsM0UEbyNQPzk4W76D2/dcHGzUZFUQMkb3i6HsMMMNHaty5h+RjgM9Xze i2Q/VIzuFX3ecLmZ8DDc9Xxe+p//+Z+vuW4NEbbr+ry570PYCKTM+/j+0JaIlamQ119/Xf/2b/8W ynkIC4Fj4+TJkzp69GiIbKlnnR3m+B944IEwjZJOp/W9731Pfvfhzwxyj+vZvf8eiv79x5npqJ3H O3TcFjfLlZbz3XJd8knhXX6eQ7AUBFM4CA9nr9dnsu1Q88y+8F2Fx8nD68gwe5/0V17gpE7qoxBK nDRecbodgt2LlV8zUzjA6BPTzwKHkc3fDqP9zc4p54s3HTwQuJfSP/3TPx0URjfDMNZ/+ghAnES1 XK/Xi5S5dtGD7270HOGHU/+3elK/a9R0azMZw2wJlP95+OVw8ATNDET+/7f9IfPtQoYfoPGqqhO7 87fvD4fUfWMUQIGNMp+yceXb4RR2P9f9n8Zt/Q9jYpqB9Q7iAP6ch8EIekRTfuHcKykPAQeL0WBw jDqfLgJEzZD39Uie3jmf/CL2RiSP3rgfHdbnbLnyWxFIfnxrfdYE3xv65YEx2438zDYaQoZjg6c9 9Sl57nzg9WH2ek/2G48zTuqMejRCCQf5ZVmUiEBEICIQEcg/BPghGEs9+ANZD8jc0/AePYROBeTO hrBPOeLkH3biR0QgIhARiAjkHQLwtU9fEckzI8NUEWl29UrIPPmjKX+Ci1Lu6JB3RxgdighEBCIC 9zACzLywQfAE6/5gGl5nP/wrQcic0YACrwAz9iH5GNHfw1dQPPSIQEQg7xGAw+FpD9Dhc8oI3hkA CvhwMufVH5+ycfKncST6vD/P0cGIQETgHkbA+dqDdXidPBt1BWBDBjIn7Ed8NHDSJ40SEYgIRAQi AvmNgAftcDpChE9ZdvVKRgDEo3cqffO6oBA/IgIRgYhARCCvECA4h689SE9G9pSFh7HJ6RnyVCAe 6fMkN0pEICIQEYgI5CcCzuGkSZJ3b7NLIPhogJILjRBPvTymEYGIQEQgIpBfCMDdBOXwdXIWBm4P D2OpIHonkifPRiP2UYoSEYgIRAQiAvmLgAfqvGXj3O1cjtdhCQSUvBByZzRg8ymc5OiQv4caPYsI RAQiAvcmAvC3P4D1X8d64N4f6Wfm35PEnpyTx0By/96EMR51RCAiEBHIXwTgaZ998Yg+OSNjg8Dw 7EjAYaAM6fOqpY8M+Xt40bOIQEQgIhAR8BkZkIC/k/uUhambkOl/l57oHfJ3xWSkj16UiEBEICIQ EcgvBHyaHd5OcriXh7fqfSIf16mA6HnRHqEuRvYBivgREYgIRATyEgF4G5JH4GxmZCiDu8kPT0bu KEDyVJCnLndqJy+PMjoVEYgIRATuYQQgdTibjYiemRjnc2DJRvTs+CQ+eR8AMBAlIhARiAhEBPIX gVy+huhdIP7wyg0Ej/iIQBTvE/rkvd4bxjQiEBGICEQE8geB5MwLMzJwNgQPpzMIhGWKcZcdoncn dYg+Oal/7Nix/Dmq6ElEICIQEYgIZBFoaWnJELqROzwOd8PpDACB6CF0J3if0yFFvC5O32TxjJmI QEQgIpCXCDhvE6wT1cPfPIwN0T0ew/qQOakLowANUWaLEhGICEQEIgL5iYCTPN6Rd/72/zES/mcs FU725J30fRqHRlEiAhGBiEBEID8RgLOJ4l3gbjZ4PfA7H74RuYf5HJvfcZKnYdKAG4ppRCAiEBGI COQHAj7rQupBO57B7UhYj56MR/EQvStTTiMm9qNEBCICEYGIQH4iAEcTnMPfpPC5kz8eB6KHzBEn e4/maUSZjwpBKX5EBCICEYGIQF4h4NyNUyxVDKfD3y7h9UqUXMi7AiMC+8l614tpRCAiEBGICOQX As7dcDb87dF9eBhLoc/rEL17RM8h0DC5n1+HFb2JCEQEIgIRARDgVUr42gNzX6+M8gG/jEXZp3F8 ZCD1MuqjRAQiAhGBiEB+IQBHE6Q7bye9oy77rwST8/CMAFSyEc1fq3HSUMxHBCICEYGIwGeHADwN X8PVbPA5b0uSJ8IPET0ZL8gleC//7A4h9hwRiAhEBCICN0IAYmdzsi8uLs6+dROm5vmA+ZMRPeTO xis71Cdf07lRZ7EuIhARiAhEBO48AnA4JI84p7sXcHl2PXpI3cmeSXzI/dKlS6HMJ/W9YUwjAhGB iEBEIH8QgKM9QIfw4W/n8xDR+4+hIHUfEXp7e7OKKHmD/Dms6ElEICIQEYgIOALwNETv4hE+3M02 YI6eUYAGTOyTIsnGbiSmEYGIQEQgIpBfCMDVPs0Oh/tLNXB5IHoP+UlRcCHCd8L3sphGBCICEYGI QH4hAE+zwd/O4ewTzZOGX8b6Q1cKGBFcESXIn/IoEYGIQEQgIpCfCCSDdfJO8KQE7NlFzXDfw36I H2WfyolEn58nN3oVEYgIRARAAEKHr523fY6eumxE76yffLvGR4QwGhjxR4kIRAQiAhGB/EQAgkec 7MlD8JRnI3pnf6ZsvAGKvo9ilIhARCAiEBHITwTgaPjaX41nHy73tyqHE7lT6QXs04DRgAGAVy1J o9xuBHrUevSozvQk7HadUevJLivoUmvrmURFItvboZaWtHoTRUPJdnek1dFtLbo7lA6ZobR23W6l 0x2+k3fp+dajagPGoUrPSR3cfVDnh9ruZvpdJ3U81yEry5zrmzXO3/ozra12pUbJFwQgd3gbDkd8 6r0/kM9UOrFT+Ytf/CJL9DTwhuSj3B4Eeo7v0MatW/XartaswZ72t7Xx7RNSzwlt3vj2Nb9EbfXP aMmS+dqX/mRUn66rVV17txbvms4AACYpSURBVHo7mrS+YShk3au9tfO0nyY22LzxSpMYL/JPerR7 41btP5UcQQfnZePmV7Wr6eTglIeg1de+T5v32XlNSM+pI9p58FSiJI+zbTv053+1OzjYtmOl/mo3 GPXo4M631T50mPP4QO9e1+BoXqdkI1Bng8uRENnzQYGH/Sg6sfOPZZE4dRNguK0fTe8cV8HIEbrY dEjnF0/WGKwXFmiE3V0hJQUjQjrwo0N1G06rslJ6o75V85ZbxqSjrVmdKlJHc4suj6tUdVWFio2M m1u7VdSbVkv6siqrq1UxulhFqTKZqorHTdfS4tLQvjvdqL31TSqeXK3qmimitKOtUU3NaSlVoceq KlV8rlkHmk+rva5BVdbvk0tLg57dGqh57141dBarqqpalWXWujstmhZ1tqilo0gzHq8Rxb0X0mo4 0KBzxWNVPadG44pD91c/LrRqx9tH1FVYodlfmqWJo6Qzxw/q4FEjllS5Zj/+mMYYPG1HG9Vn8Lzf dEIF5Y/qK49VXLVhuRKrO9/WpIMnTur8mIe1YNZUBVT7zujgrnd0UhM1a07GfrZhV6N2tEsPTC/X SArNl38yXzrtzMxa8GVVmC/njzfqwgMPa/Jos2b1jefHaMZk6WjjWTtvnWo6ekbls76kx1A2aT34 Tzp2frQeHNGjkSMy5zVU2EfJg49qwQh6unDd9uh2nWzUsc7xmvXweHZ1svFd9ZQ/Zj5c0Ls73tb7 XYWaZn3OsD57Th7V8Z4HzafRpondTj08o8LwOmp49ej9E4Va8JUZGSxMo+98q3bvtWMsHKPZdowT S+ihR8cPvi0gnzprjh6eKB08ckJXznbp4Pd/VydPdOps1z61zV6mRxc8rpHW5kLbcZ23a/fDpiad KSjXl77ymAIChtHu/e9rVPlD+oId/pipkzW677zdNe1VW2ehps5eoBmZTuk4yi0i4HPybob1buBy OD4sgeBETgHK7EP8CGVRbjMCPUe191SJnv7WcpXrhA629Q2qg962A9qXWqV1615TZ90bygT1vWpa Vqsli5ZIFePUvGKR5m5rUW+6QbW1i7SkSRpX2qRFs59QcyIE703XaVF9u7rbdmrm/GUqttEjvWGJ Zq6n7U7NXbRe91dU6P7WlZq9Yr+xdLcum5f326RRd2+7li2pM4rvVv28maptNpIv61Xt/Jmqb+Nu oVG1dtfxRtoatL+k+YvrrVWHVsyer9bUFJX17tbcR9YPvCMwTJ59aaNOllQo1blbrz7/bePSv9fL m/dqRPkkjTi1S6tWEVX26MjW7dq4cZ9g5CM7N2hb68CwkrHy1KHdOmNEembXZj37WqO1O6m/Xvqy DvaklOprNPsr1ZqE/ZKRr2mdPXNWF/t9OWW+VBSe0Ibn/8II1O4UNm/Xof47hZ5Th7R9v40MfWe1 bftmuxNr08jCM9q54WUdN7uN335WG3e129h9Urv2n1Jf/wBuXQTpCVH+9du7XolOadfWzeY90qbN 23eq/VKXtj37knaeKdRDFX3avuF5bTvepfZ3tmr7of67hJ5282u/3RWC11bDa5fOX0oe8EnDc6PO piapoq9Jr359vQ0NfTr411/X5oM9mjixR1tffV47Wn+iCxdpV6ILFz40bCxb2KeLFzu1b/Pf64Tt nz1ox//qRrUVlOj8oZ1atc3uUvsxPNFToJPvbNTGzZt1qqdPu1et0u4PU5qK369+Xe9e4Lii3CoC yejdA3WfxmG/wBmfjlB2YkfJSf9WnYjtByJwpukdXbLIZ0zJSD34gLR//1EtqpgxUOkae03bN2nC k2+qqKhU1WpWvUXsyyszd10LtxxWTWWpag6v07SZzfqoivKlOry8xiLvGr3WXKOGdLfmuN2ilCZo mBo3bFD1unc0r8qiwMo3VQ4njq3SljdnaMLYIp0ut7uGA502iMxTdcr4fl6VRqtdZamxupxu0Cun F+pw/bwQ3e9Z06Ql+9KaM+eyUtWvaeNiO6beMr07t1mXbaDoMNNltpVXr9JbVoWHLm1v79KlB5/Q Nxc9ZkUPqXDbEV0a/7Ce/Oqjmji+UG1n7Z7nZGdmOsveAlvwzbWaZUWTOtt1ZACBGccY+Tz09N9o 8VSj7hmFql1lEedxI39N0jOPP2oxerlONW3UISPHyQ9nom9Z5D+pYLv6vrRAXW+v1KXyJ/XCIs7J LHW11+rIiYsaaS+f9Xhg7ndfdgdcaPa+ufZrZtcI8MRK9didw5H3+7RgzTc1y2CdM/6SVh1LkqyZ vWF76m0jmTjH0DhiwYA0/tJBXSyYrlk9+/T8pUla88JiOxfSxAun9NdH2jVtxAj7BaQ3LLS7wv63 5Sz94guv6yuZm4JgV30XbQiwG6U+8/7xZXru0T6V9BzX7lOG7XOz9VDK7Bw/pl2HLmjLnHIdeq1Q X/7i/9LJD/6PXuur0cNjCnR8REl/b3YdL1iur9kJ6avo0l8cuaSTe/vP559xPmfpYu2rlho+TOqn +pSa9Li+8dyj4Y7ASqLcIgIE587dpGzwN2kgejI+GlBAJO/kT556j/hv0ZfYPCBgt8B7z1ruvFb9 ubEPcvagxWozlPweZioSn70tqjsgfdS8QnO3Z8o76xu1tLLKomXj5lQ/bRqBV6bSRrBWmCrNkmmq rMwKPi6dzdLkF21eBSmdIptl0YXmbXY3sEmVcxaqvNM6VWXWzuXey0E1+2FTQU7YqXFldgeQqbm/ vN9m2DWN4gpte2uL6rdt09yX7DZjwlLtqV+scf2GLnX1qCBlI0mQ0fry4i/r/Lvf1vad72vkg5M0 5iKYjTdiMcIsLNFIZj1uIMajGUmNN4I+r44T1t7K9u/YavOYRoJ2lzApFeYq+hVtftNyfVd6FHxJ dDAmNUL03hfeScgQaU+X3QL0S6HdOWQm2qBOk0vndcY8nd0/hpTYFN2N5GPtByiP0uwvprT+4Ls6 cuWEHvjyCxZbH7FjGRnuQFBNTRyjwg+lKzboZKULIsfXDF4THVpXKJyqv3zuCe16e59ePmQD+YiH 9MLTo8QhHt23S0cZwEomafqklA1cVnglg08YUzNAuKWQjuw/Rvegz+AZkT2fo2QQmiclWrz2OY2w KafXVh2yvkZqwV/+jWYlT8MAq3FnsAg40cPlvFjDA1jn88DhbsjJnQYoekOP7F0vpreIwJmDarqU 0jdef12vh22NxZlntf9o7vsL/pXJ9NfRVKfmyjUW/e/PbIe3WKS9QRbUq/h+6d2Wc0HxQnO9xfql Kiy23c6G/umdDu3b1KyxpU7JfgyFmrIwpe0N7aGgY/8zmla7X+ca6lS5Zo+2rF6uJxdm7wHUa3xw NQ6/rKKx42ya5YDs2a5JrxreqNNoJ/igSzlig0NHgxa/ktbC1Rt17NgeVZ+u07nQjnrpwYcrdOV4 UyZiP7PbBpqVan7/hEZ+8S/1Ny8s06JZD2YU+z8HojOgyt4isxmjY5ljOnPkHV00gvkfD5UbWY3R V5e/oBdeeFIjzp+55sNuLAVfThzrr2/TvvZLSo1MaaK50NnJgdkUx752m/fOkL6NHAMdGFFu5/SS Go9n5iWO2xx3X0G/7kDNzF5u+xydibNr7IHETu06UaLZ022wG/+gCoz0T4RLpk/v2AP8wtRIjakY ryvBP5vk2X8wkLb3muOhPfw4qJe3ntLiF9Zqy5Zv6IFLJ3Qu9VAYsKZ/dblh9IIetQHyPH0YyWfl Or6GMTCrJI0an9Klfgz7Tu61a547nzNav2q7Jv7ZC3p9yxbVpC7q+Jnc6z5hJGaHhACE7lPuNHQO p9xinKsPW1HySh8RGCHi65WgdHuk9aBFY+UL7HGgy2h9cfpIbXznmPR49o7dMv4VRc/m4Tce0MKV L3oji74na9WETtU3ntN0u39v/tZ81WyCiFJa89aLKtY+07W5+UeMJOyRouas0XtlxUrbngd31kxT nlqnyplLNM3aWpitNXuqNPbcOTXXztW0l6xkerWR+Sv2ls8cVSydoNpFK1R16CmbrCdKn6y1zxVp ycxpwWbnhIXaU10mOsF2VtC1h8RPaKYemfaG6Xaqc/oq+Y0EeqMeXqBH316l52sNB5PyBc+pcsRB 7dn+smoPER0+YOTWpF2ts0N98iNcxImCQnsa23f8722wgH5GqOa55RpVIS0o/wuzXxs0C+wc/N3E JMaOfaH58iVNe/tl0z1qulc0YtICfamiUD2zptt8ufmzqyB8cbKBaPZcub1R+vKT07Rq60uq3RZM aMS00O2AD9e+eq6zJQP0NGqGZqV2av+I2Xo4dPqwFk3bp63P12qbaV4ZMUnfWFChMT2zNHLXVjvu XRasWUWhDW7Xk/EPaap26et2jBb/6UrqUU0aPVlP10y0ZxK12km7ArP7ZxNV0jXVUNxuc+/T9Y2p k3TFnklsa/3WAMvJc8BRjJm1TDXHVwa8M69u4/h4PTpJ2rrU/LYGV648oKcn9d/2DLAWd4aKAIG6 T9XQ1gmfMmTYBx988CvetEH8ZXvyPmWDYldXl6ZMmUJxlLxDoFc7ax6RXjusJ8psSCguNZK31B6y PrKsWIf3W0RukXNpKaXXl+5ue0OnNNM2aNnvJ5j94cm9/ZiCjBd7Nmus19oSnI+29jeT7u4LZrfU dK/tT49dayoZpRLnvL4emzqwqRYKuE6zpHqznmw+HVujzFZCtafLHjkWjtKobAeJypxsz4ULNic/ SqNHuTOmYD4Qmw7Kjb4uXbBJ/dGjkh7kdDKoXR6+Pq+exX+rr/HcoV/67Fg6DZsxo5Nk2RemWkoG 5aC91XPhvN172N3A6Kt2DThdMLsD/YYj+nEYxHnoO/Outh0p1GJ7zlHY16a/WrpZs/727zTDugl+ 29ROasxot+iHFNNPiEBLS4t9x0tDoE5wDm872YeInkIyCHmfurl82W63TXxECDvxIy8RgDLtDUoj 4wRRU9hp5G20b8U3FS6SAWLEnqXifpKnPpHNqhcnB4hs6bUzpaWjw4Pba9fC8UnSMi2bj89y8iDJ y21/zJZVlIwacK/hqtdMS0aPHjBIBCXzIUH712yXLQyDRHbvk2X6WrVy6UZ1jnxUf5sgeYwV2rGE 13IHWLZBcdAO2jg4ekzmVcikDRtoP45SwuggzkNhapTOH9mspY27LHS3qa9pXw0kn/U75zQnu4/5 oSPgvA2H+zQ8AbwT/rBTp06F2B5FFJimIbJ3gmcQuHjxYozoh459bBERuC0I9NlrRIUliYj7tli9 M0a67K5IJaPtDurO9Hev9vL9738/RPRO9D4ND4+zhak1yN2J3Z/Y+tTNvQpcPO6IQL4gcLeSPPiN sruiKJ8+Aj4rA8H7lA3pAKLHDSJ6xCtcORTGj4hARCAiEBHIawQ8OE++POMDQIjoIXWInkKfs6eM vBN/Xh9hdC4iEBGICNzDCPiMjM/PJwN16kIY7yMBOJFn89d13MA9jGE89IhARCAikNcIwNkuzudw NzyOhIieguSGIuF/5v3XuN6NA3g3pSxHnOatm/6F6WRvUdlPnDS2vEK2ttlnI7bQWmNDWuU1Mwa+ 1cECbA3NSn9kv/C1JRdmTBl3S/51pNMqLSu74ds91+vggi1cdv6BGbZoWEKj94LS7efCK6ShtKhU 5RVlV99KclWWfu4uVdm4nDeYvP62pLZqUFtanf1vxfEDtpudU8ej+xZwuS2uRyOfKgLwNpvPxJBH SENEn0vyvHXjBOGNPlUPo/HbjkBnS71Wb3pDKxct0iLbNrzxhjat3qDmc7wd/9lI86a5WrY7PbDz 3rSeeWSu1r5r628WdWr9Evuh1vrmgTpD2rMfl633Bd+G1DAonzqyQ/vbB/5asze9T/OXLNEbdXWq s8XkVi+abz/8Wh/W7kn2MPSln5OtB5m3BeWW2PlcYee2zvzZtHqRZtuP4hrt5ZZrS7fq5teq3X4L cSu4XNt2LM03BOBypuEJ1OFuf5My/M9Y5nN8NKDi5z//uf1A5er7UDSOcnchUFazXPU15rOtRDlt frFe2zjvagRqETTLBXfYSjNVVVW2uiUrC7fYfpHSzWlNmTNDna0dFhGn1Zi2dcGqZ0gtjZm8LYZT Zvo3W3K4O91sSx832I9nq2zp40qVdjdrZZ1U/WLFgEibVTabtFDvrV0c/Hu8aopqZm5Temmlyopt 5YSWBjW0dGrclOmqCpF+t1qaM761XrBotqxClRWZO4COZls8rXyypi99UpnfY3Wr0ZZQbuq01TVt mebKEGn3qq3hgMyEptixT8mJvgttBcaPvSZeXGS/7nlRG9fOy1wEa9OqnTZf7R3LVXo5gdtjtvTz jFLzuVndqcm2mKgdgN0HtDTaInAzbL2gjjY1NLGkdEozHqtSWf+tVbpxr+qbOjXZfJyROqeWzrHZ u5rMMRkW2ZuEIltBdILWb9mosuDNWu2vnaZ9dr5mVI2z85iDu+mMnYBmcQIXKdlnTdllNbb0qtKW NA4em412W6gtLDkd+ogf+Y6AB+uQu//wFcL3ufrsMsW8XI8ShE80D+Gz+a9m8/1Ao3/XRoAftRot Jyo7tNoi6PpuW6738gHNnflMWA+no3GFFs1fpH0tNn9iA8EKW+K4dm+nitNvaP7MmVpuRKRzGwa1 5DC/yp05f6WKp1fZIjy1mjmv3pY2zqxcecAYll/RuhSXjrVsnVastzV6bEqiu2iy9h8zEoPkG1Zr 7pJ6pcru1wGL9J/Zm876Nn/lbv28p82WZNjUH1mn9S1b3qCt+7LqFi2zCLbbfjE8U8uai1U51oh5 7nxbptnW41n9iC3P3K1x47q1ZO5M7U0nsXGvrpHaNBhBM/9xjSmQZiNrfmOWxO2yrd/D0s+XW1Zq 0StNGSMdDVqyjONP64m5i9R6f4XKbOW3+bO/Ffxu2zlP85c1q3J6Sm/YMW5uO2lLQL+Sc0wf96cT QM2X3u60WpttHDJnrol7tqlF9gEXWwcnp8/16Z9r+7JFarDBz4yqcbktUWDLTUe5exCA0CF2Nngc YeodDqeswMmdQvKE/JA9KSMD26VLV1fqu3sOPXoaEDDCTEpY094i6LcsSk+pQgtfma96W5VsjsWJ 09e8qY01Fh3bSpn3m86W1U9odG+ldtoUwcblT1j8P0XvHrjZksNGpis3iGWT59myyZqxRw3TnlF7 6c6wzPFjT1UPnJ8fV6PDb4226L/epplesWjXSMvW5XlrdZUaXtmnhevesujWPF23UPNXNKi7utJ8 q9ab+9eaP906u2ammjrWak53g5onrNJr5n6nRbB9pxu0odOWUF49L9xB7LAI9aPOVr2yL6V1b1XZ Cp9FWrdwg1YYMT++fEoSomvkAXGDZmcWBAr1c9bsEIfXlsCtt22bxdpFKnt8ranb9JGq1HvAlpZ+ cYv9k5WxWrvlTZVOsOWdT5eZjUZ1Gvm/Yf9IZt079aqyZwKVO4rU+NGD+m96VQ1paV6vHZPdSXBM SRmn06qd+Ui2aILhta2ySA3zroF7b3VWLxPZp7XpY31+XtW2uN1q67TmiV5tOF2p1+zuIMrdg4CT u0fwBOisbsA+ZG/8XpCdtoHgvdJvBSiLUzd3zwm/mafn2puNSaX67faPP+zBYenChZpupKfLo/un NjIWRhshQW+sPDl6QjlNCPZMTLe44oZLDneeTiybbDRbljIWM6F5ZpnjjGXKLjTvV/P9M/TE8rVh 673QrCdm16rlmbfUaqzf3VBv//KwO/zqb+GLU+jd/Jmc8cdsz1tVqeUNtjLnuTrNWb6j32c6ssaJ JZQrah63f6iyNwwkDfV1arD1eUpLF+pFi6RvLnj+nA4feyIMGgP0c3ALdWHBuWY1NLeoc5O0/HAZ B6oNdseRrpyj6nLzzaTI7jrabWgYWxp2VVpRoxrLdqyZriV2TGWddTbV9ebVY8qoWbSf0puH92tK f7tMca+uh3t/s361a/epsUt1ekmD2spYcG6hKq6eogHN405+IgBHe9DuUXzS0+G+42QOsTMaEO6T D2F/WArPNWN6VyEQyPmqx2OnVFnIW6anlq/W6tVPaWy7/Zep/uoM/fTvfHT5aiPLX92zXMeNlhwu Dksf1zO5j3Q0qs4Mp65DHB/Z1NBLi+r7pypsDAl6KRUXjbWo26Z7Hn/K/Fytp6rH2jxyv6cJf8qq ntJHG2q1rK5ciyszAwrdFv73Kbbqpv03ptCkQyunTVOD3cFMsLrHn1oebFan7N8s+sHT6HrSjyGD zLVkAG5BwZ4JrFyoTbVLVDfdVuE0Qu49Z9E5y0xvWa3lT87LmCkus/um02rKOKmGZ6apdr89OZmx WNbYjsnqp18rsr7/6mrRWYcGift1+tS4Kvs3NZu0aFmdnrPnI1HuLgSSATlRvM/GwN+Bw3MPByUa IR7V5+rE/bsIAZgzdZXti8vm2JTFXM2cVhcOIrVwnfbYQ8O07aWSh8XSwi65+ZssOVz+pE2rzF6k advNoq2PvvC1PSozW83BXsKu7ZfN26JVzbM1NzEtMv25LUaOxZq8ZY3m2r8nrMMxW3553Z49Ft22 Z5ZIDrbsw6Ln56ZLL5UtDvP6Xmz/G1HrVlWEJZQp4zhXlZWrYk21PXOYllFL2bLKez5OpOGd46wh y+RgmKwin8TNh5rSyfM03Z49lNl/2QpjV5lNFzXXapqt/ZyaMN3+lctpbdjXqXVvrtLMJTONYjFk U2pMmRSnMsdkdxxTQmMqr4r3cbUkk7se7o0DFO0u6Fp9mk71c9Xa9FKRqipsZIpyVyEAZ/u0jTvu wTvpsHQ6bWnmlRzSUJggem4DWML2oYce8vYx/TVAgKWFL9tD91JI7BPKjZcctoeW9mBURTY9NIgu fKnjUtMf6FLGzoAllIfir02PsIbngOOk7LKVDcaxofR1U117eGpjblj62Sayem0IyEDDMSaXks78 L97ute9pccUgwBvQ72Bxz+2Th7S1WmlTVPVPVAywGHfyH4H3339fv/mbvxmCdJ/CIYX8Q0TPSACZ s11PIP8ov14IDGVp4esd+Y2XHC4eEpFe35+h2fmYr8U20OQWUjZU/sy18Yn2jdiz/TrJY4hj7Ddo D2ifeWS+mipX6b0hk7zbynbSb/RaSaJPG3L2P/OIXmqarh3vRZK/Flr5XuZBugfqzufwe9hYptgr YX7yPJBljgcF9vnHIzGiz/dTHf37dUGAVzgzUf8dPCJe1bRRaDBDxB30KnY1SASI6Efa/znm+Sq8 zSvypHA6kX14GBsY3wq5wHwkgOB5I4fQn3yUiEBE4M4gcMdJnsOKJH9nTu6n1AscDcmTcv3A4wTs kDxbASTvczkjRowI78wzCriSz/F8Sv5FsxGBiEBEICJwiwjA0x6YQ/jMyCAQP/nwggEKCISPQPSM Ch7Jsx8lIhARiAhEBPIXAfiaSB4+JyWI9xmasAQCrkPyzv5UumL+Hlb0LCIQEYgIRAQcAX+u6vsE 6HB6mLpxQvd5epRQYAkElCgnjRIRiAhEBCIC+YkAPA5Pw91sTL0j8DcS5mRciQInd5R9KofyKBGB iEBEICKQnwg4oZPC52zO35RlJ9/Z8cidPEqkbFEiAhGBiEBEIH8RgLudvyF5xPmbtIBCf7PGp2tQ osxJ3g1QHiUiEBGICEQE8gsBn7KBz/1deh7KOncP9wxuO7nTyEcDypM67EeJCEQEIgIRgfxBAI72 wJwUDnc+D/t8OJG7Au57+E/q9flzWNGTiEBEICIQEUgiAFez+QyN76NTQCEF/g9HvNLJnfCfn9Py FJc0SkQgIhARiAjkDwJws5O7pwTtcDp8DpeHqZtkJO9zPZA6JO8R/89+9rP8ObLoSUQgIhARiAgE BFiLDDJnbh5iZymbnp6ebHQfiB7W9+UOIHkEckd488YjfYxFiQhEBCICEYH8QuAnP/lJmG3hB1OQ PQK5syEheIfUPdz3p7WUJV+vpP7ixYuhUfyICEQEIgIRgfxBAG6Go+FsD9ZZwoYyJET0Pj1DyO9K nhLNe0SPkTNnzuTP0UVPIgIRgYjAPY7Aj370o8DRwOAcTgpf+z51Ya0bJ3sieUgeBcT3qU+lUsLo Rx99FOriR0QgIhARiAh8dgjAxfb/RPRbv/VbYYVKIngCc4QoPjkzM5z5eSpDeN8/R0+eEQGCZ4P8 2T7/+c/rvffei2T/2Z3b2HNEICIQEQgc3NzcrLFjx4b5eYJzeBzehr8R9ikP3E4BGQr8qS0jga+E Rp56tvvvvz9E9g0NDXEaB+CiRAQiAhGBO4wAMyvf+c53QiT/G7/xG6F3+NsDcjgbIcKHt8OMTdr+ OTgVRPYo889HECd3Uh8V0CPPdu7cuZBy2/CFL3whdBrfsw/QxY+IQEQgInDbEICbOzs79eGHH4Z/ 6woPjxkzJhuMJ/mZTiF4dOBuonoGgGEnT54MRI8yzE8KYaPgyjRAPKWcWwTerf/pT3+avRP4xS9+ Edqjx+YjjLcj9VHGbWOXvG/JWw/qkNwybLC54DPiNsi7D+jhhx+P386g4/65Pu2xFYDpB4o6yhEv J+/2PaUdeu4bd0f4nfSTdi7oYs/bkyKUs7FP6sdGHfrYowzbSV+93O2gn8z7cXNu0aW9C/ven6fU s9FniAj6ffE+XQ8f3Zb77n6jix42riXJ46fe9WjPtcSbA+QR7yPsJD648+TY6Md98mrs4cPNrmf0 6Ic++FKxzzEjbtePgzryXpeLHeXY8g2brh8a2UduGTbYXPAZcRvk3Q/08CFez5lpiV/365lzTfDN dV5SUmL/RL5Uo0aNCteDX4t+fXlKOdcOHMQ79Vwz4WqmkEoKMcpFxMXo5Shy8bFPOULKbYPfOtDG L0I6wB46ntKWejbybg9bOEhZbj4U2Ae2seMH4jZ8H1uUJW1622SKPrZI+SKTR8jjKzb8+LBFnwjl tMntlzrKvS367gO23S7H5v4nj5P2YIWe9+XYYNfLyCPeNuwkPujT9cm7oE95burHxvEkxe24D6T4 4Cm66Ph5xTY2OAbK3Z7Xexl6nueChUwR7Hob9tFjAzts3nfffQMwp87b+Hl0jOiTevbZyLsN+maj rR8L+4iXo5tsjz0/L9Rh04+L1P3Af/JuB5vuZ26efQTf3Uf23QbtEGxRlrQZKnI+0Hcc8JU84tcd NvAVwRZ9IpTTNrdf6iinDXXouw/YdruOIbrkvR0pWDlu7Ds26Hr/5L0uZHI+6NP1ybtgy/tMpn5s +JwUt+M+kOKDp+ii4+cVm9jgGCh3e17vZeh5/k5cz0k/4Fvvn5TjoR5/OC58Je/XM/6FYz59+vSv qKARJ5OKJDAOBsbQyRWMeMfkXR9b7gRl7hR5nEDoi4vCnUKHfYQ8TnveDwQ//ERh331HH/E21GEL Xf8CkPdjc3Bonzw22mMLPU+xBTlRhq63dd+8L2zRF/WIY0C9CzYQ+qGc1PX9GEjZ3H90XJ/2Sd/I e79e5ynl9IEt8kmb+ICeC3kGelL8SdbRzvdJseXidaQcLxGWC2W+0Q5f2PyLBJFzXNhzX13P+3D7 2CRPuePv1yr9Uu7XDnl0KXcdyvwY3AY6uZLEizyCvp/L5Lny+ng9x+uZaySfr+cCLvbkF8i/DFzE XNxc2H5Be51/ObycffLJLw5feLfhX1700GGfDXDYXI/+EPYhAO/P9d1X33fyw4YLbb0d5Z6n3O2i S19ehx62IQXE7Xkb6pxEgoJ9sO8k5b6SItilLX1gizxl2EHHj4PUy9FBkj6Tpx8nXu/H25C6kPeN MmwnU+y7He8/KNgH/TCQcc6wkeuz23J912Hf/abMMcJPJ0Rvg03vlzr/n8Ruy+vYJ++YOabY8XJS 3yd1f5PllPnxooO9eD1fvdvxcwU2SLyeMxzy63o9F/iBkbL5F48vSlKcZFzPv4DoI+wnv4i57anz +tx+3CYXGzpJW9j2Lz95xPeTNumP/eQX3Ospow/2+fKTIu4j9uiTzXVJk/bcVmjY/4FO7vGz73YZ OLCJuC3q3RfyRIPJL53bow152rkN2rlf1DlxUe8Yel+kCHpJm17mNqnDps910h9lpEhy3+2QOpFj J6njPlHm5dhnox1+kib793Pix0e/2PFoHH1sIeQRdCnDrh+713m99+X9h4b9H/SPvrdN+oOKH1ey n2R7Pz5vjy3vx8vi9Xz1fIEdGIGbYw1OYEYZdX7tUO8Y0o56F/TYksK+2ySPzXg9Xw06wSpE9A6a g+4XsQPs4LKPDkJZcp88ZZwgL0eXMtdP7qPDifU6ThRfeD9hTiRe73Xui9vCDuJ9ep59dNFL1mEn We76pJCu15F6nX9h3Rbl1GPXj9fz3s7rPQ3G7AN9JFmO3Vyh3stJ2actKRsCVl7udZRTlmxDGYKP nroN9mnLRlTv5AoWYOV2sUfe9R1Tt+Mp9eSpJ6UNbbHlZd7Wy91m0gZlXB/ep+u6PfY5L/jsZW6H FEGHvpIb5fTjPqLjZe4X++Tdfy9H130kTe6jE6/nzPXlmAZg+z8cL3YdN84b5Y5pvJ4/veu5AHAB nI08mwsngAsYoT4pXudfiOQX2U8gtrj40fVbdWy4rvfLiU/2gz6b++PkwxebcvSpcyJKXljuJ/bI e53b95Ry2iPYwjZlTh704+29L9d3H2hLGfUI5Yjv0xf1pN4vdeixUeb9kqc/Uq/DHy/DrutQhg4p 9ih3XW9LHeLkQ96P2W2i6xv15PEXksemE63r+3GROhbUeZ/YoB1Cmfvg7aljy9WnDHuUs5FnS/pO Of67DbcTOuv/oAzf6I+NvPvsPqGDuG9hxz7cJ7dL/55Hl3psxes5Xs9cD1wbvvm1w7XkZfl2PYcn n0nnOAi/mCnnIPzA/Evh+1z4EBV65P2AyfuBQvB8Qdmod6GeMhfsILlfMHTwB7J3cSJye/iDHint EffFj4H65GDjBJv0mzauhw3y3gd2/Jgo8837Su5Thr4LecfU6+jf21CP70huig5l6IABPmHL92nD MXg79tFhn7bo4bffrVCfFHQdc8eOlHK347aTuthwv5L2yNMvPtG3b5S7Hcr8fHs/pLSjb/Q4Rm/j frDvx4QNbwMuyWvC+0za8nakuX77Pj7jF+2T1wV5bNE2Xs+Zaztez3fX9fz/AQDF4zitvYjVAAAA AElFTkSuQmCC --089e01160002d35017051b71f06d-- From nobody Wed Jul 22 00:49:15 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66BE91B2E23 for ; Wed, 22 Jul 2015 00:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xX-MBRGLUGiU for ; Wed, 22 Jul 2015 00:49:11 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c: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 12CE31B2E20 for ; Wed, 22 Jul 2015 00:49:11 -0700 (PDT) Received: by wicgb10 with SMTP id gb10so85635825wic.1 for ; Wed, 22 Jul 2015 00:49:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tjI9evj872dLfk4sXvyEgOETxBkdMxu/yXylnWD80hg=; b=RFfriQBCO9usyLFn3NlBUbzlVAoSPes2FV3JeU3bJNAhZhv4cBT0a1EqQ9lcDj6YHv TwD4Yt/x1soDaRE0pGFDOTDe3+GIYkbEy/S+AGV/izspJT4HfpCVnsJtJ9A3v8PdS/kE C3YVxwKr5x3m/WJgaQ+dKRJY/U/urgO2B0PpcQZQaqpiAKHFycXR0swC2SwQx9bHdQoU LOJmVYRGsKCoLYK9/i5n1m6cqd6mR3tJLe3Xu9FK74+cO2iuDv0/tymmyd+GfhRi8kdC bEpvkVkvjsA+NFujKdPbrDd3sO0AAA/jHE2Zv6ve/o5gErQ6GUctW3IOiJWrKsOQNV+L Yuhg== MIME-Version: 1.0 X-Received: by 10.180.95.67 with SMTP id di3mr3844172wib.78.1437551349842; Wed, 22 Jul 2015 00:49:09 -0700 (PDT) Received: by 10.28.31.194 with HTTP; Wed, 22 Jul 2015 00:49:09 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Jul 2015 03:49:09 -0400 Message-ID: From: Kathleen Moriarty To: Barry Leiba Content-Type: multipart/alternative; boundary=f46d044287e28dc7eb051b7201f1 Archived-At: Cc: oauth WG Subject: Re: [OAUTH-WG] OAuth implementation fail X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 07:49:13 -0000 --f46d044287e28dc7eb051b7201f1 Content-Type: text/plain; charset=UTF-8 Hey Barry, >From my observations with Facebook, it now has options added for you to select what resources from Facebook will get shared when authorizing access to other applications. You can click on each of the possibilities and strip it down. It appears to me that Facebook is managing that, so in your case, I *think* (and am open to be corrected) that LinkedIn needs to do something similar. Without those options, I also cancel out and just don't use the other app. Thanks, Kathleen On Wed, Jul 22, 2015 at 3:44 AM, Barry Leiba wrote: > Yesterday, someone sent me a link to some presentation slides that > he'd posted to SlideShare. I looked at them, and wanted to download > them as a PDF. In order to let me do that, SlideShare wants me to log > in. It gives me the options to log in via LinkedIn or Facebook. As > I'm one of the three people in the world without a Facebook account, I > clicked "LinkedIn". That got me an OAuth authorization screen, image > attached. > > Now, I don't know if this is SlideShare's fault for asking for too > much, or LinkedIn's fault for not providing enough granularity for > requests, but just LOOK at that list of what I'd be giving SlideShare > access to. The first few make sense: read my profile (the whole thing > or pieces of it, including contact information). But... access to my > connections? I'm not sure they'd like my exposing their identities to > SlideShare. Access to my private messages? EDIT MY PROFILE? Srsly? > > Of course, this isn't the fault of the OAuth protocol, really (though > one might argue that there's not enough guidance provided). But, > really, with implementations like this, I have to wonder what they're > thinking. > > I clicked "Cancel", of course, and asked the slide creator to send me a > PDF. > > Barry > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Best regards, Kathleen --f46d044287e28dc7eb051b7201f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Barry,

From my observations with Fa= cebook, it now has options added for you to select what resources from Face= book will get shared when authorizing access to other applications.=C2=A0 Y= ou can click on each of the possibilities and strip it down.=C2=A0 It appea= rs to me that Facebook is managing that, so in your case, I *think* (and am= open to be corrected) that LinkedIn needs to do something similar.=C2=A0 W= ithout those options, I also cancel out and just don't use the other ap= p. =C2=A0

Thanks,
Kathleen

On Wed, Jul 22, 201= 5 at 3:44 AM, Barry Leiba <barryleiba@computer.org> wr= ote:
Yesterday, someone sent me a link to= some presentation slides that
he'd posted to SlideShare.=C2=A0 I looked at them, and wanted to downlo= ad
them as a PDF.=C2=A0 In order to let me do that, SlideShare wants me to log=
in.=C2=A0 It gives me the options to log in via LinkedIn or Facebook.=C2=A0= As
I'm one of the three people in the world without a Facebook account, I<= br> clicked "LinkedIn".=C2=A0 That got me an OAuth authorization scre= en, image
attached.

Now, I don't know if this is SlideShare's fault for asking for too<= br> much, or LinkedIn's fault for not providing enough granularity for
requests, but just LOOK at that list of what I'd be giving SlideShare access to.=C2=A0 The first few make sense: read my profile (the whole thing=
or pieces of it, including contact information).=C2=A0 But... access to my<= br> connections?=C2=A0 I'm not sure they'd like my exposing their ident= ities to
SlideShare.=C2=A0 Access to my private messages?=C2=A0 EDIT MY PROFILE?=C2= =A0 Srsly?

Of course, this isn't the fault of the OAuth protocol, really (though one might argue that there's not enough guidance provided).=C2=A0 But,<= br> really, with implementations like this, I have to wonder what they're thinking.

I clicked "Cancel", of course, and asked the slide creator to sen= d me a PDF.

Barry

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




--

Best regards,
Ka= thleen
--f46d044287e28dc7eb051b7201f1-- From nobody Wed Jul 22 01:06:21 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B559C1B304F for ; Wed, 22 Jul 2015 01:06:19 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZWKYqQbMawp for ; Wed, 22 Jul 2015 01:06:17 -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 6840C1B3028 for ; Wed, 22 Jul 2015 01:06:17 -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 t6M86AjH004355 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 Jul 2015 08:06:10 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 t6M86AB9021665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 22 Jul 2015 08:06:10 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t6M869Rl010368; Wed, 22 Jul 2015 08:06:09 GMT Received: from dhcp-b455.meeting.ietf.org (/31.133.180.85) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 22 Jul 2015 01:06:09 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_DA371F99-DC17-447A-ADA8-5D8683E17B31" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Phil Hunt In-Reply-To: Date: Wed, 22 Jul 2015 10:06:07 +0200 Message-Id: <7A9F55CC-2A34-4008-8B93-69F7911BFFE7@oracle.com> References: To: Kathleen Moriarty X-Mailer: Apple Mail (2.2102) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: Barry Leiba , "" Subject: Re: [OAUTH-WG] OAuth implementation fail X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 08:06:19 -0000 --Apple-Mail=_DA371F99-DC17-447A-ADA8-5D8683E17B31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Interesting. A couple of possible issues (and of course I am = speculating here): 1. Using OAuth for authentication (does LinkedIn support OIDC?) 2. Not asking for the minimum information needed (either by omission or = by intent) I am really speculating now, but wonder if Slideshare didn=E2=80=99t = actually want anything from LinkedIn, they just wanted to authenticate = you. It may be that LinkedIn didn=E2=80=99t provide a scope and LinkedIn = defaults this to =E2=80=9Ceverything=E2=80=9D. If true, this would seem = to be a bad practice since it has the unintended consequence of = defaulting to all scopes. The whole process failed to convert you into a user since your = experience was bad and asked for inappropriate access. =20 It would be interesting to find out more of the facts around this.=20 Phil @independentid www.independentid.com phil.hunt@oracle.com > On Jul 22, 2015, at 9:49 AM, Kathleen Moriarty = wrote: >=20 > Hey Barry, >=20 > =46rom my observations with Facebook, it now has options added for you = to select what resources from Facebook will get shared when authorizing = access to other applications. You can click on each of the = possibilities and strip it down. It appears to me that Facebook is = managing that, so in your case, I *think* (and am open to be corrected) = that LinkedIn needs to do something similar. Without those options, I = also cancel out and just don't use the other app. =20 >=20 > Thanks, > Kathleen >=20 > On Wed, Jul 22, 2015 at 3:44 AM, Barry Leiba > wrote: > Yesterday, someone sent me a link to some presentation slides that > he'd posted to SlideShare. I looked at them, and wanted to download > them as a PDF. In order to let me do that, SlideShare wants me to log > in. It gives me the options to log in via LinkedIn or Facebook. As > I'm one of the three people in the world without a Facebook account, I > clicked "LinkedIn". That got me an OAuth authorization screen, image > attached. >=20 > Now, I don't know if this is SlideShare's fault for asking for too > much, or LinkedIn's fault for not providing enough granularity for > requests, but just LOOK at that list of what I'd be giving SlideShare > access to. The first few make sense: read my profile (the whole thing > or pieces of it, including contact information). But... access to my > connections? I'm not sure they'd like my exposing their identities to > SlideShare. Access to my private messages? EDIT MY PROFILE? Srsly? >=20 > Of course, this isn't the fault of the OAuth protocol, really (though > one might argue that there's not enough guidance provided). But, > really, with implementations like this, I have to wonder what they're > thinking. >=20 > I clicked "Cancel", of course, and asked the slide creator to send me = a PDF. >=20 > Barry >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_DA371F99-DC17-447A-ADA8-5D8683E17B31 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Interesting.  A = couple of possible issues (and of course I am speculating here):

1. Using OAuth for = authentication (does LinkedIn support OIDC?)
2. Not = asking for the minimum information needed (either by omission or by = intent)

I am = really speculating now, but wonder if Slideshare didn=E2=80=99t actually = want anything from LinkedIn, they just wanted to authenticate you. It = may be that LinkedIn didn=E2=80=99t provide a scope and LinkedIn = defaults this to =E2=80=9Ceverything=E2=80=9D. If true, this would seem = to be a bad practice since it has the unintended consequence of = defaulting to all scopes.

The whole process failed to convert you into a user since = your experience was bad and asked for inappropriate access. =  

It = would be interesting to find out more of the facts around = this. 


On Jul 22, 2015, at 9:49 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Hey Barry,

=46rom my observations with Facebook, it now has options = added for you to select what resources from Facebook will get shared = when authorizing access to other applications.  You can click on = each of the possibilities and strip it down.  It appears to me that = Facebook is managing that, so in your case, I *think* (and am open to be = corrected) that LinkedIn needs to do something similar.  Without = those options, I also cancel out and just don't use the other app. =  

Thanks,
Kathleen

On Wed, = Jul 22, 2015 at 3:44 AM, Barry Leiba <barryleiba@computer.org> wrote:
Yesterday, someone = sent me a link to some presentation slides that
he'd posted to SlideShare.  I looked at them, and wanted to = download
them as a PDF.  In order to let me do that, SlideShare wants me to = log
in.  It gives me the options to log in via LinkedIn or = Facebook.  As
I'm one of the three people in the world without a Facebook account, = I
clicked "LinkedIn".  That got me an OAuth authorization screen, = image
attached.

Now, I don't know if this is SlideShare's fault for asking for too
much, or LinkedIn's fault for not providing enough granularity for
requests, but just LOOK at that list of what I'd be giving SlideShare
access to.  The first few make sense: read my profile (the whole = thing
or pieces of it, including contact information).  But... access to = my
connections?  I'm not sure they'd like my exposing their identities = to
SlideShare.  Access to my private messages?  EDIT MY = PROFILE?  Srsly?

Of course, this isn't the fault of the OAuth protocol, really (though
one might argue that there's not enough guidance provided).  = But,
really, with implementations like this, I have to wonder what they're
thinking.

I clicked "Cancel", of course, and asked the slide creator to send me a = PDF.

Barry

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




--

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

= --Apple-Mail=_DA371F99-DC17-447A-ADA8-5D8683E17B31-- From nobody Wed Jul 22 01:22:48 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673371A009D for ; Wed, 22 Jul 2015 01:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cC5Rf2YVhybC for ; Wed, 22 Jul 2015 01:22:41 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BDBB1A0137 for ; Wed, 22 Jul 2015 01:22:41 -0700 (PDT) X-AuditID: 1209190c-f79296d000000622-8c-55af52cf3717 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 2D.8C.01570.FC25FA55; Wed, 22 Jul 2015 04:22:39 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t6M8Mcc1007763; Wed, 22 Jul 2015 04:22:39 -0400 Received: from dhcp-b0b7.meeting.ietf.org (dhcp-b0b7.meeting.ietf.org [31.133.176.183]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t6M8MOmG019554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Jul 2015 04:22:35 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_36CA2DAB-4ADA-4F36-9836-C8306A759D24" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Justin Richer In-Reply-To: Date: Wed, 22 Jul 2015 10:22:24 +0200 Message-Id: <84019235-22F4-4BBA-8A45-558E7C65D5D1@mit.edu> References: To: Kathleen Moriarty X-Mailer: Apple Mail (2.2102) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBKsWRmVeSWpSXmKPExsUixCmqrHs+aH2oQdNdTYtDiy+xWjTszLc4 +fYVmwOzR8uqXmaPnbPusnssWfKTKYA5issmJTUnsyy1SN8ugSvj8G3tgjUuFa/aNRsY/1t2 MXJySAiYSJzYcIgZwhaTuHBvPVsXIxeHkMBiJok97z6wQDgbGSUm354M5Vxhkuj+dpsdpIVZ IEFi3RuIdl4BPYmec18YQWxhAUOJtXMnsoDYbAKqEtPXtDCB2JwCgRLrOu+D1bMAxZe+esoC McdP4sfFk4wQc6wk9s1ZxQpiCwlMZZToaHIFsUUELCTWNH9jgzhVVmLrm1amCYwCs5CcMQvJ GRBxbYllC18zQ9iaEvu7l7NgimtIdH6byLqAkW0Vo2xKbpVubmJmTnFqsm5xcmJeXmqRrqFe bmaJXmpK6SZGcARI8uxgfHNQ6RCjAAejEg/vhKPrQoVYE8uKK3MPMUpyMCmJ8uoFrg8V4kvK T6nMSCzOiC8qzUktPsQowcGsJMKrzA2U401JrKxKLcqHSUlzsCiJ8276wRciJJCeWJKanZpa kFoEk5Xh4FCS4N0GMlSwKDU9tSItM6cEIc3EwQkynAdo+EmQGt7igsTc4sx0iPwpRkUpcd5Z IAkBkERGaR5cLyxBvWIUB3pFmLcBpIoHmNzgul8BDWYCGnxr1hqQwSWJCCmpBkbH/JNdSqdP hn27rr9/nvWFrPmcIpcmpT85WfJp4+2ujuunxb+kd0w9r/ZsqXXI0qdVKmcLPCQen1d/X8q8 r+HCPoblVf2/1md66gtl5LH5Ms5d8LnUrftwv7uRTYnP45+LDZakb4+b87GH5aaolVfEc/uj 7vdEM/OYGX0ad26+98r54hnurM1KLMUZiYZazEXFiQCx6ZEeKwMAAA== Archived-At: Cc: Barry Leiba , "" Subject: Re: [OAUTH-WG] OAuth implementation fail X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 08:22:46 -0000 --Apple-Mail=_36CA2DAB-4ADA-4F36-9836-C8306A759D24 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is a pretty clear case of SlideShare trying to grab too much. The = LinkedIn API (which is their own proprietary thing, not OpenID Connect) = does separate all the permissions into different scopes. However, the = SlideShare app is asking for all of them, and LinkedIn doesn=E2=80=99t = let you uncheck any boxes on the authorization screen.=20 FWIW, the reason they want write access to your profile is to = automatically add new SlideShare presentations that you upload to your = LinkedIn profile page. You should still have the option of turning that = off, or of turning on that functionality later. =E2=80=94 Justin > On Jul 22, 2015, at 9:49 AM, Kathleen Moriarty = wrote: >=20 > Hey Barry, >=20 > =46rom my observations with Facebook, it now has options added for you = to select what resources from Facebook will get shared when authorizing = access to other applications. You can click on each of the = possibilities and strip it down. It appears to me that Facebook is = managing that, so in your case, I *think* (and am open to be corrected) = that LinkedIn needs to do something similar. Without those options, I = also cancel out and just don't use the other app. =20 >=20 > Thanks, > Kathleen >=20 > On Wed, Jul 22, 2015 at 3:44 AM, Barry Leiba > wrote: > Yesterday, someone sent me a link to some presentation slides that > he'd posted to SlideShare. I looked at them, and wanted to download > them as a PDF. In order to let me do that, SlideShare wants me to log > in. It gives me the options to log in via LinkedIn or Facebook. As > I'm one of the three people in the world without a Facebook account, I > clicked "LinkedIn". That got me an OAuth authorization screen, image > attached. >=20 > Now, I don't know if this is SlideShare's fault for asking for too > much, or LinkedIn's fault for not providing enough granularity for > requests, but just LOOK at that list of what I'd be giving SlideShare > access to. The first few make sense: read my profile (the whole thing > or pieces of it, including contact information). But... access to my > connections? I'm not sure they'd like my exposing their identities to > SlideShare. Access to my private messages? EDIT MY PROFILE? Srsly? >=20 > Of course, this isn't the fault of the OAuth protocol, really (though > one might argue that there's not enough guidance provided). But, > really, with implementations like this, I have to wonder what they're > thinking. >=20 > I clicked "Cancel", of course, and asked the slide creator to send me = a PDF. >=20 > Barry >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_36CA2DAB-4ADA-4F36-9836-C8306A759D24 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This is a pretty clear case of SlideShare trying to grab too = much. The LinkedIn API (which is their own proprietary thing, not OpenID = Connect) does separate all the permissions into different scopes. = However, the SlideShare app is asking for all of them, and LinkedIn = doesn=E2=80=99t let you uncheck any boxes on the authorization = screen. 

FWIW, = the reason they want write access to your profile is to automatically = add new SlideShare presentations that you upload to your LinkedIn = profile page. You should still have the option of turning that off, or = of turning on that functionality later.

 =E2=80=94 Justin

On Jul 22, 2015, at 9:49 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Hey Barry,

=46rom my observations with Facebook, = it now has options added for you to select what resources from Facebook = will get shared when authorizing access to other applications.  You = can click on each of the possibilities and strip it down.  It = appears to me that Facebook is managing that, so in your case, I *think* = (and am open to be corrected) that LinkedIn needs to do something = similar.  Without those options, I also cancel out and just don't = use the other app.  

Thanks,
Kathleen

On Wed, = Jul 22, 2015 at 3:44 AM, Barry Leiba <barryleiba@computer.org> wrote:
Yesterday, someone = sent me a link to some presentation slides that
he'd posted to SlideShare.  I looked at them, and wanted to = download
them as a PDF.  In order to let me do that, SlideShare wants me to = log
in.  It gives me the options to log in via LinkedIn or = Facebook.  As
I'm one of the three people in the world without a Facebook account, = I
clicked "LinkedIn".  That got me an OAuth authorization screen, = image
attached.

Now, I don't know if this is SlideShare's fault for asking for too
much, or LinkedIn's fault for not providing enough granularity for
requests, but just LOOK at that list of what I'd be giving SlideShare
access to.  The first few make sense: read my profile (the whole = thing
or pieces of it, including contact information).  But... access to = my
connections?  I'm not sure they'd like my exposing their identities = to
SlideShare.  Access to my private messages?  EDIT MY = PROFILE?  Srsly?

Of course, this isn't the fault of the OAuth protocol, really (though
one might argue that there's not enough guidance provided).  = But,
really, with implementations like this, I have to wonder what they're
thinking.

I clicked "Cancel", of course, and asked the slide creator to send me a = PDF.

Barry

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




--

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

= --Apple-Mail=_36CA2DAB-4ADA-4F36-9836-C8306A759D24-- From nobody Wed Jul 22 01:32:55 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71781ACE63 for ; Wed, 22 Jul 2015 01:32:53 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwrZWyvPO9z0 for ; Wed, 22 Jul 2015 01:32:51 -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 1D8531ACE4F for ; Wed, 22 Jul 2015 01:32:31 -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 t6M8WRFA031860 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 Jul 2015 08:32:28 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 t6M8WR5r032173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 22 Jul 2015 08:32:27 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t6M8WQYa021384; Wed, 22 Jul 2015 08:32:27 GMT Received: from [31.133.177.166] (/31.133.177.166) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 22 Jul 2015 01:32:26 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-23B539DE-DED8-4207-AC9D-350A832DCD77 Content-Transfer-Encoding: 7bit From: Phil Hunt Mime-Version: 1.0 (1.0) Date: Wed, 22 Jul 2015 10:26:41 +0200 Message-Id: References: <84019235-22F4-4BBA-8A45-558E7C65D5D1@mit.edu> In-Reply-To: <84019235-22F4-4BBA-8A45-558E7C65D5D1@mit.edu> To: Justin Richer X-Mailer: iPhone Mail (12F70) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: Barry Leiba , "" Subject: Re: [OAUTH-WG] OAuth implementation fail X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 08:32:54 -0000 --Apple-Mail-23B539DE-DED8-4207-AC9D-350A832DCD77 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Do they explicitly ask for those scopes? Or do they leave scope to default t= hat way.=20 Phil > On Jul 22, 2015, at 10:22, Justin Richer wrote: >=20 > This is a pretty clear case of SlideShare trying to grab too much. The Lin= kedIn API (which is their own proprietary thing, not OpenID Connect) does se= parate all the permissions into different scopes. However, the SlideShare ap= p is asking for all of them, and LinkedIn doesn=E2=80=99t let you uncheck an= y boxes on the authorization screen.=20 >=20 > FWIW, the reason they want write access to your profile is to automaticall= y add new SlideShare presentations that you upload to your LinkedIn profile p= age. You should still have the option of turning that off, or of turning on t= hat functionality later. >=20 > =E2=80=94 Justin >=20 >> On Jul 22, 2015, at 9:49 AM, Kathleen Moriarty wrote: >>=20 >> Hey Barry, >>=20 >> =46rom my observations with Facebook, it now has options added for you to= select what resources from Facebook will get shared when authorizing access= to other applications. You can click on each of the possibilities and stri= p it down. It appears to me that Facebook is managing that, so in your case= , I *think* (and am open to be corrected) that LinkedIn needs to do somethin= g similar. Without those options, I also cancel out and just don't use the o= ther app. =20 >>=20 >> Thanks, >> Kathleen >>=20 >>> On Wed, Jul 22, 2015 at 3:44 AM, Barry Leiba w= rote: >>> Yesterday, someone sent me a link to some presentation slides that >>> he'd posted to SlideShare. I looked at them, and wanted to download >>> them as a PDF. In order to let me do that, SlideShare wants me to log >>> in. It gives me the options to log in via LinkedIn or Facebook. As >>> I'm one of the three people in the world without a Facebook account, I >>> clicked "LinkedIn". That got me an OAuth authorization screen, image >>> attached. >>>=20 >>> Now, I don't know if this is SlideShare's fault for asking for too >>> much, or LinkedIn's fault for not providing enough granularity for >>> requests, but just LOOK at that list of what I'd be giving SlideShare >>> access to. The first few make sense: read my profile (the whole thing >>> or pieces of it, including contact information). But... access to my >>> connections? I'm not sure they'd like my exposing their identities to >>> SlideShare. Access to my private messages? EDIT MY PROFILE? Srsly? >>>=20 >>> Of course, this isn't the fault of the OAuth protocol, really (though >>> one might argue that there's not enough guidance provided). But, >>> really, with implementations like this, I have to wonder what they're >>> thinking. >>>=20 >>> I clicked "Cancel", of course, and asked the slide creator to send me a P= DF. >>>=20 >>> Barry >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> --=20 >>=20 >> Best regards, >> Kathleen >> _______________________________________________ >> 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-23B539DE-DED8-4207-AC9D-350A832DCD77 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Do they explicitly ask for those scope= s? Or do they leave scope to default that way. 

Phil
<= br>On Jul 22, 2015, at 10:22, Justin Richer <jricher@mit.edu> wrote:

This is a pretty clear case of SlideShare trying to grab too much. The Lin= kedIn API (which is their own proprietary thing, not OpenID Connect) does se= parate all the permissions into different scopes. However, the SlideShare ap= p is asking for all of them, and LinkedIn doesn=E2=80=99t let you uncheck an= y boxes on the authorization screen. 

FWIW, the reason they want write access to your profile i= s to automatically add new SlideShare presentations that you upload to your L= inkedIn profile page. You should still have the option of turning that off, o= r of turning on that functionality later.

 =E2=80=94 Justin

On Jul 22, 2= 015, at 9:49 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
Hey Barry,

=46rom my observations with Facebook, it now has options added for you to= select what resources from Facebook will get shared when authorizing access= to other applications.  You can click on each of the possibilities and= strip it down.  It appears to me that Facebook is managing that, so in= your case, I *think* (and am open to be corrected) that LinkedIn needs to d= o something similar.  Without those options, I also cancel out and just= don't use the other app.  

<= div class=3D"">Thanks,
Kathleen

On Wed, Jul 22, 2015= at 3:44 AM, Barry Leiba <barryleiba@computer.or= g> wrote:
Yesterda= y, someone sent me a link to some presentation slides that
he'd posted to SlideShare.  I looked at them, and wanted to download them as a PDF.  In order to let me do that, SlideShare wants me to log<= br class=3D""> in.  It gives me the options to log in via LinkedIn or Facebook.  A= s
I'm one of the three people in the world without a Facebook account, I
clicked "LinkedIn".  That got me an OAuth authorization screen, image attached.

Now, I don't know if this is SlideShare's fault for asking for too
much, or LinkedIn's fault for not providing enough granularity for
requests, but just LOOK at that list of what I'd be giving SlideShare
access to.  The first few make sense: read my profile (the whole thing<= br class=3D""> or pieces of it, including contact information).  But... access to my connections?  I'm not sure they'd like my exposing their identities to<= br class=3D""> SlideShare.  Access to my private messages?  EDIT MY PROFILE? = ; Srsly?

Of course, this isn't the fault of the OAuth protocol, really (though
one might argue that there's not enough guidance provided).  But,
really, with implementations like this, I have to wonder what they're
thinking.

I clicked "Cancel", of course, and asked the slide creator to send me a PDF.=

Barry

_______________________________________________=
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<= br class=3D"">



--

Best r= egards,
Kathleen
_______________________________________________
OAuth mailing l= ist
OAuth@ietf.or= g
= https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
= OAuth mailing list
OAuth@i= etf.org
https://www.ietf.org/mailman/listinfo/oauth
= --Apple-Mail-23B539DE-DED8-4207-AC9D-350A832DCD77-- From nobody Wed Jul 22 01:35:55 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 491991ACE78; Wed, 22 Jul 2015 01:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNHz98Y_8FPW; Wed, 22 Jul 2015 01:35:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D4CB91ACE8B; Wed, 22 Jul 2015 01:35:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.1.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150722083540.20048.48300.idtracker@ietfa.amsl.com> Date: Wed, 22 Jul 2015 01:35:40 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 08:35:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : OAuth 2.0 JWT Authorization Request Authors : Nat Sakimura John Bradley Filename : draft-ietf-oauth-jwsreq-05.txt Pages : 15 Date : 2015-07-22 Abstract: The authorization request in OAuth 2.0 utilizes query parameter serialization. This specification defines the authorization request using JWT serialization. The request is sent through "request" parameter or by reference through "request_uri" parameter that points to the JWT, allowing the request to be optionally signed and encrypted. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 22 01:42:52 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D041A21A8 for ; Wed, 22 Jul 2015 01:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1CMoE6M-lco for ; Wed, 22 Jul 2015 01:42:48 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::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 773F61A0026 for ; Wed, 22 Jul 2015 01:42:47 -0700 (PDT) Received: by lahh5 with SMTP id h5so133624456lah.2 for ; Wed, 22 Jul 2015 01:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=GpC6U3hGrWMgO3fhJ89ek0Al3yl32rj8aqzYqGJ7Bis=; b=xvJEtUD2xDwwU6nXrMtr4/zfzm1To5uWzMniy+XZoAOB4OYfrfZnnVRGTuMjNzZ4B3 uimPkfzWWCSW8qLgVO7OIvglC+JFtV264O0QprZtN44eUI0/KMMBYOjlMkD3WQS5TpfW m+fXCkQXAThVQmavgZj/q9CedzaTmRpJigJkaaH3+lHmqni8477PBUJjs+eKMjSeyvy4 oho9sy23GeGrWI9dw9cqap8ZpVsqAbCllQaDFTF9vbdPIg8yZ2nxoLLtHxB3hdI5oIsD ocm274OdOSKK95zxNf2t4U3dfXnYdec5HPLyf/AXQLLa1mvGVA+rj9UAN31av/Mh/rfs U/xQ== X-Received: by 10.112.147.8 with SMTP id tg8mr1280933lbb.62.1437554565862; Wed, 22 Jul 2015 01:42:45 -0700 (PDT) Received: from [10.39.0.31] ([87.252.227.91]) by smtp.googlemail.com with ESMTPSA id j1sm158385lbc.15.2015.07.22.01.42.45 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Jul 2015 01:42:45 -0700 (PDT) Message-ID: <55AF5784.6020701@gmail.com> Date: Wed, 22 Jul 2015 11:42:44 +0300 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: oauth@ietf.org References: <0F2B6432-4D9E-4277-BFFE-5F0354A6D9B7@mit.edu> <89B75723-0C59-4AF3-BC8E-166A63ED39EB@mit.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OAUTH-WG] Token introspection for public clients? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 08:42:51 -0000 Hi Would there be any sense at all to have a new endpoint dedicated to supporting public clients only for these clients be able to do the extra validation which only public clients may need, etc, etc. Or perhaps let the access token endpoint not only exchange grants but also do some optional follow-up validation of the token properties for public clients given that the access token endpoint can support public clients and is dedicated to working with the clients. Purely from a technical point of view it seems not a big deal to relax it back to SHOULD, but I wonder if having the introspection endpoint supporting different roles (public clients, resource servers, with some requiring the auth and some not) would make it more difficult to do the extra work for getting PoP token introspection supported, etc... My 2c, thanks, Sergey On 22/07/15 02:05, William Denniss wrote: > We had a good sync on this topic offline on Monday, and it seemed the > consensus was that if clients need to introspect access tokens they are > doing something wrong. > > That said, looking only at the resource server use-case, I still think > the MUST is problematic. > > The out of band authentication requirement when accompanied with the > MUST makes the spec less useful. i.e. "the endpoint MUST also require > some form of authorization to access this endpoint", but "The specifics > of this authentication credentials are out of scope of this > specification". This makes dynamic discovery which was mentioned as > potentially applying to this spec virtually useless (you discovered the > introspection endpoint, but how do you discover how to authenticate?). > It also adds to general implementation complexity. > > Brian mentioned that in their implementation, they decided not to force > authentication for introspection by resource servers as they were > protecting the endpoint through other means, and wanted to reduce > complexity for developers. The MUST here constrains that decision, one > which I think should be left up to the provider. > > Lastly, the MUST is presented in the spec as being required to prevent > token scanning, and yet there are other ways to mitigate that attack. If > there are better reasons than token scanning for this remaining a MUST, > then I think the spec should document them. > > Side note: If you prevent token scanning through other means, the main > benefit of still requiring authentication seems to be preventing > information leaking out to a client who is in possession of the access > token but isn't the intended audience. This may or may not be an issue > depending on the contents of the introspection response. Perhaps it > would be good to mention this in the security considerations, as it's > something that should be considered by implementors. Given the > sensitivity of information revealed by the introspection endpoint > varies, I don't think that this alone would mandate the MUST. > > > > On Tue, Jul 21, 2015 at 10:03 AM, Justin Richer > wrote: > > Just use the token at your target API and see if it works. Your > client’s going to need to be able to get a new token if this one > expires mid-session anyway, so you’re not saving anything by doing > an introspection request. > > — Justin > >> On Jul 20, 2015, at 9:34 PM, Aaron Parecki > > wrote: >> >> I'm looking for a way to check if an existing token is still >> valid. Imagine a client is holding on to a token between user >> sessions, for example if it's making API requests for the user on >> a cron job. When the user returns to the site, I want to check if >> the token is still valid, and make them sign in again if not. >> >> Aaron >> >> On Mon, Jul 20, 2015 at 12:11 PM John Bradley > > wrote: >> >> If you want the resource owner/user then get a id_token from >> the token endpoint. That saves another call to a >> introspection endpoint. >> >> Sent from my iPhone >> >> On Jul 20, 2015, at 7:49 PM, Aaron Parecki > > wrote: >> >>> Okay, if the intent is for this endpoint to be used by the >>> resource server, this all makes sense. I was under the >>> impression that it could also be used by clients to verify if >>> the token is valid. Is there some other spec I could look at >>> that is intended to be used by clients to verify if a token >>> is valid and find out the user ID associated with it? >>> >>> ---- >>> Aaron Parecki >>> aaronparecki.com >>> @aaronpk >>> >>> >>> On Sun, Jul 19, 2015 at 10:01 PM, Justin Richer >>> > wrote: >>> >>> Because the target isn’t the client, it’s the protected >>> resource. We’re re-using OAuth’s client credentialing >>> mechanisms (optionally, you can use whatever you deem >>> necessary), but it’s not a client that’s doing it. That’s >>> why it was changed to a MUST — there may be public >>> clients out there (which could also use RFC7591 to become >>> non-public), but public resource servers don’t make >>> nearly as much sense. >>> >>> Additionally, the discussion for this was back in >>> December during the WGLC, and the time for normative >>> changes to this particular spec is largely over at this >>> stage. >>> >>> — Justin >>> >>>> On Jul 20, 2015, at 12:03 AM, William Denniss >>>> > wrote: >>>> >>>> I see in earlier drafts that client authentication MUST >>>> was a SHOULD. >>>> >>>> Why not put it back to a SHOULD, and make these >>>> arguments in the Security Considerations? By the sound >>>> of it in some implementations there are good reasons for >>>> doing client authentication, but they may not apply to >>>> everyone, so do we need to be so prescriptive? An error >>>> response can be added for requests the server deems >>>> require client authentication. >>>> >>>> It wouldn't have to be an all-or-nothing policy choice >>>> either, a server could chose to reject requests from >>>> confidential clients where client authentication is not >>>> provided, but accept requests without client >>>> authentication from non-confidential clients. A server >>>> that has sufficiently high entropy in the tokens, abuse >>>> protection on the endpoint, and is not concerned about >>>> an unrelated party (that happens to have a token >>>> intended for a different party) learning the token >>>> metadata, could simply not require any client >>>> authentication at all. >>>> >>>> Apart from anything, it is really trivial to support >>>> non-confidential client usage, so why not? Perhaps >>>> there are some use-cases that will turn up in the future >>>> (especially since as defined the introspection response >>>> is extensible). One I can think of now is debugging: >>>> it's useful during development to be able to inspect the >>>> tokens you get back from the AS. >>>> >>>> Best, >>>> William >>>> >>>> >>>> On Sun, Jul 19, 2015 at 9:14 PM, Justin Richer >>>> > wrote: >>>> >>>> In the case of a “public client” using a token, the >>>> authorization is the token that the resource server >>>> uses to call the introspection endpoint, along side >>>> the token that it is introspecting. This is exactly >>>> how the UMA protocol works: the resource server has >>>> a “Protection API Token” that it uses to call >>>> several endpoints at the AS, including the >>>> introspection endpoint. In UMA, this PAT is given to >>>> the resource server through a normal OAuth >>>> transaction with an end user who facilitates the >>>> RS->AS introduction. >>>> >>>> And I think this is all actually a moot point >>>> because *clients* shouldn’t be doing the >>>> introspection in the first place — the whole spec is >>>> there to support *resource servers* introspecting at >>>> the auth server. So you probably don’t have “public >>>> client resource servers” out there. We simply >>>> re-used OAuth’s existing client authentication >>>> mechanism, that doesn’t make them clients. This >>>> decision is based on development and deployment >>>> experience (as in, several people independently >>>> built it exactly this way). Do you have a use case >>>> where you’ve got a protected resource that can’t >>>> hold credentials (either a client secret or a >>>> public/private keypair) to authenticate with, and >>>> can’t be introduced using OAuth to the AS as in UMA? >>>> >>>> To your other point: An attacker has less of a >>>> chance of getting information about a token by >>>> fishing at a protected resource with tokens, since >>>> they’re not being returned information about the >>>> token other than the fact that the token worked. (Or >>>> at least it seemed to work because a result came >>>> back — you could easily give a suspected attacker >>>> valid-looking-but-fake data as one mitigation >>>> mechanism.) The introspection response can give you >>>> information about where else the token could be >>>> used, potentially. Additionally, the RS really ought >>>> to be preventing data-fishing attacks like this just >>>> for its own sake anyway. There are lots of >>>> techniques for doing this, but they tend to be >>>> specific to the kind of API that’s being served. >>>> >>>> Requiring the resource server to authenticate with >>>> the authorization server also allows you to do a few >>>> other useful things. Our implementation, for >>>> example, limits the token information that is >>>> returned to a particular AS. This allows us to have >>>> tokens that can be used in multiple RS’s without >>>> those RS’s ever even knowing the token is powerful >>>> enough to be used elsewhere. It prevents information >>>> about the authorization from leaking to parties who >>>> have no business knowing. >>>> >>>> Hope this helps clarify it, >>>> — Justin >>>> >>>>> On Jul 19, 2015, at 7:59 PM, Aaron Parecki >>>>> > wrote: >>>>> >>>>> How are public clients supposed to authenticate if >>>>> there is no secret? >>>>> >>>>> Isn't "fishing for valid tokens" just as much of an >>>>> issue at the resource server? I don't see how >>>>> having the introspection endpoint require client >>>>> authentication actually solves the fishing problem >>>>> since attackers could just fish against the >>>>> resource server. In fact, if the resource server >>>>> queries the introspection endpoint to check if >>>>> tokens are valid, then that effectively gives an >>>>> attacker a way to fish for tokens using the >>>>> resource server's credentials. >>>>> >>>>> --- >>>>> Aaron Parecki >>>>> http://aaronparecki.com >>>>> >>>>> On Sat, Jul 18, 2015 at 10:04 PM Justin Richer >>>>> > wrote: >>>>> >>>>> Public clients can use the token-based auth >>>>> mechanism, can’t they? If you don’t have some >>>>> form of authentication on the introspection >>>>> endpoint, you end up with a way for people to >>>>> anonymously and programmatically fish for valid >>>>> token values. >>>>> >>>>> — Justin >>>>> >>>>>> On Jul 19, 2015, at 6:30 AM, Aaron Parecki >>>>>> > >>>>>> wrote: >>>>>> >>>>>> The introspection draft states that the >>>>>> introspection endpoint MUST require >>>>>> authentication of clients. It mentions either >>>>>> client authentication (id+secret) or a >>>>>> separate bearer token. >>>>>> >>>>>> How are public clients expected to use the >>>>>> token introspection endpoint? I didn't see a >>>>>> note in the document about that at all. >>>>>> >>>>>> ---- >>>>>> Aaron Parecki >>>>>> aaronparecki.com >>>>>> @aaronpk >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@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/ Blog: http://sberyozkin.blogspot.com From nobody Wed Jul 22 01:59:32 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7CF1ACEAA for ; Wed, 22 Jul 2015 01:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySATTJ33aW23 for ; Wed, 22 Jul 2015 01:59:26 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 319F41ACD29 for ; Wed, 22 Jul 2015 01:59:26 -0700 (PDT) Received: by lbbqi7 with SMTP id qi7so51825176lbb.3 for ; Wed, 22 Jul 2015 01:59:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NGmgQCsXABIOQlCldnddNS6BMBx32iaTetLCo23NlAY=; b=vXA9hNCNTV54Bqf7srZ4mhnoTedDQ2KPRR33r2n5tskISFgTxiebxbMdEQV1ZDW4yp FoJRRQZVOlu3JyyLhtUSHMczFoyNoWVW9R/5CQxGdkLOyYph5wfcTaHKqqgiQ3/Ks70/ iHivcLl3/YEqN3ukJrAjRKu25H5goTpfPJTUw1ZAmEJEZbA1sk/GpWygCg9f/0nKVRYR IrzfTgG+zlagdVZHCgG3ro8uqgYU5T6+r0+nKgtmxrZjK6qbXuVrinNyZKxNR0WkBomy /3oG9dDbjEB9n+MszLRxdBDTsiIw9Z8uTOdIL1rRPeP+dkVKu8cjTZzmMWoKTgK526H+ e8Pg== MIME-Version: 1.0 X-Received: by 10.112.50.230 with SMTP id f6mr1307134lbo.17.1437555564674; Wed, 22 Jul 2015 01:59:24 -0700 (PDT) Received: by 10.25.144.131 with HTTP; Wed, 22 Jul 2015 01:59:24 -0700 (PDT) In-Reply-To: References: <84019235-22F4-4BBA-8A45-558E7C65D5D1@mit.edu> Date: Wed, 22 Jul 2015 10:59:24 +0200 Message-ID: From: Maciej Machulak To: Phil Hunt Content-Type: multipart/alternative; boundary=001a1133b54ec70390051b72fcea Archived-At: Cc: Barry Leiba , "" Subject: Re: [OAUTH-WG] OAuth implementation fail X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 08:59:31 -0000 --001a1133b54ec70390051b72fcea Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It seems that they don't ask for scopes. The parameter is left blank: scope=3D Kind regards, Maciej On 22 July 2015 at 10:26, Phil Hunt wrote: > Do they explicitly ask for those scopes? Or do they leave scope to defaul= t > that way. > > Phil > > On Jul 22, 2015, at 10:22, Justin Richer wrote: > > This is a pretty clear case of SlideShare trying to grab too much. The > LinkedIn API (which is their own proprietary thing, not OpenID Connect) > does separate all the permissions into different scopes. However, the > SlideShare app is asking for all of them, and LinkedIn doesn=E2=80=99t le= t you > uncheck any boxes on the authorization screen. > > FWIW, the reason they want write access to your profile is to > automatically add new SlideShare presentations that you upload to your > LinkedIn profile page. You should still have the option of turning that > off, or of turning on that functionality later. > > =E2=80=94 Justin > > On Jul 22, 2015, at 9:49 AM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > Hey Barry, > > From my observations with Facebook, it now has options added for you to > select what resources from Facebook will get shared when authorizing acce= ss > to other applications. You can click on each of the possibilities and > strip it down. It appears to me that Facebook is managing that, so in yo= ur > case, I *think* (and am open to be corrected) that LinkedIn needs to do > something similar. Without those options, I also cancel out and just don= 't > use the other app. > > Thanks, > Kathleen > > On Wed, Jul 22, 2015 at 3:44 AM, Barry Leiba > wrote: > >> Yesterday, someone sent me a link to some presentation slides that >> he'd posted to SlideShare. I looked at them, and wanted to download >> them as a PDF. In order to let me do that, SlideShare wants me to log >> in. It gives me the options to log in via LinkedIn or Facebook. As >> I'm one of the three people in the world without a Facebook account, I >> clicked "LinkedIn". That got me an OAuth authorization screen, image >> attached. >> >> Now, I don't know if this is SlideShare's fault for asking for too >> much, or LinkedIn's fault for not providing enough granularity for >> requests, but just LOOK at that list of what I'd be giving SlideShare >> access to. The first few make sense: read my profile (the whole thing >> or pieces of it, including contact information). But... access to my >> connections? I'm not sure they'd like my exposing their identities to >> SlideShare. Access to my private messages? EDIT MY PROFILE? Srsly? >> >> Of course, this isn't the fault of the OAuth protocol, really (though >> one might argue that there's not enough guidance provided). But, >> really, with implementations like this, I have to wonder what they're >> thinking. >> >> I clicked "Cancel", of course, and asked the slide creator to send me a >> PDF. >> >> Barry >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > > -- > > Best regards, > Kathleen > _______________________________________________ > OAuth mailing list > OAuth@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 Maciej Machulak email: maciej.machulak@gmail.com mobile: +44 7999 606 767 (UK) mobile: +48 602 45 31 66 (PL) --001a1133b54ec70390051b72fcea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It seems that they don't ask for scopes.=C2=A0
The parameter is left blank: scope=3D

= Kind regards,
Maciej

On 22 July 2015 at 10:26, Phil Hunt <phil.hunt= @oracle.com> wrote:
Do they explicitly ask for those scopes? Or do they leave s= cope to default that way.=C2=A0

Phil

On Jul 2= 2, 2015, at 10:22, Justin Richer <jricher@mit.edu> wrote:

This is a pretty clear case of SlideShare trying to grab too= much. The LinkedIn API (which is their own proprietary thing, not OpenID C= onnect) does separate all the permissions into different scopes. However, t= he SlideShare app is asking for all of them, and LinkedIn doesn=E2=80=99t l= et you uncheck any boxes on the authorization screen.=C2=A0

<= div>FWIW, the reason they want write access to your profile is to automatic= ally add new SlideShare presentations that you upload to your LinkedIn prof= ile page. You should still have the option of turning that off, or of turni= ng on that functionality later.

=C2=A0=E2=80=94 Ju= stin

On Jul 22, 2015, at = 9:49 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
Hey Barry,

From my observa= tions with Facebook, it now has options added for you to select what resour= ces from Facebook will get shared when authorizing access to other applicat= ions.=C2=A0 You can click on each of the possibilities and strip it down.= =C2=A0 It appears to me that Facebook is managing that, so in your case, I = *think* (and am open to be corrected) that LinkedIn needs to do something s= imilar.=C2=A0 Without those options, I also cancel out and just don't u= se the other app. =C2=A0

Thanks,
Kathlee= n

On W= ed, Jul 22, 2015 at 3:44 AM, Barry Leiba <barryleiba@computer.org> wrote:
Yesterday, someone se= nt me a link to some presentation slides that
he'd posted to SlideShare.=C2=A0 I looked at them, and wanted to downlo= ad
them as a PDF.=C2=A0 In order to let me do that, SlideShare wants me to log=
in.=C2=A0 It gives me the options to log in via LinkedIn or Facebook.=C2=A0= As
I'm one of the three people in the world without a Facebook account, I<= br> clicked "LinkedIn".=C2=A0 That got me an OAuth authorization scre= en, image
attached.

Now, I don't know if this is SlideShare's fault for asking for too<= br> much, or LinkedIn's fault for not providing enough granularity for
requests, but just LOOK at that list of what I'd be giving SlideShare access to.=C2=A0 The first few make sense: read my profile (the whole thing=
or pieces of it, including contact information).=C2=A0 But... access to my<= br> connections?=C2=A0 I'm not sure they'd like my exposing their ident= ities to
SlideShare.=C2=A0 Access to my private messages?=C2=A0 EDIT MY PROFILE?=C2= =A0 Srsly?

Of course, this isn't the fault of the OAuth protocol, really (though one might argue that there's not enough guidance provided).=C2=A0 But,<= br> really, with implementations like this, I have to wonder what they're thinking.

I clicked "Cancel", of course, and asked the slide creator to sen= d me a PDF.

Barry

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




--

Best regards,
Kathleen
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth
____________= ___________________________________
OAuth mailing list
OAuth@ietf.= org
https://www.ietf.org/mailman/listinfo/oauth

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




--
Maciej Machulak
email: maciej.machulak@gmail.com
mobil= e: +44 7999 606 767 (UK)
mobile: +48 602 45 31 66 (PL)
--001a1133b54ec70390051b72fcea-- From nobody Wed Jul 22 02:06:28 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062B71ACF0A for ; Wed, 22 Jul 2015 02:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjeNoy_Vmiz1 for ; Wed, 22 Jul 2015 02:06:23 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 789141ACEDB for ; Wed, 22 Jul 2015 02:06:22 -0700 (PDT) X-AuditID: 1209190c-f79296d000000622-37-55af5d0dac28 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id A4.7D.01570.D0D5FA55; Wed, 22 Jul 2015 05:06:21 -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 t6M96KtS001594; Wed, 22 Jul 2015 05:06:20 -0400 Received: from dhcp-b0b7.meeting.ietf.org (dhcp-b0b7.meeting.ietf.org [31.133.176.183]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t6M96Fb0027755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Jul 2015 05:06:18 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_558BC898-C98E-4DA9-8382-BFC9B6BE8BB7" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Justin Richer In-Reply-To: Date: Wed, 22 Jul 2015 11:06:15 +0200 Message-Id: <6103DF00-147C-469E-B360-93F365599F3F@mit.edu> References: <84019235-22F4-4BBA-8A45-558E7C65D5D1@mit.edu> To: Maciej Machulak X-Mailer: Apple Mail (2.2102) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMKsWRmVeSWpSXmKPExsUixG6nossbuz7UoOGBqMWhxZdYLZYs3Mxi cfLtKzaLBfMb2R1YPFpW9TJ77Jx1l91jyZKfTB4fn95iCWCJ4rJJSc3JLEst0rdL4MpYcO49 c8G0rIqJx+azNjCeiO5i5OSQEDCReDXxNCOELSZx4d56ti5GLg4hgcVMEnMX3WMBSQgJbGSU 6F+VDpG4wiTx5uFxNpAEs0CCxP+Ta8G6eQX0JHrOfQGzhQUMJdbOnQjWzCagKjF9TQtTFyMH B6dAoMSd7dkgYRag8N2/6xkhxlRK7Fg5jwlijJXE/eZWZohdu5kkNv/8wwLSKyKgL3F8KjvE obISW9+0Mk1gFJiF5IpZSK6AiGtLLFv4mhnC1pTY372cBVNcQ6Lz20TWBYxsqxhlU3KrdHMT M3OKU5N1i5MT8/JSi3QN9XIzS/RSU0o3MYLiglOSZwfjm4NKhxgFOBiVeHgnHF0XKsSaWFZc mXuIUZKDSUmUd1/0+lAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrzK3EA53pTEyqrUonyYlDQH i5I476YffCFCAumJJanZqakFqUUwWRkODiUJ3pYYoEbBotT01Iq0zJwShDQTByfIcB6g4VEg NbzFBYm5xZnpEPlTjIpS4rwVIBcJgCQySvPgemFp6xWjONArwrwXQKp4gCkPrvsV0GAmoMG3 Zq0BGVySiJCSamDMT7ITVA63kvq/8m2F3T2DL3pHaov9YmMT+v/kNUgwsim8vbFp9eOpjqGP 1Oe5z64MMY4XVzsbWvEueNu689X3C7bPu7Q/4oy1jdul3HnbD54WusJ1PTVaqGX2vTC/aWud a7o3rzo7a6LUZSMZaefXZx5f/6Z4dtmKdLky9csNjJrJCr2bZZuUWIozEg21mIuKEwFUBlh/ NgMAAA== Archived-At: Cc: Barry Leiba , "" Subject: Re: [OAUTH-WG] OAuth implementation fail X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 09:06:26 -0000 --Apple-Mail=_558BC898-C98E-4DA9-8382-BFC9B6BE8BB7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 According to the LinkedIn docs, that means they get all the scopes that = they registered for. =E2=80=94 Justin > On Jul 22, 2015, at 10:59 AM, Maciej Machulak = wrote: >=20 > It seems that they don't ask for scopes.=20 >=20 > The parameter is left blank: scope=3D >=20 > Kind regards, > Maciej >=20 > On 22 July 2015 at 10:26, Phil Hunt > wrote: > Do they explicitly ask for those scopes? Or do they leave scope to = default that way.=20 >=20 > Phil >=20 > On Jul 22, 2015, at 10:22, Justin Richer > wrote: >=20 >> This is a pretty clear case of SlideShare trying to grab too much. = The LinkedIn API (which is their own proprietary thing, not OpenID = Connect) does separate all the permissions into different scopes. = However, the SlideShare app is asking for all of them, and LinkedIn = doesn=E2=80=99t let you uncheck any boxes on the authorization screen.=20= >>=20 >> FWIW, the reason they want write access to your profile is to = automatically add new SlideShare presentations that you upload to your = LinkedIn profile page. You should still have the option of turning that = off, or of turning on that functionality later. >>=20 >> =E2=80=94 Justin >>=20 >>> On Jul 22, 2015, at 9:49 AM, Kathleen Moriarty = > wrote: >>>=20 >>> Hey Barry, >>>=20 >>> =46rom my observations with Facebook, it now has options added for = you to select what resources from Facebook will get shared when = authorizing access to other applications. You can click on each of the = possibilities and strip it down. It appears to me that Facebook is = managing that, so in your case, I *think* (and am open to be corrected) = that LinkedIn needs to do something similar. Without those options, I = also cancel out and just don't use the other app. =20 >>>=20 >>> Thanks, >>> Kathleen >>>=20 >>> On Wed, Jul 22, 2015 at 3:44 AM, Barry Leiba = > wrote: >>> Yesterday, someone sent me a link to some presentation slides that >>> he'd posted to SlideShare. I looked at them, and wanted to download >>> them as a PDF. In order to let me do that, SlideShare wants me to = log >>> in. It gives me the options to log in via LinkedIn or Facebook. As >>> I'm one of the three people in the world without a Facebook account, = I >>> clicked "LinkedIn". That got me an OAuth authorization screen, = image >>> attached. >>>=20 >>> Now, I don't know if this is SlideShare's fault for asking for too >>> much, or LinkedIn's fault for not providing enough granularity for >>> requests, but just LOOK at that list of what I'd be giving = SlideShare >>> access to. The first few make sense: read my profile (the whole = thing >>> or pieces of it, including contact information). But... access to = my >>> connections? I'm not sure they'd like my exposing their identities = to >>> SlideShare. Access to my private messages? EDIT MY PROFILE? = Srsly? >>>=20 >>> Of course, this isn't the fault of the OAuth protocol, really = (though >>> one might argue that there's not enough guidance provided). But, >>> really, with implementations like this, I have to wonder what = they're >>> thinking. >>>=20 >>> I clicked "Cancel", of course, and asked the slide creator to send = me a PDF. >>>=20 >>> Barry >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>>=20 >>>=20 >>>=20 >>> --=20 >>>=20 >>> Best regards, >>> Kathleen >>> _______________________________________________ >>> 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 >=20 > --=20 > Maciej Machulak > email: maciej.machulak@gmail.com > mobile: +44 7999 606 767 (UK) > mobile: +48 602 45 31 66 (PL) --Apple-Mail=_558BC898-C98E-4DA9-8382-BFC9B6BE8BB7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 According to the LinkedIn docs, that means they get all the = scopes that they registered for.

 =E2=80=94 Justin

On Jul = 22, 2015, at 10:59 AM, Maciej Machulak <maciej.machulak@gmail.com> wrote:

It seems that they don't ask for = scopes. 

The = parameter is left blank: scope=3D

Kind regards,
Maciej

On 22 July 2015 at 10:26, Phil = Hunt <phil.hunt@oracle.com> wrote:
Do they explicitly ask for those scopes? Or = do they leave scope to default that way. 

Phil

On Jul 22, 2015, at 10:22, Justin Richer = <jricher@mit.edu> wrote:

This= is a pretty clear case of SlideShare trying to grab too much. The = LinkedIn API (which is their own proprietary thing, not OpenID Connect) = does separate all the permissions into different scopes. However, the = SlideShare app is asking for all of them, and LinkedIn doesn=E2=80=99t = let you uncheck any boxes on the authorization screen. 

FWIW, the reason they = want write access to your profile is to automatically add new SlideShare = presentations that you upload to your LinkedIn profile page. You should = still have the option of turning that off, or of turning on that = functionality later.

 =E2=80=94 Justin

On Jul = 22, 2015, at 9:49 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Hey Barry,

=46rom my observations = with Facebook, it now has options added for you to select what resources = from Facebook will get shared when authorizing access to other = applications.  You can click on each of the possibilities and strip = it down.  It appears to me that Facebook is managing that, so in = your case, I *think* (and am open to be corrected) that LinkedIn needs = to do something similar.  Without those options, I also cancel out = and just don't use the other app.  

Thanks,
Kathleen

On Wed, Jul 22, 2015 at 3:44 AM, = Barry Leiba <barryleiba@computer.org> wrote:
Yesterday, someone = sent me a link to some presentation slides that
he'd posted to SlideShare.  I looked at them, and wanted to = download
them as a PDF.  In order to let me do that, SlideShare wants me to = log
in.  It gives me the options to log in via LinkedIn or = Facebook.  As
I'm one of the three people in the world without a Facebook account, = I
clicked "LinkedIn".  That got me an OAuth authorization screen, = image
attached.

Now, I don't know if this is SlideShare's fault for asking for too
much, or LinkedIn's fault for not providing enough granularity for
requests, but just LOOK at that list of what I'd be giving SlideShare
access to.  The first few make sense: read my profile (the whole = thing
or pieces of it, including contact information).  But... access to = my
connections?  I'm not sure they'd like my exposing their identities = to
SlideShare.  Access to my private messages?  EDIT MY = PROFILE?  Srsly?

Of course, this isn't the fault of the OAuth protocol, really (though
one might argue that there's not enough guidance provided).  = But,
really, with implementations like this, I have to wonder what they're
thinking.

I clicked "Cancel", of course, and asked the slide creator to send me a = PDF.

Barry

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




--

Best= regards,
Kathleen
_______________________________________________
OAuth = mailing list
OAuth@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




--
Maciej Machulak
email: maciej.machulak@gmail.com
mobile: +44 7999 = 606 767 (UK)
mobile: +48 602 45 31 66 (PL)

= --Apple-Mail=_558BC898-C98E-4DA9-8382-BFC9B6BE8BB7-- From nobody Wed Jul 22 02:08:14 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F06E1ACEF4 for ; Wed, 22 Jul 2015 02:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gu_R52rY8e1c for ; Wed, 22 Jul 2015 02:08:11 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1828C1ACEC5 for ; Wed, 22 Jul 2015 02:08:11 -0700 (PDT) Received: by oige126 with SMTP id e126so139684469oig.0 for ; Wed, 22 Jul 2015 02:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qJaAEFGuVgY3Okye/iQyM7yblfYU91sDdB8Z1iO4hKI=; b=bCS11L7zu66aej/JbnNCPpwXsZLAJ4SHJY064PpGc3IAzBfBeMkLLRyVEfoftozE5R 4ImYQq+YQNHW5vmfYepII9FnFiO2AE8RhM2fwxsm0F4APx7E2PLg3PTkrVLx9rGeo9f3 Z5d9xi4N/bNHL1jAe/YD/SU3IVjt0o/zGwNQ3GGP2st0rq97RLRhiGgHdADHuTQun7/y /oNxGEc2ePqDBJW+f7x+NLuAf99Wepx5ILykMqGTADV4K6lC4vPyexN+AY0Rer5LXl/W NwThYKQFfybxi5/L3zRDTsQqxJ7p6H3yGmSm5k0Y8qPjYa23saM3rteKYDWhxJIf8TIk y/4w== MIME-Version: 1.0 X-Received: by 10.60.56.35 with SMTP id x3mr1346471oep.65.1437556090539; Wed, 22 Jul 2015 02:08:10 -0700 (PDT) Received: by 10.182.96.66 with HTTP; Wed, 22 Jul 2015 02:08:10 -0700 (PDT) In-Reply-To: <6103DF00-147C-469E-B360-93F365599F3F@mit.edu> References: <84019235-22F4-4BBA-8A45-558E7C65D5D1@mit.edu> <6103DF00-147C-469E-B360-93F365599F3F@mit.edu> Date: Wed, 22 Jul 2015 11:08:10 +0200 Message-ID: From: Nat Sakimura To: Justin Richer Content-Type: multipart/alternative; boundary=001a11c21dec1f16bf051b731cdb Archived-At: Cc: Barry Leiba , "" Subject: Re: [OAUTH-WG] OAuth implementation fail X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 09:08:13 -0000 --001a11c21dec1f16bf051b731cdb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Wow, that's the very opposite of Privacy by Design/Default recommendation. 2015-07-22 11:06 GMT+02:00 Justin Richer : > According to the LinkedIn docs, that means they get all the scopes that > they registered for. > > =E2=80=94 Justin > > On Jul 22, 2015, at 10:59 AM, Maciej Machulak > wrote: > > It seems that they don't ask for scopes. > > The parameter is left blank: scope=3D > > Kind regards, > Maciej > > On 22 July 2015 at 10:26, Phil Hunt wrote: > >> Do they explicitly ask for those scopes? Or do they leave scope to >> default that way. >> >> Phil >> >> On Jul 22, 2015, at 10:22, Justin Richer wrote: >> >> This is a pretty clear case of SlideShare trying to grab too much. The >> LinkedIn API (which is their own proprietary thing, not OpenID Connect) >> does separate all the permissions into different scopes. However, the >> SlideShare app is asking for all of them, and LinkedIn doesn=E2=80=99t l= et you >> uncheck any boxes on the authorization screen. >> >> FWIW, the reason they want write access to your profile is to >> automatically add new SlideShare presentations that you upload to your >> LinkedIn profile page. You should still have the option of turning that >> off, or of turning on that functionality later. >> >> =E2=80=94 Justin >> >> On Jul 22, 2015, at 9:49 AM, Kathleen Moriarty < >> kathleen.moriarty.ietf@gmail.com> wrote: >> >> Hey Barry, >> >> From my observations with Facebook, it now has options added for you to >> select what resources from Facebook will get shared when authorizing acc= ess >> to other applications. You can click on each of the possibilities and >> strip it down. It appears to me that Facebook is managing that, so in y= our >> case, I *think* (and am open to be corrected) that LinkedIn needs to do >> something similar. Without those options, I also cancel out and just do= n't >> use the other app. >> >> Thanks, >> Kathleen >> >> On Wed, Jul 22, 2015 at 3:44 AM, Barry Leiba >> wrote: >> >>> Yesterday, someone sent me a link to some presentation slides that >>> he'd posted to SlideShare. I looked at them, and wanted to download >>> them as a PDF. In order to let me do that, SlideShare wants me to log >>> in. It gives me the options to log in via LinkedIn or Facebook. As >>> I'm one of the three people in the world without a Facebook account, I >>> clicked "LinkedIn". That got me an OAuth authorization screen, image >>> attached. >>> >>> Now, I don't know if this is SlideShare's fault for asking for too >>> much, or LinkedIn's fault for not providing enough granularity for >>> requests, but just LOOK at that list of what I'd be giving SlideShare >>> access to. The first few make sense: read my profile (the whole thing >>> or pieces of it, including contact information). But... access to my >>> connections? I'm not sure they'd like my exposing their identities to >>> SlideShare. Access to my private messages? EDIT MY PROFILE? Srsly? >>> >>> Of course, this isn't the fault of the OAuth protocol, really (though >>> one might argue that there's not enough guidance provided). But, >>> really, with implementations like this, I have to wonder what they're >>> thinking. >>> >>> I clicked "Cancel", of course, and asked the slide creator to send me a >>> PDF. >>> >>> Barry >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> >> -- >> >> Best regards, >> Kathleen >> _______________________________________________ >> OAuth mailing list >> OAuth@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 >> >> > > > -- > Maciej Machulak > email: maciej.machulak@gmail.com > mobile: +44 7999 606 767 (UK) > mobile: +48 602 45 31 66 (PL) > > > > _______________________________________________ > 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 --001a11c21dec1f16bf051b731cdb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Wow, that's the very opposite of Privacy by Design/Def= ault recommendation.=C2=A0

<= br>
2015-07-22 11:06 GMT+02:00 Justin Richer <jric= her@mit.edu>:
According to the LinkedIn docs, that means they get = all the scopes that they registered for.

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

On Jul = 22, 2015, at 10:59 AM, Maciej Machulak <maciej.machulak@gmail.com> wrote:
It seems that they don't ask for scopes.=C2= =A0

The parameter is left blank: scope=3D

=
Kind regards,
Maciej

On 22 July 2015 at 10:26, Phil Hunt <phil.hunt@oracle.com> wrote:
Do they explicitly ask for those scopes? Or do t= hey leave scope to default that way.=C2=A0
Phil

On Jul 22, 2015, at 10:22, = Justin Richer <jric= her@mit.edu> wrote:

This= is a pretty clear case of SlideShare trying to grab too much. The LinkedIn= API (which is their own proprietary thing, not OpenID Connect) does separa= te all the permissions into different scopes. However, the SlideShare app i= s asking for all of them, and LinkedIn doesn=E2=80=99t let you uncheck any = boxes on the authorization screen.=C2=A0

FWIW, the reaso= n they want write access to your profile is to automatically add new SlideS= hare presentations that you upload to your LinkedIn profile page. You shoul= d still have the option of turning that off, or of turning on that function= ality later.

=C2=A0=E2=80=94 Justin

=
On Jul 22, 2015, at 9:49 AM, Kathleen M= oriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Hey Barry,

From my observations with Facebook= , it now has options added for you to select what resources from Facebook w= ill get shared when authorizing access to other applications.=C2=A0 You can= click on each of the possibilities and strip it down.=C2=A0 It appears to = me that Facebook is managing that, so in your case, I *think* (and am open = to be corrected) that LinkedIn needs to do something similar.=C2=A0 Without= those options, I also cancel out and just don't use the other app. =C2= =A0

Thanks,
Kathleen

On Wed, Jul 22, 2015 at 3= :44 AM, Barry Leiba <barryleiba@computer.org> wrote:
Yesterday, someone sent me a link to some = presentation slides that
he'd posted to SlideShare.=C2=A0 I looked at them, and wanted to downlo= ad
them as a PDF.=C2=A0 In order to let me do that, SlideShare wants me to log=
in.=C2=A0 It gives me the options to log in via LinkedIn or Facebook.=C2=A0= As
I'm one of the three people in the world without a Facebook account, I<= br> clicked "LinkedIn".=C2=A0 That got me an OAuth authorization scre= en, image
attached.

Now, I don't know if this is SlideShare's fault for asking for too<= br> much, or LinkedIn's fault for not providing enough granularity for
requests, but just LOOK at that list of what I'd be giving SlideShare access to.=C2=A0 The first few make sense: read my profile (the whole thing=
or pieces of it, including contact information).=C2=A0 But... access to my<= br> connections?=C2=A0 I'm not sure they'd like my exposing their ident= ities to
SlideShare.=C2=A0 Access to my private messages?=C2=A0 EDIT MY PROFILE?=C2= =A0 Srsly?

Of course, this isn't the fault of the OAuth protocol, really (though one might argue that there's not enough guidance provided).=C2=A0 But,<= br> really, with implementations like this, I have to wonder what they're thinking.

I clicked "Cancel", of course, and asked the slide creator to sen= d me a PDF.

Barry

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




--

Best regards,
Kathleen
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth
____________= ___________________________________
OAuth mailing list
OAuth@ietf.= org
https://www.ietf.org/mailman/listinfo/oauth

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




--
Mac= iej Machulak
email: maciej.machulak@gmail.com
mobile: +44 7999 606 7= 67 (UK)
mobile: +48 602 45 31 66 (PL)


__________________= _____________________________
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
--001a11c21dec1f16bf051b731cdb-- From nobody Wed Jul 22 02:19:33 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644571AD0B8 for ; Wed, 22 Jul 2015 02:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZqU7Yqv2V2o for ; Wed, 22 Jul 2015 02:19:27 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74F291AD0AB for ; Wed, 22 Jul 2015 02:19:27 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so92329191wib.1 for ; Wed, 22 Jul 2015 02:19:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=9myvp3F/cKK8x6tfBVJMuxlFdB5cs2n5s8dLmUPhzms=; b=TDL8p/gtDGqg6EY5S0le1Tpk+f63EUH9PFDndsoJVjcQCPXaDnMUBBNoNfcIbisf88 SrdM4EohqcGPPQldFRCARR8SkVf89iYo10vxVg9jGCdXPGLnG8MUZEWTOXjL1EoorBtL GObkmxwHw9DeWZkdCCcbhVUbTeZUosGbPKoLBcdCeiyylqO23I1QdY8PfhjN7GsY7DzR 8DoR2pNpK15X5BXMuX7chw4MBlitwCtrBe5d+dSW7dcOiS6+PwMQKQurHH3goTunHCqw 8XNqnFf/BUXsHLhto1vSsAFOCykYlQWZvmtqbtS9btCxhYyHrQ9F0NAZ2JoApE6NCJbj lhig== X-Gm-Message-State: ALoCoQnDBEwkWxozLlX9G2tcWej+/kI6+HTaQUU76TJXKn2mIvkk1fYyJf66/qvlG6zReil1smV2 X-Received: by 10.180.104.129 with SMTP id ge1mr4679953wib.84.1437556766083; Wed, 22 Jul 2015 02:19:26 -0700 (PDT) Received: from [130.129.15.152] ([130.129.15.152]) by smtp.gmail.com with ESMTPSA id ck7sm1334699wjc.43.2015.07.22.02.19.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jul 2015 02:19:25 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_52424228-473C-4E77-91BB-F8A21A79FB2D"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: John Bradley In-Reply-To: Date: Wed, 22 Jul 2015 11:19:23 +0200 Message-Id: <941211DE-F224-435D-8206-42ED464A9F20@ve7jtb.com> References: <84019235-22F4-4BBA-8A45-558E7C65D5D1@mit.edu> <6103DF00-147C-469E-B360-93F365599F3F@mit.edu> To: Nat Sakimura X-Mailer: Apple Mail (2.2102) Archived-At: Cc: Barry Leiba , "" Subject: Re: [OAUTH-WG] OAuth implementation fail X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 09:19:31 -0000 --Apple-Mail=_52424228-473C-4E77-91BB-F8A21A79FB2D Content-Type: multipart/alternative; boundary="Apple-Mail=_A3B6F041-FCD9-4EE5-9F62-8EE4EDFA72C9" --Apple-Mail=_A3B6F041-FCD9-4EE5-9F62-8EE4EDFA72C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Slideshare did register all of those scopes as ones the client could ask = for. Interpreting no scopes as all the ones the client has set as the ones it = wants is probably not unreasonable. The problem is a combination of Slideshare over asking, perhaps because = they don=E2=80=99t understand the default behaviour, and LinkedIn now = allowing only some of the scopes to be returned. I think people are moving back to allowing people to deselect scopes. = In Android m you can now deselect scopes that apps request, both at = installation and after. One argument that people have put forward is that RP will ask for the = minimum set of scopes to encourage the person to consent. However it = seems that many RP decide to grab the maximum permissions on the grounds = that people agree to it. I don=E2=80=99t know that any spec change is required, but perhaps some = sort of education is. If users decline all on a regular basis then the RP will be motivated to = change. John B. > On Jul 22, 2015, at 11:08 AM, Nat Sakimura wrote: >=20 > Wow, that's the very opposite of Privacy by Design/Default = recommendation.=20 >=20 >=20 > 2015-07-22 11:06 GMT+02:00 Justin Richer >: > According to the LinkedIn docs, that means they get all the scopes = that they registered for. >=20 > =E2=80=94 Justin >=20 >> On Jul 22, 2015, at 10:59 AM, Maciej Machulak = > wrote: >>=20 >> It seems that they don't ask for scopes.=20 >>=20 >> The parameter is left blank: scope=3D >>=20 >> Kind regards, >> Maciej >>=20 >> On 22 July 2015 at 10:26, Phil Hunt > wrote: >> Do they explicitly ask for those scopes? Or do they leave scope to = default that way.=20 >>=20 >> Phil >>=20 >> On Jul 22, 2015, at 10:22, Justin Richer > wrote: >>=20 >>> This is a pretty clear case of SlideShare trying to grab too much. = The LinkedIn API (which is their own proprietary thing, not OpenID = Connect) does separate all the permissions into different scopes. = However, the SlideShare app is asking for all of them, and LinkedIn = doesn=E2=80=99t let you uncheck any boxes on the authorization screen.=20= >>>=20 >>> FWIW, the reason they want write access to your profile is to = automatically add new SlideShare presentations that you upload to your = LinkedIn profile page. You should still have the option of turning that = off, or of turning on that functionality later. >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Jul 22, 2015, at 9:49 AM, Kathleen Moriarty = > wrote: >>>>=20 >>>> Hey Barry, >>>>=20 >>>> =46rom my observations with Facebook, it now has options added for = you to select what resources from Facebook will get shared when = authorizing access to other applications. You can click on each of the = possibilities and strip it down. It appears to me that Facebook is = managing that, so in your case, I *think* (and am open to be corrected) = that LinkedIn needs to do something similar. Without those options, I = also cancel out and just don't use the other app. =20 >>>>=20 >>>> Thanks, >>>> Kathleen >>>>=20 >>>> On Wed, Jul 22, 2015 at 3:44 AM, Barry Leiba = > wrote: >>>> Yesterday, someone sent me a link to some presentation slides that >>>> he'd posted to SlideShare. I looked at them, and wanted to = download >>>> them as a PDF. In order to let me do that, SlideShare wants me to = log >>>> in. It gives me the options to log in via LinkedIn or Facebook. = As >>>> I'm one of the three people in the world without a Facebook = account, I >>>> clicked "LinkedIn". That got me an OAuth authorization screen, = image >>>> attached. >>>>=20 >>>> Now, I don't know if this is SlideShare's fault for asking for too >>>> much, or LinkedIn's fault for not providing enough granularity for >>>> requests, but just LOOK at that list of what I'd be giving = SlideShare >>>> access to. The first few make sense: read my profile (the whole = thing >>>> or pieces of it, including contact information). But... access to = my >>>> connections? I'm not sure they'd like my exposing their identities = to >>>> SlideShare. Access to my private messages? EDIT MY PROFILE? = Srsly? >>>>=20 >>>> Of course, this isn't the fault of the OAuth protocol, really = (though >>>> one might argue that there's not enough guidance provided). But, >>>> really, with implementations like this, I have to wonder what = they're >>>> thinking. >>>>=20 >>>> I clicked "Cancel", of course, and asked the slide creator to send = me a PDF. >>>>=20 >>>> Barry >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>>=20 >>>> Best regards, >>>> Kathleen >>>> _______________________________________________ >>>> 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 >>=20 >> --=20 >> Maciej Machulak >> email: maciej.machulak@gmail.com >> mobile: +44 7999 606 767 (UK) >> mobile: +48 602 45 31 66 (PL) >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_A3B6F041-FCD9-4EE5-9F62-8EE4EDFA72C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Slideshare did register all of those scopes as ones the = client could ask for.

Interpreting no scopes as all the ones the client has set as = the ones it wants is probably not unreasonable.

The problem is a combination of = Slideshare over asking, perhaps because they don=E2=80=99t understand = the default behaviour,  and LinkedIn now allowing only some of the = scopes to be returned.

I think people are moving back to allowing people to deselect = scopes.   In Android m you can now deselect scopes that apps = request, both at installation and after.

One argument that people have put = forward is that RP will ask for the minimum set of scopes to encourage = the person to consent.   However it seems that many RP decide to = grab the maximum permissions on the grounds that people agree to = it.

I don=E2=80=99= t know that any spec change is required, but perhaps some sort of = education is.

If= users decline all on a regular basis then the RP will be motivated to = change.

John = B.

On = Jul 22, 2015, at 11:08 AM, Nat Sakimura <sakimura@gmail.com> = wrote:

Wow, that's the very opposite of Privacy by = Design/Default recommendation. 


2015-07-22 11:06 GMT+02:00 Justin Richer <jricher@mit.edu>:
According to the LinkedIn = docs, that means they get all the scopes that they registered for.

 =E2=80=94 = Justin

On Jul 22, 2015, at 10:59 AM, Maciej Machulak = <maciej.machulak@gmail.com> wrote:

It seems that = they don't ask for scopes. 

The parameter is left blank: scope=3D

Kind regards,
Maciej

On 22 July 2015 at 10:26, Phil = Hunt <phil.hunt@oracle.com> wrote:
Do they explicitly ask for those scopes? Or = do they leave scope to default that way. 

Phil

On Jul 22, 2015, at 10:22, Justin Richer = <jricher@mit.edu> wrote:

This= is a pretty clear case of SlideShare trying to grab too much. The = LinkedIn API (which is their own proprietary thing, not OpenID Connect) = does separate all the permissions into different scopes. However, the = SlideShare app is asking for all of them, and LinkedIn doesn=E2=80=99t = let you uncheck any boxes on the authorization screen. 

FWIW, the reason they = want write access to your profile is to automatically add new SlideShare = presentations that you upload to your LinkedIn profile page. You should = still have the option of turning that off, or of turning on that = functionality later.

 =E2=80=94 Justin

On Jul = 22, 2015, at 9:49 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Hey Barry,

=46rom my observations = with Facebook, it now has options added for you to select what resources = from Facebook will get shared when authorizing access to other = applications.  You can click on each of the possibilities and strip = it down.  It appears to me that Facebook is managing that, so in = your case, I *think* (and am open to be corrected) that LinkedIn needs = to do something similar.  Without those options, I also cancel out = and just don't use the other app.  

Thanks,
Kathleen

On Wed, Jul 22, 2015 at 3:44 AM, = Barry Leiba <barryleiba@computer.org> wrote:
Yesterday, someone = sent me a link to some presentation slides that
he'd posted to SlideShare.  I looked at them, and wanted to = download
them as a PDF.  In order to let me do that, SlideShare wants me to = log
in.  It gives me the options to log in via LinkedIn or = Facebook.  As
I'm one of the three people in the world without a Facebook account, = I
clicked "LinkedIn".  That got me an OAuth authorization screen, = image
attached.

Now, I don't know if this is SlideShare's fault for asking for too
much, or LinkedIn's fault for not providing enough granularity for
requests, but just LOOK at that list of what I'd be giving SlideShare
access to.  The first few make sense: read my profile (the whole = thing
or pieces of it, including contact information).  But... access to = my
connections?  I'm not sure they'd like my exposing their identities = to
SlideShare.  Access to my private messages?  EDIT MY = PROFILE?  Srsly?

Of course, this isn't the fault of the OAuth protocol, really (though
one might argue that there's not enough guidance provided).  = But,
really, with implementations like this, I have to wonder what they're
thinking.

I clicked "Cancel", of course, and asked the slide creator to send me a = PDF.

Barry

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




--

Best= regards,
Kathleen
_______________________________________________
OAuth = mailing list
OAuth@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




--
Maciej Machulak
email: maciej.machulak@gmail.com
mobile: +44 7999 606 767 (UK)
mobile: +48 602 45 31 66 (PL)


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




--
Nat Sakimura (=3Dnat)
Chairman, = OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_A3B6F041-FCD9-4EE5-9F62-8EE4EDFA72C9-- --Apple-Mail=_52424228-473C-4E77-91BB-F8A21A79FB2D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTA3MjIwOTE5MjRaMCMGCSqGSIb3DQEJBDEWBBTnAqmkbVVxslvUcN/kT6Wh Nx+P1zCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQAzqt9iZCZpYI6sluI1Q/1b5lVVBeCcMkIrK5agMbqWjfjCshPhGVu/ D5dazWwCWJk0/snoju1DwgC4bwc9LtgqZphUi1lPwK4WG3b26uPjcEBzFV4G1P90oGDEHtpYdsF+ G8ZuBmRTbOaPXaiXFWT+E1bAffeLh0s9pJwYnTKUZpPujHAZh85UfBHB/Q+v9TRi+Oekf+dnzu8C XATyulvJZd5lFt2miL3RGxGBgR2carWWpA4/dMI15J3vPVRLUMpTHV5VkFb0Awc2RTapkOLxDb9o nP6qrP8cQmDI5Gbq1v9FpXwRIwOr9vFegWqPchHlLPpN89fvCyu4MJmGZsstAAAAAAAA --Apple-Mail=_52424228-473C-4E77-91BB-F8A21A79FB2D-- From nobody Wed Jul 22 02:36:16 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77AF31A00A0 for ; Wed, 22 Jul 2015 02:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pX2fevyUR_3Q for ; Wed, 22 Jul 2015 02:36:13 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B01B1A1A15 for ; Wed, 22 Jul 2015 02:35:56 -0700 (PDT) Received: by oige126 with SMTP id e126so140049144oig.0 for ; Wed, 22 Jul 2015 02:35:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NHk9ZGIXvlG1aeAw6Q0yBDIhCIEfIs0NAiI+LuxZ7cs=; b=OaDymC7DBRrFDPmaOqDx6d4h4WqSVlHhGrwon2+qJTMmab7Wm3zsn24EHAGWwa/axd W5+BVIFdIO6HOM1NvFyrMVl12czrYrzmNb6O8ljtsbtIL45bi04eV2w0UMBPs8Qul6Qv bQ2jkK8T0qcPdS8FfYKfG7C57p7GhD+zu6HJigQzE6UC48NBGaXdw3RFx5hsgRQTDgAj UDlHfXVGS6t84r4OSC7Lbmt9CM7bjk2pAZN9M7ggKVQB+ETV/IMqU3rJBJlBySWFvgB8 o0SAKZubqVuScVqtiqUG4DgGmrDg9hgr0nyTvVe05viMo9sZB6TMn680mmAa6bJkrCcg 1PQw== MIME-Version: 1.0 X-Received: by 10.202.243.215 with SMTP id r206mr1266034oih.106.1437557755447; Wed, 22 Jul 2015 02:35:55 -0700 (PDT) Received: by 10.182.96.66 with HTTP; Wed, 22 Jul 2015 02:35:55 -0700 (PDT) In-Reply-To: <941211DE-F224-435D-8206-42ED464A9F20@ve7jtb.com> References: <84019235-22F4-4BBA-8A45-558E7C65D5D1@mit.edu> <6103DF00-147C-469E-B360-93F365599F3F@mit.edu> <941211DE-F224-435D-8206-42ED464A9F20@ve7jtb.com> Date: Wed, 22 Jul 2015 11:35:55 +0200 Message-ID: From: Nat Sakimura To: John Bradley Content-Type: multipart/alternative; boundary=94eb2c095d805b924e051b737f4d Archived-At: Cc: Barry Leiba , "" Subject: Re: [OAUTH-WG] OAuth implementation fail X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 09:36:15 -0000 --94eb2c095d805b924e051b737f4d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable IMHO, returning everything if scope is empty is a violation of the collection minimization principle. From the privacy by Design point of view, a lazy programmer sending an empty request should not cause the maximal data returned. Now, as to the spec change is concerned, I agree with John that it is not required. However, a Best practice document would probably help the developers. Nat 2015-07-22 11:19 GMT+02:00 John Bradley : > Slideshare did register all of those scopes as ones the client could ask > for. > > Interpreting no scopes as all the ones the client has set as the ones it > wants is probably not unreasonable. > > The problem is a combination of Slideshare over asking, perhaps because > they don=E2=80=99t understand the default behaviour, and LinkedIn now al= lowing > only some of the scopes to be returned. > > I think people are moving back to allowing people to deselect scopes. I= n > Android m you can now deselect scopes that apps request, both at > installation and after. > > One argument that people have put forward is that RP will ask for the > minimum set of scopes to encourage the person to consent. However it > seems that many RP decide to grab the maximum permissions on the grounds > that people agree to it. > > I don=E2=80=99t know that any spec change is required, but perhaps some s= ort of > education is. > > If users decline all on a regular basis then the RP will be motivated to > change. > > John B. > > On Jul 22, 2015, at 11:08 AM, Nat Sakimura wrote: > > Wow, that's the very opposite of Privacy by Design/Default recommendation= . > > > 2015-07-22 11:06 GMT+02:00 Justin Richer : > >> According to the LinkedIn docs, that means they get all the scopes that >> they registered for. >> >> =E2=80=94 Justin >> >> On Jul 22, 2015, at 10:59 AM, Maciej Machulak >> wrote: >> >> It seems that they don't ask for scopes. >> >> The parameter is left blank: scope=3D >> >> Kind regards, >> Maciej >> >> On 22 July 2015 at 10:26, Phil Hunt wrote: >> >>> Do they explicitly ask for those scopes? Or do they leave scope to >>> default that way. >>> >>> Phil >>> >>> On Jul 22, 2015, at 10:22, Justin Richer wrote: >>> >>> This is a pretty clear case of SlideShare trying to grab too much. The >>> LinkedIn API (which is their own proprietary thing, not OpenID Connect) >>> does separate all the permissions into different scopes. However, the >>> SlideShare app is asking for all of them, and LinkedIn doesn=E2=80=99t = let you >>> uncheck any boxes on the authorization screen. >>> >>> FWIW, the reason they want write access to your profile is to >>> automatically add new SlideShare presentations that you upload to your >>> LinkedIn profile page. You should still have the option of turning that >>> off, or of turning on that functionality later. >>> >>> =E2=80=94 Justin >>> >>> On Jul 22, 2015, at 9:49 AM, Kathleen Moriarty < >>> kathleen.moriarty.ietf@gmail.com> wrote: >>> >>> Hey Barry, >>> >>> From my observations with Facebook, it now has options added for you to >>> select what resources from Facebook will get shared when authorizing ac= cess >>> to other applications. You can click on each of the possibilities and >>> strip it down. It appears to me that Facebook is managing that, so in = your >>> case, I *think* (and am open to be corrected) that LinkedIn needs to do >>> something similar. Without those options, I also cancel out and just d= on't >>> use the other app. >>> >>> Thanks, >>> Kathleen >>> >>> On Wed, Jul 22, 2015 at 3:44 AM, Barry Leiba >>> wrote: >>> >>>> Yesterday, someone sent me a link to some presentation slides that >>>> he'd posted to SlideShare. I looked at them, and wanted to download >>>> them as a PDF. In order to let me do that, SlideShare wants me to log >>>> in. It gives me the options to log in via LinkedIn or Facebook. As >>>> I'm one of the three people in the world without a Facebook account, I >>>> clicked "LinkedIn". That got me an OAuth authorization screen, image >>>> attached. >>>> >>>> Now, I don't know if this is SlideShare's fault for asking for too >>>> much, or LinkedIn's fault for not providing enough granularity for >>>> requests, but just LOOK at that list of what I'd be giving SlideShare >>>> access to. The first few make sense: read my profile (the whole thing >>>> or pieces of it, including contact information). But... access to my >>>> connections? I'm not sure they'd like my exposing their identities to >>>> SlideShare. Access to my private messages? EDIT MY PROFILE? Srsly? >>>> >>>> Of course, this isn't the fault of the OAuth protocol, really (though >>>> one might argue that there's not enough guidance provided). But, >>>> really, with implementations like this, I have to wonder what they're >>>> thinking. >>>> >>>> I clicked "Cancel", of course, and asked the slide creator to send me = a >>>> PDF. >>>> >>>> Barry >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>> >>> >>> -- >>> >>> Best regards, >>> Kathleen >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@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 >>> >>> >> >> >> -- >> Maciej Machulak >> email: maciej.machulak@gmail.com >> mobile: +44 7999 606 767 (UK) >> mobile: +48 602 45 31 66 (PL) >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --94eb2c095d805b924e051b737f4d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
IMHO, returning everything if scope is empty is a violatio= n of the collection minimization principle. From the privacy by Design poin= t of view, a lazy programmer sending an empty request should not cause the = maximal data returned.=C2=A0

Now, as to the spec change = is concerned, I agree with John that it is not required.=C2=A0
Ho= wever, a Best practice document would probably help the developers.=C2=A0

Nat

2015-07-22 11:19 GMT+02:00 John Bradley <ve7jtb@ve7j= tb.com>:
Slideshare did register all of those scopes as ones the c= lient could ask for.

Interpreting no scopes as all the o= nes the client has set as the ones it wants is probably not unreasonable.

The problem is a combination of Slideshare over ask= ing, perhaps because they don=E2=80=99t understand the default behaviour, = =C2=A0and LinkedIn now allowing only some of the scopes to be returned.

I think people are moving back to allowing people to = deselect scopes. =C2=A0 In Android m you can now deselect scopes that apps = request, both at installation and after.

One argum= ent that people have put forward is that RP will ask for the minimum set of= scopes to encourage the person to consent. =C2=A0 However it seems that ma= ny RP decide to grab the maximum permissions on the grounds that people agr= ee to it.

I don=E2=80=99t know that any spec chang= e is required, but perhaps some sort of education is.

<= div>If users decline all on a regular basis then the RP will be motivated t= o change.

John B.

On Jul 22, 2015, at 11:= 08 AM, Nat Sakimura <sakimura@gmail.com> wrote:

Wow, = that's the very opposite of Privacy by Design/Default recommendation.= =C2=A0


2015-07-22 11:06 GMT+02:00 Justin Richer <jricher@mit.edu><= /span>:
According to the LinkedIn docs, that means they get all the scopes that = they registered for.

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

On Jul 22, 2015, at 10:59 AM, Maciej Machulak <maciej.machulak@gm= ail.com> wrote:

It seems that they do= n't ask for scopes.=C2=A0

The parameter is left blan= k: scope=3D

Kind regards,
Maciej

On 22 July 20= 15 at 10:26, Phil Hunt <phil.hunt@oracle.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Do they explicitly ask= for those scopes? Or do they leave scope to default that way.=C2=A0<= font color=3D"#888888">

Phil

O= n Jul 22, 2015, at 10:22, Justin Richer <jricher@mit.edu> wrote:

This is a pretty clear case of SlideShare trying to g= rab too much. The LinkedIn API (which is their own proprietary thing, not O= penID Connect) does separate all the permissions into different scopes. How= ever, the SlideShare app is asking for all of them, and LinkedIn doesn=E2= =80=99t let you uncheck any boxes on the authorization screen.=C2=A0
FWIW, the reason they want write access to your profile is to = automatically add new SlideShare presentations that you upload to your Link= edIn profile page. You should still have the option of turning that off, or= of turning on that functionality later.

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

On Jul 22, = 2015, at 9:49 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>= wrote:

Hey Barry,

From m= y observations with Facebook, it now has options added for you to select wh= at resources from Facebook will get shared when authorizing access to other= applications.=C2=A0 You can click on each of the possibilities and strip i= t down.=C2=A0 It appears to me that Facebook is managing that, so in your c= ase, I *think* (and am open to be corrected) that LinkedIn needs to do some= thing similar.=C2=A0 Without those options, I also cancel out and just don&= #39;t use the other app. =C2=A0

Thanks,
= Kathleen

On Wed, Jul 22, 2015 at 3:44 AM, Barry Leiba <barryleiba@computer= .org> wrote:
Yesterday, som= eone sent me a link to some presentation slides that
he'd posted to SlideShare.=C2=A0 I looked at them, and wanted to downlo= ad
them as a PDF.=C2=A0 In order to let me do that, SlideShare wants me to log=
in.=C2=A0 It gives me the options to log in via LinkedIn or Facebook.=C2=A0= As
I'm one of the three people in the world without a Facebook account, I<= br> clicked "LinkedIn".=C2=A0 That got me an OAuth authorization scre= en, image
attached.

Now, I don't know if this is SlideShare's fault for asking for too<= br> much, or LinkedIn's fault for not providing enough granularity for
requests, but just LOOK at that list of what I'd be giving SlideShare access to.=C2=A0 The first few make sense: read my profile (the whole thing=
or pieces of it, including contact information).=C2=A0 But... access to my<= br> connections?=C2=A0 I'm not sure they'd like my exposing their ident= ities to
SlideShare.=C2=A0 Access to my private messages?=C2=A0 EDIT MY PROFILE?=C2= =A0 Srsly?

Of course, this isn't the fault of the OAuth protocol, really (though one might argue that there's not enough guidance provided).=C2=A0 But,<= br> really, with implementations like this, I have to wonder what they're thinking.

I clicked "Cancel", of course, and asked the slide creator to sen= d me a PDF.

Barry

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




--

Best regards,
Kathleen
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth
____________= ___________________________________
OAuth mailing list
OAuth@ietf.= org
https://www.ietf.org/mailman/listinfo/oauth

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




--
Mac= iej Machulak
email: maciej.machulak@gmail.com
mobile: +44 7999 606 7= 67 (UK)
mobile: +48 602 45 31 66 (PL)


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




--
Nat= Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en<= /div>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth



=
--
Nat Sakimura (=3Dnat)
Chair= man, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--94eb2c095d805b924e051b737f4d-- From nobody Wed Jul 22 04:49:23 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07921B2C62 for ; Wed, 22 Jul 2015 04:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsyFMcCjB_oo for ; Wed, 22 Jul 2015 04:49:19 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A43C61B2C40 for ; Wed, 22 Jul 2015 04:49:18 -0700 (PDT) X-AuditID: 1209190d-f796f6d000005314-c1-55af833d841d Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 1F.AE.21268.D338FA55; Wed, 22 Jul 2015 07:49:17 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t6MBnG4b020556; Wed, 22 Jul 2015 07:49:16 -0400 Received: from [10.55.3.183] ([31.30.2.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t6MBnCje026342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Jul 2015 07:49:14 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_38DD1EEB-121E-476A-BA61-B8361EA2B3B5" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Justin Richer In-Reply-To: Date: Wed, 22 Jul 2015 13:49:11 +0200 Message-Id: <750B8FEF-355B-49D2-80D7-C6F05D4039A2@mit.edu> References: <84019235-22F4-4BBA-8A45-558E7C65D5D1@mit.edu> <6103DF00-147C-469E-B360-93F365599F3F@mit.edu> <941211DE-F224-435D-8206-42ED464A9F20@ve7jtb.com> To: Nat Sakimura X-Mailer: Apple Mail (2.2102) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCKsWRmVeSWpSXmKPExsUixCmqrGvbvD7UYEabnMWhxZdYLU6+fcVm cebWCkaL1Xf/sjmweLSs6mX22DnrLrvHkiU/mTxu397IEsASxWWTkpqTWZZapG+XwJUxdfYP xoL2DYwV/8+/Y21g3DuDsYuRk0NCwETi397JULaYxIV769m6GLk4hAQWM0l033zBBOFsZJSY euQCK4SzgkniRetKVpAWZoEEib9NK8DaeQX0JHrOfQGzhQUMJdbOncgCYrMJqEpMX9PCBGJz CgRKLL25gw3EZgGKn1l6kBFiTqXE6Xn97BBzrCR2Pz0EtXkZi8Te5tdgzSJADU17D7NC3Cor sfVNK9MERoFZSO6YheQOiLi2xLKFr5khbE2J/d3LWTDFNSQ6v01kXcDItopRNiW3Sjc3MTOn ODVZtzg5MS8vtUjXSC83s0QvNaV0EyM4QiR5dzC+O6h0iFGAg1GJh3fC0XWhQqyJZcWVuYcY JTmYlER57zWsDxXiS8pPqcxILM6ILyrNSS0+xCjBwawkwhtWCZTjTUmsrEotyodJSXOwKInz bvrBFyIkkJ5YkpqdmlqQWgSTleHgUJLg/dgI1ChYlJqeWpGWmVOCkGbi4AQZzgM0XKMJZHhx QWJucWY6RP4Uoy7Hsbk31jIJseTl56VKifM+BxkkAFKUUZoHNweW2F4xigO9JcybDzKKB5gU 4Sa9AlrCBLTk1qw1IEtKEhFSUg2M1c9E8zZ/cZ0c/unul4qKk3mFgRv2zFCcZZvps81o1o+j O7cqBW9M233uge/+jPe282a5VvvUutyqrHJNzw8+uWdiqbPzt+v3A/sCFcqy52mu1tLdxOuT GT5HjnGj9Y3aZwdzHiQt2rY1sNLH6TavxwqPyYKT2fkb/K4tzy2J4xYPWc5Q9futEktxRqKh FnNRcSIAhZUVSEcDAAA= Archived-At: Cc: Barry Leiba , "" Subject: Re: [OAUTH-WG] OAuth implementation fail X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 11:49:22 -0000 --Apple-Mail=_38DD1EEB-121E-476A-BA61-B8361EA2B3B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This may be a better fit for another article on = http://oauth.net/articles/ instead of a WG = document. =E2=80=94 Justin > On Jul 22, 2015, at 11:35 AM, Nat Sakimura wrote: >=20 > IMHO, returning everything if scope is empty is a violation of the = collection minimization principle. =46rom the privacy by Design point of = view, a lazy programmer sending an empty request should not cause the = maximal data returned.=20 >=20 > Now, as to the spec change is concerned, I agree with John that it is = not required.=20 > However, a Best practice document would probably help the developers.=20= >=20 > Nat >=20 > 2015-07-22 11:19 GMT+02:00 John Bradley >: > Slideshare did register all of those scopes as ones the client could = ask for. >=20 > Interpreting no scopes as all the ones the client has set as the ones = it wants is probably not unreasonable. >=20 > The problem is a combination of Slideshare over asking, perhaps = because they don=E2=80=99t understand the default behaviour, and = LinkedIn now allowing only some of the scopes to be returned. >=20 > I think people are moving back to allowing people to deselect scopes. = In Android m you can now deselect scopes that apps request, both at = installation and after. >=20 > One argument that people have put forward is that RP will ask for the = minimum set of scopes to encourage the person to consent. However it = seems that many RP decide to grab the maximum permissions on the grounds = that people agree to it. >=20 > I don=E2=80=99t know that any spec change is required, but perhaps = some sort of education is. >=20 > If users decline all on a regular basis then the RP will be motivated = to change. >=20 > John B. >=20 >> On Jul 22, 2015, at 11:08 AM, Nat Sakimura > wrote: >>=20 >> Wow, that's the very opposite of Privacy by Design/Default = recommendation.=20 >>=20 >>=20 >> 2015-07-22 11:06 GMT+02:00 Justin Richer >: >> According to the LinkedIn docs, that means they get all the scopes = that they registered for. >>=20 >> =E2=80=94 Justin >>=20 >>> On Jul 22, 2015, at 10:59 AM, Maciej Machulak = > wrote: >>>=20 >>> It seems that they don't ask for scopes.=20 >>>=20 >>> The parameter is left blank: scope=3D >>>=20 >>> Kind regards, >>> Maciej >>>=20 >>> On 22 July 2015 at 10:26, Phil Hunt > wrote: >>> Do they explicitly ask for those scopes? Or do they leave scope to = default that way.=20 >>>=20 >>> Phil >>>=20 >>> On Jul 22, 2015, at 10:22, Justin Richer > wrote: >>>=20 >>>> This is a pretty clear case of SlideShare trying to grab too much. = The LinkedIn API (which is their own proprietary thing, not OpenID = Connect) does separate all the permissions into different scopes. = However, the SlideShare app is asking for all of them, and LinkedIn = doesn=E2=80=99t let you uncheck any boxes on the authorization screen.=20= >>>>=20 >>>> FWIW, the reason they want write access to your profile is to = automatically add new SlideShare presentations that you upload to your = LinkedIn profile page. You should still have the option of turning that = off, or of turning on that functionality later. >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>> On Jul 22, 2015, at 9:49 AM, Kathleen Moriarty = > wrote: >>>>>=20 >>>>> Hey Barry, >>>>>=20 >>>>> =46rom my observations with Facebook, it now has options added for = you to select what resources from Facebook will get shared when = authorizing access to other applications. You can click on each of the = possibilities and strip it down. It appears to me that Facebook is = managing that, so in your case, I *think* (and am open to be corrected) = that LinkedIn needs to do something similar. Without those options, I = also cancel out and just don't use the other app. =20 >>>>>=20 >>>>> Thanks, >>>>> Kathleen >>>>>=20 >>>>> On Wed, Jul 22, 2015 at 3:44 AM, Barry Leiba = > wrote: >>>>> Yesterday, someone sent me a link to some presentation slides that >>>>> he'd posted to SlideShare. I looked at them, and wanted to = download >>>>> them as a PDF. In order to let me do that, SlideShare wants me to = log >>>>> in. It gives me the options to log in via LinkedIn or Facebook. = As >>>>> I'm one of the three people in the world without a Facebook = account, I >>>>> clicked "LinkedIn". That got me an OAuth authorization screen, = image >>>>> attached. >>>>>=20 >>>>> Now, I don't know if this is SlideShare's fault for asking for too >>>>> much, or LinkedIn's fault for not providing enough granularity for >>>>> requests, but just LOOK at that list of what I'd be giving = SlideShare >>>>> access to. The first few make sense: read my profile (the whole = thing >>>>> or pieces of it, including contact information). But... access to = my >>>>> connections? I'm not sure they'd like my exposing their = identities to >>>>> SlideShare. Access to my private messages? EDIT MY PROFILE? = Srsly? >>>>>=20 >>>>> Of course, this isn't the fault of the OAuth protocol, really = (though >>>>> one might argue that there's not enough guidance provided). But, >>>>> really, with implementations like this, I have to wonder what = they're >>>>> thinking. >>>>>=20 >>>>> I clicked "Cancel", of course, and asked the slide creator to send = me a PDF. >>>>>=20 >>>>> Barry >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> --=20 >>>>>=20 >>>>> Best regards, >>>>> Kathleen >>>>> _______________________________________________ >>>>> 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 >>>=20 >>> --=20 >>> Maciej Machulak >>> email: maciej.machulak@gmail.com >>> mobile: +44 7999 606 767 (UK) >>> mobile: +48 602 45 31 66 (PL) >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >>=20 >>=20 >> --=20 >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en --Apple-Mail=_38DD1EEB-121E-476A-BA61-B8361EA2B3B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This may be a better fit for another article on http://oauth.net/articles/ instead of a WG = document.
 =E2=80=94 Justin

On = Jul 22, 2015, at 11:35 AM, Nat Sakimura <sakimura@gmail.com> = wrote:

IMHO, returning everything if = scope is empty is a violation of the collection minimization principle. = =46rom the privacy by Design point of view, a lazy programmer sending an = empty request should not cause the maximal data returned. 

Now, as to the spec = change is concerned, I agree with John that it is not = required. 
However, a Best practice document = would probably help the developers. 

Nat

2015-07-22= 11:19 GMT+02:00 John Bradley <ve7jtb@ve7jtb.com>:
Slideshare did register all of those scopes as ones the = client could ask for.

Interpreting no scopes as all the ones the client has set as = the ones it wants is probably not unreasonable.

The problem is a combination of = Slideshare over asking, perhaps because they don=E2=80=99t understand = the default behaviour,  and LinkedIn now allowing only some of the = scopes to be returned.

I think people are moving back to allowing people to deselect = scopes.   In Android m you can now deselect scopes that apps = request, both at installation and after.

One argument that people have put = forward is that RP will ask for the minimum set of scopes to encourage = the person to consent.   However it seems that many RP decide to = grab the maximum permissions on the grounds that people agree to = it.

I don=E2=80=99= t know that any spec change is required, but perhaps some sort of = education is.

If= users decline all on a regular basis then the RP will be motivated to = change.

John = B.

On Jul 22, 2015, at 11:08 AM, Nat Sakimura = <sakimura@gmail.com> wrote:

Wow, that's the very opposite of = Privacy by Design/Default recommendation. 


2015-07-22 11:06 GMT+02:00 Justin Richer <jricher@mit.edu>:
According to the LinkedIn = docs, that means they get all the scopes that they registered for.

 =E2=80=94 = Justin

On Jul 22, 2015, at 10:59 AM, Maciej Machulak = <maciej.machulak@gmail.com> wrote:

It seems that = they don't ask for scopes. 

The parameter is left blank: scope=3D

Kind regards,
Maciej

On 22 July 2015 at 10:26, Phil = Hunt <phil.hunt@oracle.com> wrote:
Do they explicitly ask for those scopes? Or = do they leave scope to default that way. 

Phil

On Jul 22, 2015, at 10:22, Justin Richer = <jricher@mit.edu> wrote:

This= is a pretty clear case of SlideShare trying to grab too much. The = LinkedIn API (which is their own proprietary thing, not OpenID Connect) = does separate all the permissions into different scopes. However, the = SlideShare app is asking for all of them, and LinkedIn doesn=E2=80=99t = let you uncheck any boxes on the authorization screen. 

FWIW, the reason they = want write access to your profile is to automatically add new SlideShare = presentations that you upload to your LinkedIn profile page. You should = still have the option of turning that off, or of turning on that = functionality later.

 =E2=80=94 Justin

On Jul = 22, 2015, at 9:49 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Hey Barry,

=46rom my observations = with Facebook, it now has options added for you to select what resources = from Facebook will get shared when authorizing access to other = applications.  You can click on each of the possibilities and strip = it down.  It appears to me that Facebook is managing that, so in = your case, I *think* (and am open to be corrected) that LinkedIn needs = to do something similar.  Without those options, I also cancel out = and just don't use the other app.  

Thanks,
Kathleen

On Wed, Jul 22, 2015 at 3:44 AM, = Barry Leiba <barryleiba@computer.org> wrote:
Yesterday, someone = sent me a link to some presentation slides that
he'd posted to SlideShare.  I looked at them, and wanted to = download
them as a PDF.  In order to let me do that, SlideShare wants me to = log
in.  It gives me the options to log in via LinkedIn or = Facebook.  As
I'm one of the three people in the world without a Facebook account, = I
clicked "LinkedIn".  That got me an OAuth authorization screen, = image
attached.

Now, I don't know if this is SlideShare's fault for asking for too
much, or LinkedIn's fault for not providing enough granularity for
requests, but just LOOK at that list of what I'd be giving SlideShare
access to.  The first few make sense: read my profile (the whole = thing
or pieces of it, including contact information).  But... access to = my
connections?  I'm not sure they'd like my exposing their identities = to
SlideShare.  Access to my private messages?  EDIT MY = PROFILE?  Srsly?

Of course, this isn't the fault of the OAuth protocol, really (though
one might argue that there's not enough guidance provided).  = But,
really, with implementations like this, I have to wonder what they're
thinking.

I clicked "Cancel", of course, and asked the slide creator to send me a = PDF.

Barry

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




--

Best= regards,
Kathleen
_______________________________________________
OAuth = mailing list
OAuth@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




--
Maciej Machulak
email: maciej.machulak@gmail.com
mobile: +44 7999 606 767 (UK)
mobile: +48 602 45 31 66 (PL)


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




--
Nat Sakimura (=3Dnat)
Chairman, OpenID = Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
=
= --Apple-Mail=_38DD1EEB-121E-476A-BA61-B8361EA2B3B5-- From nobody Wed Jul 22 04:55:07 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA49B1B30C9 for ; Wed, 22 Jul 2015 04:55: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkc6PblE34Vz for ; Wed, 22 Jul 2015 04:54: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 BF0171B30EB for ; Wed, 22 Jul 2015 04:52:55 -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 t6MBqsxR000308 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 Jul 2015 11:52:54 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 t6MBqrAb001891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 22 Jul 2015 11:52:53 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 t6MBqrLX021859; Wed, 22 Jul 2015 11:52:53 GMT Received: from dhcp-8ca9.meeting.ietf.org (/31.133.140.169) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 22 Jul 2015 04:52:51 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_FA02D193-B706-4EEE-ADC4-3BC5DDBB63DD" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Phil Hunt In-Reply-To: Date: Wed, 22 Jul 2015 13:52:48 +0200 Message-Id: <7FD47277-38B4-4F13-B73E-A120A47E7F08@oracle.com> References: <84019235-22F4-4BBA-8A45-558E7C65D5D1@mit.edu> <6103DF00-147C-469E-B360-93F365599F3F@mit.edu> <941211DE-F224-435D-8206-42ED464A9F20@ve7jtb.com> To: Nat Sakimura X-Mailer: Apple Mail (2.2102) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: Barry Leiba , "" Subject: Re: [OAUTH-WG] OAuth implementation fail X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 11:55:04 -0000 --Apple-Mail=_FA02D193-B706-4EEE-ADC4-3BC5DDBB63DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Agreed. I have heard it can be equally bad to pester the user every time a new = scope is needed. There=E2=80=99s a definite balancing problem. I don=E2=80=99t think this an OAuth issue; just a good user experience = issue. Phil @independentid www.independentid.com phil.hunt@oracle.com > On Jul 22, 2015, at 11:35 AM, Nat Sakimura wrote: >=20 > IMHO, returning everything if scope is empty is a violation of the = collection minimization principle. =46rom the privacy by Design point of = view, a lazy programmer sending an empty request should not cause the = maximal data returned.=20 >=20 > Now, as to the spec change is concerned, I agree with John that it is = not required.=20 > However, a Best practice document would probably help the developers.=20= >=20 > Nat >=20 > 2015-07-22 11:19 GMT+02:00 John Bradley >: > Slideshare did register all of those scopes as ones the client could = ask for. >=20 > Interpreting no scopes as all the ones the client has set as the ones = it wants is probably not unreasonable. >=20 > The problem is a combination of Slideshare over asking, perhaps = because they don=E2=80=99t understand the default behaviour, and = LinkedIn now allowing only some of the scopes to be returned. >=20 > I think people are moving back to allowing people to deselect scopes. = In Android m you can now deselect scopes that apps request, both at = installation and after. >=20 > One argument that people have put forward is that RP will ask for the = minimum set of scopes to encourage the person to consent. However it = seems that many RP decide to grab the maximum permissions on the grounds = that people agree to it. >=20 > I don=E2=80=99t know that any spec change is required, but perhaps = some sort of education is. >=20 > If users decline all on a regular basis then the RP will be motivated = to change. >=20 > John B. >=20 >> On Jul 22, 2015, at 11:08 AM, Nat Sakimura > wrote: >>=20 >> Wow, that's the very opposite of Privacy by Design/Default = recommendation.=20 >>=20 >>=20 >> 2015-07-22 11:06 GMT+02:00 Justin Richer >: >> According to the LinkedIn docs, that means they get all the scopes = that they registered for. >>=20 >> =E2=80=94 Justin >>=20 >>> On Jul 22, 2015, at 10:59 AM, Maciej Machulak = > wrote: >>>=20 >>> It seems that they don't ask for scopes.=20 >>>=20 >>> The parameter is left blank: scope=3D >>>=20 >>> Kind regards, >>> Maciej >>>=20 >>> On 22 July 2015 at 10:26, Phil Hunt > wrote: >>> Do they explicitly ask for those scopes? Or do they leave scope to = default that way.=20 >>>=20 >>> Phil >>>=20 >>> On Jul 22, 2015, at 10:22, Justin Richer > wrote: >>>=20 >>>> This is a pretty clear case of SlideShare trying to grab too much. = The LinkedIn API (which is their own proprietary thing, not OpenID = Connect) does separate all the permissions into different scopes. = However, the SlideShare app is asking for all of them, and LinkedIn = doesn=E2=80=99t let you uncheck any boxes on the authorization screen.=20= >>>>=20 >>>> FWIW, the reason they want write access to your profile is to = automatically add new SlideShare presentations that you upload to your = LinkedIn profile page. You should still have the option of turning that = off, or of turning on that functionality later. >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>> On Jul 22, 2015, at 9:49 AM, Kathleen Moriarty = > wrote: >>>>>=20 >>>>> Hey Barry, >>>>>=20 >>>>> =46rom my observations with Facebook, it now has options added for = you to select what resources from Facebook will get shared when = authorizing access to other applications. You can click on each of the = possibilities and strip it down. It appears to me that Facebook is = managing that, so in your case, I *think* (and am open to be corrected) = that LinkedIn needs to do something similar. Without those options, I = also cancel out and just don't use the other app. =20 >>>>>=20 >>>>> Thanks, >>>>> Kathleen >>>>>=20 >>>>> On Wed, Jul 22, 2015 at 3:44 AM, Barry Leiba = > wrote: >>>>> Yesterday, someone sent me a link to some presentation slides that >>>>> he'd posted to SlideShare. I looked at them, and wanted to = download >>>>> them as a PDF. In order to let me do that, SlideShare wants me to = log >>>>> in. It gives me the options to log in via LinkedIn or Facebook. = As >>>>> I'm one of the three people in the world without a Facebook = account, I >>>>> clicked "LinkedIn". That got me an OAuth authorization screen, = image >>>>> attached. >>>>>=20 >>>>> Now, I don't know if this is SlideShare's fault for asking for too >>>>> much, or LinkedIn's fault for not providing enough granularity for >>>>> requests, but just LOOK at that list of what I'd be giving = SlideShare >>>>> access to. The first few make sense: read my profile (the whole = thing >>>>> or pieces of it, including contact information). But... access to = my >>>>> connections? I'm not sure they'd like my exposing their = identities to >>>>> SlideShare. Access to my private messages? EDIT MY PROFILE? = Srsly? >>>>>=20 >>>>> Of course, this isn't the fault of the OAuth protocol, really = (though >>>>> one might argue that there's not enough guidance provided). But, >>>>> really, with implementations like this, I have to wonder what = they're >>>>> thinking. >>>>>=20 >>>>> I clicked "Cancel", of course, and asked the slide creator to send = me a PDF. >>>>>=20 >>>>> Barry >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> --=20 >>>>>=20 >>>>> Best regards, >>>>> Kathleen >>>>> _______________________________________________ >>>>> 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 >>>=20 >>> --=20 >>> Maciej Machulak >>> email: maciej.machulak@gmail.com >>> mobile: +44 7999 606 767 (UK) >>> mobile: +48 602 45 31 66 (PL) >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >>=20 >>=20 >> --=20 >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_FA02D193-B706-4EEE-ADC4-3BC5DDBB63DD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Agreed.

I = have heard it can be equally bad to pester the user every time a new = scope is needed.

There=E2=80=99s a definite balancing problem.

I don=E2=80=99t think = this an OAuth issue; just a good user experience issue.


On Jul 22, 2015, at 11:35 AM, Nat Sakimura <sakimura@gmail.com> = wrote:

IMHO, returning everything if scope is empty is a = violation of the collection minimization principle. =46rom the privacy = by Design point of view, a lazy programmer sending an empty request = should not cause the maximal data returned. 

Now, as to the spec change is = concerned, I agree with John that it is not required. 
However, a Best practice document would probably help the = developers. 

Nat

2015-07-22 11:19 GMT+02:00 John Bradley <ve7jtb@ve7jtb.com>:
Slideshare did register all of = those scopes as ones the client could ask for.

Interpreting no scopes as all the ones = the client has set as the ones it wants is probably not = unreasonable.

The problem is a combination of Slideshare over asking, = perhaps because they don=E2=80=99t understand the default behaviour, =  and LinkedIn now allowing only some of the scopes to be = returned.

I = think people are moving back to allowing people to deselect scopes. =   In Android m you can now deselect scopes that apps request, both = at installation and after.

One argument that people have put forward is that RP will ask = for the minimum set of scopes to encourage the person to consent.   = However it seems that many RP decide to grab the maximum permissions on = the grounds that people agree to it.

I don=E2=80=99t know that any spec = change is required, but perhaps some sort of education is.

If users decline all on = a regular basis then the RP will be motivated to change.

John B.

On Jul 22, 2015, at 11:08 AM, Nat Sakimura <sakimura@gmail.com> wrote:

Wow, that's the very opposite of = Privacy by Design/Default recommendation. 


2015-07-22 11:06 GMT+02:00 Justin Richer <jricher@mit.edu>:
According to the LinkedIn = docs, that means they get all the scopes that they registered for.

 =E2=80=94 = Justin

On Jul 22, 2015, at 10:59 AM, Maciej Machulak = <maciej.machulak@gmail.com> wrote:

It seems that = they don't ask for scopes. 

The parameter is left blank: scope=3D

Kind regards,
Maciej

On 22 July 2015 at 10:26, Phil = Hunt <phil.hunt@oracle.com> wrote:
Do they explicitly ask for those scopes? Or = do they leave scope to default that way. 

Phil

On Jul 22, 2015, at 10:22, Justin Richer = <jricher@mit.edu> wrote:

This= is a pretty clear case of SlideShare trying to grab too much. The = LinkedIn API (which is their own proprietary thing, not OpenID Connect) = does separate all the permissions into different scopes. However, the = SlideShare app is asking for all of them, and LinkedIn doesn=E2=80=99t = let you uncheck any boxes on the authorization screen. 

FWIW, the reason they = want write access to your profile is to automatically add new SlideShare = presentations that you upload to your LinkedIn profile page. You should = still have the option of turning that off, or of turning on that = functionality later.

 =E2=80=94 Justin

On Jul = 22, 2015, at 9:49 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Hey Barry,

=46rom my observations = with Facebook, it now has options added for you to select what resources = from Facebook will get shared when authorizing access to other = applications.  You can click on each of the possibilities and strip = it down.  It appears to me that Facebook is managing that, so in = your case, I *think* (and am open to be corrected) that LinkedIn needs = to do something similar.  Without those options, I also cancel out = and just don't use the other app.  

Thanks,
Kathleen

On Wed, Jul 22, 2015 at 3:44 AM, = Barry Leiba <barryleiba@computer.org> wrote:
Yesterday, someone = sent me a link to some presentation slides that
he'd posted to SlideShare.  I looked at them, and wanted to = download
them as a PDF.  In order to let me do that, SlideShare wants me to = log
in.  It gives me the options to log in via LinkedIn or = Facebook.  As
I'm one of the three people in the world without a Facebook account, = I
clicked "LinkedIn".  That got me an OAuth authorization screen, = image
attached.

Now, I don't know if this is SlideShare's fault for asking for too
much, or LinkedIn's fault for not providing enough granularity for
requests, but just LOOK at that list of what I'd be giving SlideShare
access to.  The first few make sense: read my profile (the whole = thing
or pieces of it, including contact information).  But... access to = my
connections?  I'm not sure they'd like my exposing their identities = to
SlideShare.  Access to my private messages?  EDIT MY = PROFILE?  Srsly?

Of course, this isn't the fault of the OAuth protocol, really (though
one might argue that there's not enough guidance provided).  = But,
really, with implementations like this, I have to wonder what they're
thinking.

I clicked "Cancel", of course, and asked the slide creator to send me a = PDF.

Barry

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




--

Best= regards,
Kathleen
_______________________________________________
OAuth = mailing list
OAuth@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




--
Maciej Machulak
email: maciej.machulak@gmail.com
mobile: +44 7999 606 767 (UK)
mobile: +48 602 45 31 66 (PL)


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




--
Nat Sakimura (=3Dnat)
Chairman, OpenID = Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
= _______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_FA02D193-B706-4EEE-ADC4-3BC5DDBB63DD-- From nobody Wed Jul 22 05:50:43 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 604801A1A6A for ; Wed, 22 Jul 2015 05:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c_fvcnQoMLp7 for ; Wed, 22 Jul 2015 05:50:39 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACF9E1A01F7 for ; Wed, 22 Jul 2015 05:50:38 -0700 (PDT) Received: by obre1 with SMTP id e1so133660771obr.1 for ; Wed, 22 Jul 2015 05:50:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pHuQ0IsDFWNUqIFNoyXx682jTIaNCImU0hGRkZXZjpE=; b=L0J0R+RFePPUhi077GBtKeYrpSpz3ibSXz0b+kQ8pmGZqy1/3eduUn+qWbHJl5qiZe xDxhDyUDkdGEKK2jxFUK50NWLZHuMsOFRwpwWjnSxarMCFQIY0o24mmWdlQf7RNtVRfp 2I6TCPq1TaE4X9A/7Wu27KC+RNZMnW3+UcVZcQgtAEpGkevVghTwLVunAbYpYuC9saer bL1O6BH3hG2PUo39e1IufcXAkhcZy8CP+zfWw7xGNU7aTdtv85+Xryl33BKZiBrLcrqY fkmnJ2PX+4zmX8Nz8UN28iDE2yo+giC9OHkohKHj2bF9dPu+8BAE4j0cDUpv6pVQJIWL c6FQ== MIME-Version: 1.0 X-Received: by 10.202.230.70 with SMTP id d67mr2181565oih.14.1437569438178; Wed, 22 Jul 2015 05:50:38 -0700 (PDT) Received: by 10.182.96.66 with HTTP; Wed, 22 Jul 2015 05:50:38 -0700 (PDT) In-Reply-To: <7FD47277-38B4-4F13-B73E-A120A47E7F08@oracle.com> References: <84019235-22F4-4BBA-8A45-558E7C65D5D1@mit.edu> <6103DF00-147C-469E-B360-93F365599F3F@mit.edu> <941211DE-F224-435D-8206-42ED464A9F20@ve7jtb.com> <7FD47277-38B4-4F13-B73E-A120A47E7F08@oracle.com> Date: Wed, 22 Jul 2015 14:50:38 +0200 Message-ID: From: Nat Sakimura To: Phil Hunt Content-Type: multipart/alternative; boundary=001a114075c6b3e6e2051b7637dd Archived-At: Cc: Barry Leiba , "" Subject: Re: [OAUTH-WG] OAuth implementation fail X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 12:50:42 -0000 --001a114075c6b3e6e2051b7637dd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think it would be good to have both a guideline informative RFC as well as the oauth.net blog entry, former being more "formal" in the way of writing while the later can be more readable one. Re: pestering factor -- Indeed, I am the one started to talk about "turning an internet dog into a Pavlov's dog" and agree that pestering the user too much is not good. As in EU DP Directive and forthcoming regulation, we should actually skip the dialogue if it falls into one of the "conditions for processing" (apart from the explicit consent condition). However, if it is asking something that is not required for the immediate processing, it should ask, and the user should be alerted that something fishy is happening. I am working on these notice and consent issues at ISO/IEC JTC 1/SC 27/WG 5 so if you are interested, please do join :-) Nat 2015-07-22 13:52 GMT+02:00 Phil Hunt : > Agreed. > > I have heard it can be equally bad to pester the user every time a new > scope is needed. > > There=E2=80=99s a definite balancing problem. > > I don=E2=80=99t think this an OAuth issue; just a good user experience is= sue. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > On Jul 22, 2015, at 11:35 AM, Nat Sakimura wrote: > > IMHO, returning everything if scope is empty is a violation of the > collection minimization principle. From the privacy by Design point of > view, a lazy programmer sending an empty request should not cause the > maximal data returned. > > Now, as to the spec change is concerned, I agree with John that it is not > required. > However, a Best practice document would probably help the developers. > > Nat > > 2015-07-22 11:19 GMT+02:00 John Bradley : > >> Slideshare did register all of those scopes as ones the client could ask >> for. >> >> Interpreting no scopes as all the ones the client has set as the ones it >> wants is probably not unreasonable. >> >> The problem is a combination of Slideshare over asking, perhaps because >> they don=E2=80=99t understand the default behaviour, and LinkedIn now a= llowing >> only some of the scopes to be returned. >> >> I think people are moving back to allowing people to deselect scopes. >> In Android m you can now deselect scopes that apps request, both at >> installation and after. >> >> One argument that people have put forward is that RP will ask for the >> minimum set of scopes to encourage the person to consent. However it >> seems that many RP decide to grab the maximum permissions on the grounds >> that people agree to it. >> >> I don=E2=80=99t know that any spec change is required, but perhaps some = sort of >> education is. >> >> If users decline all on a regular basis then the RP will be motivated to >> change. >> >> John B. >> >> On Jul 22, 2015, at 11:08 AM, Nat Sakimura wrote: >> >> Wow, that's the very opposite of Privacy by Design/Default >> recommendation. >> >> >> 2015-07-22 11:06 GMT+02:00 Justin Richer : >> >>> According to the LinkedIn docs, that means they get all the scopes that >>> they registered for. >>> >>> =E2=80=94 Justin >>> >>> On Jul 22, 2015, at 10:59 AM, Maciej Machulak >>> wrote: >>> >>> It seems that they don't ask for scopes. >>> >>> The parameter is left blank: scope=3D >>> >>> Kind regards, >>> Maciej >>> >>> On 22 July 2015 at 10:26, Phil Hunt wrote: >>> >>>> Do they explicitly ask for those scopes? Or do they leave scope to >>>> default that way. >>>> >>>> Phil >>>> >>>> On Jul 22, 2015, at 10:22, Justin Richer wrote: >>>> >>>> This is a pretty clear case of SlideShare trying to grab too much. The >>>> LinkedIn API (which is their own proprietary thing, not OpenID Connect= ) >>>> does separate all the permissions into different scopes. However, the >>>> SlideShare app is asking for all of them, and LinkedIn doesn=E2=80=99t= let you >>>> uncheck any boxes on the authorization screen. >>>> >>>> FWIW, the reason they want write access to your profile is to >>>> automatically add new SlideShare presentations that you upload to your >>>> LinkedIn profile page. You should still have the option of turning tha= t >>>> off, or of turning on that functionality later. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Jul 22, 2015, at 9:49 AM, Kathleen Moriarty < >>>> kathleen.moriarty.ietf@gmail.com> wrote: >>>> >>>> Hey Barry, >>>> >>>> From my observations with Facebook, it now has options added for you t= o >>>> select what resources from Facebook will get shared when authorizing a= ccess >>>> to other applications. You can click on each of the possibilities and >>>> strip it down. It appears to me that Facebook is managing that, so in= your >>>> case, I *think* (and am open to be corrected) that LinkedIn needs to d= o >>>> something similar. Without those options, I also cancel out and just = don't >>>> use the other app. >>>> >>>> Thanks, >>>> Kathleen >>>> >>>> On Wed, Jul 22, 2015 at 3:44 AM, Barry Leiba >>>> wrote: >>>> >>>>> Yesterday, someone sent me a link to some presentation slides that >>>>> he'd posted to SlideShare. I looked at them, and wanted to download >>>>> them as a PDF. In order to let me do that, SlideShare wants me to lo= g >>>>> in. It gives me the options to log in via LinkedIn or Facebook. As >>>>> I'm one of the three people in the world without a Facebook account, = I >>>>> clicked "LinkedIn". That got me an OAuth authorization screen, image >>>>> attached. >>>>> >>>>> Now, I don't know if this is SlideShare's fault for asking for too >>>>> much, or LinkedIn's fault for not providing enough granularity for >>>>> requests, but just LOOK at that list of what I'd be giving SlideShare >>>>> access to. The first few make sense: read my profile (the whole thin= g >>>>> or pieces of it, including contact information). But... access to my >>>>> connections? I'm not sure they'd like my exposing their identities t= o >>>>> SlideShare. Access to my private messages? EDIT MY PROFILE? Srsly? >>>>> >>>>> Of course, this isn't the fault of the OAuth protocol, really (though >>>>> one might argue that there's not enough guidance provided). But, >>>>> really, with implementations like this, I have to wonder what they're >>>>> thinking. >>>>> >>>>> I clicked "Cancel", of course, and asked the slide creator to send me >>>>> a PDF. >>>>> >>>>> Barry >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> Best regards, >>>> Kathleen >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@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 >>>> >>>> >>> >>> >>> -- >>> Maciej Machulak >>> email: maciej.machulak@gmail.com >>> mobile: +44 7999 606 767 (UK) >>> mobile: +48 602 45 31 66 (PL) >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> >> -- >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > > > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a114075c6b3e6e2051b7637dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think it would be good to have both a guideline informat= ive RFC as well as the oauth.net blog entr= y, former being more "formal" in the way of writing while the lat= er can be more readable one.=C2=A0

Re: pestering factor = -- Indeed, I am the one started to talk about "turning an internet dog= into a Pavlov's dog" and agree that pestering the user too much i= s not good. As in EU DP Directive and forthcoming regulation, we should act= ually skip the dialogue if it falls into one of the "conditions for pr= ocessing" (apart from the explicit consent condition).=C2=A0

However, if it is asking something that is not required for= the immediate processing, it should ask, and the user should be alerted th= at something fishy is happening.=C2=A0

I am workin= g on these notice and consent issues at ISO/IEC JTC 1/SC 27/WG 5 so if you = are interested, please do join :-)

Nat
=

2015-07-22 13:52 = GMT+02:00 Phil Hunt <phil.hunt@oracle.com>:
Agreed.

I have heard it can be equally bad to pester the user every time a= new scope is needed.

There=E2=80=99s a definite b= alancing problem.

I don=E2=80=99t think this an OA= uth issue; just a good user experience issue.


On Ju= l 22, 2015, at 11:35 AM, Nat Sakimura <sakimura@gmail.com> wrote:

IMHO, returning everything if scope is empty is a violation of= the collection minimization principle. From the privacy by Design point of= view, a lazy programmer sending an empty request should not cause the maxi= mal data returned.=C2=A0

Now, as to the spec change is c= oncerned, I agree with John that it is not required.=C2=A0
Howeve= r, a Best practice document would probably help the developers.=C2=A0
=

Nat

2015-07-22 11:19 GMT+02:00 John Bradley <ve7jtb@ve7jtb.c= om>:
Slideshare did register all of those scopes as ones the clien= t could ask for.

Interpreting no scopes as all the ones = the client has set as the ones it wants is probably not unreasonable.
=

The problem is a combination of Slideshare over asking,= perhaps because they don=E2=80=99t understand the default behaviour, =C2= =A0and LinkedIn now allowing only some of the scopes to be returned.
<= div>
I think people are moving back to allowing people to des= elect scopes. =C2=A0 In Android m you can now deselect scopes that apps req= uest, both at installation and after.

One argument= that people have put forward is that RP will ask for the minimum set of sc= opes to encourage the person to consent. =C2=A0 However it seems that many = RP decide to grab the maximum permissions on the grounds that people agree = to it.

I don=E2=80=99t know that any spec change i= s required, but perhaps some sort of education is.

If users decline all on a regular basis then the RP will be motivated to c= hange.

John B.

=
On Jul 22, 2015, at 11:08 AM, Nat Sakim= ura <sakimura@gm= ail.com> wrote:

Wow, that's the v= ery opposite of Privacy by Design/Default recommendation.=C2=A0


2015-07-= 22 11:06 GMT+02:00 Justin Richer <jricher@mit.edu>:
According to th= e LinkedIn docs, that means they get all the scopes that they registered fo= r.

=C2=A0=E2=80=94 Justin<= /div>

O= n Jul 22, 2015, at 10:59 AM, Maciej Machulak <maciej.machulak@gmail.com> wrot= e:

It seems that they don't ask for scop= es.=C2=A0

The parameter is left blank: scope=3D

Kind regards,
Maciej

On 22 July 2015 at 10:26, Phil Hu= nt <phil.hunt@oracle.com> wrote:
Do they explicitly ask for those scopes? O= r do they leave scope to default that way.=C2=A0

Phil

On Jul 22, 2015, at 1= 0:22, Justin Richer <jricher@mit.edu> wrote:

This is a pretty clear case of SlideShare trying to grab too much. The Li= nkedIn API (which is their own proprietary thing, not OpenID Connect) does = separate all the permissions into different scopes. However, the SlideShare= app is asking for all of them, and LinkedIn doesn=E2=80=99t let you unchec= k any boxes on the authorization screen.=C2=A0

FWIW, the= reason they want write access to your profile is to automatically add new = SlideShare presentations that you upload to your LinkedIn profile page. You= should still have the option of turning that off, or of turning on that fu= nctionality later.

=C2=A0=E2=80=94 Justin

On Jul 22, 2015, at 9:49 AM, Kath= leen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

=
Hey Barry,

From my observations with Fa= cebook, it now has options added for you to select what resources from Face= book will get shared when authorizing access to other applications.=C2=A0 Y= ou can click on each of the possibilities and strip it down.=C2=A0 It appea= rs to me that Facebook is managing that, so in your case, I *think* (and am= open to be corrected) that LinkedIn needs to do something similar.=C2=A0 W= ithout those options, I also cancel out and just don't use the other ap= p. =C2=A0

Thanks,
Kathleen

On Wed, Jul 22, 201= 5 at 3:44 AM, Barry Leiba <barryleiba@computer.org> wr= ote:
Yesterday, someone sent me a link to= some presentation slides that
he'd posted to SlideShare.=C2=A0 I looked at them, and wanted to downlo= ad
them as a PDF.=C2=A0 In order to let me do that, SlideShare wants me to log=
in.=C2=A0 It gives me the options to log in via LinkedIn or Facebook.=C2=A0= As
I'm one of the three people in the world without a Facebook account, I<= br> clicked "LinkedIn".=C2=A0 That got me an OAuth authorization scre= en, image
attached.

Now, I don't know if this is SlideShare's fault for asking for too<= br> much, or LinkedIn's fault for not providing enough granularity for
requests, but just LOOK at that list of what I'd be giving SlideShare access to.=C2=A0 The first few make sense: read my profile (the whole thing=
or pieces of it, including contact information).=C2=A0 But... access to my<= br> connections?=C2=A0 I'm not sure they'd like my exposing their ident= ities to
SlideShare.=C2=A0 Access to my private messages?=C2=A0 EDIT MY PROFILE?=C2= =A0 Srsly?

Of course, this isn't the fault of the OAuth protocol, really (though one might argue that there's not enough guidance provided).=C2=A0 But,<= br> really, with implementations like this, I have to wonder what they're thinking.

I clicked "Cancel", of course, and asked the slide creator to sen= d me a PDF.

Barry

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




--

Best regards,
Kathleen
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth
____________= ___________________________________
OAuth mailing list
OAuth@ietf.= org
https://www.ietf.org/mailman/listinfo/oauth

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




--
Mac= iej Machulak
email: maciej.machulak@gmail.com
mobile: +44 7999 606 7= 67 (UK)
mobile: +48 602 45 31 66 (PL)


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




--
Nat= Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en<= /div>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth



=
--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
= http://nat.sakimura.= org/
@_nat_en
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth



=
--
Nat Sakimura (=3Dnat)
Chair= man, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--001a114075c6b3e6e2051b7637dd-- From nobody Wed Jul 22 06:01:51 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0151B1B2C62 for ; Wed, 22 Jul 2015 06:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nd91_F6jTydO for ; Wed, 22 Jul 2015 06:01:46 -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 443991B3330 for ; Wed, 22 Jul 2015 06:01:45 -0700 (PDT) Received: by qgy5 with SMTP id 5so101954188qgy.3 for ; Wed, 22 Jul 2015 06:01:44 -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:content-type; bh=yFG5pVA3IR9S2okimmctkh25KhmzaZkIDt8c9vT17dA=; b=N+tYQoIhmIhjQCCcmDKY2pS9Gw24hRbj4jyaBLJPUruf1tMhc6Ibk/XwKxS/9udCBR eyNVJqSfqq6ATTkNs3GmcJAdeId80mvhOB75f/+GJxrNS4OAJJwZLHVgKpjlm55Y0Um1 izeCEBoN9dQFh+biWKr7TxjlLocrOdWeUPOnBN+S0xBzR3IGqtgRhNs0OgXRpwOK7J3L +28jSX3nGXKUshcH0v/v2wxgyVCZROvMfLP7n5U4oBP/mUgcLL9pfJKSFk1oqGpC+fv9 JB9ivVzpygo7DCYPWCuwkTUimnks80gLUVvN5F+3gX3OsRMpMdlTDytgxhH5QUj76el4 Li0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yFG5pVA3IR9S2okimmctkh25KhmzaZkIDt8c9vT17dA=; b=UnRHNBTr0Dtlome3mqd+sww/j+ln1BOppCdQbNN8QbH7nl0TL/AU/ZXk6rcwQphbNt 4TD9Ndh5Wz0pWZK9/60qnAcyviXv9Zed6H7hKou71yEJStA5NdBYNLTBW0potL5SYBO8 by3uTdi5lH16UKDnmy8TPXrKOyStuLq2FATE9cg7md3MexEJIiLW/JGyN2V005bne03l 2YMQvne+MJVrdKTIFk2hhSRV2vNuuo/mP+QBr1GO3kio9F18/YW8pQ3FAp6koMEoIgN4 Faa/tl6FDE43OqfEWx8H1f4pNkPBI5At5AyvU98oogztDTxHxJs/BwqUFDdq47Fn/528 K3oA== X-Gm-Message-State: ALoCoQld/tIy2SOQmZiILAQpRZXrIgqRni2gphL+k6JeaSklV2YZLsUbI3Dpu3M5aEzaCTY/wiQ5 X-Received: by 10.140.108.130 with SMTP id j2mr3347942qgf.83.1437570104444; Wed, 22 Jul 2015 06:01:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.19.98 with HTTP; Wed, 22 Jul 2015 06:01:24 -0700 (PDT) In-Reply-To: References: <84019235-22F4-4BBA-8A45-558E7C65D5D1@mit.edu> <6103DF00-147C-469E-B360-93F365599F3F@mit.edu> <941211DE-F224-435D-8206-42ED464A9F20@ve7jtb.com> <7FD47277-38B4-4F13-B73E-A120A47E7F08@oracle.com> From: William Denniss Date: Wed, 22 Jul 2015 15:01:24 +0200 Message-ID: To: Nat Sakimura Content-Type: multipart/alternative; boundary=001a113abaa06a8051051b765ff1 Archived-At: Cc: Barry Leiba , "" Subject: Re: [OAUTH-WG] OAuth implementation fail X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 13:01:50 -0000 --001a113abaa06a8051051b765ff1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On the pestering topic, one way that can be avoided is by using incremental auth to ask for permissions just-in-time. That pattern holds up when new scopes are required for new features. By contextualising the permission ask, it likely leads to higher conversion rates as users can figure out why the information is being requested, and by being optional the cost of denying the permissions is not so great (unlike when sign is prevented through user rejection). Permission screens that ask for the kitchen sink just to sign you in are the death of identity federation. On Wed, Jul 22, 2015 at 2:50 PM, Nat Sakimura wrote: > I think it would be good to have both a guideline informative RFC as well > as the oauth.net blog entry, former being more "formal" in the way of > writing while the later can be more readable one. > > Re: pestering factor -- Indeed, I am the one started to talk about > "turning an internet dog into a Pavlov's dog" and agree that pestering th= e > user too much is not good. As in EU DP Directive and forthcoming > regulation, we should actually skip the dialogue if it falls into one of > the "conditions for processing" (apart from the explicit consent > condition). > > However, if it is asking something that is not required for the immediate > processing, it should ask, and the user should be alerted that something > fishy is happening. > > I am working on these notice and consent issues at ISO/IEC JTC 1/SC 27/WG > 5 so if you are interested, please do join :-) > > Nat > > 2015-07-22 13:52 GMT+02:00 Phil Hunt : > >> Agreed. >> >> I have heard it can be equally bad to pester the user every time a new >> scope is needed. >> >> There=E2=80=99s a definite balancing problem. >> >> I don=E2=80=99t think this an OAuth issue; just a good user experience i= ssue. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> On Jul 22, 2015, at 11:35 AM, Nat Sakimura wrote: >> >> IMHO, returning everything if scope is empty is a violation of the >> collection minimization principle. From the privacy by Design point of >> view, a lazy programmer sending an empty request should not cause the >> maximal data returned. >> >> Now, as to the spec change is concerned, I agree with John that it is no= t >> required. >> However, a Best practice document would probably help the developers. >> >> Nat >> >> 2015-07-22 11:19 GMT+02:00 John Bradley : >> >>> Slideshare did register all of those scopes as ones the client could as= k >>> for. >>> >>> Interpreting no scopes as all the ones the client has set as the ones i= t >>> wants is probably not unreasonable. >>> >>> The problem is a combination of Slideshare over asking, perhaps because >>> they don=E2=80=99t understand the default behaviour, and LinkedIn now = allowing >>> only some of the scopes to be returned. >>> >>> I think people are moving back to allowing people to deselect scopes. >>> In Android m you can now deselect scopes that apps request, both at >>> installation and after. >>> >>> One argument that people have put forward is that RP will ask for the >>> minimum set of scopes to encourage the person to consent. However it >>> seems that many RP decide to grab the maximum permissions on the ground= s >>> that people agree to it. >>> >>> I don=E2=80=99t know that any spec change is required, but perhaps some= sort of >>> education is. >>> >>> If users decline all on a regular basis then the RP will be motivated t= o >>> change. >>> >>> John B. >>> >>> On Jul 22, 2015, at 11:08 AM, Nat Sakimura wrote: >>> >>> Wow, that's the very opposite of Privacy by Design/Default >>> recommendation. >>> >>> >>> 2015-07-22 11:06 GMT+02:00 Justin Richer : >>> >>>> According to the LinkedIn docs, that means they get all the scopes tha= t >>>> they registered for. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Jul 22, 2015, at 10:59 AM, Maciej Machulak < >>>> maciej.machulak@gmail.com> wrote: >>>> >>>> It seems that they don't ask for scopes. >>>> >>>> The parameter is left blank: scope=3D >>>> >>>> Kind regards, >>>> Maciej >>>> >>>> On 22 July 2015 at 10:26, Phil Hunt wrote: >>>> >>>>> Do they explicitly ask for those scopes? Or do they leave scope to >>>>> default that way. >>>>> >>>>> Phil >>>>> >>>>> On Jul 22, 2015, at 10:22, Justin Richer wrote: >>>>> >>>>> This is a pretty clear case of SlideShare trying to grab too much. Th= e >>>>> LinkedIn API (which is their own proprietary thing, not OpenID Connec= t) >>>>> does separate all the permissions into different scopes. However, the >>>>> SlideShare app is asking for all of them, and LinkedIn doesn=E2=80=99= t let you >>>>> uncheck any boxes on the authorization screen. >>>>> >>>>> FWIW, the reason they want write access to your profile is to >>>>> automatically add new SlideShare presentations that you upload to you= r >>>>> LinkedIn profile page. You should still have the option of turning th= at >>>>> off, or of turning on that functionality later. >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> On Jul 22, 2015, at 9:49 AM, Kathleen Moriarty < >>>>> kathleen.moriarty.ietf@gmail.com> wrote: >>>>> >>>>> Hey Barry, >>>>> >>>>> From my observations with Facebook, it now has options added for you >>>>> to select what resources from Facebook will get shared when authorizi= ng >>>>> access to other applications. You can click on each of the possibili= ties >>>>> and strip it down. It appears to me that Facebook is managing that, = so in >>>>> your case, I *think* (and am open to be corrected) that LinkedIn need= s to >>>>> do something similar. Without those options, I also cancel out and j= ust >>>>> don't use the other app. >>>>> >>>>> Thanks, >>>>> Kathleen >>>>> >>>>> On Wed, Jul 22, 2015 at 3:44 AM, Barry Leiba >>>>> wrote: >>>>> >>>>>> Yesterday, someone sent me a link to some presentation slides that >>>>>> he'd posted to SlideShare. I looked at them, and wanted to download >>>>>> them as a PDF. In order to let me do that, SlideShare wants me to l= og >>>>>> in. It gives me the options to log in via LinkedIn or Facebook. As >>>>>> I'm one of the three people in the world without a Facebook account,= I >>>>>> clicked "LinkedIn". That got me an OAuth authorization screen, imag= e >>>>>> attached. >>>>>> >>>>>> Now, I don't know if this is SlideShare's fault for asking for too >>>>>> much, or LinkedIn's fault for not providing enough granularity for >>>>>> requests, but just LOOK at that list of what I'd be giving SlideShar= e >>>>>> access to. The first few make sense: read my profile (the whole thi= ng >>>>>> or pieces of it, including contact information). But... access to m= y >>>>>> connections? I'm not sure they'd like my exposing their identities = to >>>>>> SlideShare. Access to my private messages? EDIT MY PROFILE? Srsly= ? >>>>>> >>>>>> Of course, this isn't the fault of the OAuth protocol, really (thoug= h >>>>>> one might argue that there's not enough guidance provided). But, >>>>>> really, with implementations like this, I have to wonder what they'r= e >>>>>> thinking. >>>>>> >>>>>> I clicked "Cancel", of course, and asked the slide creator to send m= e >>>>>> a PDF. >>>>>> >>>>>> Barry >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Best regards, >>>>> Kathleen >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@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 >>>>> >>>>> >>>> >>>> >>>> -- >>>> Maciej Machulak >>>> email: maciej.machulak@gmail.com >>>> mobile: +44 7999 606 767 (UK) >>>> mobile: +48 602 45 31 66 (PL) >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>> >>> >>> -- >>> Nat Sakimura (=3Dnat) >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >> >> >> -- >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > > > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a113abaa06a8051051b765ff1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On the pestering topic, one way that can be avoided is by = using incremental auth to ask for permissions just-in-time. That pattern ho= lds up when new scopes are required for new features.=C2=A0 By contextualis= ing the permission ask, it likely leads to higher conversion rates as users= can figure out why the information is being requested, and by being option= al the cost of denying the permissions is not so great (unlike when sign is= prevented through user rejection).

Permission screens t= hat ask for the kitchen sink just to sign you in are the death of identity = federation.

On Wed, Jul 22, 2015 at 2:50 PM, Nat Sakimura <<= a href=3D"mailto:sakimura@gmail.com" target=3D"_blank">sakimura@gmail.com> wrote:
I t= hink it would be good to have both a guideline informative RFC as well as t= he oauth.net blog entry,= former being more "formal" in the way of writing while the later= can be more readable one.=C2=A0

Re: pestering factor --= Indeed, I am the one started to talk about "turning an internet dog i= nto a Pavlov's dog" and agree that pestering the user too much is = not good. As in EU DP Directive and forthcoming regulation, we should actua= lly skip the dialogue if it falls into one of the "conditions for proc= essing" (apart from the explicit consent condition).=C2=A0
<= br>
However, if it is asking something that is not required for t= he immediate processing, it should ask, and the user should be alerted that= something fishy is happening.=C2=A0

I am working = on these notice and consent issues at ISO/IEC JTC 1/SC 27/WG 5 so if you ar= e interested, please do join :-)

Nat

2015-07-22 13:52 GMT+02:00 Phil Hunt <phil.hunt@oracle.com= >:
Agreed.

I have heard it can be equally bad to pe= ster the user every time a new scope is needed.

Th= ere=E2=80=99s a definite balancing problem.

I don= =E2=80=99t think this an OAuth issue; just a good user experience issue.


On Jul 22, 2015, a= t 11:35 AM, Nat Sakimura <sakimura@gmail.com> wrote:

IMHO, returning everything if scope is empty is a violation of the collec= tion minimization principle. From the privacy by Design point of view, a la= zy programmer sending an empty request should not cause the maximal data re= turned.=C2=A0

Now, as to the spec change is concerned, I= agree with John that it is not required.=C2=A0
However, a Best p= ractice document would probably help the developers.=C2=A0

Nat

2015-07-22 11:19 GMT+02:00 John Bradley <ve7jtb@ve7jtb.com><= /span>:
Slideshare did register all of those scopes as ones the client could ask= for.

Interpreting no scopes as all the ones the client = has set as the ones it wants is probably not unreasonable.

The problem is a combination of Slideshare over asking, perhaps be= cause they don=E2=80=99t understand the default behaviour, =C2=A0and Linked= In now allowing only some of the scopes to be returned.

I think people are moving back to allowing people to deselect scopes.= =C2=A0 In Android m you can now deselect scopes that apps request, both at= installation and after.

One argument that people = have put forward is that RP will ask for the minimum set of scopes to encou= rage the person to consent. =C2=A0 However it seems that many RP decide to = grab the maximum permissions on the grounds that people agree to it.
<= div>
I don=E2=80=99t know that any spec change is required, b= ut perhaps some sort of education is.

If users dec= line all on a regular basis then the RP will be motivated to change.
<= div>
John B.

On Jul 22, 2015, at 11:08 AM, Nat Sakimura <sakimura@gmail.com&g= t; wrote:

Wow, that's the very opposite = of Privacy by Design/Default recommendation.=C2=A0


2015-07-22 11:06 GMT+= 02:00 Justin Richer <jricher@mit.edu>:
According to the LinkedIn do= cs, that means they get all the scopes that they registered for.

=C2=A0=E2=80=94 Justin
<= /span>

On Jul 22, 201= 5, at 10:59 AM, Maciej Machulak <maciej.machulak@gmail.com> wrote:

<= div>
It seems that they don't ask for scopes.=C2=A0
The parameter is left blank: scope=3D

<= div>Kind regards,
Maciej
On 22 July 2015 at 10:26, Phil Hunt <phil= .hunt@oracle.com> wrote:
Do they explicitly ask for those scopes? Or do they le= ave scope to default that way.=C2=A0

P= hil

On Jul 22, 2015, at 10:22, Justin= Richer <jricher@mi= t.edu> wrote:

This is a = pretty clear case of SlideShare trying to grab too much. The LinkedIn API (= which is their own proprietary thing, not OpenID Connect) does separate all= the permissions into different scopes. However, the SlideShare app is aski= ng for all of them, and LinkedIn doesn=E2=80=99t let you uncheck any boxes = on the authorization screen.=C2=A0

FWIW, the reason they= want write access to your profile is to automatically add new SlideShare p= resentations that you upload to your LinkedIn profile page. You should stil= l have the option of turning that off, or of turning on that functionality = later.

=C2=A0=E2=80=94 Justin

<= blockquote type=3D"cite">
On Jul 22, 2015, at 9:49 AM, Kathleen Moriart= y <kathleen.moriarty.ietf@gmail.com> wrote:

Hey Barry,

From my observations with Facebook, it n= ow has options added for you to select what resources from Facebook will ge= t shared when authorizing access to other applications.=C2=A0 You can click= on each of the possibilities and strip it down.=C2=A0 It appears to me tha= t Facebook is managing that, so in your case, I *think* (and am open to be = corrected) that LinkedIn needs to do something similar.=C2=A0 Without those= options, I also cancel out and just don't use the other app. =C2=A0

Thanks,
Kathleen

On Wed, Jul 22, 2015 at 3:44 AM= , Barry Leiba <barryleiba@computer.org> wrote:
Yesterday, someone sent me a link to some presen= tation slides that
he'd posted to SlideShare.=C2=A0 I looked at them, and wanted to downlo= ad
them as a PDF.=C2=A0 In order to let me do that, SlideShare wants me to log=
in.=C2=A0 It gives me the options to log in via LinkedIn or Facebook.=C2=A0= As
I'm one of the three people in the world without a Facebook account, I<= br> clicked "LinkedIn".=C2=A0 That got me an OAuth authorization scre= en, image
attached.

Now, I don't know if this is SlideShare's fault for asking for too<= br> much, or LinkedIn's fault for not providing enough granularity for
requests, but just LOOK at that list of what I'd be giving SlideShare access to.=C2=A0 The first few make sense: read my profile (the whole thing=
or pieces of it, including contact information).=C2=A0 But... access to my<= br> connections?=C2=A0 I'm not sure they'd like my exposing their ident= ities to
SlideShare.=C2=A0 Access to my private messages?=C2=A0 EDIT MY PROFILE?=C2= =A0 Srsly?

Of course, this isn't the fault of the OAuth protocol, really (though one might argue that there's not enough guidance provided).=C2=A0 But,<= br> really, with implementations like this, I have to wonder what they're thinking.

I clicked "Cancel", of course, and asked the slide creator to sen= d me a PDF.

Barry

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




--

Best regards,
Kathleen
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth
____________= ___________________________________
OAuth mailing list
OAuth@ietf.= org
https://www.ietf.org/mailman/listinfo/oauth

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




--
Mac= iej Machulak
email: maciej.machulak@gmail.com
mobile: +44 7999 606 7= 67 (UK)
mobile: +48 602 45 31 66 (PL)


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




--
Nat= Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en<= /div>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth



=
--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
= http://nat.sakimura.= org/
@_nat_en
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth



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

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


--001a113abaa06a8051051b765ff1-- From nobody Wed Jul 22 06:05:18 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D351A011D for ; Wed, 22 Jul 2015 06:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbOsRTN4JNFQ for ; Wed, 22 Jul 2015 06:05:13 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EDF81A028A for ; Wed, 22 Jul 2015 06:05:13 -0700 (PDT) Received: by obnw1 with SMTP id w1so133446705obn.3 for ; Wed, 22 Jul 2015 06:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w/A7V5Jp+z8Wk8nLdPBRWPSXjTZrwt0O2PMUUJcpnoM=; b=Hq7viAUCfD0hbSVtTRI57fxh0qoxekYO4esBMQfTy+w76GijItDlRwbU5ByjsRc+jD zz61iGKFBFZkcnEY2YAczNblbLGL6nvkf02w4XDXkI34DTRUTTJ8uqu/tOUn9xvhEQ06 QMb/uVzmIZ7+UP1nMmKQxuil8Zrhb0eWF5RIh64oR+nlQPlJBHtkl37iNv579SLd67p0 j7xONtD6G7NAU3oJ0Mb5yI0H4X3yxm325Hsjr3u12Ot961/rtBl81k6hQH2H/H8D2HLS QaGi1Fazv879X1NnD1wQ5EP1wCD0T8Qwsv9Inq/22hOdhwLZUCnuk5TO7tXrZOLLqW8p uDBw== MIME-Version: 1.0 X-Received: by 10.182.210.165 with SMTP id mv5mr2315505obc.82.1437570312540; Wed, 22 Jul 2015 06:05:12 -0700 (PDT) Received: by 10.182.96.66 with HTTP; Wed, 22 Jul 2015 06:05:12 -0700 (PDT) In-Reply-To: References: <84019235-22F4-4BBA-8A45-558E7C65D5D1@mit.edu> <6103DF00-147C-469E-B360-93F365599F3F@mit.edu> <941211DE-F224-435D-8206-42ED464A9F20@ve7jtb.com> <7FD47277-38B4-4F13-B73E-A120A47E7F08@oracle.com> Date: Wed, 22 Jul 2015 15:05:12 +0200 Message-ID: From: Nat Sakimura To: William Denniss Content-Type: multipart/alternative; boundary=001a11c24894d19956051b766b80 Archived-At: Cc: Barry Leiba , "" Subject: Re: [OAUTH-WG] OAuth implementation fail X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 13:05:17 -0000 --001a11c24894d19956051b766b80 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 Is there any A/B test kind of statistics on the improvement of the conversion of the incremental authz over kitchen sink authz? If there is, it would be a very good data to show to those people who want everything upfront. Nat 2015-07-22 15:01 GMT+02:00 William Denniss : > On the pestering topic, one way that can be avoided is by using > incremental auth to ask for permissions just-in-time. That pattern holds = up > when new scopes are required for new features. By contextualising the > permission ask, it likely leads to higher conversion rates as users can > figure out why the information is being requested, and by being optional > the cost of denying the permissions is not so great (unlike when sign is > prevented through user rejection). > > Permission screens that ask for the kitchen sink just to sign you in are > the death of identity federation. > > On Wed, Jul 22, 2015 at 2:50 PM, Nat Sakimura wrote: > >> I think it would be good to have both a guideline informative RFC as wel= l >> as the oauth.net blog entry, former being more "formal" in the way of >> writing while the later can be more readable one. >> >> Re: pestering factor -- Indeed, I am the one started to talk about >> "turning an internet dog into a Pavlov's dog" and agree that pestering t= he >> user too much is not good. As in EU DP Directive and forthcoming >> regulation, we should actually skip the dialogue if it falls into one of >> the "conditions for processing" (apart from the explicit consent >> condition). >> >> However, if it is asking something that is not required for the immediat= e >> processing, it should ask, and the user should be alerted that something >> fishy is happening. >> >> I am working on these notice and consent issues at ISO/IEC JTC 1/SC 27/W= G >> 5 so if you are interested, please do join :-) >> >> Nat >> >> 2015-07-22 13:52 GMT+02:00 Phil Hunt : >> >>> Agreed. >>> >>> I have heard it can be equally bad to pester the user every time a new >>> scope is needed. >>> >>> There=E2=80=99s a definite balancing problem. >>> >>> I don=E2=80=99t think this an OAuth issue; just a good user experience = issue. >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> On Jul 22, 2015, at 11:35 AM, Nat Sakimura wrote: >>> >>> IMHO, returning everything if scope is empty is a violation of the >>> collection minimization principle. From the privacy by Design point of >>> view, a lazy programmer sending an empty request should not cause the >>> maximal data returned. >>> >>> Now, as to the spec change is concerned, I agree with John that it is >>> not required. >>> However, a Best practice document would probably help the developers. >>> >>> Nat >>> >>> 2015-07-22 11:19 GMT+02:00 John Bradley : >>> >>>> Slideshare did register all of those scopes as ones the client could >>>> ask for. >>>> >>>> Interpreting no scopes as all the ones the client has set as the ones >>>> it wants is probably not unreasonable. >>>> >>>> The problem is a combination of Slideshare over asking, perhaps becaus= e >>>> they don=E2=80=99t understand the default behaviour, and LinkedIn now= allowing >>>> only some of the scopes to be returned. >>>> >>>> I think people are moving back to allowing people to deselect scopes. >>>> In Android m you can now deselect scopes that apps request, both at >>>> installation and after. >>>> >>>> One argument that people have put forward is that RP will ask for the >>>> minimum set of scopes to encourage the person to consent. However it >>>> seems that many RP decide to grab the maximum permissions on the groun= ds >>>> that people agree to it. >>>> >>>> I don=E2=80=99t know that any spec change is required, but perhaps som= e sort of >>>> education is. >>>> >>>> If users decline all on a regular basis then the RP will be motivated >>>> to change. >>>> >>>> John B. >>>> >>>> On Jul 22, 2015, at 11:08 AM, Nat Sakimura wrote: >>>> >>>> Wow, that's the very opposite of Privacy by Design/Default >>>> recommendation. >>>> >>>> >>>> 2015-07-22 11:06 GMT+02:00 Justin Richer : >>>> >>>>> According to the LinkedIn docs, that means they get all the scopes >>>>> that they registered for. >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> On Jul 22, 2015, at 10:59 AM, Maciej Machulak < >>>>> maciej.machulak@gmail.com> wrote: >>>>> >>>>> It seems that they don't ask for scopes. >>>>> >>>>> The parameter is left blank: scope=3D >>>>> >>>>> Kind regards, >>>>> Maciej >>>>> >>>>> On 22 July 2015 at 10:26, Phil Hunt wrote: >>>>> >>>>>> Do they explicitly ask for those scopes? Or do they leave scope to >>>>>> default that way. >>>>>> >>>>>> Phil >>>>>> >>>>>> On Jul 22, 2015, at 10:22, Justin Richer wrote: >>>>>> >>>>>> This is a pretty clear case of SlideShare trying to grab too much. >>>>>> The LinkedIn API (which is their own proprietary thing, not OpenID C= onnect) >>>>>> does separate all the permissions into different scopes. However, th= e >>>>>> SlideShare app is asking for all of them, and LinkedIn doesn=E2=80= =99t let you >>>>>> uncheck any boxes on the authorization screen. >>>>>> >>>>>> FWIW, the reason they want write access to your profile is to >>>>>> automatically add new SlideShare presentations that you upload to yo= ur >>>>>> LinkedIn profile page. You should still have the option of turning t= hat >>>>>> off, or of turning on that functionality later. >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> On Jul 22, 2015, at 9:49 AM, Kathleen Moriarty < >>>>>> kathleen.moriarty.ietf@gmail.com> wrote: >>>>>> >>>>>> Hey Barry, >>>>>> >>>>>> From my observations with Facebook, it now has options added for you >>>>>> to select what resources from Facebook will get shared when authoriz= ing >>>>>> access to other applications. You can click on each of the possibil= ities >>>>>> and strip it down. It appears to me that Facebook is managing that,= so in >>>>>> your case, I *think* (and am open to be corrected) that LinkedIn nee= ds to >>>>>> do something similar. Without those options, I also cancel out and = just >>>>>> don't use the other app. >>>>>> >>>>>> Thanks, >>>>>> Kathleen >>>>>> >>>>>> On Wed, Jul 22, 2015 at 3:44 AM, Barry Leiba >>>>> > wrote: >>>>>> >>>>>>> Yesterday, someone sent me a link to some presentation slides that >>>>>>> he'd posted to SlideShare. I looked at them, and wanted to downloa= d >>>>>>> them as a PDF. In order to let me do that, SlideShare wants me to >>>>>>> log >>>>>>> in. It gives me the options to log in via LinkedIn or Facebook. A= s >>>>>>> I'm one of the three people in the world without a Facebook account= , >>>>>>> I >>>>>>> clicked "LinkedIn". That got me an OAuth authorization screen, ima= ge >>>>>>> attached. >>>>>>> >>>>>>> Now, I don't know if this is SlideShare's fault for asking for too >>>>>>> much, or LinkedIn's fault for not providing enough granularity for >>>>>>> requests, but just LOOK at that list of what I'd be giving SlideSha= re >>>>>>> access to. The first few make sense: read my profile (the whole >>>>>>> thing >>>>>>> or pieces of it, including contact information). But... access to = my >>>>>>> connections? I'm not sure they'd like my exposing their identities >>>>>>> to >>>>>>> SlideShare. Access to my private messages? EDIT MY PROFILE? Srsl= y? >>>>>>> >>>>>>> Of course, this isn't the fault of the OAuth protocol, really (thou= gh >>>>>>> one might argue that there's not enough guidance provided). But, >>>>>>> really, with implementations like this, I have to wonder what they'= re >>>>>>> thinking. >>>>>>> >>>>>>> I clicked "Cancel", of course, and asked the slide creator to send >>>>>>> me a PDF. >>>>>>> >>>>>>> Barry >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Best regards, >>>>>> Kathleen >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@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 >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Maciej Machulak >>>>> email: maciej.machulak@gmail.com >>>>> mobile: +44 7999 606 767 (UK) >>>>> mobile: +48 602 45 31 66 (PL) >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>> >>>> >>>> -- >>>> Nat Sakimura (=3Dnat) >>>> Chairman, OpenID Foundation >>>> http://nat.sakimura.org/ >>>> @_nat_en >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>> >>> >>> -- >>> Nat Sakimura (=3Dnat) >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >> >> >> -- >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c24894d19956051b766b80 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

Is there any A/B test kind of statis= tics on the improvement of the conversion of the incremental authz over kit= chen sink authz?=C2=A0
If there is, it would be a very good data = to show to those people who want everything upfront.=C2=A0

Nat

2015-07-22 15:01 GMT+02:00 William Denniss <wdenniss@google.com>:
On the pe= stering topic, one way that can be avoided is by using incremental auth to = ask for permissions just-in-time. That pattern holds up when new scopes are= required for new features.=C2=A0 By contextualising the permission ask, it= likely leads to higher conversion rates as users can figure out why the in= formation is being requested, and by being optional the cost of denying the= permissions is not so great (unlike when sign is prevented through user re= jection).

Permission screens that ask for the kitchen si= nk just to sign you in are the death of identity federation.

On Wed, Jul 22, 2015 at 2:50 PM, Nat Sakimura <sakimu= ra@gmail.com> wrote:
I think it would be good to have both a guideline informative RF= C as well as the oauth.net blog entry, former being more "formal" in the way of writing w= hile the later can be more readable one.=C2=A0

Re: peste= ring factor -- Indeed, I am the one started to talk about "turning an = internet dog into a Pavlov's dog" and agree that pestering the use= r too much is not good. As in EU DP Directive and forthcoming regulation, w= e should actually skip the dialogue if it falls into one of the "condi= tions for processing" (apart from the explicit consent condition).=C2= =A0

However, if it is asking something that is not= required for the immediate processing, it should ask, and the user should = be alerted that something fishy is happening.=C2=A0

I am working on these notice and consent issues at ISO/IEC JTC 1/SC 27/WG= 5 so if you are interested, please do join :-)

Nat

2015-07-22 13:52 GMT+02:0= 0 Phil Hunt <phil.hunt@oracle.com>:
Agreed.

I have heard it can be equally bad to pester the user every time a new sc= ope is needed.

There=E2=80=99s a definite balancin= g problem.

I don=E2=80=99t think this an OAuth iss= ue; just a good user experience issue.


On Jul 22, 2015, a= t 11:35 AM, Nat Sakimura <sakimura@gmail.com> wrote:

IMHO, returning everything if scope is empty is a violation of the collec= tion minimization principle. From the privacy by Design point of view, a la= zy programmer sending an empty request should not cause the maximal data re= turned.=C2=A0

Now, as to the spec change is concerned, I= agree with John that it is not required.=C2=A0
However, a Best p= ractice document would probably help the developers.=C2=A0

Nat

2015-07-22 11:19 GMT+02:00 John Bradley <ve7jtb@ve7jtb.com><= /span>:
Slideshare did register all of those scopes as ones the client could ask= for.

Interpreting no scopes as all the ones the client = has set as the ones it wants is probably not unreasonable.

The problem is a combination of Slideshare over asking, perhaps be= cause they don=E2=80=99t understand the default behaviour, =C2=A0and Linked= In now allowing only some of the scopes to be returned.

I think people are moving back to allowing people to deselect scopes.= =C2=A0 In Android m you can now deselect scopes that apps request, both at= installation and after.

One argument that people = have put forward is that RP will ask for the minimum set of scopes to encou= rage the person to consent. =C2=A0 However it seems that many RP decide to = grab the maximum permissions on the grounds that people agree to it.
<= div>
I don=E2=80=99t know that any spec change is required, b= ut perhaps some sort of education is.

If users dec= line all on a regular basis then the RP will be motivated to change.
<= div>
John B.

On Jul 22, 2015, at 11:08 AM, Nat Sakimura <sakimura@gmail.com&g= t; wrote:

Wow, that's the very opposite = of Privacy by Design/Default recommendation.=C2=A0


2015-07-22 11:06 GMT+= 02:00 Justin Richer <jricher@mit.edu>:
According to the LinkedIn do= cs, that means they get all the scopes that they registered for.

=C2=A0=E2=80=94 Justin
<= /span>

On Jul 22, 201= 5, at 10:59 AM, Maciej Machulak <maciej.machulak@gmail.com> wrote:

<= div>
It seems that they don't ask for scopes.=C2=A0
The parameter is left blank: scope=3D

<= div>Kind regards,
Maciej
On 22 July 2015 at 10:26, Phil Hunt <phil= .hunt@oracle.com> wrote:
Do they explicitly ask for those scopes? Or do they le= ave scope to default that way.=C2=A0

P= hil

On Jul 22, 2015, at 10:22, Justin= Richer <jricher@mi= t.edu> wrote:

This is a = pretty clear case of SlideShare trying to grab too much. The LinkedIn API (= which is their own proprietary thing, not OpenID Connect) does separate all= the permissions into different scopes. However, the SlideShare app is aski= ng for all of them, and LinkedIn doesn=E2=80=99t let you uncheck any boxes = on the authorization screen.=C2=A0

FWIW, the reason they= want write access to your profile is to automatically add new SlideShare p= resentations that you upload to your LinkedIn profile page. You should stil= l have the option of turning that off, or of turning on that functionality = later.

=C2=A0=E2=80=94 Justin

<= blockquote type=3D"cite">
On Jul 22, 2015, at 9:49 AM, Kathleen Moriart= y <kathleen.moriarty.ietf@gmail.com> wrote:

Hey Barry,

From my observations with Facebook, it n= ow has options added for you to select what resources from Facebook will ge= t shared when authorizing access to other applications.=C2=A0 You can click= on each of the possibilities and strip it down.=C2=A0 It appears to me tha= t Facebook is managing that, so in your case, I *think* (and am open to be = corrected) that LinkedIn needs to do something similar.=C2=A0 Without those= options, I also cancel out and just don't use the other app. =C2=A0

Thanks,
Kathleen

On Wed, Jul 22, 2015 at 3:44 AM= , Barry Leiba <barryleiba@computer.org> wrote:
Yesterday, someone sent me a link to some presen= tation slides that
he'd posted to SlideShare.=C2=A0 I looked at them, and wanted to downlo= ad
them as a PDF.=C2=A0 In order to let me do that, SlideShare wants me to log=
in.=C2=A0 It gives me the options to log in via LinkedIn or Facebook.=C2=A0= As
I'm one of the three people in the world without a Facebook account, I<= br> clicked "LinkedIn".=C2=A0 That got me an OAuth authorization scre= en, image
attached.

Now, I don't know if this is SlideShare's fault for asking for too<= br> much, or LinkedIn's fault for not providing enough granularity for
requests, but just LOOK at that list of what I'd be giving SlideShare access to.=C2=A0 The first few make sense: read my profile (the whole thing=
or pieces of it, including contact information).=C2=A0 But... access to my<= br> connections?=C2=A0 I'm not sure they'd like my exposing their ident= ities to
SlideShare.=C2=A0 Access to my private messages?=C2=A0 EDIT MY PROFILE?=C2= =A0 Srsly?

Of course, this isn't the fault of the OAuth protocol, really (though one might argue that there's not enough guidance provided).=C2=A0 But,<= br> really, with implementations like this, I have to wonder what they're thinking.

I clicked "Cancel", of course, and asked the slide creator to sen= d me a PDF.

Barry

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




--

Best regards,
Kathleen
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth
____________= ___________________________________
OAuth mailing list
OAuth@ietf.= org
https://www.ietf.org/mailman/listinfo/oauth

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




--
Mac= iej Machulak
email: maciej.machulak@gmail.com
mobile: +44 7999 606 7= 67 (UK)
mobile: +48 602 45 31 66 (PL)


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




--
Nat= Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en<= /div>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth



=
--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
= http://nat.sakimura.= org/
@_nat_en
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth



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

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





--
=
Nat Sakimura (=3Dnat)
Chairman, OpenID F= oundation
http://= nat.sakimura.org/
@_nat_en
--001a11c24894d19956051b766b80-- From nobody Wed Jul 22 10:48:25 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF301B2CCA for ; Wed, 22 Jul 2015 10:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.641 X-Spam-Level: X-Spam-Status: No, score=-1.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbpqOQQwG7Y5 for ; Wed, 22 Jul 2015 10:48:22 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0712.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:712]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8BE61B2C90 for ; Wed, 22 Jul 2015 10:48:21 -0700 (PDT) Received: from BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) by BY2PR03MB588.namprd03.prod.outlook.com (10.141.144.153) with Microsoft SMTP Server (TLS) id 15.1.219.17; Wed, 22 Jul 2015 17:48:01 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.225.13; Wed, 22 Jul 2015 17:48:00 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0225.018; Wed, 22 Jul 2015 17:48:00 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Authentication Method Reference Values Specification Thread-Index: AdDEponiitwaXF5YTtCgg2mzrUGsug== Date: Wed, 22 Jul 2015 17:48:00 +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; x-originating-ip: [2001:67c:370:160:cd4:6009:4610:eb44] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:GRVfH5S6JRjulMDTudGWBSQSw3/RaBh5xxxsBE7OsOf0lvk7Gc/u3T5OYpilHC3Hm8jtPuutXudqMriDqgU9guMoMEbqmHi3G1aa86CVuLZVaW9IWHOg1mTjQbUFK1h4NUsXVvcky7T6Iq8fvQfC2w==; 24:TxwzKLk449gB5fPxkrU8nkjwYvopr6VeYzutxeB844joIWeYI93gWO3ATR4gn0FFYsTBI1mFp30VuNb13q8islZ9AenpQNSrpqjYQp6xxig=; 20:JurTH75LlnB2Li2rj8PkbzqMOxPMv4T/3IQfjxxy6UXd04mLwdVCVtoW0H26n3OYUuxDSyb4PFn+9xxq4aR2/Q== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB588; by2pr03mb443: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 0645BEB7AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(19609705001)(86362001)(229853001)(19580395003)(16236675004)(102836002)(2351001)(77096005)(15975445007)(76576001)(77156002)(50986999)(62966003)(122556002)(19617315012)(2656002)(551544002)(87936001)(40100003)(2501003)(74316001)(54356999)(33656002)(19300405004)(5003600100002)(189998001)(19625215002)(46102003)(110136002)(5002640100001)(5001960100002)(99286002)(2900100001)(10090500001)(92566002)(3826002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442F8BDAF9DF110F97B7887F5830BY2PR03MB442namprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2015 17:48:00.5777 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 X-Microsoft-Exchange-Diagnostics: 1; BY2PR03MB588; 2:2UXI+rP9SrTWLokkl30sEdDkSBP9eCmlPf6ERBZi1s7oyn1xi9Y49b4Zcdgl+u6U; 3:PDGENwXyWOCIaL0XzyXRbsbvBzmTQvugrHOYcdF8w3Xfwn+hw7iKTYiUBECg+tw2y11i6AnA0D+IyX2PfIhJ9hxbxR8vX7qFn3/hWd577Wk0y5RmcMgy7V600Cymmvok7auW4C8R6n3NaslQUjZiRw==; 25:JaTP5PgAV6p75rKdkJoOsuP/8mKmVsbVbEGYqAC76FjrUf/gj7nnKNzp0N0OPLXS5y6vkGoCGQP+Ub/9FpwJNyYbDA3bziZbPia16/1JcaH7N9l6vWzTreRFi0Xy0Cu3vjorKfxWkrQPwa3x3Utig2NZBX3CFGPg0FxqoYMzLfvD4r89AuJVpu0puIUs7IK+xCjrS63yqKy4fBoE0+rZiN2kHy0MDjyXNUka6U8g7MxP3a20/IOwOWK62l8AfDsvQM89zxSYbLGbAu/HZlvS8g== X-Microsoft-Exchange-Diagnostics: 1; BY2PR03MB588; 20:nhU0js5UJ564/37oVPaYO09cn/FJawRke5GmKyIBBQJz9eryZ1nwkRsHGVFJs8n+Yjo5Q07JMvo8cSO6oZY4lz5FS9lktC2Kg43BGa5aGMaFtJXdGLJIh7m8vLo+oc6w+E2el/SNH6c4n5V5soQok6crAPi9TM014lvbTVQR8dNWcmwvrCuLuLQLZ65lvTTEakiQvH5fFJ8K2+DFPfAJIzgQGw/LdYnHN8ksbJa5sNXBbPK2IlicxL6xrIEr8UBbIvJi5fR75NNYrSwoIkgbl1EIzJagG6+cLN120WmIYkMYE2VgctPmvz6P3GUHFdYEgOnA1CTCOw+naqlB+1QUPhEEDondHqd9JT/IWjDaHfB5NWFdduamgYeweuyS8sWnGi61jGleBS4gddP52fuiUzN9rB8Xa32speWbH1KKTIaozuQ6Ha13d+AF/CEcwSA3hZGjFMEujv1rGY2UXiHh+aSEPIkr3ZjsQsqcabTv1gg55xFdABK+TncC5TOrBs4W; 23:/T4C6Yqjdm0qfWzF99Dubt5cECelJ2vdGbO6LOFHeZGLPx4slNQqsggEaJvE8ypCVpHkil9PRqsx0BRAAmPs/qNzfYrFS+Zwx4nd4c+JvWCzPTC/9QqI9vL7g49ZKdMNEsLI2gBUsHGeKety/9Q5EfhE6P2paeiSyTFGqKfRSHMaPRgtSk4yKqWLX5L3fySgrOzZb1rMJ8Pd/ZEwz+v2+sWpnfyCMatbI/2D1ReSB5RNUoeBZTvBZAbHXLV4pNXH BY2PR03MB588: X-MS-Exchange-Organization-RulesExecuted X-OriginatorOrg: microsoft.com Archived-At: Subject: [OAUTH-WG] Authentication Method Reference Values Specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 17:48:24 -0000 --_000_BY2PR03MB442F8BDAF9DF110F97B7887F5830BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Phil Hunt and I have posted a new draft that defines some values used with = the "amr" (Authentication Methods References) claim and establishes a regis= try for Authentication Method Reference values. These values include commo= nly used authentication methods like "pwd" (password) and "otp" (one time p= assword). It also defines a parameter for requesting that specific authent= ication methods be used in the authentication. The specification is available at: * https://tools.ietf.org/html/draft-jones-oauth-amr-values-00 An HTML formatted version is also available at: * http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html -- Mike P.S. This note was also posted at http://self-issued.info/?p=3D1429 and as= @selfissued. --_000_BY2PR03MB442F8BDAF9DF110F97B7887F5830BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Phil Hunt and I have posted a new draft that defines= some values used with the “amr” (Authentication Methods References) claim and = establishes a registry for Authentication Method Reference values.  These values include commonly used authentication methods li= ke “pwd= 221; (password) and “otp” (one time password).  It also defines a paramete= r for requesting that specific authentication methods be used in the authentication.

 

The specification is available at:

·        https://tools.ietf.org/html/draft-jones-oauth-a= mr-values-00

 

An HTML formatted version is also available at:=

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

 

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

 

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

--_000_BY2PR03MB442F8BDAF9DF110F97B7887F5830BY2PR03MB442namprd_-- From nobody Thu Jul 23 00:23:18 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C281A88E9 for ; Thu, 23 Jul 2015 00:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Akl0DG04-Hxk for ; Thu, 23 Jul 2015 00:23:13 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C08321A8972 for ; Thu, 23 Jul 2015 00:22:01 -0700 (PDT) X-AuditID: 1209190e-f79c76d000002631-1a-55b09618e588 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id E8.8B.09777.81690B55; Thu, 23 Jul 2015 03:22:00 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t6N7Lxcg003815; Thu, 23 Jul 2015 03:21:59 -0400 Received: from dhcp-893a.meeting.ietf.org (dhcp-893a.meeting.ietf.org [31.133.139.58] (may be forged)) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t6N7LuDS025080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Jul 2015 03:21:58 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_539927C8-78B9-4A60-BAA0-AE009D834A48" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Justin Richer In-Reply-To: Date: Thu, 23 Jul 2015 09:21:55 +0200 Message-Id: <8BADFB60-1BE4-415A-B386-F34F9FE72A3C@mit.edu> References: To: Mike Jones X-Mailer: Apple Mail (2.2102) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAKsWRmVeSWpSXmKPExsUixCmqrCsxbUOoQdN/Xou90z6xWJx8+4rN gcljyZKfTB6tO/6yBzBFcdmkpOZklqUW6dslcGXMn9zCXDDNq+LYxOlMDYwnHLsYOTkkBEwk Oj+tYoewxSQu3FvP1sXIxSEksJhJ4vv0Z+wQzkZGiR3XJzJCOI+ZJNaf2cEM0sIskCDxeP1R sHZeAT2JnnNfGEFsYQEfiTVPTjGB2GwCqhLT17SA2ZwC0RIbl/xlA7FZgOIdd3YCzeEAmqMu 0X7SBWKMlcSGvffBxgsJREn8XN4A1ioioCPx+OI3NohLZSW2vmllmsAoMAvJFbOQXAER15ZY tvA1M4StKbG/ezkLpriGROe3iawLGNlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Rrr5WaW6KWm lG5iBAe8JN8Oxq8HlQ4xCnAwKvHwLvDaECrEmlhWXJl7iFGSg0lJlPfvZKAQX1J+SmVGYnFG fFFpTmrxIUYJDmYlEd677UA53pTEyqrUonyYlDQHi5I476YffCFCAumJJanZqakFqUUwWRkO DiUJ3qNTgBoFi1LTUyvSMnNKENJMHJwgw3mAhl8GqeEtLkjMLc5Mh8ifYlSUEue9AZIQAElk lObB9cIS0itGcaBXhHnXglTxAJMZXPcroMFMQIN5+sAGlyQipKQaGEv1TAtSQ3PO7J62yXcx +yRpm0TjoraMyJ93xcK3/Ppxd+nFiTumuida8maZ7Nt+4+J26dtJfG4vtjgz7ZigUhRzvqHV M+dI0OMDe/V0lQ342HN797IX3hSQi3xtY3FRXW6jpfv6hRqXfnY+/+jVY3lzn3HsfC+2Srf2 X2/tbFal907Q2CAcocRSnJFoqMVcVJwIAJb2mXwjAwAA Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Authentication Method Reference Values Specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 07:23:16 -0000 --Apple-Mail=_539927C8-78B9-4A60-BAA0-AE009D834A48 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Useful work, but shouldn=E2=80=99t this be defined in the OIDF, where = the =E2=80=9Camr" parameter is defined? =E2=80=94 Justin > On Jul 22, 2015, at 7:48 PM, Mike Jones = wrote: >=20 > Phil Hunt and I have posted a new draft that defines some values used = with the =E2=80=9Camr=E2=80=9D (Authentication Methods References) claim = and establishes a registry for Authentication Method Reference values. = These values include commonly used authentication methods like =E2=80=9Cpw= d=E2=80=9D (password) and =E2=80=9Cotp=E2=80=9D (one time password). It = also defines a parameter for requesting that specific authentication = methods be used in the authentication. > =20 > The specification is available at: > =C2=B7 = https://tools.ietf.org/html/draft-jones-oauth-amr-values-00 = > =20 > An HTML formatted version is also available at: > =C2=B7 = http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html = > =20 > -- Mike > =20 > P.S. This note was also posted at http://self-issued.info/?p=3D1429 = and as @selfissued = . > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_539927C8-78B9-4A60-BAA0-AE009D834A48 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Useful work, but shouldn=E2=80=99t this be defined in the = OIDF, where the =E2=80=9Camr" parameter is defined?

 =E2=80=94 Justin

On Jul 22, 2015, at 7:48 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Phil Hunt and I have = posted a new draft that defines some values used with the =E2=80=9Camr=E2=80=9D= (Authentication Methods References) claim and establishes a registry = for Authentication Method Reference values.  These values include commonly used authentication methods = like =E2=80=9Cpwd=E2=80=9D (password) and =E2=80=9Cotp=E2=80=9D= (one time password).  It also defines a parameter for requesting that specific authentication methods be used in the authentication.

 

The specification is = available at:

=C2=B7        https://tools.ietf.org/html/draft-jones-oauth-amr-values-00=

 

An HTML formatted = version is also available at:

=C2=B7        http://self-issued.info/docs/draft-jones-oauth-amr-values-00.ht= ml

 

         =             &n= bsp;           &nbs= p;            =             &n= bsp; -- Mike

 

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

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

= --Apple-Mail=_539927C8-78B9-4A60-BAA0-AE009D834A48-- From nobody Thu Jul 23 00:30:23 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C650F1A88D6 for ; Thu, 23 Jul 2015 00:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJ03qDRnBvn7 for ; Thu, 23 Jul 2015 00:30:19 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBE891A88F5 for ; Thu, 23 Jul 2015 00:30:16 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so195110372wib.0 for ; Thu, 23 Jul 2015 00:30:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=DuvJizqKSFqHmxT8b7CIX1bMBdyZflHrhjIXFm7pZD4=; b=kmbV6kYKTJ9c/ggHUl+t7dTBX+nnIKZbfvtMXAI+8nf4i3ctjOozsbMBMrlUAl3hr2 Wu9BLAkK213rYABNfnd/ziAM9kld/AZFVS9FvZ/Hzgm/KVwmyMZyNy1iiFtIJjq1K2f3 nbB34AtAd96UjR1yOrFOFd4KSSsJiA+LlIJENu3r4Cr2JHoKeBbz7D8ZAmLD/8f598eW yyCHCh+sI3fD5GZzbQRt5ehBq3ZUHqFBlwi1utGj/JqSv0xKXZwc50TBfd3rCWhSWt3I CSmeW+D62sxSFytHLuklv1rSsfPzCIeQxaFoIXZEHWoPIlQt+Gs+PFEJl0KkBzCKNhLA NiIw== X-Gm-Message-State: ALoCoQkBKjBZix0TW4PuBsA5KCQemmAEXoeScfcnI52X2XUnrCkD9Zai2Su6GetArDyZtjoBO6Ew X-Received: by 10.180.104.8 with SMTP id ga8mr49787058wib.5.1437636615410; Thu, 23 Jul 2015 00:30:15 -0700 (PDT) Received: from [10.6.0.44] ([62.212.85.119]) by smtp.gmail.com with ESMTPSA id ma4sm6062648wjb.38.2015.07.23.00.30.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Jul 2015 00:30:14 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_39EBBA5E-B8D5-4276-A64E-E55FC7E985A5"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: John Bradley In-Reply-To: <8BADFB60-1BE4-415A-B386-F34F9FE72A3C@mit.edu> Date: Thu, 23 Jul 2015 09:30:12 +0200 Message-Id: <61575F9A-8A0F-415A-89AA-480432813020@ve7jtb.com> References: <8BADFB60-1BE4-415A-B386-F34F9FE72A3C@mit.edu> To: Justin Richer X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Authentication Method Reference Values Specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 07:30:22 -0000 --Apple-Mail=_39EBBA5E-B8D5-4276-A64E-E55FC7E985A5 Content-Type: multipart/alternative; boundary="Apple-Mail=_4450E4DF-0D43-49E6-ADD9-09BA1FA7CCFD" --Apple-Mail=_4450E4DF-0D43-49E6-ADD9-09BA1FA7CCFD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I don=E2=80=99t personally have a problem with people defining values = for AMR and creating a IANA registry.=20 That exists for ACR. I am on record as not supporting clients requesting amr as it ai a bad = idea and the spec mentions that at the same time it defines a new = request parameter for it. It is probably not something I will put any real effort into fighting, = if people insist on it. I will continue to recommend only using ACR in = the request. John B. > On Jul 23, 2015, at 9:21 AM, Justin Richer wrote: >=20 > Useful work, but shouldn=E2=80=99t this be defined in the OIDF, where = the =E2=80=9Camr" parameter is defined? >=20 > =E2=80=94 Justin >=20 >> On Jul 22, 2015, at 7:48 PM, Mike Jones > wrote: >>=20 >> Phil Hunt and I have posted a new draft that defines some values used = with the =E2=80=9Camr=E2=80=9D (Authentication Methods References) claim = and establishes a registry for Authentication Method Reference values. = These values include commonly used authentication methods like =E2=80=9Cpw= d=E2=80=9D (password) and =E2=80=9Cotp=E2=80=9D (one time password). It = also defines a parameter for requesting that specific authentication = methods be used in the authentication. >> =20 >> The specification is available at: >> =C2=B7 = https://tools.ietf.org/html/draft-jones-oauth-amr-values-00 = >> =20 >> An HTML formatted version is also available at: >> =C2=B7 = http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html = >> =20 >> -- Mike >> =20 >> P.S. This note was also posted at http://self-issued.info/?p=3D1429 = and as @selfissued = . >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_4450E4DF-0D43-49E6-ADD9-09BA1FA7CCFD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I don=E2=80=99t personally have a problem with people = defining values for AMR and creating a IANA registry. 

That exists for = ACR.

I am on = record as not supporting clients requesting amr as it ai a bad idea and = the spec mentions that at the same time it defines a new request = parameter for it.

It is probably not something I will put any real effort into = fighting, if people insist on it.  I will continue to recommend = only using ACR in the request.

John B.

On Jul 23, 2015, at 9:21 AM, Justin Richer = <jricher@mit.edu> = wrote:

Useful work, but shouldn=E2=80=99t this be = defined in the OIDF, where the =E2=80=9Camr" parameter is = defined?

 =E2=80=94 Justin

On Jul 22, 2015, at 7:48 PM, Mike Jones <Michael.Jones@microsoft.com> = wrote:

Phil Hunt and I have posted a new draft that defines some = values used with the =E2=80=9Camr=E2=80=9D (Authentication Methods References) = claim and establishes a registry for Authentication Method Reference = values.  These values include commonly used authentication methods = like =E2=80=9Cpwd=E2=80=9D (password) and =E2=80=9Cotp=E2=80=9D (one time = password).  It also defines a parameter for requesting that = specific authentication methods be used in the authentication.
 
The = specification is available at:
=C2=B7        https://tools.ietf.org/html/draft-jones-oauth-amr-values-00
 
An HTML = formatted version is also available at:
=C2=B7        http://self-issued.info/docs/draft-jones-oauth-amr-values-00.h= tml
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            -- = Mike
 
P.S.  = This note was also posted at http://self-issued.info/?p=3D1429 and as @selfissued.
_______________________________________= ________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

= --Apple-Mail=_4450E4DF-0D43-49E6-ADD9-09BA1FA7CCFD-- --Apple-Mail=_39EBBA5E-B8D5-4276-A64E-E55FC7E985A5 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTA3MjMwNzMwMTNaMCMGCSqGSIb3DQEJBDEWBBQchULhLxLSmKpQ2fblqHZN yh/TNjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBgPZVVJDZKx+rRiFBLjWhpgMtgsTBgker0i6RNgTWfskc4MtZaXf92 UriunM2EOvHf9L86mYO8pbBEZjfB6+AQN0gks31hilT3ftsIH/uwIfIW4/MA2gHcHoBHLI7hILr2 p1H5uKbbjiJd1HrTYeWYosnuurwbdw8l/U4geM/w04+K0TXcEdqJ5mhiSC3yEkoZ29K9pvKJf/NX IVZ7jAXXvFGk8ZwBzRwcZpBRAlzPU4dshNOY5T22y+rqDBNCWV3cZZmty6IeTo1TKNRzMGtlARF9 esE3dYhupkJ+4fjtzyJYEXuNTuF9r3un8ntuMs8NZvYl43b2WPmPvKpv/KHPAAAAAAAA --Apple-Mail=_39EBBA5E-B8D5-4276-A64E-E55FC7E985A5-- From nobody Thu Jul 23 00:35:15 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A09FB1A88A7 for ; Thu, 23 Jul 2015 00:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLt5bMV8gF48 for ; Thu, 23 Jul 2015 00:35:11 -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 DC6781A8920 for ; Thu, 23 Jul 2015 00:35:07 -0700 (PDT) Received: from BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) by BY2PR03MB285.namprd03.prod.outlook.com (10.242.37.16) with Microsoft SMTP Server (TLS) id 15.1.225.13; Thu, 23 Jul 2015 07:35:04 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.225.13; Thu, 23 Jul 2015 07:35:05 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0225.018; Thu, 23 Jul 2015 07:35:05 +0000 From: Mike Jones To: John Bradley , Justin Richer Thread-Topic: [OAUTH-WG] Authentication Method Reference Values Specification Thread-Index: AdDEponiitwaXF5YTtCgg2mzrUGsugAcbbeAAABKDwAAABfdYA== Date: Thu, 23 Jul 2015 07:35:04 +0000 Message-ID: References: <8BADFB60-1BE4-415A-B386-F34F9FE72A3C@mit.edu> <61575F9A-8A0F-415A-89AA-480432813020@ve7jtb.com> In-Reply-To: <61575F9A-8A0F-415A-89AA-480432813020@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ve7jtb.com; dkim=none (message not signed) header.d=none; x-originating-ip: [88.208.89.131] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:iVQwdSV052CjUZRKTyt5nJl2WJfjsS7VKg6pnjU+jg7C01zXZEdkFW8fiB6rWE+MCCk09VBdrt6SJpodewUzLWfGbPCzo9xFMe1l2n2f0o/vzS4hsWEETIbBEVugDfNU9RFf7/jutoVzwFMCn2Zu8Q==; 24:Q5oSFE1D/wCdH+O6/HA+UJHv+wAIeCJpR72xNVnQRgIynGkEk3OY1chpjzF3uN0VHeILywwAPH0IP4KMrbN44DoEtl5HgqCvxYBnhu2bkHo=; 20:b0MVMmX3qV089ZnWCEaDRlt6Y7KxocgMsdkuWaZ4koshFrs6XtX1Yy4MFii/Ic1oyOPd1wY8hehiLhAM974Hzw== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB285; by2pr03mb443: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 06469BCC91 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(377454003)(24454002)(19609705001)(50986999)(551544002)(76176999)(19580395003)(102836002)(77096005)(15975445007)(16236675004)(86362001)(76576001)(77156002)(2656002)(122556002)(66066001)(19617315012)(2171001)(5001770100001)(87936001)(62966003)(40100003)(74316001)(33656002)(54356999)(19300405004)(5003600100002)(19625215002)(189998001)(5001960100002)(5002640100001)(19580405001)(10090500001)(46102003)(2900100001)(99286002)(2950100001)(92566002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4422C8D84A092E5A6D79C7EF5820BY2PR03MB442namprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2015 07:35:04.9641 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 X-Microsoft-Exchange-Diagnostics: 1; BY2PR03MB285; 2:RXersfOayt7REq6Wn/JXAg4Wo1HwbSzpkuxjtoCBdssPtzrKD3IBpR/lVegcOhlnp1eVLarxSte8nIEOhqXh9G1OLWRlt1qLiX+hJLuTB7Q4vCYffpW4XcN9t4j3jcGt+5GtxQmteFtvEwIJQ60OBBa4v3rOoKdMZqWqwrNF+8E=; 3:Eq+k0OMMLpcYI/Fkb3+eafUzsZJXtS3999tjd1XhqF7tLGXj+HUpAa61qoKdZ2t3cE1tjEqeM8QuOoGkyde5Xs8fwnT5QlZPrF+XUaKZAJhpSI5rqzQsUKtNXKeWY1PuqD6cONTjZhbVmY6ngtZRJw==; 25:tLb/zpAEBXzszoLHIW7W4iUWza2AbkF50Gijs2o6+CCAa90izo8+ltGnm3SEFoE7X9xRdi8D30u4omx5O+n8ROd91OYbUOADq7+iqBKfi63E8dnRnwvfyK2l7AUib/me+ZcxOmR7HKHl1Qmb0X7I1rCv98v5oR4WzUq4EcjuI8WcSemBR1HuYsWAdmNTFnc9en6rTgd9vAaGnVD+hfLAf1Y6WORSQNLtCcbQZaYLFnEQ+qlqs4lAlexZR7VOB9t2MtPNPZgYTvpzaWIdS1ZWGg== X-Microsoft-Exchange-Diagnostics: 1; BY2PR03MB285; 20:jFbsJAg9aj8Kb1i5KHTFj3y6Lf4kawe8xwtapIkP3jSA45WHrl8S1rKUZSuozdu3jW4OsvUz6hcc3VO54FRUA7fU4zaqbSw2X305lyKDqHb1VuQNisB4Q9OoVUgCffgkvWh+8kL1bp8/q42HEOwhrrmbOHndPAI+nifzPvJ3GoWBE/N/TcR7aJ3HDMDZNxjMrNMndThMpPRBMpLrSJnIV6Uc0BllRVX5XYWnzUEXbpS8Jd0GZv8hLm9hxr9JUL04OFrpybHSfpLehSfjoVGqVE5lzrvUoZ5PYWx5xekVnzp9Qi9CQAT+9o6dsA9QVbVdP3wsK6DMPXIxgJj3cYN7vnjyg5/k1sogbSJrni3LAXmOggdcqFWyKqkh/NsjNcJVQWpxP84IEGI9o2iLAdaLTSCQKIQtPU0lQSJYYjzXe2Xi9HoZkKcUjgCvvkov+Y80AK9rWCMI5ov3SwvSRCIq8SqlG6bbDI153mj6r2GdWZGLBUqghr2iz0f6g4AqJKBI; 23:TrFbhR52J9hU9Z0C72N6AkinBpTtDSc15pYhgX9f3nK21jCXaDGfvxShLaFPWI7u5IZZX+77zf5e4B1nk0avoHkFI8EcpVEtLFVYsY64eqrieNsJttFcDxU2VZtLF3Joeziv6DCS93u0Pzs9Qe6LuFeijdeFc+zKjVfaVHqxxbFsLEm5dMbPGHDW7Src3bVmHC2QB47S6gbMtP2dIFdh04/v7z2nDfsj9csh5knz/7uW/tkfZhB5LIYZ9mv0fLsP BY2PR03MB285: X-MS-Exchange-Organization-RulesExecuted X-OriginatorOrg: microsoft.com Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Authentication Method Reference Values Specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 07:35:13 -0000 --_000_BY2PR03MB4422C8D84A092E5A6D79C7EF5820BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGtleSBwYXJ0IG9mIHRoaXMgaXMgZXN0YWJsaXNoaW5nIGEgcmVnaXN0cnkuICBUaGF0IGNh biBvbmx5IGJlIGRvbmUgaW4gYW4gUkZDLg0KDQpKb2huLCBJIGVuY291cmFnZSB5b3UgdG8gc3Vi bWl0IHRleHQgYmVlZmluZyB1cCB0aGUgYXJndW1lbnRzIGFib3V0IHdoeSB1c2luZyDigJxhY3Li gJ0gaXMgcHJlZmVyYWJsZS4gIFRoZSB0ZXh0IGF0IGh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2Rv Y3MvZHJhZnQtam9uZXMtb2F1dGgtYW1yLXZhbHVlcy0wMC5odG1sI2FjclJlbGF0aW9uc2hpcCBp cyBhIHN0YXJ0IGF0IHRoYXQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogSm9obiBCcmFkbGV5IFtt YWlsdG86dmU3anRiQHZlN2p0Yi5jb21dDQpTZW50OiBUaHVyc2RheSwgSnVseSAyMywgMjAxNSA5 OjMwIEFNDQpUbzogSnVzdGluIFJpY2hlcg0KQ2M6IE1pa2UgSm9uZXM7IDxvYXV0aEBpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEF1dGhlbnRpY2F0aW9uIE1ldGhvZCBSZWZlcmVu Y2UgVmFsdWVzIFNwZWNpZmljYXRpb24NCg0KSSBkb27igJl0IHBlcnNvbmFsbHkgaGF2ZSBhIHBy b2JsZW0gd2l0aCBwZW9wbGUgZGVmaW5pbmcgdmFsdWVzIGZvciBBTVIgYW5kIGNyZWF0aW5nIGEg SUFOQSByZWdpc3RyeS4NCg0KVGhhdCBleGlzdHMgZm9yIEFDUi4NCg0KSSBhbSBvbiByZWNvcmQg YXMgbm90IHN1cHBvcnRpbmcgY2xpZW50cyByZXF1ZXN0aW5nIGFtciBhcyBpdCBhaSBhIGJhZCBp ZGVhIGFuZCB0aGUgc3BlYyBtZW50aW9ucyB0aGF0IGF0IHRoZSBzYW1lIHRpbWUgaXQgZGVmaW5l cyBhIG5ldyByZXF1ZXN0IHBhcmFtZXRlciBmb3IgaXQuDQoNCkl0IGlzIHByb2JhYmx5IG5vdCBz b21ldGhpbmcgSSB3aWxsIHB1dCBhbnkgcmVhbCBlZmZvcnQgaW50byBmaWdodGluZywgaWYgcGVv cGxlIGluc2lzdCBvbiBpdC4gIEkgd2lsbCBjb250aW51ZSB0byByZWNvbW1lbmQgb25seSB1c2lu ZyBBQ1IgaW4gdGhlIHJlcXVlc3QuDQoNCkpvaG4gQi4NCg0KT24gSnVsIDIzLCAyMDE1LCBhdCA5 OjIxIEFNLCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0 LmVkdT4+IHdyb3RlOg0KDQpVc2VmdWwgd29yaywgYnV0IHNob3VsZG7igJl0IHRoaXMgYmUgZGVm aW5lZCBpbiB0aGUgT0lERiwgd2hlcmUgdGhlIOKAnGFtciIgcGFyYW1ldGVyIGlzIGRlZmluZWQ/ DQoNCiDigJQgSnVzdGluDQoNCk9uIEp1bCAyMiwgMjAxNSwgYXQgNzo0OCBQTSwgTWlrZSBKb25l cyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb20+PiB3cm90ZToNCg0KUGhpbCBIdW50IGFuZCBJIGhhdmUgcG9zdGVkIGEgbmV3IGRy YWZ0IHRoYXQgZGVmaW5lcyBzb21lIHZhbHVlcyB1c2VkIHdpdGggdGhlIOKAnGFtcuKAnSAoQXV0 aGVudGljYXRpb24gTWV0aG9kcyBSZWZlcmVuY2VzKSBjbGFpbSBhbmQgZXN0YWJsaXNoZXMgYSBy ZWdpc3RyeSBmb3IgQXV0aGVudGljYXRpb24gTWV0aG9kIFJlZmVyZW5jZSB2YWx1ZXMuICBUaGVz ZSB2YWx1ZXMgaW5jbHVkZSBjb21tb25seSB1c2VkIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgbGlr ZSDigJxwd2TigJ0gKHBhc3N3b3JkKSBhbmQg4oCcb3Rw4oCdIChvbmUgdGltZSBwYXNzd29yZCku ICBJdCBhbHNvIGRlZmluZXMgYSBwYXJhbWV0ZXIgZm9yIHJlcXVlc3RpbmcgdGhhdCBzcGVjaWZp YyBhdXRoZW50aWNhdGlvbiBtZXRob2RzIGJlIHVzZWQgaW4gdGhlIGF1dGhlbnRpY2F0aW9uLg0K DQpUaGUgc3BlY2lmaWNhdGlvbiBpcyBhdmFpbGFibGUgYXQ6DQrigKIgICAgICAgIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1vYXV0aC1hbXItdmFsdWVzLTAwDQoNCkFu IEhUTUwgZm9ybWF0dGVkIHZlcnNpb24gaXMgYWxzbyBhdmFpbGFibGUgYXQ6DQrigKIgICAgICAg IGh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQtam9uZXMtb2F1dGgtYW1yLXZhbHVl cy0wMC5odG1sDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KUC5TLiAgVGhpcyBub3RlIHdhcyBhbHNvIHBvc3Rl ZCBhdCBodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby8/cD0xNDI5IGFuZCBhcyBAc2VsZmlzc3VlZDxo dHRwczovL3R3aXR0ZXIuY29tL3NlbGZpc3N1ZWQ+Lg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5v cmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoN Cg== --_000_BY2PR03MB4422C8D84A092E5A6D79C7EF5820BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUt Y29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlRoZSBrZXkgcGFydCBvZiB0aGlzIGlzIGVzdGFibGlzaGluZyBhIHJlZ2lzdHJ5 LiZuYnNwOyBUaGF0IGNhbiBvbmx5IGJlIGRvbmUgaW4gYW4gUkZDLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Sm9obiwg SSBlbmNvdXJhZ2UgeW91IHRvIHN1Ym1pdCB0ZXh0IGJlZWZpbmcgdXAgdGhlIGFyZ3VtZW50cyBh Ym91dCB3aHkgdXNpbmcg4oCcYWNy4oCdIGlzIHByZWZlcmFibGUuICZuYnNwO1RoZSB0ZXh0IGF0 DQo8YSBocmVmPSJodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWpvbmVzLW9hdXRo LWFtci12YWx1ZXMtMDAuaHRtbCNhY3JSZWxhdGlvbnNoaXAiPg0KaHR0cDovL3NlbGYtaXNzdWVk LmluZm8vZG9jcy9kcmFmdC1qb25lcy1vYXV0aC1hbXItdmFsdWVzLTAwLmh0bWwjYWNyUmVsYXRp b25zaGlwPC9hPiBpcyBhIHN0YXJ0IGF0IHRoYXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0g TWlrZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSm9obiBCcmFkbGV5IFttYWlsdG86dmU3anRiQHZl N2p0Yi5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bHkgMjMsIDIwMTUgOToz MCBBTTxicj4NCjxiPlRvOjwvYj4gSnVzdGluIFJpY2hlcjxicj4NCjxiPkNjOjwvYj4gTWlrZSBK b25lczsgJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09B VVRILVdHXSBBdXRoZW50aWNhdGlvbiBNZXRob2QgUmVmZXJlbmNlIFZhbHVlcyBTcGVjaWZpY2F0 aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb27i gJl0IHBlcnNvbmFsbHkgaGF2ZSBhIHByb2JsZW0gd2l0aCBwZW9wbGUgZGVmaW5pbmcgdmFsdWVz IGZvciBBTVIgYW5kIGNyZWF0aW5nIGEgSUFOQSByZWdpc3RyeS4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgZXhpc3RzIGZvciBBQ1IuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0g b24gcmVjb3JkIGFzIG5vdCBzdXBwb3J0aW5nIGNsaWVudHMgcmVxdWVzdGluZyBhbXIgYXMgaXQg YWkgYSBiYWQgaWRlYSBhbmQgdGhlIHNwZWMgbWVudGlvbnMgdGhhdCBhdCB0aGUgc2FtZSB0aW1l IGl0IGRlZmluZXMgYSBuZXcgcmVxdWVzdCBwYXJhbWV0ZXIgZm9yIGl0LjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBpcyBwcm9iYWJseSBu b3Qgc29tZXRoaW5nIEkgd2lsbCBwdXQgYW55IHJlYWwgZWZmb3J0IGludG8gZmlnaHRpbmcsIGlm IHBlb3BsZSBpbnNpc3Qgb24gaXQuICZuYnNwO0kgd2lsbCBjb250aW51ZSB0byByZWNvbW1lbmQg b25seSB1c2luZyBBQ1IgaW4gdGhlIHJlcXVlc3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvaG4gQi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEp1bCAy MywgMjAxNSwgYXQgOToyMSBBTSwgSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpy aWNoZXJAbWl0LmVkdSI+anJpY2hlckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PlVzZWZ1bCB3b3JrLCBidXQgc2hvdWxkbuKAmXQgdGhpcyBiZSBkZWZpbmVkIGluIHRoZSBPSURG LCB3aGVyZSB0aGUg4oCcYW1yJnF1b3Q7IHBhcmFtZXRlciBpcyBkZWZpbmVkPzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJz cDvigJQgSnVzdGluPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk9uIEp1bCAyMiwgMjAxNSwgYXQgNzo0OCBQTSwg TWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv bSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t PC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5QaGlsIEh1bnQgYW5kIEkgaGF2ZSBw b3N0ZWQgYSBuZXcgZHJhZnQgdGhhdCBkZWZpbmVzIHNvbWUgdmFsdWVzIHVzZWQgd2l0aCB0aGUg 4oCcPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij5hbXI8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij7igJ0NCiAoQXV0aGVudGljYXRpb24gTWV0aG9kcyBSZWZlcmVuY2VzKSBjbGFpbSBhbmQgZXN0 YWJsaXNoZXMgYSByZWdpc3RyeSBmb3IgQXV0aGVudGljYXRpb24gTWV0aG9kIFJlZmVyZW5jZSB2 YWx1ZXMuJm5ic3A7IFRoZXNlIHZhbHVlcyBpbmNsdWRlIGNvbW1vbmx5IHVzZWQgYXV0aGVudGlj YXRpb24gbWV0aG9kcyBsaWtlIOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+cHdkPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+4oCdDQogKHBhc3N3b3JkKSBhbmQg4oCcPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij5vdHA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igJ0gKG9uZSB0aW1l IHBhc3N3b3JkKS4mbmJzcDsgSXQgYWxzbyBkZWZpbmVzIGEgcGFyYW1ldGVyIGZvciByZXF1ZXN0 aW5nIHRoYXQgc3BlY2lmaWMgYXV0aGVudGljYXRpb24gbWV0aG9kcw0KIGJlIHVzZWQgaW4gdGhl IGF1dGhlbnRpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGUgc3BlY2lmaWNhdGlvbiBpcyBhdmFpbGFi bGUgYXQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1 aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+wrc8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1vYXV0aC1hbXItdmFsdWVz LTAwIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtam9uZXMtb2F1dGgtYW1yLXZhbHVlcy0wMDwvc3Bhbj48L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkFuIEhUTUwgZm9ybWF0dGVkIHZlcnNpb24gaXMgYWxzbyBhdmFpbGFibGUgYXQ6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Imh0dHA6Ly9zZWxmLWlz c3VlZC5pbmZvL2RvY3MvZHJhZnQtam9uZXMtb2F1dGgtYW1yLXZhbHVlcy0wMC5odG1sIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0 LWpvbmVzLW9hdXRoLWFtci12YWx1ZXMtMDAuaHRtbDwvc3Bhbj48L2E+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlAuUy4mbmJzcDsgVGhpcyBub3RlIHdhcyBh bHNvIHBvc3RlZCBhdDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YSBocmVmPSJodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby8/cD0xNDI5Ij48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5odHRwOi8vc2VsZi1pc3N1ZWQuaW5mby8/cD0xNDI5PC9zcGFuPjwv YT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+YW5kDQog YXM8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJl Zj0iaHR0cHM6Ly90d2l0dGVyLmNvbS9zZWxmaXNzdWVkIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5Ac2VsZmlzc3VlZDwvc3Bhbj48L2E+LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N Ck9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+T0F1dGhAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGg8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBs aXN0PGJyPg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpwdXJwbGUiPk9BdXRoQGlldGYub3JnPC9zcGFuPjwv YT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGg8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BY2PR03MB4422C8D84A092E5A6D79C7EF5820BY2PR03MB442namprd_-- From nobody Thu Jul 23 01:49:51 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC1ED1A8A1A for ; Thu, 23 Jul 2015 01:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpqo4MEPCTXT for ; Thu, 23 Jul 2015 01:49:48 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 007881A9027 for ; Thu, 23 Jul 2015 01:49:47 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so8570516igb.0 for ; Thu, 23 Jul 2015 01:49:47 -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:content-type; bh=HXwOdNJP66qRvSDJ/2xVSktGU8TuobqsiYc34tchEQY=; b=R3lrPTtDfq1nfiSTxOB0foTg62gZRXloASP8dv5C0NN+SB6iXRAqBfoJT0iXOYPlTF WO/DSKZ/peWret9bpVMXv+wRqAUkNfW83NvbPqmzfq0JMd4wKbahg3DO+4Q7TJMEl5Dx oKHIUYEuBgXDVtZgb+qyRAkCmjdbsOx+kjeLQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=HXwOdNJP66qRvSDJ/2xVSktGU8TuobqsiYc34tchEQY=; b=fiPQgKxjCGAKT8oH5WI1j3TUPwkJqlh56jPdhybcDWou9M3l9Z14WGRu80EIK+VP7X M17Yz5aOLcW0JLREc/fooShE5ZVnDiG7SECN9oZtwKUWylmnEQPZjkciLt0Pb/cyu6Wv hhbHmlAG3WoDLMvjDf20Zh+mKRO6QaAfSEfkyr0VrtUG77KOdjRO934ryWw0lshDRhEd QzeuMNTpxEyRGrC7XyzMir6TRM0xZRFv/Ojm2sS8YYpqK6AJZ9PHb0bJ9qP2YfRnq8ly h6ruOuVVR0xlPDz87Oh4WdgLEMBjUJ9M2sXUjlQWzgoMpdnjn97WJnOdrUyYm99/OWDt WNFw== X-Gm-Message-State: ALoCoQmZ1mv7GMoIT0S/AWUWYZDYRK7979Xa7RmQsrpZv5unA5T2Nl+Z1qQJGwTf/i24YPgkuWyy X-Received: by 10.107.14.148 with SMTP id 142mr11043393ioo.175.1437641387473; Thu, 23 Jul 2015 01:49:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Thu, 23 Jul 2015 01:49:18 -0700 (PDT) In-Reply-To: References: <8BADFB60-1BE4-415A-B386-F34F9FE72A3C@mit.edu> <61575F9A-8A0F-415A-89AA-480432813020@ve7jtb.com> From: Brian Campbell Date: Thu, 23 Jul 2015 10:49:18 +0200 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=001a113fc47c37202b051b86f85a Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Authentication Method Reference Values Specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 08:49:50 -0000 --001a113fc47c37202b051b86f85a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So maybe a naive question but why does this draft define "amr_values" while also suggesting that it's fragile and that "acr" & "acr_values" is preferable? Seems contradictory. And I doubt I'm the only one that will find it confusing. On Thu, Jul 23, 2015 at 9:35 AM, Mike Jones wrote: > The key part of this is establishing a registry. That can only be done > in an RFC. > > > > John, I encourage you to submit text beefing up the arguments about why > using =E2=80=9Cacr=E2=80=9D is preferable. The text at > http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html#acrRela= tionship > is a start at that. > > > > -- Mike > > > > *From:* John Bradley [mailto:ve7jtb@ve7jtb.com] > *Sent:* Thursday, July 23, 2015 9:30 AM > *To:* Justin Richer > *Cc:* Mike Jones; > *Subject:* Re: [OAUTH-WG] Authentication Method Reference Values > Specification > > > > I don=E2=80=99t personally have a problem with people defining values for= AMR and > creating a IANA registry. > > > > That exists for ACR. > > > > I am on record as not supporting clients requesting amr as it ai a bad > idea and the spec mentions that at the same time it defines a new request > parameter for it. > > > > It is probably not something I will put any real effort into fighting, if > people insist on it. I will continue to recommend only using ACR in the > request. > > > > John B. > > > > On Jul 23, 2015, at 9:21 AM, Justin Richer wrote: > > > > Useful work, but shouldn=E2=80=99t this be defined in the OIDF, where the= =E2=80=9Camr" > parameter is defined? > > > > =E2=80=94 Justin > > > > On Jul 22, 2015, at 7:48 PM, Mike Jones > wrote: > > > > Phil Hunt and I have posted a new draft that defines some values used wit= h > the =E2=80=9Camr=E2=80=9D (Authentication Methods References) claim and e= stablishes a > registry for Authentication Method Reference values. These values includ= e > commonly used authentication methods like =E2=80=9Cpwd=E2=80=9D (password= ) and =E2=80=9Cotp=E2=80=9D (one > time password). It also defines a parameter for requesting that specific > authentication methods be used in the authentication. > > > > The specification is available at: > > =C2=B7 https://tools.ietf.org/html/draft-jones-oauth-amr-values-00 > > > > An HTML formatted version is also available at: > > =C2=B7 http://self-issued.info/docs/draft-jones-oauth-amr-values-0= 0.html > > > > -- Mike > > > > P.S. This note was also posted at http://self-issued.info/?p=3D1429 and = as > @selfissued . > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a113fc47c37202b051b86f85a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So maybe a naive question but why does this draft define &= quot;amr_values" while also suggesting that it's fragile and that = "acr" & "acr_values" is preferable? Seems contradic= tory. And I doubt I'm the only one that will find it confusing.=C2=A0 <= br>

On Thu, = Jul 23, 2015 at 9:35 AM, Mike Jones <Michael.Jones@microsoft.com= > wrote:

The key part of this is e= stablishing a registry.=C2=A0 That can only be done in an RFC.

=C2=A0

John, I encourage you to = submit text beefing up the arguments about why using =E2=80=9Cacr=E2=80=9D = is preferable.=C2=A0 The text at http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html#acrRelati= onship is a start at that.

=C2=A0

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

=C2=A0

From: John Bra= dley [mailto:ve7jtb@= ve7jtb.com]
Sent: Thursday, July 23, 2015 9:30 AM
To: Justin Richer
Cc: Mike Jones; <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Authentication Method Reference Values Speci= fication

=C2=A0

I don=E2=80=99t personally have a problem with peopl= e defining values for AMR and creating a IANA registry.=C2=A0=

=C2=A0

That exists for ACR.

=C2=A0

I am on record as not supporting clients requesting = amr as it ai a bad idea and the spec mentions that at the same time it defi= nes a new request parameter for it.

=C2=A0

It is probably not something I will put any real eff= ort into fighting, if people insist on it.=C2=A0 I will continue to recomme= nd only using ACR in the request.

=C2=A0

John B.

=C2=A0

On Jul 23, 2015, at 9:21 AM, Justin Richer <jricher@mit.edu> wro= te:

=C2=A0

Useful work, but shouldn=E2=80=99t thi= s be defined in the OIDF, where the =E2=80=9Camr" parameter is defined= ?

=C2=A0

=C2=A0=E2=80=94 Justin

=C2=A0

On Jul 22, 2015, at 7:48 PM, Mike Jone= s <Michael.Jones@microsoft.com> wrote:<= u>

=C2=A0

Phil Hunt and I have posted a new draft= that defines some values used with the =E2=80=9Camr= =E2=80=9D (Authentication Methods References) claim and establishes a registry for A= uthentication Method Reference values.=C2=A0 These values include commonly = used authentication methods like =E2=80=9Cpwd=E2=80=9D (password) and =E2=80=9Cotp=E2=80=9D (one time passwo= rd).=C2=A0 It also defines a parameter for requesting that specific authent= ication methods be used in the authentication.

=C2=A0

The specification is available at:

= =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0https://tools.ietf.org/html/draft-jones-oauth-amr-value= s-00

=C2=A0

An HTML formatted version is also avail= able at:

= =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0http://self-issued.info/docs/draft-jones-oauth-am= r-values-00.html

=C2=A0

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

=C2=A0

P.S.=C2=A0 This note was also posted at= =C2=A0http://self-issued.info/?p=3D1429=C2=A0and as=C2=A0@selfissued.<= /span>

______________________________________= _________
OAuth mailing list
OAuth@ietf.org
<= span style=3D"color:purple">https://www.ietf.org/mailman/listinfo/oauth

=C2=A0

______________________________________= _________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oaut= h

=C2=A0


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


--001a113fc47c37202b051b86f85a-- From nobody Thu Jul 23 02:56:06 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4B41A00B2 for ; Thu, 23 Jul 2015 02:56:04 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9Vih7yH_g34 for ; Thu, 23 Jul 2015 02:56:02 -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 0CE5D1A000E for ; Thu, 23 Jul 2015 02:56:01 -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 t6N9u0Uu021585 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 Jul 2015 09:56:01 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 t6N9u0Ze004354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 23 Jul 2015 09:56:00 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t6N9tXT2028481; Thu, 23 Jul 2015 09:55:33 GMT Received: from [31.133.161.246] (/31.133.161.246) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 23 Jul 2015 02:55:32 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-DD89F83B-98ED-49D3-99AB-A505FA1819B7 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12F70) In-Reply-To: <61575F9A-8A0F-415A-89AA-480432813020@ve7jtb.com> Date: Thu, 23 Jul 2015 11:55:30 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <8BADFB60-1BE4-415A-B386-F34F9FE72A3C@mit.edu> <61575F9A-8A0F-415A-89AA-480432813020@ve7jtb.com> To: John Bradley X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Authentication Method Reference Values Specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 09:56:04 -0000 --Apple-Mail-DD89F83B-98ED-49D3-99AB-A505FA1819B7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I do tend to agree John that clients shouldn't be able to force the sp on ch= oices.=20 My thought was that it was useful to have a registry so we can have standard= auth method values for protocols that get written like oidc. It may be use= ful elsewhere.=20 Anyway as a general rule I think it is sometimes useful for a client to sign= al a preference or capability in order that the server can make a good choic= e that meets its own needs.=20 Phil > On Jul 23, 2015, at 09:30, John Bradley wrote: >=20 > I don=E2=80=99t personally have a problem with people defining values for A= MR and creating a IANA registry.=20 >=20 > That exists for ACR. >=20 > I am on record as not supporting clients requesting amr as it ai a bad ide= a and the spec mentions that at the same time it defines a new request param= eter for it. >=20 > It is probably not something I will put any real effort into fighting, if p= eople insist on it. I will continue to recommend only using ACR in the requ= est. >=20 > John B. >=20 >> On Jul 23, 2015, at 9:21 AM, Justin Richer wrote: >>=20 >> Useful work, but shouldn=E2=80=99t this be defined in the OIDF, where the= =E2=80=9Camr" parameter is defined? >>=20 >> =E2=80=94 Justin >>=20 >>> On Jul 22, 2015, at 7:48 PM, Mike Jones wr= ote: >>>=20 >>> Phil Hunt and I have posted a new draft that defines some values used wi= th the =E2=80=9Camr=E2=80=9D (Authentication Methods References) claim and e= stablishes a registry for Authentication Method Reference values. These val= ues include commonly used authentication methods like =E2=80=9Cpwd=E2=80=9D (= password) and =E2=80=9Cotp=E2=80=9D (one time password). It also defines a p= arameter for requesting that specific authentication methods be used in the a= uthentication. >>> =20 >>> The specification is available at: >>> =C2=B7 https://tools.ietf.org/html/draft-jones-oauth-amr-values-0= 0 >>> =20 >>> An HTML formatted version is also available at: >>> =C2=B7 http://self-issued.info/docs/draft-jones-oauth-amr-values-= 00.html >>> =20 >>> -- Mike >>> =20 >>> P.S. This note was also posted at http://self-issued.info/?p=3D1429 and= as @selfissued. >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-DD89F83B-98ED-49D3-99AB-A505FA1819B7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I do tend to agree John that clients s= houldn't be able to force the sp on choices. 

= My thought was that it was useful to have a registry so we can have standard= auth method values for protocols that get written like oidc.  It may b= e useful elsewhere. 

Anyway as a general rule I= think it is sometimes useful for a client to signal a preference or capabil= ity in order that the server can make a good choice that meets its own needs= . 

Phil

On Jul 23, 2015, at 09:30, John Bra= dley <ve7jtb@ve7jtb.com> wrot= e:

I don=E2=80=99t personally have a= problem with people defining values for AMR and creating a IANA registry.&n= bsp;

That exists for ACR= .

I am on record a= s not supporting clients requesting amr as it ai a bad idea and the spec men= tions that at the same time it defines a new request parameter for it.
=

It is probably not some= thing I will put any real effort into fighting, if people insist on it. &nbs= p;I will continue to recommend only using ACR in the request.

John B.
=
On Jul 23, 2015, at 9:21 AM, Justin Richer <jricher@mit.edu> wrote:

Useful work, but shouldn=E2=80=99= t this be defined in the OIDF, where the =E2=80=9Camr" parameter is defined?=

 =E2=80=94 Justin

On Jul 22, 2015, at 7:48 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Phil Hunt and I have posted a new draft that de= fines some values used with the =E2=80=9Camr=E2=80=9D (Authentication Methods References) c= laim and establishes a registry for Authentication Method Reference values.&= nbsp; These values include commonly used authentication methods like =E2=80=9C= pwd=E2=80=9D (= password) and =E2=80=9C
 
The specification is availabl= e at:
 
An HTML format= ted version is also available at:
=C2=B7     &nbs= p;  http:/= /self-issued.info/docs/draft-jones-oauth-amr-values-00.html
 
=
        &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ; -- Mike
 
P.S.  This note was als= o posted at http://self-issued.info/?p=3D1429 and as=  @selfissued.=
_______________________________________________
OAuth mailing list
OAuth@ietf.= org
https://ww= w.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-DD89F83B-98ED-49D3-99AB-A505FA1819B7-- From nobody Thu Jul 23 03:05:53 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B30FC1A0267 for ; Thu, 23 Jul 2015 03:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QW6Adhpt0rjC for ; Thu, 23 Jul 2015 03:05:47 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 565611A01FA for ; Thu, 23 Jul 2015 03:05:46 -0700 (PDT) Received: by ykdu72 with SMTP id u72so215337718ykd.2 for ; Thu, 23 Jul 2015 03:05:45 -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:content-type; bh=KILyzdUHnUdQRFK74vgWNX/MV7gJYCmL5GAfb5iU2cI=; b=GqQ88AWafqxGYbIQi8819ezQ3uB0pmQ3XcHlMlmOks1EngQNS7QgSU0oMHYd6GksWZ NCGW+kRDux5Wa2RvbEJvQprMMO/zSB54CxLlzbqGWgpXIL9pDPbrAvuyy1jOJFsfNULT DwTFc6hkOpo7n3qVFK3x+jJLGFViFmSNylINWNN1y3Z947QNCwYCmW4DanlML/m5itlP F0MskFIaEIyFF2plBABVVoxUnB55vxxq6+seynoebATywjVFrGF4pPd0kxW2r6MKUNAr +/vc2YHq1gYZNOWNsQMcEjGZ2C53GXV6vGrrribFb9SfRehMe0LbHrn3dd6yCUH1G0Ft ERJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=KILyzdUHnUdQRFK74vgWNX/MV7gJYCmL5GAfb5iU2cI=; b=YaZsYlnPD0/YuGynM+djsgpCVdJMwP5oMNil9TO85+xfyhbzhb+Equ7wuHr3eRu9Zv 2O89kwdnBK3dWGDGDnYv91bIzthp83W7YfO26HzR5O2xnZJeAtfpmw4zSAVElgFXXjnG MW2zFejsA939FcgRd75Rsc8FmzcrR+yxWcnFUmbxThayz8JFa78PL3SHHV2vKw44evoa tbMXtbPet+Hq3omcWkBwHaBEcUVfTgHJDG3blRjE+gKbW3CiEAUgLhXYcsHUHpKy0Jbu va3iCUvzJwBj3/qvPkeLwe+aHDV4thClPtl21cLAmX+EpoaxAyISm+iF/FS+IkoYgwcM dASQ== X-Gm-Message-State: ALoCoQkMocNj9iKRcnjzyOnZyrUDEtBmffTGzdwSGqlIYl0PkfErHRwNFWq9hnYNt75eOVMAsaWh X-Received: by 10.170.168.65 with SMTP id k62mr6986698ykd.99.1437645945592; Thu, 23 Jul 2015 03:05:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.50.23 with HTTP; Thu, 23 Jul 2015 03:05:26 -0700 (PDT) In-Reply-To: References: <8BADFB60-1BE4-415A-B386-F34F9FE72A3C@mit.edu> <61575F9A-8A0F-415A-89AA-480432813020@ve7jtb.com> From: William Denniss Date: Thu, 23 Jul 2015 12:05:26 +0200 Message-ID: To: Brian Campbell Content-Type: multipart/alternative; boundary=001a11398032e6b08f051b88077e Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Authentication Method Reference Values Specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 10:05:50 -0000 --001a11398032e6b08f051b88077e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for drafting this Mike. I'm in favor of having this registry. In addition to the specific values, I propose we add some generic ones too (trying to follow your naming scheme): "rba": "risk-based auth" "upt": "user presence test" My fear of making things too specific is that RPs may get lost in the weeds trying to work out what things they should care about and how. As an IdP we like to guide RPs through these kinds of decisions, and prefer to pass a more high level indication of what happened (such as these two values). If someone wanted to have best of both worlds, then both could be asserted, e.g. "upt fpt" to indicate that the user presence was tested, using a fingerprint test. Regarding the proposed "wia" value. I don't know what it is, and the spec doesn't help me find out, can a reference be added? I also wonder if it could be genericized to avoid being vendor specific values =E2=80=93 but mo= stly I just want to understand what it is. Almost all the other values are self-explanatory, perhaps "pop" could use a reference as well (or maybe just a longer explanation). I don't see the immediate value of "amr_values", can you elaborate with some places where this would be applied? Separately, I wonder if an extension to OIDC should be included in this doc, which is otherwise a fairly clean registry spec that could be used more broadly. On Thu, Jul 23, 2015 at 10:49 AM, Brian Campbell wrote: > So maybe a naive question but why does this draft define "amr_values" > while also suggesting that it's fragile and that "acr" & "acr_values" is > preferable? Seems contradictory. And I doubt I'm the only one that will > find it confusing. > > On Thu, Jul 23, 2015 at 9:35 AM, Mike Jones > wrote: > >> The key part of this is establishing a registry. That can only be done >> in an RFC. >> >> >> >> John, I encourage you to submit text beefing up the arguments about why >> using =E2=80=9Cacr=E2=80=9D is preferable. The text at >> http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html#acrRel= ationship >> is a start at that. >> >> >> >> -- Mike >> >> >> >> *From:* John Bradley [mailto:ve7jtb@ve7jtb.com] >> *Sent:* Thursday, July 23, 2015 9:30 AM >> *To:* Justin Richer >> *Cc:* Mike Jones; >> *Subject:* Re: [OAUTH-WG] Authentication Method Reference Values >> Specification >> >> >> >> I don=E2=80=99t personally have a problem with people defining values fo= r AMR and >> creating a IANA registry. >> >> >> >> That exists for ACR. >> >> >> >> I am on record as not supporting clients requesting amr as it ai a bad >> idea and the spec mentions that at the same time it defines a new reques= t >> parameter for it. >> >> >> >> It is probably not something I will put any real effort into fighting, i= f >> people insist on it. I will continue to recommend only using ACR in the >> request. >> >> >> >> John B. >> >> >> >> On Jul 23, 2015, at 9:21 AM, Justin Richer wrote: >> >> >> >> Useful work, but shouldn=E2=80=99t this be defined in the OIDF, where th= e =E2=80=9Camr" >> parameter is defined? >> >> >> >> =E2=80=94 Justin >> >> >> >> On Jul 22, 2015, at 7:48 PM, Mike Jones >> wrote: >> >> >> >> Phil Hunt and I have posted a new draft that defines some values used >> with the =E2=80=9Camr=E2=80=9D (Authentication Methods References) claim= and establishes >> a registry for Authentication Method Reference values. These values >> include commonly used authentication methods like =E2=80=9Cpwd=E2=80=9D = (password) and =E2=80=9C >> otp=E2=80=9D (one time password). It also defines a parameter for reque= sting >> that specific authentication methods be used in the authentication. >> >> >> >> The specification is available at: >> >> =C2=B7 https://tools.ietf.org/html/draft-jones-oauth-amr-values-0= 0 >> >> >> >> An HTML formatted version is also available at: >> >> =C2=B7 >> http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html >> >> >> >> -- Mike >> >> >> >> P.S. This note was also posted at http://self-issued.info/?p=3D1429 and= as >> @selfissued . >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a11398032e6b08f051b88077e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for drafting this Mike. I'm in favor of having = this registry.

In addition to the specific values, I pro= pose we add some generic ones too (trying to follow your naming scheme):

"rba": =C2=A0"risk-based auth"
"upt": =C2=A0"user presence test"
My fear of making things too specific is that RPs may get lost= in the weeds trying to work out what things they should care about and how= . As an IdP we like to guide RPs through these kinds of decisions, and pref= er to pass a more high level indication of what happened (such as these two= values).=C2=A0 If someone wanted to have best of both worlds, then both co= uld be asserted, e.g. "upt fpt" to indicate that the user presenc= e was tested, using a fingerprint test.

Regarding = the proposed "wia" value. I don't know what it is, and the sp= ec doesn't help me find out, can a reference be added?=C2=A0 I also won= der if it could be genericized to avoid being vendor specific values =E2=80= =93 but mostly I just want to understand what it is.=C2=A0 Almost all the o= ther values are self-explanatory, perhaps "pop" could use a refer= ence as well (or maybe just a longer explanation).

I don't see the immediate value of "amr_values", can you ela= borate with some places where this would be applied?=C2=A0 Separately, I wo= nder if an extension to OIDC should be included in this doc, which is other= wise a fairly clean registry spec that could be used more broadly.

On Thu, Jul 23, 2015= at 10:49 AM, Brian Campbell <bcampbell@pingidentity.com><= /span> wrote:
So maybe a= naive question but why does this draft define "amr_values" while= also suggesting that it's fragile and that "acr" & "= ;acr_values" is preferable? Seems contradictory. And I doubt I'm t= he only one that will find it confusing.=C2=A0

On Thu, Jul 23, 2015 at 9= :35 AM, Mike Jones <Michael.Jones@microsoft.com> w= rote:

The key part of this is e= stablishing a registry.=C2=A0 That can only be done in an RFC.

=C2=A0

John, I encourage you to = submit text beefing up the arguments about why using =E2=80=9Cacr=E2=80=9D = is preferable.=C2=A0 The text at http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html#acrRelati= onship is a start at that.

=C2=A0

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

=C2=A0

From: John Bra= dley [mailto:ve7jtb@= ve7jtb.com]
Sent: Thursday, July 23, 2015 9:30 AM
To: Justin Richer
Cc: Mike Jones; <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Authentication Method Reference Values Speci= fication

=C2=A0

I don=E2=80=99t personally have a problem with peopl= e defining values for AMR and creating a IANA registry.=C2=A0=

=C2=A0

That exists for ACR.

=C2=A0

I am on record as not supporting clients requesting = amr as it ai a bad idea and the spec mentions that at the same time it defi= nes a new request parameter for it.

=C2=A0

It is probably not something I will put any real eff= ort into fighting, if people insist on it.=C2=A0 I will continue to recomme= nd only using ACR in the request.

=C2=A0

John B.

=C2=A0

On Jul 23, 2015, at 9:21 AM, Justin Richer <jricher@mit.edu> wro= te:

=C2=A0

Useful work, but shouldn=E2=80=99t thi= s be defined in the OIDF, where the =E2=80=9Camr" parameter is defined= ?

=C2=A0

=C2=A0=E2=80=94 Justin

=C2=A0

On Jul 22, 2015, at 7:48 PM, Mike Jone= s <Michael.Jones@microsoft.com> wrote:<= u>

=C2=A0

Phil Hunt and I have posted a new draft= that defines some values used with the =E2=80=9Camr= =E2=80=9D (Authentication Methods References) claim and establishes a registry for A= uthentication Method Reference values.=C2=A0 These values include commonly = used authentication methods like =E2=80=9Cpwd=E2=80=9D (password) and =E2=80=9Cotp=E2=80=9D (one time passwo= rd).=C2=A0 It also defines a parameter for requesting that specific authent= ication methods be used in the authentication.

=C2=A0

The specification is available at:

= =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0https://tools.ietf.org/html/draft-jones-oauth-amr-value= s-00

=C2=A0

An HTML formatted version is also avail= able at:

= =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0http://self-issued.info/docs/draft-jones-oauth-am= r-values-00.html

=C2=A0

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

=C2=A0

P.S.=C2=A0 This note was also posted at= =C2=A0http://self-issued.info/?p=3D1429=C2=A0and as=C2=A0@selfissued.<= /span>

______________________________________= _________
OAuth mailing list
OAuth@ietf.org
<= span style=3D"color:purple">https://www.ietf.org/mailman/listinfo/oauth

=C2=A0

______________________________________= _________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oaut= h

=C2=A0


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



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


--001a11398032e6b08f051b88077e-- From nobody Thu Jul 23 04:03:56 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467A61A7005 for ; Thu, 23 Jul 2015 04:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnJ9vOjkJlGF for ; Thu, 23 Jul 2015 04:03:54 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::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 2CD711A1A34 for ; Thu, 23 Jul 2015 04:03:54 -0700 (PDT) Received: by ietj16 with SMTP id j16so189359165iet.0 for ; Thu, 23 Jul 2015 04:03:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=nUwV+RPxDdHEHCnEq8SoPx4XB2UhWdJ3yauvrplbNr4=; b=nKwWGgUQRJli5aT9l4pSVm59eKJH2lOQZ8XZGJOIxMFhZbVthe/lguSBDf1fDC6tPN Upy0DLYj3JDCaOa5B0okXDO5pd8UdY74I/k/BeVCl3LhBWZtLiHykBb/V9hk7Bbvibk1 55h90AD01LTVZYckVoVVQqsyIP+Fwu26Ibi58RaJprCxzZu5EMt7VQB6ydBMrz3zjOve /7cHpArSacASlwaHlcHaV6bfGsMezK4Ec/W3f+Y8+hUlINZTScgSeZ/+JX1mEfDqIRKO FYLqVshCXz3enZcypl8RKE3FM9ot63qvLWQlAaXNMp/kcB6eqP5AvnJWfHI0ee6lMixL yWNg== MIME-Version: 1.0 X-Received: by 10.50.176.164 with SMTP id cj4mr40148656igc.55.1437649433693; Thu, 23 Jul 2015 04:03:53 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.133.95 with HTTP; Thu, 23 Jul 2015 04:03:53 -0700 (PDT) In-Reply-To: References: <84019235-22F4-4BBA-8A45-558E7C65D5D1@mit.edu> <6103DF00-147C-469E-B360-93F365599F3F@mit.edu> <941211DE-F224-435D-8206-42ED464A9F20@ve7jtb.com> Date: Thu, 23 Jul 2015 07:03:53 -0400 X-Google-Sender-Auth: Bv7pGhLNxIBqHj7fwTDBmDOt4vQ Message-ID: From: Barry Leiba To: Nat Sakimura Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] OAuth implementation fail X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 11:03:55 -0000 > Now, as to the spec change is concerned, I agree with John that it is not > required. > > However, a Best practice document would probably help the developers. That's exactly what I had in mind -- no spec change, but something (or some things) to help guide developers into do the right thing, security-wise and user-experience-wise. Thanks, everyone, for discussing this. Barry From nobody Thu Jul 23 07:18:36 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819F31ACE0B for ; Thu, 23 Jul 2015 07:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBLU79ZjajFx for ; Thu, 23 Jul 2015 07:18:34 -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 CB1901ACDE8 for ; Thu, 23 Jul 2015 07:18:33 -0700 (PDT) Received: from [192.168.10.140] ([31.133.161.51]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lv9lm-1YsBek0nbe-010Phf for ; Thu, 23 Jul 2015 16:18:32 +0200 Message-ID: <55B0F7B6.7000705@gmx.net> Date: Thu, 23 Jul 2015 16:18:30 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ulUIhmlBBcfs86SFFWj5IAceUfmoURUfn" X-Provags-ID: V03:K0:+RsX5OW68lZxul51Jjgg69xxeP9DsfGqJ2IGGNMuDow4qQlgJkB Iw/qSUI5neWjmaUj9SfID8TU/9juONctPBLi9Sc0yAHA97JFEdgwIjaP2GmU0Lj3avih55S nJnHIjWDWMjCZrViY0g5SB5UZwJSQJxtRfYCj01g85efy5b1WojKRrAnIorrNv2/Q8zalVe kUKsraZujvo9f35v1FZgA== X-UI-Out-Filterresults: notjunk:1;V01:K0:SxWEsX0zQmY=:UP0e77uRCqc+yXv6NrhTKu JoRtn2+7I7dDRjZfE7zIFATrrnK1PbUtmBCNzFL7Jq6myTowUsgzCv9qaaQLyjDc02djKrr29 HkFl/zIJ7hhya/GY1AFYCvnRqj4MoRUW6BE9VMJFynxhPpuKmTJtSZqthQIF1dQwbgk++EgZ0 3yTKuU22Khp2TGNV2N+FTzlhhe40opF39s15Mq/sY3W0wp2l3sJTgAyRGGSFBX4ShQ+b5O33Q CQHdO7zVE6I+ANoMRhwDfnTaZWbsA1TCqNfHKEvtUBqRsfO2kC6GHHbC2vbduraRBor11swrz p36nrajrKxzjinVSLfKiU/LZWbiVJ6p/v9rMkUjEnOyWvAnj+XfR7vFKJkyP7lQObbGgFAyra XTviKZYx7S9gDOAi0NM9E6YbPpbu/F61CQeVeZzV+t5ojX3m9p3bq4o9ZORCiJpZx+EYBS4v5 o54RYt40OWu4Gj1pW3gZzMiMZ/LQIkp38u1/QfO9YgPq8zxJy8eRukSSSI3AxRtj34kOtCaNb wO03oh3noI5RoMh9qj+Wnle7Ux801zNV2BNoeQNruun4Ja2nav7AI910o/xoW5KOKLXugKuPk Q7n+OJx0BM1ryF+t/2ZZSG7uGNo17Z282yh/lkTRalCpVEWhqB8uO4yncF6NMfglpN106WBZu HJTHJpqlikaK3SQF+0lwmOCBNh5VdiN36D7H+vPNlnkj4wQ== Archived-At: Subject: [OAUTH-WG] Meeting Minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 14:18:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ulUIhmlBBcfs86SFFWj5IAceUfmoURUfn Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Here are the notes from our meeting yesterday: https://www.ietf.org/proceedings/93/minutes/minutes-93-oauth Thanks to Erik for taking notes. Please let me know if something is missing or incorrect within the next 2 weeks. Ciao Hannes --ulUIhmlBBcfs86SFFWj5IAceUfmoURUfn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVsPe2AAoJEGhJURNOOiAth6sH/37+t1no4tV0doy+mSTX+eO0 iN9CqKhBOttiYeGKmK1K6b1aRWNUMo56uPsDGTIZRJIoAVv7gS6rPUJSBdZbibV+ 4fvqrC5hxbBVoawk+9SWMGGKVwHv4eSLlyRBqJ8Oudyi2O3PDoonvoNbaSWVBcim KVnv9/rYLYwjJTmFbc7Q+3ceXquSc8wrzybbuLWCzEtszdSaqo64/wBE2dDNZwVN bNplqhPPSGIH7U1d74OFYDaLHu5076x6i3TWCb/G7OIYfQ1e6L7u6XQjiBUUvD8R DZtxPHyxRr1A9lXS6O2ED9sJY0EP3S2Y/7KmJJpsaOtmBRwXbWM/DfkqK/e9QoE= =KwdF -----END PGP SIGNATURE----- --ulUIhmlBBcfs86SFFWj5IAceUfmoURUfn-- From nobody Thu Jul 23 07:21:08 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48FE1ACE19 for ; Thu, 23 Jul 2015 07:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DimxagR5_9Z2 for ; Thu, 23 Jul 2015 07:21:05 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 010EA1ACE26 for ; Thu, 23 Jul 2015 07:20:48 -0700 (PDT) Received: by qkfc129 with SMTP id c129so131316234qkf.1 for ; Thu, 23 Jul 2015 07:20:47 -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:content-type; bh=bIxah4aO13aUCXYfVaLPgzsWW9RPWxTEnr3Pj/R2JFA=; b=nztYxDZAR6hdBjbzi0XyRT1I5s+BI7RHFdhmphf/ikhAJyMxnFbIHEBFcICt34Ihqr ErOj8tZ6fDtQzzl7tOqaVQ4LfrjpuZnBNmZiKo3zFNwMFpohBBQaOqKJYyyHqxtQEiOT 9p9MaZQwZXpazzThz2ZhLhyMyw0P0YCl5ZfYp1IB7HFD/FHs42tRL1oSTpa55ItTkx+a OgBt8SE2dFmKNpkKsaLCg0KD8FRTH4uO7FNvdHWUvMNhA0dRkvE4FAcvDitMilXf60cQ BOv1nxSDZNy+5Sfm5MxOX5KCrxpxiSftMADX2GrQOGLh7dutmGeMN5pCfaIXoe+7+9QZ KLSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=bIxah4aO13aUCXYfVaLPgzsWW9RPWxTEnr3Pj/R2JFA=; b=kuQN2dh28LbhYuxx2lJVh8AJIRw/sCsvoIalRzWJa9EUo4ZR0oqepTDyMVNmcKtuQi uVVwqMqUc+9Pd0+mkjSXw45gl67A0hxurfhtf0UC9krBhqu+fchhA1xV/rhFuN9LcmIO NNqAU2dxFaMW06XWS21IkNhGy6ApBzr6Duyqef78Pd42+1iuvjY9rThEC0MriANuCwfZ jpFx3LtPq7bEW24fIePsFVY2sq9AG0UqStuWPphuuZnYyMNaVyFJiWVI8ECEaI74avG0 J6sReJbNqIHZVyD9dHtCGBWZdGMmj1Q9Dqktpq8FOvwf+Cx0POfr/0EnpsKHvvFqSoU1 hZyw== X-Gm-Message-State: ALoCoQlnKxGk0sZubFoGqaItp6VSAjWq/9EOe6X7tW2xK73F2BynQI2Tlyc9SajeeQU+CQAKUH4V X-Received: by 10.55.23.161 with SMTP id 33mr12725810qkx.48.1437661247116; Thu, 23 Jul 2015 07:20:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.19.98 with HTTP; Thu, 23 Jul 2015 07:20:27 -0700 (PDT) From: William Denniss Date: Thu, 23 Jul 2015 16:20:27 +0200 Message-ID: To: "oauth@ietf.org" Content-Type: multipart/alternative; boundary=001a11473bb2f15231051b8b972a Archived-At: Subject: [OAUTH-WG] OAuth 2.0 for Native Apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 14:21:06 -0000 --001a11473bb2f15231051b8b972a Content-Type: text/plain; charset=UTF-8 John Bradley and I introduced a new draft at IETF93 yesterday: https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00 Goal is to provide best practices for native apps using the RFC6749 authorization endpoint, expanding on RFC6749 Section 9. Specifically, it recommends using an external user-agent (such as the system browser) for this task over an embedded user-agent (such as a web-view), and suggests ways to achieve this. Comments welcome! --001a11473bb2f15231051b8b972a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

John Bradley and I introduced a new draft at IETF93 yesterday:=C2= =A0https://tools.ietf.= org/html/draft-wdenniss-oauth-native-apps-00


Goal is to prov= ide best practices for native apps using the=C2=A0RFC6749 authorization endpoint, expanding on=C2=A0RFC6749=C2=A0Section 9.=C2=A0 Specifically, it recommends using an = external user-agent (such as the system browser) for this task over an embe= dded user-agent (such as a web-view), and suggests ways to achieve this.


Comments welcome!


--001a11473bb2f15231051b8b972a-- From nobody Thu Jul 23 09:22:11 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8845D1A0105 for ; Thu, 23 Jul 2015 09:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cCCGxPlaBiC for ; Thu, 23 Jul 2015 09:22:07 -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 9497D1A0545 for ; Thu, 23 Jul 2015 09:22:07 -0700 (PDT) Received: by obnw1 with SMTP id w1so156804745obn.3 for ; Thu, 23 Jul 2015 09:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nPDu5kMyoV+7LN28ikJuCukCtudin3wOCfM5lBcEIgo=; b=VtM0mY4z4pvMJRxfcwHUnFaJyehs7WNhTlWG6EFCsmLCOmlRAVmp97w8IbeKPtj3aO IRZb3OebpgyO00a4SIzZYBVXQduW3fa1MlhodjtmCdDWqU4GxZLagIRM1hx582qg2jo1 WvR3HShn48LjHip1yL1Q56G5hH8IyJbV4FdU4g0rbMtpcmncNPw4QREysryKwPeG7u/R 1KCmTt+i3uyeXE+YwlmzUvym0A7HCG8+2F+JLLibwKh6JKu/JbV//kF5+WISZ+3SN/51 mOM9QpHCf9xfuuppsds2L1aoS86QDRcc1zIZM0EgCp3jX8SS7b115Be8Z0Z9OjTAoo6M xtxA== MIME-Version: 1.0 X-Received: by 10.182.29.68 with SMTP id i4mr9285193obh.57.1437668527022; Thu, 23 Jul 2015 09:22:07 -0700 (PDT) Received: by 10.182.96.66 with HTTP; Thu, 23 Jul 2015 09:22:06 -0700 (PDT) In-Reply-To: References: <8BADFB60-1BE4-415A-B386-F34F9FE72A3C@mit.edu> <61575F9A-8A0F-415A-89AA-480432813020@ve7jtb.com> Date: Thu, 23 Jul 2015 18:22:06 +0200 Message-ID: From: Nat Sakimura To: William Denniss Content-Type: multipart/alternative; boundary=001a11c2993adba999051b8d49bd Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Authentication Method Reference Values Specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 16:22:10 -0000 --001a11c2993adba999051b8d49bd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So, allow me a naive question. I supppose there are good random otp, as well as pretty bad otp etc. Would it be useful to say just "otp". Would it not be better to have at least a field that references a spec that specifies the security requirement for that mechanism? 2015-07-23 12:05 GMT+02:00 William Denniss : > Thanks for drafting this Mike. I'm in favor of having this registry. > > In addition to the specific values, I propose we add some generic ones to= o > (trying to follow your naming scheme): > > "rba": "risk-based auth" > "upt": "user presence test" > > My fear of making things too specific is that RPs may get lost in the > weeds trying to work out what things they should care about and how. As a= n > IdP we like to guide RPs through these kinds of decisions, and prefer to > pass a more high level indication of what happened (such as these two > values). If someone wanted to have best of both worlds, then both could = be > asserted, e.g. "upt fpt" to indicate that the user presence was tested, > using a fingerprint test. > > Regarding the proposed "wia" value. I don't know what it is, and the spec > doesn't help me find out, can a reference be added? I also wonder if it > could be genericized to avoid being vendor specific values =E2=80=93 but = mostly I > just want to understand what it is. Almost all the other values are > self-explanatory, perhaps "pop" could use a reference as well (or maybe > just a longer explanation). > > I don't see the immediate value of "amr_values", can you elaborate with > some places where this would be applied? Separately, I wonder if an > extension to OIDC should be included in this doc, which is otherwise a > fairly clean registry spec that could be used more broadly. > > On Thu, Jul 23, 2015 at 10:49 AM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> So maybe a naive question but why does this draft define "amr_values" >> while also suggesting that it's fragile and that "acr" & "acr_values" is >> preferable? Seems contradictory. And I doubt I'm the only one that will >> find it confusing. >> >> On Thu, Jul 23, 2015 at 9:35 AM, Mike Jones >> wrote: >> >>> The key part of this is establishing a registry. That can only be >>> done in an RFC. >>> >>> >>> >>> John, I encourage you to submit text beefing up the arguments about why >>> using =E2=80=9Cacr=E2=80=9D is preferable. The text at >>> http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html#acrRe= lationship >>> is a start at that. >>> >>> >>> >>> -- Mike >>> >>> >>> >>> *From:* John Bradley [mailto:ve7jtb@ve7jtb.com] >>> *Sent:* Thursday, July 23, 2015 9:30 AM >>> *To:* Justin Richer >>> *Cc:* Mike Jones; >>> *Subject:* Re: [OAUTH-WG] Authentication Method Reference Values >>> Specification >>> >>> >>> >>> I don=E2=80=99t personally have a problem with people defining values f= or AMR >>> and creating a IANA registry. >>> >>> >>> >>> That exists for ACR. >>> >>> >>> >>> I am on record as not supporting clients requesting amr as it ai a bad >>> idea and the spec mentions that at the same time it defines a new reque= st >>> parameter for it. >>> >>> >>> >>> It is probably not something I will put any real effort into fighting, >>> if people insist on it. I will continue to recommend only using ACR in= the >>> request. >>> >>> >>> >>> John B. >>> >>> >>> >>> On Jul 23, 2015, at 9:21 AM, Justin Richer wrote: >>> >>> >>> >>> Useful work, but shouldn=E2=80=99t this be defined in the OIDF, where t= he =E2=80=9Camr" >>> parameter is defined? >>> >>> >>> >>> =E2=80=94 Justin >>> >>> >>> >>> On Jul 22, 2015, at 7:48 PM, Mike Jones >>> wrote: >>> >>> >>> >>> Phil Hunt and I have posted a new draft that defines some values used >>> with the =E2=80=9Camr=E2=80=9D (Authentication Methods References) clai= m and >>> establishes a registry for Authentication Method Reference values. The= se >>> values include commonly used authentication methods like =E2=80=9Cpwd= =E2=80=9D >>> (password) and =E2=80=9Cotp=E2=80=9D (one time password). It also defi= nes a parameter >>> for requesting that specific authentication methods be used in the >>> authentication. >>> >>> >>> >>> The specification is available at: >>> >>> =C2=B7 https://tools.ietf.org/html/draft-jones-oauth-amr-values-= 00 >>> >>> >>> >>> An HTML formatted version is also available at: >>> >>> =C2=B7 >>> http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html >>> >>> >>> >>> -- Mike >>> >>> >>> >>> P.S. This note was also posted at http://self-issued.info/?p=3D1429 an= d >>> as @selfissued . >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@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 --001a11c2993adba999051b8d49bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So, allow me a naive question.=C2=A0
I supppose there = are good random otp, as well as pretty bad otp etc.=C2=A0
Would i= t be useful to say just "otp". Would it not be better to have at = least a field that references a spec that specifies the security requiremen= t for that mechanism?=C2=A0

2015-07-23 12:05 GMT+02:00 William Denniss <wdenn= iss@google.com>:
Thanks for drafting this Mike. I'm in favor of having this reg= istry.

In addition to the specific values, I propose we = add some generic ones too (trying to follow your naming scheme):
=
"rba": =C2=A0"risk-based auth"
"upt": =C2=A0"user presence test"

=
My fear of making things too specific is that RPs may get lost in the = weeds trying to work out what things they should care about and how. As an = IdP we like to guide RPs through these kinds of decisions, and prefer to pa= ss a more high level indication of what happened (such as these two values)= .=C2=A0 If someone wanted to have best of both worlds, then both could be a= sserted, e.g. "upt fpt" to indicate that the user presence was te= sted, using a fingerprint test.

Regarding the prop= osed "wia" value. I don't know what it is, and the spec doesn= 't help me find out, can a reference be added?=C2=A0 I also wonder if i= t could be genericized to avoid being vendor specific values =E2=80=93 but = mostly I just want to understand what it is.=C2=A0 Almost all the other val= ues are self-explanatory, perhaps "pop" could use a reference as = well (or maybe just a longer explanation).

I don&#= 39;t see the immediate value of "amr_values", can you elaborate w= ith some places where this would be applied?=C2=A0 Separately, I wonder if = an extension to OIDC should be included in this doc, which is otherwise a f= airly clean registry spec that could be used more broadly.

On Th= u, Jul 23, 2015 at 10:49 AM, Brian Campbell <bcampbell@pingiden= tity.com> wrote:
So maybe a naive question but why does this draft define "amr= _values" while also suggesting that it's fragile and that "ac= r" & "acr_values" is preferable? Seems contradictory. An= d I doubt I'm the only one that will find it confusing.=C2=A0

On Thu= , Jul 23, 2015 at 9:35 AM, Mike Jones <Michael.Jones@microsoft.c= om> wrote:

The key part of this is e= stablishing a registry.=C2=A0 That can only be done in an RFC.

=C2=A0

John, I encourage you to = submit text beefing up the arguments about why using =E2=80=9Cacr=E2=80=9D = is preferable.=C2=A0 The text at http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html#acrRelati= onship is a start at that.

=C2=A0

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

=C2=A0

From: John Bra= dley [mailto:ve7jtb@= ve7jtb.com]
Sent: Thursday, July 23, 2015 9:30 AM
To: Justin Richer
Cc: Mike Jones; <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Authentication Method Reference Values Speci= fication

=C2=A0

I don=E2=80=99t personally have a problem with peopl= e defining values for AMR and creating a IANA registry.=C2=A0=

=C2=A0

That exists for ACR.

=C2=A0

I am on record as not supporting clients requesting = amr as it ai a bad idea and the spec mentions that at the same time it defi= nes a new request parameter for it.

=C2=A0

It is probably not something I will put any real eff= ort into fighting, if people insist on it.=C2=A0 I will continue to recomme= nd only using ACR in the request.

=C2=A0

John B.

=C2=A0

On Jul 23, 2015, at 9:21 AM, Justin Richer <jricher@mit.edu> wro= te:

=C2=A0

Useful work, but shouldn=E2=80=99t thi= s be defined in the OIDF, where the =E2=80=9Camr" parameter is defined= ?

=C2=A0

=C2=A0=E2=80=94 Justin

=C2=A0

On Jul 22, 2015, at 7:48 PM, Mike Jone= s <Michael.Jones@microsoft.com> wrote:<= u>

=C2=A0

Phil Hunt and I have posted a new draft= that defines some values used with the =E2=80=9Camr= =E2=80=9D (Authentication Methods References) claim and establishes a registry for A= uthentication Method Reference values.=C2=A0 These values include commonly = used authentication methods like =E2=80=9Cpwd=E2=80=9D (password) and =E2=80=9Cotp=E2=80=9D (one time passwo= rd).=C2=A0 It also defines a parameter for requesting that specific authent= ication methods be used in the authentication.

=C2=A0

The specification is available at:

= =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0https://tools.ietf.org/html/draft-jones-oauth-amr-value= s-00

=C2=A0

An HTML formatted version is also avail= able at:

= =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0http://self-issued.info/docs/draft-jones-oauth-am= r-values-00.html

=C2=A0

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

=C2=A0

P.S.=C2=A0 This note was also posted at= =C2=A0http://self-issued.info/?p=3D1429=C2=A0and as=C2=A0@selfissued.<= /span>

______________________________________= _________
OAuth mailing list
OAuth@ietf.org
<= span style=3D"color:purple">https://www.ietf.org/mailman/listinfo/oauth

=C2=A0

______________________________________= _________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oaut= h

=C2=A0


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



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



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




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundatio= n
http://nat.saki= mura.org/
@_nat_en
--001a11c2993adba999051b8d49bd-- From nobody Thu Jul 23 09:29:59 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85ADE1A6F01 for ; Thu, 23 Jul 2015 09:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.159 X-Spam-Level: ** X-Spam-Status: No, score=2.159 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_NO_WWW_INFO_CGI=2.071] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAsClw4wnG5U for ; Thu, 23 Jul 2015 09:29:48 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0762.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::762]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 883CE1A01FC for ; Thu, 23 Jul 2015 09:29:47 -0700 (PDT) Received: from BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) by BY2PR03MB585.namprd03.prod.outlook.com (10.141.143.16) with Microsoft SMTP Server (TLS) id 15.1.219.17; Thu, 23 Jul 2015 16:29:28 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.225.13; Thu, 23 Jul 2015 16:29:27 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0225.018; Thu, 23 Jul 2015 16:29:27 +0000 From: Mike Jones To: Nat Sakimura , William Denniss Thread-Topic: [OAUTH-WG] Authentication Method Reference Values Specification Thread-Index: AdDEponiitwaXF5YTtCgg2mzrUGsugAcbbeAAABKDwAAABfdYAACq1kAAAKorwAADSeqAAAAHwlA Date: Thu, 23 Jul 2015 16:29:26 +0000 Message-ID: References: <8BADFB60-1BE4-415A-B386-F34F9FE72A3C@mit.edu> <61575F9A-8A0F-415A-89AA-480432813020@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:67c:370:160:f0e0:19d9:5250:4aa2] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:0E0U3zCXKAbcT9fo/vtjeWJX5O313acA2m2w/Pd2oV2rVpHCqbGdU8etNT9oigLKZT6IE7vtocJuzCuZJNsILMa6w6FqiLNLkGi88rxCrK0ZPGZw2qP1qe/6GSWP82Y6uNYN3xv/yP/pZcc2o7RO9A==; 24:7er0feZqcL0nemT1+N03sOd6Cgos6MqSQr1+lJcgRhg/ski0E6IQ0h5pwrKtBaWZQSffPxpc6v+QaLo6Ef7Dit21xZ7DajZY2fv6jvk6nCc=; 20:4gwQu5IRknN4UU+tI/1AT6dm4d4K7p4Vlt8w+GK37vhmi06EjystJ+T768uQUbTSNHCYOM2QIZ5uY9LScTLofg== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB585; by2pr03mb443: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 06469BCC91 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(377424004)(24454002)(377454003)(52604005)(74316001)(54356999)(5003600100002)(189998001)(19625215002)(33656002)(19300405004)(40100003)(46102003)(10090500001)(2900100001)(2950100001)(99286002)(92566002)(5001960100002)(19580405001)(5002640100001)(86612001)(102836002)(77096005)(76176999)(76576001)(86362001)(19609705001)(50986999)(551544002)(19580395003)(87936001)(62966003)(15975445007)(5001770100001)(93886004)(2656002)(77156002)(19617315012)(16236675004)(3826002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442AE5E9A13B300F37898D3F5820BY2PR03MB442namprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2015 16:29:26.9157 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 X-Microsoft-Exchange-Diagnostics: 1; BY2PR03MB585; 2:/7I/T7cj3nNvYqOfquM1nX/vZTeKD75quq9R2m5zLOfButpRkOj2QvK7RYZgF1QS; 3:98h1Mmj1DbCTSaOQLkPyz9AixwjLhVCyBFGrGmHJwD8/4WdQxkWlb0oUwDjgFegmjTQn22UhbvEqlQ3K/kkGHXG9Xfq+KqE6scBGrFa1syMRynWpTk4XCwarUY392RwIWrvanV+fUMYp+mtCCmu7yQ==; 25:B4CTDjfRhQkq9mnXa2FW09/a9yNn0zclwl0qela1mr/28Zp4+g4qp0TkQFa/9IGI90+YrZjJrIm2SkLRf9et+yoOH0lpXUenhhhWxVyXGWId3NvHswdLEUWynUYdSgyZ9Tb0pzSIg5jz6ptrWjIMN9Z+6E+HQTXwKo/ZH9N3faGusHa37NxGQEO+WyFIgRfTuIJVJiF9YpyHC3WvZM8e77LYQHMdIwMZZTRt9ijuWaB7zpSTYCylIQBX84ZO6CWJ6JLAIuZj1TJpPKbXchcaTQ== X-Microsoft-Exchange-Diagnostics: 1; BY2PR03MB585; 20:PpcCwFCCjTmjqz8BfN/Ur+TVyfWfuwheMK02zoV0e3fk7h591fK1YvMq0Qv7fgyXbojTVh7VeT4oYUYA3ftWUBQ5wDITYGb4sOcVkJLqdahP6y3U0UV71fyjHYx0hI9dJdpZhLZOiahV8MG2sfK2Mn3fhh2zsjwXcFGJZfu7ZfxVGE0EtDii/i6N+ht3KGLJRiAnuFm366+r1utArEVOK0iyIFknzornvyXbGqmmdb41X3X8Ri1pheLJS3qhpySMwFveyjFd9QLvh0QWshWILohlDXG4TeSyw3lAZ3+wapopRkZ2OzPqtzfKziighdAo5LAkAqXOm4MFRtRZZSFCnIL1wVlHGfTCoXN7vQ+3aIjpJMOcsAu/svVZxLglg+DzUTcasRSkSuhytZB+wTlab4VGL4+a1X6OJqvxcRDnjAlQynCFCw6Wv8j8bj/GXOEoweWmVd3QoV+D4oA6jG1Rq3DHXnb2ETjt6Bzep/gCasD/tOB+nAu8miwkhtkZZDXa; 23:ChObpqnLnrcrGfpWmjNnWrl2+Sj49ZUOrU3k43/P050Zb/FN+nmz17uk4n8uvqijAhgCMs1vqIhfjt2kJbzhf5gH76HJc1kfJSgQUY8ZiahPZyQLfS8kxv8uG5nHDBbI2LqmO1fxfE0RZ7avPya/XVu3+m8oY4d/7X/XWq965d5gBWoNyRpfEAwo3wSlaOzEsgMWaESsZjtyKzGwb8BjYTTXzxn4Z8iycqVJKwj21BbwaWB5J7ya9Lq4qijSHIRt BY2PR03MB585: X-MS-Exchange-Organization-RulesExecuted X-OriginatorOrg: microsoft.com Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Authentication Method Reference Values Specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 16:29:51 -0000 --_000_BY2PR03MB442AE5E9A13B300F37898D3F5820BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB0aGF0IGFuIG9idmlvdXMgZ29vZCB0aGluZyB0byBkbyBpcyB0byBhZGQgc3BlYyBy ZWZlcmVuY2VzIHRvIHRoZSBmaWVsZCBkZWZpbml0aW9ucy4NCg0KSSBuZWVkIHRvIGludmVzdGln YXRlIHVzZSBjYXNlcyBmb3IgYW1yX3ZhbHVlcy4gIEkgdGhpbmsgdGhpcyBjYW1lIGZyb20gZGV2 ZWxvcGVycyB3aG8gYWN0dWFsbHkgd2FudGVkIHRoaXMgZm9yIGEgcGFydGljdWxhciBwdXJwb3Nl IGJ1dCBJ4oCZbGwgaGF2ZSB0byBnZXQgYmFjayB0byB0aGUgV0cgb24gdGhhdC4gIEl04oCZcyBk ZWZpbmVkIGhlcmUsIHJhdGhlciB0aGFuIGluIGFub3RoZXIgc3BlYywgYmVjYXVzZSBpdOKAmXMg aGlnaGx5IHJlbGF0ZWQgdG8gdGhlIOKAnGFtcuKAnSB2YWx1ZXMuDQoNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0K RnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg TmF0IFNha2ltdXJhDQpTZW50OiBUaHVyc2RheSwgSnVseSAyMywgMjAxNSA2OjIyIFBNDQpUbzog V2lsbGlhbSBEZW5uaXNzDQpDYzogPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVU SC1XR10gQXV0aGVudGljYXRpb24gTWV0aG9kIFJlZmVyZW5jZSBWYWx1ZXMgU3BlY2lmaWNhdGlv bg0KDQpTbywgYWxsb3cgbWUgYSBuYWl2ZSBxdWVzdGlvbi4NCkkgc3VwcHBvc2UgdGhlcmUgYXJl IGdvb2QgcmFuZG9tIG90cCwgYXMgd2VsbCBhcyBwcmV0dHkgYmFkIG90cCBldGMuDQpXb3VsZCBp dCBiZSB1c2VmdWwgdG8gc2F5IGp1c3QgIm90cCIuIFdvdWxkIGl0IG5vdCBiZSBiZXR0ZXIgdG8g aGF2ZSBhdCBsZWFzdCBhIGZpZWxkIHRoYXQgcmVmZXJlbmNlcyBhIHNwZWMgdGhhdCBzcGVjaWZp ZXMgdGhlIHNlY3VyaXR5IHJlcXVpcmVtZW50IGZvciB0aGF0IG1lY2hhbmlzbT8NCg0KMjAxNS0w Ny0yMyAxMjowNSBHTVQrMDI6MDAgV2lsbGlhbSBEZW5uaXNzIDx3ZGVubmlzc0Bnb29nbGUuY29t PG1haWx0bzp3ZGVubmlzc0Bnb29nbGUuY29tPj46DQpUaGFua3MgZm9yIGRyYWZ0aW5nIHRoaXMg TWlrZS4gSSdtIGluIGZhdm9yIG9mIGhhdmluZyB0aGlzIHJlZ2lzdHJ5Lg0KDQpJbiBhZGRpdGlv biB0byB0aGUgc3BlY2lmaWMgdmFsdWVzLCBJIHByb3Bvc2Ugd2UgYWRkIHNvbWUgZ2VuZXJpYyBv bmVzIHRvbyAodHJ5aW5nIHRvIGZvbGxvdyB5b3VyIG5hbWluZyBzY2hlbWUpOg0KDQoicmJhIjog ICJyaXNrLWJhc2VkIGF1dGgiDQoidXB0IjogICJ1c2VyIHByZXNlbmNlIHRlc3QiDQoNCk15IGZl YXIgb2YgbWFraW5nIHRoaW5ncyB0b28gc3BlY2lmaWMgaXMgdGhhdCBSUHMgbWF5IGdldCBsb3N0 IGluIHRoZSB3ZWVkcyB0cnlpbmcgdG8gd29yayBvdXQgd2hhdCB0aGluZ3MgdGhleSBzaG91bGQg Y2FyZSBhYm91dCBhbmQgaG93LiBBcyBhbiBJZFAgd2UgbGlrZSB0byBndWlkZSBSUHMgdGhyb3Vn aCB0aGVzZSBraW5kcyBvZiBkZWNpc2lvbnMsIGFuZCBwcmVmZXIgdG8gcGFzcyBhIG1vcmUgaGln aCBsZXZlbCBpbmRpY2F0aW9uIG9mIHdoYXQgaGFwcGVuZWQgKHN1Y2ggYXMgdGhlc2UgdHdvIHZh bHVlcykuICBJZiBzb21lb25lIHdhbnRlZCB0byBoYXZlIGJlc3Qgb2YgYm90aCB3b3JsZHMsIHRo ZW4gYm90aCBjb3VsZCBiZSBhc3NlcnRlZCwgZS5nLiAidXB0IGZwdCIgdG8gaW5kaWNhdGUgdGhh dCB0aGUgdXNlciBwcmVzZW5jZSB3YXMgdGVzdGVkLCB1c2luZyBhIGZpbmdlcnByaW50IHRlc3Qu DQoNClJlZ2FyZGluZyB0aGUgcHJvcG9zZWQgIndpYSIgdmFsdWUuIEkgZG9uJ3Qga25vdyB3aGF0 IGl0IGlzLCBhbmQgdGhlIHNwZWMgZG9lc24ndCBoZWxwIG1lIGZpbmQgb3V0LCBjYW4gYSByZWZl cmVuY2UgYmUgYWRkZWQ/ICBJIGFsc28gd29uZGVyIGlmIGl0IGNvdWxkIGJlIGdlbmVyaWNpemVk IHRvIGF2b2lkIGJlaW5nIHZlbmRvciBzcGVjaWZpYyB2YWx1ZXMg4oCTIGJ1dCBtb3N0bHkgSSBq dXN0IHdhbnQgdG8gdW5kZXJzdGFuZCB3aGF0IGl0IGlzLiAgQWxtb3N0IGFsbCB0aGUgb3RoZXIg dmFsdWVzIGFyZSBzZWxmLWV4cGxhbmF0b3J5LCBwZXJoYXBzICJwb3AiIGNvdWxkIHVzZSBhIHJl ZmVyZW5jZSBhcyB3ZWxsIChvciBtYXliZSBqdXN0IGEgbG9uZ2VyIGV4cGxhbmF0aW9uKS4NCg0K SSBkb24ndCBzZWUgdGhlIGltbWVkaWF0ZSB2YWx1ZSBvZiAiYW1yX3ZhbHVlcyIsIGNhbiB5b3Ug ZWxhYm9yYXRlIHdpdGggc29tZSBwbGFjZXMgd2hlcmUgdGhpcyB3b3VsZCBiZSBhcHBsaWVkPyAg U2VwYXJhdGVseSwgSSB3b25kZXIgaWYgYW4gZXh0ZW5zaW9uIHRvIE9JREMgc2hvdWxkIGJlIGlu Y2x1ZGVkIGluIHRoaXMgZG9jLCB3aGljaCBpcyBvdGhlcndpc2UgYSBmYWlybHkgY2xlYW4gcmVn aXN0cnkgc3BlYyB0aGF0IGNvdWxkIGJlIHVzZWQgbW9yZSBicm9hZGx5Lg0KDQpPbiBUaHUsIEp1 bCAyMywgMjAxNSBhdCAxMDo0OSBBTSwgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRl bnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+IHdyb3RlOg0KU28g bWF5YmUgYSBuYWl2ZSBxdWVzdGlvbiBidXQgd2h5IGRvZXMgdGhpcyBkcmFmdCBkZWZpbmUgImFt cl92YWx1ZXMiIHdoaWxlIGFsc28gc3VnZ2VzdGluZyB0aGF0IGl0J3MgZnJhZ2lsZSBhbmQgdGhh dCAiYWNyIiAmICJhY3JfdmFsdWVzIiBpcyBwcmVmZXJhYmxlPyBTZWVtcyBjb250cmFkaWN0b3J5 LiBBbmQgSSBkb3VidCBJJ20gdGhlIG9ubHkgb25lIHRoYXQgd2lsbCBmaW5kIGl0IGNvbmZ1c2lu Zy4NCg0KT24gVGh1LCBKdWwgMjMsIDIwMTUgYXQgOTozNSBBTSwgTWlrZSBKb25lcyA8TWljaGFl bC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+ PiB3cm90ZToNClRoZSBrZXkgcGFydCBvZiB0aGlzIGlzIGVzdGFibGlzaGluZyBhIHJlZ2lzdHJ5 LiAgVGhhdCBjYW4gb25seSBiZSBkb25lIGluIGFuIFJGQy4NCg0KSm9obiwgSSBlbmNvdXJhZ2Ug eW91IHRvIHN1Ym1pdCB0ZXh0IGJlZWZpbmcgdXAgdGhlIGFyZ3VtZW50cyBhYm91dCB3aHkgdXNp bmcg4oCcYWNy4oCdIGlzIHByZWZlcmFibGUuICBUaGUgdGV4dCBhdCBodHRwOi8vc2VsZi1pc3N1 ZWQuaW5mby9kb2NzL2RyYWZ0LWpvbmVzLW9hdXRoLWFtci12YWx1ZXMtMDAuaHRtbCNhY3JSZWxh dGlvbnNoaXA8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91 cmw9aHR0cCUzYSUyZiUyZnNlbGYtaXNzdWVkLmluZm8lMmZkb2NzJTJmZHJhZnQtam9uZXMtb2F1 dGgtYW1yLXZhbHVlcy0wMC5odG1sJTIzYWNyUmVsYXRpb25zaGlwJmRhdGE9MDElN2MwMSU3Y01p Y2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdjNDVmNzNlZWM1OWMyNDYzNjY0ZGUwOGQyOTM3 YWRmNTIlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9NiUyYmxQ U3lHMHhmQk1nMGp4S2FRdDFsQWNXNkdWMyUyZmplNGRta0UlMmJiN1E4byUzZD4gaXMgYSBzdGFy dCBhdCB0aGF0Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IEpvaG4gQnJhZGxleSBbbWFpbHRvOnZl N2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT5dDQpTZW50OiBUaHVyc2Rh eSwgSnVseSAyMywgMjAxNSA5OjMwIEFNDQpUbzogSnVzdGluIFJpY2hlcg0KQ2M6IE1pa2UgSm9u ZXM7IDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6 IFtPQVVUSC1XR10gQXV0aGVudGljYXRpb24gTWV0aG9kIFJlZmVyZW5jZSBWYWx1ZXMgU3BlY2lm aWNhdGlvbg0KDQpJIGRvbuKAmXQgcGVyc29uYWxseSBoYXZlIGEgcHJvYmxlbSB3aXRoIHBlb3Bs ZSBkZWZpbmluZyB2YWx1ZXMgZm9yIEFNUiBhbmQgY3JlYXRpbmcgYSBJQU5BIHJlZ2lzdHJ5Lg0K DQpUaGF0IGV4aXN0cyBmb3IgQUNSLg0KDQpJIGFtIG9uIHJlY29yZCBhcyBub3Qgc3VwcG9ydGlu ZyBjbGllbnRzIHJlcXVlc3RpbmcgYW1yIGFzIGl0IGFpIGEgYmFkIGlkZWEgYW5kIHRoZSBzcGVj IG1lbnRpb25zIHRoYXQgYXQgdGhlIHNhbWUgdGltZSBpdCBkZWZpbmVzIGEgbmV3IHJlcXVlc3Qg cGFyYW1ldGVyIGZvciBpdC4NCg0KSXQgaXMgcHJvYmFibHkgbm90IHNvbWV0aGluZyBJIHdpbGwg cHV0IGFueSByZWFsIGVmZm9ydCBpbnRvIGZpZ2h0aW5nLCBpZiBwZW9wbGUgaW5zaXN0IG9uIGl0 LiAgSSB3aWxsIGNvbnRpbnVlIHRvIHJlY29tbWVuZCBvbmx5IHVzaW5nIEFDUiBpbiB0aGUgcmVx dWVzdC4NCg0KSm9obiBCLg0KDQpPbiBKdWwgMjMsIDIwMTUsIGF0IDk6MjEgQU0sIEp1c3RpbiBS aWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4gd3JvdGU6DQoN ClVzZWZ1bCB3b3JrLCBidXQgc2hvdWxkbuKAmXQgdGhpcyBiZSBkZWZpbmVkIGluIHRoZSBPSURG LCB3aGVyZSB0aGUg4oCcYW1yIiBwYXJhbWV0ZXIgaXMgZGVmaW5lZD8NCg0KIOKAlCBKdXN0aW4N Cg0KT24gSnVsIDIyLCAyMDE1LCBhdCA3OjQ4IFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3Rl Og0KDQpQaGlsIEh1bnQgYW5kIEkgaGF2ZSBwb3N0ZWQgYSBuZXcgZHJhZnQgdGhhdCBkZWZpbmVz IHNvbWUgdmFsdWVzIHVzZWQgd2l0aCB0aGUg4oCcYW1y4oCdIChBdXRoZW50aWNhdGlvbiBNZXRo b2RzIFJlZmVyZW5jZXMpIGNsYWltIGFuZCBlc3RhYmxpc2hlcyBhIHJlZ2lzdHJ5IGZvciBBdXRo ZW50aWNhdGlvbiBNZXRob2QgUmVmZXJlbmNlIHZhbHVlcy4gIFRoZXNlIHZhbHVlcyBpbmNsdWRl IGNvbW1vbmx5IHVzZWQgYXV0aGVudGljYXRpb24gbWV0aG9kcyBsaWtlIOKAnHB3ZOKAnSAocGFz c3dvcmQpIGFuZCDigJxvdHDigJ0gKG9uZSB0aW1lIHBhc3N3b3JkKS4gIEl0IGFsc28gZGVmaW5l cyBhIHBhcmFtZXRlciBmb3IgcmVxdWVzdGluZyB0aGF0IHNwZWNpZmljIGF1dGhlbnRpY2F0aW9u IG1ldGhvZHMgYmUgdXNlZCBpbiB0aGUgYXV0aGVudGljYXRpb24uDQoNClRoZSBzcGVjaWZpY2F0 aW9uIGlzIGF2YWlsYWJsZSBhdDoNCuKAoiAgICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWpvbmVzLW9hdXRoLWFtci12YWx1ZXMtMDA8aHR0cHM6Ly9uYTAxLnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ0b29scy5pZXRmLm9y ZyUyZmh0bWwlMmZkcmFmdC1qb25lcy1vYXV0aC1hbXItdmFsdWVzLTAwJmRhdGE9MDElN2MwMSU3 Y01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdjNDVmNzNlZWM1OWMyNDYzNjY0ZGUwOGQy OTM3YWRmNTIlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9bUo0 N0slMmJDZXBLeHg4WnlzdCUyYkF2ZVpJWmI2RXlUUll2Nkx2MndwNno5dlklM2Q+DQoNCkFuIEhU TUwgZm9ybWF0dGVkIHZlcnNpb24gaXMgYWxzbyBhdmFpbGFibGUgYXQ6DQrigKIgICAgICAgIGh0 dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQtam9uZXMtb2F1dGgtYW1yLXZhbHVlcy0w MC5odG1sPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJs PWh0dHAlM2ElMmYlMmZzZWxmLWlzc3VlZC5pbmZvJTJmZG9jcyUyZmRyYWZ0LWpvbmVzLW9hdXRo LWFtci12YWx1ZXMtMDAuaHRtbCZkYXRhPTAxJTdjMDElN2NNaWNoYWVsLkpvbmVzJTQwbWljcm9z b2Z0LmNvbSU3YzQ1ZjczZWVjNTljMjQ2MzY2NGRlMDhkMjkzN2FkZjUyJTdjNzJmOTg4YmY4NmYx NDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPVQ5VkxxTyUyYkpqcGZCaUY3NnFCRXFrS08x YnREclByYTU5c3ElMmJoTlVwTjVJJTNkPg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNClAuUy4gIFRoaXMgbm90 ZSB3YXMgYWxzbyBwb3N0ZWQgYXQgaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vP3A9MTQyOTxodHRw czovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJm JTJmc2VsZi1pc3N1ZWQuaW5mbyUyZiUzZnAlM2QxNDI5JmRhdGE9MDElN2MwMSU3Y01pY2hhZWwu Sm9uZXMlNDBtaWNyb3NvZnQuY29tJTdjNDVmNzNlZWM1OWMyNDYzNjY0ZGUwOGQyOTM3YWRmNTIl N2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9enYyeklybE4wVUdB RktlOXJBRFZwaFVHbkpLT2dId2lSWVhrMHRvYTVRUSUzZD4gYW5kIGFzIEBzZWxmaXNzdWVkPGh0 dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNh JTJmJTJmdHdpdHRlci5jb20lMmZzZWxmaXNzdWVkJmRhdGE9MDElN2MwMSU3Y01pY2hhZWwuSm9u ZXMlNDBtaWNyb3NvZnQuY29tJTdjNDVmNzNlZWM1OWMyNDYzNjY0ZGUwOGQyOTM3YWRmNTIlN2M3 MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9R1pCNiUyZjBGWVpQU1gw UlV4UWtqTVVBYzV1R2FUSlZ1WmJrWVVjdVNGQmtBJTNkPi4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGll dGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGg8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv b2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGlu Zm8lMmZvYXV0aCZkYXRhPTAxJTdjMDElN2NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3 YzQ1ZjczZWVjNTljMjQ2MzY2NGRlMDhkMjkzN2FkZjUyJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIy ZDdjZDAxMWRiNDclN2MxJnNkYXRhPTRhTmhUeEdEJTJmOXc4cUQ5V1BYcGkyJTJiUWZpcHJKRGJz RjJQSzVFQnhhdTM0JTNkPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1 dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo PGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz JTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmZGF0YT0w MSU3YzAxJTdjTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN2M0NWY3M2VlYzU5YzI0NjM2 NjRkZTA4ZDI5MzdhZGY1MiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZz ZGF0YT00YU5oVHhHRCUyZjl3OHFEOVdQWHBpMiUyYlFmaXBySkRic0YyUEs1RUJ4YXUzNCUzZD4N Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1 dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0dHBzOi8vbmEwMS5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3Lmll dGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmZGF0YT0wMSU3YzAxJTdjTWljaGFl bC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN2M0NWY3M2VlYzU5YzI0NjM2NjRkZTA4ZDI5MzdhZGY1 MiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT00YU5oVHhHRCUy Zjl3OHFEOVdQWHBpMiUyYlFmaXBySkRic0YyUEs1RUJ4YXUzNCUzZD4NCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0 DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVj dGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1h biUyZmxpc3RpbmZvJTJmb2F1dGgmZGF0YT0wMSU3YzAxJTdjTWljaGFlbC5Kb25lcyU0MG1pY3Jv c29mdC5jb20lN2M0NWY3M2VlYzU5YzI0NjM2NjRkZTA4ZDI5MzdhZGY1MiU3YzcyZjk4OGJmODZm MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT00YU5oVHhHRCUyZjl3OHFEOVdQWHBpMiUy YlFmaXBySkRic0YyUEs1RUJ4YXUzNCUzZD4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9y ZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJm b2F1dGgmZGF0YT0wMSU3YzAxJTdjTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN2M0NWY3 M2VlYzU5YzI0NjM2NjRkZTA4ZDI5MzdhZGY1MiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2Qw MTFkYjQ3JTdjMSZzZGF0YT00YU5oVHhHRCUyZjl3OHFEOVdQWHBpMiUyYlFmaXBySkRic0YyUEs1 RUJ4YXUzNCUzZD4NCg0KDQoNCi0tDQpOYXQgU2FraW11cmEgKD1uYXQpDQpDaGFpcm1hbiwgT3Bl bklEIEZvdW5kYXRpb24NCmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzxodHRwczovL25hMDEuc2Fm ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJmJTJmbmF0LnNha2lt dXJhLm9yZyUyZiZkYXRhPTAxJTdjMDElN2NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3 YzQ1ZjczZWVjNTljMjQ2MzY2NGRlMDhkMjkzN2FkZjUyJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIy ZDdjZDAxMWRiNDclN2MxJnNkYXRhPU9JRWZIRUZkd1lKTWZFV2taZUFZeHJFZGVkY1VydFZ1WmFZ dzg2akNCa3MlM2Q+DQpAX25hdF9lbg0K --_000_BY2PR03MB442AE5E9A13B300F37898D3F5820BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0K CXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFncmVlIHRoYXQgYW4gb2J2aW91 cyBnb29kIHRoaW5nIHRvIGRvIGlzIHRvIGFkZCBzcGVjIHJlZmVyZW5jZXMgdG8gdGhlIGZpZWxk IGRlZmluaXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBuZWVkIHRvIGludmVzdGlnYXRlIHVzZSBjYXNlcyBm b3IgYW1yX3ZhbHVlcy4mbmJzcDsgSSB0aGluayB0aGlzIGNhbWUgZnJvbSBkZXZlbG9wZXJzIHdo byBhY3R1YWxseSB3YW50ZWQgdGhpcyBmb3IgYSBwYXJ0aWN1bGFyIHB1cnBvc2UgYnV0IEnigJls bCBoYXZlIHRvIGdldCBiYWNrDQogdG8gdGhlIFdHIG9uIHRoYXQuJm5ic3A7IEl04oCZcyBkZWZp bmVkIGhlcmUsIHJhdGhlciB0aGFuIGluIGFub3RoZXIgc3BlYywgYmVjYXVzZSBpdOKAmXMgaGln aGx5IHJlbGF0ZWQgdG8gdGhlIOKAnGFtcuKAnSB2YWx1ZXMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gT0F1 dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5O YXQgU2FraW11cmE8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bHkgMjMsIDIwMTUgNjoy MiBQTTxicj4NCjxiPlRvOjwvYj4gV2lsbGlhbSBEZW5uaXNzPGJyPg0KPGI+Q2M6PC9iPiAmbHQ7 b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIEF1 dGhlbnRpY2F0aW9uIE1ldGhvZCBSZWZlcmVuY2UgVmFsdWVzIFNwZWNpZmljYXRpb248bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbywgYWxsb3cgbWUgYSBuYWl2ZSBxdWVz dGlvbi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IHN1cHBwb3NlIHRoZXJlIGFyZSBnb29kIHJhbmRvbSBvdHAsIGFzIHdlbGwgYXMgcHJldHR5IGJh ZCBvdHAgZXRjLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+V291bGQgaXQgYmUgdXNlZnVsIHRvIHNheSBqdXN0ICZxdW90O290cCZxdW90 Oy4gV291bGQgaXQgbm90IGJlIGJldHRlciB0byBoYXZlIGF0IGxlYXN0IGEgZmllbGQgdGhhdCBy ZWZlcmVuY2VzIGEgc3BlYyB0aGF0IHNwZWNpZmllcyB0aGUgc2VjdXJpdHkgcmVxdWlyZW1lbnQg Zm9yIHRoYXQgbWVjaGFuaXNtPyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDE1LTA3LTIzIDEyOjA1IEdNVCYjNDM7MDI6MDAgV2ls bGlhbSBEZW5uaXNzICZsdDs8YSBocmVmPSJtYWlsdG86d2Rlbm5pc3NAZ29vZ2xlLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPndkZW5uaXNzQGdvb2dsZS5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9yIGRyYWZ0aW5nIHRoaXMgTWlr ZS4gSSdtIGluIGZhdm9yIG9mIGhhdmluZyB0aGlzIHJlZ2lzdHJ5LjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gYWRkaXRpb24gdG8gdGhlIHNwZWNpZmlj IHZhbHVlcywgSSBwcm9wb3NlIHdlIGFkZCBzb21lIGdlbmVyaWMgb25lcyB0b28gKHRyeWluZyB0 byBmb2xsb3cgeW91ciBuYW1pbmcgc2NoZW1lKTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7cmJhJnF1b3Q7OiAmbmJzcDsmcXVvdDty aXNrLWJhc2VkIGF1dGgmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZxdW90O3VwdCZxdW90OzogJm5ic3A7JnF1b3Q7dXNlciBwcmVzZW5j ZSB0ZXN0JnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk15IGZlYXIgb2YgbWFraW5nIHRoaW5ncyB0b28gc3BlY2lmaWMgaXMgdGhhdCBS UHMgbWF5IGdldCBsb3N0IGluIHRoZSB3ZWVkcyB0cnlpbmcgdG8gd29yayBvdXQgd2hhdCB0aGlu Z3MgdGhleSBzaG91bGQgY2FyZSBhYm91dCBhbmQgaG93LiBBcyBhbiBJZFAgd2UgbGlrZSB0byBn dWlkZSBSUHMgdGhyb3VnaCB0aGVzZSBraW5kcyBvZiBkZWNpc2lvbnMsIGFuZCBwcmVmZXIgdG8g cGFzcyBhIG1vcmUgaGlnaCBsZXZlbA0KIGluZGljYXRpb24gb2Ygd2hhdCBoYXBwZW5lZCAoc3Vj aCBhcyB0aGVzZSB0d28gdmFsdWVzKS4mbmJzcDsgSWYgc29tZW9uZSB3YW50ZWQgdG8gaGF2ZSBi ZXN0IG9mIGJvdGggd29ybGRzLCB0aGVuIGJvdGggY291bGQgYmUgYXNzZXJ0ZWQsIGUuZy4gJnF1 b3Q7dXB0IGZwdCZxdW90OyB0byBpbmRpY2F0ZSB0aGF0IHRoZSB1c2VyIHByZXNlbmNlIHdhcyB0 ZXN0ZWQsIHVzaW5nIGEgZmluZ2VycHJpbnQgdGVzdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkaW5nIHRoZSBwcm9wb3NlZCAmcXVv dDt3aWEmcXVvdDsgdmFsdWUuIEkgZG9uJ3Qga25vdyB3aGF0IGl0IGlzLCBhbmQgdGhlIHNwZWMg ZG9lc24ndCBoZWxwIG1lIGZpbmQgb3V0LCBjYW4gYSByZWZlcmVuY2UgYmUgYWRkZWQ/Jm5ic3A7 IEkgYWxzbyB3b25kZXIgaWYgaXQgY291bGQgYmUgZ2VuZXJpY2l6ZWQgdG8gYXZvaWQgYmVpbmcg dmVuZG9yIHNwZWNpZmljIHZhbHVlcyDigJMgYnV0IG1vc3RseSBJIGp1c3Qgd2FudCB0byB1bmRl cnN0YW5kDQogd2hhdCBpdCBpcy4mbmJzcDsgQWxtb3N0IGFsbCB0aGUgb3RoZXIgdmFsdWVzIGFy ZSBzZWxmLWV4cGxhbmF0b3J5LCBwZXJoYXBzICZxdW90O3BvcCZxdW90OyBjb3VsZCB1c2UgYSBy ZWZlcmVuY2UgYXMgd2VsbCAob3IgbWF5YmUganVzdCBhIGxvbmdlciBleHBsYW5hdGlvbikuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9u J3Qgc2VlIHRoZSBpbW1lZGlhdGUgdmFsdWUgb2YgJnF1b3Q7YW1yX3ZhbHVlcyZxdW90OywgY2Fu IHlvdSBlbGFib3JhdGUgd2l0aCBzb21lIHBsYWNlcyB3aGVyZSB0aGlzIHdvdWxkIGJlIGFwcGxp ZWQ/Jm5ic3A7IFNlcGFyYXRlbHksIEkgd29uZGVyIGlmIGFuIGV4dGVuc2lvbiB0byBPSURDIHNo b3VsZCBiZSBpbmNsdWRlZCBpbiB0aGlzIGRvYywgd2hpY2ggaXMgb3RoZXJ3aXNlIGEgZmFpcmx5 IGNsZWFuIHJlZ2lzdHJ5IHNwZWMNCiB0aGF0IGNvdWxkIGJlIHVzZWQgbW9yZSBicm9hZGx5Ljxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBUaHUsIEp1bCAyMywgMjAxNSBhdCAxMDo0OSBBTSwgQnJpYW4gQ2FtcGJlbGwgJmx0Ozxh IGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gbWF5YmUgYSBuYWl2ZSBxdWVzdGlvbiBi dXQgd2h5IGRvZXMgdGhpcyBkcmFmdCBkZWZpbmUgJnF1b3Q7YW1yX3ZhbHVlcyZxdW90OyB3aGls ZSBhbHNvIHN1Z2dlc3RpbmcgdGhhdCBpdCdzIGZyYWdpbGUgYW5kIHRoYXQgJnF1b3Q7YWNyJnF1 b3Q7ICZhbXA7ICZxdW90O2Fjcl92YWx1ZXMmcXVvdDsgaXMgcHJlZmVyYWJsZT8gU2VlbXMgY29u dHJhZGljdG9yeS4gQW5kIEkgZG91YnQgSSdtIHRoZSBvbmx5IG9uZSB0aGF0IHdpbGwgZmluZCBp dCBjb25mdXNpbmcuJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBKdWwgMjMsIDIwMTUgYXQgOTozNSBBTSwg TWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv bSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUga2V5IHBhcnQg b2YgdGhpcyBpcyBlc3RhYmxpc2hpbmcgYSByZWdpc3RyeS4mbmJzcDsgVGhhdCBjYW4gb25seSBi ZSBkb25lIGluIGFuIFJGQy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Kb2huLCBJIGVuY291cmFnZSB5b3UgdG8g c3VibWl0IHRleHQgYmVlZmluZyB1cCB0aGUgYXJndW1lbnRzIGFib3V0IHdoeSB1c2luZyDigJxh Y3LigJ0gaXMgcHJlZmVyYWJsZS4mbmJzcDsNCiBUaGUgdGV4dCBhdCA8YSBocmVmPSJodHRwczov L25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJmJTJm c2VsZi1pc3N1ZWQuaW5mbyUyZmRvY3MlMmZkcmFmdC1qb25lcy1vYXV0aC1hbXItdmFsdWVzLTAw Lmh0bWwlMjNhY3JSZWxhdGlvbnNoaXAmYW1wO2RhdGE9MDElN2MwMSU3Y01pY2hhZWwuSm9uZXMl NDBtaWNyb3NvZnQuY29tJTdjNDVmNzNlZWM1OWMyNDYzNjY0ZGUwOGQyOTM3YWRmNTIlN2M3MmY5 ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPTYlMmJsUFN5RzB4ZkJN ZzBqeEthUXQxbEFjVzZHVjMlMmZqZTRkbWtFJTJiYjdROG8lM2QiIHRhcmdldD0iX2JsYW5rIj4N Cmh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQtam9uZXMtb2F1dGgtYW1yLXZhbHVl cy0wMC5odG1sI2FjclJlbGF0aW9uc2hpcDwvYT4gaXMgYSBzdGFydCBhdCB0aGF0Ljwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSm9o biBCcmFkbGV5IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIiB0YXJn ZXQ9Il9ibGFuayI+dmU3anRiQHZlN2p0Yi5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRo dXJzZGF5LCBKdWx5IDIzLCAyMDE1IDk6MzAgQU08YnI+DQo8Yj5Ubzo8L2I+IEp1c3RpbiBSaWNo ZXI8YnI+DQo8Yj5DYzo8L2I+IE1pa2UgSm9uZXM7ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIEF1dGhlbnRpY2F0aW9uIE1ldGhvZCBSZWZlcmVu Y2UgVmFsdWVzIFNwZWNpZmljYXRpb248L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGRvbuKAmXQgcGVyc29uYWxseSBoYXZl IGEgcHJvYmxlbSB3aXRoIHBlb3BsZSBkZWZpbmluZyB2YWx1ZXMgZm9yIEFNUiBhbmQgY3JlYXRp bmcgYSBJQU5BIHJlZ2lzdHJ5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPlRoYXQgZXhpc3RzIGZvciBBQ1IuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGFtIG9uIHJlY29yZCBh cyBub3Qgc3VwcG9ydGluZyBjbGllbnRzIHJlcXVlc3RpbmcgYW1yIGFzIGl0IGFpIGEgYmFkIGlk ZWEgYW5kIHRoZSBzcGVjIG1lbnRpb25zIHRoYXQgYXQgdGhlIHNhbWUgdGltZSBpdCBkZWZpbmVz IGEgbmV3IHJlcXVlc3QgcGFyYW1ldGVyIGZvciBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkl0IGlzIHByb2JhYmx5IG5vdCBzb21l dGhpbmcgSSB3aWxsIHB1dCBhbnkgcmVhbCBlZmZvcnQgaW50byBmaWdodGluZywgaWYgcGVvcGxl IGluc2lzdCBvbiBpdC4mbmJzcDsgSSB3aWxsIGNvbnRpbnVlIHRvIHJlY29tbWVuZCBvbmx5IHVz aW5nIEFDUiBpbiB0aGUgcmVxdWVzdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkpvaG4gQi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBKdWwg MjMsIDIwMTUsIGF0IDk6MjEgQU0sIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpq cmljaGVyQG1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdC5lZHU8L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPlVzZWZ1bCB3b3JrLCBidXQgc2hvdWxkbuKAmXQgdGhpcyBi ZSBkZWZpbmVkIGluIHRoZSBPSURGLCB3aGVyZSB0aGUg4oCcYW1yJnF1b3Q7IHBhcmFtZXRlciBp cyBkZWZpbmVkPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A74oCUIEp1c3Rpbjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ T24gSnVsIDIyLCAyMDE1LCBhdCA3OjQ4IFBNLCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWls dG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9zcGFuPjwvYT4m Z3Q7DQogd3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5QaGlsIEh1bnQgYW5kIEkgaGF2ZSBwb3N0ZWQg YSBuZXcgZHJhZnQgdGhhdCBkZWZpbmVzIHNvbWUgdmFsdWVzIHVzZWQgd2l0aCB0aGUg4oCcPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij5hbXI8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igJ0N CiAoQXV0aGVudGljYXRpb24gTWV0aG9kcyBSZWZlcmVuY2VzKSBjbGFpbSBhbmQgZXN0YWJsaXNo ZXMgYSByZWdpc3RyeSBmb3IgQXV0aGVudGljYXRpb24gTWV0aG9kIFJlZmVyZW5jZSB2YWx1ZXMu Jm5ic3A7IFRoZXNlIHZhbHVlcyBpbmNsdWRlIGNvbW1vbmx5IHVzZWQgYXV0aGVudGljYXRpb24g bWV0aG9kcyBsaWtlIOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+cHdkPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+4oCdDQogKHBhc3N3b3JkKSBhbmQg4oCcPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5v dHA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igJ0gKG9uZSB0aW1lIHBhc3N3 b3JkKS4mbmJzcDsgSXQgYWxzbyBkZWZpbmVzIGEgcGFyYW1ldGVyIGZvciByZXF1ZXN0aW5nIHRo YXQgc3BlY2lmaWMgYXV0aGVudGljYXRpb24gbWV0aG9kcw0KIGJlIHVzZWQgaW4gdGhlIGF1dGhl bnRpY2F0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhlIHNwZWNpZmljYXRpb24gaXMgYXZhaWxhYmxl IGF0Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0cHM6Ly9uYTAx LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ0b29s cy5pZXRmLm9yZyUyZmh0bWwlMmZkcmFmdC1qb25lcy1vYXV0aC1hbXItdmFsdWVzLTAwJmFtcDtk YXRhPTAxJTdjMDElN2NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3YzQ1ZjczZWVjNTlj MjQ2MzY2NGRlMDhkMjkzN2FkZjUyJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDcl N2MxJmFtcDtzZGF0YT1tSjQ3SyUyYkNlcEt4eDhaeXN0JTJiQXZlWklaYjZFeVRSWXY2THYyd3A2 ejl2WSUzZCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1vYXV0aC1hbXItdmFsdWVzLTAwPC9z cGFuPjwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFuIEhUTUwgZm9ybWF0dGVkIHZlcnNpb24gaXMgYWxz byBhdmFpbGFibGUgYXQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJo dHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNh JTJmJTJmc2VsZi1pc3N1ZWQuaW5mbyUyZmRvY3MlMmZkcmFmdC1qb25lcy1vYXV0aC1hbXItdmFs dWVzLTAwLmh0bWwmYW1wO2RhdGE9MDElN2MwMSU3Y01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQu Y29tJTdjNDVmNzNlZWM1OWMyNDYzNjY0ZGUwOGQyOTM3YWRmNTIlN2M3MmY5ODhiZjg2ZjE0MWFm OTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPVQ5VkxxTyUyYkpqcGZCaUY3NnFCRXFrS08x YnREclByYTU5c3ElMmJoTlVwTjVJJTNkIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+aHR0cDovL3NlbGYtaXNzdWVkLmluZm8vZG9jcy9kcmFmdC1qb25lcy1vYXV0 aC1hbXItdmFsdWVzLTAwLmh0bWw8L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlAuUy4mbmJzcDsgVGhpcyBub3RlIHdhcyBhbHNv IHBvc3RlZCBhdCZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlv bi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZzZWxmLWlzc3VlZC5pbmZvJTJmJTNmcCUz ZDE0MjkmYW1wO2RhdGE9MDElN2MwMSU3Y01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdj NDVmNzNlZWM1OWMyNDYzNjY0ZGUwOGQyOTM3YWRmNTIlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk N2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPXp2MnpJcmxOMFVHQUZLZTlyQURWcGhVR25KS09nSHdp UllYazB0b2E1UVElM2QiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5odHRwOi8vc2VsZi1pc3N1ZWQuaW5mby8/cD0xNDI5PC9zcGFuPjwvYT4mbmJzcDthbmQNCiBh cyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r LmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmdHdpdHRlci5jb20lMmZzZWxmaXNzdWVkJmFtcDtkYXRh PTAxJTdjMDElN2NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3YzQ1ZjczZWVjNTljMjQ2 MzY2NGRlMDhkMjkzN2FkZjUyJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2Mx JmFtcDtzZGF0YT1HWkI2JTJmMEZZWlBTWDBSVXhRa2pNVUFjNXVHYVRKVnVaYmtZVWN1U0ZCa0El M2QiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5Ac2VsZmlzc3Vl ZDwvc3Bhbj48L2E+Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+T0F1dGhAaWV0Zi5vcmc8L3NwYW4+PC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJm b2F1dGgmYW1wO2RhdGE9MDElN2MwMSU3Y01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdj NDVmNzNlZWM1OWMyNDYzNjY0ZGUwOGQyOTM3YWRmNTIlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk N2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPTRhTmhUeEdEJTJmOXc4cUQ5V1BYcGkyJTJiUWZpcHJK RGJzRjJQSzVFQnhhdTM0JTNkIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvc3Bhbj48 L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFu PjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cHVycGxlIj5PQXV0aEBpZXRmLm9yZzwvc3Bhbj48 L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0 dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNh JTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmYW1wO2RhdGE9 MDElN2MwMSU3Y01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdjNDVmNzNlZWM1OWMyNDYz NjY0ZGUwOGQyOTM3YWRmNTIlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEm YW1wO3NkYXRhPTRhTmhUeEdEJTJmOXc4cUQ5V1BYcGkyJTJiUWZpcHJKRGJzRjJQSzVFQnhhdTM0 JTNkIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpw dXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L3NwYW4+ PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1 dGgmYW1wO2RhdGE9MDElN2MwMSU3Y01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdjNDVm NzNlZWM1OWMyNDYzNjY0ZGUwOGQyOTM3YWRmNTIlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2Nk MDExZGI0NyU3YzEmYW1wO3NkYXRhPTRhTmhUeEdEJTJmOXc4cUQ5V1BYcGkyJTJiUWZpcHJKRGJz RjJQSzVFQnhhdTM0JTNkIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1 dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAx LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cu aWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZhbXA7ZGF0YT0wMSU3YzAxJTdj TWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN2M0NWY3M2VlYzU5YzI0NjM2NjRkZTA4ZDI5 MzdhZGY1MiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9 NGFOaFR4R0QlMmY5dzhxRDlXUFhwaTIlMmJRZmlwckpEYnNGMlBLNUVCeGF1MzQlM2QiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlz dDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8l MmZvYXV0aCZhbXA7ZGF0YT0wMSU3YzAxJTdjTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20l N2M0NWY3M2VlYzU5YzI0NjM2NjRkZTA4ZDI5MzdhZGY1MiU3YzcyZjk4OGJmODZmMTQxYWY5MWFi MmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9NGFOaFR4R0QlMmY5dzhxRDlXUFhwaTIlMmJRZmlw ckpEYnNGMlBLNUVCeGF1MzQlM2QiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+TmF0IFNha2ltdXJhICg9bmF0KTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJs PWh0dHAlM2ElMmYlMmZuYXQuc2FraW11cmEub3JnJTJmJmFtcDtkYXRhPTAxJTdjMDElN2NNaWNo YWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3YzQ1ZjczZWVjNTljMjQ2MzY2NGRlMDhkMjkzN2Fk ZjUyJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1PSUVm SEVGZHdZSk1mRVdrWmVBWXhyRWRlZGNVcnRWdVphWXc4NmpDQmtzJTNkIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPC9hPjxicj4NCkBfbmF0X2VuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BY2PR03MB442AE5E9A13B300F37898D3F5820BY2PR03MB442namprd_-- From nobody Thu Jul 23 15:59:25 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 954211B2A46 for ; Thu, 23 Jul 2015 15:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.222 X-Spam-Level: X-Spam-Status: No, score=0.222 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mI4kRVmqydW6 for ; Thu, 23 Jul 2015 15:59:21 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E4B31B2A4B for ; Thu, 23 Jul 2015 15:59:21 -0700 (PDT) Received: by wicmv11 with SMTP id mv11so42996602wic.0 for ; Thu, 23 Jul 2015 15:59:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=vg0HXKInM2jVT5hK+2/ESuep7MtK73sO3xaP3qM7RC8=; b=hl4XYG3aVpJlCeEwklADNCKC5z160+2uqBip06ID1WmOYdDYa0D5RWCPrl42C9DM+F 0TVjN9/5loy1a9rmY/LBRwf9VKTd3jSkpwgXDN6wj0rEb1Ulr6zB4fvcKCL67j8nEN0k +23CRPNkGpbEO1BhIPkf8fQ6elzGURHk/dj+D/0GpT1T8WTskBISTB926/WAuq6Ybkdr IVzxV4y0WDmn7v2xReDQITkKezReg3DlGpIPEnopjVrz7B6x34F05zLv4AvROjvWvi0C s7Xxw4xIebHUr53QaGYiztas9Lks/SxKJw/YUyUZTjjJO7SUFd2mKTce/pmLeayc7IUa lpbw== X-Gm-Message-State: ALoCoQmElRv9PRMwwR3eFq2l7IvkhFy7B2nDMh8u5zjjtTQlaBSCRF/0iN59ce6QmWSLfOYTavac MIME-Version: 1.0 X-Received: by 10.180.78.136 with SMTP id b8mr962379wix.89.1437692360090; Thu, 23 Jul 2015 15:59:20 -0700 (PDT) Received: by 10.28.8.6 with HTTP; Thu, 23 Jul 2015 15:59:20 -0700 (PDT) X-Originating-IP: [2001:67c:370:136:d880:b5a3:6a2b:91a6] In-Reply-To: References: Date: Fri, 24 Jul 2015 00:59:20 +0200 Message-ID: From: =?UTF-8?Q?Erik_Wahlstr=C3=B6m?= To: oauth@ietf.org Content-Type: multipart/alternative; boundary=f46d0435c0346b7ba6051b92d68b Archived-At: Subject: Re: [OAUTH-WG] OAuth Digest, Vol 81, Issue 86 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 22:59:24 -0000 --f46d0435c0346b7ba6051b92d68b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Thanks for a great document! I volunteered to review draft-wdenniss-oauth-native-apps-00 at the #IETF93 meeting so here we go: In national mobile eID deployments an app is issued by gov or other organisation in a country. The app acts as the users authentication method and it works with an IDP, the IDP can be anywhere if its an PKI token or at the place that issued the credential if it=E2=80=99s something else. When a= n SP start developing an native app for there services and want=E2=80=99s to use= the national eID solution in combination with OAuth we might run into trouble here. The flow is like follows for a service provider called FooBar: FooBar=E2=80=99s app starts browser-view. FooBar=E2=80=99s SAML service pro= vider functionality redirects the user to an national SAML IDP. The IDP prompts user for a username and then starts an mobile eID token on the same phone. Users is asked if they want=E2=80=99s to authenticate to FooBar and enters = PIN. User are then redirected back with an assertion. The FooBar's service provider verifies the assertion and mint=E2=80=99s OAuth2 token(s) and redi= rects the user back to the app with the help of the redirect URL. So the phone first displays an app, then foobar.com i= n browser-view, then idp.com in *browser-view*, then mobile eID token, then idp.com in the *syste= m browser* and back to foobar.com and the app that the user wanted to use. The problem with browser-views is that the mobile eID token will start idp.com when user has authenticated and then the user is not back in the apps browser-view, but in system browser instead. The system browser is sharing the session with the browser-view and redirect the user to the native app. The user experience will be a bit strange then because there the correct page is not loaded and the browser-view should be closed and the app should start parsing out the authorization code instead. So I think draft should mention something about this scenario and that app developers should handle this scenario in the app. The grant did not really come back from the browser-view as expected but from the system browser instead. =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94 With the above in mind. Maybe even some example code would be nice to have in the non normative section "Appendix A. Operating System Specific Implementation Details=E2=80=9D. Especially how to handle call backs. =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94 Another eID related issue is the pricing model for authentications in that market segment. It=E2=80=99s really common by the eID credential issuing organisations to charge a service providers usage of a credential per tick (that is by OSCP call). The system is based on a per tick pricing model and there are regulations for how long the sessions can live. That means that its not possible to authenticate with a token once and then create a refresh token and the user will ever see the authentication flow again. It kinda messes up the usability of mobile apps a lot but end users have come to term with it. They have not however came to term to always require consents every time they use the app. That drives end user crazy. The usability would be much better if the payment model also accepted a refresh token as a tick instead of just an OSCP call, but we are not there yet. Anyway, that=E2=80=99s the backstory. The section "6.4. Always Prompting f= or User Interaction=E2=80=9D is a bit harsh with a SHOULD NOT. I would rather chang= e it to a NOT RECOMMENDED. =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94 Two additional things that strengthen the case for using the browser-view also come to mind when reading the draft. The first is the fact that multiple tabs is started in some browser when going through multiple authentication attempts. That clutters the system so I really like the new browser-views. The second is that there are additionally nice things in browser-view that do not exist in the web-view. The localStorage is also preserved and it can include important information to make authentication methods more secure. =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 "Authorization servers SHOULD consider taking steps to detect and block logins via embedded user-agents that are not their own, where possible."" Sounds good, but that also sounds very hard when it comes to public clients. =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94 And some nits: "OAuth flows between a native app and the system browser (or another external user-agent) are more secure, and take advantage of the shared authentication state." Not really clear what shared authentication state that is in that sentence. "When the authentication server completes the request, it redirects to the client's redirection URI like it would any redirect URI" s/authentication/authorization / Erik On Thu, Jul 23, 2015 at 6:22 PM, wrote: > > > John Bradley and I introduced a new draft at IETF93 yesterday: > https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00 > > > Goal is to provide best practices for native apps using the RFC6749 > authorization > endpoint, expanding on RFC6749 Section 9. Specifically, it recommends > using an external user-agent (such as the system browser) for this task > over an embedded user-agent (such as a web-view), and suggests ways to > achieve this. > > > Comments welcome! --f46d0435c0346b7ba6051b92d68b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

Thanks for a great document! I volunteer= ed to review draft-wdenniss-oauth-native-apps-00 at the #IETF93 meeting so = here we go:

In national mobile eID deployments an ap= p is issued by gov or other organisation in a country. The app acts as the = users authentication method and it works with an IDP, the IDP can be anywhe= re if its an PKI token or at the place that issued the credential if it=E2= =80=99s something else. When an SP start developing an native app for there= services and want=E2=80=99s to use the national eID solution in combinatio= n with OAuth we might run into trouble here.

The flow is like follows for a service p= rovider called FooBar:

FooBar=E2=80=99s app starts browser-view= .=C2=A0FooBar=E2=80=99s SAML service provider functionality redirects the u= ser to an national SAML IDP. The IDP prompts user for a username and then s= tarts an mobile eID token on the same phone. Users is asked if they want=E2= =80=99s to authenticate to FooBar and enters PIN. User are then redirected = back with an assertion. The FooBar's service provider verifies the asse= rtion and mint=E2=80=99s OAuth2 token(s) and redirects the user back to the= app with the help of the redirect URL.

So the phone first displays an app, then= foobar.com= =C2=A0in browser-view, then idp.com=C2=A0in browser-view, then mobile eID tok= en, then idp.com=C2=A0in the system browser=C2=A0and back to foobar.com=C2=A0and the app t= hat the user wanted to use.

The problem with browser-views is that t= he mobile eID token will start idp.com=C2=A0when user has authenticated and then the user is= not back in the apps browser-view, but in system browser instead. The syst= em browser is sharing the session with the browser-view and redirect the us= er to the native app. The user experience will be a bit strange then becaus= e there the correct page is not loaded and the browser-view should be close= d and the app should start parsing out the authorization code instead.

So I think draft should mention somethin= g about this scenario and that app developers should handle this scenario i= n the app. The grant did not really come back from the browser-view as expe= cted but from the system browser instead.=C2=A0

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94

With the above in mind. Maybe even some example code would = be nice to have in the non normative section "Appendix A.=C2=A0 Operat= ing System Specific Implementation Details=E2=80=9D. Especially how to hand= le call backs.

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94

Another eID related issue is the pricing= model for authentications in that market segment. It=E2=80=99s really comm= on by the eID credential issuing organisations to charge a service provider= s usage of a credential per tick (that is by OSCP call). The system is base= d on a per tick pricing model and there are regulations for how long the se= ssions can live. That means that its not possible to authenticate with a to= ken once and then create a refresh token and the user will ever see the aut= hentication flow again. It kinda messes up the usability of mobile apps a l= ot but end users have come to term with it. They have not however came to t= erm to always require consents every time they use the app. That drives end= user crazy. The usability would be much better if the payment model also a= ccepted a refresh token as a tick instead of just an OSCP call, but we are = not there yet.

Anyway, that=E2=80=99s the backstory. Th= e section "6.4.=C2=A0 Always Prompting for User Interaction=E2=80=9D i= s a bit harsh with a=C2=A0SHOULD NOT. I would rather change it to a NOT REC= OMMENDED.

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94

Two additional things that strengthen th= e case for using the browser-view also come to mind when reading the draft.= The first is the fact that multiple tabs is started in some browser when g= oing through multiple authentication attempts. That clutters the system so = I really like the new browser-views.

The second is that there are additionally nice things in br= owser-view that do not exist in the web-view. The localStorage is also pres= erved and it can include important information to make authentication metho= ds more secure.

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94

"Authorization servers SHOULD consi= der taking steps to detect and

block logins via embedded user-agents th= at are not their own, where

possible.""


Sounds good, but that also sounds very h= ard when it comes to public clients.=C2=A0

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94

And some nits:


"OAuth flows between a native app a= nd the system browser (or another

external user-agent) are more secure, an= d take advantage of the

shared authentication state."


Not really clear what shared authenticat= ion state that is in that sentence.


"When the authentication server com= pletes the request, it redirects to

=C2=A0 =C2=A0the client's redirectio= n URI like it would any redirect URI"


s/authentication/authorization


/ Erik




On Thu, Jul 23, 2015 at 6:22 PM, <o= auth-request@ietf.org> wrote:

John Bradley and I introduced a new draft at IETF93 yesterday:
https://tools.ietf.org/html/draft-wde= nniss-oauth-native-apps-00


Goal is to provide best practices for native apps using the RFC6749
authorization
endpoint, expanding on RFC6749 Section 9.=C2=A0 Specifically, it recommends=
using an external user-agent (such as the system browser) for this task
over an embedded user-agent (such as a web-view), and suggests ways to
achieve this.


Comments welcome!
--f46d0435c0346b7ba6051b92d68b-- From nobody Thu Jul 23 22:51:42 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C59E1A1AB5 for ; Thu, 23 Jul 2015 22:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlmbvMeKvgeT for ; Thu, 23 Jul 2015 22:51:35 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D2B51B2F45 for ; Thu, 23 Jul 2015 22:51:35 -0700 (PDT) Received: by wicgb10 with SMTP id gb10so13089159wic.1 for ; Thu, 23 Jul 2015 22:51:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=Q/7CibVAe9NwQ+iGF/febrQntX2Q5mMVi2RnUK3ish8=; b=GXZTcM7FmGp4b+rA1IjGPv+w7yZJ+ipP4f1YR82MBFdJaefmnKLyR8LCMxi3XekzFA fLbLk8QR5qJbtzIv1SglgWr1rpImvv0embwh3XTpylX9A5Z9jQNGQ1o9RzIPXFccEqbe zuD2KL13RAVuWnAWQAXbUsmIAqXUgJCTqCHToLr30G4RebnkoPTFfqDxZ/SvE0pAVpOh 2b/dPeDW7Mr6vHVgdvDL9uLSbmfFsvhAKVucJ4SnBkU2UXKQtkMloO+BOZ2c/tDqfAmL urX7V9bxkFXznNlFJqSJjEPpeapQ49sBI0JNVkCKnDMBnGZx5o+iYmShXiniHhe7XP9I 8feg== X-Gm-Message-State: ALoCoQmASFzGE8EYKL9CXfc489mDSN0nJ6lh4XzzrXIEWgg8wZA08eya65dsNSe6Xfs7CQxVx4UK X-Received: by 10.194.48.108 with SMTP id k12mr24724639wjn.151.1437717093958; Thu, 23 Jul 2015 22:51:33 -0700 (PDT) Received: from [130.129.15.152] ([130.129.15.152]) by smtp.gmail.com with ESMTPSA id k4sm1657034wix.19.2015.07.23.22.51.32 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Jul 2015 22:51:32 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: multipart/signed; boundary="Apple-Mail=_153355A7-783D-42AF-80B2-88CC826D8364"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Fri, 24 Jul 2015 07:51:30 +0200 Message-Id: <99C2C652-65E6-42CB-BAD9-0B5D7BD4A90C@ve7jtb.com> References: To: =?utf-8?Q?Erik_Wahlstr=C3=B6m?= X-Mailer: Apple Mail (2.2102) Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Digest, Vol 81, Issue 86 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 05:51:39 -0000 --Apple-Mail=_153355A7-783D-42AF-80B2-88CC826D8364 Content-Type: multipart/alternative; boundary="Apple-Mail=_54D62C12-94BB-43D2-8F0C-FFEE90F5C8AA" --Apple-Mail=_54D62C12-94BB-43D2-8F0C-FFEE90F5C8AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the review Erik, We will go through it in detail and get back to you. I am working with a couple of governments on how a eID app could use the = self issued profile of OpenID Connect to issue tokens. There are also other out of band authentication apps that people use = that need to be considered. I think that the callback / redirect_uri can work if a custom scheme URI = or a app claimed https: URI is used. I agree that sniffing the URI in a web view creates a very confusing = user experience at the moment. It works better on Android than iOS 8 = but is not smooth in many cases. I personally use a out of band mobile authenticator for my enterprise = login that has exactly that problem, and requires me to manually switch = back to the calling app. Regards John B. > On Jul 24, 2015, at 12:59 AM, Erik Wahlstr=C3=B6m = wrote: >=20 > Hi, >=20 > Thanks for a great document! I volunteered to review = draft-wdenniss-oauth-native-apps-00 at the #IETF93 meeting so here we = go: >=20 >=20 > In national mobile eID deployments an app is issued by gov or other = organisation in a country. The app acts as the users authentication = method and it works with an IDP, the IDP can be anywhere if its an PKI = token or at the place that issued the credential if it=E2=80=99s = something else. When an SP start developing an native app for there = services and want=E2=80=99s to use the national eID solution in = combination with OAuth we might run into trouble here. >=20 > The flow is like follows for a service provider called FooBar: >=20 > FooBar=E2=80=99s app starts browser-view. FooBar=E2=80=99s SAML = service provider functionality redirects the user to an national SAML = IDP. The IDP prompts user for a username and then starts an mobile eID = token on the same phone. Users is asked if they want=E2=80=99s to = authenticate to FooBar and enters PIN. User are then redirected back = with an assertion. The FooBar's service provider verifies the assertion = and mint=E2=80=99s OAuth2 token(s) and redirects the user back to the = app with the help of the redirect URL. >=20 > So the phone first displays an app, then foobar.com = in browser-view, then idp.com = in browser-view, then mobile eID token, then = idp.com in the system browser and back to = foobar.com and the app that the user wanted to = use. >=20 > The problem with browser-views is that the mobile eID token will start = idp.com when user has authenticated and then the user = is not back in the apps browser-view, but in system browser instead. The = system browser is sharing the session with the browser-view and redirect = the user to the native app. The user experience will be a bit strange = then because there the correct page is not loaded and the browser-view = should be closed and the app should start parsing out the authorization = code instead. >=20 > So I think draft should mention something about this scenario and that = app developers should handle this scenario in the app. The grant did not = really come back from the browser-view as expected but from the system = browser instead.=20 >=20 > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94 >=20 > With the above in mind. Maybe even some example code would be nice to = have in the non normative section "Appendix A. Operating System = Specific Implementation Details=E2=80=9D. Especially how to handle call = backs. >=20 > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94 >=20 > Another eID related issue is the pricing model for authentications in = that market segment. It=E2=80=99s really common by the eID credential = issuing organisations to charge a service providers usage of a = credential per tick (that is by OSCP call). The system is based on a per = tick pricing model and there are regulations for how long the sessions = can live. That means that its not possible to authenticate with a token = once and then create a refresh token and the user will ever see the = authentication flow again. It kinda messes up the usability of mobile = apps a lot but end users have come to term with it. They have not = however came to term to always require consents every time they use the = app. That drives end user crazy. The usability would be much better if = the payment model also accepted a refresh token as a tick instead of = just an OSCP call, but we are not there yet. >=20 > Anyway, that=E2=80=99s the backstory. The section "6.4. Always = Prompting for User Interaction=E2=80=9D is a bit harsh with a SHOULD = NOT. I would rather change it to a NOT RECOMMENDED. >=20 > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94 >=20 > Two additional things that strengthen the case for using the = browser-view also come to mind when reading the draft. The first is the = fact that multiple tabs is started in some browser when going through = multiple authentication attempts. That clutters the system so I really = like the new browser-views. >=20 > The second is that there are additionally nice things in browser-view = that do not exist in the web-view. The localStorage is also preserved = and it can include important information to make authentication methods = more secure. >=20 > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= >=20 > "Authorization servers SHOULD consider taking steps to detect and >=20 > block logins via embedded user-agents that are not their own, where >=20 > possible."" >=20 >=20 >=20 > Sounds good, but that also sounds very hard when it comes to public = clients.=20 >=20 > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94 >=20 > And some nits: >=20 >=20 >=20 > "OAuth flows between a native app and the system browser (or another >=20 > external user-agent) are more secure, and take advantage of the >=20 > shared authentication state." >=20 >=20 >=20 > Not really clear what shared authentication state that is in that = sentence. >=20 >=20 >=20 > "When the authentication server completes the request, it redirects to >=20 > the client's redirection URI like it would any redirect URI" >=20 >=20 >=20 > s/authentication/authorization >=20 >=20 >=20 > / Erik >=20 >=20 >=20 >=20 >=20 >=20 > On Thu, Jul 23, 2015 at 6:22 PM, > wrote: >=20 > John Bradley and I introduced a new draft at IETF93 yesterday: > https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00 = >=20 >=20 > Goal is to provide best practices for native apps using the RFC6749 > authorization > endpoint, expanding on RFC6749 Section 9. Specifically, it recommends > using an external user-agent (such as the system browser) for this = task > over an embedded user-agent (such as a web-view), and suggests ways to > achieve this. >=20 >=20 > Comments welcome! > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_54D62C12-94BB-43D2-8F0C-FFEE90F5C8AA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for the review Erik,

We will go through it in detail and get = back to you.

I = am working with a couple of governments on how a eID app could use the = self issued profile of OpenID Connect to issue tokens.

There are also other out = of band authentication  apps that people use that need to be = considered.

I = think that the callback / redirect_uri can work if a custom scheme URI = or a app claimed https: URI is used.

I agree that sniffing the URI in a web = view creates a very confusing user experience at the moment.  It = works better on Android than iOS 8 but is not smooth in many = cases.

I = personally use a out of band mobile authenticator for my enterprise = login that has exactly that problem, and requires me to manually switch = back to the calling app.

Regards
John B.




On Jul 24, 2015, at 12:59 AM, = Erik Wahlstr=C3=B6m <erik@wahlstromstekniska.se> wrote:

Hi,

Thanks for a great document! I = volunteered to review draft-wdenniss-oauth-native-apps-00 at the #IETF93 = meeting so here we go:


In national mobile eID deployments an = app is issued by gov or other organisation in a country. The app acts as = the users authentication method and it works with an IDP, the IDP can be = anywhere if its an PKI token or at the place that issued the credential = if it=E2=80=99s something else. When an SP start developing an native = app for there services and want=E2=80=99s to use the national eID = solution in combination with OAuth we might run into trouble = here.

The flow is like = follows for a service provider called FooBar:

FooBar=E2=80=99s app starts = browser-view. FooBar=E2=80=99s SAML service provider functionality = redirects the user to an national SAML IDP. The IDP prompts user for a = username and then starts an mobile eID token on the same phone. Users is = asked if they want=E2=80=99s to authenticate to FooBar and enters PIN. = User are then redirected back with an assertion. The FooBar's service = provider verifies the assertion and mint=E2=80=99s OAuth2 token(s) and = redirects the user back to the app with the help of the redirect = URL.

So the phone first = displays an app, then foobar.com in browser-view, then idp.com in browser-view, = then mobile eID token, then idp.com in the system browser and back to foobar.com and the app that the user wanted = to use.

The problem with = browser-views is that the mobile eID token will start idp.com when user has authenticated and = then the user is not back in the apps browser-view, but in system = browser instead. The system browser is sharing the session with the = browser-view and redirect the user to the native app. The user = experience will be a bit strange then because there the correct page is = not loaded and the browser-view should be closed and the app should = start parsing out the authorization code instead.

So I think draft should mention = something about this scenario and that app developers should handle this = scenario in the app. The grant did not really come back from the = browser-view as expected but from the system browser = instead. 

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94

With the above in mind. = Maybe even some example code would be nice to have in the non normative = section "Appendix A.  Operating System Specific Implementation = Details=E2=80=9D. Especially how to handle call backs.

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94

Another eID related issue is the pricing model for = authentications in that market segment. It=E2=80=99s really common by = the eID credential issuing organisations to charge a service providers = usage of a credential per tick (that is by OSCP call). The system is = based on a per tick pricing model and there are regulations for how long = the sessions can live. That means that its not possible to authenticate = with a token once and then create a refresh token and the user will ever = see the authentication flow again. It kinda messes up the usability of = mobile apps a lot but end users have come to term with it. They have not = however came to term to always require consents every time they use the = app. That drives end user crazy. The usability would be much better if = the payment model also accepted a refresh token as a tick instead of = just an OSCP call, but we are not there yet.

Anyway, that=E2=80=99s the backstory. = The section "6.4.  Always Prompting for User Interaction=E2=80=9D = is a bit harsh with a SHOULD NOT. I would rather change it to a NOT = RECOMMENDED.

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94

Two = additional things that strengthen the case for using the browser-view = also come to mind when reading the draft. The first is the fact that = multiple tabs is started in some browser when going through multiple = authentication attempts. That clutters the system so I really like the = new browser-views.

The second is that there = are additionally nice things in browser-view that do not exist in the = web-view. The localStorage is also preserved and it can include = important information to make authentication methods more secure.

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94

"Authorization servers = SHOULD consider taking steps to detect and

block logins via embedded user-agents that are not their = own, where

possible.""


Sounds good, = but that also sounds very hard when it comes to public = clients. 

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94

And some = nits:


"OAuth flows between a = native app and the system browser (or another

external user-agent) are more secure, = and take advantage of the

shared authentication state."


Not really clear what shared authentication state that is = in that sentence.


"When the = authentication server completes the request, it redirects = to

   the = client's redirection URI like it would any redirect URI"


s/authentication/authorization


/ Erik




On Thu, Jul 23, 2015 at 6:22 PM, = <oauth-request@ietf.org> = wrote:

John Bradley and I introduced a new draft at IETF93 yesterday:
https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00=


Goal is to provide best practices for native apps using the RFC6749
authorization
endpoint, expanding on RFC6749 Section 9.  Specifically, it = recommends
using an external user-agent (such as the system browser) for this = task
over an embedded user-agent (such as a web-view), and suggests ways = to
achieve this.


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

= --Apple-Mail=_54D62C12-94BB-43D2-8F0C-FFEE90F5C8AA-- --Apple-Mail=_153355A7-783D-42AF-80B2-88CC826D8364 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTA3MjQwNTUxMzFaMCMGCSqGSIb3DQEJBDEWBBSeNQNjl4Msjd8PYY7fr6o/ semFpTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQB4H71ILwpmZrrIYCnVgsyT8v4lWV+S7WWUIaQIsBkJBpIbWuQdfM3+ zWq0m6SYAhXSM+jnThC9WCVWaqz4c32anJZVQN8lVrVekaF7KmNs2V038UPW2riLECzrHdYEG6tB CuD6iuw7F+nRULXjhm/EJbLlZDvxt1mi35K1NCYB1qK9jOP7hc1jyHgiX27vl2SfDEN+zbhMkSaP SXox6pUzA6rsSvHIhd/wa3Rl6S1srlfW0GydXzgtpajpICYi60CVim8VHHmnpDiblo5AnQSOmd2c ym1lY/bIaVxYXX+s+mR5l03V5/PqKD3T5TDTsSftd7/dWFFQM/QRLO5oTq0TAAAAAAAA --Apple-Mail=_153355A7-783D-42AF-80B2-88CC826D8364-- From nobody Fri Jul 24 00:01:01 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D48B1AC407 for ; Fri, 24 Jul 2015 00:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id um-k9WtNr9mA for ; Fri, 24 Jul 2015 00:00:56 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0686.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:686]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDBC51B2F88 for ; Fri, 24 Jul 2015 00:00:55 -0700 (PDT) Received: from BY1PR0201MB1030.namprd02.prod.outlook.com (10.161.203.148) by BY1PR0201MB1031.namprd02.prod.outlook.com (10.161.203.149) with Microsoft SMTP Server (TLS) id 15.1.225.19; Fri, 24 Jul 2015 07:00:33 +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.0225.018; Fri, 24 Jul 2015 07:00:33 +0000 From: Antonio Sanso To: John Bradley Thread-Topic: [OAUTH-WG] OAuth Digest, Vol 81, Issue 86 Thread-Index: AQHQxZs7OlbLO2nX6kaUVw3hAEGObp3qHlwAgAAYdIA= Date: Fri, 24 Jul 2015 07:00:33 +0000 Message-ID: <919808A7-B1A8-4CBF-9FD8-447357E18D27@adobe.com> References: <99C2C652-65E6-42CB-BAD9-0B5D7BD4A90C@ve7jtb.com> In-Reply-To: <99C2C652-65E6-42CB-BAD9-0B5D7BD4A90C@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ve7jtb.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [192.147.117.11] x-microsoft-exchange-diagnostics: 1; BY1PR0201MB1031; 5:vi3JmD1cXSEsM1oRwAUuwwS5BS59YjSIKuu7ApdK+MaFMKh+45BbRDNACeTaN3eyFq20HP5YaZq4GWlUwfxeAuUhEXGqZNPfoayzWaQwBANV+ZOGs69S60NtCG7D8KAdRiTJh0o6niU1UvLalitAHw==; 24:7uARG33ITlDZfMiv3uNr4Rd93jhqhNTh8G50tHcxYBw9DRx6mNbexQQHI8ie+IYUlaY0kpWFziKICINVmg46XMf1JiCoWPrM/rsmGdBDyvQ=; 20:ek5gV7cVqtBb08etao4+Ke/1ih3kNcqW6Ry5cXNlYW8y5X2ZhldasB4VJGhe4JtPSOSYuTc0qof0D7KGDXEcBg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0201MB1031; by1pr0201mb1031: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BY1PR0201MB1031; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0201MB1031; x-forefront-prvs: 0647963F84 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(52314003)(51444003)(5403001)(24454002)(10533003)(51914003)(52034003)(36756003)(76176999)(50986999)(110136002)(5001960100002)(92566002)(40100003)(5002640100001)(77096005)(102836002)(15975445007)(54356999)(2950100001)(33656002)(2900100001)(122556002)(10090500001)(82746002)(46102003)(16236675004)(66066001)(87936001)(77156002)(86362001)(62966003)(83716003)(2656002)(19617315012)(19580395003)(106116001)(19580405001)(189998001)(99286002)(15395725005)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0201MB1031; H:BY1PR0201MB1030.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_919808A7B1A84CBF9FD8447357E18D27adobecom_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2015 07:00:33.5171 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0201MB1031 Archived-At: Cc: "oauth@ietf.org" , =?Windows-1252?Q?Erik_Wahlstr=F6m?= Subject: Re: [OAUTH-WG] OAuth Digest, Vol 81, Issue 86 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 07:01:00 -0000 --_000_919808A7B1A84CBF9FD8447357E18D27adobecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable hi, nice to see some work on this topic by the way! Couple of comments below inline On Jul 24, 2015, at 7:51 AM, John Bradley > wrote: Thanks for the review Erik, We will go through it in detail and get back to you. I am working with a couple of governments on how a eID app could use the se= lf issued profile of OpenID Connect to issue tokens. There are also other out of band authentication apps that people use that = need to be considered. I think that the callback / redirect_uri can work if a custom scheme URI or= a app claimed https: URI is used. Is there any example of =93popular=94 custom scheme. One I have seen is urn= :ietf:wg:oauth:2.0:oob Another common redirect_uri for native app I have seen is http://localhost One more comment. I strongly suggest for mobile app to have a really stric= t consent screen policy. Aka the authorization server MUST show the consent screen at every usage an= d not remember the fact that the app has been already authorized. Just my 2 cents :) regards antonio I agree that sniffing the URI in a web view creates a very confusing user e= xperience at the moment. It works better on Android than iOS 8 but is not = smooth in many cases. I personally use a out of band mobile authenticator for my enterprise login= that has exactly that problem, and requires me to manually switch back to = the calling app. Regards John B. On Jul 24, 2015, at 12:59 AM, Erik Wahlstr=F6m > wrote: Hi, Thanks for a great document! I volunteered to review draft-wdenniss-oauth-n= ative-apps-00 at the #IETF93 meeting so here we go: In national mobile eID deployments an app is issued by gov or other organis= ation in a country. The app acts as the users authentication method and it = works with an IDP, the IDP can be anywhere if its an PKI token or at the pl= ace that issued the credential if it=92s something else. When an SP start d= eveloping an native app for there services and want=92s to use the national= eID solution in combination with OAuth we might run into trouble here. The flow is like follows for a service provider called FooBar: FooBar=92s app starts browser-view. FooBar=92s SAML service provider functi= onality redirects the user to an national SAML IDP. The IDP prompts user fo= r a username and then starts an mobile eID token on the same phone. Users i= s asked if they want=92s to authenticate to FooBar and enters PIN. User are= then redirected back with an assertion. The FooBar's service provider veri= fies the assertion and mint=92s OAuth2 token(s) and redirects the user back= to the app with the help of the redirect URL. So the phone first displays an app, then foobar.com in= browser-view, then idp.com in browser-view, then = mobile eID token, then idp.com in the system brows= er and back to foobar.com and the app that the user wa= nted to use. The problem with browser-views is that the mobile eID token will start idp.= com when user has authenticated and then the user is not b= ack in the apps browser-view, but in system browser instead. The system bro= wser is sharing the session with the browser-view and redirect the user to = the native app. The user experience will be a bit strange then because ther= e the correct page is not loaded and the browser-view should be closed and = the app should start parsing out the authorization code instead. So I think draft should mention something about this scenario and that app = developers should handle this scenario in the app. The grant did not really= come back from the browser-view as expected but from the system browser in= stead. =97=97=97=97=97=97=97=97=97 With the above in mind. Maybe even some example code would be nice to have = in the non normative section "Appendix A. Operating System Specific Implem= entation Details=94. Especially how to handle call backs. =97=97=97=97=97=97=97=97=97 Another eID related issue is the pricing model for authentications in that = market segment. It=92s really common by the eID credential issuing organisa= tions to charge a service providers usage of a credential per tick (that is= by OSCP call). The system is based on a per tick pricing model and there a= re regulations for how long the sessions can live. That means that its not = possible to authenticate with a token once and then create a refresh token = and the user will ever see the authentication flow again. It kinda messes u= p the usability of mobile apps a lot but end users have come to term with i= t. They have not however came to term to always require consents every time= they use the app. That drives end user crazy. The usability would be much = better if the payment model also accepted a refresh token as a tick instead= of just an OSCP call, but we are not there yet. Anyway, that=92s the backstory. The section "6.4. Always Prompting for Use= r Interaction=94 is a bit harsh with a SHOULD NOT. I would rather change it= to a NOT RECOMMENDED. =97=97=97=97=97=97=97=97=97 Two additional things that strengthen the case for using the browser-view a= lso come to mind when reading the draft. The first is the fact that multipl= e tabs is started in some browser when going through multiple authenticatio= n attempts. That clutters the system so I really like the new browser-views= . The second is that there are additionally nice things in browser-view that = do not exist in the web-view. The localStorage is also preserved and it can= include important information to make authentication methods more secure. =97=97=97=97=97=97=97=97 "Authorization servers SHOULD consider taking steps to detect and block logins via embedded user-agents that are not their own, where possible."" Sounds good, but that also sounds very hard when it comes to public clients= . =97=97=97=97=97=97=97=97=97 And some nits: "OAuth flows between a native app and the system browser (or another external user-agent) are more secure, and take advantage of the shared authentication state." Not really clear what shared authentication state that is in that sentence. "When the authentication server completes the request, it redirects to the client's redirection URI like it would any redirect URI" s/authentication/authorization / Erik On Thu, Jul 23, 2015 at 6:22 PM, > wrote: John Bradley and I introduced a new draft at IETF93 yesterday: https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00 Goal is to provide best practices for native apps using the RFC6749 authorization endpoint, expanding on RFC6749 Section 9. Specifically, it recommends using an external user-agent (such as the system browser) for this task over an embedded user-agent (such as a web-view), and suggests ways to achieve this. Comments welcome! _______________________________________________ OAuth mailing 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_919808A7B1A84CBF9FD8447357E18D27adobecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable hi,

nice to see some work on this topic by the way!

Couple of comments below inline

On Jul 24, 2015, at 7:51 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Thanks for the review Erik,

We will go through it in detail and get back to you.

I am working with a couple of governments on how a eID app = could use the self issued profile of OpenID Connect to issue tokens.

There are also other out of band authentication  apps = that people use that need to be considered.

I think that the callback / redirect_uri can work if a cust= om scheme URI or a app claimed https: URI is used.

Is there any example of =93popular=94 custom scheme. One I have seen i= s urn:ietf:wg:oauth:2.0:oob 
Another common redirect_uri for native app I have seen is http://localhost

One more comment. I strongly suggest  for mobile app to have a re= ally strict consent screen policy.
Aka the authorization server MUST show the consent screen at every usa= ge and not remember the fact that the app has been already authorized.

Just my 2 cents :)

regards

antonio 


I agree that sniffing the URI in a web view creates a very = confusing user experience at the moment.  It works better on Android t= han iOS 8 but is not smooth in many cases.

I personally use a out of band mobile authenticator for my = enterprise login that has exactly that problem, and requires me to manually= switch back to the calling app.

Regards
John B.




On Jul 24, 2015, at 12:59 AM, Erik Wahlstr=F6m <erik@wahlstromstekniska.s= e> wrote:

Hi,

Thanks for a great document! I volunteer= ed to review draft-wdenniss-oauth-native-apps-00 at the #IETF93 meeting so = here we go:


In national mobile eID deployments an ap= p is issued by gov or other organisation in a country. The app acts as the = users authentication method and it works with an IDP, the IDP can be anywhe= re if its an PKI token or at the place that issued the credential if it=92s something else. When an SP start deve= loping an native app for there services and want=92s to use the national eI= D solution in combination with OAuth we might run into trouble here.=

The flow is like follows for a service p= rovider called FooBar:

FooBar=92s app starts browser-view. = ;FooBar=92s SAML service provider functionality redirects the user to an na= tional SAML IDP. The IDP prompts user for a username and then starts an mob= ile eID token on the same phone. Users is asked if they want=92s to authenticate to FooBar and enters PIN. User are then r= edirected back with an assertion. The FooBar's service provider verifies th= e assertion and mint=92s OAuth2 token(s) and redirects the user back to the= app with the help of the redirect URL.

So the phone first displays an app, then= foobar.com in browser-view, then idp.com in browser-view, then mobile eID token, then idp.com in the system browser and back to foobar.com and the app that the user wan= ted to use.

The problem with browser-views is that t= he mobile eID token will start idp.com when user has authenticated and then the user is not back in the app= s browser-view, but in system browser instead. The system browser is sharin= g the session with the browser-view and redirect the user to the native app. The user experience will be a bit strange then= because there the correct page is not loaded and the browser-view should b= e closed and the app should start parsing out the authorization code instea= d.

So I think draft should mention somethin= g about this scenario and that app developers should handle this scenario i= n the app. The grant did not really come back from the browser-view as expe= cted but from the system browser instead. 

=97=97=97=97=97=97=97=97=97

With the above in mind. Maybe even some example code would = be nice to have in the non normative section "Appendix A.  Operat= ing System Specific Implementation Details=94. Especially how to handle cal= l backs.

=97=97=97=97=97=97=97=97=97

Another eID related issue is the pricing= model for authentications in that market segment. It=92s really common by = the eID credential issuing organisations to charge a service providers usag= e of a credential per tick (that is by OSCP call). The system is based on a per tick pricing model and there are = regulations for how long the sessions can live. That means that its not pos= sible to authenticate with a token once and then create a refresh token and= the user will ever see the authentication flow again. It kinda messes up the usability of mobile apps a lot but end = users have come to term with it. They have not however came to term to alwa= ys require consents every time they use the app. That drives end user crazy= . The usability would be much better if the payment model also accepted a refresh token as a tick instead of ju= st an OSCP call, but we are not there yet.

Anyway, that=92s the backstory. The sect= ion "6.4.  Always Prompting for User Interaction=94 is a bit hars= h with a SHOULD NOT. I would rather change it to a NOT RECOMMENDED.

=97=97=97=97=97=97=97=97=97

Two additional things that strengthen th= e case for using the browser-view also come to mind when reading the draft.= The first is the fact that multiple tabs is started in some browser when g= oing through multiple authentication attempts. That clutters the system so I really like the new browser-views.=

The second is that there are additionally nice things in br= owser-view that do not exist in the web-view. The localStorage is also pres= erved and it can include important information to make authentication metho= ds more secure.

=97=97=97=97=97=97=97=97

"Authorization servers SHOULD consi= der taking steps to detect and

block logins via embedded user-agents th= at are not their own, where

possible.""


Sounds good, but that also sounds very h= ard when it comes to public clients. 

=97=97=97=97=97=97=97=97=97

And some nits:


"OAuth flows between a native app a= nd the system browser (or another

external user-agent) are more secure, an= d take advantage of the

shared authentication state."


Not really clear what shared authenticat= ion state that is in that sentence.


"When the authentication server com= pletes the request, it redirects to

   the client's redirection UR= I like it would any redirect URI"


s/authentication/authorization


/ Erik




On Thu, Jul 23, 2015 at 6:22 PM, <= oauth-request@ietf.org> wrote:

John Bradley and I introduced a new draft at IETF93 yesterday:
https://tools.ietf.org/htm= l/draft-wdenniss-oauth-native-apps-00


Goal is to provide best practices for native apps using the RFC6749
authorization
endpoint, expanding on RFC6749 Section 9.  Specifically, it recommends=
using an external user-agent (such as the system browser) for this task
over an embedded user-agent (such as a web-view), and suggests ways to
achieve this.


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

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

--_000_919808A7B1A84CBF9FD8447357E18D27adobecom_-- From nobody Fri Jul 24 00:38:52 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800CE1B2FD0 for ; Fri, 24 Jul 2015 00:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.145 X-Spam-Level: X-Spam-Status: No, score=-0.145 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecfJPYyT8Q5W for ; Fri, 24 Jul 2015 00:38:47 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A98931B2FBD for ; Fri, 24 Jul 2015 00:38:46 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so15729198wib.1 for ; Fri, 24 Jul 2015 00:38:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=iu5mgU7bCYHuc0KU0LCRPxAOSQjJ16xUTyAsaw814iw=; b=cjVWUCO87WOtob9hZ/L7VCxB/eMBh6lMbDLIQ7gcXNemf2jKYzN1p4XhhKkxHAMfcy KbA/h6VfotzALummCiFjA7D+zvRiMBVeJidbiwFcby623SwpJg8cGxMbCQOuNSvj4CRK WKB663gZAWqiq7t+8PUZy6NuJR9RYkoaKbbjWkHkEJZLg/OXNU8+qVnr0Yp+O/QmOCzy gqAUZ/kB9TokyFgmxs1LMcO+Gg799OpiKb286ucFHq6cCz6jk0bxNWtiEbjBVzY0nCmm lhYDQDwC/IoLvFcI6GDjvqRp326ETWW5vaLxfU7l70y6LRQGW4knEij81+9Luoa5PtAT 996w== X-Gm-Message-State: ALoCoQnCX2S9f6X6lrekM3RVEDoeINJ0M0vHpSk4XnNUwxaDow0gfHOlbvOzMqzhuGrsE4AtP7tb X-Received: by 10.194.97.196 with SMTP id ec4mr24036271wjb.3.1437723525287; Fri, 24 Jul 2015 00:38:45 -0700 (PDT) Received: from [10.6.0.142] ([62.212.85.119]) by smtp.gmail.com with ESMTPSA id x6sm2096806wiy.6.2015.07.24.00.38.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 Jul 2015 00:38:44 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_84589801-548B-4FAC-AE92-09386503B1E5"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: John Bradley In-Reply-To: <919808A7-B1A8-4CBF-9FD8-447357E18D27@adobe.com> Date: Fri, 24 Jul 2015 09:38:41 +0200 Message-Id: <714BEA65-C2AB-41C7-BA29-51D32BC6B8A0@ve7jtb.com> References: <99C2C652-65E6-42CB-BAD9-0B5D7BD4A90C@ve7jtb.com> <919808A7-B1A8-4CBF-9FD8-447357E18D27@adobe.com> To: Antonio Sanso X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "oauth@ietf.org" , =?utf-8?Q?Erik_Wahlstr=C3=B6m?= Subject: Re: [OAUTH-WG] OAuth Digest, Vol 81, Issue 86 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 07:38:50 -0000 --Apple-Mail=_84589801-548B-4FAC-AE92-09386503B1E5 Content-Type: multipart/alternative; boundary="Apple-Mail=_0D52FDDC-9A49-4DE9-9ABC-259C81151987" --Apple-Mail=_0D52FDDC-9A49-4DE9-9ABC-259C81151987 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Antonio, Thanks for the feedback. I agree that for non confidential clients, the user needs to be = prompted. It might be fair to just confirm the grants rather than = resetting them from defaults. I know some people are doing that, but I suspect that not everyone is. Good stuff. People should chime in with other things we need to consider. Thanks John B. > On Jul 24, 2015, at 9:00 AM, Antonio Sanso wrote: >=20 > hi, >=20 > nice to see some work on this topic by the way! >=20 > Couple of comments below inline >=20 > On Jul 24, 2015, at 7:51 AM, John Bradley > wrote: >=20 >> Thanks for the review Erik, >>=20 >> We will go through it in detail and get back to you. >>=20 >> I am working with a couple of governments on how a eID app could use = the self issued profile of OpenID Connect to issue tokens. >>=20 >> There are also other out of band authentication apps that people use = that need to be considered. >>=20 >> I think that the callback / redirect_uri can work if a custom scheme = URI or a app claimed https: URI is used. >=20 > Is there any example of =93popular=94 custom scheme. One I have seen = is urn:ietf:wg:oauth:2.0:oob=20 > Another common redirect_uri for native app I have seen is = http://localhost >=20 > One more comment. I strongly suggest for mobile app to have a really = strict consent screen policy. > Aka the authorization server MUST show the consent screen at every = usage and not remember the fact that the app has been already = authorized. >=20 > Just my 2 cents :) >=20 > regards >=20 > antonio=20 >=20 >>=20 >> I agree that sniffing the URI in a web view creates a very confusing = user experience at the moment. It works better on Android than iOS 8 = but is not smooth in many cases. >>=20 >> I personally use a out of band mobile authenticator for my enterprise = login that has exactly that problem, and requires me to manually switch = back to the calling app. >>=20 >> Regards >> John B. >>=20 >>=20 >>=20 >>=20 >>> On Jul 24, 2015, at 12:59 AM, Erik Wahlstr=F6m = > wrote: >>>=20 >>> Hi, >>>=20 >>> Thanks for a great document! I volunteered to review = draft-wdenniss-oauth-native-apps-00 at the #IETF93 meeting so here we = go: >>>=20 >>>=20 >>> In national mobile eID deployments an app is issued by gov or other = organisation in a country. The app acts as the users authentication = method and it works with an IDP, the IDP can be anywhere if its an PKI = token or at the place that issued the credential if it=92s something = else. When an SP start developing an native app for there services and = want=92s to use the national eID solution in combination with OAuth we = might run into trouble here. >>>=20 >>> The flow is like follows for a service provider called FooBar: >>>=20 >>> FooBar=92s app starts browser-view. FooBar=92s SAML service provider = functionality redirects the user to an national SAML IDP. The IDP = prompts user for a username and then starts an mobile eID token on the = same phone. Users is asked if they want=92s to authenticate to FooBar = and enters PIN. User are then redirected back with an assertion. The = FooBar's service provider verifies the assertion and mint=92s OAuth2 = token(s) and redirects the user back to the app with the help of the = redirect URL. >>>=20 >>> So the phone first displays an app, then foobar.com = in browser-view, then idp.com = in browser-view, then mobile eID token, then = idp.com in the system browser and back to = foobar.com and the app that the user wanted to = use. >>>=20 >>> The problem with browser-views is that the mobile eID token will = start idp.com when user has authenticated and then the = user is not back in the apps browser-view, but in system browser = instead. The system browser is sharing the session with the browser-view = and redirect the user to the native app. The user experience will be a = bit strange then because there the correct page is not loaded and the = browser-view should be closed and the app should start parsing out the = authorization code instead. >>>=20 >>> So I think draft should mention something about this scenario and = that app developers should handle this scenario in the app. The grant = did not really come back from the browser-view as expected but from the = system browser instead.=20 >>>=20 >>> =97=97=97=97=97=97=97=97=97 >>>=20 >>> With the above in mind. Maybe even some example code would be nice = to have in the non normative section "Appendix A. Operating System = Specific Implementation Details=94. Especially how to handle call backs. >>>=20 >>> =97=97=97=97=97=97=97=97=97 >>>=20 >>> Another eID related issue is the pricing model for authentications = in that market segment. It=92s really common by the eID credential = issuing organisations to charge a service providers usage of a = credential per tick (that is by OSCP call). The system is based on a per = tick pricing model and there are regulations for how long the sessions = can live. That means that its not possible to authenticate with a token = once and then create a refresh token and the user will ever see the = authentication flow again. It kinda messes up the usability of mobile = apps a lot but end users have come to term with it. They have not = however came to term to always require consents every time they use the = app. That drives end user crazy. The usability would be much better if = the payment model also accepted a refresh token as a tick instead of = just an OSCP call, but we are not there yet. >>>=20 >>> Anyway, that=92s the backstory. The section "6.4. Always Prompting = for User Interaction=94 is a bit harsh with a SHOULD NOT. I would rather = change it to a NOT RECOMMENDED. >>>=20 >>> =97=97=97=97=97=97=97=97=97 >>>=20 >>> Two additional things that strengthen the case for using the = browser-view also come to mind when reading the draft. The first is the = fact that multiple tabs is started in some browser when going through = multiple authentication attempts. That clutters the system so I really = like the new browser-views. >>>=20 >>> The second is that there are additionally nice things in = browser-view that do not exist in the web-view. The localStorage is also = preserved and it can include important information to make = authentication methods more secure. >>>=20 >>> =97=97=97=97=97=97=97=97 >>>=20 >>> "Authorization servers SHOULD consider taking steps to detect and >>>=20 >>> block logins via embedded user-agents that are not their own, where >>>=20 >>> possible."" >>>=20 >>>=20 >>>=20 >>> Sounds good, but that also sounds very hard when it comes to public = clients.=20 >>>=20 >>> =97=97=97=97=97=97=97=97=97 >>>=20 >>> And some nits: >>>=20 >>>=20 >>>=20 >>> "OAuth flows between a native app and the system browser (or another >>>=20 >>> external user-agent) are more secure, and take advantage of the >>>=20 >>> shared authentication state." >>>=20 >>>=20 >>>=20 >>> Not really clear what shared authentication state that is in that = sentence. >>>=20 >>>=20 >>>=20 >>> "When the authentication server completes the request, it redirects = to >>>=20 >>> the client's redirection URI like it would any redirect URI" >>>=20 >>>=20 >>>=20 >>> s/authentication/authorization >>>=20 >>>=20 >>>=20 >>> / Erik >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On Thu, Jul 23, 2015 at 6:22 PM, > wrote: >>>=20 >>> John Bradley and I introduced a new draft at IETF93 yesterday: >>> https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00 = >>>=20 >>>=20 >>> Goal is to provide best practices for native apps using the RFC6749 >>> authorization >>> endpoint, expanding on RFC6749 Section 9. Specifically, it = recommends >>> using an external user-agent (such as the system browser) for this = task >>> over an embedded user-agent (such as a web-view), and suggests ways = to >>> achieve this. >>>=20 >>>=20 >>> Comments welcome! >>> _______________________________________________ >>> 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=_0D52FDDC-9A49-4DE9-9ABC-259C81151987 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Antonio,

Thanks for the feedback.

I agree that for non confidential = clients, the user needs to be prompted.   It might be fair to just = confirm the grants rather than resetting them from defaults.

I know some people are = doing that, but I suspect that not everyone is.

Good stuff.

People should chime in with other = things we need to consider.

Thanks
John B.

On = Jul 24, 2015, at 9:00 AM, Antonio Sanso <asanso@adobe.com> = wrote:

hi,

nice to see some work on = this topic by the way!

Couple of comments below = inline

On Jul 24, = 2015, at 7:51 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Thanks = for the review Erik,

We will go through it in detail and get back to = you.

I am = working with a couple of governments on how a eID app could use the self = issued profile of OpenID Connect to issue tokens.
There are also other out of band = authentication  apps that people use that need to be = considered.

I = think that the callback / redirect_uri can work if a custom scheme URI = or a app claimed https: URI is used.

Is there any example of = =93popular=94 custom scheme. One I have seen is = urn:ietf:wg:oauth:2.0:oob 
Another common = redirect_uri for native app I have seen is http://localhost

One more comment. I strongly suggest =  for mobile app to have a really strict consent screen = policy.
Aka the authorization server MUST show the = consent screen at every usage and not remember the fact that the app has = been already authorized.

Just my 2 cents :)

regards

antonio 


I agree that sniffing the URI in a web = view creates a very confusing user experience at the moment.  It = works better on Android than iOS 8 but is not smooth in many = cases.

I = personally use a out of band mobile authenticator for my enterprise = login that has exactly that problem, and requires me to manually switch = back to the calling app.

Regards
John B.




On Jul = 24, 2015, at 12:59 AM, Erik Wahlstr=F6m <erik@wahlstromstekniska.se> wrote:

Hi,

Thanks for a great document! I = volunteered to review draft-wdenniss-oauth-native-apps-00 at the #IETF93 = meeting so here we go:


In national mobile eID deployments an = app is issued by gov or other organisation in a country. The app acts as = the users authentication method and it works with an IDP, the IDP can be = anywhere if its an PKI token or at the place that issued the credential = if it=92s something else. When an SP start developing an native app for = there services and want=92s to use the national eID solution in = combination with OAuth we might run into trouble here.

The flow is like follows for a service = provider called FooBar:

FooBar=92s app starts browser-view. FooBar=92s SAML = service provider functionality redirects the user to an national SAML = IDP. The IDP prompts user for a username and then starts an mobile eID = token on the same phone. Users is asked if they want=92s to authenticate = to FooBar and enters PIN. User are then redirected back with an = assertion. The FooBar's service provider verifies the assertion and = mint=92s OAuth2 token(s) and redirects the user back to the app with the = help of the redirect URL.

So = the phone first displays an app, then foobar.com in browser-view, then idp.com in browser-view, then mobile eID token, then idp.com in the system = browser and back to foobar.com and the app that the user wanted = to use.

The problem with = browser-views is that the mobile eID token will start idp.com when user has = authenticated and then the user is not back in the apps browser-view, = but in system browser instead. The system browser is sharing the session = with the browser-view and redirect the user to the native app. The user = experience will be a bit strange then because there the correct page is = not loaded and the browser-view should be closed and the app should = start parsing out the authorization code instead.

So I think draft should mention = something about this scenario and that app developers should handle this = scenario in the app. The grant did not really come back from the = browser-view as expected but from the system browser = instead. 

=97=97=97=97=97=97=97=97=97

With = the above in mind. Maybe even some example code would be nice to have in = the non normative section "Appendix A.  Operating System Specific = Implementation Details=94. Especially how to handle call backs.

=97=97=97=97=97=97=97=97=97

Another eID related issue is the pricing = model for authentications in that market segment. It=92s really common = by the eID credential issuing organisations to charge a service = providers usage of a credential per tick (that is by OSCP call). The = system is based on a per tick pricing model and there are regulations = for how long the sessions can live. That means that its not possible to = authenticate with a token once and then create a refresh token and the = user will ever see the authentication flow again. It kinda messes up the = usability of mobile apps a lot but end users have come to term with it. = They have not however came to term to always require consents every time = they use the app. That drives end user crazy. The usability would be = much better if the payment model also accepted a refresh token as a tick = instead of just an OSCP call, but we are not there yet.

Anyway, that=92s the backstory. The = section "6.4.  Always Prompting for User Interaction=94 is a bit = harsh with a SHOULD NOT. I would rather change it to a NOT = RECOMMENDED.

=97=97=97=97=97=97=97=97=97

Two additional things that strengthen the case for using = the browser-view also come to mind when reading the draft. The first is = the fact that multiple tabs is started in some browser when going = through multiple authentication attempts. That clutters the system so I = really like the new browser-views.

The second = is that there are additionally nice things in browser-view that do not = exist in the web-view. The localStorage is also preserved and it can = include important information to make authentication methods more = secure.

=97=97=97=97=97=97=97=97

"Authorization servers SHOULD consider taking steps to = detect and

block logins via = embedded user-agents that are not their own, where

possible.""


Sounds good, but that also sounds very = hard when it comes to public clients. 

=97=97=97=97=97=97=97=97=97

And some nits:


"OAuth flows between a native app and = the system browser (or another

external user-agent) are more secure, and take advantage of = the

shared authentication = state."


Not really clear what = shared authentication state that is in that sentence.


"When the authentication server = completes the request, it redirects to

   the client's redirection URI like it would any = redirect URI"


s/authentication/authorization


/ Erik




On Thu, Jul 23, 2015 at 6:22 = PM, <oauth-request@ietf.org> wrote:

John = Bradley and I introduced a new draft at IETF93 yesterday:
https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00=


Goal is to provide best = practices for native apps using the RFC6749
authorizationendpoint, expanding on RFC6749 Section 9.  = Specifically, it recommends
using an external user-agent = (such as the system browser) for this task
over an = embedded user-agent (such as a web-view), and suggests ways to
achieve this.


Comments = welcome!
___________________________________= ____________
OAuth mailing 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=_0D52FDDC-9A49-4DE9-9ABC-259C81151987-- --Apple-Mail=_84589801-548B-4FAC-AE92-09386503B1E5 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTA3MjQwNzM4NDJaMCMGCSqGSIb3DQEJBDEWBBStlVxqdLd9dD4ZrS/YOIq9 wYTdujCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCoXmitawIBj744mk8tawclBtiN9cXezxnlAgQ0E0KsHSvX0puYXPth S/eT6pGQkqwiO3zDb16GmfVMz9s33nPVmp5Ic7/uaHbvYabx2g8bID1HVNW50OtGc44QAAg+tTvy ujVzTgKZ9HZpQOMl1PHzxbLpZUcM9UMXYsCgZ4LrlXKN66L4Wd/hRPrrJX856U8y7dW40okY/Vgz Qlj5Lj5z6eyR0nDpzE8N3IVPl0LcQsyxacTdy22ggC32gC9OzXIfr8MUndYj7g1k6jT8TA+EJzAU Mh7JA0RBejoM9ckgYtbvj4sD4J9nhqCTh9nYUOKjq7p8FKyQVcHI+pWpVGwHAAAAAAAA --Apple-Mail=_84589801-548B-4FAC-AE92-09386503B1E5-- From nobody Fri Jul 24 00:44:13 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467221B2FDB for ; Fri, 24 Jul 2015 00:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AR8OL0iw9UR1 for ; Fri, 24 Jul 2015 00:44:07 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86E731B2FEC for ; Fri, 24 Jul 2015 00:44:07 -0700 (PDT) Received: by obre1 with SMTP id e1so11720105obr.1 for ; Fri, 24 Jul 2015 00:44:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3nPtN0TBtMkvHcnP/sG4RmdC05BSnc4xVtpHkDNoeMY=; b=vAQCcMkM/d7hKA6chjEocP2i1ZAhanur1XDXUderNOff8LwkKSWKQbh3SwH7u1xtZd VG+pTUKi/Tz5edfpDrQhimOT/jWSGJRPZt4bRd7XvxAJJC54fi+i/KvTvZwctlGFHM61 D9vnlFPdtCCbLOKGv/w2pSDqQ+xx2/7cDdhSTDP3QQwCQRbCtQydHaOyI7nLmVij8ahJ GzSOVB4s/OQh1Y025kEIKvZdVinIHp7m4R8O2I6U83RdEBkKWceevIhWFb7OUvYk0BzI 2RPUv97RS+oIYUTYqXq1FW7xf7E7/KdA126l4nTUSd/TBK3GNAQ9lxSshY59DaNzJhQL Jjcw== MIME-Version: 1.0 X-Received: by 10.202.44.210 with SMTP id s201mr13009676ois.53.1437723847029; Fri, 24 Jul 2015 00:44:07 -0700 (PDT) Received: by 10.182.96.66 with HTTP; Fri, 24 Jul 2015 00:44:06 -0700 (PDT) In-Reply-To: <714BEA65-C2AB-41C7-BA29-51D32BC6B8A0@ve7jtb.com> References: <99C2C652-65E6-42CB-BAD9-0B5D7BD4A90C@ve7jtb.com> <919808A7-B1A8-4CBF-9FD8-447357E18D27@adobe.com> <714BEA65-C2AB-41C7-BA29-51D32BC6B8A0@ve7jtb.com> Date: Fri, 24 Jul 2015 16:44:06 +0900 Message-ID: From: Nat Sakimura To: John Bradley Content-Type: multipart/alternative; boundary=001a1137c6422ffaee051b9a2b64 Archived-At: Cc: "oauth@ietf.org" , =?UTF-8?Q?Erik_Wahlstr=C3=B6m?= Subject: Re: [OAUTH-WG] OAuth Digest, Vol 81, Issue 86 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 07:44:11 -0000 --001a1137c6422ffaee051b9a2b64 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Prompting is not necessarily is a good thing. It is very context specific, so please do not make it required. Nat 2015-07-24 16:38 GMT+09:00 John Bradley : > Hi Antonio, > > Thanks for the feedback. > > I agree that for non confidential clients, the user needs to be prompted. > It might be fair to just confirm the grants rather than resetting them > from defaults. > > I know some people are doing that, but I suspect that not everyone is. > > Good stuff. > > People should chime in with other things we need to consider. > > Thanks > John B. > > On Jul 24, 2015, at 9:00 AM, Antonio Sanso wrote: > > hi, > > nice to see some work on this topic by the way! > > Couple of comments below inline > > On Jul 24, 2015, at 7:51 AM, John Bradley wrote: > > Thanks for the review Erik, > > We will go through it in detail and get back to you. > > I am working with a couple of governments on how a eID app could use the > self issued profile of OpenID Connect to issue tokens. > > There are also other out of band authentication apps that people use tha= t > need to be considered. > > I think that the callback / redirect_uri can work if a custom scheme URI > or a app claimed https: URI is used. > > > Is there any example of =E2=80=9Cpopular=E2=80=9D custom scheme. One I ha= ve seen is > urn:ietf:wg:oauth:2.0:oob > Another common redirect_uri for native app I have seen is http://localhos= t > > One more comment. I strongly suggest for mobile app to have a really > strict consent screen policy. > Aka the authorization server MUST show the consent screen at every usage > and not remember the fact that the app has been already authorized. > > Just my 2 cents :) > > regards > > antonio > > > I agree that sniffing the URI in a web view creates a very confusing user > experience at the moment. It works better on Android than iOS 8 but is n= ot > smooth in many cases. > > I personally use a out of band mobile authenticator for my enterprise > login that has exactly that problem, and requires me to manually switch > back to the calling app. > > Regards > John B. > > > > > On Jul 24, 2015, at 12:59 AM, Erik Wahlstr=C3=B6m > wrote: > > Hi, > > Thanks for a great document! I volunteered to review > draft-wdenniss-oauth-native-apps-00 at the #IETF93 meeting so here we go: > > In national mobile eID deployments an app is issued by gov or other > organisation in a country. The app acts as the users authentication metho= d > and it works with an IDP, the IDP can be anywhere if its an PKI token or = at > the place that issued the credential if it=E2=80=99s something else. When= an SP > start developing an native app for there services and want=E2=80=99s to u= se the > national eID solution in combination with OAuth we might run into trouble > here. > > The flow is like follows for a service provider called FooBar: > > FooBar=E2=80=99s app starts browser-view. FooBar=E2=80=99s SAML service p= rovider > functionality redirects the user to an national SAML IDP. The IDP prompts > user for a username and then starts an mobile eID token on the same phone= . > Users is asked if they want=E2=80=99s to authenticate to FooBar and enter= s PIN. > User are then redirected back with an assertion. The FooBar's service > provider verifies the assertion and mint=E2=80=99s OAuth2 token(s) and re= directs > the user back to the app with the help of the redirect URL. > > So the phone first displays an app, then foobar.com = in > browser-view, then idp.com in *browser-view*, > then mobile eID token, then idp.com in the *sys= tem > browser* and back to foobar.com and the app that > the user wanted to use. > > The problem with browser-views is that the mobile eID token will start > idp.com when user has authenticated and then the user is not back in the > apps browser-view, but in system browser instead. The system browser is > sharing the session with the browser-view and redirect the user to the > native app. The user experience will be a bit strange then because there > the correct page is not loaded and the browser-view should be closed and > the app should start parsing out the authorization code instead. > > So I think draft should mention something about this scenario and that ap= p > developers should handle this scenario in the app. The grant did not real= ly > come back from the browser-view as expected but from the system browser > instead. > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94 > > With the above in mind. Maybe even some example code would be nice to hav= e > in the non normative section "Appendix A. Operating System Specific > Implementation Details=E2=80=9D. Especially how to handle call backs. > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94 > > Another eID related issue is the pricing model for authentications in tha= t > market segment. It=E2=80=99s really common by the eID credential issuing > organisations to charge a service providers usage of a credential per tic= k > (that is by OSCP call). The system is based on a per tick pricing model a= nd > there are regulations for how long the sessions can live. That means that > its not possible to authenticate with a token once and then create a > refresh token and the user will ever see the authentication flow again. I= t > kinda messes up the usability of mobile apps a lot but end users have com= e > to term with it. They have not however came to term to always require > consents every time they use the app. That drives end user crazy. The > usability would be much better if the payment model also accepted a refre= sh > token as a tick instead of just an OSCP call, but we are not there yet. > > Anyway, that=E2=80=99s the backstory. The section "6.4. Always Prompting= for User > Interaction=E2=80=9D is a bit harsh with a SHOULD NOT. I would rather cha= nge it to > a NOT RECOMMENDED. > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94 > > Two additional things that strengthen the case for using the browser-view > also come to mind when reading the draft. The first is the fact that > multiple tabs is started in some browser when going through multiple > authentication attempts. That clutters the system so I really like the ne= w > browser-views. > > The second is that there are additionally nice things in browser-view tha= t > do not exist in the web-view. The localStorage is also preserved and it c= an > include important information to make authentication methods more secure. > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 > > "Authorization servers SHOULD consider taking steps to detect and > > block logins via embedded user-agents that are not their own, where > > possible."" > > > Sounds good, but that also sounds very hard when it comes to public > clients. > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94 > > And some nits: > > > "OAuth flows between a native app and the system browser (or another > > external user-agent) are more secure, and take advantage of the > > shared authentication state." > > > Not really clear what shared authentication state that is in that sentenc= e. > > > "When the authentication server completes the request, it redirects to > > the client's redirection URI like it would any redirect URI" > > > s/authentication/authorization > > > / Erik > > > > > On Thu, Jul 23, 2015 at 6:22 PM, wrote: >> >> >> John Bradley and I introduced a new draft at IETF93 yesterday: >> https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00 >> >> >> Goal is to provide best practices for native apps using the RFC6749 >> authorization >> endpoint, expanding on RFC6749 Section 9. Specifically, it recommends >> using an external user-agent (such as the system browser) for this task >> over an embedded user-agent (such as a web-view), and suggests ways to >> achieve this. >> >> >> Comments welcome! > > _______________________________________________ > OAuth mailing list > OAuth@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 --001a1137c6422ffaee051b9a2b64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Prompting is not necessarily is a good thing.=C2=A0
It= is very context specific, so please do not make it required.=C2=A0

Nat

2015-07-24 16:38 GMT+09:00 John Bradley = <ve7jtb@ve7jtb.co= m>:
Hi Antonio,

Thanks for the feedback.
<= div>
I agree that for non confidential clients, the user need= s to be prompted. =C2=A0 It might be fair to just confirm the grants rather= than resetting them from defaults.

I know some pe= ople are doing that, but I suspect that not everyone is.

Good stuff.

People should chime in with oth= er things we need to consider.

Thanks
Jo= hn B.

On= Jul 24, 2015, at 9:00 AM, Antonio Sanso <asanso@adobe.com> wrote:

hi,

nice to see some work on this to= pic by the way!

Couple of commen= ts below inline

On= Jul 24, 2015, at 7:51 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Thanks for the review = Erik,

We will go through it in detail and get back to yo= u.

I am working with a couple of governments on ho= w a eID app could use the self issued profile of OpenID Connect to issue to= kens.

There are also other out of band authenticat= ion =C2=A0apps that people use that need to be considered.

I think that the callback / redirect_uri can work if a custom sche= me URI or a app claimed https: URI is used.
Is there any example of =E2=80=9Cpopular=E2=80=9D custom schem= e. One I have seen is urn:ietf:wg:oauth:2.0:oob=C2=A0
Anot= her common redirect_uri for native app I have seen is=C2=A0http://localhost

One more comment. I strongly suggest= =C2=A0for mobile app to have a really strict consent screen policy.
<= div>Aka the authorization server MUST show the consent screen at every usag= e and not remember the fact that the app has been already authorized.
=

Just my 2 cents :)

regards

antonio=C2=A0


I agree that sniffing t= he URI in a web view creates a very confusing user experience at the moment= .=C2=A0 It works better on Android than iOS 8 but is not smooth in many cas= es.

I personally use a out of band mobile authenti= cator for my enterprise login that has exactly that problem, and requires m= e to manually switch back to the calling app.

Rega= rds
John B.




On Jul 24, 2015, at 12:59 AM, Eri= k Wahlstr=C3=B6m <erik@wahlstromstekniska.se> wrote:

Hi,

Thanks for a great document! I vo= lunteered to review draft-wdenniss-oauth-native-apps-00 at the #IETF93 meet= ing so here we go:


In nation= al mobile eID deployments an app is issued by gov or other organisation in = a country. The app acts as the users authentication method and it works wit= h an IDP, the IDP can be anywhere if its an PKI token or at the place that = issued the credential if it=E2=80=99s something else. When an SP start deve= loping an native app for there services and want=E2=80=99s to use the natio= nal eID solution in combination with OAuth we might run into trouble here.<= /span>

The flow is like follows for a service provider called F= ooBar:

FooBar=E2=80=99s app starts browser-view.=C2=A0Fo= oBar=E2=80=99s SAML service provider functionality redirects the user to an= national SAML IDP. The IDP prompts user for a username and then starts an = mobile eID token on the same phone. Users is asked if they want=E2=80=99s t= o authenticate to FooBar and enters PIN. User are then redirected back with= an assertion. The FooBar's service provider verifies the assertion and= mint=E2=80=99s OAuth2 token(s) and redirects the user back to the app with= the help of the redirect URL.

So the phone first displa= ys an app, then=C2=A0foobar.com=C2=A0in browser-view, then=C2=A0= idp.com<= /span>=C2=A0in=C2=A0browser-view, then mobile eID t= oken, then=C2=A0idp.com=C2=A0in the=C2=A0system br= owser=C2=A0and back to=C2=A0foobar.com=C2=A0and the app that the u= ser wanted to use.

The problem with browser-views is tha= t the mobile eID token will start=C2=A0idp.com=C2=A0when user has authenti= cated and then the user is not back in the apps browser-view, but in system= browser instead. The system browser is sharing the session with the browse= r-view and redirect the user to the native app. The user experience will be= a bit strange then because there the correct page is not loaded and the br= owser-view should be closed and the app should start parsing out the author= ization code instead.

So I think draft should mention so= mething about this scenario and that app developers should handle this scen= ario in the app. The grant did not really come back from the browser-view a= s expected but from the system browser instead.=C2=A0

= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94

With the above in mind. Maybe even some example code wo= uld be nice to have in the non normative section "Appendix A.=C2=A0 Op= erating System Specific Implementation Details=E2=80=9D. Especially how to = handle call backs.

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94

Another eID rela= ted issue is the pricing model for authentications in that market segment. = It=E2=80=99s really common by the eID credential issuing organisations to c= harge a service providers usage of a credential per tick (that is by OSCP c= all). The system is based on a per tick pricing model and there are regulat= ions for how long the sessions can live. That means that its not possible t= o authenticate with a token once and then create a refresh token and the us= er will ever see the authentication flow again. It kinda messes up the usab= ility of mobile apps a lot but end users have come to term with it. They ha= ve not however came to term to always require consents every time they use = the app. That drives end user crazy. The usability would be much better if = the payment model also accepted a refresh token as a tick instead of just a= n OSCP call, but we are not there yet.

Anyway, that=E2= =80=99s the backstory. The section "6.4.=C2=A0 Always Prompting for Us= er Interaction=E2=80=9D is a bit harsh with a=C2=A0SHOULD NOT. I would rath= er change it to a NOT RECOMMENDED.

=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94

<= span>Two additional things that strengthen the case for using the browser-v= iew also come to mind when reading the draft. The first is the fact that mu= ltiple tabs is started in some browser when going through multiple authenti= cation attempts. That clutters the system so I really like the new browser-= views.

The second is that there are additionally nice things i= n browser-view that do not exist in the web-view. The localStorage is also = preserved and it can include important information to make authentication m= ethods more secure.

=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94

"Authorization = servers SHOULD consider taking steps to detect and

block= logins via embedded user-agents that are not their own, where

possible.""


Sou= nds good, but that also sounds very hard when it comes to public clients.= =C2=A0

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94

And some nits:<= /p>


"OAuth flows between a native app = and the system browser (or another

external user-agent) = are more secure, and take advantage of the

shared authen= tication state."


Not really= clear what shared authentication state that is in that sentence.


"When the authentication server comp= letes the request, it redirects to

=C2=A0 =C2=A0the clie= nt's redirection URI like it would any redirect URI"

=

s/authentication/authorization

<= span>

/ Erik



On Thu, Jul 23, 2015 at 6:22 PM,=C2=A0<= oauth-request@i= etf.org>=C2=A0wrote:

John Br= adley and I introduced a new draft at IETF93 yesterday:
https://tools.ietf.org/html/draft-wdenniss-oauth-nati= ve-apps-00


Goal is to provide best practices for native apps= using the RFC6749
authorization
endpoint, expanding on RFC6749 Secti= on 9.=C2=A0 Specifically, it recommends
using an external user-agent (su= ch as the system browser) for this task
over an embedded user-agent (suc= h as a web-view), and suggests ways to
achieve this.


Comments= welcome!
___________________________________= ____________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/o= auth

______________________= _________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailm= an/listinfo/oauth


_______________________________________________=
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
--001a1137c6422ffaee051b9a2b64-- From nobody Fri Jul 24 01:47:55 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B57AB1A1B19 for ; Fri, 24 Jul 2015 01:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.077 X-Spam-Level: * X-Spam-Status: No, score=1.077 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qv1codY_eWHx for ; Fri, 24 Jul 2015 01:47:50 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C22791A1B16 for ; Fri, 24 Jul 2015 01:47:49 -0700 (PDT) Received: by iecri3 with SMTP id ri3so13590923iec.2 for ; Fri, 24 Jul 2015 01:47:49 -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:content-type; bh=Cd6Y8zx33o6QfLjsidP/yZo2RakmX3rcQoEzGVUK6v4=; b=QgjV5qgREEP/Hv+GnMUEHXhzSoSNvGGpnqc+Kr5E3VEf8DkKbcXiqz8eah7Wl9Erui 8EzCR2Um5+1ObBQCaVcFQHpwCRePUfAxJf65D6z6ffbwZFoSnj7pbmptFOx7xG5UBsLP G8tui9Zchu2r/9+TlrD6TjQ1QXJA/t8/42f/I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Cd6Y8zx33o6QfLjsidP/yZo2RakmX3rcQoEzGVUK6v4=; b=MZS2D9b5z4CRT61frfug0OUyu7IutHsXQwFS5DIeKDai6GDmC3IDIpayG0s3o4ObbT aeccMAdk8bBVfFVcSkQbLGUKgG+ZIho+E977Q57kGEz3pq7hDOVrUOIOU70MhH5Dou5s WZq4eMin+qS6CIRpkLTIA7NosBbNxNe7mqWBfMLNzQHt3d7rFieW79yEuJb3fFwaaj+G o4CM4mC13SYLJ10zjrt4dxMSFrnjJof+pSN3ZVF1vJ1ArJ7EfK3h0EZhYvaLfrt8Lbss asYVbj7fJ0rnb+Po8Dmzi+RRtTqWsaW/uaIEhUEqEDi6ahjMbt3rUm0v6pUZq/T0+ebn LyGQ== X-Gm-Message-State: ALoCoQmWlU+3PMVghEB8AABVureVfOusXDQbjuUyhmdSOt8/gdyMdQpGelL6ce9aXw4j0PjhdVKE X-Received: by 10.107.159.66 with SMTP id i63mr21640306ioe.68.1437727669164; Fri, 24 Jul 2015 01:47:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Fri, 24 Jul 2015 01:47:19 -0700 (PDT) In-Reply-To: References: <99C2C652-65E6-42CB-BAD9-0B5D7BD4A90C@ve7jtb.com> <919808A7-B1A8-4CBF-9FD8-447357E18D27@adobe.com> <714BEA65-C2AB-41C7-BA29-51D32BC6B8A0@ve7jtb.com> From: Brian Campbell Date: Fri, 24 Jul 2015 10:47:19 +0200 Message-ID: To: Nat Sakimura Content-Type: multipart/alternative; boundary=001a1141b960013688051b9b0f6e Archived-At: Cc: "oauth@ietf.org" , =?UTF-8?Q?Erik_Wahlstr=C3=B6m?= Subject: Re: [OAUTH-WG] OAuth Digest, Vol 81, Issue 86 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 08:47:54 -0000 --001a1141b960013688051b9b0f6e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable PCKE prevents a bad app from using the code when there's a collision in the custom scheme used for the redirect URI. However the same app could immediately issue a new authorization request with it's own PCKE parameters and (mostly) transparently get back a code that it can use. Having some user interaction via the browser helps mitigate that. 6.4 says that "tokens SHOULD NOT be issued to such [non-confidential] clients without user consent or interaction" so it's not strictly required. Also, FWIW from http://tools.ietf.org/html/rfc2119 SHOULD NOT and NOT RECOMMENDED are effectively synonymous On Fri, Jul 24, 2015 at 9:44 AM, Nat Sakimura wrote: > Prompting is not necessarily is a good thing. > It is very context specific, so please do not make it required. > > Nat > > 2015-07-24 16:38 GMT+09:00 John Bradley : > >> Hi Antonio, >> >> Thanks for the feedback. >> >> I agree that for non confidential clients, the user needs to be prompted= . >> It might be fair to just confirm the grants rather than resetting them >> from defaults. >> >> I know some people are doing that, but I suspect that not everyone is. >> >> Good stuff. >> >> People should chime in with other things we need to consider. >> >> Thanks >> John B. >> >> On Jul 24, 2015, at 9:00 AM, Antonio Sanso wrote: >> >> hi, >> >> nice to see some work on this topic by the way! >> >> Couple of comments below inline >> >> On Jul 24, 2015, at 7:51 AM, John Bradley wrote: >> >> Thanks for the review Erik, >> >> We will go through it in detail and get back to you. >> >> I am working with a couple of governments on how a eID app could use the >> self issued profile of OpenID Connect to issue tokens. >> >> There are also other out of band authentication apps that people use >> that need to be considered. >> >> I think that the callback / redirect_uri can work if a custom scheme URI >> or a app claimed https: URI is used. >> >> >> Is there any example of =E2=80=9Cpopular=E2=80=9D custom scheme. One I h= ave seen is >> urn:ietf:wg:oauth:2.0:oob >> Another common redirect_uri for native app I have seen is >> http://localhost >> >> One more comment. I strongly suggest for mobile app to have a really >> strict consent screen policy. >> Aka the authorization server MUST show the consent screen at every usage >> and not remember the fact that the app has been already authorized. >> >> Just my 2 cents :) >> >> regards >> >> antonio >> >> >> I agree that sniffing the URI in a web view creates a very confusing use= r >> experience at the moment. It works better on Android than iOS 8 but is = not >> smooth in many cases. >> >> I personally use a out of band mobile authenticator for my enterprise >> login that has exactly that problem, and requires me to manually switch >> back to the calling app. >> >> Regards >> John B. >> >> >> >> >> On Jul 24, 2015, at 12:59 AM, Erik Wahlstr=C3=B6m >> wrote: >> >> Hi, >> >> Thanks for a great document! I volunteered to review >> draft-wdenniss-oauth-native-apps-00 at the #IETF93 meeting so here we go= : >> >> In national mobile eID deployments an app is issued by gov or other >> organisation in a country. The app acts as the users authentication meth= od >> and it works with an IDP, the IDP can be anywhere if its an PKI token or= at >> the place that issued the credential if it=E2=80=99s something else. Whe= n an SP >> start developing an native app for there services and want=E2=80=99s to = use the >> national eID solution in combination with OAuth we might run into troubl= e >> here. >> >> The flow is like follows for a service provider called FooBar: >> >> FooBar=E2=80=99s app starts browser-view. FooBar=E2=80=99s SAML service = provider >> functionality redirects the user to an national SAML IDP. The IDP prompt= s >> user for a username and then starts an mobile eID token on the same phon= e. >> Users is asked if they want=E2=80=99s to authenticate to FooBar and ente= rs PIN. >> User are then redirected back with an assertion. The FooBar's service >> provider verifies the assertion and mint=E2=80=99s OAuth2 token(s) and r= edirects >> the user back to the app with the help of the redirect URL. >> >> So the phone first displays an app, then foobar.com in >> browser-view, then idp.com in *browser-view*, >> then mobile eID token, then idp.com in the *sy= stem >> browser* and back to foobar.com and the app that >> the user wanted to use. >> >> The problem with browser-views is that the mobile eID token will start >> idp.com when user has authenticated and then the user is not back in the >> apps browser-view, but in system browser instead. The system browser is >> sharing the session with the browser-view and redirect the user to the >> native app. The user experience will be a bit strange then because there >> the correct page is not loaded and the browser-view should be closed and >> the app should start parsing out the authorization code instead. >> >> So I think draft should mention something about this scenario and that >> app developers should handle this scenario in the app. The grant did not >> really come back from the browser-view as expected but from the system >> browser instead. >> >> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94 >> >> With the above in mind. Maybe even some example code would be nice to >> have in the non normative section "Appendix A. Operating System Specifi= c >> Implementation Details=E2=80=9D. Especially how to handle call backs. >> >> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94 >> >> Another eID related issue is the pricing model for authentications in >> that market segment. It=E2=80=99s really common by the eID credential is= suing >> organisations to charge a service providers usage of a credential per ti= ck >> (that is by OSCP call). The system is based on a per tick pricing model = and >> there are regulations for how long the sessions can live. That means tha= t >> its not possible to authenticate with a token once and then create a >> refresh token and the user will ever see the authentication flow again. = It >> kinda messes up the usability of mobile apps a lot but end users have co= me >> to term with it. They have not however came to term to always require >> consents every time they use the app. That drives end user crazy. The >> usability would be much better if the payment model also accepted a refr= esh >> token as a tick instead of just an OSCP call, but we are not there yet. >> >> Anyway, that=E2=80=99s the backstory. The section "6.4. Always Promptin= g for >> User Interaction=E2=80=9D is a bit harsh with a SHOULD NOT. I would rath= er change >> it to a NOT RECOMMENDED. >> >> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94 >> >> Two additional things that strengthen the case for using the browser-vie= w >> also come to mind when reading the draft. The first is the fact that >> multiple tabs is started in some browser when going through multiple >> authentication attempts. That clutters the system so I really like the n= ew >> browser-views. >> >> The second is that there are additionally nice things in browser-view >> that do not exist in the web-view. The localStorage is also preserved an= d >> it can include important information to make authentication methods more >> secure. >> >> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 >> >> "Authorization servers SHOULD consider taking steps to detect and >> >> block logins via embedded user-agents that are not their own, where >> >> possible."" >> >> >> Sounds good, but that also sounds very hard when it comes to public >> clients. >> >> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94 >> >> And some nits: >> >> >> "OAuth flows between a native app and the system browser (or another >> >> external user-agent) are more secure, and take advantage of the >> >> shared authentication state." >> >> >> Not really clear what shared authentication state that is in that >> sentence. >> >> >> "When the authentication server completes the request, it redirects to >> >> the client's redirection URI like it would any redirect URI" >> >> >> s/authentication/authorization >> >> >> / Erik >> >> >> >> >> On Thu, Jul 23, 2015 at 6:22 PM, wrote: >>> >>> >>> John Bradley and I introduced a new draft at IETF93 yesterday: >>> https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00 >>> >>> >>> Goal is to provide best practices for native apps using the RFC6749 >>> authorization >>> endpoint, expanding on RFC6749 Section 9. Specifically, it recommends >>> using an external user-agent (such as the system browser) for this task >>> over an embedded user-agent (such as a web-view), and suggests ways to >>> achieve this. >>> >>> >>> Comments welcome! >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a1141b960013688051b9b0f6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
PCKE prevents a bad app from using the code when ther= e's a collision in the custom scheme used for the redirect URI. However= the same app could immediately issue a new authorization request with it&#= 39;s own PCKE parameters and (mostly) transparently get back a code that it= can use. Having some user interaction via the browser helps mitigate that.= =C2=A0

6.4 says that "tokens SHOULD NOT be issued to suc= h [non-confidential] clients without user consent or interaction" so i= t's not strictly required.

Also, FWIW from http://tools.ietf.org/html/rfc2119 SHOULD NO= T and NOT RECOMMENDED are effectively synonymous

On Fri, Jul 24, 2015 at 9:44 AM, = Nat Sakimura <sakimura@gmail.com> wrote:
Prompting is not necessarily is a good thi= ng.=C2=A0
It is very context specific, so please do not make it require= d.=C2=A0

Nat

2015-07-24 16:38 GMT= +09:00 John Bradley <ve7jtb@ve7jtb.com>:
Hi Antonio,

Thanks for the feedback.

I agree that for n= on confidential clients, the user needs to be prompted. =C2=A0 It might be = fair to just confirm the grants rather than resetting them from defaults.

I know some people are doing that, but I suspect th= at not everyone is.

Good stuff.

People should chime in with other things we need to consider.
<= div>
Thanks
John B.

On Jul 24, 2015, at 9:00 AM, Antonio Sanso <asanso@adobe.com>= wrote:

hi,

nice to see some= work on this topic by the way!

= Couple of comments below inline

On Jul 24, 2015, at 7:51 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Thanks for the re= view Erik,

We will go through it in detail and get back = to you.

I am working with a couple of governments = on how a eID app could use the self issued profile of OpenID Connect to iss= ue tokens.

There are also other out of band authen= tication =C2=A0apps that people use that need to be considered.
<= br>
I think that the callback / redirect_uri can work if a custom= scheme URI or a app claimed https: URI is used.

Is there any example of =E2=80=9Cpopular=E2=80=9D custom = scheme. One I have seen is urn:ietf:wg:oauth:2.0:oob=C2=A0
Another common redirect_uri for native app I have seen is=C2=A0http://localhost

One more comment. I strongly suggest =C2=A0f= or mobile app to have a really strict consent screen policy.
Aka = the authorization server MUST show the consent screen at every usage and no= t remember the fact that the app has been already authorized.
Just my 2 cents :)

regards
<= br>
antonio=C2=A0


I agree that sniffing the URI= in a web view creates a very confusing user experience at the moment.=C2= =A0 It works better on Android than iOS 8 but is not smooth in many cases.<= /div>

I personally use a out of band mobile authenticato= r for my enterprise login that has exactly that problem, and requires me to= manually switch back to the calling app.

Regards<= /div>
John B.



On Jul 24, 2015, at 12:59 AM, Erik Wa= hlstr=C3=B6m <erik@wahlstromstekniska.se> wrote:

Hi,

Thanks for a great document! I voluntee= red to review draft-wdenniss-oauth-native-apps-00 at the #IETF93 meeting so= here we go:


In national mob= ile eID deployments an app is issued by gov or other organisation in a coun= try. The app acts as the users authentication method and it works with an I= DP, the IDP can be anywhere if its an PKI token or at the place that issued= the credential if it=E2=80=99s something else. When an SP start developing= an native app for there services and want=E2=80=99s to use the national eI= D solution in combination with OAuth we might run into trouble here.=

The flow is like follows for a service provider called FooBar:=

FooBar=E2=80=99s app starts browser-view.=C2=A0FooBar= =E2=80=99s SAML service provider functionality redirects the user to an nat= ional SAML IDP. The IDP prompts user for a username and then starts an mobi= le eID token on the same phone. Users is asked if they want=E2=80=99s to au= thenticate to FooBar and enters PIN. User are then redirected back with an = assertion. The FooBar's service provider verifies the assertion and min= t=E2=80=99s OAuth2 token(s) and redirects the user back to the app with the= help of the redirect URL.

So the phone first displays a= n app, then=C2=A0foobar.com=C2=A0in browser-view, then=C2=A0idp.com=C2=A0in=C2=A0browser-view, then mobile eID token= , then=C2=A0idp.com=C2=A0in the=C2=A0system browse= r=C2=A0and back to=C2=A0foobar.com=C2=A0and the app that the user = wanted to use.

The problem with browser-views is that th= e mobile eID token will start=C2=A0idp.com=C2=A0when user has authenticate= d and then the user is not back in the apps browser-view, but in system bro= wser instead. The system browser is sharing the session with the browser-vi= ew and redirect the user to the native app. The user experience will be a b= it strange then because there the correct page is not loaded and the browse= r-view should be closed and the app should start parsing out the authorizat= ion code instead.

So I think draft should mention someth= ing about this scenario and that app developers should handle this scenario= in the app. The grant did not really come back from the browser-view as ex= pected but from the system browser instead.=C2=A0

=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=

With the above in mind. Maybe even some example code would be= nice to have in the non normative section "Appendix A.=C2=A0 Operatin= g System Specific Implementation Details=E2=80=9D. Especially how to handle= call backs.

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94

Another eID related is= sue is the pricing model for authentications in that market segment. It=E2= =80=99s really common by the eID credential issuing organisations to charge= a service providers usage of a credential per tick (that is by OSCP call).= The system is based on a per tick pricing model and there are regulations = for how long the sessions can live. That means that its not possible to aut= henticate with a token once and then create a refresh token and the user wi= ll ever see the authentication flow again. It kinda messes up the usability= of mobile apps a lot but end users have come to term with it. They have no= t however came to term to always require consents every time they use the a= pp. That drives end user crazy. The usability would be much better if the p= ayment model also accepted a refresh token as a tick instead of just an OSC= P call, but we are not there yet.

Anyway, that=E2=80=99s= the backstory. The section "6.4.=C2=A0 Always Prompting for User Inte= raction=E2=80=9D is a bit harsh with a=C2=A0SHOULD NOT. I would rather chan= ge it to a NOT RECOMMENDED.

=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94

T= wo additional things that strengthen the case for using the browser-view al= so come to mind when reading the draft. The first is the fact that multiple= tabs is started in some browser when going through multiple authentication= attempts. That clutters the system so I really like the new browser-views.=

The second is that there are additionally nice things in brow= ser-view that do not exist in the web-view. The localStorage is also preser= ved and it can include important information to make authentication methods= more secure.

=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94

"Authorization server= s SHOULD consider taking steps to detect and

block login= s via embedded user-agents that are not their own, where

possible.""


Sounds go= od, but that also sounds very hard when it comes to public clients.=C2=A0

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94

And some nits:


"OAuth flows between a native app and the s= ystem browser (or another

external user-agent) are more = secure, and take advantage of the

shared authentication = state."


Not really clear wh= at shared authentication state that is in that sentence.


"When the authentication server completes the= request, it redirects to

=C2=A0 =C2=A0the client's = redirection URI like it would any redirect URI"


s/authentication/authorization


/ Erik



<= /span>


On Thu,= Jul 23, 2015 at 6:22 PM,=C2=A0<oauth-request@ietf.org= >=C2=A0wrote:

John Bradley a= nd I introduced a new draft at IETF93 yesterday:
https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps= -00


Goal is to provide best practices for native apps using = the RFC6749
authorization
endpoint, expanding on RFC6749 Section 9.= =C2=A0 Specifically, it recommends
using an external user-agent (such as= the system browser) for this task
over an embedded user-agent (such as = a web-view), and suggests ways to
achieve this.


Comments welc= ome!
________________________________________= _______
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oaut= h

_________________________= ______________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/= listinfo/oauth
<= /div>

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




--
Nat Sakimura (=3Dna= t)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--001a1141b960013688051b9b0f6e-- From nobody Fri Jul 24 03:28:04 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B43A1A89B4 for ; Fri, 24 Jul 2015 03:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVY_Md42yB2z for ; Fri, 24 Jul 2015 03:27:58 -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 2B89F1A8A39 for ; Fri, 24 Jul 2015 03:27:58 -0700 (PDT) Received: by obre1 with SMTP id e1so13681718obr.1 for ; Fri, 24 Jul 2015 03:27:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FiB06CYv49/a/EGe5dsfvkwAmWUVpFJON7dfnaOTbg8=; b=Z7l2HxDwerB7Hf1Z0t5KdaeaC7ZVn2LrQgK5aLWTDiMeUjTFrGlsDsfKU6QlTbTjWZ MjbiYb0TxXXiMOjYVdjq+ZR6kCiL1jMYisjcG2PrP+OTzxPsV4lectOg26Nhx6aZCmZZ ao4+wiLFvSRsRWYyoKJla1C2kIacsn9o9mJkrPGT3AVGvFcIfWVFDyFEHvoYO067kE3T Dq/V3XqQczjquzNe3ctFPqFoNbHlJMpEQlE8qbfepZhaOptZxrWJ4I+RKxtwPoLb7FN+ vChwWP2mOA0dOUKoCHhsozRqQj7H8nsI936Hjj/iMkIqccO0S2vy55kpkCPRimNs41Af 0JMQ== MIME-Version: 1.0 X-Received: by 10.60.56.35 with SMTP id x3mr14704660oep.65.1437733677626; Fri, 24 Jul 2015 03:27:57 -0700 (PDT) Received: by 10.182.96.66 with HTTP; Fri, 24 Jul 2015 03:27:57 -0700 (PDT) In-Reply-To: References: <99C2C652-65E6-42CB-BAD9-0B5D7BD4A90C@ve7jtb.com> <919808A7-B1A8-4CBF-9FD8-447357E18D27@adobe.com> <714BEA65-C2AB-41C7-BA29-51D32BC6B8A0@ve7jtb.com> Date: Fri, 24 Jul 2015 19:27:57 +0900 Message-ID: From: Nat Sakimura To: Brian Campbell Content-Type: multipart/alternative; boundary=001a11c21dec22feec051b9c7552 Archived-At: Cc: "oauth@ietf.org" , =?UTF-8?Q?Erik_Wahlstr=C3=B6m?= Subject: Re: [OAUTH-WG] OAuth Digest, Vol 81, Issue 86 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 10:28:02 -0000 --001a11c21dec22feec051b9c7552 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Right, SHOULD NOT is fine. I am just asking not to make it a MUST NOT. 2015-07-24 17:47 GMT+09:00 Brian Campbell : > PCKE prevents a bad app from using the code when there's a collision in > the custom scheme used for the redirect URI. However the same app could > immediately issue a new authorization request with it's own PCKE paramete= rs > and (mostly) transparently get back a code that it can use. Having some > user interaction via the browser helps mitigate that. > > 6.4 says that "tokens SHOULD NOT be issued to such [non-confidential] > clients without user consent or interaction" so it's not strictly require= d. > > Also, FWIW from http://tools.ietf.org/html/rfc2119 SHOULD NOT and NOT > RECOMMENDED are effectively synonymous > > On Fri, Jul 24, 2015 at 9:44 AM, Nat Sakimura wrote: > >> Prompting is not necessarily is a good thing. >> It is very context specific, so please do not make it required. >> >> Nat >> >> 2015-07-24 16:38 GMT+09:00 John Bradley : >> >>> Hi Antonio, >>> >>> Thanks for the feedback. >>> >>> I agree that for non confidential clients, the user needs to be >>> prompted. It might be fair to just confirm the grants rather than >>> resetting them from defaults. >>> >>> I know some people are doing that, but I suspect that not everyone is. >>> >>> Good stuff. >>> >>> People should chime in with other things we need to consider. >>> >>> Thanks >>> John B. >>> >>> On Jul 24, 2015, at 9:00 AM, Antonio Sanso wrote: >>> >>> hi, >>> >>> nice to see some work on this topic by the way! >>> >>> Couple of comments below inline >>> >>> On Jul 24, 2015, at 7:51 AM, John Bradley wrote: >>> >>> Thanks for the review Erik, >>> >>> We will go through it in detail and get back to you. >>> >>> I am working with a couple of governments on how a eID app could use th= e >>> self issued profile of OpenID Connect to issue tokens. >>> >>> There are also other out of band authentication apps that people use >>> that need to be considered. >>> >>> I think that the callback / redirect_uri can work if a custom scheme UR= I >>> or a app claimed https: URI is used. >>> >>> >>> Is there any example of =E2=80=9Cpopular=E2=80=9D custom scheme. One I = have seen is >>> urn:ietf:wg:oauth:2.0:oob >>> Another common redirect_uri for native app I have seen is >>> http://localhost >>> >>> One more comment. I strongly suggest for mobile app to have a really >>> strict consent screen policy. >>> Aka the authorization server MUST show the consent screen at every usag= e >>> and not remember the fact that the app has been already authorized. >>> >>> Just my 2 cents :) >>> >>> regards >>> >>> antonio >>> >>> >>> I agree that sniffing the URI in a web view creates a very confusing >>> user experience at the moment. It works better on Android than iOS 8 b= ut >>> is not smooth in many cases. >>> >>> I personally use a out of band mobile authenticator for my enterprise >>> login that has exactly that problem, and requires me to manually switch >>> back to the calling app. >>> >>> Regards >>> John B. >>> >>> >>> >>> >>> On Jul 24, 2015, at 12:59 AM, Erik Wahlstr=C3=B6m >>> wrote: >>> >>> Hi, >>> >>> Thanks for a great document! I volunteered to review >>> draft-wdenniss-oauth-native-apps-00 at the #IETF93 meeting so here we g= o: >>> >>> In national mobile eID deployments an app is issued by gov or other >>> organisation in a country. The app acts as the users authentication met= hod >>> and it works with an IDP, the IDP can be anywhere if its an PKI token o= r at >>> the place that issued the credential if it=E2=80=99s something else. Wh= en an SP >>> start developing an native app for there services and want=E2=80=99s to= use the >>> national eID solution in combination with OAuth we might run into troub= le >>> here. >>> >>> The flow is like follows for a service provider called FooBar: >>> >>> FooBar=E2=80=99s app starts browser-view. FooBar=E2=80=99s SAML service= provider >>> functionality redirects the user to an national SAML IDP. The IDP promp= ts >>> user for a username and then starts an mobile eID token on the same pho= ne. >>> Users is asked if they want=E2=80=99s to authenticate to FooBar and ent= ers PIN. >>> User are then redirected back with an assertion. The FooBar's service >>> provider verifies the assertion and mint=E2=80=99s OAuth2 token(s) and = redirects >>> the user back to the app with the help of the redirect URL. >>> >>> So the phone first displays an app, then foobar.com >>> in browser-view, then idp.com >>> in *browser-view*, then mobile eID token, the= n >>> idp.com in the *system browser* and back to >>> foobar.com and the app that the user wanted to >>> use. >>> >>> The problem with browser-views is that the mobile eID token will start >>> idp.com when user has authenticated and then the user is not back in >>> the apps browser-view, but in system browser instead. The system browse= r is >>> sharing the session with the browser-view and redirect the user to the >>> native app. The user experience will be a bit strange then because ther= e >>> the correct page is not loaded and the browser-view should be closed an= d >>> the app should start parsing out the authorization code instead. >>> >>> So I think draft should mention something about this scenario and that >>> app developers should handle this scenario in the app. The grant did no= t >>> really come back from the browser-view as expected but from the system >>> browser instead. >>> >>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94 >>> >>> With the above in mind. Maybe even some example code would be nice to >>> have in the non normative section "Appendix A. Operating System Specif= ic >>> Implementation Details=E2=80=9D. Especially how to handle call backs. >>> >>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94 >>> >>> Another eID related issue is the pricing model for authentications in >>> that market segment. It=E2=80=99s really common by the eID credential i= ssuing >>> organisations to charge a service providers usage of a credential per t= ick >>> (that is by OSCP call). The system is based on a per tick pricing model= and >>> there are regulations for how long the sessions can live. That means th= at >>> its not possible to authenticate with a token once and then create a >>> refresh token and the user will ever see the authentication flow again.= It >>> kinda messes up the usability of mobile apps a lot but end users have c= ome >>> to term with it. They have not however came to term to always require >>> consents every time they use the app. That drives end user crazy. The >>> usability would be much better if the payment model also accepted a ref= resh >>> token as a tick instead of just an OSCP call, but we are not there yet. >>> >>> Anyway, that=E2=80=99s the backstory. The section "6.4. Always Prompti= ng for >>> User Interaction=E2=80=9D is a bit harsh with a SHOULD NOT. I would rat= her change >>> it to a NOT RECOMMENDED. >>> >>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94 >>> >>> Two additional things that strengthen the case for using the >>> browser-view also come to mind when reading the draft. The first is the >>> fact that multiple tabs is started in some browser when going through >>> multiple authentication attempts. That clutters the system so I really = like >>> the new browser-views. >>> >>> The second is that there are additionally nice things in browser-view >>> that do not exist in the web-view. The localStorage is also preserved a= nd >>> it can include important information to make authentication methods mor= e >>> secure. >>> >>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94 >>> >>> "Authorization servers SHOULD consider taking steps to detect and >>> >>> block logins via embedded user-agents that are not their own, where >>> >>> possible."" >>> >>> >>> Sounds good, but that also sounds very hard when it comes to public >>> clients. >>> >>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94 >>> >>> And some nits: >>> >>> >>> "OAuth flows between a native app and the system browser (or another >>> >>> external user-agent) are more secure, and take advantage of the >>> >>> shared authentication state." >>> >>> >>> Not really clear what shared authentication state that is in that >>> sentence. >>> >>> >>> "When the authentication server completes the request, it redirects to >>> >>> the client's redirection URI like it would any redirect URI" >>> >>> >>> s/authentication/authorization >>> >>> >>> / Erik >>> >>> >>> >>> >>> On Thu, Jul 23, 2015 at 6:22 PM, wrote: >>>> >>>> >>>> John Bradley and I introduced a new draft at IETF93 yesterday: >>>> https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00 >>>> >>>> >>>> Goal is to provide best practices for native apps using the RFC6749 >>>> authorization >>>> endpoint, expanding on RFC6749 Section 9. Specifically, it recommends >>>> using an external user-agent (such as the system browser) for this tas= k >>>> over an embedded user-agent (such as a web-view), and suggests ways to >>>> achieve this. >>>> >>>> >>>> Comments welcome! >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> >> -- >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c21dec22feec051b9c7552 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Right, SHOULD NOT is fine. I am just asking not to make it= a MUST NOT.=C2=A0

2015-07-24 17:47 GMT+09:00 Brian Campbell <bcampbell@pingi= dentity.com>:
PCKE prevents a bad app from using the code when there's a col= lision in the custom scheme used for the redirect URI. However the same app= could immediately issue a new authorization request with it's own PCKE= parameters and (mostly) transparently get back a code that it can use. Hav= ing some user interaction via the browser helps mitigate that.=C2=A0
6.4 says that "tokens SHOULD NOT be issued to such [non-confid= ential] clients without user consent or interaction" so it's not s= trictly required.

Also, FWIW from http://tools.ietf.org/html/rfc2119 SHOU= LD NOT and NOT RECOMMENDED are effectively synonymous

On Fri, Jul 24, 2015 at 9:44 AM, Nat Sakimura <sakimura@gmai= l.com> wrote:
Prompting is not necessarily is a good thing.=C2=A0
It is very cont= ext specific, so please do not make it required.=C2=A0

=
Nat

2015-07-24 16:38 GMT+09:00 John Bradley <= ve7jtb@ve7jtb.com>:
Hi Antonio,

Thanks for the feedback.
=
I agree that for non confidential clients, the user needs to= be prompted. =C2=A0 It might be fair to just confirm the grants rather tha= n resetting them from defaults.

I know some people= are doing that, but I suspect that not everyone is.

Good stuff.

People should chime in with other t= hings we need to consider.

Thanks
John B= .


hi,

nice to see some work on this topic by the way!

Couple of comments below inline

On Jul 24, 2015, at 7:51 AM, John Bradl= ey <ve7jtb@ve7jtb= .com> wrote:

Thanks for the review Erik,

We will go t= hrough it in detail and get back to you.

I am work= ing with a couple of governments on how a eID app could use the self issued= profile of OpenID Connect to issue tokens.

There = are also other out of band authentication =C2=A0apps that people use that n= eed to be considered.

I think that the callback / = redirect_uri can work if a custom scheme URI or a app claimed https: URI is= used.

Is there any example of = =E2=80=9Cpopular=E2=80=9D custom scheme. One I have seen is urn:ietf:wg:oau= th:2.0:oob=C2=A0
Another common redirect_uri for native ap= p I have seen is=C2=A0http://localhost

One more co= mment. I strongly suggest =C2=A0for mobile app to have a really strict cons= ent screen policy.
Aka the authorization server MUST show the con= sent screen at every usage and not remember the fact that the app has been = already authorized.

Just my 2 cents :)
<= br>
regards

antonio=C2=A0


I agree that sniffing the URI in a web view creates a very confusing user= experience at the moment.=C2=A0 It works better on Android than iOS 8 but = is not smooth in many cases.

I personally use a ou= t of band mobile authenticator for my enterprise login that has exactly tha= t problem, and requires me to manually switch back to the calling app.

Regards
John B.



On Jul 2= 4, 2015, at 12:59 AM, Erik Wahlstr=C3=B6m <erik@wahlstromstekniska.se> wrote= :

Hi,

Thanks for= a great document! I volunteered to review draft-wdenniss-oauth-native-apps= -00 at the #IETF93 meeting so here we go:


<= /div>

In national mobile eID deployments an app is issued by gov or= other organisation in a country. The app acts as the users authentication = method and it works with an IDP, the IDP can be anywhere if its an PKI toke= n or at the place that issued the credential if it=E2=80=99s something else= . When an SP start developing an native app for there services and want=E2= =80=99s to use the national eID solution in combination with OAuth we might= run into trouble here.

The flow is like follows for a s= ervice provider called FooBar:

FooBar=E2=80=99s app star= ts browser-view.=C2=A0FooBar=E2=80=99s SAML service provider functionality = redirects the user to an national SAML IDP. The IDP prompts user for a user= name and then starts an mobile eID token on the same phone. Users is asked = if they want=E2=80=99s to authenticate to FooBar and enters PIN. User are t= hen redirected back with an assertion. The FooBar's service provider ve= rifies the assertion and mint=E2=80=99s OAuth2 token(s) and redirects the u= ser back to the app with the help of the redirect URL.

S= o the phone first displays an app, then=C2=A0foobar.com=C2=A0in browse= r-view, then=C2=A0idp.com=C2=A0in=C2=A0browser-v= iew, then mobile eID token, then=C2=A0idp.com=C2=A0in the=C2=A0system browser=C2=A0and back to=C2=A0foobar.com= =C2=A0and the app that the user wanted to use.

The probl= em with browser-views is that the mobile eID token will start=C2=A0idp.com= =C2=A0when user has authenticated and then the user is not back in the apps= browser-view, but in system browser instead. The system browser is sharing= the session with the browser-view and redirect the user to the native app.= The user experience will be a bit strange then because there the correct p= age is not loaded and the browser-view should be closed and the app should = start parsing out the authorization code instead.

So I t= hink draft should mention something about this scenario and that app develo= pers should handle this scenario in the app. The grant did not really come = back from the browser-view as expected but from the system browser instead.= =C2=A0

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94

With the above in mind. Mayb= e even some example code would be nice to have in the non normative section= "Appendix A.=C2=A0 Operating System Specific Implementation Details= =E2=80=9D. Especially how to handle call backs.

=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94

Another eID related issue is the pricing model for authenticatio= ns in that market segment. It=E2=80=99s really common by the eID credential= issuing organisations to charge a service providers usage of a credential = per tick (that is by OSCP call). The system is based on a per tick pricing = model and there are regulations for how long the sessions can live. That me= ans that its not possible to authenticate with a token once and then create= a refresh token and the user will ever see the authentication flow again. = It kinda messes up the usability of mobile apps a lot but end users have co= me to term with it. They have not however came to term to always require co= nsents every time they use the app. That drives end user crazy. The usabili= ty would be much better if the payment model also accepted a refresh token = as a tick instead of just an OSCP call, but we are not there yet.

Anyway, that=E2=80=99s the backstory. The section "6.4.=C2= =A0 Always Prompting for User Interaction=E2=80=9D is a bit harsh with a=C2= =A0SHOULD NOT. I would rather change it to a NOT RECOMMENDED.

= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94

Two additional things that strengthen the c= ase for using the browser-view also come to mind when reading the draft. Th= e first is the fact that multiple tabs is started in some browser when goin= g through multiple authentication attempts. That clutters the system so I r= eally like the new browser-views.

The second is that there are= additionally nice things in browser-view that do not exist in the web-view= . The localStorage is also preserved and it can include important informati= on to make authentication methods more secure.

=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94

"Authorization servers SHOULD consider taking steps to detect a= nd

block logins via embedded user-agents that are not th= eir own, where

possible.""

=

Sounds good, but that also sounds very hard when it= comes to public clients.=C2=A0

=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94

And some nits:


"OAuth flo= ws between a native app and the system browser (or another

external user-agent) are more secure, and take advantage of the

shared authentication state."

Not really clear what shared authentication state that is in = that sentence.


"When the au= thentication server completes the request, it redirects to

=C2=A0 =C2=A0the client's redirection URI like it would any redirect= URI"


s/authentication/auth= orization


/ Erik




<= div class=3D"gmail_quote">On Thu, Jul 23, 2015 at 6:22 PM,=C2=A0<oauth-request@ietf.org>=C2=A0wrote:
John Bradley and I introduced a new draft at IETF93 yester= day:
https://tools.ietf.org/html/d= raft-wdenniss-oauth-native-apps-00


Goal is to provide best p= ractices for native apps using the RFC6749
authorization
endpoint, ex= panding on RFC6749 Section 9.=C2=A0 Specifically, it recommends
using an= external user-agent (such as the system browser) for this task
over an = embedded user-agent (such as a web-view), and suggests ways to
achieve t= his.


Comments welcome!
___________= ____________________________________
OAuth mailing list
OAuth@ietf.org
https://www.iet= f.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
= OAuth@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/oauth


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




--
Nat Sakimura (=3Dnat)
Chairman, = OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth





--
=
Nat Sakimura (=3Dnat)
Chairman, OpenID F= oundation
http://= nat.sakimura.org/
@_nat_en
--001a11c21dec22feec051b9c7552-- From nobody Fri Jul 24 04:17:11 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1CD1A8A11 for ; Fri, 24 Jul 2015 04:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InLnBrx_N7f3 for ; Fri, 24 Jul 2015 04:17:05 -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 4B4C81A901F for ; Fri, 24 Jul 2015 04:16:43 -0700 (PDT) Received: by iggf3 with SMTP id f3so13932164igg.1 for ; Fri, 24 Jul 2015 04:16:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=rAJ3PYJ6GE42qQ5Ujg9etxl+7+2rcin1sZjZ6n8F0Kc=; b=w7rb0evEugxqSPzNCbgx620qKNXvLwgDg9CgfjptoLy5zZb5s0HtAe1JrCFiQvJZIb NbGTpqB7MEizEfJU7weE3eG9KD3rRsBftD/slOe9sLFXrb6Mx3cR/8qn4WYgSx+mTLwr Iwi5bW8Qu2KyBSZEFyibEsCC4Bs7TO2vogzV+dTyxF2jwwEyGh0NAMJJBZ6BjBccrbtC 7jkOjrezW01oePNNJfQ7X/d/wHmKfupwNefmWMgcrcnnJcFF4tEwz8n31hQCVIkq+L3a M8jRPQxphef7wwG+GnUkGD/MIX4hiCp6ArMl5wGL5EmCENdO/0/fQZGA3B5iPvfqO/h7 uAIw== X-Received: by 10.50.20.135 with SMTP id n7mr5265006ige.58.1437736602754; Fri, 24 Jul 2015 04:16:42 -0700 (PDT) Received: from [192.168.0.104] ([199.167.110.10]) by smtp.googlemail.com with ESMTPSA id h20sm1338598igq.15.2015.07.24.04.16.41 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Jul 2015 04:16:41 -0700 (PDT) Message-ID: <55B21E98.6020802@gmail.com> Date: Fri, 24 Jul 2015 07:16:40 -0400 From: Paul Madsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: oauth@ietf.org References: <99C2C652-65E6-42CB-BAD9-0B5D7BD4A90C@ve7jtb.com> <919808A7-B1A8-4CBF-9FD8-447357E18D27@adobe.com> In-Reply-To: <919808A7-B1A8-4CBF-9FD8-447357E18D27@adobe.com> Content-Type: multipart/alternative; boundary="------------000606000709000308040108" Archived-At: Subject: Re: [OAUTH-WG] OAuth Digest, Vol 81, Issue 86 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 11:17:09 -0000 This is a multi-part message in MIME format. --------------000606000709000308040108 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Antonio, are you arguing for short token lifetimes and so frequent explicit consent ? or something more if the app has a valid refresh token then there is no opportunity for the AS to inject a consent screen paul On 7/24/15 3:00 AM, Antonio Sanso wrote: > hi, > > nice to see some work on this topic by the way! > > Couple of comments below inline > > On Jul 24, 2015, at 7:51 AM, John Bradley > wrote: > >> Thanks for the review Erik, >> >> We will go through it in detail and get back to you. >> >> I am working with a couple of governments on how a eID app could use >> the self issued profile of OpenID Connect to issue tokens. >> >> There are also other out of band authentication apps that people use >> that need to be considered. >> >> I think that the callback / redirect_uri can work if a custom scheme >> URI or a app claimed https: URI is used. > > Is there any example of “popular” custom scheme. One I have seen is > urn:ietf:wg:oauth:2.0:oob > Another common redirect_uri for native app I have seen is > http://localhost > > One more comment. I strongly suggest for mobile app to have a really > strict consent screen policy. > Aka the authorization server MUST show the consent screen at every > usage and not remember the fact that the app has been already authorized. > > Just my 2 cents :) > > regards > > antonio > >> >> I agree that sniffing the URI in a web view creates a very confusing >> user experience at the moment. It works better on Android than iOS 8 >> but is not smooth in many cases. >> >> I personally use a out of band mobile authenticator for my enterprise >> login that has exactly that problem, and requires me to manually >> switch back to the calling app. >> >> Regards >> John B. >> >> >> >> >>> On Jul 24, 2015, at 12:59 AM, Erik Wahlström >>> > wrote: >>> >>> Hi, >>> >>> Thanks for a great document! I volunteered to review >>> draft-wdenniss-oauth-native-apps-00 at the #IETF93 meeting so here >>> we go: >>> >>> >>> In national mobile eID deployments an app is issued by gov or other >>> organisation in a country. The app acts as the users authentication >>> method and it works with an IDP, the IDP can be anywhere if its an >>> PKI token or at the place that issued the credential if it’s >>> something else. When an SP start developing an native app for there >>> services and want’s to use the national eID solution in combination >>> with OAuth we might run into trouble here. >>> >>> The flow is like follows for a service provider called FooBar: >>> >>> FooBar’s app starts browser-view. FooBar’s SAML service provider >>> functionality redirects the user to an national SAML IDP. The IDP >>> prompts user for a username and then starts an mobile eID token on >>> the same phone. Users is asked if they want’s to authenticate to >>> FooBar and enters PIN. User are then redirected back with an >>> assertion. The FooBar's service provider verifies the assertion and >>> mint’s OAuth2 token(s) and redirects the user back to the app with >>> the help of the redirect URL. >>> >>> So the phone first displays an app, then foobar.com >>> in browser-view, then idp.com >>> in *browser-view*, then mobile eID token, >>> then idp.com in the *system browser* and >>> back to foobar.com and the app that the user >>> wanted to use. >>> >>> The problem with browser-views is that the mobile eID token will >>> start idp.com when user has authenticated and then >>> the user is not back in the apps browser-view, but in system browser >>> instead. The system browser is sharing the session with the >>> browser-view and redirect the user to the native app. The user >>> experience will be a bit strange then because there the correct page >>> is not loaded and the browser-view should be closed and the app >>> should start parsing out the authorization code instead. >>> >>> So I think draft should mention something about this scenario and >>> that app developers should handle this scenario in the app. The >>> grant did not really come back from the browser-view as expected but >>> from the system browser instead. >>> >>> ————————— >>> >>> With the above in mind. Maybe even some example code would be nice >>> to have in the non normative section "Appendix A. Operating System >>> Specific Implementation Details”. Especially how to handle call backs. >>> >>> ————————— >>> >>> Another eID related issue is the pricing model for authentications >>> in that market segment. It’s really common by the eID credential >>> issuing organisations to charge a service providers usage of a >>> credential per tick (that is by OSCP call). The system is based on a >>> per tick pricing model and there are regulations for how long the >>> sessions can live. That means that its not possible to authenticate >>> with a token once and then create a refresh token and the user will >>> ever see the authentication flow again. It kinda messes up the >>> usability of mobile apps a lot but end users have come to term with >>> it. They have not however came to term to always require consents >>> every time they use the app. That drives end user crazy. The >>> usability would be much better if the payment model also accepted a >>> refresh token as a tick instead of just an OSCP call, but we are not >>> there yet. >>> >>> Anyway, that’s the backstory. The section "6.4. Always Prompting >>> for User Interaction” is a bit harsh with a SHOULD NOT. I would >>> rather change it to a NOT RECOMMENDED. >>> >>> ————————— >>> >>> Two additional things that strengthen the case for using the >>> browser-view also come to mind when reading the draft. The first is >>> the fact that multiple tabs is started in some browser when going >>> through multiple authentication attempts. That clutters the system >>> so I really like the new browser-views. >>> >>> The second is that there are additionally nice things in >>> browser-view that do not exist in the web-view. The localStorage is >>> also preserved and it can include important information to make >>> authentication methods more secure. >>> >>> ———————— >>> >>> "Authorization servers SHOULD consider taking steps to detect and >>> >>> block logins via embedded user-agents that are not their own, where >>> >>> possible."" >>> >>> >>> Sounds good, but that also sounds very hard when it comes to public >>> clients. >>> >>> ————————— >>> >>> And some nits: >>> >>> >>> "OAuth flows between a native app and the system browser (or another >>> >>> external user-agent) are more secure, and take advantage of the >>> >>> shared authentication state." >>> >>> >>> Not really clear what shared authentication state that is in that >>> sentence. >>> >>> >>> "When the authentication server completes the request, it redirects to >>> >>> the client's redirection URI like it would any redirect URI" >>> >>> >>> s/authentication/authorization >>> >>> >>> / Erik >>> >>> >>> >>> >>> On Thu, Jul 23, 2015 at 6:22 PM, >> > wrote: >>> >>> >>> John Bradley and I introduced a new draft at IETF93 yesterday: >>> https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00 >>> >>> >>> Goal is to provide best practices for native apps using the RFC6749 >>> authorization >>> endpoint, expanding on RFC6749 Section 9. Specifically, it >>> recommends >>> using an external user-agent (such as the system browser) for >>> this task >>> over an embedded user-agent (such as a web-view), and suggests >>> ways to >>> achieve this. >>> >>> >>> Comments welcome! >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@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 --------------000606000709000308040108 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Antonio, are you arguing for short token lifetimes and so frequent explicit consent ? or something more

if the app has a valid refresh token then there is no opportunity for the AS to inject a consent screen

paul

On 7/24/15 3:00 AM, Antonio Sanso wrote:
hi,

nice to see some work on this topic by the way!

Couple of comments below inline

On Jul 24, 2015, at 7:51 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Thanks for the review Erik,

We will go through it in detail and get back to you.

I am working with a couple of governments on how a eID app could use the self issued profile of OpenID Connect to issue tokens.

There are also other out of band authentication  apps that people use that need to be considered.

I think that the callback / redirect_uri can work if a custom scheme URI or a app claimed https: URI is used.

Is there any example of “popular” custom scheme. One I have seen is urn:ietf:wg:oauth:2.0:oob 
Another common redirect_uri for native app I have seen is http://localhost

One more comment. I strongly suggest  for mobile app to have a really strict consent screen policy.
Aka the authorization server MUST show the consent screen at every usage and not remember the fact that the app has been already authorized.

Just my 2 cents :)

regards

antonio 


I agree that sniffing the URI in a web view creates a very confusing user experience at the moment.  It works better on Android than iOS 8 but is not smooth in many cases.

I personally use a out of band mobile authenticator for my enterprise login that has exactly that problem, and requires me to manually switch back to the calling app.

Regards
John B.




On Jul 24, 2015, at 12:59 AM, Erik Wahlström <erik@wahlstromstekniska.se> wrote:

Hi,

Thanks for a great document! I volunteered to review draft-wdenniss-oauth-native-apps-00 at the #IETF93 meeting so here we go:


In national mobile eID deployments an app is issued by gov or other organisation in a country. The app acts as the users authentication method and it works with an IDP, the IDP can be anywhere if its an PKI token or at the place that issued the credential if it’s something else. When an SP start developing an native app for there services and want’s to use the national eID solution in combination with OAuth we might run into trouble here.

The flow is like follows for a service provider called FooBar:

FooBar’s app starts browser-view. FooBar’s SAML service provider functionality redirects the user to an national SAML IDP. The IDP prompts user for a username and then starts an mobile eID token on the same phone. Users is asked if they want’s to authenticate to FooBar and enters PIN. User are then redirected back with an assertion. The FooBar's service provider verifies the assertion and mint’s OAuth2 token(s) and redirects the user back to the app with the help of the redirect URL.

So the phone first displays an app, then foobar.com in browser-view, then idp.com in browser-view, then mobile eID token, then idp.com in the system browser and back to foobar.com and the app that the user wanted to use.

The problem with browser-views is that the mobile eID token will start idp.com when user has authenticated and then the user is not back in the apps browser-view, but in system browser instead. The system browser is sharing the session with the browser-view and redirect the user to the native app. The user experience will be a bit strange then because there the correct page is not loaded and the browser-view should be closed and the app should start parsing out the authorization code instead.

So I think draft should mention something about this scenario and that app developers should handle this scenario in the app. The grant did not really come back from the browser-view as expected but from the system browser instead. 

—————————

With the above in mind. Maybe even some example code would be nice to have in the non normative section "Appendix A.  Operating System Specific Implementation Details”. Especially how to handle call backs.

—————————

Another eID related issue is the pricing model for authentications in that market segment. It’s really common by the eID credential issuing organisations to charge a service providers usage of a credential per tick (that is by OSCP call). The system is based on a per tick pricing model and there are regulations for how long the sessions can live. That means that its not possible to authenticate with a token once and then create a refresh token and the user will ever see the authentication flow again. It kinda messes up the usability of mobile apps a lot but end users have come to term with it. They have not however came to term to always require consents every time they use the app. That drives end user crazy. The usability would be much better if the payment model also accepted a refresh token as a tick instead of just an OSCP call, but we are not there yet.

Anyway, that’s the backstory. The section "6.4.  Always Prompting for User Interaction” is a bit harsh with a SHOULD NOT. I would rather change it to a NOT RECOMMENDED.

—————————

Two additional things that strengthen the case for using the browser-view also come to mind when reading the draft. The first is the fact that multiple tabs is started in some browser when going through multiple authentication attempts. That clutters the system so I really like the new browser-views.

The second is that there are additionally nice things in browser-view that do not exist in the web-view. The localStorage is also preserved and it can include important information to make authentication methods more secure.

————————

"Authorization servers SHOULD consider taking steps to detect and

block logins via embedded user-agents that are not their own, where

possible.""


Sounds good, but that also sounds very hard when it comes to public clients. 

—————————

And some nits:


"OAuth flows between a native app and the system browser (or another

external user-agent) are more secure, and take advantage of the

shared authentication state."


Not really clear what shared authentication state that is in that sentence.


"When the authentication server completes the request, it redirects to

   the client's redirection URI like it would any redirect URI"


s/authentication/authorization


/ Erik




On Thu, Jul 23, 2015 at 6:22 PM, <oauth-request@ietf.org> wrote:

John Bradley and I introduced a new draft at IETF93 yesterday:
https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00


Goal is to provide best practices for native apps using the RFC6749
authorization
endpoint, expanding on RFC6749 Section 9.  Specifically, it recommends
using an external user-agent (such as the system browser) for this task
over an embedded user-agent (such as a web-view), and suggests ways to
achieve this.


Comments welcome!
_______________________________________________
OAuth mailing list
OAuth@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

--------------000606000709000308040108-- From nobody Fri Jul 24 05:45:29 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0CB1A0270 for ; Fri, 24 Jul 2015 05:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UflRRVVXK3K for ; Fri, 24 Jul 2015 05:45:23 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0615.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:615]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16A091A1A10 for ; Fri, 24 Jul 2015 05:45:22 -0700 (PDT) Received: from BY1PR0201MB1030.namprd02.prod.outlook.com (10.161.203.148) by BY1PR0201MB1030.namprd02.prod.outlook.com (10.161.203.148) with Microsoft SMTP Server (TLS) id 15.1.225.19; Fri, 24 Jul 2015 12:45: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.0225.018; Fri, 24 Jul 2015 12:45:03 +0000 From: Antonio Sanso To: Paul Madsen Thread-Topic: [OAUTH-WG] OAuth Digest, Vol 81, Issue 86 Thread-Index: AQHQxZs7OlbLO2nX6kaUVw3hAEGObp3qHlwAgAAYdICAAEJmAIAAHdkA Date: Fri, 24 Jul 2015 12:45:02 +0000 Message-ID: <3A68A8B2-6755-4427-BE39-EB58A715DC3C@adobe.com> References: <99C2C652-65E6-42CB-BAD9-0B5D7BD4A90C@ve7jtb.com> <919808A7-B1A8-4CBF-9FD8-447357E18D27@adobe.com> <55B21E98.6020802@gmail.com> In-Reply-To: <55B21E98.6020802@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [192.147.117.12] x-microsoft-exchange-diagnostics: 1; BY1PR0201MB1030; 5:RGefJxsBQwTRJfRtI6sI0ijQLnZEu9S31nAXnfGQ29IderrA3/bClzhobeDfn+XX16CFpJepyv89Rb/Q/eeB3iP3PqiQ4QDGJTiYnojH4VEVfbB58rwT1FaeFecaIkoeDr1qmIkcM4GSi4N/wPcYvw==; 24:z6+f4fDmebsJmkhfB+3H4VwvWYnvA9BnPsrz01bhxGsLluOPY8Pg3vZHevws+Kvh7Yf1kZL2sAmSjrOK90cq2cjNxmGSg6hOfmT+8Ndy2+g=; 20:qz3jMXfkR+Z2kL1Y8F9rg78zVavmZ8j+STsj9aRPsfoFqAoYHvSUYRIa6mkI1EibjytoMPAw81CTeECdPOj6IA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0201MB1030; by1pr0201mb1030: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BY1PR0201MB1030; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0201MB1030; x-forefront-prvs: 0647963F84 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(479174004)(51444003)(10533003)(52314003)(377454003)(5403001)(110136002)(2900100001)(77096005)(15975445007)(189998001)(102836002)(2950100001)(99286002)(106116001)(40100003)(54356999)(93886004)(50986999)(36756003)(76176999)(62966003)(92566002)(122556002)(19580405001)(86362001)(2656002)(16601075003)(66066001)(77156002)(87936001)(19580395003)(82746002)(5002640100001)(5001960100002)(16297215004)(83716003)(16236675004)(19617315012)(15395725005)(19625305001)(46102003)(33656002)(10090500001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0201MB1030; H:BY1PR0201MB1030.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_3A68A8B267554427BE39EB58A715DC3Cadobecom_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2015 12:45:02.5832 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0201MB1030 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Digest, Vol 81, Issue 86 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 12:45:27 -0000 --_000_3A68A8B267554427BE39EB58A715DC3Cadobecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable hi, let me give you an example of what is my concern. I admit this example is a bit extreme but still As said one popular redirect_uri used by mobile app is http://localhost. Let=92s also say a resource owner use this mobile app the first time and ap= prove the consent screen and so forth=85. It also turn out this resource owner is a developer :) and it runs one appl= ication on its own computer. This application runs as well on localhost. Now, and as said this assumption is a bit extreme, this application has as = well some open redirector and http://localhost?goto=3Dhttp://evil.com redir= ect to evil.com Well you can do your maths now and see that having a consent screen now wou= ld prevent such a threat For the record some less popular custom redirect uri used for mobile I have= seen is also data: so also this might be =93at risk" regards antonio On Jul 24, 2015, at 1:16 PM, Paul Madsen > wrote: Antonio, are you arguing for short token lifetimes and so frequent explicit= consent ? or something more if the app has a valid refresh token then there is no opportunity for the A= S to inject a consent screen paul On 7/24/15 3:00 AM, Antonio Sanso wrote: hi, nice to see some work on this topic by the way! Couple of comments below inline On Jul 24, 2015, at 7:51 AM, John Bradley > wrote: Thanks for the review Erik, We will go through it in detail and get back to you. I am working with a couple of governments on how a eID app could use the se= lf issued profile of OpenID Connect to issue tokens. There are also other out of band authentication apps that people use that = need to be considered. I think that the callback / redirect_uri can work if a custom scheme URI or= a app claimed https: URI is used. Is there any example of =93popular=94 custom scheme. One I have seen is urn= :ietf:wg:oauth:2.0:oob Another common redirect_uri for native app I have seen is http://localhost<= http://localhost/> One more comment. I strongly suggest for mobile app to have a really stric= t consent screen policy. Aka the authorization server MUST show the consent screen at every usage an= d not remember the fact that the app has been already authorized. Just my 2 cents :) regards antonio I agree that sniffing the URI in a web view creates a very confusing user e= xperience at the moment. It works better on Android than iOS 8 but is not = smooth in many cases. I personally use a out of band mobile authenticator for my enterprise login= that has exactly that problem, and requires me to manually switch back to = the calling app. Regards John B. On Jul 24, 2015, at 12:59 AM, Erik Wahlstr=F6m > wrote: Hi, Thanks for a great document! I volunteered to review draft-wdenniss-oauth-n= ative-apps-00 at the #IETF93 meeting so here we go: In national mobile eID deployments an app is issued by gov or other organis= ation in a country. The app acts as the users authentication method and it = works with an IDP, the IDP can be anywhere if its an PKI token or at the pl= ace that issued the credential if it=92s something else. When an SP start d= eveloping an native app for there services and want=92s to use the national= eID solution in combination with OAuth we might run into trouble here. The flow is like follows for a service provider called FooBar: FooBar=92s app starts browser-view. FooBar=92s SAML service provider functi= onality redirects the user to an national SAML IDP. The IDP prompts user fo= r a username and then starts an mobile eID token on the same phone. Users i= s asked if they want=92s to authenticate to FooBar and enters PIN. User are= then redirected back with an assertion. The FooBar's service provider veri= fies the assertion and mint=92s OAuth2 token(s) and redirects the user back= to the app with the help of the redirect URL. So the phone first displays an app, then foobar.com in= browser-view, then idp.com in browser-view, then = mobile eID token, then idp.com in the system brows= er and back to foobar.com and the app that the user wa= nted to use. The problem with browser-views is that the mobile eID token will start idp.= com when user has authenticated and then the user is not b= ack in the apps browser-view, but in system browser instead. The system bro= wser is sharing the session with the browser-view and redirect the user to = the native app. The user experience will be a bit strange then because ther= e the correct page is not loaded and the browser-view should be closed and = the app should start parsing out the authorization code instead. So I think draft should mention something about this scenario and that app = developers should handle this scenario in the app. The grant did not really= come back from the browser-view as expected but from the system browser in= stead. =97=97=97=97=97=97=97=97=97 With the above in mind. Maybe even some example code would be nice to have = in the non normative section "Appendix A. Operating System Specific Implem= entation Details=94. Especially how to handle call backs. =97=97=97=97=97=97=97=97=97 Another eID related issue is the pricing model for authentications in that = market segment. It=92s really common by the eID credential issuing organisa= tions to charge a service providers usage of a credential per tick (that is= by OSCP call). The system is based on a per tick pricing model and there a= re regulations for how long the sessions can live. That means that its not = possible to authenticate with a token once and then create a refresh token = and the user will ever see the authentication flow again. It kinda messes u= p the usability of mobile apps a lot but end users have come to term with i= t. They have not however came to term to always require consents every time= they use the app. That drives end user crazy. The usability would be much = better if the payment model also accepted a refresh token as a tick instead= of just an OSCP call, but we are not there yet. Anyway, that=92s the backstory. The section "6.4. Always Prompting for Use= r Interaction=94 is a bit harsh with a SHOULD NOT. I would rather change it= to a NOT RECOMMENDED. =97=97=97=97=97=97=97=97=97 Two additional things that strengthen the case for using the browser-view a= lso come to mind when reading the draft. The first is the fact that multipl= e tabs is started in some browser when going through multiple authenticatio= n attempts. That clutters the system so I really like the new browser-views= . The second is that there are additionally nice things in browser-view that = do not exist in the web-view. The localStorage is also preserved and it can= include important information to make authentication methods more secure. =97=97=97=97=97=97=97=97 "Authorization servers SHOULD consider taking steps to detect and block logins via embedded user-agents that are not their own, where possible."" Sounds good, but that also sounds very hard when it comes to public clients= . =97=97=97=97=97=97=97=97=97 And some nits: "OAuth flows between a native app and the system browser (or another external user-agent) are more secure, and take advantage of the shared authentication state." Not really clear what shared authentication state that is in that sentence. "When the authentication server completes the request, it redirects to the client's redirection URI like it would any redirect URI" s/authentication/authorization / Erik On Thu, Jul 23, 2015 at 6:22 PM, > wrote: John Bradley and I introduced a new draft at IETF93 yesterday: https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00 Goal is to provide best practices for native apps using the RFC6749 authorization endpoint, expanding on RFC6749 Section 9. Specifically, it recommends using an external user-agent (such as the system browser) for this task over an embedded user-agent (such as a web-view), and suggests ways to achieve this. Comments welcome! _______________________________________________ OAuth mailing list OAuth@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_3A68A8B267554427BE39EB58A715DC3Cadobecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <6473454E0039F048A6A6C845A0383BC0@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable hi,

let me give you an example of what is my concern.
I admit this example is a bit extreme but still
As said one popular redirect_uri used by mobile app is http://localhost.

Let=92s also say a resource owner use this mobile app the first time a= nd approve the consent screen and so forth=85.

It also turn out this resource owner is a developer :) and it runs one= application on its own computer.
This application runs as well on localhost.
Now, and as said this assumption is a bit extreme, this application ha= s as well some open redirector and http://localhost?goto= =3Dhttp://evil.com redirect to evil.com

Well you can do your maths now and see that having a consent screen no= w would prevent such a threat

For the record some less popular custom redirect uri used for mobile I= have seen is also data: so also this might be =93at risk"

regards

antonio

On Jul 24, 2015, at 1:16 PM, Paul Madsen <paul.madsen@gmail.com> wrote:

Antonio, are you arguing for shor= t token lifetimes and so frequent explicit consent ? or something more

if the app has a valid refresh token then there is no opportunity for the A= S to inject a consent screen

paul

On 7/24/15 3:00 AM, Antonio Sanso wrote:
hi,

nice to see some work on this topic by the way!

Couple of comments below inline

On Jul 24, 2015, at 7:51 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Thanks for the review Erik,

We will go through it in detail and get back to you.

I am working with a couple of governments on how a eID app = could use the self issued profile of OpenID Connect to issue tokens.

There are also other out of band authentication  apps = that people use that need to be considered.

I think that the callback / redirect_uri can work if a cust= om scheme URI or a app claimed https: URI is used.

Is there any example of =93popular=94 custom scheme. One I have seen i= s urn:ietf:wg:oauth:2.0:oob 
Another common redirect_uri for native app I have seen is http://localhost

One more comment. I strongly suggest  for mobile app to have a re= ally strict consent screen policy.
Aka the authorization server MUST show the consent screen at every usa= ge and not remember the fact that the app has been already authorized.

Just my 2 cents :)

regards

antonio 


I agree that sniffing the URI in a web view creates a very = confusing user experience at the moment.  It works better on Android t= han iOS 8 but is not smooth in many cases.

I personally use a out of band mobile authenticator for my = enterprise login that has exactly that problem, and requires me to manually= switch back to the calling app.

Regards
John B.




On Jul 24, 2015, at 12:59 AM, Erik Wahlstr=F6m <e= rik@wahlstromstekniska.se> wrote:

Hi,

Thanks for a great document! I volunteer= ed to review draft-wdenniss-oauth-native-apps-00 at the #IETF93 meeting so = here we go:


In national mobile eID deployments an ap= p is issued by gov or other organisation in a country. The app acts as the = users authentication method and it works with an IDP, the IDP can be anywhe= re if its an PKI token or at the place that issued the credential if it=92s something else. When an SP start deve= loping an native app for there services and want=92s to use the national eI= D solution in combination with OAuth we might run into trouble here.=

The flow is like follows for a service p= rovider called FooBar:

FooBar=92s app starts browser-view. = ;FooBar=92s SAML service provider functionality redirects the user to an na= tional SAML IDP. The IDP prompts user for a username and then starts an mob= ile eID token on the same phone. Users is asked if they want=92s to authenticate to FooBar and enters PIN. User are then r= edirected back with an assertion. The FooBar's service provider verifies th= e assertion and mint=92s OAuth2 token(s) and redirects the user back to the= app with the help of the redirect URL.

So the phone first displays an app, then= foobar.com in browser-view, then idp.com in browser-view, then mobile eID token, then idp.com in the system browser and back to foobar.com and the app that the user wan= ted to use.

The problem with browser-views is that t= he mobile eID token will start idp.com when user has authenticated and then the us= er is not back in the apps browser-view, but in system browser instead. The= system browser is sharing the session with the browser-view and redirect the user to the native app. The user experience = will be a bit strange then because there the correct page is not loaded and= the browser-view should be closed and the app should start parsing out the= authorization code instead.

So I think draft should mention somethin= g about this scenario and that app developers should handle this scenario i= n the app. The grant did not really come back from the browser-view as expe= cted but from the system browser instead. 

=97=97=97=97=97=97=97=97=97

With the above in mind. Maybe even some example code would = be nice to have in the non normative section "Appendix A.  Operat= ing System Specific Implementation Details=94. Especially how to handle cal= l backs.

=97=97=97=97=97=97=97=97=97

Another eID related issue is the pricing= model for authentications in that market segment. It=92s really common by = the eID credential issuing organisations to charge a service providers usag= e of a credential per tick (that is by OSCP call). The system is based on a per tick pricing model and there are = regulations for how long the sessions can live. That means that its not pos= sible to authenticate with a token once and then create a refresh token and= the user will ever see the authentication flow again. It kinda messes up the usability of mobile apps a lot but end = users have come to term with it. They have not however came to term to alwa= ys require consents every time they use the app. That drives end user crazy= . The usability would be much better if the payment model also accepted a refresh token as a tick instead of ju= st an OSCP call, but we are not there yet.

Anyway, that=92s the backstory. The sect= ion "6.4.  Always Prompting for User Interaction=94 is a bit hars= h with a SHOULD NOT. I would rather change it to a NOT RECOMMENDED.

=97=97=97=97=97=97=97=97=97

Two additional things that strengthen th= e case for using the browser-view also come to mind when reading the draft.= The first is the fact that multiple tabs is started in some browser when g= oing through multiple authentication attempts. That clutters the system so I really like the new browser-views.=

The second is that there are additionally nice things in br= owser-view that do not exist in the web-view. The localStorage is also pres= erved and it can include important information to make authentication metho= ds more secure.

=97=97=97=97=97=97=97=97

"Authorization servers SHOULD consi= der taking steps to detect and

block logins via embedded user-agents th= at are not their own, where

possible.""


Sounds good, but that also sounds very h= ard when it comes to public clients. 

=97=97=97=97=97=97=97=97=97

And some nits:


"OAuth flows between a native app a= nd the system browser (or another

external user-agent) are more secure, an= d take advantage of the

shared authentication state."


Not really clear what shared authenticat= ion state that is in that sentence.


"When the authentication server com= pletes the request, it redirects to

   the client's redirection UR= I like it would any redirect URI"


s/authentication/authorization


/ Erik




On Thu, Jul 23, 2015 at 6:22 PM, <oauth-request@ietf.org> wrote:

John Bradley and I introduced a new draft at IETF93 yesterday:
h= ttps://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00


Goal is to provide best practices for native apps using the RFC6749
authorization
endpoint, expanding on RFC6749 Section 9.  Specifically, it recommends=
using an external user-agent (such as the system browser) for this task
over an embedded user-agent (such as a web-view), and suggests ways to
achieve this.


Comments welcome!
_______________________________________________
OAuth mailing list
OAuth= @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_3A68A8B267554427BE39EB58A715DC3Cadobecom_-- From nobody Fri Jul 24 22:07:38 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A451B2A53 for ; Fri, 24 Jul 2015 22:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMl_ks7-Vep1 for ; Fri, 24 Jul 2015 22:07:35 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0146.outbound.protection.outlook.com [207.46.100.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F5971B2ADB for ; Fri, 24 Jul 2015 22:07:34 -0700 (PDT) Received: from BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) by BY2PR03MB299.namprd03.prod.outlook.com (10.141.139.21) with Microsoft SMTP Server (TLS) id 15.1.225.19; Sat, 25 Jul 2015 05:07:33 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.225.13; Sat, 25 Jul 2015 05:07:31 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0225.018; Sat, 25 Jul 2015 05:07:31 +0000 From: Mike Jones To: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Meeting Minutes Thread-Index: AQHQxVJ6eqKcIqEklESLRBcKW8yYrZ3roVOw Date: Sat, 25 Jul 2015 05:07:31 +0000 Message-ID: References: <55B0F7B6.7000705@gmx.net> In-Reply-To: <55B0F7B6.7000705@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; x-originating-ip: [12.130.117.133] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:rOgZkJRn7MXBWoyEC9aBOndJ5+ktXs8/qaRfr75pP3rEVlrtBBAiS1Wz1+g3aX2kEn1C1nqxbn2wot7n35W1spF1czB0K819/voESnsvu3pE0QDHhbQeYAxiSM/3FVrJwy6mBxeuNPReAJN4oA0iIQ==; 24:GI65WEn/+5YKHWNf3bZ8D0fCdCNowUlOWVXEQEjhxERABy5CLvi/Hpv6QbfTr/QkPG1gCUUfmfqcD/n2y4bsnM6MW14UUJXlw5/oR1h+dAM=; 20:jHlMYwjHyVlj+ofbsifxZdR+XN9+S50+7AGQsfQ2Ma7MrhKvcAxPqypd4OkAEJv1q250nDxxycvop7khI/litg== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB299; by2pr03mb443: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 0648FCFFA8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(13464003)(377454003)(122556002)(74316001)(10090500001)(76176999)(92566002)(86612001)(33656002)(189998001)(46102003)(86362001)(5003600100002)(19580405001)(107886002)(106116001)(5002640100001)(99286002)(2501003)(50986999)(54356999)(5001960100002)(77096005)(87936001)(15975445007)(62966003)(19580395003)(5001770100001)(2950100001)(76576001)(77156002)(66066001)(102836002)(40100003)(2656002)(2900100001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2015 05:07:31.1994 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 X-Microsoft-Exchange-Diagnostics: 1; BY2PR03MB299; 2:r8lWdbbrFIPlJGskr/uXbTAL75oQO0kuL+nXwHPx/VEJkBfQsGyYa/xIVeaG50Olc6thi/G401zorcsA1fun6qvp+YiAcISFvYiAeNeLmtg0OEBcd+XhQq2utp6P/9F9GSU4/NzelEeoNPzHM1stE0j5z1fB30VNnkcgmzQTY0M=; 3:T5kHgF2UQDS6b3bbLFOQLs+ciGoN8yQ3HRTYcjd73v/we6qWpiA31U4TZw4t6V/18Kbw5/ntwLX+iy5eZATu0WMrL81IESU7Fjs4olISBAu3ZquaVNTS1lm5ffuP8riaICEEq5RpvUbu8ZXGvS9QAw==; 25:+28hkir5N9E6Ew8n6I1ke+TidSq2n+CB67KAgVg5Dlb8ZJrKkdbMgYXxKe9dEoSvYcRnq3X73KwaPR9XCcVga5yfAdaJaP2yt6v/ljB70QsMdURCwBNKVoSpZwerEwqrjXIOSSn6UXLBX+oaS2u9NfSGHZJi3bFXgct7oUEYDGZJ1e7+z3cB9KvuMPLyUAH/7SKk2L4LWebD2MGPdVpirEawidDJiXBJYWmLcTLLTLrULPON5M/DpD1cVQ9fMzPuF1QDE4ubDyuksUnMu1dRMQ== X-Microsoft-Exchange-Diagnostics: 1; BY2PR03MB299; 20:XpnNOcEOahDDnCiv5KySwyRZmAcceWoDBNk/v+x5iavnusT8FMlQ7Wpq8GkisSSM1z4mHvr/whFM09/UmSy39VlOZCdNS+Qovx+nbfJUG0Wd0iA6pqUE8dlcg5ltKu63AjmsHfisxh98g01sdcizpM1x9A7mGEc/7NJnK0jyif+y9GahiGlgDREGLk0KzV7oAapO4iZQTMxjyDrRFVrchk51SXHaSWi8Y/fm+2CXeBYWTe+WixcbCnJGq9pCfZ6FRgfzVSRnpeXoHEfzjLvAwSscmuXP1ACE2Ksk4efAV3gKA9wYECTIdVR/eFT1KXYkBArn2+WpyWC9oloUvKzTe0SRkH9zItcKkzBg8xhuWPSM0eFa193Qf/yRgAomnFYQirwphjnE2+Qw2kNBfhojs41XvOYELZeCt7q6PKBit1kTdYh14mGiKkJDIugZVDYnqZiTmRq8+6LBxQKx/WjdUbsILYSB4LWcC/MDADxXRGIiwHcQw2SwRAIygehcO4Iq; 23:q4NE1dnkzAbfBlq0m8LsaKfU7MdemvNVhyAHgGQJh3ViLcM/2Sfd2v+RJm07n7a1tgjbBzTOhiKDwv4POmxJ+BDej26cu49PZFLuhVoSTMUqH2CON+T6tdqO3mAkOn9ZYmkWH5XL1Iybbotjbf1DkZlQ7297oZ90XBacCB0VXuYvAskRNCKleUOQxjaJ7qkCmD+qKFdbCTMP/S2GGlQK3H37zjp2sgae7tj6Kx2gkOSWwmNYyhspWJWnN3FQpnHZ BY2PR03MB299: X-MS-Exchange-Organization-RulesExecuted X-OriginatorOrg: microsoft.com Archived-At: Subject: Re: [OAUTH-WG] Meeting Minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2015 05:07:37 -0000 R29vZCBub3Rlcy4gIFBsZWFzZSBhcHBseSB0aGUgZm9sbG93aW5nIGZpeGVzIHRvIHRoZW0uLi4N Cg0KVG8gdGhlIGxpc3Qgb2YgbmV3IE9BdXRoIFJGQ3Mgc2luY2UgdGhlIGxhc3QgbWVldGluZyBw bGVhc2UgYWxzbyBhZGQ6DQoJZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbg0KCWRyYWZ0 LWlldGYtb2F1dGgtc2FtbDItYmVhcmVyDQoJZHJhZnQtaWV0Zi1vYXV0aC1qd3QtYmVhcmVyDQoN ClBsZWFzZSBjaGFuZ2U6DQoJTWlrZTogSWYgdGhlIGFjY2Vzc190b2tlbiBpcyB1c2VkLCB0aGVu IHdlIG11c3QgYWRkIHRvIHNwZWMgdGhhdCBpdCdzIHRoZXJlIGZvciBoaXN0b3JpYyByZWFzb25z IGFuZCBzYXkgdGhhdCBpdCdzIGFjdHVhbGx5IG5vdCBhbHdheXMgdGhlIHNhbWUgdG9rZW4uDQp0 bzoNCglNaWtlOiBJZiB0aGUgYWNjZXNzX3Rva2VuIGlzIHVzZWQsIHRoZW4gd2UgbXVzdCBhZGQg dG8gc3BlYyB0aGF0IGl0J3MgdGhlcmUgZm9yIGhpc3RvcmljIHJlYXNvbnMgYW5kIHNheSB0aGF0 IGl0J3MgYWN0dWFsbHkgbm90IGFsd2F5cyBhbiBhY2Nlc3MgdG9rZW4uDQoNClBsZWFzZSBjaGFu Z2U6DQoJQ29uc2Vuc3VzOiBGb3IgdXNlIG9mIGV4aXN0aW5nIHBhcmFtcyBkZWZpbmVkIGluIE9B dXRoLg0KdG86DQoJQ29uc2Vuc3VzOiBGb3IgdXNlIG9mIGV4aXN0aW5nIHBhcmFtcyBkZWZpbmVk IGluIE9BdXRoLCB3aGlsZSBhbGxvd2luZyBzb21lIHRvIGJlIG9wdGlvbmFsIHdoZW4gbm90IG5l ZWRlZC4NCg0KUGxlYXNlIGNoYW5nZToNCglNaWtlOiBNaWNyb3NvZnQgb2F1dGgyIHNlcnZlciBo YXZlIGEgJ3Jlc291cmNlJyBwYXJhbSB0byBpbmRpY2F0ZSB0aGUgYXVkaWVuY2UuDQp0bzoNCglN aWtlOiBNaWNyb3NvZnQgb2F1dGgyIHNlcnZlciBoYXMgYSAncmVzb3VyY2UnIHBhcmFtIHRvIGlu ZGljYXRlIHRoZSByZXNvdXJjZSB0aGF0IHRoZSBhY2Nlc3MgdG9rZW4gd2lsbCBiZSB1c2VkIHRv IGFjY2Vzcy4NCg0Kd2hpdGVseSB1c2VkIC0+IHdpZGVseSB1c2VkDQoNCldlIG5lZWQgdG8gZ28g b24gd2l0aCBvdXQgbGl2ZXMgLT4gV2UgbmVlZCB0byBnbyBvbiB3aXRoIG91ciBsaXZlcw0KDQpy ZWFkeSB0byBhIHNoZXBoZXJkIHdyaXRlLXVwIC0+IHJlYWR5IGZvciBhIHNoZXBoZXJkIHdyaXRl LXVwDQoNCkZpbmFsbHksIEkgd291bGQgYWRkIGEgbm90ZSBzYXlpbmc6DQoJU29tZSBhZGRpdGlv bmFsIGRyYWZ0cyBhcmUgcGxhbm5lZCwgaW5jbHVkaW5nIGRyYWZ0LWpvbmVzLWFtci12YWx1ZXMg YW5kIGRyYWZ0LWlldGYtb2F1dGgtZGlzY292ZXJ5DQoNCgkJCQlUaGFua3MNCgkJCQktLSBNaWtl DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRo LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIYW5uZXMgVHNjaG9mZW5pZw0KU2VudDog VGh1cnNkYXksIEp1bHkgMjMsIDIwMTUgNzoxOSBBTQ0KVG86IG9hdXRoQGlldGYub3JnDQpTdWJq ZWN0OiBbT0FVVEgtV0ddIE1lZXRpbmcgTWludXRlcw0KDQpIZXJlIGFyZSB0aGUgbm90ZXMgZnJv bSBvdXIgbWVldGluZyB5ZXN0ZXJkYXk6DQpodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZnByb2NlZWRp bmdzJTJmOTMlMmZtaW51dGVzJTJmbWludXRlcy05My1vYXV0aCZkYXRhPTAxJTdjMDElN2NNaWNo YWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3Y2NiMDg1MTA4ZWNiMDQ1NGIzM2MwMDhkMjkzNjk5 Yjg1JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPTVHaVZ5MlNp dlprNkdXZW9YdGFiYlFHMXEzcjElMmJMJTJmbk00bzJCbUg1S3Y4JTNkDQoNClRoYW5rcyB0byBF cmlrIGZvciB0YWtpbmcgbm90ZXMuDQoNClBsZWFzZSBsZXQgbWUga25vdyBpZiBzb21ldGhpbmcg aXMgbWlzc2luZyBvciBpbmNvcnJlY3Qgd2l0aGluIHRoZSBuZXh0DQoyIHdlZWtzLg0KDQpDaWFv DQpIYW5uZXMNCg0K From nobody Sat Jul 25 00:14:46 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE9F1B2D20 for ; Sat, 25 Jul 2015 00:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnnNp3LUbKGD for ; Sat, 25 Jul 2015 00:14:42 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A7F21B2D1F for ; Sat, 25 Jul 2015 00:14:42 -0700 (PDT) X-AuditID: 12074425-f799a6d000007db3-4c-55b337609ec9 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 5E.3C.32179.16733B55; Sat, 25 Jul 2015 03:14:41 -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 t6P7Eear022531; Sat, 25 Jul 2015 03:14:40 -0400 Received: from [10.55.3.183] ([31.30.2.50]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t6P7Eamv014116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 25 Jul 2015 03:14:38 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Justin Richer In-Reply-To: Date: Sat, 25 Jul 2015 09:14:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55B0F7B6.7000705@gmx.net> To: Mike Jones X-Mailer: Apple Mail (2.2102) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphleLIzCtJLcpLzFFi42IRYrdT0U003xxqsHsJi8XSnfdYLfZO+8Ri cfLtKzYHZo/Fm/azeSxZ8pPJo3XHX/YA5igum5TUnMyy1CJ9uwSujBvbNrIXnBKrOP3qKFsD 4zqhLkZODgkBE4l7T96yQ9hiEhfurWcDsYUEFjNJfNqb28XIBWRvZJT4P2c7K4Szgkmi9+ks sA5mAXWJP/MuMYPYvAJ6Ej3nvjB2MXJwCAPFm37ogYTZBFQlpq9pYQKxOQWiJW596GIEsVmA 4p33HrKClDMLxEus3hgPMVFbYtnC11ATrSTWHlgKdU+pxOxnh8HiIgI6Eo8vfmODuFlWYuub VqYJjIKzkBw0C8lBs5CMXcDIvIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXQi83s0QvNaV0EyM4 oF1UdzBOOKR0iFGAg1GJh3fD702hQqyJZcWVuYcYJTmYlER5v0huDhXiS8pPqcxILM6ILyrN SS0+xCjBwawkwiv5AKicNyWxsiq1KB8mJc3BoiTOu+kHX4iQQHpiSWp2ampBahFMVoaDQ0mC 94wp0FDBotT01Iq0zJwShDQTByfIcB6Q4WZANbzFBYm5xZnpEPlTjLoc03Y/WMskxJKXn5cq Jc7LCVIkAFKUUZoHNweWiF4xigO9JcyrDFLFA0xicJNeAS1hAlrC07cBZElJIkJKqoFx848l LKKZz8SvbHBO/Dz/1mxjp2Xu136bTJkqp8Vrqnb8VU7sY5Gjenn/J71Q+n6zedfEph0HS3P/ //h/dnKMu0Uz+xUHx8bW+bdSsrWfa/i9MLldIZciM/tNapu3QrP/nm7ZwkX/r81+KsW6k9Or YlZ3kc2pkDeVB2MSy/mDpeubJeTeGXxUYinOSDTUYi4qTgQAqbBNfh8DAAA= Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Meeting Minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2015 07:14:44 -0000 > Consensus: For use of existing params defined in OAuth, while allowing = some to be optional when not needed. That was not the consensus as I understood it in the room. The consensus = was the first portion, as originally noted. The second portion was = Mike=E2=80=99s requested amendment, and it (and other aspects like the = value of token_type) were brought up as details that the editors would = work on and come back to the list. =E2=80=94 Justin > On Jul 25, 2015, at 7:07 AM, Mike Jones = wrote: >=20 > Good notes. Please apply the following fixes to them... >=20 > To the list of new OAuth RFCs since the last meeting please also add: > draft-ietf-oauth-json-web-token > draft-ietf-oauth-saml2-bearer > draft-ietf-oauth-jwt-bearer >=20 > Please change: > Mike: If the access_token is used, then we must add to spec that = it's there for historic reasons and say that it's actually not always = the same token. > to: > Mike: If the access_token is used, then we must add to spec that = it's there for historic reasons and say that it's actually not always an = access token. >=20 > Please change: > Consensus: For use of existing params defined in OAuth. > to: > Consensus: For use of existing params defined in OAuth, while = allowing some to be optional when not needed. >=20 > Please change: > Mike: Microsoft oauth2 server have a 'resource' param to = indicate the audience. > to: > Mike: Microsoft oauth2 server has a 'resource' param to indicate = the resource that the access token will be used to access. >=20 > whitely used -> widely used >=20 > We need to go on with out lives -> We need to go on with our lives >=20 > ready to a shepherd write-up -> ready for a shepherd write-up >=20 > Finally, I would add a note saying: > Some additional drafts are planned, including = draft-jones-amr-values and draft-ietf-oauth-discovery >=20 > Thanks > -- Mike >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes = Tschofenig > Sent: Thursday, July 23, 2015 7:19 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Meeting Minutes >=20 > Here are the notes from our meeting yesterday: > = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.iet= f.org%2fproceedings%2f93%2fminutes%2fminutes-93-oauth&data=3D01%7c01%7cMic= hael.Jones%40microsoft.com%7ccb085108ecb0454b33c008d293699b85%7c72f988bf86= f141af91ab2d7cd011db47%7c1&sdata=3D5GiVy2SivZk6GWeoXtabbQG1q3r1%2bL%2fnM4o= 2BmH5Kv8%3d >=20 > Thanks to Erik for taking notes. >=20 > Please let me know if something is missing or incorrect within the = next > 2 weeks. >=20 > Ciao > Hannes >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Sat Jul 25 05:17:39 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F261A033A for ; Sat, 25 Jul 2015 05:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84jSrJlttc2N for ; Sat, 25 Jul 2015 05:17:37 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::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 D09ED1A1A6D for ; Sat, 25 Jul 2015 05:17:36 -0700 (PDT) Received: by iecrl10 with SMTP id rl10so32235807iec.1 for ; Sat, 25 Jul 2015 05:17: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:content-type; bh=+TsJMS3F4DvxoFW2R/WU6zNCl9VwJlYyqTFa5XspQ08=; b=VgIs7GR7PNEudopGXheoHNsgoPmE6VKUqjkWbRjLXlYNgAq89InaX6gA5gEeIUFhkK iyXuae7ez7Rsg5U9h30ycpxhePmp99IgJRWfV35vJhO1BLrJdiCwWQijWNsbgr68TjTU ZeTPyMyixEiNPYjspLe0WDWcpTjyNidxLrxrc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=+TsJMS3F4DvxoFW2R/WU6zNCl9VwJlYyqTFa5XspQ08=; b=C7P3P8RXb49LsZqxMCKjg14af777QdSn03L2I7RdpykDjWcCB3MX0ZRmLPZQty2fi6 jLkBZ0d5v/EE2p0MWATCmQ2ndNgQhiy/bx9Jz000Gdg15w4wCORkKitS5+2i5Nx2epgl Kw7A8EwfVLspvwrIF8+2gyQ7tfqvw8xesKpdEBLWelF7KsTMKj8MaIh1az5BpoJahKWG 4PI6qvWopt6TYgpWzREJV5ePj72LcAx+Hnv2oH6kk7+mAhRhkBjskFCdb5kC5w1uGh2P GcE4406ffbbP4mOobmPPritPdmeEMOenn/FtwJUgHmd0ELJ/wdTii1LgFnQCZzJC4clP g07Q== X-Gm-Message-State: ALoCoQk3ykQ1b/Z0YVMIhAFn9BE4An6f5s6NZqvBBDR8gcz/dsOiIF2yBk11p2zuXHdmfEdB/kR/ X-Received: by 10.50.30.226 with SMTP id v2mr3869054igh.3.1437826656295; Sat, 25 Jul 2015 05:17:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Sat, 25 Jul 2015 05:17:06 -0700 (PDT) In-Reply-To: References: <55B0F7B6.7000705@gmx.net> From: Brian Campbell Date: Sat, 25 Jul 2015 14:17:06 +0200 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=047d7b86d5021902da051bb21be6 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Meeting Minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2015 12:17:38 -0000 --047d7b86d5021902da051bb21be6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My sense of the consensus in the room is as Justin describes it. On Sat, Jul 25, 2015 at 9:14 AM, Justin Richer wrote: > > Consensus: For use of existing params defined in OAuth, while allowing > some to be optional when not needed. > > That was not the consensus as I understood it in the room. The consensus > was the first portion, as originally noted. The second portion was Mike= =E2=80=99s > requested amendment, and it (and other aspects like the value of > token_type) were brought up as details that the editors would work on and > come back to the list. > > =E2=80=94 Justin > > > > On Jul 25, 2015, at 7:07 AM, Mike Jones > wrote: > > > > Good notes. Please apply the following fixes to them... > > > > To the list of new OAuth RFCs since the last meeting please also add: > > draft-ietf-oauth-json-web-token > > draft-ietf-oauth-saml2-bearer > > draft-ietf-oauth-jwt-bearer > > > > Please change: > > Mike: If the access_token is used, then we must add to spec that > it's there for historic reasons and say that it's actually not always the > same token. > > to: > > Mike: If the access_token is used, then we must add to spec that > it's there for historic reasons and say that it's actually not always an > access token. > > > > Please change: > > Consensus: For use of existing params defined in OAuth. > > to: > > Consensus: For use of existing params defined in OAuth, while > allowing some to be optional when not needed. > > > > Please change: > > Mike: Microsoft oauth2 server have a 'resource' param to indicate > the audience. > > to: > > Mike: Microsoft oauth2 server has a 'resource' param to indicate > the resource that the access token will be used to access. > > > > whitely used -> widely used > > > > We need to go on with out lives -> We need to go on with our lives > > > > ready to a shepherd write-up -> ready for a shepherd write-up > > > > Finally, I would add a note saying: > > Some additional drafts are planned, including > draft-jones-amr-values and draft-ietf-oauth-discovery > > > > Thanks > > -- Mike > > > > -----Original Message----- > > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes > Tschofenig > > Sent: Thursday, July 23, 2015 7:19 AM > > To: oauth@ietf.org > > Subject: [OAUTH-WG] Meeting Minutes > > > > Here are the notes from our meeting yesterday: > > > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ie= tf.org%2fproceedings%2f93%2fminutes%2fminutes-93-oauth&data=3D01%7c01%7cMic= hael.Jones%40microsoft.com%7ccb085108ecb0454b33c008d293699b85%7c72f988bf86f= 141af91ab2d7cd011db47%7c1&sdata=3D5GiVy2SivZk6GWeoXtabbQG1q3r1%2bL%2fnM4o2B= mH5Kv8%3d > > > > Thanks to Erik for taking notes. > > > > Please let me know if something is missing or incorrect within the next > > 2 weeks. > > > > 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 > --047d7b86d5021902da051bb21be6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My sense of the consensus in the room is as Justin describ= es it.

O= n Sat, Jul 25, 2015 at 9:14 AM, Justin Richer <jricher@mit.edu> wrote:
> Consensus:= For use of existing params defined in OAuth, while allowing some to be opt= ional when not needed.

That was not the consensus as I understood it in the room. The conse= nsus was the first portion, as originally noted. The second portion was Mik= e=E2=80=99s requested amendment, and it (and other aspects like the value o= f token_type) were brought up as details that the editors would work on and= come back to the list.

=C2=A0=E2=80=94 Justin


> On Jul 25, 2015, at 7:07 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>
> Good notes.=C2=A0 Please apply the following fixes to them...
>
> To the list of new OAuth RFCs since the last meeting please also add:<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-oauth-json-web-token
>=C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-oauth-saml2-bearer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-oauth-jwt-bearer
>
> Please change:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Mike: If the access_token is used, then we m= ust add to spec that it's there for historic reasons and say that it= 9;s actually not always the same token.
> to:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Mike: If the access_token is used, then we m= ust add to spec that it's there for historic reasons and say that it= 9;s actually not always an access token.
>
> Please change:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Consensus: For use of existing params define= d in OAuth.
> to:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Consensus: For use of existing params define= d in OAuth, while allowing some to be optional when not needed.
>
> Please change:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Mike: Microsoft oauth2 server have a 're= source' param to indicate the audience.
> to:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Mike: Microsoft oauth2 server has a 'res= ource' param to indicate the resource that the access token will be use= d to access.
>
> whitely used -> widely used
>
> We need to go on with out lives -> We need to go on with our lives<= br> >
> ready to a shepherd write-up -> ready for a shepherd write-up
>
> Finally, I would add a note saying:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Some additional drafts are planned, includin= g draft-jones-amr-values and draft-ietf-oauth-discovery
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =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-bo= unces@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Thursday, July 23, 2015 7:19 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Meeting Minutes
>
> Here are the notes from our meeting yesterday:
> https= ://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf.org%= 2fproceedings%2f93%2fminutes%2fminutes-93-oauth&data=3D01%7c01%7cMichae= l.Jones%40microsoft.com%7ccb085108ecb0454b33c008d293699b85%7c72f988bf86f141= af91ab2d7cd011db47%7c1&sdata=3D5GiVy2SivZk6GWeoXtabbQG1q3r1%2bL%2fnM4o2= BmH5Kv8%3d
>
> Thanks to Erik for taking notes.
>
> Please let me know if something is missing or incorrect within the nex= t
> 2 weeks.
>
> 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

--047d7b86d5021902da051bb21be6-- From nobody Sat Jul 25 05:47:13 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B441A9147 for ; Sat, 25 Jul 2015 05:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.693 X-Spam-Level: X-Spam-Status: No, score=0.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URI_NO_WWW_INFO_CGI=2.071] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-GRSODboPwy for ; Sat, 25 Jul 2015 05:47:08 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4504E1A92E6 for ; Sat, 25 Jul 2015 05:47:07 -0700 (PDT) Received: by iehx8 with SMTP id x8so36368800ieh.3 for ; Sat, 25 Jul 2015 05:47:06 -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:content-type; bh=d5DEyMX4w9Uy1ghMDAGwds7TJNuBIKUaUWo5+C4IXqw=; b=MAw4wqVfSDvI+QmL+52DedfXj9qNA146xl36Rhw8CI5byssmgP+T63+NN+Rk2FHRlG RQ8GYnryDwEZW24hv4MJdPdF+gOpY6a8sK1UNWAFRw15hH8bAu3LnhMqpOvlUzJb0qb+ RSCeGLKk8iNQgxLpW2HiLJLSWSStgCemPyTLA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=d5DEyMX4w9Uy1ghMDAGwds7TJNuBIKUaUWo5+C4IXqw=; b=IgTgez2Hb+tF5h8iPll37NekitChLsmWyhtK2iTWZPit+dfnZZgdsLSICRxxWALNwd VkweqzxyGdc8yUjWtVbfIcqKaRtWN8DBS9kQMAnO4wlP+UaXNkysvwnPw/bySD4zcpFV KIwgfEsHtzDP7khY1mYcNb8EsPj4cFurFcleqRQuR6B4OvBG/lgupo27HoiJuGVoMDfd n7h0UypvIaHjP09zMOYMj3LxPx5NHLFiM6W6Z9vAy+YrJ1FH9A4iC9+CfP4itEOmJLf8 tuJ39iwpGsK5t2kcEcAJG7sWUNgX1fwdKRWFZl1xyQSKv/H/2TETtJ0YFAHFnPp9ip6V Q35A== X-Gm-Message-State: ALoCoQlOy1FSIc0hQULinZ2w48AbWNwXhEpB7ktekVqFIVg5jl8jlzt6j6TUlc7wywFXsmqvsKrz X-Received: by 10.107.14.148 with SMTP id 142mr29406791ioo.175.1437828426487; Sat, 25 Jul 2015 05:47:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Sat, 25 Jul 2015 05:46:37 -0700 (PDT) In-Reply-To: References: <8BADFB60-1BE4-415A-B386-F34F9FE72A3C@mit.edu> <61575F9A-8A0F-415A-89AA-480432813020@ve7jtb.com> From: Brian Campbell Date: Sat, 25 Jul 2015 14:46:37 +0200 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=001a113fc47c9bfe61051bb2840b Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Authentication Method Reference Values Specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2015 12:47:11 -0000 --001a113fc47c9bfe61051bb2840b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There's a method of authentication that is gaining in popularity which I'd propose adding a method for. It is typically used as a second factor where after a primary auth, like username and password, a push notification is sent to the user's phone and they acknowledge it from the device. We have the PingID product that does it and Entrust and Duo , among others I'm sure, offer something similar. It's commonly called "mobile push authentication" so maybe "mpa" could be the amr value. But, as Nat pointed out, the really interesting characteristic is that it's a second factor that utilizes only a secondary channel - so perhaps "sca" for "second channel authentication" would be a more appropriate general amr name. Thoughts are welcome. But I believe it's becoming prevalent enough that it deserves its own amr value in this doc. On Thu, Jul 23, 2015 at 6:29 PM, Mike Jones wrote: > I agree that an obvious good thing to do is to add spec references to > the field definitions. > > > > I need to investigate use cases for amr_values. I think this came from > developers who actually wanted this for a particular purpose but I=E2=80= =99ll have > to get back to the WG on that. It=E2=80=99s defined here, rather than in= another > spec, because it=E2=80=99s highly related to the =E2=80=9Camr=E2=80=9D va= lues. > > > > -- Mike > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Nat Sakimura > *Sent:* Thursday, July 23, 2015 6:22 PM > *To:* William Denniss > *Cc:* > *Subject:* Re: [OAUTH-WG] Authentication Method Reference Values > Specification > > > > So, allow me a naive question. > > I supppose there are good random otp, as well as pretty bad otp etc. > > Would it be useful to say just "otp". Would it not be better to have at > least a field that references a spec that specifies the security > requirement for that mechanism? > > > > 2015-07-23 12:05 GMT+02:00 William Denniss : > > Thanks for drafting this Mike. I'm in favor of having this registry. > > > > In addition to the specific values, I propose we add some generic ones to= o > (trying to follow your naming scheme): > > > > "rba": "risk-based auth" > > "upt": "user presence test" > > > > My fear of making things too specific is that RPs may get lost in the > weeds trying to work out what things they should care about and how. As a= n > IdP we like to guide RPs through these kinds of decisions, and prefer to > pass a more high level indication of what happened (such as these two > values). If someone wanted to have best of both worlds, then both could = be > asserted, e.g. "upt fpt" to indicate that the user presence was tested, > using a fingerprint test. > > > > Regarding the proposed "wia" value. I don't know what it is, and the spec > doesn't help me find out, can a reference be added? I also wonder if it > could be genericized to avoid being vendor specific values =E2=80=93 but = mostly I > just want to understand what it is. Almost all the other values are > self-explanatory, perhaps "pop" could use a reference as well (or maybe > just a longer explanation). > > > > I don't see the immediate value of "amr_values", can you elaborate with > some places where this would be applied? Separately, I wonder if an > extension to OIDC should be included in this doc, which is otherwise a > fairly clean registry spec that could be used more broadly. > > > > On Thu, Jul 23, 2015 at 10:49 AM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > > So maybe a naive question but why does this draft define "amr_values" > while also suggesting that it's fragile and that "acr" & "acr_values" is > preferable? Seems contradictory. And I doubt I'm the only one that will > find it confusing. > > > > On Thu, Jul 23, 2015 at 9:35 AM, Mike Jones > wrote: > > The key part of this is establishing a registry. That can only be done i= n > an RFC. > > > > John, I encourage you to submit text beefing up the arguments about why > using =E2=80=9Cacr=E2=80=9D is preferable. The text at > http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html#acrRela= tionship > > is a start at that. > > > > -- Mike > > > > *From:* John Bradley [mailto:ve7jtb@ve7jtb.com] > *Sent:* Thursday, July 23, 2015 9:30 AM > *To:* Justin Richer > *Cc:* Mike Jones; > *Subject:* Re: [OAUTH-WG] Authentication Method Reference Values > Specification > > > > I don=E2=80=99t personally have a problem with people defining values for= AMR and > creating a IANA registry. > > > > That exists for ACR. > > > > I am on record as not supporting clients requesting amr as it ai a bad > idea and the spec mentions that at the same time it defines a new request > parameter for it. > > > > It is probably not something I will put any real effort into fighting, if > people insist on it. I will continue to recommend only using ACR in the > request. > > > > John B. > > > > On Jul 23, 2015, at 9:21 AM, Justin Richer wrote: > > > > Useful work, but shouldn=E2=80=99t this be defined in the OIDF, where the= =E2=80=9Camr" > parameter is defined? > > > > =E2=80=94 Justin > > > > On Jul 22, 2015, at 7:48 PM, Mike Jones > wrote: > > > > Phil Hunt and I have posted a new draft that defines some values used wit= h > the =E2=80=9Camr=E2=80=9D (Authentication Methods References) claim and e= stablishes a > registry for Authentication Method Reference values. These values includ= e > commonly used authentication methods like =E2=80=9Cpwd=E2=80=9D (password= ) and =E2=80=9Cotp=E2=80=9D (one > time password). It also defines a parameter for requesting that specific > authentication methods be used in the authentication. > > > > The specification is available at: > > =C2=B7 https://tools.ietf.org/html/draft-jones-oauth-amr-values-00 > > > > > An HTML formatted version is also available at: > > =C2=B7 http://self-issued.info/docs/draft-jones-oauth-amr-values-0= 0.html > > > > > -- Mike > > > > P.S. This note was also posted at http://self-issued.info/?p=3D1429 > and > as @selfissued > > . > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > -- > > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > > @_nat_en > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a113fc47c9bfe61051bb2840b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There's a method of authentication that is g= aining in popularity which I'd propose adding a method for. It is typic= ally used as a second factor where after a primary auth, like username and = password, a push notification is sent to the user's phone and they ackn= owledge it from the device. We have the PingID product that does it and Entrust and Duo, among others I'm su= re, offer something similar.

It's commonly called "mo= bile push authentication" so maybe "mpa" could be the amr va= lue. But, as Nat pointed out, the really interesting characteristic is that= it's a second factor that utilizes only a secondary channel - so perha= ps "sca" for "second channel authentication" would be a= more appropriate general amr name.=C2=A0

Thoughts are welcom= e. But I believe it's becoming prevalent enough that it deserves its ow= n amr value in this doc.




On Thu, Jul 2= 3, 2015 at 6:29 PM, Mike Jones <Michael.Jones@microsoft.com&= gt; wrote:

I agree that an obvious g= ood thing to do is to add spec references to the field definitions.<= u>

=C2=A0

I need to investigate use= cases for amr_values.=C2=A0 I think this came from developers who actually= wanted this for a particular purpose but I=E2=80=99ll have to get back to the WG on that.=C2=A0 It=E2=80=99s defined here, rather than in another= spec, because it=E2=80=99s highly related to the =E2=80=9Camr=E2=80=9D val= ues.

=C2=A0

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

=C2=A0

From: OAuth [m= ailto:oauth-bou= nces@ietf.org] On Behalf Of Nat Sakimura
Sent: Thursday, July 23, 2015 6:22 PM
To: William Denniss
Cc: <oauth@ie= tf.org>
Subject: Re: [OAUTH-WG] Authentication Method Reference Values Speci= fication

=C2=A0

So, allow me a naive question.=C2=A0

I supppose there are good random otp, as well as pre= tty bad otp etc.=C2=A0

Would it be useful to say just "otp". Woul= d it not be better to have at least a field that references a spec that spe= cifies the security requirement for that mechanism?=C2=A0

=C2=A0

2015-07-23 12:05 GMT+02:00 William Denniss <wdenniss@google.com= >:

Thanks for drafting this Mike. I'm in favor of h= aving this registry.

=C2=A0

In addition to the specific values, I propose we add= some generic ones too (trying to follow your naming scheme):=

=C2=A0

"rba": =C2=A0"risk-based auth"

"upt": =C2=A0"user presence test"= ;

=C2=A0

My fear of making things too specific is that RPs ma= y get lost in the weeds trying to work out what things they should care abo= ut and how. As an IdP we like to guide RPs through these kinds of decisions= , and prefer to pass a more high level indication of what happened (such as these two values).=C2=A0 If someone w= anted to have best of both worlds, then both could be asserted, e.g. "= upt fpt" to indicate that the user presence was tested, using a finger= print test.

=C2=A0

Regarding the proposed "wia" value. I don&= #39;t know what it is, and the spec doesn't help me find out, can a ref= erence be added?=C2=A0 I also wonder if it could be genericized to avoid be= ing vendor specific values =E2=80=93 but mostly I just want to understand what it is.=C2=A0 Almost all the other values are self-explanatory, perhap= s "pop" could use a reference as well (or maybe just a longer exp= lanation).

=C2=A0

I don't see the immediate value of "amr_val= ues", can you elaborate with some places where this would be applied?= =C2=A0 Separately, I wonder if an extension to OIDC should be included in t= his doc, which is otherwise a fairly clean registry spec that could be used more broadly.

=C2=A0

On Thu, Jul 23, 2015 at 10:49 AM, Brian Campbell <= ;bcampbell@= pingidentity.com> wrote:

So maybe a naive question but why does this draft de= fine "amr_values" while also suggesting that it's fragile and= that "acr" & "acr_values" is preferable? Seems con= tradictory. And I doubt I'm the only one that will find it confusing.= =C2=A0

=C2=A0

On Thu, Jul 23, 2015 at 9:35 AM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

The key part of this is e= stablishing a registry.=C2=A0 That can only be done in an RFC.

=C2=A0

John, I encourage = you to submit text beefing up the arguments about why using =E2=80=9Cacr=E2= =80=9D is preferable.=C2=A0 The text at http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html#acrRelati= onship is a start at that.

=C2=A0

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

=C2=A0

From: John Bra= dley [mailto:ve7jtb@= ve7jtb.com]
Sent: Thursday, July 23, 2015 9:30 AM
To: Justin Richer
Cc: Mike Jones; <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Authentication Method Reference Values Speci= fication

=C2=A0

I don=E2=80=99t personally have a problem with peopl= e defining values for AMR and creating a IANA registry.=C2=A0=

=C2=A0

That exists for ACR.

=C2=A0

I am on record as not supporting clients requesting = amr as it ai a bad idea and the spec mentions that at the same time it defi= nes a new request parameter for it.

=C2=A0

It is probably not something I will put any real eff= ort into fighting, if people insist on it.=C2=A0 I will continue to recomme= nd only using ACR in the request.

=C2=A0

John B.

=C2=A0

On Jul 23, 2015, at 9:21 AM, Justin Richer <jricher@mit.edu> wro= te:

=C2=A0

Useful work, but shouldn=E2=80=99t thi= s be defined in the OIDF, where the =E2=80=9Camr" parameter is defined= ?

=C2=A0

=C2=A0=E2=80=94 Justin

=C2=A0

On Jul 22, 2015, at 7:48 PM, Mike Jone= s <Michael.Jones@microsoft.com> wrote:

=C2=A0

Phil Hunt and I have posted a new draft= that defines some values used with the =E2=80=9Camr= =E2=80=9D (Authentication Methods References) claim and establishes a registry for A= uthentication Method Reference values.=C2=A0 These values include commonly = used authentication methods like =E2=80=9Cpwd=E2=80=9D (password) and =E2=80=9Cotp=E2=80=9D (one time passwo= rd).=C2=A0 It also defines a parameter for requesting that specific authent= ication methods be used in the authentication.

=C2=A0

The specification is available at:

= =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0https://tools.ietf.org/html/draft-jones-oa= uth-amr-values-00

=C2=A0

An HTML formatted version is also avail= able at:

= =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0http://self-issued.info/docs/draft= -jones-oauth-amr-values-00.html

=C2=A0

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

=C2=A0

P.S.=C2=A0 This note was also posted at= =C2=A0http://self-issued.info/?p=3D= 1429=C2=A0and as=C2=A0@selfissued.

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

=C2=A0

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

=C2=A0


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

=C2=A0


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

=C2=A0


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



=C2=A0

--

Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
= http://nat.sakimura.org/
@_nat_en


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


--001a113fc47c9bfe61051bb2840b-- From nobody Sun Jul 26 11:48:31 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D491ACD5B for ; Sun, 26 Jul 2015 11:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kLji-5WSlgo for ; Sun, 26 Jul 2015 11:48:18 -0700 (PDT) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0CC41ACD74 for ; Sun, 26 Jul 2015 11:48:17 -0700 (PDT) Received: by iecrl10 with SMTP id rl10so46269664iec.1 for ; Sun, 26 Jul 2015 11:48:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YioQVR6+nEdcGEnYCacs3PIt15g7ZRlNdRvbEBBetmc=; b=bDilf5X+X/HwCpZHyl4cYrgcMli03GUNcHN7YQrfIQaKqE1ptZ/yWGPHx/cu0X+Fpz Pyc/qaXyF+XJfm/z0EXNB+BJ/Pf+53DPbKe9MVEjsySRxyI7E7Gylj/JeQcMN+PE70Fa 81uws5NUkLxajWWQ2GPwzX5IIyU0Yte8IfpugRY8E9nrqTFKnwzf46rHA9OYt/ulOXGE FPIjdLf8RF7p14Vc2KlGKaYBx8GuCfbRJ1k6yyes1ZX3v4v3f1Lky5rS8+4HwsXDrzgu 6rypIVjzcnouuHgfN3iE+LCRuWmNLAXnH/Ci0EqERCU20Rj644avbqwxiGqc9xfcXc0S tt8Q== X-Gm-Message-State: ALoCoQl6GoeftUwghh6x9iweS+bCNa2SwPQJQkNeESrxi2SIJ1cIaJyIVAwTszybFJ8YYYXhNQaa X-Received: by 10.107.47.26 with SMTP id j26mr37769436ioo.17.1437936497048; Sun, 26 Jul 2015 11:48:17 -0700 (PDT) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com. [209.85.213.173]) by smtp.gmail.com with ESMTPSA id 15sm10189936iop.3.2015.07.26.11.48.14 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Jul 2015 11:48:14 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so52455943igb.0 for ; Sun, 26 Jul 2015 11:48:13 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.102.98 with SMTP id fn2mr11452138igb.55.1437936493664; Sun, 26 Jul 2015 11:48:13 -0700 (PDT) Received: by 10.107.20.84 with HTTP; Sun, 26 Jul 2015 11:48:13 -0700 (PDT) In-Reply-To: References: <0F2B6432-4D9E-4277-BFFE-5F0354A6D9B7@mit.edu> <89B75723-0C59-4AF3-BC8E-166A63ED39EB@mit.edu> Date: Sun, 26 Jul 2015 11:48:13 -0700 Message-ID: From: Aaron Parecki To: William Denniss Content-Type: multipart/alternative; boundary=047d7b10caa7ea27c0051bcbadde Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Token introspection for public clients? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2015 18:48:27 -0000 --047d7b10caa7ea27c0051bcbadde Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Okay, I understand more of the intent of this document now. I will say that the first time I read it, it was not at all clear that it was not intended for OAuth 2.0 clients to use this endpoint. It seems now that it is only intended for internal servers to use, such as when a resource server is verifying an access token. I think the part that threw me off was that OAuth 2.0 client authentication was mentioned as one of the mechanisms of providing authorization to use the introspection endpoint: https://tools.ietf.org/html/draft-ietf-oauth-introspection-11#section-2.1 Hopefully that feedback is helpful. That said, I also agree with William's assessment. ---- Aaron Parecki aaronparecki.com @aaronpk On Tue, Jul 21, 2015 at 4:05 PM, William Denniss wrote: > We had a good sync on this topic offline on Monday, and it seemed the > consensus was that if clients need to introspect access tokens they are > doing something wrong. > > That said, looking only at the resource server use-case, I still think th= e > MUST is problematic. > > The out of band authentication requirement when accompanied with the MUST > makes the spec less useful. i.e. "the endpoint MUST also require some fo= rm > of authorization to access this endpoint", but "The specifics of this > authentication credentials are out of scope of this specification". This > makes dynamic discovery which was mentioned as potentially applying to th= is > spec virtually useless (you discovered the introspection endpoint, but ho= w > do you discover how to authenticate?). It also adds to general > implementation complexity. > > Brian mentioned that in their implementation, they decided not to force > authentication for introspection by resource servers as they were > protecting the endpoint through other means, and wanted to reduce > complexity for developers. The MUST here constrains that decision, one > which I think should be left up to the provider. > > Lastly, the MUST is presented in the spec as being required to prevent > token scanning, and yet there are other ways to mitigate that attack. If > there are better reasons than token scanning for this remaining a MUST, > then I think the spec should document them. > > Side note: If you prevent token scanning through other means, the main > benefit of still requiring authentication seems to be preventing > information leaking out to a client who is in possession of the access > token but isn't the intended audience. This may or may not be an issue > depending on the contents of the introspection response. Perhaps it would > be good to mention this in the security considerations, as it's something > that should be considered by implementors. Given the sensitivity of > information revealed by the introspection endpoint varies, I don't think > that this alone would mandate the MUST. > > > > On Tue, Jul 21, 2015 at 10:03 AM, Justin Richer wrote: > >> Just use the token at your target API and see if it works. Your client= =E2=80=99s >> going to need to be able to get a new token if this one expires mid-sess= ion >> anyway, so you=E2=80=99re not saving anything by doing an introspection = request. >> >> =E2=80=94 Justin >> >> On Jul 20, 2015, at 9:34 PM, Aaron Parecki wrote: >> >> I'm looking for a way to check if an existing token is still valid. >> Imagine a client is holding on to a token between user sessions, for >> example if it's making API requests for the user on a cron job. When the >> user returns to the site, I want to check if the token is still valid, a= nd >> make them sign in again if not. >> >> Aaron >> >> On Mon, Jul 20, 2015 at 12:11 PM John Bradley wrote: >> >>> If you want the resource owner/user then get a id_token from the token >>> endpoint. That saves another call to a introspection endpoint. >>> >>> Sent from my iPhone >>> >>> On Jul 20, 2015, at 7:49 PM, Aaron Parecki wrote: >>> >>> Okay, if the intent is for this endpoint to be used by the resource >>> server, this all makes sense. I was under the impression that it could = also >>> be used by clients to verify if the token is valid. Is there some other >>> spec I could look at that is intended to be used by clients to verify i= f a >>> token is valid and find out the user ID associated with it? >>> >>> ---- >>> Aaron Parecki >>> aaronparecki.com >>> @aaronpk >>> >>> >>> On Sun, Jul 19, 2015 at 10:01 PM, Justin Richer wrote= : >>> >>>> Because the target isn=E2=80=99t the client, it=E2=80=99s the protecte= d resource. We=E2=80=99re >>>> re-using OAuth=E2=80=99s client credentialing mechanisms (optionally, = you can use >>>> whatever you deem necessary), but it=E2=80=99s not a client that=E2=80= =99s doing it. That=E2=80=99s >>>> why it was changed to a MUST =E2=80=94 there may be public clients out= there (which >>>> could also use RFC7591 to become non-public), but public resource serv= ers >>>> don=E2=80=99t make nearly as much sense. >>>> >>>> Additionally, the discussion for this was back in December during the >>>> WGLC, and the time for normative changes to this particular spec is la= rgely >>>> over at this stage. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Jul 20, 2015, at 12:03 AM, William Denniss >>>> wrote: >>>> >>>> I see in earlier drafts that client authentication MUST was a SHOULD. >>>> >>>> Why not put it back to a SHOULD, and make these arguments in the >>>> Security Considerations? By the sound of it in some implementations t= here >>>> are good reasons for doing client authentication, but they may not app= ly to >>>> everyone, so do we need to be so prescriptive? An error response can = be >>>> added for requests the server deems require client authentication. >>>> >>>> It wouldn't have to be an all-or-nothing policy choice either, a serve= r >>>> could chose to reject requests from confidential clients where client >>>> authentication is not provided, but accept requests without client >>>> authentication from non-confidential clients. A server that has >>>> sufficiently high entropy in the tokens, abuse protection on the endpo= int, >>>> and is not concerned about an unrelated party (that happens to have a = token >>>> intended for a different party) learning the token metadata, could sim= ply >>>> not require any client authentication at all. >>>> >>>> Apart from anything, it is really trivial to support non-confidential >>>> client usage, so why not? Perhaps there are some use-cases that will = turn >>>> up in the future (especially since as defined the introspection respon= se is >>>> extensible). One I can think of now is debugging: it's useful during >>>> development to be able to inspect the tokens you get back from the AS. >>>> >>>> Best, >>>> William >>>> >>>> >>>> On Sun, Jul 19, 2015 at 9:14 PM, Justin Richer wrote= : >>>> >>>>> In the case of a =E2=80=9Cpublic client=E2=80=9D using a token, the a= uthorization is >>>>> the token that the resource server uses to call the introspection end= point, >>>>> along side the token that it is introspecting. This is exactly how th= e UMA >>>>> protocol works: the resource server has a =E2=80=9CProtection API Tok= en=E2=80=9D that it >>>>> uses to call several endpoints at the AS, including the introspection >>>>> endpoint. In UMA, this PAT is given to the resource server through a = normal >>>>> OAuth transaction with an end user who facilitates the RS->AS introdu= ction. >>>>> >>>>> And I think this is all actually a moot point because *clients* >>>>> shouldn=E2=80=99t be doing the introspection in the first place =E2= =80=94 the whole spec is >>>>> there to support *resource servers* introspecting at the auth server. >>>>> So you probably don=E2=80=99t have =E2=80=9Cpublic client resource se= rvers=E2=80=9D out there. We >>>>> simply re-used OAuth=E2=80=99s existing client authentication mechani= sm, that >>>>> doesn=E2=80=99t make them clients. This decision is based on developm= ent and >>>>> deployment experience (as in, several people independently built it e= xactly >>>>> this way). Do you have a use case where you=E2=80=99ve got a protecte= d resource >>>>> that can=E2=80=99t hold credentials (either a client secret or a publ= ic/private >>>>> keypair) to authenticate with, and can=E2=80=99t be introduced using = OAuth to the >>>>> AS as in UMA? >>>>> >>>>> To your other point: An attacker has less of a chance of getting >>>>> information about a token by fishing at a protected resource with tok= ens, >>>>> since they=E2=80=99re not being returned information about the token = other than the >>>>> fact that the token worked. (Or at least it seemed to work because a = result >>>>> came back =E2=80=94 you could easily give a suspected attacker >>>>> valid-looking-but-fake data as one mitigation mechanism.) The introsp= ection >>>>> response can give you information about where else the token could be= used, >>>>> potentially. Additionally, the RS really ought to be preventing >>>>> data-fishing attacks like this just for its own sake anyway. There ar= e lots >>>>> of techniques for doing this, but they tend to be specific to the kin= d of >>>>> API that=E2=80=99s being served. >>>>> >>>>> Requiring the resource server to authenticate with the authorization >>>>> server also allows you to do a few other useful things. Our implement= ation, >>>>> for example, limits the token information that is returned to a parti= cular >>>>> AS. This allows us to have tokens that can be used in multiple RS=E2= =80=99s without >>>>> those RS=E2=80=99s ever even knowing the token is powerful enough to = be used >>>>> elsewhere. It prevents information about the authorization from leaki= ng to >>>>> parties who have no business knowing. >>>>> >>>>> Hope this helps clarify it, >>>>> =E2=80=94 Justin >>>>> >>>>> On Jul 19, 2015, at 7:59 PM, Aaron Parecki wrote: >>>>> >>>>> How are public clients supposed to authenticate if there is no secret= ? >>>>> >>>>> Isn't "fishing for valid tokens" just as much of an issue at the >>>>> resource server? I don't see how having the introspection endpoint re= quire >>>>> client authentication actually solves the fishing problem since attac= kers >>>>> could just fish against the resource server. In fact, if the resource >>>>> server queries the introspection endpoint to check if tokens are vali= d, >>>>> then that effectively gives an attacker a way to fish for tokens usin= g the >>>>> resource server's credentials. >>>>> >>>>> --- >>>>> Aaron Parecki >>>>> http://aaronparecki.com >>>>> >>>>> On Sat, Jul 18, 2015 at 10:04 PM Justin Richer >>>>> wrote: >>>>> >>>>>> Public clients can use the token-based auth mechanism, can=E2=80=99t= they? If >>>>>> you don=E2=80=99t have some form of authentication on the introspect= ion endpoint, >>>>>> you end up with a way for people to anonymously and programmatically= fish >>>>>> for valid token values. >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> On Jul 19, 2015, at 6:30 AM, Aaron Parecki wrote= : >>>>>> >>>>>> The introspection draft states that the introspection endpoint MUST >>>>>> require authentication of clients. It mentions either client authent= ication >>>>>> (id+secret) or a separate bearer token. >>>>>> >>>>>> How are public clients expected to use the token introspection >>>>>> endpoint? I didn't see a note in the document about that at all. >>>>>> >>>>>> ---- >>>>>> Aaron Parecki >>>>>> aaronparecki.com >>>>>> @aaronpk >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@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 >> >> > --047d7b10caa7ea27c0051bcbadde Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Okay, I understand more of the intent of this document now= . I will say that the first time I read it, it was not at all clear that it= was not intended for OAuth 2.0 clients to use this endpoint. It seems now = that it is only intended for internal servers to use, such as when a resour= ce server is verifying an access token. I think the part that threw me off = was that OAuth 2.0 client authentication was mentioned as one of the mechan= isms of providing authorization to use the introspection endpoint:=C2=A0https://tools.ietf.org/html/draft-ietf-oauth-introspection-11#secti= on-2.1 Hopefully that feedback is helpful.=C2=A0

Tha= t said, I also agree with William's assessment.

----
Aaron Parecki


On Tue, Jul 21, 2015 at 4:05 PM, William Den= niss <wdenniss@google.com> wrote:
We had a good sync on this topic offline on Mond= ay, and it seemed the consensus was that if clients need to introspect acce= ss tokens they are doing something wrong.

That said, loo= king only at the resource server use-case, I still think the MUST is proble= matic.

The out of band authentication require= ment when accompanied with the MUST makes the spec less useful. =C2=A0i.e. = "the endpoint MUST also require some form of authorization to access t= his endpoint", but "The specifics of this authentication credenti= als are out of scope of this specification".=C2=A0 This makes dynamic = discovery which was mentioned as potentially applying to this spec virtuall= y useless (you discovered the introspection endpoint, but how do you discov= er how to authenticate?). It also adds to general implementation complexity= .

Brian mentioned that in their implementation, th= ey decided not to force authentication for introspection by resource server= s as they were protecting the endpoint through other means, and wanted to r= educe complexity for developers. The MUST here constrains that decision, on= e which I think should be left up to the provider.

Lastly, the MUST is presented in the spec as being required to prevent tok= en scanning, and yet there are other ways to mitigate that attack. If there= are better reasons than token scanning for this remaining a MUST, then I t= hink the spec should document them.

Side note: If = you prevent token scanning through other means, the main benefit of still r= equiring authentication seems to be preventing information leaking out to a= client who is in possession of the access token but isn't the intended= audience. This may or may not be an issue depending on the contents of the= introspection response. Perhaps it would be good to mention this in the se= curity considerations, as it's something that should be considered by i= mplementors.=C2=A0 Given the sensitivity of information revealed by the int= rospection endpoint varies, I don't think that this alone would mandate= the MUST. =C2=A0



On Tue, Jul 21, 2015 at 10:03 AM, Justin Richer <jricher@mit.edu> wrote:
Just u= se the token at your target API and see if it works. Your client=E2=80=99s = going to need to be able to get a new token if this one expires mid-session= anyway, so you=E2=80=99re not saving anything by doing an introspection re= quest.

=C2=A0=E2=80=94 Justin

On Jul 20, 2015, at 9:34 PM, Aaron Parecki &l= t;aaron@parecki.com<= /a>> wrote:

I'm looking for a way to chec= k if an existing token is still valid. Imagine a client is holding on to a = token between user sessions, for example if it's making API requests fo= r the user on a cron job. When the user returns to the site, I want to chec= k if the token is still valid, and make them sign in again if not.

= Aaron

On Mon, Jul 20, 2015 a= t 12:11 PM John Bradley <ve7jtb@ve7jtb.com> wrote:
<= div dir=3D"auto">
If you want the resource owner/user then get a id_tok= en from the token endpoint.=C2=A0 That saves another call to a introspectio= n endpoint. =C2=A0=C2=A0

Sent from my iPhone

On Jul 20, 2015, at 7:49 PM, Aaron Parecki <= aaron@parecki.com> wrote:

Okay, if the intent is for this endpoint to be used by the reso= urce server, this all makes sense. I was under the impression that it could= also be used by clients to verify if the token is valid. Is there some oth= er spec I could look at that is intended to be used by clients to verify if= a token is valid and find out the user ID associated with it?


On Sun, Jul 19, 2015 at 10:01 PM, Justin Ric= her <jricher@mit.edu> wrote:
Because the target isn=E2=80=99t the client, it=E2= =80=99s the protected resource. We=E2=80=99re re-using OAuth=E2=80=99s clie= nt credentialing mechanisms (optionally, you can use whatever you deem nece= ssary), but it=E2=80=99s not a client that=E2=80=99s doing it. That=E2=80= =99s why it was changed to a MUST =E2=80=94 there may be public clients out= there (which could also use RFC7591 to become non-public), but public reso= urce servers don=E2=80=99t make nearly as much sense.

Ad= ditionally, the discussion for this was back in December during the WGLC, a= nd the time for normative changes to this particular spec is largely over a= t this stage.

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

On Jul 20, 2015, at 12:03 AM, William Denniss <wdenniss@google.com> wrote= :

I see in earlier drafts that client authen= tication MUST was a SHOULD.

Why not put it back to a SHO= ULD, and make these arguments in the Security Considerations?=C2=A0 By the = sound of it in some implementations there are good reasons for doing client= authentication, but they may not apply to everyone, so do we need to be so= prescriptive?=C2=A0 An error response can be added for requests the server= deems require client authentication.

It wouldn= 9;t have to be an all-or-nothing policy choice either, a server could chose= to reject requests from confidential clients where client authentication i= s not provided, but accept requests without client authentication from non-= confidential clients.=C2=A0 A server that has sufficiently high entropy in = the tokens, abuse protection on the endpoint, and is not concerned about an= unrelated party (that happens to have a token intended for a different par= ty) learning the token metadata, could simply not require any client authen= tication at all.

Apart from anything, it is really= trivial to support non-confidential client usage, so why not?=C2=A0 Perhap= s there are some use-cases that will turn up in the future (especially sinc= e as defined the introspection response is extensible). One I can think of = now is debugging: it's useful during development to be able to inspect = the tokens you get back from the AS.

Best,
William


On Sun, Jul 19, 2015 at 9:14 PM, Justin Richer <jricher@m= it.edu> wrote:
In the case of a =E2=80=9Cpublic client=E2=80=9D using a token, t= he authorization is the token that the resource server uses to call the int= rospection endpoint, along side the token that it is introspecting. This is= exactly how the UMA protocol works: the resource server has a =E2=80=9CPro= tection API Token=E2=80=9D that it uses to call several endpoints at the AS= , including the introspection endpoint. In UMA, this PAT is given to the re= source server through a normal OAuth transaction with an end user who facil= itates the RS->AS introduction.

And I think this is a= ll actually a moot point because clients shouldn=E2=80=99t be doing = the introspection in the first place =E2=80=94 the whole spec is there to s= upport resource servers introspecting at the auth server. So you pro= bably don=E2=80=99t have =E2=80=9Cpublic client resource servers=E2=80=9D o= ut there. We simply re-used OAuth=E2=80=99s existing client authentication = mechanism, that doesn=E2=80=99t make them clients. This decision is based o= n development and deployment experience (as in, several people independentl= y built it exactly this way). Do you have a use case where you=E2=80=99ve g= ot a protected resource that can=E2=80=99t hold credentials (either a clien= t secret or a public/private keypair) to authenticate with, and can=E2=80= =99t be introduced using OAuth to the AS as in UMA?

To y= our other point: An attacker has less of a chance of getting information ab= out a token by fishing at a protected resource with tokens, since they=E2= =80=99re not being returned information about the token other than the fact= that the token worked. (Or at least it seemed to work because a result cam= e back =E2=80=94 you could easily give a suspected attacker valid-looking-b= ut-fake data as one mitigation mechanism.) The introspection response can g= ive you information about where else the token could be used, potentially. = Additionally, the RS really ought to be preventing data-fishing attacks lik= e this just for its own sake anyway. There are lots of techniques for doing= this, but they tend to be specific to the kind of API that=E2=80=99s being= served.

Requiring the resource server to authenti= cate with the authorization server also allows you to do a few other useful= things. Our implementation, for example, limits the token information that= is returned to a particular AS. This allows us to have tokens that can be = used in multiple RS=E2=80=99s without those RS=E2=80=99s ever even knowing = the token is powerful enough to be used elsewhere. It prevents information = about the authorization from leaking to parties who have no business knowin= g.

Hope this helps clarify it,
=C2=A0=E2= =80=94 Justin

On Ju= l 19, 2015, at 7:59 PM, Aaron Parecki <aaron@parecki.com> wrote:

How are public clients supposed to authenticate if there is no secre= t?

Isn't "fishing for valid tokens" just as much of an= issue at the resource server? I don't see how having the introspection= endpoint require client authentication actually solves the fishing problem= since attackers could just fish against the resource server. In fact, if t= he resource server queries the introspection endpoint to check if tokens ar= e valid, then that effectively gives an attacker a way to fish for tokens u= sing the resource server's credentials.

---
Aaron Pareckihttp://aaron= parecki.com

On Sat, Jul 18, 201= 5 at 10:04 PM Justin Richer <jricher@mit.edu> wrote:
Public clients can use the token-based auth mecha= nism, can=E2=80=99t they? If you don=E2=80=99t have some form of authentica= tion on the introspection endpoint, you end up with a way for people to ano= nymously and programmatically fish for valid token values.=C2=A0

=C2=A0=E2=80=94 Justin

<= div>
On Jul 19, 2015, at 6:30 AM, Aaron Parec= ki <aaron@parecki= .com> wrote:

The introspection draft states that the introspection endpoint MUS= T require authentication of clients. It mentions either client authenticati= on (id+secret) or a separate bearer token.

How are= public clients expected to use the token introspection endpoint? I didn= 9;t see a note in the document about that at all.

= ----
Aaron Parecki

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


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




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


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



--047d7b10caa7ea27c0051bcbadde-- From nobody Sun Jul 26 13:02:36 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D9F1A88FF for ; Sun, 26 Jul 2015 13:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.072 X-Spam-Level: X-Spam-Status: No, score=0.072 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URI_NO_WWW_INFO_CGI=2.071] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yi6IeTrm7mA9 for ; Sun, 26 Jul 2015 13:02:32 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 216F81A88F1 for ; Sun, 26 Jul 2015 13:02:32 -0700 (PDT) Received: by obre1 with SMTP id e1so46391469obr.1 for ; Sun, 26 Jul 2015 13:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QYG+NGf1u+2H51OAIkSWyaRwl7tkI9zdTSnqxtXz1TI=; b=tcakPvL3MKDPXSa3evO81OREY2d6e1+wjTiGIVM/nv9i/xc5YZucNFjvjOJ93D32Qv esx2ezMWiHNr+J5J/CSg8mivv0grtzMP1FWSvRYmMrdKlDmW5GQXyd8564MwGXvvo5sU 4+2XRatIVzS9tEJGN0kjDo6synWls3LC690yoRdYHTZbIg8yQ4Cw7NqqztS51tFTA43K kuC1HiX+lmDOykWY/2YfyuYR2iT6luB+Z8LX1xIDOBHFpLsup0DPobJ6J3IfFzdg/C3i 3rVTwiJNqqeu+kExVQ7hOm4q+ZHXKe6OpI6bu1h4qWp3B1TSvyoh7fleirGojzWEjs/l 4rzA== MIME-Version: 1.0 X-Received: by 10.182.103.201 with SMTP id fy9mr25400950obb.66.1437940951460; Sun, 26 Jul 2015 13:02:31 -0700 (PDT) Received: by 10.182.96.66 with HTTP; Sun, 26 Jul 2015 13:02:31 -0700 (PDT) In-Reply-To: References: <8BADFB60-1BE4-415A-B386-F34F9FE72A3C@mit.edu> <61575F9A-8A0F-415A-89AA-480432813020@ve7jtb.com> Date: Mon, 27 Jul 2015 05:02:31 +0900 Message-ID: From: Nat Sakimura To: Brian Campbell Content-Type: multipart/alternative; boundary=089e013c66b09eb1e3051bccb709 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Authentication Method Reference Values Specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2015 20:02:35 -0000 --089e013c66b09eb1e3051bccb709 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am in favor of William's proposal. In addition, I would like to see one for 2nd channel auth, 2ch. That would indicate some resilience against MITB. On Saturday, July 25, 2015, Brian Campbell wrote: > There's a method of authentication that is gaining in popularity which I'= d > propose adding a method for. It is typically used as a second factor wher= e > after a primary auth, like username and password, a push notification is > sent to the user's phone and they acknowledge it from the device. We have > the PingID product > that does it and Entrust > > and Duo , among > others I'm sure, offer something similar. > > It's commonly called "mobile push authentication" so maybe "mpa" could be > the amr value. But, as Nat pointed out, the really interesting > characteristic is that it's a second factor that utilizes only a secondar= y > channel - so perhaps "sca" for "second channel authentication" would be a > more appropriate general amr name. > > Thoughts are welcome. But I believe it's becoming prevalent enough that i= t > deserves its own amr value in this doc. > > > > > On Thu, Jul 23, 2015 at 6:29 PM, Mike Jones > wrote: > >> I agree that an obvious good thing to do is to add spec references to >> the field definitions. >> >> >> >> I need to investigate use cases for amr_values. I think this came from >> developers who actually wanted this for a particular purpose but I=E2=80= =99ll have >> to get back to the WG on that. It=E2=80=99s defined here, rather than i= n another >> spec, because it=E2=80=99s highly related to the =E2=80=9Camr=E2=80=9D v= alues. >> >> >> >> -- Mike >> >> >> >> *From:* OAuth [mailto:oauth-bounces@ietf.org >> ] *On Behalf Of = *Nat >> Sakimura >> *Sent:* Thursday, July 23, 2015 6:22 PM >> *To:* William Denniss >> *Cc:* > >> *Subject:* Re: [OAUTH-WG] Authentication Method Reference Values >> Specification >> >> >> >> So, allow me a naive question. >> >> I supppose there are good random otp, as well as pretty bad otp etc. >> >> Would it be useful to say just "otp". Would it not be better to have at >> least a field that references a spec that specifies the security >> requirement for that mechanism? >> >> >> >> 2015-07-23 12:05 GMT+02:00 William Denniss > >: >> >> Thanks for drafting this Mike. I'm in favor of having this registry. >> >> >> >> In addition to the specific values, I propose we add some generic ones >> too (trying to follow your naming scheme): >> >> >> >> "rba": "risk-based auth" >> >> "upt": "user presence test" >> >> >> >> My fear of making things too specific is that RPs may get lost in the >> weeds trying to work out what things they should care about and how. As = an >> IdP we like to guide RPs through these kinds of decisions, and prefer to >> pass a more high level indication of what happened (such as these two >> values). If someone wanted to have best of both worlds, then both could= be >> asserted, e.g. "upt fpt" to indicate that the user presence was tested, >> using a fingerprint test. >> >> >> >> Regarding the proposed "wia" value. I don't know what it is, and the spe= c >> doesn't help me find out, can a reference be added? I also wonder if it >> could be genericized to avoid being vendor specific values =E2=80=93 but= mostly I >> just want to understand what it is. Almost all the other values are >> self-explanatory, perhaps "pop" could use a reference as well (or maybe >> just a longer explanation). >> >> >> >> I don't see the immediate value of "amr_values", can you elaborate with >> some places where this would be applied? Separately, I wonder if an >> extension to OIDC should be included in this doc, which is otherwise a >> fairly clean registry spec that could be used more broadly. >> >> >> >> On Thu, Jul 23, 2015 at 10:49 AM, Brian Campbell < >> bcampbell@pingidentity.com >> > wrote: >> >> So maybe a naive question but why does this draft define "amr_values" >> while also suggesting that it's fragile and that "acr" & "acr_values" is >> preferable? Seems contradictory. And I doubt I'm the only one that will >> find it confusing. >> >> >> >> On Thu, Jul 23, 2015 at 9:35 AM, Mike Jones > > wrote: >> >> The key part of this is establishing a registry. That can only be done >> in an RFC. >> >> >> >> John, I encourage you to submit text beefing up the arguments about why >> using =E2=80=9Cacr=E2=80=9D is preferable. The text at >> http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html#acrRel= ationship >> >> is a start at that. >> >> >> >> -- Mike >> >> >> >> *From:* John Bradley [mailto:ve7jtb@ve7jtb.com >> ] >> *Sent:* Thursday, July 23, 2015 9:30 AM >> *To:* Justin Richer >> *Cc:* Mike Jones; > > >> *Subject:* Re: [OAUTH-WG] Authentication Method Reference Values >> Specification >> >> >> >> I don=E2=80=99t personally have a problem with people defining values fo= r AMR and >> creating a IANA registry. >> >> >> >> That exists for ACR. >> >> >> >> I am on record as not supporting clients requesting amr as it ai a bad >> idea and the spec mentions that at the same time it defines a new reques= t >> parameter for it. >> >> >> >> It is probably not something I will put any real effort into fighting, i= f >> people insist on it. I will continue to recommend only using ACR in the >> request. >> >> >> >> John B. >> >> >> >> On Jul 23, 2015, at 9:21 AM, Justin Richer > > wrote: >> >> >> >> Useful work, but shouldn=E2=80=99t this be defined in the OIDF, where th= e =E2=80=9Camr" >> parameter is defined? >> >> >> >> =E2=80=94 Justin >> >> >> >> On Jul 22, 2015, at 7:48 PM, Mike Jones > > wrote: >> >> >> >> Phil Hunt and I have posted a new draft that defines some values used >> with the =E2=80=9Camr=E2=80=9D (Authentication Methods References) claim= and establishes >> a registry for Authentication Method Reference values. These values >> include commonly used authentication methods like =E2=80=9Cpwd=E2=80=9D = (password) and =E2=80=9C >> otp=E2=80=9D (one time password). It also defines a parameter for reque= sting >> that specific authentication methods be used in the authentication. >> >> >> >> The specification is available at: >> >> =C2=B7 https://tools.ietf.org/html/draft-jones-oauth-amr-values-0= 0 >> >> >> >> >> An HTML formatted version is also available at: >> >> =C2=B7 >> http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html >> >> >> >> >> -- Mike >> >> >> >> P.S. This note was also posted at http://self-issued.info/?p=3D1429 >> and >> as @selfissued >> >> . >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> >> >> -- >> >> Nat Sakimura (=3Dnat) >> >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> >> @_nat_en >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --089e013c66b09eb1e3051bccb709 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am in favor of William's proposal.=C2=A0
In addition, I would lik= e to see one for=C2=A02nd channel auth, 2ch. That would indicate some resil= ience against MITB.=C2=A0

On Saturday, July 25, 2015, B= rian Campbell <bcampbell@p= ingidentity.com> wrote:
There's a method of authentication that is gaining i= n popularity which I'd propose adding a method for. It is typically use= d as a second factor where after a primary auth, like username and password= , a push notification is sent to the user's phone and they acknowledge = it from the device. We have the PingID product that does it and= Entrust and= Duo, among others I'm sure, offer something similar.
It's commonly called "mobile push authentication" = so maybe "mpa" could be the amr value. But, as Nat pointed out, t= he really interesting characteristic is that it's a second factor that = utilizes only a secondary channel - so perhaps "sca" for "se= cond channel authentication" would be a more appropriate general amr n= ame.=C2=A0

Thoughts are welcome. But I believe it's becom= ing prevalent enough that it deserves its own amr value in this doc.



=
On Thu, Jul 23, 2015 at 6:29 PM, Mike Jones = <Michael.Jones@microsof= t.com> wrote:

I agree that an obvious g= ood thing to do is to add spec references to the field definitions.<= u>

=C2=A0

I need to investigate use= cases for amr_values.=C2=A0 I think this came from developers who actually= wanted this for a particular purpose but I=E2=80=99ll have to get back to the WG on that.=C2=A0 It=E2=80=99s defined here, rather than in another= spec, because it=E2=80=99s highly related to the =E2=80=9Camr=E2=80=9D val= ues.

=C2=A0

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

=C2=A0

From: OAuth [m= ailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura
Sent: Thursday, July 23, 2015 6:22 PM
To: William Denniss
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Authentication Method Reference Values Speci= fication

=C2=A0

So, allow me a naive question.=C2=A0

I supppose there are good random otp, as well as pre= tty bad otp etc.=C2=A0

Would it be useful to say just "otp". Woul= d it not be better to have at least a field that references a spec that spe= cifies the security requirement for that mechanism?=C2=A0

=C2=A0

2015-07-23 12:05 GMT+02:00 William Denniss <wdenniss@google.com>:

Thanks for drafting this Mike. I'm in favor of h= aving this registry.

=C2=A0

In addition to the specific values, I propose we add= some generic ones too (trying to follow your naming scheme):=

=C2=A0

"rba": =C2=A0"risk-based auth"

"upt": =C2=A0"user presence test"= ;

=C2=A0

My fear of making things too specific is that RPs ma= y get lost in the weeds trying to work out what things they should care abo= ut and how. As an IdP we like to guide RPs through these kinds of decisions= , and prefer to pass a more high level indication of what happened (such as these two values).=C2=A0 If someone w= anted to have best of both worlds, then both could be asserted, e.g. "= upt fpt" to indicate that the user presence was tested, using a finger= print test.

=C2=A0

Regarding the proposed "wia" value. I don&= #39;t know what it is, and the spec doesn't help me find out, can a ref= erence be added?=C2=A0 I also wonder if it could be genericized to avoid be= ing vendor specific values =E2=80=93 but mostly I just want to understand what it is.=C2=A0 Almost all the other values are self-explanatory, perhap= s "pop" could use a reference as well (or maybe just a longer exp= lanation).

=C2=A0

I don't see the immediate value of "amr_val= ues", can you elaborate with some places where this would be applied?= =C2=A0 Separately, I wonder if an extension to OIDC should be included in t= his doc, which is otherwise a fairly clean registry spec that could be used more broadly.

=C2=A0

On Thu, Jul 23, 2015 at 10:49 AM, Brian Campbell <= ;bcampbell@pingidentity.com> wrote:=

So maybe a naive question but why does this draft de= fine "amr_values" while also suggesting that it's fragile and= that "acr" & "acr_values" is preferable? Seems con= tradictory. And I doubt I'm the only one that will find it confusing.= =C2=A0

=C2=A0

On Thu, Jul 23, 2015 at 9:35 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

The key part of this is e= stablishing a registry.=C2=A0 That can only be done in an RFC.

=C2=A0

John, I encourage = you to submit text beefing up the arguments about why using =E2=80=9Cacr=E2= =80=9D is preferable.=C2=A0 The text at http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html#acrRelati= onship is a start at that.

=C2=A0

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

=C2=A0

From: John Bra= dley [mailto:ve7jtb@ve7jtb.com]
Sent: Thursday, July 23, 2015 9:30 AM
To: Justin Richer
Cc: Mike Jones; <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Authentication Method Reference Values Speci= fication

=C2=A0

I don=E2=80=99t personally have a problem with peopl= e defining values for AMR and creating a IANA registry.=C2=A0=

=C2=A0

That exists for ACR.

=C2=A0

I am on record as not supporting clients requesting = amr as it ai a bad idea and the spec mentions that at the same time it defi= nes a new request parameter for it.

=C2=A0

It is probably not something I will put any real eff= ort into fighting, if people insist on it.=C2=A0 I will continue to recomme= nd only using ACR in the request.

=C2=A0

John B.

=C2=A0

On Jul 23, 2015, at 9:21 AM, Justin Richer <jricher@mit.edu> wrote:

=C2=A0

Useful work, but shouldn=E2=80=99t thi= s be defined in the OIDF, where the =E2=80=9Camr" parameter is defined= ?

=C2=A0

=C2=A0=E2=80=94 Justin

=C2=A0

On Jul 22, 2015, at 7:48 PM, Mike Jone= s <Michael.J= ones@microsoft.com> wrote:

=C2=A0

Phil Hunt and I have posted a new draft= that defines some values used with the =E2=80=9Camr= =E2=80=9D (Authentication Methods References) claim and establishes a registry for A= uthentication Method Reference values.=C2=A0 These values include commonly = used authentication methods like =E2=80=9Cpwd=E2=80=9D (password) and =E2=80=9Cotp=E2=80=9D (one time passwo= rd).=C2=A0 It also defines a parameter for requesting that specific authent= ication methods be used in the authentication.

=C2=A0

The specification is available at:

= =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0https://tools.ietf.org/html/draft-jones-oa= uth-amr-values-00

=C2=A0

An HTML formatted version is also avail= able at:

= =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0http://self-issued.info/docs/draft= -jones-oauth-amr-values-00.html

=C2=A0

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

=C2=A0

P.S.=C2=A0 This note was also posted at= =C2=A0http://self-issued.info/?p=3D= 1429=C2=A0and as=C2=A0@selfissued.

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

=C2=A0

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

=C2=A0


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

=C2=A0


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

=C2=A0


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



=C2=A0

--

Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
= http://nat.sakimura.org/
@_nat_en


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




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

--089e013c66b09eb1e3051bccb709-- From nobody Thu Jul 30 05:43:16 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8B31A88AC for ; Thu, 30 Jul 2015 05:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfCOxjUov-1p for ; Thu, 30 Jul 2015 05:43:10 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD6D71A906A for ; Thu, 30 Jul 2015 05:43:09 -0700 (PDT) Received: by ioeg141 with SMTP id g141so52305651ioe.3 for ; Thu, 30 Jul 2015 05:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to:content-type; bh=sBoYBarh6WiDGXvSKsKS/GA8GWZywE3MgJvYzBN256E=; b=QFl0o/PuQpDmt8zBm6mnEd6LwtBg5qwFJcHlqiYEfneNfKvYAkhn6d7MuicAUE/fko KF23AYhBfnf4uuhnIyVPC6E4YrUSa2fvUklQ7bbM9sYXf6qyHn4I/6X3VMbC23b5JY+o 7z+wh6c7/BDo+5QyWtnuqzrSBkozX6sBpfTpo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=sBoYBarh6WiDGXvSKsKS/GA8GWZywE3MgJvYzBN256E=; b=TIFGDuMXOl6SNXlqwnNT/GEdOhwBOntrSoNCHrXcxMK85LJtpZN5QPPzOS2H7zuf5q tab4aW66LdIf7BRykBZ8Ksahzlmv7JeJq/ie9ZonVMW1H3dvfUHKimzGrYdZq+5PHC8w Wy1JqD5jQB51t2QigtBxWpYNQv+zJsAuQBLq5Xu7zCl3SJK61E5+syt/sTW9FASKtsrh W1R4SQp1hUh6p26BmVjNVc4QlT5k8RePLMzpi0/qdUZczRhNXNx4CWaAxVwaydlR+XUC ryOtsn5O9R3PKAoqhlYrakp6AB0lN8140s1enf6mczI9Y23YX5J5wyO91grfzoXN7XKd iQ5w== X-Gm-Message-State: ALoCoQkl70rGRAJsJIagQc+wd+QhfHvmGAgfnUFadxGR7kXNm/BY/jA6Q4yMdQaAglvV3g6PZ/66 X-Received: by 10.107.47.224 with SMTP id v93mr9776351iov.86.1438260189258; Thu, 30 Jul 2015 05:43:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Thu, 30 Jul 2015 05:42:39 -0700 (PDT) From: Brian Campbell Date: Thu, 30 Jul 2015 06:42:39 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=001a11c14e96ad077f051c170bbc Archived-At: Subject: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 1 (was Re: refs and links in proof-of-possession-02 section 3.2) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 12:43:14 -0000 --001a11c14e96ad077f051c170bbc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In -03 the link is still back to the same doc and now to an anchor that doesn't exist, https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-03#section= -7 rather than to the section in JWK/RFC7517 where I assume it's intended, http://tools.ietf.org/html/rfc7517#section-7 On Sun, Mar 22, 2015 at 8:13 PM, Brian Campbell wrote: > In =C2=A73.2. Proof-of-Possession of a Symmetric Key > > it has "The rules for encrypting a JWK are found in Section 6 of the JSON > Web Key [JWK] specification.", which has two issues. > > 1) the Section 6 link is to the same document at > https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-02#secti= on-6 > which kinda works because it's the References. But is probably not what w= as > intended. I think > http://www.ietf.org/mail-archive/web/jose/current/msg04571.html has some > info on how to fix that kind of thing. > > 2) It should actually refer to section 7 > > of JWK rather than 6 as section 6 is about "String Comparison Rules" and = 7 > is "Encrypted JWK and Encrypted JWK Set Formats". > --001a11c14e96ad077f051c170bbc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In -03 the link is still back to the same doc and now= to an anchor that doesn't exist, https://tools.ietf.org= /html/draft-ietf-oauth-proof-of-possession-03#section-7 rather than to = the section in JWK/RFC7517 where I assume it's intended, http://tools.ietf.org/html/rfc75= 17#section-7

On Sun, Mar 22, 2015 at 8:13 PM, Brian Campbell <bcampb= ell@pingidentity.com> wrote:
In =C2=A73.2. Pr= oof-of-Possession of a Symmetric Key it has "The rules for encrypt= ing a JWK are found in Section 6 of the JSON Web Key [JWK] specification.&q= uot;, which has two issues.

1) the Sectio= n 6 link is to the same document at https:= //tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-02#section-6= which kinda works because it's the References. But is probably not wha= t was intended. I think http://www.ietf.org/mail-archive= /web/jose/current/msg04571.html has some info on how to fix that kind o= f thing.

2) It should actually refer to section 7 of JWK rather than 6 as section 6 is about "Stri= ng Comparison Rules" and 7 is "Encrypted JWK and Encrypted JWK Se= t Formats".

--001a11c14e96ad077f051c170bbc-- From nobody Thu Jul 30 09:16:52 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0398F1A895B for ; Thu, 30 Jul 2015 09:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.088 X-Spam-Level: X-Spam-Status: No, score=0.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOzvLOYab3Gt for ; Thu, 30 Jul 2015 09:16:49 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0114.outbound.protection.outlook.com [65.55.169.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 57EEB1A9145 for ; Thu, 30 Jul 2015 09:16:48 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.231.11; Thu, 30 Jul 2015 16:16:46 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0231.011; Thu, 30 Jul 2015 16:16:46 +0000 From: Mike Jones To: Brian Campbell , oauth Thread-Topic: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 1 (was Re: refs and links in proof-of-possession-02 section 3.2) Thread-Index: AQHQysVQJLvBiDud906qVho6f7W3/p30LmpA Date: Thu, 30 Jul 2015 16:16:46 +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: pingidentity.com; dkim=none (message not signed) header.d=none; x-originating-ip: [50.47.90.173] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:GWK9xRkjOa/vkjW1pfpVD6r7d4T2oBRo0cL3pdo7ieo6SfoS/nq+5HBDPN4XcO4bnUEOhyT6MkHpK8LnAk+Ot4bMSOlWahIhvQebRWibE2BPR5bE/9/0hqjy5lLCK4sgWDyKiQwTq5xgp/z0jPZbPg==; 24:Iz6pApo5inisypEIO+Xd0wSSD7w+kJ8ASbgPkafxuEG8Wou1AlRFEquUI3zHfafeofKoH++k8qSmMMgckN3KYS7mcVF5V9sit1aUS9hvRiY=; 20:AHSRf7CEOmNXMUWx+exCTfquQaWJTeL2xyMJ392u/7iJ0u6O4Yu5Vu4hRe/jKEp9HQhM3Wa7CwxmU3AQHkhJRg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 06530126A4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(40100003)(189998001)(15975445007)(102836002)(19300405004)(2950100001)(19625215002)(16236675004)(19580395003)(19580405001)(77096005)(2900100001)(122556002)(86362001)(107886002)(5001960100002)(92566002)(19609705001)(2656002)(33656002)(87936001)(5001770100001)(99286002)(106116001)(76576001)(66066001)(62966003)(77156002)(5003600100002)(10090500001)(230783001)(46102003)(19617315012)(76176999)(50986999)(5002640100001)(74316001)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442226CE3E541EC1EEBDCE7F58B0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2015 16:16:46.8112 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Subject: Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 1 (was Re: refs and links in proof-of-possession-02 section 3.2) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 16:16:52 -0000 --_000_BY2PR03MB442226CE3E541EC1EEBDCE7F58B0BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHRleHQgaXMgbm93IGNvcnJlY3QgYW5kIHlvdeKAmXJlIHJpZ2h0IHdoZXJlIHRoZSBsaW5r IHNob3VsZCBnbywgYnV0IHRoaXMgYXBwZWFycyB0byBiZSBhIGJ1ZyBpbiB0aGUgcmZjbWFya3Vw PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvdG9vbHMvcmZjbWFya3VwLz4gdG9vbCB0aGF0IGF1dG9t YXRpY2FsbHkgY3JlYXRlcyB0aGUgSFRNTGl6ZWQgdmVyc2lvbiBmcm9tIHRoZSAudHh0IHZlcnNp b24uICBJ4oCZbGwgdHJ5IHRvIGV4cGVyaW1lbnQgdG8gc2VlIGlmIEkgY2FuIHdvcmsgYXJvdW5k IHRoZSBidWcg4oCTIGZvciBpbnN0YW5jZSwgY2hhbmdpbmcg4oCcU2VjdGlvbiA3IG9mIHRoZSBK U09OIFdlYiBLZXkgW0pXS10gc3BlY2lmaWNhdGlvbuKAnSB0byBTZWN0aW9uIDcgb2YgW0pXS13i gJ0gYW5kIHNlZSBpZiB0aGF0IGhlbHBzIHRoZSB0b29sIGdldCBpdCByaWdodC4gIEnigJlsbCBh bHNvIGxvb2sgaW50byBmaWxpbmcgYSBidWcgb24gdGhlIHRvb2wuDQoNClRoYW5rcyBmb3IgZG91 YmxlLWNoZWNraW5nLCBCcmlhbi4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBPQXV0aCBbbWFpbHRv Om9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlhbiBDYW1wYmVsbA0KU2Vu dDogVGh1cnNkYXksIEp1bHkgMzAsIDIwMTUgNTo0MyBBTQ0KVG86IG9hdXRoDQpTdWJqZWN0OiBb T0FVVEgtV0ddIEpXVCBQb1AgS2V5IFNlbWFudGljcyBXR0xDIGZvbGxvd3VwIDEgKHdhcyBSZTog cmVmcyBhbmQgbGlua3MgaW4gcHJvb2Ytb2YtcG9zc2Vzc2lvbi0wMiBzZWN0aW9uIDMuMikNCg0K SW4gLTAzIHRoZSBsaW5rIGlzIHN0aWxsIGJhY2sgdG8gdGhlIHNhbWUgZG9jIGFuZCBub3cgdG8g YW4gYW5jaG9yIHRoYXQgZG9lc24ndCBleGlzdCwgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtb2F1dGgtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0wMyNzZWN0aW9uLTc8aHR0cHM6 Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYl MmZ0b29scy5pZXRmLm9yZyUyZmh0bWwlMmZkcmFmdC1pZXRmLW9hdXRoLXByb29mLW9mLXBvc3Nl c3Npb24tMDMlMjNzZWN0aW9uLTcmZGF0YT0wMSU3YzAxJTdjTWljaGFlbC5Kb25lcyU0MG1pY3Jv c29mdC5jb20lN2M1YzQxMmNmMWZjOTc0ODg5OWVkZjA4ZDI5OGRjNzI0YyU3YzcyZjk4OGJmODZm MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT00bWF6cW9kTDNpNnFKckdLbFVkVkFBNjYl MmJpZlR3ckZ4U05CUWh4TXdSYW8lM2Q+IHJhdGhlciB0aGFuIHRvIHRoZSBzZWN0aW9uIGluIEpX Sy9SRkM3NTE3IHdoZXJlIEkgYXNzdW1lIGl0J3MgaW50ZW5kZWQsIGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzc1MTcjc2VjdGlvbi03PGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVj dGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZ0b29scy5pZXRmLm9yZyUyZmh0bWwl MmZyZmM3NTE3JTIzc2VjdGlvbi03JmRhdGE9MDElN2MwMSU3Y01pY2hhZWwuSm9uZXMlNDBtaWNy b3NvZnQuY29tJTdjNWM0MTJjZjFmYzk3NDg4OTllZGYwOGQyOThkYzcyNGMlN2M3MmY5ODhiZjg2 ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9SFI3ZDVxTkUlMmI2MUI4dGkwaDE5Y1dI d3BSUzBwNiUyZkJhVVFlclFTSGZBYzAlM2Q+DQoNCk9uIFN1biwgTWFyIDIyLCAyMDE1IGF0IDg6 MTMgUE0sIEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86 YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+PiB3cm90ZToNCkluIMKnMy4yLiBQcm9vZi1vZi1Q b3NzZXNzaW9uIG9mIGEgU3ltbWV0cmljIEtleTxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3Rl Y3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnRvb2xzLmlldGYub3JnJTJmaHRt bCUyZmRyYWZ0LWlldGYtb2F1dGgtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0wMiUyM3NlY3Rpb24tMy4y JmRhdGE9MDElN2MwMSU3Y01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdjNWM0MTJjZjFm Yzk3NDg4OTllZGYwOGQyOThkYzcyNGMlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0 NyU3YzEmc2RhdGE9Tzhrb3hJaUtHNEtnYnpHS3JmQU95N2tROVlrUm1HdTRTbEtUdkxuZnZvSSUz ZD4gaXQgaGFzICJUaGUgcnVsZXMgZm9yIGVuY3J5cHRpbmcgYSBKV0sgYXJlIGZvdW5kIGluIFNl Y3Rpb24gNiBvZiB0aGUgSlNPTiBXZWIgS2V5IFtKV0tdIHNwZWNpZmljYXRpb24uIiwgd2hpY2gg aGFzIHR3byBpc3N1ZXMuDQoNCjEpIHRoZSBTZWN0aW9uIDYgbGluayBpcyB0byB0aGUgc2FtZSBk b2N1bWVudCBhdCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1w cm9vZi1vZi1wb3NzZXNzaW9uLTAyI3NlY3Rpb24tNjxodHRwczovL25hMDEuc2FmZWxpbmtzLnBy b3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnRvb2xzLmlldGYub3JnJTJm aHRtbCUyZmRyYWZ0LWlldGYtb2F1dGgtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0wMiUyM3NlY3Rpb24t NiZkYXRhPTAxJTdjMDElN2NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3YzVjNDEyY2Yx ZmM5NzQ4ODk5ZWRmMDhkMjk4ZGM3MjRjJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRi NDclN2MxJnNkYXRhPVN5eHQzWkNLVmlvOThlYjNZVm9uN3pTVVpMSklUaUppTWZwSSUyYmh2d28x QSUzZD4gd2hpY2gga2luZGEgd29ya3MgYmVjYXVzZSBpdCdzIHRoZSBSZWZlcmVuY2VzLiBCdXQg aXMgcHJvYmFibHkgbm90IHdoYXQgd2FzIGludGVuZGVkLiBJIHRoaW5rIGh0dHA6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9qb3NlL2N1cnJlbnQvbXNnMDQ1NzEuaHRtbDxodHRwczov L25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJmJTJm d3d3LmlldGYub3JnJTJmbWFpbC1hcmNoaXZlJTJmd2ViJTJmam9zZSUyZmN1cnJlbnQlMmZtc2cw NDU3MS5odG1sJmRhdGE9MDElN2MwMSU3Y01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdj NWM0MTJjZjFmYzk3NDg4OTllZGYwOGQyOThkYzcyNGMlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk N2NkMDExZGI0NyU3YzEmc2RhdGE9anNHN2gwdHBMTHppTlZXRVJ5Z2EyazYyNFhPM3FGNnJ2bTN5 bE0zYXpJYyUzZD4gaGFzIHNvbWUgaW5mbyBvbiBob3cgdG8gZml4IHRoYXQga2luZCBvZiB0aGlu Zy4NCjIpIEl0IHNob3VsZCBhY3R1YWxseSByZWZlciB0byBzZWN0aW9uIDc8aHR0cHM6Ly9uYTAx LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ0b29s cy5pZXRmLm9yZyUyZmh0bWwlMmZkcmFmdC1pZXRmLWpvc2UtanNvbi13ZWIta2V5LTQxJTIzc2Vj dGlvbi03JmRhdGE9MDElN2MwMSU3Y01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdjNWM0 MTJjZjFmYzk3NDg4OTllZGYwOGQyOThkYzcyNGMlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2Nk MDExZGI0NyU3YzEmc2RhdGE9SDRFcjIwdVBNMkhRd2dwdmc2a29MSmlibjdKQlJzcmdHaXNmR21E VTdRZyUzZD4gb2YgSldLIHJhdGhlciB0aGFuIDYgYXMgc2VjdGlvbiA2IGlzIGFib3V0ICJTdHJp bmcgQ29tcGFyaXNvbiBSdWxlcyIgYW5kIDcgaXMgIkVuY3J5cHRlZCBKV0sgYW5kIEVuY3J5cHRl ZCBKV0sgU2V0IEZvcm1hdHMiLg0KDQo= --_000_BY2PR03MB442226CE3E541EC1EEBDCE7F58B0BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIHRleHQgaXMgbm93 IGNvcnJlY3QgYW5kIHlvdeKAmXJlIHJpZ2h0IHdoZXJlIHRoZSBsaW5rIHNob3VsZCBnbywgYnV0 IHRoaXMgYXBwZWFycyB0byBiZSBhIGJ1ZyBpbiB0aGUNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvdG9vbHMvcmZjbWFya3VwLyI+cmZjbWFya3VwPC9hPiB0b29sIHRoYXQgYXV0b21h dGljYWxseSBjcmVhdGVzIHRoZSBIVE1MaXplZCB2ZXJzaW9uIGZyb20gdGhlIC50eHQgdmVyc2lv bi4mbmJzcDsgSeKAmWxsIHRyeSB0byBleHBlcmltZW50IHRvIHNlZSBpZiBJIGNhbiB3b3JrIGFy b3VuZCB0aGUgYnVnIOKAkyBmb3IgaW5zdGFuY2UsIGNoYW5naW5nIOKAnDwvc3Bhbj48c3BhbiBs YW5nPSJFTiI+U2VjdGlvbg0KIDcgb2YgdGhlIEpTT04gV2ViIEtleSBbSldLXSBzcGVjaWZpY2F0 aW9uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJ0g dG8NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTiI+U2VjdGlvbiA3IG9mIFtKV0td4oCdPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4gYW5kIHNlZSBpZiB0aGF0 IGhlbHBzIHRoZSB0b29sIGdldCBpdCByaWdodC4mbmJzcDsgSeKAmWxsIGFsc28gbG9vayBpbnRv IGZpbGluZyBhIGJ1ZyBvbiB0aGUgdG9vbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgZG91YmxlLWNo ZWNraW5nLCBCcmlhbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJyaWFuIENhbXBiZWxsPGJyPg0KPGI+ U2VudDo8L2I+IFRodXJzZGF5LCBKdWx5IDMwLCAyMDE1IDU6NDMgQU08YnI+DQo8Yj5Ubzo8L2I+ IG9hdXRoPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtPQVVUSC1XR10gSldUIFBvUCBLZXkgU2VtYW50 aWNzIFdHTEMgZm9sbG93dXAgMSAod2FzIFJlOiByZWZzIGFuZCBsaW5rcyBpbiBwcm9vZi1vZi1w b3NzZXNzaW9uLTAyIHNlY3Rpb24gMy4yKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JbiAtMDMgdGhlIGxpbmsgaXMgc3RpbGwgYmFjayB0byB0aGUgc2FtZSBk b2MgYW5kIG5vdyB0byBhbiBhbmNob3IgdGhhdCBkb2Vzbid0IGV4aXN0LA0KPGEgaHJlZj0iaHR0 cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2El MmYlMmZ0b29scy5pZXRmLm9yZyUyZmh0bWwlMmZkcmFmdC1pZXRmLW9hdXRoLXByb29mLW9mLXBv c3Nlc3Npb24tMDMlMjNzZWN0aW9uLTcmYW1wO2RhdGE9MDElN2MwMSU3Y01pY2hhZWwuSm9uZXMl NDBtaWNyb3NvZnQuY29tJTdjNWM0MTJjZjFmYzk3NDg4OTllZGYwOGQyOThkYzcyNGMlN2M3MmY5 ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPTRtYXpxb2RMM2k2cUpy R0tsVWRWQUE2NiUyYmlmVHdyRnhTTkJRaHhNd1JhbyUzZCI+DQpodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1wcm9vZi1vZi1wb3NzZXNzaW9uLTAzI3NlY3Rpb24t NzwvYT4gcmF0aGVyIHRoYW4gdG8gdGhlIHNlY3Rpb24gaW4gSldLL1JGQzc1MTcgd2hlcmUgSSBh c3N1bWUgaXQncyBpbnRlbmRlZCwNCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJv dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZ0b29scy5pZXRmLm9yZyUyZmh0 bWwlMmZyZmM3NTE3JTIzc2VjdGlvbi03JmFtcDtkYXRhPTAxJTdjMDElN2NNaWNoYWVsLkpvbmVz JTQwbWljcm9zb2Z0LmNvbSU3YzVjNDEyY2YxZmM5NzQ4ODk5ZWRmMDhkMjk4ZGM3MjRjJTdjNzJm OTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1IUjdkNXFORSUyYjYx Qjh0aTBoMTljV0h3cFJTMHA2JTJmQmFVUWVyUVNIZkFjMCUzZCI+DQpodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM3NTE3I3NlY3Rpb24tNzwvYT4gPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTdW4sIE1hciAyMiwgMjAxNSBhdCA4OjEzIFBNLCBC cmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHku Y29tIiB0YXJnZXQ9Il9ibGFuayI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SW4gwqc8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5j b20vP3VybD1odHRwcyUzYSUyZiUyZnRvb2xzLmlldGYub3JnJTJmaHRtbCUyZmRyYWZ0LWlldGYt b2F1dGgtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0wMiUyM3NlY3Rpb24tMy4yJmFtcDtkYXRhPTAxJTdj MDElN2NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3YzVjNDEyY2YxZmM5NzQ4ODk5ZWRm MDhkMjk4ZGM3MjRjJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtz ZGF0YT1POGtveElpS0c0S2diekdLcmZBT3k3a1E5WWtSbUd1NFNsS1R2TG5mdm9JJTNkIiB0YXJn ZXQ9Il9ibGFuayI+My4yLg0KIFByb29mLW9mLVBvc3Nlc3Npb24gb2YgYSBTeW1tZXRyaWMgS2V5 PC9hPiBpdCBoYXMgJnF1b3Q7VGhlIHJ1bGVzIGZvciBlbmNyeXB0aW5nIGEgSldLIGFyZSBmb3Vu ZCBpbiBTZWN0aW9uIDYgb2YgdGhlIEpTT04gV2ViIEtleSBbSldLXSBzcGVjaWZpY2F0aW9uLiZx dW90Oywgd2hpY2ggaGFzIHR3byBpc3N1ZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjEpIHRoZSBTZWN0aW9uIDYgbGluayBpcyB0byB0aGUgc2FtZSBkb2N1bWVudCBhdA0KPGEg aHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9 aHR0cHMlM2ElMmYlMmZ0b29scy5pZXRmLm9yZyUyZmh0bWwlMmZkcmFmdC1pZXRmLW9hdXRoLXBy b29mLW9mLXBvc3Nlc3Npb24tMDIlMjNzZWN0aW9uLTYmYW1wO2RhdGE9MDElN2MwMSU3Y01pY2hh ZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdjNWM0MTJjZjFmYzk3NDg4OTllZGYwOGQyOThkYzcy NGMlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPVN5eHQz WkNLVmlvOThlYjNZVm9uN3pTVVpMSklUaUppTWZwSSUyYmh2d28xQSUzZCIgdGFyZ2V0PSJfYmxh bmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtcHJvb2Yt b2YtcG9zc2Vzc2lvbi0wMiNzZWN0aW9uLTY8L2E+IHdoaWNoIGtpbmRhIHdvcmtzIGJlY2F1c2Ug aXQncyB0aGUgUmVmZXJlbmNlcy4gQnV0IGlzIHByb2JhYmx5IG5vdCB3aGF0IHdhcyBpbnRlbmRl ZC4gSSB0aGluaw0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWwtYXJjaGl2ZSUy ZndlYiUyZmpvc2UlMmZjdXJyZW50JTJmbXNnMDQ1NzEuaHRtbCZhbXA7ZGF0YT0wMSU3YzAxJTdj TWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN2M1YzQxMmNmMWZjOTc0ODg5OWVkZjA4ZDI5 OGRjNzI0YyU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9 anNHN2gwdHBMTHppTlZXRVJ5Z2EyazYyNFhPM3FGNnJ2bTN5bE0zYXpJYyUzZCIgdGFyZ2V0PSJf YmxhbmsiPg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2pvc2UvY3VycmVu dC9tc2cwNDU3MS5odG1sPC9hPiBoYXMgc29tZSBpbmZvIG9uIGhvdyB0byBmaXggdGhhdCBraW5k IG9mIHRoaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+MikgSXQgc2hvdWxkIGFjdHVhbGx5IHJlZmVyIHRvIDxhIGhyZWY9Imh0dHBzOi8vbmEw MS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmdG9v bHMuaWV0Zi5vcmclMmZodG1sJTJmZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWtleS00MSUyM3Nl Y3Rpb24tNyZhbXA7ZGF0YT0wMSU3YzAxJTdjTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20l N2M1YzQxMmNmMWZjOTc0ODg5OWVkZjA4ZDI5OGRjNzI0YyU3YzcyZjk4OGJmODZmMTQxYWY5MWFi MmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9SDRFcjIwdVBNMkhRd2dwdmc2a29MSmlibjdKQlJz cmdHaXNmR21EVTdRZyUzZCIgdGFyZ2V0PSJfYmxhbmsiPg0Kc2VjdGlvbiA3PC9hPiBvZiBKV0sg cmF0aGVyIHRoYW4gNiBhcyBzZWN0aW9uIDYgaXMgYWJvdXQgJnF1b3Q7U3RyaW5nIENvbXBhcmlz b24gUnVsZXMmcXVvdDsgYW5kIDcgaXMgJnF1b3Q7RW5jcnlwdGVkIEpXSyBhbmQgRW5jcnlwdGVk IEpXSyBTZXQgRm9ybWF0cyZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BY2PR03MB442226CE3E541EC1EEBDCE7F58B0BY2PR03MB442namprd_-- From nobody Thu Jul 30 11:13:08 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7D61B2D4F for ; Thu, 30 Jul 2015 11:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZ7WL_ShsMzT for ; Thu, 30 Jul 2015 11:13:06 -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 0168F1B2CF9 for ; Thu, 30 Jul 2015 11:13:06 -0700 (PDT) Received: by igbij6 with SMTP id ij6so1447800igb.1 for ; Thu, 30 Jul 2015 11:13:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to:content-type; bh=9hAdfCamiF0G9hp/skQDFL1dwa0N7VEMBiH0nqFz3f0=; b=UDpaQYg0Bz/qwnEPGHhwtnCCrn9rOzWjivOo2kwnypsZWRtOckRYiHp7wYkmrZoNhE ped7+A1KSGtqmJjnKVuQR9pM2QgxU9XTviZmpozCGAEG0rp7FtbH63Cttv8zyz7baQwP 7gdTw3itF2FC6yRGNS9+auP2PabwLytGQxYhc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=9hAdfCamiF0G9hp/skQDFL1dwa0N7VEMBiH0nqFz3f0=; b=befiaYIG+3IMVBliNpDrWPJQ1v+VHUtK2satfjbCBAa/u/4bX2Tjair9GIYZiQxpuH h7PHRnVoCP3Imj8AX2wNE2amnjTAH7+TgIHcEG87uyYyE2eEY9bBIbsZSNaTArSryZfx 5NdyGcV0WQa3Id3b8hE/Zx7m/VV9usqXbq+NxhSh5Xh/RkCfePnNjuCayoqG+Hk8GFdC 39TVZzfNUuOqO5bkpPwQVtEQCsb6oehdbrd+BRQJH4lo6buBevYiy+OlVP48fIWw03Ew m6M5PvBgkA99j2xj3+RY6+eq5eAcRyLTc9E/p6EFVxlVTZPyprEkxdeC1jkbVTjdn98P 2XcQ== X-Gm-Message-State: ALoCoQnsFtd3yAQnEZOY2VhoGqHo17WSdNpmFDLON6ATEJ0RM5O9qnpKF7C740pQXmvtP71aR7Kj X-Received: by 10.50.138.70 with SMTP id qo6mr7472836igb.15.1438279985285; Thu, 30 Jul 2015 11:13:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Thu, 30 Jul 2015 11:12:35 -0700 (PDT) From: Brian Campbell Date: Thu, 30 Jul 2015 12:12:35 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=001a1134bbc69c6cc4051c1ba7cd Archived-At: Subject: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 2 (was Re: proof-of-possession-02 unencrypted oct JWK in encrypted JWT okay?) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 18:13:07 -0000 --001a1134bbc69c6cc4051c1ba7cd Content-Type: text/plain; charset=UTF-8 I raised the below question during the WGLC back in March but never got any response. JWE does add nontrivial size overhead to the message and in the case that a JWT containing a symmetric confirmation key is already a JWE, the spec would seem to require two layers of encryption and the associated over overhead that comes with it - even though the key is already encrypted by the outer JWE layer. I believe the draft should speak to how a symmetric key be represented as a claim in the clear when the encryption of it is provided the JWE/JWT that contains it. On Mon, Mar 23, 2015 at 12:40 AM, Brian Campbell wrote: > When the JWT is itself encrypted as a JWE, would it not be reasonable to > have a symmetric key be represented in the cnf claim with the jwk member as > an unencrypted JSON Web Key? > > Is such a possibility left as an exercise to the reader? Or should it be > more explicitly allowed or disallowed? > > > --001a1134bbc69c6cc4051c1ba7cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I raised the below question during the WGLC back in March = but never got any response.

JWE does add nontrivial size o= verhead to the message and in the case that a JWT containing a symmetric co= nfirmation key is already a JWE, the spec would seem to require two layers = of encryption and the associated over overhead that comes with it - even th= ough the key is already encrypted by the outer JWE layer.

I believe the draft should speak to how a symmetric key be represented as= a claim in the clear when the encryption of it is provided the JWE/JWT tha= t contains it.

On Mon, Mar 23, 2015 at 12:40 AM, Brian Campbel= l <bcampbell@pingidentity.com> wrote:
When the JWT is itself encrypted= as a JWE, would it not be reasonable to have a symmetric key be represente= d in the cnf claim with the jwk member as an unencrypted JSON Web Key?=C2= =A0

Is such a possibility left as an exercise to the reader? = Or should it be more explicitly allowed or disallowed?



--001a1134bbc69c6cc4051c1ba7cd-- From nobody Thu Jul 30 11:28:57 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709751B2D4F for ; Thu, 30 Jul 2015 11:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxxzC7c4ndJj for ; Thu, 30 Jul 2015 11:28:48 -0700 (PDT) Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54A831B2EE0 for ; Thu, 30 Jul 2015 11:28:47 -0700 (PDT) Received: by qged69 with SMTP id d69so30241843qge.0 for ; Thu, 30 Jul 2015 11:28:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=186M4YKhtnV6Lq+ijphTgmiuAKwuUvIu4vXM2hnoBCI=; b=FG/SaOH8GjyDNK4GSoz3ewWKe5i8oy33dHi8GWp/t36wkFqRBYCJ5EHc0htT226DE2 wZ9/HkJ3mnY8Jiw/+bQV7ylj7DTlDfSjbLGQm825BpqUEHXBCM5LMmqRHPH2MPA3MvaZ 8Cs6yBmBEWxMeTBNykfPe8Lp5cKPcxFylyvS+EZSy8DnTsBHyEc9s420PAhlZs1fri8c oDMZzJMyxu5qB4YS5ys2TGW5LrvcvyjoZ6MvNCP/yNEg43/Y8yQUKzJqBLagu3JZbHXs kKg4WhOpWkC1GEIKosgGVnWVnGCaI4c7rVrVG+mgJmSRmU8sf5MJ3oNkkIyvTrlOhCtJ 8EkA== X-Gm-Message-State: ALoCoQlylJfgoCCkkblXpm3tjs8NA5Wg0X5TMUiFSb3hHYvdrFMWb5/CBlfs+2heyfNmEekLAEXw X-Received: by 10.140.89.197 with SMTP id v63mr71309030qgd.97.1438280926553; Thu, 30 Jul 2015 11:28:46 -0700 (PDT) Received: from [192.168.1.216] (181-163-90-242.baf.movistar.cl. [181.163.90.242]) by smtp.gmail.com with ESMTPSA id c73sm877877qka.24.2015.07.30.11.28.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Jul 2015 11:28:45 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_93FC9AF4-EDE4-455D-8224-0142D4B1EA90" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: John Bradley In-Reply-To: Date: Thu, 30 Jul 2015 15:28:41 -0300 Message-Id: <25D90458-85D6-4850-8EAB-26923C17C709@ve7jtb.com> References: To: Brian Campbell X-Mailer: Apple Mail (2.2102) Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 2 (was Re: proof-of-possession-02 unencrypted oct JWK in encrypted JWT okay?) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 18:28:50 -0000 --Apple-Mail=_93FC9AF4-EDE4-455D-8224-0142D4B1EA90 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes encrypting the claim should only be required when the entire JWT is = not encrypted. I will have a look. John B. > On Jul 30, 2015, at 3:12 PM, Brian Campbell = wrote: >=20 > I raised the below question during the WGLC back in March but never = got any response. >=20 > JWE does add nontrivial size overhead to the message and in the case = that a JWT containing a symmetric confirmation key is already a JWE, the = spec would seem to require two layers of encryption and the associated = over overhead that comes with it - even though the key is already = encrypted by the outer JWE layer.=20 >=20 > I believe the draft should speak to how a symmetric key be represented = as a claim in the clear when the encryption of it is provided the = JWE/JWT that contains it.=20 >=20 >=20 > On Mon, Mar 23, 2015 at 12:40 AM, Brian Campbell = > wrote: > When the JWT is itself encrypted as a JWE, would it not be reasonable = to have a symmetric key be represented in the cnf claim with the jwk = member as an unencrypted JSON Web Key? =20 >=20 > Is such a possibility left as an exercise to the reader? Or should it = be more explicitly allowed or disallowed?=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_93FC9AF4-EDE4-455D-8224-0142D4B1EA90 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Yes encrypting the claim should only be required when the = entire JWT is not encrypted.   I will have a look.
John B.

On = Jul 30, 2015, at 3:12 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

I raised the below question during the WGLC back in March but = never got any response.

JWE does add nontrivial size overhead to the message and in = the case that a JWT containing a symmetric confirmation key is already a = JWE, the spec would seem to require two layers of encryption and the = associated over overhead that comes with it - even though the key is = already encrypted by the outer JWE layer.

I believe the draft should speak to how = a symmetric key be represented as a claim in the clear when the = encryption of it is provided the JWE/JWT that contains it.


On Mon, Mar 23, 2015 at 12:40 AM, Brian Campbell = <bcampbell@pingidentity.com> wrote:
When the JWT is itself encrypted as a JWE, = would it not be reasonable to have a symmetric key be represented in the = cnf claim with the jwk member as an unencrypted JSON Web Key? 

Is such a possibility left as an = exercise to the reader? Or should it be more explicitly allowed or = disallowed?



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

= --Apple-Mail=_93FC9AF4-EDE4-455D-8224-0142D4B1EA90-- From nobody Thu Jul 30 11:29:37 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2EB41ACD2F for ; Thu, 30 Jul 2015 11:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ua1y1WjxNTkG for ; Thu, 30 Jul 2015 11:29:33 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6285C1B2D4F for ; Thu, 30 Jul 2015 11:29:33 -0700 (PDT) Received: by ioii16 with SMTP id i16so62398457ioi.0 for ; Thu, 30 Jul 2015 11:29:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=egg5FI/POUcnE+2PsbwLxEwDz8mx7TZrRhTNYKbYyK4=; b=SxndVnQJgufOgU1ZVfQIPAdo2nACTSTR6wmoVolbIVAlWWNyyeVNXQ1zMzNbQYbCbF rManKMSETUJTec59SocQ1H/CjINjVAnnZhBWKlRmYKjFgHy86DkNNwNJPOpUD7GeKGo0 xJ137PX8HSAsWXlc+gnEbV0B+iiPAIbzrtTZ8= 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:cc :content-type; bh=egg5FI/POUcnE+2PsbwLxEwDz8mx7TZrRhTNYKbYyK4=; b=AKRCQ1AnTEBjTVrhuuqhaF9Rv0KUaKQSNtOmz9G2P4xy/a/IU8YYqXuY3yH5dUOkSU MTOqyiEkqX2JZ8mCoHzdIZRZZuiUxd9ABsZ8Xg67/0OmQE4BeFIjnLD89apsrHHc7DNV T3C1SPp5UzMlcQAt57nFMfj/rSJad63IXI/YAQg18E5gMDUaGQeT/HOdtjxgkT9dYX70 9SPs4JfHabDQbBfL2JwZKzO5fMOqLLyChqp+BYLHxQkOdNL9mwN8Wmp26fSyyZxsh1pR CrnuodyUMagv1cvPxJoJoUsT13GTrJjZUSx865EpwFJAMMIeoZD1CHWKwQ1AVXZyOEKe 3xbA== X-Gm-Message-State: ALoCoQnPWp4DgOFjLUs7eB0cnakaIdCT7CyOUp2IoiJgZSpB/0QTZA4cLdDyuWxZQrhLQN4JVpHS X-Received: by 10.107.136.160 with SMTP id s32mr12607748ioi.174.1438280972719; Thu, 30 Jul 2015 11:29:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Thu, 30 Jul 2015 11:29:03 -0700 (PDT) From: Brian Campbell Date: Thu, 30 Jul 2015 12:29:03 -0600 Message-ID: To: Nat Sakimura Content-Type: multipart/alternative; boundary=001a113ecffe7771d4051c1be236 Archived-At: Cc: oauth Subject: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: confirmation model in proof-of-possession-02) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 18:29:34 -0000 --001a113ecffe7771d4051c1be236 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Using individual claims for the different confirmation types would convey the same information with a reduced message size, likely simpler implementation, and avoid the need to establish a new registry. Seems like a no-brainer to me but maybe I'm overlooking something? There hasn't been much discussion that I'm aware of. Nat seemed in favor of it (the +1 below). Mike was dismissive of it at the Dallas meeting but didn't provide any reasoning (that I understood anyway). On Mon, Mar 23, 2015 at 10:18 AM, Nat Sakimura wrote: > +1 > > =3Dnat via iPhone > > 2015/03/23 11:07=E3=80=81Brian Campbell =E3= =81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8: > > This is mostly about section 3.4 > > but also the whole draft. > > If "cnf" is intended to analogous to the SAML 2.0 SubjectConfirmation > element, it should probably contain an array value rather than an object > value. SAML allows not just for multiple methods of confirming but for > multiple instances of the same method. IIRC, only one confirmation needs = to > be confirmable. > > I'm not sure the extra complexity is worth it though. I've rarely, if > ever, seen SAML assertions that make use of it. > > If the intent is just to allow for different kinds of confirmation, > couldn't the structure be pared down and simplified and just have > individual claims for the different confirmation types? Like "cjwk" and > "ckid" or similar that have the jwk or kid value respectively as the memb= er > value. > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a113ecffe7771d4051c1be236 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Using individual claims for the different confirmatio= n types would convey the same information with a reduced message size, like= ly simpler=C2=A0 implementation, and avoid the need to establish a new regi= stry.

Seems like a no-brainer to me but maybe I'm overlooking s= omething?=C2=A0

There hasn't been much discussion that I&= #39;m aware of. Nat seemed in favor of it (the +1 below). Mike was dismissi= ve of it at the Dallas meeting but didn't provide any reasoning (that I= understood anyway).


=
On Mon, Mar 23, 2015 at 10:18 AM, Nat Sakimura <= span dir=3D"ltr"><sakimura@gmail.com> wrote:
+1

=3Dnat via iPhone

2015/03/= 23 11:07=E3=80=81Brian Campbell <bcampbell@pingidentity.com> =E3=81=AE=E3=83= =A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8:

This is mostly about= section 3.4 but also the whole draf= t.

If "cnf" is intended to analogous to the SAM= L 2.0 SubjectConfirmation element, it should probably contain an array valu= e rather than an object value. SAML allows not just for multiple methods of= confirming but for multiple instances of the same method. IIRC, only one c= onfirmation needs to be confirmable.

I'm not sure the= extra complexity is worth it though. I've rarely, if ever, seen SAML a= ssertions that make use of it.

If the intent is just to a= llow for different kinds of confirmation, couldn't the structure be par= ed down and simplified and just have individual claims for the different co= nfirmation types? Like "cjwk" and "ckid" or similar tha= t have the jwk or kid value respectively as the member value.=C2=A0



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

--001a113ecffe7771d4051c1be236-- From nobody Thu Jul 30 12:57:35 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0851A9047 for ; Thu, 30 Jul 2015 12:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXFLhgWqFy6a for ; Thu, 30 Jul 2015 12:57:30 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0787.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:787]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BE0F1A88B9 for ; Thu, 30 Jul 2015 12:57:30 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.231.11; Thu, 30 Jul 2015 19:57:25 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0231.011; Thu, 30 Jul 2015 19:57:25 +0000 From: Mike Jones To: John Bradley , Brian Campbell Thread-Topic: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 2 (was Re: proof-of-possession-02 unencrypted oct JWK in encrypted JWT okay?) Thread-Index: AQHQyvNmzSC0/uKBY06Mdm3eVeDfEZ30VTeAgAAYCtA= Date: Thu, 30 Jul 2015 19:57:25 +0000 Message-ID: References: <25D90458-85D6-4850-8EAB-26923C17C709@ve7jtb.com> In-Reply-To: <25D90458-85D6-4850-8EAB-26923C17C709@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ve7jtb.com; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e8:2::650] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:hyTZGgYcPTIo0bZsLsTYVfJ2giVcIntsgkpVmdxnyZHN435EYX4kPDy5ULaMgju/jle2DnkaDN8Hrc638FgaOCgXGaa2wUNj6t7JoSCZEN5xBa+s5it2GemozytmEopS4lsKe5TG8SQmn99j3a8ZCQ==; 24:EafPXw13bn04+c3nGt+/IKt/NMIscZTUuy9L/cH3PlbUFTVy+TIrVqIp96fjF1+khdair1tcZmvh6MIVYHkVp1U5I2xOlG4dQxWBpj49H00=; 20:pUGYxVuszXE4BCSFIY+xdODUsS1WIxZcBElhPGdjFluqTEnNXmVwplRbfA0WRSk/D4gCDW53I3FzV32YDYqfBg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 06530126A4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(19300405004)(106116001)(102836002)(10090500001)(76576001)(99286002)(19617315012)(5001960100002)(16236675004)(5001770100001)(19625215002)(230783001)(33656002)(19580405001)(5002640100001)(46102003)(19580395003)(40100003)(122556002)(92566002)(15975445007)(19609705001)(76176999)(74316001)(2656002)(87936001)(77156002)(5003600100002)(62966003)(189998001)(77096005)(54356999)(86362001)(2950100001)(2900100001)(50986999)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442B44E1C2FEDE905BB39A8F58B0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2015 19:57:25.3844 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 2 (was Re: proof-of-possession-02 unencrypted oct JWK in encrypted JWT okay?) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 19:57:34 -0000 --_000_BY2PR03MB442B44E1C2FEDE905BB39A8F58B0BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm fine updating the draft to say that the symmetric key can be carried in= the "jwk" element in an unencrypted form if the JWT is itself encrypted. = That's what you're looking for, right? -- Mike From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley Sent: Thursday, July 30, 2015 11:29 AM To: Brian Campbell Cc: oauth Subject: Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 2 (was Re: proo= f-of-possession-02 unencrypted oct JWK in encrypted JWT okay?) Yes encrypting the claim should only be required when the entire JWT is not= encrypted. I will have a look. John B. On Jul 30, 2015, at 3:12 PM, Brian Campbell > wrote: I raised the below question during the WGLC back in March but never got any= response. JWE does add nontrivial size overhead to the message and in the case that a= JWT containing a symmetric confirmation key is already a JWE, the spec wou= ld seem to require two layers of encryption and the associated over overhea= d that comes with it - even though the key is already encrypted by the oute= r JWE layer. I believe the draft should speak to how a symmetric key be represented as a= claim in the clear when the encryption of it is provided the JWE/JWT that = contains it. On Mon, Mar 23, 2015 at 12:40 AM, Brian Campbell > wrote: When the JWT is itself encrypted as a JWE, would it not be reasonable to ha= ve a symmetric key be represented in the cnf claim with the jwk member as a= n unencrypted JSON Web Key? Is such a possibility left as an exercise to the reader? Or should it be mo= re explicitly allowed or disallowed? _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_BY2PR03MB442B44E1C2FEDE905BB39A8F58B0BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m fine updating the draft to = say that the symmetric key can be carried in the “jwk” element = in an unencrypted form if the JWT is itself encrypted.  That’s w= hat you’re looking for, right?

 

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

 

From: OAuth [mailto:oauth-bounces@ie= tf.org] On Behalf Of John Bradley
Sent: Thursday, July 30, 2015 11:29 AM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 2 (was R= e: proof-of-possession-02 unencrypted oct JWK in encrypted JWT okay?)<= /o:p>

 

Yes encrypting the claim should only be required whe= n the entire JWT is not encrypted.   I will have a look.

 

John B.

 

On Jul 30, 2015, at 3:12 PM, Brian Campbell <bcampbell@pingidentity.com>= ; wrote:

 

I raised the below question during the WGLC back in = March but never got any response.


JWE does add nontrivial size overhead to the message and in the case that a= JWT containing a symmetric confirmation key is already a JWE, the spec wou= ld seem to require two layers of encryption and the associated over overhea= d that comes with it - even though the key is already encrypted by the outer JWE layer.

I believe the draft should speak to how a symmetric = key be represented as a claim in the clear when the encryption of it is pro= vided the JWE/JWT that contains it.

 

 

On Mon, Mar 23, 2015 at 12:40 AM, Brian Campbell <= ;bcampbell@= pingidentity.com> wrote:

When the JWT is itsel= f encrypted as a JWE, would it not be reasonable to have a symmetric key be= represented in the cnf claim with the jwk member as an unencrypted JSON We= b Key? 

Is such a possibility= left as an exercise to the reader? Or should it be more explicitly allowed= or disallowed?

 

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

 

--_000_BY2PR03MB442B44E1C2FEDE905BB39A8F58B0BY2PR03MB442namprd_-- From nobody Thu Jul 30 13:17:37 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8EF1ACE53 for ; Thu, 30 Jul 2015 13:17:36 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63SeEo87gLOI for ; Thu, 30 Jul 2015 13:17:33 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0103.outbound.protection.outlook.com [207.46.100.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 285371A916C for ; Thu, 30 Jul 2015 13:17: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=k1BMTqkbQIdbPD6zI9jm8hQO21DvtL3k5fzZAtF/3jM=; b=aqiVzwNAewadYF6u37jvTAT/VPesLk4OL5ICfln+ZI9sfGaXHdI3/eseF9bKqXrTEIrYzV59RhpFbjaZ/fP3FhAR0ltmhbPlH5Q6m+mscSmrM6C0szVBRqbQW0Fz2sYBWZP84Q0ADtwyIs1ud7/gLOn/ya59g5LZ2HOK6fc7s4A= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.231.11; Thu, 30 Jul 2015 20:17:32 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0231.011; Thu, 30 Jul 2015 20:17:32 +0000 From: Mike Jones To: Brian Campbell , Nat Sakimura Thread-Topic: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: confirmation model in proof-of-possession-02) Thread-Index: AQHQyvWz/SCyqgmQu0un038dwOTLUJ30bmeA Date: Thu, 30 Jul 2015 20:17:32 +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: pingidentity.com; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e8:2::650] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:n7ekzrP6De/IfCMkq/NeqZW2BOzDu+FZhoWyFAnju6G/swfp2IByq5XEtu/bNpdpYbaeMXZ+1nRGmj+Cb5ufWsl4Ig8LuTjdovKMTG5vEIUTXzjwY+ZYI4IWofh8wUxZpBfPAhPn2Hr8/nU+iXaZbg==; 24:MzrUvdK0eX0FAjru35zWnprxH0ZlZe+qe1yhGoHdUMqexbqgZJFek+VILWpdf+ITiqbjGKPA49nxpYfMmuVzXJuO3VCNM73D0lZ1sLIw9ZQ=; 20:Af7cDSa+5G/CrzdfLkks8HXp4ojE63Ccsp+/jIj54CrB6yiFXjch9jbxbcygfOvDdTO56hNiqww8Kdju/0A41Q== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 06530126A4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(479174004)(40100003)(74316001)(5002640100001)(46102003)(92566002)(15975445007)(19580405001)(102836002)(86362001)(122556002)(2900100001)(50986999)(2950100001)(2656002)(76176999)(19609705001)(77096005)(87936001)(54356999)(189998001)(77156002)(62966003)(5003600100002)(99286002)(19300405004)(106116001)(76576001)(19580395003)(19617315012)(10090500001)(33656002)(19625215002)(5001960100002)(230783001)(16236675004)(5001770100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB44265A451E0AF7B6C1D1340F58B0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2015 20:17:32.2374 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: confirmation model in proof-of-possession-02) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 20:17:36 -0000 --_000_BY2PR03MB44265A451E0AF7B6C1D1340F58B0BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGFydCBvZiB0aGUgcmVhc29uaW5nIGZvciB1c2luZyBhIHN0cnVjdHVyZWQgY29uZmlybWF0aW9u IGNsYWltLCByYXRoZXIgdGhhbiBmbGF0dGVuaW5nIHRoZSBjb25maXJtYXRpb24gY2xhaW0gaW50 byB0aGUgdG9wLWxldmVsIEpXVCBjbGFpbXMgc2V0LCBpcyB0aGF0IGEgSldUIG1heSBjYXJyeSBt b3JlIHRoYW4gb25lIGNvbmZvcm1hdGlvbiBrZXkgb3Iga2V5IGRlc2NyaXB0b3IsIGFzIHdhcyBt ZW50aW9uZWQgaW4gUHJhZ3VlLiAgRm9yIGluc3RhbmNlLCBpbWFnaW5lIHRoYXQgYW4gYXBwbGlj YXRpb24gaXMgY29udmV5aW5nIGFuIGFwcGxpY2F0aW9uLWxldmVsIGNvbmZpcm1hdGlvbiBrZXkg dXNpbmcgdGhlIOKAnGNuZuKAnSBjbGFpbSBhbmQgZm9yIGluc3RhbmNlIGEgdG9rZW4gYmluZGlu ZyBrZXkgdXNpbmcgYSBzZWNvbmQgaW5zdGFuY2Ugb2YgdGhlIGNvbmZpcm1hdGlvbiBzdHJ1Y3R1 cmUsIHNheSB1c2luZyB0aGUg4oCcdG9rYm5k4oCdIGNsYWltLiAgV2l0aCB0aGUgY3VycmVudCBz dHJ1Y3R1cmVkIGFwcHJvYWNoLCB5b3XigJlkIGhhdmU6DQoNCnvigKYNCuKAnGNuZuKAnTp74oCc andr4oCdOiDigKZ9LA0K4oCcdG9rYm5k4oCdOnvigJxqd2vigJ06IOKApn0NCn0NCg0KSWYgb25l IHdlcmUgdG8gZmxhdHRlbiB0aGUgc3RydWN0dXJlLCBob3dldmVyLCB1bmlxdWUgY2xhaW0gbmFt ZXMgd291bGQgaGF2ZSB0byBiZSBwcm9kdWNlZCBmb3IgdGhlIGNyb3NzLXByb2R1Y3Qgb2YgZWFj aCBjb25mb3JtYXRpb24gZWxlbWVudCBhbmQgZWFjaCBjb25maXJtYXRpb24gY2xhaW0uICBTbyB5 b3XigJlkIGVuZCB1cCBkZWZpbmluZyBhbmQgcmVnaXN0ZXJpbmcgdGhlc2UgY2xhaW1zIGluIHRo ZSB0b3AtbGV2ZWwgSldUIENsYWltcyByZWdpc3RyeToNCiAgICAgICAgICAgICAgICBjbmZfandr DQogICAgICAgICAgICAgICAgY25mX2p3ZQ0KICAgICAgICAgICAgICAgIGNuZl9raWQNCiAgICAg ICAgICAgICAgICB0b2tibmRfandrDQogICAgICAgICAgICAgICAgdG9rYm5kX2p3ZQ0KICAgICAg ICAgICAgICAgIHRva2JuZF9raWQNCklmIHlvdSBhZGQgb3RoZXIga2luZCBvZiBjb25maXJtYXRp b24ga2V5cywgdGhpbmdzIHdvdWxkIGNvbnRpbnVlIHRvIGdldCBldmVuIHNpbGxpZXIuDQoNClRo ZSBjb2RlIHdpbGwgYmUgc2ltcGxlciBpZiB5b3UgY2FuIGhhdmUgYSBzaW5nbGUgc2hhcmVkIHJv dXRpbmUgZm9yIGhhbmRsaW5nIGNvbmZpcm1hdGlvbiBzdHJ1Y3R1cmVzIHJhdGhlciBhIHNlcGFy YXRlIGZvciBoYW5kbGluZyBjbmZfandrLCBjbmZfandlLCBjbmZfa2lkIGZyb20gdGhlIG9uZSBm b3IgaGFuZGxpbmcgdG9rYm5kX2p3aywgdG9rYm5kX2p3ZSwgdG9rYm5kX2tpZCwgZXRjLg0KDQpB bm90aGVyIHJlYXNvbiB0aGUgc3RydWN0dXJlIG1ha2VzIHRoaW5ncyBjb25jZXB0dWFsbHkgc2lt cGxlciBpcyB0aGF0IHRoZW4geW91IGNhbiBhbHdheXMgdXNlIHRoZSBuYW1lIOKAnGtpZOKAnSB0 byBob2xkIGEga2V5IElELCBubyBtYXR0ZXIgdGhlIGNvbnRleHQsIHJhdGhlciB0aGFuIGhhdmlu ZyB0byB1c2UgbmFtZS15b3VyLXByZWZpeF9raWQuICBUaGUgc2FtZSBob2xkcyB0cnVlIGZvciBv dGhlciBlbGVtZW50cy4NCg0KSeKAmW0gc29ycnkgdGhpcyB3YXNu4oCZdCBjbGVhciBpbiBQcmFn dWUuICBJIGtub3cgaXQgd2FzIG1lbnRpb25lZCBpbiB0aGUgY29udGV4dCBvZiBjYXJyeWluZyBt dWx0aXBsZSBjb25maXJtYXRpb24ga2V5cyBpbiBhIEpXVCwgYnV0IGl0IHdlbnQgYnkgcHJldHR5 IGZhc3QuDQoNCkJhc2VkIG9uIHRoZSBkaXNjdXNzaW9uIGluIFByYWd1ZSwgSSBiZWxpZXZlIHRo YXQgd2Ugc2hvdWxkIGFkZCBsYW5ndWFnZSB0byB0aGUgc3BlYyBzYXlpbmcgdGhhdCBhcHBsaWNh dGlvbnMgY2FuIGRlZmluZSBuZXcgY2xhaW0gbmFtZXMgb3RoZXIgdGhhbiDigJxjbmbigJ0gdG8g dXNlIHRvIHJlcHJlc2VudCBhcHBsaWNhdGlvbi1zcGVjaWZpYyBjb25maXJtYXRpb24gc3RydWN0 dXJlcyB0aGF0IGhhdmUgdGhlIHNhbWUgc3ludGF4IGFzIHRob3NlIHVzaW5nIHRoZSDigJxjbmbi gJ0gbmFtZS4gIFdvdWxkIHRoYXQgZG8gdGhlIHRyaWNrIGZvciB5b3U/DQoNCkJ5IHRoZSB3YXks IEnigJltIGFzIG11Y2ggaW4gZmF2b3Igb2YgY29tcGFjdG5lc3MgYXMgYW55b25lLiAgSGVjayDi gJMgSSB3YXMgb25lIG9mIHRoZSBmb2xrcyB3aG8gZm9pc3RlZCB0aGUgc2hvcnQgY2xhaW0gbmFt ZXMgbGlrZSDigJxpc3PigJ0gb24gdGhlIHdvcmxkISAgQnV0IEkgcmVhbGx5IGRvIGJlbGlldmUg dGhhdCBpbiB0aGlzIGNhc2UsIGhhdmluZyBzdHJ1Y3R1cmUgbWFrZXMgdGhpbmdzIG1vcmUgcmVh ZGFibGUgYW5kIG1vcmUgZmxleGlibGUsIGVzcGVjaWFsbHkgc2luY2UgdGhlcmUgd2lsbCBiZSBj YXNlcyB3aGVyZSB0aGVyZSBhcmUgbXVsdGlwbGUgY29uZmlybWF0aW9uIHN0cnVjdHVyZXMgaW4g dGhlIHNhbWUgSldULiAgQW5kIG9uY2UgeW91IHByZWZpeCB0aGUgbmFtZXMsIHlvdSBsb3NlIG1v c3Qgb2YgdGhlIHNwYWNlIHNhdmluZ3MgYW55d2F5Lg0KDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQmVzdCB3aXNoZXMsDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBCcmlhbiBDYW1wYmVsbA0KU2VudDogVGh1cnNkYXksIEp1bHkgMzAs IDIwMTUgMTE6MjkgQU0NClRvOiBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbT4NCkNj OiBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbT0FVVEgtV0ddIEpXVCBQb1AgS2V5 IFNlbWFudGljcyBXR0xDIGZvbGxvd3VwIDMgKHdhcyBSZTogY29uZmlybWF0aW9uIG1vZGVsIGlu IHByb29mLW9mLXBvc3Nlc3Npb24tMDIpDQoNClVzaW5nIGluZGl2aWR1YWwgY2xhaW1zIGZvciB0 aGUgZGlmZmVyZW50IGNvbmZpcm1hdGlvbiB0eXBlcyB3b3VsZCBjb252ZXkgdGhlIHNhbWUgaW5m b3JtYXRpb24gd2l0aCBhIHJlZHVjZWQgbWVzc2FnZSBzaXplLCBsaWtlbHkgc2ltcGxlciAgaW1w bGVtZW50YXRpb24sIGFuZCBhdm9pZCB0aGUgbmVlZCB0byBlc3RhYmxpc2ggYSBuZXcgcmVnaXN0 cnkuDQoNClNlZW1zIGxpa2UgYSBuby1icmFpbmVyIHRvIG1lIGJ1dCBtYXliZSBJJ20gb3Zlcmxv b2tpbmcgc29tZXRoaW5nPw0KVGhlcmUgaGFzbid0IGJlZW4gbXVjaCBkaXNjdXNzaW9uIHRoYXQg SSdtIGF3YXJlIG9mLiBOYXQgc2VlbWVkIGluIGZhdm9yIG9mIGl0ICh0aGUgKzEgYmVsb3cpLiBN aWtlIHdhcyBkaXNtaXNzaXZlIG9mIGl0IGF0IHRoZSBEYWxsYXMgbWVldGluZyBidXQgZGlkbid0 IHByb3ZpZGUgYW55IHJlYXNvbmluZyAodGhhdCBJIHVuZGVyc3Rvb2QgYW55d2F5KS4NCg0KDQpP biBNb24sIE1hciAyMywgMjAxNSBhdCAxMDoxOCBBTSwgTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBn bWFpbC5jb208bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+IHdyb3RlOg0KKzENCg0KPW5hdCB2 aWEgaVBob25lDQoNCjIwMTUvMDMvMjMgMTE6MDfjgIFCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxs QHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPj4g44Gu 44Oh44OD44K744O844K4Og0KVGhpcyBpcyBtb3N0bHkgYWJvdXQgc2VjdGlvbiAzLjQ8aHR0cHM6 Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYl MmZ0b29scy5pZXRmLm9yZyUyZmh0bWwlMmZkcmFmdC1pZXRmLW9hdXRoLXByb29mLW9mLXBvc3Nl c3Npb24tMDIlMjNzZWN0aW9uLTMuNCZkYXRhPTAxJTdjMDElN2NNaWNoYWVsLkpvbmVzJTQwbWlj cm9zb2Z0LmNvbSU3YzhhYmJhNzNmMTBhZTRlM2RkY2ZmMDhkMjk5MGNkM2JiJTdjNzJmOTg4YmY4 NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPTJkSFp4SWhEYzJqdHUxa3JORkljY0th bWNlWnZNNCUyYjdZdzBoSkdBNldjWSUzZD4gYnV0IGFsc28gdGhlIHdob2xlIGRyYWZ0Lg0KDQpJ ZiAiY25mIiBpcyBpbnRlbmRlZCB0byBhbmFsb2dvdXMgdG8gdGhlIFNBTUwgMi4wIFN1YmplY3RD b25maXJtYXRpb24gZWxlbWVudCwgaXQgc2hvdWxkIHByb2JhYmx5IGNvbnRhaW4gYW4gYXJyYXkg dmFsdWUgcmF0aGVyIHRoYW4gYW4gb2JqZWN0IHZhbHVlLiBTQU1MIGFsbG93cyBub3QganVzdCBm b3IgbXVsdGlwbGUgbWV0aG9kcyBvZiBjb25maXJtaW5nIGJ1dCBmb3IgbXVsdGlwbGUgaW5zdGFu Y2VzIG9mIHRoZSBzYW1lIG1ldGhvZC4gSUlSQywgb25seSBvbmUgY29uZmlybWF0aW9uIG5lZWRz IHRvIGJlIGNvbmZpcm1hYmxlLg0KSSdtIG5vdCBzdXJlIHRoZSBleHRyYSBjb21wbGV4aXR5IGlz IHdvcnRoIGl0IHRob3VnaC4gSSd2ZSByYXJlbHksIGlmIGV2ZXIsIHNlZW4gU0FNTCBhc3NlcnRp b25zIHRoYXQgbWFrZSB1c2Ugb2YgaXQuDQpJZiB0aGUgaW50ZW50IGlzIGp1c3QgdG8gYWxsb3cg Zm9yIGRpZmZlcmVudCBraW5kcyBvZiBjb25maXJtYXRpb24sIGNvdWxkbid0IHRoZSBzdHJ1Y3R1 cmUgYmUgcGFyZWQgZG93biBhbmQgc2ltcGxpZmllZCBhbmQganVzdCBoYXZlIGluZGl2aWR1YWwg Y2xhaW1zIGZvciB0aGUgZGlmZmVyZW50IGNvbmZpcm1hdGlvbiB0eXBlcz8gTGlrZSAiY2p3ayIg YW5kICJja2lkIiBvciBzaW1pbGFyIHRoYXQgaGF2ZSB0aGUgandrIG9yIGtpZCB2YWx1ZSByZXNw ZWN0aXZlbHkgYXMgdGhlIG1lbWJlciB2YWx1ZS4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRm Lm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r LmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZv JTJmb2F1dGgmZGF0YT0wMSU3YzAxJTdjTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN2M4 YWJiYTczZjEwYWU0ZTNkZGNmZjA4ZDI5OTBjZDNiYiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3 Y2QwMTFkYjQ3JTdjMSZzZGF0YT1qd012b2M1MGhLdHRQcjF1NWd3V0xtbUNJOWszenVtSzhSdHpX UjJGN3cwJTNkPg0KDQo= --_000_BY2PR03MB44265A451E0AF7B6C1D1340F58B0BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTWFsZ3VuIEdvdGhpYyI7DQoJcGFub3Nl LTE6MiAxMSA1IDMgMiAwIDAgMiAwIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBN YWxndW4gR290aGljIjsNCglwYW5vc2UtMToyIDExIDUgMyAyIDAgMCAyIDAgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJNaWNyb3NvZnQgSmhlbmdIZWkiOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATWljcm9zb2Z0 IEpoZW5nSGVpIjsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzAwMjA2MCI+UGFydCBvZiB0aGUgcmVhc29uaW5nIGZvciB1c2luZyBhIHN0cnVjdHVy ZWQgY29uZmlybWF0aW9uIGNsYWltLCByYXRoZXIgdGhhbiBmbGF0dGVuaW5nIHRoZSBjb25maXJt YXRpb24gY2xhaW0gaW50byB0aGUgdG9wLWxldmVsIEpXVCBjbGFpbXMgc2V0LCBpcyB0aGF0IGEg SldUDQogbWF5IGNhcnJ5IG1vcmUgdGhhbiBvbmUgY29uZm9ybWF0aW9uIGtleSBvciBrZXkgZGVz Y3JpcHRvciwgYXMgd2FzIG1lbnRpb25lZCBpbiBQcmFndWUuJm5ic3A7IEZvciBpbnN0YW5jZSwg aW1hZ2luZSB0aGF0IGFuIGFwcGxpY2F0aW9uIGlzIGNvbnZleWluZyBhbiBhcHBsaWNhdGlvbi1s ZXZlbCBjb25maXJtYXRpb24ga2V5IHVzaW5nIHRoZSDigJxjbmbigJ0gY2xhaW0gYW5kIGZvciBp bnN0YW5jZSBhIHRva2VuIGJpbmRpbmcga2V5IHVzaW5nIGEgc2Vjb25kDQogaW5zdGFuY2Ugb2Yg dGhlIGNvbmZpcm1hdGlvbiBzdHJ1Y3R1cmUsIHNheSB1c2luZyB0aGUg4oCcdG9rYm5k4oCdIGNs YWltLiZuYnNwOyBXaXRoIHRoZSBjdXJyZW50IHN0cnVjdHVyZWQgYXBwcm9hY2gsIHlvdeKAmWQg aGF2ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPnvigKY8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzAwMjA2MCI+4oCcY25m4oCdOnvigJxqd2vigJ06IOKApn0sPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIw NjAiPuKAnHRva2JuZOKAnTp74oCcandr4oCdOiDigKZ9PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPn08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPklmIG9uZSB3ZXJlIHRvIGZs YXR0ZW4gdGhlIHN0cnVjdHVyZSwgaG93ZXZlciwgdW5pcXVlIGNsYWltIG5hbWVzIHdvdWxkIGhh dmUgdG8gYmUgcHJvZHVjZWQgZm9yIHRoZSBjcm9zcy1wcm9kdWN0IG9mIGVhY2ggY29uZm9ybWF0 aW9uIGVsZW1lbnQgYW5kIGVhY2ggY29uZmlybWF0aW9uDQogY2xhaW0uJm5ic3A7IFNvIHlvdeKA mWQgZW5kIHVwIGRlZmluaW5nIGFuZCByZWdpc3RlcmluZyB0aGVzZSBjbGFpbXMgaW4gdGhlIHRv cC1sZXZlbCBKV1QgQ2xhaW1zIHJlZ2lzdHJ5OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY25mX2p3azxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY25mX2p3ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY25mX2tpZDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdG9rYm5kX2p3azxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAy MDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdG9rYm5kX2p3ZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdG9rYm5kX2tpZDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMDAyMDYwIj5JZiB5b3UgYWRkIG90aGVyIGtpbmQgb2YgY29uZmlybWF0aW9uIGtl eXMsIHRoaW5ncyB3b3VsZCBjb250aW51ZSB0byBnZXQgZXZlbiBzaWxsaWVyLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+VGhlIGNvZGUgd2lsbCBiZSBzaW1wbGVy IGlmIHlvdSBjYW4gaGF2ZSBhIHNpbmdsZSBzaGFyZWQgcm91dGluZSBmb3IgaGFuZGxpbmcgY29u ZmlybWF0aW9uIHN0cnVjdHVyZXMgcmF0aGVyIGEgc2VwYXJhdGUgZm9yIGhhbmRsaW5nIGNuZl9q d2ssIGNuZl9qd2UsIGNuZl9raWQNCiBmcm9tIHRoZSBvbmUgZm9yIGhhbmRsaW5nIHRva2JuZF9q d2ssIHRva2JuZF9qd2UsIHRva2JuZF9raWQsIGV0Yy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMwMDIwNjAiPkFub3RoZXIgcmVhc29uIHRoZSBzdHJ1Y3R1cmUgbWFrZXMgdGhp bmdzIGNvbmNlcHR1YWxseSBzaW1wbGVyIGlzIHRoYXQgdGhlbiB5b3UgY2FuIGFsd2F5cyB1c2Ug dGhlIG5hbWUg4oCca2lk4oCdIHRvIGhvbGQgYSBrZXkgSUQsIG5vIG1hdHRlciB0aGUgY29udGV4 dCwgcmF0aGVyDQogdGhhbiBoYXZpbmcgdG8gdXNlIDxpPm5hbWUteW91ci1wcmVmaXg8L2k+X2tp ZC4mbmJzcDsgVGhlIHNhbWUgaG9sZHMgdHJ1ZSBmb3Igb3RoZXIgZWxlbWVudHMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5J4oCZbSBzb3JyeSB0aGlzIHdhc27i gJl0IGNsZWFyIGluIFByYWd1ZS4mbmJzcDsgSSBrbm93IGl0IHdhcyBtZW50aW9uZWQgaW4gdGhl IGNvbnRleHQgb2YgY2FycnlpbmcgbXVsdGlwbGUgY29uZmlybWF0aW9uIGtleXMgaW4gYSBKV1Qs IGJ1dCBpdCB3ZW50IGJ5IHByZXR0eSBmYXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzAwMjA2MCI+QmFzZWQgb24gdGhlIGRpc2N1c3Npb24gaW4gUHJhZ3VlLCBJIGJlbGll dmUgdGhhdCB3ZSBzaG91bGQgYWRkIGxhbmd1YWdlIHRvIHRoZSBzcGVjIHNheWluZyB0aGF0IGFw cGxpY2F0aW9ucyBjYW4gZGVmaW5lIG5ldyBjbGFpbSBuYW1lcyBvdGhlciB0aGFuIOKAnGNuZuKA nSB0byB1c2UNCiB0byByZXByZXNlbnQgYXBwbGljYXRpb24tc3BlY2lmaWMgY29uZmlybWF0aW9u IHN0cnVjdHVyZXMgdGhhdCBoYXZlIHRoZSBzYW1lIHN5bnRheCBhcyB0aG9zZSB1c2luZyB0aGUg 4oCcY25m4oCdIG5hbWUuJm5ic3A7IFdvdWxkIHRoYXQgZG8gdGhlIHRyaWNrIGZvciB5b3U/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5CeSB0aGUgd2F5LCBJ4oCZ bSBhcyBtdWNoIGluIGZhdm9yIG9mIGNvbXBhY3RuZXNzIGFzIGFueW9uZS4mbmJzcDsgSGVjayDi gJMgSSB3YXMgb25lIG9mIHRoZSBmb2xrcyB3aG8gZm9pc3RlZCB0aGUgc2hvcnQgY2xhaW0gbmFt ZXMgbGlrZSDigJxpc3PigJ0gb24gdGhlIHdvcmxkISZuYnNwOyBCdXQgSSByZWFsbHkNCiBkbyBi ZWxpZXZlIHRoYXQgaW4gdGhpcyBjYXNlLCBoYXZpbmcgc3RydWN0dXJlIG1ha2VzIHRoaW5ncyBt b3JlIHJlYWRhYmxlIGFuZCBtb3JlIGZsZXhpYmxlLCBlc3BlY2lhbGx5IHNpbmNlIHRoZXJlIHdp bGwgYmUgY2FzZXMgd2hlcmUgdGhlcmUgYXJlIG11bHRpcGxlIGNvbmZpcm1hdGlvbiBzdHJ1Y3R1 cmVzIGluIHRoZSBzYW1lIEpXVC4mbmJzcDsgQW5kIG9uY2UgeW91IHByZWZpeCB0aGUgbmFtZXMs IHlvdSBsb3NlIG1vc3Qgb2YgdGhlIHNwYWNlIHNhdmluZ3MNCiBhbnl3YXkuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMw MDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgQmVzdCB3aXNoZXMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE9BdXRoIFttYWlsdG86b2F1 dGgtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QnJpYW4gQ2FtcGJlbGw8 YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bHkgMzAsIDIwMTUgMTE6MjkgQU08YnI+DQo8 Yj5Ubzo8L2I+IE5hdCBTYWtpbXVyYSAmbHQ7c2FraW11cmFAZ21haWwuY29tJmd0Ozxicj4NCjxi PkNjOjwvYj4gb2F1dGggJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9i PiBbT0FVVEgtV0ddIEpXVCBQb1AgS2V5IFNlbWFudGljcyBXR0xDIGZvbGxvd3VwIDMgKHdhcyBS ZTogY29uZmlybWF0aW9uIG1vZGVsIGluIHByb29mLW9mLXBvc3Nlc3Npb24tMDIpPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+VXNpbmcgaW5kaXZpZHVhbCBjbGFpbXMgZm9yIHRoZSBkaWZmZXJlbnQgY29uZmly bWF0aW9uIHR5cGVzIHdvdWxkIGNvbnZleSB0aGUgc2FtZSBpbmZvcm1hdGlvbiB3aXRoIGEgcmVk dWNlZCBtZXNzYWdlIHNpemUsIGxpa2VseSBzaW1wbGVyJm5ic3A7IGltcGxlbWVudGF0aW9uLCBh bmQgYXZvaWQgdGhlIG5lZWQgdG8gZXN0YWJsaXNoIGEgbmV3IHJlZ2lzdHJ5Lg0KPGJyPg0KPGJy Pg0KU2VlbXMgbGlrZSBhIG5vLWJyYWluZXIgdG8gbWUgYnV0IG1heWJlIEknbSBvdmVybG9va2lu ZyBzb21ldGhpbmc/Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGVyZSBoYXNuJ3QgYmVlbiBtdWNoIGRpc2N1c3Npb24gdGhhdCBJJ20gYXdhcmUg b2YuIE5hdCBzZWVtZWQgaW4gZmF2b3Igb2YgaXQgKHRoZSAmIzQzOzEgYmVsb3cpLiBNaWtlIHdh cyBkaXNtaXNzaXZlIG9mIGl0IGF0IHRoZSBEYWxsYXMgbWVldGluZyBidXQgZGlkbid0IHByb3Zp ZGUgYW55IHJlYXNvbmluZyAodGhhdCBJIHVuZGVyc3Rvb2QgYW55d2F5KS4NCjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBNYXIgMjMsIDIwMTUg YXQgMTA6MTggQU0sIE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNha2ltdXJhQGdt YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNha2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+JiM0MzsxPGJyPg0KPGJyPg0KPW5hdCB2aWEgaVBob25lPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxicj4NCjIwMTUvMDMvMjMgMTE6MDc8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj7jgIE8L3NwYW4+QnJpYW4gQ2FtcGJlbGwg Jmx0OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDsNCjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPuOBruODoeODg+OCuzwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IEpoZW5nSGVpJnF1 b3Q7LHNhbnMtc2VyaWYiPuODvOOCuDwvc3Bhbj46PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGlzIGlzIG1vc3RseSBhYm91dCA8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3Rl Y3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnRvb2xzLmlldGYub3JnJTJmaHRt bCUyZmRyYWZ0LWlldGYtb2F1dGgtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0wMiUyM3NlY3Rpb24tMy40 JmFtcDtkYXRhPTAxJTdjMDElN2NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3YzhhYmJh NzNmMTBhZTRlM2RkY2ZmMDhkMjk5MGNkM2JiJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAx MWRiNDclN2MxJmFtcDtzZGF0YT0yZEhaeEloRGMyanR1MWtyTkZJY2NLYW1jZVp2TTQlMmI3WXcw aEpHQTZXY1klM2QiIHRhcmdldD0iX2JsYW5rIj4NCnNlY3Rpb24gMy40PC9hPiBidXQgYWxzbyB0 aGUgd2hvbGUgZHJhZnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCklmICZxdW90O2Nu ZiZxdW90OyBpcyBpbnRlbmRlZCB0byBhbmFsb2dvdXMgdG8gdGhlIFNBTUwgMi4wIFN1YmplY3RD b25maXJtYXRpb24gZWxlbWVudCwgaXQgc2hvdWxkIHByb2JhYmx5IGNvbnRhaW4gYW4gYXJyYXkg dmFsdWUgcmF0aGVyIHRoYW4gYW4gb2JqZWN0IHZhbHVlLiBTQU1MIGFsbG93cyBub3QganVzdCBm b3IgbXVsdGlwbGUgbWV0aG9kcyBvZiBjb25maXJtaW5nIGJ1dCBmb3IgbXVsdGlwbGUgaW5zdGFu Y2VzIG9mIHRoZSBzYW1lIG1ldGhvZC4gSUlSQywNCiBvbmx5IG9uZSBjb25maXJtYXRpb24gbmVl ZHMgdG8gYmUgY29uZmlybWFibGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkknbSBub3Qgc3Vy ZSB0aGUgZXh0cmEgY29tcGxleGl0eSBpcyB3b3J0aCBpdCB0aG91Z2guIEkndmUgcmFyZWx5LCBp ZiBldmVyLCBzZWVuIFNBTUwgYXNzZXJ0aW9ucyB0aGF0IG1ha2UgdXNlIG9mIGl0LjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij5JZiB0aGUgaW50ZW50IGlzIGp1c3QgdG8gYWxsb3cgZm9yIGRpZmZl cmVudCBraW5kcyBvZiBjb25maXJtYXRpb24sIGNvdWxkbid0IHRoZSBzdHJ1Y3R1cmUgYmUgcGFy ZWQgZG93biBhbmQgc2ltcGxpZmllZCBhbmQganVzdCBoYXZlIGluZGl2aWR1YWwgY2xhaW1zIGZv ciB0aGUgZGlmZmVyZW50IGNvbmZpcm1hdGlvbiB0eXBlcz8gTGlrZSAmcXVvdDtjandrJnF1b3Q7 IGFuZCAmcXVvdDtja2lkJnF1b3Q7DQogb3Igc2ltaWxhciB0aGF0IGhhdmUgdGhlIGp3ayBvciBr aWQgdmFsdWUgcmVzcGVjdGl2ZWx5IGFzIHRoZSBtZW1iZXIgdmFsdWUuJm5ic3A7IDxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1 dGgmYW1wO2RhdGE9MDElN2MwMSU3Y01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdjOGFi YmE3M2YxMGFlNGUzZGRjZmYwOGQyOTkwY2QzYmIlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2Nk MDExZGI0NyU3YzEmYW1wO3NkYXRhPWp3TXZvYzUwaEt0dFByMXU1Z3dXTG1tQ0k5azN6dW1LOFJ0 eldSMkY3dzAlM2QiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BY2PR03MB44265A451E0AF7B6C1D1340F58B0BY2PR03MB442namprd_-- From nobody Thu Jul 30 13:36:19 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883081A2119 for ; Thu, 30 Jul 2015 13:36: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WOKAInLue1e for ; Thu, 30 Jul 2015 13:36:16 -0700 (PDT) Received: from mail-qk0-f176.google.com (mail-qk0-f176.google.com [209.85.220.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22B2E1A1B62 for ; Thu, 30 Jul 2015 13:36:16 -0700 (PDT) Received: by qkdv3 with SMTP id v3so22456518qkd.3 for ; Thu, 30 Jul 2015 13:36:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=bHsDphMy7KiMJ5OyRsPKcTt1kM6lfQbm3HfDXAQkhKA=; b=VXviYw7OO3ZeKqxYDEkx3SPY1o7lPE/XfCDizOZZBQoTfea4H2m7Z5Xfcn+L7uPF2m jNoMC4VkIdHS3N4/UNJDyuQOTXJNs3mxC0EUKOyw0U0eX/n2HvFumRVPqIXBNe3sr5kT as5WdeJ4Ab72h+cvyI1TPghEiySXevh4/NidU5qtz9WNHFsL3AcWh3HtmLgF2wg5l37J qrce8C7PriQLDjSBFHZIIDxIl9mMgvDDDD0aShQJx22dtYSd3QOW5G4FvrVd19mn5xh8 RMDhMpvBOEoXqiWmfj/COoUMx2ymIteLYEJGP6geVOz0RDTymEhzXXptLiUxuWMrAQS2 7S4Q== X-Gm-Message-State: ALoCoQnj/K0c4xAFzW9FKfOu3yPr6OzxUp6ci/t2GyCotcAOLIduCZxGuzCUMJAzJGNxHtMHEi5e X-Received: by 10.55.19.19 with SMTP id d19mr74344670qkh.100.1438288575304; Thu, 30 Jul 2015 13:36:15 -0700 (PDT) Received: from [192.168.1.216] (186-79-94-106.baf.movistar.cl. [186.79.94.106]) by smtp.gmail.com with ESMTPSA id 17sm1051773qhf.16.2015.07.30.13.36.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Jul 2015 13:36:14 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_BD528E1A-5279-4B73-B6A3-5D3C9943F946" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: John Bradley In-Reply-To: Date: Thu, 30 Jul 2015 17:35:58 -0300 Message-Id: <3BAD5B86-78B6-4216-A287-1876557D26E1@ve7jtb.com> References: <25D90458-85D6-4850-8EAB-26923C17C709@ve7jtb.com> To: Michael Jones X-Mailer: Apple Mail (2.2102) Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 2 (was Re: proof-of-possession-02 unencrypted oct JWK in encrypted JWT okay?) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 20:36:18 -0000 --Apple-Mail=_BD528E1A-5279-4B73-B6A3-5D3C9943F946 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes, I think that is reasonable. There is no point to double = encrypting the key. =20 > On Jul 30, 2015, at 4:57 PM, Mike Jones = wrote: >=20 > I=E2=80=99m fine updating the draft to say that the symmetric key can = be carried in the =E2=80=9Cjwk=E2=80=9D element in an unencrypted form = if the JWT is itself encrypted. That=E2=80=99s what you=E2=80=99re = looking for, right? > =20 > -- = Mike > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley > Sent: Thursday, July 30, 2015 11:29 AM > To: Brian Campbell > Cc: oauth > Subject: Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 2 (was Re: = proof-of-possession-02 unencrypted oct JWK in encrypted JWT okay?) > =20 > Yes encrypting the claim should only be required when the entire JWT = is not encrypted. I will have a look. > =20 > John B. > =20 > On Jul 30, 2015, at 3:12 PM, Brian Campbell = > wrote: > =20 > I raised the below question during the WGLC back in March but never = got any response. >=20 > JWE does add nontrivial size overhead to the message and in the case = that a JWT containing a symmetric confirmation key is already a JWE, the = spec would seem to require two layers of encryption and the associated = over overhead that comes with it - even though the key is already = encrypted by the outer JWE layer.=20 >=20 > I believe the draft should speak to how a symmetric key be represented = as a claim in the clear when the encryption of it is provided the = JWE/JWT that contains it. > =20 > =20 > On Mon, Mar 23, 2015 at 12:40 AM, Brian Campbell = > wrote: > When the JWT is itself encrypted as a JWE, would it not be reasonable = to have a symmetric key be represented in the cnf claim with the jwk = member as an unencrypted JSON Web Key?=20 >=20 > Is such a possibility left as an exercise to the reader? Or should it = be more explicitly allowed or disallowed?=20 >=20 >=20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_BD528E1A-5279-4B73-B6A3-5D3C9943F946 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yes,  I think that is reasonable.   There is no = point to double encrypting the key.   


On Jul 30, 2015, at 4:57 PM, = Mike Jones <Michael.Jones@microsoft.com> wrote:

I=E2=80=99m fine updating the draft to say = that the symmetric key can be carried in the =E2=80=9Cjwk=E2=80=9D = element in an unencrypted form if the JWT is itself encrypted.  = That=E2=80=99s what you=E2=80=99re looking for, right?
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    -- Mike
 
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf = Of John Bradley
Sent: Thursday, July 30, 2015 = 11:29 AM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: oauth= <oauth@ietf.org>
Subject: Re: [OAUTH-WG] JWT PoP Key = Semantics WGLC followup 2 (was Re: proof-of-possession-02 unencrypted = oct JWK in encrypted JWT okay?)
 
Yes encrypting the claim should only be required when the = entire JWT is not encrypted.   I will have a look.
 
John B.
 
On Jul 30, 2015, at = 3:12 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
 
I raised the below question during the = WGLC back in March but never got any response.


JWE does add = nontrivial size overhead to the message and in the case that a JWT = containing a symmetric confirmation key is already a JWE, the spec would = seem to require two layers of encryption and the associated over = overhead that comes with it - even though the key is already encrypted = by the outer JWE layer. 

I believe the draft should speak to how a symmetric key be = represented as a claim in the clear when the encryption of it is = provided the JWE/JWT that contains it.
 
 
On Mon, Mar 23, 2015 at 12:40 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

When the JWT is itself encrypted as a JWE, would it not = be reasonable to have a symmetric key be represented in the cnf claim = with the jwk member as an unencrypted JSON Web Key? 

Is = such a possibility left as an exercise to the reader? Or should it be = more explicitly allowed or disallowed? 

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

= --Apple-Mail=_BD528E1A-5279-4B73-B6A3-5D3C9943F946-- From nobody Thu Jul 30 13:39:00 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9220D1A6EFB for ; Thu, 30 Jul 2015 13:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 374hRDRsN8te for ; Thu, 30 Jul 2015 13:38:57 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7C9A1A6EE2 for ; Thu, 30 Jul 2015 13:38:56 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so4072090igb.0 for ; Thu, 30 Jul 2015 13:38: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:content-type; bh=GHQl304tpDzKP8Jcp58b6q+WAq8p1hEu/BDnYjCuZTE=; b=Zp/mqxKmIO/ePB1nacxrF41CnxEYB0HR8yxMKHulHbFxkxGKo9WitIlIoXAzRkui6v QV22HMK+nmsfV2n2KOT7f9Ebal4TTShAePLoIne2ZPnbKUk8sSNJH75LKqPSGfjLMjyl AtN0B2gISvgdgQOmYK04kcU7/Mx21SS71+6eo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=GHQl304tpDzKP8Jcp58b6q+WAq8p1hEu/BDnYjCuZTE=; b=DkVDzLvxc2hAVlOqtxq3F9c5ovVGj1X0OHATDtjVoWFh627+76SNylAvMTKBK45TkY CtAoF7iaTP9L4fm0YBmeqYlL1CUTFYbguqPjEbMfpvZmSQ3P6jjTFxVksh4tdzbZslpC XoF9vE7SGCcNfCHUvJelyZsEjn974r33+WCKg7OuLHnRGVWHTDm/k54EgvhhszATqJh+ 796SCwq3GR0mvfPGWF/nrHT1NIL7k3N0ODH2bGZUwI3LKEH1o6iJCZMjNcKHdzQTXCfX 0KAeae1Q/0l4j5RqdrwHGNxJ4F+SNkNtR3SVtEStjrecRdwvN6k3h7mWK3WPO/xiI3M0 /eMw== X-Gm-Message-State: ALoCoQlGGjXe2UzQJd91dWR5hx9MssuytCmXo2nOmnt5tmgpFkmOXSUQHyng+SsY60YBXCtD//su X-Received: by 10.50.138.70 with SMTP id qo6mr8428664igb.15.1438288736251; Thu, 30 Jul 2015 13:38:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Thu, 30 Jul 2015 13:38:26 -0700 (PDT) In-Reply-To: References: <25D90458-85D6-4850-8EAB-26923C17C709@ve7jtb.com> From: Brian Campbell Date: Thu, 30 Jul 2015 14:38:26 -0600 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=001a1134bbc635af7a051c1db14f Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 2 (was Re: proof-of-possession-02 unencrypted oct JWK in encrypted JWT okay?) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 20:38:58 -0000 --001a1134bbc635af7a051c1db14f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yep, that's what I'm looking for. Thanks. On Thu, Jul 30, 2015 at 1:57 PM, Mike Jones wrote: > I=E2=80=99m fine updating the draft to say that the symmetric key can be = carried > in the =E2=80=9Cjwk=E2=80=9D element in an unencrypted form if the JWT is= itself > encrypted. That=E2=80=99s what you=E2=80=99re looking for, right? > > > > -- Mike > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *John Bradley > *Sent:* Thursday, July 30, 2015 11:29 AM > *To:* Brian Campbell > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 2 (was Re: > proof-of-possession-02 unencrypted oct JWK in encrypted JWT okay?) > > > > Yes encrypting the claim should only be required when the entire JWT is > not encrypted. I will have a look. > > > > John B. > > > > On Jul 30, 2015, at 3:12 PM, Brian Campbell > wrote: > > > > I raised the below question during the WGLC back in March but never got > any response. > > > JWE does add nontrivial size overhead to the message and in the case that > a JWT containing a symmetric confirmation key is already a JWE, the spec > would seem to require two layers of encryption and the associated over > overhead that comes with it - even though the key is already encrypted by > the outer JWE layer. > > I believe the draft should speak to how a symmetric key be represented as > a claim in the clear when the encryption of it is provided the JWE/JWT th= at > contains it. > > > > > > On Mon, Mar 23, 2015 at 12:40 AM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > > When the JWT is itself encrypted as a JWE, would it not be reasonable to > have a symmetric key be represented in the cnf claim with the jwk member = as > an unencrypted JSON Web Key? > > Is such a possibility left as an exercise to the reader? Or should it be > more explicitly allowed or disallowed? > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --001a1134bbc635af7a051c1db14f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yep, that's what I'm looking for. Thanks.

On Thu, Jul 30, = 2015 at 1:57 PM, Mike Jones <Michael.Jones@microsoft.com>= wrote:

I=E2=80=99m fine updating the draft t= o say that the symmetric key can be carried in the =E2=80=9Cjwk=E2=80=9D el= ement in an unencrypted form if the JWT is itself encrypted.=C2=A0 That=E2= =80=99s what you=E2=80=99re looking for, right?

=C2=A0

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

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Thursday, July 30, 2015 11:29 AM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 2 (was R= e: proof-of-possession-02 unencrypted oct JWK in encrypted JWT okay?)

=C2=A0

Yes encrypting the claim should only be required whe= n the entire JWT is not encrypted. =C2=A0 I will have a look.=

=C2=A0

John B.

=C2=A0

On Jul 30, 2015, at 3:12 PM, Brian Campbell <bcampbell@pingi= dentity.com> wrote:

=C2=A0

I raised the below question during the WGLC back in = March but never got any response.


JWE does add nontrivial size overhead to the message and in the case that a= JWT containing a symmetric confirmation key is already a JWE, the spec wou= ld seem to require two layers of encryption and the associated over overhea= d that comes with it - even though the key is already encrypted by the outer JWE layer.

I believe the draft should speak to how a symmetric = key be represented as a claim in the clear when the encryption of it is pro= vided the JWE/JWT that contains it.

=C2=A0

=C2=A0

On Mon, Mar 23, 2015 at 12:40 AM, Brian Campbell <= ;bcampbell@= pingidentity.com> wrote:

When the JWT is itsel= f encrypted as a JWE, would it not be reasonable to have a symmetric key be= represented in the cnf claim with the jwk member as an unencrypted JSON We= b Key?=C2=A0

Is such a possibility= left as an exercise to the reader? Or should it be more explicitly allowed= or disallowed?

=C2=A0

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

=C2=A0


--001a1134bbc635af7a051c1db14f-- From nobody Thu Jul 30 14:14:32 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152C31A90CA for ; Thu, 30 Jul 2015 14:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCmzCKDV2T9M for ; Thu, 30 Jul 2015 14:14:25 -0700 (PDT) Received: from mail-qk0-f173.google.com (mail-qk0-f173.google.com [209.85.220.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E7741AC3CB for ; Thu, 30 Jul 2015 14:14:25 -0700 (PDT) Received: by qkdg63 with SMTP id g63so22813532qkd.0 for ; Thu, 30 Jul 2015 14:14:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=zd6HzQgtPMAijA/wooP2BAmg7hOOsdiIcJIajK5LV20=; b=COgscLCNt2w4VFHRzHESJqsk8VaNyjsqQq2QmHJsNt/+IoTKxNOlRR8Dz29FjaN/fd FeHLx46LST2PPBE/ckpy5fgXjP32+/Flx/H6hS5u6ZQReCIZZEjiKKFHwLP0vUkNkcm/ d6MaRkMSHgLQf7aCora+hfG6XcIvK3IXrBBRDCYRkqP3j751p1wFZ9lvVKoVM6LGBeFH aNq1tb4Y2y1iLI39j7k8m/Xw9VljITFqMAnhTNfoLFvbLu4J/qNfxmbBgkighpP+8EG3 gJX/6zcrasEpd0pDDQnPU+mPjVGnHVqXcG1yFtfHEytnz+4bDv0+JlzE9O3uoplk1FgI PEQQ== X-Gm-Message-State: ALoCoQmdu6zksaqp8JlIRUVzLDB1zCU9Tn4n10pPsUrzUIh9qagvMWQ6mwe74ho8iUX8fIJjjv6B X-Received: by 10.55.42.231 with SMTP id q100mr71597664qkq.52.1438290864751; Thu, 30 Jul 2015 14:14:24 -0700 (PDT) Received: from [192.168.1.216] (186-79-94-106.baf.movistar.cl. [186.79.94.106]) by smtp.gmail.com with ESMTPSA id o77sm1104543qhb.14.2015.07.30.14.14.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Jul 2015 14:14:24 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_AAD76232-6A57-4E67-A88E-FC88A8511B5B" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: John Bradley In-Reply-To: Date: Thu, 30 Jul 2015 18:14:17 -0300 Message-Id: <3FBD2E36-79E8-4F4B-B2A5-1C3DC5E29D3D@ve7jtb.com> References: To: Michael Jones X-Mailer: Apple Mail (2.2102) Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: confirmation model in proof-of-possession-02) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 21:14:29 -0000 --Apple-Mail=_AAD76232-6A57-4E67-A88E-FC88A8511B5B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree, flattening would be a bad direction. In Prague I was indicating that there may be more than one presenter for = an assertion. The first presenter may be the OAuth client who presents = it to a RS. That RS itself may also present that token as a client in token exchange = to get a new access token for another resource. The initial AS may want to bind that token to two presenters. The = second AS doing the token exchange also probably only wants to know = about the proof key for the RS so that it doesn=E2=80=99t mistakenly = give the first client a token to directly access a backend API. Trying to find a generic pattern for that is a bit of a trick though. I think that a single cnf element is enough for most use cases, however = having cnf and cnf_rs or some other element using the cnf structure is = probably the best we can do at this point. John B. > On Jul 30, 2015, at 5:17 PM, Mike Jones = wrote: >=20 > Part of the reasoning for using a structured confirmation claim, = rather than flattening the confirmation claim into the top-level JWT = claims set, is that a JWT may carry more than one conformation key or = key descriptor, as was mentioned in Prague. For instance, imagine that = an application is conveying an application-level confirmation key using = the =E2=80=9Ccnf=E2=80=9D claim and for instance a token binding key = using a second instance of the confirmation structure, say using the = =E2=80=9Ctokbnd=E2=80=9D claim. With the current structured approach, = you=E2=80=99d have: > =20 > {=E2=80=A6 > =E2=80=9Ccnf=E2=80=9D:{=E2=80=9Cjwk=E2=80=9D: =E2=80=A6}, > =E2=80=9Ctokbnd=E2=80=9D:{=E2=80=9Cjwk=E2=80=9D: =E2=80=A6} > } > =20 > If one were to flatten the structure, however, unique claim names = would have to be produced for the cross-product of each conformation = element and each confirmation claim. So you=E2=80=99d end up defining = and registering these claims in the top-level JWT Claims registry: > cnf_jwk > cnf_jwe > cnf_kid > tokbnd_jwk > tokbnd_jwe > tokbnd_kid > If you add other kind of confirmation keys, things would continue to = get even sillier. > =20 > The code will be simpler if you can have a single shared routine for = handling confirmation structures rather a separate for handling cnf_jwk, = cnf_jwe, cnf_kid from the one for handling tokbnd_jwk, tokbnd_jwe, = tokbnd_kid, etc. > =20 > Another reason the structure makes things conceptually simpler is that = then you can always use the name =E2=80=9Ckid=E2=80=9D to hold a key ID, = no matter the context, rather than having to use name-your-prefix_kid. = The same holds true for other elements. > =20 > I=E2=80=99m sorry this wasn=E2=80=99t clear in Prague. I know it was = mentioned in the context of carrying multiple confirmation keys in a = JWT, but it went by pretty fast. > =20 > Based on the discussion in Prague, I believe that we should add = language to the spec saying that applications can define new claim names = other than =E2=80=9Ccnf=E2=80=9D to use to represent = application-specific confirmation structures that have the same syntax = as those using the =E2=80=9Ccnf=E2=80=9D name. Would that do the trick = for you? > =20 > By the way, I=E2=80=99m as much in favor of compactness as anyone. = Heck =E2=80=93 I was one of the folks who foisted the short claim names = like =E2=80=9Ciss=E2=80=9D on the world! But I really do believe that = in this case, having structure makes things more readable and more = flexible, especially since there will be cases where there are multiple = confirmation structures in the same JWT. And once you prefix the names, = you lose most of the space savings anyway. > =20 > Best = wishes, > -- = Mike > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian = Campbell > Sent: Thursday, July 30, 2015 11:29 AM > To: Nat Sakimura > Cc: oauth > Subject: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: = confirmation model in proof-of-possession-02) > =20 > Using individual claims for the different confirmation types would = convey the same information with a reduced message size, likely simpler = implementation, and avoid the need to establish a new registry.=20 >=20 > Seems like a no-brainer to me but maybe I'm overlooking something? =20 >=20 > There hasn't been much discussion that I'm aware of. Nat seemed in = favor of it (the +1 below). Mike was dismissive of it at the Dallas = meeting but didn't provide any reasoning (that I understood anyway). > =20 > =20 > On Mon, Mar 23, 2015 at 10:18 AM, Nat Sakimura > wrote: > +1 >=20 > =3Dnat via iPhone >=20 > 2015/03/23 11:07=E3=80=81Brian Campbell > =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3= =83=BC=E3=82=B8: >=20 > This is mostly about section 3.4 = but also the whole draft. >=20 > If "cnf" is intended to analogous to the SAML 2.0 SubjectConfirmation = element, it should probably contain an array value rather than an object = value. SAML allows not just for multiple methods of confirming but for = multiple instances of the same method. IIRC, only one confirmation needs = to be confirmable. >=20 > I'm not sure the extra complexity is worth it though. I've rarely, if = ever, seen SAML assertions that make use of it. >=20 > If the intent is just to allow for different kinds of confirmation, = couldn't the structure be pared down and simplified and just have = individual claims for the different confirmation types? Like "cjwk" and = "ckid" or similar that have the jwk or kid value respectively as the = member value. =20 >=20 >=20 > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_AAD76232-6A57-4E67-A88E-FC88A8511B5B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I agree, flattening would be a bad direction.

In Prague I was = indicating that there may be more than one presenter for an assertion. =  The first presenter may be the OAuth client who presents it to a = RS.

That RS = itself may also present that token as a client in token exchange to get = a new access token for another resource.

The initial AS may want to bind that = token to two presenters.   The second AS doing the token exchange = also probably only wants to know about the proof key for the RS so that = it doesn=E2=80=99t mistakenly give the first client a token to directly = access a backend API.

Trying to find a generic pattern for that is a bit of a trick = though.

I = think that a single cnf element is enough for most use cases, however = having cnf and cnf_rs or some other element using the cnf structure is = probably the best we can do at this point.

John B.
On Jul 30, 2015, at 5:17 PM, = Mike Jones <Michael.Jones@microsoft.com> wrote:

Part of the reasoning for using a structured = confirmation claim, rather than flattening the confirmation claim into = the top-level JWT claims set, is that a JWT may carry more than one = conformation key or key descriptor, as was mentioned in Prague.  = For instance, imagine that an application is conveying an = application-level confirmation key using the =E2=80=9Ccnf=E2=80=9D claim = and for instance a token binding key using a second instance of the = confirmation structure, say using the =E2=80=9Ctokbnd=E2=80=9D = claim.  With the current structured approach, you=E2=80=99d = have:
 
{=E2=80=A6
=E2=80=9Ccnf=E2=80=9D:{=E2=80=9Cjwk=E2=80=9D: =E2=80=A6},
=E2=80=9Ctokbnd=E2=80=9D:{=E2=80=9Cjwk=E2=80=9D= : =E2=80=A6}
}
 
If one were to flatten = the structure, however, unique claim names would have to be produced for = the cross-product of each conformation element and each confirmation = claim.  So you=E2=80=99d end up defining and registering these = claims in the top-level JWT Claims registry:
          &nb= sp;     cnf_jwk
          &nb= sp;     cnf_jwe
          &nb= sp;     cnf_kid
          &nb= sp;     tokbnd_jwk
          &nb= sp;     tokbnd_jwe
          &nb= sp;     tokbnd_kid
If you add other kind of confirmation keys, = things would continue to get even sillier.
 
The code will be simpler = if you can have a single shared routine for handling confirmation = structures rather a separate for handling cnf_jwk, cnf_jwe, cnf_kid from = the one for handling tokbnd_jwk, tokbnd_jwe, tokbnd_kid, etc.
 
Another reason the = structure makes things conceptually simpler is that then you can always = use the name =E2=80=9Ckid=E2=80=9D to hold a key ID, no matter the = context, rather than having to use name-your-prefix_kid.  The same holds true for other = elements.
 
I=E2=80= =99m sorry this wasn=E2=80=99t clear in Prague.  I know it was = mentioned in the context of carrying multiple confirmation keys in a = JWT, but it went by pretty fast.
 
Based on the discussion in Prague, I believe = that we should add language to the spec saying that applications can = define new claim names other than =E2=80=9Ccnf=E2=80=9D to use to = represent application-specific confirmation structures that have the = same syntax as those using the =E2=80=9Ccnf=E2=80=9D name.  Would = that do the trick for you?
 
By the way, I=E2=80=99m as much in favor of = compactness as anyone.  Heck =E2=80=93 I was one of the folks who = foisted the short claim names like =E2=80=9Ciss=E2=80=9D on the = world!  But I really do believe that in this case, having structure = makes things more readable and more flexible, especially since there = will be cases where there are multiple confirmation structures in the = same JWT.  And once you prefix the names, you lose most of the = space savings anyway.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    Best wishes,
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    -- Mike
 
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf = Of Brian = Campbell
Sent: Thursday, July 30, 2015 = 11:29 AM
To: Nat Sakimura <sakimura@gmail.com>
Cc: oauth= <oauth@ietf.org>
Subject: [OAUTH-WG] JWT PoP Key = Semantics WGLC followup 3 (was Re: confirmation model in = proof-of-possession-02)
 

Using = individual claims for the different confirmation types would convey the = same information with a reduced message size, likely simpler  = implementation, and avoid the need to establish a new registry. 

Seems like a no-brainer to me but maybe I'm overlooking = something?  

There = hasn't been much discussion that I'm aware of. Nat seemed in favor of it = (the +1 below). Mike was dismissive of it at the Dallas meeting but = didn't provide any reasoning (that I understood anyway).
 
 
On Mon, Mar 23, 2015 at 10:18 AM, Nat Sakimura <sakimura@gmail.com>= wrote:
+1

=3Dnat = via iPhone


2015/03/23 = 11:07=E3=80=81Brian Campbell <bcampbell@pingidentity.com> =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8:

This is mostly = about section = 3.4 but also the = whole draft.


If "cnf" is = intended to analogous to the SAML 2.0 SubjectConfirmation element, it = should probably contain an array value rather than an object value. SAML = allows not just for multiple methods of confirming but for multiple = instances of the same method. IIRC, only one confirmation needs to be = confirmable.

I'm not sure the extra = complexity is worth it though. I've rarely, if ever, seen SAML = assertions that make use of it.

If the intent = is just to allow for different kinds of confirmation, couldn't the = structure be pared down and simplified and just have individual claims = for the different confirmation types? Like "cjwk" and "ckid" or similar = that have the jwk or kid value respectively as the member = value.  

 

_______________________________________________
OAuth mailing 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=_AAD76232-6A57-4E67-A88E-FC88A8511B5B-- From nobody Thu Jul 30 15:41:08 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF101AD074 for ; Thu, 30 Jul 2015 15:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HMJ7hemgFPp for ; Thu, 30 Jul 2015 15:41:04 -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 15D211AD072 for ; Thu, 30 Jul 2015 15:41:03 -0700 (PDT) Received: by igbij6 with SMTP id ij6so5623929igb.1 for ; Thu, 30 Jul 2015 15:41:03 -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:content-type; bh=WvpebfDg4SfCvJUvLOCD0ToYmKV5wuFQCHvP7tnZl68=; b=cgqTCj+AGDU2gkPu6Gy6me8Rpx3NV1Fb2PlZKbgRBgxb/0nWjbcZhPyZH55+KRu9GR mp861Dla4CqTDDQtBVjP9ov1kKSY5mDSX1rZ0wLOFY/GmX9bvk2L8n3ypWsq+ZAZFnSJ +eBqKlpMHogyJpEDfh2z6o/L4JxC/jSrKz9LY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=WvpebfDg4SfCvJUvLOCD0ToYmKV5wuFQCHvP7tnZl68=; b=KeIOBMY5UdTi1D7dquCgFWmUeYfFYhsKHrWaQAVy42xlmPE+nyuijzbWkpwpVMz7mD hTTb4cN2nTkcxzgsNGZDR3/6Myaz6pq7IY6nNd1zns7vt0tPKU7RtctokEipdHX5Liqm lTy7zBWWlcvBmOZJ/MEEU7KcbE2yENgKdNbn4RphIlU9YvDqX61jHuKbVRg+ZRKYQCxA SMrTKMXGg8fDCDio69StJS+SGWDrH7yU8igXKPCxVe+t6clT3tf9/8ISOq5dLEgol085 912KULqcCzhMAt9ZSFIrfTLy2Jb7/5qvtFMYqknFzaZVphoKe6A7RlpXLk2JPOQU/FPj opjA== X-Gm-Message-State: ALoCoQkjA3iISEzLN22GgQy80D3WSVFW3W8qLLz2cTZIfR71jMfkOq0QO3xX/QzGEyd5fZutIMra X-Received: by 10.50.112.73 with SMTP id io9mr599920igb.18.1438296063460; Thu, 30 Jul 2015 15:41:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Thu, 30 Jul 2015 15:40:34 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Thu, 30 Jul 2015 16:40:34 -0600 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=047d7b3a9c12f1e43a051c1f654d Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: confirmation model in proof-of-possession-02) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 22:41:07 -0000 --047d7b3a9c12f1e43a051c1f654d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Some replies inline but the gist is that I disagree. On Thu, Jul 30, 2015 at 2:17 PM, Mike Jones wrote: > Part of the reasoning for using a structured confirmation claim, rather > than flattening the confirmation claim into the top-level JWT claims set, > is that a JWT may carry more than one conformation key or key descriptor, > as was mentioned in Prague. For instance, imagine that an application is > conveying an application-level confirmation key using the =E2=80=9Ccnf=E2= =80=9D claim and > for instance a token binding key using a second instance of the > confirmation structure, say using the =E2=80=9Ctokbnd=E2=80=9D claim. Wi= th the current > structured approach, you=E2=80=99d have: > > > > {=E2=80=A6 > > =E2=80=9Ccnf=E2=80=9D:{=E2=80=9Cjwk=E2=80=9D: =E2=80=A6}, > > =E2=80=9Ctokbnd=E2=80=9D:{=E2=80=9Cjwk=E2=80=9D: =E2=80=A6} > > } > > > That presumes token binding will use the same confirmation methods. But I'd imagine that the Token Binding ID would somehow be used to signal confirmation. So I'd be surprised if it ends up looking like that. The jwe member of the cnf claim defiantly wouldn't apply. It also presumes that you'd want cnf and tokbnd in the same JWT, which doesn't really make sense to me. This draft wants to establish a registry for JWT Confirmation Methods but a token binding confirmation would be a different claim? > If one were to flatten the structure, however, unique claim names would > have to be produced for the cross-product of each conformation element an= d > each confirmation claim. So you=E2=80=99d end up defining and registerin= g these > claims in the top-level JWT Claims registry: > > cnf_jwk > > cnf_jwe > > cnf_kid > > tokbnd_jwk > > tokbnd_jwe > > tokbnd_kid > > If you add other kind of confirmation keys, things would continue to get > even sillier. > Again that presumes token binding will use the same confirmation methods, which I think it unlikely. I suspect it'd be more like cjwk, cjwe, ckid, and ctbd. And a cnf with nested structure would need a tbd or tokbnd member defined and registered. > > > The code will be simpler if you can have a single shared routine for > handling confirmation structures rather a separate for handling cnf_jwk, > cnf_jwe, cnf_kid from the one for handling tokbnd_jwk, tokbnd_jwe, > tokbnd_kid, etc. > You can still have a shared routine for handling things that are the same. But with a nested structure you have to dig into the nesting. > > > Another reason the structure makes things conceptually simpler is that > then you can always use the name =E2=80=9Ckid=E2=80=9D to hold a key ID, = no matter the > context, rather than having to use *name-your-prefix*_kid. The same > holds true for other elements. > I personally don't find that convincing. It depends on how someone thinks about it. > > > I=E2=80=99m sorry this wasn=E2=80=99t clear in Prague. I know it was men= tioned in the > context of carrying multiple confirmation keys in a JWT, but it went by > pretty fast. > It was an informal discussion that was largely about something else. > > > Based on the discussion in Prague, I believe that we should add language > to the spec saying that applications can define new claim names other tha= n > =E2=80=9Ccnf=E2=80=9D to use to represent application-specific confirmati= on structures that > have the same syntax as those using the =E2=80=9Ccnf=E2=80=9D name. Woul= d that do the > trick for you? > That's not at all what I'm driving at. If you believe that there's need for multiple confirmation structures with the exact same syntax and meaning, I suppose that would be a useful addition. But if you really believe that, the structure itself should probably be adjusted to allow for multiples. I'm skeptical that it'll ever be needed. > > > By the way, I=E2=80=99m as much in favor of compactness as anyone. Heck = =E2=80=93 I was > one of the folks who foisted the short claim names like =E2=80=9Ciss=E2= =80=9D on the > world! But I really do believe that in this case, having structure makes > things more readable and more flexible, especially since there will be > cases where there are multiple confirmation structures in the same JWT. > I can see both sides of readability. I don't see the flexibility. > And once you prefix the names, you lose most of the space savings anyway. > Depends on how you prefix them or otherwise name things. You've chosen long prefixes to make your point but it wouldn't have to be that way. > > > Best > wishes, > > -- Mike > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian > Campbell > *Sent:* Thursday, July 30, 2015 11:29 AM > *To:* Nat Sakimura > *Cc:* oauth > *Subject:* [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: > confirmation model in proof-of-possession-02) > > > > Using individual claims for the different confirmation types would convey > the same information with a reduced message size, likely simpler > implementation, and avoid the need to establish a new registry. > > Seems like a no-brainer to me but maybe I'm overlooking something? > > There hasn't been much discussion that I'm aware of. Nat seemed in favor > of it (the +1 below). Mike was dismissive of it at the Dallas meeting but > didn't provide any reasoning (that I understood anyway). > > > > > > On Mon, Mar 23, 2015 at 10:18 AM, Nat Sakimura wrote= : > > +1 > > =3Dnat via iPhone > > > 2015/03/23 11:07=E3=80=81Brian Campbell =E3= =81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8: > > This is mostly about section 3.4 > > but also the whole draft. > > > If "cnf" is intended to analogous to the SAML 2.0 SubjectConfirmation > element, it should probably contain an array value rather than an object > value. SAML allows not just for multiple methods of confirming but for > multiple instances of the same method. IIRC, only one confirmation needs = to > be confirmable. > > I'm not sure the extra complexity is worth it though. I've rarely, if > ever, seen SAML assertions that make use of it. > > If the intent is just to allow for different kinds of confirmation, > couldn't the structure be pared down and simplified and just have > individual claims for the different confirmation types? Like "cjwk" and > "ckid" or similar that have the jwk or kid value respectively as the memb= er > value. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > --047d7b3a9c12f1e43a051c1f654d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Some replies inline but the gist is that I disagree.
<= div>

On Thu, Jul 3= 0, 2015 at 2:17 PM, Mike Jones <Michael.Jones@microsoft.com&= gt; wrote:

Part of the reasoning for using a str= uctured confirmation claim, rather than flattening the confirmation claim i= nto the top-level JWT claims set, is that a JWT may carry more than one conformation key or key descriptor, as was mention= ed in Prague.=C2=A0 For instance, imagine that an application is conveying = an application-level confirmation key using the =E2=80=9Ccnf=E2=80=9D claim= and for instance a token binding key using a second instance of the confirmation structure, say using the =E2=80=9Ctokbnd=E2= =80=9D claim.=C2=A0 With the current structured approach, you=E2=80=99d hav= e:

=C2=A0

{=E2=80=A6

=E2=80=9Ccnf=E2=80=9D:{=E2=80=9Cjwk= =E2=80=9D: =E2=80=A6},

=E2=80=9Ctokbnd=E2=80=9D:{=E2=80=9Cjw= k=E2=80=9D: =E2=80=A6}

}

=C2=A0

<= /blockquote>
That presumes token binding will use the same confirmation = methods. But I'd imagine that the Token Binding ID would somehow be use= d to signal confirmation. So I'd be surprised if it ends up looking lik= e that. The jwe member of the cnf claim defiantly wouldn't apply.
<= br>
It also presumes that you'd want cn= f and tokbnd in the same JWT, which doesn't really make sense to me. Th= is draft wants to establish a registry for JWT Confirmation Methods but a t= oken binding confirmation would be a different claim?

=C2=A0

If one were to flatten the structure,= however, unique claim names would have to be produced for the cross-produc= t of each conformation element and each confirmation claim.=C2=A0 So you=E2=80=99d end up defining and registering these claims= in the top-level JWT Claims registry:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cnf_jwk

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cnf_jwe

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cnf_kid

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 tokbnd_jwk=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 tokbnd_jwe=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 tokbnd_kid=

If you add other kind of confirmation= keys, things would continue to get even sillier.


Again that presumes token binding will use th= e same confirmation methods, which I think it unlikely.

I= suspect it'd be more like cjwk, cjwe, ckid, and ctbd.=C2=A0

An= d a cnf with nested structure would need a tbd or tokbnd member defined and= registered.
=C2=A0

=

=C2=A0

The code will be simpler if you can h= ave a single shared routine for handling confirmation structures rather a s= eparate for handling cnf_jwk, cnf_jwe, cnf_kid from the one for handling tokbnd_jwk, tokbnd_jwe, tokbnd_kid, etc.<= /p>


You can still have a shared= routine for handling things that are the same. But with a nested structure= you have to dig into the nesting.
=C2=A0

=C2=A0

Another reason the structure makes th= ings conceptually simpler is that then you can always use the name =E2=80= =9Ckid=E2=80=9D to hold a key ID, no matter the context, rather than having to use name-your-prefix_kid.=C2=A0 The same holds true = for other elements.


= I personally don't find that convincing. It depends on how someone thin= ks about it.
=C2=A0

=

=C2=A0

I=E2=80=99m sorry this wasn=E2=80=99t= clear in Prague.=C2=A0 I know it was mentioned in the context of carrying = multiple confirmation keys in a JWT, but it went by pretty fast.

=

It was an informal discussion = that was largely about something else.
=C2=A0

=C2=A0

Based on the discussion in Prague, I = believe that we should add language to the spec saying that applications ca= n define new claim names other than =E2=80=9Ccnf=E2=80=9D to use to represent application-specific confirmation structures that have the sa= me syntax as those using the =E2=80=9Ccnf=E2=80=9D name.=C2=A0 Would that d= o the trick for you?


That's not at all what I'm driving at.

If you b= elieve that there's need for multiple confirmation structures with the = exact same syntax and meaning, I suppose that would be a useful addition. B= ut if you really believe that, the structure itself should probably be adju= sted to allow for multiples. I'm skeptical that it'll ever be neede= d.
=C2=A0

=C2=A0

By the way, I=E2=80=99m as much in fa= vor of compactness as anyone.=C2=A0 Heck =E2=80=93 I was one of the folks w= ho foisted the short claim names like =E2=80=9Ciss=E2=80=9D on the world!= =C2=A0 But I really do believe that in this case, having structure makes things more readable = and more flexible, especially since there will be cases where there are mul= tiple confirmation structures in the same JWT.=C2=A0

=

I can see both sides of readability. I don= 't see the flexibility.
=C2=A0

And once you prefix the names, you lose most= of the space savings anyway.


Depends on = how you prefix them or otherwise name things. You've chosen long prefix= es to make your point but it wouldn't have to be that way.
=C2=A0

=

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Best wishes,

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

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, July 30, 2015 11:29 AM
To: Nat Sakimura <sakimura@gmail.com>
Cc: oauth <oa= uth@ietf.org>
Subject: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: c= onfirmation model in proof-of-possession-02)

<= div>

=C2=A0

Using individual clai= ms for the different confirmation types would convey the same information w= ith a reduced message size, likely simpler=C2=A0 implementation, and avoid = the need to establish a new registry.

Seems like a no-brainer to me but maybe I'm overlooking something?=C2= =A0

There hasn't been much discussion that I'm a= ware of. Nat seemed in favor of it (the +1 below). Mike was dismissive of i= t at the Dallas meeting but didn't provide any reasoning (that I unders= tood anyway).

=C2=A0

=C2=A0

On Mon, Mar 23, 2015 at 10:18 AM, Nat Sakimura <<= a href=3D"mailto:sakimura@gmail.com" target=3D"_blank">sakimura@gmail.com> wrote:

+1

=3Dnat via iPhone


2015/03/23 11:07= =E3=80=81Brian Campbell <bcampbell@pingidentity.com> =E3=81=AE=E3=83= =A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8:

This is mostly about section 3.4 but also the whole draft.


If "cnf" is intended to analogous to the SAML 2.0 SubjectConfirma= tion element, it should probably contain an array value rather than an obje= ct value. SAML allows not just for multiple methods of confirming but for m= ultiple instances of the same method. IIRC, only one confirmation needs to be confirmable.

I'm not sure the = extra complexity is worth it though. I've rarely, if ever, seen SAML as= sertions that make use of it.

If the intent is just= to allow for different kinds of confirmation, couldn't the structure b= e pared down and simplified and just have individual claims for the differe= nt confirmation types? Like "cjwk" and "ckid" or similar that have the jwk or kid value respectively as the member value= .=C2=A0

=C2=A0<= /p>

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

=C2=A0


--047d7b3a9c12f1e43a051c1f654d-- From nobody Thu Jul 30 15:48:39 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFF11AD0C2 for ; Thu, 30 Jul 2015 15:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vq7cxNh_T-50 for ; Thu, 30 Jul 2015 15:48:35 -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 CC32E1AD0CF for ; Thu, 30 Jul 2015 15:48:33 -0700 (PDT) Received: by iodd187 with SMTP id d187so68545295iod.2 for ; Thu, 30 Jul 2015 15:48:33 -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:content-type; bh=bNdJ+I7QJM9VV2uKNThO6ZG6b2cffUUj1j/xE33wcW8=; b=ml6VXwX18cuPX4js10OBPqXXRN1nOMLpfksGjZzJqbMy3FTYCSsSbjzju/ol+Wr/yE Sgro+0mcIu3QaWAJeTeKYsJP98YAAPHbIWSWRqvcuRtQBv0rC2fXz50IjUk/YD1LiJIf T16Y+CGRnDm7MD7P+JhWxqvgzDnrrgx31jT34= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=bNdJ+I7QJM9VV2uKNThO6ZG6b2cffUUj1j/xE33wcW8=; b=WoilcRTejx4g6pViQVTSUPHIvuKajZ50QX+VnCM3u3PJSeocNm5L/rC1B8WuGtyfuz YHUOpdlXQrRsRBK121LiIGYeDQAeoe96Izjn735NvyONCyI/0Ut5LWGyCUok6IxcXx+s lloLnA8cvWeiNQo77kbLOxpaWCei3U6jHWopr8tPw/NJCz5wJWDHTfn0Cg/FzWLKwYNu J2ebtNrVfuxPQptJQ4LI95c5pjXyBYi0XegDUkwMyLZ8YXXECXosDbhPy8lZW9NwouJB tEtLpUAxTqUPuIPDKDzFJ26bP/wzRnnuOLtmeVvPsq8gYEMHjjmM2BI1nWRKvd3E3iRp IfWA== X-Gm-Message-State: ALoCoQmTsM3HXc4kfWyWFyI1Tx0COslQeV3dDmx7XW96eUSpplH2OcVZqz0l3y9ujvnwhT7e7F5Z X-Received: by 10.107.136.160 with SMTP id s32mr13993877ioi.174.1438296513281; Thu, 30 Jul 2015 15:48:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Thu, 30 Jul 2015 15:48:03 -0700 (PDT) In-Reply-To: <3FBD2E36-79E8-4F4B-B2A5-1C3DC5E29D3D@ve7jtb.com> References: <3FBD2E36-79E8-4F4B-B2A5-1C3DC5E29D3D@ve7jtb.com> From: Brian Campbell Date: Thu, 30 Jul 2015 16:48:03 -0600 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a113ecffec19ed0051c1f8048 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: confirmation model in proof-of-possession-02) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 22:48:38 -0000 --001a113ecffec19ed0051c1f8048 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To really support that case where an initial AS/issuer wants to bind to two presenters, shouldn't the confirmation structure itself allow for multiple confirmation methods (i.e. be or allow for an array)? I don't actually think that is needed but the flexibility that's being argued for here would suggest that rather than renaming a nested structure that only allows for a single occurrence of each kind of confirmation method. On Thu, Jul 30, 2015 at 3:14 PM, John Bradley wrote: > I agree, flattening would be a bad direction. > > In Prague I was indicating that there may be more than one presenter for > an assertion. The first presenter may be the OAuth client who presents i= t > to a RS. > > That RS itself may also present that token as a client in token exchange > to get a new access token for another resource. > > The initial AS may want to bind that token to two presenters. The secon= d > AS doing the token exchange also probably only wants to know about the > proof key for the RS so that it doesn=E2=80=99t mistakenly give the first= client a > token to directly access a backend API. > > Trying to find a generic pattern for that is a bit of a trick though. > > I think that a single cnf element is enough for most use cases, however > having cnf and cnf_rs or some other element using the cnf structure is > probably the best we can do at this point. > > John B. > > On Jul 30, 2015, at 5:17 PM, Mike Jones > wrote: > > Part of the reasoning for using a structured confirmation claim, rather > than flattening the confirmation claim into the top-level JWT claims set, > is that a JWT may carry more than one conformation key or key descriptor, > as was mentioned in Prague. For instance, imagine that an application is > conveying an application-level confirmation key using the =E2=80=9Ccnf=E2= =80=9D claim and > for instance a token binding key using a second instance of the > confirmation structure, say using the =E2=80=9Ctokbnd=E2=80=9D claim. Wi= th the current > structured approach, you=E2=80=99d have: > > {=E2=80=A6 > =E2=80=9Ccnf=E2=80=9D:{=E2=80=9Cjwk=E2=80=9D: =E2=80=A6}, > =E2=80=9Ctokbnd=E2=80=9D:{=E2=80=9Cjwk=E2=80=9D: =E2=80=A6} > } > > If one were to flatten the structure, however, unique claim names would > have to be produced for the cross-product of each conformation element an= d > each confirmation claim. So you=E2=80=99d end up defining and registerin= g these > claims in the top-level JWT Claims registry: > cnf_jwk > cnf_jwe > cnf_kid > tokbnd_jwk > tokbnd_jwe > tokbnd_kid > If you add other kind of confirmation keys, things would continue to get > even sillier. > > The code will be simpler if you can have a single shared routine for > handling confirmation structures rather a separate for handling cnf_jwk, > cnf_jwe, cnf_kid from the one for handling tokbnd_jwk, tokbnd_jwe, > tokbnd_kid, etc. > > Another reason the structure makes things conceptually simpler is that > then you can always use the name =E2=80=9Ckid=E2=80=9D to hold a key ID, = no matter the > context, rather than having to use *name-your-prefix*_kid. The same > holds true for other elements. > > I=E2=80=99m sorry this wasn=E2=80=99t clear in Prague. I know it was men= tioned in the > context of carrying multiple confirmation keys in a JWT, but it went by > pretty fast. > > Based on the discussion in Prague, I believe that we should add language > to the spec saying that applications can define new claim names other tha= n > =E2=80=9Ccnf=E2=80=9D to use to represent application-specific confirmati= on structures that > have the same syntax as those using the =E2=80=9Ccnf=E2=80=9D name. Woul= d that do the > trick for you? > > By the way, I=E2=80=99m as much in favor of compactness as anyone. Heck = =E2=80=93 I was > one of the folks who foisted the short claim names like =E2=80=9Ciss=E2= =80=9D on the > world! But I really do believe that in this case, having structure makes > things more readable and more flexible, especially since there will be > cases where there are multiple confirmation structures in the same JWT. > And once you prefix the names, you lose most of the space savings anyway. > > Best > wishes, > -- Mike > > *From:* OAuth [mailto:oauth-bounces@ietf.org ] *O= n > Behalf Of *Brian Campbell > *Sent:* Thursday, July 30, 2015 11:29 AM > *To:* Nat Sakimura > *Cc:* oauth > *Subject:* [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: > confirmation model in proof-of-possession-02) > > > Using individual claims for the different confirmation types would convey > the same information with a reduced message size, likely simpler > implementation, and avoid the need to establish a new registry. > > Seems like a no-brainer to me but maybe I'm overlooking something? > There hasn't been much discussion that I'm aware of. Nat seemed in favor > of it (the +1 below). Mike was dismissive of it at the Dallas meeting but > didn't provide any reasoning (that I understood anyway). > > > On Mon, Mar 23, 2015 at 10:18 AM, Nat Sakimura wrote= : > > +1 > > =3Dnat via iPhone > > > 2015/03/23 11:07=E3=80=81Brian Campbell =E3= =81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8: > > This is mostly about section 3.4 > > but also the whole draft. > > > If "cnf" is intended to analogous to the SAML 2.0 SubjectConfirmation > element, it should probably contain an array value rather than an object > value. SAML allows not just for multiple methods of confirming but for > multiple instances of the same method. IIRC, only one confirmation needs = to > be confirmable. > > I'm not sure the extra complexity is worth it though. I've rarely, if > ever, seen SAML assertions that make use of it. > > If the intent is just to allow for different kinds of confirmation, > couldn't the structure be pared down and simplified and just have > individual claims for the different confirmation types? Like "cjwk" and > "ckid" or similar that have the jwk or kid value respectively as the memb= er > value. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --001a113ecffec19ed0051c1f8048 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
To really support that case where an initial AS/issuer wan= ts to bind to two presenters, shouldn't the confirmation structure itse= lf allow for multiple confirmation methods (i.e. be or allow for an array)?= =C2=A0 I don't actually think that is needed but the flexibility that&#= 39;s being argued for here would suggest that rather than renaming a nested= structure that only allows for a single occurrence of each kind of confirm= ation method.

On Thu, Jul 30, 2015 at 3:14 PM, John Bradley <<= a href=3D"mailto:ve7jtb@ve7jtb.com" target=3D"_blank">ve7jtb@ve7jtb.com= > wrote:
I agree, flattening would be a bad direction.

<= div>In Prague I was indicating that there may be more than one presenter fo= r an assertion.=C2=A0 The first presenter may be the OAuth client who prese= nts it to a RS.

That RS itself may= also present that token as a client in token exchange to get a new access = token for another resource.

The initial AS may wan= t to bind that token to two presenters. =C2=A0 The second AS doing the toke= n exchange also probably only wants to know about the proof key for the RS = so that it doesn=E2=80=99t mistakenly give the first client a token to dire= ctly access a backend API.

Tryin= g to find a generic pattern for that is a bit of a trick though.
=
I think that a single cnf element is enough for most use cas= es, however having cnf and cnf_rs or some other element using the cnf struc= ture is probably the best we can do at this point.

John B.

On J= ul 30, 2015, at 5:17 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
Part of the reasonin= g for using a structured confirmation claim, rather than flattening the con= firmation claim into the top-level JWT claims set, is that a JWT may carry = more than one conformation key or key descriptor, as was mentioned in Pragu= e.=C2=A0 For instance, imagine that an application is conveying an applicat= ion-level confirmation key using the =E2=80=9Ccnf=E2=80=9D claim and for in= stance a token binding key using a second instance of the confirmation stru= cture, say using the =E2=80=9Ctokbnd=E2=80=9D claim.=C2=A0 With the current= structured approach, you=E2=80=99d have:
=C2=A0
{=E2= =80=A6
=E2=80=9Ccnf= =E2=80=9D:{=E2=80=9Cjwk=E2=80=9D: =E2=80=A6},
=E2=80=9Ctokbnd=E2=80=9D:{=E2=80=9Cjwk=E2=80=9D: = =E2=80=A6}
}<= u>
=C2=A0
If one were to flatten the structure, however, unique = claim names would have to be produced for the cross-product of each conform= ation element and each confirmation claim.=C2=A0 So you=E2=80=99d end up de= fining and registering these claims in the top-level JWT Claims registry:
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cnf_j= wk
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= cnf_jwe
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 cnf_kid
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 tokbnd_jwk
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 tokbnd_jwe
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 tokbnd_kid
If you add other kind of confirmation keys, things wo= uld continue to get even sillier.
=C2=A0
The code will= be simpler if you can have a single shared routine for handling confirmati= on structures rather a separate for handling cnf_jwk, cnf_jwe, cnf_kid from= the one for handling tokbnd_jwk, tokbnd_jwe, tokbnd_kid, etc.
=C2=A0
Another reason the structure makes things conceptually simp= ler is that then you can always use the name =E2=80=9Ckid=E2=80=9D to hold = a key ID, no matter the context, rather than having to use=C2=A0name-your-prefix_kid.=C2=A0 The same holds true for other elements= .
=C2=A0
I=E2=80=99m sorry this wasn=E2=80=99t clear i= n Prague.=C2=A0 I know it was mentioned in the context of carrying multiple= confirmation keys in a JWT, but it went by pretty fast.
=C2=A0
Based on the discussion in Prague, I believe that we should add l= anguage to the spec saying that applications can define new claim names oth= er than =E2=80=9Ccnf=E2=80=9D to use to represent application-specific conf= irmation structures that have the same syntax as those using the =E2=80=9Cc= nf=E2=80=9D name.=C2=A0 Would that do the trick for you?
=C2=A0
By the way, I=E2=80=99m as much in favor of compactness as anyone= .=C2=A0 Heck =E2=80=93 I was one of the folks who foisted the short claim n= ames like =E2=80=9Ciss=E2=80=9D on the world!=C2=A0 But I really do believe= that in this case, having structure makes things more readable and more fl= exible, especially since there will be cases where there are multiple confi= rmation structures in the same JWT.=C2=A0 And once you prefix the names, yo= u lose most of the space savings anyway.
=C2=A0
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Best wishes,
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= -- Mike
=C2=A0
From:=C2=A0OAuth [mailto:oauth-bounces@ietf.org]= =C2=A0On Behalf Of=C2=A0Brian Campbell
Sen= t:=C2=A0Thursday, July 30, 2015 11:29 AM
To:=C2=A0Nat Sakimura <sakimura@gmail.com>
Cc:=C2=A0oau= th <oauth@ietf.org>
Subject:=C2=A0[OAUTH-WG] JWT PoP Key Semantic= s WGLC followup 3 (was Re: confirmation model in proof-of-possession-02)=

Using individual claims for th= e different confirmation types would convey the same information with a red= uced message size, likely simpler=C2=A0 implementation, and avoid the need = to establish a new registry.=C2=A0

Seems like a no-brai= ner to me but maybe I'm overlooking something?=C2=A0=C2=A0=

There hasn't been much d= iscussion that I'm aware of. Nat seemed in favor of it (the +1 below). = Mike was dismissive of it at the Dallas meeting but didn't provide any = reasoning (that I understood anyway).
=C2=A0
<= u>=C2=A0
+1

=3Dnat via iPhone
=


2015/03/23 11:07=E3=80=81Brian Campbell <bcampbell@pingidentity.com>=C2=A0=E3=81=AE=E3=83=A1=E3= =83=83=E3=82=BB=E3=83=BC=E3=82=B8:

=
This is mostly about=C2=A0section 3.4=C2=A0but also the whole draft= .


If= "cnf" is intended to analogous to the SAML 2.0 SubjectConfirmati= on element, it should probably contain an array value rather than an object= value. SAML allows not just for multiple methods of confirming but for mul= tiple instances of the same method. IIRC, only one confirmation needs to be= confirmable.

I'm not sure the extra complexity is worth it though. I've rare= ly, if ever, seen SAML assertions that make use of it.

If the intent is just to allow= for different kinds of confirmation, couldn't the structure be pared d= own and simplified and just have individual claims for the different confir= mation types? Like "cjwk" and "ckid" or similar that ha= ve the jwk or kid value respectively as the member value.=C2=A0=C2=A0=

=C2=A0

_______________________________________________
OAuth mailing list=
OAuth@ietf.org
https://www.ietf.org/mailm= an/listinfo/oauth
=C2=A0
____= ___________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/l= istinfo/oauth


--001a113ecffec19ed0051c1f8048-- From nobody Thu Jul 30 15:52:48 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89781AD0A8 for ; Thu, 30 Jul 2015 15:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pMuuP_WCY8P for ; Thu, 30 Jul 2015 15:52:43 -0700 (PDT) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2C601AD072 for ; Thu, 30 Jul 2015 15:52:42 -0700 (PDT) Received: by qgeh16 with SMTP id h16so34840346qge.3 for ; Thu, 30 Jul 2015 15:52:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=EUMbm74k8RLSkUwxyqpAEnvprgiCSNFNzd9peEmexKQ=; b=Fx/flgOi8R3seTNUwEPJC6OCXz7mDPtgOSkJhe1V09PavZ1tAvDy71YnhXzsXktdPr elOQoD8ft2TwX0neCl9JQa1OV91H1gQQ3DJMPOWz9b0CDyCV/zhixBq4/Fy/0O5YNm/o puych4o+ZDEb2IoGsjFChP56PG3ryJT9Ua67qS4J3TuCTduL94JUJ2+B3QJJYK94T+z3 tAgDODhJwdUjZwtq5PEakVGSqjamoBkjW9qd1k2W1TNs0RKBOZZ6rCujdMf3ex2K0w+7 +Asd0gltK6S2i1HDyOT2RsG7hGWlfLNOEnPntsgKYiLZodaYLqiPxt3sAHnzQC4he06h HJ3g== X-Gm-Message-State: ALoCoQlWXOHJzhDwEA6D/Dl1thaeeAtcyYi8HsEblJ19a/pIMnbpNjVZWGYUwIszJusait2pFeKV X-Received: by 10.140.19.48 with SMTP id 45mr40472542qgg.13.1438296761870; Thu, 30 Jul 2015 15:52:41 -0700 (PDT) Received: from [192.168.1.216] (186-79-94-106.baf.movistar.cl. [186.79.94.106]) by smtp.gmail.com with ESMTPSA id d30sm1223882qkh.45.2015.07.30.15.52.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Jul 2015 15:52:40 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_ECAA9138-7B9E-489D-BD33-D8C1C5EAB842" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: John Bradley In-Reply-To: Date: Thu, 30 Jul 2015 19:52:33 -0300 Message-Id: References: To: Brian Campbell X-Mailer: Apple Mail (2.2102) Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: confirmation model in proof-of-possession-02) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 22:52:47 -0000 --Apple-Mail=_ECAA9138-7B9E-489D-BD33-D8C1C5EAB842 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Token binding might be a bad example. I can=E2=80=99t see why you would need something separate unless you are = trying to do something like message signing and token binding. =20 I guess that is theoretically posable. Typically I think token binding would use the normal cnf containing a = JWK with the public key. The difference between token binding and mutual TLS is in the = presentment one is TLS client auth and the other is a signature over the = tls unique in a header. I think multiple cnf methods for the same presenter like SAML is = overkill. However the ability to re-use the cnf structure for people who want = something custom seems reasonable (we couldn't stop them anyway) John B. > On Jul 30, 2015, at 7:40 PM, Brian Campbell = wrote: >=20 > Some replies inline but the gist is that I disagree.=20 >=20 > On Thu, Jul 30, 2015 at 2:17 PM, Mike Jones = > = wrote: > Part of the reasoning for using a structured confirmation claim, = rather than flattening the confirmation claim into the top-level JWT = claims set, is that a JWT may carry more than one conformation key or = key descriptor, as was mentioned in Prague. For instance, imagine that = an application is conveying an application-level confirmation key using = the =E2=80=9Ccnf=E2=80=9D claim and for instance a token binding key = using a second instance of the confirmation structure, say using the = =E2=80=9Ctokbnd=E2=80=9D claim. With the current structured approach, = you=E2=80=99d have: >=20 > =20 >=20 > {=E2=80=A6 >=20 > =E2=80=9Ccnf=E2=80=9D:{=E2=80=9Cjwk=E2=80=9D: =E2=80=A6}, >=20 > =E2=80=9Ctokbnd=E2=80=9D:{=E2=80=9Cjwk=E2=80=9D: =E2=80=A6} >=20 > } >=20 > =20 >=20 >=20 > That presumes token binding will use the same confirmation methods. = But I'd imagine that the Token Binding ID would somehow be used to = signal confirmation. So I'd be surprised if it ends up looking like = that. The jwe member of the cnf claim defiantly wouldn't apply.=20 >=20 > It also presumes that you'd want cnf and tokbnd in the same JWT, which = doesn't really make sense to me. This draft wants to establish a = registry for JWT Confirmation Methods but a token binding confirmation = would be a different claim? >=20 > =20 >=20 > If one were to flatten the structure, however, unique claim names = would have to be produced for the cross-product of each conformation = element and each confirmation claim. So you=E2=80=99d end up defining = and registering these claims in the top-level JWT Claims registry: >=20 > cnf_jwk >=20 > cnf_jwe >=20 > cnf_kid >=20 > tokbnd_jwk >=20 > tokbnd_jwe >=20 > tokbnd_kid >=20 > If you add other kind of confirmation keys, things would continue to = get even sillier. >=20 >=20 > Again that presumes token binding will use the same confirmation = methods, which I think it unlikely. >=20 > I suspect it'd be more like cjwk, cjwe, ckid, and ctbd. =20 >=20 > And a cnf with nested structure would need a tbd or tokbnd member = defined and registered.=20 > =20 >=20 > =20 >=20 > The code will be simpler if you can have a single shared routine for = handling confirmation structures rather a separate for handling cnf_jwk, = cnf_jwe, cnf_kid from the one for handling tokbnd_jwk, tokbnd_jwe, = tokbnd_kid, etc. >=20 >=20 > You can still have a shared routine for handling things that are the = same. But with a nested structure you have to dig into the nesting. > =20 >=20 > =20 >=20 > Another reason the structure makes things conceptually simpler is that = then you can always use the name =E2=80=9Ckid=E2=80=9D to hold a key ID, = no matter the context, rather than having to use name-your-prefix_kid. = The same holds true for other elements. >=20 >=20 > I personally don't find that convincing. It depends on how someone = thinks about it.=20 > =20 >=20 > =20 >=20 > I=E2=80=99m sorry this wasn=E2=80=99t clear in Prague. I know it was = mentioned in the context of carrying multiple confirmation keys in a = JWT, but it went by pretty fast. >=20 >=20 > It was an informal discussion that was largely about something else. > =20 >=20 > =20 >=20 > Based on the discussion in Prague, I believe that we should add = language to the spec saying that applications can define new claim names = other than =E2=80=9Ccnf=E2=80=9D to use to represent = application-specific confirmation structures that have the same syntax = as those using the =E2=80=9Ccnf=E2=80=9D name. Would that do the trick = for you? >=20 >=20 > That's not at all what I'm driving at.=20 >=20 > If you believe that there's need for multiple confirmation structures = with the exact same syntax and meaning, I suppose that would be a useful = addition. But if you really believe that, the structure itself should = probably be adjusted to allow for multiples. I'm skeptical that it'll = ever be needed. > =20 >=20 > =20 >=20 > By the way, I=E2=80=99m as much in favor of compactness as anyone. = Heck =E2=80=93 I was one of the folks who foisted the short claim names = like =E2=80=9Ciss=E2=80=9D on the world! But I really do believe that = in this case, having structure makes things more readable and more = flexible, especially since there will be cases where there are multiple = confirmation structures in the same JWT.=20 >=20 >=20 > I can see both sides of readability. I don't see the flexibility.=20 > =20 > And once you prefix the names, you lose most of the space savings = anyway. >=20 >=20 > Depends on how you prefix them or otherwise name things. You've chosen = long prefixes to make your point but it wouldn't have to be that way.=20 > =20 >=20 > =20 >=20 > Best = wishes, >=20 > -- = Mike >=20 > =20 >=20 > From: OAuth [mailto:oauth-bounces@ietf.org = ] On Behalf Of Brian Campbell > Sent: Thursday, July 30, 2015 11:29 AM > To: Nat Sakimura > > Cc: oauth > > Subject: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: = confirmation model in proof-of-possession-02) >=20 > =20 >=20 > Using individual claims for the different confirmation types would = convey the same information with a reduced message size, likely simpler = implementation, and avoid the need to establish a new registry.=20 >=20 > Seems like a no-brainer to me but maybe I'm overlooking something? =20 >=20 > There hasn't been much discussion that I'm aware of. Nat seemed in = favor of it (the +1 below). Mike was dismissive of it at the Dallas = meeting but didn't provide any reasoning (that I understood anyway). >=20 > =20 >=20 > =20 >=20 > On Mon, Mar 23, 2015 at 10:18 AM, Nat Sakimura > wrote: >=20 > +1 >=20 > =3Dnat via iPhone >=20 >=20 > 2015/03/23 11:07=E3=80=81Brian Campbell > =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3= =83=BC=E3=82=B8: >=20 > This is mostly about section 3.4 = but also the whole draft. >=20 >=20 > If "cnf" is intended to analogous to the SAML 2.0 SubjectConfirmation = element, it should probably contain an array value rather than an object = value. SAML allows not just for multiple methods of confirming but for = multiple instances of the same method. IIRC, only one confirmation needs = to be confirmable. >=20 > I'm not sure the extra complexity is worth it though. I've rarely, if = ever, seen SAML assertions that make use of it. >=20 > If the intent is just to allow for different kinds of confirmation, = couldn't the structure be pared down and simplified and just have = individual claims for the different confirmation types? Like "cjwk" and = "ckid" or similar that have the jwk or kid value respectively as the = member value. =20 >=20 >=20 > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = > =20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_ECAA9138-7B9E-489D-BD33-D8C1C5EAB842 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Token binding might be a bad example.

I can=E2=80=99t see why you would need = something separate unless you are trying to do something like message = signing and token binding.  
I guess that is = theoretically posable.

Typically I think token binding would use the normal cnf = containing a JWK with the public key.

The difference between token binding = and mutual TLS is in the presentment one is TLS client auth and the = other is a signature over the tls unique in a header.

I think multiple cnf = methods for the same presenter like SAML is overkill.

However the ability to = re-use the cnf structure for people who want something custom seems = reasonable (we couldn't stop them anyway)

John B.
On Jul 30, 2015, at 7:40 PM, = Brian Campbell <bcampbell@pingidentity.com> wrote:

Some replies inline but = the gist is that I disagree. 

On Thu, Jul 30, 2015 at 2:17 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Part of the = reasoning for using a structured confirmation claim, rather than = flattening the confirmation claim into the top-level JWT claims set, is = that a JWT may carry more than one conformation key or key descriptor, = as was mentioned in Prague.  For instance, imagine that an = application is conveying an application-level confirmation key using the = =E2=80=9Ccnf=E2=80=9D claim and for instance a token binding key using a = second instance of the confirmation structure, say using the = =E2=80=9Ctokbnd=E2=80=9D claim.  With the current structured = approach, you=E2=80=99d have:

 

{=E2=80=A6

=E2=80=9Ccnf=E2=80=9D:{=E2=80=9Cjwk=E2=80=9D: = =E2=80=A6},

=E2=80=9Ctokbnd=E2=80=9D:{=E2=80=9Cjwk=E2=80=9D: =E2=80=A6}

}

 

That presumes token binding will use the same confirmation = methods. But I'd imagine that the Token Binding ID would somehow be used = to signal confirmation. So I'd be surprised if it ends up looking like = that. The jwe member of the cnf claim defiantly wouldn't apply. 

It also presumes that you'd = want cnf and tokbnd in the same JWT, which doesn't really make sense to = me. This draft wants to establish a registry for JWT Confirmation = Methods but a token binding confirmation would be a different claim?

 

If one were to flatten the structure, however, unique claim = names would have to be produced for the cross-product of each = conformation element and each confirmation claim.  So you=E2=80=99d = end up defining and registering these claims in the top-level JWT Claims = registry:

          &nb= sp;     cnf_jwk

          &nb= sp;     cnf_jwe

          &nb= sp;     cnf_kid

          &nb= sp;     tokbnd_jwk

          &nb= sp;     tokbnd_jwe

          &nb= sp;     tokbnd_kid

If you add other kind of confirmation keys, = things would continue to get even = sillier.


Again that presumes token binding will = use the same confirmation methods, which I think it unlikely.

I suspect it'd be more = like cjwk, cjwe, ckid, and ctbd.  

And a cnf with nested structure would need a tbd or tokbnd = member defined and registered. 
 

 

The code will be simpler if you can have a single shared = routine for handling confirmation structures rather a separate for = handling cnf_jwk, cnf_jwe, cnf_kid from the one for handling tokbnd_jwk, = tokbnd_jwe, tokbnd_kid, etc.


You can still have a = shared routine for handling things that are the same. But with a nested = structure you have to dig into the nesting.
 

 

Another reason the structure makes things conceptually = simpler is that then you can always use the name =E2=80=9Ckid=E2=80=9D = to hold a key ID, no matter the context, rather than having to use name-your-prefix_kid.  The same holds true for other = elements.


I personally don't find that = convincing. It depends on how someone thinks about it. 
 

 

I=E2=80=99m sorry this wasn=E2=80=99t clear in Prague.  = I know it was mentioned in the context of carrying multiple confirmation = keys in a JWT, but it went by pretty = fast.


It was an informal discussion that was = largely about something else.
 

 

Based on the discussion in Prague, I believe that we should = add language to the spec saying that applications can define new claim = names other than =E2=80=9Ccnf=E2=80=9D to use to represent = application-specific confirmation structures that have the same syntax = as those using the =E2=80=9Ccnf=E2=80=9D name.  Would that do the = trick for you?


That's not at all what I'm driving = at. 

If you believe that there's need for = multiple confirmation structures with the exact same syntax and meaning, = I suppose that would be a useful addition. But if you really believe = that, the structure itself should probably be adjusted to allow for = multiples. I'm skeptical that it'll ever be needed.
 

 

By the way, I=E2=80=99m as much in favor of compactness as = anyone.  Heck =E2=80=93 I was one of the folks who foisted the = short claim names like =E2=80=9Ciss=E2=80=9D on the world!  But I = really do believe that in this case, having structure makes things more = readable and more flexible, especially since there will be cases where = there are multiple confirmation structures in the same = JWT. 


I can see both sides of readability. I = don't see the flexibility. 
 

And = once you prefix the names, you lose most of the space savings = anyway.


Depends on how you prefix them or = otherwise name things. You've chosen long prefixes to make your point = but it wouldn't have to be that way. 
 

 

          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    Best= wishes,

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

 

From: OAuth = [mailto:oauth-bounces@ietf.org] On Behalf = Of Brian = Campbell
Sent: Thursday, July 30, 2015 = 11:29 AM
To: Nat Sakimura <sakimura@gmail.com>
Cc: oauth= <oauth@ietf.org>
Subject: [OAUTH-WG] JWT PoP Key = Semantics WGLC followup 3 (was Re: confirmation model in = proof-of-possession-02)

 

Using = individual claims for the different confirmation types would convey the = same information with a reduced message size, likely simpler  = implementation, and avoid the need to establish a new registry. 

Seems like a no-brainer to me but maybe I'm overlooking = something?  

There = hasn't been much discussion that I'm aware of. Nat seemed in favor of it = (the +1 below). Mike was dismissive of it at the Dallas meeting but = didn't provide any reasoning (that I understood anyway).

 

 

On Mon, Mar 23, 2015 at 10:18 AM, Nat Sakimura = <sakimura@gmail.com> wrote:

+1

=3Dnat via iPhone


2015/03/23 11:07=E3=80=81Bri= an Campbell <bcampbell@pingidentity.com> =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8:

This = is mostly about section 3.4 but also the whole draft.


If = "cnf" is intended to analogous to the SAML 2.0 SubjectConfirmation = element, it should probably contain an array value rather than an object = value. SAML allows not just for multiple methods of confirming but for = multiple instances of the same method. IIRC, only one confirmation needs = to be confirmable.

I'm not = sure the extra complexity is worth it though. I've rarely, if ever, seen = SAML assertions that make use of it.

If the intent is just to allow for = different kinds of confirmation, couldn't the structure be pared down = and simplified and just have individual claims for the different = confirmation types? Like "cjwk" and "ckid" or similar that have the jwk = or kid value respectively as the member value.  

 

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

 

<= /blockquote>

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

= --Apple-Mail=_ECAA9138-7B9E-489D-BD33-D8C1C5EAB842-- From nobody Thu Jul 30 16:01:01 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A69CC1AD0A7 for ; Thu, 30 Jul 2015 16:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZO3CSV_mnJDJ for ; Thu, 30 Jul 2015 16:00:57 -0700 (PDT) Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC3221ACE67 for ; Thu, 30 Jul 2015 16:00:56 -0700 (PDT) Received: by qgii95 with SMTP id i95so35071721qgi.2 for ; Thu, 30 Jul 2015 16:00:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=xhu+kqsMxa+5U/AP4z4uJgE/+Z+Zc3RTXcLYfisn0ds=; b=GfUPBGdfWHO+YF1j2+IC5+rzgbhImyL9wTqFxTm9Zd2mVD6c3ZdbOTS6f26ECF1UDC gy+efuDp7CNCPzyf08XKaXKrmR8u7OG8R3ciCUwRGqcMCW6OupLcZUNIBlyS+u/xBhrA wOLu1naQICh+0QAar9p380KfPFKyvx0hHoYsDJAA0EDrzggR5PJfO3rJZKu1zOgxTbQ+ lem0Mm2Tuhq4LMHKWhlR4vBMpKfW0rW6/17ziptSweDRBuTpmFQTs80QY9jGZ/THgYRU W8NBl/Dajuy85zwAI88LXaRS13jm0FtrWBapk5WTkEoAr2B56YpMtLwE9aDJY5n6KxL3 xYfg== X-Gm-Message-State: ALoCoQkkQZ1zo4VQnkh/HRjSSRMcdk8Qmq32H3GkmziQWoP0TRcnj6AGKdWKlezYe95yp0XmUVXI X-Received: by 10.140.86.137 with SMTP id p9mr75075365qgd.89.1438297256067; Thu, 30 Jul 2015 16:00:56 -0700 (PDT) Received: from [192.168.1.216] (186-79-94-106.baf.movistar.cl. [186.79.94.106]) by smtp.gmail.com with ESMTPSA id e207sm1240623qhc.8.2015.07.30.16.00.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Jul 2015 16:00:55 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_9D88804F-7EC7-4BC8-8C6F-37BB987D994C" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: John Bradley In-Reply-To: Date: Thu, 30 Jul 2015 20:00:18 -0300 Message-Id: <97107378-B07E-472D-954E-FA4360B17576@ve7jtb.com> References: <3FBD2E36-79E8-4F4B-B2A5-1C3DC5E29D3D@ve7jtb.com> To: Brian Campbell X-Mailer: Apple Mail (2.2102) Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: confirmation model in proof-of-possession-02) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 23:01:00 -0000 --Apple-Mail=_9D88804F-7EC7-4BC8-8C6F-37BB987D994C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In my example you don=E2=80=99t really want to treat both the presenters = as equivalent. Endpoints receiving the token should be able to tell = which presenter gave it to them and apply policy on that. If you wanted them to be equivalent then an array would work, but that = probably adds more confusion. John B. > On Jul 30, 2015, at 7:48 PM, Brian Campbell = wrote: >=20 > To really support that case where an initial AS/issuer wants to bind = to two presenters, shouldn't the confirmation structure itself allow for = multiple confirmation methods (i.e. be or allow for an array)? I don't = actually think that is needed but the flexibility that's being argued = for here would suggest that rather than renaming a nested structure that = only allows for a single occurrence of each kind of confirmation method.=20= >=20 > On Thu, Jul 30, 2015 at 3:14 PM, John Bradley > wrote: > I agree, flattening would be a bad direction. >=20 > In Prague I was indicating that there may be more than one presenter = for an assertion. The first presenter may be the OAuth client who = presents it to a RS.=20 >=20 > That RS itself may also present that token as a client in token = exchange to get a new access token for another resource. >=20 > The initial AS may want to bind that token to two presenters. The = second AS doing the token exchange also probably only wants to know = about the proof key for the RS so that it doesn=E2=80=99t mistakenly = give the first client a token to directly access a backend API.=20 >=20 > Trying to find a generic pattern for that is a bit of a trick though. >=20 > I think that a single cnf element is enough for most use cases, = however having cnf and cnf_rs or some other element using the cnf = structure is probably the best we can do at this point. >=20 > John B. >=20 >> On Jul 30, 2015, at 5:17 PM, Mike Jones > wrote: >>=20 >> Part of the reasoning for using a structured confirmation claim, = rather than flattening the confirmation claim into the top-level JWT = claims set, is that a JWT may carry more than one conformation key or = key descriptor, as was mentioned in Prague. For instance, imagine that = an application is conveying an application-level confirmation key using = the =E2=80=9Ccnf=E2=80=9D claim and for instance a token binding key = using a second instance of the confirmation structure, say using the = =E2=80=9Ctokbnd=E2=80=9D claim. With the current structured approach, = you=E2=80=99d have: >> =20 >> {=E2=80=A6 >> =E2=80=9Ccnf=E2=80=9D:{=E2=80=9Cjwk=E2=80=9D: =E2=80=A6}, >> =E2=80=9Ctokbnd=E2=80=9D:{=E2=80=9Cjwk=E2=80=9D: =E2=80=A6} >> } >> =20 >> If one were to flatten the structure, however, unique claim names = would have to be produced for the cross-product of each conformation = element and each confirmation claim. So you=E2=80=99d end up defining = and registering these claims in the top-level JWT Claims registry: >> cnf_jwk >> cnf_jwe >> cnf_kid >> tokbnd_jwk >> tokbnd_jwe >> tokbnd_kid >> If you add other kind of confirmation keys, things would continue to = get even sillier. >> =20 >> The code will be simpler if you can have a single shared routine for = handling confirmation structures rather a separate for handling cnf_jwk, = cnf_jwe, cnf_kid from the one for handling tokbnd_jwk, tokbnd_jwe, = tokbnd_kid, etc. >> =20 >> Another reason the structure makes things conceptually simpler is = that then you can always use the name =E2=80=9Ckid=E2=80=9D to hold a = key ID, no matter the context, rather than having to use = name-your-prefix_kid. The same holds true for other elements. >> =20 >> I=E2=80=99m sorry this wasn=E2=80=99t clear in Prague. I know it was = mentioned in the context of carrying multiple confirmation keys in a = JWT, but it went by pretty fast. >> =20 >> Based on the discussion in Prague, I believe that we should add = language to the spec saying that applications can define new claim names = other than =E2=80=9Ccnf=E2=80=9D to use to represent = application-specific confirmation structures that have the same syntax = as those using the =E2=80=9Ccnf=E2=80=9D name. Would that do the trick = for you? >> =20 >> By the way, I=E2=80=99m as much in favor of compactness as anyone. = Heck =E2=80=93 I was one of the folks who foisted the short claim names = like =E2=80=9Ciss=E2=80=9D on the world! But I really do believe that = in this case, having structure makes things more readable and more = flexible, especially since there will be cases where there are multiple = confirmation structures in the same JWT. And once you prefix the names, = you lose most of the space savings anyway. >> =20 >> Best = wishes, >> -- = Mike >> =20 >> From: OAuth [mailto:oauth-bounces@ietf.org = ] On Behalf Of Brian Campbell >> Sent: Thursday, July 30, 2015 11:29 AM >> To: Nat Sakimura > >> Cc: oauth > >> Subject: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: = confirmation model in proof-of-possession-02) >> =20 >> Using individual claims for the different confirmation types would = convey the same information with a reduced message size, likely simpler = implementation, and avoid the need to establish a new registry.=20 >>=20 >> Seems like a no-brainer to me but maybe I'm overlooking something? =20= >>=20 >> There hasn't been much discussion that I'm aware of. Nat seemed in = favor of it (the +1 below). Mike was dismissive of it at the Dallas = meeting but didn't provide any reasoning (that I understood anyway). >> =20 >> =20 >> On Mon, Mar 23, 2015 at 10:18 AM, Nat Sakimura > wrote: >> +1 >>=20 >> =3Dnat via iPhone >>=20 >> 2015/03/23 11:07=E3=80=81Brian Campbell > =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3= =83=BC=E3=82=B8: >>=20 >> This is mostly about section 3.4 = but also the whole draft. >>=20 >> If "cnf" is intended to analogous to the SAML 2.0 SubjectConfirmation = element, it should probably contain an array value rather than an object = value. SAML allows not just for multiple methods of confirming but for = multiple instances of the same method. IIRC, only one confirmation needs = to be confirmable. >>=20 >> I'm not sure the extra complexity is worth it though. I've rarely, if = ever, seen SAML assertions that make use of it. >>=20 >> If the intent is just to allow for different kinds of confirmation, = couldn't the structure be pared down and simplified and just have = individual claims for the different confirmation types? Like "cjwk" and = "ckid" or similar that have the jwk or kid value respectively as the = member value. =20 >>=20 >>=20 >> =20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >> =20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 --Apple-Mail=_9D88804F-7EC7-4BC8-8C6F-37BB987D994C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 In my example you don=E2=80=99t really want to treat both the = presenters as equivalent.  Endpoints receiving the token should be = able to tell which presenter gave it to them and apply policy on = that.

If you wanted = them to be equivalent then an array would work, but that probably adds = more confusion.

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


= --Apple-Mail=_9D88804F-7EC7-4BC8-8C6F-37BB987D994C-- From nobody Thu Jul 30 18:36:33 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A041A00EA for ; Thu, 30 Jul 2015 18:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id podPS56fmJOJ for ; Thu, 30 Jul 2015 18:36:28 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30FC11A00D4 for ; Thu, 30 Jul 2015 18:36:28 -0700 (PDT) Received: by obnw1 with SMTP id w1so43708967obn.3 for ; Thu, 30 Jul 2015 18:36:27 -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 :content-type; bh=sp0doTSdmSDSQSNXnnaUDkvVDJ6DDmvySwqljAc3Rkk=; b=L+yZrWzr8aFxV8tn0eqctYxPobjF1UD/rEq4eic0gp0YPXwJO/uzfpszSvfyXkYcwQ apYOakQFQafpRo/KF6o8SRaXZ9I9HFaA0iu+CTbsf1eaMd2CwaC/j65AJGDV/q/FEnlr dzPQV6xubkIqMusEZInyRbDWXuYwzWFe5T9rk3Pdl0AMvAdVqT7y+Vznr4SN+LIjoN54 ZzkMmhVSppS0bTik5fMQCUd1eJgThZ9RqfSZxD8x4ujv0dy4sNe3Q4hqKGOBA9HTvx5z fulyk9HTeZQgOdy6h6VGSgixl47n+2aI6QPFQ0BMBtx0kh9QjJoAIrKnmfB9MFqxZjze oXrg== MIME-Version: 1.0 X-Received: by 10.182.215.226 with SMTP id ol2mr259992obc.56.1438306587650; Thu, 30 Jul 2015 18:36:27 -0700 (PDT) Received: by 10.182.96.66 with HTTP; Thu, 30 Jul 2015 18:36:27 -0700 (PDT) In-Reply-To: References: Date: Fri, 31 Jul 2015 10:36:27 +0900 Message-ID: From: Nat Sakimura To: oauth Content-Type: multipart/alternative; boundary=001a11c2b06e3c338b051c21d9a6 Archived-At: Subject: Re: [OAUTH-WG] Review Comments for draft-ietf-oauth-proof-of-possession-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 01:36:32 -0000 --001a11c2b06e3c338b051c21d9a6 Content-Type: text/plain; charset=UTF-8 I cannot find any disposition of comment (DoC) to this review that the WG Chairs asked. Nor I see much of them reflected in -03. The process I would imagine to be the editors to 1) Provide the DoC [accept, discuss, reject (with reasons)], 2) Open up series of discussions on discuss items and drive towards the (rough) consensus. Since the diff between -02 and -03 is small, much of the above comments still applies. Looking forward to see the DoC. Nat 2015-03-25 22:37 GMT+09:00 Nat Sakimura : > Dear OAuthers: > > Here is my belated review comments on > draft-ietf-oauth-proof-of-possession-02 > > Below, [POPA] stands for > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01 > > Abstract > ============ > It is probably better to spell out that this document is describing the > JWT format that can be used for sender constraint (5.2 of [POPA]) and key > confirmation (5.3 of [POPA]). This will make it easier for the reader to > understand what this document aims at. > > Accordingly, we should consider the title change to something like: > JWT Sender Confirmation Token Syntax > OR > borrowing from the financial concept which I believe is the origin of the > concept of "bearer token", > JWT Registered Token Syntax > -- here, "Registered" mean that either the sender constraint or key > confirmation is registered within or in conjunction with the token. > > 1. Introduction > ============== > Consider referencing draft-ietf-oauth-pop-architecture. > It will be clearer for the reader then, and the text will be shorter. > > 2. Terminology - Presenter > ======================== > Sentence 1 > ------------------- > Not sure if the first sentence is accurately reflecting the intent. > It excludes rogue party presenting the token (and fails) from presenter. > If so, it is fine but using more qualified term like "authorized > presenter" may make it easier > for the reader to parse. > > Otherwise revise the definition. > > Sentence 2 > ------------------- > "issuer or a party different from the issuer" is not constraining anything > and meaningless. > There are more easier to parse and accurate text coming in the main text, > too. > Drop. > > 3. Proof-Of-Posession Representation > ============================== > Title > --------- > Perhaps "Sender Representation in JWT" is more reflective of the content. > > Para 2 > ------------- > The paragraph describes two ways of sender confirmation: > (1) Sender Constraint > (2) Key Confirmation > It should refer to 5.2 and 5.3 of [POPA] for it, as well as align the > terminology. > > Then, it goes on to describe (1) very briefly, in which it is just > spelling out "iss" and "sub". > > I understand the use of sub in this section comes down from SAML but I > feel that some separation between sub and presenter would be nice. > > For example, when I am presenting the token using an app that I installed > on my iPhone, the presenter is that app and not me, while the sub still may > be me. The app is the authorized presenter/party (azp) of the token. The > JWT may well be about the sub but presented by some software component that > should be independently identified. > > So my proposal is to create a new subsection on (1) for the completeness, > which is going to be a new 3.1, and to use a claim like "azp" instead of > "sub" to identify the presenter. Less overload would cause less confusion > later, IMHO. > > 3.1 > ====== > Title > -------- > Perhaps "Confirmation Key Representation for an Asymmetric Key" is more > reflective of the content. > > 3.2 > ======== > Title > ----------- > Perhaps "Confirmation Key Representation for a Symmetric Key" is more > reflective of the content. > > Last Para > ----------------- > I feel a bit like needing to sniff into the content of jwk to find out > what type may not be optimal, though I do not have a concrete proposal a > this time. > > 3.3 > ====== > Title > --------- > Perhaps "Confirmation Key Representation by Key ID" is more reflective of > the content. > > Para 1 > ----------- > There has been some discussion of using thumbprint instead of a blob > "kid". > This is a valid option. If we are to overload the "kid" member for this > purpose, we need to find a way to signal that it is a thumbprint. > It may very well be better to define a separate member name then for the > thumbprint. The title then changes to "-- by Key ID" to "-- by reference". > > Also, it is conceivable to use the combination of "kid" and "jku". This > aspect is not spelled out here but appears that some magic happens for the > key distribution. > > 3.4 > ======== > Since "cnf" appears before 3.4, it may be better to bring 3.4 at the > front. > > 5.2.2 > ========= > Add "azp" and "jkt". > > o Confirmation Method Value: "azp" > o Confirmation Method Description: Client ID of the Authorized Presenter > o Change Controller: IESG > o Specification Document(s): Section [TBD] of [[ this document ]] > > > o Confirmation Method Value: "jkt" > o Confirmation Method Description: JWK Thumbprint of the Confirmation Key > o Change Controller: IESG > o Specification Document(s): Section [TBD] of [[ this document ]] > > > o Confirmation Method Value: "jku" > o Confirmation Method Description: JWK URI of the Confirmation Key > o Change Controller: IESG > o Specification Document(s): Section [TBD] of [[ this document ]] > > Privacy Consideration > ======================== > It is missing privacy consideration. It is not required per se, but since > Key Confirmation method with ephemeral key can be less privacy intrusive > compared to other sender confirmation method so adding some text around it > may be a good idea. > > Best, > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c2b06e3c338b051c21d9a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I cannot find any disposition of comment (DoC) to this rev= iew that the WG Chairs asked.=C2=A0
Nor I see much of them reflected in= -03.=C2=A0

The process I would imagine to be the = editors to=C2=A0

1) Provide the DoC [accept, discu= ss, reject (with reasons)],=C2=A0
2) Open up series of discussion= s on discuss items and drive towards the (rough) consensus.=C2=A0

Since the diff between -02 and -03 is small, much of the ab= ove comments still applies.=C2=A0

Looking forward = to see the DoC.=C2=A0

Nat

2015-03-25 22:37 GMT+09:00 Nat= Sakimura <sakimura@gmail.com>:
Dear OAuthers:=C2=A0

Here = is my belated review comments on=C2=A0draft-ietf-oauth-proof-of-possession-02
<= br>

Abstract
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
It is = probably better to spell out that this document is describing the JWT forma= t that can be used for sender constraint (5.2 of [POPA]) and key confirmati= on (5.3 of [POPA]). This will make it easier for the reader to understand w= hat this document aims at.=C2=A0

Accordingly, we s= hould consider the title change to something like:=C2=A0
JWT Sender Confirmation Token Syntax=C2=A0
=C2=A0 OR
b= orrowing from the financial concept which I believe is the origin of the co= ncept of "bearer token",=C2=A0
JWT Registered Token Syn= tax
-- here, "Registered" mean that either the sender c= onstraint or key confirmation is registered within or in conjunction with t= he token.=C2=A0

1. Introduction
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Consider referencing draft-i= etf-oauth-pop-architecture.=C2=A0
It will be clearer for the read= er then, and the text will be shorter.=C2=A0

2. Te= rminology - Presenter
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Sentence 1
-------------= ------
Not sure if the first sentence is accurately reflecting th= e intent.=C2=A0
It excludes rogue party presenting the token (and= fails) from presenter.=C2=A0
If so, it is fine but using more qu= alified term like "authorized presenter" may make it easier=C2=A0=
for the reader to parse.=C2=A0

Otherwis= e revise the definition.=C2=A0

Sentence 2
-------------------
"issuer or a party different from the = issuer" is not constraining anything and meaningless.=C2=A0
= There are more easier to parse and accurate text coming in the main text, t= oo.=C2=A0
Drop.=C2=A0

3. Proof-Of-Posess= ion Representation
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Title
---= ------
Perhaps "Sender Representation in JWT" is more r= eflective of the content.=C2=A0

Para 2
-------------
The paragraph describes two ways of sender confi= rmation:=C2=A0
(1) Sender Constraint
(2) Key Confirmati= on
It should refer to 5.2 and 5.3 of [POPA] for it, as well as al= ign the terminology.=C2=A0

Then, it goes on to des= cribe (1) very briefly, in which it is just spelling out "iss" an= d "sub".=C2=A0

I understand the use of sub in= this section comes down from SAML but I feel that some separation between = sub and presenter would be nice.

For example, when I am presenting = the token using an app that I installed on my iPhone, the presenter is that= app and not me, while the sub still may be me. The app is the authorized p= resenter/party (azp) of the token.=C2=A0The JWT may well be about the sub b= ut presented by some software component that should be independently identi= fied. =C2=A0

So my proposal is to create a new subsection on (1) fo= r the completeness, which is going to be a new 3.1, and to use a claim like= "azp" instead of "sub" to identify the presenter. Less= overload would cause less confusion later, IMHO.

= 3.1
=3D=3D=3D=3D=3D=3D
Title
--------
Perhaps "Confirmation Key Representation for an Asymmetric Key"= ; is more reflective of the content.=C2=A0

3.2
=3D=3D=3D=3D=3D=3D=3D=3D
Title
-----------
=
Perhaps "Confirmation Key Representation for a Symmetric Key"= ; is more reflective of the content.=C2=A0

Las= t Para
-----------------
I feel a bit like needing to s= niff into the content of jwk to find out what type may not be optimal, thou= gh I do not have a concrete proposal a this time.=C2=A0

3.3
=3D=3D=3D=3D=3D=3D
Title
---------<= /div>
Perhaps "Confirmation Key Representation by Key ID" is = more reflective of the content.=C2=A0

Para 1
-----------
There has been some discussion of using thum= bprint instead of a blob "kid".=C2=A0
This is a valid o= ption. If we are to overload the "kid" member for this purpose, w= e need to find a way to signal that it is a thumbprint.=C2=A0
It = may very well be better to define a separate member name then for the thumb= print. The title then changes to "-- by Key ID" to "-- by re= ference".=C2=A0

Also, it is conceivable to us= e the combination of "kid" and "jku". This aspect is no= t spelled out here but appears that some magic happens for the key distribu= tion.=C2=A0

3.4=C2=A0
=3D=3D=3D=3D= =3D=3D=3D=3D
Since "cnf" appears before 3.4, it may be = better to bring 3.4 at the front.=C2=A0

5.2.= 2
=3D=3D=3D=3D=3D=3D=3D=3D=3D
Add "azp" and &= quot;jkt".=C2=A0

o =C2=A0Confirmation Method Value= : "azp"
o =C2=A0Confirmation Method Description: Client ID of = the Authorized Presenter
o =C2=A0Change Controller: IESG
o =C2=A0Spec= ification Document(s): Section [TBD] of [[ this document ]]


o = =C2=A0Confirmation Method Value: "jkt"
o =C2=A0Confirmation Me= thod Description: JWK Thumbprint of the Confirmation Key
o =C2=A0Change = Controller: IESG
o =C2=A0Specification Document(s): Section [TBD] of [[ = this document ]]


o =C2=A0Confirmation Method Value: "jku&qu= ot;
o =C2=A0Confirmation Method Description: JWK URI of the Confirmation= Key
o =C2=A0Change Controller: IESG
o =C2=A0Specification Document(s= ): Section [TBD] of [[ this document ]]

Privacy Consider= ation
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
It is missing privacy consideration. It is not re= quired per se, but since Key Confirmation method with ephemeral key can be = less privacy intrusive compared to other sender confirmation method so addi= ng some text around it may be a good idea.=C2=A0

<= div>Best,=C2=A0
--
=
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@= _nat_en



--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation<= br>http://nat.sakimu= ra.org/
@_nat_en
--001a11c2b06e3c338b051c21d9a6-- From nobody Thu Jul 30 19:49:25 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6F41B3005 for ; Thu, 30 Jul 2015 19:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.088 X-Spam-Level: X-Spam-Status: No, score=0.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4V6wczl_pDe for ; Thu, 30 Jul 2015 19:49:20 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0108.outbound.protection.outlook.com [65.55.169.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE4A21B2FFB for ; Thu, 30 Jul 2015 19:49:19 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.231.11; Fri, 31 Jul 2015 02:49:17 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0231.011; Fri, 31 Jul 2015 02:49:17 +0000 From: Mike Jones To: Nat Sakimura , oauth Thread-Topic: [OAUTH-WG] Review Comments for draft-ietf-oauth-proof-of-possession-02 Thread-Index: AQHQZwDsLoYVszt6jEeQRXex8srb+J31lKCAgAASmAA= Date: Fri, 31 Jul 2015 02:49:17 +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: gmail.com; dkim=none (message not signed) header.d=none; x-originating-ip: [50.47.90.173] x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:5mxBvI9h6JCcXdNGnrt5MvgLo5ki70tc10Rx+Ncr+KCRDKGFqVpKf3QBi6VQolLyozHOZjIGlCH3ZtKx8UahivhbJEsMdSLbGMgS6FcOL9xKo8nYYp8CjdRP7WxNnf74NxbFNsNv1u1X1rj5k7YeAg==; 24:nTR+mOA6wT6r0kYrlKAHVK4eEOAiyKJBxEfpiE3wsm44SWkMcKFZBivlIVwRPRYEgOnMOE5eJNDF2EqwPwkWrFgaU0Z5LFtkK8VrrwFgGRs=; 20:ziYazjEdq26Futi9qZCPQKrlaeTgp98arvrNvF4Ee3XPqlNVQNULayVbQrcyR2nQkNFhkEA7R+HDlnewhNRyPQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; x-forefront-prvs: 0654257CF5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(377424004)(69234005)(50944005)(19609705001)(76176999)(92566002)(2656002)(74316001)(122556002)(40100003)(66066001)(86362001)(107886002)(46102003)(19580405001)(230783001)(19625215002)(19617315012)(19580395003)(77156002)(19300405004)(561944003)(87936001)(2950100001)(76576001)(15975445007)(106116001)(54356999)(99286002)(102836002)(5002640100001)(5003600100002)(33656002)(5001770100001)(77096005)(50986999)(5001960100002)(189998001)(16236675004)(62966003)(2900100001)(10090500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB44280E7A1B2AA29EE5DD3EDF58A0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2015 02:49:17.8089 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444 Archived-At: Subject: Re: [OAUTH-WG] Review Comments for draft-ietf-oauth-proof-of-possession-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 02:49:24 -0000 --_000_BY2PR03MB44280E7A1B2AA29EE5DD3EDF58A0BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0eXBpY2FsbHkgZG8gcmVzcG9uZCB0byByZXZpZXcgY29tbWVudHMgbGluZS1ieS1saW5lIGJ1 dCByYW4gb3V0IG9mIHRpbWUgdG8gZG8gdGhpcyBiZWZvcmUgUHJhZ3VlLiAgKEkgd2FzIGRvaW5n IHRoaW5ncyBsaWtlIHdvcmtpbmcgd2l0aCBCcmlhbiBvbiB0aGUgVG9rZW4gRXhjaGFuZ2UgZGVj aywgcHJlcGFyaW5nIG15IHJlbWFya3MgdG8gdGhlIENPU0UgV0csIGV0Yy4pICBJ4oCZbGwgcGxh biB0byBkbyB0aGlzIHNvbWV0aW1lIGVhcmx5IG5leHQgd2Vlaywgd2hpY2ggaXMgdGhlIHNvb25l c3QgSeKAmWxsIGJlIGFibGUgdG8gZ2V0IHRvIGl0LCBnaXZlbiBvdGhlciB0aGluZ3MgY3VycmVu dGx5IG9uIG15IHBsYXRlLg0KDQpGWUksIEkgZGlkIHJlYWQgdGhyb3VnaCBhbGwgb2YgeW91ciBh bmQgb3RoZXLigJlzIGNvbW1lbnRzIGFuZCBhcHBsaWVkIG1vc3Qgb2YgdGhlbSDigJMgZm9yIGlu c3RhbmNlLCBvZmYgdGhlIHRvcCBvZiBteSBoZWFkLCBjbGFyaWZ5aW5nIGhvdyDigJxhenDigJ0g Y291bGQgYmUgdXNlZCBpbiBpZGVudGlmeWluZyB0aGUgcHJlc2VudGVyLCBlbGltaW5hdGluZyB0 aGUgbmVlZCB0byBzbmlmZiB0aGUg4oCcandr4oCdIHZhbHVlLCBhbmQgdXBkYXRpbmcgdGhlIHRp dGxlIHRvIGJlIG1vcmUgZXZvY2F0aXZlIG9mIHdoYXQgdGhlIHNwZWNpZmljYXRpb24gYWN0dWFs bHkgYWNoaWV2ZXMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIENoZWVycywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogT0F1dGggW21h aWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTmF0IFNha2ltdXJhDQpT ZW50OiBUaHVyc2RheSwgSnVseSAzMCwgMjAxNSA2OjM2IFBNDQpUbzogb2F1dGgNClN1YmplY3Q6 IFJlOiBbT0FVVEgtV0ddIFJldmlldyBDb21tZW50cyBmb3IgZHJhZnQtaWV0Zi1vYXV0aC1wcm9v Zi1vZi1wb3NzZXNzaW9uLTAyDQoNCkkgY2Fubm90IGZpbmQgYW55IGRpc3Bvc2l0aW9uIG9mIGNv bW1lbnQgKERvQykgdG8gdGhpcyByZXZpZXcgdGhhdCB0aGUgV0cgQ2hhaXJzIGFza2VkLg0KTm9y IEkgc2VlIG11Y2ggb2YgdGhlbSByZWZsZWN0ZWQgaW4gLTAzLg0KDQpUaGUgcHJvY2VzcyBJIHdv dWxkIGltYWdpbmUgdG8gYmUgdGhlIGVkaXRvcnMgdG8NCg0KMSkgUHJvdmlkZSB0aGUgRG9DIFth Y2NlcHQsIGRpc2N1c3MsIHJlamVjdCAod2l0aCByZWFzb25zKV0sDQoyKSBPcGVuIHVwIHNlcmll cyBvZiBkaXNjdXNzaW9ucyBvbiBkaXNjdXNzIGl0ZW1zIGFuZCBkcml2ZSB0b3dhcmRzIHRoZSAo cm91Z2gpIGNvbnNlbnN1cy4NCg0KU2luY2UgdGhlIGRpZmYgYmV0d2VlbiAtMDIgYW5kIC0wMyBp cyBzbWFsbCwgbXVjaCBvZiB0aGUgYWJvdmUgY29tbWVudHMgc3RpbGwgYXBwbGllcy4NCg0KTG9v a2luZyBmb3J3YXJkIHRvIHNlZSB0aGUgRG9DLg0KDQpOYXQNCg0KMjAxNS0wMy0yNSAyMjozNyBH TVQrMDk6MDAgTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb208bWFpbHRvOnNha2ltdXJh QGdtYWlsLmNvbT4+Og0KRGVhciBPQXV0aGVyczoNCg0KSGVyZSBpcyBteSBiZWxhdGVkIHJldmll dyBjb21tZW50cyBvbiBkcmFmdC1pZXRmLW9hdXRoLXByb29mLW9mLXBvc3Nlc3Npb24tMDINCg0K QmVsb3csIFtQT1BBXSBzdGFuZHMgZm9yIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW9hdXRoLXBvcC1hcmNoaXRlY3R1cmUtMDE8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ0b29scy5pZXRmLm9yZyUy Zmh0bWwlMmZkcmFmdC1pZXRmLW9hdXRoLXBvcC1hcmNoaXRlY3R1cmUtMDEmZGF0YT0wMSU3YzAx JTdjTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN2M4ZTNhMWM4MDgwMDA0NGFmZWE2NDA4 ZDI5OTQ4NzkxNCU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1h QWxVZlZyUHVTNmdacEZkVzg5cEhDdzJEV3JSY2Z0YWdsdVBkZ0YzWHpRJTNkPg0KDQpBYnN0cmFj dA0KPT09PT09PT09PT09DQpJdCBpcyBwcm9iYWJseSBiZXR0ZXIgdG8gc3BlbGwgb3V0IHRoYXQg dGhpcyBkb2N1bWVudCBpcyBkZXNjcmliaW5nIHRoZSBKV1QgZm9ybWF0IHRoYXQgY2FuIGJlIHVz ZWQgZm9yIHNlbmRlciBjb25zdHJhaW50ICg1LjIgb2YgW1BPUEFdKSBhbmQga2V5IGNvbmZpcm1h dGlvbiAoNS4zIG9mIFtQT1BBXSkuIFRoaXMgd2lsbCBtYWtlIGl0IGVhc2llciBmb3IgdGhlIHJl YWRlciB0byB1bmRlcnN0YW5kIHdoYXQgdGhpcyBkb2N1bWVudCBhaW1zIGF0Lg0KDQpBY2NvcmRp bmdseSwgd2Ugc2hvdWxkIGNvbnNpZGVyIHRoZSB0aXRsZSBjaGFuZ2UgdG8gc29tZXRoaW5nIGxp a2U6DQpKV1QgU2VuZGVyIENvbmZpcm1hdGlvbiBUb2tlbiBTeW50YXgNCiAgT1INCmJvcnJvd2lu ZyBmcm9tIHRoZSBmaW5hbmNpYWwgY29uY2VwdCB3aGljaCBJIGJlbGlldmUgaXMgdGhlIG9yaWdp biBvZiB0aGUgY29uY2VwdCBvZiAiYmVhcmVyIHRva2VuIiwNCkpXVCBSZWdpc3RlcmVkIFRva2Vu IFN5bnRheA0KLS0gaGVyZSwgIlJlZ2lzdGVyZWQiIG1lYW4gdGhhdCBlaXRoZXIgdGhlIHNlbmRl ciBjb25zdHJhaW50IG9yIGtleSBjb25maXJtYXRpb24gaXMgcmVnaXN0ZXJlZCB3aXRoaW4gb3Ig aW4gY29uanVuY3Rpb24gd2l0aCB0aGUgdG9rZW4uDQoNCjEuIEludHJvZHVjdGlvbg0KPT09PT09 PT09PT09PT0NCkNvbnNpZGVyIHJlZmVyZW5jaW5nIGRyYWZ0LWlldGYtb2F1dGgtcG9wLWFyY2hp dGVjdHVyZS4NCkl0IHdpbGwgYmUgY2xlYXJlciBmb3IgdGhlIHJlYWRlciB0aGVuLCBhbmQgdGhl IHRleHQgd2lsbCBiZSBzaG9ydGVyLg0KDQoyLiBUZXJtaW5vbG9neSAtIFByZXNlbnRlcg0KPT09 PT09PT09PT09PT09PT09PT09PT09DQpTZW50ZW5jZSAxDQotLS0tLS0tLS0tLS0tLS0tLS0tDQpO b3Qgc3VyZSBpZiB0aGUgZmlyc3Qgc2VudGVuY2UgaXMgYWNjdXJhdGVseSByZWZsZWN0aW5nIHRo ZSBpbnRlbnQuDQpJdCBleGNsdWRlcyByb2d1ZSBwYXJ0eSBwcmVzZW50aW5nIHRoZSB0b2tlbiAo YW5kIGZhaWxzKSBmcm9tIHByZXNlbnRlci4NCklmIHNvLCBpdCBpcyBmaW5lIGJ1dCB1c2luZyBt b3JlIHF1YWxpZmllZCB0ZXJtIGxpa2UgImF1dGhvcml6ZWQgcHJlc2VudGVyIiBtYXkgbWFrZSBp dCBlYXNpZXINCmZvciB0aGUgcmVhZGVyIHRvIHBhcnNlLg0KDQpPdGhlcndpc2UgcmV2aXNlIHRo ZSBkZWZpbml0aW9uLg0KDQpTZW50ZW5jZSAyDQotLS0tLS0tLS0tLS0tLS0tLS0tDQoiaXNzdWVy IG9yIGEgcGFydHkgZGlmZmVyZW50IGZyb20gdGhlIGlzc3VlciIgaXMgbm90IGNvbnN0cmFpbmlu ZyBhbnl0aGluZyBhbmQgbWVhbmluZ2xlc3MuDQpUaGVyZSBhcmUgbW9yZSBlYXNpZXIgdG8gcGFy c2UgYW5kIGFjY3VyYXRlIHRleHQgY29taW5nIGluIHRoZSBtYWluIHRleHQsIHRvby4NCkRyb3Au DQoNCjMuIFByb29mLU9mLVBvc2Vzc2lvbiBSZXByZXNlbnRhdGlvbg0KPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09DQpUaXRsZQ0KLS0tLS0tLS0tDQpQZXJoYXBzICJTZW5kZXIgUmVwcmVz ZW50YXRpb24gaW4gSldUIiBpcyBtb3JlIHJlZmxlY3RpdmUgb2YgdGhlIGNvbnRlbnQuDQoNClBh cmEgMg0KLS0tLS0tLS0tLS0tLQ0KVGhlIHBhcmFncmFwaCBkZXNjcmliZXMgdHdvIHdheXMgb2Yg c2VuZGVyIGNvbmZpcm1hdGlvbjoNCigxKSBTZW5kZXIgQ29uc3RyYWludA0KKDIpIEtleSBDb25m aXJtYXRpb24NCkl0IHNob3VsZCByZWZlciB0byA1LjIgYW5kIDUuMyBvZiBbUE9QQV0gZm9yIGl0 LCBhcyB3ZWxsIGFzIGFsaWduIHRoZSB0ZXJtaW5vbG9neS4NCg0KVGhlbiwgaXQgZ29lcyBvbiB0 byBkZXNjcmliZSAoMSkgdmVyeSBicmllZmx5LCBpbiB3aGljaCBpdCBpcyBqdXN0IHNwZWxsaW5n IG91dCAiaXNzIiBhbmQgInN1YiIuDQoNCkkgdW5kZXJzdGFuZCB0aGUgdXNlIG9mIHN1YiBpbiB0 aGlzIHNlY3Rpb24gY29tZXMgZG93biBmcm9tIFNBTUwgYnV0IEkgZmVlbCB0aGF0IHNvbWUgc2Vw YXJhdGlvbiBiZXR3ZWVuIHN1YiBhbmQgcHJlc2VudGVyIHdvdWxkIGJlIG5pY2UuDQoNCkZvciBl eGFtcGxlLCB3aGVuIEkgYW0gcHJlc2VudGluZyB0aGUgdG9rZW4gdXNpbmcgYW4gYXBwIHRoYXQg SSBpbnN0YWxsZWQgb24gbXkgaVBob25lLCB0aGUgcHJlc2VudGVyIGlzIHRoYXQgYXBwIGFuZCBu b3QgbWUsIHdoaWxlIHRoZSBzdWIgc3RpbGwgbWF5IGJlIG1lLiBUaGUgYXBwIGlzIHRoZSBhdXRo b3JpemVkIHByZXNlbnRlci9wYXJ0eSAoYXpwKSBvZiB0aGUgdG9rZW4uIFRoZSBKV1QgbWF5IHdl bGwgYmUgYWJvdXQgdGhlIHN1YiBidXQgcHJlc2VudGVkIGJ5IHNvbWUgc29mdHdhcmUgY29tcG9u ZW50IHRoYXQgc2hvdWxkIGJlIGluZGVwZW5kZW50bHkgaWRlbnRpZmllZC4NCg0KU28gbXkgcHJv cG9zYWwgaXMgdG8gY3JlYXRlIGEgbmV3IHN1YnNlY3Rpb24gb24gKDEpIGZvciB0aGUgY29tcGxl dGVuZXNzLCB3aGljaCBpcyBnb2luZyB0byBiZSBhIG5ldyAzLjEsIGFuZCB0byB1c2UgYSBjbGFp bSBsaWtlICJhenAiIGluc3RlYWQgb2YgInN1YiIgdG8gaWRlbnRpZnkgdGhlIHByZXNlbnRlci4g TGVzcyBvdmVybG9hZCB3b3VsZCBjYXVzZSBsZXNzIGNvbmZ1c2lvbiBsYXRlciwgSU1ITy4NCg0K My4xDQo9PT09PT0NClRpdGxlDQotLS0tLS0tLQ0KUGVyaGFwcyAiQ29uZmlybWF0aW9uIEtleSBS ZXByZXNlbnRhdGlvbiBmb3IgYW4gQXN5bW1ldHJpYyBLZXkiIGlzIG1vcmUgcmVmbGVjdGl2ZSBv ZiB0aGUgY29udGVudC4NCg0KMy4yDQo9PT09PT09PQ0KVGl0bGUNCi0tLS0tLS0tLS0tDQpQZXJo YXBzICJDb25maXJtYXRpb24gS2V5IFJlcHJlc2VudGF0aW9uIGZvciBhIFN5bW1ldHJpYyBLZXki IGlzIG1vcmUgcmVmbGVjdGl2ZSBvZiB0aGUgY29udGVudC4NCg0KTGFzdCBQYXJhDQotLS0tLS0t LS0tLS0tLS0tLQ0KSSBmZWVsIGEgYml0IGxpa2UgbmVlZGluZyB0byBzbmlmZiBpbnRvIHRoZSBj b250ZW50IG9mIGp3ayB0byBmaW5kIG91dCB3aGF0IHR5cGUgbWF5IG5vdCBiZSBvcHRpbWFsLCB0 aG91Z2ggSSBkbyBub3QgaGF2ZSBhIGNvbmNyZXRlIHByb3Bvc2FsIGEgdGhpcyB0aW1lLg0KDQoz LjMNCj09PT09PQ0KVGl0bGUNCi0tLS0tLS0tLQ0KUGVyaGFwcyAiQ29uZmlybWF0aW9uIEtleSBS ZXByZXNlbnRhdGlvbiBieSBLZXkgSUQiIGlzIG1vcmUgcmVmbGVjdGl2ZSBvZiB0aGUgY29udGVu dC4NCg0KUGFyYSAxDQotLS0tLS0tLS0tLQ0KVGhlcmUgaGFzIGJlZW4gc29tZSBkaXNjdXNzaW9u IG9mIHVzaW5nIHRodW1icHJpbnQgaW5zdGVhZCBvZiBhIGJsb2IgImtpZCIuDQpUaGlzIGlzIGEg dmFsaWQgb3B0aW9uLiBJZiB3ZSBhcmUgdG8gb3ZlcmxvYWQgdGhlICJraWQiIG1lbWJlciBmb3Ig dGhpcyBwdXJwb3NlLCB3ZSBuZWVkIHRvIGZpbmQgYSB3YXkgdG8gc2lnbmFsIHRoYXQgaXQgaXMg YSB0aHVtYnByaW50Lg0KSXQgbWF5IHZlcnkgd2VsbCBiZSBiZXR0ZXIgdG8gZGVmaW5lIGEgc2Vw YXJhdGUgbWVtYmVyIG5hbWUgdGhlbiBmb3IgdGhlIHRodW1icHJpbnQuIFRoZSB0aXRsZSB0aGVu IGNoYW5nZXMgdG8gIi0tIGJ5IEtleSBJRCIgdG8gIi0tIGJ5IHJlZmVyZW5jZSIuDQoNCkFsc28s IGl0IGlzIGNvbmNlaXZhYmxlIHRvIHVzZSB0aGUgY29tYmluYXRpb24gb2YgImtpZCIgYW5kICJq a3UiLiBUaGlzIGFzcGVjdCBpcyBub3Qgc3BlbGxlZCBvdXQgaGVyZSBidXQgYXBwZWFycyB0aGF0 IHNvbWUgbWFnaWMgaGFwcGVucyBmb3IgdGhlIGtleSBkaXN0cmlidXRpb24uDQoNCjMuNA0KPT09 PT09PT0NClNpbmNlICJjbmYiIGFwcGVhcnMgYmVmb3JlIDMuNCwgaXQgbWF5IGJlIGJldHRlciB0 byBicmluZyAzLjQgYXQgdGhlIGZyb250Lg0KDQo1LjIuMg0KPT09PT09PT09DQpBZGQgImF6cCIg YW5kICJqa3QiLg0KDQpvICBDb25maXJtYXRpb24gTWV0aG9kIFZhbHVlOiAiYXpwIg0KbyAgQ29u ZmlybWF0aW9uIE1ldGhvZCBEZXNjcmlwdGlvbjogQ2xpZW50IElEIG9mIHRoZSBBdXRob3JpemVk IFByZXNlbnRlcg0KbyAgQ2hhbmdlIENvbnRyb2xsZXI6IElFU0cNCm8gIFNwZWNpZmljYXRpb24g RG9jdW1lbnQocyk6IFNlY3Rpb24gW1RCRF0gb2YgW1sgdGhpcyBkb2N1bWVudCBdXQ0KDQoNCm8g IENvbmZpcm1hdGlvbiBNZXRob2QgVmFsdWU6ICJqa3QiDQpvICBDb25maXJtYXRpb24gTWV0aG9k IERlc2NyaXB0aW9uOiBKV0sgVGh1bWJwcmludCBvZiB0aGUgQ29uZmlybWF0aW9uIEtleQ0KbyAg Q2hhbmdlIENvbnRyb2xsZXI6IElFU0cNCm8gIFNwZWNpZmljYXRpb24gRG9jdW1lbnQocyk6IFNl Y3Rpb24gW1RCRF0gb2YgW1sgdGhpcyBkb2N1bWVudCBdXQ0KDQoNCm8gIENvbmZpcm1hdGlvbiBN ZXRob2QgVmFsdWU6ICJqa3UiDQpvICBDb25maXJtYXRpb24gTWV0aG9kIERlc2NyaXB0aW9uOiBK V0sgVVJJIG9mIHRoZSBDb25maXJtYXRpb24gS2V5DQpvICBDaGFuZ2UgQ29udHJvbGxlcjogSUVT Rw0KbyAgU3BlY2lmaWNhdGlvbiBEb2N1bWVudChzKTogU2VjdGlvbiBbVEJEXSBvZiBbWyB0aGlz IGRvY3VtZW50IF1dDQoNClByaXZhY3kgQ29uc2lkZXJhdGlvbg0KPT09PT09PT09PT09PT09PT09 PT09PT09DQpJdCBpcyBtaXNzaW5nIHByaXZhY3kgY29uc2lkZXJhdGlvbi4gSXQgaXMgbm90IHJl cXVpcmVkIHBlciBzZSwgYnV0IHNpbmNlIEtleSBDb25maXJtYXRpb24gbWV0aG9kIHdpdGggZXBo ZW1lcmFsIGtleSBjYW4gYmUgbGVzcyBwcml2YWN5IGludHJ1c2l2ZSBjb21wYXJlZCB0byBvdGhl ciBzZW5kZXIgY29uZmlybWF0aW9uIG1ldGhvZCBzbyBhZGRpbmcgc29tZSB0ZXh0IGFyb3VuZCBp dCBtYXkgYmUgYSBnb29kIGlkZWEuDQoNCkJlc3QsDQotLQ0KTmF0IFNha2ltdXJhICg9bmF0KQ0K Q2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQpodHRwOi8vbmF0LnNha2ltdXJhLm9yZy88aHR0 cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUy ZiUyZm5hdC5zYWtpbXVyYS5vcmclMmYmZGF0YT0wMSU3YzAxJTdjTWljaGFlbC5Kb25lcyU0MG1p Y3Jvc29mdC5jb20lN2M4ZTNhMWM4MDgwMDA0NGFmZWE2NDA4ZDI5OTQ4NzkxNCU3YzcyZjk4OGJm ODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1Ba0U5OTRKTXRjVjlTR0szeWFaOWJl Q3A0cjRSSU1uOUZzJTJiWlU5RVNkZU0lM2Q+DQpAX25hdF9lbg0KDQoNCg0KLS0NCk5hdCBTYWtp bXVyYSAoPW5hdCkNCkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbg0KaHR0cDovL25hdC5zYWtp bXVyYS5vcmcvPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHAlM2ElMmYlMmZuYXQuc2FraW11cmEub3JnJTJmJmRhdGE9MDElN2MwMSU3Y01pY2hh ZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdjOGUzYTFjODA4MDAwNDRhZmVhNjQwOGQyOTk0ODc5 MTQlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9QWtFOTk0Sk10 Y1Y5U0dLM3lhWjliZUNwNHI0UklNbjlGcyUyYlpVOUVTZGVNJTNkPg0KQF9uYXRfZW4NCg== --_000_BY2PR03MB44280E7A1B2AA29EE5DD3EDF58A0BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiLDvzJkw78zMyAgw78zMDBiNDBiNzBjMzBhZiI7DQoJ cGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkkgdHlwaWNhbGx5IGRvIHJlc3BvbmQgdG8gcmV2aWV3IGNvbW1lbnRzIGxpbmUtYnktbGluZSBi dXQgcmFuIG91dCBvZiB0aW1lIHRvIGRvIHRoaXMgYmVmb3JlIFByYWd1ZS4mbmJzcDsgKEkgd2Fz IGRvaW5nIHRoaW5ncyBsaWtlIHdvcmtpbmcgd2l0aCBCcmlhbiBvbiB0aGUgVG9rZW4NCiBFeGNo YW5nZSBkZWNrLCBwcmVwYXJpbmcgbXkgcmVtYXJrcyB0byB0aGUgQ09TRSBXRywgZXRjLikmbmJz cDsgSeKAmWxsIHBsYW4gdG8gZG8gdGhpcyBzb21ldGltZSBlYXJseSBuZXh0IHdlZWssIHdoaWNo IGlzIHRoZSBzb29uZXN0IEnigJlsbCBiZSBhYmxlIHRvIGdldCB0byBpdCwgZ2l2ZW4gb3RoZXIg dGhpbmdzIGN1cnJlbnRseSBvbiBteSBwbGF0ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZZSSwgSSBkaWQgcmVhZCB0 aHJvdWdoIGFsbCBvZiB5b3VyIGFuZCBvdGhlcuKAmXMgY29tbWVudHMgYW5kIGFwcGxpZWQgbW9z dCBvZiB0aGVtIOKAkyBmb3IgaW5zdGFuY2UsIG9mZiB0aGUgdG9wIG9mIG15IGhlYWQsIGNsYXJp ZnlpbmcgaG93IOKAnGF6cOKAnSBjb3VsZCBiZSB1c2VkDQogaW4gaWRlbnRpZnlpbmcgdGhlIHBy ZXNlbnRlciwgZWxpbWluYXRpbmcgdGhlIG5lZWQgdG8gc25pZmYgdGhlIOKAnGp3a+KAnSB2YWx1 ZSwgYW5kIHVwZGF0aW5nIHRoZSB0aXRsZSB0byBiZSBtb3JlIGV2b2NhdGl2ZSBvZiB3aGF0IHRo ZSBzcGVjaWZpY2F0aW9uIGFjdHVhbGx5IGFjaGlldmVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IENoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1p a2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9BdXRoIFttYWls dG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TmF0IFNha2lt dXJhPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdWx5IDMwLCAyMDE1IDY6MzYgUE08YnI+ DQo8Yj5Ubzo8L2I+IG9hdXRoPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFJl dmlldyBDb21tZW50cyBmb3IgZHJhZnQtaWV0Zi1vYXV0aC1wcm9vZi1vZi1wb3NzZXNzaW9uLTAy PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBjYW5ub3QgZmluZCBhbnkg ZGlzcG9zaXRpb24gb2YgY29tbWVudCAoRG9DKSB0byB0aGlzIHJldmlldyB0aGF0IHRoZSBXRyBD aGFpcnMgYXNrZWQuJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Tm9yIEkgc2VlIG11Y2ggb2YgdGhlbSByZWZsZWN0ZWQgaW4gLTAzLiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgcHJv Y2VzcyBJIHdvdWxkIGltYWdpbmUgdG8gYmUgdGhlIGVkaXRvcnMgdG8mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MSkgUHJvdmlkZSB0 aGUgRG9DIFthY2NlcHQsIGRpc2N1c3MsIHJlamVjdCAod2l0aCByZWFzb25zKV0sJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yKSBPcGVu IHVwIHNlcmllcyBvZiBkaXNjdXNzaW9ucyBvbiBkaXNjdXNzIGl0ZW1zIGFuZCBkcml2ZSB0b3dh cmRzIHRoZSAocm91Z2gpIGNvbnNlbnN1cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2luY2UgdGhlIGRpZmYgYmV0d2VlbiAtMDIg YW5kIC0wMyBpcyBzbWFsbCwgbXVjaCBvZiB0aGUgYWJvdmUgY29tbWVudHMgc3RpbGwgYXBwbGll cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+TG9va2luZyBmb3J3YXJkIHRvIHNlZSB0aGUgRG9DLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OYXQ8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MjAxNS0wMy0yNSAyMjoz NyBHTVQmIzQzOzA5OjAwIE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNha2ltdXJh QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNha2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7Ojxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWFyIE9B dXRoZXJzOiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkhlcmUgaXMgbXkgYmVsYXRlZCByZXZpZXcgY29tbWVudHMgb24mbmJzcDs8c3BhbiBsYW5n PSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O8O/MmTDvzMzICDDvzMwMGI0MGI3MGMzMGFm JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5kcmFmdC1pZXRmLW9hdXRoLXByb29mLW9mLXBvc3Nl c3Npb24tMDI8L3NwYW4+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZWxvdywgW1BPUEFdIHN0YW5kcyBmb3IgPGEgaHJlZj0i aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M2ElMmYlMmZ0b29scy5pZXRmLm9yZyUyZmh0bWwlMmZkcmFmdC1pZXRmLW9hdXRoLXBvcC1hcmNo aXRlY3R1cmUtMDEmYW1wO2RhdGE9MDElN2MwMSU3Y01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQu Y29tJTdjOGUzYTFjODA4MDAwNDRhZmVhNjQwOGQyOTk0ODc5MTQlN2M3MmY5ODhiZjg2ZjE0MWFm OTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPWFBbFVmVnJQdVM2Z1pwRmRXODlwSEN3MkRX clJjZnRhZ2x1UGRnRjNYelElM2QiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXBvcC1hcmNoaXRlY3R1cmUtMDE8L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFic3RyYWN0 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj49PT09 PT09PT09PT08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkl0IGlzIHByb2JhYmx5IGJldHRlciB0byBzcGVsbCBvdXQgdGhhdCB0aGlzIGRvY3VtZW50 IGlzIGRlc2NyaWJpbmcgdGhlIEpXVCBmb3JtYXQgdGhhdCBjYW4gYmUgdXNlZCBmb3Igc2VuZGVy IGNvbnN0cmFpbnQgKDUuMiBvZiBbUE9QQV0pIGFuZCBrZXkgY29uZmlybWF0aW9uICg1LjMgb2Yg W1BPUEFdKS4gVGhpcyB3aWxsIG1ha2UgaXQgZWFzaWVyIGZvciB0aGUgcmVhZGVyIHRvIHVuZGVy c3RhbmQgd2hhdCB0aGlzDQogZG9jdW1lbnQgYWltcyBhdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWNjb3JkaW5nbHksIHdlIHNo b3VsZCBjb25zaWRlciB0aGUgdGl0bGUgY2hhbmdlIHRvIHNvbWV0aGluZyBsaWtlOiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkpXVCBTZW5kZXIgQ29uZmlybWF0aW9uIFRva2VuIFN5bnRheCZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IE9SPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ib3Jyb3dpbmcgZnJv bSB0aGUgZmluYW5jaWFsIGNvbmNlcHQgd2hpY2ggSSBiZWxpZXZlIGlzIHRoZSBvcmlnaW4gb2Yg dGhlIGNvbmNlcHQgb2YgJnF1b3Q7YmVhcmVyIHRva2VuJnF1b3Q7LCZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SldUIFJlZ2lzdGVyZWQg VG9rZW4gU3ludGF4PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4tLSBoZXJlLCAmcXVvdDtSZWdpc3RlcmVkJnF1b3Q7IG1lYW4gdGhhdCBlaXRoZXIg dGhlIHNlbmRlciBjb25zdHJhaW50IG9yIGtleSBjb25maXJtYXRpb24gaXMgcmVnaXN0ZXJlZCB3 aXRoaW4gb3IgaW4gY29uanVuY3Rpb24gd2l0aCB0aGUgdG9rZW4uJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEuIEludHJvZHVjdGlv bjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PT09 PT09PT09PT09PT08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkNvbnNpZGVyIHJlZmVyZW5jaW5nIGRyYWZ0LWlldGYtb2F1dGgtcG9wLWFyY2hpdGVj dHVyZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkl0IHdpbGwgYmUgY2xlYXJlciBmb3IgdGhlIHJlYWRlciB0aGVuLCBhbmQgdGhlIHRl eHQgd2lsbCBiZSBzaG9ydGVyLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLiBUZXJtaW5vbG9neSAtIFByZXNlbnRlcjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PT09PT09PT09PT09 PT09PT09PT09PT09PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5TZW50ZW5jZSAxPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3Qgc3VyZSBpZiB0aGUgZmlyc3Qgc2VudGVu Y2UgaXMgYWNjdXJhdGVseSByZWZsZWN0aW5nIHRoZSBpbnRlbnQuJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBleGNsdWRlcyByb2d1 ZSBwYXJ0eSBwcmVzZW50aW5nIHRoZSB0b2tlbiAoYW5kIGZhaWxzKSBmcm9tIHByZXNlbnRlci4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PklmIHNvLCBpdCBpcyBmaW5lIGJ1dCB1c2luZyBtb3JlIHF1YWxpZmllZCB0ZXJtIGxpa2UgJnF1 b3Q7YXV0aG9yaXplZCBwcmVzZW50ZXImcXVvdDsgbWF5IG1ha2UgaXQgZWFzaWVyJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5mb3IgdGhl IHJlYWRlciB0byBwYXJzZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T3RoZXJ3aXNlIHJldmlzZSB0aGUgZGVmaW5pdGlvbi4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ U2VudGVuY2UgMjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+LS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7aXNzdWVyIG9yIGEgcGFydHkgZGlmZmVyZW50IGZy b20gdGhlIGlzc3VlciZxdW90OyBpcyBub3QgY29uc3RyYWluaW5nIGFueXRoaW5nIGFuZCBtZWFu aW5nbGVzcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZXJlIGFyZSBtb3JlIGVhc2llciB0byBwYXJzZSBhbmQgYWNjdXJhdGUgdGV4 dCBjb21pbmcgaW4gdGhlIG1haW4gdGV4dCwgdG9vLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RHJvcC4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+My4gUHJvb2YtT2YtUG9z ZXNzaW9uIFJlcHJlc2VudGF0aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRpdGxlPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS0tLS0tLS08bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBlcmhhcHMg JnF1b3Q7U2VuZGVyIFJlcHJlc2VudGF0aW9uIGluIEpXVCZxdW90OyBpcyBtb3JlIHJlZmxlY3Rp dmUgb2YgdGhlIGNvbnRlbnQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBhcmEgMjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHBhcmFncmFwaCBkZXNjcmliZXMg dHdvIHdheXMgb2Ygc2VuZGVyIGNvbmZpcm1hdGlvbjombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPigxKSBTZW5kZXIgQ29uc3RyYWludDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KDIpIEtl eSBDb25maXJtYXRpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkl0IHNob3VsZCByZWZlciB0byA1LjIgYW5kIDUuMyBvZiBbUE9QQV0gZm9yIGl0 LCBhcyB3ZWxsIGFzIGFsaWduIHRoZSB0ZXJtaW5vbG9neS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlbiwgaXQgZ29lcyBvbiB0 byBkZXNjcmliZSAoMSkgdmVyeSBicmllZmx5LCBpbiB3aGljaCBpdCBpcyBqdXN0IHNwZWxsaW5n IG91dCAmcXVvdDtpc3MmcXVvdDsgYW5kICZxdW90O3N1YiZxdW90Oy4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHVuZGVyc3RhbmQgdGhlIHVz ZSBvZiBzdWIgaW4gdGhpcyBzZWN0aW9uIGNvbWVzIGRvd24gZnJvbSBTQU1MIGJ1dCBJIGZlZWwg dGhhdCBzb21lIHNlcGFyYXRpb24gYmV0d2VlbiBzdWIgYW5kIHByZXNlbnRlciB3b3VsZCBiZSBu aWNlLg0KPGJyPg0KPGJyPg0KRm9yIGV4YW1wbGUsIHdoZW4gSSBhbSBwcmVzZW50aW5nIHRoZSB0 b2tlbiB1c2luZyBhbiBhcHAgdGhhdCBJIGluc3RhbGxlZCBvbiBteSBpUGhvbmUsIHRoZSBwcmVz ZW50ZXIgaXMgdGhhdCBhcHAgYW5kIG5vdCBtZSwgd2hpbGUgdGhlIHN1YiBzdGlsbCBtYXkgYmUg bWUuIFRoZSBhcHAgaXMgdGhlIGF1dGhvcml6ZWQgcHJlc2VudGVyL3BhcnR5IChhenApIG9mIHRo ZSB0b2tlbi4mbmJzcDtUaGUgSldUIG1heSB3ZWxsIGJlIGFib3V0IHRoZSBzdWIgYnV0DQogcHJl c2VudGVkIGJ5IHNvbWUgc29mdHdhcmUgY29tcG9uZW50IHRoYXQgc2hvdWxkIGJlIGluZGVwZW5k ZW50bHkgaWRlbnRpZmllZC4gJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KU28gbXkgcHJvcG9zYWwgaXMgdG8gY3JlYXRlIGEgbmV3IHN1YnNl Y3Rpb24gb24gKDEpIGZvciB0aGUgY29tcGxldGVuZXNzLCB3aGljaCBpcyBnb2luZyB0byBiZSBh IG5ldyAzLjEsIGFuZCB0byB1c2UgYSBjbGFpbSBsaWtlICZxdW90O2F6cCZxdW90OyBpbnN0ZWFk IG9mICZxdW90O3N1YiZxdW90OyB0byBpZGVudGlmeSB0aGUgcHJlc2VudGVyLiBMZXNzIG92ZXJs b2FkIHdvdWxkIGNhdXNlIGxlc3MgY29uZnVzaW9uIGxhdGVyLCBJTUhPLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zLjE8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPj09PT09PTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGl0bGU8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLS0tLS0tPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QZXJoYXBzICZx dW90O0NvbmZpcm1hdGlvbiBLZXkgUmVwcmVzZW50YXRpb24gZm9yIGFuIEFzeW1tZXRyaWMgS2V5 JnF1b3Q7IGlzIG1vcmUgcmVmbGVjdGl2ZSBvZiB0aGUgY29udGVudC4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+My4yPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj49PT09PT09PTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGl0bGU8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLS0tLS0t LS0tPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Q ZXJoYXBzICZxdW90O0NvbmZpcm1hdGlvbiBLZXkgUmVwcmVzZW50YXRpb24gZm9yIGEgU3ltbWV0 cmljIEtleSZxdW90OyBpcyBtb3JlIHJlZmxlY3RpdmUgb2YgdGhlIGNvbnRlbnQuJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxhc3Qg UGFyYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ LS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgZmVlbCBhIGJpdCBsaWtlIG5lZWRpbmcgdG8gc25pZmYgaW50byB0aGUg Y29udGVudCBvZiBqd2sgdG8gZmluZCBvdXQgd2hhdCB0eXBlIG1heSBub3QgYmUgb3B0aW1hbCwg dGhvdWdoIEkgZG8gbm90IGhhdmUgYSBjb25jcmV0ZSBwcm9wb3NhbCBhIHRoaXMgdGltZS4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ My4zPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj49 PT09PT08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRpdGxlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlBlcmhhcHMgJnF1b3Q7Q29uZmlybWF0aW9uIEtleSBSZXByZXNlbnRhdGlvbiBieSBL ZXkgSUQmcXVvdDsgaXMgbW9yZSByZWZsZWN0aXZlIG9mIHRoZSBjb250ZW50LiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QYXJhIDE8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLS0t LS0tLS0tPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGVyZSBoYXMgYmVlbiBzb21lIGRpc2N1c3Npb24gb2YgdXNpbmcgdGh1bWJwcmludCBpbnN0 ZWFkIG9mIGEgYmxvYiAmcXVvdDtraWQmcXVvdDsuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIGEgdmFsaWQgb3B0aW9uLiBJ ZiB3ZSBhcmUgdG8gb3ZlcmxvYWQgdGhlICZxdW90O2tpZCZxdW90OyBtZW1iZXIgZm9yIHRoaXMg cHVycG9zZSwgd2UgbmVlZCB0byBmaW5kIGEgd2F5IHRvIHNpZ25hbCB0aGF0IGl0IGlzIGEgdGh1 bWJwcmludC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkl0IG1heSB2ZXJ5IHdlbGwgYmUgYmV0dGVyIHRvIGRlZmluZSBhIHNlcGFyYXRl IG1lbWJlciBuYW1lIHRoZW4gZm9yIHRoZSB0aHVtYnByaW50LiBUaGUgdGl0bGUgdGhlbiBjaGFu Z2VzIHRvICZxdW90Oy0tIGJ5IEtleSBJRCZxdW90OyB0byAmcXVvdDstLSBieSByZWZlcmVuY2Um cXVvdDsuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkFsc28sIGl0IGlzIGNvbmNlaXZhYmxlIHRvIHVzZSB0aGUgY29tYmluYXRpb24g b2YgJnF1b3Q7a2lkJnF1b3Q7IGFuZCAmcXVvdDtqa3UmcXVvdDsuIFRoaXMgYXNwZWN0IGlzIG5v dCBzcGVsbGVkIG91dCBoZXJlIGJ1dCBhcHBlYXJzIHRoYXQgc29tZSBtYWdpYyBoYXBwZW5zIGZv ciB0aGUga2V5IGRpc3RyaWJ1dGlvbi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMuNCZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PT09PT09PT08bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNpbmNlICZxdW90O2Nu ZiZxdW90OyBhcHBlYXJzIGJlZm9yZSAzLjQsIGl0IG1heSBiZSBiZXR0ZXIgdG8gYnJpbmcgMy40 IGF0IHRoZSBmcm9udC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj41LjIuMjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PT09PT09PT09PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZGQgJnF1b3Q7YXpwJnF1b3Q7IGFuZCAm cXVvdDtqa3QmcXVvdDsuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+byAmbmJzcDtDb25maXJtYXRpb24gTWV0aG9kIFZhbHVlOiAmcXVvdDthenAm cXVvdDs8YnI+DQpvICZuYnNwO0NvbmZpcm1hdGlvbiBNZXRob2QgRGVzY3JpcHRpb246IENsaWVu dCBJRCBvZiB0aGUgQXV0aG9yaXplZCBQcmVzZW50ZXI8YnI+DQpvICZuYnNwO0NoYW5nZSBDb250 cm9sbGVyOiBJRVNHPGJyPg0KbyAmbmJzcDtTcGVjaWZpY2F0aW9uIERvY3VtZW50KHMpOiBTZWN0 aW9uIFtUQkRdIG9mIFtbIHRoaXMgZG9jdW1lbnQgXV08YnI+DQo8YnI+DQo8YnI+DQpvICZuYnNw O0NvbmZpcm1hdGlvbiBNZXRob2QgVmFsdWU6ICZxdW90O2prdCZxdW90Ozxicj4NCm8gJm5ic3A7 Q29uZmlybWF0aW9uIE1ldGhvZCBEZXNjcmlwdGlvbjogSldLIFRodW1icHJpbnQgb2YgdGhlIENv bmZpcm1hdGlvbiBLZXk8YnI+DQpvICZuYnNwO0NoYW5nZSBDb250cm9sbGVyOiBJRVNHPGJyPg0K byAmbmJzcDtTcGVjaWZpY2F0aW9uIERvY3VtZW50KHMpOiBTZWN0aW9uIFtUQkRdIG9mIFtbIHRo aXMgZG9jdW1lbnQgXV08YnI+DQo8YnI+DQo8YnI+DQpvICZuYnNwO0NvbmZpcm1hdGlvbiBNZXRo b2QgVmFsdWU6ICZxdW90O2prdSZxdW90Ozxicj4NCm8gJm5ic3A7Q29uZmlybWF0aW9uIE1ldGhv ZCBEZXNjcmlwdGlvbjogSldLIFVSSSBvZiB0aGUgQ29uZmlybWF0aW9uIEtleTxicj4NCm8gJm5i c3A7Q2hhbmdlIENvbnRyb2xsZXI6IElFU0c8YnI+DQpvICZuYnNwO1NwZWNpZmljYXRpb24gRG9j dW1lbnQocyk6IFNlY3Rpb24gW1RCRF0gb2YgW1sgdGhpcyBkb2N1bWVudCBdXTxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UHJpdmFjeSBDb25zaWRlcmF0aW9u PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj49PT09 PT09PT09PT09PT09PT09PT09PT08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkl0IGlzIG1pc3NpbmcgcHJpdmFjeSBjb25zaWRlcmF0aW9uLiBJdCBp cyBub3QgcmVxdWlyZWQgcGVyIHNlLCBidXQgc2luY2UgS2V5IENvbmZpcm1hdGlvbiBtZXRob2Qg d2l0aCBlcGhlbWVyYWwga2V5IGNhbiBiZSBsZXNzIHByaXZhY3kgaW50cnVzaXZlIGNvbXBhcmVk IHRvIG90aGVyIHNlbmRlciBjb25maXJtYXRpb24gbWV0aG9kIHNvIGFkZGluZyBzb21lIHRleHQg YXJvdW5kIGl0IG1heSBiZSBhIGdvb2QNCiBpZGVhLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCwmbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9Imhv ZW56YiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPi0tIDxvOnA+PC9vOnA+PC9zcGFuPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiM4ODg4ODgiPk5hdCBTYWtpbXVyYSAoPW5hdCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPkNoYWly bWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlu a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZuYXQuc2FraW11cmEu b3JnJTJmJmFtcDtkYXRhPTAxJTdjMDElN2NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3 YzhlM2ExYzgwODAwMDQ0YWZlYTY0MDhkMjk5NDg3OTE0JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIy ZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1Ba0U5OTRKTXRjVjlTR0szeWFaOWJlQ3A0cjRSSU1u OUZzJTJiWlU5RVNkZU0lM2QiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbmF0LnNha2ltdXJhLm9y Zy88L2E+PGJyPg0KQF9uYXRfZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TmF0 IFNha2ltdXJhICg9bmF0KTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbmEw MS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZuYXQu c2FraW11cmEub3JnJTJmJmFtcDtkYXRhPTAxJTdjMDElN2NNaWNoYWVsLkpvbmVzJTQwbWljcm9z b2Z0LmNvbSU3YzhlM2ExYzgwODAwMDQ0YWZlYTY0MDhkMjk5NDg3OTE0JTdjNzJmOTg4YmY4NmYx NDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1Ba0U5OTRKTXRjVjlTR0szeWFaOWJl Q3A0cjRSSU1uOUZzJTJiWlU5RVNkZU0lM2QiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbmF0LnNh a2ltdXJhLm9yZy88L2E+PGJyPg0KQF9uYXRfZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BY2PR03MB44280E7A1B2AA29EE5DD3EDF58A0BY2PR03MB442namprd_-- From nobody Fri Jul 31 11:47:13 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252B01B344B for ; Fri, 31 Jul 2015 11:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LH-eKWzAhOZz for ; Fri, 31 Jul 2015 11:47:10 -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 C91D21B3460 for ; Fri, 31 Jul 2015 11:47:09 -0700 (PDT) Received: by igr7 with SMTP id 7so22050481igr.0 for ; Fri, 31 Jul 2015 11:47:09 -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:content-type; bh=kU/70hNl0Lr14vUdYS27WxkSGrz29E3HFLoGLHYTRMU=; b=g8aqUrDPa1duCq+Zjos04qqo5IJJY9n/DmeOn26/TnyW7/+FZgJStHKkW4TWS5O1PK 1gF0I0ymsKdIDUN6cFDY808UkFbFg9Wqvy3lC4zs5+joxd8q8og9dbnajPR+cnIEsra0 o7GqJ7hKqMfngy4adPzoU9XrGcYzI1F+05/Ig= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=kU/70hNl0Lr14vUdYS27WxkSGrz29E3HFLoGLHYTRMU=; b=WbN6tCmIHm0BKeIarRADV6oHLXnVthzFYiQT+PBinpZR3H1rpWPy0dv+9kwPT0GQ+O uUXG5Lxr+ZTyA5HRXmpduaUkU4jm49FSvlK85e4ghQtx+xEChiWZSos13S7OiILZTfSN FTiR6k0l6VWZ4RJC3GNKviZ49PepU5BMg/fq4GVsFRguDavfjVWuRGIVSiBJS68LVsAX f0hl4Lfv2xYqsddHvwuwf0j2uhWJEcjbvxvX4SopHUmRvCz9xd/6hPcW0N6qv0joCzjf jYbIZrHlQk/1L01jz6Qlo8Rs769ure1j3iLb7PrjivOCP8SwgrDa+PHKklL9xVG3gOkO ZAAw== X-Gm-Message-State: ALoCoQm2VZVV7iKtizvAny/yj8HA+/0bfDn6nqvfHouP8oW5//YBe6rhDJ6f0EFPDlN56mbm81IA X-Received: by 10.50.61.195 with SMTP id s3mr8631530igr.62.1438368429041; Fri, 31 Jul 2015 11:47:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Fri, 31 Jul 2015 11:46:39 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Fri, 31 Jul 2015 12:46:39 -0600 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=047d7bdc05f2450bad051c303fd3 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: confirmation model in proof-of-possession-02) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 18:47:13 -0000 --047d7bdc05f2450bad051c303fd3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The Token Binding ID already has the public key in it. A normal cnf containing a JWK with the public key would work. But the whole Token Binding ID would probably be simpler. Or, if we're gonna make them parse the Token Binding ID, then a cnf that uses a finger/thumbprint of the key would be more space efficient as the whole key is already being sent elsewhere. That's all stuff that can be worked out later though. What I'm trying to express is that we don't really know what kind of flexibility will be needed and it's not at all clear that a structured cnf claim gives flexibility. On Thu, Jul 30, 2015 at 4:52 PM, John Bradley wrote: > Token binding might be a bad example. > > I can=E2=80=99t see why you would need something separate unless you are = trying to > do something like message signing and token binding. > I guess that is theoretically posable. > > Typically I think token binding would use the normal cnf containing a JWK > with the public key. > > The difference between token binding and mutual TLS is in the presentment > one is TLS client auth and the other is a signature over the tls unique i= n > a header. > > I think multiple cnf methods for the same presenter like SAML is overkill= . > > However the ability to re-use the cnf structure for people who want > something custom seems reasonable (we couldn't stop them anyway) > > John B. > > On Jul 30, 2015, at 7:40 PM, Brian Campbell > wrote: > > Some replies inline but the gist is that I disagree. > > On Thu, Jul 30, 2015 at 2:17 PM, Mike Jones > wrote: > >> Part of the reasoning for using a structured confirmation claim, rather >> than flattening the confirmation claim into the top-level JWT claims set= , >> is that a JWT may carry more than one conformation key or key descriptor= , >> as was mentioned in Prague. For instance, imagine that an application i= s >> conveying an application-level confirmation key using the =E2=80=9Ccnf= =E2=80=9D claim and >> for instance a token binding key using a second instance of the >> confirmation structure, say using the =E2=80=9Ctokbnd=E2=80=9D claim. W= ith the current >> structured approach, you=E2=80=99d have: >> >> >> >> {=E2=80=A6 >> >> =E2=80=9Ccnf=E2=80=9D:{=E2=80=9Cjwk=E2=80=9D: =E2=80=A6}, >> >> =E2=80=9Ctokbnd=E2=80=9D:{=E2=80=9Cjwk=E2=80=9D: =E2=80=A6} >> >> } >> >> >> > > That presumes token binding will use the same confirmation methods. But > I'd imagine that the Token Binding ID would somehow be used to signal > confirmation. So I'd be surprised if it ends up looking like that. The jw= e > member of the cnf claim defiantly wouldn't apply. > > It also presumes that you'd want cnf and tokbnd in the same JWT, which > doesn't really make sense to me. This draft wants to establish a registry > for JWT Confirmation Methods but a token binding confirmation would be a > different claim? > > > >> If one were to flatten the structure, however, unique claim names would >> have to be produced for the cross-product of each conformation element a= nd >> each confirmation claim. So you=E2=80=99d end up defining and registeri= ng these >> claims in the top-level JWT Claims registry: >> >> cnf_jwk >> >> cnf_jwe >> >> cnf_kid >> >> tokbnd_jwk >> >> tokbnd_jwe >> >> tokbnd_kid >> >> If you add other kind of confirmation keys, things would continue to get >> even sillier. >> > > Again that presumes token binding will use the same confirmation methods, > which I think it unlikely. > > I suspect it'd be more like cjwk, cjwe, ckid, and ctbd. > > And a cnf with nested structure would need a tbd or tokbnd member defined > and registered. > > >> >> >> The code will be simpler if you can have a single shared routine for >> handling confirmation structures rather a separate for handling cnf_jwk, >> cnf_jwe, cnf_kid from the one for handling tokbnd_jwk, tokbnd_jwe, >> tokbnd_kid, etc. >> > > You can still have a shared routine for handling things that are the same= . > But with a nested structure you have to dig into the nesting. > > >> >> >> Another reason the structure makes things conceptually simpler is that >> then you can always use the name =E2=80=9Ckid=E2=80=9D to hold a key ID,= no matter the >> context, rather than having to use *name-your-prefix*_kid. The same >> holds true for other elements. >> > > I personally don't find that convincing. It depends on how someone thinks > about it. > > >> >> >> I=E2=80=99m sorry this wasn=E2=80=99t clear in Prague. I know it was me= ntioned in the >> context of carrying multiple confirmation keys in a JWT, but it went by >> pretty fast. >> > > It was an informal discussion that was largely about something else. > > >> >> >> Based on the discussion in Prague, I believe that we should add language >> to the spec saying that applications can define new claim names other th= an >> =E2=80=9Ccnf=E2=80=9D to use to represent application-specific confirmat= ion structures that >> have the same syntax as those using the =E2=80=9Ccnf=E2=80=9D name. Wou= ld that do the >> trick for you? >> > > That's not at all what I'm driving at. > > If you believe that there's need for multiple confirmation structures wit= h > the exact same syntax and meaning, I suppose that would be a useful > addition. But if you really believe that, the structure itself should > probably be adjusted to allow for multiples. I'm skeptical that it'll eve= r > be needed. > > >> >> >> By the way, I=E2=80=99m as much in favor of compactness as anyone. Heck= =E2=80=93 I was >> one of the folks who foisted the short claim names like =E2=80=9Ciss=E2= =80=9D on the >> world! But I really do believe that in this case, having structure make= s >> things more readable and more flexible, especially since there will be >> cases where there are multiple confirmation structures in the same JWT. >> > > I can see both sides of readability. I don't see the flexibility. > > >> And once you prefix the names, you lose most of the space savings anyway= . >> > > Depends on how you prefix them or otherwise name things. You've chosen > long prefixes to make your point but it wouldn't have to be that way. > > >> >> >> Best >> wishes, >> >> -- Mike >> >> >> >> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian >> Campbell >> *Sent:* Thursday, July 30, 2015 11:29 AM >> *To:* Nat Sakimura >> *Cc:* oauth >> *Subject:* [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: >> confirmation model in proof-of-possession-02) >> >> >> >> Using individual claims for the different confirmation types would conve= y >> the same information with a reduced message size, likely simpler >> implementation, and avoid the need to establish a new registry. >> >> Seems like a no-brainer to me but maybe I'm overlooking something? >> >> There hasn't been much discussion that I'm aware of. Nat seemed in favor >> of it (the +1 below). Mike was dismissive of it at the Dallas meeting bu= t >> didn't provide any reasoning (that I understood anyway). >> >> >> >> >> >> On Mon, Mar 23, 2015 at 10:18 AM, Nat Sakimura >> wrote: >> >> +1 >> >> =3Dnat via iPhone >> >> >> 2015/03/23 11:07=E3=80=81Brian Campbell =E3= =81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8: >> >> This is mostly about section 3.4 >> >> but also the whole draft. >> >> >> If "cnf" is intended to analogous to the SAML 2.0 SubjectConfirmation >> element, it should probably contain an array value rather than an object >> value. SAML allows not just for multiple methods of confirming but for >> multiple instances of the same method. IIRC, only one confirmation needs= to >> be confirmable. >> >> I'm not sure the extra complexity is worth it though. I've rarely, if >> ever, seen SAML assertions that make use of it. >> >> If the intent is just to allow for different kinds of confirmation, >> couldn't the structure be pared down and simplified and just have >> individual claims for the different confirmation types? Like "cjwk" and >> "ckid" or similar that have the jwk or kid value respectively as the mem= ber >> value. >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --047d7bdc05f2450bad051c303fd3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The Token Binding ID already has the public key in it. A n= ormal cnf containing a JWK with the public key would work. But the whole To= ken Binding ID would probably be simpler. Or, if we're gonna make them = parse the Token Binding ID, then a cnf that uses a finger/thumbprint of the= key would be more space efficient as the whole key is already being sent e= lsewhere. That's all stuff that can be worked out later though. What I&= #39;m trying to express is that we don't really know what kind of flexi= bility will be needed and it's not at all clear that a structured cnf c= laim gives flexibility.



On Thu, Jul 30, 2015 at 4:52 PM, John Bradley <ve= 7jtb@ve7jtb.com> wrote:
Token binding might be a bad example.
=
I can=E2=80=99t see why you would need something separate un= less you are trying to do something like message signing and token binding.= =C2=A0
I guess that is theoretically posable.

Typically I think token binding would use the normal cnf containing = a JWK with the public key.

The difference between = token binding and mutual TLS is in the presentment one is TLS client auth a= nd the other is a signature over the tls unique in a header.

=
I think multiple cnf methods for the same presenter like SAML is= overkill.

However the ability to re-use the cnf s= tructure for people who want something custom seems reasonable (we couldn&#= 39;t stop them anyway)

John B.

On Jul 30, 2015, at 7:40 PM, Bri= an Campbell <bcampbell@pingidentity.com> wrote:

Some replies inline but the gist is that I disagree.=C2= =A0

On Thu, Jul 30, 2015 at 2:17 PM, Mike Jones=C2=A0<Michael.Jones@microsoft.com>=C2=A0wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">

Part of the reasoning for using a structured conf= irmation claim, rather than flattening the confirmation claim into the top-= level JWT claims set, is that a JWT may carry more than one conformation ke= y or key descriptor, as was mentioned in Prague.=C2=A0 For instance, imagin= e that an application is conveying an application-level confirmation key us= ing the =E2=80=9Ccnf=E2=80=9D claim and for instance a token binding key us= ing a second instance of the confirmation structure, say using the =E2=80= =9Ctokbnd=E2=80=9D claim.=C2=A0 With the current structured approach, you= =E2=80=99d have:

=C2=A0

{=E2=80=A6=

=E2=80=9Ccnf=E2=80=9D:{=E2=80= =9Cjwk=E2=80=9D: =E2=80=A6},

=E2=80=9Ctokbnd=E2=80=9D:{=E2=80=9Cjwk=E2=80=9D: =E2=80=A6}

}

=C2=A0

<= br>That presumes token binding will use the same confirmation methods. But = I'd imagine that the Token Binding ID would somehow be used to signal c= onfirmation. So I'd be surprised if it ends up looking like that. The j= we member of the cnf claim defiantly wouldn't apply.=C2=A0=

It also presumes that you'd wa= nt cnf and tokbnd in the same JWT, which doesn't really make sense to m= e. This draft wants to establish a registry for JWT Confirmation Methods bu= t a token binding confirmation would be a different claim?

=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">

If= one were to flatten the structure, however, unique claim names would have = to be produced for the cross-product of each conformation element and each = confirmation claim.=C2=A0 So you=E2=80=99d end up defining and registering = these claims in the top-level JWT Claims registry:

=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0cnf_jwk<= /u>

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0cnf_jwe

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0cnf_kid

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0tokbnd_jwk

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0tokbnd_jwe

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0tokbnd_kid

If you add other kind of confirmation keys, things would cont= inue to get even sillier.


Again that presumes token binding will use the same confirmation meth= ods, which I think it unlikely.

I suspect it'd be mor= e like cjwk, cjwe, ckid, and ctbd.=C2=A0=C2=A0

And a cn= f with nested structure would need a tbd or tokbnd member defined and regis= tered.=C2=A0
=C2=A0

=C2=A0<= /u>

The code will be simpler if you = can have a single shared routine for handling confirmation structures rathe= r a separate for handling cnf_jwk, cnf_jwe, cnf_kid from the one for handli= ng tokbnd_jwk, tokbnd_jwe, tokbnd_kid, etc.


You can still have a shared routine for handling th= ings that are the same. But with a nested structure you have to dig into th= e nesting.
=C2=A0

<= /u>

=C2=A0

<= p class=3D"MsoNormal">Another reason the structure makes things conce= ptually simpler is that then you can always use the name =E2=80=9Ckid=E2=80= =9D to hold a key ID, no matter the context, rather than having to use=C2=A0name-your-prefix_kid.=C2=A0 The same holds true for ot= her elements.


I pers= onally don't find that convincing. It depends on how someone thinks abo= ut it.=C2=A0
=C2=A0

=C2=A0<= /u>

I=E2=80=99m sorry this wasn=E2= =80=99t clear in Prague.=C2=A0 I know it was mentioned in the context of ca= rrying multiple confirmation keys in a JWT, but it went by pretty fast.


It was an informal disc= ussion that was largely about something else.
=C2=A0

=C2=A0

Based on the= discussion in Prague, I believe that we should add language to the spec sa= ying that applications can define new claim names other than =E2=80=9Ccnf= =E2=80=9D to use to represent application-specific confirmation structures = that have the same syntax as those using the =E2=80=9Ccnf=E2=80=9D name.=C2= =A0 Would that do the trick for you?


That's not at all what I'm driving at.=C2=A0=

If you believe that there's need for multiple= confirmation structures with the exact same syntax and meaning, I suppose = that would be a useful addition. But if you really believe that, the struct= ure itself should probably be adjusted to allow for multiples. I'm skep= tical that it'll ever be needed.
=C2=A0

=C2=A0

By the way, I=E2=80= =99m as much in favor of compactness as anyone.=C2=A0 Heck =E2=80=93 I was = one of the folks who foisted the short claim names like =E2=80=9Ciss=E2=80= =9D on the world!=C2=A0 But I really do believe that in this case, having s= tructure makes things more readable and more flexible, especially since the= re will be cases where there are multiple confirmation structures in the sa= me JWT.=C2=A0


I can = see both sides of readability. I don't see the flexibility.=C2=A0=
=C2=A0

And once you= prefix the names, you lose most of the space savings anyway.


Depends on how you prefix them or= otherwise name things. You've chosen long prefixes to make your point = but it wouldn't have to be that way.=C2=A0
= =C2=A0

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0Best wishes,

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

=C2=A0

From:= =C2=A0OAuth [mailto:oauth-bounces@ietf.org]=C2=A0On Behalf = Of=C2=A0Brian Campbell
Sent:=C2=A0T= hursday, July 30, 2015 11:29 AM
To:=C2=A0Nat Sakimur= a <sakimura@gmai= l.com>
Cc:=C2=A0oauth <oauth@ietf.org>
Subject:<= span>=C2=A0[OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re:= confirmation model in proof-of-possession-02)

=C2=A0

Using individual claims for the dif= ferent confirmation types would convey the same information with a reduced = message size, likely simpler=C2=A0 implementation, and avoid the need to es= tablish a new registry.=C2=A0

Seems like a no-brainer t= o me but maybe I'm overlooking something?=C2=A0=C2=A0

There hasn't been much discus= sion that I'm aware of. Nat seemed in favor of it (the +1 below). Mike = was dismissive of it at the Dallas meeting but didn't provide any reaso= ning (that I understood anyway).

=C2=A0

=C2= =A0

On Mon, Mar 23, 2015 at 10:18 AM,= Nat Sakimura <s= akimura@gmail.com> wrote:

+1

=3Dnat via iPhone

=


2015/03/= 23 11:07=E3=80=81Bria= n Campbell <bcampbell@pingidentity.com>=C2=A0=E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC= =E3=82=B8:

This i= s mostly about=C2=A0section 3.4=C2=A0but also the whole dra= ft.


If "cnf" is intended to analogous to the SAML 2.0 Su= bjectConfirmation element, it should probably contain an array value rather= than an object value. SAML allows not just for multiple methods of confirm= ing but for multiple instances of the same method. IIRC, only one confirmat= ion needs to be confirmable.

I'm not sure the extra complexity is = worth it though. I've rarely, if ever, seen SAML assertions that make u= se of it.

If the intent is just to allow for different kinds of confir= mation, couldn't the structure be pared down and simplified and just ha= ve individual claims for the different confirmation types? Like "cjwk&= quot; and "ckid" or similar that have the jwk or kid value respec= tively as the member value.=C2=A0=C2=A0

<= /p>

= =C2=A0

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

=C2=A0


_______________________________________________OAuth mailing = list
= OAuth@ietf.org
https://= www.ietf.org/mailman/listinfo/oauth
=
--047d7bdc05f2450bad051c303fd3-- From nobody Fri Jul 31 11:55:10 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5DD61B34A4 for ; Fri, 31 Jul 2015 11:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCkuJX-icUfn for ; Fri, 31 Jul 2015 11:55:04 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001: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 85E081B34A1 for ; Fri, 31 Jul 2015 11:55:04 -0700 (PDT) Received: by igk11 with SMTP id 11so38006501igk.1 for ; Fri, 31 Jul 2015 11:55:04 -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:content-type; bh=fShuDYSgvOzyFpJrQH2fWI9yQNEXpGdkrNnBsMkjaQ0=; b=iXm6Y6uEo3aFaM24E0ZeIBn1FSM4qWAqOKxeoeJ45ACtLO9qVVW5F2AeLcB2qzHMZO 7qPHG0+KqRov0AWRN38mBzfQ15Ucd7qLRlko8g0C1Wk0HD78QsE8129QEJvR0zjzZLPy TjmI9BGLrHEfrJ+EA4Tuh/JkPpMzUgeZVP5Mk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=fShuDYSgvOzyFpJrQH2fWI9yQNEXpGdkrNnBsMkjaQ0=; b=KDNpXr9wbYiK7fOVAgaME2F9LW2BxoHw1+Z7TqRVnH6xC2Oe/TkgSQGJRkifv8ezjd CL+apwk/uH+GA8/uiNZ82cPtnPnRA2Rz9KfHjQMGwj8nxxTgRzuhzYAmWLBA3T/dlMA9 Xd0MBht5F6HpyyILC6rIHQKTr7xd2Dep+tSCDy/ABLFrryj1qhu6YWCKt+nxhdvSW7e9 xyJBjmibKxr/PaRHOVhR/JPGFaVW7ayoJmsy9saf+tfhCTXhmNBy3xA8gUH5o7+CUskv ts5tcY0acgfOJd0etoo3VC+gsaC8LptADZipltvyNC83uWd6ATO3fCWt4tv6J2+s201z wD5Q== X-Gm-Message-State: ALoCoQm87RZQuVquGvtn7uXGq3LhO0nI5sDlcAANSYjwEVYlKj7PtuhoJWL106KHYoYWHEzEK5Pf X-Received: by 10.50.64.147 with SMTP id o19mr8341800igs.15.1438368903908; Fri, 31 Jul 2015 11:55:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Fri, 31 Jul 2015 11:54:34 -0700 (PDT) In-Reply-To: <97107378-B07E-472D-954E-FA4360B17576@ve7jtb.com> References: <3FBD2E36-79E8-4F4B-B2A5-1C3DC5E29D3D@ve7jtb.com> <97107378-B07E-472D-954E-FA4360B17576@ve7jtb.com> From: Brian Campbell Date: Fri, 31 Jul 2015 12:54:34 -0600 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=047d7bea2f9892fa39051c305b76 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: confirmation model in proof-of-possession-02) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 18:55:08 -0000 --047d7bea2f9892fa39051c305b76 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Don't get me wrong, I don't think an array is needed at all (and I fear the language in the draft that draws an analogy to SAML is maybe more likely to confuse than help). I just don't buy the argument that the nested structure is so much more flexible for these hypothetical cases. I seem to be in the minority here though (at least of the few people actually responding). And, while I thought there was room for a nice simplification, it's not something I care to fight (much) about. On Thu, Jul 30, 2015 at 5:00 PM, John Bradley wrote: > In my example you don=E2=80=99t really want to treat both the presenters = as > equivalent. Endpoints receiving the token should be able to tell which > presenter gave it to them and apply policy on that. > > If you wanted them to be equivalent then an array would work, but that > probably adds more confusion. > > John B. > > On Jul 30, 2015, at 7:48 PM, Brian Campbell > wrote: > > To really support that case where an initial AS/issuer wants to bind to > two presenters, shouldn't the confirmation structure itself allow for > multiple confirmation methods (i.e. be or allow for an array)? I don't > actually think that is needed but the flexibility that's being argued for > here would suggest that rather than renaming a nested structure that only > allows for a single occurrence of each kind of confirmation method. > > On Thu, Jul 30, 2015 at 3:14 PM, John Bradley wrote: > >> I agree, flattening would be a bad direction. >> >> In Prague I was indicating that there may be more than one presenter for >> an assertion. The first presenter may be the OAuth client who presents = it >> to a RS. >> > >> That RS itself may also present that token as a client in token exchange >> to get a new access token for another resource. >> >> The initial AS may want to bind that token to two presenters. The >> second AS doing the token exchange also probably only wants to know abou= t >> the proof key for the RS so that it doesn=E2=80=99t mistakenly give the = first >> client a token to directly access a backend API. >> > >> Trying to find a generic pattern for that is a bit of a trick though. >> >> I think that a single cnf element is enough for most use cases, however >> having cnf and cnf_rs or some other element using the cnf structure is >> probably the best we can do at this point. >> >> John B. >> >> On Jul 30, 2015, at 5:17 PM, Mike Jones >> wrote: >> >> Part of the reasoning for using a structured confirmation claim, rather >> than flattening the confirmation claim into the top-level JWT claims set= , >> is that a JWT may carry more than one conformation key or key descriptor= , >> as was mentioned in Prague. For instance, imagine that an application i= s >> conveying an application-level confirmation key using the =E2=80=9Ccnf= =E2=80=9D claim and >> for instance a token binding key using a second instance of the >> confirmation structure, say using the =E2=80=9Ctokbnd=E2=80=9D claim. W= ith the current >> structured approach, you=E2=80=99d have: >> >> {=E2=80=A6 >> =E2=80=9Ccnf=E2=80=9D:{=E2=80=9Cjwk=E2=80=9D: =E2=80=A6}, >> =E2=80=9Ctokbnd=E2=80=9D:{=E2=80=9Cjwk=E2=80=9D: =E2=80=A6} >> } >> >> If one were to flatten the structure, however, unique claim names would >> have to be produced for the cross-product of each conformation element a= nd >> each confirmation claim. So you=E2=80=99d end up defining and registeri= ng these >> claims in the top-level JWT Claims registry: >> cnf_jwk >> cnf_jwe >> cnf_kid >> tokbnd_jwk >> tokbnd_jwe >> tokbnd_kid >> If you add other kind of confirmation keys, things would continue to get >> even sillier. >> >> The code will be simpler if you can have a single shared routine for >> handling confirmation structures rather a separate for handling cnf_jwk, >> cnf_jwe, cnf_kid from the one for handling tokbnd_jwk, tokbnd_jwe, >> tokbnd_kid, etc. >> >> Another reason the structure makes things conceptually simpler is that >> then you can always use the name =E2=80=9Ckid=E2=80=9D to hold a key ID,= no matter the >> context, rather than having to use *name-your-prefix*_kid. The same >> holds true for other elements. >> >> I=E2=80=99m sorry this wasn=E2=80=99t clear in Prague. I know it was me= ntioned in the >> context of carrying multiple confirmation keys in a JWT, but it went by >> pretty fast. >> >> Based on the discussion in Prague, I believe that we should add language >> to the spec saying that applications can define new claim names other th= an >> =E2=80=9Ccnf=E2=80=9D to use to represent application-specific confirmat= ion structures that >> have the same syntax as those using the =E2=80=9Ccnf=E2=80=9D name. Wou= ld that do the >> trick for you? >> >> By the way, I=E2=80=99m as much in favor of compactness as anyone. Heck= =E2=80=93 I was >> one of the folks who foisted the short claim names like =E2=80=9Ciss=E2= =80=9D on the >> world! But I really do believe that in this case, having structure make= s >> things more readable and more flexible, especially since there will be >> cases where there are multiple confirmation structures in the same JWT. >> And once you prefix the names, you lose most of the space savings anyway= . >> >> Best >> wishes, >> -- Mike >> >> *From:* OAuth [mailto:oauth-bounces@ietf.org ] *= On >> Behalf Of *Brian Campbell >> *Sent:* Thursday, July 30, 2015 11:29 AM >> *To:* Nat Sakimura >> *Cc:* oauth >> *Subject:* [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: >> confirmation model in proof-of-possession-02) >> >> >> Using individual claims for the different confirmation types would conve= y >> the same information with a reduced message size, likely simpler >> implementation, and avoid the need to establish a new registry. >> >> Seems like a no-brainer to me but maybe I'm overlooking something? >> There hasn't been much discussion that I'm aware of. Nat seemed in favor >> of it (the +1 below). Mike was dismissive of it at the Dallas meeting bu= t >> didn't provide any reasoning (that I understood anyway). >> >> >> On Mon, Mar 23, 2015 at 10:18 AM, Nat Sakimura >> wrote: >> >> +1 >> >> =3Dnat via iPhone >> >> >> 2015/03/23 11:07=E3=80=81Brian Campbell =E3= =81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8: >> >> This is mostly about section 3.4 >> >> but also the whole draft. >> >> >> If "cnf" is intended to analogous to the SAML 2.0 SubjectConfirmation >> element, it should probably contain an array value rather than an object >> value. SAML allows not just for multiple methods of confirming but for >> multiple instances of the same method. IIRC, only one confirmation needs= to >> be confirmable. >> >> I'm not sure the extra complexity is worth it though. I've rarely, if >> ever, seen SAML assertions that make use of it. >> >> If the intent is just to allow for different kinds of confirmation, >> couldn't the structure be pared down and simplified and just have >> individual claims for the different confirmation types? Like "cjwk" and >> "ckid" or similar that have the jwk or kid value respectively as the mem= ber >> value. >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > > --047d7bea2f9892fa39051c305b76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Don't get me wrong, I don't think an array is= needed at all (and I fear the language in the draft that draws an analogy = to SAML is maybe more likely to confuse than help). I just don't buy th= e argument that the nested structure is so much more flexible for these hyp= othetical cases.

I seem to be in the minority here thoug= h (at least of the few people actually responding). And, while I thought th= ere was room for a nice simplification, it's not something I care to fi= ght (much) about.=C2=A0 =C2=A0



On Thu, Jul 30, 2015 at 5:= 00 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
In my example you = don=E2=80=99t really want to treat both the presenters as equivalent.=C2=A0= Endpoints receiving the token should be able to tell which presenter gave = it to them and apply policy on that.

If you wanted them = to be equivalent then an array would work, but that probably adds more conf= usion.

John B.

On Jul 30, 2015, at 7:48 PM, Brian Campbell <= bcampbell@p= ingidentity.com> wrote:

To really sup= port that case where an initial AS/issuer wants to bind to two presenters, = shouldn't the confirmation structure itself allow for multiple confirma= tion methods (i.e. be or allow for an array)?=C2=A0 I don't actually th= ink that is needed but the flexibility that's being argued for here wou= ld suggest that rather than renaming a nested structure that only allows fo= r a single occurrence of each kind of confirmation method.

On Thu, Jul 30, 2015 at = 3:14 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I agree, flatten= ing would be a bad direction.

In Prague I was indicating= that there may be more than one presenter for an assertion.=C2=A0 The firs= t presenter may be the OAuth client who presents it to a RS.

That RS itself may also present that token as a = client in token exchange to get a new access token for another resource.

The initial AS may want to bind that token to two pr= esenters. =C2=A0 The second AS doing the token exchange also probably only = wants to know about the proof key for the RS so that it doesn=E2=80=99t mis= takenly give the first client a token to directly access a backend API.

Trying to find a generic pattern for = that is a bit of a trick though.

I think that a si= ngle cnf element is enough for most use cases, however having cnf and cnf_r= s or some other element using the cnf structure is probably the best we can= do at this point.

John B.

On Jul 30, 2015, at 5:17 PM, Mike Jones <Michael.Jones@m= icrosoft.com> wrote:

Part of the reasoning for using a structured confirmation claim, = rather than flattening the confirmation claim into the top-level JWT claims= set, is that a JWT may carry more than one conformation key or key descrip= tor, as was mentioned in Prague.=C2=A0 For instance, imagine that an applic= ation is conveying an application-level confirmation key using the =E2=80= =9Ccnf=E2=80=9D claim and for instance a token binding key using a second i= nstance of the confirmation structure, say using the =E2=80=9Ctokbnd=E2=80= =9D claim.=C2=A0 With the current structured approach, you=E2=80=99d have:<= u>
=C2=A0
<= div style=3D"margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times = New Roman',serif">{=E2=80=A6
=E2=80=9Ccnf=E2=80=9D:{=E2=80=9Cjwk=E2=80=9D: =E2=80=A6}= ,
=E2=80=9Ctokbnd=E2= =80=9D:{=E2=80=9Cjwk=E2=80=9D: =E2=80=A6}
}
=C2=A0
If one were to flatten = the structure, however, unique claim names would have to be produced for th= e cross-product of each conformation element and each confirmation claim.= =C2=A0 So you=E2=80=99d end up defining and registering these claims in the= top-level JWT Claims registry:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 cnf_jwk
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cnf_jwe
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cnf_kid
<= div style=3D"margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times = New Roman',serif">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 tokbnd_jwk
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 tokbnd_jwe=
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 tokbnd_kid<= u>
If you add other kin= d of confirmation keys, things would continue to get even sillier.
=C2=A0
The code will be simpler if you can have a single share= d routine for handling confirmation structures rather a separate for handli= ng cnf_jwk, cnf_jwe, cnf_kid from the one for handling tokbnd_jwk, tokbnd_j= we, tokbnd_kid, etc.
=C2=A0
Another reason the structu= re makes things conceptually simpler is that then you can always use the na= me =E2=80=9Ckid=E2=80=9D to hold a key ID, no matter the context, rather th= an having to use=C2=A0name-your-prefix_kid.=C2=A0 The s= ame holds true for other elements.
=C2=A0
I=E2=80=99m = sorry this wasn=E2=80=99t clear in Prague.=C2=A0 I know it was mentioned in= the context of carrying multiple confirmation keys in a JWT, but it went b= y pretty fast.
=C2= =A0
Based on the discussion in Pra= gue, I believe that we should add language to the spec saying that applicat= ions can define new claim names other than =E2=80=9Ccnf=E2=80=9D to use to = represent application-specific confirmation structures that have the same s= yntax as those using the =E2=80=9Ccnf=E2=80=9D name.=C2=A0 Would that do th= e trick for you?
=C2= =A0
By the way, I=E2=80=99m as muc= h in favor of compactness as anyone.=C2=A0 Heck =E2=80=93 I was one of the = folks who foisted the short claim names like =E2=80=9Ciss=E2=80=9D on the w= orld!=C2=A0 But I really do believe that in this case, having structure mak= es things more readable and more flexible, especially since there will be c= ases where there are multiple confirmation structures in the same JWT.=C2= =A0 And once you prefix the names, you lose most of the space savings anywa= y.
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Best wishes,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike
=C2=A0
From:=C2=A0OAuth [mailto:= oauth-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Brian Campbell
Sent:=C2=A0Thursday, July 30= , 2015 11:29 AM
To:=C2=A0Nat Sakimura <sakimura@gmail.com>Cc:=C2=A0oauth <oauth@ietf.org>
Subject:=C2=A0[OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: confirmation mo= del in proof-of-possession-02)
=C2=A0

Using individual claims for the different confirmation types would conve= y the same information with a reduced message size, likely simpler=C2=A0 im= plementation, and avoid the need to establish a new registry.=C2=A0

Seems like a no-brainer to me but maybe I'm overlooking so= mething?=C2=A0=C2=A0

There hasn't been much discussion that I'm aware of. Nat seeme= d in favor of it (the +1 below). Mike was dismissive of it at the Dallas me= eting but didn't provide any reasoning (that I understood anyway).
=C2=A0
<= div>
=C2=A0
On Mon, Mar 23, 2015 at 10:18 AM, Nat Sakimura <sakimura@gmail.com> wrote:
+1

=3Dnat via iP= hone

2015/03/23 11:07=E3=80=81Brian Campbell <bcampbell@pin= gidentity.com>=C2=A0=E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8:<= u>

This is mostly about=C2=A0section 3.4=C2= =A0but also the whole draft.


If "cnf" is intended to analogou= s to the SAML 2.0 SubjectConfirmation element, it should probably contain a= n array value rather than an object value. SAML allows not just for multipl= e methods of confirming but for multiple instances of the same method. IIRC= , only one confirmation needs to be confirmable.

I'm not sure the extra complexit= y is worth it though. I've rarely, if ever, seen SAML assertions that m= ake use of it.

If the intent is just to allow for different kinds of confirmation, co= uldn't the structure be pared down and simplified and just have individ= ual claims for the different confirmation types? Like "cjwk" and = "ckid" or similar that have the jwk or kid value respectively as = the member value.=C2=A0=C2=A0

<= div>

=C2=A0

__________________________________= _____________
OAuth mailing list
OAuth@ietf= .org
https://www.ietf.org/mailman/listinfo/oauth
<= /u>=C2=A0
_________________________________________= ______
OAuth@i= etf.org
https://www.ietf.org/mailman/listinfo/oauth



--047d7bea2f9892fa39051c305b76-- From nobody Fri Jul 31 12:11:45 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6471B2EC3 for ; Fri, 31 Jul 2015 12:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xy8t6mge5noo for ; Fri, 31 Jul 2015 12:11:38 -0700 (PDT) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 231131B2EC8 for ; Fri, 31 Jul 2015 12:11:17 -0700 (PDT) Received: by qgeh16 with SMTP id h16so52216793qge.3 for ; Fri, 31 Jul 2015 12:11:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=DePSuLoAvZzbgPb2HWmOTlfWuqMldKxpkKGxki7eUco=; b=h8X+1SJuALue8UN0KNxU5SW8OlpPpQUlgVmz4aw/XEDBHpEwqsRlDxEg9mh5K5AhC9 PlkeaYuQIsqrTp6heyuepALSCzSk0a/8IM7TwRYZhVDF2zJsB9isWVkuF3Wh+HBZlns/ ZaBBUHjsrMVPoIcPw+czUVt6hZpOH3ltVdvBeez0t6ZQbGvIRDEK+/dWH0JNWJtkxB8B P6bfw2WleL/ntY++3WoJjFU3kUx/Qd2ucyNijIKIFtmfAs6kk8/NI6qOz3ZOW+ORZrmm SqYo7i/9r55JATbRHUo4TeyvAM0zEGeuFzpMqFENnUno9fgDeSr6tnuAqSegYsHVxsrL cBBg== X-Gm-Message-State: ALoCoQmh2U4+tzFOCXyFfuDQatOoVWVYko9bkEI1MSkX8QsnC4WgbyGI9SRYc9gA3qb6WN1c9osa X-Received: by 10.140.86.137 with SMTP id p9mr7017541qgd.89.1438369876269; Fri, 31 Jul 2015 12:11:16 -0700 (PDT) Received: from [192.168.8.100] ([181.202.170.185]) by smtp.gmail.com with ESMTPSA id d137sm2654894qhc.39.2015.07.31.12.11.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Jul 2015 12:11:15 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_8CE81E7B-9142-4E8E-8E4F-0662D6F4EFC8" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: John Bradley In-Reply-To: Date: Fri, 31 Jul 2015 16:11:09 -0300 Message-Id: References: To: Brian Campbell X-Mailer: Apple Mail (2.2102) Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: confirmation model in proof-of-possession-02) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 19:11:42 -0000 --Apple-Mail=_8CE81E7B-9142-4E8E-8E4F-0662D6F4EFC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes the token binding token has the public key so yes you could send the = JWK thumbprint of the key in the cnf method vs sending the JWK again to = save space. That is something we can add later as a confirmation = method. I prefer the structured approach even if it takes another registry. I = think it is easer to understand. I agree that we don=E2=80=99t want to = oversell the relationship to SAML confirmation methods.=20 This is POP confirmation not the more abstract subject confirmation = (that has pop as one option). John B. > On Jul 31, 2015, at 3:46 PM, Brian Campbell = wrote: >=20 > The Token Binding ID already has the public key in it. A normal cnf = containing a JWK with the public key would work. But the whole Token = Binding ID would probably be simpler. Or, if we're gonna make them parse = the Token Binding ID, then a cnf that uses a finger/thumbprint of the = key would be more space efficient as the whole key is already being sent = elsewhere. That's all stuff that can be worked out later though. What = I'm trying to express is that we don't really know what kind of = flexibility will be needed and it's not at all clear that a structured = cnf claim gives flexibility.=20 >=20 >=20 >=20 > On Thu, Jul 30, 2015 at 4:52 PM, John Bradley > wrote: > Token binding might be a bad example. >=20 > I can=E2=80=99t see why you would need something separate unless you = are trying to do something like message signing and token binding. =20 > I guess that is theoretically posable. >=20 > Typically I think token binding would use the normal cnf containing a = JWK with the public key. >=20 > The difference between token binding and mutual TLS is in the = presentment one is TLS client auth and the other is a signature over the = tls unique in a header. >=20 > I think multiple cnf methods for the same presenter like SAML is = overkill. >=20 > However the ability to re-use the cnf structure for people who want = something custom seems reasonable (we couldn't stop them anyway) >=20 > John B. >=20 >> On Jul 30, 2015, at 7:40 PM, Brian Campbell = > wrote: >>=20 >> Some replies inline but the gist is that I disagree.=20 >>=20 >> On Thu, Jul 30, 2015 at 2:17 PM, Mike Jones = > = wrote: >> Part of the reasoning for using a structured confirmation claim, = rather than flattening the confirmation claim into the top-level JWT = claims set, is that a JWT may carry more than one conformation key or = key descriptor, as was mentioned in Prague. For instance, imagine that = an application is conveying an application-level confirmation key using = the =E2=80=9Ccnf=E2=80=9D claim and for instance a token binding key = using a second instance of the confirmation structure, say using the = =E2=80=9Ctokbnd=E2=80=9D claim. With the current structured approach, = you=E2=80=99d have: >>=20 >> =20 >>=20 >> {=E2=80=A6 >>=20 >> =E2=80=9Ccnf=E2=80=9D:{=E2=80=9Cjwk=E2=80=9D: =E2=80=A6}, >>=20 >> =E2=80=9Ctokbnd=E2=80=9D:{=E2=80=9Cjwk=E2=80=9D: =E2=80=A6} >>=20 >> } >>=20 >> =20 >>=20 >>=20 >> That presumes token binding will use the same confirmation methods. = But I'd imagine that the Token Binding ID would somehow be used to = signal confirmation. So I'd be surprised if it ends up looking like = that. The jwe member of the cnf claim defiantly wouldn't apply.=20 >>=20 >> It also presumes that you'd want cnf and tokbnd in the same JWT, = which doesn't really make sense to me. This draft wants to establish a = registry for JWT Confirmation Methods but a token binding confirmation = would be a different claim? >>=20 >> =20 >>=20 >> If one were to flatten the structure, however, unique claim names = would have to be produced for the cross-product of each conformation = element and each confirmation claim. So you=E2=80=99d end up defining = and registering these claims in the top-level JWT Claims registry: >>=20 >> cnf_jwk >>=20 >> cnf_jwe >>=20 >> cnf_kid >>=20 >> tokbnd_jwk >>=20 >> tokbnd_jwe >>=20 >> tokbnd_kid >>=20 >> If you add other kind of confirmation keys, things would continue to = get even sillier. >>=20 >>=20 >> Again that presumes token binding will use the same confirmation = methods, which I think it unlikely. >>=20 >> I suspect it'd be more like cjwk, cjwe, ckid, and ctbd. =20 >>=20 >> And a cnf with nested structure would need a tbd or tokbnd member = defined and registered.=20 >> =20 >>=20 >> =20 >>=20 >> The code will be simpler if you can have a single shared routine for = handling confirmation structures rather a separate for handling cnf_jwk, = cnf_jwe, cnf_kid from the one for handling tokbnd_jwk, tokbnd_jwe, = tokbnd_kid, etc. >>=20 >>=20 >> You can still have a shared routine for handling things that are the = same. But with a nested structure you have to dig into the nesting. >> =20 >>=20 >> =20 >>=20 >> Another reason the structure makes things conceptually simpler is = that then you can always use the name =E2=80=9Ckid=E2=80=9D to hold a = key ID, no matter the context, rather than having to use = name-your-prefix_kid. The same holds true for other elements. >>=20 >>=20 >> I personally don't find that convincing. It depends on how someone = thinks about it.=20 >> =20 >>=20 >> =20 >>=20 >> I=E2=80=99m sorry this wasn=E2=80=99t clear in Prague. I know it was = mentioned in the context of carrying multiple confirmation keys in a = JWT, but it went by pretty fast. >>=20 >>=20 >> It was an informal discussion that was largely about something else. >> =20 >>=20 >> =20 >>=20 >> Based on the discussion in Prague, I believe that we should add = language to the spec saying that applications can define new claim names = other than =E2=80=9Ccnf=E2=80=9D to use to represent = application-specific confirmation structures that have the same syntax = as those using the =E2=80=9Ccnf=E2=80=9D name. Would that do the trick = for you? >>=20 >>=20 >> That's not at all what I'm driving at.=20 >>=20 >> If you believe that there's need for multiple confirmation structures = with the exact same syntax and meaning, I suppose that would be a useful = addition. But if you really believe that, the structure itself should = probably be adjusted to allow for multiples. I'm skeptical that it'll = ever be needed. >> =20 >>=20 >> =20 >>=20 >> By the way, I=E2=80=99m as much in favor of compactness as anyone. = Heck =E2=80=93 I was one of the folks who foisted the short claim names = like =E2=80=9Ciss=E2=80=9D on the world! But I really do believe that = in this case, having structure makes things more readable and more = flexible, especially since there will be cases where there are multiple = confirmation structures in the same JWT.=20 >>=20 >>=20 >> I can see both sides of readability. I don't see the flexibility.=20 >> =20 >> And once you prefix the names, you lose most of the space savings = anyway. >>=20 >>=20 >> Depends on how you prefix them or otherwise name things. You've = chosen long prefixes to make your point but it wouldn't have to be that = way.=20 >> =20 >>=20 >> =20 >>=20 >> Best = wishes, >>=20 >> -- = Mike >>=20 >> =20 >>=20 >> From: OAuth [mailto:oauth-bounces@ietf.org = ] On Behalf Of Brian Campbell >> Sent: Thursday, July 30, 2015 11:29 AM >> To: Nat Sakimura > >> Cc: oauth > >> Subject: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: = confirmation model in proof-of-possession-02) >>=20 >> =20 >>=20 >> Using individual claims for the different confirmation types would = convey the same information with a reduced message size, likely simpler = implementation, and avoid the need to establish a new registry.=20 >>=20 >> Seems like a no-brainer to me but maybe I'm overlooking something? =20= >>=20 >> There hasn't been much discussion that I'm aware of. Nat seemed in = favor of it (the +1 below). Mike was dismissive of it at the Dallas = meeting but didn't provide any reasoning (that I understood anyway). >>=20 >> =20 >>=20 >> =20 >>=20 >> On Mon, Mar 23, 2015 at 10:18 AM, Nat Sakimura > wrote: >>=20 >> +1 >>=20 >> =3Dnat via iPhone >>=20 >>=20 >> 2015/03/23 11:07=E3=80=81Brian Campbell > =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3= =83=BC=E3=82=B8: >>=20 >> This is mostly about section 3.4 = but also the whole draft. >>=20 >>=20 >> If "cnf" is intended to analogous to the SAML 2.0 SubjectConfirmation = element, it should probably contain an array value rather than an object = value. SAML allows not just for multiple methods of confirming but for = multiple instances of the same method. IIRC, only one confirmation needs = to be confirmable. >>=20 >> I'm not sure the extra complexity is worth it though. I've rarely, if = ever, seen SAML assertions that make use of it. >>=20 >> If the intent is just to allow for different kinds of confirmation, = couldn't the structure be pared down and simplified and just have = individual claims for the different confirmation types? Like "cjwk" and = "ckid" or similar that have the jwk or kid value respectively as the = member value. =20 >>=20 >>=20 >> =20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >> =20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 --Apple-Mail=_8CE81E7B-9142-4E8E-8E4F-0662D6F4EFC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yes the token binding token has the public key so yes you = could send the JWK thumbprint of the key in the cnf method vs sending = the JWK again to save space.  That is something we can add later as = a confirmation method.

I prefer the structured approach even if it takes another = registry.  I think it is easer to understand.  I agree that we = don=E2=80=99t want to oversell the relationship to SAML confirmation = methods. 
This is POP confirmation not the = more abstract subject confirmation (that has pop as one = option).

John = B.

On Jul 31, 2015, at 3:46 PM, Brian Campbell = <bcampbell@pingidentity.com> wrote:

The Token Binding ID already has the public key in it. A = normal cnf containing a JWK with the public key would work. But the = whole Token Binding ID would probably be simpler. Or, if we're gonna = make them parse the Token Binding ID, then a cnf that uses a = finger/thumbprint of the key would be more space efficient as the whole = key is already being sent elsewhere. That's all stuff that can be worked = out later though. What I'm trying to express is that we don't really = know what kind of flexibility will be needed and it's not at all clear = that a structured cnf claim gives flexibility.



On Thu, Jul 30, 2015 at 4:52 PM, = John Bradley <ve7jtb@ve7jtb.com> wrote:
Token binding might be a bad = example.

I can=E2=80=99= t see why you would need something separate unless you are trying to do = something like message signing and token binding.  
I guess that is theoretically posable.
Typically I think token binding would = use the normal cnf containing a JWK with the public key.

The difference between = token binding and mutual TLS is in the presentment one is TLS client = auth and the other is a signature over the tls unique in a = header.

I = think multiple cnf methods for the same presenter like SAML is = overkill.

However the ability to re-use the cnf structure for people = who want something custom seems reasonable (we couldn't stop them = anyway)

John = B.

On Jul = 30, 2015, at 7:40 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Some replies inline but the gist is that I = disagree. 

On Thu, = Jul 30, 2015 at 2:17 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Part of the reasoning for using a structured confirmation = claim, rather than flattening the confirmation claim into the top-level = JWT claims set, is that a JWT may carry more than one conformation key = or key descriptor, as was mentioned in Prague.  For instance, = imagine that an application is conveying an application-level = confirmation key using the =E2=80=9Ccnf=E2=80=9D claim and for instance = a token binding key using a second instance of the confirmation = structure, say using the =E2=80=9Ctokbnd=E2=80=9D claim.  With the = current structured approach, you=E2=80=99d have:

 

{=E2=80=A6

=E2=80=9Ccnf=E2=80=9D:{=E2=80=9Cjwk=E2=80=9D: =E2=80=A6},

=E2=80=9Ctokbnd=E2=80=9D:{=E2=80=9Cjwk=E2=80=9D: =E2=80=A6}

}

 


That presumes token binding will use the same confirmation = methods. But I'd imagine that the Token Binding ID would somehow be used = to signal confirmation. So I'd be surprised if it ends up looking like = that. The jwe member of the cnf claim defiantly wouldn't apply. 

It also presumes that you'd want cnf and tokbnd in = the same JWT, which doesn't really make sense to me. This draft wants to = establish a registry for JWT Confirmation Methods but a token binding = confirmation would be a different claim?

 

If one were to flatten the structure, however, unique claim = names would have to be produced for the cross-product of each = conformation element and each confirmation claim.  So you=E2=80=99d = end up defining and registering these claims in the top-level JWT Claims = registry:

          &nb= sp;     cnf_jwk

          &nb= sp;     cnf_jwe

          &nb= sp;     cnf_kid

          &nb= sp;     tokbnd_jwk

          &nb= sp;     tokbnd_jwe

          &nb= sp;     tokbnd_kid

If you add other kind of confirmation keys, things would = continue to get even sillier.


Again that presumes = token binding will use the same confirmation methods, which I think it = unlikely.

I suspect = it'd be more like cjwk, cjwe, ckid, and ctbd.  

And a cnf with = nested structure would need a tbd or tokbnd member defined and = registered. 
 

 

The code will be simpler if you can have a single shared = routine for handling confirmation structures rather a separate for = handling cnf_jwk, cnf_jwe, cnf_kid from the one for handling tokbnd_jwk, = tokbnd_jwe, tokbnd_kid, etc.


You can still have a = shared routine for handling things that are the same. But with a nested = structure you have to dig into the nesting.
 

 

Another reason the structure makes things conceptually = simpler is that then you can always use the name =E2=80=9Ckid=E2=80=9D = to hold a key ID, no matter the context, rather than having to use name-your-prefix_kid.  = The same holds true for other = elements.


I personally don't find that = convincing. It depends on how someone thinks about it. 
 

 

I=E2=80=99m sorry this wasn=E2=80=99t clear in Prague.  = I know it was mentioned in the context of carrying multiple confirmation = keys in a JWT, but it went by pretty = fast.


It was an informal discussion that was = largely about something else.
 

 

Based on the discussion in Prague, I believe that we should = add language to the spec saying that applications can define new claim = names other than =E2=80=9Ccnf=E2=80=9D to use to represent = application-specific confirmation structures that have the same syntax = as those using the =E2=80=9Ccnf=E2=80=9D name.  Would that do the = trick for you?


That's not at all what I'm driving = at. 

If you believe that there's need for multiple confirmation = structures with the exact same syntax and meaning, I suppose that would = be a useful addition. But if you really believe that, the structure = itself should probably be adjusted to allow for multiples. I'm skeptical = that it'll ever be needed.
 

 

By the way, I=E2=80=99m as much in favor of compactness as = anyone.  Heck =E2=80=93 I was one of the folks who foisted the = short claim names like =E2=80=9Ciss=E2=80=9D on the world!  But I = really do believe that in this case, having structure makes things more = readable and more flexible, especially since there will be cases where = there are multiple confirmation structures in the same = JWT. 


I can see both sides of readability. I = don't see the flexibility. 
 

And once you prefix the names, you lose most of the space = savings anyway.


Depends on how you prefix them or = otherwise name things. You've chosen long prefixes to make your point = but it wouldn't have to be that way. 
 

 

          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    Best wishes,

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

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian = Campbell
Sent: Thursday, July 30, 2015 11:29 AM
To: Nat Sakimura <sakimura@gmail.com>
Cc: oauth <oauth@ietf.org>
Subject: [OAUTH-WG] JWT PoP = Key Semantics WGLC followup 3 (was Re: confirmation model in = proof-of-possession-02)

 

Using = individual claims for the different confirmation types would convey the = same information with a reduced message size, likely simpler  = implementation, and avoid the need to establish a new registry. 

Seems like a = no-brainer to me but maybe I'm overlooking something?  

There hasn't been much discussion that I'm aware of. = Nat seemed in favor of it (the +1 below). Mike was dismissive of it at = the Dallas meeting but didn't provide any reasoning (that I understood = anyway).

 

 

On Mon, Mar 23, 2015 at 10:18 AM, Nat = Sakimura <sakimura@gmail.com> wrote:

+1

=3Dnat via iPhone


2015/03/23 11:07=E3=80=81Brian = Campbell <bcampbell@pingidentity.com> =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8:

This is mostly = about section 3.4 but also the = whole draft.


If "cnf" is intended to analogous to the SAML 2.0 = SubjectConfirmation element, it should probably contain an array value = rather than an object value. SAML allows not just for multiple methods = of confirming but for multiple instances of the same method. IIRC, only = one confirmation needs to be confirmable.

I'm not sure the extra complexity is worth = it though. I've rarely, if ever, seen SAML assertions that make use of = it.

If the intent is just = to allow for different kinds of confirmation, couldn't the structure be = pared down and simplified and just have individual claims for the = different confirmation types? Like "cjwk" and "ckid" or similar that = have the jwk or kid value respectively as the member value.  

 

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

 

<= /blockquote>

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


= --Apple-Mail=_8CE81E7B-9142-4E8E-8E4F-0662D6F4EFC8--
John B.
On Jul 30, 2015, at 7:48 PM, Brian Campbell = <bcampbell@pingidentity.com> wrote:

To really support that case where an initial AS/issuer wants = to bind to two presenters, shouldn't the confirmation structure itself = allow for multiple confirmation methods (i.e. be or allow for an = array)?  I don't actually think that is needed but the flexibility = that's being argued for here would suggest that rather than renaming a = nested structure that only allows for a single occurrence of each kind = of confirmation method.

On Thu, = Jul 30, 2015 at 3:14 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I agree, flattening would be a = bad direction.

In = Prague I was indicating that there may be more than one presenter for an = assertion.  The first presenter may be the OAuth client who = presents it to a RS.

That RS = itself may also present that token as a client in token exchange to get = a new access token for another resource.

The initial AS may want to bind that = token to two presenters.   The second AS doing the token exchange = also probably only wants to know about the proof key for the RS so that = it doesn=E2=80=99t mistakenly give the first client a token to directly = access a backend API.

Trying = to find a generic pattern for that is a bit of a trick though.

I think that a single = cnf element is enough for most use cases, however having cnf and cnf_rs = or some other element using the cnf structure is probably the best we = can do at this point.

John B.

On Jul = 30, 2015, at 5:17 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Part of the reasoning for using a structured confirmation = claim, rather than flattening the confirmation claim into the top-level = JWT claims set, is that a JWT may carry more than one conformation key = or key descriptor, as was mentioned in Prague.  For instance, = imagine that an application is conveying an application-level = confirmation key using the =E2=80=9Ccnf=E2=80=9D claim and for instance = a token binding key using a second instance of the confirmation = structure, say using the =E2=80=9Ctokbnd=E2=80=9D claim.  With the = current structured approach, you=E2=80=99d have:
 
{=E2=80=A6
=E2=80=9Ccnf=E2=80=9D:{=E2=80=9Cjwk=E2=80=9D: =E2=80=A6},
=E2=80=9Ctokbnd=E2=80=9D:{=E2=80=9Cjwk=E2=80=9D: =E2=80=A6}
}
 
If one were to flatten the structure, however, unique claim = names would have to be produced for the cross-product of each = conformation element and each confirmation claim.  So you=E2=80=99d = end up defining and registering these claims in the top-level JWT Claims = registry:
          &nb= sp;     cnf_jwk
          &nb= sp;     cnf_jwe
          &nb= sp;     cnf_kid
          &nb= sp;     tokbnd_jwk
          &nb= sp;     tokbnd_jwe
          &nb= sp;     tokbnd_kid
If you add other kind of confirmation keys, things would = continue to get even sillier.
 
The code will be simpler if you can have a single shared = routine for handling confirmation structures rather a separate for = handling cnf_jwk, cnf_jwe, cnf_kid from the one for handling tokbnd_jwk, = tokbnd_jwe, tokbnd_kid, etc.
 
Another reason the structure makes things conceptually = simpler is that then you can always use the name =E2=80=9Ckid=E2=80=9D = to hold a key ID, no matter the context, rather than having to use name-your-prefix_kid.  = The same holds true for other elements.
 
I=E2=80=99m sorry this wasn=E2=80=99t clear in Prague.  = I know it was mentioned in the context of carrying multiple confirmation = keys in a JWT, but it went by pretty fast.
 
Based on the discussion in Prague, I believe that we should = add language to the spec saying that applications can define new claim = names other than =E2=80=9Ccnf=E2=80=9D to use to represent = application-specific confirmation structures that have the same syntax = as those using the =E2=80=9Ccnf=E2=80=9D name.  Would that do the = trick for you?
 
By the way, I=E2=80=99m as much in favor of compactness as = anyone.  Heck =E2=80=93 I was one of the folks who foisted the = short claim names like =E2=80=9Ciss=E2=80=9D on the world!  But I = really do believe that in this case, having structure makes things more = readable and more flexible, especially since there will be cases where = there are multiple confirmation structures in the same JWT.  And = once you prefix the names, you lose most of the space savings anyway.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    Best wishes,
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    -- Mike
 
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, July 30, = 2015 11:29 AM
To: Nat Sakimura <sakimura@gmail.com>
Cc: oauth <oauth@ietf.org>
Subject: [OAUTH-WG] JWT PoP = Key Semantics WGLC followup 3 (was Re: confirmation model in = proof-of-possession-02)
 

Using = individual claims for the different confirmation types would convey the = same information with a reduced message size, likely simpler  = implementation, and avoid the need to establish a new registry. 

Seems like a = no-brainer to me but maybe I'm overlooking something?  

There hasn't been much discussion that I'm = aware of. Nat seemed in favor of it (the +1 below). Mike was dismissive = of it at the Dallas meeting but didn't provide any reasoning (that I = understood anyway).
 
 
On Mon, Mar 23, 2015 at 10:18 AM, Nat Sakimura = <sakimura@gmail.com> wrote:
+1

=3Dnat via iPhone


2015/03/23 11:07=E3=80=81Brian Campbell <bcampbell@pingidentity.com> =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8:

This is mostly about section 3.4 but also the = whole draft.


If= "cnf" is intended to analogous to the SAML 2.0 SubjectConfirmation = element, it should probably contain an array value rather than an object = value. SAML allows not just for multiple methods of confirming but for = multiple instances of the same method. IIRC, only one confirmation needs = to be confirmable.

I'm not sure = the extra complexity is worth it though. I've rarely, if ever, seen SAML = assertions that make use of it.

If the intent is just to allow for different kinds of = confirmation, couldn't the structure be pared down and simplified and = just have individual claims for the different confirmation types? Like = "cjwk" and "ckid" or similar that have the jwk or kid value respectively = as the member value.  

 

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