From nobody Mon May 1 15:31:47 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D905F12EAAB for ; Mon, 1 May 2017 15:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBjY87kaoIUQ for ; Mon, 1 May 2017 15:31:41 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D66C912EAA9 for ; Mon, 1 May 2017 15:29:05 -0700 (PDT) X-AuditID: 12074423-71fff70000004ca2-eb-5907b6b0580b Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 0D.53.19618.0B6B7095; Mon, 1 May 2017 18:29:04 -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 v41MT3f9027952; Mon, 1 May 2017 18:29:04 -0400 Received: from [100.110.147.91] ([104.132.1.107]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v41MSx87020706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 May 2017 18:29:02 -0400 From: Justin Richer Message-Id: <1406FF29-7E40-4B80-AF0E-CE857081C196@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_26BB7FD1-B1BE-4397-86C0-402F5B803E1A" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 1 May 2017 15:28:58 -0700 In-Reply-To: Cc: William Denniss , "" To: Samuel Erdtman References: <95776354-79e3-caa7-ba60-84cfec7f899f@gmx.net> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBKsWRmVeSWpSXmKPExsUixG6nrrthG3ukwa52FYuTb1+xWfxfeorJ YtOcZnYHZo8X//YweizYVOqxZMlPpgDmKC6blNSczLLUIn27BK6MB0smsBesm8FYcf9/bgPj jg7GLkZODgkBE4nX566ydTFycQgJtDFJ/G7oZIJwNjBKNN++yA7hrGWSuDF1NgtIC5uAqsT0 NS1MIDavgJVE88S77CA2s0CSxM/rl4DGcgDF9SV6n4NtEBYIkjjeeBisnEVAReLBv01gNqdA oMTXb1tYIFr9JNZtWMsMYosIqEncPfiIFWJvP7PEjpPn2CBOlZW4NfsS8wRG/llI1s1CWAcR 1pZYtvA1M4StKbG/ezkLpriGROe3iawLGNlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Zrp5WaW 6KWmlG5iBAe7i/IOxpd93ocYBTgYlXh4VxizRwqxJpYVV+YeYpTkYFIS5RV7xxYpxJeUn1KZ kVicEV9UmpNafIhRgoNZSYTXcSZQOW9KYmVValE+TEqag0VJnFdcozFCSCA9sSQ1OzW1ILUI JivDwaEkwXtuK1CjYFFqempFWmZOCUKaiYMTZDgP0PDvIDW8xQWJucWZ6RD5U4zWHFdaP75n 4mjb8vs9kxBLXn5eqpQ475wtQKUCIKUZpXlw00AJKyVvcjSIzmhhzH7FKA70pDDvJ5DBPMDk Bzf3FdBKJqCV9WosICtLEhFSUg2MPh9eyydoVGvdOp02kWP1te7sBZ2VIu9TTyb9sUkUXZG5 4rLShASFrZFGrSX9m+8FtGsekz7x8cmdR/rlMtq/hSrcI77veRW4Jm32tZXeG49dNSiYdXmT x/+5sn7paUsf7Yy9+Nnwy1+WZ7tNtO79j1vjdnmX+Z3C6ixGc61b05a0bQ5W1FyhoMRSnJFo qMVcVJwIAMkd6zg7AwAA Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: Mutual TLS Profiles for OAuth Clients X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 22:31:46 -0000 --Apple-Mail=_26BB7FD1-B1BE-4397-86C0-402F5B803E1A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I support this draft as a starting point for this work.=20 A context on my perspective: several years ago, I worked on a project = that looked toward this kind of functionality being standardized in the = future. See section 6.1 of this document published in 2015 (written in = 2014). = http://secure-restful-interface-profile.github.io/pages/docs/profiles/Secu= re%20RESTful%20Interface%20Profiles%20for%20OAuth%202%20v1.4.docx = =E2=80=94 Justin > On Apr 25, 2017, at 12:45 PM, Samuel Erdtman = wrote: >=20 > +1 for adoption >=20 > On Mon, Apr 24, 2017 at 9:02 AM, William Denniss > wrote: > I support the adoption of this draft by the working group. >=20 >=20 > On Sun, Apr 23, 2017 at 9:11 AM, Torsten Lodderstedt = > wrote: > +1 for adoption >=20 >> Am 21.04.2017 um 21:43 schrieb Nat Sakimura >: >>=20 >> +1 for adoption >>=20 >> On Apr 21, 2017 9:32 PM, "Dave Tonge" > wrote: >> I support adoption of draft-campbell-oauth-mtls >>=20 >> As previously mentioned this spec will be very useful for Europe = where there is legislation requiring the use of certificate-based = authentication and many financial groups and institutions are = considering OAuth2. >> =20 >> The UK Open Banking Implementation Entity has a strong interest in = using this spec. >>=20 >> Dave >>=20 >> On 20 April 2017 at 17:32, Hannes Tschofenig = > wrote: >> Hi all, >>=20 >> based on the strong support for this document at the Chicago IETF >> meeting we are issuing a call for adoption of the "Mutual TLS = Profiles >> for OAuth Clients" document, see >> https://tools.ietf.org/html/draft-campbell-oauth-mtls-01 = >>=20 >> Please let us know by May 4th whether you accept / object to the >> adoption of this document as a starting point for work in the OAuth >> working group. >>=20 >> Ciao >> Hannes & Rifaat >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >>=20 >>=20 >> --=20 >> Dave Tonge >> CTO >> = >> 10 Temple Back, Bristol, BS1 6FL >> t: +44 (0)117 280 5120 >>=20 >> Moneyhub Enterprise is a trading style of Momentum Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Momentum Financial Technology is entered on = the Financial Services Register (FRN 561538) at fca.org.uk/register = . Momentum Financial Technology is = registered in England & Wales, company registration number 06909772 =C2=A9= . Momentum Financial Technology Limited 2016. DISCLAIMER: This email = (including any attachments) is subject to copyright, and the information = in it is confidential. Use of this email or of any information in it = other than by the addressee is unauthorised and unlawful. Whilst = reasonable efforts are made to ensure that any attachments are = virus-free, it is the recipient's sole responsibility to scan all = attachments for viruses. All calls and emails to and from this company = may be monitored and recorded for legitimate purposes relating to this = company's business. Any opinions expressed in this email (or in any = attachments) are those of the author and do not necessarily represent = the opinions of Momentum Financial Technology Limited or of any other = group company. >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=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=_26BB7FD1-B1BE-4397-86C0-402F5B803E1A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I support this draft as a starting point for this = work. 

A = context on my perspective: several years ago, I worked on a project that = looked toward this kind of functionality being standardized in the = future. See section 6.1 of this document published in 2015 (written in = 2014).

http://secure-restful-interface-profile.github.io/pages/docs/pr= ofiles/Secure%20RESTful%20Interface%20Profiles%20for%20OAuth%202%20v1.4.do= cx

 =E2= =80=94 Justin

On = Apr 25, 2017, at 12:45 PM, Samuel Erdtman <samuel@erdtman.se> = wrote:

+1 for adoption

On Mon, = Apr 24, 2017 at 9:02 AM, William Denniss <wdenniss@google.com> wrote:
I support the = adoption of this draft by the working group.


On Sun, Apr 23, 2017 at 9:11 AM, Torsten = Lodderstedt <torsten@lodderstedt.net> wrote:
+1 for adoption

Am 21.04.2017 um 21:43 schrieb Nat Sakimura = <sakimura@gmail.com>:

+1= for adoption

On Apr 21, 2017 9:32 PM, "Dave Tonge" <dave.tonge@momentumft.co.uk> wrote:
I = support adoption of draft-campbell-oauth-mtls

As = previously mentioned this spec will be very useful for Europe where = there is legislation requiring the use of certificate-based = authentication and many financial groups and institutions are = considering OAuth2.
 
The = UK Open Banking Implementation Entity has a strong interest in = using this spec.

Dave

On 20 April 2017 at 17:32, Hannes = Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

based on the strong support for this document at the Chicago IETF
meeting we are issuing a call for adoption of the "Mutual TLS = Profiles
for OAuth Clients" document, see
https://tools.ietf.org/html/draft-campbell-oauth-mtls-01

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

Ciao
Hannes & Rifaat


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




--
Dave Tonge
CTO
3D"Moneyhub
10 Temple Back, Bristol, BS1 6FL
t: +44 (0)117 280 5120

Moneyhub Enterprise is a trading = style of Momentum Financial Technology Limited which is authorised and = regulated by the Financial Conduct Authority ("FCA"). Momentum = Financial Technology is entered on the Financial Services = Register (FRN 561538) at = fca.org.uk/register. Momentum Financial Technology is = registered in England & Wales, company registration = number 06909772 =C2=A9<= span style=3D"font-size:0.75em;background-color:transparent" = class=3D""> . Momentum Financial Technology Limited 2016. DISCLAIMER: This email (including any attachments) is = subject to copyright, and the information in it is confidential. Use of = this email or of any information in it other than by the addressee is = unauthorised and unlawful. Whilst reasonable efforts are made to ensure = that any attachments are virus-free, it is the recipient's sole = responsibility to scan all attachments for viruses. All calls and emails = to and from this company may be monitored and recorded for legitimate = purposes relating to this company's business. Any opinions expressed in = this email (or in any attachments) are those of the author and do not = necessarily represent the opinions of Momentum Financial Technology = Limited or of any other group = company.

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

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


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



_______________________________________________
OAuth mailing 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=_26BB7FD1-B1BE-4397-86C0-402F5B803E1A-- From nobody Mon May 1 22:35:14 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717F5126B7F for ; Mon, 1 May 2017 22:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.221 X-Spam-Level: X-Spam-Status: No, score=-0.221 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhasu6WErl-E for ; Mon, 1 May 2017 22:35:08 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.25]) (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 CB4E7128B88 for ; Mon, 1 May 2017 22:32:50 -0700 (PDT) Received: from [80.187.107.84] (helo=[10.155.141.93]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1d5QQZ-0007DW-00; Tue, 02 May 2017 07:32:47 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-5B14A1E0-B12E-4243-BBF1-7129B13D8D98; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPhone Mail (14E304) In-Reply-To: <22d06952-94ab-e6a9-d2b2-f96f8252bf5e@mit.edu> Date: Tue, 2 May 2017 07:32:42 +0200 Cc: John Bradley , William Denniss , "oauth@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <4107AB98-25D8-4542-B932-CD6F921D0D1D@lodderstedt.net> References: <77856AF4-9B2E-4478-9509-1459037C24E4@ve7jtb.com> <22d06952-94ab-e6a9-d2b2-f96f8252bf5e@mit.edu> To: Justin Richer X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Device Flow: IETF98 Follow-up X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 05:35:11 -0000 --Apple-Mail-5B14A1E0-B12E-4243-BBF1-7129B13D8D98 Content-Type: multipart/alternative; boundary=Apple-Mail-D85031C7-97EB-4E48-BC38-97F862D46BCA Content-Transfer-Encoding: 7bit --Apple-Mail-D85031C7-97EB-4E48-BC38-97F862D46BCA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 to keep the optional parameter along with clear wording regarding securit= y risk and interoperability=20 > Am 29.04.2017 um 15:12 schrieb Justin Richer : >=20 > +1, documentation is better. Though we also need to keep in mind that this= was the justification for the password flow in 6749, which has been abused a= ll over the place (and continues to this day). Still, it would be arguably w= orse without that so I'm good with keeping the parameter in there as long as= we're careful. > Namely: So long as the user code is *also* delivered separately to the use= r, we would have interoperability between the two. What I don't think w= e want is some systems that *require* the URI parameter on the approval URL a= nd other implementations that *forbid* it. That case could end up with somet= hing like: I've got a set-top system that's incapable of displaying a separa= te user code because it always assumes it's baked into the URL, and then I t= ry to put it on a server that requires the code be entered separately.=20 > The resulting spec needs to be clear that the box MUST be able to display b= oth the URL and the code separately, in case the URL does not include the co= de. In fact, maybe we'd even want to introduce a new parameter from the endp= oint for the pre-composed URL: >=20 > user_code > REQUIRED. The end-user verification code. >=20 > verification_uri > REQUIRED. The end-user verification URI on the authorization > server. The URI should be short and easy to remember as end- > users will be asked to manually type it into their user-agent. > composite_verification_uri > OPTIONAL. The end-user verification URI with the end-user=20 > verification code already included. See discussion in [blah] > for its use. >=20 > -- Justin >=20 >> On 4/28/2017 6:38 PM, John Bradley wrote: >> I would like to keep the optional parameter. It is useful enough that i= f we don=E2=80=99t have it people will add it on there own as a custom param= eter. =20 >> Better to document any issues.=20 >>=20 >> John B. >>> On Apr 28, 2017, at 5:39 PM, William Denniss wrote= : >>>=20 >>> Thanks all who joined us in Chicago in person and remotely last month fo= r the discussion on the device flow. [recording here, presentation starts at= about 7min in]. =20 >>>=20 >>> The most contentious topic was addition of the user_code URI param exten= sion (introduced in version 05, documented in Section 3.3). >>>=20 >>> I'd like to close out that discussion with a decision soon so we can adv= ance to a WG last call on the draft. >>>=20 >>> To summarise my thoughts on the param: >>> It can be can be used to improve usability =E2=80=93 QR codes and NFC ca= n be used with this feature to create a more delightful user authorization e= xperience. >>> It may increase the potential phishing risk (which= we can document), as the user has less typing. This risk assessment is like= ly not one-size-fits-all, it may vary widely due to different the different p= otential applications of this standard. >>> The way it's worded makes it completely optional, leaving it up to the d= iscretion of the authorization server on whether to offer the optimisation, a= llowing them to secure it as best they see it. >>> I do believe it is possible to design a secure user experiance that incl= udes this optimization. >>> I think on the balance, it's worthwhile feature to include, and one that= benefits interop. The authorization server has complete control over whethe= r to enable this feature =E2=80=93 as Justin pointed out in the meeting, it d= egrades really nicely =E2=80=93 and should they enable it, they have control= over the user experiance and can add whatever phishing mitigations their us= e-case warrants. Rarely is there a one-size-fits-all risk profile, use-case= s of this flow range widely from mass-market TV apps to internal-only device= bootstrapping by employees, so I don't think we should be overly prescripti= ve. >>>=20 >>> Mitigating phishing is already something that is in the domain of the au= thorization server with OAuth generally, and I know that this is an extremel= y important consideration when designing user authorization flows. This spec= will be no exception to that, with or without this optimization. >>>=20 >>> That's my opinion. I'm keen to continue the discussion from Chicago and r= each rough consensus so we can progress forward. >>>=20 >>> Best, >>> William >>>=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-D85031C7-97EB-4E48-BC38-97F862D46BCA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1 to keep the optional par= ameter along with clear wording regarding security risk and interoperability=  

Am 29.04.2017 um 15:12 schrieb Justin Richer <jricher@mit.edu>:

=20 =20 =20

+1, documentation is better. Though we also need to keep in mind that this was the justification for the password flow in 6749, which has been abused all over the place (and continues to this day). Still, it would be arguably worse without that so I'm good with keeping the parameter in there as long as we're careful.

Namely: So long as the user code is *also* delivered separately to the user, we would have interoperability between the two. What I don't think we want is some systems that *require* the URI parameter on the approval URL and other implementations that *forbid* it. That case could end up with something like: I've got a set-top system that's incapable of displaying a separate user code because it always assumes it's baked into the URL, and then I try to put it on a server that requires the code be entered separately.

The resulting spec needs to be clear that the box MUST be able to display both the URL and the code separately, in case the URL does not include the code. In fact, maybe we'd even want to introduce a new parameter from the endpoint for the pre-composed URL:

   user_code
      REQUIRED.  The end-user verification code.

   verification_uri
      REQUIRED.  The end-user verification URI on the authorization
      server.  The URI should be short and easy to remember as end-
      users will be asked to manually type it into their user-agent.

   composite_verification_uri
      OPTIONAL.  The end-user verification URI with the end-user=20
      verification code already included. See discussion in [blah]
      for its use.

 -- Justin
On 4/28/2017 6:38 PM, John Bradley wrote:
I would like to keep the optional parameter.   It is useful enoug= h that if we don=E2=80=99t have it people will add it on there own as a custom parameter.  
Better to document any issues. 

John B.
On Apr 28, 2017, at 5:39 PM, William Denniss <wdenniss@google.com> wrote:

Thanks all who joined us in Chicago in person and remotely last month for the discussion on the device flow. [recording here, presentation starts at about 7min in].

The most contentious topic was addition of the user_code URI param extension (introduced in version 05, documented in Section 3.3).

I'd like to close out that discussion with a decision soon so we can advance to a WG last call on the draft.

To summarise my thoughts on the param:
=
  1. It can be can be used to improve usability =E2=80=93 QR codes and NFC can be used with t= his feature to create a more delightful user authorization experience.
  2. It may increase the potential phishing risk (which we can document), as the user has less typing. This risk assessment is likely not one-size-fits-all, it may vary widely due to different the different potential applications of this standard.
  3. The way it's worded makes it completely optional, leaving it up to the discretion of the authorization server on whether to offer the optimisation, allowing them to secure it as best they see it.
  4. I do believe it is possible to design a secure user experiance that includes this optimization.
I think on the balance, it's worthwhile feature to include, and one that benefits interop. The authorization server has complete control over whether to enable this feature =E2=80=93 as Justin point= ed out in the meeting, it degrades really nicely =E2=80=93 a= nd should they enable it, they have control over the user experiance and can add whatever phishing mitigations their use-case warrants.  Rarely is there a one-size-fits-all risk profile, use-cases of this flow range widely from mass-market TV apps to internal-only device bootstrapping by employees, so I don't think we should be overly prescriptive.

Mitigating phishing is already something that is in the domain of the authorization server with OAuth generally, and I know that this is an extremely important consideration when designing user authorization flows. This spec will be no exception to that, with or without this optimization.

That's my opinion. I'm keen to continue the discussion from Chicago and reach rough consensus so we can progress forward.

Best,
William




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

=20
____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-D85031C7-97EB-4E48-BC38-97F862D46BCA-- --Apple-Mail-5B14A1E0-B12E-4243-BBF1-7129B13D8D98 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSTCCBUUw ggQtoAMCAQICEDPbmsaqwjeZa3PxA3uZ8LQwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNzAxMDkwMDAwMDBaFw0xODAxMDkyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEArsGSzZyz9Lq9SRW9Sve5K8n5lWhplOCE6HH3gMye12DjOpkF FZt0b73t27G17Xsp6WUxHhNevf7ck0AUpvYUPCHBqVGJSIWF9hWAoSFCgQACOoh/cDFbzz1PsMY8 El7OmIus4JXtY4/VdoSIhFP3hzATbNAg32Kp+N8vtTuKTwbgnizJSyzZTYrsttn3LmwY17HU+U9v XloMus5U/ln4ADZx0zyyDSsA6gtPxXYJpbgSTnHckVZ5zfR80guIZ538Y2qqsqt5VaSRSR2oQzE/ HETkKc/odPVhqBrXLyvnSFkCPrAXV07rcvwkPvHZeYVu4QdVWyO2HIQ4i2x9r5m7SwIDAQABo4IB 9TCCAfEwHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFPngHgVxOZ7G Sji/IW4YJMBj02PHMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEE AbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwXQYD VR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50 QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAwWAYI KwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhl bnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNv bW9kb2NhLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0B AQsFAAOCAQEAAmueyHjiyL1qYgfe+hVSsGuKlgcvjCAfG8Jaq48tC0IjP8pH/tGi4uL9CHVfLnV3 pLDnjg6M2uvpEBp7crZZcnSPLeVss+tkhwv+F7ISYQyT4flNkqVUb8nfewbCPcIN13ObfpU7rlXo IarEEplQo4SuymYVluQxTLOFKm5QOMF4JBMw/rjy4t95J7Mdp9NFUzQrKPJDaJ2Jr/TcTXFcjLvN VmMBjK0959a9v1/1miRHd1DBsTh1KvBigEOUNMxvT5uUtB6/tioDZqBDDk8Gvdno/xmye3YiasS7 JgMREq5WcXqpWGu5kMFZMGPEvyPHeBZeqxx3amf4ImVnZ6WvgzGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDPbmsaqwjeZa3PxA3uZ8LQw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTcwNTAyMDUzMjQyWjAjBgkqhkiG9w0BCQQxFgQUuDE02chcD1M1SEMNck8GOsjap04wgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAz25rGqsI3mWtz8QN7mfC0MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEB AQUABIIBAGdpCGvskyV0+VQHEZlpCjVwnKgFGD+kc66E4k9aQvtyMaGtc8TzFyqwpTUf4c5jmJjq Vgqa2sCX/JHFmL7SJTQdZQQRJ4N6Qf0YepzJB5xBHvWyPU0NaDKyH/rFuOyHx5hKuB8kkaKq7r83 irad+ZzxHX+zFsF7AEvYtP7GpuJsWO4tFyY2RbrZK6NBKZukLRfoJUPtdei6WMaEzhPhrWea+K+U hEKmQvCFTFhWFaQO2isO6fx7cTK2TNreMXTJSo4S1q8OaTe4f7AR8dwqSzf8ShIuowe34rYpSnFu evmYveKHcJvIJVYjE0r9XVmStSQEUNxjUTFlo/J4rtdKJOMAAAAAAAA= --Apple-Mail-5B14A1E0-B12E-4243-BBF1-7129B13D8D98-- From nobody Mon May 1 23:01:10 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC47D1205F0 for ; Mon, 1 May 2017 23:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4L8eQLbAYkuB for ; Mon, 1 May 2017 23:01:05 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30E76127342 for ; Mon, 1 May 2017 22:58:13 -0700 (PDT) Received: from [80.187.107.84] (helo=[10.155.141.93]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1d5Qp8-0005Fd-T6; Tue, 02 May 2017 07:58:11 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-D54B4173-FCD8-4B6F-9A2D-D8EA1A0E1256; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPhone Mail (14E304) In-Reply-To: <7F32DADA-E665-4C1A-BD7F-244C63CE0F2C@manicode.com> Date: Tue, 2 May 2017 07:58:09 +0200 Cc: "oauth@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: <269DD0EC-FCBF-4691-9BAA-2B8F144C0353@lodderstedt.net> <3A9170DD-0861-478D-A9DD-9A55DC930B8D@ve7jtb.com> <4ACE4772-E01B-4D9A-8AED-7926B9E87615@lodderstedt.net> <7F32DADA-E665-4C1A-BD7F-244C63CE0F2C@manicode.com> To: Jim Manico X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Second OAuth Security Workshop (Call for Papers) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 06:01:09 -0000 --Apple-Mail-D54B4173-FCD8-4B6F-9A2D-D8EA1A0E1256 Content-Type: multipart/alternative; boundary=Apple-Mail-6016C175-78AD-45BB-A1A9-DD74397B558F Content-Transfer-Encoding: 7bit --Apple-Mail-6016C175-78AD-45BB-A1A9-DD74397B558F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Jim, unfortunately, it is not possible to offer remote access to this workshop. W= hy don't you come to Europe? You could also attend the IETF meeting in Pragu= e. best regards, Torsten. > Am 21.04.2017 um 07:17 schrieb Jim Manico : >=20 > I'd love to attend. >=20 > 1) Can you handle remote participants? > 2) Any chance you want to move this to Hawaii? I can host the work space. S= eriously. >=20 > Aloha, > -- > Jim Manico > @Manicode >=20 >> On Apr 20, 2017, at 7:42 PM, Torsten Lodderstedt wrote: >>=20 >> Hi all, >>=20 >> I'm pleased to announce the hosts managed to change the date of the secur= ity workshop to the end of the week before IETF-99, July 13-14.=20 >>=20 >> Please find the updated CfP below. >>=20 >> kind regards, >> Torsten. >>=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >>=20 >> C a l l F o r P a p e r s >>=20 >> Second OAuth Security Workshop (OSW 2017) >>=20 >> Zurich, Switzerland -- July 13-14, 2017 (note the changed event date) >>=20 >> WWW: https://zisc.ethz.ch/oauth-security-workshop-2017-cfp/ >>=20 >> Position paper submission deadline: May 2, 2017 (AoE, UTC-12). >>=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >>=20 >> Overview >>=20 >> The OAuth Security Workshop (OSW) focuses on improving security of the >> OAuth standard and related Internet protocols. This workshop brings >> together the IETF OAuth Working Group and security experts from >> research, industry, and standardization to this end. The workshop is >> hosted by the Zurich Information Security and Privacy Center at ETH Zuric= h. >>=20 >> While the standardization process of OAuth ensures extensive reviews >> (both security and non-security related), further analysis by security >> experts from academia and industry is essential to ensure high quality >> specifications. Contributions to this workshop can help to improve the >> security of the Web and the Internet. >>=20 >>=20 >> Scope >>=20 >> We seek position papers related to the security of OAuth, OpenID >> Connect, and other technologies using OAuth under the hood. >> Contributions regarding technologies that are used in OAuth, such as >> JOSE, or impact the security of OAuth, such as Web technology, are also >> welcome. >>=20 >>=20 >> Important Dates >>=20 >> Position paper submission deadline: May 2, 2017 (AoE, UTC-12). >> Author notification: May 15, 2017. >> Registration deadline: June 16, 2017. >> Workshop: July 13 and July 14, 2017. >>=20 >>=20 >> Invited Speakers >>=20 >> Cas Cremers, University of Oxford >>=20 >>=20 >> Submission >>=20 >> We welcome position papers that describe existing work, raise new >> requirements, highlight challenges, write-ups of implementation and >> deployment experience, lessons-learned from successful or failed >> attempts, and ideas on how to improve OAuth and OAuth extensions. >>=20 >> Position papers submitted to the OAuth Security Workshop may report on >> (unpublished) work in progress, be submitted to other places, and may >> even have already appeared or been accepted elsewhere. >>=20 >> Submissions must be in PDF format and should feature reasonable margins >> and formatting. There is no page limit, but the submission should be >> brief (ideally not more than 3-5 pages). Submissions should not be >> anonymized. >>=20 >> Submission Website: https://easychair.org/conferences/?conf=3Dosw17 >>=20 >>=20 >> Publication and Presentation >>=20 >> One of the authors of the accepted position paper is expected to present >> the paper at the workshop. >>=20 >> All presentations and papers will be put online but there will be no >> formal proceedings. Authors of accepted papers will have the option to >> revise their papers before they are put online. >>=20 >>=20 >> IPR Policy >>=20 >> The workshop will have no expectation of IPR disclosure or licensing >> related to its submissions. Authors are responsible for obtaining >> appropriate publication clearances. >>=20 >>=20 >> Program Committee >>=20 >> Chairs >> David Basin (ETH Zurich) >> Torsten Lodderstedt (YES Europe) >>=20 >> Members >> John Bradley (Ping Identity) >> Ralf K=C3=BCsters (University of Stuttgart) >> Chris Mitchell (Royal Holloway University of London) >> Anthony Nadalin (Microsoft) >> Nat Sakimura (Nomura Research Institute) >> Ralf Sasse (ETH Zurich) >> J=C3=B6rg Schwenk (Ruhr University Bochum) >> Hannes Tschofenig (IETF OAuth Working Group Co-Chair) >>=20 >>> Am 13.03.2017 um 21:01 schrieb John Bradley : >>>=20 >>> I did point out earlier when I discovered the dates, that I similarly as= ked for it to be later in the week. >>> It is probably fine for Europeans but it will stop many people from bein= g able to attend including myself unless I can come up with other meetings i= n Europe to fill those days. >>>=20 >>> If we cant move it then we will have to live with it and attend or not. >>>=20 >>> John B. >>>=20 >>>> On Mar 13, 2017, at 4:46 PM, Torsten Lodderstedt wrote: >>>>=20 >>>> Hi Mike, >>>>=20 >>>> yes, those are the right dates. There are restrictions from the host's s= ide, that=E2=80=99s why the workshop needs to take place on Monday and Tuesd= ay. As far as I remember the host was clear about that from the beginning.=20= >>>>=20 >>>> best regards, >>>> Torsten. >>>>=20 >>>>> Am 12.03.2017 um 22:15 schrieb Mike Jones : >>>>>=20 >>>>> Are Monday-Tuesday, July 10-11 really the right dates? I'm asking bec= ause IETF in Prague doesn't start until Sunday, July 16th. That leaves 4 da= ys dead time in between for those of us who are attending both. >>>>>=20 >>>>> When I was first told about this workshop, I was told that it would be= sometime Wednesday-Friday that week. Can it be moved back to those dates? = That would be a big help for those of us travelling distances to attend. >>>>>=20 >>>>> Or is there also another event in the Wednesday-Friday timeframe that p= eople should also be considering attending? >>>>>=20 >>>>> Thanks, >>>>> -- Mike >>>>>=20 >>>>> -----Original Message----- >>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten Lodde= rstedt >>>>> Sent: Sunday, March 12, 2017 12:28 PM >>>>> To: oauth@ietf.org >>>>> Subject: [OAUTH-WG] Second OAuth Security Workshop (Call for Papers) >>>>>=20 >>>>> Hi all, >>>>>=20 >>>>> the OAuth WG and the ETH Zurich will organize another workshop on OAut= h security (after the one last year in Trier). >>>>>=20 >>>>> Please find the Call for Papers below. >>>>>=20 >>>>> kind regards, >>>>> Torsten. >>>>>=20 >>>>> C a l l F o r P a p e r s >>>>>=20 >>>>> Second OAuth Security Workshop (OSW 2017) >>>>>=20 >>>>> Zurich, Switzerland -- July 10-11, 2017 >>>>>=20 >>>>> WWW:https://zisc.ethz.ch/oauth-security-workshop-2017-cfp/ >>>>>=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=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>>=20 >>>>> Overview >>>>>=20 >>>>> The OAuth Security Workshop (OSW) focuses on improving security of the= OAuth standard and related Internet protocols. This workshop brings togethe= r the IETF OAuth Working Group and security experts from research, industry,= and standardization to this end. The workshop is hosted by the Zurich Infor= mation Security and Privacy Center at ETH Zurich. >>>>>=20 >>>>> While the standardization process of OAuth ensures extensive reviews (= both security and non-security related), further analysis by security expert= s from academia and industry is essential to ensure high quality specificati= ons. Contributions to this workshop can help to improve the security of the W= eb and the Internet. >>>>>=20 >>>>>=20 >>>>> Scope >>>>>=20 >>>>> We seek position papers related to the security of OAuth, OpenID Conne= ct, and other technologies using OAuth under the hood. >>>>> Contributions regarding technologies that are used in OAuth, such as J= OSE, or impact the security of OAuth, such as Web technology, are also welco= me. >>>>>=20 >>>>>=20 >>>>> Important Dates >>>>>=20 >>>>> Position paper submission deadline: May 2, 2017 (AoE, UTC-12). >>>>> Author notification: May 15, 2017. >>>>> Registration deadline: June 16, 2017. >>>>> Workshop: July 10 and July 11, 2017. >>>>>=20 >>>>>=20 >>>>> Invited Speakers >>>>>=20 >>>>> Cas Cremers, University of Oxford >>>>>=20 >>>>>=20 >>>>> Submission >>>>>=20 >>>>> We welcome position papers that describe existing work, raise new requ= irements, highlight challenges, write-ups of implementation and deployment e= xperience, lessons-learned from successful or failed attempts, and ideas on h= ow to improve OAuth and OAuth extensions. >>>>>=20 >>>>> Position papers submitted to the OAuth Security Workshop may report on= >>>>> (unpublished) work in progress, be submitted to other places, and may e= ven have already appeared or been accepted elsewhere. >>>>>=20 >>>>> Submissions must be in PDF format and should feature reasonable margin= s and formatting. There is no page limit, but the submission should be brief= (ideally not more than 3-5 pages). Submissions should not be anonymized. >>>>>=20 >>>>> Submission Website:https://easychair.org/conferences/?conf=3Dosw17 >>>>>=20 >>>>>=20 >>>>> Publication and Presentation >>>>>=20 >>>>> One of the authors of the accepted position paper is expected to prese= nt the paper at the workshop. >>>>>=20 >>>>> All presentations and papers will be put online but there will be no f= ormal proceedings. Authors of accepted papers will have the option to revise= their papers before they are put online. >>>>>=20 >>>>>=20 >>>>> IPR Policy >>>>>=20 >>>>> The workshop will have no expectation of IPR disclosure or licensing r= elated to its submissions. Authors are responsible for obtaining appropriate= publication clearances. >>>>>=20 >>>>>=20 >>>>> Program Committee >>>>>=20 >>>>> Chairs >>>>> David Basin (ETH Zurich) >>>>> Torsten Lodderstedt (YES Europe) >>>>>=20 >>>>> Members >>>>> John Bradley (Ping Identity) >>>>> Ralf K=C3=BCsters (University of Stuttgart) >>>>> Chris Mitchell (Royal Holloway University of London) Anthony Nadalin (= Microsoft) Nat Sakimura (Nomura Research Institute) Ralf Sasse (ETH Zurich) J= =C3=B6rg Schwenk (Ruhr University Bochum) Hannes Tschofenig (IETF OAuth Work= ing Group Co-Chair) >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-6016C175-78AD-45BB-A1A9-DD74397B558F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Jim,

unfortunately, it is not possible to offer remote access to this works= hop. Why don't you come to Europe? You could also attend the IETF meeting in= Prague.

best regards,
Torsten.

Am 21.04.2017 um 07:17 schrieb Jim Manico <jim@manicode.com>:

=
I'd love to attend.

1) Can you handle remote participants?
2) Any chance you want to move this to Hawaii? I c= an host the work space. Seriously.

<= /div>
Aloha,
--
Jim Manico
@Manicode

On A= pr 20, 2017, at 7:42 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi all,

I'm pleased to announce the hosts managed to change the date of the secur= ity workshop to the end of the week before IETF-99, July 13-14. 
<= div class=3D"">
Please find the updated C= fP below.

kind reg= ards,
Torsten.

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

C a l l    = ; F o r     P a p e r s

Second OAuth Security Workshop (OSW 2017)

Zur= ich, Switzerland -- July 13-14, 2017 (note the changed event date)

WWW: https://zisc.ethz.ch/oauth-security-workshop-2= 017-cfp/

Position paper submission deadline= : May 2, 2017 (AoE, UTC-12).

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

Overview

The OAuth Security Wo= rkshop (OSW) focuses on improving security of the
OAuth standa= rd and related Internet protocols. This workshop brings
togeth= er the IETF OAuth Working Group and security experts from
rese= arch, industry, and standardization to this end. The workshop is
hosted by the Zurich Information Security and Privacy Center at ETH Zuric= h.

While the standardization process of OAuth e= nsures extensive reviews
(both security and non-security relat= ed), further analysis by security
experts from academia and in= dustry is essential to ensure high quality
specifications. Con= tributions to this workshop can help to improve the
security o= f the Web and the Internet.


Scop= e

We seek position papers related to the securi= ty of OAuth, OpenID
Connect, and other technologies using OAut= h under the hood.
Contributions regarding technologies that ar= e used in OAuth, such as
JOSE, or impact the security of OAuth= , such as Web technology, are also
welcome.


Important Dates

Positi= on paper submission deadline: May 2, 2017 (AoE, UTC-12).
Autho= r notification: May 15, 2017.
Registration deadline: June 16, 2= 017.
Workshop: July 13 and July 14, 2017.


Invited Speakers

Cas Cr= emers, University of Oxford


Subm= ission

We welcome position papers that describe= existing work, raise new
requirements, highlight challenges, w= rite-ups of implementation and
deployment experience, lessons-= learned from successful or failed
attempts, and ideas on how t= o improve OAuth and OAuth extensions.

Position p= apers submitted to the OAuth Security Workshop may report on
(= unpublished) work in progress, be submitted to other places, and may
even have already appeared or been accepted elsewhere.
=
Submissions must be in PDF format and should feature reasonab= le margins
and formatting. There is no page limit, but the sub= mission should be
brief (ideally not more than 3-5 pages). Sub= missions should not be
anonymized.

Submission Website: https://easychair.org/conferences/?conf=3Dosw17

Publication and Presentation

One of the authors of the accepted position paper is= expected to present
the paper at the workshop.
=
All presentations and papers will be put online but there wil= l be no
formal proceedings. Authors of accepted papers will ha= ve the option to
revise their papers before they are put onlin= e.


IPR Policy

The workshop will have no expectation of IPR disclosure or licensi= ng
related to its submissions. Authors are responsible for obt= aining
appropriate publication clearances.


Program Committee

Chai= rs
David Basin (ETH Zurich)
Torsten Lodderstedt (= YES Europe)

Members
John Bradley (= Ping Identity)
Ralf K=C3=BCsters (University of Stuttgart)
Chris Mitchell (Royal Holloway University of London)
Anthony Nadalin (Microsoft)
Nat Sakimura (Nomura Research Ins= titute)
Ralf Sasse (ETH Zurich)
J=C3=B6rg Schwen= k (Ruhr University Bochum)
Hannes Tschofenig (IETF OAuth Worki= ng Group Co-Chair)

Am 13.03.2017 um 21:01 schrieb John Bra= dley <ve7jtb@ve7jtb.com>:

I did point out earlier when I discovered the dates, that I similar= ly asked for it to be later in the week.
It is probably fine f= or Europeans but it will stop many people from being able to attend includin= g myself unless I can come up with other meetings in Europe to fill those da= ys.

If we cant move it then we will have to liv= e with it and attend or not.

John B.

On Mar 13, 2017, at 4= :46 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi Mike,

yes, those are the right dates. Ther= e are restrictions from the host's side, that=E2=80=99s why the workshop nee= ds to take place on Monday and Tuesday. As far as I remember the host was cl= ear about that from the beginning.

best regard= s,
Torsten.

Am 12.03.2017 um 22:15 schrieb Mike Jones <Michael.Jones@microsoft.com&= gt;:

Are Monday-Tuesday, July 10-11 really the r= ight dates?  I'm asking because IETF in Prague doesn't start until Sund= ay, July 16th.  That leaves 4 days dead time in between for those of us= who are attending both.

When I was first told a= bout this workshop, I was told that it would be sometime Wednesday-Friday th= at week.  Can it be moved back to those dates?  That would be a bi= g help for those of us travelling distances to attend.

Or is there also another event in the Wednesday-Friday timeframe tha= t people should also be considering attending?

= Thanks,
-- Mike

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf= Of Torsten Lodderstedt
Sent: Sunday, March 12, 2017 12:28 PM<= br class=3D"">To: oauth@ietf.or= g
Subject: [OAUTH-WG] Second OAuth Security Workshop (Call= for Papers)

Hi all,

the OAuth WG and the ETH Zurich will organize another workshop on OAuth s= ecurity (after the one last year in Trier).

Ple= ase find the Call for Papers below.

kind regard= s,
Torsten.

C a l l   &= nbsp; F o r     P a p e r s

Second OAuth Security Workshop (OSW 2017)

Zurich, Switzerland -- July 10-11, 2017

WWW:= https://zisc.ethz.ch/oauth-security-workshop-2017-cfp/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

Overview

The OAuth Security Workshop (OSW) focuses on improving security of th= e OAuth standard and related Internet protocols. This workshop brings togeth= er the IETF OAuth Working Group and security experts from research, industry= , and standardization to this end. The workshop is hosted by the Zurich Info= rmation Security and Privacy Center at ETH Zurich.

While the standardization process of OAuth ensures extensive reviews (bot= h security and non-security related), further analysis by security experts f= rom academia and industry is essential to ensure high quality specifications= . Contributions to this workshop can help to improve the security of the Web= and the Internet.


Scope

We seek position papers related to the security of OAu= th, OpenID Connect, and other technologies using OAuth under the hood.
Contributions regarding technologies that are used in OAuth, such a= s JOSE, or impact the security of OAuth, such as Web technology, are also we= lcome.


Important Dates

Position paper submission deadline: May 2, 2017 (AoE, UTC-= 12).
Author notification: May 15, 2017.
Registra= tion deadline: June 16, 2017.
Workshop: July 10 and July 11, 2= 017.


Invited Speakers

Cas Cremers, University of Oxford


Submission

We welcome positio= n papers that describe existing work, raise new requirements, highlight chal= lenges, write-ups of implementation and deployment experience, lessons-learn= ed from successful or failed attempts, and ideas on how to improve OAuth and= OAuth extensions.

Position papers submitted to= the OAuth Security Workshop may report on
(unpublished) work i= n progress, be submitted to other places, and may even have already appeared= or been accepted elsewhere.

Submissions must b= e in PDF format and should feature reasonable margins and formatting. There i= s no page limit, but the submission should be brief (ideally not more than 3= -5 pages). Submissions should not be anonymized.

Submission Website:https://easychair.org/conferences/?conf=3Dosw17


Publication and Presentation

One of the authors of the accepted position paper is expec= ted to present the paper at the workshop.

All p= resentations and papers will be put online but there will be no formal proce= edings. Authors of accepted papers will have the option to revise their pape= rs before they are put online.


I= PR Policy

The workshop will have no expectation= of IPR disclosure or licensing related to its submissions. Authors are resp= onsible for obtaining appropriate publication clearances.


Program Committee

Chai= rs
David Basin (ETH Zurich)
Torsten Lodderstedt (= YES Europe)

Members
John Bradley (= Ping Identity)
Ralf K=C3=BCsters (University of Stuttgart)
Chris Mitchell (Royal Holloway University of London) Anthony Nadal= in (Microsoft) Nat Sakimura (Nomura Research Institute) Ralf Sasse (ETH Zuri= ch) J=C3=B6rg Schwenk (Ruhr University Bochum) Hannes Tschofenig (IETF OAuth= Working Group Co-Chair)

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

________= _______________________________________
OAuth mailing list
OAuth@ietf.orghttps://= www.ietf.org/mailman/listinfo/oauth


______________________________________= _________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oaut= h
= --Apple-Mail-6016C175-78AD-45BB-A1A9-DD74397B558F-- --Apple-Mail-D54B4173-FCD8-4B6F-9A2D-D8EA1A0E1256 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSTCCBUUw ggQtoAMCAQICEDPbmsaqwjeZa3PxA3uZ8LQwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNzAxMDkwMDAwMDBaFw0xODAxMDkyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEArsGSzZyz9Lq9SRW9Sve5K8n5lWhplOCE6HH3gMye12DjOpkF FZt0b73t27G17Xsp6WUxHhNevf7ck0AUpvYUPCHBqVGJSIWF9hWAoSFCgQACOoh/cDFbzz1PsMY8 El7OmIus4JXtY4/VdoSIhFP3hzATbNAg32Kp+N8vtTuKTwbgnizJSyzZTYrsttn3LmwY17HU+U9v XloMus5U/ln4ADZx0zyyDSsA6gtPxXYJpbgSTnHckVZ5zfR80guIZ538Y2qqsqt5VaSRSR2oQzE/ HETkKc/odPVhqBrXLyvnSFkCPrAXV07rcvwkPvHZeYVu4QdVWyO2HIQ4i2x9r5m7SwIDAQABo4IB 9TCCAfEwHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFPngHgVxOZ7G Sji/IW4YJMBj02PHMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEE AbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwXQYD VR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50 QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAwWAYI KwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhl bnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNv bW9kb2NhLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0B AQsFAAOCAQEAAmueyHjiyL1qYgfe+hVSsGuKlgcvjCAfG8Jaq48tC0IjP8pH/tGi4uL9CHVfLnV3 pLDnjg6M2uvpEBp7crZZcnSPLeVss+tkhwv+F7ISYQyT4flNkqVUb8nfewbCPcIN13ObfpU7rlXo IarEEplQo4SuymYVluQxTLOFKm5QOMF4JBMw/rjy4t95J7Mdp9NFUzQrKPJDaJ2Jr/TcTXFcjLvN VmMBjK0959a9v1/1miRHd1DBsTh1KvBigEOUNMxvT5uUtB6/tioDZqBDDk8Gvdno/xmye3YiasS7 JgMREq5WcXqpWGu5kMFZMGPEvyPHeBZeqxx3amf4ImVnZ6WvgzGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDPbmsaqwjeZa3PxA3uZ8LQw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTcwNTAyMDU1ODA5WjAjBgkqhkiG9w0BCQQxFgQUxPbVt0Ag0ggdxP0AqJMgpYIJShAwgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAz25rGqsI3mWtz8QN7mfC0MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEB AQUABIIBABB+BukClm8L7JE5PwkrjRGjYcGUT/hkgyFaqom8FtEIWeOYjNPFmUcwo5CwW/4FhZ4l ovRAtsZPmXuDHnWoB7zbpYyMNuAiuVbl9EAlhj/3ihcJ4IcVziE2cpUiigyq5I9UfhbGh0lbMnj8 lTyGaNeEKgX4CiSpgC+MEa1nku2Ohtcl2u9kMTNlN0mPZs24CzWQN1VJNhaz5EH9K3WXK+4JWktz EeFIHAR5FTt604QpyxBzLIR0vittCMMg9Bq6JS9MC/gkfje6KJiv/YI/oIqR1MPjgiR49etmnygm eY4L7tA7BjFvoLoiM62CEDECq7VN/dBQPkgwkOD6AoE8ucwAAAAAAAA= --Apple-Mail-D54B4173-FCD8-4B6F-9A2D-D8EA1A0E1256-- From nobody Tue May 2 02:01:24 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49811314DB for ; Tue, 2 May 2017 02:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fSeyiEVPb4E for ; Tue, 2 May 2017 02:01:18 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DCE812EC92 for ; Tue, 2 May 2017 01:56:49 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id r190so11601670wme.1 for ; Tue, 02 May 2017 01:56:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=NgRsRVnl3xvaV354bgtmOz2EJFhiGJ4mGTEIv7KXPqc=; b=GPflGE+en+QqoDgk61K/aBgpbQGr8F3f6wjG+PKxF67c5g5owml2IAekR5Seib99e1 n0D2hsUC85Vqp13DQXgvXTylBZmIHKGjNEKw53ppj5vVjznWMo1fS/dZ5WZUGiYzxlme eT961S0crLiFbBIUPd6/FFvoLiIwwCyKHO8xY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=NgRsRVnl3xvaV354bgtmOz2EJFhiGJ4mGTEIv7KXPqc=; b=qyUtk1o+LU5mqlHlv5u9l4lElKHzBzDRNlKe59raHbAviphj2MajWVYucJkWZYBLGa o2MEQ9zwekGW0qbGePpaxfJaonk3SLzh5zsBfAPXuP6RW5v6JwzF1Zjo91UvnDs83X36 aTDapWI1R0ACs/M1mD98dqhZBGNkwbgU1fCabsYMz0S5+s/16Z1qJgQqZv9MmJTobbjN drqMkKNDtSPcWTssfAzDVP9wL1AceTjBoAmbzF2hr4dBFMMSJOvevVuGgvCIfxxLY2lX ugOH2zCE13yQfK1LofVCgD4B8wCizlBVJiDucxduxf8+kPeU8y/7hkhkUCpM9mX//ZvP QPMA== X-Gm-Message-State: AN3rC/5adhLIcEFbFzkWipA+KMdW0iLJ3r7cGGtTqnCNcUqOMhkFZPUE 2VvrnofvDU5yotes56ibLfmEKcjnOy68wSsc8HHBKINa7/YlM6KYGMEdGBfo9PxMeyoNrvg2eyT qC5HYaLqgNwKZ6X0lllcSbIx8C2ggFBwPc8nXTWpto1/swnAZK0w= X-Received: by 10.28.147.3 with SMTP id v3mr1285636wmd.45.1493715407385; Tue, 02 May 2017 01:56:47 -0700 (PDT) Received: from [192.168.43.12] ([148.252.128.147]) by smtp.gmail.com with ESMTPSA id n99sm22174586wrb.62.2017.05.02.01.56.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 May 2017 01:56:45 -0700 (PDT) To: Torsten Lodderstedt , Justin Richer References: <77856AF4-9B2E-4478-9509-1459037C24E4@ve7jtb.com> <22d06952-94ab-e6a9-d2b2-f96f8252bf5e@mit.edu> <4107AB98-25D8-4542-B932-CD6F921D0D1D@lodderstedt.net> Cc: "oauth@ietf.org" From: Simon Moffatt Message-ID: <5529a18f-0ebe-eeae-2de1-c4066cf986b3@forgerock.com> Date: Tue, 2 May 2017 09:56:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <4107AB98-25D8-4542-B932-CD6F921D0D1D@lodderstedt.net> Content-Type: multipart/alternative; boundary="------------30D8DE1442EB7F0C3CE2CD8D" Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Device Flow: IETF98 Follow-up X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 09:01:22 -0000 This is a multi-part message in MIME format. --------------30D8DE1442EB7F0C3CE2CD8D Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit +1 for separate. The real world implementations we've seen tend to not need the URL at all. Eg end user out of band is in a web application on the their laptop/tablet and that app has a "pair device" area, where they just enter the necessary code - so they don't even need to see/use a URL from the device. Having the code augmented in to the URL too opens up the ability for that code to be logged on intermediary network devices. SM On 02/05/17 06:32, Torsten Lodderstedt wrote: > +1 to keep the optional parameter along with clear wording regarding > security risk and interoperability > > Am 29.04.2017 um 15:12 schrieb Justin Richer >: > >> +1, documentation is better. Though we also need to keep in mind that >> this was the justification for the password flow in 6749, which has >> been abused all over the place (and continues to this day). Still, it >> would be arguably worse without that so I'm good with keeping the >> parameter in there as long as we're careful. >> >> Namely: So long as the user code is *also* delivered separately to >> the user, we would have interoperability between the two. What I >> don't think we want is some systems that *require* the URI parameter >> on the approval URL and other implementations that *forbid* it. That >> case could end up with something like: I've got a set-top system >> that's incapable of displaying a separate user code because it always >> assumes it's baked into the URL, and then I try to put it on a server >> that requires the code be entered separately. >> >> The resulting spec needs to be clear that the box MUST be able to >> display both the URL and the code separately, in case the URL does >> not include the code. In fact, maybe we'd even want to introduce a >> new parameter from the endpoint for the pre-composed URL: >> >> user_code >> REQUIRED. The end-user verification code. >> >> verification_uri >> REQUIRED. The end-user verification URI on the authorization >> server. The URI should be short and easy to remember as end- >> users will be asked to manually type it into their user-agent. >> composite_verification_uri >> OPTIONAL. The end-user verification URI with the end-user >> verification code already included. See discussion in [blah] >> for its use. >> >> -- Justin >> >> On 4/28/2017 6:38 PM, John Bradley wrote: >>> I would like to keep the optional parameter. It is useful enough >>> that if we don’t have it people will add it on there own as a custom >>> parameter. >>> Better to document any issues. >>> >>> John B. >>>> On Apr 28, 2017, at 5:39 PM, William Denniss >>> > wrote: >>>> >>>> Thanks all who joined us in Chicago in person and remotely last >>>> month for the discussion on the device flow. [recording here >>>> , >>>> presentation starts at about 7min in]. >>>> >>>> The most contentious topic was addition of the user_code URI param >>>> extension (introduced in version 05, documented in Section 3.3 >>>> ). >>>> >>>> I'd like to close out that discussion with a decision soon so we >>>> can advance to a WG last call on the draft. >>>> >>>> To summarise my thoughts on the param: >>>> >>>> 1. It can be can be used to improve usability – QR codes and NFC >>>> can be used with this feature to create a more delightful user >>>> authorization experience. >>>> 2. It may increase the potential phishing risk (which we can >>>> document), as the user has less typing. This risk assessment is >>>> likely not one-size-fits-all, it may vary widely due to >>>> different the different potential applications of this standard. >>>> 3. The way it's worded makes it completely optional, leaving it up >>>> to the discretion of the authorization server on whether to >>>> offer the optimisation, allowing them to secure it as best they >>>> see it. >>>> 4. I do believe it is possible to design a secure user experiance >>>> that includes this optimization. >>>> >>>> I think on the balance, it's worthwhile feature to include, and one >>>> that benefits interop. The authorization server has complete >>>> control over whether to enable this feature – as Justin pointed out >>>> in the meeting, it degrades really nicely – and should they enable >>>> it, they have control over the user experiance and can add whatever >>>> phishing mitigations their use-case warrants. Rarely is there a >>>> one-size-fits-all risk profile, use-cases of this flow range widely >>>> from mass-market TV apps to internal-only device bootstrapping by >>>> employees, so I don't think we should be overly prescriptive. >>>> >>>> Mitigating phishing is already something that is in the domain of >>>> the authorization server with OAuth generally, and I know that this >>>> is an extremely important consideration when designing user >>>> authorization flows. This spec will be no exception to that, with >>>> or without this optimization. >>>> >>>> That's my opinion. I'm keen to continue the discussion from Chicago >>>> and reach rough consensus so we can progress forward. >>>> >>>> Best, >>>> William >>>> >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- ForgeRock *Simon Moffatt* Product Management | ForgeRock *tel* +44 (0) 7903 347 240 | *e* Simon.Moffatt@Forgerock.com *skype* simon.moffatt | *web* www.forgerock.com | *twitter* @simonmoffatt ForgeRock Live 2017 --------------30D8DE1442EB7F0C3CE2CD8D Content-Type: multipart/related; boundary="------------6D15056F6745C98F7A98D5E2" --------------6D15056F6745C98F7A98D5E2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

+1 for separate. The real world implementations we've seen tend to not need the URL at all.  Eg end user out of band is in a web application on the their laptop/tablet and that app has a "pair device" area, where they just enter the necessary code - so they don't even need to see/use a URL from the device.

Having the code augmented in to the URL too opens up the ability for that code to be logged on intermediary network devices.

SM


On 02/05/17 06:32, Torsten Lodderstedt wrote:
+1 to keep the optional parameter along with clear wording regarding security risk and interoperability 

Am 29.04.2017 um 15:12 schrieb Justin Richer <jricher@mit.edu>:

+1, documentation is better. Though we also need to keep in mind that this was the justification for the password flow in 6749, which has been abused all over the place (and continues to this day). Still, it would be arguably worse without that so I'm good with keeping the parameter in there as long as we're careful.

Namely: So long as the user code is *also* delivered separately to the user, we would have interoperability between the two. What I don't think we want is some systems that *require* the URI parameter on the approval URL and other implementations that *forbid* it. That case could end up with something like: I've got a set-top system that's incapable of displaying a separate user code because it always assumes it's baked into the URL, and then I try to put it on a server that requires the code be entered separately.

The resulting spec needs to be clear that the box MUST be able to display both the URL and the code separately, in case the URL does not include the code. In fact, maybe we'd even want to introduce a new parameter from the endpoint for the pre-composed URL:

   user_code
      REQUIRED.  The end-user verification code.

   verification_uri
      REQUIRED.  The end-user verification URI on the authorization
      server.  The URI should be short and easy to remember as end-
      users will be asked to manually type it into their user-agent.

   composite_verification_uri
      OPTIONAL.  The end-user verification URI with the end-user 
      verification code already included. See discussion in [blah]
      for its use.

 -- Justin
On 4/28/2017 6:38 PM, John Bradley wrote:
I would like to keep the optional parameter.   It is useful enough that if we don’t have it people will add it on there own as a custom parameter.  
Better to document any issues. 

John B.
On Apr 28, 2017, at 5:39 PM, William Denniss <wdenniss@google.com> wrote:

Thanks all who joined us in Chicago in person and remotely last month for the discussion on the device flow. [recording here, presentation starts at about 7min in].

The most contentious topic was addition of the user_code URI param extension (introduced in version 05, documented in Section 3.3).

I'd like to close out that discussion with a decision soon so we can advance to a WG last call on the draft.

To summarise my thoughts on the param:
  1. It can be can be used to improve usability – QR codes and NFC can be used with this feature to create a more delightful user authorization experience.
  2. It may increase the potential phishing risk (which we can document), as the user has less typing. This risk assessment is likely not one-size-fits-all, it may vary widely due to different the different potential applications of this standard.
  3. The way it's worded makes it completely optional, leaving it up to the discretion of the authorization server on whether to offer the optimisation, allowing them to secure it as best they see it.
  4. I do believe it is possible to design a secure user experiance that includes this optimization.
I think on the balance, it's worthwhile feature to include, and one that benefits interop. The authorization server has complete control over whether to enable this feature – as Justin pointed out in the meeting, it degrades really nicely – and should they enable it, they have control over the user experiance and can add whatever phishing mitigations their use-case warrants.  Rarely is there a one-size-fits-all risk profile, use-cases of this flow range widely from mass-market TV apps to internal-only device bootstrapping by employees, so I don't think we should be overly prescriptive.

Mitigating phishing is already something that is in the domain of the authorization server with OAuth generally, and I know that this is an extremely important consideration when designing user authorization flows. This spec will be no exception to that, with or without this optimization.

That's my opinion. I'm keen to continue the discussion from Chicago and reach rough consensus so we can progress forward.

Best,
William




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

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


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

--
ForgeRock Simon Moffatt
Product Management  |  ForgeRock
tel +44 (0) 7903 347 240  |  e Simon.Moffatt@Forgerock.com
skype simon.moffatt  |  web www.forgerock.com  |  twitter @simonmoffatt

ForgeRock Live 2017
--------------6D15056F6745C98F7A98D5E2 Content-Type: image/png; name="FR_Sig_Logo.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="FR_Sig_Logo.png" iVBORw0KGgoAAAANSUhEUgAAALkAAABGCAYAAACQaTWQAAAAGXRFWHRTb2Z0d2FyZQBBZG9i ZSBJbWFnZVJlYWR5ccllPAAAA2hpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tl dCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1l dGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUu My1jMDExIDY2LjE0NTY2MSwgMjAxMi8wMi8wNi0xNDo1NjoyNyAgICAgICAgIj4gPHJkZjpS REYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgt bnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wTU09Imh0dHA6 Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8iIHhtbG5zOnN0UmVmPSJodHRwOi8vbnMuYWRv YmUuY29tL3hhcC8xLjAvc1R5cGUvUmVzb3VyY2VSZWYjIiB4bWxuczp4bXA9Imh0dHA6Ly9u cy5hZG9iZS5jb20veGFwLzEuMC8iIHhtcE1NOk9yaWdpbmFsRG9jdW1lbnRJRD0ieG1wLmRp ZDo0MTdDMzdBN0FBMjE2ODExODA4M0ZGQjNERTYwNDVFMiIgeG1wTU06RG9jdW1lbnRJRD0i eG1wLmRpZDo0RjYxRUYyOUNGOEMxMUU0OTM4QkU4RDlBQzg0QTY2NyIgeG1wTU06SW5zdGFu Y2VJRD0ieG1wLmlpZDo0RjYxRUYyOENGOEMxMUU0OTM4QkU4RDlBQzg0QTY2NyIgeG1wOkNy ZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1M2IChNYWNpbnRvc2gpIj4gPHhtcE1NOkRl cml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InhtcC5paWQ6MDcwNEQ1QTUxRDIwNjgxMThD MTQ5QjkzQTA5OEZCQTYiIHN0UmVmOmRvY3VtZW50SUQ9InhtcC5kaWQ6NDE3QzM3QTdBQTIx NjgxMTgwODNGRkIzREU2MDQ1RTIiLz4gPC9yZGY6RGVzY3JpcHRpb24+IDwvcmRmOlJERj4g PC94OnhtcG1ldGE+IDw/eHBhY2tldCBlbmQ9InIiPz4qUGMsAAAoB0lEQVR42tx9CZhdVZXu 2ufeW3Wr6tZcRSYSwkxAJHQQfbS2jAJO8emTp5EPuhsB7RZbaRAjMisoqPDsthVQoZ1QEFEE mechhISETGSeA5lTSaWqUqnUPeutvc+09z5rn3vDM75cbn2nzjztvfba//rX2usIRIQPT7kY AAFAQPgvXEE5NzepX7h59foG+OoFK+Hzn10BPT2NwP98dRkhvHgdwDP2B+v2dvNcRF+7hnwG Ol4k5wX7QbuGH87Na6rjoncC5rrGc6ljOujfDbTe7Pv58+rr+qCuMADDfl1YHL51Hfu+jnVV nl7yLtozpY/RrxHcr6FxCyxfcwo88+olkM8PQs4bjp+8va0VXnh5Ojw/bTq0t7bSZQVdKqy0 uDK1urQ2mXIA5rH0+8s9t8O++G3YsAFHjhwp/trXzRsvhuGbCH1u/2ijwKDgfGQvmgiSZ1aa VVG8gOvLXii4oQApwQat0fjxObygeimhFYZwR+upxngQLX+Wlk+n406huedj7qvNjZuhb7AL np/1RSj7BcjnhtwlqysFbv3t/GKlI6BAgr1p2+G0iLQ8REWTC2+DzKNgIq8CU3WZCDYj0X/N 5///9Mvb8pvS4FzrRrswhaGRIgFMBMnWmF6GBk+0G8bXCq8X3sm+TiCcYGjTYJvZYOL96HO9 Sjtd41yaT6Ht74uEP3h2eLy+MHBbnoRp+rzz4I1VZ0NTcYshAEIIVsDCl3AKjVIWmOxT10GM izpat69PjQ7q63qhoX47+NTgUte3JVJwMow1K7h7L+TIdFHCFmBMtXqh/qILaFo2FJ5IC4PR ldtzx4+OF0oY/YovEQl9NEfkYVP8DPLawcaRNJ1Pwv+/ad/xwb3Sz0aN5fLG4jaYPv98WLL6 ZBjZvpgX6H35c2hSv1xwCKqmvXVIEjW4vRJuYfUAtSjksaZBRitZQq8XthedKzSBSPewiSYH RqODAxenMXWgmYHB88k10OhNXNAFxtP0ME1Hmz0PWI1RXlfc0VbaOHfdpokwe/GnoKW04Vja fyYd+b2ooe+VwCOnZIUJLbTtCOhQzME+va6czyJ0SOoQcLQUm9ab1LKA69hAa7FgdJ+VYWLQ OMxTbOH1U9rWbehp1xBZ2j4x+GxtLhznBceqfbfR8tE6pk96HsP425nP77nSp/V5yz5KHZJH +HfXP5Jo3UL73qMLpS6owpYi1Ho+kT4Otb+kh7SOw+xGEQs4Y0gKl9pG17ag8fC9h6hVIY8K AisbGFElyUN9tDZ7hrCb8ME3mQTDGPQ0IeQe0dcE1NOWISXQyTU8Bq6ohU/SNDnC+prgG8av fGbS4lObGzdsWbzqFFix9iRobtowAdG7NDzoOynjTteweiHGRYspg5ATwOi4eB5qVbtRuDR+ CmlaSoyVV8GcI7iGgLUr5MjBErZL1QrTMzWTJkiasPma8WhSYoEg+Zom1YXdZGTccAaYhuVr k/6q6hrfSASZM4bjhrewWNf7o/5dnTB32WSoq+uHnOd/Q7vgqbKxQIpEQSes5fa7jkdTFbNQ JNL4qWtydYda3WEFeUVHQ8CalHFd3UUFYXZTUQGh683jErU4bAMepKlBW4unDcTKhqYNVeR6 SpOjr7Mpl9D+SVGPw+P2SMPD1MaGHnhj1RmwpecQKDX0nOqjONc64aZAyNICEmtp/OsoQoOB sTV6BWFF29AUDGWOYGp7hMzGui9+Qoh9KOSoGSSWYWIWkEipCuTaTIiLTSHKMgSthoCcw8i3 tLzH9hgBRZhcN1E+fhetX5dgd5ctoF7vARLqP0keev7Sj0FjcTsQMrvK6NGCC0+g8pnqEoKo 7GzoIqqUlBTkAR72OGGlqHBNBqboXDzLSta0JrdfFoTexzpbnNAEEZHzWur7OBjDNxIH1DC8 mhEHn3ImCc/Q+iHXfZnkwjnvYdpG8G8qFPph3tLJ0Edwpb5u5/kCvJNTFR68/NdIcDqyCZXq IIptpHLwRG8kIuluGeEVLDRB29tpG7gi2SlSgi72qSbfG8LjbVCIHJ2kGaHC/TDIwIi0qzth LjgoktCL9n7fdH/HlKRvCH7arZ8yPo+h616hO47MBpg4nciw/M/WpvUz1mw4AZauez+0NG1s pG03CXAIiYA22vYdKpOL8rkcFBuK2RBCd0UIm2q1FCmaMosaC2jLs76tVCpBIeeBX/bd2Dqu 1ySEwzA2BQdPapNKzGfiLmGyixYvFfl/MmhAHYtnxaiAReHpNKKtZdPwxsDhcRyIpzeUbyPD 4Sc9QmyEDuVzg99DyMGcJZNheLgeCo1b/s0ve6NQoCEgStOKmP2YUygUwCNDfP2GjYGH0pK+ xJPJxAYZEs/sMzSz1hqYVuFRQ+vZvgPWrd8A9fV1ptBathZyFig6epwsr+5+jsnzTovajuex 3dNoy6rHOGfM/Qaboa6nC67LSOVwO2gBWmYPgmkFdAYdN1mg72hISQMjw/Ka9tKG1QuWfwRW kyZvK711kO971xnQ2K5ohBdzudyP2lpb4fmXpsFzL0+HUlMj5CRE0pxrHGUYrZt0IK8vdWoy mEcyqzuDgsIcLpdpp4Bm0uio21iCEWCut+YfYJ97efctXAGmhdtUIiMckidHhxYXBsTwLfxs aVoDbmjGp8gI3mLDBLwgpMC89s2cR9XcJo/LzSvW9X2nf6AL5i79CBS8QfBE+RYfvYJeLqjH 7gh15hUdbS2w4I2FJOSvEH4vqMoaxnLyZJiIbzl+SlT7y4wmExI60LKcR29Wtpp6OXpzIVLC Ia/v5T1zuwuCMBGHrMZ+xwRoycqzumWzUKzYFU/XS54Dntj7PdbZky3EHCOj42srqCs56Hw6 bqKJfSMWxnwGaq83NzVuhhnzz4WNPUdAV+uqk0jAP8113ZEQkBDd3dLc/PKWLdvgkaeeg3wh V9/Y2Ci37456vpzlYMuBNXcqkUDw7OOjasgLYUUXAh8uXcnBF7vtK1An4m2EMOx37Ar3npXe x9expM8LqwFHshkv07vJNQhf48LT7nvrcZtow3eDjR7jHEqeiQT88VLDtl9t3X4IvLHiTCgV t0lv580u+i2EDcM5L3dtXSEH06bPhJ29OwmmlL5JAn6LYSGiGwoEbIbgqT1XF4pW1y7SeFs7 KEU/prh7O/IU9NBcUT0rtN8LOTKOAVEdVkvjKBM7uwWWhzmJdvaZ63D8u2aUmvj829QbjDB9 Vp4VahAIP3VIl9XVDZCx+UnY0TcGGup3fIGu9Pe88AXbymX/utbW5tXLV66BuQsXQ1t7W4HK 4hIqo0vokFEcv22XcyBMaOJd1BsUo12FJdiG884WYMHj6hS9yGwTtcumOOgFVwEyBacJvF/2 oKllj0KI5bJnQRI9MIvTpLZnEsKQXF0AweLUfSa+xbN6eLX/EJr+VYc9HGQJlvM/a23aOG/t xuNh6epToKW0Pu/7uct1rW1rMpqvqKvP31wmA+/V12Yr7FzI5aRTqDVQzuJS1oAXDLZ12D6o +9Bdvas+uAU5oWTO1ytbVBDod4aMa5rcyedieltYUY1Ne2DOnDYF7dvbhwDLwgrAynIMeany RAAWhmTTjH7c02IsQP7Npr3hgRmxGO/ozeeGvi7HMS0gY3NPOQ/53O5raPUQXWvbzhfS2Ne1 trQMzZn3BixdvhJaW1vGk1BelUQr42X0byKLtatEJc5zxP+DIEb1iZimKLGKZ8J3giZH4Ls7 vWvUjh19wG74w2MHwLU/mAC5XBmKDWXDccNrXI/1dCbsC0dJepkwxwzj9c6m6VPc8bajiXD3 1c2lDVuWrjkZlq07ScaKj0X0/t3S2jbV90KxWPzFzp39MGPWnICLBvFN1ahMYfyWgb2xSkFK c33gsg2cTh5W43N+D51FEGaP4+w59h3Fsm9jV3RIYkAVm2nBRNAVr+zB+AMH4a77xsKDT4wh zT4gueYq+FATdgTrkA1FWJaGHfw81dUgjOhG9JYX6/r/o3+gA15f/HGoLwwQNvelYDZwwqRh 5m+0NJdg1py5sGnzFmhuKk2ijRcwgvARms6MzxXgjPCMGwCCaTAicHGzvEdVMJY8corLhUlc Q/f+dhp8X/HknmZ2JzEQmRx5UgHyoQp5H0Z27obbfzkOtu0oQUfrbhJ02+g0GRfbeBRxQJeL hYkiCX2LyfE0wVX7/pm2fcCMEdc6LENBiqmNDZv8xatPg809h0Njw7aTSbOfl8Um0Pv+qrnU 9OLaN9+CGbPnQKnUJMvmhpi1AMuWAbgppb0554tt5Kc0b7AgKsWO2CN7OM0MDMmAYLIpmfEq NUwhcoZWNXiNBAO6SMiXrCjBfQ+OBpEbdjiEKnGRfmxw2lo+ce+nIUxi2Hot9O9GO0ZcpxwT b6z3QlPDtvs2bz8S5i37iBRwee9vViirYepOr60v1sNrs+dCX98ANDQUzyHBP9sot5g6VNr2 +KDh2SyNqICbGeMSLU0nHJSkQdGI1CgjO5TabARaQ8LMB6pNIU8KULixHLox5IgRg3DvwyNg 89ZG6OwYAt/XYYmfSRvG3krGTW9EGWIYsAXpiEaarqV/I+LjtVhzG+tT3X9NUoZzl3wMdvSN hGLdTtLg4jRdUGzq0Pf9H7S3ty5ftnIVLFi0WOUzoW03sFhSGJMcQdRsQBasIoALHVg7A9On GgFiahSRcxCzsDQ51wPUaKwtFxLo1tyO8X7ylNbSMKzfVIT7HxpNW/ZAZ+cuyKnQbl2D+nGs eBp/+8wEhkZWRq0WL54MXPbG0fSFiDGh5Z005yZpR/xna2n9K29tOgaWyyjD0pYiYO5GjTlJ GXn0t76uULh+eE8ZXnl1JgwPl6FQl5MG6hEV47sRuun/tSkBAoexn2VMVpK3rPOwil4j1SB0 vj7pUWrtlzeZFPfIfMOlyyaqARhD2vzu34+BJasb4eLProUjD98O5eHdMDQYxiYD2sBYG6gh NA4QzdjSlMNCM4ADoeynfUfS6mZaK6TiaZPre/n8noHh4SJMn38eDJfrgGDLZb7vjbHfV6/s crl8dWdnR780NpcuXwVdHR0jfR+vMcvNjio0iuYrtPNHdNgKNiowa2SPYARbuCELHzZt16lg SAVOq2M6dEDUspAbA2FFKrbYFc2my1F9Pf3zhuGxZ7vhuWmdcO4n18KUyVKB1sPQHt80ZEJB FeG1BRNolGwTaeIAjRraGkxq46DdSvW20dq8HmYt+jS8ufFYaG9ZdwQJ+A2mjSVsB9CMYkPx pzv7diosXqyvlzE719O1mi1KJCu+Q4Yk3k67znALFQNBBKO6rSRPLOXHwH8z8A5Twszy6QJq OjDLEnLzRTFVgFpyGS5RTYxbSY3mAA4eNwA7+z340S8OgMHhz8AxR42Dnh19DC8lIGvUbFK+ wsFriSq9Kcl5eWqEu4cblLDTlkGq/D10p4J+Vz2stez7V7e1tqgIwzVvvgUjursmUcO70IUb UI/vNq1C32hIXP4TuzdNxaOIxJnj0syOurFDa5NnwGwo9DcU8H0cT+4KqxRm5izOpZySOyRh F9BYLMOo7n5oaChAvtAEe8p9kMt56cLDbF9GKrgOTHQQbpKxIh20skW9k9uDmxvc07CpkN89 6HllyQytoa1fpgr/MZdSwkf/ty3NjY9u2LhJafGWJhWffaP5wOiAEAb0k7EPF7qoSSdITgms K30funsGDuJE0aYiw5B1DLaoRZ48X0n7GbHFIgMzWtpDUA+dz+VhxqxX4MAx7dDdUYTtO3rB y3kmZYnpbr5iSCemoMVIms0KL1nWjSY0iWsPcjJDLVyNGFOmP6F//0Z7j9IFUM494V1bT/Dk ladfUKNturs7P+37/of22hUP8H9oWuMuN738wNTU7Egeq3et9AxOOCOyjUlWwGs+uVD6paod r2hqlAB3NzY0wrIVq+H3DzykGInm5pKk3cxrCxMmCMfgaa7ytEqfTdvuDJdz0UT7c9p69K5X 0T2ONN5ZwBUp2hDhltbWlsUrV62F+W8sgtY2RRle5XTmuP0KG2m6lu2edFysa2vhYD343Bd8 eaEjuEs42BJRicUR1Tg89mMhR9uZsZf8vzMLGUJXRzssW7kaHvzLY1DI56FYLCrtzWWPMtKl CYvGMuw7NsZaaujdDP2XosTo+t/S06rR8oO060HtmTYRtPqW3DnjtdlQxjL1Srl/oe3HJvaf qEzJBUJ1JR3az8MMzcjL0iRc43AaqRWy2QKmWSAXN+/CkDUp5E43vuDL34hj5lIfmAbPAd2d sHDxUnj62Zegu7MDurs6oaO9TUbvEU7PkYZER/WKlMaPYqKZIKW1NF0DKdM13fDo979oOlm/ Hv10rvwaerbeeQsWwqKlK6C11NJOW68z7IfIn4AGprDns+nAn2UKiKjEYSOf21BkHF+N34ZT ZBlp49h03rVHITpKQvBWMOqjT4y4i3TpyuNldz9n/nwFV1paStA/MAClUiNMPPZYaC41Kbwe UYkuRkAfMe7A7N+laQoJwbu5QcKWsMtw3BO1Y6ZLbU7G5mnU2/xkaGg3vDprDhQKeWlHXE/P 1uViLlJDzJLly7NoV6fgiWx8zTMzFYklnnnBKh1QonY1ed5JYbksakxrVtNRlLba5T45wHfY y8HM1+dIWk4Ju7zd8pVr4QMnnQjjx40DyUUP9A+q1A62Vom0F+eRs5Jf3kzrv7LpQMa59R7a PoWm30R0Gv3dQI3ov6Tt8NK0V2Hj5s3SfX807fuSafAyoR1pLfgQTU+5ytKgEbmyzDLyq3EC 6fcR6GZj2Gu5P6VSi6G2+ZSx4rLIo5ePPqWC6Exiyf2kvSmFV0IUVYdecI0Vq1bDujffgvdM mgjvnXQ8dHd3wLae7aoReFFaB6gyMWbw+zVNMprwQylNnk7JILX5H2h5UIUO+/7MAzo7YfHS ZfDM8y+BHJRM1/i2zS7x10wJxtedyoKj8HQYlDnoWMS+yEyZQw2KodUDZ1CLLDVsvN6+U+f7 NtRWF2JgDL6UQY6VjVDMKBwtB3onYfO6+jrlbPn1fffDgkVLoJOMVQllfPT3ooQMAbwsJYz8 4APpzr8+KuBSUxNs2roNHnvyWUV1NtTXT6bTPpF5T17Wvk1bFlQcxLAXRrzuFEL7g2XVZJsV bPYvd76dvXm2mjI8LZrKcO3b35gRkJ2xVVRh7EgNr2LS88oY3bptO9z/p7/Aw48+Cbt27Vbb PM+rroWb95tH088tmtDVC3yZpnGFXJD04clnnqPn6IHWlhZpEF/nxG3ooDNRhRjcClzumqql R6QiBgyPmKgAYRAckaMizahw54FFbwLUbNpmgyc3edQKlneWccJRX1kVGo2LJEFuaW6GtpZm eGXWbPj17/4AcgyldKk3NjTE/Do35tLxk3ChrwooVS8NViT4tJuMzd6d/VBfrxIEXUj/jktJ KccroyEkMi59a1WMhvMYZEfaM4aFlqGLGb5mNzKsxnkkeKZM1LomN7qrKpurEG5hRge+t6+P lsEl47sIJozs6oL+XQPwwEOPwCOPP6XCAVpJ+KWg68yK7kBi+PDNNqXocjTR9s+Uh8unN5ea 4egjj4ChITXwYwlLj7pc4cH0Cv3/CRsLnjX8jTWMIcPTaDpxUPvek319IUQVnk8LVqY+pbI3 FNF+KuTGQFuxF9pGoxmFnsRfVOBjOUMQk4qSvLnExx1trTBt5iy494E/yzwn0CIFveynOHT7 0yKaEfNDmlbZRqr93Z5w+5V9/f1wwvHHwrixo2FHb+9zdNzPWRrN5U8AuNEtPA6t7mhA6GK5 XH4LLdTBaAuuARpZjqUUN1/p0xQ1IOTOgbbIaMAI0iCDb11Zo7KMNm4EeBR+S3h8ZPcBsHzF KsLqD6trN5UaY48pY3Ba384RUiVPtbU9l0uFficPDQ2d30DQ6ITjjgM5QML3y1eCCt3loJuw /Ql/poU/p3Asi5cF38tV1YOCe4wow/wIozcS1RnATCKkdwAmF6xGiZKwpykzzEq/6jZkMhgD N2RHMkC7YPHy5fDUsy8SPi9CngzVLOLFEubf0jQNdVbC8h5Gx5ORe+P2HTuaJhx1OBxx+CHQ 29u7QY7rdH4n01y9jB0XyfRkAhgsn0EDmj2nyMb5XI8gGH6cvW/6Y17VDk3d/4Vcw88pj6Ow agch25FgYdAUDsaMyrTzjWhauruzE1597XWYOWsudHS0GyaBLazMlx2+ZnxeUDgHbo8mDX61 LJb3TpoIdXVFIKx+Kx2y1qJS7Hf+Ie1awtKnogK3z/WerrgUJ08tqhREYTI0rhyK75DBEg4K 0focnt7NMXjWGVVn05Au5wOkP+GhOy50DCxjXCROf+q5F2Hp8hVw4JhR0NnRBu2E22Vu8FJz ExTqCxp6MGroRZruwHjkEAxKBxAdo6Zw2y51X098eUfvjnEHjRsLRx91GPT29w3Rpb4RCtiw OlaEU/DbYBu4TgMzi1YVwA9Vs6k/Vr6r/AgXIt9zcukohKj87DXyc8euIN/NObOpCot5cYx8 EZbgI/LDrFJeRjquobEB+vr64NEnnoH16zeqdLRlwi3FYr2iH6UTqauzQyWh7+vrV/nThYg/ Ayj5cNLSSby5/aHZcJTQCLrXrhzZAx1tbeAPyyRy4h4U+KjRhIPnlZmZd9G8Nw0voKI3smL8 iXBCo1QOcXTRnPb92NgbSI02EuIdkwqRH/5WPRcOUBVeNQbGcia+NgAgg4+XI/NlXMng4G54 6vmXYtGUCefrCac3NTbBoeMPggmkgceMHq08pr29O9WchGK3iu2GZOyolmdcj27cIZdlfM3Q nj2qtlFleRRb0EWLupgjO184VuFzqAYmcMrBlWR/b3B1ipaEKmiimhFyNDUEE2TFDnpNj9Bx V5Qxgh5NAzZLBVrDyyRXXldXgM66Ng3hBDHSAwO7YPprs2HeG4vg0EMOguOPexccfNA4tV3S g9J7qtsarlBc+f5ywEdDQ32YRkOLNXGO6snQ0JqAs5GRlTS+lkErFbMiKjQS4aB/XbHtolL7 ErUq5Ek3hpnuaF6QMWuMoWGAZWXnQmOcaNV4UCTJ7IsklA2NRdLAwzB3wUJYQth94jHHwPtO /Dvo7uqA7dt7lYYO6EkBpcZGkB+0SuLZg5H9Ev9v2LQJ1qx9K/m4lJ5ywsCtFeJ4XDCsmp5S mFAiZXcK4RZY3Q/A9UCOXsYVtQkVAuVqCJNjhbQIlWrTWhaQ7S0UFbpa2+gXjgowvhwiY2Fy CpsPDe2Bl16dCUtXroLTPvh+OOzg8eEY0+CE5bR989YtUFeoi80IGUcjY91nz11A2n8ApBc0 SGCE7mSZVWg/FByXWK132VIE7FAecCugzLzo6OD+wZ0RoCaFHJnutxJ36yxs1BxGGQFdro8z cQUqHEZvBlxUyUgLeRg5ootweZ8afjdm1EiQHLhsAPPmL4RFS5bCAOF7eZz+k9pe5ldpbmqK 4UpmJWd9Qc0Bi6xPUUHFOP5sjj47CZHe2CpkBEDXe2WFANeEkFfKzJSCHZpwO7tczKRz2Yqz U0RnDbSt0qBSIQIlOYC6DKvWvQnr1q9XzqRdJNwqdKChgU1qFLvEU9/hgaoT67P2DQdbKn15 jRE8fYxqZlSibaxmwqIsxqzWMTlmd3luIxKrMFqq7ebsARmY3WWKKpVd2GjkAAwZ4ahCAmgq 1hcN7t8QmhTzKSpn+2UEAtFRPuhusM7MtfYH3UR1SiRlrGKWMSrAmRAU4W/yLc99q8mrMJoy u9Jgu0yfPA5k+CrCNhKONZJ+qy6WRWM8RAXuPvt5SuoZhEqmL9N2yXwnu6IKjAQajBwvkCEI AtC6l2nMZXjCssrQCp8Ir9dFqweqpDWBk+ktVtkIG9cb95UesYNAfr8IldNrDe3emdm7CK43 TSkgqRXqaP/O6GYfnnJxO80m0bTiL7+5fcX+KuRRqO3MoFDFQprHExWIsR56+X6uw5Gw+/oQ TS/QtIO2zKNdM2nzCirgnvD4Ax09xmdBppFAWEzHBPfA+H5LaHkRBMPZTucbokFb/ANNT9LS dpovCN5JLFLPJLcjnsJo1HZ6xteVMOnvKd89LgsMJqGcSNdAkrPxGvntWWE8szxWPfMSOv8N mt9J553IalszAvPztC7P26xG+AO8RtOb8rlU7EzQcDWta+dAUS91KN3zl7Qoy3ypen8B82mi OoGXaDpLM0Q/CjJJKsJKmm8KBdWmgT6ongFhGa2sU04vgHdFbZ4EXKakvjc89wpafyIU+rf9 29djPI+gSSawHOHGjfFvnHXMY0rI9Uy3icaTebn/iRbl9FXacJul0dqVdhDq/i6HikwENIWW ZcVLQd2ZnB9/1vt31H2fw9JeZH/Susw9fhot303L/2S9/1F0kBw4YXyWMAVdggoYrXXnMke1 RwJ6VAbmnkAzKcAP0jSZgW7jaXqeNo91wINRdB3ZmK6i5bOoPJ8IYEpK415PAn8V8rEycstJ 9P8RWvwZnfh5UMlKQQ5gHR9ep2SyN/A+et9nwchZjz+lfy/LXoKE+TM07wl3nk6TVC53hEJ/ xtsVxr/NGE8XyOM+txGc8yrNP+SGxagffyv9vzQOpBIVPhSZNjgn0fwBBgo8SoVzTiZHn+x7 1tpnUkPMcLNk0AGaudsxDA+o9IHfYP/H6f/dYORqgXFUDnNoeawTUKNRT4/Te57KwDSZm/Gq VNIj9hOV+KARnJXcVo/pnBj0yobz7lY67sLwuuulYBM8kek/gOZSqC+iuVRCK6gBHLJ/anKT HpMxGl9RmgrRM7/riY0Q5fQTMJX+vcfixO+h6X4Vy4FwKG35Il373XFORcTvkyZ6nLbPdzzP xWHXKhPXS1f6cXTO9UrjBxV7WqgpngjXLwL58SnThX4PrdwbQCepbQUJmGoE8qNX/+02sBXu lGG5MuPVwXFHkBh4JQVFeKfKjhB6bVUaMoiPeT+o5Puqp5K/88OvTiwKi+w2UgItWq8joeDt SisiDNP2v6P5l1QPk1TPnSBT3AkcDnswKn+Yqqe2oGtKbXt7YA9JjI+foO2fo20yOdKDyXg5 LuccHA4ymA3DL9kF1/2FVE6as2xI6+EnkVAvp/l94brE5YeE8/1Gk3NZbVfRtFjhZKdjAJro dS+1DBgJKe7RjpeC+BOFqQVM0QzKr9J0gcNp8jJdc0FSYaRRhIo3uVe7z0Ql5MH6FdYlzqWz fm0l75f3/0oMcxhIpDErS6UtEVeSkypMsTxDND1Nm/Q0dS+EndlN2nHvDxvKe+me/1Mrv10q D4x89+T3KEnULRDYDEeH20iAUKar+2Eo0FdYz0m9ZfChXM2n8Hs68HqF96130gzoTeGmaTQ1 icTzfY9qnJrhH33cL8TfUntLjX6RBl3u2F8NT70bLcYlIEBPmJnTaNKT4oxSwU/itXt4DYlf pH9btLZ0NnDRj4G3Msd8aWyN9XxNkRYJtUZUY/eERmp0ai68jwi72IFwPRdXNZoMWsgKReUS vDOGU7YzhkfDCDOsXIOF8LCzLAXxNZoWpI1SlCmf/9FywJ1sYO3kcZYGGlfPkxEbRzLWvcdg qdCAk0eGuLpTayCycUzRX1kbMC0FWfZKTxJMkee9RkIvG9xrtN6zfwq5Sf6fo7R5MFBgdThJ QRuONbBkMswqfYzljYN1GYb6R63yRtH2cY6hWMMpWUIFUfRKXhGuTLQYh6c1mkwakrMVhSjo PQRIdmBNOA2H75h2lwsJrxTjsCZ+d6G08wtWQ7O8xCLKYGriYEEQBrWYeSHvjwEsSARfQo8/ uLtqMSNknqLWeHC44xhaH6WV4bOG3cQ1Ro7tFLAnhCSn6cJMf1emnEnhK5Ig3xc2itMlqxJq cLn96/s1T645DRoVz8rnpg7TXxE+NfneHtZ5kVT6RtMVKPlWlg+/JKTgWhQEEOoTgedodUYV gs+Ey2OtLABbtaqVmHIsvVM9vdMY4x0DLdbkcME3S+Yh6q61lG2jWCFJLiCvd5XikIN3k5j6 JFr/qOZAkZr24fC8knY9OkdsZ51cSVw3QQ0xIXSQFcO9TVb5bdI/h1hVGK6IefW2lGdUqARN F6WcVeFzhoJ+X+04g0y6cEeoxeo0CZL/DoUkn8hWKwHnSGeYbnDgWAvGDDhiWS52el2DY6Qh Fg5Fk/ytIXSaVlMjeBbScx0evousxEO1YKUhQ50lhrd8r3UoKcXE6ByhuGKhBVqlhaYxNFiz PItf0pa3a4xCO8p7gOpBUkoirJfRGrbqC+/RY3H+B1psVIWUf1AhJEBcSI1K9mC/fGekbjZ/ 99N0nOJ4BUwQci65ZIUnMWInnrEax6dZly+GXLCO7YSCQmveRgzE2YlRo86dbXkhP6bdc3eI V7tp/QSafmtV8FrDw5f87gwN2wnxhNBBgngGgCv/oIP6MzcfQxse1+610DrhAvtcjQr8MP0/ TNu3JDxySQgro+1nhl5et/mQFe8jFOQ8x+JgZXkf7KRka0nILW4VU2M00xTDNE2jyt9kOuxK Q0Mkhudd8ntU2rEPpAQmKbif0+apNF0ed+0xzhSHWTUnDbXXtWF0Z9H8GqYSumnbv8Q8LKqe aq75OrGw73F+BJYbaJxYrNIb+D1alGM9L4NgTKk+7vJwK87nIat8r6Rjz9K0aLT9YHrouyyh fEIT2GeS9BZiJP37jSMvy/8A+ckZvgHKn/waxucC+IEagSAkNLor9RnyGvvlGUH20l+hAjv+ 2FdetuQTJnKb5KE/RdOPIXBPnxhi7JJWsPKLCz9wB/DDrcoVHdzyexB8JmVi+Az/ETasP8Wf RpSJ8XUHkeSlkRqcUMfK2I8TafnyiJEJodRdyluX+viXOv84mn+A5mN1IywsHwl5pBE4g6FV +1R6OBFSiAJk4v1FdL8R4TF/pGOkSzxKAroAglyN/xyjEIGPKAMeyQgUKK/zsYC+M+pmhnIq Jfe9gY49L2CCVEP8hBJYUJ5l6YtopWPPo9I6A2Vmr4Dp4jT7eTSPoOi/0vZTFUwLAuY+SM92 BW37blz/tSjkxgvb6XttC8akDaVF/hnteserLs5pgFKlIaxLRRaKWFPmlFAlDpgLFBebVEbo WsbN4RFSeH4csiLR4x4fChBHxG8OPYTMQAT1+7iabEMrWb8jFLQUwW/QkkJh7s/Tu/1ZE1Kp Id9tOb5kI3yXtu1MBTv4SMFdiq0xbAmF47+onis55wBauJH5ZOUXlB0j4PuxhzOp2n7tVXrU oG8Bv9Pu/h1af5p995rC5EmhFvhPoyAfYIVKazrYr7jgZHf+4RDvW8JhZvpBc7TBLJrfoCWi 7IrpyOQcCUVuqGgUBYOYPxg7RaKzMQo5cjy/ifuFoSCS8yI/gl6OBEnwbu34Y9X7J/ulcfze kIpzOJ3iZ19J26R3c7lRJwE0uTPUxGU2uZF+zSRGxrOyZBUi2jM0zu+N/B5aL/+I/DJOLQp5 NFpfunvlC0gv1itOloAPyf2yMtgQLqXlSSEbUSB56KOTV5NgPEbd9m20r4+5hnQJT9fYmu3p z4zj9eqagIepa8hwAVnhkaMlqImrQ0eQ9PZJYRgd0ocDNF9FV5LvJz8zOGiF0RIswD+G791n D8mzepVxGERrRr+ZqucijE/HrUXl9UwZ3v8OQSBUSxg+OzKMVVkbjpwaCL/SfJYKUUBl7Etj mSCj2Eb7lymNGkCsVB1oSfV/qdLUCfX+p9L6+JDxkTSshG2zlDIKIhxB+UCECrbqofIp0jtu ZMYG0LNLf4MK5ZDe4hNom3RE3VtrQv5/BRgAcKtc5z2U87AAAAAASUVORK5CYII= --------------6D15056F6745C98F7A98D5E2 Content-Type: image/png; name="fr-live-2017.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="fr-live-2017.png" iVBORw0KGgoAAAANSUhEUgAAAZAAAACGCAYAAADzR9z+AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAACXBIWXMAAAsTAAAL EwEAmpwYAAABy2lUWHRYTUw6Y29tLmFkb2JlLnhtcAAAAAAAPHg6eG1wbWV0YSB4bWxuczp4 PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iWE1QIENvcmUgNS40LjAiPgogICA8cmRmOlJE RiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1u cyMiPgogICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4 bWxuczp0aWZmPSJodHRwOi8vbnMuYWRvYmUuY29tL3RpZmYvMS4wLyIKICAgICAgICAgICAg eG1sbnM6eG1wPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIj4KICAgICAgICAgPHRp ZmY6T3JpZW50YXRpb24+MTwvdGlmZjpPcmllbnRhdGlvbj4KICAgICAgICAgPHhtcDpDcmVh dG9yVG9vbD5BZG9iZSBJbWFnZVJlYWR5PC94bXA6Q3JlYXRvclRvb2w+CiAgICAgIDwvcmRm OkRlc2NyaXB0aW9uPgogICA8L3JkZjpSREY+CjwveDp4bXBtZXRhPgqyI37xAABAAElEQVR4 Aey9B2Bk5Xku/EzTzEgzo977antvbGPZBkvvYDBuuJfEN/nxHyex48QtiePfSRz/jq9rANvE BVwwGFhY2rLL9t6reu/SSJoZacp9nm90xLDWGrjGDnH07o7mzDlfP+e8/X0/G4AEP1MwtQJT KzC1AlMrMLUCb2gFnKmlXTY3HDYnKcoUTUldl6njqRX4Y12BsXgYcf4T2BwOpCXcgN2G0Yw0 uIZHoUtj/jQ4wlE4R2MGM+i3LZaAa4TXYUM0zYFohgvOEMuExhBzJX+bMmzDlkgg6nUhxnLO 4TE4orGJMvaxOJwjY2yFXdnYVrpLTcI1xHOsF3faEXU7YI/G4WD/NqKmuIPlvMRTDjvrRmEf i5k6CdaPs++Y28452GFjHY3JHosjoQ4IGkPMk0R7GovaNX2zzTFfGtnpBNKCmhf7Yd9aixj7 T5j2YnBEYqaOdV3tJVwsR9B8NWYb56Rjgfq2QP3obFxtqRw/BjQnrZnXwUZYanysGr8jEmd/ nN84aP4xrQnXW+XMenL+mvsY105Vdd/0W2DWi3Mw91D3h2soMG1wDTW/BD8OtuHivONOB9fB Zc6Z+xkeM+NVfY3NHgwhFg2ZNvRHvZhZiHDEEtGJC1MHUyswtQL/M1bAJjRA5JBIvILs3ujM JxCJcOnFzaTz3MgbbfH3UF504/WiuIvmQdSOV9A4fxB/Y4yfcZiYv3XiUt9Wu/rW56LxWJdf Vf11N/6qWm/8x+vsx+ZMQyKaJLKmisuWhrHEKG6c/nbkpucjGo/yedKlKZhagakV+ONcAXLr iRgOte3BqZ5DZoqFq9fhyqF5gN+JXTdVYvHLbUhrH8XOWysxo7YfZS90wzYUx8mPVhObJjD3 O/WI5znQN92HrddWYOXJblT/ZxvCM93Yf0slMsjhz3+yGe4jYXS8uwBPrijG1Wyz5MUeBKu9 2H17JfyUIBb9vBFpQs+1cZz9UBkaS31Y83gDfA0hw5WfuKEULnLyM55ug4vcfawngca7irBz bi6uONSF0pe7YSc3nyCRCs7w4sLqAjSVZsAVjmHZng4UHOlHIo3cc2MMQ4vTcega9hFIw5W7 2pB/oB92EpZoRwJH/2waBilRrPxZA9JbIxjLd1IysOHstaU4WOJHKedTc7IX5Xt74OyIYrTQ heZVuTg3LwdDaXa4R+PwxhMobBlCRmcETkoQ+XVBuMT1k6g6wnFEYzYM5brh7RqFm3OP55M0 jXA+mwqwc0GeBAL4+HFTIph2uh/lu7rhGowhnm03UoVjIIaOZVnYsbYExZQOlv6qAd6OUYQD Thy4tQLFvSFMu78F0RpSOI7FHoojVO7BnqvLsXRHGzJPDRlprG9RAKe4fjaPHR2ZbsxvC2L2 P9Sh95Zs7GXbYUpDK/Z3oOgXXRhemo69N1YgjQuVt+Uodj/zPdjd6YhHRmBkOUkfIiB5GYUo 9JeQgEiknCIgf5yIY2pW/9NXQCoHvd8iIP7ewMRyeLKzURwrRnB6JnxlZSi1EwH54ygoIQE5 70QWVTyRQidc1TWoONuPwsIo2ASCq8pRVJqHaWfsKPDZcYYEZ3hJAarO9qGIBUbemYG+TWUk TmOY1z4MR046ukk8XDVZWPlME/K9xYYwNf1JAYZYb9OhDpR25CBSmYZzN5SgjMSqam8XvK5i hMvTUPeRYtTNyMa6piAWtIXgdqVheJoHbctz0VqTiSEixBm9Ycw+24n8tgDsHh9GiWAHNgXQ sLIQXqqQbjnXhwpeS7N5EclwovG+YtQuLcS6s72o6hjGwAY/mq4oQl+Bl/jdhk1dI6g+04Ws Ux7EfWXovyKAjkW56CjKQIDjm0PEXUwi6+sKw9tDFV+I6iQicFfIC1t/HKO5TkTLnBitdCNe SOTLVfe0jcBznuqgTCD7JFCS5yFx8aAnz4s6fnqmUYV1WQjTX+5A7m4SwUwSkSIbAsMuRNIK cHRGACFbHip+1AQbRRd3tw8tNaXIXu42xFPEz+4l0Yo7UF9cidBVhZjeXA+HKwHfqBdNM6sR yqKqkmqrLEc/iorGkBFKR1tBOS4UkwD3B3jvPYg6XbhQWIFoFue6r9s8LzYXCVSEKjT9smwe IhzR2BjGpgiIWaSpP1Mr8Me6AtIwxIjcRUQsSMRiGKM9onGeDwM2HlOXHpzvg7tvGO4zAxiL RjE4zYtofwh5ezsQGx3FwCI/9tT4sXpbA/K+3oL6/6cEW+ZlIkIVx9WnOtA7z40H76rGku4R LP3JeTiOhdHwwRL8mnXe/mI9crd2UnJIoO22fByanYk1T1xA/kNd6LslC8c3FqOscQBlv+6E YySOnhUB7LitCn3U9a/e34LKrR1wNY+i5do8HLiiBO05bjhJHWfV92LRw5RgtpMQXBdA7U3F 6MxPx+ksD1bVD2DZMy0IbBnC6BISI9Y9vTgfQ2T9b3r6Aop+3onmW/Lw4roy9HocWEwiNf9A F/J/0oPRuWloWZWNpjnZOFbiwyDtFqvaScR+2Qj/E0MIb/DQduTEMHlvr4241OdA0+IsDFX7 0Evi2+t0ooX2hZBsHewvcziKyj7aoGjTKAyGUXSiHzP+/wZU1zhRvikXx0lMt5WQmFxfgkVl aSjf0QU3pY20gTDm338GsXur8fjsLDivGkLVL9qR92wbRgcjGMyzI2vnEGKUDpFOVqGNwkFD H7YsLUDWhkyUbmU758dQ2DGAI/5s5A+FETjahUgebSkkhGlDIwiNusx3ND6KGCUgX0cQbbSD 9BZId0eaMS5fGAKSNIUkuRI9WOYzJYFY79XU99QK/NGtgCQQ/bPefU0wPRLF0OwMXCjNxKIL fbCPJrD38lJMP98PG5G8TSqiigwUEkml1RNB5rhwakMpqokEy3b3InJFOk4tK8TinjCqDnUj /XQIh99ZjXKqdhZvbYW3fhT912Rh/7Ii3HqoE6VPkZuN2NBzTQ6O8tzaF5qR/VAfWv5XKQ4t L8SMM30of7ILNqqf+ucHsPO2agRoxF732Hn4T1KSoTqr68pc7KF0EyRyK+uPIEICMlPSyvYI pYoynFySjx5KJKOc6pVHujHrwUbYWajz3nzUrsjH/vIApgUjuOqhC/CcDqP+Q+V4YWEByqiu WkcVV9Fz3XAfH0P7vbk4uLEUnQE3emk0X9RJieREL/J39cLmtqH+M+U4NScXozS4R0VAOOcY JZBaOiNkcJzVoVFUE/HPaRgwhvyhbKqxKJE5WW6IhO9gWSZiFVlYMjcH8x5tRNXXWpF7ZRAl JB5nOMbHV5Vg3uwczDrRg+LdPfDWRjB3SwsG7vZg/5oSqvYSKHuyEyXHBzBS4MaZD1QYlVfp oR4ESLzzW4ZRMydKolSIrNphBLh+RUf6cLwmGxVNQyh6sRfxHCfcA3EU1lEFl+9DVkcIJEGI UbxxcF2jdFoY4XwElpF+nICYc6/8Scq4r/yeOppagTeyAuPcSdI9441UnCr7X7kC8oiKZjoR IXfsaw/BezaCKurz3dThO5uiiCzzoKXIh7mUPpxtMbTcUoAwPZ5WPVQLd9Momu4sxBCRzNqf noeT6q8976pGO5H32hebkbt3AJFpbhy6thyzmgdQ80AzRqspAVxdhOb8DCw40onMxwdw+vOV 2LqoANfta0f1z1rpGQb0z/Zh1w2VHEsQMx5uNvYQGaB7FwZwaFMpBkg8atqHsJC2lIE5fpxe XwzPynycKfaT+NgRpoppDfX5M7/YhMHb/KhdW4hj1ZnopL1jPSWcWY8203aSgT1vn4ZWSgpL Lwxg5kttCLw8hNB8qsY+noeDq4sQoeRQ0h/GEiHjJ1oxPCcDp99eQRsCy5AIyKmqksQzl8Ql r2PEEIiVfgfcrWGkHxyBq5u2ZRKVOCWE3jk++Nt4fm+Ytng7Zl+TgVN3VWC/VHD3TkfBbWH4 mkdQ9nwnKtK7EKpKx4Vp2XhyNQnJ9CwseL4V+U/1YXFuM567qQo7Scgvo8RU9SzvTZCSYqEX Oyoz8Taq8gJ1JCDP92Ix57b9skJEsylFkDnwDowhQFtLbUUAJSsykXN0gJSBajdKRmm038jO lXAmX2ZL4ohzPQ2Mv+OTE5D/yqf4j7hvG33qyMdJZ/jWBbEcFryi3Uh6jOihkfLWGr/K6ljn BPqtY31U1nIpsY556jfAKpvatuql/lYla1ypY/qNxqZO/E4rEE0gRhXMKJFEnESElm2M0r01 Qa470Qucp0rJzWc4sCuI0BI3mqsCWPByOzw0CI9mOdFVHUAdXWQHZvqQ0RJCQ44XZZRO8rb3 IU4p4uidlQgMRDCLOvsE9fPnrytBW146Vj9aB9/WYTR+vBjPk/u/YXcbKqmSsXspncyjiowG +pl1/aj5dhPiVURZQ0DP4gAObKYxPNeLpbS1zH2sGb4zsic4cJYcubvQYYzXfiLQctpdqp7p QN2nynB0YR4G6L46q3MYa2sHUUgJouGaIjw/Pw/zqL656ZHzCJwZhrMuis635eKIVGOcv5fS 2cYn65F9eBBjRNQ9a3Kwe3kRWjPTkEmpqJT9lLUNo+LlTqRfCMNBtY+DDge2PhLlHAdtPrm4 sCAXLpYdod2hL9uDdLrVlpFYeeQiTYN6lFg6g+9DlCqtgyUBxCmR5C+i3ehwJ8r/tQ15S3tQ cUUedtHI3Usnhyu4poW/7MHqIi92kjAc4CdAolPweC+qZ3djd1kAA9No/N9C54cM3k4ShjgJ glRrCd5Xd88oClpH8PKMLMxYnIO8HXI2AMJ5lNh4Xe+x7pPmUkCieG4eX8xAUoVlrP182KYI yO/0xr12ZRm3RDjop4DoKF9Muv45pKh9KwKHZesmhhZS54OT8GvwyYHaBnmSXAsCNOTxGp92 83IwcChZjkXtfFlkuEt4qByhmsBGsVpt6NtG0djMerw9/dBhIosVVXaYZWUkpDrA9BVigfHf 4oT0IqqGKW+1kRza1N83aQVGSfEHiNhcvKeSQGI0mA+lpyFIhBf991nGW2fV1iY4Oil93FaA TBKDnH3kWomUpPpqp43h7r2tRIYxBIu9pD+MqYhTlRNwkFiUIkTEeNkjDfTsiqLrhhwcn5aF q56oh+8wde6Ubs7Ny8VVNKBX/rQNNj+Jx4IAnrm5CjNo1J72g2bEpznNM9Z9WSZ2kKjIFrKg fhCzt7bA00sixvG2zslCBseToNS0+DA9tJ7rgmsgilP3VmLvrGyk87FaerIHs39Iz69TUZz9 TAVeovdTBdVJS+jRlHWEthF6VzW8twjHaXBvp3RTTWliAT2YCh7owdB1GdhHO8xZGplz2McV Uik1DiJwIoj056jjK7EjVuzA4PQMDNMoHiXCbavy41QxDfkkPNms42dfUgFFKK2dmpODTs5D 0gv/YjqN9ct/VEsvtQxsp+dUQ5YbDbTHXJXuRM1DLSh/vAOe4Bj2XFmGl6+uwBV8t6q/3AjH fTE8vaEcrUtykLtnAAF6Wy1dNcxx+lA5x4vMg0OGKYhR/dZLop3r7qOhP248wQKUNjJ4v8Uw jFHK6i4jteEzYNMrp/easSjpjO9p45jzx2NeOFwDUwRkfCHezC8RDLsINRc8GmJQ1gAfqDM2 5M4YgX9aAsN9HnpNWLfgzez5d2hLDws5mvZr8xHhg+4iEsijPjVtiFwLH5rOtTl0FXQh92wQ forE4WI3OtZlwkm1Rz5FX1ffGHpWZaJ5djaGaSiUi2LZ2QEUvtxL9UA6ejdSnSDETxHeADlc HeWdoGqjyI2+onTknR+E7+wIutjXCFUC2eeDyDwzRM+fNHSuyzKumkX7emGnO6QecNNAsrWp v6+5ApJ+Lwad4cdQcnKevO+dlBpqqKf3nx1GnMTfySC2Ma51Mb2WZjaOwFcbQnghjakkFtP2 dRG7JOjF5MDJKwpRQjVS2b+3YHReGp6+by7cREyZtC/s+1AN+hmkuOGRWuruw+hf48fOK8tR Q9fRLCK7KJmOCzcWUe1DQvHTFthy+c7QQH1kU4nhcGfS6I0sehT1xTBYnY5dV5UZxLbppWaU 7OiBg8Z/kNtvvaEA+yhhCBsvpTfVtO83kwmh5PPeahyamY1C2jWW085SsKePBIZew58oxsHF efDyGV5IFZf/HOccsKGbUs+uNcUYITKdf6Ef8x9tQsaREAZu9+PolaWo57NaNDSKZdtbUbCt F2knaNu5MxP1f1lCu1EcvXRDbqzwo5cEomhwFBWtQWw618/gyCgy6TXmHOQ7RUlJCDxGaa+v ymeYNgVAZteSEDXRk6s+jBW5LvSQ+PT63Ni+MB++q0IoojRR+IMuLOGaP7+xHPsohS2i2jG9 NYRKOjecpGquZBW9p35Cd+MVvTi+vgwdS7Ph30WxjcRc7tCDtL/EyZzZKFk4qcJKcL0cXBtD LMJUYfGpYMhm8tlgnIpctb21I7iZkmF7ZAidvKKgTikDJicgqjsFb2gFUiWNWJSc3ElyIt1x BJbFMWtdJ1Z8if7vFQ342b+vQV9DOjy5coF8iyy0uAw+zEOlfDnXlWKYhkCEYrhpYBTePf2I Uh1wehndBvni3DbShKyXBxGi/vnptaUoptfOVRTrQwv8ePr6KhIh+sMTcYi7usCX6CqK5xGq DLZQrUAPT6PV0sKKXg0Sd91G9Uf/oiw8OacAt6ER6fScOb88H3toOFxT3IeVJ84jnJ2Gbewr ky/Adcdp0A1SmtGT+5sYUU1PwSQrYJcxwSAFXaREN/GPN4VraSf+CFH6aKTefC29jpz9ZH7y GD2e7qYjjx0l+wfhoA4/6neh7vYyDJCLTXuqE86IHU3XFcLhcGI+bRCOUnLcm4rZhwMbf14H RzCGc/fOwJIT3cjZOoLg5kzsuX2acX1d8GQbEmQUTr2tHB30krriB+fgpLttfMyGpltL0UhD 7rXPNiLzAiOrfU4Mzk/HPkokbhK0Vb+qR852GqTL6S5Ld9LeDdnYv7ECWZSMl29rQdHzPUiQ 8ThzezmOzsmDj8/O/ON9KH2snwTQizNXl+LEzCy4yNBsoE2n4mmWp6Rl74lhgC7Cgz4PVpBo znmE0g3Pdd1RgN0kesOcf4BEYuGRXpQ91otYpQst9xVi7+piDJBxsrM9KRgyqZ5aRyN7KT2n PHUR2kvoljuX9g2Pi0RiyBi9EyQYMk4XnR9O3hq+FDo3RnuMYyiGyie7Ma2jE4MrMuC8k3aO q6uxkPEoVS91INA1Bh/nPZKbjhevmYZ0vmdSDNjcTpzZVE5DeYRMHI35vC+hDDKsmRx3f5Qx JlS/lWcike+G+wK96SjNDHjd6JqXh6Jd/Ujj+5hOZ4SxHEoh5PgUUa9oe08XVY8/bea82rCH d1fZAy5NQPRivkVwG0fylgY7nxYbuelomFxT0IGhU/TTLgxhybuHMWNhC2YtPIui8nqkZfbj 7L71qN2RA08R6TvX1wT+vwXW2eBhPigDNLzJyJdFPe0gCUGYD1mCz7ZARrVCcmp6QaSyUBqG HHIvXp5PUIweJPFppyh+ZT310T+op+tkCZ6gZ0370lzMeKgRdw5dQJxBS/uvKTftLX+6yUgS 0jf309URbMtB7kh4zsU2S/lCdNEHP0hDpURov/pS32awpompP29gBUbGho3brh43LaEISJyR 56MxYqHxZU2EQkSgPRgIDyIYG8SIh5LjGNUzTWMYtAVhT4uhaTWJeyFQ1t1rzo1FI2jOykX2 iSZEOnowSM+s+uwxVO+thZMG7xOfqUI02If03fVUj4VQN50cdXgA60kAYs8H0fShAjzN9q49 WIexc3QlzXUglJ+Go3lx1BxvhPe5egS95IjDoAdRNi5Eh3Dt041wvdiHvgoSj5ERpvBw4PDc fAwOkOHY0w4/CdswuZWeaj+O5cZIALqR2xWC/6VGBDMiuLDYj70FVNv09aCSNoicnzQhmEv1 Mt/hrpWZOBegi2tdKwqfbECsaRj1q7JwdJEXwxy3g95oJfWUnOgB1Uc6Wb+SRvu5RNDD/cim hOQbHEN6XwSlDALMOhhk/IkNdZvzcHZBNt2CKSlEnche4L40etUN4vtUeprEjswbplMKPBxE ZcEoGqnK2lXpQOvVmQhQkgHHj6ANLuIfIfRCSi9jdOttIoGtyQwhRKks0uuDs7kTQ4MDiHeG 4erKRJBxMO0e2qZcg4jVU7hr8SJM1934GJnabAfyyaQV0gHBMqDbpLpmd3ILTgyOGyMNAruU BMI5TMFrrADXVHaNUI8DkVMJ+JczUnZNF5b+bQcNWPW8AXvhzmEbSndAJi9MI+Tj9y/FWJiB WETEo702ePkQx+Xz919NRMRpDFG1VpmOAXIbM1uHMUbk3UOOtJAvooiKvDAmBCZhIIJyF40f muucJsIMSnKcjaLkFF0wK8nh0XDn7h1D3n6qKqijtl1jqiLnXBDOTnql0DZiDLY8Lb5YoHbV 1iC5qY5FVD3QbdH0RdXgFLzxFZBbfutgIx47/yMUeyvoXvpK/oyB0T7eWK49lz64dRvizx/B tjIvjnSHMHjMg3C9EwWn+vFr3psQ3UMHdlFt+UwYjbR/dLeHqWpk8Nv9aQxIjOAAVTQjY24M f9eF0nOdOBjwo/9HtKlQxbSVxt1R5m/q2eJD9reC2DYcQiSQjuCWNHi22nDowiDLMwCvJY4B 2k/CX3chTKmlkUGCytU0kktbzI/TkdUwiN39VGtmU+1zhKpiSgODRR6Evu8hUh3C8a5e7M3K hq2VLr5RP+zHWIYR6aN1A1S9sB16hfU9ydiWR6MIUw2TaOjHaS+DAzvoosoI/CF7JnCAxuVj fXiJeUZG/HwPTjPY8nSCtoeIUTsl2tpRhwC6ymjX2E7p4KmIUel4OiKIDjWDaB9N8CHsZ7Ch i+M84AF2krAwd9gAVXNNbimJLgF6xDnfI/wKNAfh7Wd+KqrSnPePYugJLx0anNjnZ3ssk/Yk qao8pXh/HZzjUHMv+qpzMcbfW7oZX0LVc3iPG8+yTCZjPWx7yOjVe2kgt+NRrlt27whij9sR 2sdI9bEBzM5/JzzufHptDfFaxNgz7T1xdK7IxhBV1tOe47MiY42B5PeUCmt8Od7olzjlKEXE 0oVBXPb/1mPeZWeRX3wBaZ4g2XW2NsZkbyFSbCans6cN4tCu23Di/hxkruGNKxxG5rJRnHkh F94c6kMnMPMbHcWbU15SxRgfzH56tKSTuBWcH8AA0y100VAYpweJjWqBS4Gu2Cg7Z5NTK6Ve uLYwA7EvzcLMXR245RunOHeuUxEJB7mYODlFU551dBzLou6VOleTVM4iotJt8Vg+/j6Oq50B W/7sIDxUQejSFLyxFZDlQ5kmsr25Rm/YNtw4eQO8MWPMBdIf50NdB6PnRnOyqHTeBnjg4Efk R0hSH5Ax0oeoJQltya8mMarkejGY5KHYqjm2nUiW7RMOHWRFXheQ+Z84JvY1rESbzqkzPTSt PMeP6Vd1+0zvPCBwnHZ+1NQgc0Gif1xsPm1oo1G1dKgtfTgkfSh3GWgVBiQeNn1wkI4Os0zJ +esaX2dhc1VVMUGj+hjjL3L2DvarIeqjNgcoLRmI0+YQ1CfJpUvdQyYeukz0b/hK8ZZq92LQ dAVmPjqgvcZwVBwb+BFzJdBpC9RWs8ZLQimgbJKE8QNaq5JQm/xSXTUncDQk5xwr5BvG/wlq CkR8tHD2jhg652ehhYxC5TM0vFuDS1a9hA1k/OLU1+QrIAP4GIlDRnYYH/rsL1FQc+6VBz3G NAW0H9htydtrdw+iq3EaHv/GLARW88butOE9Tx1BaeVJfGnXvfTMcjG1ANVA8ckepcn7fzPP JvicyCgdLvOgg0FC+TT6FR4bQCPtEP30ABllcFFaG71GLtGpHqh4uh2B3YO4IrcF++mnfpZG xI7rPViaT93ylo6kl5awPwnCxCx5LO4p2TDPWh3oASZ3JSmtsHEIjdMDqCRH7KFaK0zubQre 2ApIVSWJI4sEZGXJBuxpfZGpPHx0fBM641pTjTVhXifnaqPOXKAssjFym/lFBQj4fAZx9PSS w+2nDSqNGFzqRt4TqW9jbCObaVBy+YmLQ+U5615LsrFRZTIWjqCluRUxqlfYTTJjLQ+Ky+ga 7CFKJYOQ4DOhMpEo0SHvtV3cdSyKjAwfCgrz2S4fVjY/kcWW4xyj2mVgcBCDoeEkcqO7rYsR 36XlZaZfjS84RMNvO5G9nkH2WVJeyj7dGKH6q721XYuQVClrraie1Q8xVXGOIzc7F1l5OWZe vMJhkiNnW6EI+7OTIeI4y4uKkJZGSYnX7Kzb19uHnl4a90m49VrHKJUX5tOFl9JUUzMpDiWy wmLO2+1GN9d0ZJht0clAmQDcXi+K8vPh0FxT3xe2O8a1GAgGMcj5aK30MmlMZWzL9M97Ytae 51RXYKO00dvD+6bxMJdVjL9NPd47o45muzYXKeKoiC5b07ypvh6kK2+chnq1YuOahDgH2cRs 9VrEVyD5tLzye+rodayAnRz30E7g9h+eQUHlOUoaftYSwVASyhHznJtmlBqbL+/u59eic0cG 3DV0IfxID+Ysfg6ezDFs+mA9fvmns5Czni+rxRK9jv7f1CJ6gIIJjC73oIsqhlzaHkarPDSO xhBKo08/8/YUNKdwe3piU8D85FMWp6tm/qM9WNsSxlkaUevK/NhGw+I6Ioyqx9uRoE//pSH5 MpjrLCaV2QhVacUMYhtk5HMLVQUhvlBOIaff1sylO/gffUUEwkW3wPLMakNAIvEQz6QQDmt1 uL4JIW+COOaMjAx0tbdjgnvlORGKvr6kvCHkIo7VnCOCEpJ6LbBR2pbXjxBdnPe5uYnixkUg ZDjKNClq30uEOjQcxBD1+78NcnJy0EtkbNWtq6t9VXEfieAQEa8abWpseNU1qfgM4dPZ5PQ1 LWRlZaGHdgZ9LgYPiV44TCmEBKup4dXtqazq9pPYqr9cfybaWyg+pUBH6yu/rbFrriESiAZ+ fhtkZmZiYGCAuCa5lpP1f3H9ifs2jv+1trrHNlJ4x9grsoyIdpCMYy/f/WF+i+Vz0q4TLKBT EGN9bNQYpL6DUwTk4pV+jd8ymo90OjHz7X1YseHn5gGRcGqzSYgl6M4QyUl1ZUsbRsvZJXj+ uxXwL6O7Y1Mcm99+DJ4sPqUsvu66Z3DoNubpueBHmp/62P8CVZasGLJB9BXQM4zMSTvtHsdv nIYccijinobL02F7mW6PIjSamzgbEQM9R0I4PLRRgum+LAtnmTZiJrOjLvv388h4fyUOzMlF A4OUinJ64OFDmPrgaaleATZiAYUMEZA2+r2nM09TCYO9jtJX3s2+THSsVW7q+3WvAO8cpQQG g/mKUe6bhqahWsMdX2r7BjuJtRDuIDn7f/mXf8HGjRsNsnr44YfxpS99iUn36BxBwiKwjj/1 qU/h7rvvNkjVQmy6LmLhYuK9lpYWfPCDH0RXV5dp2yBzXv/Rj36EWbNmkSmPIRKJ4JOf/CR2 795tiJeDXLnGcO+99+IjH/mIaUflDAFiXV1Xu1//+tfx/PPPT4xlxYoVZtzi8NX3li1boPGl p6ebdr/3ve+huroaR48exbve9S7TnkV4NGZBQUEBOjs78Xd/93e47bbbzLzUlsbzb//2b3js scdMexqP1qW8vNyMX4Tll7/8Jb7whS8w2WQhJSS6t9Mx4R/+4R9w7bXXGoKo8ateE4nnn/7p n6K+vh5lTF7ZTOnklltuwZ//+Z8jEAggytxj1lydyqPFuf7gBz/AL37xiwkClZeXh/vvv9/U F9FNBdXVGmh8//RP/zSxPq8qw1dPmYxp0uE+KVRddQNty+gUQaN83lESwDI7/J0hBCpZgMb9 Cff58Vd2cgLCcpd+2VO7/x92bBaNomRtHFd/5TgycolAmdXSZpM6gEFwpO6yZ0glZbOTw6NU sf2pJRhu88BBW9rSe9owe8FzvBEq60FmYQc2v+s0vn3HZcjbwJdcLMEfEjgf0b04gwN7mQWU Q0Zl7QBWXAiiZ4Yfu2cxHoO2kDiphFMqDXFqFG8ddXxQ15AGUhx2iKAw6G+4gIY4BoZlMU9S 2XdaUUY3x4MzckydGO0dtr7xh1vP1m8AT/K/ZZI3ajH+1uY3RfSfP8D8QNIbi7BMwf/dChhk 4vRgXuGScQJCF91L7P8jAiJEKGS5YMECLFmyxHR65AiNAQQRFwskpQhEBBYtWmSd/o3vaiJs IXCB3+830sDmzZtxxx13GKnBqrBhwwZDQFRWhEhjqKysxOrV1P9OApdddpkhcELqn/vc50wJ IdW1a9dOlBaRe/DBB3HmzBmUlJRg5cqVBrmLIFig41QEbM1rzpw5WLx4sVXMfIvwiIBIBfbu d78bV1111cTcVOD06dOmnIjQsWPH8J3vfAfve9/7ICKQClrbZ555BnfeeachZrpWWlqKyy+/ /FVrYtVZvnw5tD7z5883BEr3Qeuk+aivS8GJEzQ8EVLv26vL8r3iCyZV9vDcdJwr9SOXBMTR GzWeV3mnB+G+rABjRXRy6CKSSGPtcUmNPOcUvN4VkPQRrHdg+cc7sXDF00kZ0JjOuIxUsNqc TL9s7BlUXbnGcPrIOmz/dhkypstbZBSbbjsIB61oibgeXIq/vBdL1zyGRR/uxcApJxxpf2AE KYJIriKa7TSBfOJEKg/3YNo3memU+x5I2ugKUFRnBs4cukF2MT6kkSmsa+8rRz33XOiVlEAk 7zkTgZeBSC662nZS3XTuk1VoZC6ibpbPpOeJp40eHfRvF2g3OX0mgFOWzUOcjb5FhJVmQb/j DGzL3DaIKqaJkHeYOZ9SdaKNqYPXXAGpsez8VxqoFK+DUaqx7ApeugRYnK+kAgusY9kBLLi4 nK4JsZ4/fx7nzp3D2bNnDYd9/PjxVyFo1RfBsaQVq52bbrrJNC3O2TonLt7qW2qhbdu2mY/U OAKpdN7xjneYY/3RGEJ0SRaojXzaFG644QbzW8TRumZ9W+VMgfE/1hytfiUx6COQOsgCSTtC 4romiUFg1RHxeM973oN77rnHEA/NQ5LSj3/8Y9TV1ZmyM2bMwF/8xV+YY/1RG1o/gVSFL730 kvmkzvWjH/2oWTtJcSJ81jzUvqQarbnWX9+NjY1oGFexWeVM4+N/DLOmB4LaPVcX43yoplIu tF665IcryVQy5kqSSV5LMvV8vJQqAvGC4+/hq0liastTx5OsABFcM3Pi3HYE8s4z0oc9+aAO 95XBmcbUAF4mgHOGmVYZ2PrwYur+XYwNAW76XD1q5u/hE0KfcRuJByER88CdFcbmu46idtta xMbIqfOOSqL8Q4EChYYZzEWTB3JoQPfRfW9sAbcw7R7DtHZ65dCVNsbUDuVHerCg3I8LTBy3 hxGwfnpm1ZCoVB2jca7Yhqyjg1hd1Y9z9Jo6dEUp0tnuYuUgYrSyg04HUoFJ6ap8PAaEg/QQ kpba6XTgYXoHxXvYyAk5GAWfyQCnOPtw142ZfEFtTKnhon0mqbhlvT/gGpnx/jf/Y6mx/B6m TC++CjtbnmXgmYfG9CSyutT0hOAtEPK9FFjX9F1PlYzUTuLoLUIge0FHR9LvR6onwZVXXmkQ oJC11DxC9BYnLURqtakxWONQGxs2bDD1P/vZz+Jv/uZvTBuyOdx+++1GvaP2rboiIPp98803 41//9V9NWeua9W0au8Qfq1+VtYiKNUZVsYiJ+rCuW3V0fdOmTROc/969e82cdV6qwL/8y780 4xQRqqmpwYULF8xvq76Iwfr161XcqKCk2pJkKAlr7ty5kESofq3yImJSlf385z837YmgaNyt 4/aWtrY209akf4iSEtREuLmRVgHT+Hf5yQTzdtubGFi5OQNHGHQ5k04t9t18iXnJcgF7QwTE rrDJV54ncotJjtEE0/GZMNwj4xqEAOWpNMHg8Lcpy2+B2pEbrCDO8Uj3/6ryumDqsJ3xdvUc J6hKUR8Cta1+BZbqyEIq1nj0W1GtSregYUu9pHrqy0LSr9fu4HAn0LONgXJfbMCMedtJCLSK Ye4PTPWUN4zWBnpCsEzlfBrHiOcOvnwjjvxvRsCuAgpnBrHu+q0ch+YqQ7tGLSApZ9nZNKqX r1qCupczkV5E1ZdiQ/4QIG6fuafSGWV6xS/qtEzcRIaImyonL3dUW/VYg9l72s2snR4+WGsG maNnZgZzVtGYxgjjDKaFzmDahRhdfdNYb+GP61E1y4cofcbtzAjqZz4ebzf92BWCzvtsJ2G4 7NEGMzMdG0MqA8fKX+jAPdzlTT7vdmYqnf1sK2ro+57RQ2J2WRrTVXTjaorR4pbsw1wfhdwm b/0fYpX+aPqQFOK0MUYjswJokRTC2AD+0/k3E4T89+/fb5oUAbE4cp2QGsfi1IU0BUKcUgtJ nSWELLXQD3/4Q1RXV5vrk/0R0nzqqafwV3/1V4YoqN3c3FxT1EKo+mEdi9OXncIiYpO1+dvO qR2Nc9q0aYb7l/pJEkZFBdeSMExPKktFl9qOpCMLLFXS7NmzjQpM0olUaprnwoULTfvWeK06 ui4p46//+q+NLWbmzJkTkpDKWFKaVV6EuLu725SxnB10TYTGkqCssq98830iLoh57Ug/G0bh UARHCnwYYwaICCPta5fkMbMEnxTh6iTam6j6ugmIEO5ID7nRkWRnUp96iOxcTB8ZbKC408TA lhzudDWDEcVE7JEhbs4+QF0/dWWODHKSOXQbE+Fg9XAfA3ZOSKBmSuG5vBZgoA/Lj/YnEY0I guq4/PQO4jkXd0WLM6G/k5nQnNxhSzA2YsfQIVJ9HnunM9lXAWfHtoWkh9udGDlPrx2OI2OB PJz4knC8KjMWsjM6k8FxIob871W913h/RHTUX8EVw9h0y26mC2AVqm5iMQYldeQjr6SJiPNE 8mHlgAa6CrHlwbnwr+I+BruBux45i6zitldJH5qDYb8djIw9uQ6tR2nEzuOrnJxe8vIf4K/U Rm5y+0pGp/WTjUOGcbn4+ZmGmopyg7CjzN3jZWqTjBd5jkGHYMJEJTaU/UREUFuGuviQaItQ Wz/rcCObuK6LeGhObFPJ2TLrkz76lkpL/aeTWGVEw6Yfqal8THNt+mWbioZNo3jkrkupp/s8 BW94BUQs4uTYCn0lqMmaiwv9J3+rMf0NdzBJhVTiIWQqBCkDvKQFC7kePHhwArGLCMh+IQIi r6SLwUKYlmrKQrhS+/zqV78yxYUorXJS/YgLFyKWwVqI2Kpzcduv9VtqIdkoZByXFCBiIsSv OZ46dQqyUVwMqURFSFyg8rt27ZogrBqvJIuLQRKNJT3IDiUpS6DywUt4aol4CFKJRyrRNhcv /qP3SThQ7yi9rLTB1QwGTfoODqLzhjwcp1ZhJvcUSWtm6vkMFpJb3vg7+LoIiKQHl2cMsza3 wuMjtiCWdjhjaD6bg2a6p66+tw6l00PoaUvD/l+WYKSbQScrGQ5fwcAT+koPkWDU7eMWlcNu pjWwYcaGTsz98x6MEbFfOJyNxmO5qF7ahdxiKuIockhCGAm60NviQXHNINrqc5CeEUJfWwa6 z9NoR6RTODuIqz/QCrkw1x/34diWYubRIXFojGPR3S2oWcx0DL1OHHmhGHnlI/T7juDwr8tQ OIebtKzvpxu7C05HFMeeLYFDtr1LERGel22ie6cT937/PEqmHSVRpIHPwf2A7VHklzYR6RNJ Uhpx0vVN7ex+/kq0bKNnVTkw//39WLb2ccSYVDHCbS7T/USOhBhTGjicdJmlx94zP12CoTo3 shZTBxkmcbvkYEzVN/2PkHh83M3WZOAc7yFGBC6Kr3P6CLkrmyfyWIBSgHJSkaE1xEJDFuGJ MiARes752xi9RTxSQFyOILUfSRRK9y0JQ/V0POH1pXZFgyapZxqa+vOGVkDSRprDjbkFiw0B kURyKWP6G2o4pbCM3kKQQuL6SAqRPl52ChmlZcfYsGHDhLpKSF52jQ984APGS8pSEaUSH6t5 ERXZSYSsRYQsxCvuXl5TAqtfHUsNpHZU3nIGsIiLrr8RENJWXREkzVGESN5SIl7yoLIIiEWg ZLy35qJ+rH4tA71ltFd5tXkxyNlA9pPp06cbbzGrrT179uDXv/61KW61oR8iFF/96leNNKQ2 5VmmccmDTWtzsTQ40R/nxNRlZtfHEe5/0sT8ZzXce8W/g270TOMigX+Y8S4RZgMYYrwY6vVO 8iR579ckIEYnz8klyKXe+N5tKK06zRwrZECJdJ979GZceXcUKzc/yQ3WideJTC6/djnu/8x6 bLzzKFZs3IowGcc09tlSvxTf/tQ1WPDOHtz23u9wMpox3Ubrp+Mrd9+B9bcdw9IrXsAw7WJq u72J+We2L8VVb38eA7058GVy5y97AR7+1u3obPDiw5/9BTJzGgzHnrgd2HX5rbj/rkV493+e wvrrH1b4hTFYT5t3NQI5ET5o3Tj9yLV432dfREHxAex78UZEGS1+9KliDoQ3T9iL/y8GO/cP Huni/gFv68dl618wl20kFsGeHBrMY0gP0B+bLLYrjROiNNFWOw9bvzMNGXOoIuCmO9e98yA8 2ZSwBv1wurhIQrKjIpJ0ZXCO4OjeG3HwG3nI28Skg/RwcNAQb6PdxAQKXTyY3+PvVIRudWMh dI1Z0ejypqrlvsrKVZXbQH91ekcpg2rxS0w1Mi5pGNdeq4FJvs0ysz0RhYn2ue7m2Cr/Wr+t cm/0W/3yI5hsvskrf9x/RUA4e7r0FsHnCmCIua6UaDF1a9vfZQXENUuyWLVq1auaEdcuEJIT SCIQCKmKgMg1VZ5UQq7Lli0zaiLL60vlLAQrNdQjjzxikKOFqGVovuaaa4x0IFfXVFD7Tzzx hEHu8m6SK+2lVTmpNX/zWATk5MmTkM1Crs1S02kMMk5bhu/UWkLYltSRet4iJJc6Z82ruroa DzzwgEH8Vtl9+/ZN2FF0TuttlVdfF3uMifhYkpwIymRE2dgnJewRX/XekIXzTCmzkAk15cQS JaHoI/5f1BeCpz2CumXkHnewX0opr4uACLdGqbbKLIgiO/80oz5X44mHFlMSIdJkDoOr3/4Y 2huX4tmfLcf8VU1YvPEprLmjgno7xkYQp/7iGx/BvOV1WHzlM7jqvbOwZNUu3sBCPPXwVcjO Y379QR9izIeU7o9gZCgfj//oVmQwxUUvpZnsrA4amUnw9l+FhpNevO1j38fGW48jSIkms7AB O564HW0NWbj27u2MyXgUXf/iwtprnkJP11xs/dnlKKwM4fjOAtz64XPIyjmJjz/8HCpqDmP7 ljvxyFcWkshQfZNFnTrVNZcELmDoRBwbP38WgdwujAxwQIzi7e/KoMSUVKskiA1tUhCSaL34 +CoM1NIuQtXnZe/owOxFL5CS2GkfIdWVzYYcuYNqGZtrBAOdBXjy/jmMEWGE+gtO3PzVU4x6 HcIP37UcWeuY4kT7cP6hQF1d3J1+S4LQt9RUlFIOM0JdG+gs5tOzdWURNl/oQekvOxHjzmti NgQOZvbVwyX7ilRbOhaYqHdesnN/a/NbajBKNaYPneCz9hugJvWxriWrvrqYdc06yybFVE0Q CY2fH23RavY0IQ6zVGgTTMNkbbCSnAwMjLdhdTHxPdl4Ji6+VQ+oCia3l+3OMwSEs3zTBipE L9dbIVohNyFLSwJRJ7IbyAawdOlS06cQ/j//8z+bY9UTiNOWpJJKQMwF/pFhWGoa9SOjuwiS bCmf+9znzMcqZ33LfqBr9913n5EW5Dps2WCsMq/3WwRE6jYRENkiLLdYSQQmaPCihjRGC7mn XprsXOp169iaq36L4KqeJB/FtMgIbxEGq7wIoyQxjVN9a+5aX8v7KlVaseroO6HodKKn6Fwn 2hkAXCL1NbezVdJUvZsJvgMBOtR4OkdR7hyArFt2MpECvkqTQMrzZA5Z1kXbQ3TMA39mI666 g547zMrY00KswgI7tq7AZz87A3eszad76z4U0iYQl1qHhmYqPYigiUE4HpeDG53kdOGFRzfj wqkivOvPttMu4kfGV5mFk0glw9+NzXceRGg4Dd/8xHos2EQPEfYdI6JXoJ42YxoNjyKnkBvH d9jw8J/OxI6uAuTk9ePKu85hzrJzbG8ILz+zEt/89HSUs3ILZbOb3neGMRtdqCnsQvu5JfjB PXORvtwGT0bst+ahkvQx3OzEoo9147J11K9yrmnMkSxiUTa9iVIEpxhh8kAnlzEtgjP7r8DL D5TCP4dpN2qjXCe67VKaSkToP+0IIzQQIEcyZiQyYeQ9L2xC4y8D8F+eQN7qIay7cScNcbV4 8cYZDC7MhJcp302yxUlu0Zt6SjeZJpAEM40aoLQhN1qlszAbSIkQULq0cSOh9TS2i/lI747g nr7zxtgeYwZPSR6SUmiXRaiMLpiKF6EfuZvpoeO8LtAObVGqwEbLk/peJz290oZ5DzK0kOxf thURGxH08aHYfBwcZejEQPKE+a3xWsAhTtQTsudLJtWZg10YqUin1B5zx4fpTaaIeW12ldZO gz1vm4icfNoTjMY3hExtkGnQXJy8/7Esjp2nEqxjkhlZY+NPI7jSzvMm4l9rVr/XbxGMwXCf iQdJszG53nhakzerU7mOTha3ISlERmwREEsCEVcsZCgO3lJHiShIWvjJT34yMSQRI4FUUjKI 6/OP//iPRo0lu4RUPZ8jobgYLAnA4twVFGhJQReXfa3fQtCWbUFSltRXArnkTsbZ67wVMJna toXIrbGJyKYSFUtCkdFe6qcdO3bgpz/9Ke666y5DXD/84Q/joYceMmshImGVF2H8/Oc/bwIZ U/uzjicbo64ZJo7vXzyXtul8j3kF9c7EKhzooFt+Gd3zs5iCXtm0E2LCUmByAqIyqS8pf8qD yW6nP35/CXZumc13nNy7k7ECfH/mLanD25Z6sfG93IYyoxuhkYUsy7fSGcE77vseLdW88UdW 4tkHZ2H11TuxaM05NJ7KRNO5HCzYfBiuw1dwEWgUHyzErmfmYmiAurZWum2mMZCFCGn1NT8F 6MYtj8Mn/2MRrvtgK4qnJbDp003IeTqC2ctaODEmE6stw8zFx7FkzVlsujYTFYuZipk2lmiM 2I8QbM1navVDuOv+Wfjh++ehcB0nOc4dmwKpf3hJY4qRENz4nn2Umuhv3V2CQH4DkR0v6jpt Qw7jUTYGagLw7CNL2BzHfjaBqz/ZiMoZe1iWk5fbLtcpPEy3ybAfRTNb0H52llF1+deQ+B8E 3vndM8gpqjXt3vwnJ/Gte1YiwY11zH149T1LHeXvfiz8R8TetSobLXOzTWCgidNgn+lMjli6 pwe+Bu4Yx9TutZu47wPjRqq3cBtTGt0jjM1ouLwAWdXcyvP5LpM368LtxaglF6PcOfmsP5O7 vxVu6+a+Bwn0c8+Q8ysK0JzHNSEUcrvT2bs7zA5qgwt8qGXsiPYTUeZdzVviczmz+gbODeHs XdxciMh91lNkCegBJglC7r7DlV5cYEyKqcfyQvYKeiw+2Y+cvdyik6o1ZiZDE/dzqOVmO/30 b8+gBFXCLTpnvtgGb10Y3cu4EdbiHBJ5KiPVBkF95dUNooAbYomYtqzPR2+lckJRCcQyGmMa X6zZTzSbLT//u3iGyXUlSv3uyc4jZp50MTHfr+ePuFqBjLmWB5UIwMUghCYEL4QroqBvITeL E96wYYPhjlVP0sb73//+iSZEKIRYRUAmA0t6UIzJt7/9bRPfIU5cUo4VzZ2KjK1jxaHIbbiq qspIRmrbms9k/Ux2Tv08++yzJlJc87PGIqJoufOqnoXQdWwZtVPPa46W9KTzGoekjYtBhEbE QyB3ZTkXiPAWM/eVYmhETC0iZNW1pCJ5iVmEStH/SvOitUgdm1VHTJeAVzHK2K3qtuTGbsMz vaij676i0gPcTCzGYONG7hqJ50kP+H7r0ZmcgCTbm2hfyI9OMvCSmx7qycc/fmIuFpBlLLwy hAWrWzDnsqfx908/DaePiTCbMvHiIwtx04eIPNn6tz9zH667ewcqZu/BjLVLsPvZK3D5TY/j 3Z88wcl4MEKv173PL8La6w7DX9iOtTfU0WDOjevXd+L4NhqaqTF6/uEPIkKvgOve90OsvbMd O37FlAyVwK0f/E/c9B6+38RHx3deiV99cREKKjimy5/DZx56mR5blI6euI2xGZQI+jmWT78N H/nSM7j67p+gs+XDeOl/M8XIdEk2F0+YbdJw3rebm+J8gQb5uS9jbDSfqT5ooOGi8f0waz5M 9ZudD3t6Tj+O7b8GR75FYz9TlnjLQthw005yzizLh8CodkiAs4s66Q3GpGskhDu2rEL/2XR4 SQirbgrS0L7NID/eGSxa8QQu+zC34HyImyhN58Ytk4zvlZvzOx5p6owkD3IvkBcYeT6ND4v2 ah7m3gWt3AhqOXeeW3Z/rQn+O8dIc04dpXS59dA9N8g9QJ5jmpENbKOysR1NbyvF1gX5WDAY Rv5wBO184F5aU4IbKf6mHxjmrnXFOMYHUntPSwQ+x/QIYyRCa45zrwombts/PdtsR+rnGKTt Gyaizm+iKzBdeg/zWjYJw8w0PjDCeXwmJUmMcpfEQ7zmobidyWBG7Z7XzqSQRYU+bGD6lCwm eWy8pRDbuDdJFl/cMo6tj9dfmpvLFNzcZOhYPTdSSsMBbiLk540NcCdF3ip0civTdBLCTXRH zt3Rj+6SDOzlrnZlwVGTUmWMYr+Pnnhmz4Qkc/w73ojff3XZP2Tv6A914WjXXtNh/BLR6JON xgpmkxrnt4EQqxD8xSBuWSD7gZCmEKnatDhjSQbybhIoP5QFFhHQ71SkL6JhgcpYxunU8pbk 8o1vfMNEfEtaSb1u1X893+rvaeI5GaSrqqqMJCMCIRWcjNeTQaptxELu8uaSxGQRHcXIWJJN ahuaqwiNCIDmYREZHaeug1VHxOHAgQPmp1SFqTCRmyv15PixMYjzuJ9572KMRp++txNpjWPo WE3HJ76DuXx/HW1kAKZp51BhAKIqqbdo0p2cgKgMrwvi5LKdbubcp85/70s382b7sbR4FNlz xzDcQ1XTfZtxzZ/MQmlFO3WfOXjpFxU4+9Ms1K6tIKfDje8fyEFf0zrc8hEvsnO78Z/3LkL7 PxRiztImciZ27HxqBg58LQ+l1eVUk23kyOJUE5FjvJDF2ApuCPP8Rhx4Lh8nv0cvpdybScS4 MdPOOfh62yew/o4G+LOGUHuyCC88UIZouhcP/vUqbPpQBSpndhHpu7H3uWpyPp1o9NyMwz8q xCNV12Dt9dx8Ppsii1785HqYuVp/jGqK3lCBORESgt2GELhA9zgFSnA9DEHgYUaA6iwa0gfb c/HkAwvgWejgfgkkbP95FnmlZ4no6E4cJFUlZGT3k1AxspMxIxcOrsBL36tEgC7G/du4mc7n j5F4MmHbGFUsrONIj2LT7Ydw8Pv5XP+kbUFE6/cGfEiUPj2NYmsNt9+c85kL6LonF3u573ID c2TNmcH9rVsYUc4yilY3dgE+HyIChUSiaTw/RlVPvyQLtjV7TwfKv9aCfd+chxdrchAsS4e9 gQSH3H+AxGnRo/XwnONL85dzcZIp5JdU02bEYEIfuf4cIuhlP69Hes+oiYB1cz/r4DQvtMmV V4tgrYO+SUTsVDX5OI4A96K47Md1FBYSOHRXFU4wrXx/jQ+Zj/Sjj2lZ+inZrOWLMfPzDWj8 s2L0byhFKzccmlPK9WYAowIfixkYueQndUakP357BU6SgPSXZ3DXtj4jkcj2s2BHO4r29iHm 431hv3aeM3Yea1y/t5v05jQsZrNpgHPkWrrt6YgoffvrBBmg582bZ7h9i5N98cUXjdokFSnL 0P3CCy9McLvikqXK+da3voXHH398wnYgQvPpT3/anNcQFBy3detWw2VL3SWuW4FxqcjS6lfl JdlYoPOWRJBaxrougqaIbBGQ/1uwxmH1o3ZkbxABsIjjxW3L+8wCBQVKDaXcVB/72Mcm3Jil XtO8BRbBs+pYKjARV2uN9W0RI6ucSaPieQAAQABJREFUvlVGeb4k6WmsWgcRPaVd+fKXvzxB jFLrGKcSMl1SKp+mdiCL73J6PV3qmTxR79qQiBgZPhc1Mc1v92GAjj+CuOwmhMkJCB+yCWAj Em0SjEj+/j3LKBFwd7i5jIEgV+zOpHcRVTQ/fOccWhqmU5XshJ/pcHLWxfDUV+cwZxQ3MuFx y+ks/POGTchgzEfGajue+kI1nugvI/5mDMBcB3I2RvEM050/dm4me5JPkwZmRwa5+SPfLYBv sY0Za2148IPLuDDcJ2KhDXV76UH1/WyW0u693O+A+2z4aOiPxd342Uems4UqXmEisPks+zz3 taCOr3QzcOjXhdj5j1fBPYM3oYaqEKmjUoHzle2jb6cDt36dSc5qKOoTsSeYjC5plE3FFOSA KE7s374RDVsC8M4Bpt85gKWXv5AkwERKbi+NPwI+63a6DXNDNbzwq8soXroQbaOh/b52LF65 BdHhTBIPamK8lHJIaGrm7cKmT87BU59kYsP1nBddnn9vMD6lUT6YslZ4HDFkHw8iZyldn5ma Pa40zheYjsQMYXwc43VMfizVY4Cfixy9h0SobVoA+Wv6UXa0B5eTTju5oRSLwCm9KiWOLu4v UHayDfOOd6OIRMdFrn+MW24m22egaw9tJ8y3Fc+mmkqGeVbWgz7e5SvLwBM6FyPRUjHeJWQ+ FUTe1RGEKIFIxaZAqDCfXamccuhJYvMzOyo3LwqsLcIorxv3YNbVJjyy+fhayFZ1kJheS684 tq12Beqfs4CHQZX+PZSYaEtJFFIdRL3xfwfgG8y1dGCYfuPnuk+ZIUcVpPU6QYhNhm19UsEy HlvITeUkRWzYsCG1mEHuSpyoWAzL/iHJwwquU0CeDO+SbnRdqi/ZSgRW269qcPy8hdTl8iq7 i+wGF6t1rHpCpCpj1bHOv9FvBT3Ku0lgIfjJxihD+9/+7d/i+uuvN04DmpfyYn3zm9+cIB4i RsqHZcHFxM/6rQBBC3TO6lfnrL5FQCazPckmJRDRkTTzG6D3kifbAm7MoITubYqYoMLBacwg TgbRz83A9KYFmRl7mEZO4QgrHdHrfvrFdftXEwnSghrq4e5dR/nCEdHaGfDnqWSgH+MqHESY MqLGafj0lFDlVUr0TqNLWjp1oZsYoxHkBvIv0ziZz+HyBRQHGW2hdDPkhK+ayKeYb6veVP4n xjZIP3sdC/F4jEbUOEWDBHVv/Qc4lvlRpG8gYqGx3s54jFA39yE/zhQGrJpWRK6Q00yjxDBa S08QG0Vndheu43glEHDv4jjHypHy82pQFHuk34Gi9TRqX7fDkNgEkbeSIyYHZgbHfukgQIN6 d9N0bPnWDGSQqA3vjOPKT51CoID7K48nWXRyG1BBIs6ki/RMO7XnSuz+MvdYuILzoYrlunfu Bv0IEOzI4LTJzadz60kiMjtp07rrd2H/40V0KvCaNCl/qCDDuJ9rSmLg5jjGiJwlVXBBJ4Xk arAIx1vMPaCzin04WZ2FwQ+5MX9HG1Z97gziNXzMqCarqu1HYzb3j15SiB4SDkWcVx+gSiqT jtG0sWh/6gjVVafvKjPH8o6bvrXNSDzGLsLn4DdAAxgHuSMmKul9woBHjT0sd2ga6NmMAXmB SVxXWng9+EGWH6EKTE3oXJgSUst1+Rjjvtet5T6UU5WWd36QkfeqyDIs2L48B6OzMhClRJNB 21De7j7zjCR7eOv+tZapa7iDxvMLr1v6sJCt9X3xDC21ioXELlVOxEJIUOory1guRLx9+3Zj jLbOSVdvgewMAhEliyhY37K9HD582OR6UjmpvMThy7isMVjlUscjo/zHP/5xYytRu6nX9DsV JpuPdU75rG699VZTX/ErAuuaji9uV4ZwZTWWa7MVPKly8pCSNPKVr3zFECSpti4eu6QbqZ+0 dpJ2BLLFKIuwCKIkH6u/1DGonAiNzln3yCJGupYKNmkQeKKAqekLaTuUard/oQ/HuaPozIEw fIeGEF7KnScZC1LQw3xbLCtboGByAqJr1hNnivHP+Es4cNSOwpUjWHN3DwqKOuipQmRNpO8g d93fl4NT+0tRv81HAsIKwnicgDyyho4zb8yMIWz6cjO9prgZfUz5apTC2Yvje6pw9vEA0mvY Dx8WtWeB5BERnpyqMG76X6cZEMitMcM0Zv1kgYmMl3dYmBHv01b1our9PfTYIqWwBms1Yn2z 2TjVZvGEk67Abhx5opBSlNx4rQL8JoIZPmLDXT89i+xiivqjARIPUeCk/lYlNT5tkiPPoR1b 1qDvZDpcxTYs/0QnpY8njLRhFISmsMpT3eGkr3ifH0//aBG8i+0IngCu/usmGtoPkLJxS9Cc VqoJ8yjZkRA7uRfCKLeTrTyFTfcuxI8/sIDZesklMBjxN+6L+nizQRjXugW67/pYv9VX6rF+ 8nqMe0oX7OjFRorDh1cWozHfi67rKrG4yoeax1uZWQCo+lWb2SToyCKqJGnQ7r6b6quiVpQ8 TvUgnxMulEHMdcwGKmnIRSJQmc6NSC0KoL4vBo1tAviD/6VisyQH89u6rrK81/rSR9Mw5Xgg 6WiQxOSpy0sxTEMiM6pgFvfLzmjg3hkmfb04eDDXFx0EEn708GVaF+1FbozGSUVaqcG3MJDd M8bzs918EQmx3yJ9pHobffe73zXJ/MQpX4yg1I6kBoESBEpNJGR1cTkhOCFCRWsLiQtRCiw3 XREXGYQFIgDKZps6BqUskS1B6hgrFYkIiHI7yT1X2WnFfVvtirAo4lyI1ko7r4hwqbAkAUlV JmRqXVO/Gl8qWNc0HktKsuwLUjcpj5XgySefNN+av6WuOnTokDknLyzZORQvIuImQiKbhvrW eor4KHW9JDYruaIIqlR3sudYUehKkyL4+7//e5M6RXO1CK2I0Be/+EXTz8X3SP2IwFg2K2tO prGUP45Rakb4e9o5esk2ibmmtF2Yhna+B0tPBaEtqQfneBHhO+lnuiED4zhzcgKS0rh1aCf+ HK6zYc3HmnHju5+mjr/eupR8E9Ug36PNtzHA8LF78NinGN+wgO8Vz0c6gDu/fBLzlu5ESVXj K2RLdYjv111Ptc7ye/Do38xBBqVWIQC5YarB0TAljsPAe//+MJZdzZvFmcbCmXTVnQ9u88w4 DiL8l4Flf9WA9W/7JZ+E5DhUe1JQn1TVNxy/Di/8f8Uo20APEbOfJmkHpY+RNgcWfbQLqzb+ gic4AgfdqzivVDBIJ43xKUeX4UXaMnzzyGAfH8OVdx5CWoBzJlFMpni3apE9Z+T6vhevxskH spB5OdV8c0ew7gYOnHcgQc8mqcf8Wb2024gYs0t5sbHfVRtfws4bqtBd72dA4h/KrTcFIWru +owjSB1OYF8dG+BF/g9zz+zA/kGsZN6sunWFOE8j+faF+cjoi6D42W5E6EZb/Az3g2gN4fSa QjRwy9ydG0txLX3OtaezMUwz2eLC51rhZXJFickZbGuoggkoUxG0NSYzGGsM4988J7/2FB7k lQLj9azqatIEUfFAHl+5TEW/kgFUo9kunJiXh3q5MM4LoPA5csW8Lu/mpfs6UXB6gCI+JVwG 19oU55I6tld6e8scWeqrHhrPj3XtN+P6bYGDFoITwtbeFq8F4v6FVC09/m8rLyQuTyYLhNgt Q7NULBe3I0lCiNtC3qonwiAVjqQWBQnqY4HakMom1ait8hYBEteuTyqI4F1sexBBERKX0Vwf CyRBiFBIorBAEsLF41ZdIX4Zx6Ve01jlNXYxWJ5jOi9kL2JlESyrrIiy2kt1a9Y1uRHLCWGy dq261rc1Hut36rdMFMKJFTu7mNmjAFHaBZvnZJuEEm6mGZJ4MkLX+wQJyvTTvRDLYHas5Pfk BERvWAooh1Wo14kZV3Xhzg/9B3xF3OhkhOk86KZryJVeIIMIvfBmh3D9239MxP9ePP216VTT JHDbP53G5jt+kmTimQYEMtxJs6M6o5RWAkO47p4fo7/3w3ju8+XwLUmglYF1THwCX8ko7n3w DBavJvHQzn+2IKk3XcnYp5hWgRYgTolGxCUezeJ5jmsCVIj2CwX6sWQ8ToNujAiAqUR0hUR6 ApRY0ckuRqjCevTB95jyExdTDiSBSPI6s6+Qi+rCMKWJjZ9sRs2cnVxsxb6M2z1YJ8EACgUN 9lDV9ewPZnBbW/rgk27c82AtCqu4myHXI0EfZBGQSKSCRv95WL7+CUa5M9UK92/ILGrDNe87 hQfuWg7P5RyxGXTKYH4PhyaeQ/EaRMReGoqZdW/iSZGHkvzGNQwBrxi1oWxiZ24sxdnyAK55 pg5L7jsHfG0G9tZkY4CbVPmmp2PvzZXIoL1j+QMXsKyZnP091ThSlIHB6gxk1PGZYKNSg2Y1 MEljJ5M0ah+RSPJGm4dcHVod6/hi4ANha2CsSSZTUnPsGXQjtlF1NnGLdcDHRAKNxs1d62m3 SaoYo6zroVuwCB2YEaD7016cmJZJPwhyESpM0JeyFeccDlLiEpXn8yTp4y0OGqFWobH/ghmp h8bz8GsZzzk3SQbioIWURVR+E7hdbHDQcMNCkip7MSJWHSHoGKXJjo52k3Awi+X04mmr2X4i WEtiEVFQO0LIAvUvjych31xy6drmVYhd51RHx8qdZeWbkopHNhkRHaUR0fdEeT44ak/cvgiK QNdkEzBzY3sGzDSTqh8RACHppNqJee36+wzCFqK3IuvlhaU+U8ctpK6gSI1RzRlDeyiMYtpA NCb1p97UvlKNCPRGiVCkcdvbvHzOlVJGmMZwjU/XVDZ17DKUq2/1obFoTJPdI0l/Gl/qeEyH 5n4m3+OEvIaIspzk9rUnyAATosoVX7ntnHz/R8tdOL62BOnMhh04SyMuwU611zgKN79f/Uez Tnkv5B8/cjKBzV87A18+ueDhLNo/+jHc78PuF25kUKEbKzcxgLDyJI29fnoRBRnvcRRPf6IS +VeNYtWmFwwCiofFng/iyJ4bGUhYjBXrD6Ni5j56JwVg9wzy935sLy41uave9peMNfDQkJt9 nokKj5JYsWosQs5cQ0u+9ObucKi6HXYafkWQ7E7666aMfWJipoouJLGB8lAZSCmrNXV64gw2 zELDdj7E7GtSYB1pADylvMrj7EVj2HjzrvEki0ot8Eotmxn4GA7sWI7Gp/3IXE5X1HdoN8On NXDOR4GJpH2keXb7EGYsbOK3k3nC3DTA06DOcS9b+xgOfJRGxmeKmK339yCFpI6X2NXWyr2X r81AD7e0LKYk4GTQnQLuFBvRxTQHoxRvbU8OIPR27plOzlz2CSHqCG1LTbw+nOlGrog/kW24 hmsh3Q8JwQhTIwxwD5FwFQnjI4PIuIXGc9XVcnEt5ORm4iw45wQJktbYRI/zsspIClE2XnsP C1AcUOK35Hle4H8nAxeDV3Ib1iwyMpyHN8QXsp77lPCiiMWAz42CPup36Vk1SAKTReKhTMOJ cg6RN19SSzSf7hse2qIoEelJkaRhKI76VhkaQmJMLGmIG9dD/b6VQYTDyWdwcHQAxzsOcr2U a41puxlAqKGPJSL8HqeQzFuXlqBozXsaoxu3k27Rw/1hDPWHGABKb7Uo3VJEfQlxqvB0351U f6TZqd6gF1x7sJNxNLR7klN1EtnYiJBirBejE4OLKcKdZKZCzFIQtA8yqJSBnFq/zCzTj9oc 86UhTHf9jiClQBp0HfRwc9M/aIwq55b+QbjEELCcwxugMwZtXfwd7BlGb4T3kOMR46OxiBnr aO1FlO0p6tWeEWDWID5MHG/3KL+pPlJDdjIzbrLe5r57qLrRveaYXNpaQKp0lgnSs2NQtgce 23iswEsbNQYdzd20lVGzIGIkCYdrFWkaN1CzH2t9ja2Av6WJ6W3t0TS52kIstMfyY8rxepQO HdpATevcGqGzR3+MziW05XE+ulFadTN2ztXFNRLhMHV5oWOEzBhjzZz0YEyOm8SI66cx65yD xNvh8fNZJoIkCPk7+G5ovSX5u6n1YFY+Yx/UezxAY/kg13MGt2PIPcKcglWMtcrx4Lr9zABA BxMxYfJAFCRbNIcpf9ixBRwnI9D5ss0OoaCk3Zw2Ngo2suuFW/Ct98xl5/Tu+JIH9zAATgZt blVHyk1vihs3Yt7mMHJKWmlcJ9Hx9qOzfh7+430MgmnPRMP7ffgzqrZcbqqJeF/Lp59A2Urm z88K4fLN36c1nN0Jz9MryRAP60G3BsdvqX/SF9iw79lp6O14V9IGMj7+JP3ny8CAr7XX70FJ zTk+1EQ+7OvMoSzjunZxk5rvGFO3DLbwgTS3LaWzlEOhrjR6fbl8NL722BhgmQ+aQQivUB0j fbhDaD69BFu/W4M8eqT1v2TD5i+cpqGdhI7SymiEwYUhH9VXHazajfxi2Ycy4QtwG1lJSSR0 Y6MFdAdminQ6LfyWIaWM7g0eEinEiRiFUhqp4x/4/iL08oVqIEG44lyfCbaT1JFJJHChwIuT 60vQtCAH7fTQkp94Jjd8cteOIaeNkoOM6EsK0PEvPnQydkJEIas7BN/xERSy3FGqtY5fU4a0 K6Jm3/RCvqx+ShzatEY61kESrYMfmm64nzDbnnGoG77zQ0a9NUh10Z6PzDTBjiEipTk720x+ Hhn6B7MYy/En0xHig1/LF7u6JwQ/AxDtJYy/aRpGWmkApxfmYfBfvejN86CX9WvqmfKhm4SC SGaEn5is5EJqfOYkefQSEYaZQM4mBw5eG+I5qbyEqCyi8gZX+g9eXORZRKQj2ILucPL9DcWT XKQ1GEPCOS9ljBgVK8pXBFS762vieaPqW6/iBPAdEhiNeBKXJE/omE2MX+YBOSP+mPitRpJ8 UbL9gdAr1/qHXzmmN5D6p1c7mY/kZ6INcvOv6mNIaemTQx3X0PMXIZjUBGhI5jxvG4hqLNB5 NW3mSI5eG4uqyEQ/ujbE8+NFdO3V7SftJrpuxkqcbSqnrgdPmUZVmWYA05jVCHGoqahrbMp4 IVIQp8LCNGOKWW2p7cHkfMz4VEegNnleWGfi/uga11Wgc8bRlNKW+lA5NWmaHRhJXudvAySa 8mntY8BsHwlaQWMQrr2UAm8tQRH3CirY34sh4jtl4zWhDKw0OQEZb09fyow7xgy6pfNCSPce NtTH4aHnCWfXeC4XuRX0wiocQ1cTgwJ5c9K13zeN5mnk4nIrKDLmtiV7oSeTFrKzfTrjJtIx k2lKOuoD6OsqY/DfGS6k9i+OoKiyn3mmqNZhM0LmZqZMAyINlDFep4xNh4pTSWPa97rdWTh5 P9VX49e1hq58vjhdLtzxuVoi5nOmD1vaCKPgl+HJf5sO/4pXu/HSy9Gkep97ZTeWf7mXwyXC YENWm2pa7QocdADY9WQRzm8PMOW8C8/9bCFqZm9jLAspOQ315Mu5dmpwjPmxVqDvMLniuUDV Lf2YMfeZ5LyoahuN5JmI/DnLW4x0NTJUynPkLtK5xuSPiK2wj5tNnflhFrLXJdPamwG8WX80 IeakcnM/jzkM2pMxOUREmRHhDop8gKq3MbsACbmNXMzMnR10k6YnEmM3aulplUWua8OxbhTv YzLFJU6Uv9iJtUS65yoy0cKgw1xyiNfsb0f+rl44MxOY/XI7kRTVk6wfYYBiCQmLItXTj44g uMSH6hYiNsYAyR4hl9kIn/YYEbo40eLWYaM6M/sScMgjetj5TCh+pKKVbxyJiwiJixzuEsZz VB/vNf7sYxXc/+KlLmzMcOIsx3WsiqljyHUt51a5s7fRw4s318V5TG8ZRhaJjkDPQRYj1ee1 0vZCL8JYoQO+7jBm+kiISPAUdZ76TJhKb+E/cbK/AU8Wbp31bgoX4nvF/ugJjeMEpZJzfdTB 8kHPW7YSVwwywrrYgzYyCJWPtiJBjzwxD3VLclHYOsSsBESog9wAahO3O2b26fKnuxAtYNI9 Em7tez9Cb7pWunH/H/beA76u6zrz/dA7Ljpw0TvA3nsVJRZ125ItyzVxbE8cO5PESWbyXjIv fknmpSeT5jiOuyzJkqwuUSJFir33ToLovfde57/2xaVAibIpWclvkqctEcC999xT9tln1W99 K+dql6sd6lkcqyrWwpxDTQpuxUOcHaVjK9M0q7zbQaJPL0nR6kM0YeP4J1d7tfgA7ADUAB1/ MFsl17qU9FyHmh6mmC4jSsU7m1xCt25riurSorVoT6NCG0d16ZEs1bKmCur6VLgPYA8hV2vF fGlDmno9ocqFUSBvR4uGczBOyLkZnG4ET2kW8XzvAYA3sBVcvtOrRnJyybAjzNmFYYLAtDbN 5zZ4iZyDdGLdFsGKkHEQhCWU5l1Y6eepmwjEa/HQtyb/cCtFq9B9ZOGZGcTbvG7WrqH+HAjE JDbCfpR12IeBE8T6jSY3GNpLAjvG1xE06fVudT4Yr2PLU+UlWT1/R73CWKuGHgy8Mq6yX89S Ax1CV26vcw3YHBvD9XFVfDVDl+jfsfFAAyEmjDG8syv3ZqiD0PF85j3+ZJ8aQReWlcDKwfnE 45XMfqNRF+9MV2rboLJ3wWUHZD4yjPh9L31+OK+JHOqr8ICGl4Tpao5HmZ3QudeN4Y2Qgqhi ubAfU34/V4GYfLEcyBgMsj3dpdC6AzPFpezvGldXIy4vPUBGsMDDQNkEmTa0q0XoTaD67Htx iVjaTJ6DwXLAnnbcXjabIHFtQnhogC+5p9HUMeGgFBhq38jQc9/9nEtqj5FET07vgCfqFeKC 7OBtwwSAoQbC4icVsYEP7YQZ1u9jHAk0Z0GP7v7kbtdB0DyjMWTU60+uoGdImDylnCfum3+Y VrW6kEncsyUrH1NIAp+YCn9rE9+mdgxO25u+SH9z5D6FFYTo1N8n68K2e7V4Iwk9lKF7REFe XTtFW9u/9Cph9TgNqYK18IvdFCAShhoFthswoOikBpWgLLrbAR14DAJc5+ZrgiLIoNABtdXm a/ePihW1iGOadfyOk/Gd0vv+yb0xqGvqaR7Wc5iGPCgWArAHIJgiPrunk4SvTGjGURuypJJw Bi1upyJRkv24vxQYBjJvRtMeStV26VP1ysuk4h5yxUDWSFg9YQe88HEK7/zfX5DG9xH4wc1j CmtFICdRzU+vgWU/rXH3z09gaFfLo8gVT2npT6rdJd7qs2XP8Bkb22e2/IzM0YSI61XC+8Eo oKKf1Csrm3g3D3cAn4cgeCy+a82wEvBUVlVWOiFmYRUL12XSxMp7zOgf2DWQrNwDrco+BCUL GtTVjphA+A80UqOwIhGUbqL4aQpkAm+80ZAoZqswolPSlBcOTRECLibGo4xUQs7cd7t3g4Vp yh/uVEzvoKZ4LtImwmHgBuSQlejmw9ZLCMZS55w4tRAvz+utUETZkJrnpam9NEl5F64jDMfU keXRpYV5KuhpUGJXrwbTc5UfA6FqIowCS/OV1l6j5H1daigslZdwdM5zPA+FWZos8Cj/GMlo FPjI3Fx1ZcYq91ysorC0g7i23kXE6GGhyCu7TgiKGh48zJ7ZBbqGlxwX06W8y9UYc9ZjKFNn 5yYRKcEoHmlQ3vEmTdoaGInVieIs9RC6ixuvcwSh4yz+xLEEnS9MVTeh2ancIWW0VygMoT8G B15UbLrOFydoGIXUt2iIerYupZ1FcdYSNiLUOhXL4mFeXNW2TTAvrR2CyRjLNQQgiwNoQmeG 8fm7ctT9cfKpQMm9nPuq/Q38BkkExH1qAEP4dxI1tDJd68o6hX+uKS9QZYR9z0PRfLdAC1EK pfsIyNG2ovmuRI3cCbiHZ7ngarkSCBkqP0PXVmUoBSW/ZnedptZ4Nb4mW7N21nIcD4wQBHkp lhuG/6ojMVLrqrqVAjqy5654inBBHB4hPOmlpXVpPIgnZAIh4HdXIPbkcrE2XGKZSvTuthh9 5/fvpyodicoFT4zDutkZpYgELuJssDIKemgMxY5H0NZhOMKDyeprBX6bYkLJ9mRSCQ1MhbcN Q3UNN7GPLr5kDylKySy/+NQhdZ6GMqC2EII7QhPcqOWfb9S6e+yE7MTeGjNfWWRqRmEqVjPf PRyge0nYJmVWcl4UHYZ2qfzKBh3/q1RX4DhTedhe7cZGeid06lspOrTuIW386LMoukSEiLmq vglx3QzxegKGg5VddEbrgdm+8ltFil46RTX6bLoVHlFMYic7A0FG6HTXMwsVlBmkrlMB2vSN Wt336HfYHxeK8hjsTVR/UwIsxz1qqE7V7MVXgPp6HFS5szVeSWnNoM3WqP6NGCVtgNLE0GK+ 03hrEj6gv1yclNjojf3bbaaex9266Yk20sMQJjm0ig+xzAnC0r3QLFrmg/l3ljn3NbKW+bLk N/BXqylxXhw7uvH9cr5vgtpqNBJ8C9GstFBw6O8YSHCLRYcSa79p2DkhBNxnM79nm3HvLSRm itCGe4AxriIbOK9KvohQnELhTeF52QWadRk0xhd56Swrflu+I4g4vvu+KVOL+WI1+j93H/wH +jFulCU2H1ybU7bMqymQmWisKXIDo/DPBTePK4V+EKNWbY+gm8AQa0oLVSr1XxEnCS1l8IzT 3tTovketzologUOzdeGBIF/aqJsZHyfGTshzjFDCIPJjPIC8ArQ+Y5xHMOGU0EaEGuGhsPZ+ tkWZlw0qsbNfnSnBSr42qNwrLWoljp9KK4QAtutTlEYjyBF4KXhLoE007aN70zFaykaVdqBR iaDlmvEGupKDFN8F9Qb5t7gmkscopgBCXmMTo3TbhJbmQiuUHNGKQOi3pIQqMRPL24ARLzar ENLP11F+B1clazXnmoq3kfo0fT5qe3T44XxVxkK1siZeJd+sVUBOkPKfrFTirFa1zI/TRTzy I/DCFc9G0TX04s1yjay3YFCFocBgbc5DUWyh9cxxRqgGsyMUe6nfKZpuvO8OlM3ptAhl4LVv fLlcqW90aDQvRCENY2rYlKSnKXzdfKVVeX9XrbFC8nQQj/YTXj20xas+ku8rd9co9BKAhlXR OgypbQh5kUXUYUXiaXfPD1FtFkwgrXRGfbYSAylQOx/I0+zrbUp6plGt2+LUXBCrwqea1Lk2 TkcJMz+AYg2smFDLF2NVhJfiOdyr8UWxGkid9jl4Jmz8XA/EbTX9o6s1Fi01/YLvh8XQGasx WKmrh7Rw+VHfB2YCMro7S9Vw1NhnXZQRoYkrxlrraoa2gtCSjUnCYK5ug305SnTOJjkThBf/ xS/kYeVYoa0WFvMf1H3txg/fJdx4eeMPF4rqxmr8WB89PA669wPhsTJixgOvzFEQbqZrUXhD Wt74qhNsVk2/54lCzV2ah/KpIpzGIuQBsGE9RFzC3qaO3ay/Z5/O7EhXX3ekqp6J1bH7tuqu h5/kM6roj92tc9+jre1CwnyRI75EO+Egtz+8r4FeEtIkgid4cHOKLrJfbghhPKsxMeVReXWl 9n4vV/EredDNU3q3C55x+u/3TycA3r4afLfprV1yG0yAWqEoE2I3Daudj+2fndv09hMoBtk2 9vnMW+f/fozv+861Z024YZuz73eM6X26kMDbP/wZn910XNuOfxMoOxF+uHHe/nOztxAobkzv 065n5nvu3Gxp+z/3bf0f5qd5HDfWj/vT3rFrtn++YfcyEGs3gHCUKebADiaIJm2BPMJERTQM P5gF1G07Axd0U+OTWEPYE3JLywsZceVAWKgwqhnsAAPCPLperOqRhDCeZTzSllFFkLfsKQbd hKLooV5oFGEatrcHrxfkHzkwm+YoyDqvFiVo9nwAGWV9GlqdrgYEdPZPCWOhzHspEq1alKyE 01hpCEQLGg9z3g3LkwjZ9AOv5tTr8ApKYZUgNDVJ6MjkSWQNISpCpVeoQ6rNRiB+ukDz9qGA hnuUcrFHS/Ji1UbC+Pq8JMVWw+EGgWwUcG3Lk4Wx5q/NTVTU58aUBhw9mPB+EnUS8aDyMmd3 qnp1iguD7ZqT7EJFeXhLkSTGTdYa4CASAySMfY3ghXQxl9krCQm2DKtqTryrAr/vWBPKE+Vz tR9gR4hCa+Ckgyy0fFUaUxmg9OsguwinWjLfoi7XHshUY0KENu+pU/JhOMUKwnVlc5bjerv7 xSql4MkZ0KThY2mqIcR390tVSny+Rye+NUdRGE2lz9drNDdMJzdmKg2wxCR0RBUlCcogwW7h yI5PxOsU4cc7jjQquJoIyv1RavL4jCrXD4T7ZPfqneOtNXXTZ8aJFYIVEEJ+I4IdDTQRlkgf 0pf+fI8yi64CyeXmG7SXY+x/ZZZCcujpgXU904y1nMWNo/KnySEbZqXa+5HkM0ymTCCvMRo0 MeCbLNvmdofVc/Seh6TvwWp5kpvQFeaKT6q2fLku7UhWRDrKyfCotxjmhYTHTaj61VgdfG0t J2Dn6JsmczVHh3FlyfFYncbUGDxJWdXa8Gi1etGfsaun9Po381CS8G9x2a98ex70JiTYD+J9 /EotSfwLzFGkxrBsJ8cIzeU00f+jTi9+a6U6WnI4Rx5UvLdAQnU2H7ufW6I+6y2CteXm5xbn +0G/ZYrEhKUJkJuGvbZ/nJcJZwsXOeXh38j/Ob/tfVMONwlx2+5t33dftfd+3vBvw36dAPf/ frf37fNbjBvnzfm/QxH49znzezPfm/n3zG3+M/zN8rapbCV01b4i3nkgA8UYRDArW3fI4M4J FUM705QA2Z5ZoDwTwYQBU873KJgwyghWfs9siEVROMHcfMtFOYQVVC/BkG4GAo/uSQeigecX eWmIsBAoP2M2bmVdI/xbs2M0BmR7FElraDiCO+oi5zEIGecUwjaUMGcseaqG3BhQ/BhjhCTt FhqHmU+2cDtZt/aUngI2XvbFbBBGQUolBFla16trCM/6lUnAmJBffHf2c7WaVdWjYb7TBijk 0N3ZattA07rqIS3+caXu+PY1Led3BGFVk/6Guioq61IkQtWqsfeuy9DZXwG0MzvGMW9YNMVy D3Mfr9aaJyr00YMN2nqF3B6ecTOhrzD43+JMQNO6IJbKbiuQNRqda8DE9xNK6kDBrjvapMKf NCj+GgqRKR7FEG+8P1nHP5OnHrZdTa4xGmUZiGdvCOzyT2ZqLySiq861Kv1VQsZcfPWWVB0k x7ewvEuJZ1HIGGr9syNUluvRMvI9yT8yZBoKiOPPYX+RR+hrtNyjUZRjMaHC5nWJOg2H3Joj Tcr5mwb15UQqzs4dz2ZsXqiq5yaooJ7zmzHebnPO+OidfzrvA8kSHIFWvxqq9GX9+uI3tiur 9ByCkUC3XXlIny4dXq8j/5yhhKWW4whTpGfGvvwP/Yy3bvrzXR7+m7b5GS9c0n8wSOlr+/Ag Ljovwbx3O+yFU3PVfT5YKRvfKh58x67Y0Kz9BKz+fT/I0fxVS5U/7yTXBxonYJRr4e7dECY+ 2Mayda/r+CPpaoYAsu9aFMpzDb1GlqlhDzHaOZPKun9AqzfvcwpyZIgahSHyLwZEYD+BQcHa 9MnrtMa97gsFTFFHEkQjrCN36uRfJytu7c15mnec7wf1BtdtQj+IRe4gIIR3nMXO/v15B9P2 MxWL/317eB1c0ebFJnr6t/MapufKKRv27/ZhT7r9aa/t/2nPw78/tw82uTFMWjD829nfdhhf Tujm9+3tD8d7nAEeW7Af0LpQ6V0CT9k/tKnrMzHauzRNnz7dATABOClGz2UEUdbqeFcrM4rS qNmWogwAFAF4bycQqmsI1XgPdSidWqAxEsMh4TAXk2uKwgof8FJ/1dUG6zLeAvc9FPi03fso rPTL5BHGHkB0sC56gJYOFeOZIzS7EWxdGZFKGCCchgs0QDL74ldz1A4AI5Z9TAc73GLAntEs wjVm671KEeh9eCml36qB/r9RfQ+D0FuaonAsa+/r7UQ4IcV8rFphH8/SRViYR0EbniOxvwpq mqjmYdeWuWJzhqIBY1iSPezKiIqb6jCSqfkojnFeyEmEfx2ezYJsCkuhu4moRDFUwf6MAkh4 uQcbOlAFQOEtXxhSNaxAgAc8Jgo7O6zK/5qhhmTq6PivALDGLEJNiWfoDEke2frejORB0/JQ rlN868+3Ku1Ih9qzCXOtACSEp9cwP0HH8aA2oNTyXgPkggLrXBjrcjsbqntUgmdhJKMDFP8d fSTfKd+cnc3qvy9a9UvIpWA8zz5KiGx2qCph055V0a3Iw0MauQeyUxRsTMOgU8aDeI3JwJ8t THjqN/Pcvcp5ol4nWF5BKBZ7LG+tQLgZ73iIbU3yfiD+aV9NkHLW9uiX/+BNZRSZ8iDAzJQF hPWp8uwiPfZHaxVoyAwOMthHnNE97baDm4dNqNup/232b3mMd9ncv9XP/G2T2UXuY+1ftSk1 67I7t8DQXvU0x+jSfoqi5uLR+KJR77ofs/bN6u8uC9ee55fSxfCkYyQ2r8UJPf832XC0n9qO tC5t+cwV/cP9q5RCa9qd3yzCSwHtsGJCrW8G6qEnyoAy1zBF1A/QV4RaoWnFhkUGsifSg/Lg uv2UJ/3tUXrtRwsUVMTtMRbIX2hG/Cf7M34z4YFYlCPRIESWxrrYdjCoLM/1AQwwrhGq9Qmu x6zKENxwJ/TZ3QgJR7uHlh8YJ25oysWvBPjTJdUtjGGKZAxhYKSHQSzsEOoJLAk3aqES247X NkbZnxkpfsVi71lYzyC0LpwJIsW3Ztxq0zgxePs8BAv333qK7Fz+Mw9bZQaxGyB8OjI3VMkX uuWdlej6vZRcrFXM2X6VLBpQBVBo7z+QR3g4TDvnJmsTtQUl/1yjyLvG6ZdtcX3YaUHiteEt 5FymSVT9iFLxOGqJq+cUkeS9RF4A5NwgQjuAgs0MkFPleCDXFpD4ZY0gRUiok2toBXU3kUgu ikeFuqQsLN9LnM8wqKp+jmlKyDxKWIJcQjq6eUj559oV92K3Er/kFZR5LqQWXTukEtgD6qHV OYqSW8n+rFg0iJxDyU9qpU9M6QRJdesLZswHlstrLvboYEGcJuh9saAojsR8l+IAmMQSGos5 N6CEc93KhxOtAnr/XYTWopanaW4tvWNAKtl6NoMqCAUZdxTAzDUjH+RdnvmBokiVw/N2vTDO UfXMv9ypvDebFYXyMU+vtxiyQ4hGKwmtdaDMt5DsTt9OIWHTpGr+L7qXgs5KARzSwzwtg1du Hp6U5QbHeG7L1qS556sQdFUEnQNHyNdcuDdLLVEhevDFapeTPPRQnsrwxj76OmzY+4bV9JUU 9fL5wkPU3ZSGqg3vI69/hLwJymRWiLoI5aVX96r9HiD7fG/bkzWEDm2hMOesFRu3ViD29L99 MAdWhzDcGSTvwn594Q9eUHpxGS4cXFHAUQPoyHf91HJ9/xt3gdCKJKFOGIZw0E1PNvtwXsz0 vi0nYrkPG4bksdBXeyMFNfYGL9/rMOEyQc1KZMG4Zi285kJCU0OEm3i/qWGNrvwkTikbYBI2 SPHPGZZg98yd0NE/S9Pqu+/QrOV7NDoQS3FfrwagaA8JxbqycBMQY1PF85Zv1/JfL9D5F1MV k2+PI2G0cnp7fBFIsHUz5C1TTFGeDnfkCVBtiEWHFptCsQSQE8GfZyKM3fduXftxPCy8t3eu P+dSfvbHTL+hkvoKInVuS6aDQ3YgRNIQ6rMqezT7yVp1lsbq/Fqv4ntGtPC5GhBMY6q5L0UX lqQqv6ZHhVh5Zz+TD6zTnmamgwk3OLAXGHDBq4243ZOquidVlTSsyiT+POexGooRg3XuwSz1 476veqnaLZNj9+SguEH9cHxTRlZjMps6kHEehqu463PPtin3lWZX7Hf+4Rz3kM090qJ0g2IS q39HyOxnX/mHn86YAVaf4vAyGuMj1LE+Xonfa5Pn/nEH186Y1abYc4NKq+nTvqWpyv5tr7x7 2rWmnta1CNrgh0Edcd8v0e8lgHj9tSRCHzkjygiBGgPlHktCef+8GM1eGKesNxsV3zyoC2b5 bo1S6tFOpSGoDXpaAktyH8rByCujyQNkLsByJ5cYVAPkFZRRP+sh53Q7HHzhenOl1wEdDBBh Sf8CrOghaoHiiXZk7WjFuKC2Jz/cMcsmn+3W3EJaSxDfP7ghUxtRYKk7eQ7TUX4/qdP4LwXR p4biRAwlg8umZffo00396smMUhm5kCc3ZGkhXs3SnTRwApkYiUeRf7mB8+7U/IIoNaMcm3Ni dAy4a789Aygi6xWTsSxNHjysKMJvVrBXzTaV5D4Keb32UIMydrXxPkq7JEK1K5NVgbJq4/NU Eukb3gAdtQt4PHmlrkfj1Emu6O4TLYrDK+qAYqfgQLNLyhuYpX8OeRK8oUVXQMmhMEcBGVx5 KEtXYHnYuqdesS+gBD6ToGqU0iZCkd4dHRpZGaayBUkqttDcm4Nq/Bp5Ejy7TeRTwi+PqPHz Keqgb85S0IjlD2Qol6LCKNZAj5HE2TARijy7tQJxW9z8ww+LDSUp/tn/vkvpRaY8YoDDUXEE rce5A3fou19bAyonnBwC2GbQVmPIVgth2cH8KCtPMrTgXYhODh5EUUpoGDkTUxYuxoGcpQL5 54v3m8/N/8rc1xH27V0yqLxSFAhCOzAIdwP3vOxMvEIsiWrZp9s9AkIwCMTDjh/PV17RHhhx BwDiADnFa3CDEw0OtVwIVeP0dL/ns0dUtuceFJQhyqgAhmBy8yMXaDhlhJAx1Hb0udyLwYWD rHL+xiAmOhyp0Ghj983RG98vdLDdKaz12z7XG/t673+4bo5YgKehL1jaNqBVCP5yYsmnSxOU tAKX/GqfJten6yLNoLILopXU06MKHvpaFvsiLD+rUG/HWunFMsqjmNAw7jXp0armoYuG5yrj ZXrJEwtuoUK9B9MwZ26UQqCM7mTBNmEBrbDYBXNZxz6AacjbAuYcC8cs0kgExxRudP2iVIXP SaDzYat6cqN0CRhnEgIvniSuQYLf75p577P1n/MbttKsRse8uiskpz3/N2R+3K8hvMJaUD2l UG54CXsUk2Q+AFLpIySc4+sH1IFi708N1xCCv8kT7qhhEhCe9SiRggL6uJzHaucepWOtt7Im vMUhSrvQJav/6C+OwptplvehIVUkRil/V7NDYprXa2GjBO57xeJkxe7qhRUhXD2sk455cc7j KSKE0wREtxTamtAWkr4I3QPrM7UGhZW8l1g/qLHzGESZoMkynm/RrJcbgPyO6gIK4dSGDC0D cZhwgup2BHvpM7Ua+ly+zt2dpdLUMCUd6FIILQWiCFcn05GyiNxAE9e9j1wJS02zyG8kne5W 9BVq404NEX7uUkkcxiLrcpi8QT9AAEvoRwJbjqJGxNrERlJjNAuZsIyi1uiKAXnO+loCtK0B wXUnORWgs9mE2CyvsxBUWca3WjWyIkzXH0jXKUJ8G0FFZf8ldTn5GHex1KgRYjbPfiQ5RBfu MgE/qEKu0QANtXcnaS8AhK0X2uTd3a6JQuC3PN+F5GHyXgddBcS45tFUIgCBythLHc/8UFXN 5llnvpNOdmuMe1QJWCCFmpjQ89SCfCpEkTzHk7hp/dTG2DAvy8atFcgt5JbRmfQfDdSnf3CN nMApQkMkzUAoID10dt9d+u5XVymYmxYeDmIBzyMonMXIx+NY177BAfk/MgaBi9a0MFJEKlZP Etlmjhdg5iMyta8TNlrcPVMwP2+8YxP83eHaQM39cp2iooFvTeJvYdGPDiZQj+FVWOZ7S0bb dUSlT+jCvybp9JYHtXrri+gfX/2GWdrtDZmK9nSR70ChgNTKKz6pNZ+dpzf+rECRhZOKmzWO wL2qcUubIFQnHYLLvJMZgzmZIL/S2wlsN3JQh3euVdOuaF8PkH9D2K47A7slCH9rjtSHgI8h FJV2rUfFf1qpoT8q1oWFKXQqDFfGt1tVsrpdV9dSnFTiQWEC1aRIaRbwvtTDnUB1Kebku5EI oFnb6xVzeEDhv5urvYQG+lA4AU0tLuQQg2AZIWnahjXorScWjZKwZlAuf8Ltt14isQiCeY/X KAoosJ2Xeb1WaDVvfr9q0yLVOt8DgidG7Sz+tVArhFfQ/MZ4qXwe9YyJ/fDP254BlqRNXxTF c2nc0wTqeQpOEXtvH9CJVelqIsRUABFmOPmMWXgQXXiK46CwzLvA/FMqXqWxEZxGQdx/oUUe hNnuzTnqLYpWLAok+RTFs8VxqsICLyzEwCS0HUhYsheDIQ2hgGhRRXyYVs2PUeqrNILLQgCA 4kvE49m9yquiNdFKIVcwzlqNQWmFE16dS8Hh6/fnqW4d0NnrtS5UFst62rUtR5sJ8yQ/26nc 0m7tZs3eh9XuOdarghcblVTWq1P3ZGnnfXkqXM36JX+R82qzFv2wUuc+n6/Ht+RqfUm8ivY3 K/YqxhBCP/OVFqUFtalwSTS1FGl6bnWG5mJAZcPW7L3YpegLhOqo/Ug/g8BTh8bSCPkyP1aP FEjIxcA3gcimQIr+RmeFaoQ5uPjbBU7R1KN0BzCU7rjWqZyThJLI81geZWBTpC5+JEun8W62 nmhW5uPN6vpknKtxCW+jtgrhN0IPnaOfKdAgz8KGpyoIDXMsbkhveqSWNuH9v9jglEXdxyA2 pT/Opu3ViiwfVsdGD/mSRK06hhdzbVRt98WrkvDVfLwRUy6TwJl7OQ/zTvqXQ3ZJ+LrkbAe0 ROF4LTgEu1gvKEiT14jBWwxu6MxhceZhMOBFn+yC14pvc/JTFosKHkMwr9Of371Og+0RGmok /3AmRL2XEEhldCEDCTXQ5+OUcqEqjhYG/t64YKB7wuKm0DCZSbfVC0wW+aFOqtSDEt+hGmae zrv+HYCLO05/71lLSVCzBicn+cExWxu8aq2MhiiRxJuhwN7L4KQi5ks7flCqrtYMakmIzcLp Y+eckNrM9fiS6rZIDEW1dtsxxeZDLYCp0naQ4qjDqxVMwZC17x1DURAQ5cWMc+BSg0CNJWU1 qKF8gfY9lkeFvCkbtpmx2Xs55dve1u4jT28gVosHJlpDY9TBwtn4S2nKQjg/dLiBvuB4TaXQ m1+mmhcB08RCK1sFtQrnln+104WzDCljl+TumtWKMDnxVJkbQaHlOSZwe+1SSCEpnEVeR9jD kqwGxzTadjf4ZcvAepKPU+w3RrHhOIrBqnpD2sd4WLsdauYaLL4N0L0bRDL5Ug95NxcI9O3j w5/vbwZs4hkeQpRFhEGqqfIeI0eR8ffNWnCyRWUIuTZqHYJ6qAFCeJmgalsQR13NkNK5D5Zs TiaXMY9K9czj7Ur9UburCrccwXgC+Qor4MN4MATTIIzNQ+wbBjg6VIZqAmEbNZ20NUU1DM+a ezx4lgzQYYV3bRgtcWdIDnN+I3i9k+TVEskvLL7eqZcxcjrvJLd5ZVDLnqlSDt3zDm7NVs/m GHl/2KpFFV3qpLdLQDnSjrViXsdK6jcKybEcYR3tIxTWsCWZepRxLf7XCm3Bu9gHdPXwx/Jo 6UrtGLxrk1j71o4g/kyfFn+3Ug8g0DuAEb9GiOq1R4p05Zdz1HJPkhq+mKaOrRTl4Y0EIR+t gHaSgtoAZK55CvW/ka6j/7VIr362WAcJpx1mnhPhtdqKYJ/7o2pXaJv2FAqUMNiBzxWqnBDU g7tqVfAnNepbF6PDW7JRMMwnYa/ACvpyrE5SE/Ox6vVaRZO3MOLRAVBXltzPhYkh7NyoOld7 dHxFmpbgjSQcAeqLIXBpI33VmctUwpBW69W0MEExIMYKjHUCzTQKX50xY0eQX7Hi4HkYDdEX BjSQFKY+FL0NB5Dh9609ELfJWz8sHDNwmYI+KNMjsbinxkFUEMqy0EdTdaw2/Q7Eh9GjrvLb lI2pRxOKp1/NUHVFIe7iG76d8VlGbj2yfY7KDsTood8vV3hENWdjeowucv0Jqi1LUUgcosgp Fd/X3u3ntOhxH5scMkZYD9WiMR68D/vQkiwcs6kulf4bJKxn+956t/3d6n0T5OEUM9W9GqPd Gzfr4S//AG8JRcQqD4SnanTQV3UeRqtaY9ZNL7hMi9+5euY3fBDeXY8VaMHKTMVn1GMdIBSB AQeHMHH+wX6sbsXmctezK9VzPlxxK0Be3Uaexr+LX/R3AA9I1rF2lRASsEXbiYU5B4uo4Elc Ym7EGASD0VcGVESi8AwLP5y+GZndI7LYslXK2rCfbsr5aYRsEeRQ7PUw+YwxyAft/oQQkjNK knoe6E66nUXj4huliTNIUBxBKOthQlqnYOm17Q1JsuDVWiVQYJZ0vlvZ9DG3RlRGOLKYBz36 EiFFCsf8iXve/nD8AjMwRg4h6QTV1IQ/DmzL1l1tI8rG+l6FQKqYl6ikM9CP0JnSw709QwJ9 FuHISJTJBLHj+Nd7tKaukmcbgZsbpIyaXr1B0rpoTYK8T7RSwT9FDxWYYWd5lPK/qlVyZ6/6 TRmkk1Pd267VeCcDhMtCrJh12rAJg+zQw5powrPJb2rQgjNtOgTdScJd/Up5o1P5UJt8mvUU Du3HmDdEUS0jWgL8tvKuNJqD0R01B3gq+bnrUJpUfD1T3mus1yS6opJkXvjjKoU8AkFplken FqcC4R1UXPmASp+ucx7xcdbakS1ZKgH9lFrWQ6dK2roC4w0F1JL3T/XkUrvVA4u0iSmDIR9c k64q1m4xYdUIuPdySD5nnWgjOU7vH3IPtQsTtZ8cST5COY1QUQ45hQhqQgqgXomsw9vmGRkH 2j+yKkInH851IvG+x67L83Kveh/w6DwULKVVlszvd0i2ls8m6SrP4sY36x1VySgGlxlrZ0Bv hTGHqSfxHjbCgH1vtossZJDLgCBETShLqwm554VKF77rLyKMDDx7LsZgZBnGPLKtEcXUjwKJ Yk7CuOYQmukFwKo+iMc4ZGUaDD8i8rYUCKle/uNi52HZ8w2XHLdcQkCwNtz/qjYCwbNBPRwu n7v/cMQQrkr6De3/X3Ha9jEakSR3a2qYmGfmCX2VWoyyi5na9MBR54lMjGHdRHeq7NBSVW+P VtRcLHDMVUug+Yez8N1LhLcTTf5PfL8NvjvcQ3wdtzQy8oxzr5yfxzm1NmVppBMhGMRi5/V7 GggyUyLmFRx5OlOrt8wn/3MeZQDc1qpbyYG4gWczRWzHhKYVLx5clwttS4wadkTr5MF12vzx J0FgYX1B3RITR1zfmVnM1VQEczAIueM6HfpTL3TvVvlre/l3Gva8okCisOCWP1GpuPsyHVzz AISI3Qj3eS8QHqCaNgCrL/1UB4nAWHXzoOcBF7Rk4qR16zPX0T8s9sgaM5SM/13WpBvjeDsG k4zFimmdBbkmW7BcfJrHt4n7jq9bJG+gQFxkE68mEqRKLgn743EpSuAhTT8NzQjnbYf+d5yt 6bP8z/mrD4Vg9PQLnq7Rzi8UqhMvI/MkrYefqtHlz+Rq538p0YYXqlQAp1k94aOrhHGsm935 O9KVmxOlIYR2wW6sWGREHHmzuKXjqiG2ntbf6lBVk1PJGkHIBjVBLXOoRcfIKfSDTIqnyrlk bzM8VekazgCphUA1OpnYukHH29QHr9UUCe8UlFsMcNyT5DBWsSbjqORO3d7u1uA4lj4BEYfw Kn6iTq0r4zVAgWIMRkbB/hY1rUzUuY3AZzFAVpxtVc5fo5C6KpW2Cd5o8j4R7fA/sc7McCl+ rt7xdB0H9XRgYbKSyL0lkcvIo74iHKXaVhCjFMJrGX/DtYJKzY5vUelCSDqZrxoQVlYHU0FS /hI5RCu468SIsnqK+y62KeUM12AtYlm35pkZM24AVeXDBaG6spFGbBhxlotY8xMEPJQp1/9H DvUicInBGZe1vcUZSw13JOunoL8+DveVdwfXjxHVQDHiFbi5rI5mDfcoqIV2E5/IcaCEDdup Uif82LcoSicXpGjleQASeFMmg0YK4aXjfL3HARUgs4fwMqq4hnRYBEKrcBKYkwnOr2dtrMqW JiuovtYtfiv6tOH76f689Q9XV0FCPG1tv6Iiq9w3rLd3AJoiIJiLZ8HRuML9CyaRFgAdcaA1 1eCtUGhPLl+PpSL7QbfzgBDTcNFasHa7Pv7lbysxjcK6Cejfozod++2up+YpkM52ZuHfkD58 0/K6TzkAAEAASURBVG5qkAVKiZuaxDElZVKDrW4MW7SDF+G3QfnEYWVw5YSRiO9zyKZaDxhr LvV2Eis39vjWHxatC4Hmvb+JBjY/Wk3/cqaBoko7EeuWa/8MhhLIfNhx4zMb9eDXrmrwEg/S mknt+Ga+mirnKTiahGKifZnvcT0B1IAE0hZ3CL2844nFCsxl/uxg/57DpopDdq6I1VBGuIpJ xK093MhDP6bzFCXVb4AwzhhrASCYFRZDUttCTwmEj1xV94zTdfeDmzUVz8JEGNkIJfdjvEA2 9208TBF4hZmEDxqwZrqwzCKxTP11JAbzjQChsuT5Wq377nWtRKFFUanrKsJRYHZMa1Vr52Dn YkLGr5z+PafsP92xeHYsMNECDX7tnXTpPD0MQeWArgKbHVgCuIMkde7xVrURttn/sXxHsZ9H ctpu/arXqYIm2frTNRD6oVAsRGX0JxaKNO+kFlRX/wP0+DhJbg2SvsrkKHV/jJDUM+QPsMLr qWmw+x+G92B5gyrCowbvnQJFFdI0pizyDEbibjDX0OoRleIZX8aCbgFqK2NxoPmRhaaM+8z2 Y9+z9dKBkD+FNd6+CpQYYZicF5o1h1BMKqGas4tTdOLvSxGoMcr4Xotyn4bokXVlAsUEbygc bgUQSd7703KtBbWEjHcs1M9yja/dm6v9hM2euz9f5X9IAeInEtS2LZ6wFfB8qudzT7RrBd7N uu+XKwUv3ZL0d5AA3/p0uYp+WKe4KhiimbdgwoFWn9a1IFaXv5SjEx/JVTmJ+nzmZCnr3rO9 TzWb0/TCcq/mX2pX9jNNePvAnPH2qkFrbWUeMq2AEHk5icHWNA8wA9X2K7bXKnZnn9ruitd+ alxmYeilPtXhQomXSbbntAy4zqCGW55EFDWjLDLb8TTIJY4RbrxM3qUC8EQUnlIIdT1D3jCd /WK+9nyywM3P8j0NbvkHUi9ig9m/xTBJgIB2g99WWBfpJV491ADKCcMQimYT6m44qXGzWT81 RRtE4gzDaK4U7srL/zyXfEQgPTCeA6EFm6GtvGklEDDBRF2YB8HhOl1/LV4xxUY0yM6n94+T 40JT/cDnrH7C3h4eHnTlES70447vro1PSMJ6cPEIBw0NDTi9NoCc6yd/E5KOoLLjvs9hsN6o 3Emd/FaaVm7doJL5+2gAw/n452F6v1NTvuNm5byk/PsK1FSVoP7r4TDyrtJHPo/CNP6W6e9Y Hok+MLDt3q9LP01UzCwEtYM+v8+TfK9f4zws/GOsnhehaC9PidTdr9Uq/y/rNPoHQaomgTkA 9bnRnPsFtW2PbHAQylt5ggbZVRshTwjhbJjAD8bitG1tyVmTmjgSj5dx54cJaQRS5evmY/o+ mscRwYMY2QBaD6Vl5zaJULBh/FT2l6NTt+3fNve2zYfjfcwAk2qPRhg3uQra+9yF4cqjpuL8 Q0W6jEe6oKdKMRf7tS2lXofWZ+gEaCXr42J0++NARou/W6P+3wwFGRej8hWpWlA+5GLnEUje y4Q/xxBCsc/3asHqVu0jKV+5LlXzoPePI9l+xmDBWMYx+wlTAqA4j0Dzro9VwgUsZOLz2Xi9 1rLB4KoBkTRPukJCvjDBhTvdldqJ87Elf+23MeUaVCoGpfY6XnQPTczu6C13VeaGiFrxL2Xq XORR5cIk7SHhXgTrcMEbcEZdhlY+PUStDyQ5kE84PFaeHcDY9/Qq4WMDGiZsa5WOXVSum64Z 5+/ThJDGQXXZOrZ8n/USnwWgoI9alQzCXrP2wxaMEI7ei6RG302S0zNvg0i3+lbAWM2xz+Fd ePBOZqMQFtJjJ6Z80PW16V8XqToUypYr7cp4EhbrbILJVPrXP4iCRykVv0KCnPs1isF+/lPZ ukZh4p14JHHQqoxQIHgd7ymZvFP6mU7nWZjXchoU5X07auF9I8rRiyL6PAgvjr/t9RoF0yen 6U7mhW2iecZjQV2FVoyr9aMxOkrOMoaw3OoDLQrlHC3XG4wituf51grE3RnfDx+ZIlQEHVF6 8h+/5ixxf/hlxmY3/2k3FGu8tYok0VLi3COh+v6jC3X6K/mEf4YVGU7XMKhAJqh7aGuJ19kn 6CsxjrtZjACdoTwsjGUsu/VlCfren38dJAOHYdImoEvvbyW5ShLe0hw2TMDHLQMR9iYxviu/ dSMENtwPEdwVyNMSPwDhzMSGzQrU03+7Rkl5iznqu0swi/D1doHYYlVHz6JY6UWSdWVfBzjA Irdz9n8Vodhg55c3/b5dzL/jsGRYwCDniMcxlUGMGihi0gKUBrFbezaNZNFyEfa3DTttnzLh e1ybX4nYe6ZMrRtg56fjVYeVlMiii2jCU0iyb0FBwTamjBJoe5u8GjQI2HZ76PzDRSy5x8NU 0AZCL20FhEEk+INg/fUNnyJzStt2+eH4wGbAZjgGQdYJGq9+U4qSj3W4KuRLeKHpK+FH+laz UttblQUr7hBhqFU7anSdug/rb2+kg7Neq1fro4W6itDLnU+I5wcIvnU9OkVObQyr2QyFrGdb tBTr9nXaHGeshOIfz6AMLzQPDqm5h/uVAdLHlNDZrVla0VEB9HVU4U0jKuimroMajSBkQfRJ LPSERnUUxRJy8IWAbA13UWdiaL4owl/Ghpv9SqsewuM9QpLcqroXPF+tmJNUWKfAPH2ki4Ry twaBk1eRmzj2qXwHCOkHWbiTc/MSIo0l/5K8BZr2Y6DRnoP3CiPIFNNYBqAQgB2Go5mXRc9U KvKNKMwV1g1iLNHUzB4SA36EvkpuZiGgonti1J0aqQFCcRMU/XUTRiuPwsrHiJ7T3I8yqKfu hSJEvAKrRandlKbLKIAJnrtCYLeCEsa6g57/ah61yIFasL3O0cBbYr7s7gxXS/WR5yrkuQyk ncNXPghvGPN6B/mRxAOQKW6MRVGnKIvQWGQX/hx8Z51bPNoNCGAtucTEg92wUpOrodGaMe/m QbeSfhKvJQ/WdfoCRTOvBUDrk492qWUlOcujLBaTxYxbK5C3PZxOMABBvb6PlpUWhZr+MjLh rfG275jiCU+ZoMOfCZkpJW6QrrwSp1N1psBSnfCxNCuZDnmI+0cRFnsH8siEElJluI/CmNcS nJlkhzTPIyKVb5sX4z8H25arab1Ouf4RwmAk8V0OHfREOIzBH8RgHqn7oBK0BRf6kk85uP26 k3rrCLadnVt4EsIXGKqdo7WNLD9ETBTP7Mb88RUTwBFpCEnCbb+Ih/TW0d/DX3benKf11Eij Z4Kw/i6SPKz+Ok2lsKLicVOT6f9tKBL/MHSGr7ES79j3bWCJGo9RL5TQe2H5NH+0j4WYCzon BXrrKZTBBNq/jwfa+kaEXCCJCBfRJZKj0dMeiAmBAfYzBYZ+9ycK3Prs5vXaM60qhordsf6y xuzYcZyDG/7j+159+PP9zsD0PE6QUDJo9SUgnh64qPqxuo32vJwE+sRXA9RJMr0HwTSGwAyi TqLwzSZdRml0LKdA9B/gclrWrf3UkFQQK48hP5F2CiAGUO7LCOWAXwVaS01F1jlqScijDZOw TznSqfuyWnS9JF5ZmzxK2t+l+aVx2s0azFmWqAK4oYxq3UKlFYS2irCAgyJBDDYN6goCsXVz vOKB547S8+XwR/PUyporog4plwJHT1mfcr7ZqBgs6dPkPvYRgpm7qNNBZM2bCsHA9Zzq1aIn u3XyH0t0inPMBoq8CCRZE4ZNBzQe9eTqyoC/Fi0m30HILqIWll+QYeEk4W3tWzuCOMgJqd7Q 4PoIQl8YxfFQFSWBMlsSq/YHotVIPUwfa3qM9T2BIG3jHFMR5KvxLKyuJoKe4+ZZm3cSWDau +q+k6Vmgx/PwoJbSJ8WONUUCu+Ir6S7ku+6JckVdBeFI+Pz8l8izElZc+8NyeLtGXAiq4gvZ ugAz8EbQW1YsOQqVyiVCV/aMriAXEk9LhuF8vMXVaUokxJiGh0LmS33U5FRnxyoV5blwNzUz VUMg5ILVTlM40MjKJck+xr6OLc1xCmScPChQundRILdYiJaXiMm03IetNtMWXDThFhN69sqE t+VLfK/4xeemRG4IRT7yFIKqKEIP8L5v2PZ4BhYKQiaYEL3VsPfDCqYPxCZGtGjHNtJEZ41O f8kEdygMweEeC5n4zsT2a+/7hyG17OhOsPvfvI3fN66V/VmVfXi8L2xngAJj97C+GT7TfPra OKarWfQfm7djs3zWiR3OP2+sHl/Yanq7t1PM2/nbdc4cpmhnXtPMz97z3+hWg8qmkqDcjCtu BVPmfSQSr86i6U8KhHQTJChtQi28lA2SJZmH1OB9Fms2AJ3FvAsvgGNHuFti3CrRQ/E+vBSM RcC+atW0KSioO1mwHmjAp0qwAi92ayP95C0Jbn1H7KYsh+DNeJV8V2sPHHNGInWK/IcpOjvm ovPtigAZYufikCA3T817vvwPv8AM2PPEr2QKzeZR/3FuObUf1Nxkc68i8EouI+C7YAyYRYMn K8y7QOjGrPaFr9Y5LqdTIKNiK/uVRyionhCIdZ2MfihDs/+oSnOXtOsVcgej0H2srRhU7P4+ eTfAN8VaC8dKL/lmnfp/H2G9KEELnupSwa4moOKRuooS8eZ1OGSV0ck3UxUeATqo4Hv1bk0V E2KrQFlNrsRSZ91lkCtJNwoVzvtFb7o8Cyd0V3qD0v+pWRtRZlX3e3VsHtvPS1HJun5lg5CK RSEoXSp9tUFzqGkJhrRx1AtVSkmUWoD49qRGaIy8QgOJ7f3wgCUQ4QhhwaYSGrJ1bkWxGV/G y8A4qsFSTyV/Zwt6GANnjHxOLKGi9PIex2TcRIjJepYvg9yxdAeNn85TDkD+wiTwFEZlXx4h q08k6xIcWxtJ1s9+qV5REE8OlISr6rPpOkMYadvOGkUfGFTTZ5IJUaVoAGW0+sVqh0IzEIF5 Hq+AKPv4wXqlvowH4Q1WBYWIF4ALb9tXr+TtGHN4GhOABgwebVaaXUdA1aSGNkfoEsy+21Bs Sa+zHdGIXtgp6vAgF3HPU3e2q/VOr7JqYQm3h8YeXAanf5uDZ7jzINrVBDdfsa975pBwAnJr yKa+47Bpgh5is2kB4GSC+9ves++EZRDGyMDNQyE4iifeMw1gqKPu0z5eJNv27cOO5d+vnbBn uc+j6DwS7Kxd/2fIGBfGmjKBa08EBx2CMXiw2ieUbLt4CB5NSPeet6nz7ZdfP3PYdjHFkwpP hB/reLBG+b7/mNGFvvfbDxjg9a3ztB3aNjOH/3i2HWh3/jNsm29u7DNIHORZgWdlk8VG5sWM 9gWq54KvjoJ33TkbxUporM/DesdBbKP3OjhRO9dMqBXSw0BjcHwT0IG45A5lZfuzbXgAcne3 mM7HBWROEfY2jEer6IUG35y7d9iWcJ9RalvzJQtveY/T/e0g8Vi8GasNCCM0MeuZOh+eHDSV jVkz9+HXkCRILQ9iw3Ijs35a75SJJU4/kGt3e/7wh83AFIZD5o4WKqejdBSlYcWBpQj48K9P 0kUyUjlQqQcjaId/K0T7EGiz6UeRA4Hh8S05ivtoDtZ8lQqxVBuBtF6kQj3+lweUAa3IAsJg Bh0dpdA4YBdV6UB8o1E44zQSC4yclBfhf5XK9PaPkFwHNbWERO1LFPrVbUrVrD8FUYT1bt0v d5MvieKcvC8QHhujVwecVI2gq7aDSFpD3dHcf6jUJDVH85bEO9jstbx4Df46xhHMCqXfqFHa R7tUBSX8eZTBJWL7aSS5QagqheLJbOqeguhDHkU9RfSbg0rxQiOSbIAeOKzSw7V4Nl5TBv3Q WYqDgIZMSWSNDLpc3zBCaWlbD94C4TOMmzDCRFFNcGB1TqhjZZzqSPiPEI5axNxYvsW6fxp8 ObAPDjn2U3dvqs6Tr6lASd/JNnOeqFFY25i6yAWd25ypMyjlLM41lOLato/Fa88W0Gvcqwde rVb0ZV+nztZ18TqOt2eCPRpDQC1Tqv5Cmg6x33zmLA1DcBBARE9htNJghph3uFnXAT0Ynfww xYGVACZSMPo81eSoCfNNddPeegndUlFSG6GP6aJivpeK+ux/oUSCEYgxaGLg1grEL+lsS3tO cX9GG8b1lZcuKDMPV4aCuMCAIW3/yRId/Qvw4etH9JnnTisjj0UBltkm3YZ/N5Yz6Wye0pmD +Tr1VAqTjwCxYkEudqSLmNvKTn39O5dIkqNYgMNOf923E/vJG+NI2mCs/N7OAD3xPxe79768 9zQdDLkJYyZgrL9GuB7/i0XqrgURQX5kHNfv3t++pLkr4eQhEWsxxcf/bAFFe4O6+7ErXBed vTiNdxzvrSPzIedDeeeB7YXa/50s/doLx5WeO8AxgSPCmnv8zQLtfzpH3zh1SGFwY00AFvhZ +7PjBRPW6mix76Pwkmi8w/mHUNHf3hShx/5kkYZ7oWeIBvVVG6Q593fp/u+foW98CPsmJxQ6 pB3PLtHeP0j0Vat/QJBfV4rj55OyG8e5+Zs9zZwOa3/rhm3jH/YWCc6ZwyFi7A3TljaIH1tx pxv2XfM0YnnP/vbv66Z9zNif/3N7y5KkNvzv+V59+PMDmIEBQ86BqswGSXSWXIcVjQWQ/M2A bO/ip4vUem+ScqDTKEb41GGthmKJhxJqSaXA9BpWbvAjuZrzSp28wFerCANZvD8cJlfrt9F9 f66uE3YS3qqXXMgEIRtXjIaBYfQZkaXxOkDTpo1TFUomlLWNYsMDgDjCvpap7GebtPCxKnmw pvduyNQGrGfvCzzTPEzZL7ToHtbCBbyRnt8r0XzCL1n/TBvlxV0aJUcwgNC/AGV6DtXZmT9u 0dxLNKuiorzfC8U71v41y7kQpolH4ZX2gDIkFxhCXUkE/yxvY8SeSVd6lP39Zt9SRqmMEdox Kz7iOjB23OTBOVTXU9NhUsiQgQb66Jgbq3IgwO3ki0oJ1y6/CvUJnpBV709Y5AbJO5Rt/Tsy tJdEdiEAgofxEjLebHP5lLY7E2gWle1k6Ro8P6trOQf/m3UstNL9bW/UKekQngIN2wYgsTxB nUgaVC3r8dCjzOP6bxl6E89wNhX885+rdor/4oMwDFsOhBONP04h5uU+cjsQXd6Xqit4WVbb lUjPEaNQat6WxHsx+sjRJpcvOvYreUq0/LRd5IxxawUy49k1290s5QCKPLLzLiil5BpXzh7A DHvzZqtvnHBECJTlOceVWkzCh/DgDQlq+5kWIFmF0uxF0sb75um1J9br3PNpkA5Cq05Jc1TM kHILdzrr1L/9OwSE7QcB1N+I7Amd7w6Rk78DqhHet2Oy9u13MQvpwOkChdHTY6JvSnkl5cpb CAGxqUuUUHhUqeITe5RVuMc3GbZfO88Z18yrmwUUk5Z1jQrTumyu87BSitvdvkz9Jl/xcENy lFewnZ3zPTvOrfbn36cJPrabGp8LUzGFdSVgfa02h/P3ZpKGWJKh089lOg9jsn1SK+68ACqG c7VtuP5RjPj2qsUKK2YfdqwPath52b+Z536r/ds2txpvf/92Xv+8bW7nOLfa5sP33tsMsPas W3Qb5HkVy7wqRMAvqO7RIYRq1ja4qKjpwAbUGcIjUZ8eUtLjkAgWdejUOlqsfvu67gTFc548 wxWUSD7UN/OON+v8PXm+tYS8iwdRtSagRvtRIgPbsrSqjbawCGqjQ7FQijV5KoUcsPWBXCrN +QL1Eel4w5tIZJ/gGPVfj1UJtQv5eEPBX5jQLnIEy4GB57/RjDE2oezdrUrGG6nFYzlCbckC ahlSybfE0LAqZifcU1sx9EBjDf0aHtMrCMSXuhU/0CVvLm2K76NozjisQDNdJSdX64XlAKU4 SDisBSQhtrOWQB4bcd+YelFqvRQ/jhDWMnFj15B1vUc99EdvxcOyEJU9kwZIMWqftP5hLdxR 58gMA/G8R3MBmCyDioeOiI0pdixKDdhuy7UO5e5tUcw+DHAUa9WjXh1ZBooKuPqKl2qo2SAv syVJu7ZmKw4vYQNIqhSuz2C9EzgM57dmOrjwcnIcCU93qe5LqQ7tlkG1+bwXCXuBMDvyu8WO kLLgsQYNzKdmpQjaGIoNLVJgleeDGMpeGI/DK8mlUJR4GvJUo5rP+ykCNyZAeec7lQScu9dy uoxAi9szbq1AbBsTJG7wB6+t1mF0hPoOlMf4cArduGjEDhrKAkHmYYyO4D4N01941AQqYZgA rsz2w/dsTI15sKL7lLvogj6dikvU9Kiay+MdZ9Yk+xkbhuGWQjyjHwmgZDIgxLLNvu+6n/a3 71Tc25Mcc2Q4XlHDVCPTyMriJYEhHVq4vlF7/ihPKkLpIfjHQXeZYpkai8ZroDAGD2HQCB7t +k2b2n45T+tn4roi8tLeCwgBemefTY8Ac6sI1Y2OmhUFQyxzMAA6ZHggVEHsDjuFzVEs/oGH MknhIPYInzFPwezP8kc2JwzwInrpmwv0awVU90Y0UK9CkQ7spYvvaNChv85SeDI39M5BYIY+ hT0xxueTbTpz5F6d/S7u5gYU5AfkfbgT4vIsp+DnpXLvzfxhn9t83HAvMSvsWvzXM22Z3Hjv 7fvzf3/GPm13NwwG//vsx7wXN3ggb+zP3pj+bCbdu3uPjyzk9uF4nzOANHSCj5t5Frr2YSqT vafalU/c/jyCbD3cTHcRLjlyV5ZTAhuxynNeblbjr8W43MKc36foDaRc38N5uggya8UPyvVg eov2LPVqPesjCwFvcfUielEco/J7YRr1PyeGNRIPimhligqiO5TwPPDcBb26uN6reezfA+Fg EqifDdT7XANp9JO7crQWkMf8b1fp/rp+lWMotlK4Z2SB9pxH0fxp9t9VKeEjybpGaKaRvibR bXhHhMsMAjyFsjpCCKyDviSxwHkt9OBpoJVCPSGrqgGF1Y1iVFJUB+TYGkkZ0ioYg22Q/iQH VlE/QdJyMTxfU+RbXDtm1qiFcIOB6Q5TuxHCMRO76B+Ct2EAgyAS7GHlWKzxkIT+upfWuuGO u6qKpLy1REhpHdKqE01KukDo6/iQeu/CE/rjIkdKaYn3SAAsS6mxSTjeq6GcMF0m1xPKvKx8 HeWxm7wkwIEA9t/06TS8mnFtfKJK4STxB1ZGuvCdrYTF9BmJf6lXFb+XpU4U3+Knql2x5Hlg 2Ka803bDYg1UfhBAwxChtGQURuD1CTV9NM15X7Neb3C57THyK14AEYFhYXg7WL8V9tj7ntFb K5BbrUMWQoAFDJm/QOjb7fv+59x25ejI+SOQsI7xclw5vVqNtZlK9I7RYKZMKZmXWKRE/gdg XKVL4PqHKvW9R5YqYo7t2L6PgCWhTDcClEiYGq4vdQrKFRWyAfebug7rzU7J/gghnnCUTKBB wswlM1N50J1bRs45Zd87jxBRPBfPNiaB3P5h30HKGIqq5nKiqq4sJ2RmlenAAzG/0nMugDgx 18qtLTVXzUFBwaFj18u5tTbEKjTPpo1j8Z5R2EdavST7MAbgqmulFE5Sn0K/D5OKCclo/nji hRbS4rg97TnqaofummsMhfq+uS5Blx9P0cVPztfSzdyoQY7N3cjMrVHK0jnqqvFo1UcaFZdQ yz5QUsEQrXGJJ3blQ1fPfGA5uAuzE/5Fh80PD5khTJwLbqzFtnv/sM9x511BIErUhtvOijNt LjgXi+e693nPQYPftj+3f3IqLlTmP3XCJZYjuXEsjmP7MU4f9x6CzfqoG9uuDcP622dTrj6E 92w5UpBlwypm/fQK7o0Pf9z+DExPt60pE1LWKa8DOK8p8noQRC30vij+42qtBexwACVhFd3r j1/V3L1N2vlgngL/OE8lf1KjuaUdegnYbPKdIHxA4A0ASd29Ml13kxfIoJ93+pkOxabTl4eK 8yVUdEeeH1L4esmoRhYSyy/Y0ajej+fqB58q1oMU3xXicUTRT3fRX5Yr6+4E7d+crchHMjTr D6u09BxoomQaIt2bpnEUUSZUPAbhTXuJPt9Y1t2zY9RKn++zeDA1wGbNdrNruwrSKCQddCSv R4AgD3GN5mVkkzdIRqgH4RFMwvRrDbQsN2N9zT1Q7qRcwmv5R5hraTUbQM2EKUw3sM6t06K3 r039ECBOAGO31w2EhTqjgfmicKoJD9lzMoCQXkGCfN5/K1dAGmsfMEzfphhd+L18VUGH0gey iUdccwCpzKLaP/EcnQDh1SrfRgkA92P9YRTOUSC3dg6146r+XLquwze25gVIEun8aD1ALn/C CBg9Wn21Q14YfbsejnPggdVX2hS1b1Atv5Tk6Io2UTMSWjYmo0Q5D2prDR5n/LFu9d9LT3UK JZfAM+Z5rU89HyMPc1emFr9SQ5g6XBdmYy3vQ4fePgqLmTYJPGPYO+8+mECK5U7vK9RPvzFH kZjtGcuL9dVvhihnzlkQB6h1JjOvFKhY3hy8AuvMZYOfpiX4bHwkVf/y3+9S8w4YQHMQOibX 7WOEVzA1BRPhYUrLp6Jxin25eBof0wnGvIgEeonP39yjl36TJOB82+/MgcUQOqHGU7H6209u dvsz9t60bWP6Hz9qVWhELftkcshJPPN3q3XmX72KzmW/lukG0hiVYeguTtBOkxVpnocptZ6T Qfq7z26gOIftiE+ONkzo17bv08I7qBQdAe4bCHLl2Hz90ycXKwUk2jjeZ2iOJdAjVFORraV3 cP62osfClZx2XvPuX69n/zBGizbUOgjt5DB1ERGjqjy9FjhzkiJSOI8bSLaZ1/c+/mZeTTn0 5Uaqgzaj1rshkValrniPU7J5t8K9URZn69o4DRmZGu/HgdBJpNWlxYlHqMJtXx7rDp50pZck Iq4uqJJO//5O4eaXgjEHGmp1JTZM6RgcM5LEoEuI27GoLG5b7FE3IYFJknfGcZRCY6Nw6gFs dCz0OEsurnaAil48TxRJw0aQNZxj8lWOSxMfl9i3fX04bn8GWN92VxJJthZCWnlpTopD4mUi QAMKPTpDsVzQ700q/y/qtSIJD5liwl7yCIlPdmlRaaxehWo/7rP9yn2+SUtImJfDvFuDElpB QrgNL+YMsXhjFEjc3a01CU16akOW4rfgaewh31Hdq9e25iqb1qopPyKCIBLDm72qJzcR8GXo 2E/R8TAV//6JThVTtW4UO4H/D6FpwlemgFLS+lXvgcZjUzr9ahD2JOfjoApJ2AWC8Id4Uavh eVoUC006zMEwZVwlL9FC+Mva2a6GYNA8lF4oe9qx+sdJTPeibKyKvoV1/sbsJCUQMrK1OLIs RZXfSXRrzTROPuABQxQaYnEY4T5IjYdrBEXYy3qBjBDuisbTsDxNBh0d+3kf0aB2inUv/1Uh BuOEQ3gZTNiYb40DLIFc0lqQiNkAGULrQISlh+jaJ7O0F0TavQcblf0iBYUgqwLqUR6PUgTI tdxBPU5U2SBmbQCggxQdKU5QCaAA63c+QEfEM4S3VhD+y3qiUYMbI3UB5W3KMoUeOiMLQ1W+ DHoZTiyd6wk7Oqzy/5muUMKKVoA4ARKrCXLVk+RCvNzXftB3dYFQCLFWbE5uE8Zrm7+XwdPL V8KjxpWaP0ZTe9ys7R7teXGVPpt7ljANwoCQVaznhAruMiGNlb/N/8Tbsexvksrx9BKeF0Ky HYuApJN/mKCd6PG/9v+2T+1vrAKs+HlLz2vfogyNdyHs3f7scxvT2zNhIRQB2ZgkcRwcZ+/b tjZ82wSGc/ySMIVQo2GQ2/Eh84LsMZveh23KS/+Zh2TgJaTwmbllURbCs7iAbTS9X7hWwoEg hWQRzkrF6uE6YhfBI7TTo033ZyveW0uNTbSC8GqyCtq06O4wZWRTsWP7MC+KS7t0drb6K4KU Ahx43KjeP4hhp0cupoOY6PP0U9haTqxzN8m5HMAQWGxOeZAMPfNwrsqwpBApiuKhiCDUsSyz VYWPN2gIHp8T9AuxTml3hjcq568o9Noaqxcg09taQS9mHuT2B2O1FyinVbn2YonZwxVNRe0i KKUzdre566ynRepRLNgeakVGOQaFyMonFLEECyv64ICafilRO0HWrILUcfl3KxxtxVlCHtZF bzMIGKO5Nuvvxk35IObn/0f7CGZN5r3arO40Ct+wMCOxwi2WP0b4Yz9FZ1Gfh3332xhoVGNf 3EQeonpIeS80abEXmCsJ3y2dFSiFRu2iJqMPg6v46qhW7WzSyY/n6fVHi7QupU5Zf9uohwmf nKBXTA5rIn4fzZ5Ke3Ric5YKMTjSUFpz/6Iayzxa5+mTUYEFHIwBM/ko7N7sM451cYoeITXA zWchbI2IcdaxPo3T7ZDlquoVyTqGxWxULMl0CIxsHFLEFQgXsdCD8YBjrvWrFY9qiDqnLJqT TdHYLAqRlPlXTZoqIKfAaxsDXvrbZEZqjGPaU2+cVubhWsFgPwroLEJ9nGtIIfltJKD2rBTR gG1e54jCSKhHNg4DN4aehee/8e5kHYaSJAPjzLpvtpNrymzpVfbRNkUCX65COBfw3RTCRDGn oDaaR+8TWtRWUy1/HI9py+kWZb1BNIMur0GXR1X/2TSdRnls3A3RKAy7BrNvo7r+hCGuyN8s 53mZQvwcfjRfaVT7GwjByizaS2LUgSLbuK9WIVfGVP21dFXDrg2dl5MvrV9IcvdlNmG4qDJq TZKCVQ/J5SwUczL9X7o5pnlNJnlcOJvfvtnijw96GG36RC/WeD8MuasmdGUHPRw+ma/UvEos bTDd9NCIpRjQ2Za3kIV2TSavbT+smRuDaNCMMfMDCy9hSuGlZBddVdrsDap4nCrCW+zb7cCS QPZ1C8m4A8zYF2+5XAAPjxV52DFZOu5rN/2YuW9bvfbPFAhC0rfzmVtPv+cWG5uiEKyepHp7 rC5+bonW3Ye3YYfg/aI5l3hg0EOJoDzwYALJHbXXlejkCwnyLEWB+gzymTv/xf6207Y98MPc ef+wRWJhqzaswzISjIbSuO8I/SBYdMdZrNfpKpedDWqEB9xgyaHEhJtA76RnwL5qkztjf3Zp VpSWD+23hQZaeGiMtuI6RWrWL8LmrNy4lEhe3nG2VXHACS0efgallU0ToejtcAixk0TuVQtW XPfsaJpJ0a+BfYaiYGectv/0P/x9uzNgUoDnoN0Toet3ZmFdEhcnsXoEFFQ4AtOLELLiwcNb szUP5ZFMcWgFHsaJX4Zp+7EKrYL36fyncvX6IwW6+4dlWnG0WYfxOs4DK02q7tOKpyr1xueL dZRGVBuI12f9sFHtvxqqYWDAnoZezX4WqPD96XqJ4y0nlLO8rFwxu/u14kK5+leQu8T77eae D4MSa6Eb3wBJ7HTCPFadPUg+JSpkxNVwmLFT9Eqj9ECATmLgjJGASCMRHQ7tRskpmisBJY/E q80nMWxehkHKWzKhO1+ZpqLZccqFdDHiCh4xz3t0L8l3aEUC4cYKbjb7ntCprbJE5BpzUTI3 3IXOjN4+sJf6kFb+4TUQHEOxUMFdEqlKwnctXE8rtPVLzLPAazJor4kSa+1sQj2nu0UZ9Box RoZOet3UAjMONWJHjNwuwof3769X+k6eMSLj47CI1H4hXWV4Aut31brGV3YZ3czBIe5bOLJq xas1iqge1oHfIqQO4q342Xo8HyrPV8Hoyz2Zf6FDKT/uUPeDvIYTLILnyQyFesgYjYLF2vom kAsZhjb+yqezQdNBb/QmrXPhB7OixRQgyLUsF7NpbdyGArEt3//j6eQpAs88iaAgiwUhK0Bu BXPzkjIpYGHfto1vTJ8VUnQKBMPkJdzH2XggBh+bHoFWmepK0P3v2Et6DXTBDMqOohLgwQ/r 0cIN9brw+Gz2zmp4+7DDuENNKyf/YWds5zax2Ah/GEhgphKbsdlbf7ov2DLjnzvkW+fs38gd xu3P946F5KJKp3T0tVwtW0+4LgbgARrem3MVxt5m91C7Rlvs7+q5uWrYC0XEBqpdP8jkuZ2K /1TdNbiz9J2g3RjCSoPpEc67WEVRVNK32hR9B72xib0OAGUcJnxl1hdqVhH8rgONUrSWZmM8 EDZmzlsfrxMIW+X9LU2nHklUAwVjbSQpXX0AobB2IIqpFDCm7W9T3Bt0ocuLccR5PdBf2INp 98KsvSGswRbI4+LK+n2K/sYFuEN++OO9zgBTy/8WGNAlFHYoZJ/x9IexZdFOeCYaq7Zwe5Mq P0KhGkIon+52OZVUgKPsD/9KoRY/X6MF/2+54r6WoQtwZ5WSG1kY3a7Xge1eW5WqFf/9qu4a u6p6OhsevDNT6YSijFfKqsnHkYBpe6hO/8dqDfxusI936ZFMF0qNpJe6hz4g8U8QkoJx1jri Zc6DGgWYbDzJZSMkNai5PaaGULQiVEtgFz+OcIVBYZz6IQ+5GOOMCqBPkAlHs8wnqT+xi7O+ Gt4XWrWR3IflZd5AAeZTiW75jzZCWX1AcOPwJqwXjfVACUZ4BnXwj3DTKKzBjp8L7jdj8e27 K1pDdOszjrAK0GuWs0imdiWTxPrc1+rkOQCSLR0vBhj6GNXql0iKFx1olWdPv7o+Gqftj5Yo HOW65EizUk4TAUDPFBxqVTDXE8Az2LMoWlfvpMCTcNuG16rptw7cFkh9b36ELt+TKQ99RZZt B/G1o1fnSMZX4DU+9Fq5wujJ3rktTofuzYZOP0grgROP5HP8DV6V8ex9fE+tkq/1aucvl7gu igEooQrqZLoeCXc8WXl0Uow90aPyRzMUyvUsBdVVy3QH0T3RbO9bKxC7ITfGTS9uvPte/jA5 5DyJGw+63T32gEl5k6y1Q/FGcEiLfvXPd2jy/7MEtGl+G9AnBPbr5P4levorUKoXTgs6+8VV tDUXA4slAbXiiFtMs5fUAwAr8H1oX/8/cFjNixUnVu6K07VHN2jBhl1Q3hMKo9eKJ4lmLxPE O4NBaLSl6c2fFCh23s3hvA/skqan8qb9+W87eIlxT4ijYrDq8olS6C0Q4lFYdu0RWIUgOMLB lttDHGZcSiiB9lKPK0K7aX/TLyzBPlkYwsNIy1C2H2ChO2+Pe2h079ZL3fIYE2xjjJ+G25jE 0ryB5uNcLcbciEWaQZ4lFA1lIawPxy8+A4EUJsFdS5W41SiR7cMrjIBiobE4ESbpMBURjkqk 2O6AhSJpe5pHB73W3Hht/9JcLV9FvuHZRtVi+V7flK3Fj1VrU0KUruXEKepPZisVuGsedQvZ QHprVoGgiotSE97MoCeStQTB5vV+FeGJ9iciKOdAdcR9DuY+xy8YU976bqWfwzCE1iMenivz 0ifTQAMxrDO0Y0PAoh9KClXHYmo6yJGlUsVt4oYO1G5fkyi7KcI3Zuy4wfY9xeRGSsnn0Xlw dVmNOsnxGROD9Ry3WmTwpBriOHXBAHeI+fdioQejPKwa3dozm9ecTQOrCEKx4+zP2IQjeC6K aVu7vKUNMsJhFA8nSG3I4KZ4BZN4t2sQxcFhNOm6/KkipVOvYrxx+SimOS/XuRYJI/k01YMD zjyqsbxwiiWTdJY8VDKw3M1sE3uZSn7qWBrIeZwk/xRv9O/PVCqWJHntV7N1qSBRW4+RcD+C 7NhKWOrBXECqQbof+G9cDcwC/6VQlwoT9VFCY7kvdGkIWG8Y99mMwJUwEcSDTju6JUchvFdY 16Fejr9jYboeONelWBpZ2XC4JX7fWoG4TW7/h92SmZbmzG/a+0EE2XrKDD0F1DeAUI0JJ1yy EBBbVn3t0xC2F9sPFZqBtNbMPede3/QDOZFwrYSwFzuwfbhhf2BhUJx4/kCqZi/mI6yR1PT9 WvKrC4HdstBubDv9lf9TfnHJRlMy0hAC5T1FUCt2OavKlG2AJcnNXAJJVnZxoepeIcG9whTI v/XJv22yeOkeOrtN9jeewrRGd9w+k1iSpgAsJGAUI17oRlpyY2hNa1BJzvVtu3Nnb7BK7qUL I9g2/jHjb4fEcguFXUy/b7+HUS5pJEobaErVXRjjCqQE5PLD8QvMwPSaGu/u1lBtDQ9sEIB0 ninmOxCsCk6x9sJz1ldC+OeJc8oIoHdPShSQ2HEFV1eDzgnWyQjYXFdNqb+5TsZhFuOF7v3U NZ5nhB8GwEAJ1O/A6HOfrFHyyUpF0C+9b0uGurHUDxJlKOnuU8Kb9ALvbVbLRqhI8AKSaa88 xr7P4IlWz51SKQSJIbj3Dsln7qx/cH7GAt0fHa7jBdnKCR1VXiWMCUaBwzW4WgeE4QgeczTc U2a8WnfF2nkpqsqP1byePsWzpiZ3NCse7ybZXTjrEw9mPDKInAaN41BAV7elqxGvmbZCCu2e VAQewwiQYAMCeFBa1kgtwNrYthE56ZlU+7ooXcGzsednGCVSiKWfgiIcoflVcy8Q5iiS3Hm0 ga6sUv7LJLlRRG0QiVaVJin/LDTyzGMjjABlKRDQ1lQr8+VajVQMkeAndAeQ6HAcJLRNtZpL 5f4wzb56MbrOxcQq4/hlhcPy0EIEvywzROU9zVoNp1zQvzaq4hOJOhraqyQ4yUKoG+kcGVZD VKJaGuuUgScW9Z1q8j44VxDAhqF0hk9BLTMnVgHVhNjauKfhIIAYExY+YbwvBcJtccOUg3kQ IZHE0aLRTLy+5bD3zRLwf9E25ItREe2EIfNYZPbB275sb/m3t4+mXweCtnrH4PNgrPZLe2mg 8ktY6okV0MbDcbOUWOe4P2FgZ3p7lqo7H/8x33GwD/YNC8951kzoxA/jtenBZcosoehxxLoc oiZBeI3zoJw7XOASxlYfcyN79cGexjv39rbb8c4N7Jaw0bRFZ3clgAc0l2TgZcj4mkCXRPmt vZlftkUzvW//7Z358c/7uw9vIwMG0wFoFeo4xhRoliAfAOznffXDz99tBng0AoPC1f/GG+7f rTbDJtNx+xfJjz/0PUl+GQ5I1cmBWn77RxUV7CAuFPAD9+i7z9+0D+1eEZ1VHe/vdc6EGnh5 xR5NjEq9xPv842P3tJqAsnVSxb/TCESB9r/lsO9fYVsOYucBs5ALAd/Y1i7ATpR0mzsZszm+ wz9GJaViLhmLzHBxGc77ViOc4IaJTVvr9nXzgezvM/y7aQCEkf0zG3jfW59csz/ti1YuxmTa 5dqjcNr30hVnq5EX+31z7fax13f9NtfP8M9dg02O7Ydrtctiulw+R+hMnfLtl1++D//GJ+R3 22s7p6fZH/8Ills5h+8inuA3/zr4dc522Mu/38Eu4Nd2/ul53z4O2t/cDGJBlFiQK2LYNL/3 YXeURWekhnbfLF438bNgpWxvpIM+RWGH4w3+H6PIz9JT9r9/GBx3cjJWddfWsE+jRWGK3f+G XKInd10aSsfemPElvhyIT9W8F/bMC6XUVTA13OnShWeoG2FVcK63PTie5Wgsj+GS2rf9xfe3 ocnTIEyaHlbxmYOFUMWccJDeqQlc5KBh1VWt1slvJip2PrFWMwX/jYebVqMr8aOZ/jd77wEm 13XdeZ7KVd1dnXMC0AgESIAgCWZZEilSkhVtjWVbMx7L68/2fLZn7fHa67Xnm90d72q8+3k8 ttczu86W9Xlsz1hhRlawSCWKFHMACYBEDp1zDlXVlXp///vqdVc3CgQEghJJ4QJd9eq9G8+7 95x7T1STZScBuWBwrwz4sN9ymine++E+O7aGgSULIRwfg5deDctr3SjQ7zd1yTmiXquUE9Se 8jg2VnkedmwXJxXiLicYeQ9+CQ+qdVj9itWyZTpcXPT6nVeHgLQ69J4VoEYw9teMrvkD5Ah6 WfAYKhSinmZSALmA3t2ybAIQtocyCH9h92g+hFGpFkukiAsesnnPaUOhUd195JgFdvViAwWR dciyGY9BCI9x2YOMC2Th9iZZ9YkK1XYQN+RUXTnRhqsX+U2IY7r2Wn5SGczFjIPTRnmG6+Rq PJMvN6UiGBQRHuFcw5Z29ly6i1wF6lJgwmZwmOg6Rd8ku1HYVzc4Bhjw1dNpIQBLTpsrD4z6 VLsOUzotLlkeAC0X+1zjl35vgABOoVI//DGi/U8+DyZZTvoGSze8XBqYcC5SeJ2MjHUWQlFA LXFlOVh1wVXghRxSvcjzvtTvEPIc5ckDYzmzDGDfEkIOpPYKBFvSGgoKzrzsPO8xRT22ggxJ ZTB6CyL3CGDTACObO166KgIipEc/naWmLjX3iiDdSyWp4SZ03JU1NskBiM6mVxsNl2MekVA3 VTGqhLnVJvv9f3G3DT4XxV4btk2pYgGjfmfBkrdBZMomiB5rd44uhp06ut0O/QC/2VF17+xH GN0iqGoeXFkCinKPwPx2hPHKCr22XPKnU32waC98tdfe9t5t1tgxwItiu8R6PfViD6F64xhU MYnL1JlfW4tbSpfBRmqK4bOsNr0k7ssA0E1y3o0mcegU06cJp5powiRY9IqZLPVGGWpl+a49 vWK9+1fgwxKydgthUJUK4RnGP1JhH0JHCI6CDkmY6Zwu8lyCXIVJDcuKlzbVNZXbuCAPC64N IWkQVUr1Q7zy6+m1QgBIC95Z/8R+cX3+OizP46aOvNCS9Dwgp3Uk741Q3+pGfX55vdGAWCCw qZT0fv03GNCu1P/hnnofKrtRvuzBpkvqBTFcPp9fyMvpo5IOTkdji308hG/n/kLWjUr+MGhL Gx6oil/wkt/K5ubreg7/l1d2owZwjD9vSzc3nnmF/XGUw2RTHmAYKMHQzyvgBSA0atXLu/FO /TyV6gvkvPfkl9N7XOMvFG13nHRLyRcYSHELdCsTENXiZoY3kIqfJbgom3SD5RCwUhltIOT9 tnYbTsoiI659x4ZinmRWsMdQ5aW6/HbYt1jLbgYAYo0TRGYTsSBvZoFub+mfTjf1fSDhzzTY g//kFmvD5oQtDs4W0fVGkiZNre9lArdeOjEmxVZeGI/b/Ey9NXYOkJdx0+WlORBkO7uELTC6 dGVX8UR1078Yjch1w/QvtLk40dq11GP5mkCXvn7Hmg1DFJp+atkWcQcxBe86DqKvQmsqCxLX 8OTGXfYtbVjtnkGTYxECsZ7IIE5BCk2V8V/osH6c50kQuUdaL8QykOO7BnY4s8SbmL6LSG/E VJhGlpKBWCSRpwS0myoBUbYeyaeXree+tPVjg1DnL8T1xq5ffEcQ4DXJ+Lf6XQ9Yw/vex+ZQ uycmhV7q6znvvqNOvl6ZGSTUAYNyO7EasQ+09Ntv3vwZq4uyQYGrcWT8I/YTL9xnuzBA5uDw fQCPDTgHsF3Lw0OfWXzSsrlJWGJwRcbgb/35UVhfTBo2fpUJiCbOeiphl/XfF1+ISOivPIn1 FAApKpZHFp5f0/0Fq6nlTMbRMBAm1i68yMkL7ECZoZ7aa3lpb/5qkyL2WPlzWYBXYi3piBgh 2MzkS3XWf2q7tXW/RD6Gh1sVHSdfr7R13Be3A93n/+Kc5323YleAHevXqvAsXFOrQasWxsl9 p2D0ep08/M6qfRpTDOszDVX29A/2EaIThI8WyEfHsujPz1gfCL8ffz4XiAUt78z4McY99YzF +1dxBx01ydblKqKIHKQBL58td6XtAtbEPuGTOEQaVi/jZuGxPkIX86ADVdG9h1FVFPtjlMhz xB+Zwo3CNw61WxHtkiAnnhuxqm0lFnoAlpbqEGwUFzp2HvcYqBWfxIIYJ9slmPkDuv79HUHA WyYWbmyw+M6dvChucLp0E1Awf0smDQzWEXhKTqCPQDx+sfOc/e+HHrG22CDP2vibsIFkL4eR PXjx8PzovSVB4QblwcNfSAGxx3CZsbBw3LI1crCCApRcCvmGeGJxIwapTED8uq4QWhfNMW5I JrI6QtzknpDNDwXsxjvGiB3CvEzFLBhftlSq1ybPxohaCAG5qAK0NkC480exht3OTrzM6loB rYK8cQ9xM4iypJNQza6C08a68z7Gig8rOU9U2pzT3XqNHx5hWJ6H36gmGMNFw3AteC1HYxwr dQiq0BGNpcA7SjSiZdYKhS+r6GLYvMZuby3OMLT9akJD5IEVeNEQDdaU44dKe0QxOOQi5M7P nrde9PcVWlRn4yQhLltxw71GsKg4ee791ogrF0AbRh5Gb/rGqHVjyVuLZW4RjwLN1P8g2iwh 8Xz5L7XfemxCas7gPwyX1NKU2f5V3FOgJbOM6qSIVAgBeQsxsKtxd5LfH7FO3Iz/k/Mr1ogL ifxtGDXh8+jd+O9SUj+dz6wy2LkH1z+uHAIQjSJsCyePet0n3pV36/XIqWmiZVvFZD+C0sr/ tv2o/dqh3+TkwfTERRKYy63VZeYz23C4LARQk5DgLZ+0cY1YJof21dxDDH0UOCB9R/aByihr f/MCq0xArhZIwJrmHeBjiQJxQoiJXUuskP/Yb3e+E9G/2KMe5rfJsb028OU6qyI40saLoXP8 l++ou997ylL34D+mFBJWXdKcjkRz9srzfZZbBpFJMlaWhKBlsHjyyTYbOH27bb/peTAV+Sox VcvKXd2lN5kU20MnjNKwy3F/qVryMVNjVSzOV2uIbDppFV1/Xy3jNX4mkLObqO1PWb1iKnv0 dp2IyEmh/GIlxrO28xyTCQIjc3W5ISvWoFuPWq3kIN3fmnIdc/fYqTTgTbURnX/ndBEiU3uB +olTsKl+8ol4CDASxsL9ss7H8a6KMNW9bNhXzpliKQZJ49FFa8rgp0uOEzmRxGSoVWrXOVMk f4UXcI0B9taujq3Z+hp9K49U07wG4vHSatx+q++Y/eqhf20YXzPtasCRnDbQsYoEiHIYB6lA OCTPc4v8rQwURi3isZqdsrH5hy1fmAAX13HXu7+mneWWVJmACFbradOP9btbL3QUlLfYEKqn KDHY+/7ZI/bej0nBLYv32QuOeBVzWChHcUBGvqce6rP4bhCREJKf1BSaV5HItH34p/7uImTg 2CBipH/yl+3JP4FxsZWAwP2JVuOQ75vEUD9yo22/GQKiAFevQkD80TnCV+rKOkHzH/r949tt zMjnXL8zC+MI2SoRBn8Dp2/BvZwNV1bd+qXflOuC+wA27ns9y+t3of6BzPPS6NiS3IlVz0HY eZzRrSc65+aTnkFQinVeWT9/kfxr5He7WRGICvW7MZcDD3jKjba/yVBbfnldu7joWPKu26Vs bVeZrqfrELgMBDTvPOIRtX+z7bj96m0e8SiuoWkUgOef6YZdmrCOqglrjnkT1F+fl6n6TfzY IxLZ3DTE46ucPCAeAdTk2fWHgrhTChDedw01Nm0wylIZRii7K8S1OZ/77dhBQgZrCFOEOJSv lIpYTUfR0y7mUAdjFx2NI3Rxisl8BXgAsg8m0D7mZPitL3/Mnv5kl9XuzdvyMF1wdUEZEHoU 3fERNogEeVuT2sWtuVwYiCasralBsTDY2YpVpT5DZWK4DBg81WCryFliVbjByGPVTPtrRUT2 W8bmjyEoPhT/KUHb+iaVjU8/RSRloStlhGCRfrv8WwGlnDzSM1WpYx/fleQ2LmPpY1M/1D59 1Y5cGx//WXn+a36ttraMd1Mber7l+Fr+3GeNrt/bmv9y9avgeh4uKiXmHmRp48l6/o1b16+u Q+DVIMDZ1ck8XsLjw2/1vWL/022/aYphVQSXiHgotSWGmYvwk79vkkc8VrOTNu6IB84XHfEQ bsXBZBFvv2uookkduHz98QvsdrmkBQsGZHcfj6PehnVJOABxwIomQiRClMYcYo3FsQ6CBgTD 8PCFU/11znchtWJp2l9eOmhPf/2gfeUTu6x6lygR/0ustYgCOMEWcbFG1CW/vK5LSQhVeeRC XRnicSx+6I+65/rGeGUrkUQO8tIf1dr0T95qXQdeRCeaPIw0grGhTkhOFqEaqE+IXaeDLMGw uORehpC93j13g3tKyidtshRuCORePkdMZtG4AhpAPgnxuywV4Dx63VLbyGb9fNJSr5wq9aNY XHD9UhheBfP6riT/vfnfWxv17/vfl3pedt9nG6vIpne6tY6tv5XdFfIqu4i4Vcjv5bz+eR0C F0NAa1NeLxLsyI6shux39hy2Xzz4bw1H0454BALgH7fghVu4x7XwwVs/ecQjvTrs2FbFAgor bPixhisbuhZb5QV3WQLisXMAJ659v/Gl91nj8zjRApFGEAqDYfk7AABAAElEQVSffAG1zh2Y +adD9s1//DFrPMwJAuF5eRJynB0L2NT5sF14FJ/yo1VWdwvIlfckZB9rLNr4QIN9/u9+wcUK x57lkjtu1RVBne704VoXQOih//7zVlUnooO3SWKMB7FP8PhJZOyI2lc+fb/1HiUwFUGjdCIo 0KzaUptSEdakiiTxpTQVsv/6Rz8DcRHQYMfwNXaOfFIh1njIKJcj+WzIPv8X77HW7e9wSgJq d6K/2mpuhY3FWFyFdDKMq4FvfeFue/nwLZXzlQOIaxGw8n6E6YfgrhCZQ8drLdElu5fNcN1S xTX56VooNSNZhTPw808d3K/4XHxFAZKk5w7p67d+8BcquT5x9SEv8fl9euxVqItS4qbe8day +l2U1oeeVWrLL3/9+zoEKkBAUybCWo0wOY9kQvZnyEY/fuATXhiatSrwh4iHEngBsgEG4Lo0 0dz9t+pHiXhkBm1k/ksMPwPxiDNyjZ8/LUbthl2qDI/LEhC/rNxUfOV/7hAHqkSncfu7G4d4 nbjbWA3aw7/e6Z45xOC1uP4pk//YXk4JLQWrb8dCVciw1J9wYs3mBmP2uV+E70g+/VWqw69M +/2mPXmE5VjY/1KPk8urKolG6u+BQjBo1V/VUbBn/6zRvj7VTH89C1btKJpA9uH4huaXXCrn iPXxNMGj0Pj1Gude9XYc+ZUJ8NXfIMTt/LNNduIznLpE6OhsvBtjulomXhl8VefZx5vsFbTP Xi0frXmJsnpPF/WDDie2oWsd18v0M78O33odgK7ASc2XL4hdFWZQBXk/pu0iz5THsbHUF/4i GCzJG6rkGzpJyruBxh7khbt8yzi4awVQjEMGiTHCfxrxV4p8FVNUoBctoqJUkoUF0AgLCphY 86axBXFRePgpJ3QBLNhdWzpp+m1R/fV0HQKXggBTB0LBPIat/jIGZX9zy+P2Y3t/3zlaKDri IRVV1OyzXc7teXVklF+vhoFc9jf5h6AizlEYQ/NzNrbwMAsS7bsy4hEMEOiPXXehiNjBYfzK Q2a5V0iV4Eebre9CjkEJIU7H0sGtuHbrIRZxywMscBCFv2Mvr1X5nT0Hu3m3Uy97KFwRxl6k /T6wypZ2nc0H9zRcP0kmkKdd1df+Lj5KhdQPGRw6ZYlS5vr9eWvk5FBeXoGhXB/8tnioftft o/2y5NyGqCD5ZBzn11HVnLcaIqRBu3nIt8ZURhBdfuQk1W3k6/RLafwerPxmy5rauORhw4HN mmWqW/BzSYW53nrKKz29ui8h96WiTby9yQZQ05WthpwchiEgrTiJ6/z6lAshewZX3kvNqNfS B6ngKl8tRoTduJyuPpG2ufvr7SjxHFqJ07DzH0YRugft/D/rtCGimcnGNI5q73bsPHYQ3Gb8 AzixI5ZIDLVRqQ0r5bD5kEuSfQ8PE6d61c7/GGUJpqNoabIvacMeZOcjqPn2Z2zqjno7e1er 8/i7+yujLgypvPyuv6Srg8T1Um8xCGhmxSEeWYjHWXaHX7ztEfvgzj/mLtqDa5KLingwOVlU eclHdfmWT4KKBkoU0pXjNrH4VS75DZ/cO3kIADqZyEPI5QFSmYCoDSGrLWlpGD81WI8HOTUU FZPCW/teXhEVkHWCIFFX0O6mmkVEtkbY073MdNiKIPyLXqz6RnshNK7iDVCOUl8zc0wMHUJg J60j3bKWdC9az4mBv63PJd+4KHFLxGZ1BWBKAOOPtyyjCImeRapBhsBbhCc1CreVfvj9Ws9O fYKRiEkQA0tHVEusL+3gA+gIVGrDlaes8odrGHOjCOc1Shq2Yn4QkvNpjPz24DI6gm+dkYY4 ho3V9u7htNXhnmS8o9ouYIHeSdjNGM8ncO892Vtn78Rb6i3/eMbyH4nYc1if3019O6chSD/e Zl/BKHBfKmtNGAyONiTs6dvbrXYo5bS2VtDQ0qudwZ279BIaiWegIDsKkTv+jib7JmU7aKeD 8JszWKx/rbXZwth87HtxkBCiEXueQD0H8BaKIt+lYXaNQHS9mjcfBLRUZeMxjeHyOPZgj9z5 Zbuv52+4C3+fxRYIiJeiqaOcEWuM9+snSUgTRLEpVVj4m56/WX5oHCIW+LlcftmmFzl5OAUn LaLyMYdhvaOBJDkIp5JXS5UJSKUSWAvf8oFRq67N2MpCzKqSvIQypCoNpXw+bC8/3o06LzIH EOUlkWGl+v17jEXuzGXvsf8jw5ZIEmsChKsh+smBgbaX5+N2+tkOBqtYIQU78J4xvnGzTN90 evHbFzHS1jmEO5OpUaLgPd1iUewy3H2/0q3fNCjiUd2Uteb98/TBA/zWbPqt/k4M1Nvqctga OlN26L0I5AVZtesnDYDfq8iLIlECaa0QE4PveBUuW+DN4t/sVSMNqio5XVyaT9jJJ9qZB5ro 1ygJNpwQ5Jdq98sz1vvFCTv6M9vtGARlti9p9UeWLMr7r8adyI2PE4L2c1M28tMd9jjBhcYh DJnb4y6imqFQEOWvgN3HDF7p5Bpl5/FZu+G3ztuxf7fLHsK6fIb6dv/XYWv76rSLk/4k4U7j 5Lv3U2dd8JwQYUfPvr/LMkR92//cuO387UEb+uUOm7+/20Zx672nB9sg+tFEXxXkx6XyyXGN QHK9mjcvBLRWRDzOon1Zh+vyJ+/8rN3T8XnuSi1VfH7t7rQcfXlHzlK53cS4IjZ56Lh75rCs u2JyOcFe6fab9ktbXYJyQTznFg/b3MrjHvFwmLUcUWlNAZmS6m6+iFKUIy5aZBcvtMoEpCyf WBYSpham8va+f/6U9e46ChIUMivVV2pbqq+ZdItdOP3zljoWIlASzV7FRllEKY+WRH1T2j78 039vrV2LTitK/fCTEL+E7QOnibx1+GMAJWgLTwXs/f/phG3f9ShxR8Cv6h/5VE4nIgnQIxDT s8fvt9/+0/ss9g4eb+YW+dW7b8UwmX0qZA/80Zh98GN/aauZVurSzsVV6z5Q6kUTbcb6Tx6w P/9ff8hSF0K2/4Fl++jPfwr1YbKUE3X134cV/cG41dWlfgpOgmkCreSKRE1tUleEE8rg2Zvt +Bc+SFx12Elkrph/00iu4IcqoY0VBhcFMVcfSVmE2AQZ+qngUUpaQ1p27vlExmpHU7AGeK5x SdCub8qL/RVcRd7B6UHW5LOd1URrI0bB0Vl7kIho9cSqDmDLEWVA8unK3sClCAQ/gi7wKvGd V/FyKp21ek4lQQKjV48T7xxikSVCHDwJl79AW2+Jde0N//rnNYKAllySeXQUc4K7qxbsT+7+ lB1s/gbrpIH5iYbR+k7bIx7ZQiv2DZP2DxcetKlUk/3Lg8dLYrkS8pJVK5tTj2V9jTr5Xa9m g3jMLj5j8yuPMSbg4VIJKblruCjIPoqomdbG9xJuow+13ofZoEsOUkKoXqH1z8oEZP1x2QXs hQhBZaS+G3N6pbyq0uLHHJn6YX0UazwEqz75z8qquKJLykp4nZqkw4FOsOoiOwNJZctlFLQX xvcuesk+CykLOpqZbMD6HCQXFvbmxQtjFwmZmqkC+cLvjGasvuG8db3rdltcrKU8E0MM/a2J W/IuHMcvVUfXAEiMbkRQXVZWzVB9+9dI72dnOm3xFGF666HcdFuIPhSnz6Ja7IRcErYL5RH+ 0p9swuJ1qCCrLvFe0U1eQ6AXIj4KGNjLv/WTcVg87d6BWFnXNAkZU2EDhGRsd51l/uAGG+qs tV2zGQLgzGFxTp/IIHn35M6k5X+l18b3EK8NAtE1vmKJF3E/8k4BxGVjEuLnitCZrbh1P4Fb 9/mP77IDz03Yzb9zzgK4tslDJBRxTf63vFKUUx9Ejfwbqkug0GuXfENpE7UswdV7cv3zOgTc HPaJx62JBfuLe/7Ubmp6nGnDbjYwsz61PGLgfQ4udxAPq84+tOMvLJWvY6pprsGixx5N0zEU wsd7JMMeSe5NpKVVNkHfFDBXjzl5sJBmFp+2hZUnWbeNjEPrp3wNMS7WVwjcSVxFW8icsOXs BTxjgEfZgQfcbg0RwZYxXwJbbcmln+SUfzUhvUIuYuklEBo31mBtrGmXyv1iabf6mkBMYckj anD/Hgpj+QgOLhZA9GqHP7WZZ4cr9py/w5dMIdGzZmdewPm7bC9gDxWdd+AiTgxb7PSRPu80 RL+TdQO27Y6MpQcQ2l6CfGoOScsnSQjZ1s5xh8SKeRGEAN5xGxg7fp9FeJwKl9nI0DbLjOET i1OLcJxOFJJprJXg4+Ckm4xlbopgS/0teBRG/5hbM+NN2JZUW7JlijYlO9HYvHH68NVvB1vy u3fwmgBc4d26W6hUMz0m8Ib7dE+9LSPbkEwiT5hOl+iW8PhRhN+ffrDXjvfUWiOhNJuJ/yEt NyV1S/SygFV6/eFFYjcP2jZiUo/Xx+yRB3rs+K/vcFHhnIaWwOdK+R8ULCMQrkZ9AIrr6ToE LgcBTZUkk+9oLmZ3cPL41D1/VSIezWxqN4iH6tF2SX+r+e32ihwlEmYiGclhQMgGzgW8IaDV 0m6bTO8hPjxIQnGJXAc2z1h36w39sUE8ZheehXg8BS3wXJMw0LKec43QNhDEN2G4iWUonL4C lwRfd1qA7FjDoXo25hBix4fYKHrlBGTTQi5iaS7KJEm9KvMeevvYjcqv5sqvTj6wggGoASnA kVQaAZKzSOI62r/NchwogsgERESEd0JERRwdaGPnUA+STfMnoQKTqn7I9t/zPMQoAxzCFsMv WGMXnNAp1/2KXdSY8qiGJ1EFboGFJlh7fFPcPtfPwWoioD1sm8mhnTY/ZjZ6Om6JfYxeh56y 5CYqfc5DzOQEcmqkA1uXnLX3TjKGdltZTFhtw4wlGyad4H9pTgY8JNh4kvs42Y/GzJ9g4Gax AOQylTV0DS7V1wUGvufUnH3kr0/b7oFFe6W9ijClqEHPAUjBhHZvOz1rP/nogB24sGBTNREb ONDElNIOpaxbbCTSPUzG0Ywd+nS/HXplxmlSPX1Tsw3/YJuFZtkQaHv3Ksk91YvYoF+Vc/vV +N+Vc12/+xaGgJaDiMeRXNjuqZ62T97zF3Zz8zfBCzp5QBS2pOlMhzttxML99uHtn7H62Biz X9sg4RiP09FRfcZaE6dxY97CxEfGx/p7HZbdlp5dy5/CGQjDQUrT80/YfOpJ8Aresd0oykfC qOHwhEI847SxlDmJDyy4I7I/0AZZiW/dy+YFy8277soEpLx+1yB8bSF0eIGiFatpNGcQADtV I4fcrv3q9TajHvbwfFnRNi9YRKGth3i+HAiKnAIcAaO/EbSTJs7X2OxkC4LprM1PN7vsuVVY RqmoMyaUYZ4QUlPTOAyvS7CvHMDQG08HcQk/a7HYYImAeEhUj10CqDW1xH+eOWj9TyYs0cwp oSRTUZ8CMgYsZXXW76jj1jXPW33LNCyuDMGuJumn/IaBulEp1F91nYJGcQ4Q8dPL489/tiYW lirUUfJag7u08yfqhsWw7Wj6wpy1EvFPUdcUZdBtOhiU3kDDiUXr/t0h23Z4CjYfxJFjSbGO hVcaq/vm9HbhB9DC+tkbLN0Ws/2/c8FufmUav5YBm0abK4sTRslWfPiUinrjowI3TG4quJVY WAHacfW6l72e28uoTvl/F1VYlvf65VsSAswQq2PDdSQbsZ9onLS/e8cf2v6mR1k3uCLZcvIQ gVCKBDOWCC/YUvYGW1rt447ml/5Um5fihJxQms5SBhz35ppaJeKB08HJ+UdsMfUseJKds0sb Y/R+i2sCOxlCEwgmUEKCM7IOh41RyzJdJ5OtyYPo1rvlv8khFdv63XKKOOGQcqIGTSy0vJ7/ 9g+DqPcgZNEq3yi00ezGvau5cmgDhL84v41Ig/dB/DQAYkEkYG2JEJaQqcYVRqV38ZWgDZ3t lUiBnf006rcJTkrSFisNXBn539bRD3sq7+xJtuIk9VP3siMB27Z32lMWwAdXEd9X8ve1kaJW 1ZLCc2WnTTxfjS0LOxRfIqxMjmfo5ZZigMYSjXKi4n44Dixr5zg1ISSOYT+DxlmQe5FqhNeR tPeb+/4z9zyGIItx6QSzcYq8RpDWu6MqcTjV7VxXxJYa4x6S9wXkEBmGYQVYWrmdMWdhXo3A 3cku3Lvwxuo+gXEOx4zDnFAWe6stNJ/HrXvGUtStOqQEU3p1XiENgz+dSqSFFaGtKH8LSYgp xCHdRLwRngUVOEr9Ibl6dKG+l//p3vX0fQEBzYR6kPuLxPL4UU7xv3PPH9j25Esl4iHHfyhj rMnmo3S6YPHPZHZzmiBca/ag/fbLD9jTU3scrNZKrKutgBtBa1Lziyn9Jkk+8UjbxPw3MRQ8 Cv7Dc4cbgSAmlK8Fo8QG1mlbIbTlflPyDquJb2chskDX83DpEmX8Yv4tvssx4sbtsoy61CKO YPsRDMHX4ToLrz6Xjdnu/RdAePPsmuGXx3BjwolAm1mHlL11vlHnVV1RCf/D4UlrxTWJ2nby Bbj1IYT2/oDUptSGUxMhGx3utUPqNJ0YOtNt2/cO03f4XZR1WIuZ0Nq9SIjdgK2IHtZwX8/K k4gm9gjdu0H4knGjrrU43cMFhLRtAHYTO24RJR73n4B4oFK75gxQyispA4D654gYHWPCZ5Zr bWWpndocdF29fklHbC4S7GuXgIPK2JJNj7cgZ0cITdF1r8F+4av9pn/SnqoGZmf3N9nIv2+w qSrkRWg+1V2AcMmlO8+zapQkw0OdJnRvkXjY+R0ECdOL4p7CzSrGdNPEikWQl5zf12BL/z5i U13Vjs3VMJmyMBpezv06dekE4+iuxsNfGKJUP56yIDYmrxxssZnfr7LZ1oRN0c6ec0SJG2Ge 3SpWA7tD7j/xP+6FmPDusQm589Fha/zyjOUhgDq1XE9vXQgIodezixDx+HFOHr97z/9nXdXH WRPlAvOiTcKuqkbhpiYigoIib2SO9bpINN0q+5UbHicG+oi776v26gc+GNzK1DVT/E2UNojH 5MIjllo9Dp6SzKOE4DhlhEKSY4DyHJvKU+vViCVoX0ydglW1xAIH12o9rycBofz3+oNLEJCN 5+tXTnhbotLLC7VoEjVZx84jcp8CYQHLUr98ZMlNhdxyVG5uvboruxBGoa5TR+5GffgUDale 7qnyrQ0Ao1gPJ5CTSUujOJGoW7Ud+87SNzL68FNpftY1zlhLz7ItnEMwlBRvc2OWCDEV0MCq bU9bUwsCdNovpOKoFQ96fYY4y7dWGI0u6QwMnW6yCDKVi/pDnarVR/KS32iXo9PEmSP77FP/ 6u0WaUaGBPITAVxPut7ozvpt/2IN4EY6ofulnbh//6q/1R6uSCKpvLXPZDh1FDkpBKwdddtD Y8vW/uSss+uoXshaC2q4DvnjjiS8nLfOybSlOGnkerDqJVhUJ+Xj8/DxmmD/PTtr70Igf2ZP g50kmmENware/eKkdT8yacV6xg2BDolYEHAqJkDyjjTsQkPIuh6dsvshGGf66uzszjqLQXDu wop9zxPjTvEhJDbbDKc33o36qj0VXFu30XE/uL6e3roQ0JRtgHgchnj8SMOU/Yd7/h/rrnl5 E/FYWO2xqdVq21V7ch0QWuex0LSnURUcsHa4FhtJWyCxYpVLO3APafQkvOOy5tgbO9FvWN4F 5L8T89+AeLzCb508NA49i+BMtx05Bp4ltNkVktYTafto5SFjzhJEyiHZ0jNvRQIjl0f5L0ZM lU8ggmspr9vdYzWdmQdR5NA+Cs9ZTX0KY0KKunMdFZcwYAQtJGxx3EIWIi5/PdR4FUkDw4vv Yo2tLDeCl0b5CcKQ00PXP71sL+lkEm8r2uixGLv7XkvUD3JKSsLukg6zlzweJ/x3eKMdCLJP pdGF9ivw8zAxV5dC1v2OlCWqXnFjlLC7qibvsY/IF2TXrHKp5Z3YorRaRL6wtp4aRPyoK7Os Iw4ELUk/SiyuIvKMdBp1WGl3iIA4OLpsXn9eBXAiRE6ZoJT9NX/RtqIKth+es5bj6MmrL7Qf wOo7Mg9QIRZiABx4aNhuQl4TJkpgHqeVVQjI7/3MeWJ+QEzIG8BX1Q+PncaSHIUHTsRB4iXv +fyI7eiaxhUKb02sqQHYcsiuFIRKQayqiT749k+fd0MIUYdzR8JKjULM9vz9kO3Yhup0jLwQ m8ho1hkQ5lvD1nwSDa9BTsNKPuwAdyiNESNOP6+fPjzQvBU/tTTqWAMiHh9tnLDfu/tP14mH tK1EBDQpcqjDe1I7QYHJwRN9Kg0u7YJ1k7HeGuZvacch3OA/H1+5xRpicxZDTtLgZL1eDV7p N+KncIKsx1dscuEx7+QRKDt5aJQ8F1G8WI7BRg42Vhgh+qrckDt4CMr8iXBowxpucScTyUq2 psoExIekclOPNNkyMyE6iCCGBRurkmYScc2xpUjUopGEeqxTEgJhOsKh9q9BCgToMGO4474v Y/8AFw/LNvHyxM5xU8LxN72GhIQjCKWHv5m0hcUbrDkwiEEhMhDsPyTQdvCgVCELsCKL1rYt bblRENuuzR0VnFeOBqz3Y3lrwJjRcnHkKbOw53AsxslDHns9bTCzCyeabf4ksdiR15WfItzw Q3ScZhPVHgGTfESnEfU7l+WIiBWeQk9Lm6s0hzd3ZOsvVeoGrXq2PnyNv6lXhCGySNhOvUAl 9Q2vwoKb/iILqPlJ8C3kz7leuaK6N8sbgRjorB+fIJIbxNXlIZ9gGR/iiIojRZ1yZE/iuq4P igjRx6axxFcTPPfGx7VfFr9XLti62qyiLH+af7JED0OQvM7xTNUBFL8f/Lye3pIQwP8a8/NF BOa/1D5g/+bOP0T19iycgEa3KdSQvU1iwJoTA/z5QPAmXGna2Y5az9rcIx6aywWbTt9sU5m4 7Wt4FocKEjjDyiFN4L2XyeXNW3fnjfbhEY98fpEQtA9DBC6An/yTh99XOUXElgUC4508tHr9 VIr3QcwPQc9bUzIoBHdGmyyTxasGpxdBycGPRa1vP4lcXyZRVLtyCEixyPbRtY0xGJaeZ17q ASEnqFA77dIjai/v3mUqf9XHgMZVFq9hQHqP9EMaTe4mPZ8cabflc+yAtat1yFlDCxNMipMS p7TaZnjmuC8pEJVQAacktxDxkFxj+z70nAWKrZ1lgopINbfDFGEC+sg6SLspZBeS97hC9GcW ucjKKYgKxE1VucS3+KaFTD2yIl5k6f7sRCPaa1QonKzsJYKifuv0ctk/P5/fTqm5a/UlpF3k NLGGpbf70ynLx9E0ohODQtuWq98K6StKoBPIaMwqL2KipH7yV0B+UmhEAYFv/557rg81UWpv /Z4u/LIQHJUtEPbWGRWqP3oMgFVO/fHLq++uH16W659vIQhoOjADHPF4CfnjjzeP2L+9648c 8WCVs94k3yjNOzduldA0UikhPD3Tp3ffLULuMIPcJx8WDc1bUxzeN6m39tucPi5W/3UP31Af jIkTQh5LcQnMPeKBOu6lXGw41pQPJ2Cx6UQBLNZ/e/ASO0xpNTfitLTE5tp6CmHVVUg+nPVI 1BdkF8dJYigkKgVu5viYqCZecB8xr8krAXEcou2Qpd8/l/PqP3SikO+q3FIV7LJGdrMACwLi 3rkmAv8bWyatqhd3GJy83MmHMrGeovW/gi2I2JjSqwXz6PQQ4Cg6M95jJ164mx0xwrTksDXf ABEhxsc6S4i+y/ttAo+7DQ0I12ij1CBthJwNSCjMrhtAynf9+Egre5dSeeVVeYhBmAPGxEi3 jWNg6ORRPKhtFJeeTnEqiWFDE4T/qjFeI3Cpo68tqf/+H/1y1+qc30H/mX/Pv6+8pXs++4s7 m+6tu4D3y7gMpY/yev37fn08U1lXL89EOBwB03O16//5dah8qawuN6Wt97f+3pSZHzwX0Vpv r/x5eVn/+tW+L1W2/P7164oQ0KsVCYhBDF5Eeef/7jti/+ltvwCyP8ETlDMydTaV7uVaOfUS /KQ9s9hSrFeepbEyH0t1If9gt8n9mcxeG0/tc89hkFptdBC7j3PklC4iGx7U6pWaxMIiV3nN 7sEb4ENyjQzxy0dmv2jpbD/dRFGFmBORiCcor9hFJ8+QXV0Y1lQD45IIAiyGNlE00loqAuQQ uOdyGMsJrg6JiVSULzQvq7bTF6cyaAkxS423aRuqpxjcqI5gkJfCYm7uHvRsH8Sr8Fc5tamZ 15o8gqDAVTg/g3AU0ceWOl4oAhLWO6URqeiG4LfnfDEHu/Qwp5XBs+34rkIOUjuod49NR9Ty C0lYUQucQJgYwCweP2bthx6wgSPVlkAU4uRKGitEN3mjWdeOca8dGpIjRV8V2LHPMEocQcPr xCNVVnsbYioIku88Ua7fxUps6xYB4iWsyL0LUzSBDyjZ0ajr9POaAMnVdm0+xJ7SK3RIU6cP 4OtkCXw72QTNVJQtKK+QfCmfhqYkIbk7bek4pt9i1em9+UjZ3d1oQ6cHV5bsPtFwYFL9+i+h O8J0JXfykX0KVSr5/fR+eZ/lJyH1zVlBlrWtMm68Wj+lPq6X99tbFUDotn+y4ucmODFJK8KE 8g5+lIXL6sGvvK+qlhPfGxIrrQPhe38hkCkQVIhJ+TIbuz/c97T9iwP/lxGaqJRY/xj+ZTVp SUL82qF5JwvWJUbFs5lua0m8TLyPHhtcqSLOOeuSVB3GQWrpBYjI6LTiERxvjqk2pRnZgXBd en3u3hvhQyePVGbAJha+CWtKVtHSnNoY0UYfS5PRjQBuDdbk+cIip7a4IyA5rpXkZJGPjWKC DQRqHTFq4XJPhKc8V2UCohxq10/81unHvRiuZQEuraxCJgFChr2Vkm0GiL28jF/2ar+pS04S cbCFD6Y07CAoBUknAD859k/ZaJwcBO7V7Jkw9iAttuc25CBiG2F4kF/NoZmVtTp8a8FrsTrk G9tuzdvxv0OYex9tqfs0l18KWMe+tDV3cIQVwsB/leoVYXAJnzhIa9Fm2GUj/1hjtW/HCEcu 2X2wcqn8oRjHaiZ/errVZibqrHc33mZlnOTDSN9lxbzKv0efDC2HfUcWF+vSsoqhMVUEwa3i Nl3fMTSs1NfVOiaUEmtMuzrJS1xQKTznKp6HyoXlYZG8qUaMTUHAUSF9fmdQCy6A9KMZ8iBg 1z0RiEx91HmFUb6IEDaTOFuNmjjaXdLSiiFQD6zAPuyM23JXApDizn46a8khKL1YaNShfhbo J/sa9xa0+YjPYF+jNsiTp3+ruGYJy1swgna9n3Qd/sdgt+l3mD/1xyW+XXtdcVtpxQ4FApbE pX1iFPkOrLQcMMoCqzCaYJLFZLF1cclHaqpKR3H6I9iFkC3F+NOmRYoeq7SraEaxJWx/RGT9 dr1arn+WIKDVJk93QXDAcdhWf3XgMfv4jb/n0Njwyj58NbXjquQRa4yx0XNJclHWF6kobUfW vGKcn15EQBnosraqlyEkrXZm/h22o+4xXHb45YQYhXgxisWXn04pHdWn9LpceiOeQBzxSPfb 6PyXmeCoxYfarTrabQvpI56sw8kzGJdjSWmtibhooqHIgt8vlc/lJi1FvlikzXL5BfD5Cjo+ yiN4+Ely2gY2vPjwy0smJJuaDfyrXJUJSKVJTT+85Uk3CNASRB116PhONKSasQf5FhXrOeka rgm9VPef9qIY3WUWQSKZpNMCU1NiFzkkX+qvW7dEG5x9JmijQztsz50vAIBVKHStjYzegCbV 08grOMlot12FPUj7NGBt9U4EqpDGCli7dfZOUW6C34oFIiKpiYmwl/YUpUsIVG7hM1j21QU5 briXw5eSxk+WYhavlvjwqkFHPRpboQ1NyY2jcEjiEB3cNET+riQJ8a2zKa+kwJXkoa+BOeJ3 /ECzvXB3u3UREOrgpwcsuFy0E/+0h7ggCXvX5zjag0if+OB24McyxVuukP8SsLjn2XErJsP2 1I3NdtfzE9b36TFbuK3Gnvmh7dYwv2q3/e155l3Ajn2016bxiXXoGyPW9gK7P5BxgIiFw+9u tmM3N9tNZ+bshv88aAXkGqc+1G1n8LV1CHfu2//zmA3+ZIcdxyZkAuSt1ATy3nt8xvq+OIbg PGgnyD+B2xXBssBpIsppp34uYzd8c8y5op+8v9mev7/T+s4u2I1/MWhjH2q2l3BFn4CY3f75 AU95AG0vvcbgQtFG3tNix26H8McjxsbXulaydvOT49b2uWkb+clm+/a9nXb36WmrOblsT7y/ F/YKho8inKQ0hC8GoWo7t2RTO2ocQb3jywNW++yyDX60zV68q92aiLly+6cvWABC6k5KV/j+ XQPfBx8Ch4iHRLcvQzw+deBRiMfv80uIMAvRmLUkxFnJOznoqmAvTr/DttUM47NpxJZzjXZh cY/d2vQSvq68XfYMcsnhFPZr9Sqn9QgeAIH4p4/VQp2dX+qwnppTEKGNtara3yhJyH8lfYH4 5f9I98E9CLsLeM/NiN2kXb5LfHOiSMS2QVCyzgVJJFTriEcW/1b5vDhJEkl0IvshDEUOXOfK Cqb+ZAQ2nDaiEBxXd6nmrV+VCUhZLiG3EEh5cTSC7UcnDS16Ozt23cm6SYTNQyB3US0WUAmX +l0oq+YqLxkQ/9cgIGv4uYlXI3gAbcvVRwD5iCd43ly12EXsZW1yHH4e/QkmCnb88RttdqrR dt5EL2FHuRMC3U3WTlii/QbuAXDKCfFnh/Ewu3uRkw71YoGeRd6jOoNoVelEJPU/iVYuvJKk LJPPwxteJ9RXBi8aI3cvRbzxhmHBRavQfiCfc0dCzgIypbnjePttZpJS15qw1Ksl1QsNC7ch 1++kostkf7WqLnqmuthU5OALzHNKWCGC4I6bktbwhVlLcxIYZIfttKpAzJMEf6plIL1DyxbN FywbDloVth8p4DSG3cZcS5WbfgpONU7ePMg0L7clwGQCFyY6qFXLTkTjoT7ZczRCsFK3tdop glFtw39WoT5sR7lO4Mak5eySpW5O2IsQjwX6cdeZWUckXtzVYIf3N1vbmUWrem7Z0jybrIra /oEFd2IZ6a6xZ6kj8Lai3X502WlnDdCfXsaYxRPwwM2EJcbS/kPPjln1hbStoaqsOav47am2 qJ042Gwj2LDcQ3t0075xQ5Mlbm+xhofwTMwpSmPTySM+m7WdQyAnCOS5bRx9SX34EJMxZMvp BVvFjcvjxFTZtStpVd9csbEb6u00gbp++MSshcc52UrLrXz+uBq+vz/0Hrz45bCtYB996ubH 7KcgHkvZ3fivgoSEllGxHWUxaIPnsZ30rRQDmaYxEGxExliD8XEmuxfWVb29MP5+1m3R2pPP WJc0SF3yiIcuHWeF72ho1rYlL4gjS43qyRsreWyrfojHF8AxSaZdAzgJ90fFJRxDDjMQyXc2 +i2V3ZB06kEeucIceEwEuGi1iTu5DhIDZYhNuBCQOCN6tlFWI5fAPCfDQndfiOLiVJmAqB4/ P5TYWXnDFsrlPZuGAMh0ERfmZ47dYHe86zD1b0ZqftGLm/vO7ugVa6MwN9VpC3Pt1nfgaZDd Ru1SqdUuHlHDehIrqvqmNes/HLUFuFB17YZBYb/dePsTbp4FxEcQhqfL3X3jltwLSWJOSZNL zYkbuv1GsUeoFxW+pITfggd/LgYK5Cmfb8DKvdlCSW7qmZ+41ilQ7L14VcoRED33Ti6MRqq9 PJMzxR//f48jk1n2Th+lajZG5lfofQsOUiiYm0zaY5/dBzuO4zpKBZva3lzkO/sFOMTbV0Ap sV7GMd6rS84TsAnnkVpN/NdzuRepWc7Zns8OW/UAaoG1sJnYeU++rd562M2nYCURyQf/Vzhn Iy+QhpUVg92DB2XqqEvnLY5BouP/U2+ReOuN3563m25etMf76m16X60jOnMQnoPH5y353xZs +pfbbJiIhLeMLtvOvxoCb+Rt8RNREHOtpWFrVc0sWYi+iZW289EJa/zsnNX+UicBqLoggLDg 0OSSTEXjEHtu8oEmO91ZY7eMr1jPY1OOzcuo3YsLLBZs9UDCxiAeO/EivPvPsSXqjlhzW9Km I2Fb3QZbTjDCQl8bhTqI1/5jHP07wjb6Kze6JXPjpwctNIYnaTYd2ZaoNXbAFqGviQ9lbKi5 yvbh0qXtRQgh80vtXuqdq0vfbwmQQgT4ZKP2Mkorf33zo/aje38PJNkAy2maOVRnwysdjoDI R5zv+NCDZNhubHrYgcwJwnm+HVbV+MohO7kctQ92n7WOmgGeDzCdxe7S7PRT0DKFemQrs9Zb PUC98D7oxhvj3QgqbDQ5Daykz9v4wlf5rRMGrHO4IlFYTOlVEBjE04ODxqTOS8Cu8TJOsVtI WQhGKNSIkD2JrcgI+HwGLXlffqJ2ypOIMi2gHuzg4NhbW/OALsqLrF+XQ44Xql17okcufT3j LXm1rW0ctbsenKSITgLwHJEVXLOk9l1fuWCVReOLtm0Pxy6acB5qfXkEQ9s6JKcxRsjaga/V 2PJv3I3R0dM4KRyhQgACEpFA3k0e6m3pmEU5II0zxKRFCUkrjazmvStWXa38SiB8zbMSPCTE lyB8ZqLVpgaSFoGAiDhUSs7/jvg8dFBt5ogDIvuPqmQG7bWT7s/VqwHoXamasrY21ak8IJwL h/fZI38DxRPCV9VbB7+p0Hfww/XBg2UNSH6kp8Z6duALiwbK6LVDeJJ7yFg0mCS/5iUEp4bY 6AnyLsGiklrvKvKPPKcTmWqsdBKZEHnEMmyvnmkUInCDojIenkDpAQApdkhbd9LO4fpkFeLR DTHqPoILbvKpHsVFr8/kcIWGOje+3pJZyDz9SMcoLSNFusGhztmdSIdG9acoIwBJ+O5kNVwv c2qYwKVKhHmw5+i0JQZWLd/uGR46Jwsp8nJCmYJVtncczQw2FRHYUfc/Mux8gEUhUnLfogYd 6HkeaGMx40zSvxeQY0k8GaD4Zy0vzVvPLbDexF67u9W5fdl3ZsqqT+Ituo126cf15EFAkFD8 8hSA6+c9/5dbH7OP3fAHnCharR85Zl9ywBn3VYXBA6QN4uF+8ZG31UIz9hywYbFKdzZkLJT2 6mP2c3tfUCaS0F1p/bsrj5CMpXbaybk+u7/rYU6cvE/hND6/90m9EPEI2lLqBALzr/MbjbRw K2wpbNPYOTvjP7FO3Oos7zFyHRkI8qfTh0ucUGQPMrP4mJdfJxYpQKmsOwRoN846C+E5It5H 4KnnBOgSLJj0FVJlArIlo/ju0RrxzGAhUY8M6pTCURYyK7cACygsCWapjdcKfI1Fp55QcFbw Qu01zYtddYRsZZHYGfWcEC6RwBPOVmRxElfkg23W1Qd48tIxXoEN5fVMXnkVICUQmHBykPOr tQAbcoEAvfdWBKaJI977kNc/IQsmtdhO8pwr5D1yoQvHjaj77uaZkH55cvl1gx2vNMZKCRIC O6zRjr9wyHbtP4VPrXFYmAiFgVseA6YcMpNE9Rw4rwREv6C+3W5rmT4QhVD1lz+7FtelCiX8 TeJaZAYfU2OHGiwEgvPbEhLWTl/soud+dpdbijpV7P3WmEOUNQiFF2ujNteF2jWyg0aE33ny Z9ohRJxAlkDoSeQSAWQrPutGp5oi7KPmIwvWAdtoinZz5NuDq/ha4rDn+0KWVhAz2hFLISg5 A/1wSFwd0x/vQ+88wrs5fW+bDdxKPURBrKbv23F/EkS+I/mNiMZ0d7WlccfSTj9aX4AdBQtp ExIX6KnLETctHIiFTjatz3L81yNkNgqC5fLwW99qu3ztau5qIyBWV3Q8Z32nZu3Juzosy6mn ifgpnYdn0CFXHSp4PQkCgkQ1QF+BVd0Ph+DhOx6292z/M+424DV30jqrauzs4m7rrh7mlADL kbchtDa3CsHIIIOtw82RS9LI8tZcrljt7kSIh+60s5BBBhRdkJRGJgqJx62Jp77ZEJuxO1r9 hawX+EZIgopwFD6qiF8+ufgQP0H4nD6yEIRouBFr+xVwIiwmaUsx6WT8F0MVN50dLA0ASAmx MdcC2vWRPDcmsLVc8iYvKxvcWAVxwUyD9gprOMtdHeK6nDxUnq/UfplEObGJUlM4zRMiZu5L ZiA36XrzsrEQK0n3feTH5VUn1RFJoKfdX2Vzs3e4eiSPWJjF2tQZEbLXEAFTI5XH5IhpvBU2 1ivE1+AQEURuISIgZKNyTiUXoIsl1bFz2XKD2lWzQ305YD0HC1bfTD5iALgYHBQI0G44ognm Ec6x0T4cMVJe/anQB+EY9dWHh/JE5YwSPmx3H0JbPPe6ci5cpmKi521hhiNoCM2hIG6VuV/+ Z6WJn0AGpGCL4sJd20QH+Z/hlFA3lbGGZdzhb6thhyPx4pbEvQJHixyuR/L8kQlpOkZenC7Y eNt0b40tiIDMpK0OIpKCqCzD0spwkqhfxv6Fsutqs2oWjaQI1ug7T87qvOfYXb3HZi2E5pU0 qMjikgiYe3la37qpn0qlb7EdzvXW2nOcYqZps0oaV4vyxLyRLUcflJZgbS3t4FSQ0enEe77+ Wf671Lja1kHT78t6Xl1UIgSljOIqtBxbsGaE5hmE/dv7F63mHKePBP14o+CpTYP57v8QqEQ8 jhG//Dz8/Idu3yAeSF5dh+Igep1APOIB0S91MxlZts7qk/xSLcT6CS3YjqR+o36baXJ/7gdU XetJhEdpGmH6heUu7xH3xLqqiZznt55XfMsu73fvQz0VjsNZ6corJeIhFpXmL3MWfLGqE4gM /RzxUM9YK7ovgThCdf93FjaVJlsYmYn+Nna8/jgFm6gjPN5cZqvGe8jlxylXWjxcXSpdPgcw lZylpisP7wx5ADgjmgCRcfpYTcPrJiysOqv/qSVUHOFyObmN379LtXzJ+wIQSCUOAohCEalH 1uQRtL6yCKa1q5cW2KsmyoRxkjh0FkM/dhvoS9JPkJ7sQbLwEhdq8K4LLwSCvm3vspN76GWJ tdXWBcC573aSaoTJnVlupU1CWiLDyAKCsfNVFkUAvp6nUmfog+QUi3OwuwgkpXeRw9lkNLYI S20S7S4IFARFVvIiCO09/fSp1ZZmURG5xFsRXCrhq0rNf6f3hKpngUEDcci7kTdMI1BfxJ16 HAIhhK/TiTSc4hCF2z4/aPf+5Vl729+et0YE3SIiDYsZyyJbWuAEkgJZNhEzvY7A77OxiM22 VVmr5B/4vgrAcipfo1oqQvLJcdzYc6SpW0F7RO5PtEvXAbA0YPetomwm6OZGHcBOv3OUvf+R Ifvnn3zF9iOknoRInEO7qyAZiE46FNG3iOMCwvSRA43monWqrvJUNm+lPCFFgKlDdTZ+Lzu+ FqJOqj9by5SXL127NqtCVvNyyrqAzTjEq2MEeY2CaYm9dj05CNSIeOAK6cHkpL34jr+19+7Q yQND4DXfuAuFFOKW9y/e4vJ7Am+9JNifbAzT2Xcg57ib3zp5uHOqy9eSGEZtd9hdextBlfBe bnf1oO1dP7V4i83XynIFvqcfHvGQFfjswlMQj6/ScTgV60hBbkYIYBfpZA0w+bVDFlJ2Y5fq MuGyo7tL+T046VQhL7uep13hzvLdizzyriITOVeqhy9KOySuy8ukyqjKg7NXlGudfuQqPZeD glFCcTGk2hqDkKwn8tXUItRBzi4PvW6Rrz+88guVk+FibdsqarccTWkvgKqshNIiJIkaxQUH aOoXhMFZp2+pXog2jHxior8WATzIW+uVe1lkEJJDOGNAGfVxv7Z+wup6UxCnkNXekLeWlgve +5AfLsqo/enxeqIHQoggmnMzu+zCE3Gr7sMWZoNDtaUH/FSbVFFVM2vVtQu8Z4wxeyYgHhkI kpw8SnZEoKtcAuePtbaK59BljB0jUidV7BHcxqwVURAt/Wm87hR1cUuv/Y6ArvoZawGV3Nbn Z20VOcA8Ngti/bixlFoRYozN5Yg2yDuZwMEhqqgSSSUXYTHybKk1blkISPP5JatF/XUmIUIU tWYIQ2iK05YjIBQoT5pT9AFc4jXFtwM9PrQSnCR0MwuVkafn4CQnE9pxGQVjvyoQe2IkbcnP L1oDbccRdss31hrwlMFgCgTejcbXvqcnnJrvICyllf1VFlzcciLSfKNaLbEQKr15iOLz7+yy R+/rsQxxSYKCxxUmNwYZQPpEUBVfTw4CgqJOHkdXY/azrYP2qbf/n3ZL6z+wNhXQCNYjBoKe oBsVfjzo7qg7DKIL2YWlPbaiKIG8eOkz/N6JW+2ZiZ2uTp1CfCIRYr6ITmcLaFKyhpT8E4iu j0y/y2bTt7g21tAiZGvk8IKeeel78bLoIWwjaT6Nz33N5pYfpSvquzbVsN8ce451wAkhnRtl omJ7BSEJB6WXLGRE+IXqGy2J/MJTYfFGohmt32yHqF/KB+zC+LWR8lYV3UVdPdymHfJv/G3k qnSlmi5OZbDT7jC/gtV5XxZZhEfRMytCwoqgl7b0cjNea9m1U2ZpPmpSCAhpB1/ev4tbeNU7 wmcFJ72ttqUJdpD0oaYZnrUcm2mBi5/A98C5vTb/bNiSh9hhliNzJlYYFujSmYANn2+xlu2n gG+I/nq7GhHu1BLEkO8E7gvaiZE+dKzaGrZLQwqBk993YTTydO04TX+gjPxMpXfZ0BO11v5O jGtWywB10Yi8k5ROamFipahsnhOQ2FhhHDzqlKPqown02hvpF1k6G895bdP/oNtReZUG9FLh GEbjS24qXNTUa72hYdAXUf1sA6q6z8MaeCBlo6jDuh13qX6JkNZgc63sQ113m2dkGJ7jZLGS sQjeeCWAX8YwUDYRcdhHEZwrFnuDthzGRfsERkuTEBDscDTuTYnfuqf9o4NoqT86nUfQ+mpC e2oCTayFuzmGL+P4jpNRGCJSlcYYLw2cqcztq2ANFbZBfNUG90Q4PBmHV6/61PStOduGGu9R hPbjBxAWnsDZJjU4diOKAaHZvHUgq5ihvcU7kk6WsYIRYgsEMKL+30TNW/uvtjYNqPSDfCLK LlUoU3ryffclUCiKoGJ5/C89p+03bv9VbDtAf8TykKfsVL4J4XkjrCXCR0emtdRJepmwQaPL RBT0ZKBhEOG/PvApqxZnxCWxg+EUwK4aWbzPFti0VcdOMDeSeOw9QQ7VBCKlA/V4202Uyik/ 5xxNf5I+NF+8F/bde20e8cjmZlDT/Sqb9TGG20gv5LwVzguCbckmis5IUH30ZpzkFs6K3HU+ iOCbEBvawbv+a7zkg+DIlXuIiIN5HCrKOeKqXLevExKUVYqouzt1Xq0kkB4Gig7pOBaZ1xY3 LkqVCYigViojYCued3ZFrBaQ7to89hjwsrGqnp9sw8EgOvt9aGORf3kB/fhFDlsguxL8L2rw Sm645hmH1GFDsIHkhDA90GtN7ahVos1UZEcRI4KfnssnlUtlb1p9DmHBvtQftsnJXcybx+kP FQIX9ZM9KScAJiFyjoameSzSs3bsc0Hb/Y6UNbRCDDXmsmOe+OthseqyZiPnMCxUJWXtlXpQ 8ctX4U1z6hjC9fueW8/B1uq0ocN7mCB6wVSk9lSltqxe45vr4r4s8CeGONojyxFBvdL2N1d0 iV8AzMklIA7SegoP5q3n3Lwd7cXWpSQ3ENuFfQTha6P20If7XH/HYWl94PCk3Xh8EIEx1uFo Tx1HE2snbK4qjAirx+D3M7BhBNd7QPbRmZzlUYvdJLgudUmIdpH2q2hHoNUBsFiP9t+ZlG2f TjnV25WP9Lkwt1Mg9xsJTJU8xaTvoM+UmaasK8g7imBZnqVvC/S1gFaV0IGeZ2BHxVAD7iQw 1Quo1568odE6d81Y1TAyMoiPjBurTtMeJ5WXdtTZN354h1McmMTG5UbgkTiGa5r30A51Ffz2 1H/gIvmRS3qFfuJa43B5gaMjJpqzb4bkFn75YK5Np/Vua9ktvIhniZ/g5PFrh3zi0QJiQ6WU tJKrwYK8xY7O32RNnGY/0PM1iIRnj+BsQMijdypr89qoTzzUVyFhT9bRnnzOOpCqYQrMfeQC JO9EAzpgTm5Lvuju6WNw6XZ7ZvxWO9T2DBENj/K8ylbhAsDp5JoM6vTrmjziIZXZcWJ55LJD rHHfo65YVjLoq4eIJBkfG7L0OQgB4+Z+vjDPt+ae/iA3ck3iNMlK81GdhwjkMCDMGptjfzAu jz8wxQLRiYYB894jqPrWJe61FfqRyaHsAy4UC62CRBRceAVJ/StAzUXdlcQblvGbHCrWN0/A igMp8LJaulaspmPNpl5hjXmnxiuo/eIsbtq6saG5047V8sqSZdL1jpWWh43hJgILsbfvtNW9 7RYITAQET5/KFyfXETR8hk7XWQ5YS6bikDlgKHCCkSzFqR8jlG7uoH660bV9AtxArG88DUtN sIh8QsJwERzDnQp2gXb8mRaLbdvS1sVD4A6l2GVJTqR+RWOr1rMHrTJAeO7lHfaHH/wBDqe8 MPrjv8aK1ZTdDHdD+LqJzwFB1/q+JkkwQ05QN7Bi73l6zJpBzMV97LhfXrAHsX0Qco7MO6Db 24iDLr6AL5eQ64OmIbTDQPQKSLX7pRlrb1q2atR6JRGvgYAcwjr9IMizmXzSvhILrDw5WQHW 51GM8t72wqRTm41w4hCyVdTDGG3f+rVhazjUjDAez88g6u0nZmzb89Ow0VDDrQvZtqOz1lyD ceMs76yV/eZQyu59lnmpeUvdNchX3vfchNWPpTihoIX1zIz9IPWIWOaIZCgsoROQiKi0rg58 ddhq7kZWgtaWaPpeNLZ2PAYS2hPagBMnKqdNprJEYLzpeTZRJF27VUV9IpTFZsb+yry9G1Xm mAgVwbbY6pWD4I15rR3NNU6qMQmgX2J9vbN+3D5x6JMGx5OU4BVMscNmRUAAWnDFrr99dftQ V62DhcVkIqm8IxzuVxTbDYIkBZe5z5ZOGpPuuaeaGwrANnaaV9o16g+4r28KtX7EyvHqTUbn 7BAefldK2qXwGXC02IP7E/CBJsbrmjziUSB++fTC4yDyAfCGPOpKDiB8y2YFbauVzBl3CgkF 8XDBicIjGppk0q5SH5mH7kQhRK/k9xuowd5Cf5IsIDvBQAjJERCX0fuQ4Fpl2PEU4Hh4lu2l OYCvrWB4G02CD2Q3UpaujIBQj9g18jGjpLklTahwVAPhRqmvYU4LjojxvpTHH4IrdBUfqlrv fmmhFaO7cXcd5eThACAY4ONdp4NKDTmDwhuK1v9UxOY/3gMba4hTKv1nokkNWUTQCdfoZAs7 oajtto4+5Cy8D/nPkown5DSvqF4TEdZTanmHjcASi+Cw0TstbBlUGSzUKRGsWBxBH07cgqhA J5LeJA+CvJIg6SjIjor0/8qS3v13wIO/okppW3KChpNL1nCY3QuaT4oKGEHOsRNXIULCLg4H le3+IrsU+rApya06KqvgUet6DMtNxf4AhioTI76I6nBllI9d/kXvSu0jq4ijibXnH6i/1J4T 3Gu8lEmeWrEDx9HOoG8uyYcU+WRzIhZb97eY1IBWYXIL3Isv5GyX6lLdbCKi+PLae2ZYVmrO VX0EuU3fF+iXnnPqKHcnIlgkhlftxv8y6LVHHmcFyX25pG88sWSNLwAn/aYt1RFcXbOdqo+k 4FxOSK5yJJVpe3LW2jMzGDV6ZcRa+35LenPVfLwE2+qn2/rt/7jjP+Iy5IwDQ77Qac9P3mo3 NX/Wkswd4ZkgQGp0Hnd9SKkG1mwJ4ehksZBtRZX3Bttb/wLPhDj1tIDA/RCyjzrb0/BNLNG3 I4QPQpDOl57zzpQP4jGe7ra6CGrB8LS3Nfyj285Np+7FJmSH3dX+CDtx9kFil6vp1yUJB+l0 MGeT84+iEHCatqppiU1PYh+GgOOlkwZAAbHqtJEvwCFxhMXvlD/RlkHy4KYILpZWL5TyaH7C eg03YzvShBuok7DQq8FFcephDm9KnkdeN6G5v5w7x4tIQ7RaLVn1bltIHed0Iw0p+lKWKhMQ v29+Rn471dFSX4U8Q7CwMikP0SrYk5JDqlxe681LRIRKGIPJsUp4Wee40TXoD1c/Nichb6kD j34raSsre6xlbQiELvciORjxIAAAOrpJREFUOBSDHeVOUcLcLObWzjGroe7OPnbOQCQa086k NFhXLQCg+fHBWlscgnAiDtn02G9aRdZhV7rgyxP6M8GJJRIIaywUB+msYdHsEZD1Qu7Zd/2D fktlVkjRjUsIDruKYn2pXyWEJ2R8UdKYS39OQC4soaQyqs4v4+dzDyt8aK7LIE+p1J67Vt9A wi7pvupRP9WM36+tz9VuWV0OoWssfj9VXdlzfm0ktZcgr/78fujaL1sOJ91T0uPL1OcpD5DX L+MKfn98CLXXgBReXA3ab+84Zb9w668T6Q/wIjAPclIocP6vJxYHJkYuBdnkOXYJhETr1O0c uSN7Duc5d63aRpZvJ565XHGkOS3ssvaqszzjRZDqkJNg7UG9Sjl8YXkbN7AWv73rPJqcUTaF iTAGq8hdcvlOcNoopxC1tgLxAFm+rknEA+8G2UnYVsg88E8VCHDyUP8gFjlifEjm4SaML5tw yFtA0sg0Vv0JPmxUozs4qRAkD9ZWFMG6WFZeXZ7QXT6w3KmFut0JhlJe8haV5CxijzmWGA+C AdT46YvsUCQbcfYjJfj6JfVdWpnlt7gun+QQC7FMVmdR0V0FzeokRL9lC+LUa8UKWs+/frGl wqv9SX38r6qd4dTA4LAUjxCLXFbeLnnz5ZKVi5sOubCBU2h2iBVKx/OoDK454cpGsTpCtHY9 uGw1qPcprUndx0+uDdrj/8xkl628hHaH2GVbh0q+AlyMBNpfigeirbvj5pMvjNZYAA/G3mLg WelY7BFcCqquK/3z+3Wtv9W+j6BVt//bR6K6p+utf8rnp1crU57Pz7/126/7Uvf1LvTq/Xb8 fJXKbb2n334f/PK6Vyn5ZdWe/iqV9evyy/tl/N/l3357W8uU53mLXmsNVIOYRDz+ZN/z9mt3 eMRjbS3piAc8Uew3RmxvwyMO1ONYhS+sbuda6yWPML3GZldbHHREPJSoES0qHLlm65GB4OBy BYeopSdrxPtoiJ+iTNJ+47lf54TSgPxkAiSoXV8eh4sP2PDS2+zMwi2cTurs9MyP2sD8R3GV MsqaTtq22iftnV2f51rERojUfV3jD+/kkcGdyPDs50D2E4wVdmmJMChO+SryhzWE4WG5HsFo 0CeiIpJh5CNuYkrzSsSFVBVFGwsZiWQg0RD4DsTvTXiFusXbLoS0re69KA60oXCEKx0RUwhU FYQnHu6mTBPsuiqriuxA/nELhNkzUJQV+0LqWfpGO07WsnkSazlenCoBDYwpQhIScgQByppb NhXurW+pYXMTWx5e4U9HpCBe2RXa4DSRIrb49HinLc5vB7BQ4Ep93FK3WH0xAkxdeFl65UyG MJpAePUtFGosx+lJVuCCSySWtlvf22/VybMOWUjWoRmpU0xmWUxaGiPf4AUdhyMODqUZu9Gi 6ue9ZdMcolVeWEeD4H96GaEcXkBzhOLUb0U1lG2NHl8LWG104g12xfiu5D1dca8FrMsBzG9T 31eT/PIqeyXtXU0blytT3ofL5X2DPhfopL6gELQvMdf/eN8L9nMH/53B7XTIPICrdcfrBGm+ MPEB+9qFX3IjSbG+5NXfT6s4TpVnXKWJdB8OALeB1CftAzs+ac1VhyEOk3ao5Uk3zUDLrCnv hF8XTdu/2n2Gk4nHs5cnC6Vt1bO4RFmwLr670Mx6ZmKbnZzd5p55/dF5KcZvr81R1PuF78q6 VMp7tV8+8Ri2kbkvgGOk/SUnpGqBNkHqiUi3tdY+wE+dwDQmn1EEVEUYyKbTQtgJ1psoh3nB yrPILUa4DjtWlVP7dScu1Us58LWE7xncuONhttSe/BsuoIG14lSHVyFk8UgLdiQi2P6I1ZjH VvMWBI/Kkt+zsltc6u178Fv/4Vx26B44sJDCGG+xCvsG+Gi6V3rBXF2zpB1+kBcXjUtmEXHR AFNLGHQNtVl9a3+lsVzcNv0KE/lv+HyrZTJdUFcAzAQ+c3SHNbXNWVvfMBbVCIay83bgrqN4 F0Z1DeQfkvt2xqUTgkL3xkOLtsA8PP9czKr386p5fFHSu8VYNM/8dew+EVneQXqZmwxG792d nKhXWmX5SSbGDi/PRXV9D244B4e06zSkNN+0tZDAXP5KNJf47fJw7WtROdaQ8mnsks3w3096 FhTV5r7z5ssDn/fvl9tUN/mV3D3BXm5jSm35fXHtqD+kTXXolorTF9eG2y2wh9VaK532XX7l KeujK0P/lEcbTj1242DRug2oxl3Kvwk+l4AHudeTy++353/TLx8G6xnLL8gn2Y+zNWHOOLjR /quWKS//BrkWyPwogoex6frjG0U8PuEOj0XYT8GAp06fgYsRR0C+s/5FYnu84nrfV7Ik994G bvk5YSjJ5uPcwnabSHXbh3b8Na7a9+PC5GVejyagACxlFza1bPqGV/Y7bSpLHFXRUoINA2Fo TLzo33DfH9j516gF64WSAnN8qPceUtetWRdQan0a6NZrSOXE40sl4qFgAJqkXpL/qtX8tK0u o3DDmHIiCgjORY6VdDrJ5+mfIg9y0tCJYi71EsQER6ScPhyryReIu4WL8XIEVzpYpOczqssn BoxZ8pcCsmUhd+cmpWjzGdSdpQgiXv56Ekz0p+R/e7/Kc3l39Kn3sTX5i4D7iki4MMOREMpY R1hZz5MdaphzsWtiB+KaVj9LbcqBYgjC1drd7/7WICgBF6Njayc3/xYRitSu2cw53I33t9jO WwAgp6ad+4eoOm35FCyxKizsozNolKHNoXdEGZ0MlGSzUSO/W0BpGZ7r6DNVFuuQIVsFAOmW 3ok/nym7NI2BYEbEbwmhfBb41OE+BS2l2mVcs0OI5F5lywtRu9/VRL+FNMPnoJx0p9DJvhGh dginh8EJnAd24RsHQXYQtx/hsyzCWhBzMycoYCWbieA0g0YuUGyHVyr5QOm9haYh/NhjOEE3 BnnSZpHfK8EoPAlvlXKy2XDOEBG8hwdghVK80IMAFflQ8DxtYZdRwPrb78saQuhCqzdl5ZVX frWKHaX+iRBQZx7r7zUJ9XkWglVZREsroPqpz61TFde70prlz5VHfhFSXbCcpdUlB4xhPPOu oV3mZEOAJnwBNiQEoNDJ2JHBBHG8GO6X1hdjbAYYWnN+AgZ65qIy+veZv8U2YCRFAv+en1/f eg/UH5zCRYxUj1FfDU/j3wjcodjv3+tpUt7VV7vW65c79jAU+BhH8b+6+Wn7yZv+g0N/a2vS ttqQLYylduDnipgtMRQeSGfm77OnRu+wj+37XaaUzi8ee1x8+AiGv/e2Pw57ay+gImaPbM9I YnX5ScL3+WyTK1ekLeULBFKws9qRi8zR9qodnr4DAtNs7XhIuLP9C9ifgL9cUm713pse7oIP d/rRfLkWiXGscAoYX3gYHML8ANE7OQUtK4VA7k4OwakARAXrqtMaag/a9PLTbEohuv5JBCQj dyPyeeW5KmEqI+CW+3av9944dB0KOjU3rigjg0PgFeSeCJH+4tHtzqOvCM9S5iw4qfR+fGRI iY0keGprsJEqE5CN51yVoEffHGLVogN79O4d5MJbDH6412Q9BitJbveTF/pS3tCmKq/kh5pV BfQwLArp2tcAuH2FFQueLpbJY7goH+62nbe9RFl4rlUIlARr6sni6lkRFkP4oRJhcMQK1V0/ OcMkXrbYZ3MXqqytN3cZA8ISxNg2VyURxkVxB1LD8ZkqpZHlxRkB2QE6te8P02/vu/pN49rx 52rDNv4zra4/Tc/MYgCYs4Vbk/iLqrE61HmTJ1Ysszdh0x9utwgaTg3Pzztr9Ll3NthKOwuV 7WHty7hoGUE+JetvTmHj72m28e24XMdjbk0qaz0vz1r9YdwpEB9k9n0YirXErfkYxly4+sj0 xm32B1HTBh6tj0zZCr/nP1jn2mr+9qwt0pdF+hLFqLD5iVk3LSY+0Gw5IiTW0W7N+ZTlqHf8 I6023V7t/E7Jgr3zzLy1Pjpnme0xm3tfmzu1iFhq+mgeySljDerLdU8t2OLBGhs92GjzMlIk T9NMyjqfmrHYVNbyDdgT/VSHy1+Hh135s0phxT71Iw3OBUv9t3GCifaVqxh4SgNt7OPtOBTQ S/baWuN+Ek23mrOo/5a0t9xDl4E8tCm14skfbrFxDDgVtKtxPmNdz89Y9SD2NG8CIiK4+sTj FeLFfObWb9pHd//R+jCRpKI51UisDmKmsAndVtPPe2DdIbcIBDBGxbNEDxs5HT7FCljFxfpo qhU/WKcBLYQdpFoX804V1ZEx8nirh9XEvzU7t9Tr2tpdexJCQgAlJlQ1+GMq04h9EciS4HL1 EQxEMWzdXuedRNYgOmJRsTVxZTc+NBrOIm6Tt3H3aq9EBJdTZyAeX2aeaOGJQIJ3nFquCCWb EYTgbnYKeZeOwGvwuvVMY3WEFDlHFq0tt9vjs+AIi9huyuPNNy4oT92cSiLEOs9k+8FvDe52 ASv3MG0WYJ3JM69zLEu5tAJSUYtXhwdX77d7Ga6s96Fd9kaqTEDcCvMzlX5ofXApo+giarCy gctm2H0V8QCJNbWETbJ7EIIMwkIMSjPLyQL8erZ8l7ehPoJgi876fEs+fip4VHpJQjAJqaHE W9+1e1L5Q6FoV+G7jY/1uP4olrs8CM9ONHESUKhc1DZxjyJgibiIXRYi5rmSIyjsCgWywZMY LyK7ckTePb3Mh9hnCM9liV7gGCzHi64dYOO02DhJShgv4cyVEkS16BAfcLrifrxaNwV33pFY JU8dbLMxkP3HBtLWdDZr5/c32SM3t9gHUZVu/Ny8Tb6vxT79tl67c3De7n50lskXsJO3ttqT ODCEb2AfCodtz8lhpxI88q4W+/rbuywBW6pmNW/nEjXW35W0+zPnLf5S2o7f3GrPE/Dp4/NY r3960VZuidqX7ui0egDxUVSB53F//vd3ddsBYnY8+PCMjffV2ZfubLdOjBF/ED9ZtedW7Ch1 HMXH1o/OFSz55JIN/Q/t9tDbOq2ZvtRgy3EBVyyne5L2AAz1MLYkXznYzuETbRXG7DwLg7Bn AOaHigQVO5myZ9/Xa+eJ19EJscsxuZ8mJsoP1Mbt5r/pd6q/T9/ebudxEvl+XLPs/9I5W3l/ tX323l57kMiETUQqzBEbRScImRYUCHn71O0dNoQn4SSELEs7GU5j+25I211EQKy7gBfV8pMI aykwW7TBf9ppX7mtzTpAvlEIzjGMGfc3JojqeAH3K7KNUedf7YV+756pW3LHHmANiXh8+haf eMSYHiAxrMtroqc13WFHYbcFAQliW+WS4zPiBaLqvHUnnwCdaWISuhjniI3ROlc+jL2HkJu3 GrV7Zk9Ne14S4iwQy2OM+jnqkZJOPVf1mO1MYo2u3Qkrua/ucf7cbeoS4MX6KhI7fZdNZKpt X/2R0kM9w5ZJjmIp6tXkPbryT7UpxC/jv7Ml4sE8gf0UROvJeb/VczcumtHOS4hQJw3+JJuY Wn7M1aEdp54L8Uv118tLr/xTiesUZV1PdR/cjMZTVvYMnHSc5pXrDt58HQFSVlmkj/DXzw+E 2+7UwSV90EkjDusrg3NGT54iGAtXebIk5VKqTEA2QWvTD8fnl0dV7dQXZpDoMyMUP9wzqg7Y 8jSR7Y6ErKqL1yLT5fKkn4IPfRUrDgG/5oRTJBCBdNH29LbKE2Xy6I7LF5bTYhKMvoMkeUSi Dwvyk1Fbob3qBo6OII+GVjQRmDxxTkwLky3UGLC6NsLPyuKcsQEpboH4IynkIHV27pVuizTT +JbuVeqKy8LkLhBFcTWFZkPSlxXxMqlCruHnj3MSmmGp0JfLRiT0G1G3oG2JPeiWIdt5zURE HYXtJHckvSOcMrYlLUNQKKneKoZ5Qw616WaE/yy8FY78YYhBC67Q4+exaX07pwIQ5G7idCi0 bQaLMC1F+ZaaJwLfLAj8fQpJ+9/H7NjP7bBvE0Xw4M5a6/rWCoGr8GlGXW7s7R66aAfpx0uU VDKALp7Lo67mRxii0Avx0Ilh4uYGqz267Oro4rlikxe6w9aPF14Rj0PPTFgnp5gLP9RpDx1q syEMEG/6ywv24c9fwCIcovf2dlvA3crBx8asCuNFGRlO3tFgo/VxFwPklv82aJmOmD31/m3W v6PWdvXguA43Jkna6eZUME5kxZ37OKWob/Qxyne5HYlbv6yJGk5luxCI3f7QkHtPp9/RbieJ 2Ljjlgarf2mJU4h21Jpj/IdllmmN2hAEj+lodz5BpMQzK/bsj++wo/js2ruryuLPIexsRKgK bN5oSUuyivm+gI+8YRDWZ2/9uv3I7j/mLvI/qdMWW2wq1eUIiMLRenILw17jLoTgChQVso6q 03ZqfjcnjGbkF8fcELPs/qVKusippTGOISp3ZbCcLVTbUKodwnCOO5o/vAtSDFfvak9Jqqdh EVxS2BEPXfGuQHmSRQY5+ZSzv+pjQ2h0le2uS8RJBE/pO4e6StA3Ng/eyeMhflM/OEWjUIhZ ERCfiGiSRHDFjkkufcfjATYfEcLNKmWxBhehkxNF1ekRHxCBIx6CPqUIPSs3JY6wSDtLBIcn 3ulF34KR1/am0ayrBpPbyUIEA2Ym/XFW6KrLlfMh4MGUmy5VJiDKu56v9KPsnmCgE0YuG7N0 qsHad8LDVJ/hN972wIDdcAg+Nrs94QPJEbzKVIGXtLPPMf5oFffYSchVyiquUs4810qdor5+ Tr7J4mDOVBLC9K7Lnl/mUsi5qr1g576KX61/eZtVNx220XMYDW47g0yiz86f2mu79j6KsF7u WppttL/HOnqPWayaAWGAhEQTFy3NNokNSEhIW8fPK01uyHxQTW613mmtJeqnrR73Kff/5gBG i3qhLtOV1Ujbcp1/4XibTZzEI7AMGgXeq000zdq1ADIKxeqYYdedJRiUovgt45xIezn5sVo9 EHVxQOIgryj+rVCTt1w7YWtBxDuIsFct1gshZdOdUUseZwFTr6IXZuAfxIdz1kV8j92tVS6a XxFnigJhmoUVwuI8Mr6KvAEPy9xbHwrXOD5w+VSX8ufIHwUhjHXVWHdPjB06E7y0Iy/CvlL4 3WoIUydW6TUvZqzjtkXbcwMxTcin+dQK6ykPvM8S2ClPXQ2DK1Z/nF0tm77ht7e4eCVtWMvX HSWgGJb0jffgT4mwtyutMUucg41FWxFsiAY5ERy4t9bFOmclr/dx6yvQYVpvt/kCLINHVm2Z wFrPtdc4X2PlJ3ONTTKfbA8RNCHarbh+b3pl0RKn0tZ5PycVfHYFxPLS5pS8b7SkdybXJEfR LOxD8+nrt37RHuj9W+6ilgoiFAKNhYets3YYxE/gttCGP7c4WpF5EFQ1c3ox22cHmx9zw0vl brTzcwcxpnuGU8kcJxFvp+kj/DDOVVvRpNLK0b2x1I3UXcQ9yUl3bzl7kx2ZvMXu6vxbWDge q4g35erWLJOdSZbYOhk8dSf///bOPDbys7zjj+cej+9jfe3h3eyRbM4l5FpALaWnBEilqgCp RVVVqSAkRCu1aqWWioqqov+WVvxHCy1/UEFLq9JwKBBCspRsNsnm2PvyHt71bY/t8Rwe9/N9 3vnZ42M33mRBKPUre+Y37++939/ved7nTirUq6gh3DP5+uojKkv7b2rNVV+7z2Eq/5qN5Z+i Ib1NAs68s6yLgLMQQb1NhoC84nYojrlYWyWE6WL5KIpgU3rQQ9AugaArrmKrtsIKqE1Zsnui DSEi3i7q4z1BV7TVmNph86WrlNNhVmA/mmP0zehAavKjFYT6INtlpBOa3uhzYwSyUcm6vBi8 xEVYP727LiI/gBcp9hspmSJU6ye+FK1dyNTnyhg1H6gXDm/AmSzHLUd6UCST12L2D+c+bTeG 2h2hLFembhxW0CQyCLHMegavgKw2v6tCYnLlPnIuZ+NjA9a75xiCeEKZ0kRrx2W79xAuFMDc acjaa6cH7cKJHcTseDGMWW83+3TpNOrDZ5gfYgL26g2Tj466MrZsbEZdkWdphngmWodsK55F 7zluew4GXu6qxrROt5iaI1AOdd/8p0/a177WBIBB4Ira8FtJYovEEQi34jm3jOltCYpjFiQy x2msjZP3LFTGwt6MFQBuTbykuRFOlCCBfBd5lG+9MmfF7rSd6AE4DsCfewU37uewah9osVN7 QZqf2WcHnhq2D/zPcTe2KxPGVnvSioB7dD+npj+V11+oF8Zxq9O1gP42/GuNEOtj+kCTA/kK J3a5VSlANQGqrIlrRS1c3BG39qcm7f3fB/Agk5GPqwrzWQTRaUuVJOBfRGAeg3W0qPpQF2mo iSpGgxJgK3StHrNFrl0LiuvMLC8vlNU1EFO/YqHTn7Zso6RudK8COyuOv64c1IpASoF+yshU XENNFZmX5FCScShmithvfijABcq9Xx+ye1WEY/BiNxQL5X6ekl6FVpDHS9hWHcrO2Jee+BeQ gE7arcwdpRRnTYUFnyn129X5Fru//QwKFaIEiBbYGCiNxWoLthx7oQDC7DKJc7a3A5972Gb4 C+jZ0Ysn1hUAB5lJGX9V8+VOhO877fFe9YtPMhBDHhbNo30/BHkoB6CsL/+UrCO0U6w2wrJq pM8gRB8t7PZS3dkLPjapIQpG7MhykOSh8aa8xBt9qA8hLSKXzvwY54bP0rXY7xpF/RxwOprs hH00wmOk0zcsK+wzOEpxnYSiCPHORTGJSgkCbgnShYjWjiY8Fz5PkFIGi/R5BZXyduXAlYNQ cQhkBdDVpBjdStKYlIeBdBwNMAnRod4kM4nhuqTMmNb3t1J7YwTiI4kK8YP+JNcQ4J9lvafG d9m2gRsgD9gK8FRA8jz0kFYIo0WVzE03Wls3lpDkLcDCyaKFtLx2HDUVoErIQ8dOdyjICcAa 4KXX0qrulUdGCXfnkyNJ69kVldr8t17ILAji/PGsHXwQkjZFHGvYS3HGPz0B0nj9fnvnLx2z /t2vW/+u152x55SbyB36Hr662/Jn8Q+1HWAD5bS5FLSs5JJBkKhj2/lQjTVUs1qbZVf0PKyi dPy5ENUjCKtFqN9n1UZf3Oq0WEKDb/FTXUEZZ0ewBsabrpDCFD6gGkAWreMAbITdJdg4RZ3w AWQtBJxa3E6MDCiKRk73fSenbaqp3cYArAsgEgHlvmfH7YmmhB19aJu9BsN5jJP8A7CWBp4Z 43DAy8VDrBjlR3e12+RuHLcxUR4vp2J93mumpKWQc8Seq7NWor0r/KdxmJjW+uiFUAGSqJj4 9KJd/r0BG+bkLmF4M7HNB79xDcEsDDatay05h0LvjoA3gDtKjiz4IUSjZqPfcgopNu3glVm7 QcjfFgTc8ggcXsio9upvH5aKEMkwhVxAvct/WBXqXC7eI2TmtVSOC81BF0IavFzL/XuZn6MP zaWdRTzGe/QLuSn7x8e/SkzyJ3l0YQc3sM/MVkgiAtjdmWuc9hVf21fFZxIE43zGZmxn8zHP G559HARBXJ7c87jT2Il1+hD5qhPa07d+pZGLppCjzOCfLw0bbL74HpzAn4HCqVhvdpg22FcW uAiVociDalPtFCo9WJ/fwDp9gjgij1gu1m39Tc9DBUHi1TZbYxc7Vv00E2hOaWXU/vMmHwF5 iH02PnPEpueO8I7r6VYboZ1QkVUBbsrzroTY0fxW5BlwdwS4AUJJwtdKeC5qRBRCYHmt7V4j FsUg6irpspMkGleqpxTa4mEH8LjmlwO3MB6xxdwLL+NJQemIhVYoD9EWslu3R1jb1+rfK29O fX79XJXP6kFV+QvUxCk85qpEvAwAxsKcMIGuOeEJ+JHE5nFWD5uYyszb7HiX+5cqzqG2preG 9mVZXuVt8fXjd9277W0sf2jn6Ke9+zLhaaE+9NKv2ozlkje/oP1EB36xTvawKEBLTjCVMlb1 HGRefv5RKJNdUEJE1CtxitY/7lIcd8A7rYD7rl1oxZ6Euemlvo2kWPLhyePBYh7azzLyHEVz 1Nw1DY/xAQmfx0PvCB6HwwRZF5/n6s6itVqd+xZ/MSdpBcUJv9pDsKVZBOmju4lXgkv2NuQi ceQG+c6MzeNnonkG1UJ51O1N2iThZ3MgmRIxMooslpDLFHKERdYpjuB67+cu23u/dcl2X0eN Eu+5T/3idrtxuANVe50I4ZcDtB89Pmof+coZO/zMsIfP9bXaaInJA986QOhiTDfQUirgNMkB ONPXaxuqhdP8dC5tP2rP2fN9uGxH7qC11GO0qbRR/1QU+IFosYFrefcaPNyJRh4OJF2wrZu3 Suy7h8KljHx3OXII27+uliM25XLfVZGvIyuSf7FoAtH3upo/uwwtkSiPYzzHH2y9Yf/8ni/U kEcnzznUve+GAHD0EIdBK7Kg2EdKuhdkF6sXvBtZiJDHldlDdnp6wMuGyYf21Lb2O+Uu3RPW lQEuoJDwzNUHaZt9wlO3kMdCpdu+fvH9ePXdwXMTNuhGYSfRCDtpE6RF2XY4G9fm+rwP2Ygp 3noQ0mtMYVybf+X1jkMtwHIamfoe1tsR8tAaRHPUOKJr4B9AOzxZ5PkYo7K1MkIGsJxKlVHk Ie0gyi7K16eoPKtSQwpy9y6vvs2Zu0AGgreioOiXsbXgXyuLW/cAYxSlsIn3W9RRaEduUOQz S9RItYr1OhpbKxQglxskXokN0kYPqeakfP77d5+z4UsYpxAasqkDUp7MZAayB02jOJjcBdSS ffCyyNYhm5OQfcE1nxSMiqMgA0fHnf9oQSMQQMa6JKFXIokvfACyWEGR2vC6gjfJENKSPcjw +TYE/9u9VCqNSi0H+v33niBG+QWnosRojsFfXZgHwMPTRUJrUxPE2T5KiNQDzCU8+zfpZW22 tLDQrZ5CrgDSmJ3pRfayGyQVs4nrYHqXDemhW8SYEaALNZTNgaX92eHlQi7k4xCicaiistro O5u0pRICS121vUQIWiiQaQTiEnR3wJ5Ks4fD7QS9AuC3j0NtwvJRiNqCBI5gxe8SbOn4jhbr 5IQ9ioBZrJkrv9VnT3/lAcuVyvb4F8/YXtg9YhldhqW1iLxCMs08dTsm5q33G+PWcQl2B/3U XpsNJ6ioHZJB7Dw/DRsIJYROAAV19DyqTz3IeoYquKU58G9D9uH/vWo6PGYUR/1WiYoR60zN SatTSUBegKpe80lu2VtRxe3Kl2wEKkR9+4b5t65XJ58P7cuJoig7/c7SSRIk6kQnQ1umiura UJ4ULc5+ZIcd+et7Lf8wbj+wCRE71ZHP6m5+5r+EPF7Eq8InB07bF9/997j/wNXFEu8lPqVC 0mQ4JJR2AFAlSNfMwwRlq1FaRGkB/1VlnQq4N7ZAJM5y4EAkYpy8SdubXrRDXUf8OnzEQQrA HJwkBlih9vRCxin7E/vA3i+ATK5bZ+YGVEePjRR6bU/TjD3Y8SqAkl5Y8FjDjPVkx6FC0LhD 5fdg51P2zp7/RFOpGZcndzEetS2YtJLqtmUlc91VQB7yP3V94ttYgr/KWrQxs/pnj2cUVpbY W2E91IjmL2UKAvRhVS5/VDrtiOUUB7irnCgLfZdBIvPFIa5XkqIPBiv1lfV1Vlh1ykZnvgXi ue7seVEucVhIVTS4iuUxGlD5oKAgBKV+RelILjMF1aS9SsAGiyE7CciFr5skzWBziZV0AzrW RH6wUnhXzU8jdAHmVXE/sIRtiP7FLazCm5SrdC2OHAlOjD3gD1jvrmsAfxZFZZHeRv+aj671 Xb9hUZ7rarPIOSzFZYSn/kKd+tK3mAZjVizx/IUY1IRIbPXHPyeo7buP2T6MneTZNwElINXb EGtE7CIZEB60q08i/Mvx0jt/4Rb9aDg+F30zP5BlY/M8yI9oeblJ3N3jKgDhfNcAmii1+Wsj iwtEIkxNWHMnvvdRQxSSLSlcMN6NvR2tp8qzbmrf/28xjNu6RXtym54arRDOtmR5Yl/kRW3A s+8+O2tpePITUBuK6d06DdI9A9tgeyO69Hg4HSvYe9G0evT1MY9cOEMsENl5TKMO+5PeZlfH bSY4Vd8J7G5gJ5WJxyHDvAhoVgHIlVZObTrar0lrd1bIQurGrWgj9SELyTcRZEdAnoJZ1IGz yD7mQUqzjCF3ZI4w8lUr0Kzur02Oj5WptUSvNwmrrgV23Aysthjx3eVRuMQ6JOlTWl56DoT0 pI7beH3B+glNO8eYJZR3nL5++N6l+kmOQ6VwxppgTbKMN4m3Ps1FFIn0gCoANiHw2Pyia53N sUbu5Xe4ald7cvZcNzYhIGu31+FZ4YhzR7ffB3obHx7Lg/fm431n7G8e+zPry73CSRq5ZUMA /EK6Wli5Wj8zrdM/6paeExZpstgJcAdhFHsAagHAFtGqKi4K0YRUrnZgcX5/rSUBXJWr2NGx ffbq1G4vFPpRX8gBURN+dfI+K9DG0ZEn7Onhe0Eqr+Pi5OlaWfqGSu7OTNoYVMjEQi+sqVEQ iU7bij+Ss5PIUQq4jg9JY1Xbm0kR8pi24cnvWKF4grVoYQXqEZEeNMwFUr3ckwwj/BZlILlD AiogGBECM6FgxIbSfyjHYRIAnwLAh3XgSwlZRdrdjvRTTIi0frwcCNN7gWcE5UrvJKjWIPtA sLcFAuMROCogLmhAbEgkYJexodhYQjKyXBXrSxbuuudGXepvVfue4R+189ZKhl/V5hdy9YMF 5eFXTAsxq2McxfvuPhfm5+sEFqlL9VNRvxlC3ybTCGdYkwYGWp8aRF6Rn0K9LwFTW2w3yVR4 vwC8TBak7H5s+C0S1ddeQ6KOXK5vJglZyKBw4lTCblzfY/dnjghsazAryyIZRK39dCukpetk o6Fztg0dAXmq1BxV4ObJKUXG7s4U0UgR21WkckiVcK2xrHq40DXvxvJUc+K/AU/AAkri5Wru nl9roQHy1NdDz1kt7459cUrOEL9jcVerUxuNBIdKXoYqmijaBOq9ElI3I2hXzzOcvhVk6fDF Gdvzd7iDeSxtQ8glhjHCm9rXZNkxnLTtwv7j7g4rfQqjwoPtNg2wbRsvWJzTtxCWHim11QDA 9mXX5tZNyk/+vuEUU3GuZVwnFeL+SzM21EXsZ/JULiZbEJDAMOM6964em+5vtFPv6LZmIZio DXWn5HX49k7pEoSWQ/6TAYFcGUSN9mP9VkSaO4KSQA6ZUMsVDP9AXGG8vAaw6HqID9K6v4P5 skG1dpa/1Qd5en4LINlTH9xuxd9J2nnsYFpBRq2nwCY8d/P9GXvh13ZYF7KUe746ZI2XFqwT FuIryG7OoWqcu2fBZmD9HSCYVuYiXhNQ+z39oe02BptQqsFycR/ivavDn0LSXmhuy0lOEeVR N2mf3n7S/uqRv8W6WzJQDEDdBUgoGKgDbBx4fx7qes6NAsUWik72rRyUWtNj5J/Ci+79NjSz B4vwb3rlKsh0stSM1pVYVAGmqF51aZvNFvfaAx2vIBjnpSIF9pgGCEXLu9mblXZXBlnKsD2Y Puuw4lL+IKwfDEIbL/JoaUJx5B0/UfVakuEe7PH0dXuiB9fp1d32gysfhir5d2QvoZ+o5Mbf 1IY1VCpP2A0CQYVYHqI81tbl0ES5ueI5mglj9ocdpBap8S5x+k+AJHKNhyxfOE4xgWaoJoC7 hi4EsLIhHHqSA1AYOogCLLxs9PKofShxqfSCePXtgnq0q+K4PpH7k4XSFeoIyCK4R114Jaku O0hf+cKrXGashfEUSsO4VBnhntSIV6eNEUhdmdrrjYFY0i6fG2BKxDWokZ6rAPByHW0VpyRO zWIHqX4Sb5hjV1tZBE4qy+XChdhLcvMxMdKOZhYPgw4cFKqUUQ29MohmwhisnC7akmYAAFRt 86AlCEc5dhU9adZNL+sbJoBJAl7p0NkuGzutDemniviwLDNu3uVYMXooNWaxmCrlir12pNsa 96F6t/aZWNOh9jGOJ96FPLYCQzKuRIuCPjczNG29+pbVewXvo6JGAsTidFVp8Z4SWO8qTnom M2T5cV4wctXnnUjOPqoB0jQnZLFq0sOwqxh/G0LzC1h3t2EFniEg0sI7sRJHEJ6D/98CJVA9 gGsPTtBt1+bt5J6U5Qey1vfMqB0k4t8J6r32y5ywwOAPIXzeScApHXKWoA6ME7cproemB3XS gFCcBQj7yW+OkyjakKfDIxpRuh+DHbXUHbNtx6es4652y0vNhqYkK7ibAFKinF7EQHF2sM0e GpmzPgToVYTk2mOtsZK3KV8/6lN7j/ynC2v7Q4MT9vw9nTb07n7fsw7mdx9BotLDqPD24zpH 4yNJQ0uW79svzNgpIhq65z8OM96BOtGG8y2KosKavrQbth0AUev1yNkp6z6BvyKQkJDoqSaM U6X5xQOchuLbfXzcxnIp+/F+NGD2Q1kx38OnJqwR48kKWlp5NOFU5xAILchRap3R5R1Pax5c uWN/GRX7z+45bn906C84wesdIuRxgwCQTgMCLno/BVJK9tLor9ur0732m4P/TdCoUZYkuGJP 8B6HRYIjgPZWV+MlfmvJJOCFUseWIwsbPIebdY6sLCfGc7Ckvn/lkL1v8DnuURZqPLBzteA8 F5y4ujKhnUx20tuTwloC9d9OHVxJ2muVDWNVf2H/Q75K8P423LAn+o5weCPaqXsL9q0MN9d9 Uh8ArJgdw5NPMka5hZc79vCcLD8IeiBApmmM8poygzZTOAOiucrtAIyD7IIyvBgxDAzLUtH1 pDUlnyS7kKooB6dKeC+gSJoye6AoLsLaoi1nNWl+/PspVh54OaiornE4VT3GKimS7EtoIJT1 9tWPUpQXfoW+4MAsnKN/9mwVkqqViWqlGUCR0+3v3v9J62nGlzzSZelv1ydpNMQWWAj49Ok2 Bnoz4EU1AbYqivxxV5PhGuTpCG/NGJfb58GRfGMex4MBObEmAPBGLMQlV1mYArHABkrVG89R R4L7uTxk1qaT2CcYqKnd6HTPmBQsS+1zIPA98OZq85jFaaQQ1mZSQIah/eU92kxFlaE/rVNx GiPMLoCKYKfC+c4Io0L4tSiPcer0Opd1ucqye3gv8RY/tKUgggInY7F9JBNJYZ9Rak+iXYUq IEGYssNQbQyn0INwjtO1NLcSc7D2mGyRcqUO1A9BQI3nQTTUKexHl503PqW803OWIkiVAPYC thWVHGTyCD4CplCN5Vpt0q3lLnPaRvVVZWQnkiXqYAkDuiIBJJKMJzMWTqbzA5DdAPP0aNFS QkYYtxZwgVIYxE0DVEbTWQAH26ZgVwpZ643TgfpZJE9zkbDfERTQRpb1c7gzKaLSK0PGNGPL YaEuv3TqR/0pNeKupQHAXqbcAm3JvUqGttxZowroHQbAi8IQ9ROx6yQIb8QFihxuar00rgJz jIEcM9jC6NlrmIMNtydrxe1ovsG2amRuudeIYS1gzdjVn8aSYWxx9sPhtvp8E0nAZBFg89zQ U3Z0/BmQMxpHH/qQdX3ko0Beh9LeKtNxbasXCCX9+f0v2qcOfQbKj/G4U0QBZyEMnY6VYLXy Kbfr0wsP4/BwB4jygt3XfhGKAkDmm6ASWqYVDa154p9nE1PcxUAZwL0IgkjGopOxnv8AlOfK d1EO7c+aM8ZKtRP2E0Gh0i97m+emDyEEnrXtuTNocO2irYKr6V7K3+PykVwSlzP0EiGN6HoW VeAbMkxsfQ2Pv2hp0WULYSMwMbZTIx+3u7/3fnsoC9tUL4YnIQ/2n5P5tclv8V4ydveoGyEP PQQCelobwQ4hOZzPpjUm+bC65mNbt4F+SpV8mDVAXqF6ko8I4AdE453zEdpvqCGOyFhQY4rz gFWQgahtGSIK2cgQMYYHXiG8RQ7kCReks2tOfWh82hP961osM55r2F9FKJVEostXrCxXJ2ne ATxR2OeO8LCwSHlYcNRYn6J1qrsjwLWUTaF3jZ3AsDbhFkk3Ke9P/S2KrboFkzkhH1S1hqXR NTUORufNiQPcxVGqEm896tenSx3FPt98oh0WcRrB9ioEKAa3Hg41Wp/I8ljo9Xm3uBZAr6DW ODlC+2vbukU93VJxAREhjXmtr4ZDpn4r5WdX8hLMeVkF2O/egQ/6i0ERyO+VXjDZJYg3L6Cv 0LECiu5+g8NIM3HKdQIWMohYRFkQjk7KqrOI3UV6BvbXdyGx2T/Nq9pBWU7eYs/lcJci62uv T/kEp/sW+lUSiyhJBMH0CNSr+mQc6VHaIkqg2E3Vmryk6RxjANBrTA68MX4UcM/hW8vfcxwh hgZpkzKeWMoc7CDBI0U69HMBeepHj0DbjzBO02FLu0FgrEXckziHAASjdVHSmMWXSTE/AX4f kyAqVTyxjpJXiMUUCeLVns9F0Q9rj6uQYwtlgJXLfq7kTyt3oWBNL5Ev5MMhR9Eh9RzQbFg3 xu62Ktz/aSdNSQLzF2Bb/UH/WfvD+z9bQx6K5YE1PeBDyEKGfyfGiSne+6/UEMDHPijzgj3E /7HRw5Yv9SHcluGfkEYEZMP4WSoMAWV9jsYfxnzX5vrRhipheY4ZAO2ofNTP6ak9dqAN2yqx tkkFkMR/XThsHz3wsrOHtxPnPBKnzZW6kIv0I4g/Yf0glCC8DntbQlNrAaPGFtR/lcQuy9Tc F3WkZ2hLrlIQqDNEicBWJyEP7CPQWLox/QOQhzxaNDHGqKCQRc4a0wOw3c5TVasoufCs5Ymr 0Zh5wDWqimUoDZ1O/H6tB70oIB4B/qUlcXrkO6+dm3BDAPwr5bV2IFm3VOeQh6ddJXg91pzd B5VzCgpkkjGKClH/QgopENh2K6HNtYCargTwGpfua23EKlPoXLWivKqE25z6XWaiJhwZ6kL/ K2ljBLJyf9WVkEhMAFun9zdK3ukbFQr3fciUrxdSa/OSaZFr5EdjVsFa2qhOdO/W3wgy0zod 1JW6xVjlN+t2kpBIUsZHbzYxFmmHKUVz9GvWPBpmpALshe7kBx0u6mTBt7NI6FAIoYJqrzbB BcYqA6DTxkRlNAR54l1CLqI8lfN6fbB+uOfjFluqBjwVdra+voCljP2UHOgCoCVcj/oUkK7U 2o6eX6kL17ehtuU12KBmPDGOKPm4az+W+9Z4olS7rOD5d/m5IC/SzlKerwvlozkLIVTamK8e ztq8oua8PMoEK5PnTrR+tUKac8XnXFtX5WsOmhd7wGO0sm61Oj52GvUx1PJ+el+wL5n3MbSt PtEvgblkHlDBzraK2CzaXbGicCw5H9T5BfCvzg0CeHO2p+WkvYNYHSGtII8IMZycfNRGC332 nv5vUiTsfzLOoQNAuFjNIcQNAI2V4n6D3df5XZep1Bq05vQxDAZBYNwulA7b92/02R6cMT68 7duoAr+AQSGeAzAzuFtUW1wn+pDmK/IKHDZd4FPW8QM5IURAsKsHq1y4f4nQFdqMsMWUEPLA W+51VHXL5cv8XsO24oQQgx2V5uQ+WzxNO4BnYpy77AHW1XwkB1mFPFhHTi4SlGdBPNO4Z/f1 oC+5JpFQuwGAv4Kk1CwKFWhmcfThhxLvEKq3c8VLXNEnyKU5ux8kkkewPwRCmUIWkqWPNupB veO40U92qkk/+g9z5pDDWMqOsNT/CixTX3I3X/+4q9b6pLULz8aqew7Il8m4Vbfe0o+wVeub EEK56b31xTedU4+oNl3pNgreLtK5WdP1c4+uo++b1Xmr+euAEx0uA9Ja4wEgrxnJ2nL6reMl ae2jtFH9Vf1u1FY9wFeb/hSH9r2TKK8OcUT59d8b1Yvur51nlK/vVeNTxtoxKq8urStfdy+6 3KiMj682h82sW9TWnfrWigokoVPhdh6/33vOkUc7gu8gF4iQh/ZV8owYoWWP2q/uOcq1Royf OcpiFcQ11MOyvKIe7ISZ9TfO2VVi/EjUlcEIWQC8JzuKRtS9Nk700/2tAsArewwe8DRfwWcb BoKLAKT9rQicSfOlBpBHGc+7xMWgSooT91487k4UOwCiXZSYpk6a+CII8VPT9BTajb4jpKa2 NI4of0HyXoYLDQmQRUYB5SHkUSyd53c98gg1JTsQC2mcAE9hPaA+sPcoR8+v5BHe98q8/DcI oSI5BwgoTsTByOWIKICUYp2n2kAEF2hSB6SwfjpxCLU5NcGBLt7QDnKAUkFmkkz0QbVATcVh DUsQ7yq8l+ljHgTXyJhwIeQRDOe5RuazKAS7gowCxaE9W+lL15LThJ0M+RsjkKgO1bfS1gps rcDbfwUEzgQ+5BQRotNeJI7Nnw++an9y6PMghCmATAuAKghmI6ASsaROT74bu44me1fv08go CrCgAotJqxbcmehKSYBF4Dmcakuwad6388t+J9wNQHVf60lkGzJ4kyV5KxRCAPinph6zu1pe sdcnDuMK/jLeYq97Xck4+nLPQnWglwF0C4hGCjwJ4n0IkVWJdY4quswNvFVHB7Qe+ovmIbwt mYN8Y0nuKe5Hl7Sx+ItzQl8oXreR6R8iU7hYQx6ah9qoA7yc3tOpHYwNCgQBtNynq8TiktZE 5UKfXKxJdAYSmS68EvIdUaisBN+TUGSS42lsYmkySSiDFKq20uJKYfwn4XigUIKGVgVEV164 TpNQLi5YV9/ZGkuKcUMBOdWxzOLR3tSnIH/RSoUxa7Wk1CNZllKYRw2BhB8qLNP6YF4fim19 bq3A1gq8DVcAeOHAQWwF/nQunoTinwRxSBj+2b0v2R8//Jeos0rY2oQx3gyyDNk3NCA7CEDE ARmlFa9jF3Y5SWQYDtsoE1KAK+Ga0yvIKXQno76qTSKwlhCoK3MVBBXqqEwZ+4xJDAGz8RG7 nO+13S1TLuNoTyluecUOtr8MxTLCaViAFK5lYsxmittoZ9SlMlVsggR45b5kgZP/k0O/be/t fxlVX9lBAIQdgfnsqY4Rr8aysNtOzHTaI10vuOGhHBriR9R2tpyhg18AsM/YOLE8JG9wmQeI QhRJDKDuqriamAN93I5grFcpT4E0JIgHcPsyrEUemm8Yp8bqlEc8C8WQhTUmeUdYNf/0piUP wuAQYbwoFSnsKBaIZBULVdmPQQ2K3QQSkm8/Yj0yS2Q57o5Ejfkg+MJgOPeY+8YqoUHmgrao E//WWJDjQKXIzkSKAuwIeeRruLVmvCgfjkBEsCklUPdIKPQfP6M8v7H1sbUCWyvwtlkBwQC9 3zFO2THpzQMFcBpgd2cX7WP3nLbf2POaPdT+5dp8ZegWKIpSoska8Sihk+zUUpe1xS57S5mY bARWUnSyX8nRlXrtAeji/RbVXI1gH4ggpIBcoutMcsR2tYY297adXC6zrVH9gezigfJw4Azw 74LtFRKzAgEFaKb+kH2ghPLEwAyaWkEGEhkv1iosf7Vkl+xBVIAjGiXMOWHbO75jH2/eZV+8 NmvbQJwF7Cj8pA/ii8VhDZEaEMonsPZ2n1OiEADdsoMJCEUgdg3U9REGlpgwaqAc4mi1SwWZ 0aclZF6po6vKEqxDVL/LcoXNlgnly21KEAqJEhKCklAeOC+1X9m5SZvOU9QWbWMqUEIBYlG+ v2BHhTFG91VYZfjH8VupAcUHxSzS8UIIUt4nIj4iRZS8h8WaoGRsTsFDkPijT7pWjTcU3/rc WoGtFXh7rABCV06a+YUZt71CT8cOpZ6xX4n/hzUBj08OA9DwfFAfgnZpCZ9lqKtJCD2CGvFg k1gzAjCCJkJJOqKuTwLpCQD7y2M7UZXFIBEE4SIBASoH+PUALFwHtlJ9ewK06kPfEsjrXrgf UIY+69vROHQfrxnxb9s4bCikC5ThYlWS/RV2ZbGLzBVEisxDbWtacWzDUAi08de/g/pqj5Vl hCJWkie1BEuPNXQZA8DdyiAAp0LqO1g7Jt2jLPUSnPBlY7GIC5TV9dbWobynKF+/dR3lh7sh T9dRflQ+uh/uzS09ywXIz8e6cZmqIzPuRcJ1FcMdjw3XZGCy4SJFI3EeX4RI/M7Wx9YKbK3A /5MVQHUam60ycUlCaudL8o61wLZ2+019LYMaatdfv6nGbrOSKAVRPfUIaW0TOsErrS0TgLF0 oNBb2kpaAbQi5e5HadVOJhGsSFgUuIN+f+tjawW2VuBtvAJlTtSY7/kMExhRdHYrAJQEqOuT SkWc/ArykhTUSIRy1pdenaP2dLpPILfYqO3VpX8+fmmcQqE38C5RQstrefLR8FRAC+ATYmUk ALqdJAG2klNx4fLn+lPDFeUhTw61FC1B9Hvre2sFtlZgawW2VmBrBTa1Av8H/1JsixJlFs4A AAAASUVORK5CYII= --------------6D15056F6745C98F7A98D5E2-- --------------30D8DE1442EB7F0C3CE2CD8D-- From nobody Tue May 2 11:37:47 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E18128954 for ; Tue, 2 May 2017 11:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPyeRkk6MvsB for ; Tue, 2 May 2017 11:37:43 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e: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 5D357129C3F for ; Tue, 2 May 2017 11:34:58 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id y4so60227582pge.0 for ; Tue, 02 May 2017 11:34:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CfmWkdut5G4NUIe9tej1nwx3CUNJS2gGrGT4xJD2jqQ=; b=EEGJuWOqxYFOYYEFbeeIH+4CIfDdB3EnpIroDdrw07fXLo0e0bOf1yjFHHuUbMedHS TCasAewSa7XU6D1f0ctQFzO0/jrGc4uzsWUNGNeSXsl7IVVB5qSzALmtYf4m6cXLhE55 JWQsqsNfUYLNB1vkfMQkr5plPK2WZGG+F23WHuntaAEmZup7UJ60jBl/zjkbetTRmXxz 2V9lUNGNS/ObUrbUsGGj9TUgJfJS4SrAYSTh/8bIkG11G8Hw+miYDGKJW2dQ1NXOwTl3 BlzmOnKLpBqr6RyJC1CG+Q6DyvtoYMYIccxGU6CAdbS2P/gTipkimJcohAmQioIQkpAA Do3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CfmWkdut5G4NUIe9tej1nwx3CUNJS2gGrGT4xJD2jqQ=; b=JTylbUnavvehJpWr4XiSDFjr6myHDLol903FqprernGVPsg6tfm5w+XUznbcUk0HqF pbj5mhl7s619uObR7qMLisQjxd5SpPQkP+Q/+JPtHPBsHf0ihGvXz7K9W+IhtHWIoejM tizaYMrZSCd5E1W03edDxdSTdNNTxAI0Zhzgqtnip7kp6DQfASTFgW1uN2RW65YSSy2t NfQfU+mb5jfWBXyidhHE2G1UGhm8I/vNgrYEC1mWPhfr77T1/jN7xLc7YvrKCFcen87w WlorO7qxxbN3ffcESRxvFnWyHXEbJ52y2hj9OeOZVCv06Rrjp1UDyqsxd8O6qkQrR4J+ wL6Q== X-Gm-Message-State: AN3rC/6oIk2nzrJ7wIi5tf4Nk89K8t0QWERkt0COvg0Zrptmd8MqIFSy jMh8bABcl6eV/4eMM4iwoGnSqAyPwA== X-Received: by 10.84.241.136 with SMTP id b8mr43793110pll.107.1493750097862; Tue, 02 May 2017 11:34:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.185.143 with HTTP; Tue, 2 May 2017 11:34:17 -0700 (PDT) In-Reply-To: References: From: Kathleen Moriarty Date: Tue, 2 May 2017 14:34:17 -0400 Message-ID: To: William Denniss Cc: "oauth@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-native-apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 18:37:45 -0000 Hi William, Thank you for making the updates. Just a few notes inline and I'll kick off IETF last call. On Wed, Apr 26, 2017 at 5:50 PM, William Denniss wrote: > Thank you for your review Kathleen. > > Version 10 which addresses your comments is out: > https://tools.ietf.org/html/draft-ietf-oauth-native-apps-10 > > Replies inline: > > On Mon, Apr 24, 2017 at 6:47 PM, Kathleen Moriarty > wrote: >> >> Hello, >> >> Thanks for taking the time to document this best practice and the >> implementations in the appendix. I have one comment and a few nits. >> >> Security Considerations: >> I think it would go a long way to organize these as ones that apply to >> this best practice and ones (8.1 and the example in 8.2) about >> alternate solutions. This could also be done through some added text, >> but making this clear would be helpful. Maybe moving 8.1 and 8.2 >> until after the rest of the sections would be enough and then clearly >> state the intent of this text. > > > Good idea, I think that will help with the readability a lot. I have moved > the "Embedded User-Agent" section to the end, and clarified the purpose. > > The reason it's included at all, is that OAuth itself documents two ways to > do native OAuth. This document recommends only one of those ways, and I > thought that detailing why the other way is no longer best-practice would be > helpful to readers. Great, thank you. > >> IANA Section: >> Just a note - you might get some questions about this, but i do think >> it's fine to leave that text, although unnecessary. >> > > I think I may have mis-read https://tools.ietf.org/html/rfc5226#section-6.1. > There is an example of a document that has no IANA actions but still > provides a justification for why that is the case, but in that example it > uses a non-IANA registry unlike this BCP. > > In our case, we are definitely operating in an IANA-controlled namespace, > but using a private section of the namespace designed for that purpose. The > intent was to point out that we are following IANA guidelines correctly. > Happy to remove it (or indicate that it should be removed during > publication) if it seems superfluous. > > For now, in the latest update I have clearly stated "This document has no > IANA actions.", but retained the discussion. > Sounds good, thank you! >> >> Nits: >> Section 5, punctuation >> OLD: >> By applying the same principles from the web to native apps, we gain >> benefits seen on the web like the usability of a single sign-on >> session, and the security of a separate authentication context. >> NEW: >> By applying the same principles from the web to native apps, we gain >> benefits seen on the web, like the usability of a single sign-on >> session and the security of a separate authentication context. > > > Fixed. > >> >> The document has text that says 'native app' in some places and 'app' >> in others, I assume these are used interchangeably? It seems that >> they are used interchangeably. > > > Yes, they are. In the definition section, "app" is defined as "shorthand for > native app". Is that OK, or should I revise? I missed that, but if it's defined, then you are covered. Thanks. > >> >> Really nitty: >> Section 7.2, >> Since you are still in the example, did you mean URL in the following: >> >> Such claimed HTTPS URIs can be used as OAuth redirect URIs. >> Such claimed HTTPS URLs can be used as OAuth redirect URIs. > > > I have migrated to use URI exclusively, other than 2 references to URL where > I'm referring to platform-specific naming / colloquialisms. > > I also changed instances of "custom URI scheme" to "private-use URI scheme", > the latter being the terminology used by RFC7595. Perfect, thanks. The point in asking was just for other reviews that will follow. > >> And again in the last paragraph of this section. >> >> I'm only asking since you specify URL earlier in this section, so you >> were more specific for the example and then drop back to URI (which is >> correct, but wondering if you wanted to continue at the same level of >> specificity or if there was a reason to just say URI here. > > > I believe this is addressed now. > >> Section 8.11 >> s/uri/URI/ >> Thank you. > > Fixed. > > Best, > William > >> >> >> -- >> >> Best regards, >> Kathleen >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > -- Best regards, Kathleen From nobody Tue May 2 11:40:20 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1428B12EABF; Tue, 2 May 2017 11:40:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-oauth-native-apps@ietf.org, oauth-chairs@ietf.org, Kathleen.Moriarty.ietf@gmail.com, Hannes Tschofenig , Hannes.Tschofenig@gmx.net, oauth@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149375041098.21410.10651632794077599445.idtracker@ietfa.amsl.com> Date: Tue, 02 May 2017 11:40:10 -0700 Archived-At: Subject: [OAUTH-WG] Last Call: (OAuth 2.0 for Native Apps) to Best Current Practice X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 18:40:11 -0000 The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'OAuth 2.0 for Native Apps' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-05-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the user's browser. This specification details the security and usability reasons why this is the case, and how native apps and authorization servers can implement this best practice. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-oauth-native-apps/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-oauth-native-apps/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc6749: The OAuth 2.0 Authorization Framework (Proposed Standard - IETF stream) From nobody Wed May 3 05:32:29 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD201293FD for ; Wed, 3 May 2017 05:32: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSFQeLe9g9O5 for ; Wed, 3 May 2017 05:32:24 -0700 (PDT) Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [134.119.228.109]) (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 86196129515 for ; Wed, 3 May 2017 05:29:21 -0700 (PDT) Received: from [212.202.243.194] (helo=[10.1.12.190]) by smtprelay08.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1d5tPC-0006kR-GF; Wed, 03 May 2017 14:29:18 +0200 From: Torsten Lodderstedt Message-Id: <18ACD3B9-A5BA-4C59-993C-C3A4C5F5EBBD@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_5E1F998C-FE60-4D9B-ACF8-B4974AAA86D0"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 3 May 2017 14:29:17 +0200 In-Reply-To: To: "oauth@ietf.org" References: <269DD0EC-FCBF-4691-9BAA-2B8F144C0353@lodderstedt.net> <3A9170DD-0861-478D-A9DD-9A55DC930B8D@ve7jtb.com> <4ACE4772-E01B-4D9A-8AED-7926B9E87615@lodderstedt.net> X-Mailer: Apple Mail (2.3273) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Second OAuth Security Workshop (Call for Papers) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 12:32:28 -0000 --Apple-Mail=_5E1F998C-FE60-4D9B-ACF8-B4974AAA86D0 Content-Type: multipart/alternative; boundary="Apple-Mail=_6C485701-B1B8-4EBF-994B-1DDDF3A73C65" --Apple-Mail=_6C485701-B1B8-4EBF-994B-1DDDF3A73C65 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, FYI - submission deadline has been extended by one week since we = didn=E2=80=99t receive as much submissions as expected.=20 I would like to invite you to submit a paper or even to give an ad-hoc = talk (I plan to). Please contact me via e-mail if you happen to have any = question regarding this topic. best regards, Torsten. > Am 20.04.2017 um 19:49 schrieb Mike Jones = : >=20 > Excellent! > =C2=A0 <> > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]=20 > Sent: Thursday, April 20, 2017 10:42 AM > To: oauth@ietf.org > Cc: Mike Jones ; John Bradley = > Subject: Re: [OAUTH-WG] Second OAuth Security Workshop (Call for = Papers) > =20 > Hi all, > =20 > I'm pleased to announce the hosts managed to change the date of the = security workshop to the end of the week before IETF-99, July 13-14.=20 > =20 > Please find the updated CfP below. > =20 > kind regards, > Torsten. > =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=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >=20 > C a l l F o r P a p e r s >=20 > Second OAuth Security Workshop (OSW 2017) >=20 > Zurich, Switzerland -- July 13-14, 2017 (note the changed event date) >=20 > WWW: https://zisc.ethz.ch/oauth-security-workshop-2017-cfp/ = >=20 > Position paper submission deadline: May 2, 2017 (AoE, UTC-12). >=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=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >=20 > Overview >=20 > The OAuth Security Workshop (OSW) focuses on improving security of the > OAuth standard and related Internet protocols. This workshop brings > together the IETF OAuth Working Group and security experts from > research, industry, and standardization to this end. The workshop is > hosted by the Zurich Information Security and Privacy Center at ETH = Zurich. >=20 > While the standardization process of OAuth ensures extensive reviews > (both security and non-security related), further analysis by security > experts from academia and industry is essential to ensure high quality > specifications. Contributions to this workshop can help to improve the > security of the Web and the Internet. >=20 >=20 > Scope >=20 > We seek position papers related to the security of OAuth, OpenID > Connect, and other technologies using OAuth under the hood. > Contributions regarding technologies that are used in OAuth, such as > JOSE, or impact the security of OAuth, such as Web technology, are = also > welcome. >=20 >=20 > Important Dates >=20 > Position paper submission deadline: May 2, 2017 (AoE, UTC-12). > Author notification: May 15, 2017. > Registration deadline: June 16, 2017. > Workshop: July 13 and July 14, 2017. >=20 >=20 > Invited Speakers >=20 > Cas Cremers, University of Oxford >=20 >=20 > Submission >=20 > We welcome position papers that describe existing work, raise new > requirements, highlight challenges, write-ups of implementation and > deployment experience, lessons-learned from successful or failed > attempts, and ideas on how to improve OAuth and OAuth extensions. >=20 > Position papers submitted to the OAuth Security Workshop may report on > (unpublished) work in progress, be submitted to other places, and may > even have already appeared or been accepted elsewhere. >=20 > Submissions must be in PDF format and should feature reasonable = margins > and formatting. There is no page limit, but the submission should be > brief (ideally not more than 3-5 pages). Submissions should not be > anonymized. >=20 > Submission Website: https://easychair.org/conferences/?conf=3Dosw17 = >=20 >=20 > Publication and Presentation >=20 > One of the authors of the accepted position paper is expected to = present > the paper at the workshop. >=20 > All presentations and papers will be put online but there will be no > formal proceedings. Authors of accepted papers will have the option to > revise their papers before they are put online. >=20 >=20 > IPR Policy >=20 > The workshop will have no expectation of IPR disclosure or licensing > related to its submissions. Authors are responsible for obtaining > appropriate publication clearances. >=20 >=20 > Program Committee >=20 > Chairs > David Basin (ETH Zurich) > Torsten Lodderstedt (YES Europe) >=20 > Members > John Bradley (Ping Identity) > Ralf K=C3=BCsters (University of Stuttgart) > Chris Mitchell (Royal Holloway University of London) > Anthony Nadalin (Microsoft) > Nat Sakimura (Nomura Research Institute) > Ralf Sasse (ETH Zurich) > J=C3=B6rg Schwenk (Ruhr University Bochum) > Hannes Tschofenig (IETF OAuth Working Group Co-Chair) > =20 > Am 13.03.2017 um 21:01 schrieb John Bradley >: > =20 > I did point out earlier when I discovered the dates, that I similarly = asked for it to be later in the week. > It is probably fine for Europeans but it will stop many people from = being able to attend including myself unless I can come up with other = meetings in Europe to fill those days. >=20 > If we cant move it then we will have to live with it and attend or = not. >=20 > John B. >=20 >=20 > On Mar 13, 2017, at 4:46 PM, Torsten Lodderstedt = > wrote: >=20 > Hi Mike, >=20 > yes, those are the right dates. There are restrictions from the host's = side, that=E2=80=99s why the workshop needs to take place on Monday and = Tuesday. As far as I remember the host was clear about that from the = beginning.=20 >=20 > best regards, > Torsten. >=20 >=20 > Am 12.03.2017 um 22:15 schrieb Mike Jones >: >=20 > Are Monday-Tuesday, July 10-11 really the right dates? I'm asking = because IETF in Prague doesn't start until Sunday, July 16th. That = leaves 4 days dead time in between for those of us who are attending = both. >=20 > When I was first told about this workshop, I was told that it would be = sometime Wednesday-Friday that week. Can it be moved back to those = dates? That would be a big help for those of us travelling distances to = attend. >=20 > Or is there also another event in the Wednesday-Friday timeframe that = people should also be considering attending? >=20 > Thanks, > -- Mike >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org = ] On Behalf Of Torsten Lodderstedt > Sent: Sunday, March 12, 2017 12:28 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] Second OAuth Security Workshop (Call for Papers) >=20 > Hi all, >=20 > the OAuth WG and the ETH Zurich will organize another workshop on = OAuth security (after the one last year in Trier). >=20 > Please find the Call for Papers below. >=20 > kind regards, > Torsten. >=20 > C a l l F o r P a p e r s >=20 > Second OAuth Security Workshop (OSW 2017) >=20 > Zurich, Switzerland -- July 10-11, 2017 >=20 > WWW:https://zisc.ethz.ch/oauth-security-workshop-2017-cfp/ = >=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=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >=20 > Overview >=20 > The OAuth Security Workshop (OSW) focuses on improving security of the = OAuth standard and related Internet protocols. This workshop brings = together the IETF OAuth Working Group and security experts from = research, industry, and standardization to this end. The workshop is = hosted by the Zurich Information Security and Privacy Center at ETH = Zurich. >=20 > While the standardization process of OAuth ensures extensive reviews = (both security and non-security related), further analysis by security = experts from academia and industry is essential to ensure high quality = specifications. Contributions to this workshop can help to improve the = security of the Web and the Internet. >=20 >=20 > Scope >=20 > We seek position papers related to the security of OAuth, OpenID = Connect, and other technologies using OAuth under the hood. > Contributions regarding technologies that are used in OAuth, such as = JOSE, or impact the security of OAuth, such as Web technology, are also = welcome. >=20 >=20 > Important Dates >=20 > Position paper submission deadline: May 2, 2017 (AoE, UTC-12). > Author notification: May 15, 2017. > Registration deadline: June 16, 2017. > Workshop: July 10 and July 11, 2017. >=20 >=20 > Invited Speakers >=20 > Cas Cremers, University of Oxford >=20 >=20 > Submission >=20 > We welcome position papers that describe existing work, raise new = requirements, highlight challenges, write-ups of implementation and = deployment experience, lessons-learned from successful or failed = attempts, and ideas on how to improve OAuth and OAuth extensions. >=20 > Position papers submitted to the OAuth Security Workshop may report on > (unpublished) work in progress, be submitted to other places, and may = even have already appeared or been accepted elsewhere. >=20 > Submissions must be in PDF format and should feature reasonable = margins and formatting. There is no page limit, but the submission = should be brief (ideally not more than 3-5 pages). Submissions should = not be anonymized. >=20 > Submission Website:https://easychair.org/conferences/?conf=3Dosw17 = >=20 >=20 > Publication and Presentation >=20 > One of the authors of the accepted position paper is expected to = present the paper at the workshop. >=20 > All presentations and papers will be put online but there will be no = formal proceedings. Authors of accepted papers will have the option to = revise their papers before they are put online. >=20 >=20 > IPR Policy >=20 > The workshop will have no expectation of IPR disclosure or licensing = related to its submissions. Authors are responsible for obtaining = appropriate publication clearances. >=20 >=20 > Program Committee >=20 > Chairs > David Basin (ETH Zurich) > Torsten Lodderstedt (YES Europe) >=20 > Members > John Bradley (Ping Identity) > Ralf K=C3=BCsters (University of Stuttgart) > Chris Mitchell (Royal Holloway University of London) Anthony Nadalin = (Microsoft) Nat Sakimura (Nomura Research Institute) Ralf Sasse (ETH = Zurich) J=C3=B6rg Schwenk (Ruhr University Bochum) Hannes Tschofenig = (IETF OAuth Working Group Co-Chair) >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = > =20 > =20 --Apple-Mail=_6C485701-B1B8-4EBF-994B-1DDDF3A73C65 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi all,

FYI= - submission deadline has been extended by one week since we didn=E2=80=99= t receive as much submissions as expected. 

I would like to invite you to submit a = paper or even to give an ad-hoc talk (I plan to). Please contact me via = e-mail if you happen to have any question regarding this = topic.

best = regards,
Torsten.



Am = 20.04.2017 um 19:49 schrieb Mike Jones <Michael.Jones@microsoft.com>:

Excellent!

 

From: = Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Thursday, April 20, 2017 10:42 AM
To: oauth@ietf.org
Cc: Mike Jones <Michael.Jones@microsoft.com>; John Bradley <ve7jtb@ve7jtb.com>
Subject: Re: [OAUTH-WG] Second OAuth Security Workshop = (Call for Papers)

 

Hi all,

 

I'm pleased to announce the hosts = managed to change the date of the security workshop to the end of the = week before IETF-99, July 13-14. 

 

Please find the updated CfP = below.

 

kind regards,

Torsten.

 

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

C a l l     F o r     P a p e r = s

Second OAuth Security Workshop (OSW 2017)

Zurich, Switzerland -- July 13-14, 2017 (note the changed event date)

WWW: https://zisc.ethz.ch/oauth-security-workshop-2017-cfp/

Position paper submission deadline: May 2, 2017 (AoE, UTC-12).

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

Overview

The OAuth Security Workshop (OSW) focuses on improving security of = the
OAuth standard and related Internet protocols. This workshop brings
together the IETF OAuth Working Group and security experts from
research, industry, and standardization to this end. The workshop is
hosted by the Zurich Information Security and Privacy Center at ETH = Zurich.

While the standardization process of OAuth ensures extensive reviews
(both security and non-security related), further analysis by = security
experts from academia and industry is essential to ensure high = quality
specifications. Contributions to this workshop can help to improve = the
security of the Web and the Internet.


Scope

We seek position papers related to the security of OAuth, OpenID
Connect, and other technologies using OAuth under the hood.
= Contributions regarding technologies that are used in OAuth, such as
JOSE, or impact the security of OAuth, such as Web technology, are = also
welcome.


Important Dates

Position paper submission deadline: May 2, 2017 (AoE, UTC-12).
Author notification: May 15, 2017.
Registration deadline: June 16, 2017.
Workshop: July 13 and July 14, 2017.


Invited Speakers

Cas Cremers, University of Oxford


Submission

We welcome position papers that describe existing work, raise new
requirements, highlight challenges, write-ups of implementation and
deployment experience, lessons-learned from successful or failed
attempts, and ideas on how to improve OAuth and OAuth extensions.

Position papers submitted to the OAuth Security Workshop may report = on
(unpublished) work in progress, be submitted to other places, and may
even have already appeared or been accepted elsewhere.

Submissions must be in PDF format and should feature reasonable = margins
and formatting. There is no page limit, but the submission should be
brief (ideally not more than 3-5 pages). Submissions should not be
anonymized.

Submission Website: https://easychair.org/conferences/?conf=3Dosw17


Publication and Presentation

One of the authors of the accepted position paper is expected to = present
the paper at the workshop.

All presentations and papers will be put online but there will be no
formal proceedings. Authors of accepted papers will have the option = to
revise their papers before they are put online.


IPR Policy

The workshop will have no expectation of IPR disclosure or licensing
related to its submissions. Authors are responsible for obtaining
appropriate publication clearances.


Program Committee

Chairs
David Basin (ETH Zurich)
Torsten Lodderstedt (YES Europe)

Members
John Bradley (Ping Identity)
Ralf K=C3=BCsters (University of Stuttgart)
Chris Mitchell (Royal Holloway University of London)
Anthony Nadalin (Microsoft)
Nat Sakimura (Nomura Research Institute)
Ralf Sasse (ETH Zurich)
J=C3=B6rg Schwenk (Ruhr University Bochum)
Hannes Tschofenig (IETF OAuth Working Group Co-Chair)

 

Am 13.03.2017 um 21:01 schrieb = John Bradley <ve7jtb@ve7jtb.com>:

 

I did point out earlier when I = discovered the dates, that I similarly asked for it to be later in the = week.
It is probably fine for Europeans but it will stop many people from = being able to attend including myself unless I can come up with other = meetings in Europe to fill those days.

If we cant move it then we will have to live with it and attend or = not.

John B.


On Mar 13, 2017, at 4:46 PM, Torsten Lodderstedt = <torsten@lodderstedt.net> wrote:

Hi Mike,

yes, those are the right dates. There are restrictions from the host's = side, that=E2=80=99s why the workshop needs to take place on Monday and = Tuesday. As far as I remember the host was clear about that from the = beginning.

best regards,
Torsten.


Am 12.03.2017 um 22:15 schrieb Mike Jones <Michael.Jones@microsoft.com>:

Are Monday-Tuesday, July 10-11 really the right dates?  I'm asking = because IETF in Prague doesn't start until Sunday, July 16th.  That = leaves 4 days dead time in between for those of us who are attending = both.

When I was first told about this workshop, I was told that it would be = sometime Wednesday-Friday that week.  Can it be moved back to those = dates?  That would be a big help for those of us travelling = distances to attend.

Or is there also another event in the Wednesday-Friday timeframe that = people should also be considering attending?

        &= nbsp;     =             &n= bsp; =             &n= bsp;       Thanks,
        &= nbsp;     =             &n= bsp; =             &n= bsp; =             &n= bsp; -- Mike

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten = Lodderstedt
Sent: Sunday, March 12, 2017 12:28 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Second OAuth Security Workshop (Call for Papers)

Hi all,

the OAuth WG and the ETH Zurich will organize another workshop on OAuth = security (after the one last year in Trier).

Please find the Call for Papers below.

kind regards,
Torsten.

C a l l     F o r     P a p e r = s

Second OAuth Security Workshop (OSW 2017)

Zurich, Switzerland -- July 10-11, 2017

WWW:https://zisc.ethz.ch/oauth-security-workshop-2017-cfp/

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

Overview

The OAuth Security Workshop (OSW) focuses on improving security of the = OAuth standard and related Internet protocols. This workshop brings = together the IETF OAuth Working Group and security experts from = research, industry, and standardization to this end. The workshop is hosted by the Zurich Information Security and Privacy = Center at ETH Zurich.

While the standardization process of OAuth ensures extensive reviews = (both security and non-security related), further analysis by security = experts from academia and industry is essential to ensure high quality = specifications. Contributions to this workshop can help to improve the security of the Web and the Internet.


Scope

We seek position papers related to the security of OAuth, OpenID = Connect, and other technologies using OAuth under the hood.
= Contributions regarding technologies that are used in OAuth, such as = JOSE, or impact the security of OAuth, such as Web technology, are also = welcome.


Important Dates

Position paper submission deadline: May 2, 2017 (AoE, UTC-12).
Author notification: May 15, 2017.
Registration deadline: June 16, 2017.
Workshop: July 10 and July 11, 2017.


Invited Speakers

Cas Cremers, University of Oxford


Submission

We welcome position papers that describe existing work, raise new = requirements, highlight challenges, write-ups of implementation and = deployment experience, lessons-learned from successful or failed = attempts, and ideas on how to improve OAuth and OAuth extensions.

Position papers submitted to the OAuth Security Workshop may report = on
(unpublished) work in progress, be submitted to other places, and may = even have already appeared or been accepted elsewhere.

Submissions must be in PDF format and should feature reasonable margins = and formatting. There is no page limit, but the submission should be = brief (ideally not more than 3-5 pages). Submissions should not be = anonymized.

Submission Website:https://easychair.org/conferences/?conf=3Dosw17


Publication and Presentation

One of the authors of the accepted position paper is expected to present = the paper at the workshop.

All presentations and papers will be put online but there will be no = formal proceedings. Authors of accepted papers will have the option to = revise their papers before they are put online.


IPR Policy

The workshop will have no expectation of IPR disclosure or licensing = related to its submissions. Authors are responsible for obtaining = appropriate publication clearances.


Program Committee

Chairs
David Basin (ETH Zurich)
Torsten Lodderstedt (YES Europe)

Members
John Bradley (Ping Identity)
Ralf K=C3=BCsters (University of Stuttgart)
Chris Mitchell (Royal Holloway University of London) Anthony Nadalin = (Microsoft) Nat Sakimura (Nomura Research Institute) Ralf Sasse (ETH = Zurich) J=C3=B6rg Schwenk (Ruhr University Bochum) Hannes Tschofenig = (IETF OAuth Working Group Co-Chair)

_______________________________________________
OAuth mailing 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=_6C485701-B1B8-4EBF-994B-1DDDF3A73C65-- --Apple-Mail=_5E1F998C-FE60-4D9B-ACF8-B4974AAA86D0 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ/DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUUwggQtoAMCAQICEDPbmsaqwjeZa3PxA3uZ8LQwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNzAxMDkwMDAwMDBaFw0xODAx MDkyMzU5NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArsGSzZyz9Lq9SRW9Sve5K8n5lWhplOCE6HH3gMye 12DjOpkFFZt0b73t27G17Xsp6WUxHhNevf7ck0AUpvYUPCHBqVGJSIWF9hWAoSFCgQACOoh/cDFb zz1PsMY8El7OmIus4JXtY4/VdoSIhFP3hzATbNAg32Kp+N8vtTuKTwbgnizJSyzZTYrsttn3LmwY 17HU+U9vXloMus5U/ln4ADZx0zyyDSsA6gtPxXYJpbgSTnHckVZ5zfR80guIZ538Y2qqsqt5VaSR SR2oQzE/HETkKc/odPVhqBrXLyvnSFkCPrAXV07rcvwkPvHZeYVu4QdVWyO2HIQ4i2x9r5m7SwID AQABo4IB9TCCAfEwHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFPng HgVxOZ7GSji/IW4YJMBj02PHMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZ MBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7 BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9D UFMwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2 Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMw gYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9v Y3NwLmNvbW9kb2NhLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkq hkiG9w0BAQsFAAOCAQEAAmueyHjiyL1qYgfe+hVSsGuKlgcvjCAfG8Jaq48tC0IjP8pH/tGi4uL9 CHVfLnV3pLDnjg6M2uvpEBp7crZZcnSPLeVss+tkhwv+F7ISYQyT4flNkqVUb8nfewbCPcIN13Ob fpU7rlXoIarEEplQo4SuymYVluQxTLOFKm5QOMF4JBMw/rjy4t95J7Mdp9NFUzQrKPJDaJ2Jr/Tc TXFcjLvNVmMBjK0959a9v1/1miRHd1DBsTh1KvBigEOUNMxvT5uUtB6/tioDZqBDDk8Gvdno/xmy e3YiasS7JgMREq5WcXqpWGu5kMFZMGPEvyPHeBZeqxx3amf4ImVnZ6WvgzGCA8MwggO/AgEBMIGw MIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0y NTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDPbmsaqwjeZa3Px A3uZ8LQwCQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTcwNTAzMTIyOTE4WjAjBgkqhkiG9w0BCQQxFgQULPq+jqxsuPZaAdPi1LF+eUl1Xzcw gcEGCSsGAQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/ BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqG SIb3DQEBAQUABIIBADJKwi25AX5L+/g94oN3fUuGPZNyJFhSEwsue9ukxHmZtsV3XOUpZodAks72 48JGP3OTrXLMgtJ/fh1D1S1HmZb7nUEkrvZWINTXsN7QNC4pUNM9muS3vijN+yU72s9ifUZcS1B8 Xb1rC0JiLK+GU1yCZnBsJXdaCJU5TG6HY+2KDaN3U12K2UYUTWuDjw4IN++OCfAuGTLVrFf7pHRx UJAHBmFS/rVSWq07OHUvfa3QuhoC4KGaGmR6j1sUvTDWPSvd9mPC+HU7UjwlzsOCvAgyY5Em4B1f tzR/08iUclvAlQa0byJOn8Gfa80FdHaaa9dxM5+XK5O06H1mhgZ1R0QAAAAAAAA= --Apple-Mail=_5E1F998C-FE60-4D9B-ACF8-B4974AAA86D0-- From nobody Thu May 4 00:19:15 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0763C129BAA for ; Thu, 4 May 2017 00:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WU2PzKGfORo1 for ; Thu, 4 May 2017 00:19:08 -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 BE93712941D for ; Thu, 4 May 2017 00:19:07 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id k74so4014937qke.1 for ; Thu, 04 May 2017 00:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ZQ5R2tAYP7I+vwxvuWSKrwg3umfN9u8SbZNuW9Ux43A=; b=e66cJMyrkjrb2PB8bP4wepWyaLh6iE1Ip61aai0zUdNhuDS6W+aDbSawzw9cHrG+D3 K1lcVrX+G2HHD8+WS1f/jYiJoPnLriqiLqZHTF6xljgK4XO5hZt5abM8kBLGV6mXiGwf KmH8vSvqS80KZWlJNiXL63fYn7ejDU60flcOfrxRhyoRH35HbYMiHZ1FZMAKpzy5Xiq5 p35W8zfNcJYQmk83ny0wNVWRXqWn9bONGltMe5CCTiZcpfY7lUof/vG5fx6uJH4PVaME dnvTc/KVMExVOPjMqAGPwQfWx+jOuGYnuHHTFkD2o+S8vWSRG43U4wLPhkqO1NnKwU+P VJgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ZQ5R2tAYP7I+vwxvuWSKrwg3umfN9u8SbZNuW9Ux43A=; b=KIa6nW20lZdXDlgCISRtmZgfS1N/p3Dr2bsOF2ZcdjxhQd8yaHmr8V1oNCqp9ci7GG qXLcD00M+Ot7g1LZg7QgesKsZryEkgjUReKgsiJLjijxdWXzXTpybR7jg6uTHH5P6Pli 6qJEsLVjlYSWrB3dB2g+dMOLy0AekjmdBxwCbaHgaY4CezUZLXVVthNLH3XMPYlor5rz Rs3RmQRmBqYYw/WQHV4Eta6PJjgXJRr0+d2nr95+gpMSuQm1jg1VuZYuMUoR6STMTB+n B75bqYWSKnJ5f91NYwRNEPlxNerQegKtTtvRZO/kv3fXhq4MgfwnkCS/lVtmyKP0wFmg R/og== X-Gm-Message-State: AN3rC/7BlMbOZ6Kgcbfg3SM6G1H8KPXPpUNuYAH/eSAk+/sC6LjoWnvq VPorP1JgJx1bh7HORmxgEy5eoP0WpQ== X-Received: by 10.55.88.4 with SMTP id m4mr5975555qkb.84.1493882346873; Thu, 04 May 2017 00:19:06 -0700 (PDT) MIME-Version: 1.0 References: <269DD0EC-FCBF-4691-9BAA-2B8F144C0353@lodderstedt.net> <3A9170DD-0861-478D-A9DD-9A55DC930B8D@ve7jtb.com> <4ACE4772-E01B-4D9A-8AED-7926B9E87615@lodderstedt.net> <18ACD3B9-A5BA-4C59-993C-C3A4C5F5EBBD@lodderstedt.net> In-Reply-To: <18ACD3B9-A5BA-4C59-993C-C3A4C5F5EBBD@lodderstedt.net> From: Nat Sakimura Date: Thu, 04 May 2017 07:18:54 +0000 Message-ID: To: Torsten Lodderstedt , "oauth@ietf.org" Content-Type: multipart/alternative; boundary=001a114e2d289f2ac2054ead966d Archived-At: Subject: Re: [OAUTH-WG] Second OAuth Security Workshop (Call for Papers) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 07:19:13 -0000 --001a114e2d289f2ac2054ead966d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ok, I will try but I am under multiple deadlines also... On Wed, May 3, 2017 at 5:32 Torsten Lodderstedt wrote: > Hi all, > > FYI - submission deadline has been extended by one week since we didn=E2= =80=99t > receive as much submissions as expected. > > I would like to invite you to submit a paper or even to give an ad-hoc > talk (I plan to). Please contact me via e-mail if you happen to have any > question regarding this topic. > > best regards, > Torsten. > > > > Am 20.04.2017 um 19:49 schrieb Mike Jones : > > Excellent! > > > > *From:* Torsten Lodderstedt [mailto:torsten@lodderstedt.net > ] > *Sent:* Thursday, April 20, 2017 10:42 AM > *To:* oauth@ietf.org > *Cc:* Mike Jones ; John Bradley < > ve7jtb@ve7jtb.com> > *Subject:* Re: [OAUTH-WG] Second OAuth Security Workshop (Call for Papers= ) > > > > Hi all, > > > > I'm pleased to announce the hosts managed to change the date of the > security workshop to the end of the week before IETF-99, July 13-14. > > > > Please find the updated CfP below. > > > > kind regards, > > Torsten. > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > C a l l F o r P a p e r s > > Second OAuth Security Workshop (OSW 2017) > > Zurich, Switzerland -- July 13-14, 2017 (note the changed event date) > > WWW: https://zisc.ethz.ch/oauth-security-workshop-2017-cfp/ > > Position paper submission deadline: May 2, 2017 (AoE, UTC-12). > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > Overview > > The OAuth Security Workshop (OSW) focuses on improving security of the > OAuth standard and related Internet protocols. This workshop brings > together the IETF OAuth Working Group and security experts from > research, industry, and standardization to this end. The workshop is > hosted by the Zurich Information Security and Privacy Center at ETH Zuric= h. > > While the standardization process of OAuth ensures extensive reviews > (both security and non-security related), further analysis by security > experts from academia and industry is essential to ensure high quality > specifications. Contributions to this workshop can help to improve the > security of the Web and the Internet. > > > Scope > > We seek position papers related to the security of OAuth, OpenID > Connect, and other technologies using OAuth under the hood. > Contributions regarding technologies that are used in OAuth, such as > JOSE, or impact the security of OAuth, such as Web technology, are also > welcome. > > > Important Dates > > Position paper submission deadline: May 2, 2017 (AoE, UTC-12). > Author notification: May 15, 2017. > Registration deadline: June 16, 2017. > Workshop: July 13 and July 14, 2017. > > > Invited Speakers > > Cas Cremers, University of Oxford > > > Submission > > We welcome position papers that describe existing work, raise new > requirements, highlight challenges, write-ups of implementation and > deployment experience, lessons-learned from successful or failed > attempts, and ideas on how to improve OAuth and OAuth extensions. > > Position papers submitted to the OAuth Security Workshop may report on > (unpublished) work in progress, be submitted to other places, and may > even have already appeared or been accepted elsewhere. > > Submissions must be in PDF format and should feature reasonable margins > and formatting. There is no page limit, but the submission should be > brief (ideally not more than 3-5 pages). Submissions should not be > anonymized. > > Submission Website: https://easychair.org/conferences/?conf=3Dosw17 > > > Publication and Presentation > > One of the authors of the accepted position paper is expected to present > the paper at the workshop. > > All presentations and papers will be put online but there will be no > formal proceedings. Authors of accepted papers will have the option to > revise their papers before they are put online. > > > IPR Policy > > The workshop will have no expectation of IPR disclosure or licensing > related to its submissions. Authors are responsible for obtaining > appropriate publication clearances. > > > Program Committee > > Chairs > David Basin (ETH Zurich) > Torsten Lodderstedt (YES Europe) > > Members > John Bradley (Ping Identity) > Ralf K=C3=BCsters (University of Stuttgart) > Chris Mitchell (Royal Holloway University of London) > Anthony Nadalin (Microsoft) > Nat Sakimura (Nomura Research Institute) > Ralf Sasse (ETH Zurich) > J=C3=B6rg Schwenk (Ruhr University Bochum) > Hannes Tschofenig (IETF OAuth Working Group Co-Chair) > > > > Am 13.03.2017 um 21:01 schrieb John Bradley : > > > > I did point out earlier when I discovered the dates, that I similarly > asked for it to be later in the week. > It is probably fine for Europeans but it will stop many people from being > able to attend including myself unless I can come up with other meetings = in > Europe to fill those days. > > If we cant move it then we will have to live with it and attend or not. > > John B. > > > On Mar 13, 2017, at 4:46 PM, Torsten Lodderstedt > wrote: > > Hi Mike, > > yes, those are the right dates. There are restrictions from the host's > side, that=E2=80=99s why the workshop needs to take place on Monday and T= uesday. As > far as I remember the host was clear about that from the beginning. > > best regards, > Torsten. > > > Am 12.03.2017 um 22:15 schrieb Mike Jones : > > Are Monday-Tuesday, July 10-11 really the right dates? I'm asking becaus= e > IETF in Prague doesn't start until Sunday, July 16th. That leaves 4 days > dead time in between for those of us who are attending both. > > When I was first told about this workshop, I was told that it would be > sometime Wednesday-Friday that week. Can it be moved back to those dates= ? > That would be a big help for those of us travelling distances to attend. > > Or is there also another event in the Wednesday-Friday timeframe that > people should also be considering attending? > > Thanks, > -- Mike > > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org ] On > Behalf Of Torsten Lodderstedt > Sent: Sunday, March 12, 2017 12:28 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] Second OAuth Security Workshop (Call for Papers) > > Hi all, > > the OAuth WG and the ETH Zurich will organize another workshop on OAuth > security (after the one last year in Trier). > > Please find the Call for Papers below. > > kind regards, > Torsten. > > C a l l F o r P a p e r s > > Second OAuth Security Workshop (OSW 2017) > > Zurich, Switzerland -- July 10-11, 2017 > > WWW:https://zisc.ethz.ch/oauth-security-workshop-2017-cfp/ > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > Overview > > The OAuth Security Workshop (OSW) focuses on improving security of the > OAuth standard and related Internet protocols. This workshop brings > together the IETF OAuth Working Group and security experts from research, > industry, and standardization to this end. The workshop is hosted by the > Zurich Information Security and Privacy Center at ETH Zurich. > > While the standardization process of OAuth ensures extensive reviews (bot= h > security and non-security related), further analysis by security experts > from academia and industry is essential to ensure high quality > specifications. Contributions to this workshop can help to improve the > security of the Web and the Internet. > > > Scope > > We seek position papers related to the security of OAuth, OpenID Connect, > and other technologies using OAuth under the hood. > Contributions regarding technologies that are used in OAuth, such as JOSE= , > or impact the security of OAuth, such as Web technology, are also welcome= . > > > Important Dates > > Position paper submission deadline: May 2, 2017 (AoE, UTC-12). > Author notification: May 15, 2017. > Registration deadline: June 16, 2017. > Workshop: July 10 and July 11, 2017. > > > Invited Speakers > > Cas Cremers, University of Oxford > > > Submission > > We welcome position papers that describe existing work, raise new > requirements, highlight challenges, write-ups of implementation and > deployment experience, lessons-learned from successful or failed attempts= , > and ideas on how to improve OAuth and OAuth extensions. > > Position papers submitted to the OAuth Security Workshop may report on > (unpublished) work in progress, be submitted to other places, and may eve= n > have already appeared or been accepted elsewhere. > > Submissions must be in PDF format and should feature reasonable margins > and formatting. There is no page limit, but the submission should be brie= f > (ideally not more than 3-5 pages). Submissions should not be anonymized. > > Submission Website:https://easychair.org/conferences/?conf=3Dosw17 > > > Publication and Presentation > > One of the authors of the accepted position paper is expected to present > the paper at the workshop. > > All presentations and papers will be put online but there will be no > formal proceedings. Authors of accepted papers will have the option to > revise their papers before they are put online. > > > IPR Policy > > The workshop will have no expectation of IPR disclosure or licensing > related to its submissions. Authors are responsible for obtaining > appropriate publication clearances. > > > Program Committee > > Chairs > David Basin (ETH Zurich) > Torsten Lodderstedt (YES Europe) > > Members > John Bradley (Ping Identity) > Ralf K=C3=BCsters (University of Stuttgart) > Chris Mitchell (Royal Holloway University of London) Anthony Nadalin > (Microsoft) Nat Sakimura (Nomura Research Institute) Ralf Sasse (ETH > Zurich) J=C3=B6rg Schwenk (Ruhr University Bochum) Hannes Tschofenig (IET= F OAuth > Working Group Co-Chair) > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Nat Sakimura Chairman of the Board, OpenID Foundation --001a114e2d289f2ac2054ead966d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ok, I will try but I am under multiple deadlines also...
On Wed, May 3, 2017 at 5:32 Torsten Lodderste= dt <torsten@lodderstedt.net> wrote:




Excellent!

=C2=A0

From: Torsten Lodderstedt [mailto:torsten@lodder= stedt.net]
Sent: Thursday, April 20, 2017 10:42 AM
To: oauth@ietf.o= rg
Cc: Mike Jones <Michael.Jones@microsoft.com>; John Bradley <ve7jtb@ve7jtb.com>=
Subject: Re: [OAUTH-WG] Second OAuth Security Workshop (Call for Pap= ers)

=C2=A0

Hi all,

=C2=A0

I'm pleased to announce the hosts managed t= o change the date of the security workshop to the end of the week before IE= TF-99, July 13-14.=C2=A0

=C2=A0

Please find the updated CfP below.

=C2=A0

kind regards,

Torsten.

=C2=A0

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

C a l l =C2=A0=C2=A0=C2=A0=C2=A0F o r =C2=A0=C2=A0=C2=A0=C2=A0P a p e r s
Second OAuth Security Workshop (OSW 2017)

Zurich, Switzerland -- July 13-14, 2017 (note the changed event date)

WWW:=C2=A0https://zisc.ethz.ch/oauth-security-workshop-2017-cfp/<= /a>

Position paper submission deadline: May 2, 2017 (AoE, UTC-12).

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

Overview

The OAuth Security Workshop (OSW) focuses on improving security of the
OAuth standard and related Internet protocols. This workshop brings
together the IETF OAuth Working Group and security experts from
research, industry, and standardization to this end. The workshop is
hosted by the Zurich Information Security and Privacy Center at ETH Zurich.=

While the standardization process of OAuth ensures extensive reviews
(both security and non-security related), further analysis by security
experts from academia and industry is essential to ensure high quality
specifications. Contributions to this workshop can help to improve the
security of the Web and the Internet.


Scope

We seek position papers related to the security of OAuth, OpenID
Connect, and other technologies using OAuth under the hood.
Contributions regarding technologies that are used in OAuth, such as
JOSE, or impact the security of OAuth, such as Web technology, are also
welcome.


Important Dates

Position paper submission deadline: May 2, 2017 (AoE, UTC-12).
Author notification: May 15, 2017.
Registration deadline: June 16, 2017.
Workshop: July 13 and July 14, 2017.


Invited Speakers

Cas Cremers, University of Oxford


Submission

We welcome position papers that describe existing work, raise new
requirements, highlight challenges, write-ups of implementation and
deployment experience, lessons-learned from successful or failed
attempts, and ideas on how to improve OAuth and OAuth extensions.

Position papers submitted to the OAuth Security Workshop may report on
(unpublished) work in progress, be submitted to other places, and may
even have already appeared or been accepted elsewhere.

Submissions must be in PDF format and should feature reasonable margins
and formatting. There is no page limit, but the submission should be
brief (ideally not more than 3-5 pages). Submissions should not be
anonymized.

Submission Website:=C2=A0https://easychair.org/conferences/?conf=3Dosw17=


Publication and Presentation

One of the authors of the accepted position paper is expected to present the paper at the workshop.

All presentations and papers will be put online but there will be no
formal proceedings. Authors of accepted papers will have the option to
revise their papers before they are put online.


IPR Policy

The workshop will have no expectation of IPR disclosure or licensing
related to its submissions. Authors are responsible for obtaining
appropriate publication clearances.


Program Committee

Chairs
David Basin (ETH Zurich)
Torsten Lodderstedt (YES Europe)

Members
John Bradley (Ping Identity)
Ralf K=C3=BCsters (University of Stuttgart)
Chris Mitchell (Royal Holloway University of London)
Anthony Nadalin (Microsoft)
Nat Sakimura (Nomura Research Institute)
Ralf Sasse (ETH Zurich)
J=C3=B6rg Schwenk (Ruhr University Bochum)
Hannes Tschofenig (IETF OAuth Working Group Co-Chair)

=C2=A0

Am 13.03.2017 um 21:01 schrieb John Bradley <= ;ve7jtb@ve7jtb.com>:

=C2=A0

I did point out earlier when I discovered the d= ates, that I similarly asked for it to be later in the week.
It is probably fine for Europeans but it will stop many people from being a= ble to attend including myself unless I can come up with other meetings in = Europe to fill those days.

If we cant move it then we will have to live with it and attend or not.

John B.


On Mar 13, 2017, at 4:46 PM, Torsten Lodderstedt <torsten@lodderstedt.net&g= t; wrote:

Hi Mike,

yes, those are the right dates. There are restrictions from the host's = side, that=E2=80=99s why the workshop needs to take place on Monday and Tue= sday. As far as I remember the host was clear about that from the beginning= .

best regards,
Torsten.


Am 12.03.2017 um 22:15 schrieb Mike Jones <Michael.Jones@microsoft.com&= gt;:

Are Monday-Tuesday, July 10-11 really the right dates?=C2=A0 I'm asking= because IETF in Prague doesn't start until Sunday, July 16th.=C2=A0 Th= at leaves 4 days dead time in between for those of us who are attending bot= h.

When I was first told about this workshop, I was told that it would be some= time Wednesday-Friday that week.=C2=A0 Can it be moved back to those dates?= =C2=A0 That would be a big help for those of us travelling distances to att= end.

Or is there also another event in the Wednesday-Friday timeframe that peopl= e should also be considering attending?

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks,
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2= =A0=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 [ma= ilto:oauth-bounces@ietf.org] On Behalf Of Torsten Lodderstedt
Sent: Sunday, March 12, 2017 12:28 PM
To: oauth@ietf.org<= br> Subject: [OAUTH-WG] Second OAuth Security Workshop (Call for Papers)

Hi all,

the OAuth WG and the ETH Zurich will organize another workshop on OAuth sec= urity (after the one last year in Trier).

Please find the Call for Papers below.

kind regards,
Torsten.

C a l l =C2=A0=C2=A0=C2=A0=C2=A0F o r =C2=A0=C2=A0=C2=A0=C2=A0P a p e r s
Second OAuth Security Workshop (OSW 2017)

Zurich, Switzerland -- July 10-11, 2017

WWW:https://zisc.ethz.ch/oauth-security-workshop-2017-cfp/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

Overview

The OAuth Security Workshop (OSW) focuses on improving security of the OAut= h standard and related Internet protocols. This workshop brings together th= e IETF OAuth Working Group and security experts from research, industry, an= d standardization to this end. The workshop is hosted by the Zurich Information Security and Privacy Center a= t ETH Zurich.

While the standardization process of OAuth ensures extensive reviews (both = security and non-security related), further analysis by security experts fr= om academia and industry is essential to ensure high quality specifications= . Contributions to this workshop can help to improve the security of the Web and the Internet.


Scope

We seek position papers related to the security of OAuth, OpenID Connect, a= nd other technologies using OAuth under the hood.
Contributions regarding technologies that are used in OAuth, such as JOSE, = or impact the security of OAuth, such as Web technology, are also welcome.<= br>

Important Dates

Position paper submission deadline: May 2, 2017 (AoE, UTC-12).
Author notification: May 15, 2017.
Registration deadline: June 16, 2017.
Workshop: July 10 and July 11, 2017.


Invited Speakers

Cas Cremers, University of Oxford


Submission

We welcome position papers that describe existing work, raise new requireme= nts, highlight challenges, write-ups of implementation and deployment exper= ience, lessons-learned from successful or failed attempts, and ideas on how= to improve OAuth and OAuth extensions.

Position papers submitted to the OAuth Security Workshop may report on
(unpublished) work in progress, be submitted to other places, and may even = have already appeared or been accepted elsewhere.

Submissions must be in PDF format and should feature reasonable margins and= formatting. There is no page limit, but the submission should be brief (id= eally not more than 3-5 pages). Submissions should not be anonymized.

Submission Website:https://easychair.org/conferences/?conf=3Dosw17

Publication and Presentation

One of the authors of the accepted position paper is expected to present th= e paper at the workshop.

All presentations and papers will be put online but there will be no formal= proceedings. Authors of accepted papers will have the option to revise the= ir papers before they are put online.


IPR Policy

The workshop will have no expectation of IPR disclosure or licensing relate= d to its submissions. Authors are responsible for obtaining appropriate pub= lication clearances.


Program Committee

Chairs
David Basin (ETH Zurich)
Torsten Lodderstedt (YES Europe)

Members
John Bradley (Ping Identity)
Ralf K=C3=BCsters (University of Stuttgart)
Chris Mitchell (Royal Holloway University of London) Anthony Nadalin (Micro= soft) Nat Sakimura (Nomura Research Institute) Ralf Sasse (ETH Zurich) J=C3= =B6rg Schwenk (Ruhr University Bochum) Hannes Tschofenig (IETF OAuth Workin= g Group Co-Chair)

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


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

=C2=A0

=C2=A0


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

Nat Sakimura

Chairman of the Board, OpenID Foundation

--001a114e2d289f2ac2054ead966d-- From nobody Sat May 6 15:08:36 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91643129431 for ; Sat, 6 May 2017 15:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3 X-Spam-Level: *** X-Spam-Status: No, score=3 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, MISSING_SUBJECT=1.799, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoHOjPw9aKjX for ; Sat, 6 May 2017 15:08:34 -0700 (PDT) Received: from mail-lf0-x243.google.com (mail-lf0-x243.google.com [IPv6:2a00:1450:4010:c07::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB51129436 for ; Sat, 6 May 2017 15:08:33 -0700 (PDT) Received: by mail-lf0-x243.google.com with SMTP id q70so3227223lfi.0 for ; Sat, 06 May 2017 15:08:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:mime-version:date:reply-to:message-id; bh=Jmp7RcyenrJe322nZST/3lEgad/AuW7LHi5Kt4GYTGU=; b=lxiclXmkVD0ChxDD5QwWmsHA3aCVTyttr9rEyri5e/TbOTQcBHe0vv00IlukBNrrJm QOXX9auM4VzhEWnsDaRJhQBboLHY+j3m5yFjXqzU3II/jaUb1u9ZKH+Ermy7ylv1Duqu eo0giTl3jIdFchSp6AgYF6d3qj8eOvg12v4sC7eTk5Six62foYsTScp3A3fOQPuJojQ+ BRfNaq/ohn8sSgphcnvg22Zev0/i6l6PqYICooZNXgfdmpVft0KJEjDh/8YxBfl2cEg5 lSLlvPi+p+1aO9eGBXkh5j6MyIFFuZ7h5w60eIKWYPwvF96Mncu4g0rsMmYJ0bogy30w gulw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:mime-version:date:reply-to:message-id; bh=Jmp7RcyenrJe322nZST/3lEgad/AuW7LHi5Kt4GYTGU=; b=pIMCE1dOUC2uqUyIWDYVEC+DDwtk2WTT9+KT3q+pygL0nLEGmwjRff6zjEor/d/g7I XNkmALObyoj3K0gjbeneXEz/q/vdPZippu1/tnDy+nlRTY9icgjLdIH1hfTUWrrIE6cd QD8Z33KPlhuGBo/1cZoNk0POuG7I1BNuIREkMQ2qQV630EPF+YcmjNYxZxGq1r3YZ8Xs rbotTUyLIfivUSH+fiD4FKtAJMGTI+G0oICpLpQtwPStx/4OuZMrULes4SujBULHBvE7 UTTJXC5wdf0EEE0XwEytpF/qb6HRkZ0llaOl17jo7UCa9IoPsSDrHlRpVfRQ2SHE8bxy Qp3A== X-Gm-Message-State: AODbwcA8Ohr+WTRYDbDtTwJxG0O1SO9WfK9i0nhHxLSH+yMdsf24CMb9 90inAA3ERgTWuaqUoC4= X-Received: by 10.25.216.148 with SMTP id r20mr2747688lfi.153.1494108511072; Sat, 06 May 2017 15:08:31 -0700 (PDT) Received: from f384.i.mail.ru (f384.i.mail.ru. [185.5.136.55]) by smtp.gmail.com with ESMTPSA id h96sm646267lji.10.2017.05.06.15.08.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 May 2017 15:08:30 -0700 (PDT) From: =?UTF-8?B?0KLQsCDQpyDQmtC70LDRgdGB0L3Qvg==?= To: OAuth@ietf.org MIME-Version: 1.0 X-Mailer: Mail.Ru Mailer 1.0 Date: Sun, 07 May 2017 01:08:29 +0300 X-Letter-Fingerprint: naxjcILxmL8zV8RJeBPLhQ01UTNkpUwd Reply-To: =?UTF-8?B?0KLQsCDQpyDQmtC70LDRgdGB0L3Qvg==?= X-Priority: 3 (Normal) Message-ID: <1494108509.338069337@f384.i.mail.ru> Content-Type: multipart/alternative; boundary="--ALT--dfce91a01494108509" Authentication-Results: f384.i.mail.ru; auth=pass smtp.auth=allomaks559@gmail.com smtp.mailfrom=allomaks559@gmail.com X-7FA49CB5: 0D63561A33F958A5C12F681A2BA1B6816363B497FD4313FD985958D3EF2919B0725E5C173C3A84C32F2BBD8E6CC4192DE6AD23C89BB8041D2219AA581D1B0840C4224003CC836476C0CAF46E325F83A50BF2EBBBDD9D6B0F2AF38021CC9F462D574AF45C6390F7469DAA53EE0834AAEE X-Mailru-Sender: CAE1AB26BAE712D79F2E82615C59A90F0076A196DEF3110F995C8EF24B7591404455BCB3F16798A6000D1CD33797CF49B84998B44F3B8FB54E1958F1E076CAE2B189DBD4ED4E54F3413F457DEE9B83185FEEDEB644C299C0ED14614B50AE0675 X-Mras: OK X-Spam: undefined Archived-At: Subject: [OAUTH-WG] (no subject) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 22:08:35 -0000 ----ALT--dfce91a01494108509 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Ci0tCtCe0YLQv9GA0LDQstC70LXQvdC+INC40LcgTWFpbC5SdSDQtNC70Y8gQW5kcm9pZA== ----ALT--dfce91a01494108509 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 CjxIVE1MPjxCT0RZPjxwIHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IiBkaXI9Imx0ciI+PC9wPiAK PGRpdiBpZD0ibWFpbC1hcHAtYXV0by1kZWZhdWx0LXNpZ25hdHVyZSI+CiA8cCBkaXI9Imx0ciI+ LS08YnI+INCe0YLQv9GA0LDQstC70LXQvdC+INC40LcgTWFpbC5SdSDQtNC70Y8gQW5kcm9pZDwv cD4KPC9kaXY+PC9CT0RZPjwvSFRNTD4K ----ALT--dfce91a01494108509-- From nobody Mon May 8 06:02:31 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82EF129467 for ; Mon, 8 May 2017 06:02: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVt-P96T2qJj for ; Mon, 8 May 2017 06:02:23 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::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 EAC3B129465 for ; Mon, 8 May 2017 06:02:22 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id e55so40261646uaa.2 for ; Mon, 08 May 2017 06:02:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SXnegd+RCc48ZHH6jHdpDSUPoHc+XPUlMgTCMA5fSaI=; b=WVpnP/JDPID8xOMui4m31+HjflOPJf3jEVsY/PZYwxGPr2DkQHYgH9/LlOr1kmNeJy yfumkds+q/mDohMym9j4FadA3gBzD7yiUkWBqAsCDjWtrUPl8sSg/l5jhLOzT3jQijj4 +vzlvgyUaMvNMc6mAy4e7LrE+8+zyflkFjo63bO2VeKwmXzcyzd5CyAVJ/9sVFOhmtaO /cENVo9IJQu9Js7YzCWag7QT0hRvUIHihWn+3RiuJtabN33asVyLOtoq1f9GkOws5ZYa kTLIfeQOsX+xNT8YPCiEtX6RSIobxCTPumeMP/B/I9TLey9SMpQA7sQoMOfgRbPeUrZc 4qIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SXnegd+RCc48ZHH6jHdpDSUPoHc+XPUlMgTCMA5fSaI=; b=uIxAakf5MZLYRdedZQr5w0e0V/KJeoQC3nKb+F+FvdOnI+UyzC2YURmxuoXWvyX2DB EHxNp8RFz28rETXQ1YILBJMGI2+B+pLolVqUZlitHEKrSUUhVEiZ2PjBCijI+mVuSxlM yrd4P1txKYCPFOS4hOZaMUbnNazloMfkdrLqya5i9SAbvxB4irs4v2Z7t3T6lIibpLV3 gOPTK6mqyhN+kb1Rz/ePBJuh96ea3uWkJPrkRy7uu3iEYewTwXJ3Eg4W+Rw6bipRC8uB 0jjlCvvIvGpkUkKe65ESqd+UjuRIFvl1pRQSY+ejAGZV5udqWQiLCJaXSqXyJkG7+ucX L0MQ== X-Gm-Message-State: AN3rC/6vklWoP4558y4RMILbKjlKWKdf+MQytYgCBz/S87SiN/OFF6uZ F+p5MQobVY460dErk1sOx9L21cwFmC1P X-Received: by 10.176.6.197 with SMTP id g63mr15397719uag.52.1494248541749; Mon, 08 May 2017 06:02:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.76.91 with HTTP; Mon, 8 May 2017 06:02:21 -0700 (PDT) In-Reply-To: <5529a18f-0ebe-eeae-2de1-c4066cf986b3@forgerock.com> References: <77856AF4-9B2E-4478-9509-1459037C24E4@ve7jtb.com> <22d06952-94ab-e6a9-d2b2-f96f8252bf5e@mit.edu> <4107AB98-25D8-4542-B932-CD6F921D0D1D@lodderstedt.net> <5529a18f-0ebe-eeae-2de1-c4066cf986b3@forgerock.com> From: Rifaat Shekh-Yusef Date: Mon, 8 May 2017 09:02:21 -0400 Message-ID: To: Simon Moffatt Cc: Torsten Lodderstedt , Justin Richer , "oauth@ietf.org" Content-Type: multipart/related; boundary=94eb2c122e648c1039054f02d9ca Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Device Flow: IETF98 Follow-up X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 13:02:30 -0000 --94eb2c122e648c1039054f02d9ca Content-Type: multipart/alternative; boundary=94eb2c122e648c1036054f02d9c9 --94eb2c122e648c1036054f02d9c9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable All, Hannes and I discussed the Device Flow draft. Based on the mailing list feedback, we see that there is a good support for keeping the "user_code" parameter in, but there is a need to document the security implication of this feature. If anyone is against keeping this feature, please speak up now. *William,* Can you please update the document based on the feedback you received so far? We would like to start a WGLC after we get the new version of the draft. We also have few comments on v05 of the draft: Section 3.3, second paragraph: The document should explicitly state that this step must be done over an HTTPS channel. Also, the paragraph is talking about an "end-user" performing the procedure. This could be done by an administrator that has a long list of devices, e.g. IoT devices, that support this mechanism. So, maybe the document should clearly state that too. Nits: Section 3.3, 3rd paragraph, second line: Remove the "a" before "the browser" Section 5.2, 1st paragraph, second line: Remove the word "they" after "attacker" Regards, Rifaat & Hannes On Tue, May 2, 2017 at 4:56 AM, Simon Moffatt wrote: > +1 for separate. The real world implementations we've seen tend to not > need the URL at all. Eg end user out of band is in a web application on > the their laptop/tablet and that app has a "pair device" area, where they > just enter the necessary code - so they don't even need to see/use a URL > from the device. > > Having the code augmented in to the URL too opens up the ability for that > code to be logged on intermediary network devices. > > SM > > On 02/05/17 06:32, Torsten Lodderstedt wrote: > > +1 to keep the optional parameter along with clear wording regarding > security risk and interoperability > > Am 29.04.2017 um 15:12 schrieb Justin Richer : > > +1, documentation is better. Though we also need to keep in mind that thi= s > was the justification for the password flow in 6749, which has been abuse= d > all over the place (and continues to this day). Still, it would be arguab= ly > worse without that so I'm good with keeping the parameter in there as lon= g > as we're careful. > > Namely: So long as the user code is *also* delivered separately to the > user, we would have interoperability between the two. What I don't think = we > want is some systems that *require* the URI parameter on the approval URL > and other implementations that *forbid* it. That case could end up with > something like: I've got a set-top system that's incapable of displaying = a > separate user code because it always assumes it's baked into the URL, and > then I try to put it on a server that requires the code be entered > separately. > > The resulting spec needs to be clear that the box MUST be able to display > both the URL and the code separately, in case the URL does not include th= e > code. In fact, maybe we'd even want to introduce a new parameter from the > endpoint for the pre-composed URL: > > user_code > REQUIRED. The end-user verification code. > > verification_uri > REQUIRED. The end-user verification URI on the authorization > server. The URI should be short and easy to remember as end- > users will be asked to manually type it into their user-agent. > > composite_verification_uri > OPTIONAL. The end-user verification URI with the end-user > verification code already included. See discussion in [blah] > for its use. > > -- Justin > > > On 4/28/2017 6:38 PM, John Bradley wrote: > > I would like to keep the optional parameter. It is useful enough that i= f > we don=E2=80=99t have it people will add it on there own as a custom para= meter. > Better to document any issues. > > John B. > > On Apr 28, 2017, at 5:39 PM, William Denniss wrote: > > Thanks all who joined us in Chicago in person and remotely last month for > the discussion on the device flow. [recording here > , > presentation starts at about 7min in]. > > The most contentious topic was addition of the user_code URI param > extension (introduced in version 05, documented in Section 3.3 > > ). > > I'd like to close out that discussion with a decision soon so we can > advance to a WG last call on the draft. > > To summarise my thoughts on the param: > > 1. It can be can be used to improve usability =E2=80=93 QR codes and N= FC can > be used with this feature to create a more delightful user authorizati= on > experience. > 2. It may increase the potential phishing risk (which we can > document), as the user has less typing. This risk assessment is likely= not > one-size-fits-all, it may vary widely due to different the different > potential applications of this standard. > 3. The way it's worded makes it completely optional, leaving it up to > the discretion of the authorization server on whether to offer the > optimisation, allowing them to secure it as best they see it. > 4. I do believe it is possible to design a secure user experiance that > includes this optimization. > > I think on the balance, it's worthwhile feature to include, and one that > benefits interop. The authorization server has complete control over > whether to enable this feature =E2=80=93 as Justin pointed out in the mee= ting, it > degrades really nicely =E2=80=93 and should they enable it, they have con= trol over > the user experiance and can add whatever phishing mitigations their > use-case warrants. Rarely is there a one-size-fits-all risk profile, > use-cases of this flow range widely from mass-market TV apps to > internal-only device bootstrapping by employees, so I don't think we shou= ld > be overly prescriptive. > > Mitigating phishing is already something that is in the domain of the > authorization server with OAuth generally, and I know that this is an > extremely important consideration when designing user authorization flows= . > This spec will be no exception to that, with or without this optimization= . > > That's my opinion. I'm keen to continue the discussion from Chicago and > reach rough consensus so we can progress forward. > > Best, > William > > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > -- > [image: ForgeRock] *Simon Moffatt* > Product Management | ForgeRock > *tel* +44 (0) 7903 347 240 <+44%207903%20347240> | *e* > Simon.Moffatt@Forgerock.com > *skype* simon.moffatt | *web* www.forgerock.com | *twitter* > @simonmoffatt > [image: ForgeRock Live 2017] > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --94eb2c122e648c1036054f02d9c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

Hannes and I discussed = the Device Flow draft. Based on the mailing list
feedback, we see= that there is a good support for keeping the "user_code"
parameter in, but there is a need to document the security implication o= f
this feature. If anyone is against keeping this feature, please= speak up
now.


William= ,

Can you please update the document based on = the feedback you received so far?
We would like to start a WGLC a= fter we get the new version of the draft.


We also have few comments on v05 of the draft:

<= div>Section 3.3, second paragraph:

=C2=A0 =C2=A0Th= e document should explicitly state that this step must be done over an
=C2=A0 =C2=A0HTTPS channel.

=C2=A0 =C2=A0Als= o, the paragraph is talking about an "end-user" performing the
=C2=A0 =C2=A0procedure. This could be done by an administrator that= has a long list
=C2=A0 =C2=A0of devices, e.g. IoT devices, that = support this mechanism. So, maybe the
=C2=A0 =C2=A0document shoul= d clearly state that too.


Nits:

Section 3.3, 3rd paragraph, second line:
= =C2=A0 =C2=A0Remove the "a" before "the browser"
<= div>
Section 5.2, 1st paragraph, second line:
=C2= =A0 =C2=A0Remove the word "they" after "attacker"
=

Regards,
=C2=A0Rifaat & Hannes
=


On Tue, May 2, 2017 at 4:56 AM, Simon Moffatt <sim= on.moffatt@forgerock.com> wrote:
=20 =20 =20

+1 for separate. The real world implementations we've seen tend to not need the URL at all.=C2=A0 Eg end user out of band is in a web application on the their laptop/tablet and that app has a "pair device" area, where they just enter the necessary code - so they don't even need to see/use a URL from the device.

Having the code augmented in to the URL too opens up the ability for that code to be logged on intermediary network devices.

SM


On 02/05/17 06:32,= Torsten Lodderstedt wrote:
=20
+1 to keep the optional parameter along with clear wording regarding security risk and interoperability=C2=A0

Am 29.04.2017 um 15:12 schrieb Justin Richer <jricher@mit.edu>:

=20

+1, documentation is better. Though we also need to keep in mind that this was the justification for the password flow in 6749, which has been abused all over the place (and continues to this day). Still, it would be arguably worse without that so I'm good with keeping the parameter in ther= e as long as we're careful.

Namely: So long as the user code is *also* delivered separately to the user, we would have interoperability between the two. What I don't think we want is some systems that *require* the URI parameter on the approval URL and other implementations that *forbid* it. That case could end up with something like: I've got a set-top system that'= s incapable of displaying a separate user code because it always assumes it's baked into the URL, and then I try to put it on a server that requires the code be entered separately.

The resulting spec needs to be clear that the box MUST be able to display both the URL and the code separately, in case the URL does not include the code. In fact, maybe we'd even want to introduce a new parameter from the endpoint for the pre-composed URL:

   user_code
      REQUIRED.  The end-user verification code.

   verification_uri
      REQUIRED.  The end-user verification URI on the authorization
      server.  The URI should be short and easy to remember as end-
      users will be asked to manually type it into their user-agent.

   composite_verific=
ation_uri
      OPTIONAL.  The end-user verification URI with the end-user=20
      verification code already included. See discussion in [blah]
      for its use.

 -- Justin
On 4/28/2017= 6:38 PM, John Bradley wrote:
=20 I would like to keep the optional parameter. =C2=A0 It is usefu= l enough that if we don=E2=80=99t have it people will add it on t= here own as a custom parameter. =C2=A0
Better to document any issues.=C2=A0

John B.
On Apr 28, 2017, at 5:39 PM, William Denniss <wdenniss@google.com> wrote:

Thanks all who joined us in Chicago in person and remotely last month for the discussion on the device flow. [recording here, presentation starts at about 7min in].

The most contentious topic was addition of the user_code URI param extension (introduced in version 05, documented in=C2=A0Section 3.3).

I'd like to close out that discussion with a decision soon so we can advance to a WG last call on the draft.

To summarise my thoughts on the param:
  1. It can be can be used to improve usability =E2=80=93 QR codes and NFC can be use= d with this feature to create a more delightful user authorization experience.
  2. It may increase the potential phishing risk (which we can document), as the user has less typing. This risk assessment is likely not one-size-fits-all, it may vary widely due to different the different potential applications of this standard.
  3. The way it's worded makes it completely optional, leaving it up to the discretion of the authorization server on whether to offer the optimisation, allowing them to secure it as best they see it.
  4. I do believe it is possible to design a secure user experiance that includes this optimization.
I think on the balance, it's worthwhile feature to include, and one that benefits interop. The authorization server has complete control over whether to enable this feature =E2=80=93 as Justin pointed out in the meeting, it degrades really nicely =E2=80=93 and should they enable it, they have control over the user experiance and can add whatever phishing mitigations their use-case warrants.=C2= =A0 Rarely is there a one-size-fits-all risk profile, use-cases of this flow range widely from mass-market TV apps to internal-only device bootstrapping by employees, so I don't think we should be overly prescriptive.

Mitigating phishing is already something that is in the domain of the authorization server with OAuth generally, and I know that this is an extremely important consideration when designing user authorization flows. This spec will be no exception to that, with or without this optimization.

That's my opinion. I'm keen to continue the discussion from Chicago and reach rough consensus so we can progress forward.

Best,
William



= 

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

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


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

--
=20 =20
3D"F= Simon Moffatt
Product Management =C2=A0|=C2=A0 ForgeRock
tel +44 (0) 7903 347 240 =C2=A0|=C2=A0 e Simon.Moffatt@Forgerock.co= m
skype simon.moffatt =C2=A0|=C2=A0 web www.forgerock.com =C2=A0|=C2=A0 twitter @simonmoffatt

3D"ForgeRock

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


--94eb2c122e648c1036054f02d9c9-- --94eb2c122e648c1039054f02d9ca Content-Type: image/png; name="FR_Sig_Logo.png" Content-Disposition: inline; filename="FR_Sig_Logo.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 70f95eeb40216005_0.0.1.1 iVBORw0KGgoAAAANSUhEUgAAALkAAABGCAYAAACQaTWQAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJ bWFnZVJlYWR5ccllPAAAA2hpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tldCBiZWdp bj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1ldGEgeG1sbnM6 eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUuMy1jMDExIDY2LjE0 NTY2MSwgMjAxMi8wMi8wNi0xNDo1NjoyNyAgICAgICAgIj4gPHJkZjpSREYgeG1sbnM6cmRmPSJo dHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4gPHJkZjpEZXNjcmlw dGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wTU09Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEu MC9tbS8iIHhtbG5zOnN0UmVmPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvc1R5cGUvUmVz b3VyY2VSZWYjIiB4bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtcE1N Ok9yaWdpbmFsRG9jdW1lbnRJRD0ieG1wLmRpZDo0MTdDMzdBN0FBMjE2ODExODA4M0ZGQjNERTYw NDVFMiIgeG1wTU06RG9jdW1lbnRJRD0ieG1wLmRpZDo0RjYxRUYyOUNGOEMxMUU0OTM4QkU4RDlB Qzg0QTY2NyIgeG1wTU06SW5zdGFuY2VJRD0ieG1wLmlpZDo0RjYxRUYyOENGOEMxMUU0OTM4QkU4 RDlBQzg0QTY2NyIgeG1wOkNyZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1M2IChNYWNpbnRv c2gpIj4gPHhtcE1NOkRlcml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InhtcC5paWQ6MDcwNEQ1 QTUxRDIwNjgxMThDMTQ5QjkzQTA5OEZCQTYiIHN0UmVmOmRvY3VtZW50SUQ9InhtcC5kaWQ6NDE3 QzM3QTdBQTIxNjgxMTgwODNGRkIzREU2MDQ1RTIiLz4gPC9yZGY6RGVzY3JpcHRpb24+IDwvcmRm OlJERj4gPC94OnhtcG1ldGE+IDw/eHBhY2tldCBlbmQ9InIiPz4qUGMsAAAoB0lEQVR42tx9CZhd VZXu2ufeW3Wr6tZcRSYSwkxAJHQQfbS2jAJO8emTp5EPuhsB7RZbaRAjMisoqPDsthVQoZ1QEFEE mechhISETGSeA5lTSaWqUqnUPeutvc+09z5rn3vDM75cbn2nzjztvfba//rX2usIRIQPT7kYAAFA QPgvXEE5NzepX7h59foG+OoFK+Hzn10BPT2NwP98dRkhvHgdwDP2B+v2dvNcRF+7hnwGOl4k5wX7 QbuGH87Na6rjoncC5rrGc6ljOujfDbTe7Pv58+rr+qCuMADDfl1YHL51Hfu+jnVVnl7yLtozpY/R rxHcr6FxCyxfcwo88+olkM8PQs4bjp+8va0VXnh5Ojw/bTq0t7bSZQVdKqy0uDK1urQ2mXIA5rH0 +8s9t8O++G3YsAFHjhwp/trXzRsvhuGbCH1u/2ijwKDgfGQvmgiSZ1aaVVG8gOvLXii4oQApwQat 0fjxObygeimhFYZwR+upxngQLX+Wlk+n406huedj7qvNjZuhb7ALnp/1RSj7BcjnhtwlqysFbv3t /GKlI6BAgr1p2+G0iLQ8REWTC2+DzKNgIq8CU3WZCDYj0X/N5///9Mvb8pvS4FzrRrswhaGRIgFM BMnWmF6GBk+0G8bXCq8X3sm+TiCcYGjTYJvZYOL96HO9Sjtd41yaT6Ht74uEP3h2eLy+MHBbnoRp +rzz4I1VZ0NTcYshAEIIVsDCl3AKjVIWmOxT10GMizpat69PjQ7q63qhoX47+NTgUte3JVJwMow1 K7h7L+TIdFHCFmBMtXqh/qILaFo2FJ5IC4PRldtzx4+OF0oY/YovEQl9NEfkYVP8DPLawcaRNJ1P wv+/ad/xwb3Sz0aN5fLG4jaYPv98WLL6ZBjZvpgX6H35c2hSv1xwCKqmvXVIEjW4vRJuYfUAtSjk saZBRitZQq8XthedKzSBSPewiSYHRqODAxenMXWgmYHB88k10OhNXNAFxtP0ME1Hmz0PWI1RXlfc 0VbaOHfdpokwe/GnoKW04VjafyYd+b2ooe+VwCOnZIUJLbTtCOhQzME+va6czyJ0SOoQcLQUm9ab 1LKA69hAa7FgdJ+VYWLQOMxTbOH1U9rWbehp1xBZ2j4x+GxtLhznBceqfbfR8tE6pk96HsP425nP 77nSp/V5yz5KHZJH+HfXP5Jo3UL73qMLpS6owpYi1Ho+kT4Otb+kh7SOw+xGEQs4Y0gKl9pG17ag 8fC9h6hVIY8KAisbGFElyUN9tDZ7hrCb8ME3mQTDGPQ0IeQe0dcE1NOWISXQyTU8Bq6ohU/SNDnC +prgG8avfGbS4lObGzdsWbzqFFix9iRobtowAdG7NDzoOynjTteweiHGRYspg5ATwOi4eB5qVbtR uDR+CmlaSoyVV8GcI7iGgLUr5MjBErZL1QrTMzWTJkiasPma8WhSYoEg+Zom1YXdZGTccAaYhuVr k/6q6hrfSASZM4bjhrewWNf7o/5dnTB32WSoq+uHnOd/Q7vgqbKxQIpEQSes5fa7jkdTFbNQJNL4 qWtydYda3WEFeUVHQ8CalHFd3UUFYXZTUQGh683jErU4bAMepKlBW4unDcTKhqYNVeR6SpOjr7Mp l9D+SVGPw+P2SMPD1MaGHnhj1RmwpecQKDX0nOqjONc64aZAyNICEmtp/OsoQoOBsTV6BWFF29AU DGWOYGp7hMzGui9+Qoh9KOSoGSSWYWIWkEipCuTaTIiLTSHKMgSthoCcw8i3tLzH9hgBRZhcN1E+ fhetX5dgd5ctoF7vARLqP0keev7Sj0FjcTsQMrvK6NGCC0+g8pnqEoKo7GzoIqqUlBTkAR72OGGl qHBNBqboXDzLSta0JrdfFoTexzpbnNAEEZHzWur7OBjDNxIH1DC8mhEHn3ImCc/Q+iHXfZnkwjnv YdpG8G8qFPph3tLJ0Edwpb5u5/kCvJNTFR68/NdIcDqyCZXqIIptpHLwRG8kIuluGeEVLDRB29tp G7gi2SlSgi72qSbfG8LjbVCIHJ2kGaHC/TDIwIi0qzthLjgoktCL9n7fdH/HlKRvCH7arZ8yPo+h 616hO47MBpg4nciw/M/WpvUz1mw4AZauez+0NG1spG03CXAIiYA22vYdKpOL8rkcFBuK2RBCd0UI m2q1FCmaMosaC2jLs76tVCpBIeeBX/bd2Dqu1ySEwzA2BQdPapNKzGfiLmGyixYvFfl/MmhAHYtn xaiAReHpNKKtZdPwxsDhcRyIpzeUbyPD4Sc9QmyEDuVzg99DyMGcJZNheLgeCo1b/s0ve6NQoCEg StOKmP2YUygUwCNDfP2GjYGH0pK+xJPJxAYZEs/sMzSz1hqYVuFRQ+vZvgPWrd8A9fV1ptBathZy Fig6epwsr+5+jsnzTovajuex3dNoy6rHOGfM/Qaboa6nC67LSOVwO2gBWmYPgmkFdAYdN1mg72hI SQMjw/Ka9tKG1QuWfwRWkyZvK711kO971xnQ2K5ohBdzudyP2lpb4fmXpsFzL0+HUlMj5CRE0pxr HGUYrZt0IK8vdWoymEcyqzuDgsIcLpdpp4Bm0uio21iCEWCut+YfYJ97efctXAGmhdtUIiMckidH hxYXBsTwLfxsaVoDbmjGp8gI3mLDBLwgpMC89s2cR9XcJo/LzSvW9X2nf6AL5i79CBS8QfBE+RYf vYJeLqjH7gh15hUdbS2w4I2FJOSvEH4vqMoaxnLyZJiIbzl+SlT7y4wmExI60LKcR29Wtpp6OXpz IVLCIa/v5T1zuwuCMBGHrMZ+xwRoycqzumWzUKzYFU/XS54Dntj7PdbZky3EHCOj42srqCs56Hw6 bqKJfSMWxnwGaq83NzVuhhnzz4WNPUdAV+uqk0jAP8113ZEQkBDd3dLc/PKWLdvgkaeeg3whV9/Y 2Ci37456vpzlYMuBNXcqkUDw7OOjasgLYUUXAh8uXcnBF7vtK1An4m2EMOx37Ar3npXex9expM8L qwFHshkv07vJNQhf48LT7nvrcZtow3eDjR7jHEqeiQT88VLDtl9t3X4IvLHiTCgVt0lv580u+i2E DcM5L3dtXSEH06bPhJ29OwmmlL5JAn6LYSGiGwoEbIbgqT1XF4pW1y7SeFs7KEU/prh7O/IU9NBc UT0rtN8LOTKOAVEdVkvjKBM7uwWWhzmJdvaZ63D8u2aUmvj829QbjDB9Vp4VahAIP3VIl9XVDZCx +UnY0TcGGup3fIGu9Pe88AXbymX/utbW5tXLV66BuQsXQ1t7W4HK4hIqo0vokFEcv22XcyBMaOJd 1BsUo12FJdiG884WYMHj6hS9yGwTtcumOOgFVwEyBacJvF/2oKllj0KI5bJnQRI9MIvTpLZnEsKQ XF0AweLUfSa+xbN6eLX/EJr+VYc9HGQJlvM/a23aOG/txuNh6epToKW0Pu/7uct1rW1rMpqvqKvP 31wmA+/V12Yr7FzI5aRTqDVQzuJS1oAXDLZ12D6o+9Bdvas+uAU5oWTO1ytbVBDod4aMa5rcyedi eltYUY1Ne2DOnDYF7dvbhwDLwgrAynIMeanyRAAWhmTTjH7c02IsQP7Npr3hgRmxGO/ozeeGvi7H MS0gY3NPOQ/53O5raPUQXWvbzhfS2Ne1trQMzZn3BixdvhJaW1vGk1BelUQr42X0byKLtatEJc5z xP+DIEb1iZimKLGKZ8J3giZH4Ls7vWvUjh19wG74w2MHwLU/mAC5XBmKDWXDccNrXI/1dCbsC0dJ epkwxwzj9c6m6VPc8bajiXD31c2lDVuWrjkZlq07ScaKj0X0/t3S2jbV90KxWPzFzp39MGPWnICL BvFN1ahMYfyWgb2xSkFKc33gsg2cTh5W43N+D51FEGaP4+w59h3Fsm9jV3RIYkAVm2nBRNAVr+zB +AMH4a77xsKDT4whzT4gueYq+FATdgTrkA1FWJaGHfw81dUgjOhG9JYX6/r/o3+gA15f/HGoLwwQ NvelYDZwwqRh5m+0NJdg1py5sGnzFmhuKk2ijRcwgvARms6MzxXgjPCMGwCCaTAicHGzvEdVMJY8 corLhUlcQ/f+dhp8X/HknmZ2JzEQmRx5UgHyoQp5H0Z27obbfzkOtu0oQUfrbhJ02+g0GRfbeBRx QJeLhYkiCX2LyfE0wVX7/pm2fcCMEdc6LENBiqmNDZv8xatPg809h0Njw7aTSbOfl8Um0Pv+qrnU 9OLaN9+CGbPnQKnUJMvmhpi1AMuWAbgppb0554tt5Kc0b7AgKsWO2CN7OM0MDMmAYLIpmfEqNUwh coZWNXiNBAO6SMiXrCjBfQ+OBpEbdjiEKnGRfmxw2lo+ce+nIUxi2Hot9O9GO0ZcpxwTb6z3QlPD tvs2bz8S5i37iBRwee9vViirYepOr60v1sNrs+dCX98ANDQUzyHBP9sot5g6VNr2+KDh2SyNqICb GeMSLU0nHJSkQdGI1CgjO5TabARaQ8LMB6pNIU8KULixHLox5IgRg3DvwyNg89ZG6OwYAt/XYYmf SRvG3krGTW9EGWIYsAXpiEaarqV/I+LjtVhzG+tT3X9NUoZzl3wMdvSNhGLdTtLg4jRdUGzq0Pf9 H7S3ty5ftnIVLFi0WOUzoW03sFhSGJMcQdRsQBasIoALHVg7A9OnGgFiahSRcxCzsDQ51wPUaKwt FxLo1tyO8X7ylNbSMKzfVIT7HxpNW/ZAZ+cuyKnQbl2D+nGseBp/+8wEhkZWRq0WL54MXPbG0fSF iDGh5Z005yZpR/xna2n9K29tOgaWyyjD0pYiYO5GjTlJGXn0t76uULh+eE8ZXnl1JgwPl6FQl5MG 6hEV47sRuun/tSkBAoexn2VMVpK3rPOwil4j1SB0vj7pUWrtlzeZFPfIfMOlyyaqARhD2vzu34+B Jasb4eLProUjD98O5eHdMDQYxiYD2sBYG6ghNA4QzdjSlMNCM4ADoeynfUfS6mZaK6TiaZPre/n8 noHh4SJMn38eDJfrgGDLZb7vjbHfV6/scrl8dWdnR780NpcuXwVdHR0jfR+vMcvNjio0iuYrtPNH dNgKNiowa2SPYARbuCELHzZt16lgSAVOq2M6dEDUspAbA2FFKrbYFc2my1F9Pf3zhuGxZ7vhuWmd cO4n18KUyVKB1sPQHt80ZEJBFeG1BRNolGwTaeIAjRraGkxq46DdSvW20dq8HmYt+jS8ufFYaG9Z dwQJ+A2mjSVsB9CMYkPxpzv7diosXqyvlzE719O1mi1KJCu+Q4Yk3k67znALFQNBBKO6rSRPLOXH wH8z8A5Twszy6QJqOjDLEnLzRTFVgFpyGS5RTYxbSY3mAA4eNwA7+z340S8OgMHhz8AxR42Dnh19 DC8lIGvUbFK+wsFriSq9Kcl5eWqEu4cblLDTlkGq/D10p4J+Vz2stez7V7e1tqgIwzVvvgUjursm UcO70IUbUI/vNq1C32hIXP4TuzdNxaOIxJnj0syOurFDa5NnwGwo9DcU8H0cT+4KqxRm5izOpZyS OyRhF9BYLMOo7n5oaChAvtAEe8p9kMt56cLDbF9GKrgOTHQQbpKxIh20skW9k9uDmxvc07CpkN89 6HllyQytoa1fpgr/MZdSwkf/ty3NjY9u2LhJafGWJhWffaP5wOiAEAb0k7EPF7qoSSdITgmsK30f unsGDuJE0aYiw5B1DLaoRZ48X0n7GbHFIgMzWtpDUA+dz+VhxqxX4MAx7dDdUYTtO3rBy3kmZYnp br5iSCemoMVIms0KL1nWjSY0iWsPcjJDLVyNGFOmP6F//0Z7j9IFUM494V1bT/DkladfUKNturs7 P+37/of22hUP8H9oWuMuN738wNTU7Egeq3et9AxOOCOyjUlWwGs+uVD6paodr2hqlAB3NzY0wrIV q+H3DzykGInm5pKk3cxrCxMmCMfgaa7ytEqfTdvuDJdz0UT7c9p69K5X0T2ONN5ZwBUp2hDhltbW lsUrV62F+W8sgtY2RRle5XTmuP0KG2m6lu2edFysa2vhYD343Bd8eaEjuEs42BJRicUR1Tg89mMh R9uZsZf8vzMLGUJXRzssW7kaHvzLY1DI56FYLCrtzWWPMtKlCYvGMuw7NsZaaujdDP2XosTo+t/S 06rR8oO060HtmTYRtPqW3DnjtdlQxjL1Srl/oe3HJvafqEzJBUJ1JR3az8MMzcjL0iRc43AaqRWy 2QKmWSAXN+/CkDUp5E43vuDL34hj5lIfmAbPAd2dsHDxUnj62Zegu7MDurs6oaO9TUbvEU7PkYZE R/WKlMaPYqKZIKW1NF0DKdM13fDo979oOlm/Hv10rvwaerbeeQsWwqKlK6C11NJOW68z7IfIn4AG prDns+nAn2UKiKjEYSOf21BkHF+N34ZTZBlp49h03rVHITpKQvBWMOqjT4y4i3TpyuNldz9n/nwF V1paStA/MAClUiNMPPZYaC41KbweUYkuRkAfMe7A7N+laQoJwbu5QcKWsMtw3BO1Y6ZLbU7G5mnU 2/xkaGg3vDprDhQKeWlHXE/P1uViLlJDzJLly7NoV6fgiWx8zTMzFYklnnnBKh1QonY1ed5JYbks akxrVtNRlLba5T45wHfYy8HM1+dIWk4Ju7zd8pVr4QMnnQjjx40DyUUP9A+q1A62Vom0F+eRs5Jf 3kzrv7LpQMa59R7aPoWm30R0Gv3dQI3ov6Tt8NK0V2Hj5s3SfX807fuSafAyoR1pLfgQTU+5ytKg EbmyzDLyq3EC6fcR6GZj2Gu5P6VSi6G2+ZSx4rLIo5ePPqWC6Exiyf2kvSmFV0IUVYdecI0Vq1bD ujffgvdMmgjvnXQ8dHd3wLae7aoReFFaB6gyMWbw+zVNMprwQylNnk7JILX5H2h5UIUO+/7MAzo7 YfHSZfDM8y+BHJRM1/i2zS7x10wJxtedyoKj8HQYlDnoWMS+yEyZQw2KodUDZ1CLLDVsvN6+U+f7 NtRWF2JgDL6UQY6VjVDMKBwtB3onYfO6+jrlbPn1fffDgkVLoJOMVQllfPT3ooQMAbwsJYz84APp zr8+KuBSUxNs2roNHnvyWUV1NtTXT6bTPpF5T17Wvk1bFlQcxLAXRrzuFEL7g2XVZJsVbPYvd76d vXm2mjI8LZrKcO3b35gRkJ2xVVRh7EgNr2LS88oY3bptO9z/p7/Aw48+Cbt27VbbPM+rroWb95tH 088tmtDVC3yZpnGFXJD04clnnqPn6IHWlhZpEF/nxG3ooDNRhRjcClzumqqlR6QiBgyPmKgAYRAc kaMizahw54FFbwLUbNpmgyc3edQKlneWccJRX1kVGo2LJEFuaW6GtpZmeGXWbPj17/4AcgyldKk3 NjTE/Do35tLxk3ChrwooVS8NViT4tJuMzd6d/VBfrxIEXUj/jktJKccroyEkMi59a1WMhvMYZEfa M4aFlqGLGb5mNzKsxnkkeKZM1LomN7qrKpurEG5hRge+t6+PlsEl47sIJozs6oL+XQPwwEOPwCOP P6XCAVpJ+KWg68yK7kBi+PDNNqXocjTR9s+Uh8unN5ea4egjj4ChITXwYwlLj7pc4cH0Cv3/CRsL njX8jTWMIcPTaDpxUPvek319IUQVnk8LVqY+pbI3FNF+KuTGQFuxF9pGoxmFnsRfVOBjOUMQk4qS vLnExx1trTBt5iy494E/yzwn0CIFveynOHT70yKaEfNDmlbZRqr93Z5w+5V9/f1wwvHHwrixo2FH b+9zdNzPWRrN5U8AuNEtPA6t7mhA6GK5XH4LLdTBaAuuARpZjqUUN1/p0xQ1IOTOgbbIaMAI0iCD b11Zo7KMNm4EeBR+S3h8ZPcBsHzFKsLqD6trN5UaY48pY3Ba384RUiVPtbU9l0uFficPDQ2d30DQ 6ITjjgM5QML3y1eCCt3loJuw/Ql/poU/p3Asi5cF38tV1YOCe4wow/wIozcS1RnATCKkdwAmF6xG iZKwpykzzEq/6jZkMhgDN2RHMkC7YPHy5fDUsy8SPi9CngzVLOLFEubf0jQNdVbC8h5Gx5ORe+P2 HTuaJhx1OBxx+CHQ29u7QY7rdH4n01y9jB0XyfRkAhgsn0EDmj2nyMb5XI8gGH6cvW/6Y17VDk3d /4Vcw88pj6Owagch25FgYdAUDsaMyrTzjWhauruzE1597XWYOWsudHS0GyaBLazMlx2+ZnxeUDgH bo8mDX61LJb3TpoIdXVFIKx+Kx2y1qJS7Hf+Ie1awtKnogK3z/WerrgUJ08tqhREYTI0rhyK75DB Eg4K0focnt7NMXjWGVVn05Au5wOkP+GhOy50DCxjXCROf+q5F2Hp8hVw4JhR0NnRBu2E22Vu8FJz ExTqCxp6MGroRZruwHjkEAxKBxAdo6Zw2y51X098eUfvjnEHjRsLRx91GPT29w3Rpb4RCtiwOlaE U/DbYBu4TgMzi1YVwA9Vs6k/Vr6r/AgXIt9zcukohKj87DXyc8euIN/NObOpCot5cYx8EZbgI/LD rFJeRjquobEB+vr64NEnnoH16zeqdLRlwi3FYr2iH6UTqauzQyWh7+vrV/nThYg/Ayj5cNLSSby5 /aHZcJTQCLrXrhzZAx1tbeAPyyRy4h4U+KjRhIPnlZmZd9G8Nw0voKI3smL8iXBCo1QOcXTRnPb9 2NgbSI02EuIdkwqRH/5WPRcOUBVeNQbGcia+NgAgg4+XI/NlXMng4G546vmXYtGUCefrCac3NTbB oeMPggmkgceMHq08pr29O9WchGK3iu2GZOyolmdcj27cIZdlfM3Qnj2qtlFleRRb0EWLupgjO184 VuFzqAYmcMrBlWR/b3B1ipaEKmiimhFyNDUEE2TFDnpNj9BxV5Qxgh5NAzZLBVrDyyRXXldXgM66 Ng3hBDHSAwO7YPprs2HeG4vg0EMOguOPexccfNA4tV3Sg9J7qtsarlBc+f5ywEdDQ32YRkOLNXGO 6snQ0JqAs5GRlTS+lkErFbMiKjQS4aB/XbHtolL7ErUq5Ek3hpnuaF6QMWuMoWGAZWXnQmOcaNV4 UCTJ7IsklA2NRdLAwzB3wUJYQth94jHHwPtO/Dvo7uqA7dt7lYYO6EkBpcZGkB+0SuLZg5H9Ev9v 2LQJ1qx9K/m4lJ5ywsCtFeJ4XDCsmp5SmFAiZXcK4RZY3Q/A9UCOXsYVtQkVAuVqCJNjhbQIlWrT WhaQ7S0UFbpa2+gXjgowvhwiY2FyCpsPDe2Bl16dCUtXroLTPvh+OOzg8eEY0+CE5bR989YtUFeo i80IGUcjY91nz11A2n8ApBc0SGCE7mSZVWg/FByXWK132VIE7FAecCugzLzo6OD+wZ0RoCaFHJnu txJ36yxs1BxGGQFdro8zcQUqHEZvBlxUyUgLeRg5ootweZ8afjdm1EiQHLhsAPPmL4RFS5bCAOF7 eZz+k9pe5ldpbmqK4UpmJWd9Qc0Bi6xPUUHFOP5sjj47CZHe2CpkBEDXe2WFANeEkFfKzJSCHZpw O7tczKRz2YqzU0RnDbSt0qBSIQIlOYC6DKvWvQnr1q9XzqRdJNwqdKChgU1qFLvEU9/hgaoT67P2 DQdbKn15jRE8fYxqZlSibaxmwqIsxqzWMTlmd3luIxKrMFqq7ebsARmY3WWKKpVd2GjkAAwZ4ahC Amgq1hcN7t8QmhTzKSpn+2UEAtFRPuhusM7MtfYH3UR1SiRlrGKWMSrAmRAU4W/yLc99q8mrMJoy u9Jgu0yfPA5k+CrCNhKONZJ+qy6WRWM8RAXuPvt5SuoZhEqmL9N2yXwnu6IKjAQajBwvkCEIAtC6 l2nMZXjCssrQCp8Ir9dFqweqpDWBk+ktVtkIG9cb95UesYNAfr8IldNrDe3emdm7CK43TSkgqRXq aP/O6GYfnnJxO80m0bTiL7+5fcX+KuRRqO3MoFDFQprHExWIsR56+X6uw5Gw+/oQTS/QtIO2zKNd M2nzCirgnvD4Ax09xmdBppFAWEzHBPfA+H5LaHkRBMPZTucbokFb/ANNT9LSdpovCN5JLFLPJLcj nsJo1HZ6xteVMOnvKd89LgsMJqGcSNdAkrPxGvntWWE8szxWPfMSOv8Nmt9J553IalszAvPztC7P 26xG+AO8RtOb8rlU7EzQcDWta+dAUS91KN3zl7Qoy3ypen8B82miOoGXaDpLM0Q/CjJJKsJKmm8K BdWmgT6ongFhGa2sU04vgHdFbZ4EXKakvjc89wpafyIU+rf929djPI+gSSawHOHGjfFvnHXMY0rI 9Uy3icaTebn/iRbl9FXacJul0dqVdhDq/i6HikwENIWWZcVLQd2ZnB9/1vt31H2fw9JeZH/Susw9 fhot303L/2S9/1F0kBw4YXyWMAVdggoYrXXnMke1RwJ6VAbmnkAzKcAP0jSZgW7jaXqeNo91wINR dB3ZmK6i5bOoPJ8IYEpK415PAn8V8rEycstJ9P8RWvwZnfh5UMlKQQ5gHR9ep2SyN/A+et9nwchZ jz+lfy/LXoKE+TM07wl3nk6TVC53hEJ/xtsVxr/NGE8XyOM+txGc8yrNP+SGxagffyv9vzQOpBIV PhSZNjgn0fwBBgo8SoVzTiZHn+x71tpnUkPMcLNk0AGaudsxDA+o9IHfYP/H6f/dYORqgXFUDnNo eawTUKNRT4/Te57KwDSZm/GqVNIj9hOV+KARnJXcVo/pnBj0yobz7lY67sLwuuulYBM8kek/gOZS qC+iuVRCK6gBHLJ/anKTHpMxGl9RmgrRM7/riY0Q5fQTMJX+vcfixO+h6X4Vy4FwKG35Il373XFO RcTvkyZ6nLbPdzzPxWHXKhPXS1f6cXTO9UrjBxV7WqgpngjXLwL58SnThX4PrdwbQCepbQUJmGoE 8qNX/+02sBXulGG5MuPVwXFHkBh4JQVFeKfKjhB6bVUaMoiPeT+o5Puqp5K/88OvTiwKi+w2UgIt Wq8joeDtSisiDNP2v6P5l1QPk1TPnSBT3AkcDnswKn+Yqqe2oGtKbXt7YA9JjI+foO2fo20yOdKD yXg5LuccHA4ymA3DL9kF1/2FVE6as2xI6+EnkVAvp/l94brE5YeE8/1Gk3NZbVfRtFjhZKdjAJro dS+1DBgJKe7RjpeC+BOFqQVM0QzKr9J0gcNp8jJdc0FSYaRRhIo3uVe7z0Ql5MH6FdYlzqWzfm0l 75f3/0oMcxhIpDErS6UtEVeSkypMsTxDND1Nm/Q0dS+EndlN2nHvDxvKe+me/1Mrv10qD4x89+T3 KEnULRDYDEeH20iAUKar+2Eo0FdYz0m9ZfChXM2n8Hs68HqF96130gzoTeGmaTQ1icTzfY9qnJrh H33cL8TfUntLjX6RBl3u2F8NT70bLcYlIEBPmJnTaNKT4oxSwU/itXt4DYlfpH9btLZ0NnDRj4G3 Msd8aWyN9XxNkRYJtUZUY/eERmp0ai68jwi72IFwPRdXNZoMWsgKReUSvDOGU7YzhkfDCDOsXIOF 8LCzLAXxNZoWpI1SlCmf/9FywJ1sYO3kcZYGGlfPkxEbRzLWvcdgqdCAk0eGuLpTayCycUzRX1kb MC0FWfZKTxJMkee9RkIvG9xrtN6zfwq5Sf6fo7R5MFBgdThJQRuONbBkMswqfYzljYN1GYb6R63y RtH2cY6hWMMpWUIFUfRKXhGuTLQYh6c1mkwakrMVhSjoPQRIdmBNOA2H75h2lwsJrxTjsCZ+d6G0 8wtWQ7O8xCLKYGriYEEQBrWYeSHvjwEsSARfQo8/uLtqMSNknqLWeHC44xhaH6WV4bOG3cQ1Ro7t FLAnhCSn6cJMf1emnEnhK5Ig3xc2itMlqxJqcLn96/s1T645DRoVz8rnpg7TXxE+NfneHtZ5kVT6 RtMVKPlWlg+/JKTgWhQEEOoTgedodUYVgs+Ey2OtLABbtaqVmHIsvVM9vdMY4x0DLdbkcME3S+Yh 6q61lG2jWCFJLiCvd5XikIN3k5j6JFr/qOZAkZr24fC8knY9OkdsZ51cSVw3QQ0xIXSQFcO9TVb5 bdI/h1hVGK6IefW2lGdUqARNF6WcVeFzhoJ+X+04g0y6cEeoxeo0CZL/DoUkn8hWKwHnSGeYbnDg WAvGDDhiWS52el2DY6QhFg5Fk/ytIXSaVlMjeBbScx0evousxEO1YKUhQ50lhrd8r3UoKcXE6Byh uGKhBVqlhaYxNFizPItf0pa3a4xCO8p7gOpBUkoirJfRGrbqC+/RY3H+B1psVIWUf1AhJEBcSI1K 9mC/fGekbjZ/99N0nOJ4BUwQci65ZIUnMWInnrEax6dZly+GXLCO7YSCQmveRgzE2YlRo86dbXkh P6bdc3eIV7tp/QSafmtV8FrDw5f87gwN2wnxhNBBgngGgCv/oIP6MzcfQxse1+610DrhAvtcjQr8 MP0/TNu3JDxySQgro+1nhl5et/mQFe8jFOQ8x+JgZXkf7KRka0nILW4VU2M00xTDNE2jyt9kOuxK Q0Mkhudd8ntU2rEPpAQmKbif0+apNF0ed+0xzhSHWTUnDbXXtWF0Z9H8GqYSumnbv8Q8LKqeaq75 OrGw73F+BJYbaJxYrNIb+D1alGM9L4NgTKk+7vJwK87nIat8r6Rjz9K0aLT9YHrouyyhfEIT2GeS 9BZiJP37jSMvy/8A+ckZvgHKn/waxucC+IEagSAkNLor9RnyGvvlGUH20l+hAjv+2FdetuQTJnKb 5KE/RdOPIXBPnxhi7JJWsPKLCz9wB/DDrcoVHdzyexB8JmVi+Az/ETasP8WfRpSJ8XUHkeSlkRqc UMfK2I8TafnyiJEJodRdyluX+viXOv84mn+A5mN1IywsHwl5pBE4g6FV+1R6OBFSiAJk4v1FdL8R 4TF/pGOkSzxKAroAglyN/xyjEIGPKAMeyQgUKK/zsYC+M+pmhnIqJfe9gY49L2CCVEP8hBJYUJ5l 6YtopWPPo9I6A2Vmr4Dp4jT7eTSPoOi/0vZTFUwLAuY+SM92BW37blz/tSjkxgvb6XttC8akDaVF /hnteserLs5pgFKlIaxLRRaKWFPmlFAlDpgLFBebVEboWsbN4RFSeH4csiLR4x4fChBHxG8OPYTM QAT1+7iabEMrWb8jFLQUwW/QkkJh7s/Tu/1ZE1KpId9tOb5kI3yXtu1MBTv4SMFdiq0xbAmF47+o nis55wBauJH5ZOUXlB0j4PuxhzOp2n7tVXrUoG8Bv9Pu/h1af5p995rC5EmhFvhPoyAfYIVKazrY r7jgZHf+4RDvW8JhZvpBc7TBLJrfoCWi7IrpyOQcCUVuqGgUBYOYPxg7RaKzMQo5cjy/ifuFoSCS 8yI/gl6OBEnwbu34Y9X7J/ulcfzekIpzOJ3iZ19J26R3c7lRJwE0uTPUxGU2uZF+zSRGxrOyZBUi 2jM0zu+N/B5aL/+I/DJOLQp5NFpfunvlC0gv1itOloAPyf2yMtgQLqXlSSEbUSB56KOTV5NgPEbd 9m20r4+5hnQJT9fYmu3pz4zj9eqagIepa8hwAVnhkaMlqImrQ0eQ9PZJYRgd0ocDNF9FV5LvJz8z OGiF0RIswD+G791nD8mzepVxGERrRr+ZqucijE/HrUXl9UwZ3v8OQSBUSxg+OzKMVVkbjpwaCL/S fJYKUUBl7EtjmSCj2Eb7lymNGkCsVB1oSfV/qdLUCfX+p9L6+JDxkTSshG2zlDIKIhxB+UCECrbq ofIp0jtuZMYG0LNLf4MK5ZDe4hNom3RE3VtrQv5/BRgAcKtc5z2U87AAAAAASUVORK5CYII= --94eb2c122e648c1039054f02d9ca Content-Type: image/png; name="fr-live-2017.png" Content-Disposition: inline; filename="fr-live-2017.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 70f95eeb40216005_0.0.1.2 iVBORw0KGgoAAAANSUhEUgAAAZAAAACGCAYAAADzR9z+AAAABGdBTUEAALGPC/xhBQAAACBjSFJN AAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAACXBIWXMAAAsTAAALEwEAmpwY AAABy2lUWHRYTUw6Y29tLmFkb2JlLnhtcAAAAAAAPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpu czptZXRhLyIgeDp4bXB0az0iWE1QIENvcmUgNS40LjAiPgogICA8cmRmOlJERiB4bWxuczpyZGY9 Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPgogICAgICA8cmRm OkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczp0aWZmPSJodHRwOi8v bnMuYWRvYmUuY29tL3RpZmYvMS4wLyIKICAgICAgICAgICAgeG1sbnM6eG1wPSJodHRwOi8vbnMu YWRvYmUuY29tL3hhcC8xLjAvIj4KICAgICAgICAgPHRpZmY6T3JpZW50YXRpb24+MTwvdGlmZjpP cmllbnRhdGlvbj4KICAgICAgICAgPHhtcDpDcmVhdG9yVG9vbD5BZG9iZSBJbWFnZVJlYWR5PC94 bXA6Q3JlYXRvclRvb2w+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICA8L3JkZjpSREY+Cjwv eDp4bXBtZXRhPgqyI37xAABAAElEQVR4Aey9B2Bk5Xku/EzTzEgzo977antvbGPZBkvvYDBuuJfE N/nxHyex48QtiePfSRz/jq9rANvEBVwwGFhY2rLL9t6reu/SSJoZacp9nm90xLDWGrjGDnH07o7m zDlfP+e8/X0/G4AEP1MwtQJTKzC1AlMrMLUCb2gFnKmlXTY3HDYnKcoUTUldl6njqRX4Y12BsXgY cf4T2BwOpCXcgN2G0Yw0uIZHoUtj/jQ4wlE4R2MGM+i3LZaAa4TXYUM0zYFohgvOEMuExhBzJX+b MmzDlkgg6nUhxnLO4TE4orGJMvaxOJwjY2yFXdnYVrpLTcI1xHOsF3faEXU7YI/G4WD/NqKmuIPl vMRTDjvrRmEfi5k6CdaPs++Y28452GFjHY3JHosjoQ4IGkPMk0R7GovaNX2zzTFfGtnpBNKCmhf7 Yd9aixj7T5j2YnBEYqaOdV3tJVwsR9B8NWYb56Rjgfq2QP3obFxtqRw/BjQnrZnXwUZYanysGr8j Emd/nN84aP4xrQnXW+XMenL+mvsY105Vdd/0W2DWi3Mw91D3h2soMG1wDTW/BD8OtuHivONOB9fB Zc6Z+xkeM+NVfY3NHgwhFg2ZNvRHvZhZiHDEEtGJC1MHUyswtQL/M1bAJjRA5JBIvILs3ujMJxCJ cOnFzaTz3MgbbfH3UF504/WiuIvmQdSOV9A4fxB/Y4yfcZiYv3XiUt9Wu/rW56LxWJdfVf11N/6q Wm/8x+vsx+ZMQyKaJLKmisuWhrHEKG6c/nbkpucjGo/yedKlKZhagakV+ONcAXLriRgOte3BqZ5D ZoqFq9fhyqF5gN+JXTdVYvHLbUhrH8XOWysxo7YfZS90wzYUx8mPVhObJjD3O/WI5znQN92HrddW YOXJblT/ZxvCM93Yf0slMsjhz3+yGe4jYXS8uwBPrijG1Wyz5MUeBKu92H17JfyUIBb9vBFpQs+1 cZz9UBkaS31Y83gDfA0hw5WfuKEULnLyM55ug4vcfawngca7irBzbi6uONSF0pe7YSc3nyCRCs7w 4sLqAjSVZsAVjmHZng4UHOlHIo3cc2MMQ4vTcega9hFIw5W72pB/oB92EpZoRwJH/2waBilRrPxZ A9JbIxjLd1IysOHstaU4WOJHKedTc7IX5Xt74OyIYrTQheZVuTg3LwdDaXa4R+PwxhMobBlCRmcE TkoQ+XVBuMT1k6g6wnFEYzYM5brh7RqFm3OP55M0jXA+mwqwc0GeBAL4+HFTIph2uh/lu7rhGowh nm03UoVjIIaOZVnYsbYExZQOlv6qAd6OUYQDThy4tQLFvSFMu78F0RpSOI7FHoojVO7BnqvLsXRH GzJPDRlprG9RAKe4fjaPHR2ZbsxvC2L2P9Sh95Zs7GXbYUpDK/Z3oOgXXRhemo69N1YgjQuVt+Uo dj/zPdjd6YhHRmBkOUkfIiB5GYUo9JeQgEiknCIgf5yIY2pW/9NXQCoHvd8iIP7ewMRyeLKzURwr RnB6JnxlZSi1EwH54ygoIQE570QWVTyRQidc1TWoONuPwsIo2ASCq8pRVJqHaWfsKPDZcYYEZ3hJ AarO9qGIBUbemYG+TWUkTmOY1z4MR046ukk8XDVZWPlME/K9xYYwNf1JAYZYb9OhDpR25CBSmYZz N5SgjMSqam8XvK5ihMvTUPeRYtTNyMa6piAWtIXgdqVheJoHbctz0VqTiSEixBm9Ycw+24n8tgDs Hh9GiWAHNgXQsLIQXqqQbjnXhwpeS7N5EclwovG+YtQuLcS6s72o6hjGwAY/mq4oQl+Bl/jdhk1d I6g+04WsUx7EfWXovyKAjkW56CjKQIDjm0PEXUwi6+sKw9tDFV+I6iQicFfIC1t/HKO5TkTLnBit dCNeSOTLVfe0jcBznuqgTCD7JFCS5yFx8aAnz4s6fnqmUYV1WQjTX+5A7m4SwUwSkSIbAsMuRNIK cHRGACFbHip+1AQbRRd3tw8tNaXIXu42xFPEz+4l0Yo7UF9cidBVhZjeXA+HKwHfqBdNM6sRyqKq kmqrLEc/iorGkBFKR1tBOS4UkwD3B3jvPYg6XbhQWIFoFue6r9s8LzYXCVSEKjT9smweIhzR2BjG pgiIWaSpP1Mr8Me6AtIwxIjcRUQsSMRiGKM9onGeDwM2HlOXHpzvg7tvGO4zAxiLRjE4zYtofwh5 ezsQGx3FwCI/9tT4sXpbA/K+3oL6/6cEW+ZlIkIVx9WnOtA7z40H76rGku4RLP3JeTiOhdHwwRL8 mnXe/mI9crd2UnJIoO22fByanYk1T1xA/kNd6LslC8c3FqOscQBlv+6EYySOnhUB7LitCn3U9a/e 34LKrR1wNY+i5do8HLiiBO05bjhJHWfV92LRw5RgtpMQXBdA7U3F6MxPx+ksD1bVD2DZMy0IbBnC 6BISI9Y9vTgfQ2T9b3r6Aop+3onmW/Lw4roy9HocWEwiNf9AF/J/0oPRuWloWZWNpjnZOFbiwyDt FqvaScR+2Qj/E0MIb/DQduTEMHlvr4241OdA0+IsDFX70Evi2+t0ooX2hZBsHewvcziKyj7aoGjT KAyGUXSiHzP+/wZU1zhRvikXx0lMt5WQmFxfgkVlaSjf0QU3pY20gTDm338GsXur8fjsLDivGkLV L9qR92wbRgcjGMyzI2vnEGKUDpFOVqGNwkFDH7YsLUDWhkyUbmU758dQ2DGAI/5s5A+FETjahUge bSkkhGlDIwiNusx3ND6KGCUgX0cQbbSD9BZId0eaMS5fGAKSNIUkuRI9WOYzJYFY79XU99QK/NGt gCQQ/bPefU0wPRLF0OwMXCjNxKILfbCPJrD38lJMP98PG5G8TSqiigwUEkml1RNB5rhwakMpqokE y3b3InJFOk4tK8TinjCqDnUj/XQIh99ZjXKqdhZvbYW3fhT912Rh/7Ii3HqoE6VPkZuN2NBzTQ6O 8tzaF5qR/VAfWv5XKQ4tL8SMM30of7ILNqqf+ucHsPO2agRoxF732Hn4T1KSoTqr68pc7KF0EyRy K+uPIEICMlPSyvYIpYoynFySjx5KJKOc6pVHujHrwUbYWajz3nzUrsjH/vIApgUjuOqhC/CcDqP+ Q+V4YWEByqiuWkcVV9Fz3XAfH0P7vbk4uLEUnQE3emk0X9RJieREL/J39cLmtqH+M+U4NScXozS4 R0VAOOcYJZBaOiNkcJzVoVFUE/HPaRgwhvyhbKqxKJE5WW6IhO9gWSZiFVlYMjcH8x5tRNXXWpF7 ZRAlJB5nOMbHV5Vg3uwczDrRg+LdPfDWRjB3SwsG7vZg/5oSqvYSKHuyEyXHBzBS4MaZD1QYlVfp oR4ESLzzW4ZRMydKolSIrNphBLh+RUf6cLwmGxVNQyh6sRfxHCfcA3EU1lEFl+9DVkcIJEGIUbxx cF2jdFoY4XwElpF+nICYc6/8Scq4r/yeOppagTeyAuPcSdI9441UnCr7X7kC8oiKZjoRIXfsaw/B ezaCKurz3dThO5uiiCzzoKXIh7mUPpxtMbTcUoAwPZ5WPVQLd9Momu4sxBCRzNqfnoeT6q8976pG O5H32hebkbt3AJFpbhy6thyzmgdQ80AzRqspAVxdhOb8DCw40onMxwdw+vOV2LqoANfta0f1z1rp GQb0z/Zh1w2VHEsQMx5uNvYQGaB7FwZwaFMpBkg8atqHsJC2lIE5fpxeXwzPynycKfaT+NgRpopp DfX5M7/YhMHb/KhdW4hj1ZnopL1jPSWcWY8203aSgT1vn4ZWSgpLLwxg5kttCLw8hNB8qsY+noeD q4sQoeRQ0h/GEiHjJ1oxPCcDp99eQRsCy5AIyKmqksQzl8Qlr2PEEIiVfgfcrWGkHxyBq5u2ZRKV OCWE3jk++Nt4fm+Ytng7Zl+TgVN3VWC/VHD3TkfBbWH4mkdQ9nwnKtK7EKpKx4Vp2XhyNQnJ9Cws eL4V+U/1YXFuM567qQo7Scgvo8RU9SzvTZCSYqEXOyoz8Taq8gJ1JCDP92Ix57b9skJEsylFkDnw DowhQFtLbUUAJSsykXN0gJSBajdKRmm038jOlXAmX2ZL4ohzPQ2Mv+OTE5D/yqf4j7hvG33qyMdJ Z/jWBbEcFryi3Uh6jOihkfLWGr/K6ljnBPqtY31U1nIpsY556jfAKpvatuql/lYla1ypY/qNxqZO /E4rEE0gRhXMKJFEnESElm2M0r01Qa470Qucp0rJzWc4sCuI0BI3mqsCWPByOzw0CI9mOdFVHUAd XWQHZvqQ0RJCQ44XZZRO8rb3IU4p4uidlQgMRDCLOvsE9fPnrytBW146Vj9aB9/WYTR+vBjPk/u/ YXcbKqmSsXspncyjiowG+pl1/aj5dhPiVURZQ0DP4gAObKYxPNeLpbS1zH2sGb4zsic4cJYcubvQ YYzXfiLQctpdqp7pQN2nynB0YR4G6L46q3MYa2sHUUgJouGaIjw/Pw/zqL656ZHzCJwZhrMuis63 5eKIVGOcv5fS2cYn65F9eBBjRNQ9a3Kwe3kRWjPTkEmpqJT9lLUNo+LlTqRfCMNBtY+DDge2PhLl HAdtPrm4sCAXLpYdod2hL9uDdLrVlpFYeeQiTYN6lFg6g+9DlCqtgyUBxCmR5C+i3ehwJ8r/tQ15 S3tQcUUedtHI3Usnhyu4poW/7MHqIi92kjAc4CdAolPweC+qZ3djd1kAA9No/N9C54cM3k4ShjgJ glRrCd5Xd88oClpH8PKMLMxYnIO8HXI2AMJ5lNh4Xe+x7pPmUkCieG4eX8xAUoVlrP182KYIyO/0 xr12ZRm3RDjop4DoKF9Muv45pKh9KwKHZesmhhZS54OT8GvwyYHaBnmSXAsCNOTxGp9283IwcChZ jkXtfFlkuEt4qByhmsBGsVpt6NtG0djMerw9/dBhIosVVXaYZWUkpDrA9BVigfHf4oT0IqqGKW+1 kRza1N83aQVGSfEHiNhcvKeSQGI0mA+lpyFIhBf991nGW2fV1iY4Oil93FaATBKDnH3kWomUpPpq p43h7r2tRIYxBIu9pD+MqYhTlRNwkFiUIkTEeNkjDfTsiqLrhhwcn5aFq56oh+8wde6Ubs7Ny8VV NKBX/rQNNj+Jx4IAnrm5CjNo1J72g2bEpznNM9Z9WSZ2kKjIFrKgfhCzt7bA00sixvG2zslCBseT oNS0+DA9tJ7rgmsgilP3VmLvrGyk87FaerIHs39Iz69TUZz9TAVeovdTBdVJS+jRlHWEthF6VzW8 twjHaXBvp3RTTWliAT2YCh7owdB1GdhHO8xZGplz2McVUik1DiJwIoj056jjK7EjVuzA4PQMDNMo HiXCbavy41QxDfkkPNms42dfUgFFKK2dmpODTs5D0gv/YjqN9ct/VEsvtQxsp+dUQ5YbDbTHXJXu RM1DLSh/vAOe4Bj2XFmGl6+uwBV8t6q/3AjHfTE8vaEcrUtykLtnAAF6Wy1dNcxx+lA5x4vMg0OG KYhR/dZLop3r7qOhP248wQKUNjJ4v8UwjFHK6i4jteEzYNMrp/easSjpjO9p45jzx2NeOFwDUwRk fCHezC8RDLsINRc8GmJQ1gAfqDM25M4YgX9aAsN9HnpNWLfgzez5d2hLDws5mvZr8xHhg+4iEsij PjVtiFwLH5rOtTl0FXQh92wQforE4WI3OtZlwkm1Rz5FX1ffGHpWZaJ5djaGaSiUi2LZ2QEUvtxL 9UA6ejdSnSDETxHeADlcHeWdoGqjyI2+onTknR+E7+wIutjXCFUC2eeDyDwzRM+fNHSuyzKumkX7 emGnO6QecNNAsrWpv6+5ApJ+Lwad4cdQcnKevO+dlBpqqKf3nx1GnMTfySC2Ma51Mb2WZjaOwFcb QnghjakkFtP2dRG7JOjF5MDJKwpRQjVS2b+3YHReGp6+by7cREyZtC/s+1AN+hmkuOGRWuruw+hf 48fOK8tRQ9fRLCK7KJmOCzcWUe1DQvHTFthy+c7QQH1kU4nhcGfS6I0sehT1xTBYnY5dV5UZxLbp pWaU7OiBg8Z/kNtvvaEA+yhhCBsvpTfVtO83kwmh5PPeahyamY1C2jWW085SsKePBIZew58oxsHF efDyGV5IFZf/HOccsKGbUs+uNcUYITKdf6Ef8x9tQsaREAZu9+PolaWo57NaNDSKZdtbUbCtF2kn aNu5MxP1f1lCu1EcvXRDbqzwo5cEomhwFBWtQWw618/gyCgy6TXmHOQ7RUlJCDxGaa+vymeYNgVA ZteSEDXRk6s+jBW5LvSQ+PT63Ni+MB++q0IoojRR+IMuLOGaP7+xHPsohS2i2jG9NYRKOjecpGqu ZBW9p35Cd+MVvTi+vgwdS7Ph30WxjcRc7tCDtL/EyZzZKFk4qcJKcL0cXBtDLMJUYfGpYMhm8tlg nIpctb21I7iZkmF7ZAidvKKgTikDJicgqjsFb2gFUiWNWJSc3ElyIt1xBJbFMWtdJ1Z8if7vFQ34 2b+vQV9DOjy5coF8iyy0uAw+zEOlfDnXlWKYhkCEYrhpYBTePf2IUh1wehndBvni3DbShKyXBxGi /vnptaUoptfOVRTrQwv8ePr6KhIh+sMTcYi7usCX6CqK5xGqDLZQrUAPT6PV0sKKXg0Sd91G9Uf/ oiw8OacAt6ER6fScOb88H3toOFxT3IeVJ84jnJ2Gbewrky/Adcdp0A1SmtGT+5sYUU1PwSQrYJcx wSAFXaREN/GPN4VraSf+CFH6aKTefC29jpz9ZH7yGD2e7qYjjx0l+wfhoA4/6neh7vYyDJCLTXuq E86IHU3XFcLhcGI+bRCOUnLcm4rZhwMbf14HRzCGc/fOwJIT3cjZOoLg5kzsuX2acX1d8GQbEmQU Tr2tHB30krriB+fgpLttfMyGpltL0UhD7rXPNiLzAiOrfU4Mzk/HPkokbhK0Vb+qR852GqTL6S5L d9LeDdnYv7ECWZSMl29rQdHzPUiQ8ThzezmOzsmDj8/O/ON9KH2snwTQizNXl+LEzCy4yNBsoE2n 4mmWp6Rl74lhgC7Cgz4PVpBoznmE0g3Pdd1RgN0kesOcf4BEYuGRXpQ91otYpQst9xVi7+piDJBx srM9KRgyqZ5aRyN7KT2nPHUR2kvoljuX9g2Pi0RiyBi9EyQYMk4XnR9O3hq+FDo3RnuMYyiGyie7 Ma2jE4MrMuC8k3aOq6uxkPEoVS91INA1Bh/nPZKbjhevmYZ0vmdSDNjcTpzZVE5DeYRMHI35vC+h DDKsmRx3f5QxJlS/lWcike+G+wK96SjNDHjd6JqXh6Jd/Ujj+5hOZ4SxHEoh5PgUUa9oe08XVY8/ bea82rCHd1fZAy5NQPRivkVwG0fylgY7nxYbuelomFxT0IGhU/TTLgxhybuHMWNhC2YtPIui8nqk Zfbj7L71qN2RA08R6TvX1wT+vwXW2eBhPigDNLzJyJdFPe0gCUGYD1mCz7ZARrVCcmp6QaSyUBqG HHIvXp5PUIweJPFppyh+ZT310T+op+tkCZ6gZ0370lzMeKgRdw5dQJxBS/uvKTftLX+6yUgS0jf3 09URbMtB7kh4zsU2S/lCdNEHP0hDpURov/pS32awpompP29gBUbGho3brh43LaEISJyR56MxYqHx ZU2EQkSgPRgIDyIYG8SIh5LjGNUzTWMYtAVhT4uhaTWJeyFQ1t1rzo1FI2jOykX2iSZEOnowSM+s +uwxVO+thZMG7xOfqUI02If03fVUj4VQN50cdXgA60kAYs8H0fShAjzN9q49WIexc3QlzXUglJ+G o3lx1BxvhPe5egS95IjDoAdRNi5Eh3Dt041wvdiHvgoSj5ERpvBw4PDcfAwOkOHY0w4/CdswuZWe aj+O5cZIALqR2xWC/6VGBDMiuLDYj70FVNv09aCSNoicnzQhmEv1Mt/hrpWZOBegi2tdKwqfbECs aRj1q7JwdJEXwxy3g95oJfWUnOgB1Uc6Wb+SRvu5RNDD/cimhOQbHEN6XwSlDALMOhhk/IkNdZvz cHZBNt2CKSlEnche4L40etUN4vtUeprEjswbplMKPBxEZcEoGqnK2lXpQOvVmQhQkgHHj6ANLuIf IfRCSi9jdOttIoGtyQwhRKks0uuDs7kTQ4MDiHeG4erKRJBxMO0e2qZcg4jVU7hr8SJM1934GJna bAfyyaQV0gHBMqDbpLpmd3ILTgyOGyMNAruUBMI5TMFrrADXVHaNUI8DkVMJ+JczUnZNF5b+bQcN WPW8AXvhzmEbSndAJi9MI+Tj9y/FWJiBWETEo702ePkQx+Xz919NRMRpDFG1VpmOAXIbM1uHMUbk 3UOOtJAvooiKvDAmBCZhIIJyF40fmuucJsIMSnKcjaLkFF0wK8nh0XDn7h1D3n6qKqijtl1jqiLn XBDOTnql0DZiDLY8Lb5YoHbV1iC5qY5FVD3QbdH0RdXgFLzxFZBbfutgIx47/yMUeyvoXvpK/oyB 0T7eWK49lz64dRvizx/BtjIvjnSHMHjMg3C9EwWn+vFr3psQ3UMHdlFt+UwYjbR/dLeHqWpk8Nv9 aQxIjOAAVTQjY24Mf9eF0nOdOBjwo/9HtKlQxbSVxt1R5m/q2eJD9reC2DYcQiSQjuCWNHi22nDo wiDLMwCvJY4B2k/CX3chTKmlkUGCytU0kktbzI/TkdUwiN39VGtmU+1zhKpiSgODRR6Evu8hUh3C 8a5e7M3Khq2VLr5RP+zHWIYR6aN1A1S9sB16hfU9ydiWR6MIUw2TaOjHaS+DAzvoosoI/CF7JnCA xuVjfXiJeUZG/HwPTjPY8nSCtoeIUTsl2tpRhwC6ymjX2E7p4KmIUel4OiKIDjWDaB9N8CHsZ7Ch i+M84AF2krAwd9gAVXNNbimJLgF6xDnfI/wKNAfh7Wd+KqrSnPePYugJLx0anNjnZ3ssk/Ykqao8 pXh/HZzjUHMv+qpzMcbfW7oZX0LVc3iPG8+yTCZjPWx7yOjVe2kgt+NRrlt27whij9sR2sdI9bEB zM5/JzzufHptDfFaxNgz7T1xdK7IxhBV1tOe47MiY42B5PeUCmt8Od7olzjlKEXE0oVBXPb/1mPe ZWeRX3wBaZ4g2XW2NsZkbyFSbCans6cN4tCu23Di/hxkruGNKxxG5rJRnHkhF94c6kMnMPMbHcWb U15SxRgfzH56tKSTuBWcH8AA0y100VAYpweJjWqBS4Gu2Cg7Z5NTK6VeuLYwA7EvzcLMXR245Run OHeuUxEJB7mYODlFU551dBzLou6VOleTVM4iotJt8Vg+/j6Oq50BW/7sIDxUQejSFLyxFZDlQ5km sr25Rm/YNtw4eQO8MWPMBdIf50NdB6PnRnOyqHTeBnjg4EfkR0hSH5Ax0oeoJQltya8mMarkejGY 5KHYqjm2nUiW7RMOHWRFXheQ+Z84JvY1rESbzqkzPTStPMeP6Vd1+0zvPCBwnHZ+1NQgc0Gif1xs Pm1oo1G1dKgtfTgkfSh3GWgVBiQeNn1wkI4Os0zJ+esaX2dhc1VVMUGj+hjjL3L2DvarIeqjNgco LRmI0+YQ1CfJpUvdQyYeukz0b/hK8ZZq92LQdAVmPjqgvcZwVBwb+BFzJdBpC9RWs8ZLQimgbJKE 8QNaq5JQm/xSXTUncDQk5xwr5BvG/wlqCkR8tHD2jhg652ehhYxC5TM0vFuDS1a9hA1k/OLU1+Qr IAP4GIlDRnYYH/rsL1FQc+6VBz3GNAW0H9htydtrdw+iq3EaHv/GLARW88butOE9Tx1BaeVJfGnX vfTMcjG1ANVA8ckepcn7fzPPJvicyCgdLvOgg0FC+TT6FR4bQCPtEP30ABllcFFaG71GLtGpHqh4 uh2B3YO4IrcF++mnfpZGxI7rPViaT93ylo6kl5awPwnCxCx5LO4p2TDPWh3oASZ3JSmtsHEIjdMD qCRH7KFaK0zubQre2ApIVSWJI4sEZGXJBuxpfZGpPHx0fBM641pTjTVhXifnaqPOXKAssjFym/lF BQj4fAZx9PSSw+2nDSqNGFzqRt4TqW9jbCObaVBy+YmLQ+U5615LsrFRZTIWjqCluRUxqlfYTTJj LQ+Ky+ga7CFKJYOQ4DOhMpEo0SHvtV3cdSyKjAwfCgrz2S4fVjY/kcWW4xyj2mVgcBCDoeEkcqO7 rYsR36XlZaZfjS84RMNvO5G9nkH2WVJeyj7dGKH6q721XYuQVClrraie1Q8xVXGOIzc7F1l5OWZe vMJhkiNnW6EI+7OTIeI4y4uKkJZGSYnX7Kzb19uHnl4a90m49VrHKJUX5tOFl9JUUzMpDiWywmLO 2+1GN9d0ZJht0clAmQDcXi+K8vPh0FxT3xe2O8a1GAgGMcj5aK30MmlMZWzL9M97Ytae51RXYKO0 0dvD+6bxMJdVjL9NPd47o45muzYXKeKoiC5b07ypvh6kK2+chnq1YuOahDgH2cRs9VrEVyD5tLzy e+rodayAnRz30E7g9h+eQUHlOUoaftYSwVASyhHznJtmlBqbL+/u59eic0cG3DV0IfxID+Ysfg6e zDFs+mA9fvmns5Czni+rxRK9jv7f1CJ6gIIJjC73oIsqhlzaHkarPDSOxhBKo08/8/YUNKdwe3pi U8D85FMWp6tm/qM9WNsSxlkaUevK/NhGw+I6Ioyqx9uRoE//pSH5MpjrLCaV2QhVacUMYhtk5HML VQUhvlBOIaff1sylO/gffUUEwkW3wPLMakNAIvEQz6QQDmt1uL4JIW+COOaMjAx0tbdjgnvlORGK vr6kvCHkIo7VnCOCEpJ6LbBR2pbXjxBdnPe5uYnixkUgZDjKNClq30uEOjQcxBD1+78NcnJy0Etk bNWtq6t9VXEfieAQEa8abWpseNU1qfgM4dPZ5PQ1LWRlZaGHdgZ9LgYPiV44TCmEBKup4dXtqazq 9pPYqr9cfybaWyg+pUBH6yu/rbFrriESiAZ+fhtkZmZiYGCAuCa5lpP1f3H9ifs2jv+1trrHNlJ4 x9grsoyIdpCMYy/f/WF+i+Vz0q4TLKBTEGN9bNQYpL6DUwTk4pV+jd8ymo90OjHz7X1YseHn5gGR cGqzSYgl6M4QyUl1ZUsbRsvZJXj+uxXwL6O7Y1Mcm99+DJ4sPqUsvu66Z3DoNubpueBHmp/62P8C VZasGLJB9BXQM4zMSTvtHsdvnIYccijinobL02F7mW6PIjSamzgbEQM9R0I4PLRRgum+LAtnmTZi JrOjLvv388h4fyUOzMlFA4OUinJ64OFDmPrgaaleATZiAYUMEZA2+r2nM09TCYO9jtJX3s2+THSs VW7q+3WvAO8cpQQGg/mKUe6bhqahWsMdX2r7BjuJtRDuIDn7f/mXf8HGjRsNsnr44YfxpS99iUn3 6BxBwiKwjj/1qU/h7rvvNkjVQmy6LmLhYuK9lpYWfPCDH0RXV5dp2yBzXv/Rj36EWbNmkSmPIRKJ 4JOf/CR2795tiJeDXLnGcO+99+IjH/mIaUflDAFiXV1Xu1//+tfx/PPPT4xlxYoVZtzi8NX3li1b oPGlp6ebdr/3ve+huroaR48exbve9S7TnkV4NGZBQUEBOjs78Xd/93e47bbbzLzUlsbzb//2b3js scdMexqP1qW8vNyMX4Tll7/8Jb7whS8w2WQhJSS6t9Mx4R/+4R9w7bXXGoKo8ateE4nnn/7pn6K+ vh5lTF7ZTOnklltuwZ//+Z8jEAggytxj1lydyqPFuf7gBz/AL37xiwkClZeXh/vvv9/UF9FNBdXV Gmh8//RP/zSxPq8qw1dPmYxp0uE+KVRddQNty+gUQaN83lESwDI7/J0hBCpZgMb9Cff58Vd2cgLC cpd+2VO7/x92bBaNomRtHFd/5TgycolAmdXSZpM6gEFwpO6yZ0glZbOTw6NUsf2pJRhu88BBW9rS e9owe8FzvBEq60FmYQc2v+s0vn3HZcjbwJdcLMEfEjgf0b04gwN7mQWUQ0Zl7QBWXAiiZ4Yfu2cx HoO2kDiphFMqDXFqFG8ddXxQ15AGUhx2iKAw6G+4gIY4BoZlMU9S2XdaUUY3x4MzckydGO0dtr7x h1vP1m8AT/K/ZZI3ajH+1uY3RfSfP8D8QNIbi7BMwf/dChhk4vRgXuGScQJCF91L7P8jAiJEKGS5 YMECLFmyxHR65AiNAQQRFwskpQhEBBYtWmSd/o3vaiJsIXCB3+830sDmzZtxxx13GKnBqrBhwwZD QFRWhEhjqKysxOrV1P9OApdddpkhcELqn/vc50wJIdW1a9dOlBaRe/DBB3HmzBmUlJRg5cqVBrmL IFig41QEbM1rzpw5WLx4sVXMfIvwiIBIBfbud78bV1111cTcVOD06dOmnIjQsWPH8J3vfAfve9/7 ICKQClrbZ555BnfeeachZrpWWlqKyy+//FVrYtVZvnw5tD7z5883BEr3Qeuk+aivS8GJEzQ8EVLv 26vL8r3iCyZV9vDcdJwr9SOXBMTRGzWeV3mnB+G+rABjRXRy6CKSSGPtcUmNPOcUvN4VkPQRrHdg +cc7sXDF00kZ0JjOuIxUsNqcTL9s7BlUXbnGcPrIOmz/dhkypstbZBSbbjsIB61oibgeXIq/vBdL 1zyGRR/uxcApJxxpf2AEKYJIriKa7TSBfOJEKg/3YNo3memU+x5I2ugKUFRnBs4cukF2MT6kkSms a+8rRz33XOiVlEAk7zkTgZeBSC662nZS3XTuk1VoZC6ibpbPpOeJp40eHfRvF2g3OX0mgFOWzUOc jb5FhJVmQb/jDGzL3DaIKqaJkHeYOZ9SdaKNqYPXXAGpsez8VxqoFK+DUaqx7ApeugRYnK+kAgus Y9kBLLi4nK4JsZ4/fx7nzp3D2bNnDYd9/PjxVyFo1RfBsaQVq52bbrrJNC3O2TonLt7qW2qhbdu2 mY/UOAKpdN7xjneYY/3RGEJ0SRaojXzaFG644QbzW8TRumZ9W+VMgfE/1hytfiUx6COQOsgCSTtC 4romiUFg1RHxeM973oN77rnHEA/NQ5LSj3/8Y9TV1ZmyM2bMwF/8xV+YY/1RG1o/gVSFL730kvmk zvWjH/2oWTtJcSJ81jzUvqQarbnWX9+NjY1oGFexWeVM4+N/DLOmB4LaPVcX43yoplIutF665Icr yVQy5kqSSV5LMvV8vJQqAvGC4+/hq0liastTx5OsABFcM3Pi3HYE8s4z0oc9+aAO95XBmcbUAF4m gHOGmVYZ2PrwYur+XYwNAW76XD1q5u/hE0KfcRuJByER88CdFcbmu46idttaxMbIqfOOSqL8Q4EC hYYZzEWTB3JoQPfRfW9sAbcw7R7DtHZ65dCVNsbUDuVHerCg3I8LTBy3hxGwfnpm1ZCoVB2jca7Y hqyjg1hd1Y9z9Jo6dEUp0tnuYuUgYrSyg04HUoFJ6ap8PAaEg/QQkpba6XTgYXoHxXvYyAk5GAWf yQCnOPtw142ZfEFtTKnhon0mqbhlvT/gGpnx/jf/Y6mx/B6mTC++CjtbnmXgmYfG9CSyutT0hOAt EPK9FFjX9F1PlYzUTuLoLUIge0FHR9LvR6onwZVXXmkQoJC11DxC9BYnLURqtakxWONQGxs2bDD1 P/vZz+Jv/uZvTBuyOdx+++1GvaP2rboiIPp9880341//9V9NWeua9W0au8Qfq1+VtYiKNUZVsYiJ +rCuW3V0fdOmTROc/969e82cdV6qwL/8y7804xQRqqmpwYULF8xvq76Iwfr161XcqKCk2pJkKAlr 7ty5kESofq3yImJSlf385z837YmgaNyt4/aWtrY209akf4iSEtREuLmRVgHT+Hf5yQTzdtubGFi5 OQNHGHQ5k04t9t18iXnJcgF7QwTErrDJV54ncotJjtEE0/GZMNwj4xqEAOWpNMHg8Lcpy2+B2pEb rCDO8Uj3/6ryumDqsJ3xdvUcJ6hKUR8Cta1+BZbqyEIq1nj0W1GtSregYUu9pHrqy0LSr9fu4HAn 0LONgXJfbMCMedtJCLSKYe4PTPWUN4zWBnpCsEzlfBrHiOcOvnwjjvxvRsCuAgpnBrHu+q0ch+Yq Q7tGLSApZ9nZNKqXr1qCupczkV5E1ZdiQ/4QIG6fuafSGWV6xS/qtEzcRIaImyonL3dUW/VYg9l7 2s2snR4+WGsGmaNnZgZzVtGYxgjjDKaFzmDahRhdfdNYb+GP61E1y4cofcbtzAjqZz4ebzf92BWC zvtsJ2G47NEGMzMdG0MqA8fKX+jAPdzlTT7vdmYqnf1sK2ro+57RQ2J2WRrTVXTjaorR4pbsw1wf hdwmb/0fYpX+aPqQFOK0MUYjswJokRTC2AD+0/k3E4T89+/fb5oUAbE4cp2QGsfi1IU0BUKcUgtJ nSWELLXQD3/4Q1RXV5vrk/0R0nzqqafwV3/1V4YoqN3c3FxT1EKo+mEdi9OXncIiYpO1+dvOqR2N c9q0aYb7l/pJEkZFBdeSMExPKktFl9qOpCMLLFXS7NmzjQpM0olUaprnwoULTfvWeK06ui4p46// +q+NLWbmzJkTkpDKWFKaVV6EuLu725SxnB10TYTGkqCssq98830iLoh57Ug/G0bhUARHCnwYYwaI CCPta5fkMbMEnxTh6iTam6j6ugmIEO5ID7nRkWRnUp96iOxcTB8ZbKC408TAlhzudDWDEcVE7JEh bs4+QF0/dWWODHKSOXQbE+Fg9XAfA3ZOSKBmSuG5vBZgoA/Lj/YnEY0Iguq4/PQO4jkXd0WLM6G/ k5nQnNxhSzA2YsfQIVJ9HnunM9lXAWfHtoWkh9udGDlPrx2OI2OBPJz4knC8KjMWsjM6k8FxIob8 71W913h/RHTUX8EVw9h0y26mC2AVqm5iMQYldeQjr6SJiPNE8mHlgAa6CrHlwbnwr+I+BruBux45 i6zitldJH5qDYb8djIw9uQ6tR2nEzuOrnJxe8vIf4K/URm5y+0pGp/WTjUOGcbn4+ZmGmopyg7Cj zN3jZWqTjBd5jkGHYMJEJTaU/UREUFuGuviQaItQWz/rcCObuK6LeGhObFPJ2TLrkz76lkpL/aeT WGVEw6Yfqal8THNt+mWbioZNo3jkrkupp/s8BW94BUQs4uTYCn0lqMmaiwv9J3+rMf0NdzBJhVTi IWQqBCkDvKQFC7kePHhwArGLCMh+IQIir6SLwUKYlmrKQrhS+/zqV78yxYUorXJS/YgLFyKWwVqI 2Kpzcduv9VtqIdkoZByXFCBiIsSvOZ46dQqyUVwMqURFSFyg8rt27ZogrBqvJIuLQRKNJT3IDiUp S6DywUt4aol4CFKJRyrRNhcv/qP3SThQ7yi9rLTB1QwGTfoODqLzhjwcp1ZhJvcUSWtm6vkMFpJb 3vg7+LoIiKQHl2cMsza3wuMjtiCWdjhjaD6bg2a6p66+tw6l00PoaUvD/l+WYKSbQScrGQ5fwcAT +koPkWDU7eMWlcNupjWwYcaGTsz98x6MEbFfOJyNxmO5qF7ahdxiKuIockhCGAm60NviQXHNINrq c5CeEUJfWwa6z9NoR6RTODuIqz/QCrkw1x/34diWYubRIXFojGPR3S2oWcx0DL1OHHmhGHnlI/T7 juDwr8tQOIebtKzvpxu7C05HFMeeLYFDtr1LERGel22ie6cT937/PEqmHSVRpIHPwf2A7VHklzYR 6RNJUhpx0vVN7ex+/kq0bKNnVTkw//39WLb2ccSYVDHCbS7T/USOhBhTGjicdJmlx94zP12CoTo3 shZTBxkmcbvkYEzVN/2PkHh83M3WZOAc7yFGBC6Kr3P6CLkrmyfyWIBSgHJSkaE1xEJDFuGJMiAR es752xi9RTxSQFyOILUfSRRK9y0JQ/V0POH1pXZFgyapZxqa+vOGVkDSRprDjbkFiw0BkURyKWP6 G2o4pbCM3kKQQuL6SAqRPl52ChmlZcfYsGHDhLpKSF52jQ984APGS8pSEaUSH6t5ERXZSYSsRYQs xCvuXl5TAqtfHUsNpHZU3nIGsIiLrr8RENJWXREkzVGESN5SIl7yoLIIiEWgZLy35qJ+rH4tA71l tFd5tXkxyNlA9pPp06cbbzGrrT179uDXv/61KW61oR8iFF/96leNNKQ25VmmccmDTWtzsTQ40R/n xNRlZtfHEe5/0sT8ZzXce8W/g270TOMigX+Y8S4RZgMYYrwY6vVO8iR579ckIEYnz8klyKXe+N5t KK06zRwrZECJdJ979GZceXcUKzc/yQ3WideJTC6/djnu/8x6bLzzKFZs3IowGcc09tlSvxTf/tQ1 WPDOHtz23u9wMpox3Ubrp+Mrd9+B9bcdw9IrXsAw7WJqu72J+We2L8VVb38eA7058GVy5y97AR7+ 1u3obPDiw5/9BTJzGgzHnrgd2HX5rbj/rkV493+ewvrrH1b4hTFYT5t3NQI5ET5o3Tj9yLV432df REHxAex78UZEGS1+9KliDoQ3T9iL/y8GO/cPHuni/gFv68dl618wl20kFsGeHBrMY0gP0B+bLLYr jROiNNFWOw9bvzMNGXOoIuCmO9e98yA82ZSwBv1wurhIQrKjIpJ0ZXCO4OjeG3HwG3nI28Skg/Rw cNAQb6PdxAQKXTyY3+PvVIRudWMhdI1Z0ejypqrlvsrKVZXbQH91ekcpg2rxS0w1Mi5pGNdeq4FJ vs0ysz0RhYn2ue7m2Cr/Wr+tcm/0W/3yI5hsvskrf9x/RUA4e7r0FsHnCmCIua6UaDF1a9vfZQXE NUuyWLVq1auaEdcuEJITSCIQCKmKgMg1VZ5UQq7Lli0zaiLL60vlLAQrNdQjjzxikKOFqGVovuaa a4x0IFfXVFD7TzzxhEHu8m6SK+2lVTmpNX/zWATk5MmTkM1Crs1S02kMMk5bhu/UWkLYltSRet4i JJc6Z82ruroaDzzwgEH8Vtl9+/ZN2FF0TuttlVdfF3uMifhYkpwIymRE2dgnJewRX/XekIXzTCmz kAk15cQSJaHoI/5f1BeCpz2CumXkHnewX0opr4uACLdGqbbKLIgiO/80oz5X44mHFlMSIdJkDoOr 3/4Y2huX4tmfLcf8VU1YvPEprLmjgno7xkYQp/7iGx/BvOV1WHzlM7jqvbOwZNUu3sBCPPXwVcjO Y379QR9izIeU7o9gZCgfj//oVmQwxUUvpZnsrA4amUnw9l+FhpNevO1j38fGW48jSIkms7ABO564 HW0NWbj27u2MyXgUXf/iwtprnkJP11xs/dnlKKwM4fjOAtz64XPIyjmJjz/8HCpqDmP7ljvxyFcW kshQfZNFnTrVNZcELmDoRBwbP38WgdwujAxwQIzi7e/KoMSUVKskiA1tUhCSaL34+CoM1NIuQtXn Ze/owOxFL5CS2GkfIdWVzYYcuYNqGZtrBAOdBXjy/jmMEWGE+gtO3PzVU4x6HcIP37UcWeuY4kT7 cP6hQF1d3J1+S4LQt9RUlFIOM0JdG+gs5tOzdWURNl/oQekvOxHjzmtiNgQOZvbVwyX7ilRbOhaY qHdesnN/a/NbajBKNaYPneCz9hugJvWxriWrvrqYdc06yybFVE0QCY2fH23RavY0IQ6zVGgTTMNk bbCSnAwMjLdhdTHxPdl4Ji6+VQ+oCia3l+3OMwSEs3zTBipEL9dbIVohNyFLSwJRJ7IbyAawdOlS 06cQ/j//8z+bY9UTiNOWpJJKQMwF/pFhWGoa9SOjuwiSbCmf+9znzMcqZ33LfqBr9913n5EW5Dps 2WCsMq/3WwRE6jYRENkiLLdYSQQmaPCihjRGC7mnXprsXOp169iaq36L4KqeJB/FtMgIbxEGq7wI oyQxjVN9a+5aX8v7KlVaseroO6HodKKn6Fwn2hkAXCL1NbezVdJUvZsJvgMBOtR4OkdR7hyArFt2 MpECvkqTQMrzZA5Z1kXbQ3TMA39mI666g547zMrY00KswgI7tq7AZz87A3eszad76z4U0iYQl1qH hmYqPYigiUE4HpeDG53kdOGFRzfjwqkivOvPttMu4kfGV5mFk0glw9+NzXceRGg4Dd/8xHos2EQP EfYdI6JXoJ42YxoNjyKnkBvHd9jw8J/OxI6uAuTk9ePKu85hzrJzbG8ILz+zEt/89HSUs3ILZbOb 3neGMRtdqCnsQvu5JfjBPXORvtwGT0bst+ahkvQx3OzEoo9147J11K9yrmnMkSxiUTa9iVIEpxhh 8kAnlzEtgjP7r8DLD5TCP4dpN2qjXCe67VKaSkToP+0IIzQQIEcyZiQyYeQ9L2xC4y8D8F+eQN7q Iay7cScNcbV48cYZDC7MhJcp302yxUlu0Zt6SjeZJpAEM40aoLQhN1qlszAbSIkQULq0cSOh9TS2 i/lI747gnr7zxtgeYwZPSR6SUmiXRaiMLpiKF6EfuZvpoeO8LtAObVGqwEbLk/peJz290oZ5DzK0 kOxfthURGxH08aHYfBwcZejEQPKE+a3xWsAhTtQTsudLJtWZg10YqUin1B5zx4fpTaaIeW12ldZO gz1vm4icfNoTjMY3hExtkGnQXJy8/7Esjp2nEqxjkhlZY+NPI7jSzvMm4l9rVr/XbxGMwXCfiQdJ szG53nhakzerU7mOTha3ISlERmwREEsCEVcsZCgO3lJHiShIWvjJT34yMSQRI4FUUjKI6/OP//iP Ro0lu4RUPZ8jobgYLAnA4twVFGhJQReXfa3fQtCWbUFSltRXArnkTsbZ67wVMJnatoXIrbGJyKYS FUtCkdFe6qcdO3bgpz/9Ke666y5DXD/84Q/joYceMmshImGVF2H8/Oc/bwIZU/uzjicbo64ZJo7v XzyXtul8j3kF9c7EKhzooFt+Gd3zs5iCXtm0E2LCUmByAqIyqS8pf8qDyW6nP35/CXZumc13nNy7 k7ECfH/mLanD25Z6sfG93IYyoxuhkYUsy7fSGcE77vseLdW88UdW4tkHZ2H11TuxaM05NJ7KRNO5 HCzYfBiuw1dwEWgUHyzErmfmYmiAurZWum2mMZCFCGn1NT8F6MYtj8Mn/2MRrvtgK4qnJbDp003I eTqC2ctaODEmE6stw8zFx7FkzVlsujYTFYuZipk2lmiM2I8QbM1navVDuOv+Wfjh++ehcB0nOc4d mwKpf3hJY4qRENz4nn2Umuhv3V2CQH4DkR0v6jptQw7jUTYGagLw7CNL2BzHfjaBqz/ZiMoZe1iW k5fbLtcpPEy3ybAfRTNb0H52llF1+deQ+B8E3vndM8gpqjXt3vwnJ/Gte1YiwY11zH149T1LHeXv fiz8R8TetSobLXOzTWCgidNgn+lMjli6pwe+Bu4Yx9TutZu47wPjRqq3cBtTGt0jjM1ouLwAWdXc yvP5LpM368LtxaglF6PcOfmsP5O7vxVu6+a+Bwn0c8+Q8ysK0JzHNSEUcrvT2bs7zA5qgwt8qGXs iPYTUeZdzVviczmz+gbODeHsXdxciMh91lNkCegBJglC7r7DlV5cYEyKqcfyQvYKeiw+2Y+cvdyi k6o1ZiZDE/dzqOVmO/30b8+gBFXCLTpnvtgGb10Y3cu4EdbiHBJ5KiPVBkF95dUNooAbYomYtqzP R2+lckJRCcQyGmMaX6zZTzSbLT//u3iGyXUlSv3uyc4jZp50MTHfr+ePuFqBjLmWB5UIwMUghCYE L4QroqBvITeLE96wYYPhjlVP0sb73//+iSZEKIRYRUAmA0t6UIzJt7/9bRPfIU5cUo4VzZ2KjK1j xaHIbbiqqspIRmrbms9k/Ux2Tv08++yzJlJc87PGIqJoufOqnoXQdWwZtVPPa46W9KTzGoekjYtB hEbEQyB3ZTkXiPAWM/eVYmhETC0iZNW1pCJ5iVmEStH/SvOitUgdm1VHTJeAVzHK2K3qtuTGbsMz vaij676i0gPcTCzGYONG7hqJ50kP+H7r0ZmcgCTbm2hfyI9OMvCSmx7qycc/fmIuFpBlLLwyhAWr WzDnsqfx908/DaePiTCbMvHiIwtx04eIPNn6tz9zH667ewcqZu/BjLVLsPvZK3D5TY/j3Z88wcl4 MEKv173PL8La6w7DX9iOtTfU0WDOjevXd+L4NhqaqTF6/uEPIkKvgOve90OsvbMdO37FlAyVwK0f /E/c9B6+38RHx3deiV99cREKKjimy5/DZx56mR5blI6euI2xGZQI+jmWT78NH/nSM7j67p+gs+XD eOl/M8XIdEk2F0+YbdJw3rebm+J8gQb5uS9jbDSfqT5ooOGi8f0waz5M9ZudD3t6Tj+O7b8GR75F Yz9TlnjLQthw005yzizLh8CodkiAs4s66Q3GpGskhDu2rEL/2XR4SQirbgrS0L7NID/eGSxa8QQu +zC34HyImyhN58Ytk4zvlZvzOx5p6owkD3IvkBcYeT6ND4v2ah7m3gWt3AhqOXeeW3Z/rQn+O8dI c04dpXS59dA9N8g9QJ5jmpENbKOysR1NbyvF1gX5WDAYRv5wBO184F5aU4IbKf6mHxjmrnXFOMYH UntPSwQ+x/QIYyRCa45zrwombts/PdtsR+rnGKTtGyaizm+iKzBdeg/zWjYJw8w0PjDCeXwmJUmM cpfEQ7zmobidyWBG7Z7XzqSQRYU+bGD6lCwmeWy8pRDbuDdJFl/cMo6tj9dfmpvLFNzcZOhYPTdS SsMBbiLk540NcCdF3ip0civTdBLCTXRHzt3Rj+6SDOzlrnZlwVGTUmWMYr+Pnnhmz4Qkc/w73ojf f3XZP2Tv6A914WjXXtNh/BLR6JONxgpmkxrnt4EQqxD8xSBuWSD7gZCmEKnatDhjSQbybhIoP5QF FhHQ71SkL6JhgcpYxunU8pbk8o1vfMNEfEtaSb1u1X893+rvaeI5GaSrqqqMJCMCIRWcjNeTQapt xELu8uaSxGQRHcXIWJJNahuaqwiNCIDmYREZHaeug1VHxOHAgQPmp1SFqTCRmyv15PixMYjzuJ95 72KMRp++txNpjWPoWE3HJ76DuXx/HW1kAKZp51BhAKIqqbdo0p2cgKgMrwvi5LKdbubcp85/70s3 82b7sbR4FNlzxzDcQ1XTfZtxzZ/MQmlFO3WfOXjpFxU4+9Ms1K6tIKfDje8fyEFf0zrc8hEvsnO7 8Z/3LkL7PxRiztImciZ27HxqBg58LQ+l1eVUk23kyOJUE5FjvJDF2ApuCPP8Rhx4Lh8nv0cvpdyb ScS4MdPOOfh62yew/o4G+LOGUHuyCC88UIZouhcP/vUqbPpQBSpndhHpu7H3uWpyPp1o9NyMwz8q xCNV12Dt9dx8Ppsii1785HqYuVp/jGqK3lCBORESgt2GELhA9zgFSnA9DEHgYUaA6iwa0gfbc/Hk AwvgWejgfgkkbP95FnmlZ4no6E4cJFUlZGT3k1AxspMxIxcOrsBL36tEgC7G/du4mc7nj5F4MmHb GFUsrONIj2LT7Ydw8Pv5XP+kbUFE6/cGfEiUPj2NYmsNt9+c85kL6LonF3u573IDc2TNmcH9rVsY Uc4yilY3dgE+HyIChUSiaTw/RlVPvyQLtjV7TwfKv9aCfd+chxdrchAsS4e9gQSH3H+AxGnRo/Xw nONL85dzcZIp5JdU02bEYEIfuf4cIuhlP69Hes+oiYB1cz/r4DQvtMmVV4tgrYO+SUTsVDX5OI4A 96K47Md1FBYSOHRXFU4wrXx/jQ+Zj/Sjj2lZ+inZrOWLMfPzDWj8s2L0byhFKzccmlPK9WYAowIf ixkYueQndUakP357BU6SgPSXZ3DXtj4jkcj2s2BHO4r29iHm431hv3aeM3Yea1y/t5v05jQsZrNp gHPkWrrt6YgoffvrBBmg582bZ7h9i5N98cUXjdokFSnL0P3CCy9McLvikqXK+da3voXHH398wnYg QvPpT3/anNcQFBy3detWw2VL3SWuW4FxqcjS6lflJdlYoPOWRJBaxrougqaIbBGQ/1uwxmH1o3Zk bxABsIjjxW3L+8wCBQVKDaXcVB/72Mcm3JilXtO8BRbBs+pYKjARV2uN9W0RI6ucSaPieQAAQABJ REFUvlVGeb4k6WmsWgcRPaVd+fKXvzxBjFLrGKcSMl1SKp+mdiCL73J6PV3qmTxR79qQiBgZPhc1 Mc1v92GAjj+CuOwmhMkJCB+yCWAjEm0SjEj+/j3LKBFwd7i5jIEgV+zOpHcRVTQ/fOccWhqmU5Xs hJ/pcHLWxfDUV+cwZxQ3MuFxy+ks/POGTchgzEfGajue+kI1nugvI/5mDMBcB3I2RvEM050/dm4m e5JPkwZmRwa5+SPfLYBvsY0Za2148IPLuDDcJ2KhDXV76UH1/WyW0u693O+A+2z4aOiPxd342Uem s4UqXmEisPks+zz3taCOr3QzcOjXhdj5j1fBPYM3oYaqEKmjUoHzle2jb6cDt36dSc5qKOoTsSeY jC5plE3FFOSAKE7s374RDVsC8M4Bpt85gKWXv5AkwERKbi+NPwI+63a6DXNDNbzwq8soXroQbaOh /b52LF65BdHhTBIPamK8lHJIaGrm7cKmT87BU59kYsP1nBddnn9vMD6lUT6YslZ4HDFkHw8iZyld n5maPa40zheYjsQMYXwc43VMfizVY4Cfixy9h0SobVoA+Wv6UXa0B5eTTju5oRSLwCm9KiWOLu4v UHayDfOOd6OIRMdFrn+MW24m22egaw9tJ8y3Fc+mmkqGeVbWgz7e5SvLwBM6FyPRUjHeJWQ+FUTe 1RGEKIFIxaZAqDCfXamccuhJYvMzOyo3LwqsLcIorxv3YNbVJjyy+fhayFZ1kJheS684tq12Beqf s4CHQZX+PZSYaEtJFFIdRL3xfwfgG8y1dGCYfuPnuk+ZIUcVpPU6QYhNhm19UsEyHlvITeUkRWzY sCG1mEHuSpyoWAzL/iHJwwquU0CeDO+SbnRdqi/ZSgRW269qcPy8hdTl8iq7i+wGF6t1rHpCpCpj 1bHOv9FvBT3Ku0lgIfjJxihD+9/+7d/i+uuvN04DmpfyYn3zm9+cIB4iRsqHZcHFxM/6rQBBC3TO 6lfnrL5FQCazPckmJRDRkTTzG6D3kifbAm7MoITubYqYoMLBacwgTgbRz83A9KYFmRl7mEZO4Qgr HdHrfvrFdftXEwnSghrq4e5dR/nCEdHaGfDnqWSgH+MqHESYMqLGafj0lFDlVUr0TqNLWjp1oZsY oxHkBvIv0ziZz+HyBRQHGW2hdDPkhK+ayKeYb6veVP4nxjZIP3sdC/F4jEbUOEWDBHVv/Qc4lvlR pG8gYqGx3s54jFA39yE/zhQGrJpWRK6Q00yjxDBaS08QG0Vndheu43glEHDv4jjHypHy82pQFHuk 34Gi9TRqX7fDkNgEkbeSIyYHZgbHfukgQIN6d9N0bPnWDGSQqA3vjOPKT51CoID7K48nWXRyG1BB Is6ki/RMO7XnSuz+MvdYuILzoYrlunfuBv0IEOzI4LTJzadz60kiMjtp07rrd2H/40V0KvCaNCl/ qCDDuJ9rSmLg5jjGiJwlVXBBJ4XkarAIx1vMPaCzin04WZ2FwQ+5MX9HG1Z97gziNXzMqCarqu1H Yzb3j15SiB4SDkWcVx+gSiqTjtG0sWh/6gjVVafvKjPH8o6bvrXNSDzGLsLn4DdAAxgHuSMmKul9 woBHjT0sd2ga6NmMAXmBSVxXWng9+EGWH6EKTE3oXJgSUst1+Rjjvtet5T6UU5WWd36QkfeqyDIs 2L48B6OzMhClRJNB21De7j7zjCR7eOv+tZapa7iDxvMLr1v6sJCt9X3xDC21ioXELlVOxEJIUOor y1guRLx9+3ZjjLbOSVdvgewMAhEliyhY37K9HD582OR6UjmpvMThy7isMVjlUscjo/zHP/5xYytR u6nX9DsVJpuPdU75rG699VZTX/ErAuuaji9uV4ZwZTWWa7MVPKly8pCSNPKVr3zFECSpti4eu6Qb qZ+0dpJ2BLLFKIuwCKIkH6u/1DGonAiNzln3yCJGupYKNmkQeKKAqekLaTuUard/oQ/HuaPozIEw fIeGEF7KnScZC1LQw3xbLCtboGByAqJr1hNnivHP+Es4cNSOwpUjWHN3DwqKOuipQmRNpO8gd93f l4NT+0tRv81HAsIKwnicgDyyho4zb8yMIWz6cjO9prgZfUz5apTC2Yvje6pw9vEA0mvYDx8WtWeB 5BERnpyqMG76X6cZEMitMcM0Zv1kgYmMl3dYmBHv01b1our9PfTYIqWwBms1Yn2z2TjVZvGEk67A bhx5opBSlNx4rQL8JoIZPmLDXT89i+xiivqjARIPUeCk/lYlNT5tkiPPoR1b1qDvZDpcxTYs/0Qn pY8njLRhFISmsMpT3eGkr3ifH0//aBG8i+0IngCu/usmGtoPkLJxS9CcVqoJ8yjZkRA7uRfCKLeT rTyFTfcuxI8/sIDZesklMBjxN+6L+nizQRjXugW67/pYv9VX6rF+8nqMe0oX7OjFRorDh1cWozHf i67rKrG4yoeax1uZWQCo+lWb2SToyCKqJGnQ7r6b6quiVpQ8TvUgnxMulEHMdcwGKmnIRSJQmc6N SC0KoL4vBo1tAviD/6VisyQH89u6rrK81/rSR9Mw5Xgg6WiQxOSpy0sxTEMiM6pgFvfLzmjg3hkm fb04eDDXFx0EEn708GVaF+1FbozGSUVaqcG3MJDdM8bzs918EQmx3yJ9pHobffe73zXJ/MQpX4yg 1I6kBoESBEpNJGR1cTkhOCFCRWsLiQtRCiw3XREXGYQFIgDKZps6BqUskS1B6hgrFYkIiHI7yT1X 2WnFfVvtirAo4lyI1ko7r4hwqbAkAUlVJmRqXVO/Gl8qWNc0HktKsuwLUjcpj5XgySefNN+av6Wu OnTokDknLyzZORQvIuImQiKbhvrWeor4KHW9JDYruaIIqlR3sudYUehKkyL4+7//e5M6RXO1CK2I 0Be/+EXTz8X3SP2IwFg2K2tOprGUP45Rakb4e9o5esk2ibmmtF2Yhna+B0tPBaEtqQfneBHhO+ln uiED4zhzcgKS0rh1aCf+HK6zYc3HmnHju5+mjr/eupR8E9Ug36PNtzHA8LF78NinGN+wgO8Vz0c6 gDu/fBLzlu5ESVXjK2RLdYjv111Ptc7ye/Do38xBBqVWIQC5YarB0TAljsPAe//+MJZdzZvFmcbC mXTVnQ9u88w4DiL8l4Flf9WA9W/7JZ+E5DhUe1JQn1TVNxy/Di/8f8Uo20APEbOfJmkHpY+RNgcW fbQLqzb+gic4AgfdqzivVDBIJ43xKUeX4UXaMnzzyGAfH8OVdx5CWoBzJlFMpni3apE9Z+T6vhev xskHspB5OdV8c0ew7gYOnHcgQc8mqcf8Wb2024gYs0t5sbHfVRtfws4bqtBd72dA4h/KrTcFIWru +owjSB1OYF8dG+BF/g9zz+zA/kGsZN6sunWFOE8j+faF+cjoi6D42W5E6EZb/Az3g2gN4fSaQjRw y9ydG0txLX3OtaezMUwz2eLC51rhZXJFickZbGuoggkoUxG0NSYzGGsM4988J7/2FB7klQLj9azq atIEUfFAHl+5TEW/kgFUo9kunJiXh3q5MM4LoPA5csW8Lu/mpfs6UXB6gCI+JVwG19oU55I6tld6 e8scWeqrHhrPj3XtN+P6bYGDFoITwtbeFq8F4v6FVC09/m8rLyQuTyYLhNgtQ7NULBe3I0lCiNtC 3qonwiAVjqQWBQnqY4HakMom1ait8hYBEteuTyqI4F1sexBBERKX0VwfCyRBiFBIorBAEsLF41Zd IX4Zx6Ve01jlNXYxWJ5jOi9kL2JlESyrrIiy2kt1a9Y1uRHLCWGydq261rc1Hut36rdMFMKJFTu7 mNmjAFHaBZvnZJuEEm6mGZJ4MkLX+wQJyvTTvRDLYHas5PfkBERvWAooh1Wo14kZV3Xhzg/9B3xF 3OhkhOk86KZryJVeIIMIvfBmh3D9239MxP9ePP216VTTJHDbP53G5jt+kmTimQYEMtxJs6M6o5RW AkO47p4fo7/3w3ju8+XwLUmglYF1THwCX8ko7n3wDBavJvHQzn+2IKk3XcnYp5hWgRYgTolGxCUe zeJ5jmsCVIj2CwX6sWQ8ToNujAiAqUR0hUR6ApRY0ckuRqjCevTB95jyExdTDiSBSPI6s6+Qi+rC MKWJjZ9sRs2cnVxsxb6M2z1YJ8EACgUN9lDV9ewPZnBbW/rgk27c82AtCqu4myHXI0EfZBGQSKSC Rv95WL7+CUa5M9UK92/ILGrDNe87hQfuWg7P5RyxGXTKYH4PhyaeQ/EaRMReGoqZdW/iSZGHkvzG NQwBrxi1oWxiZ24sxdnyAK55pg5L7jsHfG0G9tZkY4CbVPmmp2PvzZXIoL1j+QMXsKyZnP091ThS lIHB6gxk1PGZYKNSg2Y1MEljJ5M0ah+RSPJGm4dcHVod6/hi4ANha2CsSSZTUnPsGXQjtlF1NnGL dcDHRAKNxs1d62m3SaoYo6zroVuwCB2YEaD7016cmJZJPwhyESpM0JeyFeccDlLiEpXn8yTp4y0O GqFWobH/ghmph8bz8GsZzzk3SQbioIWURVR+E7hdbHDQcMNCkip7MSJWHSHoGKXJjo52k3Awi+X0 4mmr2X4iWEtiEVFQO0LIAvUvjych31xy6drmVYhd51RHx8qdZeWbkopHNhkRHaUR0fdEeT44ak/c vgiKQNdkEzBzY3sGzDSTqh8RACHppNqJee36+wzCFqK3IuvlhaU+U8ctpK6gSI1RzRlDeyiMYtpA NCb1p97UvlKNCPRGiVCkcdvbvHzOlVJGmMZwjU/XVDZ17DKUq2/1obFoTJPdI0l/Gl/qeEyH5n4m 3+OEvIaIspzk9rUnyAATosoVX7ntnHz/R8tdOL62BOnMhh04SyMuwU611zgKN79f/UezTnkv5B8/ cjKBzV87A18+ueDhLNo/+jHc78PuF25kUKEbKzcxgLDyJI29fnoRBRnvcRRPf6IS+VeNYtWmFwwC iofFng/iyJ4bGUhYjBXrD6Ni5j56JwVg9wzy935sLy41uave9peMNfDQkJt9nokKj5JYsWosQs5c Q0u+9ObucKi6HXYafkWQ7E7666aMfWJipoouJLGB8lAZSCmrNXV64gw2zELDdj7E7GtSYB1pADyl vMrj7EVj2HjzrvEki0ot8Eotmxn4GA7sWI7Gp/3IXE5X1HdoN8OnNXDOR4GJpH2keXb7EGYsbOK3 k3nC3DTA06DOcS9b+xgOfJRGxmeKmK339yCFpI6X2NXWyr2Xr81AD7e0LKYk4GTQnQLuFBvRxTQH oxRvbU8OIPR27plOzlz2CSHqCG1LTbw+nOlGrog/kW24hmsh3Q8JwQhTIwxwD5FwFQnjI4PIuIXG c9XVcnEt5ORm4iw45wQJktbYRI/zsspIClE2XnsPC1AcUOK35Hle4H8nAxeDV3Ib1iwyMpyHN8QX sp77lPCiiMWAz42CPup36Vk1SAKTReKhTMOJcg6RN19SSzSf7hse2qIoEelJkaRhKI76VhkaQmJM LGmIG9dD/b6VQYTDyWdwcHQAxzsOcr2Ua41puxlAqKGPJSL8HqeQzFuXlqBozXsaoxu3k27Rw/1h DPWHGABKb7Uo3VJEfQlxqvB0351Uf6TZqd6gF1x7sJNxNLR7klN1EtnYiJBirBejE4OLKcKdZKZC zFIQtA8yqJSBnFq/zCzTj9oc86UhTHf9jiClQBp0HfRwc9M/aIwq55b+QbjEELCcwxugMwZtXfwd 7BlGb4T3kOMR46OxiBnraO1FlO0p6tWeEWDWID5MHG/3KL+pPlJDdjIzbrLe5r57qLrRveaYXNpa QKp0lgnSs2NQtgce23iswEsbNQYdzd20lVGzIGIkCYdrFWkaN1CzH2t9ja2Av6WJ6W3t0TS52kIs tMfyY8rxepQOHdpATevcGqGzR3+MziW05XE+ulFadTN2ztXFNRLhMHV5oWOEzBhjzZz0YEyOm8SI 66cx65yDxNvh8fNZJoIkCPk7+G5ovSX5u6n1YFY+Yx/UezxAY/kg13MGt2PIPcKcglWMtcrx4Lr9 zABABxMxYfJAFCRbNIcpf9ixBRwnI9D5ss0OoaCk3Zw2Ngo2suuFW/Ct98xl5/Tu+JIH9zAATgZt blVHyk1vihs3Yt7mMHJKWmlcJ9Hx9qOzfh7+430MgmnPRMP7ffgzqrZcbqqJeF/Lp59A2Urmz88K 4fLN36c1nN0Jz9MryRAP60G3BsdvqX/SF9iw79lp6O14V9IGMj7+JP3ny8CAr7XX70FJzTk+1EQ+ 7OvMoSzjunZxk5rvGFO3DLbwgTS3LaWzlEOhrjR6fbl8NL722BhgmQ+aQQivUB0jfbhDaD69BFu/ W4M8eqT1v2TD5i+cpqGdhI7SymiEwYUhH9VXHazajfxi2Ycy4QtwG1lJSSR0Y6MFdAdminQ6LfyW IaWM7g0eEinEiRiFUhqp4x/4/iL08oVqIEG44lyfCbaT1JFJJHChwIuT60vQtCAH7fTQkp94Jjd8 cteOIaeNkoOM6EsK0PEvPnQydkJEIas7BN/xERSy3FGqtY5fU4a0K6Jm3/RCvqx+ShzatEY61kES rYMfmm64nzDbnnGoG77zQ0a9NUh10Z6PzDTBjiEipTk720x+Hhn6B7MYy/En0xHig1/LF7u6JwQ/ AxDtJYy/aRpGWmkApxfmYfBfvejN86CX9WvqmfKhm4SCSGaEn5is5EJqfOYkefQSEYaZQM4mBw5e G+I5qbyEqCyi8gZX+g9eXORZRKQj2ILucPL9DcWTXKQ1GEPCOS9ljBgVK8pXBFS762vieaPqW6/i BPAdEhiNeBKXJE/omE2MX+YBOSP+mPitRpJ8UbL9gdAr1/qHXzmmN5D6p1c7mY/kZ6INcvOv6mNI aemTQx3X0PMXIZjUBGhI5jxvG4hqLNB5NW3mSI5eG4uqyEQ/ujbE8+NFdO3V7SftJrpuxkqcbSqn rgdPmUZVmWYA05jVCHGoqahrbMp4IVIQp8LCNGOKWW2p7cHkfMz4VEegNnleWGfi/uga11Wgc8bR lNKW+lA5NWmaHRhJXudvAySa8mntY8BsHwlaQWMQrr2UAm8tQRH3CirY34sh4jtl4zWhDKw0OQEZ b09fyow7xgy6pfNCSPceNtTH4aHnCWfXeC4XuRX0wiocQ1cTgwJ5c9K13zeN5mnk4nIrKDLmtiV7 oSeTFrKzfTrjJtIxk2lKOuoD6OsqY/DfGS6k9i+OoKiyn3mmqNZhM0LmZqZMAyINlDFep4xNh4pT SWPa97rdWTh5P9VX49e1hq58vjhdLtzxuVoi5nOmD1vaCKPgl+HJf5sO/4pXu/HSy9Gkep97ZTeW f7mXwyXCYENWm2pa7QocdADY9WQRzm8PMOW8C8/9bCFqZm9jLAspOQ315Mu5dmpwjPmxVqDvMLni uUDVLf2YMfeZ5LyoahuN5JmI/DnLW4x0NTJUynPkLtK5xuSPiK2wj5tNnflhFrLXJdPamwG8WX80 IeakcnM/jzkM2pMxOUREmRHhDop8gKq3MbsACbmNXMzMnR10k6YnEmM3aulplUWua8OxbhTvYzLF JU6Uv9iJtUS65yoy0cKgw1xyiNfsb0f+rl44MxOY/XI7kRTVk6wfYYBiCQmLItXTj44guMSH6hYi NsYAyR4hl9kIn/YYEbo40eLWYaM6M/sScMgjetj5TCh+pKKVbxyJiwiJixzuEsZzVB/vNf7sYxXc /+KlLmzMcOIsx3WsiqljyHUt51a5s7fRw4s318V5TG8ZRhaJjkDPQRYj1ee10vZCL8JYoQO+7jBm +kiISPAUdZ76TJhKb+E/cbK/AU8Wbp31bgoX4nvF/ugJjeMEpZJzfdTB8kHPW7YSVwwywrrYgzYy CJWPtiJBjzwxD3VLclHYOsSsBESog9wAahO3O2b26fKnuxAtYNI9Em7tez9Cb7pWunH/H/beA76u 6zrz/dA7Ljpw0TvA3nsVJRZ125ItyzVxbE8cO5PESWbyXjIvfknmpSeT5jiOuyzJkqwuUSJFir33 ToLovfde57/2xaVAibIpWclvkqctEcC999xT9tln1W99K+dql6sd6lkcqyrWwpxDTQpuxUOcHaVj K9M0q7zbQaJPL0nR6kM0YeP4J1d7tfgA7ADUAB1/MFsl17qU9FyHmh6mmC4jSsU7m1xCt25riurS orVoT6NCG0d16ZEs1bKmCur6VLgPYA8hV2vFfGlDmno9ocqFUSBvR4uGczBOyLkZnG4ET2kW8Xzv AYA3sBVcvtOrRnJyybAjzNmFYYLAtDbN5zZ4iZyDdGLdFsGKkHEQhCWU5l1Y6eepmwjEa/HQtyb/ cCtFq9B9ZOGZGcTbvG7WrqH+HAjEJDbCfpR12IeBE8T6jSY3GNpLAjvG1xE06fVudT4Yr2PLU+Ul WT1/R73CWKuGHgy8Mq6yX89SAx1CV26vcw3YHBvD9XFVfDVDl+jfsfFAAyEmjDG8syv3ZqiD0PF8 5j3+ZJ8aQReWlcDKwfnE45XMfqNRF+9MV2rboLJ3wWUHZD4yjPh9L31+OK+JHOqr8ICGl4Tpao5H mZ3QudeN4Y2QgqhiubAfU34/V4GYfLEcyBgMsj3dpdC6AzPFpezvGldXIy4vPUBGsMDDQNkEmTa0 q0XoTaD67HtxiVjaTJ6DwXLAnnbcXjabIHFtQnhogC+5p9HUMeGgFBhq38jQc9/9nEtqj5FET07v gCfqFeKC7OBtwwSAoQbC4icVsYEP7YQZ1u9jHAk0Z0GP7v7kbtdB0DyjMWTU60+uoGdImDylnCfu m3+YVrW6kEncsyUrH1NIAp+YCn9rE9+mdgxO25u+SH9z5D6FFYTo1N8n68K2e7V4Iwk9lKF7REFe XTtFW9u/9Cph9TgNqYK18IvdFCAShhoFthswoOikBpWgLLrbAR14DAJc5+ZrgiLIoNABtdXma/eP ihW1iGOadfyOk/Gd0vv+yb0xqGvqaR7Wc5iGPCgWArAHIJgiPrunk4SvTGjGURuypJJwBi1upyJR kv24vxQYBjJvRtMeStV26VP1ysuk4h5yxUDWSFg9YQe88HEK7/zfX5DG9xH4wc1jCmtFICdRzU+v gWU/rXH3z09gaFfLo8gVT2npT6rdJd7qs2XP8Bkb22e2/IzM0YSI61XC+8EooKKf1Csrm3g3D3cA n4cgeCy+a82wEvBUVlVWOiFmYRUL12XSxMp7zOgf2DWQrNwDrco+BCULGtTVjphA+A80UqOwIhGU bqL4aQpkAm+80ZAoZqswolPSlBcOTRECLibGo4xUQs7cd7t3g4Vpyh/uVEzvoKZ4LtImwmHgBuSQ lejmw9ZLCMZS55w4tRAvz+utUETZkJrnpam9NEl5F64jDMfUkeXRpYV5KuhpUGJXrwbTc5UfA6Fq IowCS/OV1l6j5H1daigslZdwdM5zPA+FWZos8Cj/GMloFPjI3Fx1ZcYq91ysorC0g7i23kXE6GGh yCu7TgiKGh48zJ7ZBbqGlxwX06W8y9UYc9ZjKFNn5yYRKcEoHmlQ3vEmTdoaGInVieIs9RC6ixuv cwSh4yz+xLEEnS9MVTeh2ancIWW0VygMoT8GB15UbLrOFydoGIXUt2iIerYupZ1FcdYSNiLUOhXL 4mFeXNW2TTAvrR2CyRjLNQQgiwNoQmeG8fm7ctT9cfKpQMm9nPuq/Q38BkkExH1qAEP4dxI1tDJd 68o6hX+uKS9QZYR9z0PRfLdAC1EKpfsIyNG2ovmuRI3cCbiHZ7ngarkSCBkqP0PXVmUoBSW/Zned ptZ4Nb4mW7N21nIcD4wQBHkplhuG/6ojMVLrqrqVAjqy5654inBBHB4hPOmlpXVpPIgnZAIh4HdX IPbkcrE2XGKZSvTuthh95/fvpyodicoFT4zDutkZpYgELuJssDIKemgMxY5H0NZhOMKDyeprBX6b YkLJ9mRSCQ1MhbcNQ3UNN7GPLr5kDylKySy/+NQhdZ6GMqC2EII7QhPcqOWfb9S6e+yE7MTeGjNf WWRqRmEqVjPfPRyge0nYJmVWcl4UHYZ2qfzKBh3/q1RX4DhTedhe7cZGeid06lspOrTuIW386LMo ukSEiLmqvglx3QzxegKGg5VddEbrgdm+8ltFil46RTX6bLoVHlFMYic7A0FG6HTXMwsVlBmkrlMB 2vSNWt336HfYHxeK8hjsTVR/UwIsxz1qqE7V7MVXgPp6HFS5szVeSWnNoM3WqP6NGCVtgNLE0GK+ 03hrEj6gv1yclNjojf3bbaaex9266Yk20sMQJjm0ig+xzAnC0r3QLFrmg/l3ljn3NbKW+bLkN/BX qylxXhw7uvH9cr5vgtpqNBJ8C9GstFBw6O8YSHCLRYcSa79p2DkhBNxnM79nm3HvLSRmitCGe4Ax riIbOK9KvohQnELhTeF52QWadRk0xhd56Swrflu+I4g4vvu+KVOL+WI1+j93H/wH+jFulCU2H1yb U7bMqymQmWisKXIDo/DPBTePK4V+EKNWbY+gm8AQa0oLVSr1XxEnCS1l8IzT3tTovketzologUOz deGBIF/aqJsZHyfGTshzjFDCIPJjPIC8ArQ+Y5xHMOGU0EaEGuGhsPZ+tkWZlw0qsbNfnSnBSr42 qNwrLWoljp9KK4QAtutTlEYjyBF4KXhLoE007aN70zFaykaVdqBRiaDlmvEGupKDFN8F9Qb5t7gm kscopgBCXmMTo3TbhJbmQiuUHNGKQOi3pIQqMRPL24ARLzarENLP11F+B1clazXnmoq3kfo0fT5q e3T44XxVxkK1siZeJd+sVUBOkPKfrFTirFa1zI/TRTzyI/DCFc9G0TX04s1yjay3YFCFocBgbc5D UWyh9cxxRqgGsyMUe6nfKZpuvO8OlM3ptAhl4LVvfLlcqW90aDQvRCENY2rYlKSnKXzdfKVVeX9X rbFC8nQQj/YTXj20xas+ku8rd9co9BKAhlXROgypbQh5kUXUYUXiaXfPD1FtFkwgrXRGfbYSAylQ Ox/I0+zrbUp6plGt2+LUXBCrwqea1Lk2TkcJMz+AYg2smFDLF2NVhJfiOdyr8UWxGkid9jl4Jmz8 XA/EbTX9o6s1Fi01/YLvh8XQGasxWKmrh7Rw+VHfB2YCMro7S9Vw1NhnXZQRoYkrxlrraoa2gtCS jUnCYK5ug305SnTOJjkThBf/xS/kYeVYoa0WFvMf1H3txg/fJdx4eeMPF4rqxmr8WB89PA669wPh sTJixgOvzFEQbqZrUXhDWt74qhNsVk2/54lCzV2ah/KpIpzGIuQBsGE9RFzC3qaO3ay/Z5/O7EhX X3ekqp6J1bH7tuquh5/kM6roj92tc9+jre1CwnyRI75EO+Egtz+8r4FeEtIkgid4cHOKLrJfbghh PKsxMeVReXWl9n4vV/EredDNU3q3C55x+u/3TycA3r4afLfprV1yG0yAWqEoE2I3Daudj+2fndv0 9hMoBtk29vnMW+f/fozv+861Z024YZuz73eM6X26kMDbP/wZn910XNuOfxMoOxF+uHHe/nOztxAo bkzv065n5nvu3Gxp+z/3bf0f5qd5HDfWj/vT3rFrtn++YfcyEGs3gHCUKebADiaIJm2BPMJERTQM P5gF1G07Axd0U+OTWEPYE3JLywsZceVAWKgwqhnsAAPCPLperOqRhDCeZTzSllFFkLfsKQbdhKLo oV5oFGEatrcHrxfkHzkwm+YoyDqvFiVo9nwAGWV9GlqdrgYEdPZPCWOhzHspEq1alKyE01hpCEQL Gg9z3g3LkwjZ9AOv5tTr8ApKYZUgNDVJ6MjkSWQNISpCpVeoQ6rNRiB+ukDz9qGAhnuUcrFHS/Ji 1UbC+Pq8JMVWw+EGgWwUcG3Lk4Wx5q/NTVTU58aUBhw9mPB+EnUS8aDyMmd3qnp1iguD7ZqT7EJF eXhLkSTGTdYa4CASAySMfY3ghXQxl9krCQm2DKtqTryrAr/vWBPKE+VztR9gR4hCa+Ckgyy0fFUa Uxmg9OsguwinWjLfoi7XHshUY0KENu+pU/JhOMUKwnVlc5bjerv7xSql4MkZ0KThY2mqIcR390tV Sny+Rye+NUdRGE2lz9drNDdMJzdmKg2wxCR0RBUlCcogwW7hyI5PxOsU4cc7jjQquJoIyv1RavL4 jCrXD4T7ZPfqneOtNXXTZ8aJFYIVEEJ+I4IdDTQRlkgf0pf+fI8yi64CyeXmG7SXY+x/ZZZCcujp gXU904y1nMWNo/KnySEbZqXa+5HkM0ymTCCvMRo0MeCbLNvmdofVc/Seh6TvwWp5kpvQFeaKT6q2 fLku7UhWRDrKyfCotxjmhYTHTaj61VgdfG0tJ2Dn6JsmczVHh3FlyfFYncbUGDxJWdXa8Gi1etGf saun9Po381CS8G9x2a98ex70JiTYD+J9/EotSfwLzFGkxrBsJ8cIzeU00f+jTi9+a6U6WnI4Rx5U vLdAQnU2H7ufW6I+6y2CteXm5xbn+0G/ZYrEhKUJkJuGvbZ/nJcJZwsXOeXh38j/Ob/tfVMONwlx 2+5t33dftfd+3vBvw36dAPf/frf37fNbjBvnzfm/QxH49znzezPfm/n3zG3+M/zN8rapbCV01b4i 3nkgA8UYRDArW3fI4M4JFUM705QA2Z5ZoDwTwYQBU873KJgwyghWfs9siEVROMHcfMtFOYQVVC/B kG4GAo/uSQeigecXeWmIsBAoP2M2bmVdI/xbs2M0BmR7FElraDiCO+oi5zEIGecUwjaUMGcseaqG 3BhQ/BhjhCTtFhqHmU+2cDtZt/aUngI2XvbFbBBGQUolBFla16trCM/6lUnAmJBffHf2c7WaVdWj Yb7TBijk0N3ZattA07rqIS3+caXu+PY1Led3BGFVk/6Guioq61IkQtWqsfeuy9DZXwG0MzvGMW9Y NMVyD3Mfr9aaJyr00YMN2nqF3B6ecTOhrzD43+JMQNO6IJbKbiuQNRqda8DE9xNK6kDBrjvapMKf NCj+GgqRKR7FEG+8P1nHP5OnHrZdTa4xGmUZiGdvCOzyT2ZqLySiq861Kv1VQsZcfPWWVB0kx7ew vEuJZ1HIGGr9syNUluvRMvI9yT8yZBoKiOPPYX+RR+hrtNyjUZRjMaHC5nWJOg2H3JojTcr5mwb1 5UQqzs4dz2ZsXqiq5yaooJ7zmzHebnPO+OidfzrvA8kSHIFWvxqq9GX9+uI3tiur9ByCkUC3XXlI ny4dXq8j/5yhhKWW4whTpGfGvvwP/Yy3bvrzXR7+m7b5GS9c0n8wSOlr+/AgLjovwbx3O+yFU3PV fT5YKRvfKh58x67Y0Kz9BKz+fT/I0fxVS5U/7yTXBxonYJRr4e7dECY+2Mayda/r+CPpaoYAsu9a FMpzDb1GlqlhDzHaOZPKun9AqzfvcwpyZIgahSHyLwZEYD+BQcHa9MnrtMa97gsFTFFHEkQjrCN3 6uRfJytu7c15mnec7wf1BtdtQj+IRe4gIIR3nMXO/v15B9P2MxWL/317eB1c0ebFJnr6t/MapufK KRv27/ZhT7r9aa/t/2nPw78/tw82uTFMWjD829nfdhhfTujm9+3tD8d7nAEeW7Af0LpQ6V0CT9k/ tKnrMzHauzRNnz7dATABOClGz2UEUdbqeFcrM4rSqNmWogwAFAF4bycQqmsI1XgPdSidWqAxEsMh 4TAXk2uKwgof8FJ/1dUG6zLeAvc9FPi03fsorPTL5BHGHkB0sC56gJYOFeOZIzS7EWxdGZFKGCCc hgs0QDL74ldz1A4AI5Z9TAc73GLAntEswjVm671KEeh9eCml36qB/r9RfQ+D0FuaonAsa+/r7UQ4 IcV8rFphH8/SRViYR0EbniOxvwpqmqjmYdeWuWJzhqIBY1iSPezKiIqb6jCSqfkojnFeyEmEfx2e zYJsCkuhu4moRDFUwf6MAkh4uQcbOlAFQOEtXxhSNaxAgAc8Jgo7O6zK/5qhhmTq6PivALDGLEJN iWfoDEke2frejORB0/JQrlN868+3Ku1Ih9qzCXOtACSEp9cwP0HH8aA2oNTyXgPkggLrXBjrcjsb qntUgmdhJKMDFP8dfSTfKd+cnc3qvy9a9UvIpWA8zz5KiGx2qCph055V0a3Iw0MauQeyUxRsTMOg U8aDeI3JwJ8tTHjqN/Pcvcp5ol4nWF5BKBZ7LG+tQLgZ73iIbU3yfiD+aV9NkHLW9uiX/+BNZRSZ 8iDAzJQFhPWp8uwiPfZHaxVoyAwOMthHnNE97baDm4dNqNup/232b3mMd9ncv9XP/G2T2UXuY+1f tSk167I7t8DQXvU0x+jSfoqi5uLR+KJR77ofs/bN6u8uC9ee55fSxfCkYyQ2r8UJPf832XC0n9qO tC5t+cwV/cP9q5RCa9qd3yzCSwHtsGJCrW8G6qEnyoAy1zBF1A/QV4RaoWnFhkUGsifSg/Lguv2U J/3tUXrtRwsUVMTtMRbIX2hG/Cf7M34z4YFYlCPRIESWxrrYdjCoLM/1AQwwrhGq9Qmux6zKENxw J/TZ3QgJR7uHlh8YJ25oysWvBPjTJdUtjGGKZAxhYKSHQSzsEOoJLAk3aqES247XNkbZnxkpfsVi 71lYzyC0LpwJIsW3Ztxq0zgxePs8BAv333qK7Fz+Mw9bZQaxGyB8OjI3VMkXuuWdlej6vZRcrFXM 2X6VLBpQBVBo7z+QR3g4TDvnJmsTtQUl/1yjyLvG6ZdtcX3YaUHiteEt5FymSVT9iFLxOGqJq+cU keS9RF4A5NwgQjuAgs0MkFPleCDXFpD4ZY0gRUiok2toBXU3kUguikeFuqQsLN9LnM8wqKp+jmlK yDxKWIJcQjq6eUj559oV92K3Er/kFZR5LqQWXTukEtgD6qHVOYqSW8n+rFg0iJxDyU9qpU9M6QRJ desLZswHlstrLvboYEGcJuh9saAojsR8l+IAmMQSGos5N6CEc93KhxOtAnr/XYTWopanaW4tvWNA Ktl6NoMqCAUZdxTAzDUjH+RdnvmBokiVw/N2vTDOUfXMv9ypvDebFYXyMU+vtxiyQ4hGKwmtdaDM t5DsTt9OIWHTpGr+L7qXgs5KARzSwzwtg1duHp6U5QbHeG7L1qS556sQdFUEnQNHyNdcuDdLLVEh evDFapeTPPRQnsrwxj76OmzY+4bV9JUU9fL5wkPU3ZSGqg3vI69/hLwJymRWiLoI5aVX96r9HiD7 fG/bkzWEDm2hMOesFRu3ViD29L99MAdWhzDcGSTvwn594Q9eUHpxGS4cXFHAUQPoyHf91HJ9/xt3 gdCKJKFOGIZw0E1PNvtwXsz0vi0nYrkPG4bksdBXeyMFNfYGL9/rMOEyQc1KZMG4Zi285kJCU0OE m3i/qWGNrvwkTikbYBI2SPHPGZZg98yd0NE/S9Pqu+/QrOV7NDoQS3FfrwagaA8JxbqycBMQY1PF 85Zv1/JfL9D5F1MVk2+PI2G0cnp7fBFIsHUz5C1TTFGeDnfkCVBtiEWHFptCsQSQE8GfZyKM3fdu XftxPCy8t3euP+dSfvbHTL+hkvoKInVuS6aDQ3YgRNIQ6rMqezT7yVp1lsbq/Fqv4ntGtPC5GhBM Y6q5L0UXlqQqv6ZHhVh5Zz+TD6zTnmamgwk3OLAXGHDBq4243ZOquidVlTSsyiT+POexGooRg3Xu wSz1476veqnaLZNj9+SguEH9cHxTRlZjMps6kHEehqu463PPtin3lWZX7Hf+4Rz3kM090qJ0g2IS q39HyOxnX/mHn86YAVaf4vAyGuMj1LE+Xonfa5Pn/nEH186Y1abYc4NKq+nTvqWpyv5tr7x72rWm nta1CNrgh0Edcd8v0e8lgHj9tSRCHzkjygiBGgPlHktCef+8GM1eGKesNxsV3zyoC2b5bo1S6tFO pSGoDXpaAktyH8rByCujyQNkLsByJ5cYVAPkFZRRP+sh53Q7HHzhenOl1wEdDBBhSf8CrOghaoHi iXZk7WjFuKC2Jz/cMcsmn+3W3EJaSxDfP7ghUxtRYKk7eQ7TUX4/qdP4LwXRp4biRAwlg8umZffo 00396smMUhm5kCc3ZGkhXs3SnTRwApkYiUeRf7mB8+7U/IIoNaMcm3NidAy4a789Aygi6xWTsSxN HjysKMJvVrBXzTaV5D4Keb32UIMydrXxPkq7JEK1K5NVgbJq4/NUEukb3gAdtQt4PHmlrkfj1Emu 6O4TLYrDK+qAYqfgQLNLyhuYpX8OeRK8oUVXQMmhMEcBGVx5KEtXYHnYuqdesS+gBD6ToGqU0iZC kd4dHRpZGaayBUkqttDcm4Nq/Bp5Ejy7TeRTwi+PqPHzKeqgb85S0IjlD2Qol6LCKNZAj5HE2TAR ijy7tQJxW9z8ww+LDSUp/tn/vkvpRaY8YoDDUXEErce5A3fou19bAyonnBwC2GbQVmPIVgth2cH8 KCtPMrTgXYhODh5EUUpoGDkTUxYuxoGcpQL554v3m8/N/8rc1xH27V0yqLxSFAhCOzAIdwP3vOxM vEIsiWrZp9s9AkIwCMTDjh/PV17RHhhxBwDiADnFa3CDEw0OtVwIVeP0dL/ns0dUtuceFJQhyqgA hmBy8yMXaDhlhJAx1Hb0udyLwYWDrHL+xiAmOhyp0Ghj983RG98vdLDdKaz12z7XG/t673+4bo5Y gKehL1jaNqBVCP5yYsmnSxOUtAKX/GqfJten6yLNoLILopXU06MKHvpaFvsiLD+rUG/HWunFMsqj mNAw7jXp0armoYuG5yrjZXrJEwtuoUK9B9MwZ26UQqCM7mTBNmEBrbDYBXNZxz6AacjbAuYcC8cs 0kgExxRudP2iVIXPSaDzYat6cqN0CRhnEgIvniSuQYLf75p577P1n/MbttKsRse8uiskpz3/N2R+ 3K8hvMJaUD2lUG54CXsUk2Q+AFLpIySc4+sH1IFi708N1xCCv8kT7qhhEhCe9SiRggL6uJzHauce pWOtt7ImvMUhSrvQJav/6C+OwptplvehIVUkRil/V7NDYprXa2GjBO57xeJkxe7qhRUhXD2sk455 cc7jKSKE0wREtxTamtAWkr4I3QPrM7UGhZW8l1g/qLHzGESZoMkynm/RrJcbgPyO6gIK4dSGDC0D cZhwgup2BHvpM7Ua+ly+zt2dpdLUMCUd6FIILQWiCFcn05GyiNxAE9e9j1wJS02zyG8kne5W9BVq 404NEX7uUkkcxiLrcpi8QT9AAEvoRwJbjqJGxNrERlJjNAuZsIyi1uiKAXnO+loCtK0BwXUnORWg s9mE2CyvsxBUWca3WjWyIkzXH0jXKUJ8G0FFZf8ldTn5GHex1KgRYjbPfiQ5RBfuMgE/qEKu0QAN tXcnaS8AhK0X2uTd3a6JQuC3PN+F5GHyXgddBcS45tFUIgCBythLHc/8UFXN5llnvpNOdmuMe1QJ WCCFmpjQ89SCfCpEkTzHk7hp/dTG2DAvy8atFcgt5JbRmfQfDdSnf3CNnMApQkMkzUAoID10dt9d +u5XVymYmxYeDmIBzyMonMXIx+NY177BAfk/MgaBi9a0MFJEKlZPEtlmjhdg5iMyta8TNlrcPVMw P2+8YxP83eHaQM39cp2iooFvTeJvYdGPDiZQj+FVWOZ7S0bbdUSlT+jCvybp9JYHtXrri+gfX/2G WdrtDZmK9nSR70ChgNTKKz6pNZ+dpzf+rECRhZOKmzWOwL2qcUubIFQnHYLLvJMZgzmZIL/S2wls N3JQh3euVdOuaF8PkH9D2K47A7slCH9rjtSHgI8hFJV2rUfFf1qpoT8q1oWFKXQqDFfGt1tVsrpd V9dSnFTiQWEC1aRIaRbwvtTDnUB1Kebku5EIoFnb6xVzeEDhv5urvYQG+lA4AU0tLuQQg2AZIWna hjXorScWjZKwZlAuf8Ltt14isQiCeY/XKAoosJ2Xeb1WaDVvfr9q0yLVOt8DgidG7Sz+tVArhFfQ /MZ4qXwe9YyJ/fDP254BlqRNXxTFc2nc0wTqeQpOEXtvH9CJVelqIsRUABFmOPmMWXgQXXiK46Cw zLvA/FMqXqWxEZxGQdx/oUUehNnuzTnqLYpWLAok+RTFs8VxqsICLyzEwCS0HUhYsheDIQ2hgGhR RXyYVs2PUeqrNILLQgCA4kvE49m9yquiNdFKIVcwzlqNQWmFE16dS8Hh6/fnqW4d0NnrtS5UFst6 2rUtR5sJ8yQ/26nc0m7tZs3eh9XuOdarghcblVTWq1P3ZGnnfXkqXM36JX+R82qzFv2wUuc+n6/H t+RqfUm8ivY3K/YqxhBCP/OVFqUFtalwSTS1FGl6bnWG5mJAZcPW7L3YpegLhOqo/Ug/g8BTh8bS CPkyP1aPFEjIxcA3gcimQIr+RmeFaoQ5uPjbBU7R1KN0BzCU7rjWqZyThJLI81geZWBTpC5+JEun 8W62nmhW5uPN6vpknKtxCW+jtgrhN0IPnaOfKdAgz8KGpyoIDXMsbkhveqSWNuH9v9jglEXdxyA2 pT/Opu3ViiwfVsdGD/mSRK06hhdzbVRt98WrkvDVfLwRUy6TwJl7OQ/zTvqXQ3ZJ+LrkbAe0ROF4 LTgEu1gvKEiT14jBWwxu6MxhceZhMOBFn+yC14pvc/JTFosKHkMwr9Of371Og+0RGmok/3AmRL2X EEhldCEDCTXQ5+OUcqEqjhYG/t64YKB7wuKm0DCZSbfVC0wW+aFOqtSDEt+hGmaezrv+HYCLO05/ 71lLSVCzBicn+cExWxu8aq2MhiiRxJuhwN7L4KQi5ks7flCqrtYMakmIzcLpY+eckNrM9fiS6rZI DEW1dtsxxeZDLYCp0naQ4qjDqxVMwZC17x1DURAQ5cWMc+BSg0CNJWU1qKF8gfY9lkeFvCkbtpmx 2Xs55dve1u4jT28gVosHJlpDY9TBwtn4S2nKQjg/dLiBvuB4TaXQm1+mmhcB08RCK1sFtQrnln+1 04WzDCljl+TumtWKMDnxVJkbQaHlOSZwe+1SSCEpnEVeR9jDkqwGxzTadjf4ZcvAepKPU+w3RrHh OIrBqnpD2sd4WLsdauYaLL4N0L0bRDL5Ug95NxcI9O3jw5/vbwZs4hkeQpRFhEGqqfIeI0eR8ffN WnCyRWUIuTZqHYJ6qAFCeJmgalsQR13NkNK5D5ZsTiaXMY9K9czj7Ur9UburCrccwXgC+Qor4MN4 MATTIIzNQ+wbBjg6VIZqAmEbNZ20NUU1DM+aezx4lgzQYYV3bRgtcWdIDnN+I3i9k+TVEskvLL7e qZcxcjrvJLd5ZVDLnqlSDt3zDm7NVs/mGHl/2KpFFV3qpLdLQDnSjrViXsdK6jcKybEcYR3tIxTW sCWZepRxLf7XCm3Bu9gHdPXwx/Jo6UrtGLxrk1j71o4g/kyfFn+3Ug8g0DuAEb9GiOq1R4p05Zdz 1HJPkhq+mKaOrRTl4Y0EIR+tgHaSgtoAZK55CvW/ka6j/7VIr362WAcJpx1mnhPhtdqKYJ/7o2pX aJv2FAqUMNiBzxWqnBDUg7tqVfAnNepbF6PDW7JRMMwnYa/ACvpyrE5SE/Ox6vVaRZO3MOLRAVBX ltzPhYkh7NyoOld7dHxFmpbgjSQcAeqLIXBpI33VmctUwpBW69W0MEExIMYKjHUCzTQKX50xY0eQ X7Hi4HkYDdEXBjSQFKY+FL0NB5Dh9609ELfJWz8sHDNwmYI+KNMjsbinxkFUEMqy0EdTdaw2/Q7E h9GjrvLblI2pRxOKp1/NUHVFIe7iG76d8VlGbj2yfY7KDsTood8vV3hENWdjeowucv0Jqi1LUUgc osgpFd/X3u3ntOhxH5scMkZYD9WiMR68D/vQkiwcs6kulf4bJKxn+956t/3d6n0T5OEUM9W9GqPd Gzfr4S//AG8JRcQqD4SnanTQV3UeRqtaY9ZNL7hMi9+5euY3fBDeXY8VaMHKTMVn1GMdIBSBAQeH MHH+wX6sbsXmctezK9VzPlxxK0Be3Uaexr+LX/R3AA9I1rF2lRASsEXbiYU5B4uo4ElcYm7EGASD 0VcGVESi8AwLP5y+GZndI7LYslXK2rCfbsr5aYRsEeRQ7PUw+YwxyAft/oQQkjNKknoe6E66nUXj 4huliTNIUBxBKOthQlqnYOm17Q1JsuDVWiVQYJZ0vlvZ9DG3RlRGOLKYBz36EiFFCsf8iXve/nD8 AjMwRg4h6QTV1IQ/DmzL1l1tI8rG+l6FQKqYl6ikM9CP0JnSw709QwJ9FuHISJTJBLHj+Nd7tKau kmcbgZsbpIyaXr1B0rpoTYK8T7RSwT9FDxWYYWd5lPK/qlVyZ6/6TRmkk1Pd267VeCcDhMtCrJh1 2rAJg+zQw5powrPJb2rQgjNtOgTdScJd/Up5o1P5UJt8mvUUDu3HmDdEUS0jWgL8tvKuNJqD0R01 B3gq+bnrUJpUfD1T3mus1yS6opJkXvjjKoU8AkFplkenFqcC4R1UXPmASp+ucx7xcdbakS1ZKgH9 lFrWQ6dK2roC4w0F1JL3T/XkUrvVA4u0iSmDIR9ck64q1m4xYdUIuPdySD5nnWgjOU7vH3IPtQsT tZ8cST5COY1QUQ45hQhqQgqgXomsw9vmGRkH2j+yKkInH851IvG+x67L83Kveh/w6DwULKVVlszv d0i2ls8m6SrP4sY36x1VySgGlxlrZ0BvhTGHqSfxHjbCgH1vtossZJDLgCBETShLqwm554VKF77r LyKMDDx7LsZgZBnGPLKtEcXUjwKJYk7CuOYQmukFwKo+iMc4ZGUaDD8i8rYUCKle/uNi52HZ8w2X HLdcQkCwNtz/qjYCwbNBPRwun7v/cMQQrkr6De3/X3Ha9jEakSR3a2qYmGfmCX2VWoyyi5na9MBR 54lMjGHdRHeq7NBSVW+PVtRcLHDMVUug+Yez8N1LhLcTTf5PfL8NvjvcQ3wdtzQy8oxzr5yfxzm1 NmVppBMhGMRi5/V7GggyUyLmFRx5OlOrt8wn/3MeZQDc1qpbyYG4gWczRWzHhKYVLx5clwttS4wa dkTr5MF12vzxJ0FgYX1B3RITR1zfmVnM1VQEczAIueM6HfpTL3TvVvlre/l3Gva8okCisOCWP1Gp uPsyHVzzAISI3Qj3eS8QHqCaNgCrL/1UB4nAWHXzoOcBF7Rk4qR16zPX0T8s9sgaM5SM/13WpBvj eDsGk4zFimmdBbkmW7BcfJrHt4n7jq9bJG+gQFxkE68mEqRKLgn743EpSuAhTT8NzQjnbYf+d5yt 6bP8z/mrD4Vg9PQLnq7Rzi8UqhMvI/MkrYefqtHlz+Rq538p0YYXqlQAp1k94aOrhHGsm935O9KV mxOlIYR2wW6sWGREHHmzuKXjqiG2ntbf6lBVk1PJGkHIBjVBLXOoRcfIKfSDTIqnyrlkbzM8Veka zgCphUA1OpnYukHH29QHr9UUCe8UlFsMcNyT5DBWsSbjqORO3d7u1uA4lj4BEYfwKn6iTq0r4zVA gWIMRkbB/hY1rUzUuY3AZzFAVpxtVc5fo5C6KpW2Cd5o8j4R7fA/sc7McCl+rt7xdB0H9XRgYbKS yL0lkcvIo74iHKXaVhCjFMJrGX/DtYJKzY5vUelCSDqZrxoQVlYHU0FS/hI5RCu468SIsnqK+y62 KeUM12AtYlm35pkZM24AVeXDBaG6spFGbBhxlotY8xMEPJQp1/9HDvUicInBGZe1vcUZSw13JOun oL8+DveVdwfXjxHVQDHiFbi5rI5mDfcoqIV2E5/IcaCEDdupUif82LcoSicXpGjleQASeFMmg0YK 4aXjfL3HARUgs4fwMqq4hnRYBEKrcBKYkwnOr2dtrMqWJiuovtYtfiv6tOH76f689Q9XV0FCPG1t v6Iiq9w3rLd3AJoiIJiLZ8HRuML9CyaRFgAdcaA11eCtUGhPLl+PpSL7QbfzgBDTcNFasHa7Pv7l bysxjcK6Cejfozod++2up+YpkM52ZuHfkD580/K6TzkAAEAASURBVG5qkAVKiZuaxDElZVKDrW4M W7SDF+G3QfnEYWVw5YSRiO9zyKZaDxhrLvV2Eis39vjWHxatC4Hmvb+JBjY/Wk3/cqaBoko7EeuW a/8MhhLIfNhx4zMb9eDXrmrwEg/Smknt+Ga+mirnKTiahGKifZnvcT0B1IAE0hZ3CL2844nFCsxl /uxg/57DpopDdq6I1VBGuIpJxK093MhDP6bzFCXVb4AwzhhrASCYFRZDUttCTwmEj1xV94zTdfeD mzUVz8JEGNkIJfdjvEA29208TBF4hZmEDxqwZrqwzCKxTP11JAbzjQChsuT5Wq377nWtRKFFUanr KsJRYHZMa1Vr52DnYkLGr5z+PafsP92xeHYsMNECDX7tnXTpPD0MQeWArgKbHVgCuIMkde7xVrUR ttn/sXxHsZ9Hctpu/arXqYIm2frTNRD6oVAsRGX0JxaKNO+kFlRX/wP0+DhJbg2SvsrkKHV/jJDU M+QPsMLrqWmw+x+G92B5gyrCowbvnQJFFdI0pizyDEbibjDX0OoRleIZX8aCbgFqK2NxoPmRhaaM +8z2Y9+z9dKBkD+FNd6+CpQYYZicF5o1h1BMKqGas4tTdOLvSxGoMcr4Xotyn4bokXVlAsUEbygc bgUQSd7703KtBbWEjHcs1M9yja/dm6v9hM2euz9f5X9IAeInEtS2LZ6wFfB8qudzT7RrBd7Nuu+X KwUv3ZL0d5AA3/p0uYp+WKe4KhiimbdgwoFWn9a1IFaXv5SjEx/JVTmJ+nzmZCnr3rO9TzWb0/TC cq/mX2pX9jNNePvAnPH2qkFrbWUeMq2AEHk5icHWNA8wA9X2K7bXKnZnn9ruitd+alxmYeilPtXh QomXSbbntAy4zqCGW55EFDWjLDLb8TTIJY4RbrxM3qUC8EQUnlIIdT1D3jCd/WK+9nyywM3P8j0N bvkHUi9ig9m/xTBJgIB2g99WWBfpJV491ADKCcMQimYT6m44qXGzWT81RRtE4gzDaK4U7srL/zyX fEQgPTCeA6EFm6GtvGklEDDBRF2YB8HhOl1/LV4xxUY0yM6n94+T40JT/cDnrH7C3h4eHnTlES70 447vro1PSMJ6cPEIBw0NDTi9NoCc6yd/E5KOoLLjvs9hsN6o3Emd/FaaVm7doJL5+2gAw/n452F6 v1NTvuNm5byk/PsK1FSVoP7r4TDyrtJHPo/CNP6W6e9YHok+MLDt3q9LP01UzCwEtYM+v8+TfK9f 4zws/GOsnhehaC9PidTdr9Uq/y/rNPoHQaomgTkA9bnRnPsFtW2PbHAQylt5ggbZVRshTwjhbJjA D8bitG1tyVmTmjgSj5dx54cJaQRS5evmY/o+mscRwYMY2QBaD6Vl5zaJULBh/FT2l6NTt+3fNve2 zYfjfcwAk2qPRhg3uQra+9yF4cqjpuL8Q0W6jEe6oKdKMRf7tS2lXofWZ+gEaCXr42J0++NARou/ W6P+3wwFGRej8hWpWlA+5GLnEUjey4Q/xxBCsc/3asHqVu0jKV+5LlXzoPePI9l+xmDBWMYx+wlT AqA4j0Dzro9VwgUsZOLz2Xi91rLB4KoBkTRPukJCvjDBhTvdldqJ87Elf+23MeUaVCoGpfY6XnQP Tczu6C13VeaGiFrxL2XqXORR5cIk7SHhXgTrcMEbcEZdhlY+PUStDyQ5kE84PFaeHcDY9/Qq4WMD GiZsa5WOXVSum64Z5+/ThJDGQXXZOrZ8n/USnwWgoI9alQzCXrP2wxaMEI7ei6RG302S0zNvg0i3 +lbAWM2xz+FdePBOZqMQFtJjJ6Z80PW16V8XqToUypYr7cp4EhbrbILJVPrXP4iCRykVv0KCnPs1 isF+/lPZukZh4p14JHHQqoxQIHgd7ymZvFP6mU7nWZjXchoU5X07auF9I8rRiyL6PAgvjr/t9RoF 0yen6U7mhW2iecZjQV2FVoyr9aMxOkrOMoaw3OoDLQrlHC3XG4wituf51grE3RnfDx+ZIlQEHVF6 8h+/5ixxf/hlxmY3/2k3FGu8tYok0VLi3COh+v6jC3X6K/mEf4YVGU7XMKhAJqh7aGuJ19kn6Csx jrtZjACdoTwsjGUsu/VlCfren38dJAOHYdImoEvvbyW5ShLe0hw2TMDHLQMR9iYxviu/dSMENtwP EdwVyNMSPwDhzMSGzQrU03+7Rkl5iznqu0swi/D1doHYYlVHz6JY6UWSdWVfBzjAIrdz9n8Vodhg 55c3/b5dzL/jsGRYwCDniMcxlUGMGihi0gKUBrFbezaNZNFyEfa3DTttnzLhe1ybX4nYe6ZMrRtg 56fjVYeVlMiii2jCU0iyb0FBwTamjBJoe5u8GjQI2HZ76PzDRSy5x8NU0AZCL20FhEEk+INg/fUN nyJzStt2+eH4wGbAZjgGQdYJGq9+U4qSj3W4KuRLeKHpK+FH+lazUttblQUr7hBhqFU7anSdug/r b2+kg7Neq1fro4W6itDLnU+I5wcIvnU9OkVObQyr2QyFrGdbtBTr9nXaHGeshOIfz6AMLzQPDqm5 h/uVAdLHlNDZrVla0VEB9HVU4U0jKuimroMajSBkQfRJLPSERnUUxRJy8IWAbA13UWdiaL4owl/G hpv9SqsewuM9QpLcqroXPF+tmJNUWKfAPH2ki4RytwaBk1eRmzj2qXwHCOkHWbiTc/MSIo0l/5K8 BZr2Y6DRnoP3CiPIFNNYBqAQgB2Go5mXRc9UKvKNKMwV1g1iLNHUzB4SA36EvkpuZiGgonti1J0a qQFCcRMU/XUTRiuPwsrHiJ7T3I8yqKfuhSJEvAKrRandlKbLKIAJnrtCYLeCEsa6g57/ah61yIFa sL3O0cBbYr7s7gxXS/WR5yrkuQykncNXPghvGPN6B/mRxAOQKW6MRVGnKIvQWGQX/hx8Z51bPNoN CGAtucTEg92wUpOrodGaMe/mQbeSfhKvJQ/WdfoCRTOvBUDrk492qWUlOcujLBaTxYxbK5C3PZxO MABBvb6PlpUWhZr+MjLhrfG275jiCU+ZoMOfCZkpJW6QrrwSp1N1psBSnfCxNCuZDnmI+0cRFnsH 8siEElJluI/CmNcSnJlkhzTPIyKVb5sX4z8H25arab1Ouf4RwmAk8V0OHfREOIzBH8RgHqn7oBK0 BRf6kk85uP26k3rrCLadnVt4EsIXGKqdo7WNLD9ETBTP7Mb88RUTwBFpCEnCbb+Ih/TW0d/DX3be nKf11EijZ4Kw/i6SPKz+Ok2lsKLicVOT6f9tKBL/MHSGr7ES79j3bWCJGo9RL5TQe2H5NH+0j4WY CzonBXrrKZTBBNq/jwfa+kaEXCCJCBfRJZKj0dMeiAmBAfYzBYZ+9ycK3Prs5vXaM60qhordsf6y xuzYcZyDG/7j+159+PP9zsD0PE6QUDJo9SUgnh64qPqxuo32vJwE+sRXA9RJMr0HwTSGwAyiTqLw zSZdRml0LKdA9B/gclrWrf3UkFQQK48hP5F2CiAGUO7LCOWAXwVaS01F1jlqScijDZOwTznSqfuy WnS9JF5ZmzxK2t+l+aVx2s0azFmWqAK4oYxq3UKlFYS2irCAgyJBDDYN6goCsXVzvOKB547S8+Xw R/PUyporog4plwJHT1mfcr7ZqBgs6dPkPvYRgpm7qNNBZM2bCsHA9Zzq1aInu3XyH0t0inPMBoq8 CCRZE4ZNBzQe9eTqyoC/Fi0m30HILqIWll+QYeEk4W3tWzuCOMgJqd7Q4PoIQl8YxfFQFSWBMlsS q/YHotVIPUwfa3qM9T2BIG3jHFMR5KvxLKyuJoKe4+ZZm3cSWDau+q+k6Vmgx/PwoJbSJ8WONUUC u+Ir6S7ku+6JckVdBeFI+Pz8l8izElZc+8NyeLtGXAiq4gvZugAz8EbQW1YsOQqVyiVCV/aMriAX Ek9LhuF8vMXVaUokxJiGh0LmS33U5FRnxyoV5blwNzUzVUMg5ILVTlM40MjKJck+xr6OLc1xCmSc PChQundRILdYiJaXiMm03IetNtMWXDThFhN69sqEt+VLfK/4xeemRG4IRT7yFIKqKEIP8L5v2PZ4 BhYKQiaYEL3VsPfDCqYPxCZGtGjHNtJEZ41Of8kEdygMweEeC5n4zsT2a+/7hyG17OhOsPvfvI3f N66V/VmVfXi8L2xngAJj97C+GT7TfPraOKarWfQfm7djs3zWiR3OP2+sHl/Yanq7t1PM2/nbdc4c pmhnXtPMz97z3+hWg8qmkqDcjCtuBVPmfSQSr86i6U8KhHQTJChtQi28lA2SJZmH1OB9Fms2AJ3F vAsvgGNHuFti3CrRQ/E+vBSMRcC+atW0KSioO1mwHmjAp0qwAi92ayP95C0Jbn1H7KYsh+DNeJV8 V2sPHHNGInWK/IcpOjvmovPtigAZYufikCA3T817vvwPv8AM2PPEr2QKzeZR/3FuObUf1Nxkc68i 8EouI+C7YAyYRYMnK8y7QOjGrPaFr9Y5LqdTIKNiK/uVRyionhCIdZ2MfihDs/+oSnOXtOsVcgej 0H2srRhU7P4+eTfAN8VaC8dKL/lmnfp/H2G9KEELnupSwa4moOKRuooS8eZ1OGSV0ck3UxUeATqo 4Hv1bk0VE2KrQFlNrsRSZ91lkCtJNwoVzvtFb7o8Cyd0V3qD0v+pWRtRZlX3e3VsHtvPS1HJun5l g5CKRSEoXSp9tUFzqGkJhrRx1AtVSkmUWoD49qRGaIy8QgOJ7f3wgCUQ4QhhwaYSGrJ1bkWxGV/G y8A4qsFSTyV/Zwt6GANnjHxOLKGi9PIex2TcRIjJepYvg9yxdAeNn85TDkD+wiTwFEZlXx4hq08k 6xIcWxtJ1s9+qV5REE8OlISr6rPpOkMYadvOGkUfGFTTZ5IJUaVoAGW0+sVqh0IzEIF5Hq+AKPv4 wXqlvowH4Q1WBYWIF4ALb9tXr+TtGHN4GhOABgwebVaaXUdA1aSGNkfoEsy+21BsSa+zHdGIXtgp 6vAgF3HPU3e2q/VOr7JqYQm3h8YeXAanf5uDZ7jzINrVBDdfsa975pBwAnJryKa+47Bpgh5is2kB 4GSC+9ves++EZRDGyMDNQyE4iifeMw1gqKPu0z5eJNv27cOO5d+vnbBnuc+j6DwS7Kxd/2fIGBfG mjKBa08EBx2CMXiw2ieUbLt4CB5NSPeet6nz7ZdfP3PYdjHFkwpPhB/reLBG+b7/mNGFvvfbDxjg 9a3ztB3aNjOH/3i2HWh3/jNsm29u7DNIHORZgWdlk8VG5sWM9gWq54KvjoJ33TkbxUporM/DesdB bKP3OjhRO9dMqBXSw0BjcHwT0IG45A5lZfuzbXgAcne3mM7HBWROEfY2jEer6IUG35y7d9iWcJ9R alvzJQtveY/T/e0g8Vi8GasNCCM0MeuZOh+eHDSVjVkz9+HXkCRILQ9iw3Ijs35a75SJJU4/kGt3 e/7wh83AFIZD5o4WKqejdBSlYcWBpQj48K9P0kUyUjlQqQcjaId/K0T7EGiz6UeRA4Hh8S05ivto DtZ8lQqxVBuBtF6kQj3+lweUAa3IAsJgBh0dpdA4YBdV6UB8o1E44zQSC4yclBfhf5XK9PaPkFwH NbWERO1LFPrVbUrVrD8FUYT1bt0vd5MvieKcvC8QHhujVwecVI2gq7aDSFpD3dHcf6jUJDVH85bE O9jstbx4Df46xhHMCqXfqFHaR7tUBSX8eZTBJWL7aSS5QagqheLJbOqeguhDHkU9RfSbg0rxQiOS bIAeOKzSw7V4Nl5TBv3QWYqDgIZMSWSNDLpc3zBCaWlbD94C4TOMmzDCRFFNcGB1TqhjZZzqSPiP EI5axNxYvsW6fxp8ObAPDjn2U3dvqs6Tr6lASd/JNnOeqFFY25i6yAWd25ypMyjlLM41lOLato/F a88W0GvcqwderVb0ZV+nztZ18TqOt2eCPRpDQC1Tqv5Cmg6x33zmLA1DcBBARE9htNJghph3uFnX AT0YnfwwxYGVACZSMPo81eSoCfNNddPeegndUlFSG6GP6aJivpeK+ux/oUSCEYgxaGLg1grEL+ls S3tOcX9GG8b1lZcuKDMPV4aCuMCAIW3/yRId/Qvw4etH9JnnTisjj0UBltkm3YZ/N5Yz6Wye0pmD +Tr1VAqTjwCxYkEudqSLmNvKTn39O5dIkqNYgMNOf923E/vJG+NI2mCs/N7OAD3xPxe797689zQd DLkJYyZgrL9GuB7/i0XqrgURQX5kHNfv3t++pLkr4eQhEWsxxcf/bAFFe4O6+7ErXBedvTiNdxzv rSPzIedDeeeB7YXa/50s/doLx5WeO8AxgSPCmnv8zQLtfzpH3zh1SGFwY00AFvhZ+7PjBRPW6mix 76Pwkmi8w/mHUNHf3hShx/5kkYZ7oWeIBvVVG6Q593fp/u+foW98CPsmJxQ6pB3PLtHeP0j0Vat/ QJBfV4rj55OyG8e5+Zs9zZwOa3/rhm3jH/YWCc6ZwyFi7A3TljaIH1txpxv2XfM0YnnP/vbv66Z9 zNif/3N7y5KkNvzv+V59+PMDmIEBQ86BqswGSXSWXIcVjQWQ/M2AbO/ip4vUem+ScqDTKEb41GGt hmKJhxJqSaXA9BpWbvAjuZrzSp28wFerCANZvD8cJlfrt9F9f66uE3YS3qqXXMgEIRtXjIaBYfQZ kaXxOkDTpo1TFUomlLWNYsMDgDjCvpap7GebtPCxKnmwpvduyNQGrGfvCzzTPEzZL7ToHtbCBbyR nt8r0XzCL1n/TBvlxV0aJUcwgNC/AGV6DtXZmT9u0dxLNKuiorzfC8U71v41y7kQpolH4ZX2gDIk FxhCXUkE/yxvY8SeSVd6lP39Zt9SRqmMEdoxKz7iOjB23OTBOVTXU9NhUsiQgQb66Jgbq3IgwO3k i0oJ1y6/CvUJnpBV709Y5AbJO5Rt/TsytJdEdiEAgofxEjLebHP5lLY7E2gWle1k6Ro8P6trOQf/ m3UstNL9bW/UKekQngIN2wYgsTxBnUgaVC3r8dCjzOP6bxl6E89wNhX885+rdor/4oMwDFsOhBON P04h5uU+cjsQXd6Xqit4WVbblUjPEaNQat6WxHsx+sjRJpcvOvYreUq0/LRd5IxxawUy49k1290s 5QCKPLLzLiil5BpXzh7ADHvzZqtvnHBECJTlOceVWkzCh/DgDQlq+5kWIFmF0uxF0sb75um1J9br 3PNpkA5Cq05Jc1TMkHILdzrr1L/9OwSE7QcB1N+I7Amd7w6Rk78DqhHet2Oy9u13MQvpwOkChdHT Y6JvSnkl5cpbCAGxqUuUUHhUqeITe5RVuMc3GbZfO88Z18yrmwUUk5Z1jQrTumyu87BSitvdvkz9 Jl/xcENylFewnZ3zPTvOrfbn36cJPrabGp8LUzGFdSVgfa02h/P3ZpKGWJKh089lOg9jsn1SK+68 ACqGc7VtuP5RjPj2qsUKK2YfdqwPath52b+Z536r/ds2txpvf/92Xv+8bW7nOLfa5sP33tsMsPas W3Qb5HkVy7wqRMAvqO7RIYRq1ja4qKjpwAbUGcIjUZ8eUtLjkAgWdejUOlqsfvu67gTFc548wxWU SD7UN/OON+v8PXm+tYS8iwdRtSagRvtRIgPbsrSqjbawCGqjQ7FQijV5KoUcsPWBXCrN+QL1Eel4 w5tIZJ/gGPVfj1UJtQv5eEPBX5jQLnIEy4GB57/RjDE2oezdrUrGG6nFYzlCbckCahlSybfE0LAq ZifcU1sx9EBjDf0aHtMrCMSXuhU/0CVvLm2K76NozjisQDNdJSdX64XlAKU4SDisBSQhtrOWQB4b cd+YelFqvRQ/jhDWMnFj15B1vUc99EdvxcOyEJU9kwZIMWqftP5hLdxR58gMA/G8R3MBmCyDioeO iI0pdixKDdhuy7UO5e5tUcw+DHAUa9WjXh1ZBooKuPqKl2qo2SAvsyVJu7ZmKw4vYQNIqhSuz2C9 EzgM57dmOrjwcnIcCU93qe5LqQ7tlkG1+bwXCXuBMDvyu8WOkLLgsQYNzKdmpQjaGIoNLVJgleeD GMpeGI/DK8mlUJR4GvJUo5rP+ykCNyZAeec7lQScu9dyuoxAi9szbq1AbBsTJG7wB6+t1mF0hPoO lMf4cArduGjEDhrKAkHmYYyO4D4N01941AQqYZgArsz2w/dsTI15sKL7lLvogj6dikvU9Kiay+Md Z9Yk+xkbhuGWQjyjHwmgZDIgxLLNvu+6n/a371Tc25Mcc2Q4XlHDVCPTyMriJYEhHVq4vlF7/ihP KkLpIfjHQXeZYpkai8ZroDAGD2HQCB7t+k2b2n45T+tn4roi8tLeCwgBemefTY8Ac6sI1Y2OmhUF QyxzMAA6ZHggVEHsDjuFzVEs/oGHMknhIPYInzFPwezP8kc2JwzwInrpmwv0awVU90Y0UK9CkQ7s pYvvaNChv85SeDI39M5BYIY+hT0xxueTbTpz5F6d/S7u5gYU5AfkfbgT4vIsp+DnpXLvzfxhn9t8 3HAvMSvsWvzXM22Z3Hjv7fvzf3/GPm13NwwG//vsx7wXN3ggb+zP3pj+bCbdu3uPjyzk9uF4nzOA NHSCj5t5Frr2YSqTvafalU/c/jyCbD3cTHcRLjlyV5ZTAhuxynNeblbjr8W43MKc36foDaRc38N5 uggya8UPyvVgeov2LPVqPesjCwFvcfUielEco/J7YRr1PyeGNRIPimhligqiO5TwPPDcBb26uN6r eezfA+FgEqifDdT7XANp9JO7crQWkMf8b1fp/rp+lWMotlK4Z2SB9pxH0fxp9t9VKeEjybpGaKaR vibRbXhHhMsMAjyFsjpCCKyDviSxwHkt9OBpoJVCPSGrqgGF1Y1iVFJUB+TYGkkZ0ioYg22Q/iQH VlE/QdJyMTxfU+RbXDtm1qiFcIOB6Q5TuxHCMRO76B+Ct2EAgyAS7GHlWKzxkIT+upfWuuGOu6qK pLy1REhpHdKqE01KukDo6/iQeu/CE/rjIkdKaYn3SAAsS6mxSTjeq6GcMF0m1xPKvKx8HeWxm7wk wIEA9t/06TS8mnFtfKJK4STxB1ZGuvCdrYTF9BmJf6lXFb+XpU4U3+Knql2x5Hlg2Ka803bDYg1U fhBAwxChtGQURuD1CTV9NM15X7Neb3C57THyK14AEYFhYXg7WL8V9tj7ntFbK5BbrUMWQoAFDJm/ QOjb7fv+59x25ejI+SOQsI7xclw5vVqNtZlK9I7RYKZMKZmXWKRE/gdgXKVL4PqHKvW9R5YqYo7t 2L6PgCWhTDcClEiYGq4vdQrKFRWyAfebug7rzU7J/gghnnCUTKBBwswlM1N50J1bRs45Zd87jxBR PBfPNiaB3P5h30HKGIqq5nKiqq4sJ2RmlenAAzG/0nMugDgx18qtLTVXzUFBwaFj18u5tTbEKjTP po1j8Z5R2EdavST7MAbgqmulFE5Sn0K/D5OKCclo/njihRbS4rg97TnqaofummsMhfq+uS5Blx9P 0cVPztfSzdyoQY7N3cjMrVHK0jnqqvFo1UcaFZdQyz5QUsEQrXGJJ3blQ1fPfGA5uAuzE/5Fh80P D5khTJwLbqzFtnv/sM9x511BIErUhtvOijNtLjgXi+e693nPQYPftj+3f3IqLlTmP3XCJZYjuXEs jmP7MU4f9x6CzfqoG9uuDcP622dTrj6E92w5UpBlwypm/fQK7o0Pf9z+DExPt60pE1LWKa8DOK8p 8noQRC30vij+42qtBexwACVhFd3rj1/V3L1N2vlgngL/OE8lf1KjuaUdegnYbPKdIHxA4A0ASd29 Ml13kxfIoJ93+pkOxabTl4eK8yVUdEeeH1L4esmoRhYSyy/Y0ajej+fqB58q1oMU3xXicUTRT3fR X5Yr6+4E7d+crchHMjTrD6u09BxoomQaIt2bpnEUUSZUPAbhTXuJPt9Y1t2zY9RKn++zeDA1wGbN drNruwrSKCQddCSvR4AgD3GN5mVkkzdIRqgH4RFMwvRrDbQsN2N9zT1Q7qRcwmv5R5hraTUbQM2E KUw3sM6t06K3r039ECBOAGO31w2EhTqjgfmicKoJD9lzMoCQXkGCfN5/K1dAGmsfMEzfphhd+L18 VUGH0geyiUdccwCpzKLaP/EcnQDh1SrfRgkA92P9YRTOUSC3dg6146r+XLquwze25gVIEun8aD1A Ln/CCBg9Wn21Q14YfbsejnPggdVX2hS1b1Atv5Tk6Io2UTMSWjYmo0Q5D2prDR5n/LFu9d9LT3UK JZfAM+Z5rU89HyMPc1emFr9SQ5g6XBdmYy3vQ4fePgqLmTYJPGPYO+8+mECK5U7vK9RPvzFHkZjt GcuL9dVvhihnzlkQB6h1JjOvFKhY3hy8AuvMZYOfpiX4bHwkVf/y3+9S8w4YQHMQOibX7WOEVzA1 BRPhYUrLp6Jxin25eBof0wnGvIgEeonP39yjl36TJOB82+/MgcUQOqHGU7H6209udvsz9t60bWP6 Hz9qVWhELftkcshJPPN3q3XmX72KzmW/lukG0hiVYeguTtBOkxVpnocptZ6TQfq7z26gOIftiE+O Nkzo17bv08I7qBQdAe4bCHLl2Hz90ycXKwUk2jjeZ2iOJdAjVFORraV3cP62osfClZx2XvPuX69n /zBGizbUOgjt5DB1ERGjqjy9FjhzkiJSOI8bSLaZ1/c+/mZeTTn05Uaqgzaj1rshkValrniPU7J5 t8K9URZn69o4DRmZGu/HgdBJpNWlxYlHqMJtXx7rDp50pZckIq4uqJJO//5O4eaXgjEHGmp1JTZM 6RgcM5LEoEuI27GoLG5b7FE3IYFJknfGcZRCY6Nw6gFsdCz0OEsurnaAil48TxRJw0aQNZxj8lWO SxMfl9i3fX04bn8GWN92VxJJthZCWnlpTopD4mUiQAMKPTpDsVzQ700q/y/qtSIJD5liwl7yCIlP dmlRaaxehWo/7rP9yn2+SUtImJfDvFuDElpBQrgNL+YMsXhjFEjc3a01CU16akOW4rfgaewh31Hd q9e25iqb1qopPyKCIBLDm72qJzcR8GXo2E/R8TAV//6JThVTtW4UO4H/D6FpwlemgFLS+lXvgcZj Uzr9ahD2JOfjoApJ2AWC8Id4UavheVoUC006zMEwZVwlL9FC+Mva2a6GYNA8lF4oe9qx+sdJTPei bKyKvoV1/sbsJCUQMrK1OLIsRZXfSXRrzTROPuABQxQaYnEY4T5IjYdrBEXYy3qBjBDuisbTsDxN Bh0d+3kf0aB2inUv/1UhBuOEQ3gZTNiYb40DLIFc0lqQiNkAGULrQISlh+jaJ7O0F0TavQcblf0i BYUgqwLqUR6PUgTItdxBPU5U2SBmbQCggxQdKU5QCaAA63c+QEfEM4S3VhD+y3qiUYMbI3UB5W3K MoUeOiMLQ1W+DHoZTiyd6wk7Oqzy/5muUMKKVoA4ARKrCXLVk+RCvNzXftB3dYFQCLFWbE5uE8Zr m7+XwdPLV8KjxpWaP0ZTe9ys7R7teXGVPpt7ljANwoCQVaznhAruMiGNlb/N/8Tbsexvksrx9BKe F0KyHYuApJN/mKCd6PG/9v+2T+1vrAKs+HlLz2vfogyNdyHs3f7scxvT2zNhIRQB2ZgkcRwcZ+/b tjZ82wSGc/ySMIVQo2GQ2/Eh84LsMZveh23KS/+Zh2TgJaTwmbllURbCs7iAbTS9X7hWwoEghWQR zkrF6uE6YhfBI7TTo033ZyveW0uNTbSC8GqyCtq06O4wZWRTsWP7MC+KS7t0drb6K4KUAhx43Kje P4hhp0cupoOY6PP0U9haTqxzN8m5HMAQWGxOeZAMPfNwrsqwpBApiuKhiCDUsSyzVYWPN2gIHp8T 9AuxTml3hjcq568o9Noaqxcg09taQS9mHuT2B2O1FyinVbn2YonZwxVNRe0iKKUzdre566ynRepR LNgeakVGOQaFyMonFLEECyv64ICafilRO0HWrILUcfl3KxxtxVlCHtZFbzMIGKO5Nuvvxk35IObn /0f7CGZN5r3arO40Ct+wMCOxwi2WP0b4Yz9FZ1Gfh3332xhoVGNf3EQeonpIeS80abEXmCsJ3y2d FSiFRu2iJqMPg6v46qhW7WzSyY/n6fVHi7QupU5Zf9uohwmfnKBXTA5rIn4fzZ5Ke3Ric5YKMTjS UFpz/6Iayzxa5+mTUYEFHIwBM/ko7N7sM451cYoeITXAzWchbI2IcdaxPo3T7ZDlquoVyTqGxWxU LMl0CIxsHFLEFQgXsdCD8YBjrvWrFY9qiDqnLJqTTdHYLAqRlPlXTZoqIKfAaxsDXvrbZEZqjGPa U2+cVubhWsFgPwroLEJ9nGtIIfltJKD2rBTRgG1e54jCSKhHNg4DN4aehee/8e5kHYaSJAPjzLpv tpNrymzpVfbRNkUCX65COBfw3RTCRDGnoDaaR+8TWtRWUy1/HI9py+kWZb1BNIMur0GXR1X/2TSd Rnls3A3RKAy7BrNvo7r+hCGuyN8s53mZQvwcfjRfaVT7GwjByizaS2LUgSLbuK9WIVfGVP21dFXD rg2dl5MvrV9IcvdlNmG4qDJqTZKCVQ/J5SwUczL9X7o5pnlNJnlcOJvfvtnijw96GG36RC/WeD8M uasmdGUHPRw+ma/UvEosbTDd9NCIpRjQ2Za3kIV2TSavbT+smRuDaNCMMfMDCy9hSuGlZBddVdrs Dap4nCrCW+zb7cCSQPZ1C8m4A8zYF2+5XAAPjxV52DFZOu5rN/2YuW9bvfbPFAhC0rfzmVtPv+cW G5uiEKyepHp7rC5+bonW3Ye3YYfg/aI5l3hg0EOJoDzwYALJHbXXlejkCwnyLEWB+gzymTv/xf62 07Y98MPcef+wRWJhqzaswzISjIbSuO8I/SBYdMdZrNfpKpedDWqEB9xgyaHEhJtA76RnwL5qkztj f3ZpVpSWD+23hQZaeGiMtuI6RWrWL8LmrNy4lEhe3nG2VXHACS0efgallU0ToejtcAixk0TuVQtW XPfsaJpJ0a+BfYaiYGectv/0P/x9uzNgUoDnoN0Toet3ZmFdEhcnsXoEFFQ4AtOLELLiwcNbszUP 5ZFMcWgFHsaJX4Zp+7EKrYL36fyncvX6IwW6+4dlWnG0WYfxOs4DK02q7tOKpyr1xueLdZRGVBuI 12f9sFHtvxqqYWDAnoZezX4WqPD96XqJ4y0nlLO8rFwxu/u14kK5+leQu8T77eaeD4MSa6Eb3wBJ 7HTCPFadPUg+JSpkxNVwmLFT9Eqj9ECATmLgjJGASCMRHQ7tRskpmisBJY/Eq80nMWxehkHKWzKh O1+ZpqLZccqFdDHiCh4xz3t0L8l3aEUC4cYKbjb7ntCprbJE5BpzUTI33IXOjN4+sJf6kFb+4TUQ HEOxUMFdEqlKwnctXE8rtPVLzLPAazJor4kSa+1sQj2nu0UZ9BoxRoZOet3UAjMONWJHjNwuwof3 769X+k6eMSLj47CI1H4hXWV4Aut31brGV3YZ3czBIe5bOLJqxas1iqge1oHfIqQO4q342Xo8HyrP V8Hoyz2Zf6FDKT/uUPeDvIYTLILnyQyFesgYjYLF2vomkAsZhjb+yqezQdNBb/QmrXPhB7OixRQg yLUsF7NpbdyGArEt3//j6eQpAs88iaAgiwUhK0BuBXPzkjIpYGHfto1vTJ8VUnQKBMPkJdzH2Xgg Bh+bHoFWmepK0P3v2Et6DXTBDMqOohLgwQ/r0cIN9brw+Gz2zmp4+7DDuENNKyf/YWds5zax2Ah/ GEhgphKbsdlbf7ov2DLjnzvkW+fs38gdxu3P946F5KJKp3T0tVwtW0+4LgbgARrem3MVxt5m91C7 Rlvs7+q5uWrYC0XEBqpdP8jkuZ2K/1TdNbiz9J2g3RjCSoPpEc67WEVRVNK32hR9B72xib0OAGUc Jnxl1hdqVhH8rgONUrSWZmM8EDZmzlsfrxMIW+X9LU2nHklUAwVjbSQpXX0AobB2IIqpFDCm7W9T 3Bt0ocuLccR5PdBf2INp98KsvSGswRbI4+LK+n2K/sYFuEN++OO9zgBTy/8WGNAlFHYoZJ/x9Iex ZdFOeCYaq7Zwe5MqP0KhGkIon+52OZVUgKPsD/9KoRY/X6MF/2+54r6WoQtwZ5WSG1kY3a7Xge1e W5WqFf/9qu4au6p6OhsevDNT6YSijFfKqsnHkYBpe6hO/8dqDfxusI936ZFMF0qNpJe6hz4g8U8Q koJx1jriZc6DGgWYbDzJZSMkNai5PaaGULQiVEtgFz+OcIVBYZz6IQ+5GOOMCqBPkAlHs8wnqT+x i7O+Gt4XWrWR3IflZd5AAeZTiW75jzZCWX1AcOPwJqwXjfVACUZ4BnXwj3DTKKzBjp8L7jdj8e27 K1pDdOszjrAK0GuWs0imdiWTxPrc1+rkOQCSLR0vBhj6GNXql0iKFx1olWdPv7o+Gqftj5YoHOW6 5EizUk4TAUDPFBxqVTDXE8Az2LMoWlfvpMCTcNuG16rptw7cFkh9b36ELt+TKQ99RZZtB/G1o1fn SMZX4DU+9Fq5wujJ3rktTofuzYZOP0grgROP5HP8DV6V8ex9fE+tkq/1aucvl7guigEooQrqZLoe CXc8WXl0Uow90aPyRzMUyvUsBdVVy3QH0T3RbO9bKxC7ITfGTS9uvPte/jA55DyJGw+63T32gEl5 k6y1Q/FGcEiLfvXPd2jy/7MEtGl+G9AnBPbr5P4levorUKoXTgs6+8VVtDUXA4slAbXiiFtMs5fU AwAr8H1oX/8/cFjNixUnVu6K07VHN2jBhl1Q3hMKo9eKJ4lmLxPEO4NBaLSl6c2fFCh23s3hvA/s kqan8qb9+W87eIlxT4ijYrDq8olS6C0Q4lFYdu0RWIUgOMLBlttDHGZcSiiB9lKPK0K7aX/TLyzB PlkYwsNIy1C2H2ChO2+Pe2h079ZL3fIYE2xjjJ+G25jE0ryB5uNcLcbciEWaQZ4lFA1lIawPxy8+ A4EUJsFdS5W41SiR7cMrjIBiobE4ESbpMBURjkqk2O6AhSJpe5pHB73W3Hht/9JcLV9FvuHZRtVi +V7flK3Fj1VrU0KUruXEKepPZisVuGsedQvZQHprVoGgiotSE97MoCeStQTB5vV+FeGJ9iciKOdA dcR9DuY+xy8YU976bqWfwzCE1iMenivz0ifTQAMxrDO0Y0PAoh9KClXHYmo6yJGlUsVt4oYO1G5f kyi7KcI3Zuy4wfY9xeRGSsnn0XlwdVmNOsnxGROD9Ry3WmTwpBriOHXBAHeI+fdioQejPKwa3doz m9ecTQOrCEKx4+zP2IQjeC6KaVu7vKUNMsJhFA8nSG3I4KZ4BZN4t2sQxcFhNOm6/KkipVOvYrxx +SimOS/XuRYJI/k01YMDzjyqsbxwiiWTdJY8VDKw3M1sE3uZSn7qWBrIeZwk/xRv9O/PVCqWJHnt V7N1qSBRW4+RcD+C7NhKWOrBXECqQbof+G9cDcwC/6VQlwoT9VFCY7kvdGkIWG8Y99mMwJUwEcSD Tju6JUchvFdY16Fejr9jYboeONelWBpZ2XC4JX7fWoG4TW7/h92SmZbmzG/a+0EE2XrKDD0F1DeA UI0JJ1yyEBBbVn3t0xC2F9sPFZqBtNbMPede3/QDOZFwrYSwFzuwfbhhf2BhUJx4/kCqZi/mI6yR 1PT9WvKrC4HdstBubDv9lf9TfnHJRlMy0hAC5T1FUCt2OavKlG2AJcnNXAJJVnZxoepeIcG9whTI v/XJv22yeOkeOrtN9jeewrRGd9w+k1iSpgAsJGAUI17oRlpyY2hNa1BJzvVtu3Nnb7BK7qULI9g2 /jHjb4fEcguFXUy/b7+HUS5pJEobaErVXRjjCqQE5PLD8QvMwPSaGu/u1lBtDQ9sEIB0ninmOxCs Ck6x9sJz1ldC+OeJc8oIoHdPShSQ2HEFV1eDzgnWyQjYXFdNqb+5TsZhFuOF7v3UNZ5nhB8GwEAJ 1O/A6HOfrFHyyUpF0C+9b0uGurHUDxJlKOnuU8Kb9ALvbVbLRqhI8AKSaa88xr7P4IlWz51SKQSJ Ibj3Dsln7qx/cH7GAt0fHa7jBdnKCR1VXiWMCUaBwzW4WgeE4QgeczTcU2a8WnfF2nkpqsqP1bye PsWzpiZ3NCse7ybZXTjrEw9mPDKInAaN41BAV7elqxGvmbZCCu2eVAQewwiQYAMCeFBa1kgtwNrY thE56ZlU+7ooXcGzsednGCVSiKWfgiIcoflVcy8Q5iiS3Hm0ga6sUv7LJLlRRG0QiVaVJin/LDTy zGMjjABlKRDQ1lQr8+VajVQMkeAndAeQ6HAcJLRNtZpL5f4wzb56MbrOxcQq4/hlhcPy0EIEvywz ROU9zVoNp1zQvzaq4hOJOhraqyQ4yUKoG+kcGVZDVKJaGuuUgScW9Z1q8j44VxDAhqF0hk9BLTMn VgHVhNjauKfhIIAYExY+YbwvBcJtccOUg3kQIZHE0aLRTLy+5bD3zRLwf9E25ItREe2EIfNYZPbB 275sb/m3t4+mXweCtnrH4PNgrPZLe2mg8ktY6okV0MbDcbOUWOe4P2FgZ3p7lqo7H/8x33GwD/YN C8951kzoxA/jtenBZcosoehxxLocoiZBeI3zoJw7XOASxlYfcyN79cGexjv39rbb8c4N7Jaw0bRF Z3clgAc0l2TgZcj4mkCXRPmtvZlftkUzvW//7Z358c/7uw9vIwMG0wFoFeo4xhRoliAfAOznffXD z99tBng0AoPC1f/GG+7frTbDJtNx+xfJjz/0PUl+GQ5I1cmBWn77RxUV7CAuFPAD9+i7z9+0D+1e EZ1VHe/vdc6EGnh5xR5NjEq9xPv842P3tJqAsnVSxb/TCESB9r/lsO9fYVsOYucBs5ALAd/Y1i7A TpR0mzsZszm+wz9GJaViLhmLzHBxGc77ViOc4IaJTVvr9nXzgezvM/y7aQCEkf0zG3jfW59csz/t i1YuxmTa5dqjcNr30hVnq5EX+31z7fax13f9NtfP8M9dg02O7Ydrtctiulw+R+hMnfLtl1++D//G J+R322s7p6fZH/8Ills5h+8inuA3/zr4dc522Mu/38Eu4Nd2/ul53z4O2t/cDGJBlFiQK2LYNL/3 YXeURWekhnbfLF438bNgpWxvpIM+RWGH4w3+H6PIz9JT9r9/GBx3cjJWddfWsE+jRWGK3f+GXKIn d10aSsfemPElvhyIT9W8F/bMC6XUVTA13OnShWeoG2FVcK63PTie5Wgsj+GS2rf9xfe3ocnTIEya HlbxmYOFUMWccJDeqQlc5KBh1VWt1slvJip2PrFWMwX/jYebVqMr8aOZ/jd77wEm13XdeZ7KVd1d nXMC0AgESIAgCWZZEilSkhVtjWVbMx7L68/2fLZn7fHa67Xnm90d72q8+3k8ttczu86W9Xlsz1hh RlawSCWKFHMACYBEDp1zDlXVlXp///vqdVc3CgQEghJJ4QJd9eq9G8+795x7T1STZScBuWBwrwz4 sN9ymine++E+O7aGgSULIRwfg5deDctr3SjQ7zd1yTmiXquUE9Se8jg2VnkedmwXJxXiLicYeQ9+ CQ+qdVj9itWyZTpcXPT6nVeHgLQ69J4VoEYw9teMrvkD5Ah6WfAYKhSinmZSALmA3t2ybAIQtocy CH9h92g+hFGpFkukiAsesnnPaUOhUd195JgFdvViAwWRdciyGY9BCI9x2YOMC2Th9iZZ9YkK1XYQ N+RUXTnRhqsX+U2IY7r2Wn5SGczFjIPTRnmG6+RqPJMvN6UiGBQRHuFcw5Z29ly6i1wF6lJgwmZw mOg6Rd8ku1HYVzc4Bhjw1dNpIQBLTpsrD4z6VLsOUzotLlkeAC0X+1zjl35vgABOoVI//DGi/U8+ DyZZTvoGSze8XBqYcC5SeJ2MjHUWQlFALXFlOVh1wVXghRxSvcjzvtTvEPIc5ckDYzmzDGDfEkIO pPYKBFvSGgoKzrzsPO8xRT22ggxJZTB6CyL3CGDTACObO166KgIipEc/naWmLjX3iiDdSyWp4SZ0 3JU1NskBiM6mVxsNl2MekVA3VTGqhLnVJvv9f3G3DT4XxV4btk2pYgGjfmfBkrdBZMomiB5rd44u hp06ut0O/QC/2VF17+xHGN0iqGoeXFkCinKPwPx2hPHKCr22XPKnU32waC98tdfe9t5t1tgxwIti u8R6PfViD6F64xhUMYnL1JlfW4tbSpfBRmqK4bOsNr0k7ssA0E1y3o0mcegU06cJp5powiRY9IqZ LPVGGWpl+a49vWK9+1fgwxKydgthUJUK4RnGP1JhH0JHCI6CDkmY6Zwu8lyCXIVJDcuKlzbVNZXb uCAPC64NIWkQVUr1Q7zy6+m1QgBIC95Z/8R+cX3+OizP46aOvNCS9Dwgp3Uk741Q3+pGfX55vdGA WCCwqZT0fv03GNCu1P/hnnofKrtRvuzBpkvqBTFcPp9fyMvpo5IOTkdji308hG/n/kLWjUr+MGhL Gx6oil/wkt/K5ubreg7/l1d2owZwjD9vSzc3nnmF/XGUw2RTHmAYKMHQzyvgBSA0atXLu/FO/TyV 6gvkvPfkl9N7XOMvFG13nHRLyRcYSHELdCsTENXiZoY3kIqfJbgom3SD5RCwUhltIOT9tnYbTsoi I659x4ZinmRWsMdQ5aW6/HbYt1jLbgYAYo0TRGYTsSBvZoFub+mfTjf1fSDhzzTYg//kFmvD5oQt Ds4W0fVGkiZNre9lArdeOjEmxVZeGI/b/Ey9NXYOkJdx0+WlORBkO7uELTC6dGVX8UR1078Yjch1 w/QvtLk40dq11GP5mkCXvn7Hmg1DFJp+atkWcQcxBe86DqKvQmsqCxLX8OTGXfYtbVjtnkGTYxEC sZ7IIE5BCk2V8V/osH6c50kQuUdaL8QykOO7BnY4s8SbmL6LSG/EVJhGlpKBWCSRpwS0myoBUbYe yaeXree+tPVjg1DnL8T1xq5ffEcQ4DXJ+Lf6XQ9Yw/vex+ZQuycmhV7q6znvvqNOvl6ZGSTUAYNy O7EasQ+09Ntv3vwZq4uyQYGrcWT8I/YTL9xnuzBA5uDwfQCPDTgHsF3Lw0OfWXzSsrlJWGJwRcbg b/35UVhfTBo2fpUJiCbOeiphl/XfF1+ISOivPIn1FAApKpZHFp5f0/0Fq6nlTMbRMBAm1i68yMkL 7ECZoZ7aa3lpb/5qkyL2WPlzWYBXYi3piBgh2MzkS3XWf2q7tXW/RD6Gh1sVHSdfr7R13Be3A93n /+Kc5323YleAHevXqvAsXFOrQasWxsl9p2D0ep08/M6qfRpTDOszDVX29A/2EaIThI8WyEfHsujP z1gfCL8ffz4XiAUt78z4McY99YzF+1dxBx01ydblKqKIHKQBL58td6XtAtbEPuGTOEQaVi/jZuGx PkIX86ADVdG9h1FVFPtjlMhzxB+Zwo3CNw61WxHtkiAnnhuxqm0lFnoAlpbqEGwUFzp2HvcYqBWf xIIYJ9slmPkDuv79HUHAWyYWbmyw+M6dvChucLp0E1Awf0smDQzWEXhKTqCPQDx+sfOc/e+HHrG2 2CDP2vibsIFkL4eRPXjx8PzovSVB4QblwcNfSAGxx3CZsbBw3LI1crCCApRcCvmGeGJxIwapTED8 uq4QWhfNMW5IJrI6QtzknpDNDwXsxjvGiB3CvEzFLBhftlSq1ybPxohaCAG5qAK0NkC480exht3O TrzM6loBrYK8cQ9xM4iypJNQza6C08a68z7Gig8rOU9U2pzT3XqNHx5hWJ6H36gmGMNFw3AteC1H YxwrdQiq0BGNpcA7SjSiZdYKhS+r6GLYvMZuby3OMLT9akJD5IEVeNEQDdaU44dKe0QxOOQi5M7P nrde9PcVWlRn4yQhLltxw71GsKg4ee791ogrF0AbRh5Gb/rGqHVjyVuLZW4RjwLN1P8g2iwh8Xz5 L7XfemxCas7gPwyX1NKU2f5V3FOgJbOM6qSIVAgBeQsxsKtxd5LfH7FO3Iz/k/Mr1ogLifxtGDXh 8+jd+O9SUj+dz6wy2LkH1z+uHAIQjSJsCyePet0n3pV36/XIqWmiZVvFZD+C0sr/tv2o/dqh3+Tk wfTERRKYy63VZeYz23C4LARQk5DgLZ+0cY1YJof21dxDDH0UOCB9R/aByihrf/MCq0xArhZIwJrm HeBjiQJxQoiJXUuskP/Yb3e+E9G/2KMe5rfJsb028OU6qyI40saLoXP8l++ou997ylL34D+mFBJW XdKcjkRz9srzfZZbBpFJMlaWhKBlsHjyyTYbOH27bb/peTAV+SoxVcvKXd2lN5kU20MnjNKwy3F/ qVryMVNjVSzOV2uIbDppFV1/Xy3jNX4mkLObqO1PWb1iKnv0dp2IyEmh/GIlxrO28xyTCQIjc3W5 ISvWoFuPWq3kIN3fmnIdc/fYqTTgTbURnX/ndBEiU3uB+olTsKl+8ol4CDASxsL9ss7H8a6KMNW9 bNhXzpliKQZJ49FFa8rgp0uOEzmRxGSoVWrXOVMkf4UXcI0B9taujq3Z+hp9K49U07wG4vHSatx+ q++Y/eqhf20YXzPtasCRnDbQsYoEiHIYB6lAOCTPc4v8rQwURi3isZqdsrH5hy1fmAAX13HXu7+m neWWVJmACFbradOP9btbL3QUlLfYEKqnKDHY+/7ZI/bej0nBLYv32QuOeBVzWChHcUBGvqce6rP4 bhCREJKf1BSaV5HItH34p/7uImTg2CBipH/yl+3JP4FxsZWAwP2JVuOQ75vEUD9yo22/GQKiAFev QkD80TnCV+rKOkHzH/r949ttzMjnXL8zC+MI2SoRBn8Dp2/BvZwNV1bd+qXflOuC+wA27ns9y+t3 of6BzPPS6NiS3IlVz0HYeZzRrSc65+aTnkFQinVeWT9/kfxr5He7WRGICvW7MZcDD3jKjba/yVBb fnldu7joWPKu26VsbVeZrqfrELgMBDTvPOIRtX+z7bj96m0e8SiuoWkUgOef6YZdmrCOqglrjnkT 1F+fl6n6TfzYIxLZ3DTE46ucPCAeAdTk2fWHgrhTChDedw01Nm0wylIZRii7K8S1OZ/77dhBQgZr CFOEOJSvlIpYTUfR0y7mUAdjFx2NI3Rxisl8BXgAsg8m0D7mZPitL3/Mnv5kl9XuzdvyMF1wdUEZ EHoU3fERNogEeVuT2sWtuVwYiCasralBsTDY2YpVpT5DZWK4DBg81WCryFliVbjByGPVTPtrRUT2 W8bmjyEoPhT/KUHb+iaVjU8/RSRloStlhGCRfrv8WwGlnDzSM1WpYx/fleQ2LmPpY1M/1D591Y5c Gx//WXn+a36ttraMd1Mber7l+Fr+3GeNrt/bmv9y9avgeh4uKiXmHmRp48l6/o1b16+uQ+DVIMDZ 1ck8XsLjw2/1vWL/022/aYphVQSXiHgotSWGmYvwk79vkkc8VrOTNu6IB84XHfEQbsXBZBFvv2uo okkduHz98QvsdrmkBQsGZHcfj6PehnVJOABxwIomQiRClMYcYo3FsQ6CBgTD8PCFU/11znchtWJp 2l9eOmhPf/2gfeUTu6x6lygR/0ustYgCOMEWcbFG1CW/vK5LSQhVeeRCXRnicSx+6I+65/rGeGUr kUQO8tIf1dr0T95qXQdeRCeaPIw0grGhTkhOFqEaqE+IXaeDLMGwuORehpC93j13g3tKyidtshRu CORePkdMZtG4AhpAPgnxuywV4Dx63VLbyGb9fNJSr5wq9aNYXHD9UhheBfP6riT/vfnfWxv17/vf l3pedt9nG6vIpne6tY6tv5XdFfIqu4i4Vcjv5bz+eR0CF0NAa1NeLxLsyI6shux39hy2Xzz4bw1H 0454BALgH7fghVu4x7XwwVs/ecQjvTrs2FbFAgorbPixhisbuhZb5QV3WQLisXMAJ659v/Gl91nj 8zjRApFGEAqDYfk7AABAAElEQVSffAG1zh2Y+adD9s1//DFrPMwJAuF5eRJynB0L2NT5sF14FJ/y o1VWdwvIlfckZB9rLNr4QIN9/u9+wcUKx57lkjtu1RVBne704VoXQOih//7zVlUnooO3SWKMB7FP 8PhJZOyI2lc+fb/1HiUwFUGjdCIo0KzaUptSEdakiiTxpTQVsv/6Rz8DcRHQYMfwNXaOfFIh1njI KJcj+WzIPv8X77HW7e9wSgJqd6K/2mpuhY3FWFyFdDKMq4FvfeFue/nwLZXzlQOIaxGw8n6E6Yfg rhCZQ8drLdElu5fNcN1SxTX56VooNSNZhTPw808d3K/4XHxFAZKk5w7p67d+8BcquT5x9SEv8fl9 euxVqItS4qbe8day+l2U1oeeVWrLL3/9+zoEKkBAUybCWo0wOY9kQvZnyEY/fuATXhiatSrwh4iH EngBsgEG4Lo00dz9t+pHiXhkBm1k/ksMPwPxiDNyjZ8/LUbthl2qDI/LEhC/rNxUfOV/7hAHqkSn cfu7G4d4nbjbWA3aw7/e6Z45xOC1uP4pk//YXk4JLQWrb8dCVciw1J9wYs3mBmP2uV+E70g+/VWq w69M+/2mPXmE5VjY/1KPk8urKolG6u+BQjBo1V/VUbBn/6zRvj7VTH89C1btKJpA9uH4huaXXCrn iPXxNMGj0Pj1Gude9XYc+ZUJ8NXfIMTt/LNNduIznLpE6OhsvBtjulomXhl8VefZx5vsFbTPXi0f rXmJsnpPF/WDDie2oWsd18v0M78O33odgK7ASc2XL4hdFWZQBXk/pu0iz5THsbHUF/4iGCzJG6rk GzpJyruBxh7khbt8yzi4awVQjEMGiTHCfxrxV4p8FVNUoBctoqJUkoUF0AgLCphY86axBXFRePgp J3QBLNhdWzpp+m1R/fV0HQKXggBTB0LBPIat/jIGZX9zy+P2Y3t/3zlaKDriIRVV1OyzXc7teXVk lF+vhoFc9jf5h6AizlEYQ/NzNrbwMAsS7bsy4hEMEOiPXXehiNjBYfzKQ2a5V0iV4Eebre9CjkEJ IU7H0sGtuHbrIRZxywMscBCFv2Mvr1X5nT0Hu3m3Uy97KFwRxl6k/T6wypZ2nc0H9zRcP0kmkKdd 1df+Lj5KhdQPGRw6ZYlS5vr9eWvk5FBeXoGhXB/8tnioftfto/2y5NyGqCD5ZBzn11HVnLcaIqRB u3nIt8ZURhBdfuQk1W3k6/RLafwerPxmy5rauORhw4HNmmWqW/BzSYW53nrKKz29ui8h96WiTby9 yQZQ05WthpwchiEgrTiJ6/z6lAshewZX3kvNqNfSB6ngKl8tRoTduJyuPpG2ufvr7SjxHFqJ07Dz H0YRugft/D/rtCGimcnGNI5q73bsPHYQ3Gb8AzixI5ZIDLVRqQ0r5bD5kEuSfQ8PE6d61c7/GGUJ pqNoabIvacMeZOcjqPn2Z2zqjno7e1er8/i7+yujLgypvPyuv6Srg8T1Um8xCGhmxSEeWYjHWXaH X7ztEfvgzj/mLtqDa5KLingwOVlUeclHdfmWT4KKBkoU0pXjNrH4VS75DZ/cO3kIADqZyEPI5QFS mYCoDSGrLWlpGD81WI8HOTUUFZPCW/teXhEVkHWCIFFX0O6mmkVEtkbY073MdNiKIPyLXqz6Rnsh NK7iDVCOUl8zc0wMHUJgJ60j3bKWdC9az4mBv63PJd+4KHFLxGZ1BWBKAOOPtyyjCImeRapBhsBb hCc1CreVfvj9Ws9OfYKRiEkQA0tHVEusL+3gA+gIVGrDlaes8odrGHOjCOc1Shq2Yn4QkvNpjPz2 4DI6gm+dkYY4ho3V9u7htNXhnmS8o9ouYIHeSdjNGM8ncO892Vtn78Rb6i3/eMbyH4nYc1if3019 O6chSD/eZl/BKHBfKmtNGAyONiTs6dvbrXYo5bS2VtDQ0qudwZ279BIaiWegIDsKkTv+jib7JmU7 aKeD8JszWKx/rbXZwth87HtxkBCiEXueQD0H8BaKIt+lYXaNQHS9mjcfBLRUZeMxjeHyOPZgj9z5 Zbuv52+4C3+fxRYIiJeiqaOcEWuM9+snSUgTRLEpVVj4m56/WX5oHCIW+LlcftmmFzl5OAUnLaLy MYdhvaOBJDkIp5JXS5UJSKUSWAvf8oFRq67N2MpCzKqSvIQypCoNpXw+bC8/3o06LzIHEOUlkWGl +v17jEXuzGXvsf8jw5ZIEmsChKsh+smBgbaX5+N2+tkOBqtYIQU78J4xvnGzTN90evHbFzHS1jmE O5OpUaLgPd1iUewy3H2/0q3fNCjiUd2Uteb98/TBA/zWbPqt/k4M1NvqctgaOlN26L0I5AVZtesn DYDfq8iLIlECaa0QE4PveBUuW+DN4t/sVSMNqio5XVyaT9jJJ9qZB5ro1ygJNpwQ5Jdq98sz1vvF CTv6M9vtGARlti9p9UeWLMr7r8adyI2PE4L2c1M28tMd9jjBhcYhDJnb4y6imqFQEOWvgN3HDF7p 5Bpl5/FZu+G3ztuxf7fLHsK6fIb6dv/XYWv76rSLk/4k4U7j5Lv3U2dd8JwQYUfPvr/LMkR92//c uO387UEb+uUOm7+/20Zx672nB9sg+tFEXxXkx6XyyXGNQHK9mjcvBLRWRDzOon1Zh+vyJ+/8rN3T 8XnuSi1VfH7t7rQcfXlHzlK53cS4IjZ56Lh75rCsu2JyOcFe6fab9ktbXYJyQTznFg/b3MrjHvFw mLUcUWlNAZmS6m6+iFKUIy5aZBcvtMoEpCyfWBYSpham8va+f/6U9e46ChIUMivVV2pbqq+ZdItd OP3zljoWIlASzV7FRllEKY+WRH1T2j78039vrV2LTitK/fCTEL+E7QOnibx1+GMAJWgLTwXs/f/p hG3f9ShxR8Cv6h/5VE4nIgnQIxDTs8fvt9/+0/ss9g4eb+YW+dW7b8UwmX0qZA/80Zh98GN/aauZ VurSzsVV6z5Q6kUTbcb6Tx6wP/9ff8hSF0K2/4Fl++jPfwr1YbKUE3X134cV/cG41dWlfgpOgmkC reSKRE1tUleEE8rg2Zvt+Bc+SFx12Elkrph/00iu4IcqoY0VBhcFMVcfSVmE2AQZ+qngUUpaQ1p2 7vlExmpHU7AGeK5xSdCub8qL/RVcRd7B6UHW5LOd1URrI0bB0Vl7kIho9cSqDmDLEWVA8unK3sCl CAQ/gi7wKvGdV/FyKp21ek4lQQKjV48T7xxikSVCHDwJl79AW2+Jde0N//rnNYKAllySeXQUc4K7 qxbsT+7+lB1s/gbrpIH5iYbR+k7bIx7ZQiv2DZP2DxcetKlUk/3Lg8dLYrkS8pJVK5tTj2V9jTr5 Xa9mg3jMLj5j8yuPMSbg4VIJKblruCjIPoqomdbG9xJuow+13ofZoEsOUkKoXqH1z8oEZP1x2QXs hQhBZaS+G3N6pbyq0uLHHJn6YX0UazwEqz75z8qquKJLykp4nZqkw4FOsOoiOwNJZctlFLQXxvcu esk+CykLOpqZbMD6HCQXFvbmxQtjFwmZmqkC+cLvjGasvuG8db3rdltcrKU8E0MM/a2JW/IuHMcv VUfXAEiMbkRQXVZWzVB9+9dI72dnOm3xFGF666HcdFuIPhSnz6Ja7IRcErYL5RH+0p9swuJ1qCCr LvFe0U1eQ6AXIj4KGNjLv/WTcVg87d6BWFnXNAkZU2EDhGRsd51l/uAGG+qstV2zGQLgzGFxTp/I IHn35M6k5X+l18b3EK8NAtE1vmKJF3E/8k4BxGVjEuLnitCZrbh1P4Fb9/mP77IDz03Yzb9zzgK4 tslDJBRxTf63vFKUUx9Ejfwbqkug0GuXfENpE7UswdV7cv3zOgTcHPaJx62JBfuLe/7Ubmp6nGnD bjYwsz61PGLgfQ4udxAPq84+tOMvLJWvY6pprsGixx5N0zEUwsd7JMMeSe5NpKVVNkHfFDBXjzl5 sJBmFp+2hZUnWbeNjEPrp3wNMS7WVwjcSVxFW8icsOXsBTxjgEfZgQfcbg0RwZYxXwJbbcmln+SU fzUhvUIuYuklEBo31mBtrGmXyv1iabf6mkBMYckjanD/Hgpj+QgOLhZA9GqHP7WZZ4cr9py/w5dM IdGzZmdewPm7bC9gDxWdd+AiTgxb7PSRPu80RL+TdQO27Y6MpQcQ2l6CfGoOScsnSQjZ1s5xh8SK eRGEAN5xGxg7fp9FeJwKl9nI0DbLjOETi1OLcJxOFJJprJXg4+Ckm4xlbopgS/0teBRG/5hbM+NN 2JZUW7JlijYlO9HYvHH68NVvB1vyu3fwmgBc4d26W6hUMz0m8Ib7dE+9LSPbkEwiT5hOl+iW8PhR hN+ffrDXjvfUWiOhNJuJ/yEtNyV1S/SygFV6/eFFYjcP2jZiUo/Xx+yRB3rs+K/vcFHhnIaWwOdK +R8ULCMQrkZ9AIrr6ToELgcBTZUkk+9oLmZ3cPL41D1/VSIezWxqN4iH6tF2SX+r+e32ihwlEmYi GclhQMgGzgW8IaDV0m6bTO8hPjxIQnGJXAc2z1h36w39sUE8ZheehXg8BS3wXJMw0LKec43QNhDE N2G4iWUonL4ClwRfd1qA7FjDoXo25hBix4fYKHrlBGTTQi5iaS7KJEm9KvMeevvYjcqv5sqvTj6w ggGoASnAkVQaAZKzSOI62r/NchwogsgERESEd0JERRwdaGPnUA+STfMnoQKTqn7I9t/zPMQoAxzC FsMvWGMXnNAp1/2KXdSY8qiGJ1EFboGFJlh7fFPcPtfPwWoioD1sm8mhnTY/ZjZ6Om6JfYxeh56y 5CYqfc5DzOQEcmqkA1uXnLX3TjKGdltZTFhtw4wlGyad4H9pTgY8JNh4kvs42Y/GzJ9g4GaxAOQy lTV0DS7V1wUGvufUnH3kr0/b7oFFe6W9ijClqEHPAUjBhHZvOz1rP/nogB24sGBTNREbONDElNIO paxbbCTSPUzG0Ywd+nS/HXplxmlSPX1Tsw3/YJuFZtkQaHv3Ksk91YvYoF+Vc/vV+N+Vc12/+xaG gJaDiMeRXNjuqZ62T97zF3Zz8zfBCzp5QBS2pOlMhzttxML99uHtn7H62BizX9sg4RiP09FRfcZa E6dxY97CxEfGx/p7HZbdlp5dy5/CGQjDQUrT80/YfOpJ8Aresd0oykfCqOHwhEI847SxlDmJDyy4 I7I/0AZZiW/dy+YFy8277soEpLx+1yB8bSF0eIGiFatpNGcQADtVI4fcrv3q9TajHvbwfFnRNi9Y RKGth3i+HAiKnAIcAaO/EbSTJs7X2OxkC4LprM1PN7vsuVVYRqmoMyaUYZ4QUlPTOAyvS7CvHMDQ G08HcQk/a7HYYImAeEhUj10CqDW1xH+eOWj9TyYs0cwpoSRTUZ8CMgYsZXXW76jj1jXPW33LNCyu DMGuJumn/IaBulEp1F91nYJGcQ4Q8dPL489/tiYWlirUUfJag7u08yfqhsWw7Wj6wpy1EvFPUdcU ZdBtOhiU3kDDiUXr/t0h23Z4CjYfxJFjSbGOhVcaq/vm9HbhB9DC+tkbLN0Ws/2/c8FufmUav5YB m0abK4sTRslWfPiUinrjowI3TG4quJVYWAHacfW6l72e28uoTvl/F1VYlvf65VsSAswQq2PDdSQb sZ9onLS/e8cf2v6mR1k3uCLZcvIQgVCKBDOWCC/YUvYGW1rt447ml/5Um5fihJxQms5SBhz35ppa JeKB08HJ+UdsMfUseJKds0sbY/R+i2sCOxlCEwgmUEKCM7IOh41RyzJdJ5OtyYPo1rvlv8khFdv6 3XKKOOGQcqIGTSy0vJ7/9g+DqPcgZNEq3yi00ezGvau5cmgDhL84v41Ig/dB/DQAYkEkYG2JEJaQ qcYVRqV38ZWgDZ3tlUiBnf006rcJTkrSFisNXBn539bRD3sq7+xJtuIk9VP3siMB27Z32lMWwAdX Ed9X8ve1kaJW1ZLCc2WnTTxfjS0LOxRfIqxMjmfo5ZZigMYSjXKi4n44Dixr5zg1ISSOYT+DxlmQ e5FqhNeRtPeb+/4z9zyGIItx6QSzcYq8RpDWu6MqcTjV7VxXxJYa4x6S9wXkEBmGYQVYWrmdMWdh Xo3A3cku3Lvwxuo+gXEOx4zDnFAWe6stNJ/HrXvGUtStOqQEU3p1XiENgz+dSqSFFaGtKH8LSYgp xCHdRLwRngUVOEr9Ibl6dKG+l//p3vX0fQEBzYR6kPuLxPL4UU7xv3PPH9j25Esl4iHHfyhjrMnm o3S6YPHPZHZzmiBca/ag/fbLD9jTU3scrNZKrKutgBtBa1Lziyn9Jkk+8UjbxPw3MRQ8Cv7Dc4cb gSAmlK8Fo8QG1mlbIbTlflPyDquJb2chskDX83DpEmX8Yv4tvssx4sbtsoy61CKOYPsRDMHX4ToL rz6Xjdnu/RdAePPsmuGXx3BjwolAm1mHlL11vlHnVV1RCf/D4UlrxTWJ2nbyBbj1IYT2/oDUptSG UxMhGx3utUPqNJ0YOtNt2/cO03f4XZR1WIuZ0Nq9SIjdgK2IHtZwX8/Kk4gm9gjdu0H4knGjrrU4 3cMFhLRtAHYTO24RJR73n4B4oFK75gxQyispA4D654gYHWPCZ5ZrbWWpndocdF29fklHbC4S7GuX gIPK2JJNj7cgZ0cITdF1r8F+4av9pn/SnqoGZmf3N9nIv2+wqSrkRWg+1V2AcMmlO8+zapQkw0Od JnRvkXjY+R0ECdOL4p7CzSrGdNPEikWQl5zf12BL/z5iU13Vjs3VMJmyMBpezv06dekE4+iuxsNf GKJUP56yIDYmrxxssZnfr7LZ1oRN0c6ec0SJG2Ge3SpWA7tD7j/xP+6FmPDusQm589Fha/zyjOUh gDq1XE9vXQgIodezixDx+HFOHr97z/9nXdXHWRPlAvOiTcKuqkbhpiYigoIib2SO9bpINN0q+5Ub HicG+oi776v26gc+GNzK1DVT/E2UNojH5MIjllo9Dp6SzKOE4DhlhEKSY4DyHJvKU+vViCVoX0yd glW1xAIH12o9rycBofz3+oNLEJCN5+tXTnhbotLLC7VoEjVZx84jcp8CYQHLUr98ZMlNhdxyVG5u vboruxBGoa5TR+5GffgUDale7qnyrQ0Ao1gPJ5CTSUujOJGoW7Ud+87SNzL68FNpftY1zlhLz7It nEMwlBRvc2OWCDEV0MCqbU9bUwsCdNovpOKoFQ96fYY4y7dWGI0u6QwMnW6yCDKVi/pDnarVR/KS 32iXo9PEmSP77FP/6u0WaUaGBPITAVxPut7ozvpt/2IN4EY6ofulnbh//6q/1R6uSCKpvLXPZDh1 FDkpBKwdddtDY8vW/uSss+uoXshaC2q4DvnjjiS8nLfOybSlOGnkerDqJVhUJ+Xj8/DxmmD/PTtr 70Igf2ZPg50kmmENware/eKkdT8yacV6xg2BDolYEHAqJkDyjjTsQkPIuh6dsvshGGf66uzszjqL QXDuwop9zxPjTvEhJDbbDKc33o36qj0VXFu30XE/uL6e3roQ0JRtgHgchnj8SMOU/Yd7/h/rrnl5 E/FYWO2xqdVq21V7ch0QWuex0LSnURUcsHa4FhtJWyCxYpVLO3APafQkvOOy5tgbO9FvWN4F5L8T 89+AeLzCb508NA49i+BMtx05Bp4ltNkVktYTafto5SFjzhJEyiHZ0jNvRQIjl0f5L0ZMlU8ggmsp r9vdYzWdmQdR5NA+Cs9ZTX0KY0KKunMdFZcwYAQtJGxx3EIWIi5/PdR4FUkDw4vvYo2tLDeCl0b5 CcKQ00PXP71sL+lkEm8r2uixGLv7XkvUD3JKSsLukg6zlzweJ/x3eKMdCLJPpdGF9ivw8zAxV5dC 1v2OlCWqXnFjlLC7qibvsY/IF2TXrHKp5Z3YorRaRL6wtp4aRPyoK7OsIw4ELUk/SiyuIvKMdBp1 WGl3iIA4OLpsXn9eBXAiRE6ZoJT9NX/RtqIKth+es5bj6MmrL7QfwOo7Mg9QIRZiABx4aNhuQl4T JkpgHqeVVQjI7/3MeWJ+QEzIG8BX1Q+PncaSHIUHTsRB4iXv+fyI7eiaxhUKb02sqQHYcsiuFIRK QayqiT749k+fd0MIUYdzR8JKjULM9vz9kO3Yhup0jLwQm8ho1hkQ5lvD1nwSDa9BTsNKPuwAdyiN ESNOP6+fPjzQvBU/tTTqWAMiHh9tnLDfu/tP14mHtK1EBDQpcqjDe1I7QYHJwRN9Kg0u7YJ1k7He GuZvacch3OA/H1+5xRpicxZDTtLgZL1eDV7pN+KncIKsx1dscuEx7+QRKDt5aJQ8F1G8WI7BRg42 Vhgh+qrckDt4CMr8iXBowxpucScTyUq2psoExIekclOPNNkyMyE6iCCGBRurkmYScc2xpUjUopGE eqxTEgJhOsKh9q9BCgToMGO4474vY/8AFw/LNvHyxM5xU8LxN72GhIQjCKWHv5m0hcUbrDkwiEEh MhDsPyTQdvCgVCELsCKL1rYtbblRENuuzR0VnFeOBqz3Y3lrwJjRcnHkKbOw53AsxslDHns9bTCz Cyeabf4ksdiR15WfItzwQ3ScZhPVHgGTfESnEfU7l+WIiBWeQk9Lm6s0hzd3ZOsvVeoGrXq2PnyN v6lXhCGySNhOvUAl9Q2vwoKb/iILqPlJ8C3kz7leuaK6N8sbgRjorB+fIJIbxNXlIZ9gGR/iiIoj RZ1yZE/iuq4PigjRx6axxFcTPPfGx7VfFr9XLti62qyiLH+af7JED0OQvM7xTNUBFL8f/Lye3pIQ wP8a8/NFBOa/1D5g/+bOP0T19iycgEa3KdSQvU1iwJoTA/z5QPAmXGna2Y5az9rcIx6aywWbTt9s U5m47Wt4FocKEjjDyiFN4L2XyeXNW3fnjfbhEY98fpEQtA9DBC6An/yTh99XOUXElgUC4508tHr9 VIr3QcwPQc9bUzIoBHdGmyyTxasGpxdBycGPRa1vP4lcXyZRVLtyCEixyPbRtY0xGJaeZ17qASEn qFA77dIjai/v3mUqf9XHgMZVFq9hQHqP9EMaTe4mPZ8cabflc+yAtat1yFlDCxNMipMSp7TaZnjm uC8pEJVQAacktxDxkFxj+z70nAWKrZ1lgopINbfDFGEC+sg6SLspZBeS97hC9GcWucjKKYgKxE1V ucS3+KaFTD2yIl5k6f7sRCPaa1QonKzsJYKifuv0ctk/P5/fTqm5a/UlpF3kNLGGpbf70ynLx9E0 ohODQtuWq98K6StKoBPIaMwqL2KipH7yV0B+UmhEAYFv/557rg81UWpv/Z4u/LIQHJUtEPbWGRWq P3oMgFVO/fHLq++uH16W659vIQhoOjADHPF4CfnjjzeP2L+9648c8WCVs94k3yjNOzduldA0Uikh PD3Tp3ffLULuMIPcJx8WDc1bUxzeN6m39tucPi5W/3UP31AfjIkTQh5LcQnMPeKBOu6lXGw41pQP J2Cx6UQBLNZ/e/ASO0xpNTfitLTE5tp6CmHVVUg+nPVI1BdkF8dJYigkKgVu5viYqCZecB8xr8kr AXEcou2Qpd8/l/PqP3SikO+q3FIV7LJGdrMACwLi3rkmAv8bWyatqhd3GJy83MmHMrGeovW/gi2I 2JjSqwXz6PQQ4Cg6M95jJ164mx0xwrTksDXfABEhxsc6S4i+y/ttAo+7DQ0I12ij1CBthJwNSCjM rhtAynf9+Egre5dSeeVVeYhBmAPGxEi3jWNg6ORRPKhtFJeeTnEqiWFDE4T/qjFeI3Cpo68tqf/+ H/1y1+qc30H/mX/Pv6+8pXs++4s7m+6tu4D3y7gMpY/yev37fn08U1lXL89EOBwB03O16//5dah8 qawuN6Wt97f+3pSZHzwX0Vpvr/x5eVn/+tW+L1W2/P7164oQ0KsVCYhBDF5Eeef/7jti/+ltvwCy P8ETlDMydTaV7uVaOfUS/KQ9s9hSrFeepbEyH0t1If9gt8n9mcxeG0/tc89hkFptdBC7j3PklC4i Gx7U6pWaxMIiV3nN7sEb4ENyjQzxy0dmv2jpbD/dRFGFmBORiCcor9hFJ8+QXV0Y1lQD45IIAiyG NlE00loqAuQQuOdyGMsJrg6JiVSULzQvq7bTF6cyaAkxS423aRuqpxjcqI5gkJfCYm7uHvRsH8Sr 8Fc5tamZ15o8gqDAVTg/g3AU0ceWOl4oAhLWO6URqeiG4LfnfDEHu/Qwp5XBs+34rkIOUjuod49N R9TyC0lYUQucQJgYwCweP2bthx6wgSPVlkAU4uRKGitEN3mjWdeOca8dGpIjRV8V2LHPMEocQcPr xCNVVnsbYioIku88Ua7fxUps6xYB4iWsyL0LUzSBDyjZ0ajr9POaAMnVdm0+xJ7SK3RIU6cP4Otk CXw72QTNVJQtKK+QfCmfhqYkIbk7bek4pt9i1em9+UjZ3d1oQ6cHV5bsPtFwYFL9+i+hO8J0JXfy kX0KVSr5/fR+eZ/lJyH1zVlBlrWtMm68Wj+lPq6X99tbFUDotn+y4ucmODFJK8KE8g5+lIXL6sGv vK+qlhPfGxIrrQPhe38hkCkQVIhJ+TIbuz/c97T9iwP/lxGaqJRY/xj+ZTVpSUL82qF5JwvWJUbF s5lua0m8TLyPHhtcqSLOOeuSVB3GQWrpBYjI6LTiERxvjqk2pRnZgXBden3u3hvhQyePVGbAJha+ CWtKVtHSnNoY0UYfS5PRjQBuDdbk+cIip7a4IyA5rpXkZJGPjWKCDQRqHTFq4XJPhKc8V2UCohxq 10/81unHvRiuZQEuraxCJgFChr2Vkm0GiL28jF/2ar+pS04ScbCFD6Y07CAoBUknAD859k/ZaJwc BO7V7Jkw9iAttuc25CBiG2F4kF/NoZmVtTp8a8FrsTrkG9tuzdvxv0OYex9tqfs0l18KWMe+tDV3 cIQVwsB/leoVYXAJnzhIa9Fm2GUj/1hjtW/HCEcu2X2wcqn8oRjHaiZ/errVZibqrHc33mZlnOTD SN9lxbzKv0efDC2HfUcWF+vSsoqhMVUEwa3iNl3fMTSs1NfVOiaUEmtMuzrJS1xQKTznKp6HyoXl YZG8qUaMTUHAUSF9fmdQCy6A9KMZ8iBg1z0RiEx91HmFUb6IEDaTOFuNmjjaXdLSiiFQD6zAPuyM 23JXApDizn46a8khKL1YaNShfhboJ/sa9xa0+YjPYF+jNsiTp3+ruGYJy1swgna9n3Qd/sdgt+l3 mD/1xyW+XXtdcVtpxQ4FApbEpX1iFPkOrLQcMMoCqzCaYJLFZLF1cclHaqpKR3H6I9iFkC3F+NOm RYoeq7SraEaxJWx/RGT9dr1arn+WIKDVJk93QXDAcdhWf3XgMfv4jb/n0Njwyj58NbXjquQRa4yx 0XNJclHWF6kobUfWvGKcn15EQBnosraqlyEkrXZm/h22o+4xXHb45YQYhXgxisWXn04pHdWn9Lpc eiOeQBzxSPfb6PyXmeCoxYfarTrabQvpI56sw8kzGJdjSWmtibhooqHIgt8vlc/lJi1FvlikzXL5 BfD5Cjo+yiN4+Ely2gY2vPjwy0smJJuaDfyrXJUJSKVJTT+85Uk3CNASRB116PhONKSasQf5FhXr Oekargm9VPef9qIY3WUWQSKZpNMCU1NiFzkkX+qvW7dEG5x9JmijQztsz50vAIBVKHStjYzegCbV 08grOMlot12FPUj7NGBt9U4EqpDGCli7dfZOUW6C34oFIiKpiYmwl/YUpUsIVG7hM1j21QU5briX w5eSxk+WYhavlvjwqkFHPRpboQ1NyY2jcEjiEB3cNET+riQJ8a2zKa+kwJXkoa+BOeJ3/ECzvXB3 u3UREOrgpwcsuFy0E/+0h7ggCXvX5zjag0if+OB24McyxVuukP8SsLjn2XErJsP21I3NdtfzE9b3 6TFbuK3Gnvmh7dYwv2q3/e155l3Ajn2016bxiXXoGyPW9gK7P5BxgIiFw+9utmM3N9tNZ+bshv88 aAXkGqc+1G1n8LV1CHfu2//zmA3+ZIcdxyZkAuSt1ATy3nt8xvq+OIbgPGgnyD+B2xXBssBpIspp p34uYzd8c8y5op+8v9mev7/T+s4u2I1/MWhjH2q2l3BFn4CY3f75AU95AG0vvcbgQtFG3tNix26H 8McjxsbXulaydvOT49b2uWkb+clm+/a9nXb36WmrOblsT7y/F/YKho8inKQ0hC8GoWo7t2RTO2oc Qb3jywNW++yyDX60zV68q92aiLly+6cvWABC6k5KV/j+XQPfBx8Ch4iHRLcvQzw+deBRiMfv80uI MAvRmLUkxFnJOznoqmAvTr/DttUM47NpxJZzjXZhcY/d2vQSvq68XfYMcsnhFPZr9Sqn9QgeAIH4 p4/VQp2dX+qwnppTEKGNtara3yhJyH8lfYH45f9I98E9CLsLeM/NiN2kXb5LfHOiSMS2QVCyzgVJ JFTriEcW/1b5vDhJEkl0IvshDEUOXOfKCqb+ZAQ2nDaiEBxXd6nmrV+VCUhZLiG3EEh5cTSC7Ucn DS16Ozt23cm6SYTNQyB3US0WUAmX+l0oq+YqLxkQ/9cgIGv4uYlXI3gAbcvVRwD5iCd43ly12EXs ZW1yHH4e/QkmCnb88RttdqrRdt5EL2FHuRMC3U3WTlii/QbuAXDKCfFnh/Ewu3uRkw71YoGeRd6j OoNoVelEJPU/iVYuvJKkLJPPwxteJ9RXBi8aI3cvRbzxhmHBRavQfiCfc0dCzgIypbnjePttZpJS 15qw1Ksl1QsNC7ch1++kostkf7WqLnqmuthU5OALzHNKWCGC4I6bktbwhVlLcxIYZIfttKpAzJME f6plIL1DyxbNFywbDloVth8p4DSG3cZcS5WbfgpONU7ePMg0L7clwGQCFyY6qFXLTkTjoT7ZczRC sFK3tdopglFtw39WoT5sR7lO4Mak5eySpW5O2IsQjwX6cdeZWUckXtzVYIf3N1vbmUWrem7Z0jyb rIra/oEFd2IZ6a6xZ6kj8Lai3X502WlnDdCfXsaYxRPwwM2EJcbS/kPPjln1hbStoaqsOav47am2 qJ042Gwj2LDcQ3t0075xQ5Mlbm+xhofwTMwpSmPTySM+m7WdQyAnCOS5bRx9SX34EJMxZMvpBVvF jcvjxFTZtStpVd9csbEb6u00gbp++MSshcc52UrLrXz+uBq+vz/0Hrz45bCtYB996ubH7KcgHkvZ 3fivgoSEllGxHWUxaIPnsZ30rRQDmaYxEGxExliD8XEmuxfWVb29MP5+1m3R2pPPWJc0SF3yiIcu HWeF72ho1rYlL4gjS43qyRsreWyrfojHF8AxSaZdAzgJ90fFJRxDDjMQyXc2+i2V3ZB06kEeucIc eEwEuGi1iTu5DhIDZYhNuBCQOCN6tlFWI5fAPCfDQndfiOLiVJmAqB4/P5TYWXnDFsrlPZuGAMh0 ERfmZ47dYHe86zD1b0ZqftGLm/vO7ugVa6MwN9VpC3Pt1nfgaZDdRu1SqdUuHlHDehIrqvqmNes/ HLUFuFB17YZBYb/dePsTbp4FxEcQhqfL3X3jltwLSWJOSZNLzYkbuv1GsUeoFxW+pITfggd/LgYK 5Cmfb8DKvdlCSW7qmZ+41ilQ7L14VcoRED33Ti6MRqq9PJMzxR//f48jk1n2Th+lajZG5lfofQsO UiiYm0zaY5/dBzuO4zpKBZva3lzkO/sFOMTbV0ApsV7GMd6rS84TsAnnkVpN/NdzuRepWc7Zns8O W/UAaoG1sJnYeU++rd562M2nYCURyQf/VzhnIy+QhpUVg92DB2XqqEvnLY5BouP/U2+ReOuN3563 m25etMf76m16X60jOnMQnoPH5y353xZs+pfbbJiIhLeMLtvOvxoCb+Rt8RNREHOtpWFrVc0sWYi+ iZW289EJa/zsnNX+UicBqLoggLDg0OSSTEXjEHtu8oEmO91ZY7eMr1jPY1OOzcuo3YsLLBZs9UDC xiAeO/EivPvPsSXqjlhzW9KmI2Fb3QZbTjDCQl8bhTqI1/5jHP07wjb6Kze6JXPjpwctNIYnaTYd 2ZaoNXbAFqGviQ9lbKi5yvbh0qXtRQgh80vtXuqdq0vfbwmQQgT4ZKP2Mkorf33zo/aje38PJNkA y2maOVRnwysdjoDIR5zv+NCDZNhubHrYgcwJwnm+HVbV+MohO7kctQ92n7WOmgGeDzCdxe7S7PRT 0DKFemQrs9ZbPUC98D7oxhvj3QgqbDQ5Daykz9v4wlf5rRMGrHO4IlFYTOlVEBjE04ODxqTOS8Cu 8TJOsVtIWQhGKNSIkD2JrcgI+HwGLXlffqJ2ypOIMi2gHuzg4NhbW/OALsqLrF+XQ44Xql17okcu fT3jLXm1rW0ctbsenKSITgLwHJEVXLOk9l1fuWCVReOLtm0Pxy6acB5qfXkEQ9s6JKcxRsjaga/V 2PJv3I3R0dM4KRyhQgACEpFA3k0e6m3pmEU5II0zxKRFCUkrjazmvStWXa38SiB8zbMSPCTElyB8 ZqLVpgaSFoGAiDhUSs7/jvg8dFBt5ogDIvuPqmQG7bWT7s/VqwHoXamasrY21ak8IJwLh/fZI38D xRPCV9VbB7+p0Hfww/XBg2UNSH6kp8Z6duALiwbK6LVDeJJ7yFg0mCS/5iUEp4bY6AnyLsGiklrv KvKPPKcTmWqsdBKZEHnEMmyvnmkUInCDojIenkDpAQApdkhbd9LO4fpkFeLRDTHqPoILbvKpHsVF r8/kcIWGOje+3pJZyDz9SMcoLSNFusGhztmdSIdG9acoIwBJ+O5kNVwvc2qYwKVKhHmw5+i0JQZW Ld/uGR46Jwsp8nJCmYJVtncczQw2FRHYUfc/Mux8gEUhUnLfogYd6HkeaGMx40zSvxeQY0k8GaD4 Zy0vzVvPLbDexF67u9W5fdl3ZsqqT+Ituo126cf15EFAkFD88hSA6+c9/5dbH7OP3fAHnCharR85 Zl9ywBn3VYXBA6QN4uF+8ZG31UIz9hywYbFKdzZkLJT26mP2c3tfUCaS0F1p/bsrj5CMpXbaybk+ u7/rYU6cvE/hND6/90m9EPEI2lLqBALzr/MbjbRwK2wpbNPYOTvjP7FO3Oos7zFyHRkI8qfTh0uc UGQPMrP4mJdfJxYpQKmsOwRoN846C+E5It5H4KnnBOgSLJj0FVJlArIlo/ju0RrxzGAhUY8M6pTC URYyK7cACygsCWapjdcKfI1Fp55QcFbwQu01zYtddYRsZZHYGfWcEC6RwBPOVmRxElfkg23W1Qd4 8tIxXoEN5fVMXnkVICUQmHBykPOrtQAbcoEAvfdWBKaJI977kNc/IQsmtdhO8pwr5D1yoQvHjaj7 7uaZkH55cvl1gx2vNMZKCRICO6zRjr9wyHbtP4VPrXFYmAiFgVseA6YcMpNE9Rw4rwREv6C+3W5r mT4QhVD1lz+7FtelCiX8TeJaZAYfU2OHGiwEgvPbEhLWTl/soud+dpdbijpV7P3WmEOUNQiFF2uj NteF2jWyg0aE33nyZ9ohRJxAlkDoSeQSAWQrPutGp5oi7KPmIwvWAdtoinZz5NuDq/ha4rDn+0KW VhAz2hFLISg5A/1wSFwd0x/vQ+88wrs5fW+bDdxKPURBrKbv23F/EkS+I/mNiMZ0d7WlccfSTj9a X4AdBQtpExIX6KnLETctHIiFTjatz3L81yNkNgqC5fLwW99qu3ztau5qIyBWV3Q8Z32nZu3Juzos y6mnifgpnYdn0CFXHSp4PQkCgkQ1QF+BVd0Ph+DhOx6292z/M+424DV30jqrauzs4m7rrh7mlADL kbchtDa3CsHIIIOtw82RS9LI8tZcrljt7kSIh+60s5BBBhRdkJRGJgqJx62Jp77ZEJuxO1r9hawX +EZIgopwFD6qiF8+ufgQP0H4nD6yEIRouBFr+xVwIiwmaUsx6WT8F0MVN50dLA0ASAmxMdcC2vWR PDcmsLVc8iYvKxvcWAVxwUyD9gprOMtdHeK6nDxUnq/UfplEObGJUlM4zRMiZu5LZiA36XrzsrEQ K0n3feTH5VUn1RFJoKfdX2Vzs3e4eiSPWJjF2tQZEbLXEAFTI5XH5IhpvBU21ivE1+AQEURuISIg ZKNyTiUXoIsl1bFz2XKD2lWzQ305YD0HC1bfTD5iALgYHBQI0G44ognmEc6x0T4cMVJe/anQB+EY 9dWHh/JE5YwSPmx3H0JbPPe6ci5cpmKi521hhiNoCM2hIG6VuV/+Z6WJn0AGpGCL4sJd20QH+Z/h lFA3lbGGZdzhb6thhyPx4pbEvQJHixyuR/L8kQlpOkZenC7YeNt0b40tiIDMpK0OIpKCqCzD0spw kqhfxv6Fsutqs2oWjaQI1ug7T87qvOfYXb3HZi2E5pU0qMjikgiYe3la37qpn0qlb7EdzvXW2nOc YqZps0oaV4vyxLyRLUcflJZgbS3t4FSQ0enEe77+Wf671Lja1kHT78t6Xl1UIgSljOIqtBxbsGaE 5hmE/dv7F63mHKePBP14o+CpTYP57v8QqEQ8jhG//Dz8/Idu3yAeSF5dh+Igep1APOIB0S91MxlZ ts7qk/xSLcT6CS3YjqR+o36baXJ/7gdUXetJhEdpGmH6heUu7xH3xLqqiZznt55XfMsu73fvQz0V jsNZ6corJeIhFpXmL3MWfLGqE4gM/RzxUM9YK7ovgThCdf93FjaVJlsYmYn+Nna8/jgFm6gjPN5c ZqvGe8jlxylXWjxcXSpdPgcwlZylpisP7wx5ADgjmgCRcfpYTcPrJiysOqv/qSVUHOFyObmN379L tXzJ+wIQSCUOAohCEalH1uQRtL6yCKa1q5cW2KsmyoRxkjh0FkM/dhvoS9JPkJ7sQbLwEhdq8K4L LwSCvm3vspN76GWJtdXWBcC573aSaoTJnVlupU1CWiLDyAKCsfNVFkUAvp6nUmfog+QUi3Owuwgk pXeRw9lkNLYIS20S7S4IFARFVvIiCO09/fSp1ZZmURG5xFsRXCrhq0rNf6f3hKpngUEDcci7kTdM I1BfxJ16HAIhhK/TiTSc4hCF2z4/aPf+5Vl729+et0YE3SIiDYsZyyJbWuAEkgJZNhEzvY7A77Ox iM22VVmr5B/4vgrAcipfo1oqQvLJcdzYc6SpW0F7RO5PtEvXAbA0YPetomwm6OZGHcBOv3OUvf+R Ifvnn3zF9iOknoRInEO7qyAZiE46FNG3iOMCwvSRA43monWqrvJUNm+lPCFFgKlDdTZ+Lzu+FqJO qj9by5SXL127NqtCVvNyyrqAzTjEq2MEeY2CaYm9dj05CNSIeOAK6cHkpL34jr+19+7QyQND4DXf uAuFFOKW9y/e4vJ7Am+9JNifbAzT2Xcg57ib3zp5uHOqy9eSGEZtd9hdextBlfBebnf1oO1dP7V4 i83XynIFvqcfHvGQFfjswlMQj6/ScTgV60hBbkYIYBfpZA0w+bVDFlJ2Y5fqMuGyo7tL+T046VQh L7uep13hzvLdizzyriITOVeqhy9KOySuy8ukyqjKg7NXlGudfuQqPZeDglFCcTGk2hqDkKwn8tXU ItRBzi4PvW6Rrz+88guVk+FibdsqarccTWkvgKqshNIiJIkaxQUHaOoXhMFZp2+pXog2jHxior8W ATzIW+uVe1lkEJJDOGNAGfVxv7Z+wup6UxCnkNXekLeWlgve+5AfLsqo/enxeqIHQoggmnMzu+zC E3Gr7sMWZoNDtaUH/FSbVFFVM2vVtQu8Z4wxeyYgHhkIkpw8SnZEoKtcAuePtbaK59BljB0jUidV 7BHcxqwVURAt/Wm87hR1cUuv/Y6ArvoZawGV3NbnZ20VOcA8Ngti/bixlFoRYozN5Yg2yDuZwMEh qqgSSSUXYTHybKk1blkISPP5JatF/XUmIUIUtWYIQ2iK05YjIBQoT5pT9AFc4jXFtwM9PrQSnCR0 MwuVkafn4CQnE9pxGQVjvyoQe2IkbcnPL1oDbccRdss31hrwlMFgCgTejcbXvqcnnJrvICyllf1V FlzcciLSfKNaLbEQKr15iOLz7+yyR+/rsQxxSYKCxxUmNwYZQPpEUBVfTw4CgqJOHkdXY/azrYP2 qbf/n3ZL6z+wNhXQCNYjBoKeoBsVfjzo7qg7DKIL2YWlPbaiKIG8eOkz/N6JW+2ZiZ2uTp1CfCIR Yr6ITmcLaFKyhpT8E4iuj0y/y2bTt7g21tAiZGvk8IKeeel78bLoIWwjaT6Nz33N5pYfpSvquzbV sN8ce451wAkhnRtlomJ7BSEJB6WXLGRE+IXqGy2J/MJTYfFGohmt32yHqF/KB+zC+LWR8lYV3UVd PdymHfJv/G3kqnSlmi5OZbDT7jC/gtV5XxZZhEfRMytCwoqgl7b0cjNea9m1U2ZpPmpSCAhpB1/e v4tbeNU7wmcFJ72ttqUJdpD0oaYZnrUcm2mBi5/A98C5vTb/bNiSh9hhliNzJlYYFujSmYANn2+x lu2ngG+I/nq7GhHu1BLEkO8E7gvaiZE+dKzaGrZLQwqBk993YTTydO04TX+gjPxMpXfZ0BO11v5O jGtWywB10Yi8k5ROamFipahsnhOQ2FhhHDzqlKPqown02hvpF1k6G895bdP/oNtReZUG9FLhGEbj S24qXNTUa72hYdAXUf1sA6q6z8MaeCBlo6jDuh13qX6JkNZgc63sQ113m2dkGJ7jZLGSsQjeeCWA X8YwUDYRcdhHEZwrFnuDthzGRfsERkuTEBDscDTuTYnfuqf9o4NoqT86nUfQ+mpCe2oCTayFuzmG L+P4jpNRGCJSlcYYLw2cqcztq2ANFbZBfNUG90Q4PBmHV6/61PStOduGGu9RhPbjBxAWnsDZJjU4 diOKAaHZvHUgq5ihvcU7kk6WsYIRYgsEMKL+30TNW/uvtjYNqPSDfCLKLlUoU3ryffclUCiKoGJ5 /C89p+03bv9VbDtAf8TykKfsVL4J4XkjrCXCR0emtdRJepmwQaPLRBT0ZKBhEOG/PvApqxZnxCWx g+EUwK4aWbzPFti0VcdOMDeSeOw9QQ7VBCKlA/V4202Uyik/5xxNf5I+NF+8F/bde20e8cjmZlDT /Sqb9TGG20gv5LwVzguCbckmis5IUH30ZpzkFs6K3HU+iOCbEBvawbv+a7zkg+DIlXuIiIN5HCrK OeKqXLevExKUVYqouzt1Xq0kkB4Gig7pOBaZ1xY3LkqVCYigViojYCued3ZFrBaQ7to89hjwsrGq np9sw8EgOvt9aGORf3kB/fhFDlsguxL8L2rwSm645hmH1GFDsIHkhDA90GtN7ahVos1UZEcRI4Kf nssnlUtlb1p9DmHBvtQftsnJXcybx+kPFQIX9ZM9KScAJiFyjoameSzSs3bsc0Hb/Y6UNbRCDDXm smOe+OthseqyZiPnMCxUJWXtlXpQ8ctX4U1z6hjC9fueW8/B1uq0ocN7mCB6wVSk9lSltqxe45vr 4r4s8CeGONojyxFBvdL2N1d0iV8AzMklIA7SegoP5q3n3Lwd7cXWpSQ3ENuFfQTha6P20If7XH/H YWl94PCk3Xh8EIEx1uFoTx1HE2snbK4qjAirx+D3M7BhBNd7QPbRmZzlUYvdJLgudUmIdpH2q2hH oNUBsFiP9t+ZlG2fTjnV25WP9Lkwt1Mg9xsJTJU8xaTvoM+UmaasK8g7imBZnqVvC/S1gFaV0IGe Z2BHxVAD7iQw1Quo1568odE6d81Y1TAyMoiPjBurTtMeJ5WXdtTZN354h1McmMTG5UbgkTiGa5r3 0A51Ffz21H/gIvmRS3qFfuJa43B5gaMjJpqzb4bkFn75YK5Np/Vua9ktvIhniZ/g5PFrh3zi0QJi Q6WUtJKrwYK8xY7O32RNnGY/0PM1iIRnj+BsQMijdypr89qoTzzUVyFhT9bRnnzOOpCqYQrMfeQC JO9EAzpgTm5Lvuju6WNw6XZ7ZvxWO9T2DBENj/K8ylbhAsDp5JoM6vTrmjziIZXZcWJ55LJDrHHf o65YVjLoq4eIJBkfG7L0OQgB4+Z+vjDPt+ae/iA3ck3iNMlK81GdhwjkMCDMGptjfzAujz8wxQLR iYYB894jqPrWJe61FfqRyaHsAy4UC62CRBRceAVJ/StAzUXdlcQblvGbHCrWN0/AigMp8LJaulas pmPNpl5hjXmnxiuo/eIsbtq6saG5047V8sqSZdL1jpWWh43hJgILsbfvtNW97RYITAQET5/KFyfX ETR8hk7XWQ5YS6bikDlgKHCCkSzFqR8jlG7uoH660bV9AtxArG88DUtNsIh8QsJwERzDnQp2gXb8 mRaLbdvS1sVD4A6l2GVJTqR+RWOr1rMHrTJAeO7lHfaHH/wBDqe8MPrjv8aK1ZTdDHdD+LqJzwFB 1/q+JkkwQ05QN7Bi73l6zJpBzMV97LhfXrAHsX0Qco7MO6Db24iDLr6AL5eQ64OmIbTDQPQKSLX7 pRlrb1q2atR6JRGvgYAcwjr9IMizmXzSvhILrDw5WQHW51GM8t72wqRTm41w4hCyVdTDGG3f+rVh azjUjDAez88g6u0nZmzb89Ow0VDDrQvZtqOz1lyDceMs76yV/eZQyu59lnmpeUvdNchX3vfchNWP pTihoIX1zIz9IPWIWOaIZCgsoROQiKi0rg58ddhq7kZWgtaWaPpeNLZ2PAYS2hPagBMnKqdNprJE YLzpeTZRJF27VUV9IpTFZsb+yry9G1XmmAgVwbbY6pWD4I15rR3NNU6qMQmgX2J9vbN+3D5x6JMG x5OU4BVMscNmRUAAWnDFrr99dftQV62DhcVkIqm8IxzuVxTbDYIkBZe5z5ZOGpPuuaeaGwrANnaa V9o16g+4r28KtX7EyvHqTUbn7BAefldK2qXwGXC02IP7E/CBJsbrmjziUSB++fTC4yDyAfCGPOpK DiB8y2YFbauVzBl3CgkF8XDBicIjGppk0q5SH5mH7kQhRK/k9xuowd5Cf5IsIDvBQAjJERCX0fuQ 4Fpl2PEU4Hh4lu2lOYCvrWB4G02CD2Q3UpaujIBQj9g18jGjpLklTahwVAPhRqmvYU4LjojxvpTH H4IrdBUfqlrvfmmhFaO7cXcd5eThACAY4ONdp4NKDTmDwhuK1v9UxOY/3gMba4hTKv1nokkNWUTQ CdfoZAs7oajtto4+5Cy8D/nPkown5DSvqF4TEdZTanmHjcASi+Cw0TstbBlUGSzUKRGsWBxBH07c gqhAJ5LeJA+CvJIg6SjIjor0/8qS3v13wIO/okppW3KChpNL1nCY3QuaT4oKGEHOsRNXIULCLg4H le3+IrsU+rApya06KqvgUet6DMtNxf4AhioTI76I6nBllI9d/kXvSu0jq4ijibXnH6i/1J4T3Gu8 lEmeWrEDx9HOoG8uyYcU+WRzIhZb97eY1IBWYXIL3Isv5GyX6lLdbCKi+PLae2ZYVmrOVX0EuU3f F+iXnnPqKHcnIlgkhlftxv8y6LVHHmcFyX25pG88sWSNLwAn/aYt1RFcXbOdqo+k4FxOSK5yJJVp e3LW2jMzGDV6ZcRa+35LenPVfLwE2+qn2/rt/7jjP+Iy5IwDQ77Qac9P3mo3NX/Wkswd4ZkgQGp0 Hnd9SKkG1mwJ4ehksZBtRZX3Bttb/wLPhDj1tIDA/RCyjzrb0/BNLNG3I4QPQpDOl57zzpQP4jGe 7ra6CGrB8LS3Nfyj285Np+7FJmSH3dX+CDtx9kFil6vp1yUJB+l0MGeT84+iEHCatqppiU1PYh+G gOOlkwZAAbHqtJEvwCFxhMXvlD/RlkHy4KYILpZWL5TyaH7Ceg03YzvShBuok7DQq8FFcephDm9K nkdeN6G5v5w7x4tIQ7RaLVn1bltIHed0Iw0p+lKWKhMQv29+Rn471dFSX4U8Q7CwMikP0SrYk5JD qlxe681LRIRKGIPJsUp4Wee40TXoD1c/Nichb6kDj34raSsre6xlbQiELvciORjxIAAAOrpJREFU OBSDHeVOUcLcLObWzjGroe7OPnbOQCQa086kNFhXLQCg+fHBWlscgnAiDtn02G9aRdZhV7rgyxP6 M8GJJRIIaywUB+msYdHsEZD1Qu7Zd/2DfktlVkjRjUsIDruKYn2pXyWEJ2R8UdKYS39OQC4soaQy qs4v4+dzDyt8aK7LIE+p1J67Vt9Awi7pvupRP9WM36+tz9VuWV0OoWssfj9VXdlzfm0ktZcgr/78 fujaL1sOJ91T0uPL1OcpD5DXL+MKfn98CLXXgBReXA3ab+84Zb9w668T6Q/wIjAPclIocP6vJxYH JkYuBdnkOXYJhETr1O0cuSN7Duc5d63aRpZvJ565XHGkOS3ssvaqszzjRZDqkJNg7UG9Sjl8YXkb N7AWv73rPJqcUTaFiTAGq8hdcvlOcNoopxC1tgLxAFm+rknEA+8G2UnYVsg88E8VCHDyUP8gFjli fEjm4SaML5twyFtA0sg0Vv0JPmxUozs4qRAkD9ZWFMG6WFZeXZ7QXT6w3KmFut0JhlJe8haV5Cxi jzmWGA+CAdT46YvsUCQbcfYjJfj6JfVdWpnlt7gun+QQC7FMVmdR0V0FzeokRL9lC+LUa8UKWs+/ frGlwqv9SX38r6qd4dTA4LAUjxCLXFbeLnnz5ZKVi5sOubCBU2h2iBVKx/OoDK454cpGsTpCtHY9 uGw1qPcprUndx0+uDdrj/8xkl628hHaH2GVbh0q+AlyMBNpfigeirbvj5pMvjNZYAA/G3mLgWelY 7BFcCqquK/3z+3Wtv9W+j6BVt//bR6K6p+utf8rnp1crU57Pz7/126/7Uvf1LvTq/Xb8fJXKbb2n 334f/PK6Vyn5ZdWe/iqV9evyy/tl/N/l3357W8uU53mLXmsNVIOYRDz+ZN/z9mt3eMRjbS3piAc8 Uew3RmxvwyMO1ONYhS+sbuda6yWPML3GZldbHHREPJSoES0qHLlm65GB4OByBYeopSdrxPtoiJ+i TNJ+47lf54TSgPxkAiSoXV8eh4sP2PDS2+zMwi2cTurs9MyP2sD8R3GVMsqaTtq22iftnV2f51rE RojUfV3jD+/kkcGdyPDs50D2E4wVdmmJMChO+SryhzWE4WG5HsFo0CeiIpJh5CNuYkrzSsSFVBVF GwsZiWQg0RD4DsTvTXiFusXbLoS0re69KA60oXCEKx0RUwhUFYQnHu6mTBPsuiqriuxA/nELhNkz UJQV+0LqWfpGO07WsnkSazlenCoBDYwpQhIScgQByppbNhXurW+pYXMTWx5e4U9HpCBe2RXa4DSR Irb49HinLc5vB7BQ4Ep93FK3WH0xAkxdeFl65UyGMJpAePUtFGosx+lJVuCCSySWtlvf22/VybMO WUjWoRmpU0xmWUxaGiPf4AUdhyMODqUZu9Gi6ue9ZdMcolVeWEeD4H96GaEcXkBzhOLUb0U1lG2N Hl8LWG104g12xfiu5D1dca8FrMsBzG9T31eT/PIqeyXtXU0blytT3ofL5X2DPhfopL6gELQvMdf/ eN8L9nMH/53B7XTIPICrdcfrBGm+MPEB+9qFX3IjSbG+5NXfT6s4TpVnXKWJdB8OALeB1CftAzs+ ac1VhyEOk3ao5Uk3zUDLrCnvhF8XTdu/2n2Gk4nHs5cnC6Vt1bO4RFmwLr670Mx6ZmKbnZzd5p55 /dF5KcZvr81R1PuF78q6VMp7tV8+8Ri2kbkvgGOk/SUnpGqBNkHqiUi3tdY+wE+dwDQmn1EEVEUY yKbTQtgJ1psoh3nByrPILUa4DjtWlVP7dScu1Us58LWE7xncuONhttSe/BsuoIG14lSHVyFk8UgL diQi2P6I1ZjHVvMWBI/Kkt+zsltc6u178Fv/4Vx26B44sJDCGG+xCvsG+Gi6V3rBXF2zpB1+kBcX jUtmEXHRAFNLGHQNtVl9a3+lsVzcNv0KE/lv+HyrZTJdUFcAzAQ+c3SHNbXNWVvfMBbVCIay83bg rqN4F0Z1DeQfkvt2xqUTgkL3xkOLtsA8PP9czKr386p5fFHSu8VYNM/8dew+EVneQXqZmwxG792d nKhXWmX5SSbGDi/PRXV9D244B4e06zSkNN+0tZDAXP5KNJf47fJw7WtROdaQ8mnsks3w3096FhTV 5r7z5ssDn/fvl9tUN/mV3D3BXm5jSm35fXHtqD+kTXXolorTF9eG2y2wh9VaK532XX7lKeujK0P/ lEcbTj1242DRug2oxl3Kvwk+l4AHudeTy++353/TLx8G6xnLL8gn2Y+zNWHOOLjR/quWKS//BrkW yPwogoex6frjG0U8PuEOj0XYT8GAp06fgYsRR0C+s/5FYnu84nrfV7Ik994Gbvk5YSjJ5uPcwnab SHXbh3b8Na7a9+PC5GVejyagACxlFza1bPqGV/Y7bSpLHFXRUoINA2FoTLzo33DfH9j516gF64WS AnN8qPceUtetWRdQan0a6NZrSOXE40sl4qFgAJqkXpL/qtX8tK0uo3DDmHIiCgjORY6VdDrJ5+mf Ig9y0tCJYi71EsQER6ScPhyryReIu4WL8XIEVzpYpOczqssnBoxZ8pcCsmUhd+cmpWjzGdSdpQgi Xv56Ekz0p+R/e7/Kc3l39Kn3sTX5i4D7iki4MMOREMpYR1hZz5MdaphzsWtiB+KaVj9LbcqBYgjC 1drd7/7WICgBF6Njayc3/xYRitSu2cw53I33t9jOWwAgp6ad+4eoOm35FCyxKizsozNolKHNoXdE GZ0MlGSzUSO/W0BpGZ7r6DNVFuuQIVsFAOmW3ok/nym7NI2BYEbEbwmhfBb41OE+BS2l2mVcs0OI 5F5lywtRu9/VRL+FNMPnoJx0p9DJvhGhdginh8EJnAd24RsHQXYQtx/hsyzCWhBzMycoYCWbieA0 g0YuUGyHVyr5QOm9haYh/NhjOEE3BnnSZpHfK8EoPAlvlXKy2XDOEBG8hwdghVK80IMAFflQ8Dxt YZdRwPrb78saQuhCqzdl5ZVXfrWKHaX+iRBQZx7r7zUJ9XkWglVZREsroPqpz61TFde70prlz5VH fhFSXbCcpdUlB4xhPPOuoV3mZEOAJnwBNiQEoNDJ2JHBBHG8GO6X1hdjbAYYWnN+AgZ65qIy+veZ v8U2YCRFAv+en1/feg/UH5zCRYxUj1FfDU/j3wjcodjv3+tpUt7VV7vW65c79jAU+BhH8b+6+Wn7 yZv+g0N/a2vSttqQLYylduDnipgtMRQeSGfm77OnRu+wj+37XaaUzi8ee1x8+AiGv/e2Pw57ay+g ImaPbM9IYnX5ScL3+WyTK1ekLeULBFKws9qRi8zR9qodnr4DAtNs7XhIuLP9C9ifgL9cUm713pse 7oIPd/rRfLkWiXGscAoYX3gYHML8ANE7OQUtK4VA7k4OwakARAXrqtMaag/a9PLTbEohuv5JBCQj dyPyeeW5KmEqI+CW+3av9944dB0KOjU3rigjg0PgFeSeCJH+4tHtzqOvCM9S5iw4qfR+fGRIiY0k eGprsJEqE5CN51yVoEffHGLVogN79O4d5MJbDH6412Q9BitJbveTF/pS3tCmKq/kh5pVBfQwLArp 2tcAuH2FFQueLpbJY7goH+62nbe9RFl4rlUIlARr6sni6lkRFkP4oRJhcMQK1V0/OcMkXrbYZ3MX qqytN3cZA8ISxNg2VyURxkVxB1LD8ZkqpZHlxRkB2QE6te8P02/vu/pN49rx52rDNv4zra4/Tc/M YgCYs4Vbk/iLqrE61HmTJ1Ysszdh0x9utwgaTg3Pzztr9Ll3NthKOwuV7WHty7hoGUE+JetvTmHj 72m28e24XMdjbk0qaz0vz1r9YdwpEB9k9n0YirXErfkYxly4+sj0xm32B1HTBh6tj0zZCr/nP1jn 2mr+9qwt0pdF+hLFqLD5iVk3LSY+0Gw5IiTW0W7N+ZTlqHf8I6023V7t/E7Jgr3zzLy1Pjpnme0x m3tfmzu1iFhq+mgeySljDerLdU8t2OLBGhs92GjzMlIkT9NMyjqfmrHYVNbyDdgT/VSHy1+Hh135 s0phxT71Iw3OBUv9t3GCifaVqxh4SgNt7OPtOBTQS/baWuN+Ek23mrOo/5a0t9xDl4E8tCm14skf brFxDDgVtKtxPmNdz89Y9SD2NG8CIiK4+sTjFeLFfObWb9pHd//R+jCRpKI51UisDmKmsAndVtPP e2DdIbcIBDBGxbNEDxs5HT7FCljFxfpoqhU/WKcBLYQdpFoX804V1ZEx8nirh9XEvzU7t9Tr2tpd exJCQgAlJlQ1+GMq04h9EciS4HL1EQxEMWzdXuedRNYgOmJRsTVxZTc+NBrOIm6Tt3H3aq9EBJdT ZyAeX2aeaOGJQIJ3nFquCCWbEYTgbnYKeZeOwGvwuvVMY3WEFDlHFq0tt9vjs+AIi9huyuPNNy4o T92cSiLEOs9k+8FvDe52ASv3MG0WYJ3JM69zLEu5tAJSUYtXhwdX77d7Ga6s96Fd9kaqTEDcCvMz lX5ofXApo+giarCygctm2H0V8QCJNbWETbJ7EIIMwkIMSjPLyQL8erZ8l7ehPoJgi876fEs+fip4 VHpJQjAJqaHEW9+1e1L5Q6FoV+G7jY/1uP4olrs8CM9ONHESUKhc1DZxjyJgibiIXRYi5rmSIyjs CgWywZMYLyK7ckTePb3Mh9hnCM9liV7gGCzHi64dYOO02DhJShgv4cyVEkS16BAfcLrifrxaNwV3 3pFYJU8dbLMxkP3HBtLWdDZr5/c32SM3t9gHUZVu/Ny8Tb6vxT79tl67c3De7n50lskXsJO3ttqT ODCEb2AfCodtz8lhpxI88q4W+/rbuywBW6pmNW/nEjXW35W0+zPnLf5S2o7f3GrPE/Dp4/NYr396 0VZuidqX7ui0egDxUVSB53F//vd3ddsBYnY8+PCMjffV2ZfubLdOjBF/ED9ZtedW7Ch1HMXH1o/O FSz55JIN/Q/t9tDbOq2ZvtRgy3EBVyyne5L2AAz1MLYkXznYzuETbRXG7DwLg7BnAOaHigQVO5my Z9/Xa+eJ19EJscsxuZ8mJsoP1Mbt5r/pd6q/T9/ebudxEvl+XLPs/9I5W3l/tX323l57kMiETUQq zBEbRScImRYUCHn71O0dNoQn4SSELEs7GU5j+25I211EQKy7gBfV8pMIaykwW7TBf9ppX7mtzTpA vlEIzjGMGfc3JojqeAH3K7KNUedf7YV+756pW3LHHmANiXh8+hafeMSYHiAxrMtroqc13WFHYbcF AQliW+WS4zPiBaLqvHUnnwCdaWISuhjniI3ROlc+jL2HkJu3GrV7Zk9Ne14S4iwQy2OM+jnqkZJO PVf1mO1MYo2u3Qkrua/ucf7cbeoS4MX6KhI7fZdNZKptX/2R0kM9w5ZJjmIp6tXkPbryT7UpxC/j v7Ml4sE8gf0UROvJeb/VczcumtHOS4hQJw3+JJuYWn7M1aEdp54L8Uv118tLr/xTiesUZV1PdR/c jMZTVvYMnHSc5pXrDt58HQFSVlmkj/DXzw+E2+7UwSV90EkjDusrg3NGT54iGAtXebIk5VKqTEA2 QWvTD8fnl0dV7dQXZpDoMyMUP9wzqg7Y8jSR7Y6ErKqL1yLT5fKkn4IPfRUrDgG/5oRTJBCBdNH2 9LbKE2Xy6I7LF5bTYhKMvoMkeUSiDwvyk1Fbob3qBo6OII+GVjQRmDxxTkwLky3UGLC6NsLPyuKc sQEpboH4IynkIHV27pVuizTT+JbuVeqKy8LkLhBFcTWFZkPSlxXxMqlCruHnj3MSmmGp0JfLRiT0 G1G3oG2JPeiWIdt5zUREHYXtJHckvSOcMrYlLUNQKKneKoZ5Qw616WaE/yy8FY78YYhBC67Q4+ex aX07pwIQ5G7idCi0bQaLMC1F+ZaaJwLfLAj8fQpJ+9/H7NjP7bBvE0Xw4M5a6/rWCoGr8GlGXW7s 7R66aAfpx0uUVDKALp7Lo67mRxii0Avx0Ilh4uYGqz267Oro4rlikxe6w9aPF14Rj0PPTFgnp5gL P9RpDx1qsyEMEG/6ywv24c9fwCIcovf2dlvA3crBx8asCuNFGRlO3tFgo/VxFwPklv82aJmOmD31 /m3Wv6PWdvXguA43Jkna6eZUME5kxZ37OKWob/Qxyne5HYlbv6yJGk5luxCI3f7QkHtPp9/RbieJ 2Ljjlgarf2mJU4h21Jpj/IdllmmN2hAEj+lodz5BpMQzK/bsj++wo/js2ruryuLPIexsRKgKbN5o SUuyivm+gI+8YRDWZ2/9uv3I7j/mLvI/qdMWW2wq1eUIiMLRenILw17jLoTgChQVso6q03Zqfjcn jGbkF8fcELPs/qVKusippTGOISp3ZbCcLVTbUKodwnCOO5o/vAtSDFfvak9JqqdhEVxS2BEPXfGu QHmSRQY5+ZSzv+pjQ2h0le2uS8RJBE/pO4e6StA3Ng/eyeMhflM/OEWjUIhZERCfiGiSRHDFjkku fcfjATYfEcLNKmWxBhehkxNF1ekRHxCBIx6CPqUIPSs3JY6wSDtLBIcn3ulF34KR1/am0ayrBpPb yUIEA2Ym/XFW6KrLlfMh4MGUmy5VJiDKu56v9KPsnmCgE0YuG7N0qsHad8LDVJ/hN972wIDdcAg+ Nrs94QPJEbzKVIGXtLPPMf5oFffYSchVyiquUs4810qdor5+Tr7J4mDOVBLC9K7Lnl/mUsi5qr1g 576KX61/eZtVNx220XMYDW47g0yiz86f2mu79j6KsF7uWppttL/HOnqPWayaAWGAhEQTFy3NNokN SEhIW8fPK01uyHxQTW613mmtJeqnrR73Kff/5gBGi3qhLtOV1Ujbcp1/4XibTZzEI7AMGgXeq000 zdq1ADIKxeqYYdedJRiUovgt45xIezn5sVo9EHVxQOIgryj+rVCTt1w7YWtBxDuIsFct1gshZdOd UUseZwFTr6IXZuAfxIdz1kV8j92tVS6aXxFnigJhmoUVwuI8Mr6KvAEPy9xbHwrXOD5w+VSX8ufI HwUhjHXVWHdPjB06E7y0Iy/CvlL43WoIUydW6TUvZqzjtkXbcwMxTcin+dQK6ykPvM8S2ClPXQ2D K1Z/nF0tm77ht7e4eCVtWMvXHSWgGJb0jffgT4mwtyutMUucg41FWxFsiAY5ERy4t9bFOmclr/dx 6yvQYVpvt/kCLINHVm2ZwFrPtdc4X2PlJ3ONTTKfbA8RNCHarbh+b3pl0RKn0tZ5PycVfHYFxPLS 5pS8b7SkdybXJEfRLOxD8+nrt37RHuj9W+6ilgoiFAKNhYets3YYxE/gttCGP7c4WpF5EFQ1c3ox 22cHmx9zw0vlbrTzcwcxpnuGU8kcJxFvp+kj/DDOVVvRpNLK0b2x1I3UXcQ9yUl3bzl7kx2ZvMXu 6vxbWDgeq4g35erWLJOdSZbYOhk8dSf///bOPDbys7zjj+cej+9jfe3h3eyRbM4l5FpALaWnBEil qgCpRVVVqSAkRCu1aqWWioqqov+WVvxHCy1/UEFLq9JwKBBCspRsNsnm2PvyHt71bY/t8Rwe9/N9 3vnZ42M33mRBKPUre+Y37++939/ved7nTirUq6gh3DP5+uojKkv7b2rNVV+7z2Eq/5qN5Z+iIb1N As68s6yLgLMQQb1NhoC84nYojrlYWyWE6WL5KIpgU3rQQ9AugaArrmKrtsIKqE1ZsnuiDSEi3i7q 4z1BV7TVmNph86WrlNNhVmA/mmP0zehAavKjFYT6INtlpBOa3uhzYwSyUcm6vBi8xEVYP727LiI/ gBcp9hspmSJU6ye+FK1dyNTnyhg1H6gXDm/AmSzHLUd6UCST12L2D+c+bTeG2h2hLFembhxW0CQy CLHMegavgKw2v6tCYnLlPnIuZ+NjA9a75xiCeEKZ0kRrx2W79xAuFMDcacjaa6cH7cKJHcTseDGM WW83+3TpNOrDZ5gfYgL26g2Tj466MrZsbEZdkWdphngmWodsK55F7zluew4GXu6qxrROt5iaI1AO dd/8p0/a177WBIBB4Ira8FtJYovEEQi34jm3jOltCYpjFiQyx2msjZP3LFTGwt6MFQBuTbykuRFO lCCBfBd5lG+9MmfF7rSd6AE4DsCfewU37uewah9osVN7QZqf2WcHnhq2D/zPcTe2KxPGVnvSioB7 dD+npj+V11+oF8Zxq9O1gP42/GuNEOtj+kCTA/kKJ3a5VSlANQGqrIlrRS1c3BG39qcm7f3fB/Ag k5GPqwrzWQTRaUuVJOBfRGAeg3W0qPpQF2moiSpGgxJgK3StHrNFrl0LiuvMLC8vlNU1EFO/YqHT n7Zso6RudK8COyuOv64c1IpASoF+yshUXENNFZmX5FCScShmithvfijABcq9Xx+ye1WEY/BiNxQL 5X6ekl6FVpDHS9hWHcrO2Jee+BeQgE7arcwdpRRnTYUFnyn129X5Fru//QwKFaIEiBbYGCiNxWoL thx7oQDC7DKJc7a3A5972Gb4C+jZ0Ysn1hUAB5lJGX9V8+VOhO877fFe9YtPMhBDHhbNo30/BHko B6CsL/+UrCO0U6w2wrJqpM8gRB8t7PZS3dkLPjapIQpG7MhykOSh8aa8xBt9qA8hLSKXzvwY54bP 0rXY7xpF/RxwOprshH00wmOk0zcsK+wzOEpxnYSiCPHORTGJSgkCbgnShYjWjiY8Fz5PkFIGi/R5 BZXyduXAlYNQcQhkBdDVpBjdStKYlIeBdBwNMAnRod4kM4nhuqTMmNb3t1J7YwTiI4kK8YP+JNcQ 4J9lvafGd9m2gRsgD9gK8FRA8jz0kFYIo0WVzE03Wls3lpDkLcDCyaKFtLx2HDUVoErIQ8dOdyjI CcAa4KXX0qrulUdGCXfnkyNJ69kVldr8t17ILAji/PGsHXwQkjZFHGvYS3HGPz0B0nj9fnvnLx2z /t2vW/+u152x55SbyB36Hr662/Jn8Q+1HWAD5bS5FLSs5JJBkKhj2/lQjTVUs1qbZVf0PKyidPy5 ENUjCKtFqN9n1UZf3Oq0WEKDb/FTXUEZZ0ewBsabrpDCFD6gGkAWreMAbITdJdg4RZ3wAWQtBJxa 3E6MDCiKRk73fSenbaqp3cYArAsgEgHlvmfH7YmmhB19aJu9BsN5jJP8A7CWBp4Z43DAy8VDrBjl R3e12+RuHLcxUR4vp2J93mumpKWQc8Seq7NWor0r/KdxmJjW+uiFUAGSqJj49KJd/r0BG+bkLmF4 M7HNB79xDcEsDDatay05h0LvjoA3gDtKjiz4IUSjZqPfcgopNu3glVm7QcjfFgTc8ggcXsio9upv H5aKEMkwhVxAvct/WBXqXC7eI2TmtVSOC81BF0IavFzL/XuZn6MPzaWdRTzGe/QLuSn7x8e/Skzy J3l0YQc3sM/MVkgiAtjdmWuc9hVf21fFZxIE43zGZmxn8zHPG559HARBXJ7c87jT2Il1+hD5qhPa 07d+pZGLppCjzOCfLw0bbL74HpzAn4HCqVhvdpg22FcWuAiVociDalPtFCo9WJ/fwDp9gjgij1gu 1m39Tc9DBUHi1TZbYxc7Vv00E2hOaWXU/vMmHwF5iH02PnPEpueO8I7r6VYboZ1QkVUBbsrzroTY 0fxW5BlwdwS4AUJJwtdKeC5qRBRCYHmt7V4jFsUg6irpspMkGleqpxTa4mEH8LjmlwO3MB6xxdwL L+NJQemIhVYoD9EWslu3R1jb1+rfK29OfX79XJXP6kFV+QvUxCk85qpEvAwAxsKcMIGuOeEJ+JHE 5nFWD5uYyszb7HiX+5cqzqG2preG9mVZXuVt8fXjd9277W0sf2jn6Ke9+zLhaaE+9NKv2ozlkje/ oP1EB36xTvawKEBLTjCVMlb1HGRefv5RKJNdUEJE1CtxitY/7lIcd8A7rYD7rl1oxZ6Euemlvo2k WPLhyePBYh7azzLyHEVz1Nw1DY/xAQmfx0PvCB6HwwRZF5/n6s6itVqd+xZ/MSdpBcUJv9pDsKVZ BOmju4lXgkv2NuQiceQG+c6MzeNnonkG1UJ51O1N2iThZ3MgmRIxMooslpDLFHKERdYpjuB67+cu 23u/dcl2X0eNEu+5T/3idrtxuANVe50I4ZcDtB89Pmof+coZO/zMsIfP9bXaaInJA986QOhiTDfQ UirgNMkBONPXaxuqhdP8dC5tP2rP2fN9uGxH7qC11GO0qbRR/1QU+IFosYFrefcaPNyJRh4OJF2w rZu3Suy7h8KljHx3OXII27+uliM25XLfVZGvIyuSf7FoAtH3upo/uwwtkSiPYzzHH2y9Yf/8ni/U kEcnzznUve+GAHD0EIdBK7Kg2EdKuhdkF6sXvBtZiJDHldlDdnp6wMuGyYf21Lb2O+Uu3RPWlQEu oJDwzNUHaZt9wlO3kMdCpdu+fvH9ePXdwXMTNuhGYSfRCDtpE6RF2XY4G9fm+rwP2Ygp3noQ0mtM YVybf+X1jkMtwHIamfoe1tsR8tAaRHPUOKJr4B9AOzxZ5PkYo7K1MkIGsJxKlVHkIe0gyi7K16eo PKtSQwpy9y6vvs2Zu0AGgreioOiXsbXgXyuLW/cAYxSlsIn3W9RRaEduUOQzS9RItYr1OhpbKxQg lxskXokN0kYPqeakfP77d5+z4UsYpxAasqkDUp7MZAayB02jOJjcBdSSffCyyNYhm5OQfcE1nxSM iqMgA0fHnf9oQSMQQMa6JKFXIokvfACyWEGR2vC6gjfJENKSPcjw+TYE/9u9VCqNSi0H+v33niBG +QWnosRojsFfXZgHwMPTRUJrUxPE2T5KiNQDzCU8+zfpZW22tLDQrZ5CrgDSmJ3pRfayGyQVs4nr YHqXDemhW8SYEaALNZTNgaX92eHlQi7k4xCicaiistroO5u0pRICS121vUQIWiiQaQTiEnR3wJ5K s4fD7QS9AuC3j0NtwvJRiNqCBI5gxe8SbOn4jhbr5IQ9ioBZrJkrv9VnT3/lAcuVyvb4F8/YXtg9 YhldhqW1iLxCMs08dTsm5q33G+PWcQl2B/3UXpsNJ6ioHZJB7Dw/DRsIJYROAAV19DyqTz3IeoYq uKU58G9D9uH/vWo6PGYUR/1WiYoR60zNSatTSUBegKpe80lu2VtRxe3Kl2wEKkR9+4b5t65XJ58P 7cuJoig7/c7SSRIk6kQnQ1umiuraUJ4ULc5+ZIcd+et7Lf8wbj+wCRE71ZHP6m5+5r+EPF7Eq8In B07bF9/997j/wNXFEu8lPqVC0mQ4JJR2AFAlSNfMwwRlq1FaRGkB/1VlnQq4N7ZAJM5y4EAkYpy8 SdubXrRDXUf8OnzEQQrAHJwkBlih9vRCxin7E/vA3i+ATK5bZ+YGVEePjRR6bU/TjD3Y8SqAkl5Y 8FjDjPVkx6FC0LhD5fdg51P2zp7/RFOpGZcndzEetS2YtJLqtmUlc91VQB7yP3V94ttYgr/KWrQx s/pnj2cUVpbYW2E91IjmL2UKAvRhVS5/VDrtiOUUB7irnCgLfZdBIvPFIa5XkqIPBiv1lfV1Vlh1 ykZnvgXiue7seVEucVhIVTS4iuUxGlD5oKAgBKV+RelILjMF1aS9SsAGiyE7CciFr5skzWBziZV0 AzrWRH6wUnhXzU8jdAHmVXE/sIRtiP7FLazCm5SrdC2OHAlOjD3gD1jvrmsAfxZFZZHeRv+aj671 Xb9hUZ7rarPIOSzFZYSn/kKd+tK3mAZjVizx/IUY1IRIbPXHPyeo7buP2T6MneTZNwElINXbEGtE 7CIZEB60q08i/Mvx0jt/4Rb9aDg+F30zP5BlY/M8yI9oeblJ3N3jKgDhfNcAmii1+WsjiwtEIkxN WHMnvvdRQxSSLSlcMN6NvR2tp8qzbmrf/28xjNu6RXtym54arRDOtmR5Yl/kRW3As+8+O2tpePIT UBuK6d06DdI9A9tgeyO69Hg4HSvYe9G0evT1MY9cOEMsENl5TKMO+5PeZlfHbSY4Vd8J7G5gJ5WJ xyHDvAhoVgHIlVZObTrar0lrd1bIQurGrWgj9SELyTcRZEdAnoJZ1IGzyD7mQUqzjCF3ZI4w8lUr 0Kzur02Oj5WptUSvNwmrrgV23Aysthjx3eVRuMQ6JOlTWl56DoT0pI7beH3B+glNO8eYJZR3nL5+ +N6l+kmOQ6VwxppgTbKMN4m3Ps1FFIn0gCoANiHw2Pyia53NsUbu5Xe4ald7cvZcNzYhIGu31+FZ 4YhzR7ffB3obHx7Lg/fm431n7G8e+zPry73CSRq5ZUMA/EK6Wli5Wj8zrdM/6paeExZpstgJcAdh FHsAagHAFtGqKi4K0YRUrnZgcX5/rSUBXJWr2NGxffbq1G4vFPpRX8gBURN+dfI+K9DG0ZEn7Onh e0Eqr+Pi5OlaWfqGSu7OTNoYVMjEQi+sqVEQiU7bij+Ss5PIUQq4jg9JY1Xbm0kR8pi24cnvWKF4 grVoYQXqEZEeNMwFUr3ckwwj/BZlILlDAiogGBECM6FgxIbSfyjHYRIAnwLAh3XgSwlZRdrdjvRT TIi0frwcCNN7gWcE5UrvJKjWIPtAsLcFAuMROCogLmhAbEgkYJexodhYQjKyXBXrSxbuuudGXepv Vfue4R+189ZKhl/V5hdy9YMF5eFXTAsxq2McxfvuPhfm5+sEFqlL9VNRvxlC3ybTCGdYkwYGWp8a RF6Rn0K9LwFTW2w3yVR4vwC8TBak7H5s+C0S1ddeQ6KOXK5vJglZyKBw4lTCblzfY/dnjghsazAr yyIZRK39dCukpetko6Fztg0dAXmq1BxV4ObJKUXG7s4U0UgR21WkckiVcK2xrHq40DXvxvJUc+K/ AU/AAkri5Wrunl9roQHy1NdDz1kt7459cUrOEL9jcVerUxuNBIdKXoYqmijaBOq9ElI3I2hXzzOc vhVk6fDFGdvzd7iDeSxtQ8glhjHCm9rXZNkxnLTtwv7j7g4rfQqjwoPtNg2wbRsvWJzTtxCWHim1 1QDA9mXX5tZNyk/+vuEUU3GuZVwnFeL+SzM21EXsZ/JULiZbEJDAMOM6964em+5vtFPv6LZmIZio DXWn5HX49k7pEoSWQ/6TAYFcGUSN9mP9VkSaO4KSQA6ZUMsVDP9AXGG8vAaw6HqID9K6v4P5skG1 dpa/1Qd5en4LINlTH9xuxd9J2nnsYFpBRq2nwCY8d/P9GXvh13ZYF7KUe746ZI2XFqwTFuIryG7O oWqcu2fBZmD9HSCYVuYiXhNQ+z39oe02BptQqsFycR/ivavDn0LSXmhuy0lOEeVRN2mf3n7S/uqR v8W6WzJQDEDdBUgoGKgDbBx4fx7qes6NAsUWik72rRyUWtNj5J/Ci+79NjSzB4vwb3rlKsh0stSM 1pVYVAGmqF51aZvNFvfaAx2vIBjnpSIF9pgGCEXLu9mblXZXBlnKsD2YPuuw4lL+IKwfDEIbL/Jo aUJx5B0/UfVakuEe7PH0dXuiB9fp1d32gysfhir5d2QvoZ+o5Mbf1IY1VCpP2A0CQYVYHqI81tbl 0ES5ueI5mglj9ocdpBap8S5x+k+AJHKNhyxfOE4xgWaoJoC7hi4EsLIhHHqSA1AYOogCLLxs9PKo fShxqfSCePXtgnq0q+K4PpH7k4XSFeoIyCK4R114JakuO0hf+cKrXGashfEUSsO4VBnhntSIV6eN EUhdmdrrjYFY0i6fG2BKxDWokZ6rAPByHW0VpyROzWIHqX4Sb5hjV1tZBE4qy+XChdhLcvMxMdKO ZhYPgw4cFKqUUQ29MohmwhisnC7akmYAAFRt86AlCEc5dhU9adZNL+sbJoBJAl7p0NkuGzutDemn iviwLDNu3uVYMXooNWaxmCrlir12pNsa96F6t/aZWNOh9jGOJ96FPLYCQzKuRIuCPjczNG29+pbV ewXvo6JGAsTidFVp8Z4SWO8qTnomM2T5cV4wctXnnUjOPqoB0jQnZLFq0sOwqxh/G0LzC1h3t2EF niEg0sI7sRJHEJ6D/98CJVA9gGsPTtBt1+bt5J6U5Qey1vfMqB0k4t8J6r32y5ywwOAPIXzeScAp HXKWoA6ME7cproemB3XSgFCcBQj7yW+OkyjakKfDIxpRuh+DHbXUHbNtx6es4652y0vNhqYkK7ib AFKinF7EQHF2sM0eGpmzPgToVYTk2mOtsZK3KV8/6lN7j/ynC2v7Q4MT9vw9nTb07n7fsw7mdx9B otLDqPD24zpH4yNJQ0uW79svzNgpIhq65z8OM96BOtGG8y2KosKavrQbth0AUev1yNkp6z6BvyKQ kJDoqSaMU6X5xQOchuLbfXzcxnIp+/F+NGD2Q1kx38OnJqwR48kKWlp5NOFU5xAILchRap3R5R1P ax5cuWN/GRX7z+45bn906C84wesdIuRxgwCQTgMCLno/BVJK9tLor9ur0732m4P/TdCoUZYkuGJP 8B6HRYIjgPZWV+MlfmvJJOCFUseWIwsbPIebdY6sLCfGc7Ckvn/lkL1v8DnuURZqPLBzteA8F5y4 ujKhnUx20tuTwloC9d9OHVxJ2muVDWNVf2H/Q75K8P423LAn+o5weCPaqXsL9q0MN9d9Uh8ArJgd w5NPMka5hZc79vCcLD8IeiBApmmM8poygzZTOAOiucrtAIyD7IIyvBgxDAzLUtH1pDUlnyS7kKoo B6dKeC+gSJoye6AoLsLaoi1nNWl+/PspVh54OaiornE4VT3GKimS7EtoIJT19tWPUpQXfoW+4MAs nKN/9mwVkqqViWqlGUCR0+3v3v9J62nGlzzSZelv1ydpNMQWWAj49Ok2Bnoz4EU1AbYqivxxV5Ph GuTpCG/NGJfb58GRfGMex4MBObEmAPBGLMQlV1mYArHABkrVG89RR4L7uTxk1qaT2CcYqKnd6HTP mBQsS+1zIPA98OZq85jFaaQQ1mZSQIah/eU92kxFlaE/rVNxGiPMLoCKYKfC+c4Io0L4tSiPcer0 Opd1ucqye3gv8RY/tKUgggInY7F9JBNJYZ9Rak+iXYUqIEGYssNQbQyn0INwjtO1NLcSc7D2mGyR cqUO1A9BQI3nQTTUKexHl503PqW803OWIkiVAPYCthWVHGTyCD4CplCN5Vpt0q3lLnPaRvVVZWQn kiXqYAkDuiIBJJKMJzMWTqbzA5DdAPP0aNFSQkYYtxZwgVIYxE0DVEbTWQAH26ZgVwpZ643TgfpZ JE9zkbDfERTQRpb1c7gzKaLSK0PGNGPLYaEuv3TqR/0pNeKupQHAXqbcAm3JvUqGttxZowroHQbA i8IQ9ROx6yQIb8QFihxuar00rgJzjIEcM9jC6NlrmIMNtydrxe1ovsG2amRuudeIYS1gzdjVn8aS YWxx9sPhtvp8E0nAZBFg89zQU3Z0/BmQMxpHH/qQdX3ko0Beh9LeKtNxbasXCCX9+f0v2qcOfQbK j/G4U0QBZyEMnY6VYLXyKbfr0wsP4/BwB4jygt3XfhGKAkDmm6ASWqYVDa154p9nE1PcxUAZwL0I gkjGopOxnv8AlOfKd1EO7c+aM8ZKtRP2E0Gh0i97m+emDyEEnrXtuTNocO2irYKr6V7K3+PykVwS lzP0EiGN6HoWVeAbMkxsfQ2Pv2hp0WULYSMwMbZTIx+3u7/3fnsoC9tUL4YnIQ/2n5P5tclv8V4y dveoGyEPPQQCelobwQ4hOZzPpjUm+bC65mNbt4F+SpV8mDVAXqF6ko8I4AdE453zEdpvqCGOyFhQ Y4rzgFWQgahtGSIK2cgQMYYHXiG8RQ7kCReks2tOfWh82hP961osM55r2F9FKJVEostXrCxXJ2ne ATxR2OeO8LCwSHlYcNRYn6J1qrsjwLWUTaF3jZ3AsDbhFkk3Ke9P/S2KrboFkzkhH1S1hqXRNTUO RufNiQPcxVGqEm896tenSx3FPt98oh0WcRrB9ioEKAa3Hg41Wp/I8ljo9Xm3uBZAr6DWODlC+2vb ukU93VJxAREhjXmtr4ZDpn4r5WdX8hLMeVkF2O/egQ/6i0ERyO+VXjDZJYg3L6Cv0LECiu5+g8NI M3HKdQIWMohYRFkQjk7KqrOI3UV6BvbXdyGx2T/Nq9pBWU7eYs/lcJci62uvT/kEp/sW+lUSiyhJ BMH0CNSr+mQc6VHaIkqg2E3Vmryk6RxjANBrTA68MX4UcM/hW8vfcxwhhgZpkzKeWMoc7CDBI0U6 9HMBeepHj0DbjzBO02FLu0FgrEXckziHAASjdVHSmMWXSTE/AX4fkyAqVTyxjpJXiMUUCeLVns9F 0Q9rj6uQYwtlgJXLfq7kTyt3oWBNL5Ev5MMhR9Eh9RzQbFg3xu62Ktz/aSdNSQLzF2Bb/UH/WfvD +z9bQx6K5YE1PeBDyEKGfyfGiSne+6/UEMDHPijzgj3E/7HRw5Yv9SHcluGfkEYEZMP4WSoMAWV9 jsYfxnzX5vrRhipheY4ZAO2ofNTP6ak9dqAN2yqxtkkFkMR/XThsHz3wsrOHtxPnPBKnzZW6kIv0 I4g/Yf0glCC8DntbQlNrAaPGFtR/lcQuy9TcF3WkZ2hLrlIQqDNEicBWJyEP7CPQWLox/QOQhzxa NDHGqKCQRc4a0wOw3c5TVasoufCs5Ymr0Zh5wDWqimUoDZ1O/H6tB70oIB4B/qUlcXrkO6+dm3BD APwr5bV2IFm3VOeQh6ddJXg91pzdB5VzCgpkkjGKClH/QgopENh2K6HNtYCargTwGpfua23EKlPo XLWivKqE25z6XWaiJhwZ6kL/K2ljBLJyf9WVkEhMAFun9zdK3ukbFQr3fciUrxdSa/OSaZFr5Edj VsFa2qhOdO/W3wgy0zod1JW6xVjlN+t2kpBIUsZHbzYxFmmHKUVz9GvWPBpmpALshe7kBx0u6mTB t7NI6FAIoYJqrzbBBcYqA6DTxkRlNAR54l1CLqI8lfN6fbB+uOfjFluqBjwVdra+voCljP2UHOgC oCVcj/oUkK7U2o6eX6kL17ehtuU12KBmPDGOKPm4az+W+9Z4olS7rOD5d/m5IC/SzlKerwvlozkL IVTamK8eztq8oua8PMoEK5PnTrR+tUKac8XnXFtX5WsOmhd7wGO0sm61Oj52GvUx1PJ+el+wL5n3 MbStPtEvgblkHlDBzraK2CzaXbGicCw5H9T5BfCvzg0CeHO2p+WkvYNYHSGtII8IMZycfNRGC332 nv5vUiTsfzLOoQNAuFjNIcQNAI2V4n6D3df5XZep1Bq05vQxDAZBYNwulA7b92/02R6cMT687duo Ar+AQSGeAzAzuFtUW1wn+pDmK/IKHDZd4FPW8QM5IURAsKsHq1y4f4nQFdqMsMWUEPLAW+51VHXL 5cv8XsO24oQQgx2V5uQ+WzxNO4BnYpy77AHW1XwkB1mFPFhHTi4SlGdBPNO4Z/f1oC+5JpFQuwGA v4Kk1CwKFWhmcfThhxLvEKq3c8VLXNEnyKU5ux8kkkewPwRCmUIWkqWPNupBveO40U92qkk/+g9z 5pDDWMqOsNT/CixTX3I3X/+4q9b6pLULz8aqew7Il8m4Vbfe0o+wVeubEEK56b31xTedU4+oNl3p NgreLtK5WdP1c4+uo++b1Xmr+euAEx0uA9Ja4wEgrxnJ2nL6reMlae2jtFH9Vf1u1FY9wFeb/hSH 9r2TKK8OcUT59d8b1Yvur51nlK/vVeNTxtoxKq8urStfdy+63KiMj682h82sW9TWnfrWigokoVPh dh6/33vOkUc7gu8gF4iQh/ZV8owYoWWP2q/uOcq1RoyfOcpiFcQ11MOyvKIe7ISZ9TfO2VVi/EjU lcEIWQC8JzuKRtS9Nk700/2tAsArewwe8DRfwWcbBoKLAKT9rQicSfOlBpBHGc+7xMWgSooT9148 7k4UOwCiXZSYpk6a+CII8VPT9BTajb4jpKa2NI4of0HyXoYLDQmQRUYB5SHkUSyd53c98gg1JTsQ C2mcAE9hPaA+sPcoR8+v5BHe98q8/DcIoSI5BwgoTsTByOWIKICUYp2n2kAEF2hSB6SwfjpxCLU5 NcGBLt7QDnKAUkFmkkz0QbVATcVhDUsQ7yq8l+ljHgTXyJhwIeQRDOe5RuazKAS7gowCxaE9W+lL 15LThJ0M+RsjkKgO1bfS1gpsrcDbfwUEzgQ+5BQRotNeJI7Nnw++an9y6PMghCmATAuAKghmI6AS saROT74bu44me1fv08goCrCgAotJqxbcmehKSYBF4Dmcakuwad6388t+J9wNQHVf60lkGzJ4kyV5 KxRCAPinph6zu1pesdcnDuMK/jLeYq97Xck4+nLPQnWglwF0C4hGCjwJ4n0IkVWJdY4quswNvFVH B7Qe+ovmIbwtmYN8Y0nuKe5Hl7Sx+ItzQl8oXreR6R8iU7hYQx6ah9qoA7yc3tOpHYwNCgQBtNyn q8TiktZE5UKfXKxJdAYSmS68EvIdUaisBN+TUGSS42lsYmkySSiDFKq20uJKYfwn4XigUIKGVgVE V164TpNQLi5YV9/ZGkuKcUMBOdWxzOLR3tSnIH/RSoUxa7Wk1CNZllKYRw2BhB8qLNP6YF4fim19 bq3A1gq8DVcAeOHAQWwF/nQunoTinwRxSBj+2b0v2R8//Jeos0rY2oQx3gyyDNk3NCA7CEDEARml Fa9jF3Y5SWQYDtsoE1KAK+Ga0yvIKXQno76qTSKwlhCoK3MVBBXqqEwZ+4xJDAGz8RG7nO+13S1T LuNoTyluecUOtr8MxTLCaViAFK5lYsxmittoZ9SlMlVsggR45b5kgZP/k0O/be/tfxlVX9lBAIQd gfnsqY4Rr8aysNtOzHTaI10vuOGhHBriR9R2tpyhg18AsM/YOLE8JG9wmQeIQhRJDKDuqriamAN9 3I5grFcpT4E0JIgHcPsyrEUemm8Yp8bqlEc8C8WQhTUmeUdYNf/0piUPwuAQYbwoFSnsKBaIZBUL VdmPQQ2K3QQSkm8/Yj0yS2Q57o5Ejfkg+MJgOPeY+8YqoUHmgraoE//WWJDjQKXIzkSKAuwIeeRr uLVmvCgfjkBEsCklUPdIKPQfP6M8v7H1sbUCWyvwtlkBwQC93zFO2THpzQMFcBpgd2cX7WP3nLbf 2POaPdT+5dp8ZegWKIpSoska8Sihk+zUUpe1xS57S5mYbARWUnSyX8nRlXrtAeji/RbVXI1gH4gg pIBcoutMcsR2tYY297adXC6zrVH9gezigfJw4Azw74LtFRKzAgEFaKb+kH2ghPLEwAyaWkEGEhkv 1iosf7Vkl+xBVIAjGiXMOWHbO75jH2/eZV+8NmvbQJwF7Cj8pA/ii8VhDZEaEMonsPZ2n1OiEADd soMJCEUgdg3U9REGlpgwaqAc4mi1SwWZ0aclZF6po6vKEqxDVL/LcoXNlgnly21KEAqJEhKCklAe OC+1X9m5SZvOU9QWbWMqUEIBYlG+v2BHhTFG91VYZfjH8VupAcUHxSzS8UIIUt4nIj4iRZS8h8Wa oGRsTsFDkPijT7pWjTcU3/rcWoGtFXh7rABCV06a+YUZt71CT8cOpZ6xX4n/hzUBj08OA9DwfFAf gnZpCZ9lqKtJCD2CGvFgk1gzAjCCJkJJOqKuTwLpCQD7y2M7UZXFIBEE4SIBASoH+PUALFwHtlJ9 ewK06kPfEsjrXrgfUIY+69vROHQfrxnxb9s4bCikC5ThYlWS/RV2ZbGLzBVEisxDbWtacWzDUAi0 8de/g/pqj5VlhCJWkie1BEuPNXQZA8DdyiAAp0LqO1g7Jt2jLPUSnPBlY7GIC5TV9dbWobynKF+/ dR3lh7shT9dRflQ+uh/uzS09ywXIz8e6cZmqIzPuRcJ1FcMdjw3XZGCy4SJFI3EeX4RI/M7Wx9YK bK3A/5MVQHUam60ycUlCaudL8o61wLZ2+019LYMaatdfv6nGbrOSKAVRPfUIaW0TOsErrS0TgLF0 oNBb2kpaAbQi5e5HadVOJhGsSFgUuIN+f+tjawW2VuBtvAJlTtSY7/kMExhRdHYrAJQEqOuTSkWc /ArykhTUSIRy1pdenaP2dLpPILfYqO3VpX8+fmmcQqE38C5RQstrefLR8FRAC+ATYmUkALqdJAG2 klNx4fLn+lPDFeUhTw61FC1B9Hvre2sFtlZgawW2VmBrBTa1Av8H/1JsixJlFs4AAAAASUVORK5C YII= --94eb2c122e648c1039054f02d9ca-- From nobody Mon May 8 07:01:51 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4E9129471 for ; Mon, 8 May 2017 07:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXKCWiqg0dVZ for ; Mon, 8 May 2017 07:01:46 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c: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 6FCF0127444 for ; Mon, 8 May 2017 07:01:46 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id x71so28500089vkd.0 for ; Mon, 08 May 2017 07:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gFrdHGMvzBCQTQqjFaOypaQH9sDjdmw/Zx7bNy+BdHU=; b=QTUQV5LfNJBC3TFDQOF+ds2+or/KMZg3di3mWiLoy7+s5NwLOHQuGNOevgirEklBUs v6Ppbb4B7n+IRElSO0Oknwq8ZDOqqY8SBm9I9V2OJ1bAm9lU5kjoeU4vXXNcaJtgFqCf MmYjDGzXM/KRijs32ClgpbuW7VLaIkrj9f/ar4qmSpyC6uKO4DIgFzSS3XWaR9a7uzkY ODcO78ADCkhgg1x3tUhu7nIUiZ4aRmrUJra34/X+Ims2GeWOa4AOuaCfHgxF0Y/x2Ut/ SF+6v1ZZKH6rQLqEcQgfse+xbn5GerzwGlMu3mlOHbVQoNvwFSaUi7pNWecnkVao+i8J A3lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gFrdHGMvzBCQTQqjFaOypaQH9sDjdmw/Zx7bNy+BdHU=; b=sW0wxlSwBm6GVcbl1WTYGuUhOLNTfNahENhqYpHC48/1/iG6+qutZmOVvlEM56Bfxd /bFKz3kD/vbo6UeNgEg8mqoy3FUb4Tw79OF0ujWLiE6FfdSl7bvV1//8C8sfgMrTyRjK w8VS1NetIsywZZhYfferb4uPWl7xz/Q7OKuaRQFRxWhpD/hf84iS391ZIhK1HVq1usxK SDWNZelFD+PIO6MOueEA3EhbQUywJMPR0uWJHliqnBka0PI3db8dMhYiyP6+dYlYdur4 8Y0L86mrqKbHKNu6cj18kpymta7H10Jyv8JrXl6/mNQ2r2COdoKMcDLIJ6nL7Vrdk5+q /E8g== X-Gm-Message-State: AODbwcC+5+FmVQ4MZ8Pjrg8WVRu0LXF/rF4YqS0sXh3dOsinGW26XgMT fNA38hPE1pCpuHMSm9xBWT8cwzP44Q== X-Received: by 10.31.98.196 with SMTP id w187mr9232874vkb.96.1494252105429; Mon, 08 May 2017 07:01:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.76.91 with HTTP; Mon, 8 May 2017 07:01:45 -0700 (PDT) In-Reply-To: References: <148416124213.8244.5842562779051799977.idtracker@ietfa.amsl.com> <9199091B-5D7F-4D66-9EC5-CB0EF2D3CF6D@lodderstedt.net> <30B37ED3-6E3B-4739-9917-BDEC198CA027@lodderstedt.net> From: Rifaat Shekh-Yusef Date: Mon, 8 May 2017 10:01:45 -0400 Message-ID: To: Brian Campbell Cc: Nat Sakimura , oauth Content-Type: multipart/alternative; boundary=94eb2c07b57af2f958054f03adff Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 14:01:50 -0000 --94eb2c07b57af2f958054f03adff Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi All, The last email from Brian addresses the multiple audiences/resources issue with an error code, and we did not see any objection to this approach so far. *Authors,* Are there any other open issues with this draft? Do you believe it is ready for WGLC? Thanks, Rifaat & Hannes On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell wrote: > As mentioned during the Chicago meeting the "invalid_target" error code > that was added in -07 was intended to give the AS a standard way to rejec= t > request with multiple audiences/resources that it doesn't understand or i= s > unwilling or unable to process based on policy or whatever criteria . It > was intended as a compromise, of sorts, to allow for the multiple > resources/audiences in the request but provide an easy out for the AS of > saying it can't be supported based on whatever implementation or security > or policy it has. > > On Tue, Mar 28, 2017 at 1:32 AM, Nat Sakimura wrote: > >> There are cases where tokens are supposed to be consumed at multiple >> places and the `aud` needed to capture them. That's why `aud` is a >> multi-valued field. >> >> On Mon, Mar 27, 2017 at 11:35 AM Torsten Lodderstedt < >> torsten@lodderstedt.net> wrote: >> >>> May I ask you to explain this reason? >>> >>> Am 27.03.2017 um 08:48 schrieb Mike Jones = : >>> >>> For the same reason that the =E2=80=9Caud=E2=80=9D claim is multi-value= d in JWTs, the >>> audience needs to stay multi-valued in Token Exchange. Ditto for resou= rces. >>> >>> >>> >>> Thanks, >>> >>> -- Mike >>> >>> >>> >>> *From:* OAuth [mailto:oauth-bounces@ietf.org ] = *On >>> Behalf Of *Brian Campbell >>> *Sent:* Monday, March 27, 2017 8:45 AM >>> *To:* Torsten Lodderstedt >>> *Cc:* oauth >>> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchang >>> e-07.txt >>> >>> >>> >>> Thanks for the review and question, Torsten. >>> >>> The desire to support multiple audience/resource values in the request >>> came up during a review and discussion among the authors of the documen= t >>> when preparing the -03 draft. As I recall, it was said that both Salesf= orce >>> and Microsoft had use-cases for it. I incorporated support for it into = the >>> draft acting in the role of editor. >>> >>> From an individual perspective, I tend to agree with you that allowing >>> for multiple audiences/resources adds a lot of complexity that's like n= ot >>> needed in many (or most) cases. And I would personally be open to makin= g >>> audience and resource mutual exclusive and single valued. A question fo= r >>> the WG I suppose. >>> >>> The "invalid_target" error code that was added in -07 was intended to >>> give the AS a standard way to deal with the complexity and reject reque= st >>> with multiple audiences/resources that it doesn't understand or is >>> unwilling or unable to process. It was intended as a compromise, of sor= ts, >>> to allow for the multiples but provide an easy out of saying it can't b= e >>> supported based on whatever implementation or policy of the AS. >>> >>> >>> >>> >>> >>> >>> >>> On Sun, Mar 26, 2017 at 9:00 AM, Torsten Lodderstedt < >>> torsten@lodderstedt.net> wrote: >>> >>> Hi Brian, >>> >>> >>> >>> thanks for the clarification around resource, audience and scope. >>> >>> >>> >>> Here are my comments on the draft: >>> >>> >>> >>> In section 2.1 it states: =E2=80=9EMultiple "resource" parameters may b= e used to >>> indicate >>> >>> that the issued token is intended to be used at the multiple >>> >>> resources listed.=E2=80=9C >>> >>> >>> >>> Can you please explain the rational in more detail? I don=E2=80=99t und= erstand >>> why there is a need to ask for access tokens, which are good for multip= le >>> resources at once. This is a request type more or less exclusively used= in >>> server to server scenarios, right? So the only reason I can think of is >>> call reduction. >>> >>> >>> >>> On the other side, this feature increases the AS's complexity, e.g. its >>> policy may prohibit to issue tokens for multiple resources in general o= r >>> the particular set the client is asking for. How shall the AS handles s= uch >>> cases? >>> >>> >>> >>> And it is getting even more complicated given there could also be >>> multiple audience values and the client could mix them: >>> >>> >>> >>> "Multiple "audience" parameters >>> >>> may be used to indicate that the issued token is intended to be >>> >>> used at the multiple audiences listed. The "audience" and >>> >>> "resource" parameters may be used together to indicate multiple >>> >>> target services with a mix of logical names and physical >>> >>> locations.=E2=80=9C >>> >>> >>> >>> And in the end the client may add some scope values to the =E2=80=9Emea= l=E2=80=9C, which >>> brings us to >>> >>> >>> >>> =E2=80=9EEffectively, the requested access rights of the >>> >>> token are the cartesian product of all the scopes at all the target >>> >>> services." >>> >>> >>> >>> I personally would suggest to drop support for multiple audience and >>> resource parameters and make audience and resource mutual exclusive. I >>> think this is sufficient and much easier to implement. >>> >>> >>> >>> kind regards, >>> >>> Torsten. >>> >>> >>> >>> >>> >>> Am 11.01.2017 um 20:04 schrieb Brian Campbell < >>> bcampbell@pingidentity.com>: >>> >>> >>> >>> Draft -07 of "OAuth 2.0 Token Exchange" has been published. The primary >>> change in -07 is the addition of a description of the relationship betw= een >>> audience/resource/scope, which was a request or comment that came up du= ring >>> the f2f meeting in Seoul. >>> >>> Excerpted from the Document History: >>> >>> -07 >>> >>> o Fixed typo (desecration -> discretion). >>> o Added an explanation of the relationship between scope, audience >>> and resource in the request and added an "invalid_target" error >>> code enabling the AS to tell the client that the requested >>> audiences/resources were too broad. >>> >>> ---------- Forwarded message ---------- >>> From: >>> Date: Wed, Jan 11, 2017 at 12:00 PM >>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt >>> To: i-d-announce@ietf.org >>> Cc: oauth@ietf.org >>> >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Web Authorization Protocol of the IETF= . >>> >>> Title : OAuth 2.0 Token Exchange >>> Authors : Michael B. Jones >>> Anthony Nadalin >>> Brian Campbell >>> John Bradley >>> Chuck Mortimore >>> Filename : draft-ietf-oauth-token-exchange-07.txt >>> Pages : 31 >>> Date : 2017-01-11 >>> >>> Abstract: >>> This specification defines a protocol for an HTTP- and JSON- based >>> Security Token Service (STS) by defining how to request and obtain >>> security tokens from OAuth 2.0 authorization servers, including >>> security tokens employing impersonation and delegation. >>> >>> >>> 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-07 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-token-exchange-07 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> -- >> >> Nat Sakimura >> >> Chairman of the Board, OpenID Foundation >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --94eb2c07b57af2f958054f03adff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

The last email from Brian addre= sses the multiple audiences/resources issue with an error code, and we did = not see any objection to this approach so far.

Authors,

Are there any other op= en issues with this draft?
Do you believe it is ready for WGLC?

Thanks,
=C2=A0Rifaat & Hannes



On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
As mentioned during the Chicago meeting the &quo= t;invalid_target" error code that was added in -07 was intended to=20 give the AS a standard way to reject=20 request with multiple audiences/resources that it doesn't understand or= =20 is unwilling or unable to process based on policy or whatever criteria . It= was intended as a compromise, of=20 sorts, to allow for the multiple resources/audiences in the request but pro= vide an easy out for the AS of saying it=20 can't be supported based on whatever implementation or security or poli= cy it has.
<= br>
On Tue, Mar 28, 2017 at 1:32 AM, Nat Sakimura= <sakimura@gmail.com> wrote:
There are cases where tokens are supposed to be consum= ed at multiple places and the `aud` needed to capture them. That's why = `aud` is a multi-valued field.=C2=A0

On Mon, Mar 27, 2017 at 11:35 AM Torsten Lodderstedt = <torsten@lo= dderstedt.net> wrote:
May I ask you to explain this reason?

Am 27= .03.2017 um 08:48 schrieb Mike Jones <Michael.Jones@microsoft.com>:

For the same reason that the =E2=80=9Caud=E2=80=9D claim is = multi-valued in JWTs, the audience needs to stay multi-valued in Token Exch= ange.=C2=A0 Ditto for resources.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks,

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=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-boun= ces@ietf.org] On Behalf Of Brian Campbell
Sent:= Monday, March 27, 2017 8:45 AM
To: T= orsten Lodderstedt <tor= sten@lodderstedt.net>
Cc: o= auth <oauth@ietf.org>
Subject:<= /b> Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt<= u class=3D"m_3983298834558915277m_-4354184635220679769gmail_msg">

=C2=A0

Thanks for the review and question, Torsten.

The desire to support multiple audien= ce/resource values in the request came up during a review and discussion am= ong the authors of the document when preparing the -03 draft. As I recall, = it was said that both Salesforce and Microsoft had use-cases for it. I incorporated support for = it into the draft acting in the role of editor.

From an individual perspective, I tend to agree w= ith you that allowing for multiple audiences/resources adds a lot of comple= xity that's like not needed in many (or most) cases. And I would person= ally be open to making audience and resource mutual exclusive and single valued. A ques= tion for the WG I suppose.

The &q= uot;invalid_target" error code that was added in -07 was intended to g= ive the AS a standard way to deal with the complexity and reject request wi= th multiple audiences/resources that it doesn't understand or is unwill= ing or unable to process. It was intended as a compromise, of sorts, to allow for the multiples but = provide an easy out of saying it can't be supported based on whatever i= mplementation or policy of the AS.

=C2=A0=

=C2=A0

=C2=A0

On Sun= , Mar 26, 2017 at 9:00 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi Bri= an,

=C2=A0

thanks= for the clarification around resource, audience and scope.=C2=A0

=C2=A0

Here a= re my comments on the draft:

=C2=A0

In sec= tion 2.1 it states: =E2=80=9EMultiple "resource" parameters may b= e used to indicate

=C2=A0= =C2=A0 =C2=A0 that the issued token is intended to be used at the multiple=

=C2=A0= =C2=A0 =C2=A0 resources listed.=E2=80=9C

=C2=A0

Can yo= u please explain the rational in more detail? I don=E2=80=99t understand wh= y there is a need to ask for access tokens, which are good for multiple res= ources at once. This is a request type more or less exclusively used in ser= ver to server scenarios, right? So the only reason I can think of is call reduction.=C2= =A0

=C2=A0

On the= other side, this feature increases the AS's complexity, e.g. its polic= y may prohibit to issue tokens for multiple resources in general or the par= ticular set the client is asking for. How shall the AS handles such cases?<= u class=3D"m_3983298834558915277m_-4354184635220679769gmail_msg">

=C2=A0

And it= is getting even more complicated given there could also be multiple audien= ce values and the client could mix them:=C2=A0

=C2=A0

"= Multiple "audience" parameters

=C2=A0= =C2=A0 =C2=A0 may be used to indicate that the issued token is intended to= be

=C2=A0= =C2=A0 =C2=A0 used at the multiple audiences listed.=C2=A0 The "audie= nce" and<= /u>

=C2=A0= =C2=A0 =C2=A0 "resource" parameters may be used together to indi= cate multiple<= /u>

=C2=A0= =C2=A0 =C2=A0 target services with a mix of logical names and physical

=C2=A0= =C2=A0 =C2=A0 locations.=E2=80=9C

=C2=A0

And in= the end the client may add some scope values to the =E2=80=9Emeal=E2=80=9C= , which brings us to=C2=A0

=C2=A0

=E2=80= =9EEffectively, the requested access rights of the

=C2=A0= =C2=A0token are the cartesian product of all the scopes at all the target<= u class=3D"m_3983298834558915277m_-4354184635220679769gmail_msg">

=C2=A0= =C2=A0services."

=C2=A0

I pers= onally would suggest to drop support for multiple audience and resource par= ameters and make audience and resource mutual exclusive. I think this is su= fficient and much easier to implement.

=C2=A0

kind r= egards,

Torste= n.

=C2=A0

=C2=A0

Am 11.= 01.2017 um 20:04 schrieb Brian Campbell <bcampbell@pingidentity.com>:

=C2=A0<= /u>

Draft -07 of "OAuth 2.0 Token Exchange" has bee= n published. The primary change in -07 is the addition of a description of = the relationship between audience/resource/scope, which was a request or co= mment that came up during the f2f meeting in Seoul.

Excerpted from the Document History:

=C2=A0=C2=A0 -07

=C2=A0=C2=A0 o=C2=A0 Fixed typo (desecration -> discretion).
=C2=A0=C2=A0 o=C2=A0 Added an explanation of the relationship between scope= , audience
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and resource in the request and added an &qu= ot;invalid_target" error
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 code enabling the AS to tell the client that= the requested
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 audiences/resources were too broad.

------= ---- Forwarded message ----------
From: <internet-drafts= @ietf.org>
Date: Wed, Jan 11, 2017 at 12:00 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt=
To: i-d-announce@ietf.org
Cc: oauth@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Web Authorization Protocol of the IETF.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= OAuth 2.0 Token Exchange
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Mich= ael B. Jones
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Anthony Nadalin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Brian Campbell
=C2=A0 =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 Chuck Mortimore
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-token-exchange-07.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 31
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-01-11

Abstract:
=C2=A0 =C2=A0This specification defines a protocol for an HTTP- and JSON- b= ased
=C2=A0 =C2=A0Security Token Service (STS) by defining how to request and ob= tain
=C2=A0 =C2=A0security tokens from OAuth 2.0 authorization servers, includin= g
=C2=A0 =C2=A0security tokens employing impersonation and delegation.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exch<= wbr>ange/

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

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


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

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

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

=C2=A0<= /u>

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

=C2=A0<= /u>

=C2=A0<= /u>


_________________________________________= ______
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
=
--

Nat Sakimura

Chairman of the Board, OpenID Foundation


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



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


--94eb2c07b57af2f958054f03adff-- From nobody Mon May 8 09:30:32 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D53C1294FF for ; Mon, 8 May 2017 09:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nOrjAcE156f for ; Mon, 8 May 2017 09:30:28 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e: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 1A418127866 for ; Mon, 8 May 2017 09:30:28 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id e64so35611595pfd.1 for ; Mon, 08 May 2017 09:30: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; bh=a6fh5eJ3apHTUWT9rVpfQJ22ITKIJq8mYSTgcU4geXo=; b=VPu0UvwAgYKBQa7jAULg13o10r+5djEyR2Hraom+pKbOEzaHqOHdh7SDkKg3EIhvW0 JEpuqZiWRSSDuE/cZgTkOipnDDfjVDZf8cfGIn3C8TVx6LRgL+/LnXiVL0SMfzlATdkf Rze29Pu4w6ZlpjI7FSynEXN60TgM2t7RA4vGE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=a6fh5eJ3apHTUWT9rVpfQJ22ITKIJq8mYSTgcU4geXo=; b=g+RwmcjK5OMY+UWJ+RddyxLC/O6lh7/hzxMOsb329vTYacVMmiNnH5P6OulaTMVXBB td73A1f1Isl6w2rQD7T4Oy8mKI7CW8CeLPePwPppD9wp4k/bpK5UTJhWmSK3kSkhhJG6 /ZddQ1PrQlMi2VU+eXMx0gVWbiTNlsV8V+gQICFnCp39Qo6JU5IQ11o420jSODONRPJq 6LigdgZ/vh3ckYX921L+DSWRzFJe3rUborSihMn40uDcXP2H7rvXVwaEcIyOa78U70Xb XjrUh7X1V2d+IOAjHXDH5RT2pC+Y2pneEJsJmHTHA6SrwYFUsYibtshxr6AWrEvPB0p3 wh0g== X-Gm-Message-State: AN3rC/5YDUU/Esbw4m+Ip3Ty64nVeugMCqyA6dXdTm2HjoQVm3caLoJG 4bn7EFncVon0+duKaO/MOeJzG1mGdNyw X-Received: by 10.84.245.1 with SMTP id i1mr81118693pll.51.1494261027549; Mon, 08 May 2017 09:30:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.154.205 with HTTP; Mon, 8 May 2017 09:29:56 -0700 (PDT) In-Reply-To: References: <148416124213.8244.5842562779051799977.idtracker@ietfa.amsl.com> <9199091B-5D7F-4D66-9EC5-CB0EF2D3CF6D@lodderstedt.net> <30B37ED3-6E3B-4739-9917-BDEC198CA027@lodderstedt.net> From: Brian Campbell Date: Mon, 8 May 2017 10:29:56 -0600 Message-ID: To: Rifaat Shekh-Yusef Cc: Nat Sakimura , oauth Content-Type: multipart/alternative; boundary=94eb2c1cebc2bfecdb054f05c10f Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 16:30:31 -0000 --94eb2c1cebc2bfecdb054f05c10f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I do have one minor issue I'd like to raise that relates to some conversations I've been a party to recently about implementations and applications of token exchange. I think that the current text in =C2=A72.1 for the "actor_token" is overly specific towards the delegation scenario. I'd propose the language be generalized somewhat to allow more versatility in applications/deployments of the token exchange framework. Here's that text: actor_token OPTIONAL. A security token that represents the identity of the acting party. On Mon, May 8, 2017 at 8:01 AM, Rifaat Shekh-Yusef wrote: > Hi All, > > The last email from Brian addresses the multiple audiences/resources issu= e > with an error code, and we did not see any objection to this approach so > far. > > > *Authors,* > > Are there any other open issues with this draft? > Do you believe it is ready for WGLC? > > Thanks, > Rifaat & Hannes > > > > On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> As mentioned during the Chicago meeting the "invalid_target" error code >> that was added in -07 was intended to give the AS a standard way to reje= ct >> request with multiple audiences/resources that it doesn't understand or = is >> unwilling or unable to process based on policy or whatever criteria . It >> was intended as a compromise, of sorts, to allow for the multiple >> resources/audiences in the request but provide an easy out for the AS of >> saying it can't be supported based on whatever implementation or securit= y >> or policy it has. >> >> On Tue, Mar 28, 2017 at 1:32 AM, Nat Sakimura wrote= : >> >>> There are cases where tokens are supposed to be consumed at multiple >>> places and the `aud` needed to capture them. That's why `aud` is a >>> multi-valued field. >>> >>> On Mon, Mar 27, 2017 at 11:35 AM Torsten Lodderstedt < >>> torsten@lodderstedt.net> wrote: >>> >>>> May I ask you to explain this reason? >>>> >>>> Am 27.03.2017 um 08:48 schrieb Mike Jones >>> >: >>>> >>>> For the same reason that the =E2=80=9Caud=E2=80=9D claim is multi-valu= ed in JWTs, the >>>> audience needs to stay multi-valued in Token Exchange. Ditto for reso= urces. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> -- Mike >>>> >>>> >>>> >>>> *From:* OAuth [mailto:oauth-bounces@ietf.org ]= *On >>>> Behalf Of *Brian Campbell >>>> *Sent:* Monday, March 27, 2017 8:45 AM >>>> *To:* Torsten Lodderstedt >>>> *Cc:* oauth >>>> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchang >>>> e-07.txt >>>> >>>> >>>> >>>> Thanks for the review and question, Torsten. >>>> >>>> The desire to support multiple audience/resource values in the request >>>> came up during a review and discussion among the authors of the docume= nt >>>> when preparing the -03 draft. As I recall, it was said that both Sales= force >>>> and Microsoft had use-cases for it. I incorporated support for it into= the >>>> draft acting in the role of editor. >>>> >>>> From an individual perspective, I tend to agree with you that allowing >>>> for multiple audiences/resources adds a lot of complexity that's like = not >>>> needed in many (or most) cases. And I would personally be open to maki= ng >>>> audience and resource mutual exclusive and single valued. A question f= or >>>> the WG I suppose. >>>> >>>> The "invalid_target" error code that was added in -07 was intended to >>>> give the AS a standard way to deal with the complexity and reject requ= est >>>> with multiple audiences/resources that it doesn't understand or is >>>> unwilling or unable to process. It was intended as a compromise, of so= rts, >>>> to allow for the multiples but provide an easy out of saying it can't = be >>>> supported based on whatever implementation or policy of the AS. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Sun, Mar 26, 2017 at 9:00 AM, Torsten Lodderstedt < >>>> torsten@lodderstedt.net> wrote: >>>> >>>> Hi Brian, >>>> >>>> >>>> >>>> thanks for the clarification around resource, audience and scope. >>>> >>>> >>>> >>>> Here are my comments on the draft: >>>> >>>> >>>> >>>> In section 2.1 it states: =E2=80=9EMultiple "resource" parameters may = be used >>>> to indicate >>>> >>>> that the issued token is intended to be used at the multiple >>>> >>>> resources listed.=E2=80=9C >>>> >>>> >>>> >>>> Can you please explain the rational in more detail? I don=E2=80=99t un= derstand >>>> why there is a need to ask for access tokens, which are good for multi= ple >>>> resources at once. This is a request type more or less exclusively use= d in >>>> server to server scenarios, right? So the only reason I can think of i= s >>>> call reduction. >>>> >>>> >>>> >>>> On the other side, this feature increases the AS's complexity, e.g. it= s >>>> policy may prohibit to issue tokens for multiple resources in general = or >>>> the particular set the client is asking for. How shall the AS handles = such >>>> cases? >>>> >>>> >>>> >>>> And it is getting even more complicated given there could also be >>>> multiple audience values and the client could mix them: >>>> >>>> >>>> >>>> "Multiple "audience" parameters >>>> >>>> may be used to indicate that the issued token is intended to be >>>> >>>> used at the multiple audiences listed. The "audience" and >>>> >>>> "resource" parameters may be used together to indicate multiple >>>> >>>> target services with a mix of logical names and physical >>>> >>>> locations.=E2=80=9C >>>> >>>> >>>> >>>> And in the end the client may add some scope values to the =E2=80=9Eme= al=E2=80=9C, >>>> which brings us to >>>> >>>> >>>> >>>> =E2=80=9EEffectively, the requested access rights of the >>>> >>>> token are the cartesian product of all the scopes at all the target >>>> >>>> services." >>>> >>>> >>>> >>>> I personally would suggest to drop support for multiple audience and >>>> resource parameters and make audience and resource mutual exclusive. I >>>> think this is sufficient and much easier to implement. >>>> >>>> >>>> >>>> kind regards, >>>> >>>> Torsten. >>>> >>>> >>>> >>>> >>>> >>>> Am 11.01.2017 um 20:04 schrieb Brian Campbell < >>>> bcampbell@pingidentity.com>: >>>> >>>> >>>> >>>> Draft -07 of "OAuth 2.0 Token Exchange" has been published. The >>>> primary change in -07 is the addition of a description of the relation= ship >>>> between audience/resource/scope, which was a request or comment that c= ame >>>> up during the f2f meeting in Seoul. >>>> >>>> Excerpted from the Document History: >>>> >>>> -07 >>>> >>>> o Fixed typo (desecration -> discretion). >>>> o Added an explanation of the relationship between scope, audience >>>> and resource in the request and added an "invalid_target" error >>>> code enabling the AS to tell the client that the requested >>>> audiences/resources were too broad. >>>> >>>> ---------- Forwarded message ---------- >>>> From: >>>> Date: Wed, Jan 11, 2017 at 12:00 PM >>>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt >>>> To: i-d-announce@ietf.org >>>> Cc: oauth@ietf.org >>>> >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Web Authorization Protocol of the IET= F. >>>> >>>> Title : OAuth 2.0 Token Exchange >>>> Authors : Michael B. Jones >>>> Anthony Nadalin >>>> Brian Campbell >>>> John Bradley >>>> Chuck Mortimore >>>> Filename : draft-ietf-oauth-token-exchange-07.txt >>>> Pages : 31 >>>> Date : 2017-01-11 >>>> >>>> Abstract: >>>> This specification defines a protocol for an HTTP- and JSON- based >>>> Security Token Service (STS) by defining how to request and obtain >>>> security tokens from OAuth 2.0 authorization servers, including >>>> security tokens employing impersonation and delegation. >>>> >>>> >>>> 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-07 >>>> >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-token-exchange-07 >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> -- >>> >>> Nat Sakimura >>> >>> Chairman of the Board, OpenID Foundation >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > --94eb2c1cebc2bfecdb054f05c10f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I do have one minor issue I'd like to raise that = relates to some conversations I've been a party to recently about imple= mentations and applications of token exchange.

I think t= hat the current text in =C2=A72.1 for the "actor_token" is overly= specific towards the delegation scenario. I'd propose the language be = generalized somewhat to allow more versatility in applications/deployments = of the token exchange framework. Here's that text:

=C2=A0=C2=A0 = actor_token
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OPTIONAL.=C2=A0 A security to= ken that represents the identity of the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a= cting party.=C2=A0



<= br>
On Mon, May 8, 2017 at 8:01 AM, Rifaat Shekh-= Yusef <rifaat.ietf@gmail.com> wrote:
Hi All,

The last email f= rom Brian addresses the multiple audiences/resources issue with an error co= de, and we did not see any objection to this approach so far.

Authors,

Are the= re any other open issues with this draft?
Do you believe it is re= ady for WGLC?

Thanks,
=C2=A0Rifaat &= Hannes



On = Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell <bcampbell@pingiden= tity.com> wrote:
As mentioned during the Chicago meeting the "invalid_target&q= uot; error code that was added in -07 was intended to=20 give the AS a standard way to reject=20 request with multiple audiences/resources that it doesn't understand or= =20 is unwilling or unable to process based on policy or whatever criteria . It= was intended as a compromise, of=20 sorts, to allow for the multiple resources/audiences in the request but pro= vide an easy out for the AS of saying it=20 can't be supported based on whatever implementation or security or poli= cy it has.

O= n Tue, Mar 28, 2017 at 1:32 AM, Nat Sakimura <sakimura@gmail.com>= wrote:
There are= cases where tokens are supposed to be consumed at multiple places and the = `aud` needed to capture them. That's why `aud` is a multi-valued field.= =C2=A0

On Mon, Mar 27, 2017 at 11:35 AM Torste= n Lodderstedt <torsten@lodderstedt.net> wrote:
May I ask you to expl= ain this reason?

Am 27.03.2017 um 08:48 schrieb Mike Jones <Michael.Jones@mi= crosoft.com>:

For the same reason that the =E2=80=9Caud=E2= =80=9D claim is multi-valued in JWTs, the audience needs to stay multi-valu= ed in Token Exchange.=C2=A0 Ditto for resources.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=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 = [mail= to:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Monday, March 27, 2017 8:45 AM
To: Torsten Lodderstedt <torsten@lodderstedt.net> Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token= -exchange-07.txt

=C2=A0

Thanks= for the review and question, Torsten.

The desire to s= upport multiple audience/resource values in the request came up during a re= view and discussion among the authors of the document when preparing the -0= 3 draft. As I recall, it was said that both Salesforce and Microsoft had use-cases for it. I incorporated support for = it into the draft acting in the role of editor.

From a= n individual perspective, I tend to agree with you that allowing for multip= le audiences/resources adds a lot of complexity that's like not needed = in many (or most) cases. And I would personally be open to making audience and resource mutual exclusive and single valued. A ques= tion for the WG I suppose.

The "invalid_target" error = code that was added in -07 was intended to give the AS a standard way to de= al with the complexity and reject request with multiple audiences/resources= that it doesn't understand or is unwilling or unable to process. It was intended as a compromise, of sorts, to allow for the multiples but = provide an easy out of saying it can't be supported based on whatever i= mplementation or policy of the AS.

=C2=A0 =

=C2=A0

=C2=A0<= /u>

On Sun, Mar 26, 2017 at 9:00 AM, Tors= ten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi Brian,

=C2=A0<= /u>

thanks for the clarification around r= esource, audience and scope.=C2=A0

=C2=A0<= /u>

Here are my comments on the draft:

=C2=A0<= /u>

In section 2.1 it states: =E2=80=9EMu= ltiple "resource" parameters may be used to indicate=

=C2=A0 =C2=A0 =C2=A0 that the issued = token is intended to be used at the multiple<= /u>

=C2=A0 =C2=A0 =C2=A0 resources listed= .=E2=80=9C

=C2=A0<= /u>

Can you please explain the rational i= n more detail? I don=E2=80=99t understand why there is a need to ask for ac= cess tokens, which are good for multiple resources at once. This is a reque= st type more or less exclusively used in server to server scenarios, right? So the only reason I can think of is call reduction.=C2= =A0

=C2=A0<= /u>

On the other side, this feature incre= ases the AS's complexity, e.g. its policy may prohibit to issue tokens = for multiple resources in general or the particular set the client is askin= g for. How shall the AS handles such cases?

=C2=A0<= /u>

And it is getting even more complicat= ed given there could also be multiple audience values and the client could = mix them:=C2=A0

=C2=A0<= /u>

"Multiple "audience" p= arameters

=C2=A0 =C2=A0 =C2=A0 may be used to i= ndicate that the issued token is intended to be

=C2=A0 =C2=A0 =C2=A0 used at the mult= iple audiences listed.=C2=A0 The "audience" and<= u class=3D"m_-2675142197049852080m_3983298834558915277m_-435418463522067976= 9gmail_msg">

=C2=A0 =C2=A0 =C2=A0 "resource&q= uot; parameters may be used together to indicate multiple<= u class=3D"m_-2675142197049852080m_3983298834558915277m_-435418463522067976= 9gmail_msg">

=C2=A0 =C2=A0 =C2=A0 target services = with a mix of logical names and physical<= /p>

=C2=A0 =C2=A0 =C2=A0 locations.=E2=80= =9C

=C2=A0<= /u>

And in the end the client may add som= e scope values to the =E2=80=9Emeal=E2=80=9C, which brings us to=C2=A0

=C2=A0<= /u>

=E2=80=9EEffectively, the requested a= ccess rights of the

=C2=A0 =C2=A0token are the cartesian = product of all the scopes at all the target

=C2=A0 =C2=A0services."

=C2=A0<= /u>

I personally would suggest to drop su= pport for multiple audience and resource parameters and make audience and r= esource mutual exclusive. I think this is sufficient and much easier to imp= lement.

=C2=A0<= /u>

kind regards,

Torsten.

=C2=A0<= /u>

=C2=A0<= /u>

Am 11.01.2017 um 20:04 schrieb Brian = Campbell <bcampbell@pingidentity.com>:=C2=A0

Draft = -07 of "OAuth 2.0 Token Exchange" has been published. The primary change= in -07 is the addition of a description of the relationship between audien= ce/resource/scope, which was a request or comment that came up during the f2f meeting in Seoul.

Excerpted from the Document History:

=C2=A0=C2=A0 -07

=C2=A0=C2=A0 o=C2=A0 Fixed typo (desecration -> discretion).
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and resource in the request and added an &qu= ot;invalid_target" error
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 code enabling the AS to tell the client that= the requested
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 audiences/resources were too broad.

---------- Forwarded message --------= --
From: <internet-drafts@ietf.org>
Date: Wed, Jan 11, 2017 at 12:00 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt=
To: i-= d-announce@ietf.org
Cc: oauth@iet= f.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Web Authorization Protocol of the IETF.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= OAuth 2.0 Token Exchange
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Mich= ael B. Jones
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Anthony Nadalin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Brian Campbell
=C2=A0 =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 Chuck Mortimore
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-token-exchange-07.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 31
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-01-11

Abstract:
=C2=A0 =C2=A0This specification defines a protocol for an HTTP- and JSON- b= ased
=C2=A0 =C2=A0Security Token Service (STS) by defining how to request and ob= tain
=C2=A0 =C2=A0security tokens from OAuth 2.0 authorization servers, includin= g
=C2=A0 =C2=A0security tokens employing impersonation and delegation.


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-oau= th-token-exchange-07

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


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

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

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

=C2=A0

_________________________________________= ______
OAuth mailing list
OAuth@ietf.or= g
https://www.ietf.org/mailman/listinfo/oauth<= /u>

=C2=A0

=C2=A0


________________________= _______________________
OAuth mailing list
OAuth@ietf.or= g
https://www.ietf.org/mailman/listinfo/oaut= h
--

Nat Sakimura

Chairman of the Board, OpenID Foundation


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



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



--94eb2c1cebc2bfecdb054f05c10f-- From nobody Mon May 8 10:00:34 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF34124D6C for ; Mon, 8 May 2017 10:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWpRJvjSP-_0 for ; Mon, 8 May 2017 10:00:26 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 443ED1200F1 for ; Mon, 8 May 2017 10:00:25 -0700 (PDT) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id C37C7780333 for ; Mon, 8 May 2017 19:00:21 +0200 (CEST) To: oauth@ietf.org References: <148416124213.8244.5842562779051799977.idtracker@ietfa.amsl.com> <9199091B-5D7F-4D66-9EC5-CB0EF2D3CF6D@lodderstedt.net> <30B37ED3-6E3B-4739-9917-BDEC198CA027@lodderstedt.net> From: Denis Message-ID: Date: Mon, 8 May 2017 19:00:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6746639BEF718B88600251BF" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 17:00:31 -0000 This is a multi-part message in MIME format. --------------6746639BEF718B88600251BF Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Brian, The current text is: actor_token OPTIONAL. A security token that represents the identity of the party that is authorized to use the requested security token and act on behalf of the subject. This sentence is indeed wrong since an actor-token is not a security token. So your proposed change does not solve this issue: actor_token OPTIONAL. A security token that represents the identity of the acting party. The current text states: Typically, in the request, the subject_token represents the identity of the party on behalf of whom the token is being requested while the actor_token represents the identity of the party to whom the access rights of the issued token are being delegated. Logically, the definition should be along the following lines: actor_token OPTIONAL. Indicates the identity of the party to whom the access rights of the issued token are being delegated. If there is no delegation, then this field (which is optional) will not be used. Anyway, thank you for requesting the change, otherwise this would have been a left error. Denis > I do have one minor issue I'd like to raise that relates to some > conversations I've been a party to recently about implementations and > applications of token exchange. > > I think that the current text in §2.1 for the "actor_token" is overly > specific towards the delegation scenario. I'd propose the language be > generalized somewhat to allow more versatility in > applications/deployments of the token exchange framework. Here's that > text: > > actor_token > OPTIONAL. A security token that represents the identity of the > acting party. > > > > > On Mon, May 8, 2017 at 8:01 AM, Rifaat Shekh-Yusef > > wrote: > > Hi All, > > The last email from Brian addresses the multiple > audiences/resources issue with an error code, and we did not see > any objection to this approach so far. > > > *Authors,* > > Are there any other open issues with this draft? > Do you believe it is ready for WGLC? > > Thanks, > Rifaat & Hannes > > > > On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell > > > wrote: > > As mentioned during the Chicago meeting the "invalid_target" > error code that was added in -07 was intended to give the AS a > standard way to reject request with multiple > audiences/resources that it doesn't understand or is unwilling > or unable to process based on policy or whatever criteria . It > was intended as a compromise, of sorts, to allow for the > multiple resources/audiences in the request but provide an > easy out for the AS of saying it can't be supported based on > whatever implementation or security or policy it has. > > On Tue, Mar 28, 2017 at 1:32 AM, Nat Sakimura > > wrote: > > There are cases where tokens are supposed to be consumed > at multiple places and the `aud` needed to capture them. > That's why `aud` is a multi-valued field. > > On Mon, Mar 27, 2017 at 11:35 AM Torsten Lodderstedt > > > wrote: > > May I ask you to explain this reason? > >> Am 27.03.2017 um 08:48 schrieb Mike Jones >> > >: >> >> For the same reason that the “aud” claim is >> multi-valued in JWTs, the audience needs to stay >> multi-valued in Token Exchange. Ditto for resources. >> >> Thanks, >> >> -- Mike >> >> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On >> Behalf Of *Brian Campbell >> *Sent:* Monday, March 27, 2017 8:45 AM >> *To:* Torsten Lodderstedt > > >> *Cc:* oauth > >> *Subject:* Re: [OAUTH-WG] I-D Action: >> draft-ietf-oauth-token-exchange-07.txt >> >> Thanks for the review and question, Torsten. >> >> The desire to support multiple audience/resource >> values in the request came up during a review and >> discussion among the authors of the document when >> preparing the -03 draft. As I recall, it was said >> that both Salesforce and Microsoft had use-cases for >> it. I incorporated support for it into the draft >> acting in the role of editor. >> >> From an individual perspective, I tend to agree with >> you that allowing for multiple audiences/resources >> adds a lot of complexity that's like not needed in >> many (or most) cases. And I would personally be open >> to making audience and resource mutual exclusive and >> single valued. A question for the WG I suppose. >> >> The "invalid_target" error code that was added in -07 >> was intended to give the AS a standard way to deal >> with the complexity and reject request with multiple >> audiences/resources that it doesn't understand or is >> unwilling or unable to process. It was intended as a >> compromise, of sorts, to allow for the multiples but >> provide an easy out of saying it can't be supported >> based on whatever implementation or policy of the AS. >> >> On Sun, Mar 26, 2017 at 9:00 AM, Torsten Lodderstedt >> > > wrote: >> >> Hi Brian, >> >> thanks for the clarification around resource, >> audience and scope. >> >> Here are my comments on the draft: >> >> In section 2.1 it states: „Multiple "resource" >> parameters may be used to indicate >> >> that the issued token is intended to be used >> at the multiple >> >> resources listed.“ >> >> Can you please explain the rational in more >> detail? I don’t understand why there is a need to >> ask for access tokens, which are good for >> multiple resources at once. This is a request >> type more or less exclusively used in server to >> server scenarios, right? So the only reason I can >> think of is call reduction. >> >> On the other side, this feature increases the >> AS's complexity, e.g. its policy may prohibit to >> issue tokens for multiple resources in general or >> the particular set the client is asking for. How >> shall the AS handles such cases? >> >> And it is getting even more complicated given >> there could also be multiple audience values and >> the client could mix them: >> >> "Multiple "audience" parameters >> >> may be used to indicate that the issued token >> is intended to be >> >> used at the multiple audiences listed. The >> "audience" and >> >> "resource" parameters may be used together to >> indicate multiple >> >> target services with a mix of logical names >> and physical >> >> locations.“ >> >> And in the end the client may add some scope >> values to the „meal“, which brings us to >> >> „Effectively, the requested access rights of the >> >> token are the cartesian product of all the >> scopes at all the target >> >> services." >> >> I personally would suggest to drop support for >> multiple audience and resource parameters and >> make audience and resource mutual exclusive. I >> think this is sufficient and much easier to >> implement. >> >> kind regards, >> >> Torsten. >> >> Am 11.01.2017 um 20:04 schrieb Brian Campbell >> > >: >> >> Draft -07 of "OAuth 2.0 Token Exchange" has >> been published. The primary change in -07 is >> the addition of a description of the >> relationship between audience/resource/scope, >> which was a request or comment that came up >> during the f2f meeting in Seoul. >> >> Excerpted from the Document History: >> >> -07 >> >> o Fixed typo (desecration -> discretion). >> o Added an explanation of the >> relationship between scope, audience >> and resource in the request and added >> an "invalid_target" error >> code enabling the AS to tell the client >> that the requested >> audiences/resources were too broad. >> >> ---------- Forwarded message ---------- >> From: > > >> Date: Wed, Jan 11, 2017 at 12:00 PM >> Subject: [OAUTH-WG] I-D Action: >> draft-ietf-oauth-token-exchange-07.txt >> To: i-d-announce@ietf.org >> >> Cc: oauth@ietf.org >> >> >> >> A New Internet-Draft is available from the >> on-line Internet-Drafts directories. >> This draft is a work item of the Web >> Authorization Protocol of the IETF. >> >> Title : OAuth 2.0 Token Exchange >> Authors : Michael B. Jones >> Anthony Nadalin >> Brian Campbell >> John Bradley >> Chuck Mortimore >> Filename : >> draft-ietf-oauth-token-exchange-07.txt >> Pages : 31 >> Date : 2017-01-11 >> >> Abstract: >> This specification defines a protocol for >> an HTTP- and JSON- based >> Security Token Service (STS) by defining >> how to request and obtain >> security tokens from OAuth 2.0 >> authorization servers, including >> security tokens employing impersonation >> and delegation. >> >> >> 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-07 >> >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-07 >> >> >> >> Please note that it may take a couple of >> minutes from the time of submission >> until the htmlized version and diff are >> available at tools.ietf.org >> . >> >> Internet-Drafts are also available by >> anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > -- > > Nat Sakimura > > Chairman of the Board, OpenID Foundation > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------6746639BEF718B88600251BF Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Brian,

The current text is:

actor_token OPTIONAL. A security token that represents the identity of the party that is authorized to use the requested security token and act on behalf of the subject.

This sentence is indeed wrong since an actor-token is not a security token.

So your proposed change does not solve this issue: actor_token  OPTIONAL.  A security token that represents the identity of the acting party.

The current text states:
Typically, in the request, the subject_token represents the identity of the party on behalf of whom
the token is being requested while the actor_token represents the identity of the party to whom the access
rights of the issued token are being delegated.
Logically, the definition should be along the following lines:

 actor_token OPTIONAL. Indicates the identity of the party to whom the access rights of the issued token are being delegated.

If there is no delegation, then this field (which is optional) will not be used.

Anyway, thank you for requesting the change, otherwise this would have been a left error.

Denis

I do have one minor issue I'd like to raise that relates to some conversations I've been a party to recently about implementations and applications of token exchange.

I think that the current text in §2.1 for the "actor_token" is overly specific towards the delegation scenario. I'd propose the language be generalized somewhat to allow more versatility in applications/deployments of the token exchange framework. Here's that text:

   actor_token
      OPTIONAL.  A security token that represents the identity of the
      acting party. 




On Mon, May 8, 2017 at 8:01 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Hi All,

The last email from Brian addresses the multiple audiences/resources issue with an error code, and we did not see any objection to this approach so far.


Authors,

Are there any other open issues with this draft?
Do you believe it is ready for WGLC?

Thanks,
 Rifaat & Hannes



On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
As mentioned during the Chicago meeting the "invalid_target" error code that was added in -07 was intended to give the AS a standard way to reject request with multiple audiences/resources that it doesn't understand or is unwilling or unable to process based on policy or whatever criteria . It was intended as a compromise, of sorts, to allow for the multiple resources/audiences in the request but provide an easy out for the AS of saying it can't be supported based on whatever implementation or security or policy it has.

On Tue, Mar 28, 2017 at 1:32 AM, Nat Sakimura <sakimura@gmail.com> wrote:
There are cases where tokens are supposed to be consumed at multiple places and the `aud` needed to capture them. That's why `aud` is a multi-valued field. 

On Mon, Mar 27, 2017 at 11:35 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
May I ask you to explain this reason?

Am 27.03.2017 um 08:48 schrieb Mike Jones <Michael.Jones@microsoft.com>:

For the same reason that the “aud” claim is multi-valued in JWTs, the audience needs to stay multi-valued in Token Exchange.  Ditto for resources.

 

                                                       Thanks,

                                                       -- Mike

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Monday, March 27, 2017 8:45 AM
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt

 

Thanks for the review and question, Torsten.

The desire to support multiple audience/resource values in the request came up during a review and discussion among the authors of the document when preparing the -03 draft. As I recall, it was said that both Salesforce and Microsoft had use-cases for it. I incorporated support for it into the draft acting in the role of editor.

From an individual perspective, I tend to agree with you that allowing for multiple audiences/resources adds a lot of complexity that's like not needed in many (or most) cases. And I would personally be open to making audience and resource mutual exclusive and single valued. A question for the WG I suppose.

The "invalid_target" error code that was added in -07 was intended to give the AS a standard way to deal with the complexity and reject request with multiple audiences/resources that it doesn't understand or is unwilling or unable to process. It was intended as a compromise, of sorts, to allow for the multiples but provide an easy out of saying it can't be supported based on whatever implementation or policy of the AS.

 

 

 

On Sun, Mar 26, 2017 at 9:00 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi Brian,

 

thanks for the clarification around resource, audience and scope. 

 

Here are my comments on the draft:

 

In section 2.1 it states: „Multiple "resource" parameters may be used to indicate

      that the issued token is intended to be used at the multiple

      resources listed.“

 

Can you please explain the rational in more detail? I don’t understand why there is a need to ask for access tokens, which are good for multiple resources at once. This is a request type more or less exclusively used in server to server scenarios, right? So the only reason I can think of is call reduction. 

 

On the other side, this feature increases the AS's complexity, e.g. its policy may prohibit to issue tokens for multiple resources in general or the particular set the client is asking for. How shall the AS handles such cases?

 

And it is getting even more complicated given there could also be multiple audience values and the client could mix them: 

 

"Multiple "audience" parameters

      may be used to indicate that the issued token is intended to be

      used at the multiple audiences listed.  The "audience" and

      "resource" parameters may be used together to indicate multiple

      target services with a mix of logical names and physical

      locations.“

 

And in the end the client may add some scope values to the „meal“, which brings us to 

 

„Effectively, the requested access rights of the

   token are the cartesian product of all the scopes at all the target

   services."

 

I personally would suggest to drop support for multiple audience and resource parameters and make audience and resource mutual exclusive. I think this is sufficient and much easier to implement.

 

kind regards,

Torsten.

 

 

Am 11.01.2017 um 20:04 schrieb Brian Campbell <bcampbell@pingidentity.com>:

 

Draft -07 of "OAuth 2.0 Token Exchange" has been published. The primary change in -07 is the addition of a description of the relationship between audience/resource/scope, which was a request or comment that came up during the f2f meeting in Seoul.

Excerpted from the Document History:

   -07

   o  Fixed typo (desecration -> discretion).
   o  Added an explanation of the relationship between scope, audience
      and resource in the request and added an "invalid_target" error
      code enabling the AS to tell the client that the requested
      audiences/resources were too broad.

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Wed, Jan 11, 2017 at 12:00 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt
To: i-d-announce@ietf.org
Cc: oauth@ietf.org



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

        Title           : OAuth 2.0 Token Exchange
        Authors         : Michael B. Jones
                          Anthony Nadalin
                          Brian Campbell
                          John Bradley
                          Chuck Mortimore
        Filename        : draft-ietf-oauth-token-exchange-07.txt
        Pages           : 31
        Date            : 2017-01-11

Abstract:
   This specification defines a protocol for an HTTP- and JSON- based
   Security Token Service (STS) by defining how to request and obtain
   security tokens from OAuth 2.0 authorization servers, including
   security tokens employing impersonation and delegation.


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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-07


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

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

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

 

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

 

 


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

Nat Sakimura

Chairman of the Board, OpenID Foundation


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



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





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


--------------6746639BEF718B88600251BF-- From nobody Mon May 8 11:13:14 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDE812896F for ; Mon, 8 May 2017 11:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQh2eXEgBYrj for ; Mon, 8 May 2017 11:13:10 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e: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 4EE861250B8 for ; Mon, 8 May 2017 11:13:10 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id v14so36852921pfd.2 for ; Mon, 08 May 2017 11:13:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=psH70Lk7KyWP9SQfnFPocI7WKCDFKfOhn5YqJOLSAMo=; b=Z26v5d8rLdEbzjZCRSLpzy3aw54aP05noI1NRfyYDuizXMYssxYbijtGGWfPtr4at8 e/YMLiGf7JWZGWx1V0oUzuszgU/iv/2lIwUIgA7dVOszk4saswasQ4lsHABVbKptjury uLGY+jtUq0iqwtJ2EsJXdLv+2XCdSSurFgqWw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=psH70Lk7KyWP9SQfnFPocI7WKCDFKfOhn5YqJOLSAMo=; b=CteiXTkh45dDXd113TRR9A3Hye+YEahEbtK2nWiMg/SY07vrmfKzjCaGg/+0xA4Cvz SOLOvhvQ09SK6i/gvHakyMHUFVbPImDiVq9faIWNa795EobZXWKwp0QXJQXuNDE4qMZX J4MQsidZsEPWvaBBNc2YUF8bqf4WrkFM4CorBSLgG4NkdNeD1HrhcdbcoMEcpjcixkL6 3DXFa8UK+vTCUK0Pd93allME8zTzmeTTYyVSDaGz08e1vxym9R2k89ralZSRdp4tohl5 k19aneBhHjPUJeN4EUz9/Sn28A6TSR/x/3hc5HXTW+0SpiZF4PCqA+V6RWVhbKYAs4Fw dT0A== X-Gm-Message-State: AN3rC/5s5om4BQPCfYntokoLnWEO6jCEUbKK6ev9qybjFyfrx9KYK8pT rdPZ0fEiIM+QANsOrdU7Y+w5Xr44jw7j X-Received: by 10.99.106.5 with SMTP id f5mr19616960pgc.66.1494267189752; Mon, 08 May 2017 11:13:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.154.205 with HTTP; Mon, 8 May 2017 11:12:39 -0700 (PDT) In-Reply-To: References: <148416124213.8244.5842562779051799977.idtracker@ietfa.amsl.com> <9199091B-5D7F-4D66-9EC5-CB0EF2D3CF6D@lodderstedt.net> <30B37ED3-6E3B-4739-9917-BDEC198CA027@lodderstedt.net> From: Brian Campbell Date: Mon, 8 May 2017 12:12:39 -0600 Message-ID: To: Denis Cc: oauth Content-Type: multipart/alternative; boundary=94eb2c13f4560b99d4054f07317a Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 18:13:13 -0000 --94eb2c13f4560b99d4054f07317a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The actor_token is a security token so that's not an issue that needs to be addressed. On Mon, May 8, 2017 at 11:00 AM, Denis wrote: > Brian, > > The current text is: > > actor_token OPTIONAL. A security token that represents the identity of th= e > party that is authorized to use the requested security token and act on > behalf of the subject. > > This sentence is indeed wrong since an actor-token is not a security toke= n. > > So your proposed change does not solve this issue: actor_token > OPTIONAL. A security token that represents the identity of the acting > party. > > The current text states: > > Typically, in the request, the subject_token represents the identity of > the party on behalf of whom > the token is being requested while the actor_token represents the identit= y > of the party to whom the access > rights of the issued token are being delegated. > > Logically, the definition should be along the following lines: > > actor_token OPTIONAL. Indicates the identity of the party to whom the > access rights of the issued token are being delegated. > > If there is no delegation, then this field (which is optional) will not b= e > used. > > Anyway, thank you for requesting the change, otherwise this would have > been a left error. > > Denis > > I do have one minor issue I'd like to raise that relates to some > conversations I've been a party to recently about implementations and > applications of token exchange. > > I think that the current text in =C2=A72.1 for the "actor_token" is overl= y > specific towards the delegation scenario. I'd propose the language be > generalized somewhat to allow more versatility in applications/deployment= s > of the token exchange framework. Here's that text: > > actor_token > OPTIONAL. A security token that represents the identity of the > acting party. > > > > > On Mon, May 8, 2017 at 8:01 AM, Rifaat Shekh-Yusef > wrote: > >> Hi All, >> >> The last email from Brian addresses the multiple audiences/resources >> issue with an error code, and we did not see any objection to this appro= ach >> so far. >> >> >> *Authors,* >> >> Are there any other open issues with this draft? >> Do you believe it is ready for WGLC? >> >> Thanks, >> Rifaat & Hannes >> >> >> >> On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >>> As mentioned during the Chicago meeting the "invalid_target" error code >>> that was added in -07 was intended to give the AS a standard way to rej= ect >>> request with multiple audiences/resources that it doesn't understand or= is >>> unwilling or unable to process based on policy or whatever criteria . I= t >>> was intended as a compromise, of sorts, to allow for the multiple >>> resources/audiences in the request but provide an easy out for the AS o= f >>> saying it can't be supported based on whatever implementation or securi= ty >>> or policy it has. >>> >>> On Tue, Mar 28, 2017 at 1:32 AM, Nat Sakimura >>> wrote: >>> >>>> There are cases where tokens are supposed to be consumed at multiple >>>> places and the `aud` needed to capture them. That's why `aud` is a >>>> multi-valued field. >>>> >>>> On Mon, Mar 27, 2017 at 11:35 AM Torsten Lodderstedt < >>>> torsten@lodderstedt.net> wrote: >>>> >>>>> May I ask you to explain this reason? >>>>> >>>>> Am 27.03.2017 um 08:48 schrieb Mike Jones >>>> >: >>>>> >>>>> For the same reason that the =E2=80=9Caud=E2=80=9D claim is multi-val= ued in JWTs, the >>>>> audience needs to stay multi-valued in Token Exchange. Ditto for res= ources. >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> -- Mike >>>>> >>>>> >>>>> >>>>> *From:* OAuth [mailto:oauth-bounces@ietf.org = ] >>>>> *On Behalf Of *Brian Campbell >>>>> *Sent:* Monday, March 27, 2017 8:45 AM >>>>> *To:* Torsten Lodderstedt >>>>> *Cc:* oauth >>>>> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchang >>>>> e-07.txt >>>>> >>>>> >>>>> >>>>> Thanks for the review and question, Torsten. >>>>> >>>>> The desire to support multiple audience/resource values in the reques= t >>>>> came up during a review and discussion among the authors of the docum= ent >>>>> when preparing the -03 draft. As I recall, it was said that both Sale= sforce >>>>> and Microsoft had use-cases for it. I incorporated support for it int= o the >>>>> draft acting in the role of editor. >>>>> >>>>> From an individual perspective, I tend to agree with you that allowin= g >>>>> for multiple audiences/resources adds a lot of complexity that's like= not >>>>> needed in many (or most) cases. And I would personally be open to mak= ing >>>>> audience and resource mutual exclusive and single valued. A question = for >>>>> the WG I suppose. >>>>> >>>>> The "invalid_target" error code that was added in -07 was intended to >>>>> give the AS a standard way to deal with the complexity and reject req= uest >>>>> with multiple audiences/resources that it doesn't understand or is >>>>> unwilling or unable to process. It was intended as a compromise, of s= orts, >>>>> to allow for the multiples but provide an easy out of saying it can't= be >>>>> supported based on whatever implementation or policy of the AS. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Sun, Mar 26, 2017 at 9:00 AM, Torsten Lodderstedt < >>>>> torsten@lodderstedt.net> wrote: >>>>> >>>>> Hi Brian, >>>>> >>>>> >>>>> >>>>> thanks for the clarification around resource, audience and scope. >>>>> >>>>> >>>>> >>>>> Here are my comments on the draft: >>>>> >>>>> >>>>> >>>>> In section 2.1 it states: =E2=80=9EMultiple "resource" parameters may= be used >>>>> to indicate >>>>> >>>>> that the issued token is intended to be used at the multiple >>>>> >>>>> resources listed.=E2=80=9C >>>>> >>>>> >>>>> >>>>> Can you please explain the rational in more detail? I don=E2=80=99t u= nderstand >>>>> why there is a need to ask for access tokens, which are good for mult= iple >>>>> resources at once. This is a request type more or less exclusively us= ed in >>>>> server to server scenarios, right? So the only reason I can think of = is >>>>> call reduction. >>>>> >>>>> >>>>> >>>>> On the other side, this feature increases the AS's complexity, e.g. >>>>> its policy may prohibit to issue tokens for multiple resources in gen= eral >>>>> or the particular set the client is asking for. How shall the AS hand= les >>>>> such cases? >>>>> >>>>> >>>>> >>>>> And it is getting even more complicated given there could also be >>>>> multiple audience values and the client could mix them: >>>>> >>>>> >>>>> >>>>> "Multiple "audience" parameters >>>>> >>>>> may be used to indicate that the issued token is intended to be >>>>> >>>>> used at the multiple audiences listed. The "audience" and >>>>> >>>>> "resource" parameters may be used together to indicate multiple >>>>> >>>>> target services with a mix of logical names and physical >>>>> >>>>> locations.=E2=80=9C >>>>> >>>>> >>>>> >>>>> And in the end the client may add some scope values to the =E2=80=9Em= eal=E2=80=9C, >>>>> which brings us to >>>>> >>>>> >>>>> >>>>> =E2=80=9EEffectively, the requested access rights of the >>>>> >>>>> token are the cartesian product of all the scopes at all the targe= t >>>>> >>>>> services." >>>>> >>>>> >>>>> >>>>> I personally would suggest to drop support for multiple audience and >>>>> resource parameters and make audience and resource mutual exclusive. = I >>>>> think this is sufficient and much easier to implement. >>>>> >>>>> >>>>> >>>>> kind regards, >>>>> >>>>> Torsten. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Am 11.01.2017 um 20:04 schrieb Brian Campbell < >>>>> bcampbell@pingidentity.com>: >>>>> >>>>> >>>>> >>>>> Draft -07 of "OAuth 2.0 Token Exchange" has been published. The >>>>> primary change in -07 is the addition of a description of the relatio= nship >>>>> between audience/resource/scope, which was a request or comment that = came >>>>> up during the f2f meeting in Seoul. >>>>> >>>>> Excerpted from the Document History: >>>>> >>>>> -07 >>>>> >>>>> o Fixed typo (desecration -> discretion). >>>>> o Added an explanation of the relationship between scope, audienc= e >>>>> and resource in the request and added an "invalid_target" error >>>>> code enabling the AS to tell the client that the requested >>>>> audiences/resources were too broad. >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: >>>>> Date: Wed, Jan 11, 2017 at 12:00 PM >>>>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.tx= t >>>>> To: i-d-announce@ietf.org >>>>> Cc: oauth@ietf.org >>>>> >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> This draft is a work item of the Web Authorization Protocol of the >>>>> IETF. >>>>> >>>>> Title : OAuth 2.0 Token Exchange >>>>> Authors : Michael B. Jones >>>>> Anthony Nadalin >>>>> Brian Campbell >>>>> John Bradley >>>>> Chuck Mortimore >>>>> Filename : draft-ietf-oauth-token-exchange-07.txt >>>>> Pages : 31 >>>>> Date : 2017-01-11 >>>>> >>>>> Abstract: >>>>> This specification defines a protocol for an HTTP- and JSON- based >>>>> Security Token Service (STS) by defining how to request and obtain >>>>> security tokens from OAuth 2.0 authorization servers, including >>>>> security tokens employing impersonation and delegation. >>>>> >>>>> >>>>> 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-07 >>>>> >>>>> A diff from the previous version is available at: >>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-token-exchange-0= 7 >>>>> >>>>> >>>>> 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 >>>>> >>>> -- >>>> >>>> Nat Sakimura >>>> >>>> Chairman of the Board, OpenID Foundation >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --94eb2c13f4560b99d4054f07317a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The actor_token is a security token so that's not an i= ssue that needs to be addressed.





On Mon, May 8, 2017 at 11:00 AM, D= enis <denis.ietf@free.fr> wrote:
=20 =20 =20
Brian,

The current text is:

actor_token OPTIONAL. A security token that represents the identity of the party that is authorized to use the requested security token and act on behalf of the subject.

This sentence is indeed wrong since an actor-token is not a security token.

So your proposed change does not solve this issue: actor_token=C2=A0 OPTIONAL.=C2=A0 A security token that represents the identity of the acting party.

The current text states:
Typically, in the request, the subject_token represents the identity of the party on behalf of whom
the token is being requested while the actor_token represents the identity of the party to whom the access
rights of the issued token are being delegated.
Logically, the definition should be along the following lines:

=C2=A0actor_token OPTIONAL. Indicates the identity of the party to whom the access rights of the issued token are being delegated.

If there is no delegation, then this field (which is optional) will not be used.

Anyway, thank you for requesting the change, otherwise this would have been a left error.

Denis

I do have one minor issue I'd like to raise that relates t= o some conversations I've been a party to recently about implementations and applications of token exchange.

I think that the current text in =C2=A72.1 for the "actor= _token" is overly specific towards the delegation scenario. I'd propose the language be generalized somewhat to allow more versatility in applications/deployments of the token exchange framework. Here's that text:

=C2=A0=C2=A0 actor_token
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OPTIONAL.=C2=A0 A security token t= hat represents the identity of the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 acting party.=C2=A0




On Mon, May 8, 2017 at 8:01 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Hi All,

The last email from Brian addresses the multiple audiences/resources issue with an error code, and we did not see any objection to this approach so far.


Authors,

Are there any other open issues with this draft?
Do you believe it is ready for WGLC?

Thanks,
=C2=A0Rifaat & Hannes



On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell <bcampbell@pingidentity.co= m> wrote:
As mentioned during the Chicago meeting the "invalid_target" error code t= hat was added in -07 was intended to give the AS a standard way to reject request with multiple audiences/resources that it doesn't understand or is unwilling or unable to process based on policy or whatever criteria . It was intended as a compromise, of sorts, to allow for the multiple resources/audiences in the request but provide an easy out for the AS of saying it can't be supported based on whatever implementation or security or policy it has.

On Tue, Mar 28, 2017 at 1:32 AM, Nat Sakimura <sakimura@gma= il.com> wrote:
There are cases where tokens are supposed to be consumed at multiple places and the `aud` needed to capture them. That's why `aud` is = a multi-valued field.=C2=A0

On Mon, Mar 27, 2017 at 11:35 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
May I ask you to explain this reason?

Am 27.03.2017 um 08:48 schrieb Mike Jones <= Michael.Jones@microsoft.com>:

For the same reason that the =E2=80=9Caud= =E2=80=9D claim is multi-valued in JWTs, the audience needs to stay multi-valued in Token Exchange.=C2=A0 Ditto for resources.=

=C2=A0=

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Thanks,

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=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: Monday, March 27, 2017 8:45 AM To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-to= ken-exchange-07.txt

=C2=A0

Thanks for the review and question, Torsten.

The desire to support multiple audience/resource values in the request came up during a review and discussion among the authors of the document when preparing the -03 draft. As I recall, it was said that both Salesforce and Microsoft had use-cases for it. I incorporated support for it into the draft acting in the role of editor.

From an individual perspective, I tend to agree with you that allowing for multiple audiences/resourc= es adds a lot of complexity that's like not needed in many (or most) cases. And I would personally be open to making audience and resource mutual exclusive and single valued. A question for the WG I suppose.

The "invalid_target" error code that was added in -07 was intended to= give the AS a standard way to deal with the complexity and reject request with multiple audiences/resourc= es that it doesn't understand or is unwilling or unable to process. It was intended as a compromise, of sorts, to allow for the multiples but provide an easy out of saying it can't be supported based on whatever implementation or policy of the AS.

=C2=A0

=C2=A0

=C2=A0

On Sun, Mar 26, 2017 at 9:00 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi Brian,

=C2=A0

thanks for the clarification around resource, audience and scope.=C2=A0

=C2=A0

Here are my comments on the draft:

=C2=A0

In section 2.1 it states: =E2=80=9EMultiple "resource&qu= ot; parameters may be used to indicate

=C2=A0 =C2=A0 =C2=A0 tha= t the issued token is intended to be used at the multiple

=C2=A0 =C2=A0 =C2=A0 res= ources listed.=E2=80=9C<= /p>

=C2=A0

Can you please explain the rational in more detail? I don=E2=80=99t understand why there is a need to ask for access tokens, which are good for multiple resources at once. This is a request type more or less exclusively used in server to server scenarios, right? So the only reason I can think of is call reduction.=C2=A0<= /p>

=C2=A0

On the other side, this feature increases the AS's complexity, e.g. its policy may prohibit to issue tokens for multiple resources in general or the particular set the client is asking for. How shall the AS handles such cases?

=C2=A0

And it is getting even more complicated given there could also be multiple audience values and the client could mix them:=C2=A0

=C2=A0

"Multiple "audience&qu= ot; parameters

=C2=A0 =C2=A0 =C2=A0 may= be used to indicate that the issued token is intended to be

=C2=A0 =C2=A0 =C2=A0 use= d at the multiple audiences listed.=C2=A0 The "audience&qu= ot; and

=C2=A0 =C2=A0 =C2=A0 &qu= ot;resource" parameters may be used together to indicate multiple

=C2=A0 =C2=A0 =C2=A0 tar= get services with a mix of logical names and physical

=C2=A0 =C2=A0 =C2=A0 locations.=E2=80= =9C

=C2=A0

And in the end the client may add some scope values to the =E2=80=9Emeal=E2= =80=9C, which brings us to=C2= =A0

=C2=A0

=E2=80=9EEffectively, the requested access rights of the

=C2=A0 =C2=A0token are t= he cartesian product of all the scopes at all the target

=C2=A0 =C2=A0services.&q= uot;

=C2=A0

I personally would suggest to drop support for multiple audience and resource parameters and make audience and resource mutual exclusive. I think this is sufficient and much easier to implement.

=C2=A0

kind regards,

Torsten.

=C2=A0

=C2=A0

Am 11.01.2017 um 20:04 schrieb Brian Campbell <bcampbell@pingidentity.com>:

=C2=A0

Draft -07 of "OAuth 2.0 Token Exchange" has been published. The primary change in -07 is the addition of a description of the relationship between audience/resource= /scope, which was a request or comment that came up during the f2f meeting in Seoul.

Excerpted from the Document History:

=C2=A0=C2=A0 -07<= br class=3D"m_8675160420969604263m_-2675142197049852080m_398329883455891527= 7m_-4354184635220679769gmail_msg">
=C2=A0=C2=A0 o=C2= =A0 Fixed typo (desecration -> discretion).
=C2=A0=C2=A0 o=C2= =A0 Added an explanation of the relationship between scope, audience
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 and resource in the request and added an "invalid_tar= get" error
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 code enabling the AS to tell the client that the requested
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 audiences/resourc= es were too broad.

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Wed, Jan 11, 2017 at 12:00 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-= token-exchange-07.txt
To: i-d-announce@ietf.org
Cc: oauth= @ietf.org



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

=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0: OAuth 2.0 Token Exchange =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Authors=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0: Michael B= . Jones
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Anthony Nadalin
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Brian Campbell =C2=A0 =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 Chuck Mortimore
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Filename=C2=A0 = =C2=A0 =C2=A0 =C2=A0 : draft-ietf-oauth-= token-exchange-07.txt
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0: 31
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 : 2017-01-11

Abstract:
=C2=A0 =C2=A0This specification defines a protocol for an HTTP- and JSON- based
=C2=A0 =C2=A0Secu= rity Token Service (STS) by defining how to request and obtain
=C2=A0 =C2=A0secu= rity tokens from OAuth 2.0 authorization servers, including
=C2=A0 =C2=A0secu= rity tokens employing impersonation and delegation.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dr= aft-ietf-oauth-token-exchange/

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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?u= rl2=3Ddraft-ietf-oauth-token-exchange-07


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

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

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

=C2=A0

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

=C2=A0

=C2=A0


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

Nat Sakimura

Chairman of the Board, OpenID Foundation


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



_______________________________________________<= br> OAuth mailing list
O= Auth@ietf.org
https://www.ietf.org/mailman/l= istinfo/oauth





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



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


--94eb2c13f4560b99d4054f07317a-- From nobody Mon May 8 12:36:43 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA61A1296B3 for ; Mon, 8 May 2017 12:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnejQSield7i for ; Mon, 8 May 2017 12:36:34 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6160F129A8E for ; Mon, 8 May 2017 12:36:34 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id e64so37807507pfd.1 for ; Mon, 08 May 2017 12:36:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=96W4R6IjNq9HflZgjefIbpmq8Rjz1MxFAGNnU3opWz8=; b=i+UFV0GAzY1ovXk/FechN1VIGBtbmvo0h70OS9o4mndvpt0HSyKEInau/i/g6CATeD tCEo3fmu1JxksnvLklHq1jAPkMiLnl8J6ogCWpUV+5Nbh6vYFotDVZ9eFrywUyCJkFYV /cjj195WfTocR4AEU0CJUmMdasH8jsPOe0I9g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=96W4R6IjNq9HflZgjefIbpmq8Rjz1MxFAGNnU3opWz8=; b=mcizlo5eW1MRpGbHZJvQF/zJ64GWFl7KgCYs6Dh7RLR9nWz7NvNBfT9BjG7RSJY/V4 XXuxMDSAkFt07C4g5kRE2FcOTaYn6pD/HLBTKZuKpmNLrxsKnwjjSQK6kaXlSn3aN0th 9UB9uvIBoxWHwoj8bbUCf9hYKyUA/1Oigmk63HDaleEvA7W7AD9zmC/GNhtsnUUMVOkQ BVRb8k4hIDTyUwfCT/vu0WvoWPhwxltFrDZxLeXj6uWW5LwmY9jkSqPNVe6IKREj/wMb tOReRmjb/EGSjttTomeNwg2bIY+w2tyE9kCTu4QwLoWVi+7e7Ia2dxtjoRhC9Zmz4DMB B2gQ== X-Gm-Message-State: AN3rC/5EqH7QU4WIfEI/J56qEuWpvAoqPVqAWWKrhtaeP7WpiKn3xr6Q 2l9mwVis6HhgweAeRs7Cd/Mt+Rpd+cMp X-Received: by 10.99.123.77 with SMTP id k13mr20947624pgn.32.1494272193757; Mon, 08 May 2017 12:36:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.154.205 with HTTP; Mon, 8 May 2017 12:36:03 -0700 (PDT) In-Reply-To: References: <148416124213.8244.5842562779051799977.idtracker@ietfa.amsl.com> <9199091B-5D7F-4D66-9EC5-CB0EF2D3CF6D@lodderstedt.net> <30B37ED3-6E3B-4739-9917-BDEC198CA027@lodderstedt.net> From: Brian Campbell Date: Mon, 8 May 2017 13:36:03 -0600 Message-ID: To: Rifaat Shekh-Yusef Cc: Nat Sakimura , oauth Content-Type: multipart/alternative; boundary=f403045c5f804eada4054f085b35 Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 19:36:42 -0000 --f403045c5f804eada4054f085b35 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Let me throw out a bit more context about this. The "actor_token" might, in a delegation scenario, represent the identity of the party to whom the access rights of the issued token are being delegated. That's the typical delegation scenario that is discussed in the draft. However, the "actor_token" might also be utilized/needed by the AS in an impersonation scenario for policy or auditing reasons even when the resulting issued token doesn't contain info about the delegation or actor. Similarly, the actor might not be strictly doing the impersonation but rather just be a party (again maybe needed for policy or auditing) to the token exchange event itself. When I wrote the "actor_token" text in section 2.1 some ~18 months ago I had the delegation scenario at the front of my mind and (clearly) intended to accommodate it. However, I didn't intend to limit it to only that and, looking at the text again, I think what is there now is too prescriptive and narrow. Thus my proposing to generalize the text somewhat. On Mon, May 8, 2017 at 10:29 AM, Brian Campbell wrote: > I do have one minor issue I'd like to raise that relates to some > conversations I've been a party to recently about implementations and > applications of token exchange. > > I think that the current text in =C2=A72.1 for the "actor_token" is overl= y > specific towards the delegation scenario. I'd propose the language be > generalized somewhat to allow more versatility in applications/deployment= s > of the token exchange framework. Here's that text: > > actor_token > OPTIONAL. A security token that represents the identity of the > acting party. > > > > > On Mon, May 8, 2017 at 8:01 AM, Rifaat Shekh-Yusef > wrote: > >> Hi All, >> >> The last email from Brian addresses the multiple audiences/resources >> issue with an error code, and we did not see any objection to this appro= ach >> so far. >> >> >> *Authors,* >> >> Are there any other open issues with this draft? >> Do you believe it is ready for WGLC? >> >> Thanks, >> Rifaat & Hannes >> >> >> >> On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >>> As mentioned during the Chicago meeting the "invalid_target" error code >>> that was added in -07 was intended to give the AS a standard way to rej= ect >>> request with multiple audiences/resources that it doesn't understand or= is >>> unwilling or unable to process based on policy or whatever criteria . I= t >>> was intended as a compromise, of sorts, to allow for the multiple >>> resources/audiences in the request but provide an easy out for the AS o= f >>> saying it can't be supported based on whatever implementation or securi= ty >>> or policy it has. >>> >>> On Tue, Mar 28, 2017 at 1:32 AM, Nat Sakimura >>> wrote: >>> >>>> There are cases where tokens are supposed to be consumed at multiple >>>> places and the `aud` needed to capture them. That's why `aud` is a >>>> multi-valued field. >>>> >>>> On Mon, Mar 27, 2017 at 11:35 AM Torsten Lodderstedt < >>>> torsten@lodderstedt.net> wrote: >>>> >>>>> May I ask you to explain this reason? >>>>> >>>>> Am 27.03.2017 um 08:48 schrieb Mike Jones >>>> >: >>>>> >>>>> For the same reason that the =E2=80=9Caud=E2=80=9D claim is multi-val= ued in JWTs, the >>>>> audience needs to stay multi-valued in Token Exchange. Ditto for res= ources. >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> -- Mike >>>>> >>>>> >>>>> >>>>> *From:* OAuth [mailto:oauth-bounces@ietf.org = ] >>>>> *On Behalf Of *Brian Campbell >>>>> *Sent:* Monday, March 27, 2017 8:45 AM >>>>> *To:* Torsten Lodderstedt >>>>> *Cc:* oauth >>>>> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchang >>>>> e-07.txt >>>>> >>>>> >>>>> >>>>> Thanks for the review and question, Torsten. >>>>> >>>>> The desire to support multiple audience/resource values in the reques= t >>>>> came up during a review and discussion among the authors of the docum= ent >>>>> when preparing the -03 draft. As I recall, it was said that both Sale= sforce >>>>> and Microsoft had use-cases for it. I incorporated support for it int= o the >>>>> draft acting in the role of editor. >>>>> >>>>> From an individual perspective, I tend to agree with you that allowin= g >>>>> for multiple audiences/resources adds a lot of complexity that's like= not >>>>> needed in many (or most) cases. And I would personally be open to mak= ing >>>>> audience and resource mutual exclusive and single valued. A question = for >>>>> the WG I suppose. >>>>> >>>>> The "invalid_target" error code that was added in -07 was intended to >>>>> give the AS a standard way to deal with the complexity and reject req= uest >>>>> with multiple audiences/resources that it doesn't understand or is >>>>> unwilling or unable to process. It was intended as a compromise, of s= orts, >>>>> to allow for the multiples but provide an easy out of saying it can't= be >>>>> supported based on whatever implementation or policy of the AS. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Sun, Mar 26, 2017 at 9:00 AM, Torsten Lodderstedt < >>>>> torsten@lodderstedt.net> wrote: >>>>> >>>>> Hi Brian, >>>>> >>>>> >>>>> >>>>> thanks for the clarification around resource, audience and scope. >>>>> >>>>> >>>>> >>>>> Here are my comments on the draft: >>>>> >>>>> >>>>> >>>>> In section 2.1 it states: =E2=80=9EMultiple "resource" parameters may= be used >>>>> to indicate >>>>> >>>>> that the issued token is intended to be used at the multiple >>>>> >>>>> resources listed.=E2=80=9C >>>>> >>>>> >>>>> >>>>> Can you please explain the rational in more detail? I don=E2=80=99t u= nderstand >>>>> why there is a need to ask for access tokens, which are good for mult= iple >>>>> resources at once. This is a request type more or less exclusively us= ed in >>>>> server to server scenarios, right? So the only reason I can think of = is >>>>> call reduction. >>>>> >>>>> >>>>> >>>>> On the other side, this feature increases the AS's complexity, e.g. >>>>> its policy may prohibit to issue tokens for multiple resources in gen= eral >>>>> or the particular set the client is asking for. How shall the AS hand= les >>>>> such cases? >>>>> >>>>> >>>>> >>>>> And it is getting even more complicated given there could also be >>>>> multiple audience values and the client could mix them: >>>>> >>>>> >>>>> >>>>> "Multiple "audience" parameters >>>>> >>>>> may be used to indicate that the issued token is intended to be >>>>> >>>>> used at the multiple audiences listed. The "audience" and >>>>> >>>>> "resource" parameters may be used together to indicate multiple >>>>> >>>>> target services with a mix of logical names and physical >>>>> >>>>> locations.=E2=80=9C >>>>> >>>>> >>>>> >>>>> And in the end the client may add some scope values to the =E2=80=9Em= eal=E2=80=9C, >>>>> which brings us to >>>>> >>>>> >>>>> >>>>> =E2=80=9EEffectively, the requested access rights of the >>>>> >>>>> token are the cartesian product of all the scopes at all the targe= t >>>>> >>>>> services." >>>>> >>>>> >>>>> >>>>> I personally would suggest to drop support for multiple audience and >>>>> resource parameters and make audience and resource mutual exclusive. = I >>>>> think this is sufficient and much easier to implement. >>>>> >>>>> >>>>> >>>>> kind regards, >>>>> >>>>> Torsten. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Am 11.01.2017 um 20:04 schrieb Brian Campbell < >>>>> bcampbell@pingidentity.com>: >>>>> >>>>> >>>>> >>>>> Draft -07 of "OAuth 2.0 Token Exchange" has been published. The >>>>> primary change in -07 is the addition of a description of the relatio= nship >>>>> between audience/resource/scope, which was a request or comment that = came >>>>> up during the f2f meeting in Seoul. >>>>> >>>>> Excerpted from the Document History: >>>>> >>>>> -07 >>>>> >>>>> o Fixed typo (desecration -> discretion). >>>>> o Added an explanation of the relationship between scope, audienc= e >>>>> and resource in the request and added an "invalid_target" error >>>>> code enabling the AS to tell the client that the requested >>>>> audiences/resources were too broad. >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: >>>>> Date: Wed, Jan 11, 2017 at 12:00 PM >>>>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.tx= t >>>>> To: i-d-announce@ietf.org >>>>> Cc: oauth@ietf.org >>>>> >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> This draft is a work item of the Web Authorization Protocol of the >>>>> IETF. >>>>> >>>>> Title : OAuth 2.0 Token Exchange >>>>> Authors : Michael B. Jones >>>>> Anthony Nadalin >>>>> Brian Campbell >>>>> John Bradley >>>>> Chuck Mortimore >>>>> Filename : draft-ietf-oauth-token-exchange-07.txt >>>>> Pages : 31 >>>>> Date : 2017-01-11 >>>>> >>>>> Abstract: >>>>> This specification defines a protocol for an HTTP- and JSON- based >>>>> Security Token Service (STS) by defining how to request and obtain >>>>> security tokens from OAuth 2.0 authorization servers, including >>>>> security tokens employing impersonation and delegation. >>>>> >>>>> >>>>> 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-07 >>>>> >>>>> A diff from the previous version is available at: >>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-token-exchange-0= 7 >>>>> >>>>> >>>>> 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 >>>>> >>>> -- >>>> >>>> Nat Sakimura >>>> >>>> Chairman of the Board, OpenID Foundation >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> > --f403045c5f804eada4054f085b35 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Let me throw out a bit more context about this. The "= actor_token" might, in a delegation scenario, represent the identity o= f the party to whom the access rights of the issued token are being delegat= ed. That's the typical delegation scenario that is discussed in the dra= ft. However, the "actor_token" might also be utilized/needed by t= he AS in an impersonation scenario for policy or auditing reasons even when= the resulting issued token doesn't contain info about the delegation o= r actor. Similarly, the actor might not be strictly doing the impersonation= but rather just be a party (again maybe needed for policy or auditing) to = the token exchange event itself.=C2=A0 When I wrote the "actor_token&q= uot; text in section 2.1 some ~18 months ago I had the delegation scenario = at the front of my mind and (clearly) intended to accommodate it. However, = I didn't intend to limit it to only that and, looking at the text again= , I think what is there now is too prescriptive and narrow. Thus my propos= ing to generalize the text somewhat.
--f403045c5f804eada4054f085b35-- From nobody Tue May 9 02:06:13 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCCD0129B4C for ; Tue, 9 May 2017 02:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-31-L6y740s for ; Tue, 9 May 2017 02:06:05 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE17E129AF4 for ; Tue, 9 May 2017 02:06:04 -0700 (PDT) Received: from [192.168.0.14] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 340227803DB for ; Tue, 9 May 2017 11:06:02 +0200 (CEST) To: oauth@ietf.org References: <148416124213.8244.5842562779051799977.idtracker@ietfa.amsl.com> <9199091B-5D7F-4D66-9EC5-CB0EF2D3CF6D@lodderstedt.net> <30B37ED3-6E3B-4739-9917-BDEC198CA027@lodderstedt.net> From: Denis Message-ID: Date: Tue, 9 May 2017 11:06:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CC3E33AA91603DC8713D19C6" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 09:06:10 -0000 This is a multi-part message in MIME format. --------------CC3E33AA91603DC8713D19C6 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Brian, You omitted to include my comments in this post. So here it is again: =========================================================== The current text is: actor_token OPTIONAL. A security token that represents the identity of the party that is authorized to use the requested security token and act on behalf of the subject. This sentence is indeed wrong since an actor-token is not a security token. So your proposed change does not solve this issue: actor_token OPTIONAL. A security token that represents the identity of the acting party. The current text states: Typically, in the request, the subject_token represents the identity of the party on behalf of whom the token is being requested while the actor_token represents the identity of the party to whom the access rights of the issued token are being delegated. Logically, the definition should be along the following lines: actor_token OPTIONAL. Indicates the identity of the party to whom the access rights of the issued token are being delegated. If there is no delegation, then this field (which is optional) will not be used. =========================================================== I read your argumentation, but I maintain my comment. Each field should have a precise semantics. If you want to have another semantics, you should propose to define another field with its precise meaning. Denis > Let me throw out a bit more context about this. The "actor_token" > might, in a delegation scenario, represent the identity of the party > to whom the access rights of the issued token are being delegated. > That's the typical delegation scenario that is discussed in the draft. > However, the "actor_token" might also be utilized/needed by the AS in > an impersonation scenario for policy or auditing reasons even when the > resulting issued token doesn't contain info about the delegation or > actor. Similarly, the actor might not be strictly doing the > impersonation but rather just be a party (again maybe needed for > policy or auditing) to the token exchange event itself. When I wrote > the "actor_token" text in section 2.1 some ~18 months ago I had the > delegation scenario at the front of my mind and (clearly) intended to > accommodate it. However, I didn't intend to limit it to only that and, > looking at the text again, I think what is there now is too > prescriptive and narrow. Thus my proposing to generalize the text > somewhat. > > > > > On Mon, May 8, 2017 at 10:29 AM, Brian Campbell > > wrote: > > I do have one minor issue I'd like to raise that relates to some > conversations I've been a party to recently about implementations > and applications of token exchange. > > I think that the current text in §2.1 for the "actor_token" is > overly specific towards the delegation scenario. I'd propose the > language be generalized somewhat to allow more versatility in > applications/deployments of the token exchange framework. Here's > that text: > > actor_token > OPTIONAL. A security token that represents the identity of the > acting party. > > > > > On Mon, May 8, 2017 at 8:01 AM, Rifaat Shekh-Yusef > > wrote: > > Hi All, > > The last email from Brian addresses the multiple > audiences/resources issue with an error code, and we did not > see any objection to this approach so far. > > > *Authors,* > > Are there any other open issues with this draft? > Do you believe it is ready for WGLC? > > Thanks, > Rifaat & Hannes > > > > On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell > > wrote: > > As mentioned during the Chicago meeting the > "invalid_target" error code that was added in -07 was > intended to give the AS a standard way to reject request > with multiple audiences/resources that it doesn't > understand or is unwilling or unable to process based on > policy or whatever criteria . It was intended as a > compromise, of sorts, to allow for the multiple > resources/audiences in the request but provide an easy out > for the AS of saying it can't be supported based on > whatever implementation or security or policy it has. > > On Tue, Mar 28, 2017 at 1:32 AM, Nat Sakimura > > wrote: > > There are cases where tokens are supposed to be > consumed at multiple places and the `aud` needed to > capture them. That's why `aud` is a multi-valued field. > > On Mon, Mar 27, 2017 at 11:35 AM Torsten Lodderstedt > > wrote: > > May I ask you to explain this reason? > >> Am 27.03.2017 um 08:48 schrieb Mike Jones >> > >: >> >> For the same reason that the “aud” claim is >> multi-valued in JWTs, the audience needs to stay >> multi-valued in Token Exchange. Ditto for resources. >> >> Thanks, >> >> -- Mike >> >> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On >> Behalf Of *Brian Campbell >> *Sent:* Monday, March 27, 2017 8:45 AM >> *To:* Torsten Lodderstedt >> > > >> *Cc:* oauth > >> *Subject:* Re: [OAUTH-WG] I-D Action: >> draft-ietf-oauth-token-exchange-07.txt >> >> Thanks for the review and question, Torsten. >> >> The desire to support multiple audience/resource >> values in the request came up during a review and >> discussion among the authors of the document when >> preparing the -03 draft. As I recall, it was said >> that both Salesforce and Microsoft had use-cases >> for it. I incorporated support for it into the >> draft acting in the role of editor. >> >> From an individual perspective, I tend to agree >> with you that allowing for multiple >> audiences/resources adds a lot of complexity >> that's like not needed in many (or most) cases. >> And I would personally be open to making audience >> and resource mutual exclusive and single valued. >> A question for the WG I suppose. >> >> The "invalid_target" error code that was added in >> -07 was intended to give the AS a standard way to >> deal with the complexity and reject request with >> multiple audiences/resources that it doesn't >> understand or is unwilling or unable to process. >> It was intended as a compromise, of sorts, to >> allow for the multiples but provide an easy out >> of saying it can't be supported based on whatever >> implementation or policy of the AS. >> >> On Sun, Mar 26, 2017 at 9:00 AM, Torsten >> Lodderstedt > > wrote: >> >> Hi Brian, >> >> thanks for the clarification around resource, >> audience and scope. >> >> Here are my comments on the draft: >> >> In section 2.1 it states: „Multiple >> "resource" parameters may be used to indicate >> >> that the issued token is intended to be >> used at the multiple >> >> resources listed.“ >> >> Can you please explain the rational in more >> detail? I don’t understand why there is a >> need to ask for access tokens, which are good >> for multiple resources at once. This is a >> request type more or less exclusively used in >> server to server scenarios, right? So the >> only reason I can think of is call reduction. >> >> On the other side, this feature increases the >> AS's complexity, e.g. its policy may prohibit >> to issue tokens for multiple resources in >> general or the particular set the client is >> asking for. How shall the AS handles such cases? >> >> And it is getting even more complicated given >> there could also be multiple audience values >> and the client could mix them: >> >> "Multiple "audience" parameters >> >> may be used to indicate that the issued >> token is intended to be >> >> used at the multiple audiences listed. >> The "audience" and >> >> "resource" parameters may be used >> together to indicate multiple >> >> target services with a mix of logical >> names and physical >> >> locations.“ >> >> And in the end the client may add some scope >> values to the „meal“, which brings us to >> >> „Effectively, the requested access rights of the >> >> token are the cartesian product of all the >> scopes at all the target >> >> services." >> >> I personally would suggest to drop support >> for multiple audience and resource parameters >> and make audience and resource mutual >> exclusive. I think this is sufficient and >> much easier to implement. >> >> kind regards, >> >> Torsten. >> >> Am 11.01.2017 um 20:04 schrieb Brian >> Campbell > >: >> >> Draft -07 of "OAuth 2.0 Token Exchange" >> has been published. The primary change in >> -07 is the addition of a description of >> the relationship between >> audience/resource/scope, which was a >> request or comment that came up during >> the f2f meeting in Seoul. >> >> Excerpted from the Document History: >> >> -07 >> >> o Fixed typo (desecration -> discretion). >> o Added an explanation of the >> relationship between scope, audience >> and resource in the request and >> added an "invalid_target" error >> code enabling the AS to tell the >> client that the requested >> audiences/resources were too broad. >> >> ---------- Forwarded message ---------- >> From: > > >> Date: Wed, Jan 11, 2017 at 12:00 PM >> Subject: [OAUTH-WG] I-D Action: >> draft-ietf-oauth-token-exchange-07.txt >> To: i-d-announce@ietf.org >> >> Cc: oauth@ietf.org >> >> >> >> A New Internet-Draft is available from >> the on-line Internet-Drafts directories. >> This draft is a work item of the Web >> Authorization Protocol of the IETF. >> >> Title : OAuth 2.0 Token >> Exchange >> Authors : Michael B. Jones >> Anthony Nadalin >> Brian Campbell >> John Bradley >> Chuck Mortimore >> Filename : >> draft-ietf-oauth-token-exchange-07.txt >> Pages : 31 >> Date : 2017-01-11 >> >> Abstract: >> This specification defines a protocol >> for an HTTP- and JSON- based >> Security Token Service (STS) by >> defining how to request and obtain >> security tokens from OAuth 2.0 >> authorization servers, including >> security tokens employing >> impersonation and delegation. >> >> >> 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-07 >> >> >> A diff from the previous version is >> available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-07 >> >> >> >> Please note that it may take a couple of >> minutes from the time of submission >> until the htmlized version and diff are >> available at tools.ietf.org >> . >> >> Internet-Drafts are also available by >> anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > -- > > Nat Sakimura > > Chairman of the Board, OpenID Foundation > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------CC3E33AA91603DC8713D19C6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Brian,

You omitted to include my comments in this post. So here it is again:

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

The current text is:

actor_token OPTIONAL. A security token that represents the identity of the party that is authorized to use the requested security token and act on behalf of the subject.

This sentence is indeed wrong since an actor-token is not a security token.

So your proposed change does not solve this issue: actor_token  OPTIONAL.  A security token that represents the identity of the acting party.

The current text states:
Typically, in the request, the subject_token represents the identity of the party on behalf of whom
the token is being requested while the actor_token represents the identity of the party to whom the access
rights of the issued token are being delegated.
Logically, the definition should be along the following lines:

 actor_token OPTIONAL. Indicates the identity of the party to whom the access rights of the issued token are being delegated.

If there is no delegation, then this field (which is optional) will not be used.

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

I read your argumentation, but I maintain my comment. Each field should have a precise semantics.

If you want to have another semantics, you should propose to define another field with its precise meaning.

Denis

Let me throw out a bit more context about this. The "actor_token" might, in a delegation scenario, represent the identity of the party to whom the access rights of the issued token are being delegated. That's the typical delegation scenario that is discussed in the draft. However, the "actor_token" might also be utilized/needed by the AS in an impersonation scenario for policy or auditing reasons even when the resulting issued token doesn't contain info about the delegation or actor. Similarly, the actor might not be strictly doing the impersonation but rather just be a party (again maybe needed for policy or auditing) to the token exchange event itself.  When I wrote the "actor_token" text in section 2.1 some ~18 months ago I had the delegation scenario at the front of my mind and (clearly) intended to accommodate it. However, I didn't intend to limit it to only that and, looking at the text again, I think what is there now is too prescriptive and narrow. Thus my proposing to generalize the text somewhat.




On Mon, May 8, 2017 at 10:29 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
I do have one minor issue I'd like to raise that relates to some conversations I've been a party to recently about implementations and applications of token exchange.

I think that the current text in §2.1 for the "actor_token" is overly specific towards the delegation scenario. I'd propose the language be generalized somewhat to allow more versatility in applications/deployments of the token exchange framework. Here's that text:

   actor_token
      OPTIONAL.  A security token that represents the identity of the
      acting party. 




On Mon, May 8, 2017 at 8:01 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Hi All,

The last email from Brian addresses the multiple audiences/resources issue with an error code, and we did not see any objection to this approach so far.


Authors,

Are there any other open issues with this draft?
Do you believe it is ready for WGLC?

Thanks,
 Rifaat & Hannes



On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
As mentioned during the Chicago meeting the "invalid_target" error code that was added in -07 was intended to give the AS a standard way to reject request with multiple audiences/resources that it doesn't understand or is unwilling or unable to process based on policy or whatever criteria . It was intended as a compromise, of sorts, to allow for the multiple resources/audiences in the request but provide an easy out for the AS of saying it can't be supported based on whatever implementation or security or policy it has.

On Tue, Mar 28, 2017 at 1:32 AM, Nat Sakimura <sakimura@gmail.com> wrote:
There are cases where tokens are supposed to be consumed at multiple places and the `aud` needed to capture them. That's why `aud` is a multi-valued field. 

On Mon, Mar 27, 2017 at 11:35 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
May I ask you to explain this reason?

Am 27.03.2017 um 08:48 schrieb Mike Jones <Michael.Jones@microsoft.com>:

For the same reason that the “aud” claim is multi-valued in JWTs, the audience needs to stay multi-valued in Token Exchange.  Ditto for resources.

 

                                                       Thanks,

                                                       -- Mike

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Monday, March 27, 2017 8:45 AM
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt

 

Thanks for the review and question, Torsten.

The desire to support multiple audience/resource values in the request came up during a review and discussion among the authors of the document when preparing the -03 draft. As I recall, it was said that both Salesforce and Microsoft had use-cases for it. I incorporated support for it into the draft acting in the role of editor.

From an individual perspective, I tend to agree with you that allowing for multiple audiences/resources adds a lot of complexity that's like not needed in many (or most) cases. And I would personally be open to making audience and resource mutual exclusive and single valued. A question for the WG I suppose.

The "invalid_target" error code that was added in -07 was intended to give the AS a standard way to deal with the complexity and reject request with multiple audiences/resources that it doesn't understand or is unwilling or unable to process. It was intended as a compromise, of sorts, to allow for the multiples but provide an easy out of saying it can't be supported based on whatever implementation or policy of the AS.

 

 

 

On Sun, Mar 26, 2017 at 9:00 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi Brian,

 

thanks for the clarification around resource, audience and scope. 

 

Here are my comments on the draft:

 

In section 2.1 it states: „Multiple "resource" parameters may be used to indicate

      that the issued token is intended to be used at the multiple

      resources listed.“

 

Can you please explain the rational in more detail? I don’t understand why there is a need to ask for access tokens, which are good for multiple resources at once. This is a request type more or less exclusively used in server to server scenarios, right? So the only reason I can think of is call reduction. 

 

On the other side, this feature increases the AS's complexity, e.g. its policy may prohibit to issue tokens for multiple resources in general or the particular set the client is asking for. How shall the AS handles such cases?

 

And it is getting even more complicated given there could also be multiple audience values and the client could mix them: 

 

"Multiple "audience" parameters

      may be used to indicate that the issued token is intended to be

      used at the multiple audiences listed.  The "audience" and

      "resource" parameters may be used together to indicate multiple

      target services with a mix of logical names and physical

      locations.“

 

And in the end the client may add some scope values to the „meal“, which brings us to 

 

„Effectively, the requested access rights of the

   token are the cartesian product of all the scopes at all the target

   services."

 

I personally would suggest to drop support for multiple audience and resource parameters and make audience and resource mutual exclusive. I think this is sufficient and much easier to implement.

 

kind regards,

Torsten.

 

 

Am 11.01.2017 um 20:04 schrieb Brian Campbell <bcampbell@pingidentity.com>:

 

Draft -07 of "OAuth 2.0 Token Exchange" has been published. The primary change in -07 is the addition of a description of the relationship between audience/resource/scope, which was a request or comment that came up during the f2f meeting in Seoul.

Excerpted from the Document History:

   -07

   o  Fixed typo (desecration -> discretion).
   o  Added an explanation of the relationship between scope, audience
      and resource in the request and added an "invalid_target" error
      code enabling the AS to tell the client that the requested
      audiences/resources were too broad.

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Wed, Jan 11, 2017 at 12:00 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt
To: i-d-announce@ietf.org
Cc: oauth@ietf.org



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

        Title           : OAuth 2.0 Token Exchange
        Authors         : Michael B. Jones
                          Anthony Nadalin
                          Brian Campbell
                          John Bradley
                          Chuck Mortimore
        Filename        : draft-ietf-oauth-token-exchange-07.txt
        Pages           : 31
        Date            : 2017-01-11

Abstract:
   This specification defines a protocol for an HTTP- and JSON- based
   Security Token Service (STS) by defining how to request and obtain
   security tokens from OAuth 2.0 authorization servers, including
   security tokens employing impersonation and delegation.


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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-07


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

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

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

 

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

 

 


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

Nat Sakimura

Chairman of the Board, OpenID Foundation


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



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






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


--------------CC3E33AA91603DC8713D19C6-- From nobody Tue May 9 06:32:38 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054D6129B82 for ; Tue, 9 May 2017 06:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.002 X-Spam-Level: X-Spam-Status: No, score=-3.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rji20oSxLPo7 for ; Tue, 9 May 2017 06:32:35 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38F3412945D for ; Tue, 9 May 2017 06:32:34 -0700 (PDT) Received: from [192.168.91.191] ([80.92.121.214]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M3eDF-1dyOp73a1B-00rHrD for ; Tue, 09 May 2017 15:32:33 +0200 References: <95776354-79e3-caa7-ba60-84cfec7f899f@gmx.net> To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Forwarded-Message-Id: <95776354-79e3-caa7-ba60-84cfec7f899f@gmx.net> Message-ID: <018b080b-ca62-f301-a73f-056667526244@gmx.net> Date: Tue, 9 May 2017 15:32:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <95776354-79e3-caa7-ba60-84cfec7f899f@gmx.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KKTpkO3c3G2vT2Gs2o5ugXWMNTmWePtpL" X-Provags-ID: V03:K0:vLVzZ6SOSGyEizwIdLQn3+jS3GEa/Co7FHGyhJqWdb7g5Hm7QGT AAEW5MgQU2GwXMe6jlf7K7eVrmdqOQSeS1rslnZZKnMFTsd9J8M1W3KW0nNiluy1jBcBWLU QvAxAUKAJWrgTdKKDRj9oMZdL6pOoH0x+0GLAfmch700gvR+K0mbax+2JGEbOIaJ7qARWag wuRi5/KbNEOLWqH7Wpd7A== X-UI-Out-Filterresults: notjunk:1;V01:K0:8sdMzGDm75g=:ivV4X37lmYxTtAyePh/OlT 2eE8m1jfqJGxHCrp+sa3vG7jbMyN55jsJ3HMYJeYMFN8zL4iDKo94XVMhnWdEL3qph18OJ3dw +tZspTWusWM22RmhLcLLAhpyAD07/KufNx96Gg8YbEXL0ZlWrOqz+nj8BH0HbI0189tcOR+MH gpCQ9d7Ij9OPR0tKD2IUol44BRBTp7BE4fInDbxv+8AQ7By2mmrk46zdXVukB2Y7ncVep6Dzp lLgaGiSSC7L/oqb2BvmyQfUWI7rMDCCGLVS0wrwl7Qtwjh+tL+sBtPBYCBJSdKxz4c8SNzgAw iS8D+EIP2rFeMbuyi4aWPLmkMOFjK0KYAS93G+hyXoiqru8YTWIGBwOPElJyagrUz4IhdD08x TltecFP3ilmsjK9xHcElz6Mvv/+zVqz9hbLyzefV7Q5yEUXGyYNxvysOlZSEZdVUuGDQEEHq5 nVX3f8xYVgYj3EbcP23XeeOpn0XaaDARmJlW8VK8lUe/4Ki/R1Iv5cd90GcP+I+/dCljKezRi 99sLiP+v3FSGXDuTqXvSXoxK9ZFnXvuT7ArO0PJMSpGueonWy5heHOx3BftqdPuUiEjg5Wtjd iO0HQo2psCz3AMpxSaPj/s9kI2wBN4FGVckZ+4EVs8yq0A+WtrxA3atDn/+iG6yNRA4SthqK7 5qRYqSIUrpSljeEoOupReTygYVFjNbxKKIrhJhG1Qp6ST3l31IyrIXaL9VA+PWuJqg6z73sKi cvTrBEXJA1GrTuWvA7EHz7rg8rHzULELQtcHE8GGNNPTed7ndaxiRcOPAKg= Archived-At: Subject: [OAUTH-WG] Fwd: Call for Adoption: Mutual TLS Profiles for OAuth Clients X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 13:32:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KKTpkO3c3G2vT2Gs2o5ugXWMNTmWePtpL Content-Type: multipart/mixed; boundary="tNiNCDCqlrwM4jUV5ph5uVCKINeN1qX4G"; protected-headers="v1" From: Hannes Tschofenig To: "oauth@ietf.org" Message-ID: <018b080b-ca62-f301-a73f-056667526244@gmx.net> Subject: Fwd: Call for Adoption: Mutual TLS Profiles for OAuth Clients References: <95776354-79e3-caa7-ba60-84cfec7f899f@gmx.net> In-Reply-To: <95776354-79e3-caa7-ba60-84cfec7f899f@gmx.net> --tNiNCDCqlrwM4jUV5ph5uVCKINeN1qX4G Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable resending -------- Forwarded Message -------- Subject: Call for Adoption: Mutual TLS Profiles for OAuth Clients Date: Thu, 20 Apr 2017 18:32:55 +0200 From: Hannes Tschofenig To: oauth@ietf.org Hi all, based on the strong support for this document at the Chicago IETF meeting we are issuing a call for adoption of the "Mutual TLS Profiles for OAuth Clients" document, see https://tools.ietf.org/html/draft-campbell-oauth-mtls-01 Please let us know by May 4th whether you accept / object to the adoption of this document as a starting point for work in the OAuth working group. Ciao Hannes & Rifaat --tNiNCDCqlrwM4jUV5ph5uVCKINeN1qX4G-- --KKTpkO3c3G2vT2Gs2o5ugXWMNTmWePtpL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJZEcTvAAoJEGhJURNOOiAt24UH/0lrnRvvERXwFBnBUTNvX1ei XE0b9OzroRGNaVtrDMoQTzM4dnmMZqnHnVYWmFTMzZ+nKSMFzv+iurSQ0kRZyMPw fJXf9ppwRyojTYhWgCvLMAVcKWF/6CRRwhWSgXZ5Dl7BCy/AJ3RLDHnje8Vqd9bQ nD/kJR0oHBl3ctclw+NVHR/xQDOlOUS/ZRlagNJTnjtjhXr2otEVt6qYSFlIgcFR i0lbT30TLxkcw65nZQBN0puT3RJbOvhJqddNHGSHjtNyWdCedBoeRacUdO+Z1YFQ REUlKoCxZ46ejtns/kEi1nY9aAdR2iuPdmOdQUKcGR55KbxLfdN2+iLdrEzxs6Y= =jDg7 -----END PGP SIGNATURE----- --KKTpkO3c3G2vT2Gs2o5ugXWMNTmWePtpL-- From nobody Tue May 9 06:37:40 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF35129C60 for ; Tue, 9 May 2017 06:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.002 X-Spam-Level: X-Spam-Status: No, score=-3.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6_PxtcnR8wE for ; Tue, 9 May 2017 06:37:37 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 575F2129B46 for ; Tue, 9 May 2017 06:37:37 -0700 (PDT) Received: from [192.168.91.191] ([80.92.121.214]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LpKKr-1ddaKB2kGD-00fCPo for ; Tue, 09 May 2017 15:37:35 +0200 To: "oauth@ietf.org" References: <95776354-79e3-caa7-ba60-84cfec7f899f@gmx.net> <018b080b-ca62-f301-a73f-056667526244@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <8a3815d8-e0f4-869a-afaa-5bbf345ceead@gmx.net> Date: Tue, 9 May 2017 15:37:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <018b080b-ca62-f301-a73f-056667526244@gmx.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HEcvsmGEn1GOUpCWaq6UvdmDW9kVMctBp" X-Provags-ID: V03:K0:xEAr96ipDQSoLbfgVAqIuu4Ics0KOYhdLkAHwXnQo6g2eHQoljY sKvtiYRziomgeVuDCc6ueF0JVF1VzNK++o8WtQ4iXGSrDCcYXsriXrj4s+Wg+uuGQ9CYzk3 hoznmVAQfrR/3fgiTmPWCT9nWvxWN1q/BeydzUZ5OBYSD1ce/MCcWU47S0fVP9AlNZtnadS 1LAhPvKSeVu5XNzsvOcaQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:SCRXHdMu6VY=:lhty1CDKe74Y1ryIKHE3IY 4QmxEPFRROgyz7fxGBDpynYrfjmk386VNFzMR7HEgFycvHR4U0EWcvu6qknPML5Gm4yJ5a/+G +AdyXfxk/DaxZ4MSir8dwX/l2vUlkIEV+HIvfr5L4bzXRdpdNsTP8TDStdu3/04hfyM0Dkj76 d5JZgtxP9ztbE4IAjyfAN5RPP+ay5/zSuOI2tkkIYeqxBLqZWkoJqHkAh1P8Rvcezbqr22bHw 0pILndedCcO6R8TPrU29GuMjU6XG9VjPdrRWHzn3IM4VX0xV6ssA4XvJDx+1zZUTeDo0PowaJ dW0Jv90OO9Uheaty5+PAw7ryGaRN9ZVb5Cq8ibgA1FJejdiDS1OIUfxPwyhfyqeMRSaOTtleH LIzqUlPyuPB1dmmUDb3SklW3hNX5bqC4oEYAxhL+VolU76UpdQ35gUnRWJrUU6CpJpYpOZe88 z9ysn/P/2UnZFdlUQ0en0+hyouljuxaaYIa3eGs3yo7Ao3qUlca8xj2FccOfn513e+8INoO5o 6OIx0TZbFz1mjOp6xA2v/IWbcXh8EIe+NWyK35YIcg+b3kQjoEC+XkcGKd+j3YEN2zWuTOVEE NDaWtgbujXTTlHmbmN4rF+C6ozDp/zmx9P8nI2aAPl+S/QfLdq6t9TIfq5wTcgvokLuxYiihm Vv2T55xQAwLdolG431Etx+9KWMfE9FsHH6HV1RXyLtWa7fVF4PUyagfbogjCRmBLk6JTEnwfC i1G2/vLAP4qfAPORLu04xU/CJ84bNjaojQ1h6i95AIB69QFnYjminlmCGlQ= Archived-At: Subject: Re: [OAUTH-WG] Fwd: Call for Adoption: Mutual TLS Profiles for OAuth Clients X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 13:37:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HEcvsmGEn1GOUpCWaq6UvdmDW9kVMctBp Content-Type: multipart/mixed; boundary="RuSnT5FLGSsDBjwTjagjO216qMB3PLTc9"; protected-headers="v1" From: Hannes Tschofenig To: "oauth@ietf.org" Message-ID: <8a3815d8-e0f4-869a-afaa-5bbf345ceead@gmx.net> Subject: Re: [OAUTH-WG] Fwd: Call for Adoption: Mutual TLS Profiles for OAuth Clients References: <95776354-79e3-caa7-ba60-84cfec7f899f@gmx.net> <018b080b-ca62-f301-a73f-056667526244@gmx.net> In-Reply-To: <018b080b-ca62-f301-a73f-056667526244@gmx.net> --RuSnT5FLGSsDBjwTjagjO216qMB3PLTc9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sorry; this was the wrong email. I had sent a mail around to confirm the call for adoption and it turns out that this email got lost somewhere....= On 05/09/2017 03:32 PM, Hannes Tschofenig wrote: > resending >=20 >=20 > -------- Forwarded Message -------- > Subject: Call for Adoption: Mutual TLS Profiles for OAuth Clients > Date: Thu, 20 Apr 2017 18:32:55 +0200 > From: Hannes Tschofenig > To: oauth@ietf.org >=20 > Hi all, >=20 > based on the strong support for this document at the Chicago IETF > meeting we are issuing a call for adoption of the "Mutual TLS Profiles > for OAuth Clients" document, see > https://tools.ietf.org/html/draft-campbell-oauth-mtls-01 >=20 > Please let us know by May 4th whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. >=20 > Ciao > Hannes & Rifaat >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 --RuSnT5FLGSsDBjwTjagjO216qMB3PLTc9-- --HEcvsmGEn1GOUpCWaq6UvdmDW9kVMctBp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJZEcYdAAoJEGhJURNOOiAtyH0H/RVcjOWMnUm8FekDKLQPOwyT w4v1PznA/QS8CVapLM9AbPW65Hp6W5cuZ1HKKmc8mw41PmuVe4EPoYIOOHVCk+wm MsddFVTu5ns0ewbGe5xjwr3pd4o5YypSNaZ6q48cX/AuN5g3rMGTiSn9C8B2EyMc 5wNJHZD1DYJRcP2J/YlMPSCplJSqH54c2lydFI+md8EGkJXqnwhskG3yKh2snLai vU9PSx1bgML+zNFcqzIkSjna29Ehleg06KTv4jwM2GQP+SnwoWCykYVCQwIao6au YScJvYzTqHDBGeSzaurBID2s5NkxLAw4hbbfSvpfNZ+PadKJ9jdDaD8xTV7s9+g= =5VMy -----END PGP SIGNATURE----- --HEcvsmGEn1GOUpCWaq6UvdmDW9kVMctBp-- From nobody Tue May 9 06:40:47 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C68D129BB7 for ; Tue, 9 May 2017 06:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZBWQlOmgJZx for ; Tue, 9 May 2017 06:40:43 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 807B3129C6E for ; Tue, 9 May 2017 06:40:42 -0700 (PDT) Received: from [192.168.91.191] ([80.92.121.214]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M936L-1dJwxB18bV-00CUdp for ; Tue, 09 May 2017 15:40:40 +0200 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Tue, 9 May 2017 15:40:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hHtgF8n7N2GskTLVCxAFLD3KGETMGgSSj" X-Provags-ID: V03:K0:FSBQuHWG7ScZ7jLO6lN+itNSCrsd9bRtl7KZ3Uf46iuqT1kjSns MfW5q50JmTSlX6fVlGFZtNZOZd0pFKXkaIRlbVg3itYykGutrrqGxO0Vv5km6KYlz7RMzPw q0LcBXPaXs7u1C6+WC8M5ipZeS/w9VcOPoqrtecF86iypNZ0ql2qAac/1U3cEyfOGUFaqee X72fW8zuEI8uFoBLfhkLA== X-UI-Out-Filterresults: notjunk:1;V01:K0:rdfnOZnNh8U=:iUolhDX9gag8cpaSt1Zn5c +UuivVRTVxIP3y9+z7Iaa/mKhoDv9dl7zTM5p8pmOZC4tcqqwZEVhuEjZ3Ab2i1ttwoeKK1wJ YxMsyvKi1rFiSrWLiFzBh0Gjal5Me4qRQwy2L+2ak7U8uWMkaHyEAegcCvZzC7ikTfIXeDuOq 8a3dphhihRddT2fMC6K4QVYyBakp6VvN/RunhvtE4YW50pBuRY13ZAcK7V1rENni7LtD0Or5a 9V7rjw5G0BUoJtRN6x5KN43bniWJ0miWcbuSSNeXdW5M1GLZpyCEf/981vKVssBNd5Xpq+kDn V6XCpe5HwBNcmx3qCbXViGxprWgwRtUDuVLgLg6axPl9kc5aPRnGp6BcAOI1Yo084gKHBOdq0 j9Km0NC698NNPrIzBQ0KVsDN1Bj+5LOwzhaptU3yO5K6D5jMTMvLS1mHdhHOPt1ZvTQTHmPwR kFUOlc7ddVp+WnAwULu2K/RdeBqZ3iKU9EAeQ3BrcEONqpA12bDmnkR6sr0/021X8YfH4VTXv S/L8O79GfWFXyQ/wQLDCcDG2PbrruPtACdrGbRRrQ+MWtXrSa8fUpKt8IQA3ZX0Ooddixc1VQ Ix2lU38pjL04yyFP+1YapgFre+5hmQYxVNiS7xnSHRpCj8iivZ4Q+Mx4zFxLvfE6e8I/oV5ao zc5hQKP3LFkC1O+a7B9XiXkJT8BCi5Bz1TF7I/XU1MK1KadYOIdRxudUgVJt3eS6mDGJCpFGt Nv88WRgaiYRSaX0HTjzC5H8TdjZdDq7X+PVNd66RHJ2+qONsYP6uFdi0XqI= Archived-At: Subject: [OAUTH-WG] Mutual TLS Profiles for OAuth Clients X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 13:40:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hHtgF8n7N2GskTLVCxAFLD3KGETMGgSSj Content-Type: multipart/mixed; boundary="pOo9BdVaxAkrxdBr59I593wxceN14UDmi"; protected-headers="v1" From: Hannes Tschofenig To: "oauth@ietf.org" Message-ID: Subject: Mutual TLS Profiles for OAuth Clients --pOo9BdVaxAkrxdBr59I593wxceN14UDmi Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi authors, based on the feedback at the last IETF meeting and the response from the mailing list there is good support for adopting this document. Please submit a -00 version of the WG document as a starting point for future work in the OAuth WG. Ciao Hannes & Rifaat --pOo9BdVaxAkrxdBr59I593wxceN14UDmi-- --hHtgF8n7N2GskTLVCxAFLD3KGETMGgSSj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJZEcbXAAoJEGhJURNOOiAtxx8H+wZSYsFqEjZW1F59jPOd3KSE eNmKjJ6ngH2Uo4BcGcj3TNzUbLXN9c0vrvD7/5LFrILtLtLsQZhQB8PQk7Sojv// 5/jTPb1xUevIynapshr8A6LeHpTQGbf2XUUdZ5WXpEVDasTM+D00wbgpcGAiFHjl yTey9va09xLbPdNr8iBPAfzj5+CoL0s4kFUtS38VK0BLEnrQQPKlRFWzfUNpdwUM QGqAzXmJj72wV8UJQGwcw89AgVVfrFSSN5suEFnheQObz1NeCR3HiMv0Scpwrt3A B9X9+Sb03WYOAiVoixXDfm8MNbcHWQImEJl/dsqhRKO0AyIB8uXr/BCgcvRfzWo= =JrZK -----END PGP SIGNATURE----- --hHtgF8n7N2GskTLVCxAFLD3KGETMGgSSj-- From nobody Tue May 9 08:13:02 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24944129493 for ; Tue, 9 May 2017 08:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNd7JKiFS9PD for ; Tue, 9 May 2017 08:12:56 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e: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 4DDE4127867 for ; Tue, 9 May 2017 08:12:56 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id u187so1221430pgb.0 for ; Tue, 09 May 2017 08:12:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9FV2HtV6zcCIOXbGVLsBxzNZSW2g2szwIGYRSIGa4qk=; b=K2swiIdEHhAf4UqwWvYUotXdjCoG0yXQL0vKn7gQzcBHR2AxD32AZhaxT4pFfIHliB SjyNgwbd9yzn+aGB0JwlDCGYzRz3I+yRsZsEZO6ejAAYAygwCYwRVf+MGPZqkq6oVvJv 7ugI95IPtuTVeZP6qjoyRPzN0boqqq1DrUsmo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9FV2HtV6zcCIOXbGVLsBxzNZSW2g2szwIGYRSIGa4qk=; b=A8+uyTvpaWQVwXTW1gvmfXnmrG1pGV7kOsXyB1Z6TKe0hmT5nSkhykBP0Ew41MVR4A j2Hp+MTc/deVSZWnC+nt7hk4zv7wuEjH1NP9Gz4WxTy2XNIrQaZ/+7XuQQSDDNqlI2Gg ozsdQBooaldK76inUUu0cns5zEvgTWvFODjDp3xfFuJNeiZPgYegYbTtvkp7R0t7iEe9 ICVbA7D0HWDD9EGy5NR3cxDmULO5hjLxU4n/r4XXT17ILkOxrNO5sBz9KKGi0tCWLtVv mY3DxB47tebtFkfudf5AVO23YGkMnY37Abq1YriYwC2edquePHsHl+X17MWchmbWIKlV u9Ag== X-Gm-Message-State: AODbwcCO/JfWZWPNX7wdMGrk8PONTC72OHkYFR9VjKeIOQvUDL1w5mdr j/rFLweygp6EpMkwCReMYzbFsqmTmULK X-Received: by 10.99.101.135 with SMTP id z129mr730439pgb.66.1494342775648; Tue, 09 May 2017 08:12:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.154.205 with HTTP; Tue, 9 May 2017 08:12:24 -0700 (PDT) In-Reply-To: References: <148416124213.8244.5842562779051799977.idtracker@ietfa.amsl.com> <9199091B-5D7F-4D66-9EC5-CB0EF2D3CF6D@lodderstedt.net> <30B37ED3-6E3B-4739-9917-BDEC198CA027@lodderstedt.net> From: Brian Campbell Date: Tue, 9 May 2017 09:12:24 -0600 Message-ID: To: Denis Cc: oauth Content-Type: multipart/alternative; boundary=94eb2c116f6850ced5054f18cad0 Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 15:13:00 -0000 --94eb2c116f6850ced5054f18cad0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, I omitted your comments in that post because I'd previously replied to you in a separate message where I said that the "actor_token is a security token so that's not an issue that needs to be addressed." https://www.ietf.org/mail-archive/web/oauth/current/msg17247.html The other point you've just made about having very precise semantics for a field is a fair one. However, I wanted to avoid introducing yet another field (or really two fields b/c of the associated *_type for each inbound token field), for what felt like a minor semantic variation that could be easily accommodated by the existing framework, to the draft that already has a lot of options and parameters on the request. And Token Exchange really is a framework. I think that, to some extent, the framework is a bit of a Rorschach test for deployers and implementers to utilize to solve their specific issues and needs. I expect that will be the case regardless. And I am proposing to somewhat genericize the text around one request parameter to be more reflective of that. I would like to hear from others in the WG though. On Tue, May 9, 2017 at 3:06 AM, Denis wrote: > Brian, > > You omitted to include my comments in this post. So here it is again: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The current text is: > > actor_token OPTIONAL. A security token that represents the identity of th= e > party that is authorized to use the requested security token and act on > behalf of the subject. > > This sentence is indeed wrong since an actor-token is not a security toke= n. > > So your proposed change does not solve this issue: actor_token > OPTIONAL. A security token that represents the identity of the acting > party. > > The current text states: > > Typically, in the request, the subject_token represents the identity of > the party on behalf of whom > the token is being requested while the actor_token represents the identit= y > of the party to whom the access > rights of the issued token are being delegated. > > Logically, the definition should be along the following lines: > > actor_token OPTIONAL. Indicates the identity of the party to whom the > access rights of the issued token are being delegated. > > If there is no delegation, then this field (which is optional) will not b= e > used. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > I read your argumentation, but I maintain my comment. Each field should > have a precise semantics. > > If you want to have another semantics, you should propose to define > another field with its precise meaning. > > Denis > > Let me throw out a bit more context about this. The "actor_token" might, > in a delegation scenario, represent the identity of the party to whom the > access rights of the issued token are being delegated. That's the typical > delegation scenario that is discussed in the draft. However, the > "actor_token" might also be utilized/needed by the AS in an impersonation > scenario for policy or auditing reasons even when the resulting issued > token doesn't contain info about the delegation or actor. Similarly, the > actor might not be strictly doing the impersonation but rather just be a > party (again maybe needed for policy or auditing) to the token exchange > event itself. When I wrote the "actor_token" text in section 2.1 some ~1= 8 > months ago I had the delegation scenario at the front of my mind and > (clearly) intended to accommodate it. However, I didn't intend to limit i= t > to only that and, looking at the text again, I think what is there now is > too prescriptive and narrow. Thus my proposing to generalize the text > somewhat. > > > > > On Mon, May 8, 2017 at 10:29 AM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> I do have one minor issue I'd like to raise that relates to some >> conversations I've been a party to recently about implementations and >> applications of token exchange. >> >> I think that the current text in =C2=A72.1 for the "actor_token" is over= ly >> specific towards the delegation scenario. I'd propose the language be >> generalized somewhat to allow more versatility in applications/deploymen= ts >> of the token exchange framework. Here's that text: >> >> actor_token >> OPTIONAL. A security token that represents the identity of the >> acting party. >> >> >> >> >> On Mon, May 8, 2017 at 8:01 AM, Rifaat Shekh-Yusef > > wrote: >> >>> Hi All, >>> >>> The last email from Brian addresses the multiple audiences/resources >>> issue with an error code, and we did not see any objection to this appr= oach >>> so far. >>> >>> >>> *Authors,* >>> >>> Are there any other open issues with this draft? >>> Do you believe it is ready for WGLC? >>> >>> Thanks, >>> Rifaat & Hannes >>> >>> >>> >>> On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell < >>> bcampbell@pingidentity.com> wrote: >>> >>>> As mentioned during the Chicago meeting the "invalid_target" error cod= e >>>> that was added in -07 was intended to give the AS a standard way to re= ject >>>> request with multiple audiences/resources that it doesn't understand o= r is >>>> unwilling or unable to process based on policy or whatever criteria . = It >>>> was intended as a compromise, of sorts, to allow for the multiple >>>> resources/audiences in the request but provide an easy out for the AS = of >>>> saying it can't be supported based on whatever implementation or secur= ity >>>> or policy it has. >>>> >>>> On Tue, Mar 28, 2017 at 1:32 AM, Nat Sakimura >>>> wrote: >>>> >>>>> There are cases where tokens are supposed to be consumed at multiple >>>>> places and the `aud` needed to capture them. That's why `aud` is a >>>>> multi-valued field. >>>>> >>>>> On Mon, Mar 27, 2017 at 11:35 AM Torsten Lodderstedt < >>>>> torsten@lodderstedt.net> wrote: >>>>> >>>>>> May I ask you to explain this reason? >>>>>> >>>>>> Am 27.03.2017 um 08:48 schrieb Mike Jones < >>>>>> Michael.Jones@microsoft.com>: >>>>>> >>>>>> For the same reason that the =E2=80=9Caud=E2=80=9D claim is multi-va= lued in JWTs, the >>>>>> audience needs to stay multi-valued in Token Exchange. Ditto for re= sources. >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -- Mike >>>>>> >>>>>> >>>>>> >>>>>> *From:* OAuth [mailto:oauth-bounces@ietf.org ] >>>>>> *On Behalf Of *Brian Campbell >>>>>> *Sent:* Monday, March 27, 2017 8:45 AM >>>>>> *To:* Torsten Lodderstedt >>>>>> *Cc:* oauth >>>>>> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchang >>>>>> e-07.txt >>>>>> >>>>>> >>>>>> >>>>>> Thanks for the review and question, Torsten. >>>>>> >>>>>> The desire to support multiple audience/resource values in the >>>>>> request came up during a review and discussion among the authors of = the >>>>>> document when preparing the -03 draft. As I recall, it was said that= both >>>>>> Salesforce and Microsoft had use-cases for it. I incorporated suppor= t for >>>>>> it into the draft acting in the role of editor. >>>>>> >>>>>> From an individual perspective, I tend to agree with you that >>>>>> allowing for multiple audiences/resources adds a lot of complexity t= hat's >>>>>> like not needed in many (or most) cases. And I would personally be o= pen to >>>>>> making audience and resource mutual exclusive and single valued. A q= uestion >>>>>> for the WG I suppose. >>>>>> >>>>>> The "invalid_target" error code that was added in -07 was intended t= o >>>>>> give the AS a standard way to deal with the complexity and reject re= quest >>>>>> with multiple audiences/resources that it doesn't understand or is >>>>>> unwilling or unable to process. It was intended as a compromise, of = sorts, >>>>>> to allow for the multiples but provide an easy out of saying it can'= t be >>>>>> supported based on whatever implementation or policy of the AS. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Sun, Mar 26, 2017 at 9:00 AM, Torsten Lodderstedt < >>>>>> torsten@lodderstedt.net> wrote: >>>>>> >>>>>> Hi Brian, >>>>>> >>>>>> >>>>>> >>>>>> thanks for the clarification around resource, audience and scope. >>>>>> >>>>>> >>>>>> >>>>>> Here are my comments on the draft: >>>>>> >>>>>> >>>>>> >>>>>> In section 2.1 it states: =E2=80=9EMultiple "resource" parameters ma= y be used >>>>>> to indicate >>>>>> >>>>>> that the issued token is intended to be used at the multiple >>>>>> >>>>>> resources listed.=E2=80=9C >>>>>> >>>>>> >>>>>> >>>>>> Can you please explain the rational in more detail? I don=E2=80=99t >>>>>> understand why there is a need to ask for access tokens, which are g= ood for >>>>>> multiple resources at once. This is a request type more or less excl= usively >>>>>> used in server to server scenarios, right? So the only reason I can = think >>>>>> of is call reduction. >>>>>> >>>>>> >>>>>> >>>>>> On the other side, this feature increases the AS's complexity, e.g. >>>>>> its policy may prohibit to issue tokens for multiple resources in ge= neral >>>>>> or the particular set the client is asking for. How shall the AS han= dles >>>>>> such cases? >>>>>> >>>>>> >>>>>> >>>>>> And it is getting even more complicated given there could also be >>>>>> multiple audience values and the client could mix them: >>>>>> >>>>>> >>>>>> >>>>>> "Multiple "audience" parameters >>>>>> >>>>>> may be used to indicate that the issued token is intended to b= e >>>>>> >>>>>> used at the multiple audiences listed. The "audience" and >>>>>> >>>>>> "resource" parameters may be used together to indicate multipl= e >>>>>> >>>>>> target services with a mix of logical names and physical >>>>>> >>>>>> locations.=E2=80=9C >>>>>> >>>>>> >>>>>> >>>>>> And in the end the client may add some scope values to the =E2=80=9E= meal=E2=80=9C, >>>>>> which brings us to >>>>>> >>>>>> >>>>>> >>>>>> =E2=80=9EEffectively, the requested access rights of the >>>>>> >>>>>> token are the cartesian product of all the scopes at all the targ= et >>>>>> >>>>>> services." >>>>>> >>>>>> >>>>>> >>>>>> I personally would suggest to drop support for multiple audience and >>>>>> resource parameters and make audience and resource mutual exclusive.= I >>>>>> think this is sufficient and much easier to implement. >>>>>> >>>>>> >>>>>> >>>>>> kind regards, >>>>>> >>>>>> Torsten. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Am 11.01.2017 um 20:04 schrieb Brian Campbell < >>>>>> bcampbell@pingidentity.com>: >>>>>> >>>>>> >>>>>> >>>>>> Draft -07 of "OAuth 2.0 Token Exchange" has been published. The >>>>>> primary change in -07 is the addition of a description of the relati= onship >>>>>> between audience/resource/scope, which was a request or comment that= came >>>>>> up during the f2f meeting in Seoul. >>>>>> >>>>>> Excerpted from the Document History: >>>>>> >>>>>> -07 >>>>>> >>>>>> o Fixed typo (desecration -> discretion). >>>>>> o Added an explanation of the relationship between scope, audien= ce >>>>>> and resource in the request and added an "invalid_target" erro= r >>>>>> code enabling the AS to tell the client that the requested >>>>>> audiences/resources were too broad. >>>>>> >>>>>> ---------- Forwarded message ---------- >>>>>> From: >>>>>> Date: Wed, Jan 11, 2017 at 12:00 PM >>>>>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchang >>>>>> e-07.txt >>>>>> To: i-d-announce@ietf.org >>>>>> Cc: oauth@ietf.org >>>>>> >>>>>> >>>>>> >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>> directories. >>>>>> This draft is a work item of the Web Authorization Protocol of the >>>>>> IETF. >>>>>> >>>>>> Title : OAuth 2.0 Token Exchange >>>>>> Authors : Michael B. Jones >>>>>> Anthony Nadalin >>>>>> Brian Campbell >>>>>> John Bradley >>>>>> Chuck Mortimore >>>>>> Filename : draft-ietf-oauth-token-exchange-07.txt >>>>>> Pages : 31 >>>>>> Date : 2017-01-11 >>>>>> >>>>>> Abstract: >>>>>> This specification defines a protocol for an HTTP- and JSON- base= d >>>>>> Security Token Service (STS) by defining how to request and obtai= n >>>>>> security tokens from OAuth 2.0 authorization servers, including >>>>>> security tokens employing impersonation and delegation. >>>>>> >>>>>> >>>>>> 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-07 >>>>>> >>>>>> A diff from the previous version is available at: >>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-token-exchange-= 07 >>>>>> >>>>>> >>>>>> Please note that it may take a couple of minutes from the time of >>>>>> submission >>>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>> -- >>>>> >>>>> Nat Sakimura >>>>> >>>>> Chairman of the Board, OpenID Foundation >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>> >> > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --94eb2c116f6850ced5054f18cad0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, I omitted your comments in that post because I&#= 39;d previously replied to you in a separate message where I said that the = "actor_token is a security token so that's not an issue that needs= to be addressed."=C2=A0 https://www.ietf.org/mai= l-archive/web/oauth/current/msg17247.html

The ot= her point you've just made about having very precise semantics for a fi= eld is a fair one. However, I wanted to avoid introducing yet another field= (or really two fields b/c of the associated *_type for each inbound token = field), for what felt like a minor semantic variation that could be easily = accommodated by the existing framework, to the draft that already has a lot= of options and parameters on the request. And Token Exchange really is a f= ramework. I think that, to some extent, the framework is a bit of a Rorscha= ch test for deployers and implementers to utilize to solve their specific i= ssues and needs. I expect that will be the case regardless. And I am propos= ing to somewhat genericize the text around one request parameter to be more= reflective of that.

I would like to hear from others in the WG tho= ugh.

On= Tue, May 9, 2017 at 3:06 AM, Denis <denis.ietf@free.fr> wr= ote:
=20 =20 =20
Brian,

You omitted to include my comments in this post. So here it is again:

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

The current text is:

actor_token OPTIONAL. A security token that represents the identity of the party that is authorized to use the requested security token and act on behalf of the subject.

This sentence is indeed wrong since an actor-token is not a security token.

So your proposed change does not solve this issue: actor_token=C2=A0 OPTIONAL.=C2=A0 A security token that represents the identity of the acting party.

The current text states:
Typically, in the request, the su= bject_token represents the identity of the party on behalf of whom
 the token is being requested while the actor_token represents the identity of the party to whom the access
rights of the issued token are being delegated.
Logically, the definition should be along the following lines:

=C2=A0actor_token OPTIONAL. Indicates the identity of the party to whom the access rights of the issued token are being delegated.

If there is no delegation, then this field (which is optional) will not be used.

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

I read your argumentation, but I maintain my comment. Each field should have a precise semantics.

If you want to have another semantics, you should propose to define another field with its precise meaning.=

Denis

Let me throw out a bit more context about this. The "actor_token" might, in a delegation scenario, represent = the identity of the party to whom the access rights of the issued token are being delegated. That's the typical delegation scenario that is discussed in the draft. However, the "actor_token" might also be utilized/needed by the AS in = an impersonation scenario for policy or auditing reasons even when the resulting issued token doesn't contain info about the delegation or actor. Similarly, the actor might not be strictly doing the impersonation but rather just be a party (again maybe needed for policy or auditing) to the token exchange event itself.=C2=A0 When I wrote the "actor_token" text in sect= ion 2.1 some ~18 months ago I had the delegation scenario at the front of my mind and (clearly) intended to accommodate it. However, I didn'= t intend to limit it to only that and, looking at the text again, I think what is there now is too prescriptive and narrow. Thus my proposing to generalize the text somewhat.




On Mon, May 8, 2017 at 10:29 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
I do have one minor issue I'd like to raise that relates to some conversations I've been a party to recently about implementations and applications of token exchange.

I think that the current text in =C2=A72.1 for the "actor_token" is overly specific towards the dele= gation scenario. I'd propose the language be generalized somewhat to allow more versatility in applications/deployments of the token exchange framework. Here's that text:

=C2=A0=C2=A0 actor_token
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OPTIONAL.=C2=A0 A security t= oken that represents the identity of the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 acting party.=C2=A0




On Mon, May 8, 2017 at 8:01 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com&= gt; wrote:
Hi All,

The last email from Brian addresses the multiple audiences/resources issue with an error code, and we did not see any objection to this approach so far.


Authors,

Are there any other open issues with this draft?
Do you believe it is ready for WGLC?

Thanks,
=C2=A0Rifaat & Hannes



On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell <b= campbell@pingidentity.com> wrote:
As mentioned during the Chicago meeting the "invalid_target&= quot; error code that was added in -07 was intended to give the AS a standard way to reject request with multiple audiences/resources that it doesn't understand or is unwilling or unable to process based on policy or whatever criteria . It was intended as a compromise, of sorts, to allow for the multiple resources/audiences in the request but provide an easy out for the AS of saying it can't be supporte= d based on whatever implementation or security or policy it has.

On Tue, Mar 28, 2017 at 1:32 AM, Nat Sakimura <sakimura@gmail.com&= gt; wrote:
There are cases where tokens are supposed to be consumed at multiple places and the `aud` needed to capture them. That's why `aud` is a multi-valued field.=C2=A0
On Mon, Mar 27, 2017 at 11:35 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
May I ask you to explain this reason?

Am 27.03.2017 um 08:48 schrieb Mike Jones <Michael.Jones@microsoft.com>:

For the same reason that the =E2=80=9Caud= =E2=80=9D claim is multi-valued in JWTs, the audience needs to stay multi-valued in Token Exchange.=C2=A0 Ditto for resources.=

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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

mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Monday, March 27, 2017 8:45 AM
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-= token-exchange-07.txt

=C2=A0

Thanks for the review = and question, Torsten.

The desire to support = multiple audience/resource values in the request came up during a review and discussion among the authors of the document when preparing the -03 draft. As I recall, it was said that both Salesforce and Microsoft had use-cases for it. I incorporated support for it into the draft acting in the role of editor.

From an individual per= spective, I tend to agree with you that allowing for multiple audiences/resourc= es adds a lot of complexity that's like not needed in many (or most) cases. And I would personally be open to making audience and resource mutual exclusive and single valued. A question for the WG I suppose.

The "invalid_target" error code that was added in -07 was intended to= give the AS a standard way to deal with the complexity and reject request with multiple audiences/resourc= es that it doesn't understand or is unwilling or unable to process. It was intended as a compromise, of sorts, to allow for the multiples but provide an easy out of saying it can't be supported based on whatever implementation or policy of the AS.

=C2=A0

=C2=A0

=C2=A0

On Sun, Mar 26, 2017 at 9:00 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi Brian,

=C2=A0

thanks for the clarification around resource, audience and scope.=C2=A0

=C2=A0

Here are my comments on the draft:

=C2=A0

In section 2.1 it states: =E2=80=9EMultiple "resource&qu= ot; parameters may be used to indicate

=C2=A0 =C2=A0 =C2=A0 tha= t the issued token is intended to be used at the multiple

=C2=A0 =C2=A0 =C2=A0 res= ources listed.=E2=80=9C<= /p>

=C2=A0

Can you please explain the rational in more detail? I don=E2=80=99t understand why there is a need to ask for access tokens, which are good for multiple resources at once. This is a request type more or less exclusively used in server to server scenarios, right? So the only reason I can think of is call reduction.=C2=A0<= /p>

=C2=A0

On the other side, this feature increases the AS's complexity, e.g. its policy may prohibit to issue tokens for multiple resources in general or the particular set the client is asking for. How shall the AS handles such cases?

=C2=A0

And it is getting even more complicated given there could also be multiple audience values and the client could mix them:=C2=A0

=C2=A0

"Multiple "audience&qu= ot; parameters

=C2=A0 =C2=A0 =C2=A0 may= be used to indicate that the issued token is intended to be

=C2=A0 =C2=A0 =C2=A0 use= d at the multiple audiences listed.=C2=A0 The "audience&qu= ot; and

=C2=A0 =C2=A0 =C2=A0 &qu= ot;resource" parameters may be used together to indicate multiple

=C2=A0 =C2=A0 =C2=A0 tar= get services with a mix of logical names and physical

=C2=A0 =C2=A0 =C2=A0 locations.=E2=80= =9C

=C2=A0

And in the end the client may add some scope values to the =E2=80=9Emeal=E2= =80=9C, which brings us to=C2= =A0

=C2=A0

=E2=80=9EEffectively, the requested access rights of the

=C2=A0 =C2=A0token are t= he cartesian product of all the scopes at all the target

=C2=A0 =C2=A0services.&q= uot;

=C2=A0

I personally would suggest to drop support for multiple audience and resource parameters and make audience and resource mutual exclusive. I think this is sufficient and much easier to implement.

=C2=A0

kind regards,

Torsten.

=C2=A0

=C2=A0

Am 11.01.2017 um 20:04 schrieb Brian Campbell <bcampbell@pingidentity.com>:

=C2=A0

Draft -07 of "OAu= th 2.0 Token Exchange" has been published. The primary change in -07 is the addition of a description of the relationship between audience/resource= /scope, which was a request or comment that came up during the f2f meeting in Seoul.

Excerpted from the Document History:

=C2=A0=C2=A0 -07<= br class=3D"m_6905276776273010841m_4803735329627533709m_-267514219704985208= 0m_3983298834558915277m_-4354184635220679769gmail_msg">
=C2=A0=C2=A0 o=C2= =A0 Fixed typo (desecration -> discretion).
=C2=A0=C2=A0 o=C2= =A0 Added an explanation of the relationship between scope, audience
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 and resource in the request and added an "invalid_tar= get" error
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 code enabling the AS to tell the client that the requested
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 audiences/resourc= es were too broad.

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Wed, Jan 11, 2017 at 12:00 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-= token-exchange-07.txt
To: i-d-announce@ietf.org
Cc: oauth@ietf.org



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

=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0: OAuth 2.0 Token Exchange =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Authors=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0: Michael B= . Jones
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Anthony Nadalin
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Brian Campbell =C2=A0 =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 Chuck Mortimore
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Filename=C2=A0 = =C2=A0 =C2=A0 =C2=A0 : draft-ietf-oauth-= token-exchange-07.txt
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0: 31

Abstract:
=C2=A0 =C2=A0This specification defines a protocol for an HTTP- and JSON- based
=C2=A0 =C2=A0Secu= rity Token Service (STS) by defining how to request and obtain
=C2=A0 =C2=A0secu= rity tokens from OAuth 2.0 authorization servers, including
=C2=A0 =C2=A0secu= rity tokens employing impersonation and delegation.


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

A diff from the previous version is available at:
https://www.ie= tf.org/rfcdiff?url2=3Ddraft-ietf-oauth-token-exchange-07


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

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

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

=C2=A0

_______________________________________________<= br class=3D"m_6905276776273010841m_4803735329627533709m_-267514219704985208= 0m_3983298834558915277m_-4354184635220679769gmail_msg"> OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinf= o/oauth

=C2=A0

=C2=A0


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/l= istinfo/oauth
=
--

Nat Sakimura

Chairman of the Board, OpenID Foundation


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



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






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



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


--94eb2c116f6850ced5054f18cad0-- From nobody Tue May 9 08:56:06 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B7712E054 for ; Tue, 9 May 2017 08:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQmQwRtw7j6r for ; Tue, 9 May 2017 08:55:57 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7048A12949A for ; Tue, 9 May 2017 08:55:56 -0700 (PDT) Received: from [192.168.0.14] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 5BE6278039D; Tue, 9 May 2017 17:55:53 +0200 (CEST) To: Brian Campbell References: <148416124213.8244.5842562779051799977.idtracker@ietfa.amsl.com> <9199091B-5D7F-4D66-9EC5-CB0EF2D3CF6D@lodderstedt.net> <30B37ED3-6E3B-4739-9917-BDEC198CA027@lodderstedt.net> Cc: oauth From: Denis Message-ID: <58cc229c-ca5e-18d4-8b62-fbb3853f5cca@free.fr> Date: Tue, 9 May 2017 17:55:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EEAEE88F620BB96F53B0D418" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 15:56:04 -0000 This is a multi-part message in MIME format. --------------EEAEE88F620BB96F53B0D418 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Brian, Even if Token Exchange is a framework, the goal is to be finally able to interoperate. Whether we have one or two parameters, would you be able to provide a precise semantics for the "other case" you have in mind ? Denis > Yes, I omitted your comments in that post because I'd previously > replied to you in a separate message where I said that the > "actor_token is a security token so that's not an issue that needs to > be addressed." > https://www.ietf.org/mail-archive/web/oauth/current/msg17247.html > > > The other point you've just made about having very precise semantics > for a field is a fair one. However, I wanted to avoid introducing yet > another field (or really two fields b/c of the associated *_type for > each inbound token field), for what felt like a minor semantic > variation that could be easily accommodated by the existing framework, > to the draft that already has a lot of options and parameters on the > request. And Token Exchange really is a framework. I think that, to > some extent, the framework is a bit of a Rorschach test for deployers > and implementers to utilize to solve their specific issues and needs. > I expect that will be the case regardless. And I am proposing to > somewhat genericize the text around one request parameter to be more > reflective of that. > > I would like to hear from others in the WG though. > > On Tue, May 9, 2017 at 3:06 AM, Denis > wrote: > > Brian, > > You omitted to include my comments in this post. So here it is again: > > =========================================================== > > The current text is: > > actor_token OPTIONAL. A security token that represents the > identity of the party that is authorized to use the requested > security token and act on behalf of the subject. > > This sentence is indeed wrong since an actor-token is not a > security token. > > So your proposed change does not solve this issue: actor_token > OPTIONAL. A security token that represents the identity of the > acting party. > > The current text states: > > Typically, in the request, the subject_token represents the > identity of the party on behalf of whom > the token is being requested while the actor_token represents > the identity of the party to whom the access > rights of the issued token are being delegated. > > Logically, the definition should be along the following lines: > > actor_token OPTIONAL. Indicates the identity of the party to whom > the access rights of the issued token are being delegated. > > If there is no delegation, then this field (which is optional) > will not be used. > > =========================================================== > > I read your argumentation, but I maintain my comment. Each field > should have a precise semantics. > > If you want to have another semantics, you should propose to > define another field with its precise meaning. > > Denis > >> Let me throw out a bit more context about this. The "actor_token" >> might, in a delegation scenario, represent the identity of the >> party to whom the access rights of the issued token are being >> delegated. That's the typical delegation scenario that is >> discussed in the draft. However, the "actor_token" might also be >> utilized/needed by the AS in an impersonation scenario for policy >> or auditing reasons even when the resulting issued token doesn't >> contain info about the delegation or actor. Similarly, the actor >> might not be strictly doing the impersonation but rather just be >> a party (again maybe needed for policy or auditing) to the token >> exchange event itself. When I wrote the "actor_token" text in >> section 2.1 some ~18 months ago I had the delegation scenario at >> the front of my mind and (clearly) intended to accommodate it. >> However, I didn't intend to limit it to only that and, looking at >> the text again, I think what is there now is too prescriptive and >> narrow. Thus my proposing to generalize the text somewhat. >> >> >> >> >> On Mon, May 8, 2017 at 10:29 AM, Brian Campbell >> > >> wrote: >> >> I do have one minor issue I'd like to raise that relates to >> some conversations I've been a party to recently about >> implementations and applications of token exchange. >> >> I think that the current text in §2.1 for the "actor_token" >> is overly specific towards the delegation scenario. I'd >> propose the language be generalized somewhat to allow more >> versatility in applications/deployments of the token exchange >> framework. Here's that text: >> >> actor_token >> OPTIONAL. A security token that represents the >> identity of the >> acting party. >> >> >> >> >> On Mon, May 8, 2017 at 8:01 AM, Rifaat Shekh-Yusef >> > wrote: >> >> Hi All, >> >> The last email from Brian addresses the multiple >> audiences/resources issue with an error code, and we did >> not see any objection to this approach so far. >> >> >> *Authors,* >> >> Are there any other open issues with this draft? >> Do you believe it is ready for WGLC? >> >> Thanks, >> Rifaat & Hannes >> >> >> >> On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell >> > > wrote: >> >> As mentioned during the Chicago meeting the >> "invalid_target" error code that was added in -07 was >> intended to give the AS a standard way to reject >> request with multiple audiences/resources that it >> doesn't understand or is unwilling or unable to >> process based on policy or whatever criteria . It was >> intended as a compromise, of sorts, to allow for the >> multiple resources/audiences in the request but >> provide an easy out for the AS of saying it can't be >> supported based on whatever implementation or >> security or policy it has. >> >> On Tue, Mar 28, 2017 at 1:32 AM, Nat Sakimura >> > wrote: >> >> There are cases where tokens are supposed to be >> consumed at multiple places and the `aud` needed >> to capture them. That's why `aud` is a >> multi-valued field. >> >> On Mon, Mar 27, 2017 at 11:35 AM Torsten >> Lodderstedt > > wrote: >> >> May I ask you to explain this reason? >> >>> Am 27.03.2017 um 08:48 schrieb Mike Jones >>> >> >: >>> >>> For the same reason that the “aud†claim is >>> multi-valued in JWTs, the audience needs to >>> stay multi-valued in Token Exchange. Ditto >>> for resources. >>> >>> Thanks, >>> >>> -- Mike >>> >>> *From:* OAuth >>> [mailto:oauth-bounces@ietf.org] *On Behalf >>> Of *Brian Campbell >>> *Sent:* Monday, March 27, 2017 8:45 AM >>> *To:* Torsten Lodderstedt >>> >> > >>> *Cc:* oauth >> > >>> *Subject:* Re: [OAUTH-WG] I-D Action: >>> draft-ietf-oauth-token-exchange-07.txt >>> >>> Thanks for the review and question, Torsten. >>> >>> The desire to support multiple >>> audience/resource values in the request came >>> up during a review and discussion among the >>> authors of the document when preparing the >>> -03 draft. As I recall, it was said that >>> both Salesforce and Microsoft had use-cases >>> for it. I incorporated support for it into >>> the draft acting in the role of editor. >>> >>> From an individual perspective, I tend to >>> agree with you that allowing for multiple >>> audiences/resources adds a lot of complexity >>> that's like not needed in many (or most) >>> cases. And I would personally be open to >>> making audience and resource mutual >>> exclusive and single valued. A question for >>> the WG I suppose. >>> >>> The "invalid_target" error code that was >>> added in -07 was intended to give the AS a >>> standard way to deal with the complexity and >>> reject request with multiple >>> audiences/resources that it doesn't >>> understand or is unwilling or unable to >>> process. It was intended as a compromise, of >>> sorts, to allow for the multiples but >>> provide an easy out of saying it can't be >>> supported based on whatever implementation >>> or policy of the AS. >>> >>> On Sun, Mar 26, 2017 at 9:00 AM, Torsten >>> Lodderstedt >> > wrote: >>> >>> Hi Brian, >>> >>> thanks for the clarification around >>> resource, audience and scope. >>> >>> Here are my comments on the draft: >>> >>> In section 2.1 it states: „Multiple >>> "resource" parameters may be used to >>> indicate >>> >>> that the issued token is intended to >>> be used at the multiple >>> >>> resources listed.“ >>> >>> Can you please explain the rational in >>> more detail? I don’t understand why >>> there is a need to ask for access >>> tokens, which are good for multiple >>> resources at once. This is a request >>> type more or less exclusively used in >>> server to server scenarios, right? So >>> the only reason I can think of is call >>> reduction. >>> >>> On the other side, this feature >>> increases the AS's complexity, e.g. its >>> policy may prohibit to issue tokens for >>> multiple resources in general or the >>> particular set the client is asking for. >>> How shall the AS handles such cases? >>> >>> And it is getting even more complicated >>> given there could also be multiple >>> audience values and the client could mix >>> them: >>> >>> "Multiple "audience" parameters >>> >>> may be used to indicate that the >>> issued token is intended to be >>> >>> used at the multiple audiences >>> listed. The "audience" and >>> >>> "resource" parameters may be used >>> together to indicate multiple >>> >>> target services with a mix of >>> logical names and physical >>> >>> locations.“ >>> >>> And in the end the client may add some >>> scope values to the „meal“, which brings >>> us to >>> >>> „Effectively, the requested access >>> rights of the >>> >>> token are the cartesian product of all >>> the scopes at all the target >>> >>> services." >>> >>> I personally would suggest to drop >>> support for multiple audience and >>> resource parameters and make audience >>> and resource mutual exclusive. I think >>> this is sufficient and much easier to >>> implement. >>> >>> kind regards, >>> >>> Torsten. >>> >>> Am 11.01.2017 um 20:04 schrieb Brian >>> Campbell >> >: >>> >>> Draft -07 of "OAuth 2.0 Token >>> Exchange" has been published. The >>> primary change in -07 is the >>> addition of a description of the >>> relationship between >>> audience/resource/scope, which was a >>> request or comment that came up >>> during the f2f meeting in Seoul. >>> >>> Excerpted from the Document History: >>> >>> -07 >>> >>> o Fixed typo (desecration -> >>> discretion). >>> o Added an explanation of the >>> relationship between scope, audience >>> and resource in the request >>> and added an "invalid_target" error >>> code enabling the AS to tell >>> the client that the requested >>> audiences/resources were too broad. >>> >>> ---------- Forwarded message ---------- >>> From: >> > >>> Date: Wed, Jan 11, 2017 at 12:00 PM >>> Subject: [OAUTH-WG] I-D Action: >>> draft-ietf-oauth-token-exchange-07.txt >>> To: i-d-announce@ietf.org >>> >>> Cc: oauth@ietf.org >>> >>> >>> >>> >>> A New Internet-Draft is available >>> from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Web >>> Authorization Protocol of the IETF. >>> >>> Title : OAuth 2.0 >>> Token Exchange >>> Authors : Michael B. Jones >>> Anthony Nadalin >>> Brian Campbell >>> John Bradley >>> Chuck Mortimore >>> Filename : >>> draft-ietf-oauth-token-exchange-07.txt >>> Pages : 31 >>> Date : 2017-01-11 >>> >>> Abstract: >>> This specification defines a >>> protocol for an HTTP- and JSON- based >>> Security Token Service (STS) by >>> defining how to request and obtain >>> security tokens from OAuth 2.0 >>> authorization servers, including >>> security tokens employing >>> impersonation and delegation. >>> >>> >>> 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-07 >>> >>> >>> A diff from the previous version is >>> available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-07 >>> >>> >>> >>> Please note that it may take a >>> couple of minutes from the time of >>> submission >>> until the htmlized version and diff >>> are available at tools.ietf.org >>> . >>> >>> Internet-Drafts are also available >>> by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> -- >> >> Nat Sakimura >> >> Chairman of the Board, OpenID Foundation >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --------------EEAEE88F620BB96F53B0D418 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Brian,

Even if Token Exchange is a framework, the goal is to be finally able to interoperate.

Whether we have one or two parameters, would you be able to provide a precise semantics for the "other case" you have in mind ?

Denis

Yes, I omitted your comments in that post because I'd previously replied to you in a separate message where I said that the "actor_token is a security token so that's not an issue that needs to be addressed."  https://www.ietf.org/mail-archive/web/oauth/current/msg17247.html

The other point you've just made about having very precise semantics for a field is a fair one. However, I wanted to avoid introducing yet another field (or really two fields b/c of the associated *_type for each inbound token field), for what felt like a minor semantic variation that could be easily accommodated by the existing framework, to the draft that already has a lot of options and parameters on the request. And Token Exchange really is a framework. I think that, to some extent, the framework is a bit of a Rorschach test for deployers and implementers to utilize to solve their specific issues and needs. I expect that will be the case regardless. And I am proposing to somewhat genericize the text around one request parameter to be more reflective of that.

I would like to hear from others in the WG though.

On Tue, May 9, 2017 at 3:06 AM, Denis <denis.ietf@free.fr> wrote:
Brian,

You omitted to include my comments in this post. So here it is again:

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

The current text is:

actor_token OPTIONAL. A security token that represents the identity of the party that is authorized to use the requested security token and act on behalf of the subject.

This sentence is indeed wrong since an actor-token is not a security token.

So your proposed change does not solve this issue: actor_token  OPTIONAL.  A security token that represents the identity of the acting party.

The current text states:
Typically, in the request, the subject_token represents the identity of the party on behalf of whom
 the token is being requested while the actor_token represents the identity of the party to whom the access
rights of the issued token are being delegated.
Logically, the definition should be along the following lines:

 actor_token OPTIONAL. Indicates the identity of the party to whom the access rights of the issued token are being delegated.

If there is no delegation, then this field (which is optional) will not be used.

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

I read your argumentation, but I maintain my comment. Each field should have a precise semantics.

If you want to have another semantics, you should propose to define another field with its precise meaning.

Denis

Let me throw out a bit more context about this. The "actor_token" might, in a delegation scenario, represent the identity of the party to whom the access rights of the issued token are being delegated. That's the typical delegation scenario that is discussed in the draft. However, the "actor_token" might also be utilized/needed by the AS in an impersonation scenario for policy or auditing reasons even when the resulting issued token doesn't contain info about the delegation or actor. Similarly, the actor might not be strictly doing the impersonation but rather just be a party (again maybe needed for policy or auditing) to the token exchange event itself.  When I wrote the "actor_token" text in section 2.1 some ~18 months ago I had the delegation scenario at the front of my mind and (clearly) intended to accommodate it. However, I didn't intend to limit it to only that and, looking at the text again, I think what is there now is too prescriptive and narrow. Thus my proposing to generalize the text somewhat.




On Mon, May 8, 2017 at 10:29 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
I do have one minor issue I'd like to raise that relates to some conversations I've been a party to recently about implementations and applications of token exchange.

I think that the current text in §2.1 for the "actor_token" is overly specific towards the delegation scenario. I'd propose the language be generalized somewhat to allow more versatility in applications/deployments of the token exchange framework. Here's that text:

   actor_token
      OPTIONAL.  A security token that represents the identity of the
      acting party. 




On Mon, May 8, 2017 at 8:01 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Hi All,

The last email from Brian addresses the multiple audiences/resources issue with an error code, and we did not see any objection to this approach so far.


Authors,

Are there any other open issues with this draft?
Do you believe it is ready for WGLC?

Thanks,
 Rifaat & Hannes



On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
As mentioned during the Chicago meeting the "invalid_target" error code that was added in -07 was intended to give the AS a standard way to reject request with multiple audiences/resources that it doesn't understand or is unwilling or unable to process based on policy or whatever criteria . It was intended as a compromise, of sorts, to allow for the multiple resources/audiences in the request but provide an easy out for the AS of saying it can't be supported based on whatever implementation or security or policy it has.

On Tue, Mar 28, 2017 at 1:32 AM, Nat Sakimura <sakimura@gmail.com> wrote:
There are cases where tokens are supposed to be consumed at multiple places and the `aud` needed to capture them. That's why `aud` is a multi-valued field. 

On Mon, Mar 27, 2017 at 11:35 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
May I ask you to explain this reason?

Am 27.03.2017 um 08:48 schrieb Mike Jones <Michael.Jones@microsoft.com>:

For the same reason that the “aud†claim is multi-valued in JWTs, the audience needs to stay multi-valued in Token Exchange.  Ditto for resources.

 

                                                       Thanks,

                                                       -- Mike

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Monday, March 27, 2017 8:45 AM
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt

 

Thanks for the review and question, Torsten.

The desire to support multiple audience/resource values in the request came up during a review and discussion among the authors of the document when preparing the -03 draft. As I recall, it was said that both Salesforce and Microsoft had use-cases for it. I incorporated support for it into the draft acting in the role of editor.

From an individual perspective, I tend to agree with you that allowing for multiple audiences/resources adds a lot of complexity that's like not needed in many (or most) cases. And I would personally be open to making audience and resource mutual exclusive and single valued. A question for the WG I suppose.

The "invalid_target" error code that was added in -07 was intended to give the AS a standard way to deal with the complexity and reject request with multiple audiences/resources that it doesn't understand or is unwilling or unable to process. It was intended as a compromise, of sorts, to allow for the multiples but provide an easy out of saying it can't be supported based on whatever implementation or policy of the AS.

 

 

 

On Sun, Mar 26, 2017 at 9:00 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi Brian,

 

thanks for the clarification around resource, audience and scope. 

 

Here are my comments on the draft:

 

In section 2.1 it states: „Multiple "resource" parameters may be used to indicate

      that the issued token is intended to be used at the multiple

      resources listed.“

 

Can you please explain the rational in more detail? I don’t understand why there is a need to ask for access tokens, which are good for multiple resources at once. This is a request type more or less exclusively used in server to server scenarios, right? So the only reason I can think of is call reduction. 

 

On the other side, this feature increases the AS's complexity, e.g. its policy may prohibit to issue tokens for multiple resources in general or the particular set the client is asking for. How shall the AS handles such cases?

 

And it is getting even more complicated given there could also be multiple audience values and the client could mix them: 

 

"Multiple "audience" parameters

      may be used to indicate that the issued token is intended to be

      used at the multiple audiences listed.  The "audience" and

      "resource" parameters may be used together to indicate multiple

      target services with a mix of logical names and physical

      locations.“

 

And in the end the client may add some scope values to the „meal“, which brings us to 

 

„Effectively, the requested access rights of the

   token are the cartesian product of all the scopes at all the target

   services."

 

I personally would suggest to drop support for multiple audience and resource parameters and make audience and resource mutual exclusive. I think this is sufficient and much easier to implement.

 

kind regards,

Torsten.

 

 

Am 11.01.2017 um 20:04 schrieb Brian Campbell <bcampbell@pingidentity.com>:

 

Draft -07 of "OAuth 2.0 Token Exchange" has been published. The primary change in -07 is the addition of a description of the relationship between audience/resource/scope, which was a request or comment that came up during the f2f meeting in Seoul.

Excerpted from the Document History:

   -07

   o  Fixed typo (desecration -> discretion).
   o  Added an explanation of the relationship between scope, audience
      and resource in the request and added an "invalid_target" error
      code enabling the AS to tell the client that the requested
      audiences/resources were too broad.

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Wed, Jan 11, 2017 at 12:00 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt
To: i-d-announce@ietf.org
Cc: oauth@ietf.org



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

        Title           : OAuth 2.0 Token Exchange
        Authors         : Michael B. Jones
                          Anthony Nadalin
                          Brian Campbell
                          John Bradley
                          Chuck Mortimore
        Filename        : draft-ietf-oauth-token-exchange-07.txt
        Pages           : 31
        Date            : 2017-01-11

Abstract:
   This specification defines a protocol for an HTTP- and JSON- based
   Security Token Service (STS) by defining how to request and obtain
   security tokens from OAuth 2.0 authorization servers, including
   security tokens employing impersonation and delegation.


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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-07


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

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

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

 

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

 

 


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

Nat Sakimura

Chairman of the Board, OpenID Foundation


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



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






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

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

--------------EEAEE88F620BB96F53B0D418-- From nobody Tue May 9 15:22:18 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E0512EB6A; Tue, 9 May 2017 15:22:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149436853671.1801.1450894534613809895@ietfa.amsl.com> Date: Tue, 09 May 2017 15:22:16 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 22:22:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol of the IETF. Title : Mutual TLS Profiles for OAuth Clients Authors : Brian Campbell John Bradley Nat Sakimura Torsten Lodderstedt Filename : draft-ietf-oauth-mtls-00.txt Pages : 10 Date : 2017-05-09 Abstract: This document describes Transport Layer Security (TLS) mutual authentication using X.509 certificates as a mechanism for both OAuth client authentication to the token endpoint as well as for sender constrained access to OAuth protected resources. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-mtls-00 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 9 15:27:26 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F752127419 for ; Tue, 9 May 2017 15:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUj5AiODr27b for ; Tue, 9 May 2017 15:27:23 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 657F2126BFD for ; Tue, 9 May 2017 15:27:23 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id k74so13930244qke.1 for ; Tue, 09 May 2017 15:27:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2+T2r4kWjef6MsArkjTWbMdc0cLg/701ePCNt+J8wC0=; b=n0RvrBeV9ISzkKUv+W0lR0T2tK1A8kfwXplGnGXuxSZnuSvx+n5aTGFnLhwz+jaqZY /Xs5J8qUmNwt8qMGx28SgjHaw5cqvzGiePQoplO/uEzsrrKBgvEy/lKabpw12TK1X45b vlINbnqSWYQq2OwTzHYc6r0UlFh285TmXEQNs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2+T2r4kWjef6MsArkjTWbMdc0cLg/701ePCNt+J8wC0=; b=VWj2Nj42TLiA0DA5yLXcBnXA974DcTxThVS7uvoUa3LJUiHy7fkvjpHnagoGv5w6NZ KT5CG3lZ8NHznHtg2v7EkgkK92rVg3Ci7FrUPQEl6uwTsKHR69vEqnjtHvJjQY6REA8q RAq7bVeO+WjDfbYimS8zBqWJ+QC7uFvxutiXk+syYOIzDET1b6aubbka9PUFVM38dpHb TNyDTeQW5kcEqhDhZZSkEMNz1oQoLNspx1fOl4L2WGp/Scq+QVbetRntWLWdTxhaCbI5 By197YyEdnUznPqmXpky+iSMakgsZD5TpKQMVYH7zW/gTxPsmVgMrfIw8khPtG7b1m2d XnXA== X-Gm-Message-State: AODbwcCfvEd6n05Sxh66R6I18wyCZD6RHUPTx7HjdlOFWhn/x2zfBJVy SiOBnfALKiEBC/Gy0ydH6ejuAspjkY27 X-Received: by 10.55.54.204 with SMTP id d195mr2483105qka.255.1494368842496; Tue, 09 May 2017 15:27:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.50.163 with HTTP; Tue, 9 May 2017 15:26:52 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Tue, 9 May 2017 16:26:52 -0600 Message-ID: To: Hannes Tschofenig Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary=001a1147299a0585de054f1edcea Archived-At: Subject: Re: [OAUTH-WG] Mutual TLS Profiles for OAuth Clients X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 22:27:25 -0000 --001a1147299a0585de054f1edcea Content-Type: text/plain; charset=UTF-8 Thanks Hannes & Rifaat, draft-ietf-oauth-mtls-00 has been submitted. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-mtls-00 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-00 On Tue, May 9, 2017 at 7:40 AM, Hannes Tschofenig wrote: > Hi authors, > > based on the feedback at the last IETF meeting and the response from the > mailing list there is good support for adopting this document. > > Please submit a -00 version of the WG document as a starting point for > future work in the OAuth WG. > > Ciao > Hannes & Rifaat > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a1147299a0585de054f1edcea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Hannes & Rifaat,

draft-ietf-oauth-mtls-0= 0 has been submitted.=C2=A0

On Tu= e, May 9, 2017 at 7:40 AM, Hannes Tschofenig <hannes.tschofenig@g= mx.net> wrote:
Hi authors,<= br>
based on the feedback at the last IETF meeting and the response from the mailing list there is good support for adopting this document.

Please submit a -00 version of the WG document as a starting point for
future work in the OAuth WG.

Ciao
Hannes & Rifaat


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


--001a1147299a0585de054f1edcea-- From nobody Wed May 10 14:16:02 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A1D127871 for ; Wed, 10 May 2017 14:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plB3QfT3gGvC for ; Wed, 10 May 2017 14:15:59 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4801128959 for ; Wed, 10 May 2017 14:15:58 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id b84so19142070wmh.0 for ; Wed, 10 May 2017 14:15:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=IwRHdgTN80OAuMqd0+jX49SAsfRccUrLvMMQ+/5m2ds=; b=UbSCLYJ4DrsN6O9LFfblZe4CWA2KWbrHxIEKPiCPJsYG8Z30URqM4yLoIYGJYntV/+ o5Rz6GWCWWVwfe2b+LVqeCiaJve5PhQFEMnucfy3cLN57P1RvN1V6U7NbGnV6poDXM3o 4P4mZu0NBqtEigdTEyKbTKuxvKSESN2fjHjH5JmKk3ld/oWGb48u0l5t61pvE4b27N09 WyDcr2iiUkm3mOaL1qG2Aql6Ho7YFioSIsVIa6C7sBiGg+AFCL9o7zhISL9j5veymNeg hDxhJ22v8uvYPpCe3JQRpchE72eb8uTJgXiZAIGr0PhXIKLrwwyqR0d7r7ZBiK2b7eEv f63g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=IwRHdgTN80OAuMqd0+jX49SAsfRccUrLvMMQ+/5m2ds=; b=PfrkiB4/1nBsJCht7WozqrnBLSZFZP7WgA7yWOqnMIsKTyeAUcTJcsBmECQ4shOt1Q tGBkuN0xbPjhyQjWjp0gCVf4VUUb7fm0vcUA26Cp4WZa3gKimtPpkAmgUV1L1JGmbGqm xAtdvIzm2i61hlk5gh2FIxnDMYJeV4ICFPXmNeNhgixP5YCgtw365Fo8VWrUhrhknW1C zmPOEFp5WCoucMaaAM2mSd5zmB5vl18OxR8G5EXQC5eGrbgWrRy66caqjVs7HorqSa8l Vx049mRPtJyV422az+T36pSduYczT6c/FAw/cTVZ+y0DCUs3lagjLIiry8+0B4V0e48K CxrQ== X-Gm-Message-State: AODbwcB2yo8Uecfg/uZuB64a5YGV+cfJfCPbggFNtT2v2KNf6R9pAqon o+b3SbMvilHR6s2++6F9bMMvb1yVpA== X-Received: by 10.80.182.174 with SMTP id d43mr5812366ede.56.1494450957085; Wed, 10 May 2017 14:15:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.146.221 with HTTP; Wed, 10 May 2017 14:15:56 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723453A754C534@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: =?UTF-8?Q?Andr=C3=A9_DeMarre?= Date: Wed, 10 May 2017 14:15:56 -0700 Message-ID: To: OAuth WG Content-Type: multipart/alternative; boundary=f403045c0bd66e73eb054f31fa6c Archived-At: Subject: Re: [OAUTH-WG] Phishing with Client Application Name Spoofing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 21:16:01 -0000 --f403045c0bd66e73eb054f31fa6c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I see there is a new security considerations document being drafted. There is an old issue that I've recently been reminded of. Should text about phishing conducted through the authorization dialog be added to the new security document? This kind of attack made headlines last week with a widespread Gmail / Google Docs phishing worm ( https://security.googleblog.com/2017/05/protecting-you-against-phishing.htm= l ). Five years ago, I was encouraged to propose text about this for the Threat Model and Security Considerations document, but I never did; sorry. Original thread in the mail archive: https://www.ietf.org/mail-arch ive/web/oauth/current/msg07625.html This concerns both authorization dialog design and client registration, and as far as I know it's not really covered in any published documents. I'm not entirely sure what mitigations should be recommended, but I think authorization server implementers need to be more cognizant of this attack. Regards, Andre DeMarre On Tue, Jan 17, 2012 at 4:06 AM, Mark Mcgloin wrote: > Andre > > Please feel free to propose text, perhaps with a better title than I > suggested. During our discussion on section 4.1.4 (End-user credentials > phished using compromised or embedded browser), we have decided on the > countermeasure below, albeit for a different threat - phishing client as > opposed to client name spoofing. Your's can be a variant of this with > different validation recommendations. > > > 2. Client applications could be validated prior to publication in an > application market for users to access. That validation is out of scope f= or > OAuth but could include validating that the client application handles us= er > authentication in an appropriate way > > > Regards > Mark > > Andr=C3=A9 DeMarre wrote on 16/01/2012 23:20:02: > > > > > To: > > > > Eran Hammer 16/01/2012 23:22 > > > > > > > Re: [OAUTH-WG] Phishing with Client Application Name Spoofing > > > > Eran, > > > > Yes; I think a section should be added to the security model doc. > > > > On 2011-12-16 Mark Mcgloin agreed and suggested we call it "Client > > Registration of phishing clients": > > http://www.ietf.org/mail-archive/web/oauth/current/msg08061.html > > > > I'm happy to propose the text; it might be one or two days though. > > > > Regards, > > Andre DeMarre > > > > On Mon, Jan 16, 2012 at 10:30 AM, Eran Hammer > wrote: > > > Should this be added to the security model document? Is it already > > addressed there? > > > > > > EHL > > > > > >> -----Original Message----- > > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf > > >> Of Andr=C3=A9 DeMarre > > >> Sent: Tuesday, October 04, 2011 11:33 AM > > >> To: OAuth WG > > >> Subject: [OAUTH-WG] Phishing with Client Application Name Spoofing > > >> > > >> I've not seen this particular variant of phishing and client > impersonation > > >> discussed. A cursory search revealed that most of the related > discussion > > >> centers around either (a) client impersonation with stolen client > > credentials > > >> or (b) phishing by malicious clients directing resource owners to > spoofed > > >> authorization servers. This is different. > > >> > > >> This attack exploits the trust a resource owner has for an OAuth > > >> authorization server so as to lend repute to a malicious client > > pretending to > > >> be from a trustworthy source. This is not necessarily a direct > > vulnerability of > > >> OAuth; rather, it shows that authorization servers have a > responsibility > > >> regarding client application names and how they present resource > owners > > >> with the option to allow or deny authorization. > > >> > > >> A key to this exploit is the process of client registration with > > the authorization > > >> server. A malicious client developer registers his client > > application with a > > >> name that appears to represent a legitimate organization which > resource > > >> owners are likely to trust. Resource owners at the authorization > endpoint > > >> may be misled into granting authorization when they see the > authorization > > >> server asserting " is requesting permission > to..." > > >> > > >> Imagine someone registers a client application with an OAuth service= , > let's > > >> call it Foobar, and he names his client app "Google, Inc.". The Foob= ar > > >> authorization server will engage the user with "Google, Inc. is > requesting > > >> permission to do the following." The resource owner might reason, "I > see > > >> that I'm legitimately on the https://www.foobar.com site, and Foobar > is > > >> telling me that Google wants permission. I trust Foobar and Google, = so > I'll > > >> click Allow." > > >> > > >> To make the masquerade act even more convincing, many of the most > > >> popular OAuth services allow app developers to upload images which > could > > >> be official logos of the organizations they are posing as. Often app > > >> developers can supply arbitrary, unconfirmed URIs which are shown to > the > > >> resource owner as the app's website, even if the domain does not mat= ch > the > > >> redirect URI. Some OAuth services blindly entrust client apps to > customize > > >> the authorization page in other ways. > > >> > > >> This is hard to defend against. Authorization server administrators > could > > >> police client names, but that approach gives them a burden similar t= o > > >> certificate authorities to verify organizations before issuing > > certificates. Very > > >> expensive. > > >> > > >> A much simpler solution is for authorization servers to be > > careful with their > > >> wording and educate resource owners about the need for discretion wh= en > > >> granting authority. Foobar's message above could be > > >> changed: "An application calling itself Google, Inc. is > > requesting permission to > > >> do the following" later adding, "Only allow this request if you > > are sure of the > > >> application's source." Such wording is less likely to give the > > impression that > > >> the resource server is vouching for the application's identity. > > >> > > >> Authorization servers would also do well to show the resource owner > > >> additional information about the client application to help them mak= e > > >> informed decisions. For example, it could display all or part of the > app's > > >> redirect URI, saying, "The application is operating on > > example.com" or "If you > > >> decide to allow this application, your browser will be directed to > > >> http://www.example.com/." Further, if the client app's redirect > > URI uses TLS > > >> (something authorization servers might choose to mandate), then auth > > >> servers can verify the certificate and show the certified > > organization name to > > >> resource owners. > > >> > > >> This attack is possible with OAuth 1, but OAuth 2 makes successful > > >> exploitation easier. OAuth 1 required the client to obtain temporary > > >> credentials (aka access tokens) before sending resource owners to th= e > > >> authorization endpoint. Now with OAuth 2, this attack does not requi= re > > >> resource owners to interact with the client application before > visiting the > > >> authorization server. The malicious client developer only needs > > to distribute > > >> links around the web to the authorization server's authorization > > endpoint. If > > >> the HTTP service is a social platform, the client app might > > distribute links using > > >> resource owners' accounts with the access tokens it has acquired, > becoming > > >> a sort of worm. Continuing the Google/Foobar example above, it might > use > > >> anchor text such as "I used Google Plus to synchronize with my Fooba= r > > >> account." Moreover, if the app's redirect URI bounces the resource > owner > > >> back to the HTTP service after acquiring an authorization code, > > the victim will > > >> never see a page rendered at the insidious app's domain. > > >> > > >> This is especially dangerous because the public is not trained to > defend > > >> against it. Savvy users are (arguably) getting better at > > protecting themselves > > >> from traditional phishing by verifying the domain in the address bar= , > and > > >> perhaps checking TLS certificates, but such defenses are irrelevent > here. > > >> Resource owners now need to verify not only that they are on the > legitimate > > >> authorization server, but to consider the trustworthyness of the lin= k > that > > >> referred them there. > > >> > > >> I'm not sure what can or should be done, but I think it's important > for > > >> authorization server implementers to be aware of this attack. If > > >> administrators are not able to authenticate client organizations,the= n > they > > >> are shifting this burden to resource owners. They should do all they > can to > > >> educate resource owners and help them make informed decisions before > > >> granting authorization. > > >> > > >> Regards, > > >> Andre DeMarre > > >> _______________________________________________ > > >> OAuth mailing list > > >> OAuth@ietf.org > > >> https://www.ietf.org/mailman/listinfo/oauth > > > > --f403045c0bd66e73eb054f31fa6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I see= there is a new security considerations document being drafted. There is an= old issue that I've recently been reminded of.
=
Should text about phishing conducted through th= e authorization dialog be added to the new security document? This kind of = attack made headlines last week with a widespread Gmail / Google Docs phish= ing worm (https://security.googleblog.com/2017/05/protecting-you-against-phishing.html).

<= /div>Five years ago, I was encouraged to propose text about this for the Th= reat Model and Security Considerations document, but I never did; sorry. Or= iginal thread in the mail archive: https://www.ietf.or= g/mail-archive/web/oauth/current/msg07625.html

=
This concerns both authorization dialog design and client registration= , and as far as I know it's not really covered in any published documen= ts. I'm not entirely sure what mitigations should be recommended, but I= think authorization server implementers need to be more cognizant of this = attack.

Regards,
Andre DeMarre
<= div class=3D"gmail_extra">
On Tue, Jan 17, 20= 12 at 4:06 AM, Mark Mcgloin <mark.mcgloin@ie.ibm.com> = wrote:
Andre

Please feel free to propose text, perhaps with a better title than I
suggested. During our discussion on section 4.1.4 (End-user credentials
phished using compromised or=C2=A0 embedded browser), we have decided on th= e
countermeasure below, albeit for a different threat - phishing client as opposed to client name spoofing. Your's can be a variant of this with different validation recommendations.


2. Client applications could be validated prior to publication in an
application market for users to access. That validation is out of scope for=
OAuth but could include validating that the client application handles user=
authentication in an appropriate way


Regards
Mark

Andr=C3=A9 DeMarre <andredemarre@gmail.com> wrote on 16/01/2012 23:20:02:

>
> To:
>
> Eran Hammer <eran@hueniverse.com> 16/01/2012 23:22
>

>
> Re: [OAUTH-WG] Phishing with Client Application Name Spoofing
>
> Eran,
>
> Yes; I think a section should be added to the security model doc.
>
> On 2011-12-16 Mark Mcgloin agreed and suggested we call it "Clien= t
> Registration of phishing clients":
> http://www.ietf.org/mail-archi<= wbr>ve/web/oauth/current/msg08061.html
>
> I'm happy to propose the text; it might be one or two days though.=
>
> Regards,
> Andre DeMarre
>
> On Mon, Jan 16, 2012 at 10:30 AM, Eran Hammer <eran@hueniverse.com>
wrote:
> > Should this be added to the security model document? Is it alread= y
> addressed there?
> >
> > EHL
> >
> >> -----Original Message-----
> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> >> Of Andr=C3=A9 DeMarre
> >> Sent: Tuesday, October 04, 2011 11:33 AM
> >> To: OAuth WG
> >> Subject: [OAUTH-WG] Phishing with Client Application Name Spo= ofing
> >>
> >> I've not seen this particular variant of phishing and cli= ent
impersonation
> >> discussed. A cursory search revealed that most of the related=
discussion
> >> centers around either (a) client impersonation with stolen cl= ient
> credentials
> >> or (b) phishing by malicious clients directing resource owner= s to
spoofed
> >> authorization servers. This is different.
> >>
> >> This attack exploits the trust a resource owner has for an OA= uth
> >> authorization server so as to lend repute to a malicious clie= nt
> pretending to
> >> be from a trustworthy source. This is not necessarily a direc= t
> vulnerability of
> >> OAuth; rather, it shows that authorization servers have a
responsibility
> >> regarding client application names and how they present resou= rce
owners
> >> with the option to allow or deny authorization.
> >>
> >> A key to this exploit is the process of client registration w= ith
> the authorization
> >> server. A malicious client developer registers his client
> application with a
> >> name that appears to represent a legitimate organization whic= h
resource
> >> owners are likely to trust. Resource owners at the authorizat= ion
endpoint
> >> may be misled into granting authorization when they see the authorization
> >> server asserting "<some trustworthy name> is reque= sting permission
to..."
> >>
> >> Imagine someone registers a client application with an OAuth = service,
let's
> >> call it Foobar, and he names his client app "Google, Inc= .". The Foobar
> >> authorization server will engage the user with "Google, = Inc. is
requesting
> >> permission to do the following." The resource owner migh= t reason, "I
see
> >> that I'm legitimately on the https://www.foobar.com site= , and Foobar
is
> >> telling me that Google wants permission. I trust Foobar and G= oogle, so
I'll
> >> click Allow."
> >>
> >> To make the masquerade act even more convincing, many of the = most
> >> popular OAuth services allow app developers to upload images = which
could
> >> be official logos of the organizations they are posing as. Of= ten app
> >> developers can supply arbitrary, unconfirmed URIs which are s= hown to
the
> >> resource owner as the app's website, even if the domain d= oes not match
the
> >> redirect URI. Some OAuth services blindly entrust client apps= to
customize
> >> the authorization page in other ways.
> >>
> >> This is hard to defend against. Authorization server administ= rators
could
> >> police client names, but that approach gives them a burden si= milar to
> >> certificate authorities to verify organizations before issuin= g
> certificates. Very
> >> expensive.
> >>
> >> A much simpler solution is for authorization servers to be > careful with their
> >> wording and educate resource owners about the need for discre= tion when
> >> granting authority. Foobar's message above could be
> >> changed: "An application calling itself Google, Inc. is<= br> > requesting permission to
> >> do the following" later adding, "Only allow this re= quest if you
> are sure of the
> >> application's source." Such wording is less likely t= o give the
> impression that
> >> the resource server is vouching for the application's ide= ntity.
> >>
> >> Authorization servers would also do well to show the resource= owner
> >> additional information about the client application to help t= hem make
> >> informed decisions. For example, it could display all or part= of the
app's
> >> redirect URI, saying, "The application is operating on > ex= ample.com" or "If you
> >> decide to allow this application, your browser will be direct= ed to
> >> http://www.example.com/." Further, if the client app&#= 39;s redirect
> URI uses TLS
> >> (something authorization servers might choose to mandate), th= en auth
> >> servers can verify the certificate and show the certified
> organization name to
> >> resource owners.
> >>
> >> This attack is possible with OAuth 1, but OAuth 2 makes succe= ssful
> >> exploitation easier. OAuth 1 required the client to obtain te= mporary
> >> credentials (aka access tokens) before sending resource owner= s to the
> >> authorization endpoint. Now with OAuth 2, this attack does no= t require
> >> resource owners to interact with the client application befor= e
visiting the
> >> authorization server. The malicious client developer only nee= ds
> to distribute
> >> links around the web to the authorization server's author= ization
> endpoint. If
> >> the HTTP service is a social platform, the client app might > distribute links using
> >> resource owners' accounts with the access tokens it has a= cquired,
becoming
> >> a sort of worm. Continuing the Google/Foobar example above, i= t might
use
> >> anchor text such as "I used Google Plus to synchronize w= ith my Foobar
> >> account." Moreover, if the app's redirect URI bounce= s the resource
owner
> >> back to the HTTP service after acquiring an authorization cod= e,
> the victim will
> >> never see a page rendered at the insidious app's domain.<= br> > >>
> >> This is especially dangerous because the public is not traine= d to
defend
> >> against it. Savvy users are (arguably) getting better at
> protecting themselves
> >> from traditional phishing by verifying the domain in the addr= ess bar,
and
> >> perhaps checking TLS certificates, but such defenses are irre= levent
here.
> >> Resource owners now need to verify not only that they are on = the
legitimate
> >> authorization server, but to consider the trustworthyness of = the link
that
> >> referred them there.
> >>
> >> I'm not sure what can or should be done, but I think it&#= 39;s important
for
> >> authorization server implementers to be aware of this attack.= If
> >> administrators are not able to authenticate client organizati= ons,then
they
> >> are shifting this burden to resource owners. They should do a= ll they
can to
> >> educate resource owners and help them make informed decisions= before
> >> granting authorization.
> >>
> >> Regards,
> >> Andre DeMarre
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@iet= f.org
> >> https://www.ietf.org/mailman/listinf= o/oauth
>


--f403045c0bd66e73eb054f31fa6c-- From nobody Thu May 11 09:06:29 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD2712EC42 for ; Thu, 11 May 2017 09:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XMH-lm0Wm3c for ; Thu, 11 May 2017 09:06:23 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9056A12EC84 for ; Thu, 11 May 2017 08:59:18 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id f131so2006451pgc.2 for ; Thu, 11 May 2017 08:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pP1ZecrT9jOOoKcXdZ+r8RITsurUxzNBgchnKBk6IKU=; b=LgqGpRcK5V7Xnt4tDezdW+uIWcdoq8wndCTphNtKernqLuXr/wanZcxlygBPfJS8Hg GHbIQIjnMFkxt4QAkBxLVQAEWpi2GJbEYeLB52qw9hgkPSl0CJKDQOT0UGW24LEHFnZ/ AtXeIgzW+vgszE0wuAoBstT28umeoq9CJLJVs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pP1ZecrT9jOOoKcXdZ+r8RITsurUxzNBgchnKBk6IKU=; b=TLCShE8CzNe2xu4nFjByFK7OZhLxPepS/iYjx379n93qb9+EKY0E6XDgnx0FH86/t6 8E8m6KjWY+AMq0A4RA46IoBc49ziSXyaI3LElGOyjiLqQsGKGmcGVZdN5O4WhUT0zuxr /Kmydr/Z9ot1oeYxtqUk83W/0kE9O+S6ekhL8m8da0gSU23AlHAAetqZ0cF/DxZHWpSf aSpDERqDUQVHU0lCrmVWaLsnuFeBDiAoeLcHqqcP+4wB9XeTwPcCppjAdLHZqJLazhzR i28vP3euwHRjf/aUm2ToHnw3V2MExVo3cinMKSv8UOXLgBxEnKwLb/MeYhx1+xl1ETgx 3ptA== X-Gm-Message-State: AODbwcAzeGZiqr+ZUDZTVDxwdaXWtTg/OzSvpZEQ4tPfG38v/wPxDqDv TKudqCQF8yz0TXIKZAFiHfogMjU/snAn X-Received: by 10.99.109.129 with SMTP id i123mr1068594pgc.103.1494518357934; Thu, 11 May 2017 08:59:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.154.205 with HTTP; Thu, 11 May 2017 08:58:47 -0700 (PDT) In-Reply-To: <58cc229c-ca5e-18d4-8b62-fbb3853f5cca@free.fr> References: <148416124213.8244.5842562779051799977.idtracker@ietfa.amsl.com> <9199091B-5D7F-4D66-9EC5-CB0EF2D3CF6D@lodderstedt.net> <30B37ED3-6E3B-4739-9917-BDEC198CA027@lodderstedt.net> <58cc229c-ca5e-18d4-8b62-fbb3853f5cca@free.fr> From: Brian Campbell Date: Thu, 11 May 2017 09:58:47 -0600 Message-ID: To: Denis Cc: oauth Content-Type: multipart/alternative; boundary="f403045c5052d5e3aa054f41ab4d" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 16:06:28 -0000 --f403045c5052d5e3aa054f41ab4d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The token exchange framework facilitates deployments like this one https://help.salesforce.com/articleView?id=3Dremoteaccess_oaut h_asset_token_flow.htm or https://developer.box.com/docs /getting-started-with-new-box-view, for example, and I don't think pure plug and play interoperability is a realistic goal. The framework promotes interoperability in the form of common patterns and parameters that can be supported in libraries, products, and services. There's not one "other case" I have in mind but rather just broadening the text somewhat to more straightforwardly accommodate other cases. One potential example is where the actor_token represents an authorizing party (again maybe needed for policy or auditing) to the token exchange event itself rather than the party that's having access rights assigned to it (implicitly with impersonation or explicitly with delegation). On Tue, May 9, 2017 at 9:55 AM, Denis wrote: > Brian, > > Even if Token Exchange is a framework, the goal is to be finally able to > interoperate. > > Whether we have one or two parameters, would you be able to provide a > precise semantics for the "other case" you have in mind ? > > Denis > > Yes, I omitted your comments in that post because I'd previously replied > to you in a separate message where I said that the "actor_token is a > security token so that's not an issue that needs to be addressed." > https://www.ietf.org/mail-archive/web/oauth/current/msg17247.html > > The other point you've just made about having very precise semantics for = a > field is a fair one. However, I wanted to avoid introducing yet another > field (or really two fields b/c of the associated *_type for each inbound > token field), for what felt like a minor semantic variation that could be > easily accommodated by the existing framework, to the draft that already > has a lot of options and parameters on the request. And Token Exchange > really is a framework. I think that, to some extent, the framework is a b= it > of a Rorschach test for deployers and implementers to utilize to solve > their specific issues and needs. I expect that will be the case regardles= s. > And I am proposing to somewhat genericize the text around one request > parameter to be more reflective of that. > > I would like to hear from others in the WG though. > > On Tue, May 9, 2017 at 3:06 AM, Denis wrote: > >> Brian, >> >> You omitted to include my comments in this post. So here it is again: >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> The current text is: >> >> actor_token OPTIONAL. A security token that represents the identity of >> the party that is authorized to use the requested security token and act= on >> behalf of the subject. >> >> This sentence is indeed wrong since an actor-token is not a security >> token. >> >> So your proposed change does not solve this issue: actor_token >> OPTIONAL. A security token that represents the identity of the acting >> party. >> >> The current text states: >> >> Typically, in the request, the subject_token represents the identity of >> the party on behalf of whom >> the token is being requested while the actor_token represents the >> identity of the party to whom the access >> rights of the issued token are being delegated. >> >> Logically, the definition should be along the following lines: >> >> actor_token OPTIONAL. Indicates the identity of the party to whom the >> access rights of the issued token are being delegated. >> >> If there is no delegation, then this field (which is optional) will not >> be used. >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> I read your argumentation, but I maintain my comment. Each field should >> have a precise semantics. >> >> If you want to have another semantics, you should propose to define >> another field with its precise meaning. >> >> Denis >> >> Let me throw out a bit more context about this. The "actor_token" might, >> in a delegation scenario, represent the identity of the party to whom th= e >> access rights of the issued token are being delegated. That's the typica= l >> delegation scenario that is discussed in the draft. However, the >> "actor_token" might also be utilized/needed by the AS in an impersonatio= n >> scenario for policy or auditing reasons even when the resulting issued >> token doesn't contain info about the delegation or actor. Similarly, the >> actor might not be strictly doing the impersonation but rather just be a >> party (again maybe needed for policy or auditing) to the token exchange >> event itself. When I wrote the "actor_token" text in section 2.1 some ~= 18 >> months ago I had the delegation scenario at the front of my mind and >> (clearly) intended to accommodate it. However, I didn't intend to limit = it >> to only that and, looking at the text again, I think what is there now i= s >> too prescriptive and narrow. Thus my proposing to generalize the text >> somewhat. >> >> >> >> >> On Mon, May 8, 2017 at 10:29 AM, Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >>> I do have one minor issue I'd like to raise that relates to some >>> conversations I've been a party to recently about implementations and >>> applications of token exchange. >>> >>> I think that the current text in =C2=A72.1 for the "actor_token" is ove= rly >>> specific towards the delegation scenario. I'd propose the language be >>> generalized somewhat to allow more versatility in applications/deployme= nts >>> of the token exchange framework. Here's that text: >>> >>> actor_token >>> OPTIONAL. A security token that represents the identity of the >>> acting party. >>> >>> >>> >>> >>> On Mon, May 8, 2017 at 8:01 AM, Rifaat Shekh-Yusef < >>> rifaat.ietf@gmail.com> wrote: >>> >>>> Hi All, >>>> >>>> The last email from Brian addresses the multiple audiences/resources >>>> issue with an error code, and we did not see any objection to this app= roach >>>> so far. >>>> >>>> >>>> *Authors,* >>>> >>>> Are there any other open issues with this draft? >>>> Do you believe it is ready for WGLC? >>>> >>>> Thanks, >>>> Rifaat & Hannes >>>> >>>> >>>> >>>> On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell < >>>> bcampbell@pingidentity.com> wrote: >>>> >>>>> As mentioned during the Chicago meeting the "invalid_target" error >>>>> code that was added in -07 was intended to give the AS a standard way= to >>>>> reject request with multiple audiences/resources that it doesn't unde= rstand >>>>> or is unwilling or unable to process based on policy or whatever crit= eria . >>>>> It was intended as a compromise, of sorts, to allow for the multiple >>>>> resources/audiences in the request but provide an easy out for the AS= of >>>>> saying it can't be supported based on whatever implementation or secu= rity >>>>> or policy it has. >>>>> >>>>> On Tue, Mar 28, 2017 at 1:32 AM, Nat Sakimura >>>>> wrote: >>>>> >>>>>> There are cases where tokens are supposed to be consumed at multiple >>>>>> places and the `aud` needed to capture them. That's why `aud` is a >>>>>> multi-valued field. >>>>>> >>>>>> On Mon, Mar 27, 2017 at 11:35 AM Torsten Lodderstedt < >>>>>> torsten@lodderstedt.net> wrote: >>>>>> >>>>>>> May I ask you to explain this reason? >>>>>>> >>>>>>> Am 27.03.2017 um 08:48 schrieb Mike Jones < >>>>>>> Michael.Jones@microsoft.com>: >>>>>>> >>>>>>> For the same reason that the =E2=80=9Caud=E2=80=9D claim is multi-v= alued in JWTs, >>>>>>> the audience needs to stay multi-valued in Token Exchange. Ditto f= or >>>>>>> resources. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -- Mike >>>>>>> >>>>>>> >>>>>>> >>>>>>> *From:* OAuth [mailto:oauth-bounces@ietf.org >>>>>>> ] *On Behalf Of *Brian Campbell >>>>>>> *Sent:* Monday, March 27, 2017 8:45 AM >>>>>>> *To:* Torsten Lodderstedt >>>>>>> *Cc:* oauth >>>>>>> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchan= g >>>>>>> e-07.txt >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks for the review and question, Torsten. >>>>>>> >>>>>>> The desire to support multiple audience/resource values in the >>>>>>> request came up during a review and discussion among the authors of= the >>>>>>> document when preparing the -03 draft. As I recall, it was said tha= t both >>>>>>> Salesforce and Microsoft had use-cases for it. I incorporated suppo= rt for >>>>>>> it into the draft acting in the role of editor. >>>>>>> >>>>>>> From an individual perspective, I tend to agree with you that >>>>>>> allowing for multiple audiences/resources adds a lot of complexity = that's >>>>>>> like not needed in many (or most) cases. And I would personally be = open to >>>>>>> making audience and resource mutual exclusive and single valued. A = question >>>>>>> for the WG I suppose. >>>>>>> >>>>>>> The "invalid_target" error code that was added in -07 was intended >>>>>>> to give the AS a standard way to deal with the complexity and rejec= t >>>>>>> request with multiple audiences/resources that it doesn't understan= d or is >>>>>>> unwilling or unable to process. It was intended as a compromise, of= sorts, >>>>>>> to allow for the multiples but provide an easy out of saying it can= 't be >>>>>>> supported based on whatever implementation or policy of the AS. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sun, Mar 26, 2017 at 9:00 AM, Torsten Lodderstedt < >>>>>>> torsten@lodderstedt.net> wrote: >>>>>>> >>>>>>> Hi Brian, >>>>>>> >>>>>>> >>>>>>> >>>>>>> thanks for the clarification around resource, audience and scope. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Here are my comments on the draft: >>>>>>> >>>>>>> >>>>>>> >>>>>>> In section 2.1 it states: =E2=80=9EMultiple "resource" parameters m= ay be >>>>>>> used to indicate >>>>>>> >>>>>>> that the issued token is intended to be used at the multiple >>>>>>> >>>>>>> resources listed.=E2=80=9C >>>>>>> >>>>>>> >>>>>>> >>>>>>> Can you please explain the rational in more detail? I don=E2=80=99t >>>>>>> understand why there is a need to ask for access tokens, which are = good for >>>>>>> multiple resources at once. This is a request type more or less exc= lusively >>>>>>> used in server to server scenarios, right? So the only reason I can= think >>>>>>> of is call reduction. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On the other side, this feature increases the AS's complexity, e.g. >>>>>>> its policy may prohibit to issue tokens for multiple resources in g= eneral >>>>>>> or the particular set the client is asking for. How shall the AS ha= ndles >>>>>>> such cases? >>>>>>> >>>>>>> >>>>>>> >>>>>>> And it is getting even more complicated given there could also be >>>>>>> multiple audience values and the client could mix them: >>>>>>> >>>>>>> >>>>>>> >>>>>>> "Multiple "audience" parameters >>>>>>> >>>>>>> may be used to indicate that the issued token is intended to = be >>>>>>> >>>>>>> used at the multiple audiences listed. The "audience" and >>>>>>> >>>>>>> "resource" parameters may be used together to indicate multip= le >>>>>>> >>>>>>> target services with a mix of logical names and physical >>>>>>> >>>>>>> locations.=E2=80=9C >>>>>>> >>>>>>> >>>>>>> >>>>>>> And in the end the client may add some scope values to the =E2=80= =9Emeal=E2=80=9C, >>>>>>> which brings us to >>>>>>> >>>>>>> >>>>>>> >>>>>>> =E2=80=9EEffectively, the requested access rights of the >>>>>>> >>>>>>> token are the cartesian product of all the scopes at all the >>>>>>> target >>>>>>> >>>>>>> services." >>>>>>> >>>>>>> >>>>>>> >>>>>>> I personally would suggest to drop support for multiple audience an= d >>>>>>> resource parameters and make audience and resource mutual exclusive= . I >>>>>>> think this is sufficient and much easier to implement. >>>>>>> >>>>>>> >>>>>>> >>>>>>> kind regards, >>>>>>> >>>>>>> Torsten. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Am 11.01.2017 um 20:04 schrieb Brian Campbell < >>>>>>> bcampbell@pingidentity.com>: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Draft -07 of "OAuth 2.0 Token Exchange" has been published. The >>>>>>> primary change in -07 is the addition of a description of the relat= ionship >>>>>>> between audience/resource/scope, which was a request or comment tha= t came >>>>>>> up during the f2f meeting in Seoul. >>>>>>> >>>>>>> Excerpted from the Document History: >>>>>>> >>>>>>> -07 >>>>>>> >>>>>>> o Fixed typo (desecration -> discretion). >>>>>>> o Added an explanation of the relationship between scope, >>>>>>> audience >>>>>>> and resource in the request and added an "invalid_target" err= or >>>>>>> code enabling the AS to tell the client that the requested >>>>>>> audiences/resources were too broad. >>>>>>> >>>>>>> ---------- Forwarded message ---------- >>>>>>> From: >>>>>>> Date: Wed, Jan 11, 2017 at 12:00 PM >>>>>>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchang >>>>>>> e-07.txt >>>>>>> To: i-d-announce@ietf.org >>>>>>> Cc: oauth@ietf.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>>> directories. >>>>>>> This draft is a work item of the Web Authorization Protocol of the >>>>>>> IETF. >>>>>>> >>>>>>> Title : OAuth 2.0 Token Exchange >>>>>>> Authors : Michael B. Jones >>>>>>> Anthony Nadalin >>>>>>> Brian Campbell >>>>>>> John Bradley >>>>>>> Chuck Mortimore >>>>>>> Filename : draft-ietf-oauth-token-exchange-07.txt >>>>>>> Pages : 31 >>>>>>> Date : 2017-01-11 >>>>>>> >>>>>>> Abstract: >>>>>>> This specification defines a protocol for an HTTP- and JSON- bas= ed >>>>>>> Security Token Service (STS) by defining how to request and obta= in >>>>>>> security tokens from OAuth 2.0 authorization servers, including >>>>>>> security tokens employing impersonation and delegation. >>>>>>> >>>>>>> >>>>>>> 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-07 >>>>>>> >>>>>>> A diff from the previous version is available at: >>>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-token-exchange= -07 >>>>>>> >>>>>>> >>>>>>> Please note that it may take a couple of minutes from the time of >>>>>>> submission >>>>>>> until the htmlized version and diff are available at tools.ietf.org= . >>>>>>> >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>> ... > > [Message clipped] --f403045c5052d5e3aa054f41ab4d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The token exchange framework facilitates deployments = like this one https://help.salesfor= ce.com/articleView?id=3Dremoteaccess_oauth_asset_token_flow.htm or https://developer.box.com/docs/getting-start= ed-with-new-box-view, for example, and I don't think pure plug= and play interoperability is a realistic goal. The framework promotes inte= roperability in the form of common patterns and parameters that can be supp= orted in libraries, products, and services.

There's not o= ne "other case" I have in mind but rather just broadening the tex= t somewhat to more straightforwardly accommodate other cases.=C2=A0 One pot= ential example is where the actor_token represents an authorizing party (ag= ain maybe needed for policy or auditing) to the token exchange event itself rather than the party that's having access rights assigne= d to it (implicitly with impersonation or explicitly with delegation).
=


On Tue, May 9, 2017 at 9:55 AM, Denis <denis.ietf@free.fr> wrote:
=20 =20 =20
Brian,

Even if Token Exchange is a framework, the goal is to be finally able to interoperate.

Whether we have one or two parameters, would you be able to provide a precise semantics for the "other case" you have i= n mind ?

Denis

Yes, I omitted your comments in that post because I'd previously replied to you in a separate message where I said that the "actor_token is a security token so that's not = an issue that needs to be addressed."=C2=A0 https://www.ietf.org/mail-archive/web/oauth/current/msg17247.ht= ml

The other point you've just made about having very precise semantics for a field is a fair one. However, I wanted to avoid introducing yet another field (or really two fields b/c of the associated *_type for each inbound token field), for what felt like a minor semantic variation that could be easily accommodated by the existing framework, to the draft that already has a lot of options and parameters on the request. And Token Exchange really is a framework. I think that, to some extent, the framework is a bit of a Rorschach test for deployers and implementers to utilize to solve their specific issues and needs. I expect that will be the case regardless. And I am proposing to somewhat genericize the text around one request parameter to be more reflective of that.

I would like to hear from others in the WG though.

On Tue, May 9, 2017 at 3:06 AM, Denis <denis.ietf@free.fr> wrote:
Brian,

You omitted to include my comments in this post. So here it is again:

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

The current text is:

actor_token OPTIONAL. A security token that represents the identity of the party that is authorized to use the requested security token and act on behalf of the subject.

This sentence is indeed wrong since an actor-token is not a security token.

So your proposed change does not solve this issue: actor_token=C2=A0 OPTIONAL.=C2=A0 A security token that represents the identity of the acting party.

The current text states:
Typically, in the request, the subject_token represents the identity of the party on behalf of whom
 the token is being requested while the actor_token represents the identity of the party to whom the access
rights of the issued token are being delegated.
Logically, the definition should be along the following lines:

=C2=A0actor_token OPTIONAL. Indic= ates the identity of the party to whom the access rights of the issued token are being delegated.

If there is no delegation, then this field (which is optional) will not be used.

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

I read your argumentation, but I maintain my comment. Each field should have a precise semantics.

If you want to have another semantics, you should propose to define another field with its precise meaning.

Denis

Let me throw out a bit more context about this. The "actor_token" might, in a delegation scenario, represent the identity of the party to whom the access rights of the issued token are being delegated. That's the typical delegation scenario that is discussed in the draft. However, the "actor_token" might als= o be utilized/needed by the AS in an impersonation scenario for policy or auditing reasons even when the resulting issued token doesn't contain info about the delegation or actor. Similarly, the actor might not be strictly doing the impersonation but rather just be a party (again maybe needed for policy or auditing) to the token exchange event itself.=C2=A0 When I wrote the "actor_token" text in section 2.1 some ~18 = months ago I had the delegation scenario at the front of my mind and (clearly) intended to accommodate it. However, I didn't intend to limit it to only that and, looking at the text again, I think what is there now is too prescriptive and narrow. Thus my proposing to generalize the text somewhat.




On Mon, May 8, 2017 at 10:29 AM, Brian Campbell <bcampbell@pingi= dentity.com> wrote:
I do have one minor issue I'd like to raise that relates to some conversations I've been a party to recently about implementations and applications of token exchange.

I think that the current text in =C2=A72.1 for the "actor_token" is overly spe= cific towards the delegation scenario. I'd propose the language be generalized somewhat to allow more versatility in applications/deployments of the token exchange framework. Here's that text:

=C2=A0=C2=A0 actor_token
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OPTIONAL.=C2= =A0 A security token that represents the identity of the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 acting party.= =C2=A0




On Mon, May 8, 2017 at 8:01 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Hi All,

The last email from Brian addresses the multiple audiences/resources issue with an error code, and we did not see any objection to this approach so far.


Authors,

Are there any other open issues with this draft?
Do you believe it is ready for WGLC?

Thanks,
=C2=A0Rifaat & Hannes



On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell <b= campbell@pingidentity.com> wrote:
As mentioned during the Chicago meeting the "invalid_target" = error code that was added in -07 was intended to give the AS a standard way to reject request with multiple audiences/resources that it doesn't understand o= r is unwilling or unable to process based on policy or whatever criteria . It was intended as a compromise, of sorts, to allow for the multiple resources/audiences in the request but provide an easy out for the AS of saying it can't be supported based on whatever implementation or security or policy it has.

On Tue, Mar 28, 2017 at 1:32 AM, Nat Sakimura <sakimura@= gmail.com> wrote:
Th= ere are cases where tokens are supposed to be consumed at multiple places and the `aud` needed to capture them. That's why `aud` is a multi-valued field.=C2=A0

= On Mon, Mar 27, 2017 at 11:35 AM Torsten Lodderstedt <torsten@lodderstedt.net= > wrote:
May I ask you to explain this reason?

Am 27.03.2017 um 08:48 schrieb Mike Jones <Michael.Jones@microsoft.c= om>:

For the same reason that the =E2=80=9Caud= =E2=80=9D claim is multi-valued in JWTs, the audience needs to stay multi-valued in Token Exchange.=C2=A0 Ditto for resources.=

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=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.o= rg] On Behalf Of Bri= an Campbell
Sent: Monday, March 27, 2017 8:45 AM
To: Torsten Lodderstedt <torsten@lodderstedt.net&g= t;
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-= token-exchange-07.txt

=C2=A0

Thanks for the review = and question, Torsten.

The desire to support = multiple audience/resource values in the request came up during a review and discussion among the authors of the document when preparing the -03 draft. As I recall, it was said that both Salesforce and Microsoft had use-cases for it. I incorporated support for it into the draft acting in the role of editor.

From an individual per= spective, I tend to agree with you that allowing for multiple audiences/resourc= es adds a lot of complexity that's like not needed in many (or most) cases. And I would personally be open to making audience and resource mutual exclusive and single valued. A question for the WG I suppose.

The "invalid_target" error code that was added in -07 was intended to= give the AS a standard way to deal with the complexity and reject request with multiple audiences/resourc= es that it doesn't understand or is unwilling or unable to process. It was intended as a compromise, of sorts, to allow for the multiples but provide an easy out of saying it can't be supported based on whatever implementation or policy of the AS.

=C2=A0

=C2=A0

=C2=A0

On Sun, Mar 26, 2017 at 9:00 AM, Torsten Lodderstedt <torsten@lodderstedt.net&g= t; wrote:

Hi Brian,

=C2=A0

thanks for the clarification around resource, audience and scope.=C2=A0

=C2=A0

Here are my comments on the draft:

=C2=A0

In section 2.1 it states: =E2=80=9EMultiple "resource&qu= ot; parameters may be used to indicate

=C2=A0 =C2=A0 =C2=A0 tha= t the issued token is intended to be used at the multiple

=C2=A0 =C2=A0 =C2=A0 res= ources listed.=E2=80=9C<= /p>

=C2=A0

Can you please explain the rational in more detail? I don=E2=80=99t understand why there is a need to ask for access tokens, which are good for multiple resources at once. This is a request type more or less exclusively used in server to server scenarios, right? So the only reason I can think of is call reduction.=C2=A0<= /p>

=C2=A0

On the other side, this feature increases the AS's complexity, e.g. its policy may prohibit to issue tokens for multiple resources in general or the particular set the client is asking for. How shall the AS handles such cases?

=C2=A0

And it is getting even more complicated given there could also be multiple audience values and the client could mix them:=C2=A0

=C2=A0

"Multiple "audience&qu= ot; parameters

=C2=A0 =C2=A0 =C2=A0 may= be used to indicate that the issued token is intended to be

=C2=A0 =C2=A0 =C2=A0 use= d at the multiple audiences listed.=C2=A0 The "audience&qu= ot; and

=C2=A0 =C2=A0 =C2=A0 &qu= ot;resource" parameters may be used together to indicate multiple

=C2=A0 =C2=A0 =C2=A0 tar= get services with a mix of logical names and physical

=C2=A0 =C2=A0 =C2=A0 locations.=E2=80= =9C

=C2=A0

And in the end the client may add some scope values to the =E2=80=9Emeal=E2= =80=9C, which brings us to=C2= =A0

=C2=A0

=E2=80=9EEffectively, the requested access rights of the

=C2=A0 =C2=A0token are t= he cartesian product of all the scopes at all the target

=C2=A0 =C2=A0services.&q= uot;

=C2=A0

I personally would suggest to drop support for multiple audience and resource parameters and make audience and resource mutual exclusive. I think this is sufficient and much easier to implement.

=C2=A0

kind regards,

Torsten.

=C2=A0

=C2=A0

Am 11.01.2017 um 20:04 schrieb Brian Campbell <bcampbell@pingidentity.com= >:

=C2=A0

Draft -07 of "OAu= th 2.0 Token Exchange" has been published. The primary change in -07 is the addition of a description of the relationship between audience/resource= /scope, which was a request or comment that came up during the f2f meeting in Seoul.

Excerpted from the Document History:

=C2=A0=C2=A0 -07<= br class=3D"m_8684407748554078058m_6905276776273010841m_4803735329627533709= m_-2675142197049852080m_3983298834558915277m_-4354184635220679769gmail_msg"= >
=C2=A0=C2=A0 o=C2= =A0 Fixed typo (desecration -> discretion).
=C2=A0=C2=A0 o=C2= =A0 Added an explanation of the relationship between scope, audience
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 and resource in the request and added an "invalid_tar= get" error
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 code enabling the AS to tell the client that the requested
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 audiences/resourc= es were too broad.

---------- Forwarded message ----------
From: <internet-drafts@ietf.o= rg>
Date: Wed, Jan 11, 2017 at 12:00 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-= token-exchange-07.txt
To: i-d-announce@ietf.org
Cc: oauth@ietf.org



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

=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0: OAuth 2.0 Token Exchange =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Authors=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0: Michael B= . Jones
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Anthony Nadalin
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Brian Campbell =C2=A0 =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 Chuck Mortimore
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Filename=C2=A0 = =C2=A0 =C2=A0 =C2=A0 : draft-ietf-oauth-= token-exchange-07.txt
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0: 31
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 : 2017-01-11

Abstract:
=C2=A0 =C2=A0This specification defines a protocol for an HTTP- and JSON- based
=C2=A0 =C2=A0Secu= rity Token Service (STS) by defining how to request and obtain
=C2=A0 =C2=A0secu= rity tokens from OAuth 2.0 authorization servers, including
=C2=A0 =C2=A0secu= rity tokens employing impersonation and delegation.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchang= e/

There's also = a htmlized version available at:
h= ttps://tools.ietf.org/html/draft-ietf-oauth-token-exchange-07=
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-token-exc<= wbr>hange-07


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

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

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

=C2=A0

_______________________________________________<= br class=3D"m_8684407748554078058m_6905276776273010841m_4803735329627533709= m_-2675142197049852080m_3983298834558915277m_-4354184635220679769gmail_msg"= > OAuth mailing list
OAuth@ietf.org
https://www.ietf.org= /mailman/listinfo/oauth

=C2=A0

=C2=A0


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

[Message clip= ped]=C2=A0=C2=A0

--f403045c5052d5e3aa054f41ab4d-- From nobody Fri May 12 01:08:59 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2669D12704B for ; Fri, 12 May 2017 01:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSPFeayCOpWB for ; Fri, 12 May 2017 01:08:47 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85E4B12871F for ; Fri, 12 May 2017 01:03:29 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id l18so57335993oig.2 for ; Fri, 12 May 2017 01:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=wUh1j6EuFqWpS7u28DmmHlrccW3TtTrlF+Ocn5WIjrA=; b=SWKJJsG24Z4B4BSf+2HmN5XkI+AAceqq9Zns/Pkk31+MzLqbRUqTwA913mYVlV3Wul z25Zn/ZM5qq/Mv75XhzdQwktYtKYLVMNs7+PAz/ZVh3uqlwVyriSGrVCJR5ps9VOSmQ0 BHq9sKfD6YHtLS1LfKxzol9zR+WBU14BDhR3j1mMav39//u8vzZGq1qPOEwvogRgxkS4 6wh/WVa9mtBBtHVxQaGVQ64lnnCl5SioYxtmtze5YbUJBpuFabos01HM42S6hDSUkFea jt+0397pr/cO5bs0+/vipSvR5qqVcw6X7so8lW6xCkZEriz3Epal9evYdfUlzF97GlTd FPng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=wUh1j6EuFqWpS7u28DmmHlrccW3TtTrlF+Ocn5WIjrA=; b=Vx1x1qPBLKeBoYmr6/5VaHw02M1gUrVda2Jtm2/95MjLTVDcGbR0klYqiQ+H79Up6U kdJtREMM8IdkCVBSkyz3QP2L6mQc73/R7O7tjcf59wRhjOlAEk+od7YRisXaqS0F6BH5 eGJTRO6QQ6Izx9SSKBLXbf6lkmfz83nOfDhittcLFBa4xbHRNswcgCYms0QhKg/yw8gr GDVLqgV2vQWcioIcXmlTKeCLUp+DQbXai+WNDdLiKtrY2RISwffT60/MbSK/aQGCiQyU TjvtkuloWjI2YLGBCbq/nPxM93g3sDGqstcc35q6KCNt7+v5djBhB7JWMiK6fq5q4dze U3GA== X-Gm-Message-State: AODbwcC8c7hLtOSVhGXMoU4nFHwQMTQkV5u9KGhB8QzzlR2Bs9QRPRem F3CtgNne1u+3wXZFyjVRqfkFKDasZw== X-Received: by 10.202.190.85 with SMTP id o82mr1116584oif.19.1494576208511; Fri, 12 May 2017 01:03:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.42.193 with HTTP; Fri, 12 May 2017 01:03:28 -0700 (PDT) From: Samuel Erdtman Date: Fri, 12 May 2017 10:03:28 +0200 Message-ID: To: "" , ace Content-Type: multipart/alternative; boundary="001a113d6758ff9d1b054f4f2386" Archived-At: Subject: [OAUTH-WG] New OAuth client credentials RPK and PSK X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 08:08:51 -0000 --001a113d6758ff9d1b054f4f2386 Content-Type: text/plain; charset="UTF-8" Hi ACE and OAuth WGs, I and Ludwig submitted a new draft yesterday defining how to use Raw Public Key and Pre Shared Key with (D)TLS as OAuth client credentials, https://datatracker.ietf.org/doc/draft-erdtman-ace-rpcc/. We think this is valuable to the ACE work since the ACE framework is based on OAuth, but client credentials as defined in the OAuth framework are not the best match for embedded devices. We think Raw Public Keys and Pre Shared Keys are more suitable credentials for embedded devices for the following reasons: * Better security by binding to transport layer. * If PSK DTLS is to be used a key need to be distributed any way, why not make use of it as credential. * Client id and client secret accommodates for manual input by a humans. This does not scale well and requires some for of input device. * Some/many devices will have crypto-hardware that can protect key material, to not use that possibility would be a waste. * There are probably more reasons these was just the once on top of my head. This is not the first resent initiative to create new client credential types, the OAuth WG adopted a similar draft for certificate based client credentials (https://tools.ietf.org/html/draft-ietf-oauth-mtls-00.html). That work is also valuable to ACE but not all devices will be able to work with certificates or even asymmetric cryptos . Please review and comment. Cheers //Samuel --001a113d6758ff9d1b054f4f2386 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi ACE and OAuth WGs,

I and Lu= dwig submitted a new draft yesterday defining how to use Raw Public Key and= Pre Shared Key with (D)TLS as OAuth client credentials, https://datatracker.ietf= .org/doc/draft-erdtman-ace-rpcc/.

We think this= is valuable to the ACE work since the ACE framework is based on OAuth, but= client credentials as defined in the OAuth framework are not the best matc= h for embedded devices.

We think Raw Public Keys and Pre = Shared Keys are more suitable credentials for embedded devices for the foll= owing reasons:
* Better security by binding to transport laye= r.
* If PSK DTLS is to be used a key need to be distributed a= ny way, why not make use of it as credential.
* Client id and= client secret accommodates for manual input by a humans. This does not sca= le well and requires some for of input device.
* Some/many de= vices will have crypto-hardware that can protect key material, to not use t= hat possibility would be a waste.
* There are probably more r= easons these was just the once on top of my head.

<= div>This is not the first resent initiative to create new client credential= types, the OAuth WG adopted a similar draft for certificate based client c= redentials (https://tools.ietf.org/html/draft-ietf-oauth-mtls-00.html). That= work is also valuable to ACE but not all devices will be able to work with= certificates or even asymmetric cryptos .

Please review = and comment.

Cheers
//Samuel
=

--001a113d6758ff9d1b054f4f2386-- From nobody Sat May 13 03:00:23 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4EA12955A; Sat, 13 May 2017 03:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.279 X-Spam-Level: * X-Spam-Status: No, score=1.279 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqcPHygGsH_s; Sat, 13 May 2017 03:00:11 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACDEF1293DF; Sat, 13 May 2017 02:58:04 -0700 (PDT) Received: from [80.187.102.33] (helo=[10.155.159.117]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1d9ToH-0007sD-TK; Sat, 13 May 2017 11:58:02 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-EE7126E8-91EF-4095-9A38-5C1A7E7C509E; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPhone Mail (14E304) In-Reply-To: Date: Sat, 13 May 2017 11:58:01 +0200 Cc: "" , ace Content-Transfer-Encoding: 7bit Message-Id: <22C1AD59-1B76-4596-AAFB-2CF1770FA58B@lodderstedt.net> References: To: Samuel Erdtman X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] New OAuth client credentials RPK and PSK X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 10:00:14 -0000 --Apple-Mail-EE7126E8-91EF-4095-9A38-5C1A7E7C509E Content-Type: multipart/alternative; boundary=Apple-Mail-768C5DE9-09D7-4D5E-AED8-A00E4F601F98 Content-Transfer-Encoding: 7bit --Apple-Mail-768C5DE9-09D7-4D5E-AED8-A00E4F601F98 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Samuel, as far as I understand your draft, it utilizes results of the (D)TLS client a= uthentication for authentication towards the tokens endpoint - similar to ht= tps://tools.ietf.org/html/draft-ietf-oauth-mtls-00.html. Do you intend to al= so utilize the binding of the access token to a certain key pair as describe= d in oauth-ietf-mtls? best regards, Torsten. > Am 12.05.2017 um 10:03 schrieb Samuel Erdtman : >=20 > Hi ACE and OAuth WGs, >=20 > I and Ludwig submitted a new draft yesterday defining how to use Raw Publi= c Key and Pre Shared Key with (D)TLS as OAuth client credentials, https://da= tatracker.ietf.org/doc/draft-erdtman-ace-rpcc/. >=20 > We think this is valuable to the ACE work since the ACE framework is based= on OAuth, but client credentials as defined in the OAuth framework are not t= he best match for embedded devices. >=20 > We think Raw Public Keys and Pre Shared Keys are more suitable credentials= for embedded devices for the following reasons: > * Better security by binding to transport layer. > * If PSK DTLS is to be used a key need to be distributed any way, why not m= ake use of it as credential. > * Client id and client secret accommodates for manual input by a humans. T= his does not scale well and requires some for of input device. > * Some/many devices will have crypto-hardware that can protect key materia= l, to not use that possibility would be a waste. > * There are probably more reasons these was just the once on top of my hea= d. >=20 > This is not the first resent initiative to create new client credential ty= pes, the OAuth WG adopted a similar draft for certificate based client crede= ntials (https://tools.ietf.org/html/draft-ietf-oauth-mtls-00.html). That wor= k is also valuable to ACE but not all devices will be able to work with cert= ificates or even asymmetric cryptos . >=20 > Please review and comment. >=20 > Cheers > //Samuel >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-768C5DE9-09D7-4D5E-AED8-A00E4F601F98 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Samuel,
 --94eb2c1486b65eb8ff05501e2bfa-- From nobody Mon May 22 09:05:08 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D764612EB0F; Mon, 22 May 2017 09:05:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-oauth-native-apps@ietf.org, Hannes Tschofenig , oauth-chairs@ietf.org, Hannes.Tschofenig@gmx.net, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149546910687.10043.16893686894193706023.idtracker@ietfa.amsl.com> Date: Mon, 22 May 2017 09:05:06 -0700 Archived-At: Subject: [OAUTH-WG] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-oauth-native-apps-11=3A_=28with_COMMENT=29?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 16:05:07 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-oauth-native-apps-11: 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-native-apps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Quick question just to double-check: should this document update RFC6749? From nobody Mon May 22 12:09:02 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749E0128B91 for ; Mon, 22 May 2017 12:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKHbbn07txMh for ; Mon, 22 May 2017 12:08:58 -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 EECA2128616 for ; Mon, 22 May 2017 12:08:57 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id f102so87068704ioi.2 for ; Mon, 22 May 2017 12:08:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qxMxstGIbPVZ8QVipkgAGfsdWIIQHnlpSxYnHq/FX9A=; b=jNTFoWUaszqYLLQvtpFwvnJaHfLnK4kIPDjt+fOU/cU+guO3jj656RhIoZZUTULW9o DK51h0x4pP9zfLHVSpA+pxH3HPyKBt5XiWdqm+Qxo9ySa/Vo8bX1hP3Qd7Sw4mItgOaV uyupFlGemKMsqnKUVebp5IyyYol279ZT2a1SXnQAjxng9KPgoj9pgu4+91Rw5bj/Vjdz 4VaDrIQNNTyHkXai6d87gOcbQNffCUu1fhavazMq0z2PhZ5P8qlDJ7fJQhGQExceStca rxsfJQxLfkaxTiBJWCCK4ESW5Cu2tjN3vp+bAPmcFxpbAZHzcajgd97FXYT5rnSnpWGt ZNLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qxMxstGIbPVZ8QVipkgAGfsdWIIQHnlpSxYnHq/FX9A=; b=BAJK2nsF+p/SlKw0IMvSLczMUTcu2Jw/0SK06shPKAlZZ3V2/QvVHk82tLeEk5HPQ1 jzNjg9cL0YuR91905/Eq7+5mvRuLUT0fQSRoaxAnIWIW1ccOy4xR7B7VZ3IzBRjX6A1V 8BpW+Axw4o4KJxZIsNiEJ137WNrBeqUVHRu5ZtTEwlT3qmyXEGdeAU4khDHJA+aQHa1D yaAQ4Aln4d9DSTCkGA8h2CPpIHvVV9NuoxxnCSXmFyz3NN8XEl0M3/IPxLFJVf4l/KYg 55p5i/s/kZfFJhUYRB7TZWu0oHEFBgbzuQcX0Vcpg5aBRKWfBfc/et5Vp6FJD5p8mo0B tQDQ== X-Gm-Message-State: AODbwcBv+3Tjd1gL16DsNnOw2bBSQDz8hhkR9qgLa1ngRKxXUTZ4T7En GDFxuO3G6dnSGsAax4EUU3aZoliHIoKa2lk= X-Received: by 10.107.6.27 with SMTP id 27mr23657527iog.53.1495480137083; Mon, 22 May 2017 12:08:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.35.37 with HTTP; Mon, 22 May 2017 12:08:36 -0700 (PDT) In-Reply-To: References: From: William Denniss Date: Mon, 22 May 2017 12:08:36 -0700 Message-ID: To: wangzitao Cc: "ops-dir@ietf.org" , "oauth@ietf.org" , "draft-ietf-oauth-native-apps.all@ietf.org" , "ietf@ietf.org" Content-Type: multipart/alternative; boundary="001a113ee7d25754640550219a2a" Archived-At: Subject: Re: [OAUTH-WG] [OPS-DIR] Opsdir telechat review of draft-ietf-oauth-native-apps-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 19:09:01 -0000 --001a113ee7d25754640550219a2a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for your review Zitao! Version 12 addresses your comments. Detailed responses below: On Sun, May 21, 2017 at 8:05 PM, wangzitao wrote: > Reviewer: Zitao Wang (Michael) > > Review result: Has Nits > > > > I have reviewed this document as part of the Operational > directorate=E2=80=99s ongoing effort to review all IETF documents being p= rocessed > by the IESG. These comments were written with the intent of improving th= e > operational aspects of the IETF drafts. Comments that are not addressed i= n > last call may be included in AD reviews during the IESG review. Document > editors and WG chairs should treat these comments just like any other las= t > call comments. > > > > Document reviewed: draft-ietf-oauth-native-apps-10 > > > > Summary: > > > > OAuth 2.0 authorization requests from native apps should only be made > > through external user-agents, primarily the user=E2=80=99s browser. This > > specification details the security and usability reasons why this is > > the case, and how native apps and authorization servers can implement > > this best practice. > > > > I think the document is written very clear, except some small nits: > > Page 3: The last sentence of introduction-- =E2=80=9CThis practice is= also > known as the AppAuth pattern=E2=80=9D. > > I suggest adding a reference to explain the AppAuth pattern. > > Done > Page 3: Terminology -- "OAuth". > > I suggest modifying to: "OAuth" The Web Authorization (OAuth) protocol. > In this document, OAuth refers to OAuth 2.0 [RFC6749]. > I went with: "In this document, OAuth refers to the OAuth 2.0 Authorization Framework [RFC6749]." The phrase "Web Authorization (OAuth) protocol" only seems to appear in our WG Charter, and not general usage . > Page 4: Terminology -- "web-view" A web browser UI component. > > Does it mean "User Information"? Suggest expanding this abbreviation. > > Done. > Page 5: Figure 1. Does the browser and authorization endpoint are > some kinds of "external user-agent"? Suggest describing it more clearly. > Now states: "illustrates the interaction of the native app with a browser external user-agent to authorize the user. " Page 9: PKCE [RFC7636] details how this limitation can be used to > execute a code interception attack (see Figure 1). > > Does the Figure 1 means =E2=80=9CFigure 1 of RFC7636=E2=80=9D? > Good catch. I delete the figure reference, since the entire spec talks about this attack, which is likely sufficient. > > Page10: However, as the Implicit Flow cannot be protected by PKCE > > Seems here, the reference be omitted. > Added. > A run of idnits revealed no errors, flaws. There were 1 warning and 1 com= ments though > > > > =3D=3D There are 1 instance of lines with non-RFC2606-compliant FQDNs i= n the > > document. > > > > I ran it myself with verbose output, and got: tmp/draft-ietf-oauth-native-apps__1_.txt(435): Found possible FQDN 'com.example.app' in position 5; this doesn't match RFC 2606's suggested ".example" or ".example.(com|org|net)". We are actually using a RFC2606 domain name here, but in reverse domain name notation which is causing this warning. No changes required. > Miscellaneous warnings: > > -----------------------------------------------------------------------= ----- > > > > -- The document date (April 26, 2017) is 14 days in the past. Is this > > intentional? > > > > > > Checking references for intended status: Best Current Practice > > -----------------------------------------------------------------------= ----- > > > > (See RFCs 3967 and 4897 for information about using normative refere= nces > > to lower-maturity documents in RFCs) > > > > No issues found here. > > > > Summary: 0 errors (**), 0 flaws (~~), 1 warning (=3D=3D), 1 comment = (--). > > > > > > _______________________________________________ > > OPS-DIR mailing list > > OPS-DIR@ietf.org > > https://www.ietf.org/mailman/listinfo/ops-dir > > > --001a113ee7d25754640550219a2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

as far as I understand your draft, it utilizes results of the (D)TL= S client authentication for authentication towards the tokens endpoint - sim= ilar to https://tools.ietf.org/html/draft-ietf-oauth-mtls-00.html. Do you= intend to also utilize the binding of the access token to a certain key pai= r as described in oauth-ietf-mtls?

best regards,
Torsten.

Am 12.05.2017 um 10:03 schrieb Samuel Erdtman= <samuel@erdtman.se>:

=
Hi ACE a= nd OAuth WGs,

I and Ludwig submitted a new draft yesterday defi= ning how to use Raw Public Key and Pre Shared Key with (D)TLS as OAuth clien= t credentials, https://datatracker.ietf.org/doc/draft-erdtman-ace-rpcc/.

We think this is valuable to the ACE work since the ACE fr= amework is based on OAuth, but client credentials as defined in the OAuth fr= amework are not the best match for embedded devices.

We th= ink Raw Public Keys and Pre Shared Keys are more suitable credentials for em= bedded devices for the following reasons:
* Better security by= binding to transport layer.
* If PSK DTLS is to be used a key= need to be distributed any way, why not make use of it as credential.
* Client id and client secret accommodates for manual input by a hu= mans. This does not scale well and requires some for of input device.
* Some/many devices will have crypto-hardware that can protect key m= aterial, to not use that possibility would be a waste.
* There= are probably more reasons these was just the once on top of my head.

This is not the first resent initiative to create new= client credential types, the OAuth WG adopted a similar draft for certifica= te based client credentials (https://tools.ietf.org/html/draft-ietf-oauth-mtls-00.= html). That work is also valuable to ACE but not all devices will be abl= e to work with certificates or even asymmetric cryptos .

P= lease review and comment.

Cheers
//Samuel


____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-768C5DE9-09D7-4D5E-AED8-A00E4F601F98-- --Apple-Mail-EE7126E8-91EF-4095-9A38-5C1A7E7C509E Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSTCCBUUw ggQtoAMCAQICEDPbmsaqwjeZa3PxA3uZ8LQwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNzAxMDkwMDAwMDBaFw0xODAxMDkyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEArsGSzZyz9Lq9SRW9Sve5K8n5lWhplOCE6HH3gMye12DjOpkF FZt0b73t27G17Xsp6WUxHhNevf7ck0AUpvYUPCHBqVGJSIWF9hWAoSFCgQACOoh/cDFbzz1PsMY8 El7OmIus4JXtY4/VdoSIhFP3hzATbNAg32Kp+N8vtTuKTwbgnizJSyzZTYrsttn3LmwY17HU+U9v XloMus5U/ln4ADZx0zyyDSsA6gtPxXYJpbgSTnHckVZ5zfR80guIZ538Y2qqsqt5VaSRSR2oQzE/ HETkKc/odPVhqBrXLyvnSFkCPrAXV07rcvwkPvHZeYVu4QdVWyO2HIQ4i2x9r5m7SwIDAQABo4IB 9TCCAfEwHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFPngHgVxOZ7G Sji/IW4YJMBj02PHMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEE AbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwXQYD VR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50 QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAwWAYI KwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhl bnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNv bW9kb2NhLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0B AQsFAAOCAQEAAmueyHjiyL1qYgfe+hVSsGuKlgcvjCAfG8Jaq48tC0IjP8pH/tGi4uL9CHVfLnV3 pLDnjg6M2uvpEBp7crZZcnSPLeVss+tkhwv+F7ISYQyT4flNkqVUb8nfewbCPcIN13ObfpU7rlXo IarEEplQo4SuymYVluQxTLOFKm5QOMF4JBMw/rjy4t95J7Mdp9NFUzQrKPJDaJ2Jr/TcTXFcjLvN VmMBjK0959a9v1/1miRHd1DBsTh1KvBigEOUNMxvT5uUtB6/tioDZqBDDk8Gvdno/xmye3YiasS7 JgMREq5WcXqpWGu5kMFZMGPEvyPHeBZeqxx3amf4ImVnZ6WvgzGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDPbmsaqwjeZa3PxA3uZ8LQw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTcwNTEzMDk1ODAxWjAjBgkqhkiG9w0BCQQxFgQUYOEC6XrZA/dpTQeAFfq0ljlifFAwgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAz25rGqsI3mWtz8QN7mfC0MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEB AQUABIIBAHQ40c3DyWzr6dE3lOhaZAb9gtBqDWYfr7u+4bSTutxl58xdnrFClL7+94fNHPM35YfQ 51juPP1qMokJqNUaWeeqtzpdPZer/8FvlF3eXRXAPQziVa5EJgH9nEMwYx9I1VNoz3jlN1Y2qAy5 dEuifBJQLXrQvEhAXXF6kvhGUv+Xm70DhYpvbpYg+bAF2Y2Gbalhu0FgeSR/RU3GKkGsLOX+e8I2 GowyaqiVRFyxzmskyeHZc+DNWRoiNS/RCaf5/98oGBUJPpDaMJG2iXfwjL2MRu7kg+QcYk1cc+N5 8DVknkpX6G/QDrloUlRgCae/XyU+2fZBYFnUekXtjdA9UD0AAAAAAAA= --Apple-Mail-EE7126E8-91EF-4095-9A38-5C1A7E7C509E-- From nobody Sat May 13 03:07:49 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C403C129494 for ; Sat, 13 May 2017 03:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMBo9cRIr7Hb for ; Sat, 13 May 2017 03:07:44 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.39]) (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 A3333129B0F for ; Sat, 13 May 2017 03:05:39 -0700 (PDT) Received: from [80.187.102.33] (helo=[10.155.159.117]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1d9Tvd-0003A2-0F; Sat, 13 May 2017 12:05:37 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-D582D64D-F9F5-4337-8109-B2F6F12145CD; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPhone Mail (14E304) In-Reply-To: Date: Sat, 13 May 2017 12:05:36 +0200 Cc: OAuth WG Content-Transfer-Encoding: 7bit Message-Id: <18AE7BC9-1EAE-4012-BD38-94412328EBCD@lodderstedt.net> References: <90C41DD21FB7C64BB94121FBBC2E723453A754C534@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: =?utf-8?Q?Andr=C3=A9_DeMarre?= X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Phishing with Client Application Name Spoofing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 10:07:48 -0000 --Apple-Mail-D582D64D-F9F5-4337-8109-B2F6F12145CD Content-Type: multipart/alternative; boundary=Apple-Mail-F8DC5663-47F2-481C-9F67-293EB32E0056 Content-Transfer-Encoding: 7bit --Apple-Mail-F8DC5663-47F2-481C-9F67-293EB32E0056 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable two days can last for a very long time ;-) I will add this threat to the lis= t to be covered by our new security draft. > Am 10.05.2017 um 23:15 schrieb Andr=C3=A9 DeMarre = : >=20 > I see there is a new security considerations document being drafted. There= is an old issue that I've recently been reminded of. >=20 > Should text about phishing conducted through the authorization dialog be a= dded to the new security document? This kind of attack made headlines last w= eek with a widespread Gmail / Google Docs phishing worm (https://security.go= ogleblog.com/2017/05/protecting-you-against-phishing.html). >=20 > Five years ago, I was encouraged to propose text about this for the Threat= Model and Security Considerations document, but I never did; sorry. Origina= l thread in the mail archive: https://www.ietf.org/mail-archive/web/oauth/cu= rrent/msg07625.html >=20 > This concerns both authorization dialog design and client registration, an= d as far as I know it's not really covered in any published documents. I'm n= ot entirely sure what mitigations should be recommended, but I think authori= zation server implementers need to be more cognizant of this attack. >=20 > Regards, > Andre DeMarre >=20 >> On Tue, Jan 17, 2012 at 4:06 AM, Mark Mcgloin w= rote: >> Andre >>=20 >> Please feel free to propose text, perhaps with a better title than I >> suggested. During our discussion on section 4.1.4 (End-user credentials >> phished using compromised or embedded browser), we have decided on the >> countermeasure below, albeit for a different threat - phishing client as >> opposed to client name spoofing. Your's can be a variant of this with >> different validation recommendations. >>=20 >>=20 >> 2. Client applications could be validated prior to publication in an >> application market for users to access. That validation is out of scope f= or >> OAuth but could include validating that the client application handles us= er >> authentication in an appropriate way >>=20 >>=20 >> Regards >> Mark >>=20 >> Andr=C3=A9 DeMarre wrote on 16/01/2012 23:20:02:= >>=20 >> > >> > To: >> > >> > Eran Hammer 16/01/2012 23:22 >> > >>=20 >> > >> > Re: [OAUTH-WG] Phishing with Client Application Name Spoofing >> > >> > Eran, >> > >> > Yes; I think a section should be added to the security model doc. >> > >> > On 2011-12-16 Mark Mcgloin agreed and suggested we call it "Client >> > Registration of phishing clients": >> > http://www.ietf.org/mail-archive/web/oauth/current/msg08061.html >> > >> > I'm happy to propose the text; it might be one or two days though. >> > >> > Regards, >> > Andre DeMarre >> > >> > On Mon, Jan 16, 2012 at 10:30 AM, Eran Hammer >> wrote: >> > > Should this be added to the security model document? Is it already >> > addressed there? >> > > >> > > EHL >> > > >> > >> -----Original Message----- >> > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Beha= lf >> > >> Of Andr=C3=A9 DeMarre >> > >> Sent: Tuesday, October 04, 2011 11:33 AM >> > >> To: OAuth WG >> > >> Subject: [OAUTH-WG] Phishing with Client Application Name Spoofing >> > >> >> > >> I've not seen this particular variant of phishing and client >> impersonation >> > >> discussed. A cursory search revealed that most of the related >> discussion >> > >> centers around either (a) client impersonation with stolen client >> > credentials >> > >> or (b) phishing by malicious clients directing resource owners to >> spoofed >> > >> authorization servers. This is different. >> > >> >> > >> This attack exploits the trust a resource owner has for an OAuth >> > >> authorization server so as to lend repute to a malicious client >> > pretending to >> > >> be from a trustworthy source. This is not necessarily a direct >> > vulnerability of >> > >> OAuth; rather, it shows that authorization servers have a >> responsibility >> > >> regarding client application names and how they present resource >> owners >> > >> with the option to allow or deny authorization. >> > >> >> > >> A key to this exploit is the process of client registration with >> > the authorization >> > >> server. A malicious client developer registers his client >> > application with a >> > >> name that appears to represent a legitimate organization which >> resource >> > >> owners are likely to trust. Resource owners at the authorization >> endpoint >> > >> may be misled into granting authorization when they see the >> authorization >> > >> server asserting " is requesting permission >> to..." >> > >> >> > >> Imagine someone registers a client application with an OAuth service= , >> let's >> > >> call it Foobar, and he names his client app "Google, Inc.". The Foob= ar >> > >> authorization server will engage the user with "Google, Inc. is >> requesting >> > >> permission to do the following." The resource owner might reason, "I= >> see >> > >> that I'm legitimately on the https://www.foobar.com site, and Foobar= >> is >> > >> telling me that Google wants permission. I trust Foobar and Google, s= o >> I'll >> > >> click Allow." >> > >> >> > >> To make the masquerade act even more convincing, many of the most >> > >> popular OAuth services allow app developers to upload images which >> could >> > >> be official logos of the organizations they are posing as. Often app= >> > >> developers can supply arbitrary, unconfirmed URIs which are shown to= >> the >> > >> resource owner as the app's website, even if the domain does not mat= ch >> the >> > >> redirect URI. Some OAuth services blindly entrust client apps to >> customize >> > >> the authorization page in other ways. >> > >> >> > >> This is hard to defend against. Authorization server administrators >> could >> > >> police client names, but that approach gives them a burden similar t= o >> > >> certificate authorities to verify organizations before issuing >> > certificates. Very >> > >> expensive. >> > >> >> > >> A much simpler solution is for authorization servers to be >> > careful with their >> > >> wording and educate resource owners about the need for discretion wh= en >> > >> granting authority. Foobar's message above could be >> > >> changed: "An application calling itself Google, Inc. is >> > requesting permission to >> > >> do the following" later adding, "Only allow this request if you >> > are sure of the >> > >> application's source." Such wording is less likely to give the >> > impression that >> > >> the resource server is vouching for the application's identity. >> > >> >> > >> Authorization servers would also do well to show the resource owner >> > >> additional information about the client application to help them mak= e >> > >> informed decisions. For example, it could display all or part of the= >> app's >> > >> redirect URI, saying, "The application is operating on >> > example.com" or "If you >> > >> decide to allow this application, your browser will be directed to >> > >> http://www.example.com/." Further, if the client app's redirect >> > URI uses TLS >> > >> (something authorization servers might choose to mandate), then auth= >> > >> servers can verify the certificate and show the certified >> > organization name to >> > >> resource owners. >> > >> >> > >> This attack is possible with OAuth 1, but OAuth 2 makes successful >> > >> exploitation easier. OAuth 1 required the client to obtain temporary= >> > >> credentials (aka access tokens) before sending resource owners to th= e >> > >> authorization endpoint. Now with OAuth 2, this attack does not requi= re >> > >> resource owners to interact with the client application before >> visiting the >> > >> authorization server. The malicious client developer only needs >> > to distribute >> > >> links around the web to the authorization server's authorization >> > endpoint. If >> > >> the HTTP service is a social platform, the client app might >> > distribute links using >> > >> resource owners' accounts with the access tokens it has acquired, >> becoming >> > >> a sort of worm. Continuing the Google/Foobar example above, it might= >> use >> > >> anchor text such as "I used Google Plus to synchronize with my Fooba= r >> > >> account." Moreover, if the app's redirect URI bounces the resource >> owner >> > >> back to the HTTP service after acquiring an authorization code, >> > the victim will >> > >> never see a page rendered at the insidious app's domain. >> > >> >> > >> This is especially dangerous because the public is not trained to >> defend >> > >> against it. Savvy users are (arguably) getting better at >> > protecting themselves >> > >> from traditional phishing by verifying the domain in the address bar= , >> and >> > >> perhaps checking TLS certificates, but such defenses are irrelevent >> here. >> > >> Resource owners now need to verify not only that they are on the >> legitimate >> > >> authorization server, but to consider the trustworthyness of the lin= k >> that >> > >> referred them there. >> > >> >> > >> I'm not sure what can or should be done, but I think it's important >> for >> > >> authorization server implementers to be aware of this attack. If >> > >> administrators are not able to authenticate client organizations,the= n >> they >> > >> are shifting this burden to resource owners. They should do all they= >> can to >> > >> educate resource owners and help them make informed decisions before= >> > >> granting authorization. >> > >> >> > >> Regards, >> > >> Andre DeMarre >> > >> _______________________________________________ >> > >> 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-F8DC5663-47F2-481C-9F67-293EB32E0056 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
two days can last for a ver= y long time ;-) I will add this threat to the list to be covered by our new s= ecurity draft.

Am 10.05.2017 um 23:15 schrieb Andr=C3=A9 DeMar= re <andredemarre@gmail.com&= gt;:

I see there is a new security cons= iderations document being drafted. There is an old issue that I've recently b= een reminded of.

Should t= ext about phishing conducted through the authorization dialog be added to th= e new security document? This kind of attack made headlines last week with a= widespread Gmail / Google Docs phishing worm (https://security.googleblog.com/2017/05/protecting-you-against-p= hishing.html).

Five years ago, I was encouraged to p= ropose text about this for the Threat Model and Security Considerations docu= ment, but I never did; sorry. Original thread in the mail archive: https://www.ietf.org/mail-archive/web/oauth/current/msg07625.html

This concerns both authorization dialog desi= gn and client registration, and as far as I know it's not really covered in a= ny published documents. I'm not entirely sure what mitigations should be rec= ommended, but I think authorization server implementers need to be more cogn= izant of this attack.

Regards,
Andre= DeMarre

On Tue= , Jan 17, 2012 at 4:06 AM, Mark Mcgloin <mark.mcgloin@ie.ibm.com&g= t; wrote:
Andre
Please feel free to propose text, perhaps with a better title than I
suggested. During our discussion on section 4.1.4 (End-user credentials
phished using compromised or  embedded browser), we have decided on the=
countermeasure below, albeit for a different threat - phishing client as
= opposed to client name spoofing. Your's can be a variant of this with
different validation recommendations.


2. Client applications could be validated prior to publication in an
application market for users to access. That validation is out of scope for<= br> OAuth but could include validating that the client application handles user<= br> authentication in an appropriate way


Regards
Mark

Andr=C3=A9 DeMarre <andredemarre@gmail.com> wrote on 16/01/2012 23:20:02:

>
> To:
>
> Eran Hammer <eran@hueniverse.com> 16/01/2012 23:22
>

>
> Re: [OAUTH-WG] Phishing with Client Application Name Spoofing
>
> Eran,
>
> Yes; I think a section should be added to the security model doc.
>
> On 2011-12-16 Mark Mcgloin agreed and suggested we call it "Client
> Registration of phishing clients":
> http://www.ietf.org/mail-archive/web/oauth/current/msg08061.html
>
> I'm happy to propose the text; it might be one or two days though.
>
> Regards,
> Andre DeMarre
>
> On Mon, Jan 16, 2012 at 10:30 AM, Eran Hammer <eran@hueniverse.com>
wrote:
> > Should this be added to the security model document? Is it already=
> addressed there?
> >
> > EHL
> >
> >> -----Original Message-----
> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> >> Of Andr=C3=A9 DeMarre
> >> Sent: Tuesday, October 04, 2011 11:33 AM
> >> To: OAuth WG
> >> Subject: [OAUTH-WG] Phishing with Client Application Name Spoo= fing
> >>
> >> I've not seen this particular variant of phishing and client impersonation
> >> discussed. A cursory search revealed that most of the related<= br> discussion
> >> centers around either (a) client impersonation with stolen cli= ent
> credentials
> >> or (b) phishing by malicious clients directing resource owners= to
spoofed
> >> authorization servers. This is different.
> >>
> >> This attack exploits the trust a resource owner has for an OAu= th
> >> authorization server so as to lend repute to a malicious clien= t
> pretending to
> >> be from a trustworthy source. This is not necessarily a direct=
> vulnerability of
> >> OAuth; rather, it shows that authorization servers have a
responsibility
> >> regarding client application names and how they present resour= ce
owners
> >> with the option to allow or deny authorization.
> >>
> >> A key to this exploit is the process of client registration wi= th
> the authorization
> >> server. A malicious client developer registers his client
> application with a
> >> name that appears to represent a legitimate organization which=
resource
> >> owners are likely to trust. Resource owners at the authorizati= on
endpoint
> >> may be misled into granting authorization when they see the authorization
> >> server asserting "<some trustworthy name> is requesting p= ermission
to..."
> >>
> >> Imagine someone registers a client application with an OAuth s= ervice,
let's
> >> call it Foobar, and he names his client app "Google, Inc.". Th= e Foobar
> >> authorization server will engage the user with "Google, Inc. i= s
requesting
> >> permission to do the following." The resource owner might reas= on, "I
see
> >> that I'm legitimately on the https://www.foobar.com site, and = Foobar
is
> >> telling me that Google wants permission. I trust Foobar and Go= ogle, so
I'll
> >> click Allow."
> >>
> >> To make the masquerade act even more convincing, many of the m= ost
> >> popular OAuth services allow app developers to upload images w= hich
could
> >> be official logos of the organizations they are posing as. Oft= en app
> >> developers can supply arbitrary, unconfirmed URIs which are sh= own to
the
> >> resource owner as the app's website, even if the domain does n= ot match
the
> >> redirect URI. Some OAuth services blindly entrust client apps t= o
customize
> >> the authorization page in other ways.
> >>
> >> This is hard to defend against. Authorization server administr= ators
could
> >> police client names, but that approach gives them a burden sim= ilar to
> >> certificate authorities to verify organizations before issuing=
> certificates. Very
> >> expensive.
> >>
> >> A much simpler solution is for authorization servers to be
= > careful with their
> >> wording and educate resource owners about the need for discret= ion when
> >> granting authority. Foobar's message above could be
> >> changed: "An application calling itself Google, Inc. is
> requesting permission to
> >> do the following" later adding, "Only allow this request if yo= u
> are sure of the
> >> application's source." Such wording is less likely to give the=
> impression that
> >> the resource server is vouching for the application's identity= .
> >>
> >> Authorization servers would also do well to show the resource o= wner
> >> additional information about the client application to help th= em make
> >> informed decisions. For example, it could display all or part o= f the
app's
> >> redirect URI, saying, "The application is operating on
> exa= mple.com" or "If you
> >> decide to allow this application, your browser will be directe= d to
> >> http://www.example.com/." Further, if the client app's redirect=
> URI uses TLS
> >> (something authorization servers might choose to mandate), the= n auth
> >> servers can verify the certificate and show the certified
> organization name to
> >> resource owners.
> >>
> >> This attack is possible with OAuth 1, but OAuth 2 makes succes= sful
> >> exploitation easier. OAuth 1 required the client to obtain tem= porary
> >> credentials (aka access tokens) before sending resource owners= to the
> >> authorization endpoint. Now with OAuth 2, this attack does not= require
> >> resource owners to interact with the client application before=
visiting the
> >> authorization server. The malicious client developer only need= s
> to distribute
> >> links around the web to the authorization server's authorizati= on
> endpoint. If
> >> the HTTP service is a social platform, the client app might > distribute links using
> >> resource owners' accounts with the access tokens it has acquir= ed,
becoming
> >> a sort of worm. Continuing the Google/Foobar example above, it= might
use
> >> anchor text such as "I used Google Plus to synchronize with my= Foobar
> >> account." Moreover, if the app's redirect URI bounces the reso= urce
owner
> >> back to the HTTP service after acquiring an authorization code= ,
> the victim will
> >> never see a page rendered at the insidious app's domain.
> >>
> >> This is especially dangerous because the public is not trained= to
defend
> >> against it. Savvy users are (arguably) getting better at
> protecting themselves
> >> from traditional phishing by verifying the domain in the addre= ss bar,
and
> >> perhaps checking TLS certificates, but such defenses are irrel= event
here.
> >> Resource owners now need to verify not only that they are on t= he
legitimate
> >> authorization server, but to consider the trustworthyness of t= he link
that
> >> referred them there.
> >>
> >> I'm not sure what can or should be done, but I think it's impo= rtant
for
> >> authorization server implementers to be aware of this attack. I= f
> >> administrators are not able to authenticate client organizatio= ns,then
they
> >> are shifting this burden to resource owners. They should do al= l they
can to
> >> educate resource owners and help them make informed decisions b= efore
> >> granting authorization.
> >>
> >> Regards,
> >> Andre DeMarre
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf= .org
> >> https://www.ietf.org/mailman/listinfo/oa= uth
>


____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-F8DC5663-47F2-481C-9F67-293EB32E0056-- --Apple-Mail-D582D64D-F9F5-4337-8109-B2F6F12145CD Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSTCCBUUw ggQtoAMCAQICEDPbmsaqwjeZa3PxA3uZ8LQwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNzAxMDkwMDAwMDBaFw0xODAxMDkyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEArsGSzZyz9Lq9SRW9Sve5K8n5lWhplOCE6HH3gMye12DjOpkF FZt0b73t27G17Xsp6WUxHhNevf7ck0AUpvYUPCHBqVGJSIWF9hWAoSFCgQACOoh/cDFbzz1PsMY8 El7OmIus4JXtY4/VdoSIhFP3hzATbNAg32Kp+N8vtTuKTwbgnizJSyzZTYrsttn3LmwY17HU+U9v XloMus5U/ln4ADZx0zyyDSsA6gtPxXYJpbgSTnHckVZ5zfR80guIZ538Y2qqsqt5VaSRSR2oQzE/ HETkKc/odPVhqBrXLyvnSFkCPrAXV07rcvwkPvHZeYVu4QdVWyO2HIQ4i2x9r5m7SwIDAQABo4IB 9TCCAfEwHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFPngHgVxOZ7G Sji/IW4YJMBj02PHMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEE AbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwXQYD VR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50 QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAwWAYI KwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhl bnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNv bW9kb2NhLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0B AQsFAAOCAQEAAmueyHjiyL1qYgfe+hVSsGuKlgcvjCAfG8Jaq48tC0IjP8pH/tGi4uL9CHVfLnV3 pLDnjg6M2uvpEBp7crZZcnSPLeVss+tkhwv+F7ISYQyT4flNkqVUb8nfewbCPcIN13ObfpU7rlXo IarEEplQo4SuymYVluQxTLOFKm5QOMF4JBMw/rjy4t95J7Mdp9NFUzQrKPJDaJ2Jr/TcTXFcjLvN VmMBjK0959a9v1/1miRHd1DBsTh1KvBigEOUNMxvT5uUtB6/tioDZqBDDk8Gvdno/xmye3YiasS7 JgMREq5WcXqpWGu5kMFZMGPEvyPHeBZeqxx3amf4ImVnZ6WvgzGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDPbmsaqwjeZa3PxA3uZ8LQw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTcwNTEzMTAwNTM2WjAjBgkqhkiG9w0BCQQxFgQUeTSv8HtlF61m3umriKizwCKyiNQwgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAz25rGqsI3mWtz8QN7mfC0MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEB AQUABIIBAFUJ/NzpUPGb4D+k6ATTgecE1oCgWA9sV0VLLgjuZ+bdkWKcSKxFwPkTuWD6S0w7XXih 1cscqHujOXzXW9WRlXCIutX3b438S56YTQVkFSm4GBOfCWe9UiL51pomk8qt00RNC2HF9BfrN7CC MPMAzFnLTkD2vaYXOB3649xC0Sw76UoS8GXnfgHBa7nNlK3gcvttEFCZOwcnvds/8GnHtQt1xhYT Slx/Luta/uSAGJytAU4ng2otIx1Rsl7Aj0d+bkX2YpKUCiLaBYOx3fHFGpYW0KhZfXNHXcguAe3F vK04RnCoVv8D9pSg8FvYcUCFTbvULyWBHiXzuWEb17330k0AAAAAAAA= --Apple-Mail-D582D64D-F9F5-4337-8109-B2F6F12145CD-- From nobody Sun May 14 03:14:19 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD674129471 for ; Sun, 14 May 2017 03:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nPq7JWTpUIK for ; Sun, 14 May 2017 03:14:16 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5C4F127076 for ; Sun, 14 May 2017 03:12:23 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id l18so104252285oig.2 for ; Sun, 14 May 2017 03:12:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Klg4BDvrvlcQmAEwnfMyJ4PGGz53h8XLRx21D+ksuXM=; b=sSq6lExH+aQlhX/o2a1wXsT+ziLLo46C0j8VmWo3PPv1JL3fEjcrHTejSaOW8EXtjE QEjfknocD55ZA4DQJdm7x5USGSifktkUc8bGttekSP8Y/6AgtQmXUGiEETlAjPv9Om/1 mHPuHxd56pI/1BRccSwyzj66XnpmV0ZS2ulYu7gJMayzZjHZZEREYoczCyEkVVZcKarc cHRYeZ3/l8FNCG3kWIHCm26FMDxqRzkHSlCpScvBsLUZW8mGz+WXcYekm1OcGozHZLhV HbQy2a0JaajGEjs85fJgUyaIZBuz5JxSKsPLKTRx7f2B8b/zRPC4QUicH3pUNpGSyj3O 2GtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Klg4BDvrvlcQmAEwnfMyJ4PGGz53h8XLRx21D+ksuXM=; b=IH0pxNlx+moMDg7ZKtVNHxI54jd+vD5DjyjA9VeOKTaJ/1o62eB5S5XjDV54Bc44Lx 4Smd1eUnI6h6yx8iFPMXDB+jundeZ+JZUNxTtsJ0HEVGWnIvXyPcnfn+hfs62K/Ruv6S Zf1BlnThRLJXvB8+dhBrk4HUrDsAhckYXCqDQ/QHc1/D4xmbh3MsZRf/64KfneCGnTz3 Kiyf679KUOfmsr/RyimlMEg1SsgowFYo3fjz+1bb0ukDAdg2mShIAE7FsaFdmeajFxNn qepuk2jURGLGnHhhHAqSjE2h1Gcc1W2DlfQsBNeTiWShDwGtkBBxd52KfNoFZnbplUtk 7HTQ== X-Gm-Message-State: AODbwcAoM56VoUmYpUmHRSRTDoLYeKZpOPj/nMAD4vbmmwPaXXsr4qrt XUpAzKNq3jZIaz3C5rV4OSufW+MM6UFtHo8= X-Received: by 10.157.82.87 with SMTP id q23mr278733otg.52.1494756742923; Sun, 14 May 2017 03:12:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.255.137 with HTTP; Sun, 14 May 2017 03:12:22 -0700 (PDT) In-Reply-To: <22C1AD59-1B76-4596-AAFB-2CF1770FA58B@lodderstedt.net> References: <22C1AD59-1B76-4596-AAFB-2CF1770FA58B@lodderstedt.net> From: Samuel Erdtman Date: Sun, 14 May 2017 12:12:22 +0200 Message-ID: To: Torsten Lodderstedt Cc: "" , ace Content-Type: multipart/alternative; boundary="f403043c4becb01b5b054f792c79" Archived-At: Subject: Re: [OAUTH-WG] New OAuth client credentials RPK and PSK X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 10:14:19 -0000 --f403043c4becb01b5b054f792c79 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Torsten, That is a possibility, I excluded it to keep the scope limited and because I don=C2=B4t think it is as applicable with these credential types. I think these credential types will mostly be used in IoT deployments using the ACE framework, in that case the token will have its own key that will most likely be used in the (D)TLS handshake between the client and resource server see e.g. https://tools.ietf.org/html/draft-gerdes-ace-dtls-authorize-01. However if the token would not be a PoP token then it could make sense. Do you fore see such use cases where it would be useful? One thing that I did not mention in my earlier email that could be a possible path forward would be to merge this draft into the mtls one. //Samuel On Sat, May 13, 2017 at 11:58 AM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > Hi Samuel, > > as far as I understand your draft, it utilizes results of the (D)TLS > client authentication for authentication towards the tokens endpoint - > similar to https://tools.ietf.org/html/draft-ietf-oauth-mtls-00.html. Do > you intend to also utilize the binding of the access token to a certain k= ey > pair as described in oauth-ietf-mtls? > > best regards, > Torsten. > > Am 12.05.2017 um 10:03 schrieb Samuel Erdtman : > > Hi ACE and OAuth WGs, > > I and Ludwig submitted a new draft yesterday defining how to use Raw > Public Key and Pre Shared Key with (D)TLS as OAuth client credentials, > https://datatracker.ietf.org/doc/draft-erdtman-ace-rpcc/. > > We think this is valuable to the ACE work since the ACE framework is base= d > on OAuth, but client credentials as defined in the OAuth framework are no= t > the best match for embedded devices. > > We think Raw Public Keys and Pre Shared Keys are more suitable credential= s > for embedded devices for the following reasons: > * Better security by binding to transport layer. > * If PSK DTLS is to be used a key need to be distributed any way, why not > make use of it as credential. > * Client id and client secret accommodates for manual input by a humans. > This does not scale well and requires some for of input device. > * Some/many devices will have crypto-hardware that can protect key > material, to not use that possibility would be a waste. > * There are probably more reasons these was just the once on top of my > head. > > This is not the first resent initiative to create new client credential > types, the OAuth WG adopted a similar draft for certificate based client > credentials (https://tools.ietf.org/html/draft-ietf-oauth-mtls-00.html). > That work is also valuable to ACE but not all devices will be able to wor= k > with certificates or even asymmetric cryptos . > > Please review and comment. > > Cheers > //Samuel > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --f403043c4becb01b5b054f792c79 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Torsten,

That is a po= ssibility, I excluded it to keep the scope limited and because I don=C2=B4t= think it is as applicable with these credential types.

I thin= k these credential types will mostly be used in IoT deployments using the A= CE framework, in that case the token will have its own key that will most l= ikely be used in the (D)TLS handshake between the client and resource serve= r see e.g. https://tools.ietf.org/html/draft-gerdes-ace-dtls-authorize-01.

However if the token would not be a PoP token then it coul= d make sense. Do you fore see such use cases where it would be useful?
<= br>

//Samuel


On Sat, Ma= y 13, 2017 at 11:58 AM, Torsten Lodderstedt <torsten@lodderstedt.n= et> wrote:
Hi Samuel,

as far as I understan= d your draft, it utilizes results of the (D)TLS client authentication for a= uthentication towards the tokens endpoint - similar to=C2=A0ht= tps://tools.ietf.org/html/draft-ietf-oauth-mtls-00.html. Do y= ou intend to also utilize the binding of the access token to a certain key = pair as described in oauth-ietf-mtls?

best regards= ,
Torsten.

Am 12.05.2017 um = 10:03 schrieb Samuel Erdtman <samuel@erdtman.se>:

Hi ACE and OAuth WGs,

I and Ludwig submitted a new draft yesterday defining how to use Raw Publi= c Key and Pre Shared Key with (D)TLS as OAuth client credentials, https://datatracker.ietf.org/doc/draft-erdtman-ace-rpcc/.
=

We think this is valuable to the ACE work since the AC= E framework is based on OAuth, but client credentials as defined in the OAu= th framework are not the best match for embedded devices.

We think Raw Public Keys and Pre Shared Keys are more suitable credentials= for embedded devices for the following reasons:
* Better sec= urity by binding to transport layer.
* If PSK DTLS is to be u= sed a key need to be distributed any way, why not make use of it as credent= ial.
* Client id and client secret accommodates for manual in= put by a humans. This does not scale well and requires some for of input de= vice.
* Some/many devices will have crypto-hardware that can = protect key material, to not use that possibility would be a waste.
* There are probably more reasons these was just the once on top of = my head.

This is not the first resent initiati= ve to create new client credential types, the OAuth WG adopted a similar dr= aft for certificate based client credentials (https://tools.ie= tf.org/html/draft-ietf-oauth-mtls-00.html). That work is also= valuable to ACE but not all devices will be able to work with certificates= or even asymmetric cryptos .

Please review and comment.<= br>
Cheers
//Samuel


_______= ________________________________________
OAuth mailing= list
O= Auth@ietf.org
https://www.ietf.org/mailman/listinfo= /oauth

--f403043c4becb01b5b054f792c79-- From nobody Sun May 14 13:33:25 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F18128B8E; Sun, 14 May 2017 13:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u_dWTlEVBJ8d; Sun, 14 May 2017 13:33:14 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0E04127977; Sun, 14 May 2017 13:29:09 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01D2CCB4.8D30C950" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1494793748; h=from:subject:to:date:message-id; bh=STC2dMLkpzH3n6mwKiHt/r7IpIZQlkciAOrTpUvFH2k=; b=SQGP8R8LY0hy8dNSYGFvfmX2oKn4XovTqTU7alsdFdi+Qh6GiZAzBWNjOIHC+uBvaV7/0rwlxHj 7qCVIU3azwCvxL4LR4BImMBO85Q6mOGtIt4xcxff1eO2znDNlKRtLY+RhxKg+DR31Giycof9z8jGs n8S18+hT7jG5HFFRkExBtuc+QSEZh5AP0HFb7r0RrR55RH/KVwuQ78cOK9jC6W2TDFPZzEVg9/FLS NpOUPsGQpQLwFztfScaH+bXFM8E3g2M46jf7m7nEHClp+BU9LQsfwrY1t+5bNz+aYe+QctXB2wD53 2Nm5qQiPQ51TD4exWBd0c83A/QGyO2udf6IA== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 14 May 2017 13:29:07 -0700 Received: from Hebrews (173.8.216.38) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 14 May 2017 13:29:00 -0700 From: Jim Schaad To: 'Samuel Erdtman' , , 'ace' References: In-Reply-To: Date: Sun, 14 May 2017 13:18:14 -0700 Message-ID: <000501d2ccef$398d0940$aca71bc0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQF2pOMAEHj6tEKs9s8Af1VsoCYHA6KslJaw X-Originating-IP: [173.8.216.38] Archived-At: Subject: Re: [OAUTH-WG] [Ace] New OAuth client credentials RPK and PSK X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 20:33:16 -0000 ------=_NextPart_000_0006_01D2CCB4.8D30C950 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable How is this draft supposed to interact with = draft-gerdes-ace-dtls-authorize? =20 Jim =20 =20 From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Samuel Erdtman Sent: Friday, May 12, 2017 1:03 AM To: ; ace Cc: Ludwig Seitz Subject: [Ace] New OAuth client credentials RPK and PSK =20 Hi ACE and OAuth WGs, I and Ludwig submitted a new draft yesterday defining how to use Raw = Public Key and Pre Shared Key with (D)TLS as OAuth client credentials, = https://datatracker.ietf.org/doc/draft-erdtman-ace-rpcc/. =20 We think this is valuable to the ACE work since the ACE framework is = based on OAuth, but client credentials as defined in the OAuth framework = are not the best match for embedded devices. We think Raw Public Keys and Pre Shared Keys are more suitable = credentials for embedded devices for the following reasons: * Better security by binding to transport layer. * If PSK DTLS is to be used a key need to be distributed any way, why = not make use of it as credential. * Client id and client secret accommodates for manual input by a humans. = This does not scale well and requires some for of input device. * Some/many devices will have crypto-hardware that can protect key = material, to not use that possibility would be a waste. * There are probably more reasons these was just the once on top of my = head. =20 This is not the first resent initiative to create new client credential = types, the OAuth WG adopted a similar draft for certificate based client = credentials (https://tools.ietf.org/html/draft-ietf-oauth-mtls-00.html). = That work is also valuable to ACE but not all devices will be able to = work with certificates or even asymmetric cryptos . Please review and comment. Cheers //Samuel =20 ------=_NextPart_000_0006_01D2CCB4.8D30C950 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

How is = this draft supposed to interact with = draft-gerdes-ace-dtls-authorize?

 

Jim

 

 

From: = Ace [mailto:ace-bounces@ietf.org] On Behalf Of Samuel = Erdtman
Sent: Friday, May 12, 2017 1:03 AM
To: = <oauth@ietf.org> <oauth@ietf.org>; ace = <Ace@ietf.org>
Cc: Ludwig Seitz = <ludwig.seitz@ri.se>
Subject: [Ace] New OAuth client = credentials RPK and PSK

 

Hi ACE and OAuth = WGs,

I and Ludwig submitted a = new draft yesterday defining how to use Raw Public Key and Pre Shared = Key with (D)TLS as OAuth client credentials, https:/= /datatracker.ietf.org/doc/draft-erdtman-ace-rpcc/.

 

We think this is = valuable to the ACE work since the ACE framework is based on OAuth, but = client credentials as defined in the OAuth framework are not the best = match for embedded devices.

We think Raw Public Keys and Pre Shared Keys are more = suitable credentials for embedded devices for the following = reasons:

* Better security = by binding to transport layer.

* If PSK DTLS is to be used a key need to be = distributed any way, why not make use of it as = credential.

* Client id = and client secret accommodates for manual input by a humans. This does = not scale well and requires some for of input = device.

* Some/many = devices will have crypto-hardware that can protect key material, to not = use that possibility would be a waste.

* There are probably more reasons these was just the = once on top of my head.

 

This is not the first resent initiative = to create new client credential types, the OAuth WG adopted a similar = draft for certificate based client credentials (https:= //tools.ietf.org/html/draft-ietf-oauth-mtls-00.html). That work is = also valuable to ACE but not all devices will be able to work with = certificates or even asymmetric cryptos .

Please review and = comment.

Cheers

//Samuel

 

------=_NextPart_000_0006_01D2CCB4.8D30C950-- From nobody Mon May 15 01:52:49 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5139129AFA for ; Mon, 15 May 2017 01:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2O03gyO9cPL4 for ; Mon, 15 May 2017 01:52:45 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A876E129C49 for ; Mon, 15 May 2017 01:49:03 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id w10so122519741oif.0 for ; Mon, 15 May 2017 01:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Pfs0LLLfbhQWwh8WIOXvB7xvm2mphNTE8Wk+6eB8QPI=; b=xgT2wpclIo2xykcLwAcSIxfkMQ3/OLfV/Ft/J6lbyO3l/+KDoZGl3uzCAyF6apZ+CW 61oZJXoFd6oToGqIkc9GldMtTgJFUggUkeQ5qqQG56AycukNlIZL6CVgn191iWmO1w7a DQTj9BjrHqixZOYMAgqHepQkZB4QfUEV0F8W2o5sq9zUNaalq/k0OqojXCVED9At5SnA RqYvE1S3juxhda/bHvwJHS/PExTldhpXp2ESp2K82tjYkeJQ1ZIpgEs9BtIQ9gF3kJhf UiHtjd7dZF0pMWdtZPkDsoEmQP4Uj4c3PN9IDPBfuRVisaU3t+hrzRcX/CSdtv6Zeiz6 VHGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Pfs0LLLfbhQWwh8WIOXvB7xvm2mphNTE8Wk+6eB8QPI=; b=BSH6xGdb7Zgc/ncxd6aiTiisdALvZa7Ok+sWpGHQH3QirYa4s/m7O8hh2lkBcoRDHf g9Nrs6y3okW++WnEmqmx0hIdA4kk0vLRO3qEh14EVXkK7SDohkonTihAYCM3BbAWIsLb WMAwJ++rzOSzz23Bds0NJtIuXfsTDzg4dtx6gaD8phxGuAm0/3y+Z8yn7uiW3TCuwH9I SYPRtymfecDU3lOsEO0sEZVNtFyLn2bKPRZRI0pw6HlLguuS1m4dc8nsvyYe0lBp+r+D OcLhhlNQVYQ5Kjjjm5q94ZHQ9ub/5CHcijzrHr9P5b5E/vMtFbQd6t/i7Ha5pMLNll0E ezaQ== X-Gm-Message-State: AODbwcATlkHwLG4aHVXL+Jy94mdflq4Fbs/OYUrGJoFcSMT4VnzGesWG 7J1DhP5OGGXk/qlc6g7amECS8np9EA== X-Received: by 10.157.82.95 with SMTP id q31mr2600441otg.165.1494838142882; Mon, 15 May 2017 01:49:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.255.137 with HTTP; Mon, 15 May 2017 01:49:02 -0700 (PDT) In-Reply-To: <000501d2ccef$398d0940$aca71bc0$@augustcellars.com> References: <000501d2ccef$398d0940$aca71bc0$@augustcellars.com> From: Samuel Erdtman Date: Mon, 15 May 2017 10:49:02 +0200 Message-ID: To: Jim Schaad Cc: "" , ace , Ludwig Seitz Content-Type: multipart/alternative; boundary="f403043c496480eb1f054f8c2086" Archived-At: Subject: Re: [OAUTH-WG] [Ace] New OAuth client credentials RPK and PSK X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 08:52:48 -0000 --f403043c496480eb1f054f8c2086 Content-Type: text/plain; charset="UTF-8" In short this draft focuses on the C to AS connection and draft-gerdes-ace-dtls-authorize focuses on the C to RS connection. This draft details on how to use RPK or PSK as client credentials to setup the (D)TLS between C and AS while draft-gerdes-ace-dtls-authorize provides details for how to use the RPK or PSK bound to an access token to setup the connection between C and RS. //Samuel On Sun, May 14, 2017 at 10:18 PM, Jim Schaad wrote: > How is this draft supposed to interact with draft-gerdes-ace-dtls- > authorize? > > > > Jim > > > > > > *From:* Ace [mailto:ace-bounces@ietf.org] *On Behalf Of *Samuel Erdtman > *Sent:* Friday, May 12, 2017 1:03 AM > *To:* ; ace > *Cc:* Ludwig Seitz > *Subject:* [Ace] New OAuth client credentials RPK and PSK > > > > Hi ACE and OAuth WGs, > > I and Ludwig submitted a new draft yesterday defining how to use Raw > Public Key and Pre Shared Key with (D)TLS as OAuth client credentials, > https://datatracker.ietf.org/doc/draft-erdtman-ace-rpcc/. > > > > We think this is valuable to the ACE work since the ACE framework is based > on OAuth, but client credentials as defined in the OAuth framework are not > the best match for embedded devices. > > We think Raw Public Keys and Pre Shared Keys are more suitable credentials > for embedded devices for the following reasons: > > * Better security by binding to transport layer. > > * If PSK DTLS is to be used a key need to be distributed any way, why not > make use of it as credential. > > * Client id and client secret accommodates for manual input by a humans. > This does not scale well and requires some for of input device. > > * Some/many devices will have crypto-hardware that can protect key > material, to not use that possibility would be a waste. > > * There are probably more reasons these was just the once on top of my > head. > > > > This is not the first resent initiative to create new client credential > types, the OAuth WG adopted a similar draft for certificate based client > credentials (https://tools.ietf.org/html/draft-ietf-oauth-mtls-00.html). > That work is also valuable to ACE but not all devices will be able to work > with certificates or even asymmetric cryptos . > > Please review and comment. > > Cheers > > //Samuel > > > --f403043c496480eb1f054f8c2086 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In short this draft focuses on the C to AS connection= and draft-gerdes-ace-dtls-authorize focuses on the C to RS connection= .

This draft details on how to use RPK or PSK as client c= redentials to setup the (D)TLS between C and AS while draft-gerdes-ace-dtls= -authorize provides details for how to use the RPK or PSK bound to an = access token to setup the connection between C and RS.

//= Samuel


On Sun, May 14, 2017 at 10:18 PM, Jim Schaad <ie= tf@augustcellars.com> wrote:

How is this draft suppose= d to interact with draft-gerdes-ace-dtls-authorize?

<= p class=3D"MsoNormal">=C2=A0

Jim=

=C2=A0

=C2=A0

From: Ace [= mailto:ace-bounce= s@ietf.org] On Behalf Of Samuel Erdtman
Sent: Friday, = May 12, 2017 1:03 AM
To: <oauth@ietf.org> <oauth@ietf.org>; ace <Ace@ietf.org>
Cc: Ludwig Seitz = <ludwig.seitz@ri= .se>
Subject: [Ace] New OAuth client credentials RPK and P= SK

= =C2=A0

Hi ACE and OAuth WGs,

I and Ludwig submitted a new draft yesterday defining how to use R= aw Public Key and Pre Shared Key with (D)TLS as OAuth client credentials, <= a href=3D"https://datatracker.ietf.org/doc/draft-erdtman-ace-rpcc/" target= =3D"_blank">https://datatracker.ietf.org/doc/draft-erdtman-ace-rpcc/.

=C2=A0=

We think th= is is valuable to the ACE work since the ACE framework is based on OAuth, b= ut client credentials as defined in the OAuth framework are not the best ma= tch for embedded devices.

We think Raw Public Keys and Pre Shared Keys are more suitable credential= s for embedded devices for the following reasons:

* Better security by binding to transport layer.<= u>

* If PSK DTLS is to be u= sed a key need to be distributed any way, why not make use of it as credent= ial.

* Client id and cli= ent secret accommodates for manual input by a humans. This does not scale w= ell and requires some for of input device.

* Some/many devices will have crypto-hardware that can p= rotect key material, to not use that possibility would be a waste.

* There are probably more reason= s these was just the once on top of my head.

=C2=A0

This is not the first resent initiative = to create new client credential types, the OAuth WG adopted a similar draft= for certificate based client credentials (https://tools.ietf.= org/html/draft-ietf-oauth-mtls-00.html). That work is also va= luable to ACE but not all devices will be able to work with certificates or= even asymmetric cryptos .

Please review and comment.<= /p>

Cheers

//Samuel

=C2=A0


--f403043c496480eb1f054f8c2086-- From nobody Mon May 15 04:32:04 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4998127011; Mon, 15 May 2017 04:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.146 X-Spam-Level: X-Spam-Status: No, score=-1.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1J35wytyzoI; Mon, 15 May 2017 04:31:53 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-oln040092068105.outbound.protection.outlook.com [40.92.68.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D18A012957A; Mon, 15 May 2017 04:27:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=F6NZnywjVGc9lquINQWy3LzM0XSzDIvy2bYKKhvuuUo=; b=Hm3sSY2smJuRR8PihP9tfyXbtHGdj934a0Xp9t67JNtvh1qKr5CgFHxxRqAX62G82QKc231e7gD2K6/Zjs1e+zKEOJsIrodHKsNuRL/tqv2hKX6AZhu/xoKyD0dG7gpcjbJYd/JQik5PYSoEdVDmhdEYIFSnmIKjA8kF7aNYokI9W6p5TweGydriuFP4blW3o7kB0ozPLN6LmNIziLrBDRNlAODp2rPkFp4GZrGLaj+k/r7mJNDxlGze09UzU9uZQ/MSRLtLPdPYYzE1xO/8F7Fy77ZYjPMSuACvksyypasaMyoC9WVqvS1Ux1L9wt3Rsz16wA3w30X4vqxOV9J+MQ== Received: from HE1EUR02FT030.eop-EUR02.prod.protection.outlook.com (10.152.10.51) by HE1EUR02HT211.eop-EUR02.prod.protection.outlook.com (10.152.11.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1075.5; Mon, 15 May 2017 11:27:57 +0000 Received: from AM4PR09MB0627.eurprd09.prod.outlook.com (10.152.10.51) by HE1EUR02FT030.mail.protection.outlook.com (10.152.10.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.5 via Frontend Transport; Mon, 15 May 2017 11:27:56 +0000 Received: from AM4PR09MB0627.eurprd09.prod.outlook.com ([fe80::b562:3:99a7:9530]) by AM4PR09MB0627.eurprd09.prod.outlook.com ([fe80::b562:3:99a7:9530%14]) with mapi id 15.01.1084.029; Mon, 15 May 2017 11:27:56 +0000 From: Adrian Imach To: Samuel Erdtman CC: Jim Schaad , "" , ace Thread-Topic: [OAUTH-WG] [Ace] New OAuth client credentials RPK and PSK Thread-Index: AQF2pOMAEHj6tEKs9s8Af1VsoCYHA6KslJawgADR1wCAACxkKg== Date: Mon, 15 May 2017 11:27:56 +0000 Message-ID: References: <000501d2ccef$398d0940$aca71bc0$@augustcellars.com>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: erdtman.se; dkim=none (message not signed) header.d=none;erdtman.se; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:EE7621ACA0A9762E1B554070139F5CE68D3A53794B47A2C2FB867CA046B9E5E3; UpperCasedChecksum:06D0C4D13DF55FE168E6C789AF3743D3DA673CBFE176A3A94506B358FD949017; SizeAsReceived:8509; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [XCWKhpD+KPT/DFLzYEwjPAxDKuT/jMM1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1EUR02HT211; 5:kb3tqbEtYUdi0h+FXVRzMegPfnuDz2yQnQqTL6TE0IitrtL0MzziT6WlXt6eQHQmdZHGF/XcMtLarvrEtVrmo5v29o4fttQk5y7rUYaa5iK/r14WAogNOp0jG9kBcmdbMRP0dJVewIGDWewnwY59qQ==; 24:swL5xt43+9J4qFJ1GY6QwZHdlVuhk6MEfl2p8wxq61HuitHYXezMv57C/vtq3xZRYGHpkXRX3x06ZRgItCXeKddCPgfsISlHqbuJwj/Xzkw=; 7:a4NoOtzaz3JKDbaf+WiOA1FDZbRYM2AQGCwtDMae7D+XCXi1VYDpFkcCiXvci7GnxMEQUBc58GNhxq4A4dEb5rTjopHrBmdXod9TIXz2W0pm4wAC+Ss6s0x/L9zwFIS+WHpBMuUlTUqZnmHEP97VRsqAgxqz+jKyqs8PWOf/TmHZq8yfSXf1fvFJQB7hLkycweyBV9UiQ9ppILUoI2T7P1xgdBS0Q6VAk6r0RfbDBgU/XyHXkguuZ67uWnpOSg6B0QmmyAKGy/cp0fyP35Zk6zoxWI19KxK1pBY9f5y2Ikp4Pb1Rl6epoPNCMSdOhDlO x-incomingheadercount: 46 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:HE1EUR02HT211; H:AM4PR09MB0627.eurprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: c63e5c8f-c3da-4599-e7bf-08d49b856f60 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322274)(1601125374)(1603101448)(1701031045); SRVR:HE1EUR02HT211; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:HE1EUR02HT211; BCL:0; PCL:0; RULEID:; SRVR:HE1EUR02HT211; x-forefront-prvs: 0308EE423E spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR09MB0627E138F244480420AD4949B0E10AM4PR09MB0627eurp_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2017 11:27:56.5858 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1EUR02HT211 Archived-At: Subject: Re: [OAUTH-WG] [Ace] New OAuth client credentials RPK and PSK X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 11:31:56 -0000 --_000_AM4PR09MB0627E138F244480420AD4949B0E10AM4PR09MB0627eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGxlYXNlIHVuc3Vic2NyaWJlIG1lIGZyb20geW91ciBtYWlsaW5nIGxpc3QuIFRoYW5rIHlvdSAs DQoNCkFkcmlhbiBJbWFjaA0KDQpPbiAxNSBNYXkgMjAxNywgYXQgMDk6NTIsIFNhbXVlbCBFcmR0 bWFuIDxzYW11ZWxAZXJkdG1hbi5zZTxtYWlsdG86c2FtdWVsQGVyZHRtYW4uc2U+PiB3cm90ZToN Cg0KSW4gc2hvcnQgdGhpcyBkcmFmdCBmb2N1c2VzIG9uIHRoZSBDIHRvIEFTIGNvbm5lY3Rpb24g YW5kIGRyYWZ0LWdlcmRlcy1hY2UtZHRscy1hdXRob3JpemUgZm9jdXNlcyBvbiB0aGUgQyB0byBS UyBjb25uZWN0aW9uLg0KDQpUaGlzIGRyYWZ0IGRldGFpbHMgb24gaG93IHRvIHVzZSBSUEsgb3Ig UFNLIGFzIGNsaWVudCBjcmVkZW50aWFscyB0byBzZXR1cCB0aGUgKEQpVExTIGJldHdlZW4gQyBh bmQgQVMgd2hpbGUgZHJhZnQtZ2VyZGVzLWFjZS1kdGxzLWF1dGhvcml6ZSBwcm92aWRlcyBkZXRh aWxzIGZvciBob3cgdG8gdXNlIHRoZSBSUEsgb3IgUFNLIGJvdW5kIHRvIGFuIGFjY2VzcyB0b2tl biB0byBzZXR1cCB0aGUgY29ubmVjdGlvbiBiZXR3ZWVuIEMgYW5kIFJTLg0KDQovL1NhbXVlbA0K DQoNCk9uIFN1biwgTWF5IDE0LCAyMDE3IGF0IDEwOjE4IFBNLCBKaW0gU2NoYWFkIDxpZXRmQGF1 Z3VzdGNlbGxhcnMuY29tPG1haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tPj4gd3JvdGU6DQpI b3cgaXMgdGhpcyBkcmFmdCBzdXBwb3NlZCB0byBpbnRlcmFjdCB3aXRoIGRyYWZ0LWdlcmRlcy1h Y2UtZHRscy1hdXRob3JpemU/DQoNCkppbQ0KDQoNCkZyb206IEFjZSBbbWFpbHRvOmFjZS1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzphY2UtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBT YW11ZWwgRXJkdG1hbg0KU2VudDogRnJpZGF5LCBNYXkgMTIsIDIwMTcgMTowMyBBTQ0KVG86IDxv YXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+PiA8b2F1dGhAaWV0Zi5vcmc8bWFp bHRvOm9hdXRoQGlldGYub3JnPj47IGFjZSA8QWNlQGlldGYub3JnPG1haWx0bzpBY2VAaWV0Zi5v cmc+Pg0KQ2M6IEx1ZHdpZyBTZWl0eiA8bHVkd2lnLnNlaXR6QHJpLnNlPG1haWx0bzpsdWR3aWcu c2VpdHpAcmkuc2U+Pg0KU3ViamVjdDogW0FjZV0gTmV3IE9BdXRoIGNsaWVudCBjcmVkZW50aWFs cyBSUEsgYW5kIFBTSw0KDQpIaSBBQ0UgYW5kIE9BdXRoIFdHcywNCkkgYW5kIEx1ZHdpZyBzdWJt aXR0ZWQgYSBuZXcgZHJhZnQgeWVzdGVyZGF5IGRlZmluaW5nIGhvdyB0byB1c2UgUmF3IFB1Ymxp YyBLZXkgYW5kIFByZSBTaGFyZWQgS2V5IHdpdGggKEQpVExTIGFzIE9BdXRoIGNsaWVudCBjcmVk ZW50aWFscywgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZXJkdG1hbi1h Y2UtcnBjYy8uDQoNCldlIHRoaW5rIHRoaXMgaXMgdmFsdWFibGUgdG8gdGhlIEFDRSB3b3JrIHNp bmNlIHRoZSBBQ0UgZnJhbWV3b3JrIGlzIGJhc2VkIG9uIE9BdXRoLCBidXQgY2xpZW50IGNyZWRl bnRpYWxzIGFzIGRlZmluZWQgaW4gdGhlIE9BdXRoIGZyYW1ld29yayBhcmUgbm90IHRoZSBiZXN0 IG1hdGNoIGZvciBlbWJlZGRlZCBkZXZpY2VzLg0KV2UgdGhpbmsgUmF3IFB1YmxpYyBLZXlzIGFu ZCBQcmUgU2hhcmVkIEtleXMgYXJlIG1vcmUgc3VpdGFibGUgY3JlZGVudGlhbHMgZm9yIGVtYmVk ZGVkIGRldmljZXMgZm9yIHRoZSBmb2xsb3dpbmcgcmVhc29uczoNCiogQmV0dGVyIHNlY3VyaXR5 IGJ5IGJpbmRpbmcgdG8gdHJhbnNwb3J0IGxheWVyLg0KKiBJZiBQU0sgRFRMUyBpcyB0byBiZSB1 c2VkIGEga2V5IG5lZWQgdG8gYmUgZGlzdHJpYnV0ZWQgYW55IHdheSwgd2h5IG5vdCBtYWtlIHVz ZSBvZiBpdCBhcyBjcmVkZW50aWFsLg0KKiBDbGllbnQgaWQgYW5kIGNsaWVudCBzZWNyZXQgYWNj b21tb2RhdGVzIGZvciBtYW51YWwgaW5wdXQgYnkgYSBodW1hbnMuIFRoaXMgZG9lcyBub3Qgc2Nh bGUgd2VsbCBhbmQgcmVxdWlyZXMgc29tZSBmb3Igb2YgaW5wdXQgZGV2aWNlLg0KKiBTb21lL21h bnkgZGV2aWNlcyB3aWxsIGhhdmUgY3J5cHRvLWhhcmR3YXJlIHRoYXQgY2FuIHByb3RlY3Qga2V5 IG1hdGVyaWFsLCB0byBub3QgdXNlIHRoYXQgcG9zc2liaWxpdHkgd291bGQgYmUgYSB3YXN0ZS4N CiogVGhlcmUgYXJlIHByb2JhYmx5IG1vcmUgcmVhc29ucyB0aGVzZSB3YXMganVzdCB0aGUgb25j ZSBvbiB0b3Agb2YgbXkgaGVhZC4NCg0KVGhpcyBpcyBub3QgdGhlIGZpcnN0IHJlc2VudCBpbml0 aWF0aXZlIHRvIGNyZWF0ZSBuZXcgY2xpZW50IGNyZWRlbnRpYWwgdHlwZXMsIHRoZSBPQXV0aCBX RyBhZG9wdGVkIGEgc2ltaWxhciBkcmFmdCBmb3IgY2VydGlmaWNhdGUgYmFzZWQgY2xpZW50IGNy ZWRlbnRpYWxzIChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1t dGxzLTAwLmh0bWwpLiBUaGF0IHdvcmsgaXMgYWxzbyB2YWx1YWJsZSB0byBBQ0UgYnV0IG5vdCBh bGwgZGV2aWNlcyB3aWxsIGJlIGFibGUgdG8gd29yayB3aXRoIGNlcnRpZmljYXRlcyBvciBldmVu IGFzeW1tZXRyaWMgY3J5cHRvcyAuDQpQbGVhc2UgcmV2aWV3IGFuZCBjb21tZW50Lg0KQ2hlZXJz DQovL1NhbXVlbA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg== --_000_AM4PR09MB0627E138F244480420AD4949B0E10AM4PR09MB0627eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PlBsZWFzZSB1bnN1YnNjcmliZSBtZSBmcm9tIHlvdXIgbWFpbGluZyBsaXN0LiBUaGFuayB5 b3UgLDxicj4NCjxicj4NCkFkcmlhbiBJbWFjaDwvZGl2Pg0KPGRpdj48YnI+DQpPbiAxNSBNYXkg MjAxNywgYXQgMDk6NTIsIFNhbXVlbCBFcmR0bWFuICZsdDs8YSBocmVmPSJtYWlsdG86c2FtdWVs QGVyZHRtYW4uc2UiPnNhbXVlbEBlcmR0bWFuLnNlPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2PkluIHNob3J0IHRoaXMgZHJhZnQg Zm9jdXNlcyBvbiB0aGUgQyB0byBBUyBjb25uZWN0aW9uIGFuZCBkcmFmdC1nZXJkZXMtYWNlLWR0 bHMtPHdicj5hdXRob3JpemUgZm9jdXNlcyBvbiB0aGUgQyB0byBSUyBjb25uZWN0aW9uLjxicj4N CjwvZGl2Pg0KPGRpdj48YnI+DQpUaGlzIGRyYWZ0IGRldGFpbHMgb24gaG93IHRvIHVzZSBSUEsg b3IgUFNLIGFzIGNsaWVudCBjcmVkZW50aWFscyB0byBzZXR1cCB0aGUgKEQpVExTIGJldHdlZW4g QyBhbmQgQVMgd2hpbGUgZHJhZnQtZ2VyZGVzLWFjZS1kdGxzLTx3YnI+YXV0aG9yaXplIHByb3Zp ZGVzIGRldGFpbHMgZm9yIGhvdyB0byB1c2UgdGhlIFJQSyBvciBQU0sgYm91bmQgdG8gYW4gYWNj ZXNzIHRva2VuIHRvIHNldHVwIHRoZSBjb25uZWN0aW9uIGJldHdlZW4gQyBhbmQgUlMuPGJyPg0K PGJyPg0KPC9kaXY+DQo8ZGl2Pi8vU2FtdWVsPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KPGRpdiBjbGFzcz0iZ21h aWxfcXVvdGUiPk9uIFN1biwgTWF5IDE0LCAyMDE3IGF0IDEwOjE4IFBNLCBKaW0gU2NoYWFkIDxz cGFuIGRpcj0ibHRyIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmlldGZAYXVndXN0Y2VsbGFycy5jb208L2E+Jmd0Ozwvc3Bhbj4g d3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2lu OjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+ DQo8ZGl2IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIGxhbmc9IkVOLVVTIj4NCjxkaXYgY2xh c3M9Im1fODEzOTM4Njc4MjIwOTg4NjMxOVdvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Ib3cgaXMgdGhpcyBkcmFmdCBzdXBwb3NlZCB0byBpbnRlcmFjdCB3aXRoIGRyYWZ0LWdl cmRlcy1hY2UtZHRscy08d2JyPmF1dGhvcml6ZT88dT48L3U+PHU+PC91PjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SmltPHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+Jm5i c3A7PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IEFjZSBbbWFpbHRvOjxhIGhy ZWY9Im1haWx0bzphY2UtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmFjZS1ib3Vu Y2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+U2FtdWVsIEVyZHRtYW48YnI+ DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXkgMTIsIDIwMTcgMTowMyBBTTxicj4NCjxiPlRvOjwv Yj4gJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9h dXRoQGlldGYub3JnPC9hPiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPiZndDs7IGFjZSAmbHQ7PGEgaHJlZj0i bWFpbHRvOkFjZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPkFjZUBpZXRmLm9yZzwvYT4mZ3Q7 PGJyPg0KPGI+Q2M6PC9iPiBMdWR3aWcgU2VpdHogJmx0OzxhIGhyZWY9Im1haWx0bzpsdWR3aWcu c2VpdHpAcmkuc2UiIHRhcmdldD0iX2JsYW5rIj5sdWR3aWcuc2VpdHpAcmkuc2U8L2E+Jmd0Ozxi cj4NCjxiPlN1YmplY3Q6PC9iPiBbQWNlXSBOZXcgT0F1dGggY2xpZW50IGNyZWRlbnRpYWxzIFJQ SyBhbmQgUFNLPHU+PC91Pjx1PjwvdT48L3A+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iaDUiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij5IaSBBQ0UgYW5kIE9BdXRoIFdHcyw8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbmQgTHVkd2lnIHN1Ym1pdHRlZCBhIG5ldyBkcmFmdCB5 ZXN0ZXJkYXkgZGVmaW5pbmcgaG93IHRvIHVzZSBSYXcgUHVibGljIEtleSBhbmQgUHJlIFNoYXJl ZCBLZXkgd2l0aCAoRClUTFMgYXMgT0F1dGggY2xpZW50IGNyZWRlbnRpYWxzLA0KPGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZXJkdG1hbi1hY2UtcnBjYy8i IHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvPHdicj5kb2Mv ZHJhZnQtZXJkdG1hbi1hY2UtcnBjYy88L2E+Ljx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+V2Ug dGhpbmsgdGhpcyBpcyB2YWx1YWJsZSB0byB0aGUgQUNFIHdvcmsgc2luY2UgdGhlIEFDRSBmcmFt ZXdvcmsgaXMgYmFzZWQgb24gT0F1dGgsIGJ1dCBjbGllbnQgY3JlZGVudGlhbHMgYXMgZGVmaW5l ZCBpbiB0aGUgT0F1dGggZnJhbWV3b3JrIGFyZSBub3QgdGhlIGJlc3QgbWF0Y2ggZm9yIGVtYmVk ZGVkIGRldmljZXMuPHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5XZSB0aGluayBSYXcgUHVibGljIEtleXMgYW5kIFByZSBTaGFyZWQgS2V5cyBh cmUgbW9yZSBzdWl0YWJsZSBjcmVkZW50aWFscyBmb3IgZW1iZWRkZWQgZGV2aWNlcyBmb3IgdGhl IGZvbGxvd2luZyByZWFzb25zOjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+KiBCZXR0ZXIgc2VjdXJpdHkgYnkgYmluZGluZyB0byB0cmFuc3Bv cnQgbGF5ZXIuPHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4qIElmIFBTSyBEVExTIGlzIHRvIGJlIHVzZWQgYSBrZXkgbmVlZCB0byBiZSBkaXN0 cmlidXRlZCBhbnkgd2F5LCB3aHkgbm90IG1ha2UgdXNlIG9mIGl0IGFzIGNyZWRlbnRpYWwuPHU+ PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qIENs aWVudCBpZCBhbmQgY2xpZW50IHNlY3JldCBhY2NvbW1vZGF0ZXMgZm9yIG1hbnVhbCBpbnB1dCBi eSBhIGh1bWFucy4gVGhpcyBkb2VzIG5vdCBzY2FsZSB3ZWxsIGFuZCByZXF1aXJlcyBzb21lIGZv ciBvZiBpbnB1dCBkZXZpY2UuPHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4qIFNvbWUvbWFueSBkZXZpY2VzIHdpbGwgaGF2ZSBjcnlwdG8taGFy ZHdhcmUgdGhhdCBjYW4gcHJvdGVjdCBrZXkgbWF0ZXJpYWwsIHRvIG5vdCB1c2UgdGhhdCBwb3Nz aWJpbGl0eSB3b3VsZCBiZSBhIHdhc3RlLjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiBUaGVyZSBhcmUgcHJvYmFibHkgbW9yZSByZWFzb25z IHRoZXNlIHdhcyBqdXN0IHRoZSBvbmNlIG9uIHRvcCBvZiBteSBoZWFkLjx1PjwvdT48dT48L3U+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1 PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPlRoaXMgaXMgbm90IHRoZSBmaXJzdCByZXNlbnQgaW5pdGlhdGl2 ZSB0byBjcmVhdGUgbmV3IGNsaWVudCBjcmVkZW50aWFsIHR5cGVzLCB0aGUgT0F1dGggV0cgYWRv cHRlZCBhIHNpbWlsYXIgZHJhZnQgZm9yIGNlcnRpZmljYXRlIGJhc2VkIGNsaWVudCBjcmVkZW50 aWFscyAoPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1 dGgtbXRscy0wMC5odG1sIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sLzx3YnI+ZHJhZnQtaWV0Zi1vYXV0aC1tdGxzLTAwLmh0bWw8L2E+KTx3YnI+Lg0KIFRoYXQg d29yayBpcyBhbHNvIHZhbHVhYmxlIHRvIEFDRSBidXQgbm90IGFsbCBkZXZpY2VzIHdpbGwgYmUg YWJsZSB0byB3b3JrIHdpdGggY2VydGlmaWNhdGVzIG9yIGV2ZW4gYXN5bW1ldHJpYyBjcnlwdG9z IC48dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+UGxlYXNlIHJldmlldyBhbmQgY29tbWVudC48 dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNo ZWVyczx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Ly9TYW11ZWw8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHU+PC91PiZuYnNwOzx1Pjwv dT48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2PjxzcGFuPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxicj4N CjxzcGFuPk9BdXRoIG1haWxpbmcgbGlzdDwvc3Bhbj48YnI+DQo8c3Bhbj48YSBocmVmPSJtYWls dG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+DQo8c3Bhbj48 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjwvc3Bhbj48YnI+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_AM4PR09MB0627E138F244480420AD4949B0E10AM4PR09MB0627eurp_-- From nobody Mon May 15 11:46:30 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15C2B129BD1 for ; Mon, 15 May 2017 11:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfSKhJeti6AP for ; Mon, 15 May 2017 11:46:24 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e: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 B1F371243F6 for ; Mon, 15 May 2017 11:43:06 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id u187so64124611pgb.0 for ; Mon, 15 May 2017 11:43: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; bh=5bphGGnhq3yFnP8yldevBgNF6XNNxEY7nTnIztF4hnA=; b=LZ1EEVNleBdn9XQpY3tCkfAz/zfqkIjZp9ywkGyNAlmok0p4gmL41QVwLJFiWZ5bDC UCElKseLkVjq02jzuR31wkC7dXcCsDKzUQkTd4bk8wI4DMBDkAw2/utIQWQQCtAkR5DF GQ4MNbqJlPnscVR1pwE93vzBIhQsbC4HPEnfI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5bphGGnhq3yFnP8yldevBgNF6XNNxEY7nTnIztF4hnA=; b=PgZuF86RuxsdZH+fHqC2OICmejJTcrxPF/Wb7I3NCaD1dLHY6evSRPzjEc3oS7QIAF 0C55rUSMl+551Mt+Wqc7WAWzPR+rggsMMwOkirDFPqzVpMgcE75gG7jkR3LGCTOGSu6E ymKNOa+KBdVbGT/mBHohW2Rkormoj53mI5Dsbv9EcE8XFeQiJfOBecpukXfiK935a63A cdb6zcsSz/4FUb+1iO2YTHAfp5oZSU6b68WUPWE3VaOUzV6vGvQe2z7sw7aXq6ncsnt3 7wNJL8Tl34pLEB0DDAJAePizBnszE6JSr4DbsZA34EDHTwVkUf0NPiJB2QEHzpZCd/Ez xCUw== X-Gm-Message-State: AODbwcBqnyW8mAxPkUFjZD26646qkYeQlnKu/5fdhpUB5FqdAglS+/kH sLjLoKmTBxbM1FcziMzbJuoh+bkaK1Pl X-Received: by 10.84.212.15 with SMTP id d15mr10474498pli.51.1494873786269; Mon, 15 May 2017 11:43:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.154.205 with HTTP; Mon, 15 May 2017 11:42:35 -0700 (PDT) In-Reply-To: <698E4B80-754F-42E1-AD2B-602CD605C680@ve7jtb.com> References: <698E4B80-754F-42E1-AD2B-602CD605C680@ve7jtb.com> From: Brian Campbell Date: Mon, 15 May 2017 12:42:35 -0600 Message-ID: To: John Bradley Cc: "Manger, James" , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="f403045d202e03da60054f946d5c" Archived-At: Subject: Re: [OAUTH-WG] re comments on MTLS (was Re: Call for Adoption: Mutual TLS Profiles for OAuth Clients) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 18:46:30 -0000 --f403045d202e03da60054f946d5c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'll add text/clarification that the DN metadata fields being RFC4514 string representations of DNs in the next draft. Given that this is a profile of use and the metadata fields are just one way to express the binding of certificate and client, and after thinking about it some more and not wanting to introduce too many variations, I feel that keeping tls_client_auth_subject_dn as the subject distinguished name of the client certificate is more straightforward and sufficient for this case. Is there rough consensus to change "tls_client_auth_issuer_dn" to "tls_client_auth_root_dn" as was suggested? The latter name makes sense to me but I don't want to make that change without a little more input or buy-in from the WG. So please respond one way or the other, if you've got an opinion. Similarly I'm looking for some rough consensus around if a single root/issuer is sufficient in the metadata before potentially making any changes. Should "tls_client_auth_issuer/root_dn" remain a single DN string value or should it be an array allowing for more than one? On Fri, Apr 21, 2017 at 6:18 PM, John Bradley wrote: > I agree with Brian. > > Trying to do anything with PKIX opens up cans of worms. One of the > reasons we have resisted to this point. > > However there are server to server use cases that legitimately need this. > > I agree that in general DN is a mess, I suspect that telling people to > directly use the DER encoded version wont fly, so my thought was to use t= he > RFC 4514 string representation that most tools produce. > > We did talk about subject alt DNS Names, however those may not be present > in eIDAS certificates that some people may need to use for legal reasons, > or if it is present it might be an email. > > I suspect that users of this will fall into two camps. One that has a > small set of trusted CA that are configured out of band and any certifica= te > from those roots with the correct DN is OK. > > The other group will be trying to do something more dynamic with SSL > server certs (May or may not be EV) I could see those people preferring > DNS Name subject alt, or using JWKS to publish there certs. > > The problem is finding the right balance of flexibility without too many > options to confuse people. > > I am inclined towards DN for those that are willing to suffer the pain, > and JWKS_uri for everyone else. One advantage of the JWKS_URI approach = is > that self signed certs should work just fine, that is something that the > R&E people will want if they use this. > > For most proof of possession we should be promoting token binding as the > most flexible approach as it also works with mobile without per instance > registration. > > John B. > > > On Apr 21, 2017, at 7:41 PM, Brian Campbell > wrote: > > Thanks, James, for the adoption support as well as the review and > comments. I've tried to respond to the comments inline below. > > On Thu, Apr 20, 2017 at 11:33 PM, Manger, James < > James.H.Manger@team.telstra.com> wrote: > >> I support adoption of draft-campbell-oauth-mtls. >> >> Now some comments on the doc: >> >> 1. [=C2=A72.3] The syntax of tls_client_auth_subject_dn is not specified= . >> Perhaps LDAP's "String Representation of Distinguished Names" [RFC4514]? >> Perhaps a base64url-encoding of a DER-encoded DN? It would actually be >> better to allow any subjectAltName to be specified, instead of a DN. >> > > How about calling it tls_client_auth_subject and defining it as a string > and allowing it to represent the expected subject which could be in the > cert as the subject DN or a subjectAltName? For Subject DN and DN > subjectAltNames it would be the "String Representation of Distinguished > Names" and an appropriate string for the other subjectAltName types (I'll > have to look at what's there 'cause I don't know off hand and guidance or > suggested text is always more than welcome). > > > > >> 2. [=C2=A72.3] Change the name of tls_client_auth_issuer_dn (maybe >> tls_client_auth_root_dn). Given tls_client_auth_client_dn, it will be to= o >> easy to assume this pair refer to the issuer and subject fields of the c= ert. >> > > The accompanying text tries to make it clear that it's the root issuer bu= t > the tls_client_auth_issuer_dn name can certainly be changed to > tls_client_auth_root_dn or something along those lines, if folks think th= e > name in -01 is liable to cause confusion? > > > > PKI chains can be complex so the expected root might not be such a stable >> concept. For example, the Let's Encrypt CA chains to an ISRG Root and an >> IdenTrust DST Root [https://letsencrypt.org/certificates/]. >> > > The goal was to provide a metadata field to express some constraint for > what is kind of expected to be a common deployment of a number of entitie= s > participating in some OAuth API thing and are being issued certificates > from a common issuer for the group of participants. > > Perhaps it should be an array of strings rather than a single value? > > Or do you have suggestions for some alternative? > > > > >> 3. [=C2=A72.3] If a client dynamically registers a "jwks_uri" does this = mean >> the authz server MUST automatically cope when the client updates the key= (s) >> it publishes there? >> > > If the authz server supports that kind of trust model as well as > dynamically registration, then I would expect so, yes. > > > > >> 4. [=C2=A73] An access token is bound to a specific client certificate. = That >> is probably ok, but does mean all access tokens die when the client upda= tes >> their certificate (which could be every 2 months if using Let's Encrypt)= . >> This at least warrants a paragraph in the Security Considerations. >> > > In my own mind that was implied and okay because it's likely that access > tokens will have a shorter lifespan than certificates and refreshing or > getting a new access token is typically easy anyhow. > > Anyway, it doesn't hurt to be explicit about it, can you propose some suc= h > text for the Security Considerations? > > > > >> >> 5. [=C2=A73.1] "exp" and "nbf" values in the example need to be numbers,= not >> strings (drop the quotes). >> > > Silly mistake on my part. Thanks for catching that. Will fix. > > > >> >> 6. An access token linked to a client TLS cert isn't a bearer token. The >> spec should really define a new token_type for responses from the token >> endpoint. That might not necessarily mean we needs a new HTTP >> authentication scheme as well (it might just hint that "Bearer" wasn't >> quite the right name). >> > > Indeed "Bearer" isn't quite right and very likely a name that would be > different with the benefit of hindsight. But other than having names on t= he > wire that are more true to the nature of the tokens, I don't know that a > new token_type or HTTP auth scheme adds value to the use cases here. > However, they would likely make deployment of this stuff more cumbersome > and take longer. Whereas many systems can likely plug in mutual TLS on t= op > of the existing token_type and HTTP auth scheme without major changes. I'= m > strongly inclined to not introduce a new token_type and more inclined to > not do a new HTTP auth scheme. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --f403045d202e03da60054f946d5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'll add text/clarification that the DN meta= data fields being RFC4514 string representations of DNs in the next draft.<= br>
Given that this is a profile of use and the metadata fields ar= e just one way to express the binding of certificate and client, and after = thinking about it some more and not wanting to introduce too many variation= s, I feel that keeping tls_client_auth_subject_dn as the subject distinguis= hed name of the client certificate is more straightforward and sufficient f= or this case.

Is there rough consensus to change "tls_client_au= th_issuer_dn" to "tls_client_auth_root_dn" as was suggested= ? The latter name makes sense to me but I don't want to make that chang= e without a little more input or buy-in from the WG. So please respond one = way or the other, if you've got an opinion.=C2=A0

Similar= ly I'm looking for some rough consensus around if a single root/issuer = is sufficient in the metadata before potentially making any changes. Should= "tls_client_auth_issuer/root_dn" remain a single DN string value= or should it be an array allowing for more than one?



On Fri, A= pr 21, 2017 at 6:18 PM, John Bradley <ve7jtb@ve7jtb.com> wro= te:
I= agree with Brian.

Trying to do anything with PKIX opens= up cans of worms.=C2=A0 One of the reasons we have resisted to this point.=

However there are server to server use cases that= legitimately need this.

I agree that in general D= N is a mess, I suspect that telling people to directly use the DER encoded = version wont fly, so my thought was to use the RFC 4514 string representati= on that most tools produce.

We did talk about subj= ect alt DNS Names, however those may not be present in eIDAS certificates t= hat some people may need to use for legal reasons, or if it is present it m= ight be an email.

I suspect that users of this wil= l fall into two camps.=C2=A0 One that has a small set of trusted CA that ar= e configured out of band and any certificate from those roots with the corr= ect DN is OK.

The other group will be trying to do= something more dynamic with SSL server certs (May or may not be EV) =C2=A0= I could see those people preferring DNS Name subject alt, or using JWKS to= publish there certs.

The problem is finding the r= ight balance of flexibility without too many options to confuse people.

I am inclined towards DN for those that are willing t= o suffer the pain, and JWKS_uri for everyone else. =C2=A0 One advantage of = the JWKS_URI approach is that self signed certs should work just fine, that= is something that the R&E people will want if they use this. =C2=A0

For most proof of possession we should be promoting = token binding as the most flexible approach as it also works with mobile wi= thout per instance registration.

John B.


On Apr 21, 2017, at 7:41 PM, Brian Campbell <bcampbell@pingidentity.= com> wrote:

Thanks, = James, for the adoption support as well as the review and comments. I'v= e tried to respond to the comments inline below.

On Thu, Apr 20, 2017 at 11:33 PM, = Manger, James <James.H.Manger@team.telstra.com><= /span> wrote:
I suppor= t adoption of draft-campbell-oauth-mtls.

Now some comments on the doc:

1. [=C2=A72.3] The syntax of tls_client_auth_subject_dn is not specified. P= erhaps LDAP's "String Representation of Distinguished Names" = [RFC4514]? Perhaps a base64url-encoding of a DER-encoded DN? It would actua= lly be better to allow any subjectAltName to be specified, instead of a DN.=

How about calling it tls_client_auth_s= ubject and defining it as a string and allowing it to represent the expecte= d subject which could be in the cert as the subject DN or a subjectAltName?= For Subject DN and DN subjectAltNames it would be the "String Represe= ntation of Distinguished Names" and an appropriate string for the othe= r subjectAltName types (I'll have to look at what's there 'caus= e I don't know off hand and guidance or suggested text is always more t= han welcome).
=C2=A0



2. [=C2=A72.3] Change the name of tls_client_auth_issuer_dn (maybe tls_clie= nt_auth_root_dn). Given tls_client_auth_client_dn, it will be too easy to a= ssume this pair refer to the issuer and subject fields of the cert.

The accompanying text tries to make it clear t= hat it's the root issuer but the tls_client_auth_issuer_dn name can cer= tainly be changed to tls_client_auth_root_dn or something along those lines= , if folks think the name in -01 is liable to cause confusion?
=C2=A0


PKI chains can be complex so the expected root might not be such a stable c= oncept. For example, the Let's Encrypt CA chains to an ISRG Root and an= IdenTrust DST Root [https://letsencrypt.org/certificates= /].

The goal was to provide a metad= ata field to express some constraint for what is kind of expected to be a c= ommon deployment of a number of entities participating in some OAuth API th= ing and are being issued certificates from a common issuer for the group of= participants.

Perhaps it should be an array of strings = rather than a single value?

Or do you have suggestions fo= r some alternative?




3. [=C2=A72.3] If a client dynamically registers a "jwks_uri" doe= s this mean the authz server MUST automatically cope when the client update= s the key(s) it publishes there?

If the= authz server supports that kind of trust model as well as dynamically regi= stration, then I would expect so, yes.
=C2=A0



4. [=C2=A73] An access token is bound to a specific client certificate. Tha= t is probably ok, but does mean all access tokens die when the client updat= es their certificate (which could be every 2 months if using Let's Encr= ypt). This at least warrants a paragraph in the Security Considerations.

In my own mind that was implied and okay = because it's likely that access tokens will have a shorter lifespan tha= n certificates and refreshing or getting a new access token is typically ea= sy anyhow.

Anyway, it doesn't hurt to be explicit abo= ut it, can you propose some such text for the Security Considerations?
<= br>
=C2=A0

5. [=C2=A73.1] "exp" and "nbf" values in the example ne= ed to be numbers, not strings (drop the quotes).

<= /div>
Silly mistake on my part. Thanks for catching that. Will fix.
=C2=A0

6. An access token linked to a client TLS cert isn't a bearer token. Th= e spec should really define a new token_type for responses from the token e= ndpoint. That might not necessarily mean we needs a new HTTP authentication= scheme as well (it might just hint that "Bearer" wasn't quit= e the right name).

Indeed "Bearer&= quot; isn't quite right and very likely a name that would be different = with the benefit of hindsight. But other than having names on the wire that= are more true to the nature of the tokens, I don't know that a new tok= en_type or HTTP auth scheme adds value to the use cases here. However, they= would likely make deployment of this stuff more cumbersome and take longer= .=C2=A0 Whereas many systems can likely plug in mutual TLS on top of the ex= isting token_type and HTTP auth scheme without major changes. I'm stron= gly inclined to not introduce a new token_type and more inclined to not do = a new HTTP auth scheme.



_______________________________________________
OAuth mailing list<= br>OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth


--f403045d202e03da60054f946d5c-- From nobody Mon May 15 16:41:59 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D21129BE0; Mon, 15 May 2017 16:41:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Elwyn Davies To: Cc: draft-ietf-oauth-native-apps.all@ietf.org, ietf@ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149489171188.11868.13336890952697460283@ietfa.amsl.com> Date: Mon, 15 May 2017 16:41:51 -0700 Archived-At: Subject: [OAUTH-WG] Genart last call review of draft-ietf-oauth-native-apps-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 23:41:52 -0000 Reviewer: Elwyn Davies Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-oauth-native-apps-10 Reviewer: Elwyn Davies Review Date: 2017-05-15 IETF LC End Date: 2017-05-16 IESG Telechat date: 2017-05-25 Summary: Almost ready. A couple of simple minor issues could do with addressing. Major issues: None. Minor issues: s3: "browser":  The browser that acts as the Oauth user-agent is conflated with the user's choice of default browser.  Firstly this is not something that is discussed in RFC 6749.  Secondly, the concept of 'default browser' would normally be thought of by users as the browser that is used to display the content associated with hyperlinks rather than providing Oauth services.  I suggest that the implication in the body of the draft that 'the browser' is the user selected or system selected default browser needs to be at least discussed explicitly rather than buried in the terminology definitions in s3.  I wonder whether ths connection is something that should be made by a separate OS setting or a setting in each native app rather than conflated with the default browser.  The term "designated browser" might be useful. In all cases there might be secuity implications if a bad actor could subvert the designated browser setting. s8.1, Requirement of use of PKCE in some cases:  This strict requirement really needs to be introduced in the body of the discussion rather than buried in the seurity considerations. Nits/editorial comments: General: s/i.e./i.e.,/ (3 places) Title and Abstract: s/apps/applications/g  (uses before we get to terminology in s3) s1, para 1:  Suggest the following to make it clear that the definition is in RFC 6749 rather than here. OLD:  The OAuth 2.0 [RFC6749] authorization framework documents two approaches in Section 9 for native apps to interact with the authorization endpoint: an embedded user-agent, and an external user- agent. NEW: The OAuth 2.0 [RFC6749] authorization framework defines "native applications" in Section 9 of RFC 6749 (see also Section 3 below) and documents two approaches by whch they can interact with the authorization endpoint: an embedded user-agent, and an external user-agent.  END  s1, para 2: s/apps/applications/(2places) .  For second case: s/native apps/native applications (shortened to "native apps" or just "apps" hereafter)/ s3, "native app": s/app/application/g in the definition.  After that in the document "[native] app" is fine except for the definitions mentioned in the next comment. Worth repeating the link to Section 9 of RFC 6749. s3, All definitions after "app"; s/app/application/g in the definitions as these are not restricted to (native) apps as defined here. s3, "embedded user-agent": s/modify/modifyng/ s4, last para: s/emcompasses/encompasses/ s4, last para: s/inter-process/inter-app/ (since this term is defined) s4, last para: Might be worth pointing to the 'SHOULD' about client type assumptions in s2.1 of RFC 6749 withe reference to servers that do make assumptions. s4.1, para below figure 1: s/system browser/browser/ (or maybe "designated browser"). s5, paras 1 and  2: Reword to clarify and remove 'we gain' usage (not allowed in RFCs): OLD:    Just as URIs are used for OAuth 2.0 [RFC6749] on the web to initiate    the authorization request and return the authorization response to    the requesting website, URIs can be used by native apps to initiate    the authorization request in the device's browser and return the    response to the requesting native app.    By applying the same principles from the web to native apps, we gain    benefits seen on the web, like the usability of a single sign-on    session and the security of a separate authentication context.  It    also reduces the implementation complexity by reusing similar flows    as the web, and increases interoperability by relying on standards-    based web flows that are not specific to a particular platform. NEW:    Just as URIs are used for OAuth 2.0 [RFC6749] in the HTTP protocol on the web to initiate    the authorization request and return the authorization response to    the requesting website, URIs can be used by native apps to initiate    the authorization request in the device's browser and return the    response to the requesting native app.    By extending the techniques from the web to native apps, the    benefits gained in the web context will also be reaped when using     OAuth with native apps; benefits include the usability of a single sign-on    session and the security of a separate authentication context.  Use of    the techniques also reduces implementation complexity by reusing similar flows    to those employed on the web, and increases interoperability by relying on standards-    based web flows that are not specific to a particular platform. END s5, para 3: Suggest prefixing this para with: "To conform to this best practise," - the MUST is not derived from RFC 6749. s7.1, last para: s/URI like it/URI as it/; s/like normal/as it would normally/ s7.2, next to last para: OLD: Due to this reason, they SHOULD be used over the other redirect choices for native apps where possible. NEW: For this reason, they SHOULD be used in preference to the other redirect options for native apps where possible. END s7.2, last para: s/it REQUIRED/it is REQUIRED/ s8.1, para 2: Need to expand acronym PKCE at first use (currently expanded in para 4). s8.1, para 4: s/sends data/send data/ s8.2: It would be more consistent with RFC 6749 to refer to "Implicit Flow" as "Implicit Grant authorization flow" at least for the title and first occurrence.   The second and third occurrences in para 1 should s/Implicit Flow/implicit flow/ for consistency with para 2. s8.2, para 2: s/code flow/Authorization Code Grant flow/ s8.3, last para: Is a reminder to choose the 'right' type of IP literal (IPv4 or v6) desirable?  Doing an address lookup on "localhost" presumably tells you which one to use! [perhaps?] s8.7, para 4: s/like/such as/ s8.8; need to expand CSRF (Cross Site Request Forgery) and maybe explain a it how CSRGF and the cross-app case are related From nobody Thu May 18 11:14:20 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0EA7127599 for ; Thu, 18 May 2017 11:14:17 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bx-Pz5qgHz2d for ; Thu, 18 May 2017 11:14:16 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e: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 3AABD12EB28 for ; Thu, 18 May 2017 11:08:48 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id u28so26393293pgn.1 for ; Thu, 18 May 2017 11:08:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BRUVpZLUJEbNWNqIZaA6GIUCHa2SAn9I1LH5iTZUCWM=; b=lOmCC+/e3XINuIueaWyHUzN11kNi9v1ixCP3q5/BQz1umLCa735AHuRDvsXeRcnYA7 sQGBCiikr9aQnFSXBQlxZZ/hexg1Baol/CYUjZfh2hVo2yLOx+2b/HH5Hd3ZaIW0fNmb rx2TSIxxmT+i81WbBXk76Z5bSen2wskqFMcRtpWAdCRT3XsIGi+OuKRISksZmkF2vCZB XrejUdP1tn4+KxTh9cWusJoLgbpSdsQKHGpVi8DLlOljOJNXY9PN2KZ4m6b/2wBxa+W5 qkjGj6xXir5nVyGrYvC74ZtJmR4Y1++QTjuvS5PriwTdvqIkSaCMHNp2mQyeJlLKVyNi vdAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BRUVpZLUJEbNWNqIZaA6GIUCHa2SAn9I1LH5iTZUCWM=; b=VXdFic5gcaGFmDGecFawUPVVjAvIfEmtU0qpgYLDb/gsjNJd7vCn0pClL0l2YOSW5p AbMPmG3luuDMtBGSI73VT9Ill7GM2ThjvR9IjP9+0/HAGSLffSRFQnWD5K3ZACZLoGkR K3FOr/7mLt2kNfwCz7SeLJfcPW3/9gEuVSjF+4Yw7gqIc68bnHAif2/NJx30/i0sC3yz qpY2h/J9D42Y8q9c100cSb5bRWR/9m9mH5U2LCLI/nNblttTpGRmvZpP5eFtMLBCYHTj 9QUD9spChu5kHEFDzIMuqVqiGdMtCM8rxoNXiVlDCgUoaRfQydFBH7phmzFrAkzNYw68 xwMQ== X-Gm-Message-State: AODbwcC3xy3j4V015AYUkl1VQTAtxCE3v7MOq6U1G1wWbmdU3AJickbv uzlRpZ9Cj2ozY53Eq6J3gWR4DNy78g== X-Received: by 10.99.96.3 with SMTP id u3mr5747603pgb.69.1495130927792; Thu, 18 May 2017 11:08:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.186.135 with HTTP; Thu, 18 May 2017 11:08:07 -0700 (PDT) In-Reply-To: References: From: Kathleen Moriarty Date: Thu, 18 May 2017 14:08:07 -0400 Message-ID: To: William Denniss Cc: "oauth@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-native-apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 18:14:18 -0000 Hi, Will there be a new document posted today/tomorrow to address last call comments/the GenART review? I'd like to add the ballot for the IESG review and telechat next week, , but it would be best on the updated draft to avoid duplicate comments. Thank you, Kathleen On Tue, May 2, 2017 at 2:34 PM, Kathleen Moriarty wrote: > Hi William, > > Thank you for making the updates. Just a few notes inline and I'll > kick off IETF last call. > > On Wed, Apr 26, 2017 at 5:50 PM, William Denniss wrote: >> Thank you for your review Kathleen. >> >> Version 10 which addresses your comments is out: >> https://tools.ietf.org/html/draft-ietf-oauth-native-apps-10 >> >> Replies inline: >> >> On Mon, Apr 24, 2017 at 6:47 PM, Kathleen Moriarty >> wrote: >>> >>> Hello, >>> >>> Thanks for taking the time to document this best practice and the >>> implementations in the appendix. I have one comment and a few nits. >>> >>> Security Considerations: >>> I think it would go a long way to organize these as ones that apply to >>> this best practice and ones (8.1 and the example in 8.2) about >>> alternate solutions. This could also be done through some added text, >>> but making this clear would be helpful. Maybe moving 8.1 and 8.2 >>> until after the rest of the sections would be enough and then clearly >>> state the intent of this text. >> >> >> Good idea, I think that will help with the readability a lot. I have moved >> the "Embedded User-Agent" section to the end, and clarified the purpose. >> >> The reason it's included at all, is that OAuth itself documents two ways to >> do native OAuth. This document recommends only one of those ways, and I >> thought that detailing why the other way is no longer best-practice would be >> helpful to readers. > > Great, thank you. >> >>> IANA Section: >>> Just a note - you might get some questions about this, but i do think >>> it's fine to leave that text, although unnecessary. >>> >> >> I think I may have mis-read https://tools.ietf.org/html/rfc5226#section-6.1. >> There is an example of a document that has no IANA actions but still >> provides a justification for why that is the case, but in that example it >> uses a non-IANA registry unlike this BCP. >> >> In our case, we are definitely operating in an IANA-controlled namespace, >> but using a private section of the namespace designed for that purpose. The >> intent was to point out that we are following IANA guidelines correctly. >> Happy to remove it (or indicate that it should be removed during >> publication) if it seems superfluous. >> >> For now, in the latest update I have clearly stated "This document has no >> IANA actions.", but retained the discussion. >> > > Sounds good, thank you! > >>> >>> Nits: >>> Section 5, punctuation >>> OLD: >>> By applying the same principles from the web to native apps, we gain >>> benefits seen on the web like the usability of a single sign-on >>> session, and the security of a separate authentication context. >>> NEW: >>> By applying the same principles from the web to native apps, we gain >>> benefits seen on the web, like the usability of a single sign-on >>> session and the security of a separate authentication context. >> >> >> Fixed. >> >>> >>> The document has text that says 'native app' in some places and 'app' >>> in others, I assume these are used interchangeably? It seems that >>> they are used interchangeably. >> >> >> Yes, they are. In the definition section, "app" is defined as "shorthand for >> native app". Is that OK, or should I revise? > > I missed that, but if it's defined, then you are covered. Thanks. > >> >>> >>> Really nitty: >>> Section 7.2, >>> Since you are still in the example, did you mean URL in the following: >>> >>> Such claimed HTTPS URIs can be used as OAuth redirect URIs. >>> Such claimed HTTPS URLs can be used as OAuth redirect URIs. >> >> >> I have migrated to use URI exclusively, other than 2 references to URL where >> I'm referring to platform-specific naming / colloquialisms. >> >> I also changed instances of "custom URI scheme" to "private-use URI scheme", >> the latter being the terminology used by RFC7595. > > Perfect, thanks. The point in asking was just for other reviews that > will follow. > >> >>> And again in the last paragraph of this section. >>> >>> I'm only asking since you specify URL earlier in this section, so you >>> were more specific for the example and then drop back to URI (which is >>> correct, but wondering if you wanted to continue at the same level of >>> specificity or if there was a reason to just say URI here. >> >> >> I believe this is addressed now. >> >>> Section 8.11 >>> s/uri/URI/ >>> > Thank you. >> >> Fixed. >> >> Best, >> William >> >>> >>> >>> -- >>> >>> Best regards, >>> Kathleen >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> > > > > -- > > Best regards, > Kathleen -- Best regards, Kathleen From nobody Thu May 18 11:56:00 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF681293EE for ; Thu, 18 May 2017 11:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wruw_z2ceXOi for ; Thu, 18 May 2017 11:55:55 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e: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 DF4BB129B2B for ; Thu, 18 May 2017 11:50:36 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id u187so26827356pgb.0 for ; Thu, 18 May 2017 11:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:mime-version; bh=N6+vWs7BNWUi+mMO9/1uSNxnirUkasqDkbUV+eIofyo=; b=ITP5MjCYF584JHk1qR77//OSg1UfeRcME1Oe4ZVk1FkWeAT7G3gqu2dJ9PqK/3Pz6a BzQiODzJMnHqZv1+5Tu/LQFjP7xcDlEj5TPv34oXZaAfcch/o5bUQlcH/dlv4iHP+K7W KzceIYqGnAjVcJZFk7Iqgjg7VwRg+7PV1rKPrSQh814fd9pLIqmAaWzLHjHMeFtmif9Q V05246J/vktdpXRpjwBeJRVgW72gs40y0qOTD/l73C7LP+pyhg2tTudL7fwdmBNlp3HR 6ZPkH23LkEF4dGWjQ4WAk8rwNwwTbNwAaA2hcUqx9jfqw2a6V51bfKK5hqDnXD241koM MpJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:mime-version; bh=N6+vWs7BNWUi+mMO9/1uSNxnirUkasqDkbUV+eIofyo=; b=hWHJtC1swPGu4Il0vQddZikaM+ntlGiSw2/6bJOIcdK4uTgA85jkcroDeoepTL77IF t2U9P/8XBCmDU8NX/m1JVWKSEeHimxwyE6RKdfIfQ4hEtec3O8DGKOROO8/2fJZfd8lB eCH3oVDTZp1Kmi6ct+83bx20cRNRFDx43BwOF2StzZ0cusFwrNRVlnWU8iekruOMTj3U DerOl+nBxDOF2H3co/irMlt2TpseNSrUKJWsXSt/iUOPdxEId4IeAY/fpFKMSnRV4w9b QTXfnT6JKUAe+p/7soheD45PaWMmxWAI+BjTfw2uhVFJ9gPzF2OhH+wv1ysjD7VZUCIn /aSg== X-Gm-Message-State: AODbwcCiySpu0cZLTjpUgRA2kUnNGn4sVDw+rZ/zLnaiBE4LhA7aeVbI NMAJ7lWRT9kkir/9 X-Received: by 10.98.90.199 with SMTP id o190mr983782pfb.185.1495133436304; Thu, 18 May 2017 11:50:36 -0700 (PDT) Received: from MWHPR19MB1085.namprd19.prod.outlook.com ([40.97.141.109]) by smtp.gmail.com with ESMTPSA id p84sm11211904pfi.25.2017.05.18.11.50.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 18 May 2017 11:50:35 -0700 (PDT) From: John Bradley To: Kathleen Moriarty , William Denniss CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] AD review of draft-ietf-oauth-native-apps Thread-Index: AXdnWnky8DIFdWBESMY4VjWdM1kiRmctUDV3UTVaRy13VWZZOa1TmT23 X-MS-Exchange-MessageSentRepresentingType: 2 Date: Thu, 18 May 2017 18:48:36 +0000 Message-ID: References: , In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c03b00a611b96054fd0e1a2" Archived-At: Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-native-apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 18:55:58 -0000 --94eb2c03b00a611b96054fd0e1a2 Content-Language: en-CA Content-Type: multipart/alternative; boundary="_000_MWHPR19MB108559BA79F3460C01F54E40FAE40MWHPR19MB1085namp_" --_000_MWHPR19MB108559BA79F3460C01F54E40FAE40MWHPR19MB1085namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable William and I just discussed it and the goal is to get a new draft out addr= essing those comments today or tomorrow. John B. Sent from Mail for Window= s 10 From: Kathleen Moriarty Sent: May 18, 2017 2:14 PM To: William Denniss Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-native-apps Hi, Will there be a new document posted today/tomorrow to address last call comments/the GenART review? I'd like to add the ballot for the IESG review and telechat next week, , but it would be best on the updated draft to avoid duplicate comments. Thank you, Kathleen On Tue, May 2, 2017 at 2:34 PM, Kathleen Moriarty wrote: > Hi William, > > Thank you for making the updates. Just a few notes inline and I'll > kick off IETF last call. > > On Wed, Apr 26, 2017 at 5:50 PM, William Denniss wr= ote: >> Thank you for your review Kathleen. >> >> Version 10 which addresses your comments is out: >> https://tools.ietf.org/html/draft-ietf-oauth-native-apps-10 >> >> Replies inline: >> >> On Mon, Apr 24, 2017 at 6:47 PM, Kathleen Moriarty >> wrote: >>> >>> Hello, >>> >>> Thanks for taking the time to document this best practice and the >>> implementations in the appendix. I have one comment and a few nits. >>> >>> Security Considerations: >>> I think it would go a long way to organize these as ones that apply to >>> this best practice and ones (8.1 and the example in 8.2) about >>> alternate solutions. This could also be done through some added text, >>> but making this clear would be helpful. Maybe moving 8.1 and 8.2 >>> until after the rest of the sections would be enough and then clearly >>> state the intent of this text. >> >> >> Good idea, I think that will help with the readability a lot. I have mov= ed >> the "Embedded User-Agent" section to the end, and clarified the purpose. >> >> The reason it's included at all, is that OAuth itself documents two ways= to >> do native OAuth. This document recommends only one of those ways, and I >> thought that detailing why the other way is no longer best-practice woul= d be >> helpful to readers. > > Great, thank you. >> >>> IANA Section: >>> Just a note - you might get some questions about this, but i do think >>> it's fine to leave that text, although unnecessary. >>> >> >> I think I may have mis-read https://tools.ietf.org/html/rfc5226#section-= 6.1. >> There is an example of a document that has no IANA actions but still >> provides a justification for why that is the case, but in that example i= t >> uses a non-IANA registry unlike this BCP. >> >> In our case, we are definitely operating in an IANA-controlled namespace= , >> but using a private section of the namespace designed for that purpose. = The >> intent was to point out that we are following IANA guidelines correctly. >> Happy to remove it (or indicate that it should be removed during >> publication) if it seems superfluous. >> >> For now, in the latest update I have clearly stated "This document has n= o >> IANA actions.", but retained the discussion. >> > > Sounds good, thank you! > >>> >>> Nits: >>> Section 5, punctuation >>> OLD: >>> By applying the same principles from the web to native apps, we gain >>> benefits seen on the web like the usability of a single sign-on >>> session, and the security of a separate authentication context. >>> NEW: >>> By applying the same principles from the web to native apps, we gain >>> benefits seen on the web, like the usability of a single sign-on >>> session and the security of a separate authentication context. >> >> >> Fixed. >> >>> >>> The document has text that says 'native app' in some places and 'app' >>> in others, I assume these are used interchangeably? It seems that >>> they are used interchangeably. >> >> >> Yes, they are. In the definition section, "app" is defined as "shorthand= for >> native app". Is that OK, or should I revise? > > I missed that, but if it's defined, then you are covered. Thanks. > >> >>> >>> Really nitty: >>> Section 7.2, >>> Since you are still in the example, did you mean URL in the following: >>> >>> Such claimed HTTPS URIs can be used as OAuth redirect URIs. >>> Such claimed HTTPS URLs can be used as OAuth redirect URIs. >> >> >> I have migrated to use URI exclusively, other than 2 references to URL w= here >> I'm referring to platform-specific naming / colloquialisms. >> >> I also changed instances of "custom URI scheme" to "private-use URI sche= me", >> the latter being the terminology used by RFC7595. > > Perfect, thanks. The point in asking was just for other reviews that > will follow. > >> >>> And again in the last paragraph of this section. >>> >>> I'm only asking since you specify URL earlier in this section, so you >>> were more specific for the example and then drop back to URI (which is >>> correct, but wondering if you wanted to continue at the same level of >>> specificity or if there was a reason to just say URI here. >> >> >> I believe this is addressed now. >> >>> Section 8.11 >>> s/uri/URI/ >>> > Thank you. >> >> Fixed. >> >> Best, >> William >> >>> >>> >>> -- >>> >>> Best regards, >>> Kathleen >>> >>> _______________________________________________ >>> 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 --_000_MWHPR19MB108559BA79F3460C01F54E40FAE40MWHPR19MB1085namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

William and I just discussed it and the goal is to g= et a new draft out addressing those comments today or tomorrow.

 

John B.

 

 

Sent from Mail for Windows 10

 

From: Kathleen Moriarty
Sent: May 18, 2017 2:14 PM
To: William Denniss
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-native-apps

 

Hi,

Will there be a new document posted today/tomorrow to address last
call comments/the GenART review?  I'd like to add the ballot for the IESG review and telechat next week, , but it would be best on the
updated draft to avoid duplicate comments.

Thank you,
Kathleen

On Tue, May 2, 2017 at 2:34 PM, Kathleen Moriarty
<kathleen.moriarty.ietf@gmail.com> wrote:
> Hi William,
>
> Thank you for making the updates.  Just a few notes inline and I'= ll
> kick off IETF last call.
>
> On Wed, Apr 26, 2017 at 5:50 PM, William Denniss <wdenniss@google.c= om> wrote:
>> Thank you for your review Kathleen.
>>
>> Version 10 which addresses your comments is out:
>> https://tools.ietf.org/html/draft-ietf-oauth-native-apps-10
>>
>> Replies inline:
>>
>> On Mon, Apr 24, 2017 at 6:47 PM, Kathleen Moriarty
>> <kathleen.moriarty.ietf@gmail.com> wrote:
>>>
>>> Hello,
>>>
>>> Thanks for taking the time to document this best practice and = the
>>> implementations in the appendix. I have one comment and a few = nits.
>>>
>>> Security Considerations:
>>> I think it would go a long way to organize these as ones that = apply to
>>> this best practice and ones (8.1 and the example in 8.2) about=
>>> alternate solutions.  This could also be done through som= e added text,
>>> but making this clear would be helpful.  Maybe moving 8.1= and 8.2
>>> until after the rest of the sections would be enough and then = clearly
>>> state the intent of this text.
>>
>>
>> Good idea, I think that will help with the readability a lot. I ha= ve moved
>> the "Embedded User-Agent" section to the end, and clarif= ied the purpose.
>>
>> The reason it's included at all, is that OAuth itself documents tw= o ways to
>> do native OAuth. This document recommends only one of those ways, = and I
>> thought that detailing why the other way is no longer best-practic= e would be
>> helpful to readers.
>
> Great, thank you.
>>
>>> IANA Section:
>>> Just a note - you might get some questions about this, but i d= o think
>>> it's fine to leave that text, although unnecessary.
>>>
>>
>> I think I may have mis-read https://tools.ietf.org/html/rfc5226#section-6.1.
>> There is an example of a document that has no IANA actions but sti= ll
>> provides a justification for why that is the case, but in that exa= mple it
>> uses a non-IANA registry unlike this BCP.
>>
>> In our case, we are definitely operating in an IANA-controlled nam= espace,
>> but using a private section of the namespace designed for that pur= pose.  The
>> intent was to point out that we are following IANA guidelines corr= ectly.
>> Happy to remove it (or indicate that it should be removed during >> publication) if it seems superfluous.
>>
>> For now, in the latest update I have clearly stated "This doc= ument has no
>> IANA actions.", but retained the discussion.
>>
>
> Sounds good, thank you!
>
>>>
>>> Nits:
>>> Section 5, punctuation
>>> OLD:
>>>    By applying the same principles from the web= to native apps, we gain
>>>    benefits seen on the web like the usability = of a single sign-on
>>>    session, and the security of a separate auth= entication context.
>>> NEW:
>>>    By applying the same principles from the web= to native apps, we gain
>>>    benefits seen on the web, like the usability= of a single sign-on
>>>    session and the security of a separate authe= ntication context.
>>
>>
>> Fixed.
>>
>>>
>>> The document has text that says 'native app' in some places an= d 'app'
>>> in others, I assume these are used interchangeably?  It s= eems that
>>> they are used interchangeably.
>>
>>
>> Yes, they are. In the definition section, "app" is defin= ed as "shorthand for
>> native app". Is that OK, or should I revise?
>
> I missed that, but if it's defined, then you are covered.  Thanks= .
>
>>
>>>
>>> Really nitty:
>>> Section 7.2,
>>> Since you are still in the example, did you mean URL in the fo= llowing:
>>>
>>> Such claimed HTTPS URIs can be used as OAuth redirect URIs. >>> Such claimed HTTPS URLs can be used as OAuth redirect URIs. >>
>>
>> I have migrated to use URI exclusively, other than 2 references to= URL where
>> I'm referring to platform-specific naming / colloquialisms.
>>
>> I also changed instances of "custom URI scheme" to "= ;private-use URI scheme",
>> the latter being the terminology used by RFC7595.
>
> Perfect, thanks.  The point in asking was just for other reviews = that
> will follow.
>
>>
>>> And again in the last paragraph of this section.
>>>
>>> I'm only asking since you specify URL earlier in this section,= so you
>>> were more specific for the example and then drop back to URI (= which is
>>> correct, but wondering if you wanted to continue at the same l= evel of
>>> specificity or if there was a reason to just say URI here.
>>
>>
>> I believe this is addressed now.
>>
>>> Section 8.11
>>> s/uri/URI/
>>>
> Thank you.
>>
>> Fixed.
>>
>> Best,
>> William
>>
>>>
>>>
>>> --
>>>
>>> Best regards,
>>> Kathleen
>>>
>>> _______________________________________________
>>> 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.or= g/mailman/listinfo/oauth

 

--_000_MWHPR19MB108559BA79F3460C01F54E40FAE40MWHPR19MB1085namp_-- --94eb2c03b00a611b96054fd0e1a2 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIMD5OiJ2SWBihYRnOvtjlhrceXil NAvv8/ZZNJO347hKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDUxODE4NTAzNlowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQAK/IEsHuOYt7Xwex2k0LZ0m+a6QEZPDEY0DkeVZvZ9FfKi /78MOHg4LdzMK+jCQ0QdHXCr1nHiLbmuPANl7ETUkvngucI+Q41g9BjvnVJ4IFG9onNmaxvzRpe2 7BacBuV53mteiZt497FzcuRddKSYL/Yf3oH0v1SH54I6WvfQ1YDK/GTRrwFnPu82AEkoalmKIulP Dfq2QcM4KyIKoypSLuGkOd3fmu1hykFWotaBTQBhKHP5PyIG4OlGwIYAM4OY6A4r1GTxOK3ftAXJ EOpVX1x0bw1ESDygA+KQuH4TIB1aO71TYtPnXuBLDmmWtLjmFWfc4cDZA+kpna9322S8 --94eb2c03b00a611b96054fd0e1a2-- From nobody Thu May 18 12:04:08 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9AC129488 for ; Thu, 18 May 2017 12:04:07 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kAoId1TLzI1 for ; Thu, 18 May 2017 12:04:04 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-oln040092069097.outbound.protection.outlook.com [40.92.69.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03667129B1E for ; Thu, 18 May 2017 11:58:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=n1bHFEj1Wu7QDjrGFSeuB70y2pZXY4KEwcE7fkqHxPw=; b=ZVOHrfh/U6yd78PUSstDEt9vuMBlykUQPxMOT+h9dBcpeSb+izAL5XY39xoE0X32r8iM3TadrudDkuJ2Q6p2ozHVLjcPcJ9EAdtS9J92Pqpv8yEk+Gha0h5/9mN+2/s4m/4S23c7RpMvudFLrYgUYoqAOurTcaVJ8wWSgeEwwTe1tfZyLLXX1D3sFlhOXmc4608fAZEEp+5MV9K5RPLPoQvTSTgidZ8kV0IlpZsgkOoAC9dZL4bGJkKCvwJr8d5nef5PhPszJildCHHrFKJmdFId+47Ewa53SPs4El2ZbTyDeLNjshfIZ0E8mjYB6py5nWLnnI9NB4MN/WNqjuRrsA== Received: from HE1EUR02FT047.eop-EUR02.prod.protection.outlook.com (10.152.10.60) by HE1EUR02HT160.eop-EUR02.prod.protection.outlook.com (10.152.11.89) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1075.5; Thu, 18 May 2017 18:58:30 +0000 Received: from AM4PR09MB0627.eurprd09.prod.outlook.com (10.152.10.54) by HE1EUR02FT047.mail.protection.outlook.com (10.152.11.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.5 via Frontend Transport; Thu, 18 May 2017 18:58:30 +0000 Received: from AM4PR09MB0627.eurprd09.prod.outlook.com ([fe80::b562:3:99a7:9530]) by AM4PR09MB0627.eurprd09.prod.outlook.com ([fe80::b562:3:99a7:9530%14]) with mapi id 15.01.1084.030; Thu, 18 May 2017 18:58:30 +0000 From: Adrian Imach To: John Bradley CC: Kathleen Moriarty , William Denniss , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] AD review of draft-ietf-oauth-native-apps Thread-Index: AQHS0AKqdkdgJQJ8CEq0ZYjKm3dLJaH6brEAgAACwf4= Date: Thu, 18 May 2017 18:58:29 +0000 Message-ID: References: , , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ve7jtb.com; dkim=none (message not signed) header.d=none;ve7jtb.com; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:D12048D0F44B4DFF956AFF2913D115064146C6894E7CB7926A3EB841FBE3FCE8; UpperCasedChecksum:DFE4D84004207BC76728DB66657DB97257F8F639B137636B42BB6D4ADDE25441; SizeAsReceived:8707; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [ELJfNLiP02BxQqoHVbwQeGO1iGyjqahB] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1EUR02HT160; 5:B4wGzCSpiEESIUJ/z6xPLqcdyNMh1/IKoygoY8GKwoyZd8pwqneyxXIVt61kORL02ir9TyjoxSNjdIcjVCP3xlY4v5j9dMRTziXknQBo8cI1O39pleelMi3I43tlriNseJXsb+CmlsBW2CKJsNU33Q==; 24:pBGtgneizKzZulu797AoIj1s5Ol0bCfiwE9JDrLV8i8wE7C7GfVpOKrLA6fkj0wdutYUH7dIuPfVH8waakHnuTzRnc0cEmZwNj2o9QjgVEQ=; 7:PQMQyjl9qyBSL0SkiZZccNOBK+c1haJlTvHL/ux3GYEV9PsKS6rGD9LSCIZjCOc9JraKwfcDYOfR9pEEncJPgL8eLih89EFRidJfsAY0f9oHEPvvDV9bYm6luFDnwwSxQxahXxAvKSWZYaMd2HvLY6176W8r0cOAnFtyKrx1OZN4a35ic2O5Xb9e04zGdSsYjYSrxd5aJlppWLRYq+/MfT/PhCjnJA/0zC1hOSqkybxqxAcArc1lvfksU2p1XQybcoi/DnGlbAAv/hYiNkbBXs+4NIeks95lb1faiOVbow1mwcijXDZso7im6SA7HL9N x-incomingheadercount: 46 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:HE1EUR02HT160; H:AM4PR09MB0627.eurprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 8d113149-7f70-4a9a-b423-08d49e1fdfba x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322274)(1601125374)(1603101448)(1701031045); SRVR:HE1EUR02HT160; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:HE1EUR02HT160; BCL:0; PCL:0; RULEID:; SRVR:HE1EUR02HT160; x-forefront-prvs: 0311124FA9 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR09MB0627D050138C01F0CB408DBAB0E40AM4PR09MB0627eurp_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2017 18:58:29.8780 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1EUR02HT160 Archived-At: Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-native-apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 19:04:07 -0000 --_000_AM4PR09MB0627D050138C01F0CB408DBAB0E40AM4PR09MB0627eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgLA0KDQpDYW4gSSBhc2sgb25lIG1vcmUgdGltZSB0byB1bnN1YnNjcmliZSBtZSBmcm9tIHlv dXIgbWFpbGluZyBsaXN0LiBUaGFuayB5b3UuDQoNCkFkcmlhbiBJbWFjaA0KDQpPbiAxOCBNYXkg MjAxNywgYXQgMTk6NTYsIEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZl N2p0YkB2ZTdqdGIuY29tPj4gd3JvdGU6DQoNCldpbGxpYW0gYW5kIEkganVzdCBkaXNjdXNzZWQg aXQgYW5kIHRoZSBnb2FsIGlzIHRvIGdldCBhIG5ldyBkcmFmdCBvdXQgYWRkcmVzc2luZyB0aG9z ZSBjb21tZW50cyB0b2RheSBvciB0b21vcnJvdy4NCg0KSm9obiBCLg0KDQoNClNlbnQgZnJvbSBN YWlsPGh0dHBzOi8vZ28ubWljcm9zb2Z0LmNvbS9md2xpbmsvP0xpbmtJZD01NTA5ODY+IGZvciBX aW5kb3dzIDEwDQoNCkZyb206IEthdGhsZWVuIE1vcmlhcnR5PG1haWx0bzprYXRobGVlbi5tb3Jp YXJ0eS5pZXRmQGdtYWlsLmNvbT4NClNlbnQ6IE1heSAxOCwgMjAxNyAyOjE0IFBNDQpUbzogV2ls bGlhbSBEZW5uaXNzPG1haWx0bzp3ZGVubmlzc0Bnb29nbGUuY29tPg0KQ2M6IG9hdXRoQGlldGYu b3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEFEIHJl dmlldyBvZiBkcmFmdC1pZXRmLW9hdXRoLW5hdGl2ZS1hcHBzDQoNCkhpLA0KDQpXaWxsIHRoZXJl IGJlIGEgbmV3IGRvY3VtZW50IHBvc3RlZCB0b2RheS90b21vcnJvdyB0byBhZGRyZXNzIGxhc3QN CmNhbGwgY29tbWVudHMvdGhlIEdlbkFSVCByZXZpZXc/ICBJJ2QgbGlrZSB0byBhZGQgdGhlIGJh bGxvdCBmb3IgdGhlDQpJRVNHIHJldmlldyBhbmQgdGVsZWNoYXQgbmV4dCB3ZWVrLCAsIGJ1dCBp dCB3b3VsZCBiZSBiZXN0IG9uIHRoZQ0KdXBkYXRlZCBkcmFmdCB0byBhdm9pZCBkdXBsaWNhdGUg Y29tbWVudHMuDQoNClRoYW5rIHlvdSwNCkthdGhsZWVuDQoNCk9uIFR1ZSwgTWF5IDIsIDIwMTcg YXQgMjozNCBQTSwgS2F0aGxlZW4gTW9yaWFydHkNCjxrYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdt YWlsLmNvbTxtYWlsdG86a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToN Cj4gSGkgV2lsbGlhbSwNCj4NCj4gVGhhbmsgeW91IGZvciBtYWtpbmcgdGhlIHVwZGF0ZXMuICBK dXN0IGEgZmV3IG5vdGVzIGlubGluZSBhbmQgSSdsbA0KPiBraWNrIG9mZiBJRVRGIGxhc3QgY2Fs bC4NCj4NCj4gT24gV2VkLCBBcHIgMjYsIDIwMTcgYXQgNTo1MCBQTSwgV2lsbGlhbSBEZW5uaXNz IDx3ZGVubmlzc0Bnb29nbGUuY29tPG1haWx0bzp3ZGVubmlzc0Bnb29nbGUuY29tPj4gd3JvdGU6 DQo+PiBUaGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3IEthdGhsZWVuLg0KPj4NCj4+IFZlcnNpb24g MTAgd2hpY2ggYWRkcmVzc2VzIHlvdXIgY29tbWVudHMgaXMgb3V0Og0KPj4gaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtbmF0aXZlLWFwcHMtMTANCj4+DQo+PiBS ZXBsaWVzIGlubGluZToNCj4+DQo+PiBPbiBNb24sIEFwciAyNCwgMjAxNyBhdCA2OjQ3IFBNLCBL YXRobGVlbiBNb3JpYXJ0eQ0KPj4gPGthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPG1h aWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KPj4+DQo+Pj4g SGVsbG8sDQo+Pj4NCj4+PiBUaGFua3MgZm9yIHRha2luZyB0aGUgdGltZSB0byBkb2N1bWVudCB0 aGlzIGJlc3QgcHJhY3RpY2UgYW5kIHRoZQ0KPj4+IGltcGxlbWVudGF0aW9ucyBpbiB0aGUgYXBw ZW5kaXguIEkgaGF2ZSBvbmUgY29tbWVudCBhbmQgYSBmZXcgbml0cy4NCj4+Pg0KPj4+IFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zOg0KPj4+IEkgdGhpbmsgaXQgd291bGQgZ28gYSBsb25nIHdheSB0 byBvcmdhbml6ZSB0aGVzZSBhcyBvbmVzIHRoYXQgYXBwbHkgdG8NCj4+PiB0aGlzIGJlc3QgcHJh Y3RpY2UgYW5kIG9uZXMgKDguMSBhbmQgdGhlIGV4YW1wbGUgaW4gOC4yKSBhYm91dA0KPj4+IGFs dGVybmF0ZSBzb2x1dGlvbnMuICBUaGlzIGNvdWxkIGFsc28gYmUgZG9uZSB0aHJvdWdoIHNvbWUg YWRkZWQgdGV4dCwNCj4+PiBidXQgbWFraW5nIHRoaXMgY2xlYXIgd291bGQgYmUgaGVscGZ1bC4g IE1heWJlIG1vdmluZyA4LjEgYW5kIDguMg0KPj4+IHVudGlsIGFmdGVyIHRoZSByZXN0IG9mIHRo ZSBzZWN0aW9ucyB3b3VsZCBiZSBlbm91Z2ggYW5kIHRoZW4gY2xlYXJseQ0KPj4+IHN0YXRlIHRo ZSBpbnRlbnQgb2YgdGhpcyB0ZXh0Lg0KPj4NCj4+DQo+PiBHb29kIGlkZWEsIEkgdGhpbmsgdGhh dCB3aWxsIGhlbHAgd2l0aCB0aGUgcmVhZGFiaWxpdHkgYSBsb3QuIEkgaGF2ZSBtb3ZlZA0KPj4g dGhlICJFbWJlZGRlZCBVc2VyLUFnZW50IiBzZWN0aW9uIHRvIHRoZSBlbmQsIGFuZCBjbGFyaWZp ZWQgdGhlIHB1cnBvc2UuDQo+Pg0KPj4gVGhlIHJlYXNvbiBpdCdzIGluY2x1ZGVkIGF0IGFsbCwg aXMgdGhhdCBPQXV0aCBpdHNlbGYgZG9jdW1lbnRzIHR3byB3YXlzIHRvDQo+PiBkbyBuYXRpdmUg T0F1dGguIFRoaXMgZG9jdW1lbnQgcmVjb21tZW5kcyBvbmx5IG9uZSBvZiB0aG9zZSB3YXlzLCBh bmQgSQ0KPj4gdGhvdWdodCB0aGF0IGRldGFpbGluZyB3aHkgdGhlIG90aGVyIHdheSBpcyBubyBs b25nZXIgYmVzdC1wcmFjdGljZSB3b3VsZCBiZQ0KPj4gaGVscGZ1bCB0byByZWFkZXJzLg0KPg0K PiBHcmVhdCwgdGhhbmsgeW91Lg0KPj4NCj4+PiBJQU5BIFNlY3Rpb246DQo+Pj4gSnVzdCBhIG5v dGUgLSB5b3UgbWlnaHQgZ2V0IHNvbWUgcXVlc3Rpb25zIGFib3V0IHRoaXMsIGJ1dCBpIGRvIHRo aW5rDQo+Pj4gaXQncyBmaW5lIHRvIGxlYXZlIHRoYXQgdGV4dCwgYWx0aG91Z2ggdW5uZWNlc3Nh cnkuDQo+Pj4NCj4+DQo+PiBJIHRoaW5rIEkgbWF5IGhhdmUgbWlzLXJlYWQgaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzUyMjYjc2VjdGlvbi02LjEuDQo+PiBUaGVyZSBpcyBhbiBleGFt cGxlIG9mIGEgZG9jdW1lbnQgdGhhdCBoYXMgbm8gSUFOQSBhY3Rpb25zIGJ1dCBzdGlsbA0KPj4g cHJvdmlkZXMgYSBqdXN0aWZpY2F0aW9uIGZvciB3aHkgdGhhdCBpcyB0aGUgY2FzZSwgYnV0IGlu IHRoYXQgZXhhbXBsZSBpdA0KPj4gdXNlcyBhIG5vbi1JQU5BIHJlZ2lzdHJ5IHVubGlrZSB0aGlz IEJDUC4NCj4+DQo+PiBJbiBvdXIgY2FzZSwgd2UgYXJlIGRlZmluaXRlbHkgb3BlcmF0aW5nIGlu IGFuIElBTkEtY29udHJvbGxlZCBuYW1lc3BhY2UsDQo+PiBidXQgdXNpbmcgYSBwcml2YXRlIHNl Y3Rpb24gb2YgdGhlIG5hbWVzcGFjZSBkZXNpZ25lZCBmb3IgdGhhdCBwdXJwb3NlLiAgVGhlDQo+ PiBpbnRlbnQgd2FzIHRvIHBvaW50IG91dCB0aGF0IHdlIGFyZSBmb2xsb3dpbmcgSUFOQSBndWlk ZWxpbmVzIGNvcnJlY3RseS4NCj4+IEhhcHB5IHRvIHJlbW92ZSBpdCAob3IgaW5kaWNhdGUgdGhh dCBpdCBzaG91bGQgYmUgcmVtb3ZlZCBkdXJpbmcNCj4+IHB1YmxpY2F0aW9uKSBpZiBpdCBzZWVt cyBzdXBlcmZsdW91cy4NCj4+DQo+PiBGb3Igbm93LCBpbiB0aGUgbGF0ZXN0IHVwZGF0ZSBJIGhh dmUgY2xlYXJseSBzdGF0ZWQgIlRoaXMgZG9jdW1lbnQgaGFzIG5vDQo+PiBJQU5BIGFjdGlvbnMu IiwgYnV0IHJldGFpbmVkIHRoZSBkaXNjdXNzaW9uLg0KPj4NCj4NCj4gU291bmRzIGdvb2QsIHRo YW5rIHlvdSENCj4NCj4+Pg0KPj4+IE5pdHM6DQo+Pj4gU2VjdGlvbiA1LCBwdW5jdHVhdGlvbg0K Pj4+IE9MRDoNCj4+PiAgICBCeSBhcHBseWluZyB0aGUgc2FtZSBwcmluY2lwbGVzIGZyb20gdGhl IHdlYiB0byBuYXRpdmUgYXBwcywgd2UgZ2Fpbg0KPj4+ICAgIGJlbmVmaXRzIHNlZW4gb24gdGhl IHdlYiBsaWtlIHRoZSB1c2FiaWxpdHkgb2YgYSBzaW5nbGUgc2lnbi1vbg0KPj4+ICAgIHNlc3Np b24sIGFuZCB0aGUgc2VjdXJpdHkgb2YgYSBzZXBhcmF0ZSBhdXRoZW50aWNhdGlvbiBjb250ZXh0 Lg0KPj4+IE5FVzoNCj4+PiAgICBCeSBhcHBseWluZyB0aGUgc2FtZSBwcmluY2lwbGVzIGZyb20g dGhlIHdlYiB0byBuYXRpdmUgYXBwcywgd2UgZ2Fpbg0KPj4+ICAgIGJlbmVmaXRzIHNlZW4gb24g dGhlIHdlYiwgbGlrZSB0aGUgdXNhYmlsaXR5IG9mIGEgc2luZ2xlIHNpZ24tb24NCj4+PiAgICBz ZXNzaW9uIGFuZCB0aGUgc2VjdXJpdHkgb2YgYSBzZXBhcmF0ZSBhdXRoZW50aWNhdGlvbiBjb250 ZXh0Lg0KPj4NCj4+DQo+PiBGaXhlZC4NCj4+DQo+Pj4NCj4+PiBUaGUgZG9jdW1lbnQgaGFzIHRl eHQgdGhhdCBzYXlzICduYXRpdmUgYXBwJyBpbiBzb21lIHBsYWNlcyBhbmQgJ2FwcCcNCj4+PiBp biBvdGhlcnMsIEkgYXNzdW1lIHRoZXNlIGFyZSB1c2VkIGludGVyY2hhbmdlYWJseT8gIEl0IHNl ZW1zIHRoYXQNCj4+PiB0aGV5IGFyZSB1c2VkIGludGVyY2hhbmdlYWJseS4NCj4+DQo+Pg0KPj4g WWVzLCB0aGV5IGFyZS4gSW4gdGhlIGRlZmluaXRpb24gc2VjdGlvbiwgImFwcCIgaXMgZGVmaW5l ZCBhcyAic2hvcnRoYW5kIGZvcg0KPj4gbmF0aXZlIGFwcCIuIElzIHRoYXQgT0ssIG9yIHNob3Vs ZCBJIHJldmlzZT8NCj4NCj4gSSBtaXNzZWQgdGhhdCwgYnV0IGlmIGl0J3MgZGVmaW5lZCwgdGhl biB5b3UgYXJlIGNvdmVyZWQuICBUaGFua3MuDQo+DQo+Pg0KPj4+DQo+Pj4gUmVhbGx5IG5pdHR5 Og0KPj4+IFNlY3Rpb24gNy4yLA0KPj4+IFNpbmNlIHlvdSBhcmUgc3RpbGwgaW4gdGhlIGV4YW1w bGUsIGRpZCB5b3UgbWVhbiBVUkwgaW4gdGhlIGZvbGxvd2luZzoNCj4+Pg0KPj4+IFN1Y2ggY2xh aW1lZCBIVFRQUyBVUklzIGNhbiBiZSB1c2VkIGFzIE9BdXRoIHJlZGlyZWN0IFVSSXMuDQo+Pj4g U3VjaCBjbGFpbWVkIEhUVFBTIFVSTHMgY2FuIGJlIHVzZWQgYXMgT0F1dGggcmVkaXJlY3QgVVJJ cy4NCj4+DQo+Pg0KPj4gSSBoYXZlIG1pZ3JhdGVkIHRvIHVzZSBVUkkgZXhjbHVzaXZlbHksIG90 aGVyIHRoYW4gMiByZWZlcmVuY2VzIHRvIFVSTCB3aGVyZQ0KPj4gSSdtIHJlZmVycmluZyB0byBw bGF0Zm9ybS1zcGVjaWZpYyBuYW1pbmcgLyBjb2xsb3F1aWFsaXNtcy4NCj4+DQo+PiBJIGFsc28g Y2hhbmdlZCBpbnN0YW5jZXMgb2YgImN1c3RvbSBVUkkgc2NoZW1lIiB0byAicHJpdmF0ZS11c2Ug VVJJIHNjaGVtZSIsDQo+PiB0aGUgbGF0dGVyIGJlaW5nIHRoZSB0ZXJtaW5vbG9neSB1c2VkIGJ5 IFJGQzc1OTUuDQo+DQo+IFBlcmZlY3QsIHRoYW5rcy4gIFRoZSBwb2ludCBpbiBhc2tpbmcgd2Fz IGp1c3QgZm9yIG90aGVyIHJldmlld3MgdGhhdA0KPiB3aWxsIGZvbGxvdy4NCj4NCj4+DQo+Pj4g QW5kIGFnYWluIGluIHRoZSBsYXN0IHBhcmFncmFwaCBvZiB0aGlzIHNlY3Rpb24uDQo+Pj4NCj4+ PiBJJ20gb25seSBhc2tpbmcgc2luY2UgeW91IHNwZWNpZnkgVVJMIGVhcmxpZXIgaW4gdGhpcyBz ZWN0aW9uLCBzbyB5b3UNCj4+PiB3ZXJlIG1vcmUgc3BlY2lmaWMgZm9yIHRoZSBleGFtcGxlIGFu ZCB0aGVuIGRyb3AgYmFjayB0byBVUkkgKHdoaWNoIGlzDQo+Pj4gY29ycmVjdCwgYnV0IHdvbmRl cmluZyBpZiB5b3Ugd2FudGVkIHRvIGNvbnRpbnVlIGF0IHRoZSBzYW1lIGxldmVsIG9mDQo+Pj4g c3BlY2lmaWNpdHkgb3IgaWYgdGhlcmUgd2FzIGEgcmVhc29uIHRvIGp1c3Qgc2F5IFVSSSBoZXJl Lg0KPj4NCj4+DQo+PiBJIGJlbGlldmUgdGhpcyBpcyBhZGRyZXNzZWQgbm93Lg0KPj4NCj4+PiBT ZWN0aW9uIDguMTENCj4+PiBzL3VyaS9VUkkvDQo+Pj4NCj4gVGhhbmsgeW91Lg0KPj4NCj4+IEZp eGVkLg0KPj4NCj4+IEJlc3QsDQo+PiBXaWxsaWFtDQo+Pg0KPj4+DQo+Pj4NCj4+PiAtLQ0KPj4+ DQo+Pj4gQmVzdCByZWdhcmRzLA0KPj4+IEthdGhsZWVuDQo+Pj4NCj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IE9BdXRoIG1haWxpbmcgbGlz dA0KPj4+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+Pg0KPj4NCj4NCj4NCj4NCj4g LS0NCj4NCj4gQmVzdCByZWdhcmRzLA0KPiBLYXRobGVlbg0KDQoNCg0KLS0NCg0KQmVzdCByZWdh cmRzLA0KS2F0aGxlZW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRo QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGgg bWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo= --_000_AM4PR09MB0627D050138C01F0CB408DBAB0E40AM4PR09MB0627eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PkhpICw8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+PGJyPg0KPC9kaXY+ DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPkNhbiBJIGFzayBvbmUgbW9yZSB0aW1lIHRv IHVuc3Vic2NyaWJlIG1lIGZyb20geW91ciBtYWlsaW5nIGxpc3QuIFRoYW5rIHlvdS4mbmJzcDs8 YnI+DQo8YnI+DQpBZHJpYW4gSW1hY2g8L2Rpdj4NCjxkaXY+PGJyPg0KT24gMTggTWF5IDIwMTcs IGF0IDE5OjU2LCBKb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRi LmNvbSI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8L2Rpdj4N CjxkaXY+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE1 IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICov DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIg NCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0K CXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0 IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5XaWxsaWFtIGFuZCBJIGp1c3QgZGlzY3Vzc2VkIGl0IGFuZCB0aGUgZ29h bCBpcyB0byBnZXQgYSBuZXcgZHJhZnQgb3V0IGFkZHJlc3NpbmcgdGhvc2UgY29tbWVudHMgdG9k YXkgb3IgdG9tb3Jyb3cuPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb2huIEIuPC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlbnQgZnJvbSA8YSBocmVmPSJo dHRwczovL2dvLm1pY3Jvc29mdC5jb20vZndsaW5rLz9MaW5rSWQ9NTUwOTg2Ij4NCk1haWw8L2E+ IGZvciBXaW5kb3dzIDEwPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2IHN0eWxlPSJtc28tZWxlbWVudDpwYXJhLWJvcmRlci1kaXY7Ym9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJvcmRlcjpub25lO3BhZGRpbmc6MGNt Ij48Yj5Gcm9tOiA8L2I+PGEgaHJlZj0ibWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21h aWwuY29tIj5LYXRobGVlbiBNb3JpYXJ0eTwvYT48YnI+DQo8Yj5TZW50OiA8L2I+TWF5IDE4LCAy MDE3IDI6MTQgUE08YnI+DQo8Yj5UbzogPC9iPjxhIGhyZWY9Im1haWx0bzp3ZGVubmlzc0Bnb29n bGUuY29tIj5XaWxsaWFtIERlbm5pc3M8L2E+PGJyPg0KPGI+Q2M6IDwvYj48YSBocmVmPSJtYWls dG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6IDwv Yj5SZTogW09BVVRILVdHXSBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1vYXV0aC1uYXRpdmUtYXBw czwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+SGks PGJyPg0KPGJyPg0KV2lsbCB0aGVyZSBiZSBhIG5ldyBkb2N1bWVudCBwb3N0ZWQgdG9kYXkvdG9t b3Jyb3cgdG8gYWRkcmVzcyBsYXN0PGJyPg0KY2FsbCBjb21tZW50cy90aGUgR2VuQVJUIHJldmll dz8mbmJzcDsgSSdkIGxpa2UgdG8gYWRkIHRoZSBiYWxsb3QgZm9yIHRoZTxicj4NCklFU0cgcmV2 aWV3IGFuZCB0ZWxlY2hhdCBuZXh0IHdlZWssICwgYnV0IGl0IHdvdWxkIGJlIGJlc3Qgb24gdGhl PGJyPg0KdXBkYXRlZCBkcmFmdCB0byBhdm9pZCBkdXBsaWNhdGUgY29tbWVudHMuPGJyPg0KPGJy Pg0KVGhhbmsgeW91LDxicj4NCkthdGhsZWVuPGJyPg0KPGJyPg0KT24gVHVlLCBNYXkgMiwgMjAx NyBhdCAyOjM0IFBNLCBLYXRobGVlbiBNb3JpYXJ0eTxicj4NCiZsdDs8YSBocmVmPSJtYWlsdG86 a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb20iPmthdGhsZWVuLm1vcmlhcnR5LmlldGZA Z21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyBIaSBXaWxsaWFtLDxicj4NCiZndDs8 YnI+DQomZ3Q7IFRoYW5rIHlvdSBmb3IgbWFraW5nIHRoZSB1cGRhdGVzLiZuYnNwOyBKdXN0IGEg ZmV3IG5vdGVzIGlubGluZSBhbmQgSSdsbDxicj4NCiZndDsga2ljayBvZmYgSUVURiBsYXN0IGNh bGwuPGJyPg0KJmd0Ozxicj4NCiZndDsgT24gV2VkLCBBcHIgMjYsIDIwMTcgYXQgNTo1MCBQTSwg V2lsbGlhbSBEZW5uaXNzICZsdDs8YSBocmVmPSJtYWlsdG86d2Rlbm5pc3NAZ29vZ2xlLmNvbSI+ d2Rlbm5pc3NAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7IFRoYW5rIHlv dSBmb3IgeW91ciByZXZpZXcgS2F0aGxlZW4uPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBW ZXJzaW9uIDEwIHdoaWNoIGFkZHJlc3NlcyB5b3VyIGNvbW1lbnRzIGlzIG91dDo8YnI+DQomZ3Q7 Jmd0OyA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0 aC1uYXRpdmUtYXBwcy0xMCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt b2F1dGgtbmF0aXZlLWFwcHMtMTA8L2E+PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBSZXBs aWVzIGlubGluZTo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IE9uIE1vbiwgQXByIDI0LCAy MDE3IGF0IDY6NDcgUE0sIEthdGhsZWVuIE1vcmlhcnR5PGJyPg0KJmd0OyZndDsgJmx0OzxhIGhy ZWY9Im1haWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbSI+a2F0aGxlZW4ubW9y aWFydHkuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsgSGVsbG8sPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 IFRoYW5rcyBmb3IgdGFraW5nIHRoZSB0aW1lIHRvIGRvY3VtZW50IHRoaXMgYmVzdCBwcmFjdGlj ZSBhbmQgdGhlPGJyPg0KJmd0OyZndDsmZ3Q7IGltcGxlbWVudGF0aW9ucyBpbiB0aGUgYXBwZW5k aXguIEkgaGF2ZSBvbmUgY29tbWVudCBhbmQgYSBmZXcgbml0cy48YnI+DQomZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM6PGJyPg0KJmd0OyZndDsm Z3Q7IEkgdGhpbmsgaXQgd291bGQgZ28gYSBsb25nIHdheSB0byBvcmdhbml6ZSB0aGVzZSBhcyBv bmVzIHRoYXQgYXBwbHkgdG88YnI+DQomZ3Q7Jmd0OyZndDsgdGhpcyBiZXN0IHByYWN0aWNlIGFu ZCBvbmVzICg4LjEgYW5kIHRoZSBleGFtcGxlIGluIDguMikgYWJvdXQ8YnI+DQomZ3Q7Jmd0OyZn dDsgYWx0ZXJuYXRlIHNvbHV0aW9ucy4mbmJzcDsgVGhpcyBjb3VsZCBhbHNvIGJlIGRvbmUgdGhy b3VnaCBzb21lIGFkZGVkIHRleHQsPGJyPg0KJmd0OyZndDsmZ3Q7IGJ1dCBtYWtpbmcgdGhpcyBj bGVhciB3b3VsZCBiZSBoZWxwZnVsLiZuYnNwOyBNYXliZSBtb3ZpbmcgOC4xIGFuZCA4LjI8YnI+ DQomZ3Q7Jmd0OyZndDsgdW50aWwgYWZ0ZXIgdGhlIHJlc3Qgb2YgdGhlIHNlY3Rpb25zIHdvdWxk IGJlIGVub3VnaCBhbmQgdGhlbiBjbGVhcmx5PGJyPg0KJmd0OyZndDsmZ3Q7IHN0YXRlIHRoZSBp bnRlbnQgb2YgdGhpcyB0ZXh0Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyBHb29kIGlkZWEsIEkgdGhpbmsgdGhhdCB3aWxsIGhlbHAgd2l0aCB0aGUgcmVhZGFiaWxp dHkgYSBsb3QuIEkgaGF2ZSBtb3ZlZDxicj4NCiZndDsmZ3Q7IHRoZSAmcXVvdDtFbWJlZGRlZCBV c2VyLUFnZW50JnF1b3Q7IHNlY3Rpb24gdG8gdGhlIGVuZCwgYW5kIGNsYXJpZmllZCB0aGUgcHVy cG9zZS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoZSByZWFzb24gaXQncyBpbmNsdWRl ZCBhdCBhbGwsIGlzIHRoYXQgT0F1dGggaXRzZWxmIGRvY3VtZW50cyB0d28gd2F5cyB0bzxicj4N CiZndDsmZ3Q7IGRvIG5hdGl2ZSBPQXV0aC4gVGhpcyBkb2N1bWVudCByZWNvbW1lbmRzIG9ubHkg b25lIG9mIHRob3NlIHdheXMsIGFuZCBJPGJyPg0KJmd0OyZndDsgdGhvdWdodCB0aGF0IGRldGFp bGluZyB3aHkgdGhlIG90aGVyIHdheSBpcyBubyBsb25nZXIgYmVzdC1wcmFjdGljZSB3b3VsZCBi ZTxicj4NCiZndDsmZ3Q7IGhlbHBmdWwgdG8gcmVhZGVycy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBH cmVhdCwgdGhhbmsgeW91Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IElBTkEgU2Vj dGlvbjo8YnI+DQomZ3Q7Jmd0OyZndDsgSnVzdCBhIG5vdGUgLSB5b3UgbWlnaHQgZ2V0IHNvbWUg cXVlc3Rpb25zIGFib3V0IHRoaXMsIGJ1dCBpIGRvIHRoaW5rPGJyPg0KJmd0OyZndDsmZ3Q7IGl0 J3MgZmluZSB0byBsZWF2ZSB0aGF0IHRleHQsIGFsdGhvdWdoIHVubmVjZXNzYXJ5Ljxicj4NCiZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSSB0aGluayBJIG1heSBoYXZl IG1pcy1yZWFkIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjI2I3Nl Y3Rpb24tNi4xIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjI2I3NlY3Rpb24t Ni4xPC9hPi48YnI+DQomZ3Q7Jmd0OyBUaGVyZSBpcyBhbiBleGFtcGxlIG9mIGEgZG9jdW1lbnQg dGhhdCBoYXMgbm8gSUFOQSBhY3Rpb25zIGJ1dCBzdGlsbDxicj4NCiZndDsmZ3Q7IHByb3ZpZGVz IGEganVzdGlmaWNhdGlvbiBmb3Igd2h5IHRoYXQgaXMgdGhlIGNhc2UsIGJ1dCBpbiB0aGF0IGV4 YW1wbGUgaXQ8YnI+DQomZ3Q7Jmd0OyB1c2VzIGEgbm9uLUlBTkEgcmVnaXN0cnkgdW5saWtlIHRo aXMgQkNQLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSW4gb3VyIGNhc2UsIHdlIGFyZSBk ZWZpbml0ZWx5IG9wZXJhdGluZyBpbiBhbiBJQU5BLWNvbnRyb2xsZWQgbmFtZXNwYWNlLDxicj4N CiZndDsmZ3Q7IGJ1dCB1c2luZyBhIHByaXZhdGUgc2VjdGlvbiBvZiB0aGUgbmFtZXNwYWNlIGRl c2lnbmVkIGZvciB0aGF0IHB1cnBvc2UuJm5ic3A7IFRoZTxicj4NCiZndDsmZ3Q7IGludGVudCB3 YXMgdG8gcG9pbnQgb3V0IHRoYXQgd2UgYXJlIGZvbGxvd2luZyBJQU5BIGd1aWRlbGluZXMgY29y cmVjdGx5Ljxicj4NCiZndDsmZ3Q7IEhhcHB5IHRvIHJlbW92ZSBpdCAob3IgaW5kaWNhdGUgdGhh dCBpdCBzaG91bGQgYmUgcmVtb3ZlZCBkdXJpbmc8YnI+DQomZ3Q7Jmd0OyBwdWJsaWNhdGlvbikg aWYgaXQgc2VlbXMgc3VwZXJmbHVvdXMuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBGb3Ig bm93LCBpbiB0aGUgbGF0ZXN0IHVwZGF0ZSBJIGhhdmUgY2xlYXJseSBzdGF0ZWQgJnF1b3Q7VGhp cyBkb2N1bWVudCBoYXMgbm88YnI+DQomZ3Q7Jmd0OyBJQU5BIGFjdGlvbnMuJnF1b3Q7LCBidXQg cmV0YWluZWQgdGhlIGRpc2N1c3Npb24uPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0 OyBTb3VuZHMgZ29vZCwgdGhhbmsgeW91ITxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsgTml0czo8YnI+DQomZ3Q7Jmd0OyZndDsgU2VjdGlvbiA1LCBwdW5jdHVh dGlvbjxicj4NCiZndDsmZ3Q7Jmd0OyBPTEQ6PGJyPg0KJmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IEJ5IGFwcGx5aW5nIHRoZSBzYW1lIHByaW5jaXBsZXMgZnJvbSB0aGUgd2ViIHRvIG5h dGl2ZSBhcHBzLCB3ZSBnYWluPGJyPg0KJmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJl bmVmaXRzIHNlZW4gb24gdGhlIHdlYiBsaWtlIHRoZSB1c2FiaWxpdHkgb2YgYSBzaW5nbGUgc2ln bi1vbjxicj4NCiZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBzZXNzaW9uLCBhbmQgdGhl IHNlY3VyaXR5IG9mIGEgc2VwYXJhdGUgYXV0aGVudGljYXRpb24gY29udGV4dC48YnI+DQomZ3Q7 Jmd0OyZndDsgTkVXOjxicj4NCiZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBCeSBhcHBs eWluZyB0aGUgc2FtZSBwcmluY2lwbGVzIGZyb20gdGhlIHdlYiB0byBuYXRpdmUgYXBwcywgd2Ug Z2Fpbjxicj4NCiZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBiZW5lZml0cyBzZWVuIG9u IHRoZSB3ZWIsIGxpa2UgdGhlIHVzYWJpbGl0eSBvZiBhIHNpbmdsZSBzaWduLW9uPGJyPg0KJmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNlc3Npb24gYW5kIHRoZSBzZWN1cml0eSBvZiBh IHNlcGFyYXRlIGF1dGhlbnRpY2F0aW9uIGNvbnRleHQuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7IEZpeGVkLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7IFRoZSBkb2N1bWVudCBoYXMgdGV4dCB0aGF0IHNheXMgJ25hdGl2 ZSBhcHAnIGluIHNvbWUgcGxhY2VzIGFuZCAnYXBwJzxicj4NCiZndDsmZ3Q7Jmd0OyBpbiBvdGhl cnMsIEkgYXNzdW1lIHRoZXNlIGFyZSB1c2VkIGludGVyY2hhbmdlYWJseT8mbmJzcDsgSXQgc2Vl bXMgdGhhdDxicj4NCiZndDsmZ3Q7Jmd0OyB0aGV5IGFyZSB1c2VkIGludGVyY2hhbmdlYWJseS48 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgWWVzLCB0aGV5IGFyZS4g SW4gdGhlIGRlZmluaXRpb24gc2VjdGlvbiwgJnF1b3Q7YXBwJnF1b3Q7IGlzIGRlZmluZWQgYXMg JnF1b3Q7c2hvcnRoYW5kIGZvcjxicj4NCiZndDsmZ3Q7IG5hdGl2ZSBhcHAmcXVvdDsuIElzIHRo YXQgT0ssIG9yIHNob3VsZCBJIHJldmlzZT88YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIG1pc3NlZCB0 aGF0LCBidXQgaWYgaXQncyBkZWZpbmVkLCB0aGVuIHlvdSBhcmUgY292ZXJlZC4mbmJzcDsgVGhh bmtzLjxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0OyBSZWFsbHkgbml0dHk6PGJyPg0KJmd0OyZndDsmZ3Q7IFNlY3Rpb24gNy4yLDxicj4N CiZndDsmZ3Q7Jmd0OyBTaW5jZSB5b3UgYXJlIHN0aWxsIGluIHRoZSBleGFtcGxlLCBkaWQgeW91 IG1lYW4gVVJMIGluIHRoZSBmb2xsb3dpbmc6PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7IFN1Y2ggY2xhaW1lZCBIVFRQUyBVUklzIGNhbiBiZSB1c2VkIGFzIE9BdXRoIHJlZGly ZWN0IFVSSXMuPGJyPg0KJmd0OyZndDsmZ3Q7IFN1Y2ggY2xhaW1lZCBIVFRQUyBVUkxzIGNhbiBi ZSB1c2VkIGFzIE9BdXRoIHJlZGlyZWN0IFVSSXMuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7IEkgaGF2ZSBtaWdyYXRlZCB0byB1c2UgVVJJIGV4Y2x1c2l2ZWx5LCBv dGhlciB0aGFuIDIgcmVmZXJlbmNlcyB0byBVUkwgd2hlcmU8YnI+DQomZ3Q7Jmd0OyBJJ20gcmVm ZXJyaW5nIHRvIHBsYXRmb3JtLXNwZWNpZmljIG5hbWluZyAvIGNvbGxvcXVpYWxpc21zLjxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSSBhbHNvIGNoYW5nZWQgaW5zdGFuY2VzIG9mICZxdW90 O2N1c3RvbSBVUkkgc2NoZW1lJnF1b3Q7IHRvICZxdW90O3ByaXZhdGUtdXNlIFVSSSBzY2hlbWUm cXVvdDssPGJyPg0KJmd0OyZndDsgdGhlIGxhdHRlciBiZWluZyB0aGUgdGVybWlub2xvZ3kgdXNl ZCBieSBSRkM3NTk1Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFBlcmZlY3QsIHRoYW5rcy4mbmJzcDsg VGhlIHBvaW50IGluIGFza2luZyB3YXMganVzdCBmb3Igb3RoZXIgcmV2aWV3cyB0aGF0PGJyPg0K Jmd0OyB3aWxsIGZvbGxvdy48YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsgQW5kIGFnYWluIGluIHRoZSBsYXN0IHBhcmFncmFwaCBvZiB0aGlzIHNlY3Rpb24uPGJyPg0K Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEknbSBvbmx5IGFza2luZyBzaW5jZSB5b3Ug c3BlY2lmeSBVUkwgZWFybGllciBpbiB0aGlzIHNlY3Rpb24sIHNvIHlvdTxicj4NCiZndDsmZ3Q7 Jmd0OyB3ZXJlIG1vcmUgc3BlY2lmaWMgZm9yIHRoZSBleGFtcGxlIGFuZCB0aGVuIGRyb3AgYmFj ayB0byBVUkkgKHdoaWNoIGlzPGJyPg0KJmd0OyZndDsmZ3Q7IGNvcnJlY3QsIGJ1dCB3b25kZXJp bmcgaWYgeW91IHdhbnRlZCB0byBjb250aW51ZSBhdCB0aGUgc2FtZSBsZXZlbCBvZjxicj4NCiZn dDsmZ3Q7Jmd0OyBzcGVjaWZpY2l0eSBvciBpZiB0aGVyZSB3YXMgYSByZWFzb24gdG8ganVzdCBz YXkgVVJJIGhlcmUuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEkg YmVsaWV2ZSB0aGlzIGlzIGFkZHJlc3NlZCBub3cuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsgU2VjdGlvbiA4LjExPGJyPg0KJmd0OyZndDsmZ3Q7IHMvdXJpL1VSSS88YnI+DQomZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7IFRoYW5rIHlvdS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 IEZpeGVkLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgQmVzdCw8YnI+DQomZ3Q7Jmd0OyBX aWxsaWFtPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsgLS08YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsg QmVzdCByZWdhcmRzLDxicj4NCiZndDsmZ3Q7Jmd0OyBLYXRobGVlbjxicj4NCiZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCiZndDsmZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7 Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwv YT48YnI+DQomZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aDwvYT48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLTxicj4NCiZndDs8YnI+DQomZ3Q7IEJlc3QgcmVnYXJkcyw8 YnI+DQomZ3Q7IEthdGhsZWVuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KLS0gPGJyPg0KPGJyPg0K QmVzdCByZWdhcmRzLDxicj4NCkthdGhsZWVuPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+ DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj48c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+DQo8c3Bhbj5PQXV0aCBtYWlsaW5nIGxpc3Q8L3Nw YW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRm Lm9yZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aDwvYT48L3NwYW4+PGJyPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_AM4PR09MB0627D050138C01F0CB408DBAB0E40AM4PR09MB0627eurp_-- From nobody Fri May 19 12:57:34 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B4F129434; Fri, 19 May 2017 12:57:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149522384581.21403.2217774421031968539@ietfa.amsl.com> Date: Fri, 19 May 2017 12:57:25 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-native-apps-11.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 19:57:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol of the IETF. Title : OAuth 2.0 for Native Apps Authors : William Denniss John Bradley Filename : draft-ietf-oauth-native-apps-11.txt Pages : 20 Date : 2017-05-19 Abstract: OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the user's browser. This specification details the security and usability reasons why this is the case, and how native apps and authorization servers can implement this best practice. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-native-apps/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-native-apps-11 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-native-apps-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-native-apps-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 May 19 13:04:17 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4966129AB6 for ; Fri, 19 May 2017 13:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-tEwwKHb5xc for ; Fri, 19 May 2017 13:04:07 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 116A11294AB for ; Fri, 19 May 2017 13:04:06 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id o12so53889852iod.3 for ; Fri, 19 May 2017 13:04:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DIxZijMyoosEBEnHAb1cHOE1AsjPqASahl8Rbj8RQ4A=; b=eemJyYjZYqgg/TNT9am0JhnOyxmz8/RWKf4TjTavffIoW1fgPndpX0603zHamsvKVh Pvw306xN/jGz74WTbiQDe+qMjU9k7ahJScAbVZxyghVB9Ml4txZ3ufYKAHQ0nsNeCIa1 29zSZLzThrQJ0ucwmR9f2fIsu7/2gZW8SlnnlA2gwFjn6U9nu0SD/u3vniZ4CEdg7LEX Bdt3IXgpfcOa6RXqqqp0w8WvJRZ1zVKCwHmeuzzabEV9rCxYy8rsrB7WSnlIgN5IXjF1 nxLOzF0PgvTeKijy2t5nC53FbEy9/5psT3mjkpcN8+knWsEH218LcCWoJ8O3NLFS/9LB mAJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DIxZijMyoosEBEnHAb1cHOE1AsjPqASahl8Rbj8RQ4A=; b=PWPMSlr+40+1jBd0KQnqLEbWJXWqTKkY+9QEgktuu8AxzHuDH0OX0hOG1qbxn/ycD9 8B3VwNPgS9F1j3jy43p+bU2XfFf5z6l9Aohn0RBqoMQlaStw3V5rLtav0+o5VcUMKxsi GkQwfpDrQaJjf8TB2TvEWrXYxkc5/tNAZsqWc6ib9Jz+qNjCGhA1DBqCJy29fKip/vAU vOpyWhXGziZfqrtCjPug2IrL1P9rpd/ghPrAB0NeTgyH3M4kHxJN+OS0neah3nRwYJX3 E716UdAOQUOs/wnClGEBntgeuXiv6q5PTsBMqJ5NC3aBYt4bex7RLTGktcxWkRn0K/k9 3A5g== X-Gm-Message-State: AODbwcCRti4e2FerOs7XkDIKJjIT1kixoYIIbf0/ms4uYKmZ1MhZFWvY pi6pm9Uv5B6h9q/8T3MeM0jdOtKtYyyI X-Received: by 10.107.25.203 with SMTP id 194mr11591604ioz.182.1495224245104; Fri, 19 May 2017 13:04:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.35.37 with HTTP; Fri, 19 May 2017 13:03:44 -0700 (PDT) In-Reply-To: <149489171188.11868.13336890952697460283@ietfa.amsl.com> References: <149489171188.11868.13336890952697460283@ietfa.amsl.com> From: William Denniss Date: Fri, 19 May 2017 13:03:44 -0700 Message-ID: To: Elwyn Davies Cc: gen-art@ietf.org, draft-ietf-oauth-native-apps.all@ietf.org, ietf@ietf.org, "oauth@ietf.org" Content-Type: multipart/alternative; boundary="001a113fe2dafe2c0d054fe6056b" Archived-At: Subject: Re: [OAUTH-WG] Genart last call review of draft-ietf-oauth-native-apps-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 20:04:11 -0000 --001a113fe2dafe2c0d054fe6056b Content-Type: text/plain; charset="UTF-8" Elwyn, Thank you for your detailed review. Comments inline, my changes appear in version 11 . On Mon, May 15, 2017 at 4:41 PM, Elwyn Davies wrote: > Reviewer: Elwyn Davies > Review result: Almost Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-oauth-native-apps-10 > Reviewer: Elwyn Davies > Review Date: 2017-05-15 > IETF LC End Date: 2017-05-16 > IESG Telechat date: 2017-05-25 > > Summary: Almost ready. A couple of simple minor issues could do with > addressing. > > Major issues: > None. > > Minor issues: > s3: "browser": The browser that acts as the Oauth user-agent is > conflated with the user's choice of default browser. Firstly this is > not something that is discussed in RFC 6749. Secondly, the concept of > 'default browser' would normally be thought of by users as the browser > that is used to display the content associated with hyperlinks rather > than providing Oauth services. I suggest that the implication in the > body of the draft that 'the browser' is the user selected or system > selected default browser needs to be at least discussed explicitly > rather than buried in the terminology definitions in s3. I wonder > whether ths connection is something that should be made by a separate > OS setting or a setting in each native app rather than conflated with > the default browser. The term "designated browser" might be useful. > In all cases there might be secuity implications if a bad actor could > subvert the designated browser setting. > I reworded the definition, please take another look. s8.1, Requirement of use of PKCE in some cases: This strict > requirement really needs to be introduced in the body of the > discussion rather than buried in the seurity considerations. > I reworked Section 6 to include this requirement there. Nits/editorial comments: > > General: s/i.e./i.e.,/ (3 places) > Done. Title and Abstract: s/apps/applications/g (uses before we get to > terminology in s3) > After consulting some dictionaries, I'm convinced that app is a bonafide synonym for application, and not shorthand (even if it started out that way). So I've reworded our definition, but am otherwise planning to retain the use of "app". The primary use-case for this BCP are "apps", I believe replacing this usage would introduce more confusion that it could potentially solve. s1, para 1: Suggest the following to make it clear that the > definition is in RFC 6749 rather than here. > OLD: > The OAuth 2.0 [RFC6749] authorization framework documents two > approaches in Section 9 for native apps to interact with the > authorization endpoint: an embedded user-agent, and an external user- > agent. > NEW: > The OAuth 2.0 [RFC6749] authorization framework defines "native > applications" in Section 9 of RFC 6749 (see also Section 3 below) and > documents two approaches by whch they can interact with the > authorization endpoint: an embedded user-agent, and an external > user-agent. > END > I feel like this is implied due to the reference to Section 9 of 6749 in the opening sentence. s1, para 2: s/apps/applications/(2places) . For second case: s/native > apps/native applications (shortened to "native apps" or just "apps" > hereafter)/ > > s3, "native app": s/app/application/g in the definition. After that > in the document "[native] app" is fine except for the definitions > mentioned in the next comment. Worth repeating the link to Section 9 > of RFC 6749. > > s3, All definitions after "app"; s/app/application/g in the > definitions as these are not restricted to (native) apps as defined > here. > Per earlier comment. s3, "embedded user-agent": s/modify/modifyng/ > Done. s4, last para: s/emcompasses/encompasses/ > Done. > s4, last para: s/inter-process/inter-app/ (since this term is > defined) > Done. > s4, last para: Might be worth pointing to the 'SHOULD' about client > type assumptions in s2.1 of RFC 6749 withe reference to servers that > do make assumptions. > This is covered in detail in Section 8.4. I'd like to keep this introduction light, and not get into the details just yet. Let me know if you think 8.4 is inadequate. s4.1, para below figure 1: s/system browser/browser/ (or maybe > "designated browser"). > Reworded. s5, paras 1 and 2: Reword to clarify and remove 'we gain' usage (not > allowed in RFCs): > OLD: > Just as URIs are used for OAuth 2.0 [RFC6749] on the web to > initiate > the authorization request and return the authorization response to > the requesting website, URIs can be used by native apps to > initiate > the authorization request in the device's browser and return the > response to the requesting native app. > > By applying the same principles from the web to native apps, we > gain > benefits seen on the web, like the usability of a single sign-on > session and the security of a separate authentication context. It > also reduces the implementation complexity by reusing similar > flows > as the web, and increases interoperability by relying on > standards- > based web flows that are not specific to a particular platform. > NEW: > Just as URIs are used for OAuth 2.0 [RFC6749] in the HTTP protocol > on the web to initiate > the authorization request and return the authorization response to > the requesting website, URIs can be used by native apps to > initiate > the authorization request in the device's browser and return the > response to the requesting native app. > > By extending the techniques from the web to native apps, the > benefits gained in the web context will also be reaped when using > OAuth with native apps; benefits include the usability of a single > sign-on > session and the security of a separate authentication context. Use > of > the techniques also reduces implementation complexity by reusing > similar flows > to those employed on the web, and increases interoperability by > relying on standards- > based web flows that are not specific to a particular platform. > END > Re-worded to remove "we gain", thanks for your suggestion. s5, para 3: Suggest prefixing this para with: "To conform to this best > practise," - the MUST is not derived from RFC 6749. > Re-worded taking into account this suggestion. s7.1, last para: s/URI like it/URI as it/; s/like normal/as it would > normally/ > Done. > s7.2, next to last para: > OLD: > Due to this reason, they SHOULD be used over the other redirect > choices for native apps where possible. > NEW: > For this reason, they SHOULD be used in preference to the other > redirect options for native apps where possible. > END > Done. s7.2, last para: s/it REQUIRED/it is REQUIRED/ > Done. s8.1, para 2: Need to expand acronym PKCE at first use (currently > expanded in para 4). > PKCE now defined earlier in the doc. > s8.1, para 4: s/sends data/send data/ > Done. s8.2: It would be more consistent with RFC 6749 to refer to "Implicit > Flow" as "Implicit Grant authorization flow" at least for the title > and first occurrence. The second and third occurrences in para 1 > should s/Implicit Flow/implicit flow/ for consistency with para 2. > Done. > s8.2, para 2: s/code flow/Authorization Code Grant flow/ > Done. s8.3, last para: Is a reminder to choose the 'right' type of IP > literal (IPv4 or v6) desirable? Doing an address lookup on > "localhost" presumably tells you which one to use! [perhaps?] > Good point, but I think this is an implementation consideration. I've added a note to 7.3. s8.7, para 4: s/like/such as/ > Done. > s8.8; need to expand CSRF (Cross Site Request Forgery) Done. > and maybe > explain a it how CSRGF and the cross-app case are related > Great point, done. --001a113fe2dafe2c0d054fe6056b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Elwyn,

Thank you for your detailed revi= ew.

Comments inline, my changes appear in version 11.

On Mon, May 15, 2017 at 4:41 PM, Elwyn Davies <elw= ynd@dial.pipex.com> wrote:
Reviewer: Elwyn Davies
Review result: Almost Ready

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

For more information, please see the FAQ at

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

Document: draft-ietf-oauth-native-apps-10
Reviewer: Elwyn Davies
Review Date: 2017-05-15
IETF LC End Date: 2017-05-16
IESG Telechat date: 2017-05-25

Summary: Almost ready.=C2=A0 A couple of simple minor issues could do with<= br> addressing.

Major issues:
None.

Minor issues:
s3: "browser": =C2=A0The browser that acts as the Oauth user-agen= t is
conflated with the user's choice of default browser.=C2=A0 Firstly this= is
not something that is discussed in RFC 6749.=C2=A0 Secondly, the concept of=
'default browser' would normally be thought of by users as the brow= ser
that is used to display the content associated with hyperlinks rather
than providing Oauth services.=C2=A0 I suggest that the implication in the<= br> body of the draft that 'the browser' is the user selected or system=
selected default browser needs to be at least discussed explicitly
rather than buried in the terminology definitions in s3.=C2=A0 I wonder
whether ths connection is something that should be made by a separate
OS setting or a setting in each native app rather than conflated with
the default browser.=C2=A0 The term "designated browser" might be= useful.
In all cases there might be secuity implications if a bad actor could
subvert the designated browser setting.

I reworded the definition, please take another look.

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> s8.1, Requirement of use of PKCE in some cases: =C2=A0This strict
requirement really needs to be introduced in the body of the
discussion rather than buried in the seurity considerations.

I reworked Section 6 to include this requirement ther= e.

Nits/editorial comments:

General: s/i.e./i.e.,/ (3 places)

Done.=

Title and Abstract: s/apps/applications/g =C2=A0(uses before we get to
terminology in s3)

After consulting som= e dictionaries, I'm convinced that app is a bonafide synonym for applic= ation, and not shorthand (even if it started out that way). So I've rew= orded our definition, but am otherwise planning to retain the use of "= app". The primary use-case for this BCP are "apps", I believ= e replacing this usage would introduce more confusion that it could potenti= ally solve.

s1, para 1: =C2=A0Suggest the following to make it clear that the
definition is in RFC 6749 rather than here.
OLD:
=C2=A0The OAuth 2.0 [RFC6749] authorization framework documents two
approaches in Section 9 for native apps to interact with the
authorization endpoint: an embedded user-agent, and an external user-
agent.
NEW:
The OAuth 2.0 [RFC6749] authorization framework defines "native
applications" in Section 9 of RFC 6749 (see also Section 3 below) and<= br> documents two approaches by whch they can interact with the
authorization endpoint: an embedded user-agent, and an external
user-agent.=C2=A0
END=C2=A0

I feel like this is implied d= ue to the reference to Section 9 of 6749 in the opening sentence.=C2=A0

s1, para= 2: s/apps/applications/(2places) .=C2=A0 For second case: s/native
apps/native applications (shortened to "native apps" or just &quo= t;apps"
hereafter)/

s3, "native app": s/app/application/g in the definition.=C2=A0 Af= ter that
in the document "[native] app" is fine except for the definitions=
mentioned in the next comment. Worth repeating the link to Section 9
of RFC 6749.

s3, All definitions after "app"; s/app/application/g in the
definitions as these are not restricted to (native) apps as defined
here.

Per earlier comment.
s3, "embedded user-agent": s/modify/modifyng/

Done.

s4, last para: s/emcompasses/encompasses/

Done.
s4, last para: s/inter-process/inter-app/ (since this term is
defined)

s4, last para: Might be worth pointing to the 'SHOULD' about client=
type assumptions in s2.1 of RFC 6749 withe reference to servers that
do make assumptions.

This is covered in= detail in Section 8.4. I'd like to keep this introduction light, and n= ot get into the details just yet.=C2=A0 Let me know if you think 8.4 is ina= dequate.

s4.1, para below figure 1: s/system browser/browser/ (or maybe
"designated browser").

Reword= ed.

s5, paras 1 and =C2=A02: Reword to clarify and remove 'we gain' usa= ge (not
allowed in RFCs):
OLD:
=C2=A0 =C2=A0Just as URIs are used for OAuth 2.0 [RFC6749] on the web to initiate
=C2=A0=C2=A0 the authorization request and return the authorization respons= e to
=C2=A0=C2=A0 the requesting website, URIs can be used by native apps to
initiate
=C2=A0=C2=A0 the authorization request in the device's browser and retu= rn the
=C2=A0=C2=A0 response to the requesting native app.

=C2=A0=C2=A0 By applying the same principles from the web to native apps, w= e
gain
=C2=A0=C2=A0 benefits seen on the web, like the usability of a single sign-= on
=C2=A0=C2=A0 session and the security of a separate authentication context.= =C2=A0 It
=C2=A0=C2=A0 also reduces the implementation complexity by reusing similar<= br> flows
=C2=A0=C2=A0 as the web, and increases interoperability by relying on
standards-
=C2=A0=C2=A0 based web flows that are not specific to a particular platform= .
NEW:
=C2=A0 =C2=A0Just as URIs are used for OAuth 2.0 [RFC6749] in the HTTP prot= ocol
on the web to initiate
=C2=A0=C2=A0 the authorization request and return the authorization respons= e to
=C2=A0=C2=A0 the requesting website, URIs can be used by native apps to
initiate
=C2=A0=C2=A0 the authorization request in the device's browser and retu= rn the
=C2=A0=C2=A0 response to the requesting native app.

=C2=A0=C2=A0 By extending the techniques from the web to native apps, the =C2=A0=C2=A0 benefits gained in the web context will also be reaped when us= ing=C2=A0
=C2=A0 =C2=A0OAuth with native apps; benefits include the usability of a si= ngle
sign-on
=C2=A0=C2=A0 session and the security of a separate authentication context.= =C2=A0 Use
of
=C2=A0 =C2=A0the techniques also reduces implementation complexity by reusi= ng
similar flows
=C2=A0 =C2=A0to those employed on the web, and increases interoperability b= y
relying on standards-
=C2=A0=C2=A0 based web flows that are not specific to a particular platform= .
END

Re-worded to remove "we gain&q= uot;, thanks for your suggestion.

s5, para 3: Suggest prefixing this para with: "To conform to this best=
practise," - the MUST is not derived from RFC 6749.

s7.1, last para: s/URI like it/URI as it/; s/like normal/as it would
normally/

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> s7.2, next to last para:
OLD:
Due to this reason, they SHOULD be used over the other redirect
choices for native apps where possible.
NEW:
For this reason, they SHOULD be used in preference to the other
redirect options for native apps where possible.
END

Done.

s7.2, last para: s/it REQUIRED/it is REQUIRED/

Done.

s8.1, para 2: Need to expand acronym PKCE at first use (currently
expanded in para 4).

PKCE now defined e= arlier in the doc.
=C2=A0
s8.1, para 4: s/sends data/send data/

D= one.

s8.2: It would be more consistent with RFC 6749 to refer to "Implicit<= br> Flow" as "Implicit Grant authorization flow" at least for th= e title
and first occurrence. =C2=A0 The second and third occurrences in para 1
should s/Implicit Flow/implicit flow/ for consistency with para 2.

Done.
=C2=A0
s8.2, para 2: s/code flow/Authorization Code Grant flow/

Done.

s8.3, last para: Is a reminder to choose the 'right' type of IP
literal (IPv4 or v6) desirable?=C2=A0 Doing an address lookup on
"localhost" presumably tells you which one to use! [perhaps?]
=

Good point, but I think this is an impleme= ntation consideration. I've added a note to 7.3.

s8.7, para 4: s/like/such as/

Done.
=C2=A0
s8.8; need to expand CSRF (Cross Site Request Forgery)
Done.
=C2=A0
and maybe
explain a it how CSRGF and the cross-app case are related
<= div>
Great point, done.

--001a113fe2dafe2c0d054fe6056b-- From nobody Sat May 20 01:24:10 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 887811287A0 for ; Sat, 20 May 2017 01:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HudER-S8CgtM for ; Sat, 20 May 2017 01:24:06 -0700 (PDT) Received: from p3plsmtpa06-10.prod.phx3.secureserver.net (p3plsmtpa06-10.prod.phx3.secureserver.net [173.201.192.111]) (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 6029C124234 for ; Sat, 20 May 2017 01:24:06 -0700 (PDT) Received: from [192.168.1.113] ([95.252.130.234]) by :SMTPAUTH: with SMTP id BzffdjIcsipIcBzfgdgMdB; Sat, 20 May 2017 01:23:34 -0700 To: oauth@ietf.org References: <698E4B80-754F-42E1-AD2B-602CD605C680@ve7jtb.com> From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: Date: Sat, 20 May 2017 10:23:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------05F7C67AABCAF50E8A292451" Content-Language: en-US X-CMAE-Envelope: MS4wfBAc3VypOdyvASge3JgNFPHTo5Az1hyOx1lBe3o5SpSRve6ISzVRNrz3FEc3wd4STOZn876JkcrrIPpgrTHtNOVYm0ytd/G1YqEVGRP/D5HOKJW4bXhd GCcsOdo0LkJA+m2zJNUBPl1gEET+pI2lg9qINH8/Y47oYJVyNxd+6Tn4 Archived-At: Subject: Re: [OAUTH-WG] re comments on MTLS (was Re: Call for Adoption: Mutual TLS Profiles for OAuth Clients) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2017 08:24:10 -0000 This is a multi-part message in MIME format. --------------05F7C67AABCAF50E8A292451 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 for tls_client_auth_root_dn, I find this name to be more exact. People may find issuer_dn ambiguous. +1 to also make it an array Thanks! Vladimir On 15/05/17 20:42, Brian Campbell wrote: > I'll add text/clarification that the DN metadata fields being RFC4514 > string representations of DNs in the next draft. > > Given that this is a profile of use and the metadata fields are just on= e > way to express the binding of certificate and client, and after thinkin= g > about it some more and not wanting to introduce too many variations, I = feel > that keeping tls_client_auth_subject_dn as the subject distinguished na= me > of the client certificate is more straightforward and sufficient for th= is > case. > > Is there rough consensus to change "tls_client_auth_issuer_dn" to > "tls_client_auth_root_dn" as was suggested? The latter name makes sense= to > me but I don't want to make that change without a little more input or > buy-in from the WG. So please respond one way or the other, if you've g= ot > an opinion. > > Similarly I'm looking for some rough consensus around if a single > root/issuer is sufficient in the metadata before potentially making any= > changes. Should "tls_client_auth_issuer/root_dn" remain a single DN str= ing > value or should it be an array allowing for more than one? > > > > On Fri, Apr 21, 2017 at 6:18 PM, John Bradley wrote= : > >> I agree with Brian. >> >> Trying to do anything with PKIX opens up cans of worms. One of the >> reasons we have resisted to this point. >> >> However there are server to server use cases that legitimately need th= is. >> >> I agree that in general DN is a mess, I suspect that telling people to= >> directly use the DER encoded version wont fly, so my thought was to us= e the >> RFC 4514 string representation that most tools produce. >> >> We did talk about subject alt DNS Names, however those may not be pres= ent >> in eIDAS certificates that some people may need to use for legal reaso= ns, >> or if it is present it might be an email. >> >> I suspect that users of this will fall into two camps. One that has a= >> small set of trusted CA that are configured out of band and any certif= icate >> from those roots with the correct DN is OK. >> >> The other group will be trying to do something more dynamic with SSL >> server certs (May or may not be EV) I could see those people preferr= ing >> DNS Name subject alt, or using JWKS to publish there certs. >> >> The problem is finding the right balance of flexibility without too ma= ny >> options to confuse people. >> >> I am inclined towards DN for those that are willing to suffer the pain= , >> and JWKS_uri for everyone else. One advantage of the JWKS_URI approa= ch is >> that self signed certs should work just fine, that is something that t= he >> R&E people will want if they use this. >> >> For most proof of possession we should be promoting token binding as t= he >> most flexible approach as it also works with mobile without per instan= ce >> registration. >> >> John B. >> >> >> On Apr 21, 2017, at 7:41 PM, Brian Campbell >> wrote: >> >> Thanks, James, for the adoption support as well as the review and >> comments. I've tried to respond to the comments inline below. >> >> On Thu, Apr 20, 2017 at 11:33 PM, Manger, James < >> James.H.Manger@team.telstra.com> wrote: >> >>> I support adoption of draft-campbell-oauth-mtls. >>> >>> Now some comments on the doc: >>> >>> 1. [=C2=A72.3] The syntax of tls_client_auth_subject_dn is not specif= ied. >>> Perhaps LDAP's "String Representation of Distinguished Names" [RFC451= 4]? >>> Perhaps a base64url-encoding of a DER-encoded DN? It would actually b= e >>> better to allow any subjectAltName to be specified, instead of a DN. >>> >> How about calling it tls_client_auth_subject and defining it as a stri= ng >> and allowing it to represent the expected subject which could be in th= e >> cert as the subject DN or a subjectAltName? For Subject DN and DN >> subjectAltNames it would be the "String Representation of Distinguishe= d >> Names" and an appropriate string for the other subjectAltName types (I= 'll >> have to look at what's there 'cause I don't know off hand and guidance= or >> suggested text is always more than welcome). >> >> >> >> >>> 2. [=C2=A72.3] Change the name of tls_client_auth_issuer_dn (maybe >>> tls_client_auth_root_dn). Given tls_client_auth_client_dn, it will be= too >>> easy to assume this pair refer to the issuer and subject fields of th= e cert. >>> >> The accompanying text tries to make it clear that it's the root issuer= but >> the tls_client_auth_issuer_dn name can certainly be changed to >> tls_client_auth_root_dn or something along those lines, if folks think= the >> name in -01 is liable to cause confusion? >> >> >> >> PKI chains can be complex so the expected root might not be such a sta= ble >>> concept. For example, the Let's Encrypt CA chains to an ISRG Root and= an >>> IdenTrust DST Root [https://letsencrypt.org/certificates/]. >>> >> The goal was to provide a metadata field to express some constraint fo= r >> what is kind of expected to be a common deployment of a number of enti= ties >> participating in some OAuth API thing and are being issued certificate= s >> from a common issuer for the group of participants. >> >> Perhaps it should be an array of strings rather than a single value? >> >> Or do you have suggestions for some alternative? >> >> >> >> >>> 3. [=C2=A72.3] If a client dynamically registers a "jwks_uri" does th= is mean >>> the authz server MUST automatically cope when the client updates the = key(s) >>> it publishes there? >>> >> If the authz server supports that kind of trust model as well as >> dynamically registration, then I would expect so, yes. >> >> >> >> >>> 4. [=C2=A73] An access token is bound to a specific client certificat= e. That >>> is probably ok, but does mean all access tokens die when the client u= pdates >>> their certificate (which could be every 2 months if using Let's Encry= pt). >>> This at least warrants a paragraph in the Security Considerations. >>> >> In my own mind that was implied and okay because it's likely that acce= ss >> tokens will have a shorter lifespan than certificates and refreshing o= r >> getting a new access token is typically easy anyhow. >> >> Anyway, it doesn't hurt to be explicit about it, can you propose some = such >> text for the Security Considerations? >> >> >> >> >>> 5. [=C2=A73.1] "exp" and "nbf" values in the example need to be numbe= rs, not >>> strings (drop the quotes). >>> >> Silly mistake on my part. Thanks for catching that. Will fix. >> >> >> >>> 6. An access token linked to a client TLS cert isn't a bearer token. = The >>> spec should really define a new token_type for responses from the tok= en >>> endpoint. That might not necessarily mean we needs a new HTTP >>> authentication scheme as well (it might just hint that "Bearer" wasn'= t >>> quite the right name). >>> >> Indeed "Bearer" isn't quite right and very likely a name that would be= >> different with the benefit of hindsight. But other than having names o= n the >> wire that are more true to the nature of the tokens, I don't know that= a >> new token_type or HTTP auth scheme adds value to the use cases here. >> However, they would likely make deployment of this stuff more cumberso= me >> and take longer. Whereas many systems can likely plug in mutual TLS o= n top >> of the existing token_type and HTTP auth scheme without major changes.= I'm >> strongly inclined to not introduce a new token_type and more inclined = to >> not do a new HTTP auth scheme. >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------05F7C67AABCAF50E8A292451 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

+1 for tls_client_auth_root_dn, I find this name to be more exact. People may find issuer_dn ambiguous.

+1 to also make it an array


Thanks!

Vladimir


On 15/05/17 20:42, Brian Campbell wrote:
I'll add text/clarification that the DN metadata fields being RFC4514
string representations of DNs in the next draft.

Given that this is a profile of use and the metadata fields are just one
way to express the binding of certificate and client, and after thinking
about it some more and not wanting to introduce too many variations, I feel
that keeping tls_client_auth_subject_dn as the subject distinguished name
of the client certificate is more straightforward and sufficient for this
case.

Is there rough consensus to change "tls_client_auth_issuer_dn" to
"tls_client_auth_root_dn" as was suggested? The latter name makes sense to
me but I don't want to make that change without a little more input or
buy-in from the WG. So please respond one way or the other, if you've got
an opinion.

Similarly I'm looking for some rough consensus around if a single
root/issuer is sufficient in the metadata before potentially making any
changes. Should "tls_client_auth_issuer/root_dn" remain a single DN string
value or should it be an array allowing for more than one?



On Fri, Apr 21, 2017 at 6:18 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:


I agree with Brian.

Trying to do anything with PKIX opens up cans of worms.  One of the
reasons we have resisted to this point.

However there are server to server use cases that legitimately need this.

I agree that in general DN is a mess, I suspect that telling people to
directly use the DER encoded version wont fly, so my thought was to use the
RFC 4514 string representation that most tools produce.

We did talk about subject alt DNS Names, however those may not be present
in eIDAS certificates that some people may need to use for legal reasons,
or if it is present it might be an email.

I suspect that users of this will fall into two camps.  One that has a
small set of trusted CA that are configured out of band and any certificate
from those roots with the correct DN is OK.

The other group will be trying to do something more dynamic with SSL
server certs (May or may not be EV)   I could see those people preferring
DNS Name subject alt, or using JWKS to publish there certs.

The problem is finding the right balance of flexibility without too many
options to confuse people.

I am inclined towards DN for those that are willing to suffer the pain,
and JWKS_uri for everyone else.   One advantage of the JWKS_URI approach is
that self signed certs should work just fine, that is something that the
R&E people will want if they use this.

For most proof of possession we should be promoting token binding as the
most flexible approach as it also works with mobile without per instance
registration.

John B.


On Apr 21, 2017, at 7:41 PM, Brian Campbell <bcampbell@pingidentity.com>
wrote:

Thanks, James, for the adoption support as well as the review and
comments. I've tried to respond to the comments inline below.

On Thu, Apr 20, 2017 at 11:33 PM, Manger, James <
James.H.Manger@team.telstra.com> wrote:


I support adoption of draft-campbell-oauth-mtls.

Now some comments on the doc:

1. [§2.3] The syntax of tls_client_auth_subject_dn is not specified.
Perhaps LDAP's "String Representation of Distinguished Names" [RFC4514]?
Perhaps a base64url-encoding of a DER-encoded DN? It would actually be
better to allow any subjectAltName to be specified, instead of a DN.


How about calling it tls_client_auth_subject and defining it as a string
and allowing it to represent the expected subject which could be in the
cert as the subject DN or a subjectAltName? For Subject DN and DN
subjectAltNames it would be the "String Representation of Distinguished
Names" and an appropriate string for the other subjectAltName types (I'll
have to look at what's there 'cause I don't know off hand and guidance or
suggested text is always more than welcome).





2. [§2.3] Change the name of tls_client_auth_issuer_dn (maybe
tls_client_auth_root_dn). Given tls_client_auth_client_dn, it will be too
easy to assume this pair refer to the issuer and subject fields of the cert.


The accompanying text tries to make it clear that it's the root issuer but
the tls_client_auth_issuer_dn name can certainly be changed to
tls_client_auth_root_dn or something along those lines, if folks think the
name in -01 is liable to cause confusion?



PKI chains can be complex so the expected root might not be such a stable

concept. For example, the Let's Encrypt CA chains to an ISRG Root and an
IdenTrust DST Root [https://letsencrypt.org/certificates/].


The goal was to provide a metadata field to express some constraint for
what is kind of expected to be a common deployment of a number of entities
participating in some OAuth API thing and are being issued certificates
from a common issuer for the group of participants.

Perhaps it should be an array of strings rather than a single value?

Or do you have suggestions for some alternative?





3. [§2.3] If a client dynamically registers a "jwks_uri" does this mean
the authz server MUST automatically cope when the client updates the key(s)
it publishes there?


If the authz server supports that kind of trust model as well as
dynamically registration, then I would expect so, yes.





4. [§3] An access token is bound to a specific client certificate. That
is probably ok, but does mean all access tokens die when the client updates
their certificate (which could be every 2 months if using Let's Encrypt).
This at least warrants a paragraph in the Security Considerations.


In my own mind that was implied and okay because it's likely that access
tokens will have a shorter lifespan than certificates and refreshing or
getting a new access token is typically easy anyhow.

Anyway, it doesn't hurt to be explicit about it, can you propose some such
text for the Security Considerations?





5. [§3.1] "exp" and "nbf" values in the example need to be numbers, not
strings (drop the quotes).


Silly mistake on my part. Thanks for catching that. Will fix.




6. An access token linked to a client TLS cert isn't a bearer token. The
spec should really define a new token_type for responses from the token
endpoint. That might not necessarily mean we needs a new HTTP
authentication scheme as well (it might just hint that "Bearer" wasn't
quite the right name).


Indeed "Bearer" isn't quite right and very likely a name that would be
different with the benefit of hindsight. But other than having names on the
wire that are more true to the nature of the tokens, I don't know that a
new token_type or HTTP auth scheme adds value to the use cases here.
However, they would likely make deployment of this stuff more cumbersome
and take longer.  Whereas many systems can likely plug in mutual TLS on top
of the existing token_type and HTTP auth scheme without major changes. I'm
strongly inclined to not introduce a new token_type and more inclined to
not do a new HTTP auth scheme.



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





      

      

      

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


    

  


--------------05F7C67AABCAF50E8A292451--


From nobody Sat May 20 07:44:50 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E64126DC2 for ; Sat, 20 May 2017 07:44:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7LT-Sg9M9Yy for ; Sat, 20 May 2017 07:44:45 -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 A27251201F8 for ; Sat, 20 May 2017 07:44:45 -0700 (PDT)
Received: by mail-qk0-x22c.google.com with SMTP id u75so79982632qka.3 for ; Sat, 20 May 2017 07:44:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2sD4yBPNI0h7Ocvm11tOrexin6sumZ0chgNCLwLgI3w=; b=vjYAreLSPPpNhXs2xE0XrdHRhuqd589NIz70Nd9EvS1qxGcuOvyVEV0rEMVJC+Uycs tkrYzUO2opBJW5IkiwtLk8R1Eypa54B086NO+0mtHa54rBx2WtMlhdeZTB5siPcIzLvS quAAi7ds+bQt8jQA2a+sotvRtauphccLU+P/UfCRlwGl2WEdPf574NMspCBhezWOl4s5 lB+og/75H4XyOfLP9jFWh7/6Q2P35s6qkEz8Z+PHrMBxV3YIV9q/tVGgaBHuK5WZIBXn m1+g2Ma4R0kmrfhGmXhMVcCZZx1/3OpcmhGu886EwVC2VUsSB21lekMbDu//6vAsXqhP kizg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=2sD4yBPNI0h7Ocvm11tOrexin6sumZ0chgNCLwLgI3w=; b=r48o78yRLSbV+oAPCwoeGORUZqFNbXc+4r0nK7mw1fnmAAMp1GoHQTHUofoFgnajS5 f9iH6FIQpysVBM4iSNrc0RTFU/42jff3VbbX+UwKKG6R0qTSMBfQ1OImz5lTAMBcPdE7 4XkpSZ82GwNJcI4x7ZyUEnScv2IBeEWSyZl9o56fnLxygKHi/vgAuWGPfa6w72LQv9gS 9uZmHNb43O1cd+Ff0rbVdLYMoalrtbJYYuNq+8+G389/Zzp0RMF8qIJt7uadbUKdUB4s UAsiSOdwgi759szVBxQdnPBFqiclojy2IXq23D/Zsi4QjFGDV4QMRnq3wGsb8DOgJmeY pppA==
X-Gm-Message-State: AODbwcDA71mgm8puKrs6Lx3PR95zdmq4HLwC6kZ6djj/0/fuJFYQPzeP f1f0VeberY82oQn5
X-Received: by 10.55.169.193 with SMTP id s184mr13085501qke.118.1495291484596;  Sat, 20 May 2017 07:44:44 -0700 (PDT)
Received: from [192.168.8.100] ([181.201.143.235]) by smtp.gmail.com with ESMTPSA id x139sm8302228qkx.20.2017.05.20.07.44.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 20 May 2017 07:44:43 -0700 (PDT)
From: John Bradley 
Message-Id: <77F2A1D2-5A8E-4E88-9920-A15BC24795E6@ve7jtb.com>
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Sat, 20 May 2017 10:44:09 -0400
In-Reply-To: 
Cc: "Manger, James" , "oauth@ietf.org" 
To: Brian Campbell 
References:  <698E4B80-754F-42E1-AD2B-602CD605C680@ve7jtb.com> 
X-Mailer: Apple Mail (2.3273)
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c060616ca8f97054ff5ad26"
Archived-At: 
Subject: Re: [OAUTH-WG] re comments on MTLS (was Re: Call for Adoption: Mutual TLS Profiles for OAuth Clients)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 May 2017 14:44:48 -0000

--94eb2c060616ca8f97054ff5ad26
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_A8A9BED2-5EAC-4643-8080-18DA1C815F5F"


--Apple-Mail=_A8A9BED2-5EAC-4643-8080-18DA1C815F5F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

+1 for =E2=80=9Ctls_client_auth_root_dn"

On making it an array, I think that adds complexity for little gain, and =
perhaps introduces new trust issues.

I think it should be one trusted root or all the trusted roots.  If you =
only trust 5 then configure that in the AS.

An array seems only useful where the client has a cert from x but may =
want to get the next one from y and not re-register.=20
I think if the client or federation operator is locking itself down to =
specific issuers one per client should be fine.
I expect that in most cases the issuer will need to be in the trust =
store of the AS anyway so this is just pinning the cert to one of a =
limited set.

John B.

> On May 15, 2017, at 2:42 PM, Brian Campbell =
 wrote:
>=20
> I'll add text/clarification that the DN metadata fields being RFC4514 =
string representations of DNs in the next draft.
>=20
> Given that this is a profile of use and the metadata fields are just =
one way to express the binding of certificate and client, and after =
thinking about it some more and not wanting to introduce too many =
variations, I feel that keeping tls_client_auth_subject_dn as the =
subject distinguished name of the client certificate is more =
straightforward and sufficient for this case.
>=20
> Is there rough consensus to change "tls_client_auth_issuer_dn" to =
"tls_client_auth_root_dn" as was suggested? The latter name makes sense =
to me but I don't want to make that change without a little more input =
or buy-in from the WG. So please respond one way or the other, if you've =
got an opinion. =20
>=20
> Similarly I'm looking for some rough consensus around if a single =
root/issuer is sufficient in the metadata before potentially making any =
changes. Should "tls_client_auth_issuer/root_dn" remain a single DN =
string value or should it be an array allowing for more than one?=20
>=20
>=20
>=20
> On Fri, Apr 21, 2017 at 6:18 PM, John Bradley > wrote:
> I agree with Brian.
>=20
> Trying to do anything with PKIX opens up cans of worms.  One of the =
reasons we have resisted to this point.
>=20
> However there are server to server use cases that legitimately need =
this.
>=20
> I agree that in general DN is a mess, I suspect that telling people to =
directly use the DER encoded version wont fly, so my thought was to use =
the RFC 4514 string representation that most tools produce.
>=20
> We did talk about subject alt DNS Names, however those may not be =
present in eIDAS certificates that some people may need to use for legal =
reasons, or if it is present it might be an email.
>=20
> I suspect that users of this will fall into two camps.  One that has a =
small set of trusted CA that are configured out of band and any =
certificate from those roots with the correct DN is OK.
>=20
> The other group will be trying to do something more dynamic with SSL =
server certs (May or may not be EV)   I could see those people =
preferring DNS Name subject alt, or using JWKS to publish there certs.
>=20
> The problem is finding the right balance of flexibility without too =
many options to confuse people.
>=20
> I am inclined towards DN for those that are willing to suffer the =
pain, and JWKS_uri for everyone else.   One advantage of the JWKS_URI =
approach is that self signed certs should work just fine, that is =
something that the R&E people will want if they use this. =20
>=20
> For most proof of possession we should be promoting token binding as =
the most flexible approach as it also works with mobile without per =
instance registration.
>=20
> John B.
>=20
>=20
>> On Apr 21, 2017, at 7:41 PM, Brian Campbell =
> wrote:
>>=20
>> Thanks, James, for the adoption support as well as the review and =
comments. I've tried to respond to the comments inline below.=20
>>=20
>> On Thu, Apr 20, 2017 at 11:33 PM, Manger, James =
> wrote:
>> I support adoption of draft-campbell-oauth-mtls.
>>=20
>> Now some comments on the doc:
>>=20
>> 1. [=C2=A72.3] The syntax of tls_client_auth_subject_dn is not =
specified. Perhaps LDAP's "String Representation of Distinguished Names" =
[RFC4514]? Perhaps a base64url-encoding of a DER-encoded DN? It would =
actually be better to allow any subjectAltName to be specified, instead =
of a DN.
>>=20
>> How about calling it tls_client_auth_subject and defining it as a =
string and allowing it to represent the expected subject which could be =
in the cert as the subject DN or a subjectAltName? For Subject DN and DN =
subjectAltNames it would be the "String Representation of Distinguished =
Names" and an appropriate string for the other subjectAltName types =
(I'll have to look at what's there 'cause I don't know off hand and =
guidance or suggested text is always more than welcome).=20
>> =20
>>=20
>>=20
>>=20
>> 2. [=C2=A72.3] Change the name of tls_client_auth_issuer_dn (maybe =
tls_client_auth_root_dn). Given tls_client_auth_client_dn, it will be =
too easy to assume this pair refer to the issuer and subject fields of =
the cert.
>>=20
>> The accompanying text tries to make it clear that it's the root =
issuer but the tls_client_auth_issuer_dn name can certainly be changed =
to tls_client_auth_root_dn or something along those lines, if folks =
think the name in -01 is liable to cause confusion?
>> =20
>>=20
>>=20
>> PKI chains can be complex so the expected root might not be such a =
stable concept. For example, the Let's Encrypt CA chains to an ISRG Root =
and an IdenTrust DST Root [https://letsencrypt.org/certificates/ =
].
>>=20
>> The goal was to provide a metadata field to express some constraint =
for what is kind of expected to be a common deployment of a number of =
entities participating in some OAuth API thing and are being issued =
certificates from a common issuer for the group of participants.=20
>>=20
>> Perhaps it should be an array of strings rather than a single value?
>>=20
>> Or do you have suggestions for some alternative?
>>=20
>>=20
>>=20
>>=20
>> 3. [=C2=A72.3] If a client dynamically registers a "jwks_uri" does =
this mean the authz server MUST automatically cope when the client =
updates the key(s) it publishes there?
>>=20
>> If the authz server supports that kind of trust model as well as =
dynamically registration, then I would expect so, yes.=20
>> =20
>>=20
>>=20
>>=20
>> 4. [=C2=A73] An access token is bound to a specific client =
certificate. That is probably ok, but does mean all access tokens die =
when the client updates their certificate (which could be every 2 months =
if using Let's Encrypt). This at least warrants a paragraph in the =
Security Considerations.
>>=20
>> In my own mind that was implied and okay because it's likely that =
access tokens will have a shorter lifespan than certificates and =
refreshing or getting a new access token is typically easy anyhow.
>>=20
>> Anyway, it doesn't hurt to be explicit about it, can you propose some =
such text for the Security Considerations?
>>=20
>>=20
>> =20
>>=20
>> 5. [=C2=A73.1] "exp" and "nbf" values in the example need to be =
numbers, not strings (drop the quotes).
>>=20
>> Silly mistake on my part. Thanks for catching that. Will fix.=20
>>=20
>> =20
>>=20
>> 6. An access token linked to a client TLS cert isn't a bearer token. =
The spec should really define a new token_type for responses from the =
token endpoint. That might not necessarily mean we needs a new HTTP =
authentication scheme as well (it might just hint that "Bearer" wasn't =
quite the right name).
>>=20
>> Indeed "Bearer" isn't quite right and very likely a name that would =
be different with the benefit of hindsight. But other than having names =
on the wire that are more true to the nature of the tokens, I don't know =
that a new token_type or HTTP auth scheme adds value to the use cases =
here. However, they would likely make deployment of this stuff more =
cumbersome and take longer.  Whereas many systems can likely plug in =
mutual TLS on top of the existing token_type and HTTP auth scheme =
without major changes. I'm strongly inclined to not introduce a new =
token_type and more inclined to not do a new HTTP auth scheme.
>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth =

>=20
>=20


--Apple-Mail=_A8A9BED2-5EAC-4643-8080-18DA1C815F5F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

+1 for =E2=80=9Ctls_client_auth_root_dn"

On making it an array, I think that =
adds complexity for little gain, and perhaps introduces new trust =
issues.

I =
think it should be one trusted root or all the trusted roots.  If =
you only trust 5 then configure that in the AS.

An array seems only useful where the =
client has a cert from x but may want to get the next one from y and not =
re-register. 
I think if the client or =
federation operator is locking itself down to specific issuers one per =
client should be fine.
I expect that in most cases =
the issuer will need to be in the trust store of the AS anyway so this =
is just pinning the cert to one of a limited set.
John B.

On May 15, 2017, at 2:42 PM, Brian Campbell =
<bcampbell@pingidentity.com> wrote:

I'll add text/clarification =
that the DN metadata fields being RFC4514 string representations of DNs =
in the next draft.

Given that this is =
a profile of use and the metadata fields are just one way to express the =
binding of certificate and client, and after thinking about it some more =
and not wanting to introduce too many variations, I feel that keeping =
tls_client_auth_subject_dn as the subject distinguished name of the =
client certificate is more straightforward and sufficient for this =
case.

Is there rough consensus to change =
"tls_client_auth_issuer_dn" to  "tls_client_auth_root_dn" as was =
suggested? The latter name makes sense to me but I don't want to make =
that change without a little more input or buy-in from the WG. So please =
respond one way or the other, if you've got an opinion.  

Similarly I'm looking for some rough =
consensus around if a single root/issuer is sufficient in the metadata =
before potentially making any changes. Should =
"tls_client_auth_issuer/root_dn" remain a single DN string value or =
should it be an array allowing for more than one? 



On Fri, =
Apr 21, 2017 at 6:18 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I agree with Brian.

Trying to do anything =
with PKIX opens up cans of worms.  One of the reasons we have =
resisted to this point.

However there are server to server use cases that =
legitimately need this.

I agree that in general DN is a mess, I suspect that telling =
people to directly use the DER encoded version wont fly, so my thought =
was to use the RFC 4514 string representation that most tools =
produce.

We =
did talk about subject alt DNS Names, however those may not be present =
in eIDAS certificates that some people may need to use for legal =
reasons, or if it is present it might be an email.

I suspect that users of =
this will fall into two camps.  One that has a small set of trusted =
CA that are configured out of band and any certificate from those roots =
with the correct DN is OK.

The other group will be trying to do something more dynamic =
with SSL server certs (May or may not be EV)   I could see those =
people preferring DNS Name subject alt, or using JWKS to publish there =
certs.

The =
problem is finding the right balance of flexibility without too many =
options to confuse people.

I am inclined towards DN for those that are willing to suffer =
the pain, and JWKS_uri for everyone else.   One advantage of the =
JWKS_URI approach is that self signed certs should work just fine, that =
is something that the R&E people will want if they use this. =
 

For =
most proof of possession we should be promoting token binding as the =
most flexible approach as it also works with mobile without per instance =
registration.

John B.


On Apr 21, 2017, at 7:41 PM, Brian Campbell =
<bcampbell@pingidentity.com> wrote:

Thanks, James, for the adoption support as well as the review =
and comments. I've tried to respond to the comments inline below. 

On Thu, Apr 20, 2017 at 11:33 PM, Manger, James =
<James.H.Manger@team.telstra.com> =
wrote:
I support adoption of =
draft-campbell-oauth-mtls.



Now some comments on the doc:



1. [=C2=A72.3] The syntax of tls_client_auth_subject_dn is not =
specified. Perhaps LDAP's "String Representation of Distinguished Names" =
[RFC4514]? Perhaps a base64url-encoding of a DER-encoded DN? It would =
actually be better to allow any subjectAltName to be specified, instead =
of a DN.

How about calling it =
tls_client_auth_subject and defining it as a string and allowing it to =
represent the expected subject which could be in the cert as the subject =
DN or a subjectAltName? For Subject DN and DN subjectAltNames it would =
be the "String Representation of Distinguished Names" and an appropriate =
string for the other subjectAltName types (I'll have to look at what's =
there 'cause I don't know off hand and guidance or suggested text is =
always more than welcome). 
 





2. [=C2=A72.3] Change the name of tls_client_auth_issuer_dn (maybe =
tls_client_auth_root_dn). Given tls_client_auth_client_dn, it will be =
too easy to assume this pair refer to the issuer and subject fields of =
the cert.

The accompanying text tries to make it =
clear that it's the root issuer but the tls_client_auth_issuer_dn name =
can certainly be changed to tls_client_auth_root_dn or something along =
those lines, if folks think the name in -01 is liable to cause =
confusion?
 



PKI chains can be complex so the expected root might not be such a =
stable concept. For example, the Let's Encrypt CA chains to an ISRG Root =
and an IdenTrust DST Root [https://letsencrypt.org/certificates/].

The goal was to provide a metadata =
field to express some constraint for what is kind of expected to be a =
common deployment of a number of entities participating in some OAuth =
API thing and are being issued certificates from a common issuer for the =
group of participants. 

Perhaps it should be an array of strings rather than a single =
value?

Or do you have =
suggestions for some alternative?






3. [=C2=A72.3] If a client dynamically registers a "jwks_uri" does this =
mean the authz server MUST automatically cope when the client updates =
the key(s) it publishes there?

If the authz server =
supports that kind of trust model as well as dynamically registration, =
then I would expect so, yes. 
 





4. [=C2=A73] An access token is bound to a specific client certificate. =
That is probably ok, but does mean all access tokens die when the client =
updates their certificate (which could be every 2 months if using Let's =
Encrypt). This at least warrants a paragraph in the Security =
Considerations.

In my own mind that was implied and =
okay because it's likely that access tokens will have a shorter lifespan =
than certificates and refreshing or getting a new access token is =
typically easy anyhow.

Anyway, it doesn't hurt to be explicit about it, can you =
propose some such text for the Security Considerations?


 



5. [=C2=A73.1] "exp" and "nbf" values in the example need to be numbers, =
not strings (drop the quotes).

Silly mistake on my =
part. Thanks for catching that. Will fix. 

 



6. An access token linked to a client TLS cert isn't a bearer token. The =
spec should really define a new token_type for responses from the token =
endpoint. That might not necessarily mean we needs a new HTTP =
authentication scheme as well (it might just hint that "Bearer" wasn't =
quite the right name).

Indeed "Bearer" isn't quite right and =
very likely a name that would be different with the benefit of =
hindsight. But other than having names on the wire that are more true to =
the nature of the tokens, I don't know that a new token_type or HTTP =
auth scheme adds value to the use cases here. However, they would likely =
make deployment of this stuff more cumbersome and take longer.  =
Whereas many systems can likely plug in mutual TLS on top of the =
existing token_type and HTTP auth scheme without major changes. I'm =
strongly inclined to not introduce a new token_type and more inclined to =
not do a new HTTP auth scheme. 




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





=

--Apple-Mail=_A8A9BED2-5EAC-4643-8080-18DA1C815F5F--

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

MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg
gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG
A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy
MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl
ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl
ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1
cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW
pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW
/qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G
sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt
MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G
Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g
JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud
EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw
BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1
c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v
b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er
wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y
G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum
NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG
NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2
ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU
MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3
b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX
DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD
VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0
ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng
TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt
Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH
E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA
Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl
ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL
VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6
xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG
A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4
dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5
gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW
t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC
Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0
cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda
e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB
mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs
Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2
IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw
MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB
o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM
Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f
a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN
M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR
AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU
Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l
BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9
MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0
L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy
NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB
gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp
ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov
L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3
DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL
5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM
JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N
BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU
jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx
CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv
cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD
bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y
FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIPK735/nDnJkMdyE7+76pRO+i82q
ALS4WqTWK6ysrdtAMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3
MDUyMDE0NDQ0NFowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG
CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl
AwQCATANBgkqhkiG9w0BAQEFAASCAQAhlQPMOCIhht8l6CZGJ3h2WX7S3l1QL4RQ68Smj7IWtIrr
e9ospelDpEuY72gFLywpzyofzA0xTu0afkfl/ZkAH/ECEWUBEVddqua1ndmPoJJElcBs920XTEM/
HPXx9mKBZnrGY38/3j2GIMqr01tHtAI1xuRwClkEf4dejQoMDVfY1u/+AwO+g3pqv4LYvKHbpntu
g69OjR3MiheUBJNTVXwgmP46Hpc0OAi5ySR3ArhLc3bN5RDXEAfexAne42Doe0OFIbUMVd+oNDfO
+NNsI/LUXQDMKFV8ZUHgIS013xff6G9K+4xhQEg6lRLOX1HudgjToaCL6Dr6EkDx0N3J
--94eb2c060616ca8f97054ff5ad26--


From nobody Sun May 21 20:05:32 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE08129515; Sun, 21 May 2017 20:05:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.82
X-Spam-Level: 
X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KiFsNPJH4Ryt; Sun, 21 May 2017 20:05:14 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33F95124B0A; Sun, 21 May 2017 20:05:13 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DHB06537; Mon, 22 May 2017 03:05:11 +0000 (GMT)
Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 22 May 2017 04:05:09 +0100
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.49]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0301.000; Mon, 22 May 2017 11:05:05 +0800
From: wangzitao 
To: "ops-dir@ietf.org" 
CC: "oauth@ietf.org" , "draft-ietf-oauth-native-apps.all@ietf.org" , "ietf@ietf.org" 
Thread-Topic: [OPS-DIR] Opsdir telechat review of draft-ietf-oauth-native-apps-10
Thread-Index: AdLSqDVW3BTeNlgFQ6WqlwAw3ux67g==
Date: Mon, 22 May 2017 03:05:04 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.136.79.161]
Content-Type: multipart/alternative; boundary="_000_E6BC9BBCBCACC246846FC685F9FF41EA2AE094F0DGGEMM506MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.59225567.00BB, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.3.49, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 01d0af88b641625d75bea2fdc53aa751
Archived-At: 
Subject: [OAUTH-WG] [OPS-DIR] Opsdir telechat review of draft-ietf-oauth-native-apps-10
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 03:05:18 -0000

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

Reviewer: Zitao Wang (Michael)

Review result: Has Nits



I have reviewed this document as part of the Operational directorate's ongo=
ing effort to review all IETF documents being processed by the IESG.  These=
 comments were written with the intent of improving the operational aspects=
 of the IETF drafts. Comments that are not addressed in last call may be in=
cluded in AD reviews during the IESG review.  Document editors and WG chair=
s should treat these comments just like any other last call comments.



Document reviewed:  draft-ietf-oauth-native-apps-10



Summary:


OAuth 2.0 authorization requests from native apps should only be made
through external user-agents, primarily the user's browser. This
specification details the security and usability reasons why this is
the case, and how native apps and authorization servers can implement

this best practice.


I think the document is written very clear, except some small nits:

Page 3:     The last sentence of introduction-- "This practice is also know=
n as the AppAuth pattern".

I suggest adding a reference to explain the AppAuth pattern.



Page 3:     Terminology -- "OAuth".

I suggest modifying to: "OAuth"   The Web Authorization (OAuth) protocol.  =
In this document, OAuth refers to OAuth 2.0 [RFC6749].



Page 4:     Terminology -- "web-view"  A web browser UI component.

Does it mean "User Information"?  Suggest expanding this abbreviation.



Page 5:     Figure 1.   Does the browser and authorization endpoint are som=
e kinds of "external user-agent"? Suggest describing it more clearly.


Page   9:   PKCE [RFC7636] details how this limitation can be used to execu=
te a code interception attack (see Figure 1).

Does the Figure 1 means "Figure 1 of RFC7636"?


Page10:     However, as the Implicit Flow cannot be protected by PKCE
Seems here, the reference be omitted.





A run of idnits revealed no errors, flaws. There were 1 warning and 1 comme=
nts though



  =3D=3D There are 1 instance of lines with non-RFC2606-compliant FQDNs in =
the

     document.





  Miscellaneous warnings:

  -------------------------------------------------------------------------=
---



  -- The document date (April 26, 2017) is 14 days in the past.  Is this

     intentional?





  Checking references for intended status: Best Current Practice

  -------------------------------------------------------------------------=
---



     (See RFCs 3967 and 4897 for information about using normative referenc=
es

     to lower-maturity documents in RFCs)



     No issues found here.



     Summary: 0 errors (**), 0 flaws (~~), 1 warning (=3D=3D), 1 comment (-=
-).





_______________________________________________

OPS-DIR mailing list

OPS-DIR@ietf.org

https://www.ietf.org/mailman/listinfo/ops-dir


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











Reviewer: Zitao Wang (Michael)


Review result: Has Nits


 


I have reviewed this document as part of the Oper=
ational directorate’s ongoing effort to review all IETF document=
s being processed by the IESG.  These comments were written with =
the intent of improving the operational aspects of the
 IETF drafts. Comments that are not addressed in last call may be included =
in AD reviews during the IESG review.  Document editors and WG ch=
airs should treat these comments just like any other last call comment=
s.


 


Document reviewed:  draft-ietf-oauth-native-=
apps-10


 


Summary: 


 



OAuth 2.0 authorizati=
on requests from native apps should only be made



through external user=
-agents, primarily the user’s browser. This



specification details=
 the security and usability reasons why this is



the case, and how nat=
ive apps and authorization servers can implement


this best practice.


 


I think the document is written very clear, except some =
small nits:


P=
age 3:     The last sentence of introduction-- R=
20;This practice is also known as the AppAuth pattern”.  



I=
 suggest adding a reference to explain the AppAuth pattern.


 


Page 3:     Terminology -- &q=
uot;OAuth".  


I=
 suggest modifying to: "OAuth"   The Web Authorization =
(OAuth) protocol.  In this document, OAuth refers to OAuth 2.0 [RFC674=
9].


 


Page 4:     Terminology -- &q=
uot;web-view"  A web browser UI component.  



D=
oes it mean "User Information"?  Suggest expanding this abbr=
eviation.


 


Page 5:     Figure 1. &n=
bsp; Does the browser and authorization endpoint are some kinds of "ex=
ternal user-agent"? Suggest describing it more clearly.


 



Page   9:&n=
bsp;  PKCE [RFC7636] details how this limitation can be used to execut=
e a code interception attack (see Figure 1).   



D=
oes the Figure 1 means “Figure 1 of RFC7636”? 



 



Page10:  &n=
bsp;  However, as the Implicit Flow cannot be protected by PKCE &=
nbsp;  




Seems here, the refer=
ence be omitted. 



 


 


A run of idnits =
revealed no errors, flaws. There were 1 warning and 1 comments though<=
/o:p>


 


  =3D=3D There are 1 instance of line=
s with non-RFC2606-compliant FQDNs in the


     document.


 


 


  Miscellaneous warnings:<=
/span>


  -----------------------------------=
-----------------------------------------


 


  -- The document date (April 26, 201=
7) is 14 days in the past.  Is this


     intentional?=



 


 


  Checking references for intended st=
atus: Best Current Practice


  -----------------------------------=
-----------------------------------------


 


     (See RFCs 3967 an=
d 4897 for information about using normative references

     to lower-maturity=
 documents in RFCs)


 


     No issues found h=
ere.


 


     Summary: 0 errors=
 (**), 0 flaws (~~), 1 warning (=3D=3D), 1 comment (--).


 


 


_______________________________________________


OPS-DIR mailing list


OPS-DIR@ietf.=
org


https://www.ietf.org/mailman/listinfo/ops-dir


 






--_000_E6BC9BBCBCACC246846FC685F9FF41EA2AE094F0DGGEMM506MBXchi_--


From nobody Mon May 22 08:03:29 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA6A612EAF9 for ; Mon, 22 May 2017 08:03:22 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vp8-myzOsiF8 for ; Mon, 22 May 2017 08:03:20 -0700 (PDT)
Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AEAB12EAFC for ; Mon, 22 May 2017 08:03:11 -0700 (PDT)
Received: by mail-pf0-x232.google.com with SMTP id e193so85036427pfh.0 for ; Mon, 22 May 2017 08:03:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4VwqlwHcP4GBf+xvlrNBCt9v/IZ125aHc6RLI1pBnVg=; b=h/k14faV7lNVzv3KQCV/jhDGzXmKRNmO6d34zaP0wC7voxb1zSUX65xjvjFNze73eN qwV1SIpLfSZ/ydVkKyj8A/Gi+505GBg39OmZFxUI1gYk7j49JB/lOqOEU9QBjXmbGsJr 92yYiWKz051Ez8bT2exooTHjb7F0ymciMU+Sk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4VwqlwHcP4GBf+xvlrNBCt9v/IZ125aHc6RLI1pBnVg=; b=NTeXLF9gQOJvbXTfo6AFxz//G1ko+rwOk6kuLMfOMuAHC42VLsfhaNKe5ZTgXaGDW6 WCcV5GfbiOfSvnSpqtk8Vglu6+UZVj+zih1rK93yFSvMr90+6rb8lSYG31r/G132veH9 /QWxFE1pDk9i8LjaVDV8R89jTuIF+GzeXn4GGQg5r7H8LB3E2C4g0YmUvxF7KTSWzVVJ q94QQpO2ShMV+ocoerz0P2VtPrDxRU1u/0QlUUtAVvCCFv9pC/UNq4yOU2xk+6SAHJSH 90fQUp8alEMO0Cp5UaKcx0ntpkMu06vXyYrO66eXz0N5VIeKcp9/JqSg16mCtgDwPg+N wtgg==
X-Gm-Message-State: AODbwcDRObj7DaebvLN1GXym85I4Vy0Y3e7acFfGQNYKixkJxvB0sku7 CelLvNhQayi7Vg/RUN3cZ3ou5+jwF5+k
X-Received: by 10.84.202.163 with SMTP id x32mr29804385pld.51.1495465390413; Mon, 22 May 2017 08:03:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.154.205 with HTTP; Mon, 22 May 2017 08:02:39 -0700 (PDT)
In-Reply-To: <77F2A1D2-5A8E-4E88-9920-A15BC24795E6@ve7jtb.com>
References:  <698E4B80-754F-42E1-AD2B-602CD605C680@ve7jtb.com>  <77F2A1D2-5A8E-4E88-9920-A15BC24795E6@ve7jtb.com>
From: Brian Campbell 
Date: Mon, 22 May 2017 09:02:39 -0600
Message-ID: 
To: John Bradley 
Cc: "Manger, James" , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c1486b65eb8ff05501e2bfa"
Archived-At: 
Subject: Re: [OAUTH-WG] re comments on MTLS (was Re: Call for Adoption: Mutual TLS Profiles for OAuth Clients)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 15:03:23 -0000

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

Thought I was looking to get a sense of preference from the WG, I tend to
lean the same way as John. The issuer constraint is an optional thing
that's applied per client and the only use I can see in supporting more
than one is for the client to change issuers without updating it's
registration/configuration.

On Sat, May 20, 2017 at 8:44 AM, John Bradley  wrote:

> +1 for =E2=80=9Ctls_client_auth_root_dn"
>
> On making it an array, I think that adds complexity for little gain, and
> perhaps introduces new trust issues.
>
> I think it should be one trusted root or all the trusted roots.  If you
> only trust 5 then configure that in the AS.
>
> An array seems only useful where the client has a cert from x but may wan=
t
> to get the next one from y and not re-register.
> I think if the client or federation operator is locking itself down to
> specific issuers one per client should be fine.
> I expect that in most cases the issuer will need to be in the trust store
> of the AS anyway so this is just pinning the cert to one of a limited set=
.
>
> John B.
>
> On May 15, 2017, at 2:42 PM, Brian Campbell 
> wrote:
>
> I'll add text/clarification that the DN metadata fields being RFC4514
> string representations of DNs in the next draft.
>
> Given that this is a profile of use and the metadata fields are just one
> way to express the binding of certificate and client, and after thinking
> about it some more and not wanting to introduce too many variations, I fe=
el
> that keeping tls_client_auth_subject_dn as the subject distinguished name
> of the client certificate is more straightforward and sufficient for this
> case.
>
> Is there rough consensus to change "tls_client_auth_issuer_dn" to
> "tls_client_auth_root_dn" as was suggested? The latter name makes sense t=
o
> me but I don't want to make that change without a little more input or
> buy-in from the WG. So please respond one way or the other, if you've got
> an opinion.
>
> Similarly I'm looking for some rough consensus around if a single
> root/issuer is sufficient in the metadata before potentially making any
> changes. Should "tls_client_auth_issuer/root_dn" remain a single DN
> string value or should it be an array allowing for more than one?
>
>
>
> On Fri, Apr 21, 2017 at 6:18 PM, John Bradley  wrote:
>
>> I agree with Brian.
>>
>> Trying to do anything with PKIX opens up cans of worms.  One of the
>> reasons we have resisted to this point.
>>
>> However there are server to server use cases that legitimately need this=
.
>>
>> I agree that in general DN is a mess, I suspect that telling people to
>> directly use the DER encoded version wont fly, so my thought was to use =
the
>> RFC 4514 string representation that most tools produce.
>>
>> We did talk about subject alt DNS Names, however those may not be presen=
t
>> in eIDAS certificates that some people may need to use for legal reasons=
,
>> or if it is present it might be an email.
>>
>> I suspect that users of this will fall into two camps.  One that has a
>> small set of trusted CA that are configured out of band and any certific=
ate
>> from those roots with the correct DN is OK.
>>
>> The other group will be trying to do something more dynamic with SSL
>> server certs (May or may not be EV)   I could see those people preferrin=
g
>> DNS Name subject alt, or using JWKS to publish there certs.
>>
>> The problem is finding the right balance of flexibility without too many
>> options to confuse people.
>>
>> I am inclined towards DN for those that are willing to suffer the pain,
>> and JWKS_uri for everyone else.   One advantage of the JWKS_URI approach=
 is
>> that self signed certs should work just fine, that is something that the
>> R&E people will want if they use this.
>>
>> For most proof of possession we should be promoting token binding as the
>> most flexible approach as it also works with mobile without per instance
>> registration.
>>
>> John B.
>>
>>
>> On Apr 21, 2017, at 7:41 PM, Brian Campbell 
>> wrote:
>>
>> Thanks, James, for the adoption support as well as the review and
>> comments. I've tried to respond to the comments inline below.
>>
>> On Thu, Apr 20, 2017 at 11:33 PM, Manger, James <
>> James.H.Manger@team.telstra.com> wrote:
>>
>>> I support adoption of draft-campbell-oauth-mtls.
>>>
>>> Now some comments on the doc:
>>>
>>> 1. [=C2=A72.3] The syntax of tls_client_auth_subject_dn is not specifie=
d.
>>> Perhaps LDAP's "String Representation of Distinguished Names" [RFC4514]=
?
>>> Perhaps a base64url-encoding of a DER-encoded DN? It would actually be
>>> better to allow any subjectAltName to be specified, instead of a DN.
>>>
>>
>> How about calling it tls_client_auth_subject and defining it as a string
>> and allowing it to represent the expected subject which could be in the
>> cert as the subject DN or a subjectAltName? For Subject DN and DN
>> subjectAltNames it would be the "String Representation of Distinguished
>> Names" and an appropriate string for the other subjectAltName types (I'l=
l
>> have to look at what's there 'cause I don't know off hand and guidance o=
r
>> suggested text is always more than welcome).
>>
>>
>>
>>
>>> 2. [=C2=A72.3] Change the name of tls_client_auth_issuer_dn (maybe
>>> tls_client_auth_root_dn). Given tls_client_auth_client_dn, it will be t=
oo
>>> easy to assume this pair refer to the issuer and subject fields of the =
cert.
>>>
>>
>> The accompanying text tries to make it clear that it's the root issuer
>> but the tls_client_auth_issuer_dn name can certainly be changed to
>> tls_client_auth_root_dn or something along those lines, if folks think t=
he
>> name in -01 is liable to cause confusion?
>>
>>
>>
>> PKI chains can be complex so the expected root might not be such a stabl=
e
>>> concept. For example, the Let's Encrypt CA chains to an ISRG Root and a=
n
>>> IdenTrust DST Root [https://letsencrypt.org/certificates/].
>>>
>>
>> The goal was to provide a metadata field to express some constraint for
>> what is kind of expected to be a common deployment of a number of entiti=
es
>> participating in some OAuth API thing and are being issued certificates
>> from a common issuer for the group of participants.
>>
>> Perhaps it should be an array of strings rather than a single value?
>>
>> Or do you have suggestions for some alternative?
>>
>>
>>
>>
>>> 3. [=C2=A72.3] If a client dynamically registers a "jwks_uri" does this=
 mean
>>> the authz server MUST automatically cope when the client updates the ke=
y(s)
>>> it publishes there?
>>>
>>
>> If the authz server supports that kind of trust model as well as
>> dynamically registration, then I would expect so, yes.
>>
>>
>>
>>
>>> 4. [=C2=A73] An access token is bound to a specific client certificate.=
 That
>>> is probably ok, but does mean all access tokens die when the client upd=
ates
>>> their certificate (which could be every 2 months if using Let's Encrypt=
).
>>> This at least warrants a paragraph in the Security Considerations.
>>>
>>
>> In my own mind that was implied and okay because it's likely that access
>> tokens will have a shorter lifespan than certificates and refreshing or
>> getting a new access token is typically easy anyhow.
>>
>> Anyway, it doesn't hurt to be explicit about it, can you propose some
>> such text for the Security Considerations?
>>
>>
>>
>>
>>>
>>> 5. [=C2=A73.1] "exp" and "nbf" values in the example need to be numbers=
, not
>>> strings (drop the quotes).
>>>
>>
>> Silly mistake on my part. Thanks for catching that. Will fix.
>>
>>
>>
>>>
>>> 6. An access token linked to a client TLS cert isn't a bearer token. Th=
e
>>> spec should really define a new token_type for responses from the token
>>> endpoint. That might not necessarily mean we needs a new HTTP
>>> authentication scheme as well (it might just hint that "Bearer" wasn't
>>> quite the right name).
>>>
>>
>> Indeed "Bearer" isn't quite right and very likely a name that would be
>> different with the benefit of hindsight. But other than having names on =
the
>> wire that are more true to the nature of the tokens, I don't know that a
>> new token_type or HTTP auth scheme adds value to the use cases here.
>> However, they would likely make deployment of this stuff more cumbersome
>> and take longer.  Whereas many systems can likely plug in mutual TLS on =
top
>> of the existing token_type and HTTP auth scheme without major changes. I=
'm
>> strongly inclined to not introduce a new token_type and more inclined to
>> not do a new HTTP auth scheme.
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>
>

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


Thought I was looking to get a sense of preference from th=
e WG, I tend to lean the same way as John. The issuer constraint is an opti=
onal thing that's applied per client and the only use I can see in supp=
orting more than one is for the client to change issuers without updating i=
t's registration/configuration.
=C2=A0
On Sat, May 20, 2017 at 8:44 AM,=
 John Bradley <ve7jtb@ve7jtb.com> wrote:
+1 for =E2=80=9Ctls_client_auth_root_dn"

On making=
 it an array, I think that adds complexity for little gain, and perhaps int=
roduces new trust issues.

I think it should be one=
 trusted root or all the trusted roots.=C2=A0 If you only trust 5 then conf=
igure that in the AS.

An array seems only useful w=
here the client has a cert from x but may want to get the next one from y a=
nd not re-register.=C2=A0
I think if the client or federation ope=
rator is locking itself down to specific issuers one per client should be f=
ine.
I expect that in most cases the issuer will need to be in th=
e trust store of the AS anyway so this is just pinning the cert to one of a=
 limited set.

John B.

On May 15, 2017, at 2:4=
2 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

=
I'll add text/clarification that the DN metadata fields being RFC4514 s=
tring representations of DNs in the next draft.

Given that thi=
s is a profile of use and the metadata fields are just one way to express t=
he binding of certificate and client, and after thinking about it some more=
 and not wanting to introduce too many variations, I feel that keeping tls_=
client_auth_subject_dn as the subject distinguished name of the client cert=
ificate is more straightforward and sufficient for this case.

Is the=
re rough consensus to change "tls_client_auth_issuer_dn" to  &quo=
t;tls_client_auth_root_dn" as was suggested? The latter name makes sen=
se to me but I don't want to make that change without a little more inp=
ut or buy-in from the WG. So please respond one way or the other, if you=
9;ve got an opinion.=C2=A0 

Similarly I'm looking for some=
 rough consensus around if a single root/issuer is sufficient in the metada=
ta before potentially making any changes. Should "tls_client_auth_issu=
er/root_dn" remain a single DN string value or should it be an ar=
ray allowing for more than one? 



On Fri, Apr 21, 2017 at 6:18 PM=
, John Bradley <ve7jtb@ve7jtb.com> wrote:
On Apr 21, 2017, at 7:41 PM, Brian Campb=
ell <bca=
mpbell@pingidentity.com> wrote:

Thanks, James, for the adopti=
on support as well as the review and comments. I've tried to respond to=
 the comments inline below. 

On Thu, Apr 20, 2017 at 11:33 PM, Manger, James <James.H.Manger@team.telstra.com> wrote:
I support adoption of draft-c=
ampbell-oauth-mtls.



Now some comments on the doc:



1. [=C2=A72.3] The syntax of tls_client_auth_subject_dn is not specified. P=
erhaps LDAP's "String Representation of Distinguished Names" =
[RFC4514]? Perhaps a base64url-encoding of a DER-encoded DN? It would actua=
lly be better to allow any subjectAltName to be specified, instead of a DN.=


How about calling it tls_client_auth_s=
ubject and defining it as a string and allowing it to represent the expecte=
d subject which could be in the cert as the subject DN or a subjectAltName?=
 For Subject DN and DN subjectAltNames it would be the "String Represe=
ntation of Distinguished Names" and an appropriate string for the othe=
r subjectAltName types (I'll have to look at what's there 'caus=
e I don't know off hand and guidance or suggested text is always more t=
han welcome). 
=C2=A0





2. [=C2=A72.3] Change the name of tls_client_auth_issuer_dn (maybe tls_clie=
nt_auth_root_dn). Given tls_client_auth_client_dn, it will be too easy to a=
ssume this pair refer to the issuer and subject fields of the cert.

The accompanying text tries to make it clear t=
hat it's the root issuer but the tls_client_auth_issuer_dn name can cer=
tainly be changed to tls_client_auth_root_dn or something along those lines=
, if folks think the name in -01 is liable to cause confusion?
=C2=A0



PKI chains can be complex so the expected root might not be such a stable c=
oncept. For example, the Let's Encrypt CA chains to an ISRG Root and an=
 IdenTrust DST Root [https://letsencrypt.org/certificates=
/].

The goal was to provide a metad=
ata field to express some constraint for what is kind of expected to be a c=
ommon deployment of a number of entities participating in some OAuth API th=
ing and are being issued certificates from a common issuer for the group of=
 participants. 

Perhaps it should be an array of strings =
rather than a single value?

Or do you have suggestions fo=
r some alternative?






3. [=C2=A72.3] If a client dynamically registers a "jwks_uri" doe=
s this mean the authz server MUST automatically cope when the client update=
s the key(s) it publishes there?

If the=
 authz server supports that kind of trust model as well as dynamically regi=
stration, then I would expect so, yes. 
=C2=A0





4. [=C2=A73] An access token is bound to a specific client certificate. Tha=
t is probably ok, but does mean all access tokens die when the client updat=
es their certificate (which could be every 2 months if using Let's Encr=
ypt). This at least warrants a paragraph in the Security Considerations.

In my own mind that was implied and okay =
because it's likely that access tokens will have a shorter lifespan tha=
n certificates and refreshing or getting a new access token is typically ea=
sy anyhow.

Anyway, it doesn't hurt to be explicit abo=
ut it, can you propose some such text for the Security Considerations?
<=
br>
=C2=A0



5. [=C2=A73.1] "exp" and "nbf" values in the example ne=
ed to be numbers, not strings (drop the quotes).

<=
/div>
Silly mistake on my part. Thanks for catching that. Will fix. 
=C2=A0



6. An access token linked to a client TLS cert isn't a bearer token. Th=
e spec should really define a new token_type for responses from the token e=
ndpoint. That might not necessarily mean we needs a new HTTP authentication=
 scheme as well (it might just hint that "Bearer" wasn't quit=
e the right name).

Indeed "Bearer&=
quot; isn't quite right and very likely a name that would be different =
with the benefit of hindsight. But other than having names on the wire that=
 are more true to the nature of the tokens, I don't know that a new tok=
en_type or HTTP auth scheme adds value to the use cases here. However, they=
 would likely make deployment of this stuff more cumbersome and take longer=
.=C2=A0 Whereas many systems can likely plug in mutual TLS on top of the ex=
isting token_type and HTTP auth scheme without major changes. I'm stron=
gly inclined to not introduce a new token_type and more inclined to not do =
a new HTTP auth scheme. 




_______________________________________________
OAuth mailing list<=
br>OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth





Thanks for your review Zitao!

Version 1=
2 addresses your comments. Detailed responses below:

On Sun, May 21, 2017 at 8:05 PM, wan=
gzitao <wangzitao@huawei.com> wrote:











Reviewer: Zitao Wang (Mi=
chael)


Review result: Has Nits<=
u>


=C2=A0


I have reviewed this doc=
ument as part of the Operational directorate=E2=80=99s=C2=A0ongoing effort =
to review all IETF documents being processed by the IESG.=C2=A0 These=C2=A0=
comments were written with the intent of improving the operational=C2=A0asp=
ects of the
 IETF drafts. Comments that are not addressed in last call may be included =
in AD reviews during the IESG review.=C2=A0 Document editors and=C2=A0WG ch=
airs should treat these comments just like any other last call=C2=A0comment=
s.


=C2=A0


Document reviewed: =C2=
=A0draft-ietf-oauth-native-apps-10


=C2=A0


Summary: <=
/p>

=C2=A0



OAuth 2.0 authorizati=
on requests from native apps should only be made



through external user=
-agents, primarily the user=E2=80=99s browser. This


specification details=
 the security and usability reasons why this is



the case, and how nat=
ive apps and authorization servers can implement


this best practice.


=C2=A0


I think the document is written very clear, except some =
small nits:


Page 3:=C2=A0=
=C2=A0=C2=A0=C2=A0 The last sentence of introduction-- =E2=80=9CThis practi=
ce is also known as the AppAuth pattern=E2=80=9D.=C2=A0=C2=A0



I suggest adding a reference to explain the AppAuth pat=
tern.


<=
/blockquote>

Done
=C2=A0


Page 3:=C2=A0=C2=A0=C2=
=A0=C2=A0 Terminology -- "OAuth".=C2=A0 


I suggest modifying to: "OAuth"=C2=A0=C2=A0 T=
he Web Authorization (OAuth) protocol.=C2=A0 In this document, OAuth refers=
 to OAuth 2.0 [RFC6749].
I went with:
"In this document, OAuth refers to the OAuth 2.0 Authorization F=
ramework [RFC6749]."

The phrase "Web=
 Authorization (OAuth) protocol" only seems to appear in our WG Charte=
r, and not general usage.
=C2=A0


Page 4:=C2=A0=C2=A0=C2=
=A0=C2=A0 Terminology -- "web-view"=C2=A0 A web browser UI compon=
ent.=C2=A0=C2=A0



Does it mean "User Information"?=C2=A0 Sugges=
t expanding this abbreviation.


<=
/blockquote>

Done.
=C2=A0


Page 5:=C2=A0=C2=A0=C2=
=A0=C2=A0 Figure 1.=C2=A0=C2=A0 Does the browser and authorization endpoint=
 are some kinds of "external user-agent"? Suggest describing it m=
ore clearly.

Now states:
"illustrates the interaction of the native app with a browser<=
/div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 external user-agent to authorize the =
user. "




Page=C2=A0=C2=A0 9:=
=C2=A0=C2=A0 PKCE [RFC7636] details how this limitation can be used to exec=
ute a code interception attack (see Figure 1).=C2=A0=C2=A0=C2=A0



Does the Figure 1 means =E2=80=9CFigure 1 of RFC7636=E2=
=80=9D?=C2=A0

Good catch. I=
 delete the figure reference, since the entire spec talks about this attack=
, which is likely sufficient.
=C2=A0







Page10:=C2=A0=C2=A0=
=C2=A0=C2=A0 However, as the Implicit Flow cannot be protected by PKCE=C2=
=A0=C2=A0=C2=A0=C2=A0




Seems here, the refer=
ence be omitted.=C2=A0

Added.
=C2=A0


A run of idnits =
revealed no errors, flaws. There were 1 warning and 1 comments though


=C2=A0


=C2=A0 =3D=3D There are 1 instance of line=
s with non-RFC2606-compliant FQDNs in the


=C2=A0=C2=A0=C2=A0=C2=A0 document.<=
u>


=C2=A0

I ran it myself with verbose output, and got:<=
/div>
tmp/draft-ietf-oauth-native-apps__1_.txt(435): Found possible=
 FQDN 'com.example.app' in position 5; this doesn't match RFC 2=
606's suggested ".example" or ".example.(com|org|net)&qu=
ot;.
=C2=A0
We are actually using a RFC2606 domai=
n name here, but in reverse domain name notation which is causing this warn=
ing.

No changes required.
=C2=A0


=C2=A0 Miscellaneous warnings:


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

=C2=A0


=C2=A0 -- The document date (April 26, 201=
7) is 14 days in the past.=C2=A0 Is this


=C2=A0=C2=A0=C2=A0=C2=A0 intentional?


=C2=A0


=C2=A0


=C2=A0 Checking references for intended st=
atus: Best Current Practice


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

=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0 (See RFCs 3967 an=
d 4897 for information about using normative references


=C2=A0=C2=A0=C2=A0=C2=A0 to lower-maturity=
 documents in RFCs)


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0 No issues found h=
ere.


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0 Summary: 0 errors=
 (**), 0 flaws (~~), 1 warning (=3D=3D), 1 comment (--).


=C2=A0


=C2=A0


________________________=
_______________________


OPS-DIR mailing list<=
/u>


OPS-DIR@ietf.org


https://www.ietf.org/ma=
ilman/listinfo/ops-dir


=C2=A0










--001a113ee7d25754640550219a2a--


From nobody Mon May 22 13:27:17 2017
Return-Path: 
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE426128896; Mon, 22 May 2017 13:27:08 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Adam Roach 
To: "The IESG" 
Cc: draft-ietf-oauth-native-apps@ietf.org, Hannes Tschofenig , oauth-chairs@ietf.org, Hannes.Tschofenig@gmx.net, oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149548482877.9096.13896958451655712801.idtracker@ietfa.amsl.com>
Date: Mon, 22 May 2017 13:27:08 -0700
Archived-At: 
Subject: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 20:27:09 -0000

Adam Roach has entered the following ballot position for
draft-ietf-oauth-native-apps-11: 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-native-apps/



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

General
=======
The thesis of this document seems to be that bad actors can access
authentication information that gives them broader or more durable
authorization than is intended; and appears to want to mitigate this
predominantly with a single normative statement in a BCP telling
potential bad actors to stop doing the one thing that enables their
shenanigans.  For those familiar with the animated series "The Tick," it
recalls the titular character yelling "Hey! You in the pumps! I say to
you: stop being bad!" -- which, of course, is insufficient to achieve the
desired effect.

I see that there is nevertheless "strong consensus" to publish the
document; in which case, I would encourage somewhat more detail around
what the rest of the ecosystem -- and the authentication server in
particular -- can do to mitigate the ability of such bad actors.
Specifically, section 8.1 has a rather hand-wavy suggestion that
authorization endpoints "MAY take steps to detect and block authorization
requests in embedded user agents," without offering up how this might be
done. The problem is that that the naïve ways of doing this (UA strings?)
are going to be easy to circumvent, and the more advanced ones (say,
instructing users to log in using a non-OAuth flow if the auth endpoint
detects absolutely no cookies associated with its origin) will have
interactions that probably warrant discussion in this document. (For
example, such an approach -- while potentially effective -- would
interact very poorly with the "SSO mode" described in section B.3;
although I think that recommending the use of "SSO mode" should be
removed for other reasons, described below).

________

Specific comments follow

The terminology section makes distinctions about cookie handling and
content access in generic definitions (embedded versus external UAs, for
example) but doesn't do the same for specific technologies. It is
probably worthwhile noting that the "in-app browser tab" prevents apps
from accessing cookies and content, while the "web-view" does not (I had
to infer these facts from statements much later in the document).

Section 7.3 gives examples of IPv4 and IPv6 addresses for loopback. While
I'm sympathetic to the deployment challenges inherent in getting entire
network paths to upgrade to IPv6, this text discusses loopback
exclusively, which means that only the local operating system needs to
support IPv6. Since all modern operating systems have supported IPv6 for
well over a decade, I suggest that the use of IPv4 addresses for this
purpose should be explicitly deprecated, so as to avoid unnecessary
transition pain in the future. Minimally, the example needs to be
replaced or supplemented with an IPv6 example, as per
: "We recommend
that existing standards be reviewed to ensure they... use IPv6
examples."

Section 8.1 makes the statement that "Loopback IP based redirect URIs may
be susceptible to interception by other apps listening on the same
loopback interface." That's not how TCP listener sockets work: for any
given IP address, they guarantee single-process access to a port at any
one time. (Exceptions would include processes with root access, but an
attacking process with that level of access is going to be impossible to
defend against). While mostly harmless, the statement appears to be false
on its face, and should be removed or clarified.

Section 8.4 indicates that loopback redirect URIs are allowed to vary
from their registered value in port number only. If you decide not to
deprecate the use of IPv4 loopback, I imagine that servers should also
treat [::1] identical to 127.0.01 for this purpose as well.

Section 8.7 claims that users are likely to be suspicious of a sign-in
request when they should have already been signed in, and goes on to
claim that they will distinguish between completely-logged-out states and
logged-in-but-needing-reauth states, and may even take evasive action
based on associated suspicion. Based on what I know of user research for
security indicators, the chances of these statements being true for any
non-trivial portion of any user population is basically zero. I propose
that this section simply highlight that this is effectively an
intractable problem from the client end, without any illusions that users
have the ability to distinguish between the two circumstances, and that
authentication servers must be extra vigilant in detecting and avoiding
these kinds of attacks.

Section 8.11, third paragraph talks about keystroke logging; in practice,
the attack here is far easier than that, as I believe that applications
that embed a web view can simply extract authentication-related material
directly from the DOM.

Section B.2 uses the phrase "Android Implicit Intends" where I believe it
means "Android Implicit Intents."

Section B.3 describes the use of a "Web Authentication Broker" in SSO
mode, which provides an isolated authentication context. If the section
8.7 text regarding user detection of nefarious application behavior in
the form of web-view embedding is not removed, this needs a very clear
treatment of how users might be expected to distinguish between that
behavior and the SSO mode behavior. On casual examination, it seems that
there would be no way to do so. I'll note that this BCP also promotes the
"already logged in" behavior as being a key benefit to OAuth (cf. the
third paragraph of Section 4), which the described behavior seems to
mostly defeat. I would strongly suggest either removing discussion of
using this mode, or deprecating it in favor of the user's preferred web
browser, so as to obtain the advantages described in section 4.



From nobody Mon May 22 15:14:34 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABD01293E9 for ; Mon, 22 May 2017 15:14:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFIRY_KKQWMt for ; Mon, 22 May 2017 15:14:27 -0700 (PDT)
Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 ABBE41286CA for ; Mon, 22 May 2017 15:14:27 -0700 (PDT)
Received: by mail-it0-x229.google.com with SMTP id g126so7317044ith.0 for ; Mon, 22 May 2017 15:14:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wV1Ly8lMyGoxTQZC2mXANaqkl9X12UwHXEQqof+BsK0=; b=IhFQ9Ox8JzkRa2EhAjPacVO8037ysdrYJuteWQdgG75kdJKs6HMT9xulrHGCvq6Tax i3e93NxK1b0cPOQOCRawtL1H4r6+iaL/eRaus5ZnXkQVkvLpD/FGg1cDEGjjVAuF6x0F DsrMKU+Bb/5bo2v2ogrfGzIDl2YAN1bs8gTBYAJ2FUktfjivSI4DdAeUZm1CnGhqxlE6 MgmL1cjqCNkwYT++IApO4+oFCYKAsuy7cWrnqp+sCU8fHd35HR90rcRz3wQD0VPRQzQD 2C8qIC7G7xCiyw3uwmyoQ7P/LGAJcqpG+6t17fa8CPdsBQABQxCmugThom3W9ZIN0s9H 8LGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wV1Ly8lMyGoxTQZC2mXANaqkl9X12UwHXEQqof+BsK0=; b=bss3ZcLkuZGaLoC06F+GBlQiSsekOpXXwdgSO/RoOvKYM2QwvHkwPUZ01ZvDmYJd1F bVuUL+oO4HNUE2OV5PbOv5hbz86i21pIITZWA5F8ydoLLrNEwASUDmSKCAXDND0GlsRh y+ec6rfPgtB10EwSigWnlUbszNfhy7AkkFE5bRpGpN/OG/r9HPtmzihNRim72jsmczXR KP4ISLxhHg2+ixrTKyXDRNulQ5ssF80kMA7+E1JQ1dpRF3vT8KwkJZMgRy5kfguqDFD0 S0LgiqznYhHSY8GBafb98IJG0ZyQrDmlCaEz3qoCaBi139akEHgQmfbQhBalk33Nod44 rWnw==
X-Gm-Message-State: AODbwcBG+e4gg8s3p45cYvWO5k1Gf+mLbdw/TmDP91g45a8/oQ/5sGoJ nitsy1I8wuZ8RVy9+J7HIJZrxrNyVUJJlbCvoA==
X-Received: by 10.36.37.17 with SMTP id g17mr45124573itg.101.1495491266769; Mon, 22 May 2017 15:14:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.35.37 with HTTP; Mon, 22 May 2017 15:14:06 -0700 (PDT)
In-Reply-To: <149548482877.9096.13896958451655712801.idtracker@ietfa.amsl.com>
References: <149548482877.9096.13896958451655712801.idtracker@ietfa.amsl.com>
From: William Denniss 
Date: Mon, 22 May 2017 15:14:06 -0700
Message-ID: 
To: Adam Roach 
Cc: The IESG , draft-ietf-oauth-native-apps@ietf.org,  Hannes Tschofenig , oauth-chairs@ietf.org,  "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114522c2b9244e0550243131"
Archived-At: 
Subject: Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 22:14:32 -0000

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

Adam,

Thank you for reviewing the draft.

On Mon, May 22, 2017 at 1:27 PM, Adam Roach  wrote:

> Adam Roach has entered the following ballot position for
> draft-ietf-oauth-native-apps-11: No Objection
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> General
> =3D=3D=3D=3D=3D=3D=3D
> The thesis of this document seems to be that bad actors can access
> authentication information that gives them broader or more durable
> authorization than is intended; and appears to want to mitigate this
> predominantly with a single normative statement in a BCP telling
> potential bad actors to stop doing the one thing that enables their
> shenanigans.  For those familiar with the animated series "The Tick," it
> recalls the titular character yelling "Hey! You in the pumps! I say to
> you: stop being bad!" -- which, of course, is insufficient to achieve the
> desired effect.
>

I see that there is nevertheless "strong consensus" to publish the
> document;


Two years ago when I posted version 00 of the draft, nearly every native
app OAuth interaction in the wild violated that MUST. It was quite a large
problem, and we've been working in the OAuth community for a while to get
to this point, and I do believe there is a strong consensus to publish.

I see this BCP not only as a single MUST of what you shouldn't do, but also
as a valuable document detailing exactly how to meet that requirement,
which is non-trivial. Given how widespread the old practice was, I think
it's worth very clearly detailing why the old way is bad (e.g. Section
8.7), and giving as much information as possible for how to do it the right
way which is the goal of the document.

in which case, I would encourage somewhat more detail around
> what the rest of the ecosystem -- and the authentication server in
> particular -- can do to mitigate the ability of such bad actors.
> Specifically, section 8.1 has a rather hand-wavy suggestion that
> authorization endpoints "MAY take steps to detect and block authorization
> requests in embedded user agents," without offering up how this might be
> done. The problem is that that the na=C3=AFve ways of doing this (UA stri=
ngs?)
> are going to be easy to circumvent, and the more advanced ones (say,
> instructing users to log in using a non-OAuth flow if the auth endpoint
> detects absolutely no cookies associated with its origin) will have
> interactions that probably warrant discussion in this document. (For
> example, such an approach -- while potentially effective -- would
> interact very poorly with the "SSO mode" described in section B.3;
> although I think that recommending the use of "SSO mode" should be
> removed for other reasons, described below).
>

One of the problems with the old way of doing things is that it was hard to
tell the good actors from the bad =E2=80=93 they all used the same techniqu=
es. So I
do actually see value in naive UA filtering as even though the bad actor
can lie, it becomes a provable lie.

Thanks for your feedback here, I'll take another look and see if we can
build in some of your suggestions.

________
>
> Specific comments follow
>
> The terminology section makes distinctions about cookie handling and
> content access in generic definitions (embedded versus external UAs, for
> example) but doesn't do the same for specific technologies. It is
> probably worthwhile noting that the "in-app browser tab" prevents apps
> from accessing cookies and content, while the "web-view" does not (I had
> to infer these facts from statements much later in the document).
>
> Section 7.3 gives examples of IPv4 and IPv6 addresses for loopback. While
> I'm sympathetic to the deployment challenges inherent in getting entire
> network paths to upgrade to IPv6, this text discusses loopback
> exclusively, which means that only the local operating system needs to
> support IPv6. Since all modern operating systems have supported IPv6 for
> well over a decade, I suggest that the use of IPv4 addresses for this
> purpose should be explicitly deprecated, so as to avoid unnecessary
> transition pain in the future. Minimally, the example needs to be
> replaced or supplemented with an IPv6 example, as per
> : "We recommend
> that existing standards be reviewed to ensure they... use IPv6
> examples."


Good points. Version 11 added an IPv6 example, and a discussion around
IPv4/6 compatibility. I believe with that we are now conformance with the
IAB guidelines.

While I agree with your statement in principle that all hosts should
support already IPv6 loopback, in practice I was dealing with a case
recently where some code that was written assuming local IPv6 availability
broke when a user had explicitly disabled IPv6 on their machine. It seems
users can still get away without IPv6 for now, meaning IPv6 loopback
availability is not completely guaranteed.

Due to this, I think documenting an approach where clients can support IPv6
only, IPv4 only, and both being available is probably best for now (and 7.3
in v11 does that in the last paragraph).  It looks like that approach we
took in v11 does follow the IAB recommendations for mixed environments.


Section 8.1 makes the statement that "Loopback IP based redirect URIs may
> be susceptible to interception by other apps listening on the same
> loopback interface." That's not how TCP listener sockets work: for any
> given IP address, they guarantee single-process access to a port at any
> one time. (Exceptions would include processes with root access, but an
> attacking process with that level of access is going to be impossible to
> defend against). While mostly harmless, the statement appears to be false
> on its face, and should be removed or clarified.
>

Will be removed in the next update. Thank you.

Section 8.4 indicates that loopback redirect URIs are allowed to vary
> from their registered value in port number only. If you decide not to
> deprecate the use of IPv4 loopback, I imagine that servers should also
> treat [::1] identical to 127.0.01 for this purpose as well.
>

The expectation here was that the client would register both I guess. That
said, they'd be no harm in treating them as identical for that purpose, so
that's good advice. I'll revise.


> Section 8.7 claims that users are likely to be suspicious of a sign-in
> request when they should have already been signed in, and goes on to
> claim that they will distinguish between completely-logged-out states and
> logged-in-but-needing-reauth states, and may even take evasive action
> based on associated suspicion. Based on what I know of user research for
> security indicators, the chances of these statements being true for any
> non-trivial portion of any user population is basically zero. I propose
> that this section simply highlight that this is effectively an
> intractable problem from the client end, without any illusions that users
> have the ability to distinguish between the two circumstances, and that
> authentication servers must be extra vigilant in detecting and avoiding
> these kinds of attacks.
>

I'll revise this, I agree the claim is a little too aspirational.

Section 8.11, third paragraph talks about keystroke logging; in practice,
> the attack here is far easier than that, as I believe that applications
> that embed a web view can simply extract authentication-related material
> directly from the DOM.
>

Yes, they can do that too (and I agree it's a simpler attack
implementation). I'll include in the next revision. I'll keep in the
keystroke logging text, as it's another vector, and people tend to have a
visceral reaction when learning this.

Section B.2 uses the phrase "Android Implicit Intends" where I believe it
> means "Android Implicit Intents."
>

Fixed in the next update, thanks.


>
> Section B.3 describes the use of a "Web Authentication Broker" in SSO
> mode, which provides an isolated authentication context. If the section
> 8.7 text regarding user detection of nefarious application behavior in
> the form of web-view embedding is not removed, this needs a very clear
> treatment of how users might be expected to distinguish between that
> behavior and the SSO mode behavior. On casual examination, it seems that
> there would be no way to do so. I'll note that this BCP also promotes the
> "already logged in" behavior as being a key benefit to OAuth (cf. the
> third paragraph of Section 4), which the described behavior seems to
> mostly defeat. I would strongly suggest either removing discussion of
> using this mode, or deprecating it in favor of the user's preferred web
> browser, so as to obtain the advantages described in section 4.
>

My understanding of the Web Authentication Broker is that it is effectively
a special-case browser designed for authentication. There is a single
cookie-jar which is retained and used with all apps that use the Web
Authentication Broker in "SSO mode". So logins are shared, and the
advantages of Section 4 apply.  It's a separate cookie-jar from the main
browser, which would imply a minimum of two sign-ins on the device (so not
quite "single" at a device level), but I'm not sure if this is enough to
disqualify it.

My goal here is to simply document the current state of the art of the
platforms, and I felt that the Web Authentication Broker qualified as an
external user agent per the BCP.  The user interface is arguably quite nice
too, which mitigates some of the downsides of using a special
authentication "browser" with a separate cookie jar.

I'm open to suggestions on this section.


Thanks again for your comments.

Best,
William

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


Adam,

Thank you for reviewing the draft=
.

On Mon, May =
22, 2017 at 1:27 PM, Adam Roach <adam@nostrum.com> wrote:
=

Adam Roach has entered th=
e following ballot position for

draft-ietf-oauth-native-apps-11: No Objection


-----------------------------------------------------------------=
-----

COMMENT:

-----------------------------------------------------------------=
-----



General

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

The thesis of this document seems to be that bad actors can access

authentication information that gives them broader or more durable

authorization than is intended; and appears to want to mitigate this

predominantly with a single normative statement in a BCP telling

potential bad actors to stop doing the one thing that enables their

shenanigans.=C2=A0 For those familiar with the animated series "The Ti=
ck," it

recalls the titular character yelling "Hey! You in the pumps! I say to=


you: stop being bad!" -- which, of course, is insufficient to achieve =
the

desired effect.


I see that there is nevertheless "strong consensus" to publish th=
e

document; 

Two years ago when I posted vers=
ion 00 of the draft, nearly every native app OAuth interaction in the wild =
violated that MUST. It was quite a large problem, and we've been workin=
g in the OAuth community for a while to get to this point, and I do believe=
 there is a strong consensus to publish.

I see thi=
s BCP not only as a single MUST of what you shouldn't do, but also as a=
 valuable document detailing exactly how to meet that requirement, which is=
 non-trivial. Given how widespread the old practice was, I think it's w=
orth very clearly detailing why the old way is bad (e.g. Section 8.7), and =
giving as much information as possible for how to do it the right way which=
 is the goal of the document.

in which case, I would encourage somewhat more det=
ail around

what the rest of the ecosystem -- and the authentication server in

particular -- can do to mitigate the ability of such bad actors.

Specifically, section 8.1 has a rather hand-wavy suggestion that

authorization endpoints "MAY take steps to detect and block authorizat=
ion

requests in embedded user agents," without offering up how this might =
be

done. The problem is that that the na=C3=AFve ways of doing this (UA string=
s?)

are going to be easy to circumvent, and the more advanced ones (say,

instructing users to log in using a non-OAuth flow if the auth endpoint

detects absolutely no cookies associated with its origin) will have

interactions that probably warrant discussion in this document. (For

example, such an approach -- while potentially effective -- would

interact very poorly with the "SSO mode" described in section B.3=
;

although I think that recommending the use of "SSO mode" should b=
e

removed for other reasons, described below).

One of the problems with the old way of doing things is that it was h=
ard to tell the good actors from the bad =E2=80=93 they all used the same t=
echniques. So I do actually see value in naive UA filtering as even though =
the bad actor can lie, it becomes a provable lie.

<=
div>Thanks for your feedback here, I'll take another look and see if we=
 can build in some of your suggestions.

________



Specific comments follow



The terminology section makes distinctions about cookie handling and

content access in generic definitions (embedded versus external UAs, for
example) but doesn't do the same for specific technologies. It is

probably worthwhile noting that the "in-app browser tab" prevents=
 apps

from accessing cookies and content, while the "web-view" does not=
 (I had

to infer these facts from statements much later in the document).



Section 7.3 gives examples of IPv4 and IPv6 addresses for loopback. While
I'm sympathetic to the deployment challenges inherent in getting entire=


network paths to upgrade to IPv6, this text discusses loopback

exclusively, which means that only the local operating system needs to

support IPv6. Since all modern operating systems have supported IPv6 for
well over a decade, I suggest that the use of IPv4 addresses for this

purpose should be explicitly deprecated, so as to avoid unnecessary

transition pain in the future. Minimally, the example needs to be

replaced or supplemented with an IPv6 example, as per

<https://www.iab.org/2016/11/07/iab-s=
tatement-on-ipv6/>: "We recommend

that existing standards be reviewed to ensure they... use IPv6

examples."

Good points. Version 11 add=
ed an IPv6 example, and a discussion around IPv4/6 compatibility. I believe=
 with that we are now conformance with the IAB guidelines.

While I agree with your statement in principle that all hosts shou=
ld support already IPv6 loopback, in practice I was dealing with a case rec=
ently where some code that was written assuming local IPv6 availability bro=
ke when a user had explicitly disabled IPv6 on their machine. It seems user=
s can still get away without IPv6 for now, meaning IPv6 loopback availabili=
ty is not completely guaranteed.

Due to this, I th=
ink documenting an approach where clients can support IPv6 only, IPv4 only,=
 and both being available is probably best for now (and 7.3 in v11 does tha=
t in the last paragraph).=C2=A0 It looks like that approach we took in v11 =
does follow the IAB recommendations for mixed environments.

<=
/div>


Section 8.1 makes the statement that "Loopback IP based redirect URIs =
may

be susceptible to interception by other apps listening on the same

loopback interface." That's not how TCP listener sockets work: for=
 any

given IP address, they guarantee single-process access to a port at any

one time. (Exceptions would include processes with root access, but an

attacking process with that level of access is going to be impossible to
defend against). While mostly harmless, the statement appears to be false
on its face, and should be removed or clarified.

<=
/div>
Will be removed in the next update. Thank you.


Section 8.4 indicates that loopback redirect URIs are allowed to vary

from their registered value in port number only. If you decide not to

deprecate the use of IPv4 loopback, I imagine that servers should also

treat [::1] identical to 127.0.01 for this purpose as well.

The expectation here was that the client would registe=
r both I guess. That said, they'd be no harm in treating them as identi=
cal for that purpose, so that's good advice. I'll revise.
=C2=A0

Section 8.7 claims that users are likely to be suspicious of a sign-in

request when they should have already been signed in, and goes on to

claim that they will distinguish between completely-logged-out states and
logged-in-but-needing-reauth states, and may even take evasive action

based on associated suspicion. Based on what I know of user research for
security indicators, the chances of these statements being true for any

non-trivial portion of any user population is basically zero. I propose

that this section simply highlight that this is effectively an

intractable problem from the client end, without any illusions that users
have the ability to distinguish between the two circumstances, and that

authentication servers must be extra vigilant in detecting and avoiding

these kinds of attacks.

I'll revise=
 this, I agree the claim is a little too aspirational.

=


Section 8.11, third paragraph talks about keystroke logging; in practice,
the attack here is far easier than that, as I believe that applications

that embed a web view can simply extract authentication-related material
directly from the DOM.

Yes, they can do=
 that too (and I agree it's a simpler attack implementation). I'll =
include in the next revision. I'll keep in the keystroke logging text, =
as it's another vector, and people tend to have a visceral reaction whe=
n learning this.


Section B.2 uses the phrase "Android Implicit Intends" where I be=
lieve it

means "Android Implicit Intents."

=

Fixed in the next update, thanks.
=C2=A0



Section B.3 describes the use of a "Web Authentication Broker" in=
 SSO

mode, which provides an isolated authentication context. If the section

8.7 text regarding user detection of nefarious application behavior in

the form of web-view embedding is not removed, this needs a very clear

treatment of how users might be expected to distinguish between that

behavior and the SSO mode behavior. On casual examination, it seems that
there would be no way to do so. I'll note that this BCP also promotes t=
he

"already logged in" behavior as being a key benefit to OAuth (cf.=
 the

third paragraph of Section 4), which the described behavior seems to

mostly defeat. I would strongly suggest either removing discussion of

using this mode, or deprecating it in favor of the user's preferred web=


browser, so as to obtain the advantages described in section 4.

My understanding of the Web Authentication Broker =
is that it is effectively a special-case browser designed for authenticatio=
n. There is a single cookie-jar which is retained and used with all apps th=
at use the Web Authentication Broker in "SSO mode". So logins are=
 shared, and the advantages of Section 4 apply.=C2=A0 It's a separate c=
ookie-jar from the main browser, which would imply a minimum of two sign-in=
s on the device (so not quite "single" at a device level), but I&=
#39;m not sure if this is enough to disqualify it.

My goal here is to simply document the current state of the art of the pla=
tforms, and I felt that the Web Authentication Broker qualified as an exter=
nal user agent per the BCP.=C2=A0 The user interface is arguably quite nice=
 too, which mitigates some of the downsides of using a special authenticati=
on "browser" with a separate cookie jar.

I'm open to suggestions on this section.


=

Thanks again for your comments.

Best,
Wi=
lliam



--001a114522c2b9244e0550243131--


From nobody Mon May 22 19:50:41 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 247F2129503; Mon, 22 May 2017 19:50:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jGrQvNr14cn; Mon, 22 May 2017 19:50:26 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F8D91294D8; Mon, 22 May 2017 19:50:24 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DNO75742; Tue, 23 May 2017 02:50:22 +0000 (GMT)
Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 23 May 2017 03:50:21 +0100
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.49]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0301.000; Tue, 23 May 2017 10:50:17 +0800
From: wangzitao 
To: William Denniss 
CC: "ops-dir@ietf.org" , "oauth@ietf.org" ,  "draft-ietf-oauth-native-apps.all@ietf.org" , "ietf@ietf.org" 
Thread-Topic: [OPS-DIR] Opsdir telechat review of draft-ietf-oauth-native-apps-10
Thread-Index: AdLSqDVW3BTeNlgFQ6WqlwAw3ux67gAQ4yYAACDVwOA=
Date: Tue, 23 May 2017 02:50:17 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.136.79.161]
Content-Type: multipart/alternative; boundary="_000_E6BC9BBCBCACC246846FC685F9FF41EA2AE09727DGGEMM506MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.5923A36F.0037, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.3.49, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 19faa7ae4a8c3e6c71edad8340774957
Archived-At: 
Subject: Re: [OAUTH-WG] [OPS-DIR] Opsdir telechat review of draft-ietf-oauth-native-apps-10
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 02:50:39 -0000

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

Q29vbCEgVGhpcyBjaGFuZ2VzL2V4cGxhaW5zIG1ha2Ugc2Vuc2UgdG8gbWUuDQoNCkJlc3QgUmVn
YXJkcyENCi1NaWNoYWVsDQoNCuWPkeS7tuS6ujogV2lsbGlhbSBEZW5uaXNzIFttYWlsdG86d2Rl
bm5pc3NAZ29vZ2xlLmNvbV0NCuWPkemAgeaXtumXtDogMjAxN+W5tDXmnIgyM+aXpSAzOjA5DQrm
lLbku7bkuro6IHdhbmd6aXRhbw0K5oqE6YCBOiBvcHMtZGlyQGlldGYub3JnOyBvYXV0aEBpZXRm
Lm9yZzsgZHJhZnQtaWV0Zi1vYXV0aC1uYXRpdmUtYXBwcy5hbGxAaWV0Zi5vcmc7IGlldGZAaWV0
Zi5vcmcNCuS4u+mimDogUmU6IFtPUFMtRElSXSBPcHNkaXIgdGVsZWNoYXQgcmV2aWV3IG9mIGRy
YWZ0LWlldGYtb2F1dGgtbmF0aXZlLWFwcHMtMTANCg0KVGhhbmtzIGZvciB5b3VyIHJldmlldyBa
aXRhbyENCg0KVmVyc2lvbiAxMiBhZGRyZXNzZXMgeW91ciBjb21tZW50cy4gRGV0YWlsZWQgcmVz
cG9uc2VzIGJlbG93Og0KDQpPbiBTdW4sIE1heSAyMSwgMjAxNyBhdCA4OjA1IFBNLCB3YW5neml0
YW8gPHdhbmd6aXRhb0BodWF3ZWkuY29tPG1haWx0bzp3YW5neml0YW9AaHVhd2VpLmNvbT4+IHdy
b3RlOg0KDQpSZXZpZXdlcjogWml0YW8gV2FuZyAoTWljaGFlbCkNCg0KUmV2aWV3IHJlc3VsdDog
SGFzIE5pdHMNCg0KDQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2Yg
dGhlIE9wZXJhdGlvbmFsIGRpcmVjdG9yYXRl4oCZcyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcg
YWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIFRoZXNlIGNv
bW1lbnRzIHdlcmUgd3JpdHRlbiB3aXRoIHRoZSBpbnRlbnQgb2YgaW1wcm92aW5nIHRoZSBvcGVy
YXRpb25hbCBhc3BlY3RzIG9mIHRoZSBJRVRGIGRyYWZ0cy4gQ29tbWVudHMgdGhhdCBhcmUgbm90
IGFkZHJlc3NlZCBpbiBsYXN0IGNhbGwgbWF5IGJlIGluY2x1ZGVkIGluIEFEIHJldmlld3MgZHVy
aW5nIHRoZSBJRVNHIHJldmlldy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91
bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29t
bWVudHMuDQoNCg0KDQpEb2N1bWVudCByZXZpZXdlZDogIGRyYWZ0LWlldGYtb2F1dGgtbmF0aXZl
LWFwcHMtMTANCg0KDQoNClN1bW1hcnk6DQoNCg0KT0F1dGggMi4wIGF1dGhvcml6YXRpb24gcmVx
dWVzdHMgZnJvbSBuYXRpdmUgYXBwcyBzaG91bGQgb25seSBiZSBtYWRlDQp0aHJvdWdoIGV4dGVy
bmFsIHVzZXItYWdlbnRzLCBwcmltYXJpbHkgdGhlIHVzZXLigJlzIGJyb3dzZXIuIFRoaXMNCnNw
ZWNpZmljYXRpb24gZGV0YWlscyB0aGUgc2VjdXJpdHkgYW5kIHVzYWJpbGl0eSByZWFzb25zIHdo
eSB0aGlzIGlzDQp0aGUgY2FzZSwgYW5kIGhvdyBuYXRpdmUgYXBwcyBhbmQgYXV0aG9yaXphdGlv
biBzZXJ2ZXJzIGNhbiBpbXBsZW1lbnQNCg0KdGhpcyBiZXN0IHByYWN0aWNlLg0KDQoNCkkgdGhp
bmsgdGhlIGRvY3VtZW50IGlzIHdyaXR0ZW4gdmVyeSBjbGVhciwgZXhjZXB0IHNvbWUgc21hbGwg
bml0czoNCg0KUGFnZSAzOiAgICAgVGhlIGxhc3Qgc2VudGVuY2Ugb2YgaW50cm9kdWN0aW9uLS0g
4oCcVGhpcyBwcmFjdGljZSBpcyBhbHNvIGtub3duIGFzIHRoZSBBcHBBdXRoIHBhdHRlcm7igJ0u
DQoNCkkgc3VnZ2VzdCBhZGRpbmcgYSByZWZlcmVuY2UgdG8gZXhwbGFpbiB0aGUgQXBwQXV0aCBw
YXR0ZXJuLg0KDQpEb25lDQoNCg0KUGFnZSAzOiAgICAgVGVybWlub2xvZ3kgLS0gIk9BdXRoIi4N
Cg0KSSBzdWdnZXN0IG1vZGlmeWluZyB0bzogIk9BdXRoIiAgIFRoZSBXZWIgQXV0aG9yaXphdGlv
biAoT0F1dGgpIHByb3RvY29sLiAgSW4gdGhpcyBkb2N1bWVudCwgT0F1dGggcmVmZXJzIHRvIE9B
dXRoIDIuMCBbUkZDNjc0OV0uDQpJIHdlbnQgd2l0aDoNCiJJbiB0aGlzIGRvY3VtZW50LCBPQXV0
aCByZWZlcnMgdG8gdGhlIE9BdXRoIDIuMCBBdXRob3JpemF0aW9uIEZyYW1ld29yayBbUkZDNjc0
OV0uIg0KDQpUaGUgcGhyYXNlICJXZWIgQXV0aG9yaXphdGlvbiAoT0F1dGgpIHByb3RvY29sIiBv
bmx5IHNlZW1zIHRvIGFwcGVhciBpbiBvdXIgV0cgQ2hhcnRlciwgYW5kIG5vdCBnZW5lcmFsIHVz
YWdlPGh0dHBzOi8vd3d3Lmdvb2dsZS5jb20vc2VhcmNoP3E9d2ViK2F1dGhvcml6YXRpb24rcHJv
dG9jb2w+Lg0KDQoNClBhZ2UgNDogICAgIFRlcm1pbm9sb2d5IC0tICJ3ZWItdmlldyIgIEEgd2Vi
IGJyb3dzZXIgVUkgY29tcG9uZW50Lg0KDQpEb2VzIGl0IG1lYW4gIlVzZXIgSW5mb3JtYXRpb24i
PyAgU3VnZ2VzdCBleHBhbmRpbmcgdGhpcyBhYmJyZXZpYXRpb24uDQoNCkRvbmUuDQoNCg0KUGFn
ZSA1OiAgICAgRmlndXJlIDEuICAgRG9lcyB0aGUgYnJvd3NlciBhbmQgYXV0aG9yaXphdGlvbiBl
bmRwb2ludCBhcmUgc29tZSBraW5kcyBvZiAiZXh0ZXJuYWwgdXNlci1hZ2VudCI/IFN1Z2dlc3Qg
ZGVzY3JpYmluZyBpdCBtb3JlIGNsZWFybHkuDQoNCk5vdyBzdGF0ZXM6DQoiaWxsdXN0cmF0ZXMg
dGhlIGludGVyYWN0aW9uIG9mIHRoZSBuYXRpdmUgYXBwIHdpdGggYSBicm93c2VyDQogICAgICAg
IGV4dGVybmFsIHVzZXItYWdlbnQgdG8gYXV0aG9yaXplIHRoZSB1c2VyLiAiDQoNClBhZ2UgICA5
OiAgIFBLQ0UgW1JGQzc2MzZdIGRldGFpbHMgaG93IHRoaXMgbGltaXRhdGlvbiBjYW4gYmUgdXNl
ZCB0byBleGVjdXRlIGEgY29kZSBpbnRlcmNlcHRpb24gYXR0YWNrIChzZWUgRmlndXJlIDEpLg0K
DQpEb2VzIHRoZSBGaWd1cmUgMSBtZWFucyDigJxGaWd1cmUgMSBvZiBSRkM3NjM24oCdPw0KDQpH
b29kIGNhdGNoLiBJIGRlbGV0ZSB0aGUgZmlndXJlIHJlZmVyZW5jZSwgc2luY2UgdGhlIGVudGly
ZSBzcGVjIHRhbGtzIGFib3V0IHRoaXMgYXR0YWNrLCB3aGljaCBpcyBsaWtlbHkgc3VmZmljaWVu
dC4NCg0KDQpQYWdlMTA6ICAgICBIb3dldmVyLCBhcyB0aGUgSW1wbGljaXQgRmxvdyBjYW5ub3Qg
YmUgcHJvdGVjdGVkIGJ5IFBLQ0UNClNlZW1zIGhlcmUsIHRoZSByZWZlcmVuY2UgYmUgb21pdHRl
ZC4NCg0KQWRkZWQuDQoNCg0KQSBydW4gb2YgaWRuaXRzIHJldmVhbGVkIG5vIGVycm9ycywgZmxh
d3MuIFRoZXJlIHdlcmUgMSB3YXJuaW5nIGFuZCAxIGNvbW1lbnRzIHRob3VnaA0KDQoNCg0KICA9
PSBUaGVyZSBhcmUgMSBpbnN0YW5jZSBvZiBsaW5lcyB3aXRoIG5vbi1SRkMyNjA2LWNvbXBsaWFu
dCBGUUROcyBpbiB0aGUNCg0KICAgICBkb2N1bWVudC4NCg0KDQoNCkkgcmFuIGl0IG15c2VsZiB3
aXRoIHZlcmJvc2Ugb3V0cHV0LCBhbmQgZ290Og0KDQp0bXAvZHJhZnQtaWV0Zi1vYXV0aC1uYXRp
dmUtYXBwc19fMV8udHh0KDQzNSk6IEZvdW5kIHBvc3NpYmxlIEZRRE4gJ2NvbS5leGFtcGxlLmFw
cCcgaW4gcG9zaXRpb24gNTsgdGhpcyBkb2Vzbid0IG1hdGNoIFJGQyAyNjA2J3Mgc3VnZ2VzdGVk
ICIuZXhhbXBsZSIgb3IgIi5leGFtcGxlLihjb218b3JnfG5ldCkiLg0KDQpXZSBhcmUgYWN0dWFs
bHkgdXNpbmcgYSBSRkMyNjA2IGRvbWFpbiBuYW1lIGhlcmUsIGJ1dCBpbiByZXZlcnNlIGRvbWFp
biBuYW1lIG5vdGF0aW9uIHdoaWNoIGlzIGNhdXNpbmcgdGhpcyB3YXJuaW5nLg0KDQpObyBjaGFu
Z2VzIHJlcXVpcmVkLg0KDQoNCiAgTWlzY2VsbGFuZW91cyB3YXJuaW5nczoNCg0KICAtLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tDQoNCg0KDQogIC0tIFRoZSBkb2N1bWVudCBkYXRlIChBcHJpbCAyNiwgMjAx
NykgaXMgMTQgZGF5cyBpbiB0aGUgcGFzdC4gIElzIHRoaXMNCg0KICAgICBpbnRlbnRpb25hbD8N
Cg0KDQoNCg0KDQogIENoZWNraW5nIHJlZmVyZW5jZXMgZm9yIGludGVuZGVkIHN0YXR1czogQmVz
dCBDdXJyZW50IFByYWN0aWNlDQoNCiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg0KICAgICAo
U2VlIFJGQ3MgMzk2NyBhbmQgNDg5NyBmb3IgaW5mb3JtYXRpb24gYWJvdXQgdXNpbmcgbm9ybWF0
aXZlIHJlZmVyZW5jZXMNCg0KICAgICB0byBsb3dlci1tYXR1cml0eSBkb2N1bWVudHMgaW4gUkZD
cykNCg0KDQoNCiAgICAgTm8gaXNzdWVzIGZvdW5kIGhlcmUuDQoNCg0KDQogICAgIFN1bW1hcnk6
IDAgZXJyb3JzICgqKiksIDAgZmxhd3MgKH5+KSwgMSB3YXJuaW5nICg9PSksIDEgY29tbWVudCAo
LS0pLg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQoNCk9QUy1ESVIgbWFpbGluZyBsaXN0DQoNCk9QUy1ESVJAaWV0Zi5vcmc8bWFpbHRv
Ok9QUy1ESVJAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vb3BzLWRpcg0KDQoNCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBh
bm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERl
ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ
e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7
DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4u
TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl
eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv
bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k
ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z
by1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1h
cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD
b3VyaWVyIE5ldyI7fQ0KcC5tLTM3MDU2NjA2MjkzMjQzMDcyODBnbWFpbC1tLTM2MDM4NjEwNTE2
MTk3ODQ2NTJtLTc5NDI0ODE5NTY4NDQ5OTc0NjlnbWFpbC1tLTQ1MTg2NjUyMjYyNTEzOTg0NDdt
c29wbGFpbnRleHQsIGxpLm0tMzcwNTY2MDYyOTMyNDMwNzI4MGdtYWlsLW0tMzYwMzg2MTA1MTYx
OTc4NDY1Mm0tNzk0MjQ4MTk1Njg0NDk5NzQ2OWdtYWlsLW0tNDUxODY2NTIyNjI1MTM5ODQ0N21z
b3BsYWludGV4dCwgZGl2Lm0tMzcwNTY2MDYyOTMyNDMwNzI4MGdtYWlsLW0tMzYwMzg2MTA1MTYx
OTc4NDY1Mm0tNzk0MjQ4MTk1Njg0NDk5NzQ2OWdtYWlsLW0tNDUxODY2NTIyNjI1MTM5ODQ0N21z
b3BsYWludGV4dA0KCXttc28tc3R5bGUtbmFtZTptXy0zNzA1NjYwNjI5MzI0MzA3MjgwZ21haWwt
bV8tMzYwMzg2MTA1MTYxOTc4NDY1Mm1fLTc5NDI0ODE5NTY4NDQ5OTc0NjlnbWFpbC1tXy00NTE4
NjY1MjI2MjUxMzk4NDQ3bXNvcGxhaW50ZXh0Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0K
CW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2lu
LWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS
b21hbiIsInNlcmlmIjt9DQpzcGFuLkhUTUxDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIOmi
hOiuvuagvOW8jyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp
bms6IkhUTUwg6aKE6K6+5qC85byPIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVt
YWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1
bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ
e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4w
cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl
PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg
c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48
eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi
IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+
DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs
YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNvb2whIFRoaXMgY2hhbmdlcy9leHBsYWlucyBt
YWtlIHNlbnNlIHRvIG1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCBSZWdhcmRzITxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj4tTWljaGFlbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj7lj5Hku7bkuro8L3NwYW4+PC9iPjxiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+Ojwvc3Bhbj48L2I+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj4gV2lsbGlhbSBE
ZW5uaXNzIFttYWlsdG86d2Rlbm5pc3NAZ29vZ2xlLmNvbV0NCjxicj4NCjxiPjxzcGFuIGxhbmc9
IlpILUNOIj7lj5HpgIHml7bpl7Q8L3NwYW4+OjwvYj4gMjAxNzxzcGFuIGxhbmc9IlpILUNOIj7l
ubQ8L3NwYW4+NTxzcGFuIGxhbmc9IlpILUNOIj7mnIg8L3NwYW4+MjM8c3BhbiBsYW5nPSJaSC1D
TiI+5pelPC9zcGFuPiAzOjA5PGJyPg0KPGI+PHNwYW4gbGFuZz0iWkgtQ04iPuaUtuS7tuS6ujwv
c3Bhbj46PC9iPiB3YW5neml0YW88YnI+DQo8Yj48c3BhbiBsYW5nPSJaSC1DTiI+5oqE6YCBPC9z
cGFuPjo8L2I+IG9wcy1kaXJAaWV0Zi5vcmc7IG9hdXRoQGlldGYub3JnOyBkcmFmdC1pZXRmLW9h
dXRoLW5hdGl2ZS1hcHBzLmFsbEBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzxicj4NCjxiPjxzcGFu
IGxhbmc9IlpILUNOIj7kuLvpopg8L3NwYW4+OjwvYj4gUmU6IFtPUFMtRElSXSBPcHNkaXIgdGVs
ZWNoYXQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtb2F1dGgtbmF0aXZlLWFwcHMtMTA8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgeW91ciByZXZp
ZXcgWml0YW8hPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5W
ZXJzaW9uIDEyIGFkZHJlc3NlcyB5b3VyIGNvbW1lbnRzLiBEZXRhaWxlZCByZXNwb25zZXMgYmVs
b3c6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU3VuLCBNYXkgMjEs
IDIwMTcgYXQgODowNSBQTSwgd2FuZ3ppdGFvICZsdDs8YSBocmVmPSJtYWlsdG86d2FuZ3ppdGFv
QGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj53YW5neml0YW9AaHVhd2VpLmNvbTwvYT4mZ3Q7
IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0ibS0zNzA1NjYw
NjI5MzI0MzA3MjgwZ21haWwtbS0zNjAzODYxMDUxNjE5Nzg0NjUybS03OTQyNDgxOTU2ODQ0OTk3
NDY5Z21haWwtbS00NTE4NjY1MjI2MjUxMzk4NDQ3bXNvcGxhaW50ZXh0Ij4NClJldmlld2VyOiBa
aXRhbyBXYW5nIChNaWNoYWVsKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tMzcwNTY2MDYy
OTMyNDMwNzI4MGdtYWlsLW0tMzYwMzg2MTA1MTYxOTc4NDY1Mm0tNzk0MjQ4MTk1Njg0NDk5NzQ2
OWdtYWlsLW0tNDUxODY2NTIyNjI1MTM5ODQ0N21zb3BsYWludGV4dCI+DQpSZXZpZXcgcmVzdWx0
OiBIYXMgTml0czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tMzcwNTY2MDYyOTMyNDMwNzI4
MGdtYWlsLW0tMzYwMzg2MTA1MTYxOTc4NDY1Mm0tNzk0MjQ4MTk1Njg0NDk5NzQ2OWdtYWlsLW0t
NDUxODY2NTIyNjI1MTM5ODQ0N21zb3BsYWludGV4dCI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJtLTM3MDU2NjA2MjkzMjQzMDcyODBnbWFpbC1tLTM2MDM4NjEwNTE2MTk3ODQ2
NTJtLTc5NDI0ODE5NTY4NDQ5OTc0NjlnbWFpbC1tLTQ1MTg2NjUyMjYyNTEzOTg0NDdtc29wbGFp
bnRleHQiPg0KSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgT3Bl
cmF0aW9uYWwgZGlyZWN0b3JhdGXigJlzJm5ic3A7b25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFs
bCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuJm5ic3A7IFRoZXNl
Jm5ic3A7Y29tbWVudHMgd2VyZSB3cml0dGVuIHdpdGggdGhlIGludGVudCBvZiBpbXByb3Zpbmcg
dGhlIG9wZXJhdGlvbmFsJm5ic3A7YXNwZWN0cyBvZiB0aGUgSUVURiBkcmFmdHMuIENvbW1lbnRz
IHRoYXQNCiBhcmUgbm90IGFkZHJlc3NlZCBpbiBsYXN0IGNhbGwgbWF5IGJlIGluY2x1ZGVkIGlu
IEFEIHJldmlld3MgZHVyaW5nIHRoZSBJRVNHIHJldmlldy4mbmJzcDsgRG9jdW1lbnQgZWRpdG9y
cyBhbmQmbmJzcDtXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlr
ZSBhbnkgb3RoZXIgbGFzdCBjYWxsJm5ic3A7Y29tbWVudHMuPG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0ibS0zNzA1NjYwNjI5MzI0MzA3MjgwZ21haWwtbS0zNjAzODYxMDUxNjE5Nzg0NjUybS03
OTQyNDgxOTU2ODQ0OTk3NDY5Z21haWwtbS00NTE4NjY1MjI2MjUxMzk4NDQ3bXNvcGxhaW50ZXh0
Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tMzcwNTY2MDYyOTMyNDMwNzI4
MGdtYWlsLW0tMzYwMzg2MTA1MTYxOTc4NDY1Mm0tNzk0MjQ4MTk1Njg0NDk5NzQ2OWdtYWlsLW0t
NDUxODY2NTIyNjI1MTM5ODQ0N21zb3BsYWludGV4dCI+DQpEb2N1bWVudCByZXZpZXdlZDogJm5i
c3A7ZHJhZnQtaWV0Zi1vYXV0aC1uYXRpdmUtYXBwcy0xMDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Im0tMzcwNTY2MDYyOTMyNDMwNzI4MGdtYWlsLW0tMzYwMzg2MTA1MTYxOTc4NDY1Mm0tNzk0
MjQ4MTk1Njg0NDk5NzQ2OWdtYWlsLW0tNDUxODY2NTIyNjI1MTM5ODQ0N21zb3BsYWludGV4dCI+
DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTM3MDU2NjA2MjkzMjQzMDcyODBn
bWFpbC1tLTM2MDM4NjEwNTE2MTk3ODQ2NTJtLTc5NDI0ODE5NTY4NDQ5OTc0NjlnbWFpbC1tLTQ1
MTg2NjUyMjYyNTEzOTg0NDdtc29wbGFpbnRleHQiPg0KU3VtbWFyeTogPG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0ibS0zNzA1NjYwNjI5MzI0MzA3MjgwZ21haWwtbS0zNjAzODYxMDUxNjE5Nzg0
NjUybS03OTQyNDgxOTU2ODQ0OTk3NDY5Z21haWwtbS00NTE4NjY1MjI2MjUxMzk4NDQ3bXNvcGxh
aW50ZXh0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw
dDtmb250LWZhbWlseTpDb25zb2xhcyI+T0F1dGggMi4wIGF1dGhvcml6YXRpb24gcmVxdWVzdHMg
ZnJvbSBuYXRpdmUgYXBwcyBzaG91bGQgb25seSBiZSBtYWRlPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcyI+dGhyb3Vn
aCBleHRlcm5hbCB1c2VyLWFnZW50cywgcHJpbWFyaWx5IHRoZSB1c2Vy4oCZcyBicm93c2VyLiBU
aGlzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250
LWZhbWlseTpDb25zb2xhcyI+c3BlY2lmaWNhdGlvbiBkZXRhaWxzIHRoZSBzZWN1cml0eSBhbmQg
dXNhYmlsaXR5IHJlYXNvbnMgd2h5IHRoaXMgaXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG8iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj50aGUgY2FzZSwgYW5k
IGhvdyBuYXRpdmUgYXBwcyBhbmQgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzIGNhbiBpbXBsZW1lbnQ8
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS0zNzA1NjYwNjI5MzI0MzA3MjgwZ21h
aWwtbS0zNjAzODYxMDUxNjE5Nzg0NjUybS03OTQyNDgxOTU2ODQ0OTk3NDY5Z21haWwtbS00NTE4
NjY1MjI2MjUxMzk4NDQ3bXNvcGxhaW50ZXh0Ij4NCnRoaXMgYmVzdCBwcmFjdGljZS48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJtLTM3MDU2NjA2MjkzMjQzMDcyODBnbWFpbC1tLTM2MDM4NjEw
NTE2MTk3ODQ2NTJtLTc5NDI0ODE5NTY4NDQ5OTc0NjlnbWFpbC1tLTQ1MTg2NjUyMjYyNTEzOTg0
NDdtc29wbGFpbnRleHQiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFz
Ij5JIHRoaW5rIHRoZSBkb2N1bWVudCBpcyB3cml0dGVuIHZlcnkgY2xlYXIsIGV4Y2VwdCBzb21l
IHNtYWxsIG5pdHM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tMzcwNTY2MDYy
OTMyNDMwNzI4MGdtYWlsLW0tMzYwMzg2MTA1MTYxOTc4NDY1Mm0tNzk0MjQ4MTk1Njg0NDk5NzQ2
OWdtYWlsLW0tNDUxODY2NTIyNjI1MTM5ODQ0N21zb3BsYWludGV4dCI+DQo8YSBuYW1lPSJtXy0z
NzA1NjYwNjI5MzI0MzA3MjgwX21fLTM2MDM4NjEwNTE2MTk3Ij5QYWdlIDM6PC9hPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyBUaGUgbGFzdCBzZW50ZW5jZSBvZiBpbnRyb2R1Y3Rpb24tLSDigJxU
aGlzIHByYWN0aWNlIGlzIGFsc28ga25vd24gYXMgdGhlIEFwcEF1dGggcGF0dGVybuKAnS4mbmJz
cDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tMzcwNTY2MDYyOTMyNDMwNzI4
MGdtYWlsLW0tMzYwMzg2MTA1MTYxOTc4NDY1Mm0tNzk0MjQ4MTk1Njg0NDk5NzQ2OWdtYWlsLW0t
NDUxODY2NTIyNjI1MTM5ODQ0N21zb3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw
dDt0ZXh0LWluZGVudDozNi4wcHQiPg0KSSBzdWdnZXN0IGFkZGluZyBhIHJlZmVyZW5jZSB0byBl
eHBsYWluIHRoZSBBcHBBdXRoIHBhdHRlcm4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG9uZTxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj
Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7
bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJtLTM3MDU2NjA2Mjkz
MjQzMDcyODBnbWFpbC1tLTM2MDM4NjEwNTE2MTk3ODQ2NTJtLTc5NDI0ODE5NTY4NDQ5OTc0Njln
bWFpbC1tLTQ1MTg2NjUyMjYyNTEzOTg0NDdtc29wbGFpbnRleHQiPg0KUGFnZSAzOiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyBUZXJtaW5vbG9neSAtLSAmcXVvdDtPQXV0aCZxdW90Oy4mbmJzcDsg
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS0zNzA1NjYwNjI5MzI0MzA3MjgwZ21haWwtbS0z
NjAzODYxMDUxNjE5Nzg0NjUybS03OTQyNDgxOTU2ODQ0OTk3NDY5Z21haWwtbS00NTE4NjY1MjI2
MjUxMzk4NDQ3bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O3RleHQtaW5k
ZW50OjM2LjBwdCI+DQpJIHN1Z2dlc3QgbW9kaWZ5aW5nIHRvOiAmcXVvdDtPQXV0aCZxdW90OyZu
YnNwOyZuYnNwOyBUaGUgV2ViIEF1dGhvcml6YXRpb24gKE9BdXRoKSBwcm90b2NvbC4mbmJzcDsg
SW4gdGhpcyBkb2N1bWVudCwgT0F1dGggcmVmZXJzIHRvIE9BdXRoIDIuMCBbUkZDNjc0OV0uPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkkgd2VudCB3aXRoOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7SW4gdGhpcyBkb2N1bWVudCwgT0F1dGggcmVm
ZXJzIHRvIHRoZSBPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBGcmFtZXdvcmsgW1JGQzY3NDldLiZx
dW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5UaGUgcGhyYXNlICZxdW90O1dlYiBBdXRob3JpemF0aW9uIChPQXV0aCkgcHJvdG9jb2wmcXVv
dDsgb25seSBzZWVtcyB0byBhcHBlYXIgaW4gb3VyIFdHIENoYXJ0ZXIsIGFuZA0KPGEgaHJlZj0i
aHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS9zZWFyY2g/cT13ZWImIzQzO2F1dGhvcml6YXRpb24mIzQz
O3Byb3RvY29sIiB0YXJnZXQ9Il9ibGFuayI+DQpub3QgZ2VuZXJhbCB1c2FnZTwvYT4uPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl
ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJn
aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Im0tMzcwNTY2MDYyOTMyNDMwNzI4MGdtYWlsLW0tMzYwMzg2MTA1MTYxOTc4NDY1Mm0tNzk0MjQ4
MTk1Njg0NDk5NzQ2OWdtYWlsLW0tNDUxODY2NTIyNjI1MTM5ODQ0N21zb3BsYWludGV4dCI+DQpQ
YWdlIDQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRlcm1pbm9sb2d5IC0tICZxdW90O3dlYi12
aWV3JnF1b3Q7Jm5ic3A7IEEgd2ViIGJyb3dzZXIgVUkgY29tcG9uZW50LiZuYnNwOyZuYnNwOyA8
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTM3MDU2NjA2MjkzMjQzMDcyODBnbWFpbC1tLTM2
MDM4NjEwNTE2MTk3ODQ2NTJtLTc5NDI0ODE5NTY4NDQ5OTc0NjlnbWFpbC1tLTQ1MTg2NjUyMjYy
NTEzOTg0NDdtc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7dGV4dC1pbmRl
bnQ6MzYuMHB0Ij4NCkRvZXMgaXQgbWVhbiAmcXVvdDtVc2VyIEluZm9ybWF0aW9uJnF1b3Q7PyZu
YnNwOyBTdWdnZXN0IGV4cGFuZGluZyB0aGlzIGFiYnJldmlhdGlvbi48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5Eb25lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi
b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBj
bSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJtLTM3MDU2NjA2MjkzMjQzMDcyODBnbWFpbC1tLTM2MDM4NjEwNTE2
MTk3ODQ2NTJtLTc5NDI0ODE5NTY4NDQ5OTc0NjlnbWFpbC1tLTQ1MTg2NjUyMjYyNTEzOTg0NDdt
c29wbGFpbnRleHQiPg0KUGFnZSA1OiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBGaWd1cmUgMS4m
bmJzcDsmbmJzcDsgRG9lcyB0aGUgYnJvd3NlciBhbmQgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBh
cmUgc29tZSBraW5kcyBvZiAmcXVvdDtleHRlcm5hbCB1c2VyLWFnZW50JnF1b3Q7PyBTdWdnZXN0
IGRlc2NyaWJpbmcgaXQgbW9yZSBjbGVhcmx5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdyBzdGF0
ZXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m
cXVvdDtpbGx1c3RyYXRlcyB0aGUgaW50ZXJhY3Rpb24gb2YgdGhlIG5hdGl2ZSBhcHAgd2l0aCBh
IGJyb3dzZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBleHRlcm5hbCB1c2VyLWFnZW50IHRvIGF1
dGhvcml6ZSB0aGUgdXNlci4gJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr
cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7
cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6
MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls
eTpDb25zb2xhcyI+UGFnZSZuYnNwOyZuYnNwOyA5OiZuYnNwOyZuYnNwOyBQS0NFIFtSRkM3NjM2
XSBkZXRhaWxzIGhvdyB0aGlzIGxpbWl0YXRpb24gY2FuIGJlIHVzZWQgdG8gZXhlY3V0ZSBhIGNv
ZGUgaW50ZXJjZXB0aW9uIGF0dGFjayAoc2VlIEZpZ3VyZSAxKS4mbmJzcDsmbmJzcDsmbmJzcDsN
Cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTM3MDU2NjA2MjkzMjQzMDcyODBn
bWFpbC1tLTM2MDM4NjEwNTE2MTk3ODQ2NTJtLTc5NDI0ODE5NTY4NDQ5OTc0NjlnbWFpbC1tLTQ1
MTg2NjUyMjYyNTEzOTg0NDdtc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7
dGV4dC1pbmRlbnQ6MzYuMHB0Ij4NCkRvZXMgdGhlIEZpZ3VyZSAxIG1lYW5zIOKAnEZpZ3VyZSAx
IG9mIFJGQzc2MzbigJ0/Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i
bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R29vZCBjYXRjaC4gSSBk
ZWxldGUgdGhlIGZpZ3VyZSByZWZlcmVuY2UsIHNpbmNlIHRoZSBlbnRpcmUgc3BlYyB0YWxrcyBh
Ym91dCB0aGlzIGF0dGFjaywgd2hpY2ggaXMgbGlrZWx5IHN1ZmZpY2llbnQuPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0
OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm
dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv
bnQtZmFtaWx5OkNvbnNvbGFzIj5QYWdlMTA6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhvd2V2
ZXIsIGFzIHRoZSBJbXBsaWNpdCBGbG93IGNhbm5vdCBiZSBwcm90ZWN0ZWQgYnkgUEtDRSZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBw
dDt0ZXh0LWluZGVudDozNi4wcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u
dC1mYW1pbHk6Q29uc29sYXMiPlNlZW1zIGhlcmUsIHRoZSByZWZlcmVuY2UgYmUgb21pdHRlZC4m
bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWRkZWQuPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk
ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw
dDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcyI+QSBydW4gb2YgaWRuaXRzIHJldmVh
bGVkIG5vIGVycm9ycywgZmxhd3MuIFRoZXJlIHdlcmUgMSB3YXJuaW5nIGFuZCAxIGNvbW1lbnRz
IHRob3VnaDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Im0tMzcwNTY2MDYyOTMy
NDMwNzI4MGdtYWlsLW0tMzYwMzg2MTA1MTYxOTc4NDY1Mm0tNzk0MjQ4MTk1Njg0NDk5NzQ2OWdt
YWlsLW0tNDUxODY2NTIyNjI1MTM5ODQ0N21zb3BsYWludGV4dCI+DQombmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgPT0gVGhlcmUgYXJl
IDEgaW5zdGFuY2Ugb2YgbGluZXMgd2l0aCBub24tUkZDMjYwNi1jb21wbGlhbnQgRlFETnMgaW4g
dGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj
ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRvY3VtZW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwv
bzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkkgcmFuIGl0IG15c2VsZiB3aXRoIHZlcmJvc2Ugb3V0cHV0LCBhbmQg
Z290OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0id29yZC13cmFw
OmJyZWFrLXdvcmQ7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj
ayI+dG1wL2RyYWZ0LWlldGYtb2F1dGgtbmF0aXZlLWFwcHNfXzFfLnR4dCg0MzUpOiBGb3VuZCBw
b3NzaWJsZSBGUUROICdjb20uZXhhbXBsZS5hcHAnIGluIHBvc2l0aW9uIDU7IHRoaXMgZG9lc24n
dCBtYXRjaCBSRkMgMjYwNidzIHN1Z2dlc3RlZCAmcXVvdDsuZXhhbXBsZSZxdW90OyBvciAmcXVv
dDsuZXhhbXBsZS4oY29tfG9yZ3xuZXQpJnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBhcmUgYWN0dWFsbHkgdXNp
bmcgYSBSRkMyNjA2IGRvbWFpbiBuYW1lIGhlcmUsIGJ1dCBpbiByZXZlcnNlIGRvbWFpbiBuYW1l
IG5vdGF0aW9uIHdoaWNoIGlzIGNhdXNpbmcgdGhpcyB3YXJuaW5nLjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ObyBjaGFuZ2VzIHJlcXVpcmVk
LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u
ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w
cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxw
cmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgTWlzY2VsbGFuZW91cyB3YXJuaW5n
czo8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr
Ij4mbmJzcDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAtLSBUaGUgZG9jdW1lbnQg
ZGF0ZSAoQXByaWwgMjYsIDIwMTcpIGlzIDE0IGRheXMgaW4gdGhlIHBhc3QuJm5ic3A7IElzIHRo
aXM8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr
Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW50ZW50aW9uYWw/PC9zcGFuPjxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFu
PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7
IENoZWNraW5nIHJlZmVyZW5jZXMgZm9yIGludGVuZGVkIHN0YXR1czogQmVzdCBDdXJyZW50IFBy
YWN0aWNlPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpi
bGFjayI+Jm5ic3A7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L3NwYW4+PG86cD48L286cD48L3ByZT4N
CjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48
L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgKFNlZSBSRkNzIDM5NjcgYW5kIDQ4OTcgZm9yIGluZm9ybWF0aW9uIGFib3V0IHVzaW5n
IG5vcm1hdGl2ZSByZWZlcmVuY2VzPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFu
IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRvIGxvd2VyLW1h
dHVyaXR5IGRvY3VtZW50cyBpbiBSRkNzKTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48
c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBO
byBpc3N1ZXMgZm91bmQgaGVyZS48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4g
c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+
PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU3VtbWFy
eTogMCBlcnJvcnMgKCoqKSwgMCBmbGF3cyAofn4pLCAxIHdhcm5pbmcgKD09KSwgMSBjb21tZW50
ICgtLSkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpi
bGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJj
b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0ibS0z
NzA1NjYwNjI5MzI0MzA3MjgwZ21haWwtbS0zNjAzODYxMDUxNjE5Nzg0NjUybS03OTQyNDgxOTU2
ODQ0OTk3NDY5Z21haWwtbS00NTE4NjY1MjI2MjUxMzk4NDQ3bXNvcGxhaW50ZXh0Ij4NCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0ibS0zNzA1NjYwNjI5MzI0MzA3MjgwZ21haWwtbS0zNjAzODYxMDUxNjE5Nzg0
NjUybS03OTQyNDgxOTU2ODQ0OTk3NDY5Z21haWwtbS00NTE4NjY1MjI2MjUxMzk4NDQ3bXNvcGxh
aW50ZXh0Ij4NCk9QUy1ESVIgbWFpbGluZyBsaXN0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
bS0zNzA1NjYwNjI5MzI0MzA3MjgwZ21haWwtbS0zNjAzODYxMDUxNjE5Nzg0NjUybS03OTQyNDgx
OTU2ODQ0OTk3NDY5Z21haWwtbS00NTE4NjY1MjI2MjUxMzk4NDQ3bXNvcGxhaW50ZXh0Ij4NCjxh
IGhyZWY9Im1haWx0bzpPUFMtRElSQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T1BTLURJUkBp
ZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTM3MDU2NjA2MjkzMjQzMDcy
ODBnbWFpbC1tLTM2MDM4NjEwNTE2MTk3ODQ2NTJtLTc5NDI0ODE5NTY4NDQ5OTc0NjlnbWFpbC1t
LTQ1MTg2NjUyMjYyNTEzOTg0NDdtc29wbGFpbnRleHQiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHMtZGlyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHMtZGlyPC9hPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+
DQo8L2h0bWw+DQo=

--_000_E6BC9BBCBCACC246846FC685F9FF41EA2AE09727DGGEMM506MBXchi_--


From nobody Tue May 23 02:07:07 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8171294E8; Tue, 23 May 2017 02:06:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.719
X-Spam-Level: 
X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=DnjARNSl; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=sbkcQxpy
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjV3KkbTB3ds; Tue, 23 May 2017 02:06:57 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E4DC128B44; Tue, 23 May 2017 02:06:57 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id B674C208B2; Tue, 23 May 2017 05:06:56 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Tue, 23 May 2017 05:06:56 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=JtrfSNAKaNHoarolxA Mceb2sDRjuWhWSvOdnuB/kAec=; b=DnjARNSl4haSj/99CYj/I4nyATYjB0c4e/ Pk/Go503/o4BRHpL11Of6LG9vkWeaxPknq2bbr2rhzwPayrOP0WBf5mpgUdgEJdU l1yLm1w+XdmfjB6Wd5yXkpyh6VBemi9BI7pL8o88kyfYe1illGIfFW8Oy+mCe2qO ECGKf+Tmct58T5NRAeHv+4E4yI+u0OOl7mnh+TB8eQT84XpZ+3mbfoApUPOpNI91 Nc4U90ivflHBQIt6Jphda5FBoso8o4mnMBT1DZuKvqXrgclu61hhuuW+AYCdEAM7 GnvHenTiyWyaN3IrQhT604RHhCe2oFouBcVFhppeu64X62EJsc2g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=JtrfSNAKaNHoarolxAMceb2sDRjuWhWSvOdnuB/kAec=; b=sbkcQxpy 7vAQKScnptZDRGys3JRDLSJ6wfO5/zPfd7dXmdtRlofy8EZTAl2GTLJxMkWVMkF0 E5rPJbyQhRE4b2ImKbV511l0mWKtFsinRCFSZExu4ZXE11iZRqQ670NGjFfVVNNp KorotaTBbANWiuDbV2yiYKQo5mej9ncIet81WJrheb2jkVX/ViU7GF0/46vqmWcW T8Yi8wo4TjOBOzzhOuzto13/O4KnC4/nqeWKHj2LiMoxrK/h2uFfNZhjmiwVMF0I 2dvpm8uIyTvWCzPxo8/NfvDNLFPx6uTVE/E+8gHmoiVfYOfJ0SldQ+8zd9hv8Q/e otnNrMOeLMUufg==
X-ME-Sender: 
X-Sasl-enc: ivLHyXpIRxJNKAO3MVrPFbGRx+bCVXjfg22Lrl0CiZPu 1495530416
Received: from [10.13.86.3] (unknown [85.255.237.123]) by mail.messagingengine.com (Postfix) with ESMTPA id 5945224753; Tue, 23 May 2017 05:06:56 -0400 (EDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-EB9E0507-F693-4610-8D05-C085ED8E290D
Mime-Version: 1.0 (1.0)
From: Alexey Melnikov 
X-Mailer: iPhone Mail (13G35)
In-Reply-To: 
Date: Tue, 23 May 2017 10:24:12 +0100
Cc: Adam Roach , draft-ietf-oauth-native-apps@ietf.org, Hannes Tschofenig , "oauth@ietf.org" , The IESG , oauth-chairs@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <1D2FDD6E-3DA0-4E7C-BBF3-1A6146F7889B@fastmail.fm>
References: <149548482877.9096.13896958451655712801.idtracker@ietfa.amsl.com> 
To: William Denniss 
Archived-At: 
Subject: Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 09:06:59 -0000

--Apple-Mail-EB9E0507-F693-4610-8D05-C085ED8E290D
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Hi William,

On 22 May 2017, at 23:14, William Denniss  wrote:

>> Section 8.1 makes the statement that "Loopback IP based redirect URIs may=

>> be susceptible to interception by other apps listening on the same
>> loopback interface." That's not how TCP listener sockets work: for any
>> given IP address, they guarantee single-process access to a port at any
>> one time. (Exceptions would include processes with root access, but an
>> attacking process with that level of access is going to be impossible to
>> defend against). While mostly harmless, the statement appears to be false=

>> on its face, and should be removed or clarified.
>=20
> Will be removed in the next update. Thank you.

Actually, I disagree with Adam on this, because what he says is OS specific.=
 So I think the text is valuable and should stay.


--Apple-Mail-EB9E0507-F693-4610-8D05-C085ED8E290D
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit


Hi William,

On 22 May 2017, at 23:14, William Denniss <wdenniss@google.com> wrote:

Section 8.1 makes the statement that "Loopback IP based redirect URIs may

be susceptible to interception by other apps listening on the same

loopback interface." That's not how TCP listener sockets work: for any

given IP address, they guarantee single-process access to a port at any

one time. (Exceptions would include processes with root access, but an

attacking process with that level of access is going to be impossible to

defend against). While mostly harmless, the statement appears to be false

on its face, and should be removed or clarified.


Will be removed in the next update. Thank you.

Actually, I disagree with Adam on this, because what he says is OS specific. So I think the text is valuable and should stay.


--Apple-Mail-EB9E0507-F693-4610-8D05-C085ED8E290D--


From nobody Tue May 23 02:53:36 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE6F127286 for ; Tue, 23 May 2017 02:53:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.58
X-Spam-Level: *
X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Zn6gTcOUEpT for ; Tue, 23 May 2017 02:53:33 -0700 (PDT)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D1E0124C27 for ; Tue, 23 May 2017 02:53:33 -0700 (PDT)
Received: from [80.187.97.52] (helo=[10.23.67.16]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1dD6VP-0007vD-Gq for oauth@ietf.org; Tue, 23 May 2017 11:53:31 +0200
Content-Transfer-Encoding: 7bit
Content-Type: multipart/signed; boundary=Apple-Mail-6E1FFA2A-561E-4EB2-8665-5CA95D191990; protocol="application/pkcs7-signature"; micalg=sha1
From: Torsten Lodderstedt 
Mime-Version: 1.0 (1.0)
Message-Id: <55BAF4EE-D6C9-47D2-B27B-CECAE1D1CFDF@lodderstedt.net>
Date: Tue, 23 May 2017 11:53:30 +0200
To: oauth@ietf.org
X-Mailer: iPhone Mail (14F89)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: [OAUTH-WG] ZISC OAuth Security Workshop at ETH Zurich on July 13+14
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 09:53:35 -0000

--Apple-Mail-6E1FFA2A-561E-4EB2-8665-5CA95D191990
Content-Type: multipart/alternative;
	boundary=Apple-Mail-C5BE9408-0FC0-4355-9299-C2E5B207F274
Content-Transfer-Encoding: 7bit


--Apple-Mail-C5BE9408-0FC0-4355-9299-C2E5B207F274
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

The Zurich Information Security and Privacy Center (ZISC) is hosting the OAu=
th Security Workshop on July 13+14 at ETH Zurich, Switzerland. The main them=
e is the security of OAuth, but there are also talks about OpenID Connect an=
d other related technologies. You can find more information, including the s=
chedule with all talks, and the exact venue, at https://zisc.ethz.ch/oauth-s=
ecurity-workshop-2017/

Registration is open at https://zisc.ethz.ch/event/oauth-security-workshop-2=
017/ and early registration ends June 16, 2017.

--Apple-Mail-C5BE9408-0FC0-4355-9299-C2E5B207F274
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


The Zurich Informat=
ion Security and Privacy Center (ZISC) is hosting the OAuth Security Worksho=
p on July 13+14 at ETH Zurich, Switzerland. The main theme is the security o=
f OAuth, but there are also talks about OpenID Connect and other related tec=
hnologies. You can find more information, including the schedule with all ta=
lks, and the exact venue, at https://zisc.e=
thz.ch/oauth-security-workshop-2017/

Registration is open at =
;https://zisc.ethz.ch/event/oauth-security=
-workshop-2017/ and early registration ends June 16, 2017<=
/a>.
=

--Apple-Mail-C5BE9408-0FC0-4355-9299-C2E5B207F274--

--Apple-Mail-6E1FFA2A-561E-4EB2-8665-5CA95D191990
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSTCCBUUw
ggQtoAMCAQICEDPbmsaqwjeZa3PxA3uZ8LQwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNVBAYTAkdC
MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT
EUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNzAxMDkwMDAwMDBaFw0xODAxMDkyMzU5
NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEArsGSzZyz9Lq9SRW9Sve5K8n5lWhplOCE6HH3gMye12DjOpkF
FZt0b73t27G17Xsp6WUxHhNevf7ck0AUpvYUPCHBqVGJSIWF9hWAoSFCgQACOoh/cDFbzz1PsMY8
El7OmIus4JXtY4/VdoSIhFP3hzATbNAg32Kp+N8vtTuKTwbgnizJSyzZTYrsttn3LmwY17HU+U9v
XloMus5U/ln4ADZx0zyyDSsA6gtPxXYJpbgSTnHckVZ5zfR80guIZ538Y2qqsqt5VaSRSR2oQzE/
HETkKc/odPVhqBrXLyvnSFkCPrAXV07rcvwkPvHZeYVu4QdVWyO2HIQ4i2x9r5m7SwIDAQABo4IB
9TCCAfEwHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFPngHgVxOZ7G
Sji/IW4YJMBj02PHMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG
AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEE
AbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwXQYD
VR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50
QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAwWAYI
KwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhl
bnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNv
bW9kb2NhLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0B
AQsFAAOCAQEAAmueyHjiyL1qYgfe+hVSsGuKlgcvjCAfG8Jaq48tC0IjP8pH/tGi4uL9CHVfLnV3
pLDnjg6M2uvpEBp7crZZcnSPLeVss+tkhwv+F7ISYQyT4flNkqVUb8nfewbCPcIN13ObfpU7rlXo
IarEEplQo4SuymYVluQxTLOFKm5QOMF4JBMw/rjy4t95J7Mdp9NFUzQrKPJDaJ2Jr/TcTXFcjLvN
VmMBjK0959a9v1/1miRHd1DBsTh1KvBigEOUNMxvT5uUtB6/tioDZqBDDk8Gvdno/xmye3YiasS7
JgMREq5WcXqpWGu5kMFZMGPEvyPHeBZeqxx3amf4ImVnZ6WvgzGCA8MwggO/AgEBMIGwMIGbMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp
ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDPbmsaqwjeZa3PxA3uZ8LQw
CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN
MTcwNTIzMDk1MzMwWjAjBgkqhkiG9w0BCQQxFgQUwx7DCpeSancKS2NcnIvYDIJgmGowgcEGCSsG
AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl
cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT
OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB
AhAz25rGqsI3mWtz8QN7mfC0MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50
aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEB
AQUABIIBAI/qPYFYEGi6kFcATlWrCsPQFMBi/JcP5GbSVpXBO/yswf2MeKHsuF7HByLLxz6Y6ws5
pnlXMCoSScOQ/mJXgnke5cKBpyByXAEBRsJDFU5A0JFckVdr53J6XXpPw/4RWZgvBIlFCeEW7w92
nRc58jB9RfhFh+7eAdNbyeQdOWrkOrOG2H3GofqOi8IoRH2lirPR0cFih4/1kudpAbfV6Hctjzuu
drBMG33xxD9v6crr3C1eSzN6o4mFNL2+vRToSAWiU5bG3u6y0JTxOt/dO44k4/IhEje1/7cS/5SY
DNL3tEibx7DplhaLWD3pzRf0Y8jOff7vjkg838AuoikiDzcAAAAAAAA=

--Apple-Mail-6E1FFA2A-561E-4EB2-8665-5CA95D191990--


From nobody Tue May 23 03:09:23 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F89129451; Tue, 23 May 2017 03:09:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.719
X-Spam-Level: 
X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=aZw3Xkg4; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NAeXh1jm
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Um2hsNU_zxfC; Tue, 23 May 2017 03:09:19 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 733A812943E; Tue, 23 May 2017 03:09:19 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id DCBC720911; Tue, 23 May 2017 06:09:18 -0400 (EDT)
Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Tue, 23 May 2017 06:09:18 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=jyfMyquvPU8o3dHgJKiT9Fo1r1Z2C EbseCGnk69Nthc=; b=aZw3Xkg4JO5oHw78z2fLMkeq47XKCg1u+P2WSv6BYNjqk EUdLmnebBGFfPw6wqFHxXW1ramd1cuYKaBpMx6FgQMj7rLMM/jYDhG8hpupFhlGq UDhGL0+QPCElJwAecjYqjkxpv/lzJXp+G4lwaGule2RRjRq/BTP/FJ6fGYcnkKH4 DXqUVEtqJuLk85OYCFeYm9tllltijchPs//14TeDGp8h+9xwuJLoaZH4Qn4JbzIp ZEYIfH/gHV6u2uCpnvgifkG2GHW+wpO4feEe96i/mP8IwEo32QUs+e6VJhJy1M/w IKVDFZx6Ur/B9mRgTCJQhiVzITluhaggn7hpqsXaA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=jyfMyq uvPU8o3dHgJKiT9Fo1r1Z2CEbseCGnk69Nthc=; b=NAeXh1jmvvGpGV6JKtDLaX Ic+Om4/aXYhIWj/70uzkmwjXUpON22OvsjQeb8PQINBSkMk2rhpPdFDSkMEXMlVU H6mdfxKByfYnTWvBrhMfHorftfwW3nWIvbm9JTv6jvdQegkrlA5dvIyagJbPopBD rQjVzNfUevpaqXMxNOSdCTFgKyIRVgvuq+tzHndtlcDRB9gpt3SPjsFTlLddgfny qokHN6nrzJ2uFOLrK0lFoOI/f3arWOfPIg6fO9bkrKKmd3wq95vZX1D5Kq9hfUAO jIyyceWcp+h9Gf8G0GxK/XtX2FPAcwyQHxiqEgmwulXZNDg9i0Z4dTAVxI4SoCaw ==
X-ME-Sender: 
Received: by mailuser.nyi.internal (Postfix, from userid 99) id B98A69E23B; Tue, 23 May 2017 06:09:18 -0400 (EDT)
Message-Id: <1495534158.1405045.985657536.26AE401D@webmail.messagingengine.com>
From: Alexey Melnikov 
To: William Denniss 
Cc: Adam Roach , draft-ietf-oauth-native-apps@ietf.org, Hannes Tschofenig , oauth@ietf.org, The IESG , oauth-chairs@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary="_----------=_149553415814050450"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-a5162694
References: <149548482877.9096.13896958451655712801.idtracker@ietfa.amsl.com>  <1D2FDD6E-3DA0-4E7C-BBF3-1A6146F7889B@fastmail.fm>
Date: Tue, 23 May 2017 11:09:18 +0100
In-Reply-To: <1D2FDD6E-3DA0-4E7C-BBF3-1A6146F7889B@fastmail.fm>
Archived-At: 
Subject: Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 10:09:21 -0000

This is a multi-part message in MIME format.

--_----------=_149553415814050450
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"

On Tue, May 23, 2017, at 10:24 AM, Alexey Melnikov wrote:
> Hi William,
> 
> On 22 May 2017, at 23:14, William Denniss  wrote:>>> Section 8.1 makes the statement that "Loopback IP based redirect
>>> URIs may>>>  be susceptible to interception by other apps listening on the same>>>  loopback interface." That's not how TCP listener sockets work:
>>>  for any>>>  given IP address, they guarantee single-process access to a port
>>>  at any>>>  one time. (Exceptions would include processes with root access,
>>>  but an>>>  attacking process with that level of access is going to be
>>>  impossible to>>>  defend against). While mostly harmless, the statement appears to be
>>>  false>>>  on its face, and should be removed or clarified.
>>> 
>> 
>> Will be removed in the next update. Thank you.
> 
> Actually, I disagree with Adam on this, because what he says is OS
> specific. So I think the text is valuable and should stay.> 
In particular, I think SO_REUSEADDR socket option is widely implemented,
both on Windows and Linux.

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







On Tue, May 23, 2017, at 10:24 AM, Alexey Melnikov wrote:


Hi William,



Section 8.1 makes the statement that "Loopback IP based redirect URIs may


 be susceptible to interception by other apps listening on the same


 loopback interface." That's not how TCP listener sockets work: for any


 given IP address, they guarantee single-process access to a port at any


 one time. (Exceptions would include processes with root access, but an


 attacking process with that level of access is going to be impossible to


 defend against). While mostly harmless, the statement appears to be false


 on its face, and should be removed or clarified.








Will be removed in the next update. Thank you.





Actually, I disagree with Adam on this, because what he says is OS specific. So I think the text is valuable and should stay.





In particular, I think SO_REUSEADDR socket option is widely implemented, both on Windows and Linux.







--_----------=_149553415814050450--


From nobody Tue May 23 09:53:41 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0113D1201F8; Tue, 23 May 2017 09:53:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level: 
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVdmUqpbfCTL; Tue, 23 May 2017 09:53:26 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF71C1200C5; Tue, 23 May 2017 09:53:25 -0700 (PDT)
Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4NGrDpH016662 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 23 May 2017 11:53:14 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local
To: Alexey Melnikov , William Denniss 
Cc: draft-ietf-oauth-native-apps@ietf.org, Hannes Tschofenig , oauth@ietf.org, The IESG , oauth-chairs@ietf.org
References: <149548482877.9096.13896958451655712801.idtracker@ietfa.amsl.com>  <1D2FDD6E-3DA0-4E7C-BBF3-1A6146F7889B@fastmail.fm> <1495534158.1405045.985657536.26AE401D@webmail.messagingengine.com>
From: Adam Roach 
Message-ID: 
Date: Tue, 23 May 2017 11:53:08 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <1495534158.1405045.985657536.26AE401D@webmail.messagingengine.com>
Content-Type: multipart/alternative; boundary="------------0D53017DEE4387F52677BBB4"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 16:53:27 -0000

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

On 5/23/17 05:09, Alexey Melnikov wrote:
> On Tue, May 23, 2017, at 10:24 AM, Alexey Melnikov wrote:
>> Hi William,
>>
>> On 22 May 2017, at 23:14, William Denniss > > wrote:
>>>
>>>     Section 8.1 makes the statement that "Loopback IP based redirect
>>>     URIs may
>>>     be susceptible to interception by other apps listening on the same
>>>     loopback interface." That's not how TCP listener sockets work:
>>>     for any
>>>     given IP address, they guarantee single-process access to a port
>>>     at any
>>>     one time. (Exceptions would include processes with root access,
>>>     but an
>>>     attacking process with that level of access is going to be
>>>     impossible to
>>>     defend against). While mostly harmless, the statement appears to
>>>     be false
>>>     on its face, and should be removed or clarified.
>>>
>>>
>>> Will be removed in the next update. Thank you.
>>
>> Actually, I disagree with Adam on this, because what he says is OS 
>> specific. So I think the text is valuable and should stay.
>>
> In particular, I think SO_REUSEADDR socket option is widely 
> implemented, both on Windows and Linux.
>

Okay, after doing a lot of digging, this appears to be much more 
complicated than it should be [1]. Linux (as of 3.9) does allow multiple 
_listeners_ on a single IP/Address pair (and does load balancing among 
them o_O), but only if they're both using SO_REUSEADDR ("don't do that 
then" would be good advice). Windows allows the kind of hijacking 
described in the document unless SO_EXCLUSIVEADDRUSE is set (and it 
might be good advice in this document to suggest setting it).

So I'm okay with the paragraph staying in, although I would like to see 
it qualified with "on some operating systems", and would like to see a 
note (probably in section B.3) recommending the use of 
SO_EXCLUSIVEADDRUSE on listening sockets.

/a


____

[1] The most comprehensive explanation of facts on the ground that I 
could find is 
https://stackoverflow.com/questions/14388706/socket-options-so-reuseaddr-and-so-reuseport-how-do-they-differ-do-they-mean-t


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


  
    
  
  
    
On 5/23/17 05:09, Alexey Melnikov
      wrote:

    

    

      
      
On Tue, May 23, 2017, at 10:24 AM, Alexey Melnikov wrote:

      

      

        
Hi William,

        

        

          


          

          
On 22 May 2017, at 23:14, William Denniss <wdenniss@google.com>
            wrote:

          

        

        

          

            
Section 8.1 makes the statement that "Loopback IP based
              redirect URIs may

            

            
 be susceptible to interception by other apps listening
              on the same

            

            
 loopback interface." That's not how TCP listener
              sockets work: for any

            

            
 given IP address, they guarantee single-process access
              to a port at any

            

            
 one time. (Exceptions would include processes with
              root access, but an

            

            
 attacking process with that level of access is going
              to be impossible to

            

            
 defend against). While mostly harmless, the statement
              appears to be false

            

            
 on its face, and should be removed or clarified.

            

            


            

          

          


          

          
Will be removed in the next update. Thank you.

          

        

        


        

        
Actually, I disagree with Adam on this, because what he
          says is OS specific. So I think the text is valuable and
          should stay.

        

        


        

      

      
In particular, I think SO_REUSEADDR socket option is widely
        implemented, both on Windows and Linux.

      

      


      

    

    


    

    
Okay, after doing a lot of digging, this appears to be much more
      complicated than it should be [1]. Linux (as of 3.9) does allow
      multiple _listeners_ on a single IP/Address pair (and does load
      balancing among them o_O), but only if they're both using
      SO_REUSEADDR ("don't do that then" would be good advice). Windows
      allows the kind of hijacking described in the document unless
      SO_EXCLUSIVEADDRUSE is set (and it might be good advice in this
      document to suggest setting it).

    
So I'm okay with the paragraph staying in, although I would like
      to see it qualified with "on some operating systems", and would
      like to see a note (probably in section B.3) recommending the use
      of SO_EXCLUSIVEADDRUSE on listening sockets. 

    
/a

    


    

    
____

    
[1] The most comprehensive explanation of facts on the ground
      that I could find is
https://stackoverflow.com/questions/14388706/socket-options-so-reuseaddr-and-so-reuseport-how-do-they-differ-do-they-mean-t

    

  


--------------0D53017DEE4387F52677BBB4--


From nobody Tue May 23 10:27:30 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C97A4129C3E; Tue, 23 May 2017 10:27:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level: 
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1W3leItfRxB; Tue, 23 May 2017 10:27:21 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9D96129C37; Tue, 23 May 2017 10:27:21 -0700 (PDT)
Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4NHREZ5022728 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 23 May 2017 12:27:16 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local
To: William Denniss 
Cc: The IESG , draft-ietf-oauth-native-apps@ietf.org, Hannes Tschofenig , oauth-chairs@ietf.org, "oauth@ietf.org" 
References: <149548482877.9096.13896958451655712801.idtracker@ietfa.amsl.com> 
From: Adam Roach 
Message-ID: 
Date: Tue, 23 May 2017 12:27:09 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------E2F5C0BD007C926365915E05"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 17:27:24 -0000

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

William --

Thanks for your quick responses! I have only one follow-up (beyond my 
response to the thread that Alexey started):

On 5/22/17 17:14, William Denniss wrote:
> My understanding of the Web Authentication Broker is that it is 
> effectively a special-case browser designed for authentication. There 
> is a single cookie-jar which is retained and used with all apps that 
> use the Web Authentication Broker in "SSO mode". So logins are shared, 
> and the advantages of Section 4 apply.  It's a separate cookie-jar 
> from the main browser, which would imply a minimum of two sign-ins on 
> the device (so not quite "single" at a device level), but I'm not sure 
> if this is enough to disqualify it.
>
> My goal here is to simply document the current state of the art of the 
> platforms, and I felt that the Web Authentication Broker qualified as 
> an external user agent per the BCP.  The user interface is arguably 
> quite nice too, which mitigates some of the downsides of using a 
> special authentication "browser" with a separate cookie jar.

Some of this comes down to user experience and some of it comes down to 
user choice. I'm going to speak using first-person pronouns here, but 
please be aware that I'm speaking from the point of view of a 
significant body of users.

For the user experience side of things: users of Firefox and Chrome will 
commonly take advantage of cross-machine, cross-platform password 
synchronization built into those browsers, and the recommendation you're 
giving in this document defeats those pretty soundly. Thinking all the 
way through the user experience you're promoting, here's what this would 
look like to me:

 1. Native app has a button I can use to [link an account, authenticate
    myself, etc]
 2. I click that button, and the Web Authentication Broker opens
 3. I manually open Firefox, go to options->security, and click on
    "saved logins"
 4. I type in the name of the authenticating website, click on "Show
    Passwords," and enter my master password
 5. I copy and paste the (long, randomly-generated) password for the
    authenticating website into the Web Authentication Broker

That's... pretty friction-laden, especially when you consider that 
opening the authentication flow in my native browser would take maybe 
one or two clicks instead. The situation for Chrome users is 
approximately as bad.


The other part of this recommendation (and I think this is a bigger 
issue) is that I, as a user, have made a pretty conscious decision about 
the browser I want to use for these kinds of things, based in part on 
the way I know various browsers handle things like analytics and 
privacy, and based in part on the speed with which browser security 
exploits are patched. I'm going to presume that the Web Authentication 
Broker acts in every way that I care about like either Edge or Explorer 
(probably Edge), which is likely to fall outside the envelope of what 
I'm okay with in a browser. I don't mean this as a major knock on Edge; 
I just have certain preferences in this area, and it's a choice that I 
feel I should be allowed to make and have respected when possible.

This section is written in a way that reads very much like "use the Web 
Authentication Broker when possible, and fall back on the user's 
explicitly selected and preferred browser only as a last resort." This 
circumvents the user agency I describe above, which gives me more than a 
little cause for concern.

For these two reasons, I would like to see the recommendation in this 
section pretty much reversed: calling to to the browser registered with 
the operating system should be preferred so as to respect user agency, 
followed by a note that using the Microsoft Web Authentication Browser 
in SSO Mode qualifies as using an External Browser as described in this 
document, although it has the three drawbacks of:

 1. Not integrating with cookie storage for the user's preferred browser.
 2. Not integrating with password management for the user's preferred
    browser.
 3. Bypassing user choice regarding various browser attributes, such as
    privacy and security properties.


/a

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


  
    
  
  
    
William --

      

      Thanks for your quick responses! I have only one follow-up (beyond
      my response to the thread that Alexey started):

      

      On 5/22/17 17:14, William Denniss wrote:

    

    

      

        

          

            
My understanding of the Web
              Authentication Broker is that it is effectively a
              special-case browser designed for authentication. There is
              a single cookie-jar which is retained and used with all
              apps that use the Web Authentication Broker in "SSO mode".
              So logins are shared, and the advantages of Section 4
              apply.  It's a separate cookie-jar from the main browser,
              which would imply a minimum of two sign-ins on the device
              (so not quite "single" at a device level), but I'm not
              sure if this is enough to disqualify it.
              


              

              
My goal here is to simply document the current state
                of the art of the platforms, and I felt that the Web
                Authentication Broker qualified as an external user
                agent per the BCP.  The user interface is arguably quite
                nice too, which mitigates some of the downsides of using
                a special authentication "browser" with a separate
                cookie jar.

            

          

        

      

    

    

    Some of this comes down to user experience and some of it comes down
    to user choice. I'm going to speak using first-person pronouns here,
    but please be aware that I'm speaking from the point of view of a
    significant body of users.

    

    For the user experience side of things: users of Firefox and Chrome
    will commonly take advantage of cross-machine, cross-platform
    password synchronization built into those browsers, and the
    recommendation you're giving in this document defeats those pretty
    soundly. Thinking all the way through the user experience you're
    promoting, here's what this would look like to me:

    
    
      
  1. Native app has a button I can use to [link an account,
        authenticate myself, etc]
    2. 
      
  2. I click that button, and the Web Authentication Broker opens
    3. 
      
  3. I manually open Firefox, go to options->security, and click
        on "saved logins"
    4. 
      
  4. I type in the name of the authenticating website, click on
        "Show Passwords," and enter my master password
    5. 
      
  5. I copy and paste the (long, randomly-generated) password for
        the authenticating website into the Web Authentication Broker
    6. 
    

    
That's... pretty friction-laden, especially when you consider
      that opening the authentication flow in my native browser would
      take maybe one or two clicks instead. The situation for Chrome
      users is approximately as bad.

    

    


    

    
The other part of this recommendation (and I think this is a
      bigger issue) is that I, as a user, have made a pretty conscious
      decision about the browser I want to use for these kinds of
      things, based in part on the way I know various browsers handle
      things like analytics and privacy, and based in part on the speed
      with which browser security exploits are patched. I'm going to
      presume that the Web Authentication Broker acts in every way that
      I care about like either Edge or Explorer (probably Edge), which
      is likely to fall outside the envelope of what I'm okay with in a
      browser. I don't mean this as a major knock on Edge; I just have
      certain preferences in this area, and it's a choice that I feel I
      should be allowed to make and have respected when possible.

    This section is written in a way that reads very much like "use the
    Web Authentication Broker when possible, and fall back on the user's
    explicitly selected and preferred browser only as a last resort."
    This circumvents the user agency I describe above, which gives me
    more than a little cause for concern.

    

    For these two reasons, I would like to see the recommendation in
    this section pretty much reversed: calling to to the browser
    registered with the operating system should be preferred so as to
    respect user agency, followed by a note that using the Microsoft Web
    Authentication Browser in SSO Mode qualifies as using an External
    Browser as described in this document, although it has the three
    drawbacks of:

    
    
      
  1. Not integrating with cookie storage for the user's preferred
        browser.
    2. 
      
  2. Not integrating with password management for the user's
        preferred browser.
    3. 
      
  3. Bypassing user choice regarding various browser attributes,
        such as privacy and security properties.
    
      
    4. 
    

    

    /a

  


--------------E2F5C0BD007C926365915E05--


From nobody Tue May 23 14:48:13 2017
Return-Path: 
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED06128CDB; Tue, 23 May 2017 14:48:03 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ben Campbell 
To: "The IESG" 
Cc: draft-ietf-oauth-native-apps@ietf.org, Hannes Tschofenig , oauth-chairs@ietf.org, Hannes.Tschofenig@gmx.net, oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149557608311.28484.15294343372018912184.idtracker@ietfa.amsl.com>
Date: Tue, 23 May 2017 14:48:03 -0700
Archived-At: 
Subject: [OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 21:48:03 -0000

Ben Campbell has entered the following ballot position for
draft-ietf-oauth-native-apps-11: 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-native-apps/



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

I agree with Adam's general sentiment about detection of bad behavior vs
asking people not to be bad.

-8 and it's children: There seems to be a lot of duplication (including
duplication of normative language) between the security considerations
and the rest of the document.

- 8.7: This section seems to argue against using in-app browser tabs in
the first place. If there is no good way for the user to tell the
difference between that and an imbedded UA, then maybe we should train
users to be suspicious of any in-app presentation of the authorization
request? The last paragraph seems to be founded on a mismatch between
user needs and typical user sophistication.



From nobody Tue May 23 16:20:18 2017
Return-Path: 
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A03151293FF; Tue, 23 May 2017 16:20:04 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Elwyn Davies 
To: 
Cc: draft-ietf-oauth-native-apps.all@ietf.org, ietf@ietf.org, oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149558160461.28455.9901952519540975154@ietfa.amsl.com>
Date: Tue, 23 May 2017 16:20:04 -0700
Archived-At: 
Subject: [OAUTH-WG] Genart telechat review of draft-ietf-oauth-native-apps-11
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 23:20:05 -0000

Reviewer: Elwyn Davies
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document: draft-ietf-oauth-native-apps-11
Reviewer: Elwyn Davies
Review Date: 2017-05-23
IETF LC End Date: 2017-05-16
IESG Telechat date: 2017-05-25

Summary: (still) Almost ready.  Thanks for the responses to my last
call review of -10 which have addressed several of the comments.  It
seems to me that there still some issues with ensuring the selection
of, and hence the connection to,  the browser providing access to the
authorization services is secure (this was referred to in my previous
review but only (IMO)pary addressed).  This feels like a considerable
problem but I am neither a deep security expert or OAuth expert so I
may be wrong.  My old fogey soul is deeply offended by this new
fangled usage of 'app' which is still in my book an abbreviation, but
I guess I have to bow to the changing times and the acknowledgment
that 'app' is now dignified by an appearance in the OED. >shame<.
 Still, given that RFC 6749 lives on the other side of the
app/application divide, I think that the examples in the abstract and
the beginning of s1 should match with RFC 6749 which uses 'native
application(s).'    There are also a couple more nits that I missed on
the previous pass. [BTW UI is indeed a well-known abbreviation but
given it is only used once it might be worh expanding it.]

I understand that -12 has been submitted but had not been placed in
the public repository as of 9pm  UTC on 2017/05/23 (Tuesday evening my
time).

Major issues:
Possibly 2nd minor issue  is actually major.

Minor issues:
Relationship between (web) browser, (operating) system and user choice
of browser:
The terminology definition of 'browser' in s3:
   "browser" The default application launched by the operating system
to handle "http" 
                      and "https" scheme URI content.
The terminology of 'system browser' used in version 10 of the draft
has been removed but the term 'default application' could still be
interpreted as a system choice.  As far as I know, although some
operating systems have a preinstalled browser which will be the
'default browser', this is a commercial decision and users usually
have the option to install an alternative browser and instruct the OS
to use this as the application used to handle http/https content.  I
suggest that 'user selected application' would be clearer than
'default application'.  In particular Linux installations have no
default application - the user/installer has to separately install a
browser and set it as the default.

Security implications of browser application selection and
activation:
[This could possibly be consdiered as a major issue.]
AFAIK the choice of application that is invoked to handle http/https
content is a user choice made on a per-user configuration that does
not require special privileges.  Typically a browser application will
allow a user to select it as default http/https content when it is
first run by a given user and the choice can be changed at the user's
whim subsequently.  However there is no requirement to involve the
user.  A user-level application could (AFAICS) happily hijack the
configuration and install itself as selected browser without any user
intervention.  Apart from the obvious possibility of DoS, I am not
sufficiently expert in the details of OAuth to know what the
consequences of a bad actor installing a malicious pseudo-browser,
potentially acting as a MiTM or otherwise, might be.  It strikes me
that a user of OAuth might be concerned that the browser acting as
intermediary was what s/he thought it was.

Nits/editorial comments:
Abstract:  'Native apps' needs a reference to Section 9 of RFC 6749.
 I note that there they are (still) called 'native applications'.
 Suggest you postpone introducing the shorthand 'native apps' to
section 1 and indicate that the browser is a web browser. Thus:
OLD:
   OAuth 2.0 authorization requests from native apps should only be
made 
   through external user-agents, primarily the user's browser.  This
   specification details the security and usability reasons why this
is
   the case, and how native apps and authorization servers can
implement
   this best practice.
NEW:
   OAuth 2.0 authorization requests from native applications, as
described 
   in Section 9 of RFC 6749, should only be made through external
user-agents,
   primarily the user's web browser.  This specification details the
security and 
   usability reasons why this is the case, and how native applications
and 
   authorization servers can implement this best practice.
END

s1, para 1: In line with the above: s/native apps/native applications
(hereafter known as 'native apps')/

s1, para 2: s/browser/web browser/

s1, last para: 'AppAuth' needs a reference (a pointer to Appendix B
would provide something suitable I think). 

s3:  Needs a definition for 'redirect URI' pointing to RFC 6749
(possibly to Section 3.1.2 there).

s4.1, Figure 1: Rather nitty but the equivalence of authz and
authorization should be noted.

s7.1: Are there any references that an interested reader could follow
to find more info?

s7.2: Again reference(s) would help.  While the draft writes of
operating systems I can only find one (android). Is this in fact
correct?  Is there an expectation that this will become more generally
implemented?  If not making this a firm requirement is somewhat
dubious.

s7.1 and s7.2: It might be useful to mention that s8.1 describes means
to protect against bad actors installing malicious URI claiming apps.
(And also helps with s7.3 I believe).



From nobody Tue May 23 20:12:16 2017
Return-Path: 
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 97ACC126C7A; Tue, 23 May 2017 20:12:14 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla 
To: "The IESG" 
Cc: draft-ietf-oauth-native-apps@ietf.org, Hannes Tschofenig , oauth-chairs@ietf.org, Hannes.Tschofenig@gmx.net, oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149559553461.28492.8246838477291927765.idtracker@ietfa.amsl.com>
Date: Tue, 23 May 2017 20:12:14 -0700
Archived-At: 
Subject: [OAUTH-WG] Eric Rescorla's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 03:12:15 -0000

Eric Rescorla has entered the following ballot position for
draft-ietf-oauth-native-apps-11: 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-native-apps/



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

Document: draft-ietf-oauth-native-apps-11.txt

S 7.
   To fully support this best practice, authorization servers MUST
   support the following three redirect URI options.  Native apps MAY
   use whichever redirect option suits their needs best, taking into
   account platform specific implementation details.

It's not entirely clear from this text what "support" means. Would
just echoing whatever redirect URI the client provided count as
support?


S 7.2.

   App-claimed HTTPS redirect URIs have some advantages in that the
   identity of the destination app is guaranteed by the operating
   system.  For this reason, they SHOULD be used in preference to the
   other redirect options for native apps where possible.

You should probably be clearer on who this guarantee is provided to.
And I assume this SHOULD is directed to app authors?

   Claimed HTTPS redirect URIs function as normal HTTPS redirects from
   the perspective of the authorization server, though as stated in
   Section 8.4, it is REQUIRED that the authorization server is able to
   distinguish between public native app clients that use app-claimed
   HTTPS redirect URIs and confidential web clients.

S 8.4 doesn't seem clear on how one makes this distinction. Is
it just a matter of remembering what the app author told you?


S 8.1.
   As most forms of inter-app URI-based communication send data over
   insecure local channels, eavesdropping and interception of the
   authorization response is a risk for native apps.  App-claimed HTTPS
   redirects are hardened against this type of attack due to the
   presence of the URI authority, but they are still public clients and
   the URI is still transmitted over local channels with unknown
   security properties.

I'm probably missing something, but I'm not sure what this last
sentence means. Is the channel here the one that kicks off the
native app with the HTTPS URI as the target?



From nobody Wed May 24 08:27:05 2017
Return-Path: 
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA54B127369; Wed, 24 May 2017 08:27:02 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alexey Melnikov 
To: "The IESG" 
Cc: draft-ietf-oauth-native-apps@ietf.org, Hannes Tschofenig , oauth-chairs@ietf.org, Hannes.Tschofenig@gmx.net, oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149563962282.28554.14590140614058686244.idtracker@ietfa.amsl.com>
Date: Wed, 24 May 2017 08:27:02 -0700
Archived-At: 
Subject: [OAUTH-WG] Alexey Melnikov's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 15:27:04 -0000

Alexey Melnikov has entered the following ballot position for
draft-ietf-oauth-native-apps-11: 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-native-apps/



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

A couple of nits:

8.2.  OAuth Implicit Grant Authorization Flow

   The OAuth 2.0 implicit grant authorization flow as defined in
   Section 4.2 of OAuth 2.0 [RFC6749] generally works with the practice
   of performing the authorization request in the browser, and
receiving
   the authorization response via URI-based inter-app communication.
   However, as the Implicit Flow cannot be protected by PKCE (which is
a
   required in Section 8.1), the use of the Implicit Flow with native
   apps is NOT RECOMMENDED.

NOT RECOMMENDED is not actually a construct allowed by RFC 2119, I think
you should reword it using "SHOULD NOT".

It would be good to add RFC reference for HTTPS URIs.



From nobody Wed May 24 08:51:35 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 577DE129B9C; Wed, 24 May 2017 08:51:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level: 
X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=grbF0r1z; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=oSP/0Dj0
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7laQfhUTx1XL; Wed, 24 May 2017 08:51:23 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6913D129B84; Wed, 24 May 2017 08:51:23 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id CF13A20B70; Wed, 24 May 2017 11:51:22 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 24 May 2017 11:51:22 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=lJszP1hqAlxHdDz3b7 OvfXHUHIy0pvld8M/psP3UbMk=; b=grbF0r1zCLBfbHjCIhAEPTMphOn54QQZ5G yjtP1GGGLctK/jNnEIrMXqtByXg7EeU+5BY/TNgCKJLfZjytJ111om1l76OYxfuu 5DDZnL7pb0MI0aU6rCLyiuQNJGg15W0elFKtmqHr7Wbi3X3XPwP6yFlsmFvLkG9V 7UJzppM+vHQONn+VG4SY18iVQmSDLQeDy3e/7pnW7k6lWOQGeL01FqWRqu5x6ja3 X2/OraFImZh181bDh/kgXAHsBsmgd+HpedTAwFvjMRs59A5ddsnjo9gpubVuHV4+ z93TkxsvxCv0JaO7UKrhfTZMOJ5wzdcYJPfwKBg2DOzrYAveAQBA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=lJszP1hqAlxHdDz3b7OvfXHUHIy0pvld8M/psP3UbMk=; b=oSP/0Dj0 3u85Cb2TgRxt8rOlgQNOz4O99QI6Uer3a7/9C2w2LX8MUHjWKmJ461H7TEfjEymz V757wAQs6IJSL73c6yfmraEg9NYJhHQG02Tvl/vrpK46JhU0e1MrNXhzqSy/fLzF 989EkKZEFuYzy5So2jz+KLWY6x5ohfsFhOutPsTz5GEc7I/Ih/inPdYkS9Aoo358 Q6HU/PjJan47FXd+MTW8zNVTfj3WxEBuc/21bvIx5DhnIaG5ja6P9P9TKfgIX8r5 zX3rOKL5W+IJi5EWNoPa9Jux0CoKsRowY8pWUD5rZZHXI1tfo+8ozsfXWWhOclTM O8q/ZgFj4poncg==
X-ME-Sender: 
X-Sasl-enc: tqioOHLFjlUvFXvrsDZe0lXZ3i1PRXf7Q5af8QqkJFsp 1495641082
Received: from sjc-alcoop-8813.cisco.com (unknown [128.107.241.165]) by mail.messagingengine.com (Postfix) with ESMTPA id AC40C7E1FB; Wed, 24 May 2017 11:51:21 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper 
In-Reply-To: <149558160461.28455.9901952519540975154@ietfa.amsl.com>
Date: Wed, 24 May 2017 11:51:19 -0400
Cc: "gen-art >> General area reviewing team" , draft-ietf-oauth-native-apps.all@ietf.org, oauth@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <149558160461.28455.9901952519540975154@ietfa.amsl.com>
To: Elwyn Davies 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [OAUTH-WG] [Gen-art] Genart telechat review of draft-ietf-oauth-native-apps-11
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 15:51:25 -0000

Elwyn, thanks for your reviews of this document. I think the notion of =
what is meant by default browser as specified in this document matches =
the expectations of those likely to be consuming the document, so I =
don=E2=80=99t see a need for changes there. I have balloted No =
Objection.

Authors, thanks for your engagement with Elwyn=E2=80=99s previous =
review.

Alissa

> On May 23, 2017, at 7:20 PM, Elwyn Davies  =
wrote:
>=20
> Reviewer: Elwyn Davies
> Review result: Almost Ready
>=20
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
>=20
> For more information, please see the FAQ at
>=20
> .
>=20
> Document: draft-ietf-oauth-native-apps-11
> Reviewer: Elwyn Davies
> Review Date: 2017-05-23
> IETF LC End Date: 2017-05-16
> IESG Telechat date: 2017-05-25
>=20
> Summary: (still) Almost ready.  Thanks for the responses to my last
> call review of -10 which have addressed several of the comments.  It
> seems to me that there still some issues with ensuring the selection
> of, and hence the connection to,  the browser providing access to the
> authorization services is secure (this was referred to in my previous
> review but only (IMO)pary addressed).  This feels like a considerable
> problem but I am neither a deep security expert or OAuth expert so I
> may be wrong.  My old fogey soul is deeply offended by this new
> fangled usage of 'app' which is still in my book an abbreviation, but
> I guess I have to bow to the changing times and the acknowledgment
> that 'app' is now dignified by an appearance in the OED. >shame<.
>  Still, given that RFC 6749 lives on the other side of the
> app/application divide, I think that the examples in the abstract and
> the beginning of s1 should match with RFC 6749 which uses 'native
> application(s).'    There are also a couple more nits that I missed on
> the previous pass. [BTW UI is indeed a well-known abbreviation but
> given it is only used once it might be worh expanding it.]
>=20
> I understand that -12 has been submitted but had not been placed in
> the public repository as of 9pm  UTC on 2017/05/23 (Tuesday evening my
> time).
>=20
> Major issues:
> Possibly 2nd minor issue  is actually major.
>=20
> Minor issues:
> Relationship between (web) browser, (operating) system and user choice
> of browser:
> The terminology definition of 'browser' in s3:
>    "browser" The default application launched by the operating system
> to handle "http"=20
>                       and "https" scheme URI content.
> The terminology of 'system browser' used in version 10 of the draft
> has been removed but the term 'default application' could still be
> interpreted as a system choice.  As far as I know, although some
> operating systems have a preinstalled browser which will be the
> 'default browser', this is a commercial decision and users usually
> have the option to install an alternative browser and instruct the OS
> to use this as the application used to handle http/https content.  I
> suggest that 'user selected application' would be clearer than
> 'default application'.  In particular Linux installations have no
> default application - the user/installer has to separately install a
> browser and set it as the default.
>=20
> Security implications of browser application selection and
> activation:
> [This could possibly be consdiered as a major issue.]
> AFAIK the choice of application that is invoked to handle http/https
> content is a user choice made on a per-user configuration that does
> not require special privileges.  Typically a browser application will
> allow a user to select it as default http/https content when it is
> first run by a given user and the choice can be changed at the user's
> whim subsequently.  However there is no requirement to involve the
> user.  A user-level application could (AFAICS) happily hijack the
> configuration and install itself as selected browser without any user
> intervention.  Apart from the obvious possibility of DoS, I am not
> sufficiently expert in the details of OAuth to know what the
> consequences of a bad actor installing a malicious pseudo-browser,
> potentially acting as a MiTM or otherwise, might be.  It strikes me
> that a user of OAuth might be concerned that the browser acting as
> intermediary was what s/he thought it was.
>=20
> Nits/editorial comments:
> Abstract:  'Native apps' needs a reference to Section 9 of RFC 6749.
>  I note that there they are (still) called 'native applications'.
>  Suggest you postpone introducing the shorthand 'native apps' to
> section 1 and indicate that the browser is a web browser. Thus:
> OLD:
>    OAuth 2.0 authorization requests from native apps should only be
> made=20
>    through external user-agents, primarily the user's browser.  This
>    specification details the security and usability reasons why this
> is
>    the case, and how native apps and authorization servers can
> implement
>    this best practice.
> NEW:
>    OAuth 2.0 authorization requests from native applications, as
> described=20
>    in Section 9 of RFC 6749, should only be made through external
> user-agents,
>    primarily the user's web browser.  This specification details the
> security and=20
>    usability reasons why this is the case, and how native applications
> and=20
>    authorization servers can implement this best practice.
> END
>=20
> s1, para 1: In line with the above: s/native apps/native applications
> (hereafter known as 'native apps')/
>=20
> s1, para 2: s/browser/web browser/
>=20
> s1, last para: 'AppAuth' needs a reference (a pointer to Appendix B
> would provide something suitable I think).=20
>=20
> s3:  Needs a definition for 'redirect URI' pointing to RFC 6749
> (possibly to Section 3.1.2 there).
>=20
> s4.1, Figure 1: Rather nitty but the equivalence of authz and
> authorization should be noted.
>=20
> s7.1: Are there any references that an interested reader could follow
> to find more info?
>=20
> s7.2: Again reference(s) would help.  While the draft writes of
> operating systems I can only find one (android). Is this in fact
> correct?  Is there an expectation that this will become more generally
> implemented?  If not making this a firm requirement is somewhat
> dubious.
>=20
> s7.1 and s7.2: It might be useful to mention that s8.1 describes means
> to protect against bad actors installing malicious URI claiming apps.
> (And also helps with s7.3 I believe).
>=20
>=20
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art


From nobody Wed May 24 09:17:55 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95BF312EB4B for ; Wed, 24 May 2017 09:17: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nk2q0HAitew9 for ; Wed, 24 May 2017 09:17:51 -0700 (PDT)
Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e: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 A619A12EB44 for ; Wed, 24 May 2017 09:17:51 -0700 (PDT)
Received: by mail-pg0-x235.google.com with SMTP id x64so67976286pgd.3 for ; Wed, 24 May 2017 09:17:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=unCH9I4hEkpPnL3vbdd10FYS4ksJ/AfDRnPESu7Oel8=; b=hZRAMpTF8iewGghyva5G+ndTVy1NsVPYd5IkYPWAbZlHPYtV78b+6dJC/R8P4VRofl u1NPc106hkg5stKMHzLPbRSHdPFmAFrsUJremmZ3f2mPbwrDwPcRxw3Y2AtvlJtcW8gD pi0jpKHAVztOHthBa6dkRaM5W9qD3cGHIpKbo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=unCH9I4hEkpPnL3vbdd10FYS4ksJ/AfDRnPESu7Oel8=; b=OZ6rgJ+pbCb9nYbzmohCJywv0P3BAbRYMD3f1jgseY7VzSN9urrLv3vgh1QHQEaE7W bU+gn6wA2cB7WBViSrsl3w05B98gtjH6YakzWLJUqy5oBpDtkod60fG/BaKfznjv3ft0 mL39GP2x9VTMHreibjXQGo57ujlMYTKYoBAoh6H9R+zM6ka54om911r9NGUlTG8ez6XT jMbchoYmKDk285SprrWtsMoI3XU/J4V6biWW/BLPqyD0+AUVTlBcPtawQ6blsIhFjC5e 3qOrUWNJc7myHPYPEMa8AIAMZk3liAr6fMGnjQeKI4I0upCHINaFgKVAsafOoQSFANzX 4EUw==
X-Gm-Message-State: AODbwcBTA4cfI2/cs1TPOgMQdcVflODhAS6RsVtZlPe8LSm0BCGiLCt8 xT7ZKkVsoef3V6pihxY61y9ro2aQwi8E
X-Received: by 10.98.30.129 with SMTP id e123mr39901165pfe.240.1495642671161;  Wed, 24 May 2017 09:17:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.154.205 with HTTP; Wed, 24 May 2017 09:17:20 -0700 (PDT)
In-Reply-To: <149563962282.28554.14590140614058686244.idtracker@ietfa.amsl.com>
References: <149563962282.28554.14590140614058686244.idtracker@ietfa.amsl.com>
From: Brian Campbell 
Date: Wed, 24 May 2017 10:17:20 -0600
Message-ID: 
To: Alexey Melnikov 
Cc: The IESG , draft-ietf-oauth-native-apps@ietf.org,  oauth-chairs@ietf.org, oauth 
Content-Type: multipart/alternative; boundary="94eb2c03aa6620410a05504772fa"
Archived-At: 
Subject: Re: [OAUTH-WG] Alexey Melnikov's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 16:17:54 -0000

--94eb2c03aa6620410a05504772fa
Content-Type: text/plain; charset="UTF-8"

As far as I can tell, 'NOT RECOMMENDED' is fine per RFC 2119.


from https://www.ietf.org/rfc/rfc2119.txt

4. SHOULD NOT   This phrase, *or the phrase "NOT RECOMMENDED"* mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

And also this errata notes that NOT RECOMMENDED should be in the first
part of the abstract
https://www.rfc-editor.org/errata_search.php?rfc=2119&eid=499


On Wed, May 24, 2017 at 9:27 AM, Alexey Melnikov 
wrote:

> Alexey Melnikov has entered the following ballot position for
> draft-ietf-oauth-native-apps-11: 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-native-apps/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> A couple of nits:
>
> 8.2.  OAuth Implicit Grant Authorization Flow
>
>    The OAuth 2.0 implicit grant authorization flow as defined in
>    Section 4.2 of OAuth 2.0 [RFC6749] generally works with the practice
>    of performing the authorization request in the browser, and
> receiving
>    the authorization response via URI-based inter-app communication.
>    However, as the Implicit Flow cannot be protected by PKCE (which is
> a
>    required in Section 8.1), the use of the Implicit Flow with native
>    apps is NOT RECOMMENDED.
>
> NOT RECOMMENDED is not actually a construct allowed by RFC 2119, I think
> you should reword it using "SHOULD NOT".
>
> It would be good to add RFC reference for HTTPS URIs.
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


As far as I can tell, 'NOT RECOMMENDED' is fi=
ne per RFC 2119.

from https://www.ietf.org/rfc/rfc2119.txt

4. SHOULD NOT   T=
his phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

And also this errata notes that NOT RECOMMENDED should be in the firs=
t part of the abstract https://www.rfc-editor.org/errata_search.php?=
rfc=3D2119&eid=3D499 
On Wed, May 24, 2017 at 9:27 AM, Alexey Melniko=
v <aamelnikov@fastmail.fm> wrote:
Alexey Melnikov has entered the following ballot position for=


draft-ietf-oauth-native-apps-11: 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/<=
wbr>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-native-apps/







-----------------------------------------------------------------=
-----

COMMENT:

-----------------------------------------------------------------=
-----



A couple of nits:



8.2.=C2=A0 OAuth Implicit Grant Authorization Flow



=C2=A0 =C2=A0The OAuth 2.0 implicit grant authorization flow as defined in<=
br>
=C2=A0 =C2=A0Section 4.2 of OAuth 2.0 [RFC6749] generally works with the pr=
actice

=C2=A0 =C2=A0of performing the authorization request in the browser, and
receiving

=C2=A0 =C2=A0the authorization response via URI-based inter-app communicati=
on.

=C2=A0 =C2=A0However, as the Implicit Flow cannot be protected by PKCE (whi=
ch is

a

=C2=A0 =C2=A0required in Section 8.1), the use of the Implicit Flow with na=
tive

=C2=A0 =C2=A0apps is NOT RECOMMENDED.



NOT RECOMMENDED is not actually a construct allowed by RFC 2119, I think
you should reword it using "SHOULD NOT".



It would be good to add RFC reference for HTTPS URIs.





_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





--94eb2c03aa6620410a05504772fa--


From nobody Wed May 24 09:20:26 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2024128B8E; Wed, 24 May 2017 09:20:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.718
X-Spam-Level: 
X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=glOhjxLl; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nhWSSZl4
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdS9DXnjKeU2; Wed, 24 May 2017 09:20:17 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBD62129449; Wed, 24 May 2017 09:20:16 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 457CC207CC; Wed, 24 May 2017 12:20:16 -0400 (EDT)
Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Wed, 24 May 2017 12:20:16 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=gxbQTfrs+5iHEEuX/mn5WeZXC9f5C I7XMAL0A3jrFrE=; b=glOhjxLlg1rc5n/hXhOOqhLSzJtt0KzBQ6ub7K/GkVNf2 MnfoebTy7Ngx0lq5z3/FpNvvXJqi+x3NJz3weioXEEJ0ArTy/6Ia18e4E920vs0a faRCHf5RjCoyZdUaatDnFq8krd23uD4L9VaFZX/hi/UnZ+QuZWV0eAm+j8ErDHtP 08ms9fdK0pSHIufDZfqSsU5NdTjRTVVA80Jbr/XfH/1KxzIcIM4ZXz1gHXTeTjMK 7yd3x0D30o//pFhoT01w16DNNbd7R2hjZ+wtEVFH7ooV3cvaXH2ViWkc2cH1cWOW iJGqivNfkRCJrfuAnqDKS+039p1zmkjWeqZQuJGag==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=gxbQTf rs+5iHEEuX/mn5WeZXC9f5CI7XMAL0A3jrFrE=; b=nhWSSZl4FzWoqHV0bwWWme Y2mNC3HKFRiB8JOJfv+5fAu1CGGCiPDvofdYd8wI9c5vhIor9OZ9LQ6UIlkccC6n miYgjQXgIHj5dUqhn5LFQKSsetuKv0DywkNLgEpJXUzd9dzo6jQeJ1bjvuqELLrp +awNbnNk5NImAPzYITGHDH+rmROR8MmDoRNMW7GZf8DmlLQFLdcf4cl5tWvZQllz qT20XRoIJr7s8+aGfteSFHRjXo5G/AmgM1/hkYEb7DofMJQs5HfnxhhKO9zsHa5i lUGjBRjoXVUrPaxEcPAmXMsjuUTEeJjtbFJgZDMpRKJB3Lixn7PeAlbEQGxdEf5g ==
X-ME-Sender: 
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 188489E259; Wed, 24 May 2017 12:20:16 -0400 (EDT)
Message-Id: <1495642815.971519.987329656.342C84A9@webmail.messagingengine.com>
From: Alexey Melnikov 
To: Brian Campbell 
Cc: The IESG , draft-ietf-oauth-native-apps@ietf.org, oauth-chairs@ietf.org, oauth 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary="_----------=_14956428169715190"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-a5162694
References: <149563962282.28554.14590140614058686244.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Date: Wed, 24 May 2017 17:20:15 +0100
Archived-At: 
Subject: Re: [OAUTH-WG] Alexey Melnikov's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 16:20:19 -0000

This is a multi-part message in MIME format.

--_----------=_14956428169715190
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"

On Wed, May 24, 2017, at 05:17 PM, Brian Campbell wrote:
> As far as I can tell, 'NOT RECOMMENDED' is fine per RFC 2119.
> 
> 
> from https://www.ietf.org/rfc/rfc2119.txt
> 
> 
> 
> 4. SHOULD NOT   This phrase, *or the phrase "NOT RECOMMENDED"* mean
>    that there may exist valid reasons in particular circumstances when
>    the particular behavior is acceptable or even useful, but the full
>    implications should be understood and the case carefully weighed
>    before implementing any behavior described with this label.
>
> And also this errata notes that NOT RECOMMENDED should be in the first
> part of the abstract
> https://www.rfc-editor.org/errata_search.php?rfc=2119&eid=499
Never mind then!

> 
> On Wed, May 24, 2017 at 9:27 AM, Alexey Melnikov
>  wrote:>> Alexey Melnikov has entered the following ballot position for
>>  draft-ietf-oauth-native-apps-11: 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-native-apps/
>> 
>> 
>> 
>>  ----------------------------------------------------------------
>>  ------>>  COMMENT:
>>  ----------------------------------------------------------------
>>  ------>> 
>>  A couple of nits:
>> 
>>  8.2.  OAuth Implicit Grant Authorization Flow
>> 
>>     The OAuth 2.0 implicit grant authorization flow as defined in
>>     Section 4.2 of OAuth 2.0 [RFC6749] generally works with the
>>     practice>>     of performing the authorization request in the browser, and
>>  receiving
>>     the authorization response via URI-based inter-app communication.>>     However, as the Implicit Flow cannot be protected by PKCE
>>     (which is>>  a
>>     required in Section 8.1), the use of the Implicit Flow with
>>     native>>     apps is NOT RECOMMENDED.
>> 
>>  NOT RECOMMENDED is not actually a construct allowed by RFC 2119,
>>  I think>>  you should reword it using "SHOULD NOT".
>> 
>>  It would be good to add RFC reference for HTTPS URIs.
>> 
>> 
>>  _______________________________________________
>>  OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth


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







On Wed, May 24, 2017, at 05:17 PM, Brian Campbell wrote:


As far as I can tell, 'NOT RECOMMENDED' is fine per RFC 2119.







4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.


And also this errata notes that NOT RECOMMENDED should be in the first part of the abstract https://www.rfc-editor.org/errata_search.php?rfc=2119&eid=499 





Never mind then!








On Wed, May 24, 2017 at 9:27 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:


Alexey Melnikov has entered the following ballot position for


 draft-ietf-oauth-native-apps-11: 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.)


 


 



 for more information about IESG DISCUSS and COMMENT positions.


 


 


 The document, along with other ballot positions, can be found here:



 


 


 


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


 COMMENT:


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


 


 A couple of nits:


 


 8.2.  OAuth Implicit Grant Authorization Flow


 


    The OAuth 2.0 implicit grant authorization flow as defined in


    Section 4.2 of OAuth 2.0 [RFC6749] generally works with the practice


    of performing the authorization request in the browser, and


 receiving


    the authorization response via URI-based inter-app communication.


    However, as the Implicit Flow cannot be protected by PKCE (which is


 a


    required in Section 8.1), the use of the Implicit Flow with native


    apps is NOT RECOMMENDED.


 


 NOT RECOMMENDED is not actually a construct allowed by RFC 2119, I think


 you should reword it using "SHOULD NOT".


 


 It would be good to add RFC reference for HTTPS URIs.


 


 


 _______________________________________________


 OAuth mailing list













--_----------=_14956428169715190--


From nobody Wed May 24 13:43:22 2017
Return-Path: 
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D661287A3; Wed, 24 May 2017 13:43:14 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Warren Kumari 
To: "The IESG" 
Cc: draft-ietf-oauth-native-apps@ietf.org, Hannes Tschofenig , oauth-chairs@ietf.org, Hannes.Tschofenig@gmx.net, oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149565859459.8704.10614692639622962562.idtracker@ietfa.amsl.com>
Date: Wed, 24 May 2017 13:43:14 -0700
Archived-At: 
Subject: [OAUTH-WG] Warren Kumari's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 20:43:15 -0000

Warren Kumari has entered the following ballot position for
draft-ietf-oauth-native-apps-11: 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-native-apps/



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

Thanks to Zitao Wang (Michael) for the OpsDir review, and William for
addressing the comments...



From nobody Fri May 26 08:33:25 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCF0129432 for ; Fri, 26 May 2017 08:33:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.8
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFmWVdiM_53f for ; Fri, 26 May 2017 08:33:22 -0700 (PDT)
Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58CE11200FC for ; Fri, 26 May 2017 08:33:22 -0700 (PDT)
Received: by mail-vk0-x233.google.com with SMTP id x71so7206160vkd.0 for ; Fri, 26 May 2017 08:33:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=9SuSYQVCneQegEOsAueFX7dhjKyhiRifBrem0FJvme0=; b=gQGWtikZopd91xh2GUSI4J8s25Z5Xg8eea9IFCdeeSY3cFvImeEn84Uo7Tp6/bkdV5 QPZhmMCx5VMOYKrzmAlOPQlrenxXxh+3n03uo+jzVaUWjtG41CbzC8N0KpBdYGCIjVQX 8ZIOSFAWIdfNZIkVOR41QeMcDHvW6Gg1iweiYE5AhZtL48YpiQR+p02ClWo6a+vu5kis K5ynMSac0NQhz1I0tLL4GE298gCdffoelgCAEqqTkg23gyX8nGZEtN9sjwHooq3yY5wj JaOYnaJVQoESnZs2QTY/fpahcgdHVIo4gMAHNE6iDTA7OkfgBu3iHeMNbri63u492oEd OujQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=9SuSYQVCneQegEOsAueFX7dhjKyhiRifBrem0FJvme0=; b=K2cozPwjb5S0LwYjvZeaE6oFhUekquKwQKBExlGqm8FtK9Og3Qe6srDylo8leX98oi PSml4pt/AZDD7aEiizVcG0CQ2zKC+YAihnUJnIvTmcjt+2GmxGv2bbNmMOLlZ6mDMnGX L4rU8LXY3lCe8HyYQ7nsOK/SLAdjKe0izwvZChLVBZY1HBFXeOY6Suj2wDxWQNGr95Ax O0FasG4M5B1QHZ+fJ1qzvB/q37xc0HCVWoaOhkGXFJkq1AIIE1Bv32nv94qfoEP5kD6a YNdL9BacwVWY0B1pTJa2YsG0hoDJf02wIZHa1N1/FXNbu6V4nhuZLTzGyRxIKrgBcPVi teKw==
X-Gm-Message-State: AODbwcDvRTcjXk5gYuclyHbfi2xM3KOw1cxtLmsHL1pGhml5unsXlgGj pIcftR+9elGaXbBkmjMQQJAfO9dnyQ==
X-Received: by 10.31.188.21 with SMTP id m21mr1085373vkf.81.1495812801233; Fri, 26 May 2017 08:33:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.76.91 with HTTP; Fri, 26 May 2017 08:33:20 -0700 (PDT)
From: Rifaat Shekh-Yusef 
Date: Fri, 26 May 2017 11:33:20 -0400
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="001a1143a74cab0b9005506f0e36"
Archived-At: 
Subject: [OAUTH-WG]  Plan for Prague
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 May 2017 15:33:23 -0000

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

All,

Hannes and I discuss the plan for Prague, and we think that the following
documents would need to be discussed:

1. Device Flow
2. Mutual TLS Profile
3. PoP Key Distribution
4. Security Topics
5. Token Bindings
6. Token Exchange

Does this sound like a reasonable plan?
Any other documents/topics that needs to be added to this list?

Regards,
 Rifaat & Hannes

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


All,

Hannes and I discuss the plan for =
Prague, and we think that the following documents would need to be discusse=
d:

1. Device Flow
2. Mutual TLS Profile<=
/div>
3. PoP Key Distribution
4. Security Topics
5.=
 Token Bindings
6. Token Exchange

Does t=
his sound like a reasonable plan?
Any other documents/topics that=
 needs to be added to this list?

Regards,
=C2=A0Rifaat & Hannes




--001a1143a74cab0b9005506f0e36--


From nobody Fri May 26 13:26:26 2017
Return-Path: 
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 71730129449; Fri, 26 May 2017 13:26:24 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149583038439.8608.6889631754413770370@ietfa.amsl.com>
Date: Fri, 26 May 2017 13:26:24 -0700
Archived-At: 
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-01.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 May 2017 20:26: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 of the IETF.

        Title           : Mutual TLS Profiles for OAuth Clients
        Authors         : Brian Campbell
                          John Bradley
                          Nat Sakimura
                          Torsten Lodderstedt
	Filename        : draft-ietf-oauth-mtls-01.txt
	Pages           : 12
	Date            : 2017-05-26

Abstract:
   This document describes Transport Layer Security (TLS) mutual
   authentication using X.509 certificates as a mechanism for both OAuth
   client authentication to the token endpoint as well as for sender
   constrained access to OAuth protected resources.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-mtls-01
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-01


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 May 26 13:35:03 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 169571274D2 for ; Fri, 26 May 2017 13:35: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UezzMeSOw42 for ; Fri, 26 May 2017 13:35:00 -0700 (PDT)
Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e: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 4118A126D46 for ; Fri, 26 May 2017 13:35:00 -0700 (PDT)
Received: by mail-pf0-x230.google.com with SMTP id m17so20847340pfg.3 for ; Fri, 26 May 2017 13:35:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=XSgx4URis60gzO0ylp+MzgA/88lCkIj49HyEVQs5yec=; b=JIXUFt12uJlCihI8PL2dqo5/7C8YmQD+CEze09h4SNKzzPwyN6uTNN8toKMRzT1ote R/nsvJL/CVGhboRzyYQr91LVS7Tdl/d+pdmKJlEwsXiJ/JrG4/gVHMfT5t4lM67QKaN0 31DCHdCjYCnPABgF8Kx1CtKlNQJBvx+9tYSPc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=XSgx4URis60gzO0ylp+MzgA/88lCkIj49HyEVQs5yec=; b=CRoXS8Gpwdt1Av/ZDGcMtpkOOwzkkVMoehqn/Ty20yKuy1019Sb0MdqkGN+jA/sGk5 odrr5XNrDWJqS0VMDCLkTwantggOjhSWPU9EehgD8zemR9X9dPKX0cyzIBOS6KGeuAvY Lfg1dVu8A6wrVWvt+KV6d9fTrsX+S+xEvsOeYWlX9oddFjAPlVnxm9mVdvsgj6WHa3g3 zVTjbS+obFNpymd7WKYlJs5mZCTvoBIlkgu62cWWM+8oqq2Zr/rPthWzj5k0BgolcO1O M4092NUDPKrVUFdlB28Drl8vdvy2tltaPkLxJbv/tIk6yHW3Hk8QH9M8TlIU6qqXVLSH hpKg==
X-Gm-Message-State: AODbwcBkEVc5tr9HOvVzzeh0ketOz+L9YEkEE30cGqzApMA8sb71kM0A 6lZ1GnGpSHrErDzxW/Bsf3VDhQ9C7YGbTQM=
X-Received: by 10.84.228.207 with SMTP id y15mr59833922pli.172.1495830899569;  Fri, 26 May 2017 13:34:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.154.205 with HTTP; Fri, 26 May 2017 13:34:28 -0700 (PDT)
In-Reply-To: <149583038439.8608.6889631754413770370@ietfa.amsl.com>
References: <149583038439.8608.6889631754413770370@ietfa.amsl.com>
From: Brian Campbell 
Date: Fri, 26 May 2017 14:34:28 -0600
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="089e08e4f3b769cec305507345f7"
Archived-At: 
Subject: [OAUTH-WG] Fwd:  I-D Action: draft-ietf-oauth-mtls-01.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 May 2017 20:35:02 -0000

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

A new draft of "Mutual TLS Profiles for OAuth Clients" has been
published. The changes from the previous version are summarized below.


   draft-ietf-oauth-mtls-01


   o  Added more explicit details of using RFC 7662
 token introspection
      with mutual TLS sender constrained access tokens.
   o  Added an IANA OAuth Token Introspection Response Registration
      request for "cnf".
   o  Specify that tls_client_auth_subject_dn and
      tls_client_auth_root_dn are RFC 4514
 String Representation
of
      Distinguished Names.
   o  Changed tls_client_auth_issuer_dn to tls_client_auth_root_dn.
   o  Changed the text in the Section 3

to not be specific about using a
      hash of the cert.
   o  Changed the abbreviated title to 'OAuth Mutual TLS' (previously
      was the acronym MTLSPOC).




---------- Forwarded message ----------
From: 
Date: Fri, May 26, 2017 at 2:26 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-01.txt
To: i-d-announce@ietf.org
Cc: oauth@ietf.org



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

        Title           : Mutual TLS Profiles for OAuth Clients
        Authors         : Brian Campbell
                          John Bradley
                          Nat Sakimura
                          Torsten Lodderstedt
        Filename        : draft-ietf-oauth-mtls-01.txt
        Pages           : 12
        Date            : 2017-05-26

Abstract:
   This document describes Transport Layer Security (TLS) mutual
   authentication using X.509 certificates as a mechanism for both OAuth
   client authentication to the token endpoint as well as for sender
   constrained access to OAuth protected resources.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-mtls-01
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-01


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

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


A new draft of "Mutual TLS Profiles for OAut=
h Clients" has been published. The changes from the previous version a=
re summarized below. 

   <=
a href=3D"https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-01">d=
raft-ietf-oauth-mtls-01

   o  Added more explicit details of using RFC 7662 token introspection
      with mutual TLS sender constrained access tokens.
   o  Added an IANA OAuth Token Introspection Response Registration
      request for "cnf".
   o  Specify that tls_client_auth_subject_dn and
      tls_client_auth_root_dn are RFC 4514 String Representation of
      Distinguished Names.
   o  Changed tls_client_auth_issuer_dn to tls_client_auth_root_dn.
   o  Changed the text in the Section 3 to not be specific ab=
out using a
      hash of the cert.
   o  Changed the abbreviated title to 'OAuth Mutual TLS' (previous=
ly
      was the acronym MTLSPOC).



---------- Forwarded message ----------
From:  <internet-drafts@ietf.org>
Date: Fri, May 26, 2017 at 2:26=
 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-01.txt
To: =
i-d-announce@ietf.org
Cc: <=
a href=3D"mailto:oauth@ietf.org">oauth@ietf.org




A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.

This draft is a work item of the Web Authorization Protocol of the IETF.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 Mutual TLS Profiles for OAuth Clients

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Bria=
n Campbell

=C2=A0 =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 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 Torsten Lodderstedt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet=
f-oauth-mtls-01.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 12

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=
 2017-05-26



Abstract:

=C2=A0 =C2=A0This document describes Transport Layer Security (TLS) mutual<=
br>
=C2=A0 =C2=A0authentication using X.509 certificates as a mechanism for bot=
h OAuth

=C2=A0 =C2=A0client authentication to the token endpoint as well as for sen=
der

=C2=A0 =C2=A0constrained access to OAuth protected resources.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-i=
etf-oauth-mtls/



There are also htmlized versions available at:

https://tools.ietf.org/html/draft-ietf-oaut=
h-mtls-01

https://datatracker.ietf.org/doc/=
html/draft-ietf-oauth-mtls-01



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=
=3Ddraft-ietf-oauth-mtls-01





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





--089e08e4f3b769cec305507345f7--


From nobody Fri May 26 15:21:57 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A34DA12940C for ; Fri, 26 May 2017 15:21: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEJWbgQowzbl for ; Fri, 26 May 2017 15:21:51 -0700 (PDT)
Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75600127863 for ; Fri, 26 May 2017 15:21:51 -0700 (PDT)
Received: by mail-pf0-x234.google.com with SMTP id m17so22576242pfg.3 for ; Fri, 26 May 2017 15:21:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=FNEgRcdjVD0PWoqHGupXn3QniS85gm2HAFA3GFW98EE=; b=Cwu3y7ZCZSfa0hmC/gd7zS5ZcDJ7j2GdkZKvH/13rdMvg6s9JNQuS3vhjPBVsN/Ah2 NODTpud+iT/DQwoPVoa0veLDsPxq6n8z5D84JTneL9npawqvYEktU+JHpYnBPk8QIbql Kx6lFhG1QIjKsxMSsoYCa+prdaErC6Rq2+AT0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=FNEgRcdjVD0PWoqHGupXn3QniS85gm2HAFA3GFW98EE=; b=sImaeq6vB0Qct7RM+BOnp9IUb5KzKk9tSgAVb4XcLtTYt98D1J2Rc3JGQUq4IseOQF PertcdC6Zv1THVhQaCmCUL+Oxv6spJZ/66MW+hbfGsYjtRlI/kbuInc4vHbmJdQPQW8D KHeT4zqYwQ4/BVUvjdZXz+fjYMPDRWPUPbuLqdPCW7Qt31+kyWHEBOSjzrudlqhDl0VT 4+3t7CVKUa3ffo9mq2kdFzubCbYnRGrAevvtfZ3m6CWEAdfWLsKxyj2DXCTF4gCP8VKj sxgsnhyasL5/qTy7IT6iIf8blXdI64xA2I2j/z0V6P10RrHHAQkbke60BIaDQ3MrehcG 2oWw==
X-Gm-Message-State: AODbwcAov4TZfDDzbK2oY6eYVUE0Pe04AFyBnHcByXLWKHsUaOjdipGt nZs7zJJbrB9Hu+5gzWqIMzxtRBPicNzIz+g=
X-Received: by 10.98.30.129 with SMTP id e123mr5009638pfe.240.1495837310367; Fri, 26 May 2017 15:21:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.154.205 with HTTP; Fri, 26 May 2017 15:21:19 -0700 (PDT)
In-Reply-To: 
References: <148416124213.8244.5842562779051799977.idtracker@ietfa.amsl.com>  <9199091B-5D7F-4D66-9EC5-CB0EF2D3CF6D@lodderstedt.net>   <30B37ED3-6E3B-4739-9917-BDEC198CA027@lodderstedt.net>        <58cc229c-ca5e-18d4-8b62-fbb3853f5cca@free.fr> 
From: Brian Campbell 
Date: Fri, 26 May 2017 16:21:19 -0600
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="94eb2c03aa6686d2a8055074c3ff"
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 May 2017 22:21:56 -0000

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

Following up on this, I'd like to propose a different and less invasive
change to the "actor_token" text. The new wording is below and not much
different than the text in the current draft. Barring any solid objections
to this in the next week or so, I'll publish -08 at which point I believe
the document will be ready for WGLC.

actor_token

OPTIONAL.  A security token that represents the identity of the acting
party. Typically this will be the party that is authorized to use the
requested security token and act on behalf of the subject.



On Thu, May 11, 2017 at 9:58 AM, Brian Campbell 
wrote:

> The token exchange framework facilitates deployments like this one
> https://help.salesforce.com/articleView?id=3Dremoteaccess_oaut
> h_asset_token_flow.htm or https://developer.box.com/docs
> /getting-started-with-new-box-view, for example, and I don't think pure
> plug and play interoperability is a realistic goal. The framework promote=
s
> interoperability in the form of common patterns and parameters that can b=
e
> supported in libraries, products, and services.
>
> There's not one "other case" I have in mind but rather just broadening th=
e
> text somewhat to more straightforwardly accommodate other cases.  One
> potential example is where the actor_token represents an authorizing part=
y
> (again maybe needed for policy or auditing) to the token exchange event
> itself rather than the party that's having access rights assigned to it
> (implicitly with impersonation or explicitly with delegation).
>
>
>
> On Tue, May 9, 2017 at 9:55 AM, Denis  wrote:
>
>> Brian,
>>
>> Even if Token Exchange is a framework, the goal is to be finally able to
>> interoperate.
>>
>> Whether we have one or two parameters, would you be able to provide a
>> precise semantics for the "other case" you have in mind ?
>>
>> Denis
>>
>> Yes, I omitted your comments in that post because I'd previously replied
>> to you in a separate message where I said that the "actor_token is a
>> security token so that's not an issue that needs to be addressed."
>> https://www.ietf.org/mail-archive/web/oauth/current/msg17247.html
>>
>> The other point you've just made about having very precise semantics for
>> a field is a fair one. However, I wanted to avoid introducing yet anothe=
r
>> field (or really two fields b/c of the associated *_type for each inboun=
d
>> token field), for what felt like a minor semantic variation that could b=
e
>> easily accommodated by the existing framework, to the draft that already
>> has a lot of options and parameters on the request. And Token Exchange
>> really is a framework. I think that, to some extent, the framework is a =
bit
>> of a Rorschach test for deployers and implementers to utilize to solve
>> their specific issues and needs. I expect that will be the case regardle=
ss.
>> And I am proposing to somewhat genericize the text around one request
>> parameter to be more reflective of that.
>>
>> I would like to hear from others in the WG though.
>>
>> On Tue, May 9, 2017 at 3:06 AM, Denis  wrote:
>>
>>> Brian,
>>>
>>> You omitted to include my comments in this post. So here it is again:
>>>
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>
>>> The current text is:
>>>
>>> actor_token OPTIONAL. A security token that represents the identity of
>>> the party that is authorized to use the requested security token and ac=
t on
>>> behalf of the subject.
>>>
>>> This sentence is indeed wrong since an actor-token is not a security
>>> token.
>>>
>>> So your proposed change does not solve this issue: actor_token
>>> OPTIONAL.  A security token that represents the identity of the acting
>>> party.
>>>
>>> The current text states:
>>>
>>> Typically, in the request, the subject_token represents the identity of
>>> the party on behalf of whom
>>> the token is being requested while the actor_token represents the
>>> identity of the party to whom the access
>>> rights of the issued token are being delegated.
>>>
>>> Logically, the definition should be along the following lines:
>>>
>>>  actor_token OPTIONAL. Indicates the identity of the party to whom the
>>> access rights of the issued token are being delegated.
>>>
>>> If there is no delegation, then this field (which is optional) will not
>>> be used.
>>>
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>
>>> I read your argumentation, but I maintain my comment. Each field should
>>> have a precise semantics.
>>>
>>> If you want to have another semantics, you should propose to define
>>> another field with its precise meaning.
>>>
>>> Denis
>>>
>>> Let me throw out a bit more context about this. The "actor_token" might=
,
>>> in a delegation scenario, represent the identity of the party to whom t=
he
>>> access rights of the issued token are being delegated. That's the typic=
al
>>> delegation scenario that is discussed in the draft. However, the
>>> "actor_token" might also be utilized/needed by the AS in an impersonati=
on
>>> scenario for policy or auditing reasons even when the resulting issued
>>> token doesn't contain info about the delegation or actor. Similarly, th=
e
>>> actor might not be strictly doing the impersonation but rather just be =
a
>>> party (again maybe needed for policy or auditing) to the token exchange
>>> event itself.  When I wrote the "actor_token" text in section 2.1 some =
~18
>>> months ago I had the delegation scenario at the front of my mind and
>>> (clearly) intended to accommodate it. However, I didn't intend to limit=
 it
>>> to only that and, looking at the text again, I think what is there now =
is
>>> too prescriptive and narrow. Thus my proposing to generalize the text
>>> somewhat.
>>>
>>>
>>>
>>>
>>> On Mon, May 8, 2017 at 10:29 AM, Brian Campbell <
>>> bcampbell@pingidentity.com> wrote:
>>>
>>>> I do have one minor issue I'd like to raise that relates to some
>>>> conversations I've been a party to recently about implementations and
>>>> applications of token exchange.
>>>>
>>>> I think that the current text in =C2=A72.1 for the "actor_token" is ov=
erly
>>>> specific towards the delegation scenario. I'd propose the language be
>>>> generalized somewhat to allow more versatility in applications/deploym=
ents
>>>> of the token exchange framework. Here's that text:
>>>>
>>>>    actor_token
>>>>       OPTIONAL.  A security token that represents the identity of the
>>>>       acting party.
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, May 8, 2017 at 8:01 AM, Rifaat Shekh-Yusef <
>>>> rifaat.ietf@gmail.com> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> The last email from Brian addresses the multiple audiences/resources
>>>>> issue with an error code, and we did not see any objection to this ap=
proach
>>>>> so far.
>>>>>
>>>>>
>>>>> *Authors,*
>>>>>
>>>>> Are there any other open issues with this draft?
>>>>> Do you believe it is ready for WGLC?
>>>>>
>>>>> Thanks,
>>>>>  Rifaat & Hannes
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Mar 31, 2017 at 11:03 AM, Brian Campbell <
>>>>> bcampbell@pingidentity.com> wrote:
>>>>>
>>>>>> As mentioned during the Chicago meeting the "invalid_target" error
>>>>>> code that was added in -07 was intended to give the AS a standard wa=
y to
>>>>>> reject request with multiple audiences/resources that it doesn't und=
erstand
>>>>>> or is unwilling or unable to process based on policy or whatever cri=
teria .
>>>>>> It was intended as a compromise, of sorts, to allow for the multiple
>>>>>> resources/audiences in the request but provide an easy out for the A=
S of
>>>>>> saying it can't be supported based on whatever implementation or sec=
urity
>>>>>> or policy it has.
>>>>>>
>>>>>> On Tue, Mar 28, 2017 at 1:32 AM, Nat Sakimura 
>>>>>> wrote:
>>>>>>
>>>>>>> There are cases where tokens are supposed to be consumed at multipl=
e
>>>>>>> places and the `aud` needed to capture them. That's why `aud` is a
>>>>>>> multi-valued field.
>>>>>>>
>>>>>>> On Mon, Mar 27, 2017 at 11:35 AM Torsten Lodderstedt <
>>>>>>> torsten@lodderstedt.net> wrote:
>>>>>>>
>>>>>>>> May I ask you to explain this reason?
>>>>>>>>
>>>>>>>> Am 27.03.2017 um 08:48 schrieb Mike Jones <
>>>>>>>> Michael.Jones@microsoft.com>:
>>>>>>>>
>>>>>>>> For the same reason that the =E2=80=9Caud=E2=80=9D claim is multi-=
valued in JWTs,
>>>>>>>> the audience needs to stay multi-valued in Token Exchange.  Ditto =
for
>>>>>>>> resources.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                                                        Thanks,
>>>>>>>>
>>>>>>>>                                                        -- Mike
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *From:* OAuth [mailto:oauth-bounces@ietf.org
>>>>>>>> ] *On Behalf Of *Brian Campbell
>>>>>>>> *Sent:* Monday, March 27, 2017 8:45 AM
>>>>>>>> *To:* Torsten Lodderstedt 
>>>>>>>> *Cc:* oauth 
>>>>>>>> *Subject:* Re: [OAUTH-WG] I-D Action:
>>>>>>>> draft-ietf-oauth-token-exchange-07.txt
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks for the review and question, Torsten.
>>>>>>>>
>>>>>>>> The desire to support multiple audience/resource values in the
>>>>>>>> request came up during a review and discussion among the authors o=
f the
>>>>>>>> document when preparing the -03 draft. As I recall, it was said th=
at both
>>>>>>>> Salesforce and Microsoft had use-cases for it. I incorporated supp=
ort for
>>>>>>>> it into the draft acting in the role of editor.
>>>>>>>>
>>>>>>>> From an individual perspective, I tend to agree with you that
>>>>>>>> allowing for multiple audiences/resources adds a lot of complexity=
 that's
>>>>>>>> like not needed in many (or most) cases. And I would personally be=
 open to
>>>>>>>> making audience and resource mutual exclusive and single valued. A=
 question
>>>>>>>> for the WG I suppose.
>>>>>>>>
>>>>>>>> The "invalid_target" error code that was added in -07 was intended
>>>>>>>> to give the AS a standard way to deal with the complexity and reje=
ct
>>>>>>>> request with multiple audiences/resources that it doesn't understa=
nd or is
>>>>>>>> unwilling or unable to process. It was intended as a compromise, o=
f sorts,
>>>>>>>> to allow for the multiples but provide an easy out of saying it ca=
n't be
>>>>>>>> supported based on whatever implementation or policy of the AS.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, Mar 26, 2017 at 9:00 AM, Torsten Lodderstedt <
>>>>>>>> torsten@lodderstedt.net> wrote:
>>>>>>>>
>>>>>>>> Hi Brian,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> thanks for the clarification around resource, audience and scope.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Here are my comments on the draft:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> In section 2.1 it states: =E2=80=9EMultiple "resource" parameters =
may be
>>>>>>>> used to indicate
>>>>>>>>
>>>>>>>>       that the issued token is intended to be used at the multiple
>>>>>>>>
>>>>>>>>       resources listed.=E2=80=9C
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Can you please explain the rational in more detail? I don=E2=80=99=
t
>>>>>>>> understand why there is a need to ask for access tokens, which are=
 good for
>>>>>>>> multiple resources at once. This is a request type more or less ex=
clusively
>>>>>>>> used in server to server scenarios, right? So the only reason I ca=
n think
>>>>>>>> of is call reduction.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On the other side, this feature increases the AS's complexity, e.g=
.
>>>>>>>> its policy may prohibit to issue tokens for multiple resources in =
general
>>>>>>>> or the particular set the client is asking for. How shall the AS h=
andles
>>>>>>>> such cases?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> And it is getting even more complicated given there could also be
>>>>>>>> multiple audience values and the client could mix them:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> "Multiple "audience" parameters
>>>>>>>>
>>>>>>>>       may be used to indicate that the issued token is intended to
>>>>>>>> be
>>>>>>>>
>>>>>>>>       used at the multiple audiences listed.  The "audience" and
>>>>>>>>
>>>>>>>>       "resource" parameters may be used together to indicate
>>>>>>>> multiple
>>>>>>>>
>>>>>>>>       target services with a mix of logical names and physical
>>>>>>>>
>>>>>>>>       locations.=E2=80=9C
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> And in the end the client may add some scope values to the =E2=80=
=9Emeal=E2=80=9C,
>>>>>>>> which brings us to
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> =E2=80=9EEffectively, the requested access rights of the
>>>>>>>>
>>>>>>>>    token are the cartesian product of all the scopes at all the
>>>>>>>> target
>>>>>>>>
>>>>>>>>    services."
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I personally would suggest to drop support for multiple audience
>>>>>>>> and resource parameters and make audience and resource mutual excl=
usive. I
>>>>>>>> think this is sufficient and much easier to implement.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> kind regards,
>>>>>>>>
>>>>>>>> Torsten.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 11.01.2017 um 20:04 schrieb Brian Campbell <
>>>>>>>> bcampbell@pingidentity.com>:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Draft -07 of "OAuth 2.0 Token Exchange" has been published. The
>>>>>>>> primary change in -07 is the addition of a description of the rela=
tionship
>>>>>>>> between audience/resource/scope, which was a request or comment th=
at came
>>>>>>>> up during the f2f meeting in Seoul.
>>>>>>>>
>>>>>>>> Excerpted from the Document History:
>>>>>>>>
>>>>>>>>    -07
>>>>>>>>
>>>>>>>>    o  Fixed typo (desecration -> discretion).
>>>>>>>>    o  Added an explanation of the relationship between scope,
>>>>>>>> audience
>>>>>>>>       and resource in the request and added an "invalid_target"
>>>>>>>> error
>>>>>>>>       code enabling the AS to tell the client that the requested
>>>>>>>>       audiences/resources were too broad.
>>>>>>>>
>>>>>>>> ---------- Forwarded message ----------
>>>>>>>> From: 
>>>>>>>> Date: Wed, Jan 11, 2017 at 12:00 PM
>>>>>>>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchang
>>>>>>>> e-07.txt
>>>>>>>> To: i-d-announce@ietf.org
>>>>>>>> Cc: oauth@ietf.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>>>>>> directories.
>>>>>>>> This draft is a work item of the Web Authorization Protocol of the
>>>>>>>> IETF.
>>>>>>>>
>>>>>>>>         Title           : OAuth 2.0 Token Exchange
>>>>>>>>         Authors         : Michael B. Jones
>>>>>>>>                           Anthony Nadalin
>>>>>>>>                           Brian Campbell
>>>>>>>>                           John Bradley
>>>>>>>>                           Chuck Mortimore
>>>>>>>>         Filename        : draft-ietf-oauth-token-exchange-07.txt
>>>>>>>>         Pages           : 31
>>>>>>>>         Date            : 2017-01-11
>>>>>>>>
>>>>>>>> Abstract:
>>>>>>>>    This specification defines a protocol for an HTTP- and JSON-
>>>>>>>> based
>>>>>>>>    Security Token Service (STS) by defining how to request and
>>>>>>>> obtain
>>>>>>>>    security tokens from OAuth 2.0 authorization servers, including
>>>>>>>>    security tokens employing impersonation and delegation.
>>>>>>>>
>>>>>>>>
>>>>>>>> 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-07
>>>>>>>>
>>>>>>>> A diff from the previous version is available at:
>>>>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-token-exc
>>>>>>>> hange-07
>>>>>>>>
>>>>>>>>
>>>>>>>> Please note that it may take a couple of minutes from the time of
>>>>>>>> submission
>>>>>>>> until the htmlized version and diff are available at tools.ietf.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
>>>>>>>>
>>>>>>> ...
>>
>> [Message clipped]
>
>
>

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


Following up on this, I'd like to propose a different =
and less invasive change to the "actor_token" text. The new wordi=
ng is below and not much different than the text in the current draft. Barr=
ing any solid objections to this in the next week or so, I'll publish -=
08 at which point I believe the document will be ready for WGLC.
<=
div style=3D"margin-left:40px">
actor_token

OPTIONAL.=C2=A0 A sec=
urity token that represents the identity of the acting party. Typically thi=
s will be the party that is authorized to use the requested security token =
and act on behalf of the subject.



On Thu, May 11, 2017 at 9:58 AM, Brian Ca=
mpbell <bcampbell@pingidentity.com> wrote:
The toke=
n exchange framework facilitates deployments like this one https://help.salesforce.com/articleView?id=3Dr=
emoteaccess_oauth_asset_token_flow.htm or http=
s://developer.box.com/docs/getting-started-with-new-box-view,=
 for example, and I don't think pure plug and play interoperability is =
a realistic goal. The framework promotes interoperability in the form of co=
mmon patterns and parameters that can be supported in libraries, products, =
and services. 

There's not one "other case" I ha=
ve in mind but rather just broadening the text somewhat to more straightfor=
wardly accommodate other cases.=C2=A0 One potential example is where the ac=
tor_token represents an authorizing party (again maybe needed for policy or=
 auditing) to the token exchange
 event itself rather than the party that's having access rights assigne=
d to it (implicitly with impersonation or explicitly with delegation).
=



On Tue, May 9, 2017 a=
t 9:55 AM, Denis <denis.ietf@free.fr> wrote:

 =20
   =20
 =20
  

    
Brian,

      

      Even if Token Exchange is a framework, the goal is to be finally
      able to interoperate.

      

      Whether we have one or two parameters, would you be able to
      provide a precise semantics for the "other case" you have i=
n mind
      ?

      

      Denis

      

    

    

      

        
Yes, I omitted your comments in that post because I'd
          previously replied to you in a separate message where I said
          that the "actor_token is a security token so that's not =
an
          issue that needs to be addressed."=C2=A0 https://www.ietf.org/mail-archive/web/oauth/current/msg17247.ht=
ml

          

        

        The other point you've just made about having very precise
        semantics for a field is a fair one. However, I wanted to avoid
        introducing yet another field (or really two fields b/c of the
        associated *_type for each inbound token field), for what felt
        like a minor semantic variation that could be easily
        accommodated by the existing framework, to the draft that
        already has a lot of options and parameters on the request. And
        Token Exchange really is a framework. I think that, to some
        extent, the framework is a bit of a Rorschach test for deployers
        and implementers to utilize to solve their specific issues and
        needs. I expect that will be the case regardless. And I am
        proposing to somewhat genericize the text around one request
        parameter to be more reflective of that. 

        

        I would like to hear from others in the WG though. 

      

      


        
On Tue, May 9, 2017 at 3:06 AM, Denis <denis.ietf@free.fr>
          wrote:

          

            

              
Brian,

                

                You omitted to include my comments in this post. So here
                it is again:

                

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

                  

                  The current text is:

                  

                  actor_token OPTIONAL. A security
                    token that represents the identity of the party that
                    is authorized to use the requested security token
                    and act on behalf of the subject.

                  

                  This sentence is indeed wrong since an actor-token is
                  not a security token.

                  

                  So your proposed change does not solve this issue: actor_token=C2=A0 OPTIONAL.=C2=A0 A security
                    token that represents the identity of the acting
                    party.

                  

                  The current text states:

                
                
Typically, in the request,
                    the subject_token represents the identity of the
                    party on behalf of whom

                   the token is being requested while the
                  actor_token represents the identity of the party to
                  whom the access

                    rights of the issued token are being delegated.

                  

                 Logically, the definition should be
                  along the following lines:

                  

                  =C2=A0actor_token OPTIONAL. Indic=
ates
                    the identity of the party to whom the access rights
                    of the issued token are being delegated.

                  

                  If there is no delegation, then this field (which is
                  optional) will not be used.

                  

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

                

                I read your argumentation, but I maintain my comment.
                Each field should have a precise semantics.

                

                If you want to have another semantics, you should
                propose to define another field with its precise
                meaning.

                    

                    Denis

                    

                  

              

                

                  

                    
Let me throw out a bit more context
                      about this. The "actor_token" might, in a
                      delegation scenario, represent the identity of the
                      party to whom the access rights of the issued
                      token are being delegated. That's the typical
                      delegation scenario that is discussed in the
                      draft. However, the "actor_token" might als=
o be
                      utilized/needed by the AS in an impersonation
                      scenario for policy or auditing reasons even when
                      the resulting issued token doesn't contain info
                      about the delegation or actor. Similarly, the
                      actor might not be strictly doing the
                      impersonation but rather just be a party (again
                      maybe needed for policy or auditing) to the token
                      exchange event itself.=C2=A0 When I wrote the
                      "actor_token" text in section 2.1 some ~18 =
months
                      ago I had the delegation scenario at the front of
                      my mind and (clearly) intended to accommodate it.
                      However, I didn't intend to limit it to only that
                      and, looking at the text again, I think what is
                      there now is too prescriptive and narrow. Thus my
                      proposing to generalize the text somewhat.

                      

                      

                      

                    

                    


                      
On Mon, May 8, 2017 at
                        10:29 AM, Brian Campbell <bcampbell@pingi=
dentity.com>
                        wrote:

                        

                          

                            
I do have one minor issue I'd like to
                              raise that relates to some conversations
                              I've been a party to recently about
                              implementations and applications of token
                              exchange. 

                              

                            

                            
I think that the current text in =C2=A72.1
                              for the "actor_token" is overly spe=
cific
                              towards the delegation scenario. I'd
                              propose the language be generalized
                              somewhat to allow more versatility in
                              applications/deployments of the token
                              exchange framework. Here's that text:

                              

                              =C2=A0=C2=A0 actor_token

                              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OPTIONAL.=C2=
=A0 A security token that
                              represents the identity of the

                              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 acting party.=
=C2=A0 

                              

                              

                              

                            

                          

                          

                            

                              


                                
On Mon, May 8,
                                  2017 at 8:01 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
                                  wrote:

                                  

                                    
Hi All,
                                      


                                      

                                      
The last email from Brian
                                        addresses the multiple
                                        audiences/resources issue with
                                        an error code, and we did not
                                        see any objection to this
                                        approach so far.

                                      


                                      

                                      


                                      

                                      
Authors,

                                      


                                      

                                      
Are there any other open
                                        issues with this draft?

                                      
Do you believe it is ready
                                        for WGLC?

                                      


                                      

                                      
Thanks,

                                      
=C2=A0Rifaat & Hannes

                                      


                                      

                                      


                                      

                                    

                                    

                                      

                                        


                                          
On
                                            Fri, Mar 31, 2017 at 11:03
                                            AM, Brian Campbell <b=
campbell@pingidentity.com>
                                            wrote:

                                            

                                              
As
                                                mentioned during the
                                                Chicago meeting the
                                                "invalid_target" =
error
                                                code that was added in
                                                -07 was intended to give
                                                the AS a standard way to
                                                reject request with
                                                multiple
                                                audiences/resources that
                                                it doesn't understand o=
r
                                                is unwilling or unable
                                                to process based on
                                                policy or whatever
                                                criteria . It was
                                                intended as a
                                                compromise, of sorts, to
                                                allow for the multiple
                                                resources/audiences in
                                                the request but provide
                                                an easy out for the AS
                                                of saying it can't be
                                                supported based on
                                                whatever implementation
                                                or security or policy it
                                                has. 

                                              

                                                

                                                  


                                                    
On
                                                      Tue, Mar 28, 2017
                                                      at 1:32 AM, Nat
                                                      Sakimura <sakimura@=
gmail.com>
                                                      wrote:

                                                      

                                                        
Th=
ere
                                                          are cases
                                                          where tokens
                                                          are supposed
                                                          to be consumed
                                                          at multiple
                                                          places and the
                                                          `aud` needed
                                                          to capture
                                                          them. That's
                                                          why `aud` is a
                                                          multi-valued
                                                          field.=C2=A0
                                                        

                                                          


                                                          

                                                          
=
On
                                                          Mon, Mar 27,
                                                          2017 at 11:35
                                                          AM Torsten
                                                          Lodderstedt
                                                          <torsten@lodderstedt.net=
>
                                                          wrote:

                                                          

                                                          

                                                          
Ma=
y
                                                          I ask you to
                                                          explain this
                                                          reason?

                                                          

                                                          


                                                          

                                                          

                                                          
Am
                                                          27.03.2017 um
                                                          08:48 schrieb
                                                          Mike Jones
                                                          <Michael.Jones@microsoft.com>:

                                                          

                                                          

                                                          

                                                          

                                                          
For
                                                          the same
                                                          reason that
                                                          the =E2=80=9Caud=
=E2=80=9D
                                                          claim is
                                                          multi-valued
                                                          in JWTs, the
                                                          audience needs
                                                          to stay
                                                          multi-valued
                                                          in Token
                                                          Exchange.=C2=A0
                                                          Ditto for
                                                          resources.=


                                                          
=C2=A0

                                                          
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0
                                                          Thanks,
                                                          
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=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 Bri=
an
                                                          Campbell

                                                          Sent:
                                                          Monday, March
                                                          27, 2017 8:45
                                                          AM

                                                          To:
                                                          Torsten
                                                          Lodderstedt
                                                          <torsten@lodderstedt.net>

                                                          Cc:
                                                          oauth <oauth@ietf.org>

                                                          Subject:
                                                          Re: [OAUTH-WG]
                                                          I-D Action:
                                                          draft-ietf-oauth-=
token-exchange-07.txt

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          
Thanks for the review and question,
                                                          Torsten. 

                                                          

                                                          
The desire to support multiple
                                                          audience/resource
                                                          values in the
                                                          request came
                                                          up during a
                                                          review and
                                                          discussion
                                                          among the
                                                          authors of the
                                                          document when
                                                          preparing the
                                                          -03 draft. As
                                                          I recall, it
                                                          was said that
                                                          both
                                                          Salesforce and
                                                          Microsoft had
                                                          use-cases for
                                                          it. I
                                                          incorporated
                                                          support for it
                                                          into the draft
                                                          acting in the
                                                          role of
                                                          editor.

                                                          

                                                          

                                                          
From an individual perspective, I tend to
                                                          agree with you
                                                          that allowing
                                                          for multiple
                                                          audiences/resourc=
es
                                                          adds a lot of
                                                          complexity
                                                          that's like
                                                          not needed in
                                                          many (or most)
                                                          cases. And I
                                                          would
                                                          personally be
                                                          open to making
                                                          audience and
                                                          resource
                                                          mutual
                                                          exclusive and
                                                          single valued.
                                                          A question for
                                                          the WG I
                                                          suppose.

                                                          

                                                          

                                                          
The
"invalid_target" error code that was added in -07 was intended to=
 give
                                                          the AS a
                                                          standard way
                                                          to deal with
                                                          the complexity
                                                          and reject
                                                          request with
                                                          multiple
                                                          audiences/resourc=
es
                                                          that it
                                                          doesn't
                                                          understand or
                                                          is unwilling
                                                          or unable to
                                                          process. It
                                                          was intended
                                                          as a
                                                          compromise, of
                                                          sorts, to
                                                          allow for the
                                                          multiples but
                                                          provide an
                                                          easy out of
                                                          saying it
                                                          can't be
                                                          supported
                                                          based on
                                                          whatever
                                                          implementation
                                                          or policy of
                                                          the AS. 

                                                          

                                                          

                                                          
=C2=A0
                                                          

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          
On
                                                          Sun, Mar 26,
                                                          2017 at 9:00
                                                          AM, Torsten
                                                          Lodderstedt
                                                          <torsten@lodderstedt.net> wrote:

                                                          

                                                          

                                                          
Hi
                                                          Brian,

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
thanks
                                                          for the
                                                          clarification
                                                          around
                                                          resource,
                                                          audience and
                                                          scope.=C2=A0

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          
Here
                                                          are my
                                                          comments on
                                                          the draft:

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
In
                                                          section 2.1 it
                                                          states:
                                                          =E2=80=9EMultiple
                                                          "resource&qu=
ot;
                                                          parameters may
                                                          be used to
                                                          indicate

                                                          

                                                          

                                                          
=C2=A0
                                                          =C2=A0 =C2=A0 tha=
t the
                                                          issued token
                                                          is intended to
                                                          be used at the
                                                          multiple

                                                          

                                                          

                                                          
=C2=A0
                                                          =C2=A0 =C2=A0 res=
ources
                                                          listed.=E2=80=9C<=
/p>
                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
Can
                                                          you please
                                                          explain the
                                                          rational in
                                                          more detail? I
                                                          don=E2=80=99t
                                                          understand why
                                                          there is a
                                                          need to ask
                                                          for access
                                                          tokens, which
                                                          are good for
                                                          multiple
                                                          resources at
                                                          once. This is
                                                          a request type
                                                          more or less
                                                          exclusively
                                                          used in server
                                                          to server
                                                          scenarios,
                                                          right? So the
                                                          only reason I
                                                          can think of
                                                          is call
                                                          reduction.=C2=A0<=
/p>
                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
On
                                                          the other
                                                          side, this
                                                          feature
                                                          increases the
                                                          AS's
                                                          complexity,
                                                          e.g. its
                                                          policy may
                                                          prohibit to
                                                          issue tokens
                                                          for multiple
                                                          resources in
                                                          general or the
                                                          particular set
                                                          the client is
                                                          asking for.
                                                          How shall the
                                                          AS handles
                                                          such cases?

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
And
                                                          it is getting
                                                          even more
                                                          complicated
                                                          given there
                                                          could also be
                                                          multiple
                                                          audience
                                                          values and the
                                                          client could
                                                          mix them:=C2=A0
                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
"Multiple
                                                          "audience&qu=
ot;
                                                          parameters

                                                          

                                                          

                                                          
=C2=A0
                                                          =C2=A0 =C2=A0 may=
 be
                                                          used to
                                                          indicate that
                                                          the issued
                                                          token is
                                                          intended to be
                                                          

                                                          

                                                          
=C2=A0
                                                          =C2=A0 =C2=A0 use=
d at
                                                          the multiple
                                                          audiences
                                                          listed.=C2=A0 The
                                                          "audience&qu=
ot; and

                                                          

                                                          

                                                          
=C2=A0
                                                          =C2=A0 =C2=A0 &qu=
ot;resource"
                                                          parameters may
                                                          be used
                                                          together to
                                                          indicate
                                                          multiple

                                                          

                                                          

                                                          
=C2=A0
                                                          =C2=A0 =C2=A0 tar=
get
                                                          services with
                                                          a mix of
                                                          logical names
                                                          and physical

                                                          

                                                          

                                                          
=C2=A0
                                                          =C2=A0 =C2=A0
                                                          locations.=E2=80=
=9C

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
And
                                                          in the end the
                                                          client may add
                                                          some scope
                                                          values to the
                                                          =E2=80=9Emeal=E2=
=80=9C, which
                                                          brings us to=C2=
=A0

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
=E2=80=9EEffectively,
                                                          the requested
                                                          access rights
                                                          of the

                                                          

                                                          

                                                          
=C2=A0
                                                          =C2=A0token are t=
he
                                                          cartesian
                                                          product of all
                                                          the scopes at
                                                          all the target
                                                          

                                                          

                                                          
=C2=A0
                                                          =C2=A0services.&q=
uot;

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
I
                                                          personally
                                                          would suggest
                                                          to drop
                                                          support for
                                                          multiple
                                                          audience and
                                                          resource
                                                          parameters and
                                                          make audience
                                                          and resource
                                                          mutual
                                                          exclusive. I
                                                          think this is
                                                          sufficient and
                                                          much easier to
                                                          implement.

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
kind
                                                          regards,

                                                          

                                                          

                                                          
Torsten.

                                                          

                                                          

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          
Am
                                                          11.01.2017 um
                                                          20:04 schrieb
                                                          Brian Campbell
                                                          <bcampbell@pingidentity.com>:

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
Draft -07 of "OAuth 2.0 
                                                          Token Exchange"
                                                          has been
                                                          published. The
                                                          primary change
                                                          in -07 is the
                                                          addition of a
                                                          description of
                                                          the
                                                          relationship
                                                          between
                                                          audience/resource=
/scope,
                                                          which was a
                                                          request or
                                                          comment that
                                                          came up during
                                                          the f2f
                                                          meeting in
                                                          Seoul. 

                                                          

                                                          Excerpted from
                                                          the Document
                                                          History:

                                                          

                                                          =C2=A0=C2=A0 -07<=
br class=3D"gmail-m_-6853265654903375744m_-5500081355606695985m_86844077485=
54078058m_6905276776273010841m_4803735329627533709m_-2675142197049852080m_3=
983298834558915277m_-4354184635220679769gmail_msg">
                                                          

                                                          =C2=A0=C2=A0 o=C2=
=A0 Fixed
                                                          typo
                                                          (desecration
                                                          ->
                                                          discretion).

                                                          =C2=A0=C2=A0 o=C2=
=A0 Added an
                                                          explanation of
                                                          the
                                                          relationship
                                                          between scope,
                                                          audience

                                                          =C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 and
                                                          resource in
                                                          the request
                                                          and added an
                                                          "invalid_tar=
get"
                                                          error

                                                          =C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 code
                                                          enabling the
                                                          AS to tell the
                                                          client that
                                                          the requested

                                                          =C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0
                                                          audiences/resourc=
es
                                                          were too
                                                          broad.

                                                          

                                                          

                                                          

                                                          
----------
                                                          Forwarded
                                                          message
                                                          ----------

                                                          From: <internet-drafts@ietf.org>

                                                          Date: Wed, Jan
                                                          11, 2017 at
                                                          12:00 PM

                                                          Subject:
                                                          [OAUTH-WG] I-D
                                                          Action:
                                                          draft-ietf-oauth-=
token-exchange-07.txt

                                                          To: i-d-announce@ietf.org

                                                          Cc: oauth@ietf.org

                                                          

                                                          

                                                          

                                                          A New
                                                          Internet-Draft
                                                          is available
                                                          from the
                                                          on-line
                                                          Internet-Drafts
                                                          directories.

                                                          This draft is
                                                          a work item of
                                                          the Web
                                                          Authorization
                                                          Protocol of
                                                          the IETF.

                                                          

                                                          =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Title=C2=A0
                                                          =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0:
                                                          OAuth 2.0
                                                          Token Exchange
                                                          =C2=A0 =C2=A0 =C2=
=A0 =C2=A0
                                                          Authors=C2=A0 =C2=
=A0 =C2=A0 =C2=A0
                                                          =C2=A0: Michael B=
.
                                                          Jones

                                                          =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                          =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0
                                                          Anthony
                                                          Nadalin

                                                          =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                                          =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0
                                                          Brian Campbell
                                                          =C2=A0 =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
                                                          Chuck
                                                          Mortimore

                                                          =C2=A0 =C2=A0 =C2=
=A0 =C2=A0
                                                          Filename=C2=A0 =
=C2=A0 =C2=A0
                                                          =C2=A0 :
                                                          draft-ietf-oauth-=
token-exchange-07.txt

                                                          =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Pages=C2=A0
                                                          =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0: 31

                                                          =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Date=C2=A0
                                                          =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 :
                                                          2017-01-11

                                                          

                                                          Abstract:

                                                          =C2=A0 =C2=A0This
                                                          specification
                                                          defines a
                                                          protocol for
                                                          an HTTP- and
                                                          JSON- based

                                                          =C2=A0 =C2=A0Secu=
rity
                                                          Token Service
                                                          (STS) by
                                                          defining how
                                                          to request and
                                                          obtain

                                                          =C2=A0 =C2=A0secu=
rity
                                                          tokens from
                                                          OAuth 2.0
                                                          authorization
                                                          servers,
                                                          including

                                                          =C2=A0 =C2=A0secu=
rity
                                                          tokens
                                                          employing
                                                          impersonation
                                                          and
                                                          delegation.

                                                          

                                                          

                                                          The IETF
                                                          datatracker
                                                          status page
                                                          for this draft
                                                          is:

                                                          https://datatracker.iet=
f.org/doc/draft-ietf-oauth-token-exchange/

                                                          

                                                          There's also =
a
                                                          htmlized
                                                          version
                                                          available at:

                                                          https://tools.ietf.org/htm=
l/draft-ietf-oauth-token-exchange-07

                                                          

                                                          A diff from
                                                          the previous
                                                          version is
                                                          available at:

                                                          https://www.ietf.o=
rg/rfcdiff?url2=3Ddraft-ietf-oauth-token-exchange-07

                                                          

                                                          

                                                          Please note
                                                          that it may
                                                          take a couple
                                                          of minutes
                                                          from the time
                                                          of submission

                                                          until the
                                                          htmlized
                                                          version and
                                                          diff are
                                                          available at  tools.ietf.org.

                                                          

Internet-Drafts are also available by anonymous FTP at:

                                                          ftp://ftp.ietf.org/internet-drafts/

                                                          

_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

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

                                                          

                                                          
=C2=A0

                                                          

                                                          
_________________________=
______________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

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

                                                          

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

                                                          https://www.ietf.org/mailm=
an/listinfo/oauth

                                                          

                                   
...

[=
Message clipped]=C2=A0=C2=A0






--94eb2c03aa6686d2a8055074c3ff--


From nobody Mon May 29 00:12:04 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF501293D9 for ; Mon, 29 May 2017 00:12:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.098
X-Spam-Level: 
X-Spam-Status: No, score=0.098 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzyeXfy5Esfs for ; Mon, 29 May 2017 00:11:59 -0700 (PDT)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.32]) (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 971321200F1 for ; Mon, 29 May 2017 00:11:59 -0700 (PDT)
Received: from [87.143.165.151] (helo=[192.168.71.161]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1dFEqL-0000by-4K for oauth@ietf.org; Mon, 29 May 2017 09:11:57 +0200
From: Torsten Lodderstedt 
Content-Type: multipart/signed; boundary="Apple-Mail=_6B137AD5-F6BB-4C2D-8E7E-F51C4E6EB1D0"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: 
Date: Mon, 29 May 2017 09:11:56 +0200
To: oauth 
X-Mailer: Apple Mail (2.3273)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: [OAUTH-WG] Call for Participation: Second OAuth Security Workshop
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 May 2017 07:12:02 -0000

--Apple-Mail=_6B137AD5-F6BB-4C2D-8E7E-F51C4E6EB1D0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

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

C a l l     F o r     P a r t i c i p a t i o n

Second OAuth Security Workshop (OSW 2017)

Zurich, Switzerland -- July 10-11, 2017

Registration: https://zisc.ethz.ch/event/oauth-security-workshop-2017/

Early Registration Deadline: June 16, 2017

WWW: https://zisc.ethz.ch/oauth-security-workshop-2017/

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

Overview

The OAuth Security Workshop (OSW) focuses on improving security of the
OAuth standard and related Internet protocols. This workshop brings
together the IETF OAuth Working Group and security experts from
research, industry, and standardization to this end. The workshop is
hosted by the Zurich Information Security and Privacy Center at ETH =
Zurich.

While the standardization process of OAuth ensures extensive reviews
(both security and non-security related), further analysis by security
experts from academia and industry is essential to ensure high quality
specifications. Contributions to this workshop can help to improve the
security of the Web and the Internet.


Schedule: https://zisc.ethz.ch/oauth-security-workshop-2017/


Important Dates

Registration deadline: June 16, 2017.
Workshop: July 10 and July 11, 2017.


Invited Speakers

Cas Cremers, University of Oxford


Program Committee

Chairs
David Basin (ETH Zurich)
Torsten Lodderstedt (YES Europe)

Members
John Bradley (Ping Identity)
Ralf K=C3=BCsters (University of Stuttgart)
Chris Mitchell (Royal Holloway University of London)
Anthony Nadalin (Microsoft)
Nat Sakimura (Nomura Research Institute)
Ralf Sasse (ETH Zurich)
J=C3=B6rg Schwenk (Ruhr University Bochum)
Hannes Tschofenig (IETF OAuth Working Group Co-Chair)



--Apple-Mail=_6B137AD5-F6BB-4C2D-8E7E-F51C4E6EB1D0
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ/DCCBK8w
ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF
MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l
dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw
WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl
c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV
BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls
IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW
51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD
FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI
kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az
aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA
P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD
VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG
AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw
RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu
YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl
cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm
am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7
BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl
nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK
2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7
mzCCBUUwggQtoAMCAQICEDPbmsaqwjeZa3PxA3uZ8LQwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV
BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY
BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg
QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNzAxMDkwMDAwMDBaFw0xODAx
MDkyMzU5NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArsGSzZyz9Lq9SRW9Sve5K8n5lWhplOCE6HH3gMye
12DjOpkFFZt0b73t27G17Xsp6WUxHhNevf7ck0AUpvYUPCHBqVGJSIWF9hWAoSFCgQACOoh/cDFb
zz1PsMY8El7OmIus4JXtY4/VdoSIhFP3hzATbNAg32Kp+N8vtTuKTwbgnizJSyzZTYrsttn3LmwY
17HU+U9vXloMus5U/ln4ADZx0zyyDSsA6gtPxXYJpbgSTnHckVZ5zfR80guIZ538Y2qqsqt5VaSR
SR2oQzE/HETkKc/odPVhqBrXLyvnSFkCPrAXV07rcvwkPvHZeYVu4QdVWyO2HIQ4i2x9r5m7SwID
AQABo4IB9TCCAfEwHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFPng
HgVxOZ7GSji/IW4YJMBj02PHMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZ
MBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7
BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9D
UFMwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2
Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMw
gYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVu
dEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9v
Y3NwLmNvbW9kb2NhLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkq
hkiG9w0BAQsFAAOCAQEAAmueyHjiyL1qYgfe+hVSsGuKlgcvjCAfG8Jaq48tC0IjP8pH/tGi4uL9
CHVfLnV3pLDnjg6M2uvpEBp7crZZcnSPLeVss+tkhwv+F7ISYQyT4flNkqVUb8nfewbCPcIN13Ob
fpU7rlXoIarEEplQo4SuymYVluQxTLOFKm5QOMF4JBMw/rjy4t95J7Mdp9NFUzQrKPJDaJ2Jr/Tc
TXFcjLvNVmMBjK0959a9v1/1miRHd1DBsTh1KvBigEOUNMxvT5uUtB6/tioDZqBDDk8Gvdno/xmy
e3YiasS7JgMREq5WcXqpWGu5kMFZMGPEvyPHeBZeqxx3amf4ImVnZ6WvgzGCA8MwggO/AgEBMIGw
MIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT
YWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0y
NTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDPbmsaqwjeZa3Px
A3uZ8LQwCQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMTcwNTI5MDcxMTU2WjAjBgkqhkiG9w0BCQQxFgQUi+eUUgmJK51QvpPkwbbZGDOxWL8w
gcEGCSsGAQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/
BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt
YWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBB
dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqG
SIb3DQEBAQUABIIBAHvdBiB9H8QwehubDi8MwyscgIq1e3WiLDhbhTGO2pfDd0ZD800dTiH686+V
VcsPuniQgbIAx80EZ4YnNpncnjG+gz6b3rQjZZUJ6QkUFf/N0ZgPBtu4HR93BA2ngdEA8OHAQZYO
CkIb4D49yzG1KI1Q6hlf5AzbPNfBfTwFXvUBemRoGcfzFWdeAN69HlmrWO96tq5nTOlagz7e5Rj4
gOI/wwBN1PhFiL6HITJZyyznO+Mu7uJ7SEziNLxYujyxSBVflPo+BsZbYU0Op0R0zc7YaEjnsVeS
oNtDa0vv6i8a2cMjMuXyllVtoSrFaC4ZmQPGAqc9tl+641TqTWRJhDsAAAAAAAA=
--Apple-Mail=_6B137AD5-F6BB-4C2D-8E7E-F51C4E6EB1D0--


From nobody Mon May 29 04:57:31 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 225C6129541 for ; Mon, 29 May 2017 04:57:28 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWKVVbUWQbGh for ; Mon, 29 May 2017 04:57:25 -0700 (PDT)
Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [134.119.228.106]) (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 687CF12953B for ; Mon, 29 May 2017 04:57:25 -0700 (PDT)
Received: from [80.187.101.46] (helo=[10.22.102.12]) by smtprelay08.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1dFJIY-0001bB-D4 for oauth@ietf.org; Mon, 29 May 2017 13:57:22 +0200
Content-Transfer-Encoding: 7bit
Content-Type: multipart/signed; boundary=Apple-Mail-9F4E42F5-876E-456B-BB9A-5AB4CC556F60; protocol="application/pkcs7-signature"; micalg=sha1
From: Torsten Lodderstedt 
Mime-Version: 1.0 (1.0)
Date: Mon, 29 May 2017 13:57:21 +0200
Message-Id: <2A1DBE5A-E492-4838-AF34-6B5A80F740E8@lodderstedt.net>
References: 
In-Reply-To: 
To: oauth 
X-Mailer: iPhone Mail (14F89)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] Call for Participation: Second OAuth Security Workshop
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 May 2017 11:57:28 -0000

--Apple-Mail-9F4E42F5-876E-456B-BB9A-5AB4CC556F60
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Correction: the workshop takes place July 13-14

> Am 29.05.2017 um 09:11 schrieb Torsten Lodderstedt :
>=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
>=20
> C a l l     F o r     P a r t i c i p a t i o n
>=20
> Second OAuth Security Workshop (OSW 2017)
>=20
> Zurich, Switzerland -- July 10-11, 2017
>=20
> Registration: https://zisc.ethz.ch/event/oauth-security-workshop-2017/
>=20
> Early Registration Deadline: June 16, 2017
>=20
> WWW: https://zisc.ethz.ch/oauth-security-workshop-2017/
>=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
>=20
> Overview
>=20
> The OAuth Security Workshop (OSW) focuses on improving security of the
> OAuth standard and related Internet protocols. This workshop brings
> together the IETF OAuth Working Group and security experts from
> research, industry, and standardization to this end. The workshop is
> hosted by the Zurich Information Security and Privacy Center at ETH Zurich=
.
>=20
> While the standardization process of OAuth ensures extensive reviews
> (both security and non-security related), further analysis by security
> experts from academia and industry is essential to ensure high quality
> specifications. Contributions to this workshop can help to improve the
> security of the Web and the Internet.
>=20
>=20
> Schedule: https://zisc.ethz.ch/oauth-security-workshop-2017/
>=20
>=20
> Important Dates
>=20
> Registration deadline: June 16, 2017.
> Workshop: July 10 and July 11, 2017.
>=20
>=20
> Invited Speakers
>=20
> Cas Cremers, University of Oxford
>=20
>=20
> Program Committee
>=20
> Chairs
> David Basin (ETH Zurich)
> Torsten Lodderstedt (YES Europe)
>=20
> Members
> John Bradley (Ping Identity)
> Ralf K=C3=BCsters (University of Stuttgart)
> Chris Mitchell (Royal Holloway University of London)
> Anthony Nadalin (Microsoft)
> Nat Sakimura (Nomura Research Institute)
> Ralf Sasse (ETH Zurich)
> J=C3=B6rg Schwenk (Ruhr University Bochum)
> Hannes Tschofenig (IETF OAuth Working Group Co-Chair)
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-9F4E42F5-876E-456B-BB9A-5AB4CC556F60
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSTCCBUUw
ggQtoAMCAQICEDPbmsaqwjeZa3PxA3uZ8LQwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNVBAYTAkdC
MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT
EUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNzAxMDkwMDAwMDBaFw0xODAxMDkyMzU5
NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEArsGSzZyz9Lq9SRW9Sve5K8n5lWhplOCE6HH3gMye12DjOpkF
FZt0b73t27G17Xsp6WUxHhNevf7ck0AUpvYUPCHBqVGJSIWF9hWAoSFCgQACOoh/cDFbzz1PsMY8
El7OmIus4JXtY4/VdoSIhFP3hzATbNAg32Kp+N8vtTuKTwbgnizJSyzZTYrsttn3LmwY17HU+U9v
XloMus5U/ln4ADZx0zyyDSsA6gtPxXYJpbgSTnHckVZ5zfR80guIZ538Y2qqsqt5VaSRSR2oQzE/
HETkKc/odPVhqBrXLyvnSFkCPrAXV07rcvwkPvHZeYVu4QdVWyO2HIQ4i2x9r5m7SwIDAQABo4IB
9TCCAfEwHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFPngHgVxOZ7G
Sji/IW4YJMBj02PHMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG
AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEE
AbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwXQYD
VR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50
QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAwWAYI
KwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhl
bnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNv
bW9kb2NhLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0B
AQsFAAOCAQEAAmueyHjiyL1qYgfe+hVSsGuKlgcvjCAfG8Jaq48tC0IjP8pH/tGi4uL9CHVfLnV3
pLDnjg6M2uvpEBp7crZZcnSPLeVss+tkhwv+F7ISYQyT4flNkqVUb8nfewbCPcIN13ObfpU7rlXo
IarEEplQo4SuymYVluQxTLOFKm5QOMF4JBMw/rjy4t95J7Mdp9NFUzQrKPJDaJ2Jr/TcTXFcjLvN
VmMBjK0959a9v1/1miRHd1DBsTh1KvBigEOUNMxvT5uUtB6/tioDZqBDDk8Gvdno/xmye3YiasS7
JgMREq5WcXqpWGu5kMFZMGPEvyPHeBZeqxx3amf4ImVnZ6WvgzGCA8MwggO/AgEBMIGwMIGbMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp
ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDPbmsaqwjeZa3PxA3uZ8LQw
CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN
MTcwNTI5MTE1NzIxWjAjBgkqhkiG9w0BCQQxFgQUTDDF/G8xJxSpHrrKbNpTLKOuz54wgcEGCSsG
AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl
cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT
OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB
AhAz25rGqsI3mWtz8QN7mfC0MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50
aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEB
AQUABIIBABZFeBU/ZfEPJLVvEqpIRooqF1nGsbVIqp1axnzBS7hoowpBQZ82WT0Z3q/CuE9+cK7m
7PGLcqZlGdSNZgjFc8cymzmlFrz8T4KQyXbz3x2w/NB3AXxI8tQWDQrtW23yua/GgMTM4A+f6DWC
gcGfIXR2u316NgLQy1ZAeKHq5Zg76pgBKqDOtR/vvFIiIQfwEKJ8tcnaqodSmAwcX7K/CPd1G+r1
t7dxODbW9BlkD6qTzAolqAk8FxDcZsdPXXDEjmjCr36nPRQTwrdje7QZEdesrk8Hbaut1sRcsm7M
W9qFVtTFte1t33LQzALTM6GK285IZ9wToSvKlsLPYb7bn8MAAAAAAAA=

--Apple-Mail-9F4E42F5-876E-456B-BB9A-5AB4CC556F60--


From nobody Wed May 31 03:01:44 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E5E12704B for ; Wed, 31 May 2017 03:01:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Level: 
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrZ-kkEqir53 for ; Wed, 31 May 2017 03:01:40 -0700 (PDT)
Received: from SMTPGATE02.enterexchange.com (smtpgate02.enterexchange.com [109.205.196.241]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 956F3127010 for ; Wed, 31 May 2017 03:01:39 -0700 (PDT)
From: Jaap Francke 
To: "oauth@ietf.org" 
Thread-Topic: token revocation from a different client
Thread-Index: AQHS2fTk4vZSN1onGEKgAd94bEGeYQ==
Date: Wed, 31 May 2017 10:01:36 +0000
Message-ID: <612B4B7C-CE5B-4790-B4EA-0953885BB560@iwelcome.com>
Accept-Language: nl-NL, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.17.5.138]
Content-Type: multipart/signed; boundary="Apple-Mail=_46E6ED3B-556D-4CF7-97D3-E122A35BC8AA"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Archived-At: 
Subject: [OAUTH-WG] token revocation from a different client
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 May 2017 10:01:43 -0000

--Apple-Mail=_46E6ED3B-556D-4CF7-97D3-E122A35BC8AA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi all,

It=E2=80=99s only since recently that I=E2=80=99m sticking my nose =
deeper into the various OAUTH (draft) specifications.
I also recently joined this mailing list.
I have a question and I hope someone can help me.

I=E2=80=99ve been looking for a mechanism/endpoint/specification for =
token revocation.

RFC7009 is aimed at token revocation by the client itself - logoff is =
the typical use case.
What I=E2=80=99m looking for is a possibility for the enduser (resource =
owner) to revoke one of his tokens from a different client.

Use cases for this would be:
- suspection that password is compromised, so enduser wants to change =
his password and terminate all sessions on any device. For such devices =
to regain access, they would need the new password.
- stolen/lost device; the enduser should be able to revoke specific =
access/refresh-tokesn that have been issued for the stolen/lost device.

Any thoughts on this?=20

Thanks in advance,

Jaap Francke
Product Manager iWelcome=

--Apple-Mail=_46E6ED3B-556D-4CF7-97D3-E122A35BC8AA
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII2jCCBBYw
ggL+oAMCAQICCwQAAAAAAS9O4SzhMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYD
VQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxT
aWduIFJvb3QgQ0EwHhcNMTEwNDEzMTAwMDAwWhcNMTkwNDEzMTAwMDAwWjBUMQswCQYDVQQGEwJC
RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25h
bFNpZ24gMSBDQSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8aUcr5BvPNGj
x0+LH0uRqeZCHrYQ7KN3QuahfxY8fAzAbnvNDzGdEMyKn3+YX+k/QbAGNJOSFRxrAfhviF7WGcqD
lin3HracDqMRgwrknWuFeqxhN2J7uXs3Y0zluJEkEittRXv+ZdXOG/Gp3gtoz5P9noc5jBbfWQpQ
BhcaJA2ucABbUVTHDTxi7dBY8mTWq6kRAkGWBybHwq0YX+jaHudtQw0oBEmxjpJFP9qIXu0ckU/+
OhtnAhrgzrsd4oAyqgc6u4dBYERcjDJFohihjbzPozgKDSSbdr44uO3p9Bg6ibjCxn2besLrIE7u
poxvV09Fsf7hDeD/jcvs64z8pQIDAQABo4HlMIHiMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8E
CDAGAQH/AgEAMB0GA1UdDgQWBBTsrJjMJ3KTz1YyzSPHnY1FhfQiAzBHBgNVHSAEQDA+MDwGBFUd
IAAwNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8w
MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LmNybDAfBgNV
HSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUFAAOCAQEAr7unyEtmt9Ia
7hmNpqP+xMd0t5hLM0QBY8G3Dlg70XI6F+ZeSZeeXgCtUT/JhdQ+HsJ8+c6HypDuvg/OZ0gILDFI
a9LDfRWm+tHIgxKaJjtCy0izg838dLwwnt/O3kA9N/htEYev2lsmWYCV9cVUm5V1tW3XuYNg6Sbt
cDRH+Ki1RED9es3R0BgHSm012KPxsiAOOxuhm1D3Iqs1qe6ms5WTKXVgwb/j/kplOa13nshhc8zU
LVO+oAlD4+7czNK2RJiTvhJiDJDRTZy3DJ3BCQ8rXOGdWzDEI5uiB8TZ0s327g44Ylc6dgKgYelN
n9RLYjNETX8OIJZlr0tFYpcYrDCCBLwwggOkoAMCAQICEGZgT+TGYtW+XJFIfF7kzN4wDQYJKoZI
hvcNAQEFBQAwVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNV
BAMTIUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIDEgQ0EgLSBHMjAeFw0xNDA5MTcxNDA1MDhaFw0x
NzA5MTcxNDA1MDhaME4xIjAgBgNVBAMMGWphYXAuZnJhbmNrZUBpd2VsY29tZS5jb20xKDAmBgkq
hkiG9w0BCQEWGWphYXAuZnJhbmNrZUBpd2VsY29tZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IB
DwAwggEKAoIBAQDNj5bPYUJuRw/IlkkEGXMYuw052nhg4k8VsXbciMDvmmHAJXO3Lsv7oBxmc7n3
WSgU+dzYG/abcpQCv2UGHmXpYoSKqE85LABAZCdQYR9ZdGf9tcqasRcK8L6fY081WpggyRqTbBaa
4UnvwCYp7/kiQtRCn8uvyqWQ7KS2HxzGTBZTOrIBbKKMKHnBHO3V7QyFAwohbbXJKqpAkWpkrgSf
lQz7F+D59oH54LtNTPndLUmmf9L42sk/2rxdxdmvv7vOwW+FaZ4HTFQ2nmkNtxIZiZ2g3I9sI5c/
5PEIrkrk+6gVxpMBFQ/JylAs9b3eOrI1irFlxUrogQ3QMPN3sPItAgMBAAGjggGOMIIBijAOBgNV
HQ8BAf8EBAMCBaAwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYmaHR0cHM6
Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wJAYDVR0RBB0wG4EZamFhcC5mcmFuY2tl
QGl3ZWxjb21lLmNvbTAJBgNVHRMEAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBD
BgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2dzL2dzcGVyc29uYWxz
aWduMWcyLmNybDBVBggrBgEFBQcBAQRJMEcwRQYIKwYBBQUHMAKGOWh0dHA6Ly9zZWN1cmUuZ2xv
YmFsc2lnbi5jb20vY2FjZXJ0L2dzcGVyc29uYWxzaWduMWcyLmNydDAdBgNVHQ4EFgQUo+Cg1aMR
RyWYQtZ4YC0dSowEVfcwHwYDVR0jBBgwFoAU7KyYzCdyk89WMs0jx52NRYX0IgMwDQYJKoZIhvcN
AQEFBQADggEBABND+GJQ4zWHXfQeWv2840Yjl7q8BB+L7+G5I0HiorvbsvYSbx9nPNvCOKrLxUrA
PXPavuA+D2gf2gBT1G5hZ5X8cYq6SR056wCQsmgHO+BQKxmCxig+4RHbNGS34w/Jv5lI8kplC8kW
4wvmpXyVf45k8tU9aPkb1gnQCUC134CkWy/5/XsHZO9T3Qp/43jEDIcfOG3ebIij8mCthOLDe4jR
7NaJEjn8Iec6dlrR+jL6tyzWOBb7ZBnKr+JdfDYxm6Wd/XbcW5PNSwNEuv5i3FLHXkoRAk2BPwN2
dCP+L8v3HAZ1gV5syDscRLSKlEjIeANPc+dLnW7nAvVewZF9cjcxggLkMIIC4AIBATBoMFQxCzAJ
BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWdu
IFBlcnNvbmFsU2lnbiAxIENBIC0gRzICEGZgT+TGYtW+XJFIfF7kzN4wCQYFKw4DAhoFAKCCAVEw
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNTMxMTAwMTM3WjAj
BgkqhkiG9w0BCQQxFgQUPaGDjE3paEZ+qih4iPhHYh4w6XQwdwYJKwYBBAGCNxAEMWowaDBUMQsw
CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2ln
biBQZXJzb25hbFNpZ24gMSBDQSAtIEcyAhBmYE/kxmLVvlyRSHxe5MzeMHkGCyqGSIb3DQEJEAIL
MWqgaDBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMh
R2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyAhBmYE/kxmLVvlyRSHxe5MzeMA0GCSqG
SIb3DQEBAQUABIIBAIwevlyF4M/ASI+s+PHcFXVIZXdaLSzUm9dBZC9lZ9F57sUcpgNnsnZyCWF0
mSwej0IBxK6VPSJBw4iPRssEZ3FgJeYKvCLlblEHvuL/jiS1UoXeHfexonq6HtIlQjvpG59EstNg
67qlkQNIvOJfAR/xpuT0t5OYfm8bX5X9asOSPOKX9GpETnDgCbedgpZliDJBHkRgmHOk0zSNlFU5
fWCurHbONRigAb3esFQFDrC/rA5iAvFInlI5pFFYL5lQ0Rw/w7ZAYVd2B/h/VMxd3xbVa8V8Oydj
3LFCfPOqTRB6iL9FFoQwiYsnNePyg2xjDFA41xsM8eI45iGcmZ8CcV8AAAAAAAA=

--Apple-Mail=_46E6ED3B-556D-4CF7-97D3-E122A35BC8AA--


From nobody Wed May 31 05:57:44 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E333128B37 for ; Wed, 31 May 2017 05:57:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Umekq9sXUF4z for ; Wed, 31 May 2017 05:57:42 -0700 (PDT)
Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16AB81289B0 for ; Wed, 31 May 2017 05:57:42 -0700 (PDT)
Received: by mail-ua0-x229.google.com with SMTP id y4so8655135uay.2 for ; Wed, 31 May 2017 05:57:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=D/uek+cJJoAI+fTdbeuh3zt3NrJYOLUBMLm/MVFPZDA=; b=LJmXD13KqcjMlmk4rF9AmE/wKgnabY4cjN6ueRVbS5QdcC2eUswmJ7kjl3wv6NIuNU r515vXj/GkNbCT7JG6wn7HHswRW788dYAW4gBoAk+eCrVvKphcWB4Vn5Wd+RpoLkvaGg OkYUG/qJ9HEl3qiuVeUX8wkA4whx3w991fd4Y+GiW6cfQXmKr4fSHHpNFmgao4O/QGjj sHpKCDlNz5OaQl1ugw8IVcLo96GooT+tZvuPB3oL8RtVtO7lck1QKcwQbUEpO3J2AHe/ /+UMkG9MDjXwHhvOjkfrEgPjTQTqLbGHfVcMA6MG6XyunLmZZ1YbzPDH/tRifzitH2KH OZZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=D/uek+cJJoAI+fTdbeuh3zt3NrJYOLUBMLm/MVFPZDA=; b=VXuW0P+w53YaL6aZqs/Z9hN9DYa5QsnUpolPGxg+/v5pDQy+40W1vQiUjeJqu2B2/Y e/dHJqVrNRlpCAD7pfttQFq1IrstdHLNR305drquVrS5bvtsFvcnflH1YcGUqSjRQLLq yI7x6sjPswst8mUqDS6djY/AtK6OYOiitVANO+ZLhaRxpPJr251DETZVJs/lAf1paPz5 GdqXNEx3JZ30SpMsddon6D6KS+w1jLK45eeIfrORphY055t6Q+y8mDBAZD5ob2qKaon4 l3BtmAjuJaltq5cNNbvEBval+ke0GRAwSiI1GMwcdUYity0uIhkqU/WXPYpZy5fgdwWT 6jqw==
X-Gm-Message-State: AODbwcAA1gm4l/8hdPgr+2gJTnEA39jnXclVltXL3WZgjYRWRuq7P1fC D3Z8DS28dPad6IQtv4wF9v20VWntQynd
X-Received: by 10.176.9.205 with SMTP id e13mr13195278uah.66.1496235461252; Wed, 31 May 2017 05:57:41 -0700 (PDT)
MIME-Version: 1.0
References: <612B4B7C-CE5B-4790-B4EA-0953885BB560@iwelcome.com>
In-Reply-To: <612B4B7C-CE5B-4790-B4EA-0953885BB560@iwelcome.com>
From: Thomas Broyer 
Date: Wed, 31 May 2017 12:57:30 +0000
Message-ID: 
To: Jaap Francke , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="f403043ee9b02b20880550d177d4"
Archived-At: 
Subject: Re: [OAUTH-WG] token revocation from a different client
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 May 2017 12:57:44 -0000

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

On Wed, May 31, 2017 at 12:01 PM Jaap Francke 
wrote:

> Hi all,
>
> It=E2=80=99s only since recently that I=E2=80=99m sticking my nose deeper=
 into the various
> OAUTH (draft) specifications.
> I also recently joined this mailing list.
> I have a question and I hope someone can help me.
>
> I=E2=80=99ve been looking for a mechanism/endpoint/specification for toke=
n
> revocation.
>
> RFC7009 is aimed at token revocation by the client itself - logoff is the
> typical use case.
> What I=E2=80=99m looking for is a possibility for the enduser (resource o=
wner) to
> revoke one of his tokens from a different client.
>
> Use cases for this would be:
> - suspection that password is compromised, so enduser wants to change his
> password and terminate all sessions on any device. For such devices to
> regain access, they would need the new password.
> - stolen/lost device; the enduser should be able to revoke specific
> access/refresh-tokesn that have been issued for the stolen/lost device.
>
> Any thoughts on this?
>

That's outside the scope of OAuth I'm afraid.

If the AS is the same as the one where the user does those actions, and
then it's entirely internal (RFC6749/6750 define how clients are "notified"
of it =E2=80=93 their token is rejected with invalid_token error code).
If the application allowing the user to do these actions is a special kind
of client to the AS, then there'll likely be APIs it can use to list
current tokens and authorization grants and allow to revoke them, or revoke
all of them at once. In any case, it'd be a special API that either would
require a specific scope (that you'd likely only grant to that client) or
would allow access based on the client only (either using client
credentials, or looking at the

There might exist specifications for such APIs already, but I'm not aware
of them (i.e. probably not from the OAuth WG)

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




On Wed=
, May 31, 2017 at 12:01 PM Jaap Francke <jaap.francke@iwelcome.com> wrote:
Hi all,



It=E2=80=99s only since recently that I=E2=80=99m sticking my nose deeper i=
nto the various OAUTH (draft) specifications.

I also recently joined this mailing list.

I have a question and I hope someone can help me.



I=E2=80=99ve been looking for a mechanism/endpoint/specification for token =
revocation.



RFC7009 is aimed at token revocation by the client itself - logoff is the t=
ypical use case.

What I=E2=80=99m looking for is a possibility for the enduser (resource own=
er) to revoke one of his tokens from a different client.



Use cases for this would be:

- suspection that password is compromised, so enduser wants to change his p=
assword and terminate all sessions on any device. For such devices to regai=
n access, they would need the new password.

- stolen/lost device; the enduser should be able to revoke specific access/=
refresh-tokesn that have been issued for the stolen/lost device.



Any thoughts on this?

That's outsid=
e the scope of OAuth I'm afraid.

If the AS is =
the same as the one where the user does those actions, and then it's en=
tirely internal (RFC6749/6750 define how clients are "notified" o=
f it =E2=80=93 their token is rejected with invalid_token error code).
If the application allowing the user to do these actions is a special=
 kind of client to the AS, then there'll likely be APIs it can use to l=
ist current tokens and authorization grants and allow to revoke them, or re=
voke all of them at once. In any case, it'd be a special API that eithe=
r would require a specific scope (that you'd likely only grant to that =
client) or would allow access based on the client only (either using client=
 credentials, or looking at the=C2=A0

There might =
exist specifications for such APIs already, but I'm not aware of them (=
i.e. probably not from the OAuth WG)


--f403043ee9b02b20880550d177d4--


From nobody Wed May 31 10:13:52 2017
Return-Path: 
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E14129A9F; Wed, 31 May 2017 10:13:51 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.52.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149625083176.19916.6538159783527721652@ietfa.amsl.com>
Date: Wed, 31 May 2017 10:13:51 -0700
Archived-At: 
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-device-flow-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 May 2017 17:13:52 -0000

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

        Title           : OAuth 2.0 Device Flow for Browserless and Input Constrained Devices
        Authors         : William Denniss
                          John Bradley
                          Michael B. Jones
                          Hannes Tschofenig
	Filename        : draft-ietf-oauth-device-flow-06.txt
	Pages           : 16
	Date            : 2017-05-31

Abstract:
   This OAuth 2.0 authorization flow for browserless and input
   constrained devices, often referred to as the device flow, enables
   OAuth clients to request user authorization from devices that have an
   Internet connection, but don't have an easy input method (such as a
   smart TV, media console, picture frame, or printer), or lack a
   suitable browser for a more traditional OAuth flow.  This
   authorization flow instructs the user to perform the authorization
   request on a secondary device, such as a smartphone.  There is no
   requirement for communication between the constrained device and the
   user's secondary device.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-06
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-device-flow-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-device-flow-06


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

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


From nobody Wed May 31 10:21:13 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187C0127BA3 for ; Wed, 31 May 2017 10:21:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIhV2rQOR1cy for ; Wed, 31 May 2017 10:21:05 -0700 (PDT)
Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 A20DF126E01 for ; Wed, 31 May 2017 10:21:05 -0700 (PDT)
Received: by mail-it0-x232.google.com with SMTP id r63so15582125itc.1 for ; Wed, 31 May 2017 10:21:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XjiTC7tEM5xKQ//jv42tLt7qF2C7BPUHBxG2KMy+rhI=; b=NpXrpwtAbfcrPDizlRyGKaWqh6Csh5zrYDLCiIqWVJcA/EkclQsAegF/jmKQ4z0KKo JAQ8Lm1tViYQIc/GkfZB+VrbdDNjA5iUVG+8rNfA5BZGvhjuDtmV4BanVPsT8avaxMN8 q14GbhVcldMSZ2lqitieRGpeJyVpq/46bsCxo7uyYEMvmvuaEpbFNZAas6Oaz60dvrjx muQpnOiJi6WVY99XhT3oro0tisDdpnUBm3QqQWHbe1DaZ4qFfMlxjavKf3rfD7+jIU6e r+OokC1cgdnMQAld+LIW5bP1Mfbumzq5pNwMlqEtDGcolgxDvqoJVOhFLlgcD5elZ1G/ sM0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XjiTC7tEM5xKQ//jv42tLt7qF2C7BPUHBxG2KMy+rhI=; b=TVFsZhXnckvWePBgK3yUjHZrlvFqNinLRtpaufMZsfX1hDS4MAwiACZI0dTWqcelmV EmkBMzMqRk3ceQY0y57yla0zDnoU6Wu+BgJw5+vyt9vi+WfOy+3GjgtT4dK59zCI024W vylMcof6XprJbKv9hvyxhhNrhEVLuWOaWTYrJjbmGEPfbCX2skNwiJyYPcuAGDwbPqts ejoShxoHDz8hrL37q4vDxyrgOK3z2Sh9p22F9URtAlI7+s2myBhu/emZzOJUsw2GkEx5 i7fpd8Bd4Gs1MRIYQOaij6wAIFvDHs4wu4OgDSa0KLVG5hhG2yhlGJ0Gn0uQ7x7YOuAq v+Rw==
X-Gm-Message-State: AODbwcBLTDZijAh+EO7YO4qxf92T8RvYoBlGMuLMIkZy3pu8pnmEL8X3 aeUodL+GbhV1FGQ9apdbNaacvxXtV49fyP0=
X-Received: by 10.36.185.29 with SMTP id w29mr8056257ite.2.1496251264544; Wed, 31 May 2017 10:21:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.35.37 with HTTP; Wed, 31 May 2017 10:20:43 -0700 (PDT)
In-Reply-To: 
References:  <77856AF4-9B2E-4478-9509-1459037C24E4@ve7jtb.com> <22d06952-94ab-e6a9-d2b2-f96f8252bf5e@mit.edu> <4107AB98-25D8-4542-B932-CD6F921D0D1D@lodderstedt.net> <5529a18f-0ebe-eeae-2de1-c4066cf986b3@forgerock.com> 
From: William Denniss 
Date: Wed, 31 May 2017 10:20:43 -0700
Message-ID: 
To: Rifaat Shekh-Yusef 
Cc: "oauth@ietf.org" 
Content-Type: multipart/related; boundary="f403045d97121f346b0550d5259c"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.0 Device Flow: IETF98 Follow-up
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 May 2017 17:21:08 -0000

--f403045d97121f346b0550d5259c
Content-Type: multipart/alternative; boundary="f403045d97121f34680550d5259b"

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

Rifaat and Hannes,

Thank you for your review, and for the consensus judgement.  Version v06
 has been
posted that actions this feedback.

I would also like to see a WGLC issued on the document.

Best,
William

On Mon, May 8, 2017 at 6:02 AM, Rifaat Shekh-Yusef 
wrote:

> All,
>
> Hannes and I discussed the Device Flow draft. Based on the mailing list
> feedback, we see that there is a good support for keeping the "user_code"
> parameter in, but there is a need to document the security implication of
> this feature. If anyone is against keeping this feature, please speak up
> now.
>
>
> *William,*
>
> Can you please update the document based on the feedback you received so
> far?
> We would like to start a WGLC after we get the new version of the draft.
>
>
> We also have few comments on v05 of the draft:
>
> Section 3.3, second paragraph:
>
>    The document should explicitly state that this step must be done over =
an
>    HTTPS channel.
>
>    Also, the paragraph is talking about an "end-user" performing the
>    procedure. This could be done by an administrator that has a long list
>    of devices, e.g. IoT devices, that support this mechanism. So, maybe t=
he
>    document should clearly state that too.
>
>
> Nits:
>
> Section 3.3, 3rd paragraph, second line:
>    Remove the "a" before "the browser"
>
> Section 5.2, 1st paragraph, second line:
>    Remove the word "they" after "attacker"
>
> Regards,
>  Rifaat & Hannes
>
>
>
> On Tue, May 2, 2017 at 4:56 AM, Simon Moffatt  > wrote:
>
>> +1 for separate. The real world implementations we've seen tend to not
>> need the URL at all.  Eg end user out of band is in a web application on
>> the their laptop/tablet and that app has a "pair device" area, where the=
y
>> just enter the necessary code - so they don't even need to see/use a URL
>> from the device.
>>
>> Having the code augmented in to the URL too opens up the ability for tha=
t
>> code to be logged on intermediary network devices.
>>
>> SM
>>
>> On 02/05/17 06:32, Torsten Lodderstedt wrote:
>>
>> +1 to keep the optional parameter along with clear wording regarding
>> security risk and interoperability
>>
>> Am 29.04.2017 um 15:12 schrieb Justin Richer :
>>
>> +1, documentation is better. Though we also need to keep in mind that
>> this was the justification for the password flow in 6749, which has been
>> abused all over the place (and continues to this day). Still, it would b=
e
>> arguably worse without that so I'm good with keeping the parameter in th=
ere
>> as long as we're careful.
>>
>> Namely: So long as the user code is *also* delivered separately to the
>> user, we would have interoperability between the two. What I don't think=
 we
>> want is some systems that *require* the URI parameter on the approval UR=
L
>> and other implementations that *forbid* it. That case could end up with
>> something like: I've got a set-top system that's incapable of displaying=
 a
>> separate user code because it always assumes it's baked into the URL, an=
d
>> then I try to put it on a server that requires the code be entered
>> separately.
>>
>> The resulting spec needs to be clear that the box MUST be able to displa=
y
>> both the URL and the code separately, in case the URL does not include t=
he
>> code. In fact, maybe we'd even want to introduce a new parameter from th=
e
>> endpoint for the pre-composed URL:
>>
>>    user_code
>>       REQUIRED.  The end-user verification code.
>>
>>    verification_uri
>>       REQUIRED.  The end-user verification URI on the authorization
>>       server.  The URI should be short and easy to remember as end-
>>       users will be asked to manually type it into their user-agent.
>>
>>    composite_verification_uri
>>       OPTIONAL.  The end-user verification URI with the end-user
>>       verification code already included. See discussion in [blah]
>>       for its use.
>>
>>  -- Justin
>>
>>
>> On 4/28/2017 6:38 PM, John Bradley wrote:
>>
>> I would like to keep the optional parameter.   It is useful enough that
>> if we don=E2=80=99t have it people will add it on there own as a custom =
parameter.
>>
>> Better to document any issues.
>>
>> John B.
>>
>> On Apr 28, 2017, at 5:39 PM, William Denniss  wrote=
:
>>
>> Thanks all who joined us in Chicago in person and remotely last month fo=
r
>> the discussion on the device flow. [recording here
>> ,
>> presentation starts at about 7min in].
>>
>> The most contentious topic was addition of the user_code URI param
>> extension (introduced in version 05, documented in Section 3.3
>> 
>> ).
>>
>> I'd like to close out that discussion with a decision soon so we can
>> advance to a WG last call on the draft.
>>
>> To summarise my thoughts on the param:
>>
>>    1. It can be can be used to improve usability =E2=80=93 QR codes and =
NFC can
>>    be used with this feature to create a more delightful user authorizat=
ion
>>    experience.
>>    2. It may increase the potential phishing risk (which we can
>>    document), as the user has less typing. This risk assessment is likel=
y not
>>    one-size-fits-all, it may vary widely due to different the different
>>    potential applications of this standard.
>>    3. The way it's worded makes it completely optional, leaving it up to
>>    the discretion of the authorization server on whether to offer the
>>    optimisation, allowing them to secure it as best they see it.
>>    4. I do believe it is possible to design a secure user experiance
>>    that includes this optimization.
>>
>> I think on the balance, it's worthwhile feature to include, and one that
>> benefits interop. The authorization server has complete control over
>> whether to enable this feature =E2=80=93 as Justin pointed out in the me=
eting, it
>> degrades really nicely =E2=80=93 and should they enable it, they have co=
ntrol over
>> the user experiance and can add whatever phishing mitigations their
>> use-case warrants.  Rarely is there a one-size-fits-all risk profile,
>> use-cases of this flow range widely from mass-market TV apps to
>> internal-only device bootstrapping by employees, so I don't think we sho=
uld
>> be overly prescriptive.
>>
>> Mitigating phishing is already something that is in the domain of the
>> authorization server with OAuth generally, and I know that this is an
>> extremely important consideration when designing user authorization flow=
s.
>> This spec will be no exception to that, with or without this optimizatio=
n.
>>
>> That's my opinion. I'm keen to continue the discussion from Chicago and
>> reach rough consensus so we can progress forward.
>>
>> Best,
>> William
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oa=
uth
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oa=
uth
>>
>>
>> --
>> [image: ForgeRock]  *Simon Moffatt*
>> Product Management  |  ForgeRock
>> *tel* +44 (0) 7903 347 240 <+44%207903%20347240>  |  *e*
>> Simon.Moffatt@Forgerock.com 
>> *skype* simon.moffatt  |  *web* www.forgerock.com  |  *twitter*
>> @simonmoffatt
>> [image: ForgeRock Live 2017] 
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

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


Rifaat and Hannes,

Thank you for your r=
eview, and for the consensus judgement.=C2=A0 Version v06 has been posted =
that actions this feedback.

I would also like to s=
ee a WGLC issued on the document.

Best,
<=
div>William

On Mon, May 8, 2017 at 6:02 AM, Rifaat Shekh-Yusef &=
lt;rifaat.ietf@g=
mail.com> wrote:
All,

Hannes and I discussed the Devi=
ce Flow draft. Based on the mailing list
feedback, we see that th=
ere is a good support for keeping the "user_code"
param=
eter in, but there is a need to document the security implication of
<=
div>this feature. If anyone is against keeping this feature, please speak u=
p
now.


William,

Can you please update the document based on the feed=
back you received so far?
We would like to start a WGLC after we =
get the new version of the draft.


W=
e also have few comments on v05 of the draft:

Sect=
ion 3.3, second paragraph:

=C2=A0 =C2=A0The docume=
nt should explicitly state that this step must be done over an
=
=C2=A0 =C2=A0HTTPS channel.

=C2=A0 =C2=A0Also, the=
 paragraph is talking about an "end-user" performing the
=C2=A0 =C2=A0procedure. This could be done by an administrator that has a=
 long list
=C2=A0 =C2=A0of devices, e.g. IoT devices, that suppor=
t this mechanism. So, maybe the
=C2=A0 =C2=A0document should clea=
rly state that too.


Nits:

Section 3.3, 3rd paragraph, second line:
=C2=A0 =
=C2=A0Remove the "a" before "the browser"
Section 5.2, 1st paragraph, second line:
=C2=A0 =C2=
=A0Remove the word "they" after "attacker"
Regards,
=C2=A0Rifaat & Hannes



On Tue, May 2, 2017 at 4:56=
 AM, Simon Moffatt <simon.moffatt@forgerock.com> w=
rote:

 =20
   =20
 =20
  

    
+1 for separate. The real world implementations we've seen tend
      to not need the URL at all.=C2=A0 Eg end user out of band is in a web
      application on the their laptop/tablet and that app has a "pair
      device" area, where they just enter the necessary code - so they
      don't even need to see/use a URL from the device.

    

    
Having the code augmented in to the URL too opens up the ability
      for that code to be logged on intermediary network devices.

    
SM

    

    

    
On 02/05/17 06:32, Torsten Lodderstedt
      wrote:

    

    

     =20
      
+1 to keep the optional parameter along with clear wording
        regarding security risk and interoperability=C2=A0

      


        Am 29.04.2017 um 15:12 schrieb Justin Richer <jricher@mit.edu>:

        

      

      

        

         =20
          
+1, documentation is better. Though we also need to keep in
            mind that this was the justification for the password flow
            in 6749, which has been abused all over the place (and
            continues to this day). Still, it would be arguably worse
            without that so I'm good with keeping the parameter in ther=
e
            as long as we're careful.

          

          
Namely: So long as the user code is *also* delivered
            separately to the user, we would have interoperability
            between the two. What I don't think we want is some systems
            that *require* the URI parameter on the approval URL and
            other implementations that *forbid* it. That case could end
            up with something like: I've got a set-top system that'=
s
            incapable of displaying a separate user code because it
            always assumes it's baked into the URL, and then I try to
            put it on a server that requires the code be entered
            separately. 

          

          
The resulting spec needs to be clear that the box MUST be
            able to display both the URL and the code separately, in
            case the URL does not include the code. In fact, maybe we'd
            even want to introduce a new parameter from the endpoint for
            the pre-composed URL:

          
   user_code
      REQUIRED.  The end-user verification code.

   verification_uri
      REQUIRED.  The end-user verification URI on the authorization
      server.  The URI should be short and easy to remember as end-
      users will be asked to manually type it into their user-agent.


          
   composite_verification_uri
      OPTIONAL.  The end-user verification URI with the end-user=20
      verification code already included. See discussion in [blah]
      for its use.

 -- Justin



          
On 4/28/2017 6:38 PM, John
            Bradley wrote:

          

          

           =20
            I would like to keep the optional parameter. =C2=A0 It is usefu=
l
            enough that if we don=E2=80=99t have it people will add it on t=
here
            own as a custom parameter. =C2=A0
            
Better to document any issues.=C2=A0

            


            

            
John B.

              

                

                  
On Apr 28, 2017, at 5:39 PM, William
                    Denniss <wdenniss@google.com>
                    wrote:

                  

                  

                    
Thanks all who joined us in
                      Chicago in person and remotely last month for the
                      discussion on the device flow. [recording here,
                      presentation starts at about 7min in].
                      


                      

                      
The most contentious topic was
                        addition of the user_code URI param extension
                        (introduced in version 05, documented in=C2=A0Section 3.3).

                      


                      

                      
I'd like to close out that
                        discussion with a decision soon so we can
                        advance to a WG last call on the draft.

                      


                      

                      
To summarise my thoughts on the
                        param:

                      

                        
    
                          
  1. It can be can be used to improve
                            usability =E2=80=93 QR codes and NFC can be use=
d
                            with this feature to create a more
                            delightful user authorization experience.
    2. 
                          
  2. It may increase the potential
                            phishing risk (which we can document), as
                            the user has less typing. This risk
                            assessment is likely not one-size-fits-all,
                            it may vary widely due to different the
                            different potential applications of this
                            standard.
    3. 
                          
  3. The way it's worded makes it
                            completely optional, leaving it up to the
                            discretion of the authorization server on
                            whether to offer the optimisation, allowing
                            them to secure it as best they see it.
    
                          
    4. 
                          
  4. I do believe it is possible to
                            design a secure user experiance that
                            includes this optimization.
    5. 
                        

                        
I think on the balance, it's
                          worthwhile feature to include, and one that
                          benefits interop. The authorization server has
                          complete control over whether to enable this
                          feature =E2=80=93 as Justin pointed out in the
                          meeting, it degrades really nicely =E2=80=93 and
                          should they enable it, they have control over
                          the user experiance and can add whatever
                          phishing mitigations their use-case warrants.=C2=
=A0
                          Rarely is there a one-size-fits-all risk
                          profile, use-cases of this flow range widely
                          from mass-market TV apps to internal-only
                          device bootstrapping by employees, so I don't
                          think we should be overly prescriptive.

                        


                        

                        
Mitigating phishing is already
                          something that is in the domain of the
                          authorization server with OAuth generally, and
                          I know that this is an extremely important
                          consideration when designing user
                          authorization flows. This spec will be no
                          exception to that, with or without this
                          optimization.

                        


                        

                      

                      
That's my opinion. I'm keen to
                        continue the discussion from Chicago and reach
                        rough consensus so we can progress forward.

                        

                      

                      
Best,

                      
William

                      


                      

                    

                  

                

              

              

            

            

            

            

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


          

          

        

      

      

        
_______________________________________________

          OAuth mailing list

          OAuth@i=
etf.org

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

      

      

      

      

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


    

    

    
-- 

     =20
     =20
      

        
          

            3D"F=
            
              Simon Moffatt

              Product Management =C2=A0|=C2=A0 ForgeRock

              tel
              +44 (0) 7903 347 240 =C2=A0|=C2=A0 e
              Simon.Moffatt@Forgerock.co=
m

              skype
              simon.moffatt =C2=A0|=C2=A0 web
              www.forgerock.com
              =C2=A0|=C2=A0
              twitter
              @simonmoffatt  		
          

        
      

      

      3D"ForgeRock
    

  



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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






_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





--f403045d97121f34680550d5259b--

--f403045d97121f346b0550d5259c
Content-Type: image/png; name="FR_Sig_Logo.png"
Content-Disposition: inline; filename="FR_Sig_Logo.png"
Content-Transfer-Encoding: base64
Content-ID: 
X-Attachment-Id: 70f95eeb40216005_0.0.1.1

iVBORw0KGgoAAAANSUhEUgAAALkAAABGCAYAAACQaTWQAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJ
bWFnZVJlYWR5ccllPAAAA2hpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tldCBiZWdp
bj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1ldGEgeG1sbnM6
eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUuMy1jMDExIDY2LjE0
NTY2MSwgMjAxMi8wMi8wNi0xNDo1NjoyNyAgICAgICAgIj4gPHJkZjpSREYgeG1sbnM6cmRmPSJo
dHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4gPHJkZjpEZXNjcmlw
dGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wTU09Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEu
MC9tbS8iIHhtbG5zOnN0UmVmPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvc1R5cGUvUmVz
b3VyY2VSZWYjIiB4bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtcE1N
Ok9yaWdpbmFsRG9jdW1lbnRJRD0ieG1wLmRpZDo0MTdDMzdBN0FBMjE2ODExODA4M0ZGQjNERTYw
NDVFMiIgeG1wTU06RG9jdW1lbnRJRD0ieG1wLmRpZDo0RjYxRUYyOUNGOEMxMUU0OTM4QkU4RDlB
Qzg0QTY2NyIgeG1wTU06SW5zdGFuY2VJRD0ieG1wLmlpZDo0RjYxRUYyOENGOEMxMUU0OTM4QkU4
RDlBQzg0QTY2NyIgeG1wOkNyZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1M2IChNYWNpbnRv
c2gpIj4gPHhtcE1NOkRlcml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InhtcC5paWQ6MDcwNEQ1
QTUxRDIwNjgxMThDMTQ5QjkzQTA5OEZCQTYiIHN0UmVmOmRvY3VtZW50SUQ9InhtcC5kaWQ6NDE3
QzM3QTdBQTIxNjgxMTgwODNGRkIzREU2MDQ1RTIiLz4gPC9yZGY6RGVzY3JpcHRpb24+IDwvcmRm
OlJERj4gPC94OnhtcG1ldGE+IDw/eHBhY2tldCBlbmQ9InIiPz4qUGMsAAAoB0lEQVR42tx9CZhd
VZXu2ufeW3Wr6tZcRSYSwkxAJHQQfbS2jAJO8emTp5EPuhsB7RZbaRAjMisoqPDsthVQoZ1QEFEE
mechhISETGSeA5lTSaWqUqnUPeutvc+09z5rn3vDM75cbn2nzjztvfba//rX2usIRIQPT7kYAAFA
QPgvXEE5NzepX7h59foG+OoFK+Hzn10BPT2NwP98dRkhvHgdwDP2B+v2dvNcRF+7hnwGOl4k5wX7
QbuGH87Na6rjoncC5rrGc6ljOujfDbTe7Pv58+rr+qCuMADDfl1YHL51Hfu+jnVVnl7yLtozpY/R
rxHcr6FxCyxfcwo88+olkM8PQs4bjp+8va0VXnh5Ojw/bTq0t7bSZQVdKqy0uDK1urQ2mXIA5rH0
+8s9t8O++G3YsAFHjhwp/trXzRsvhuGbCH1u/2ijwKDgfGQvmgiSZ1aaVVG8gOvLXii4oQApwQat
0fjxObygeimhFYZwR+upxngQLX+Wlk+n406huedj7qvNjZuhb7ALnp/1RSj7BcjnhtwlqysFbv3t
/GKlI6BAgr1p2+G0iLQ8REWTC2+DzKNgIq8CU3WZCDYj0X/N5///9Mvb8pvS4FzrRrswhaGRIgFM
BMnWmF6GBk+0G8bXCq8X3sm+TiCcYGjTYJvZYOL96HO9Sjtd41yaT6Ht74uEP3h2eLy+MHBbnoRp
+rzz4I1VZ0NTcYshAEIIVsDCl3AKjVIWmOxT10GMizpat69PjQ7q63qhoX47+NTgUte3JVJwMow1
K7h7L+TIdFHCFmBMtXqh/qILaFo2FJ5IC4PRldtzx4+OF0oY/YovEQl9NEfkYVP8DPLawcaRNJ1P
wv+/ad/xwb3Sz0aN5fLG4jaYPv98WLL6ZBjZvpgX6H35c2hSv1xwCKqmvXVIEjW4vRJuYfUAtSjk
saZBRitZQq8XthedKzSBSPewiSYHRqODAxenMXWgmYHB88k10OhNXNAFxtP0ME1Hmz0PWI1RXlfc
0VbaOHfdpokwe/GnoKW04VjafyYd+b2ooe+VwCOnZIUJLbTtCOhQzME+va6czyJ0SOoQcLQUm9ab
1LKA69hAa7FgdJ+VYWLQOMxTbOH1U9rWbehp1xBZ2j4x+GxtLhznBceqfbfR8tE6pk96HsP425nP
77nSp/V5yz5KHZJH+HfXP5Jo3UL73qMLpS6owpYi1Ho+kT4Otb+kh7SOw+xGEQs4Y0gKl9pG17ag
8fC9h6hVIY8KAisbGFElyUN9tDZ7hrCb8ME3mQTDGPQ0IeQe0dcE1NOWISXQyTU8Bq6ohU/SNDnC
+prgG8avfGbS4lObGzdsWbzqFFix9iRobtowAdG7NDzoOynjTteweiHGRYspg5ATwOi4eB5qVbtR
uDR+CmlaSoyVV8GcI7iGgLUr5MjBErZL1QrTMzWTJkiasPma8WhSYoEg+Zom1YXdZGTccAaYhuVr
k/6q6hrfSASZM4bjhrewWNf7o/5dnTB32WSoq+uHnOd/Q7vgqbKxQIpEQSes5fa7jkdTFbNQJNL4
qWtydYda3WEFeUVHQ8CalHFd3UUFYXZTUQGh683jErU4bAMepKlBW4unDcTKhqYNVeR6SpOjr7Mp
l9D+SVGPw+P2SMPD1MaGHnhj1RmwpecQKDX0nOqjONc64aZAyNICEmtp/OsoQoOBsTV6BWFF29AU
DGWOYGp7hMzGui9+Qoh9KOSoGSSWYWIWkEipCuTaTIiLTSHKMgSthoCcw8i3tLzH9hgBRZhcN1E+
fhetX5dgd5ctoF7vARLqP0keev7Sj0FjcTsQMrvK6NGCC0+g8pnqEoKo7GzoIqqUlBTkAR72OGGl
qHBNBqboXDzLSta0JrdfFoTexzpbnNAEEZHzWur7OBjDNxIH1DC8mhEHn3ImCc/Q+iHXfZnkwjnv
YdpG8G8qFPph3tLJ0Edwpb5u5/kCvJNTFR68/NdIcDqyCZXqIIptpHLwRG8kIuluGeEVLDRB29tp
G7gi2SlSgi72qSbfG8LjbVCIHJ2kGaHC/TDIwIi0qzthLjgoktCL9n7fdH/HlKRvCH7arZ8yPo+h
616hO47MBpg4nciw/M/WpvUz1mw4AZauez+0NG1spG03CXAIiYA22vYdKpOL8rkcFBuK2RBCd0UI
m2q1FCmaMosaC2jLs76tVCpBIeeBX/bd2Dqu1ySEwzA2BQdPapNKzGfiLmGyixYvFfl/MmhAHYtn
xaiAReHpNKKtZdPwxsDhcRyIpzeUbyPD4Sc9QmyEDuVzg99DyMGcJZNheLgeCo1b/s0ve6NQoCEg
StOKmP2YUygUwCNDfP2GjYGH0pK+xJPJxAYZEs/sMzSz1hqYVuFRQ+vZvgPWrd8A9fV1ptBathZy
Fig6epwsr+5+jsnzTovajuex3dNoy6rHOGfM/Qaboa6nC67LSOVwO2gBWmYPgmkFdAYdN1mg72hI
SQMjw/Ka9tKG1QuWfwRWkyZvK711kO971xnQ2K5ohBdzudyP2lpb4fmXpsFzL0+HUlMj5CRE0pxr
HGUYrZt0IK8vdWoymEcyqzuDgsIcLpdpp4Bm0uio21iCEWCut+YfYJ97efctXAGmhdtUIiMckidH
hxYXBsTwLfxsaVoDbmjGp8gI3mLDBLwgpMC89s2cR9XcJo/LzSvW9X2nf6AL5i79CBS8QfBE+RYf
vYJeLqjH7gh15hUdbS2w4I2FJOSvEH4vqMoaxnLyZJiIbzl+SlT7y4wmExI60LKcR29Wtpp6OXpz
IVLCIa/v5T1zuwuCMBGHrMZ+xwRoycqzumWzUKzYFU/XS54Dntj7PdbZky3EHCOj42srqCs56Hw6
bqKJfSMWxnwGaq83NzVuhhnzz4WNPUdAV+uqk0jAP8113ZEQkBDd3dLc/PKWLdvgkaeeg3whV9/Y
2Ci37456vpzlYMuBNXcqkUDw7OOjasgLYUUXAh8uXcnBF7vtK1An4m2EMOx37Ar3npXex9expM8L
qwFHshkv07vJNQhf48LT7nvrcZtow3eDjR7jHEqeiQT88VLDtl9t3X4IvLHiTCgVt0lv580u+i2E
DcM5L3dtXSEH06bPhJ29OwmmlL5JAn6LYSGiGwoEbIbgqT1XF4pW1y7SeFs7KEU/prh7O/IU9NBc
UT0rtN8LOTKOAVEdVkvjKBM7uwWWhzmJdvaZ63D8u2aUmvj829QbjDB9Vp4VahAIP3VIl9XVDZCx
+UnY0TcGGup3fIGu9Pe88AXbymX/utbW5tXLV66BuQsXQ1t7W4HK4hIqo0vokFEcv22XcyBMaOJd
1BsUo12FJdiG884WYMHj6hS9yGwTtcumOOgFVwEyBacJvF/2oKllj0KI5bJnQRI9MIvTpLZnEsKQ
XF0AweLUfSa+xbN6eLX/EJr+VYc9HGQJlvM/a23aOG/txuNh6epToKW0Pu/7uct1rW1rMpqvqKvP
31wmA+/V12Yr7FzI5aRTqDVQzuJS1oAXDLZ12D6o+9Bdvas+uAU5oWTO1ytbVBDod4aMa5rcyedi
eltYUY1Ne2DOnDYF7dvbhwDLwgrAynIMeanyRAAWhmTTjH7c02IsQP7Npr3hgRmxGO/ozeeGvi7H
MS0gY3NPOQ/53O5raPUQXWvbzhfS2Ne1trQMzZn3BixdvhJaW1vGk1BelUQr42X0byKLtatEJc5z
xP+DIEb1iZimKLGKZ8J3giZH4Ls7vWvUjh19wG74w2MHwLU/mAC5XBmKDWXDccNrXI/1dCbsC0dJ
epkwxwzj9c6m6VPc8bajiXD31c2lDVuWrjkZlq07ScaKj0X0/t3S2jbV90KxWPzFzp39MGPWnICL
BvFN1ahMYfyWgb2xSkFKc33gsg2cTh5W43N+D51FEGaP4+w59h3Fsm9jV3RIYkAVm2nBRNAVr+zB
+AMH4a77xsKDT4whzT4gueYq+FATdgTrkA1FWJaGHfw81dUgjOhG9JYX6/r/o3+gA15f/HGoLwwQ
NvelYDZwwqRh5m+0NJdg1py5sGnzFmhuKk2ijRcwgvARms6MzxXgjPCMGwCCaTAicHGzvEdVMJY8
corLhUlcQ/f+dhp8X/HknmZ2JzEQmRx5UgHyoQp5H0Z27obbfzkOtu0oQUfrbhJ02+g0GRfbeBRx
QJeLhYkiCX2LyfE0wVX7/pm2fcCMEdc6LENBiqmNDZv8xatPg809h0Njw7aTSbOfl8Um0Pv+qrnU
9OLaN9+CGbPnQKnUJMvmhpi1AMuWAbgppb0554tt5Kc0b7AgKsWO2CN7OM0MDMmAYLIpmfEqNUwh
coZWNXiNBAO6SMiXrCjBfQ+OBpEbdjiEKnGRfmxw2lo+ce+nIUxi2Hot9O9GO0ZcpxwTb6z3QlPD
tvs2bz8S5i37iBRwee9vViirYepOr60v1sNrs+dCX98ANDQUzyHBP9sot5g6VNr2+KDh2SyNqICb
GeMSLU0nHJSkQdGI1CgjO5TabARaQ8LMB6pNIU8KULixHLox5IgRg3DvwyNg89ZG6OwYAt/XYYmf
SRvG3krGTW9EGWIYsAXpiEaarqV/I+LjtVhzG+tT3X9NUoZzl3wMdvSNhGLdTtLg4jRdUGzq0Pf9
H7S3ty5ftnIVLFi0WOUzoW03sFhSGJMcQdRsQBasIoALHVg7A9OnGgFiahSRcxCzsDQ51wPUaKwt
FxLo1tyO8X7ylNbSMKzfVIT7HxpNW/ZAZ+cuyKnQbl2D+nGseBp/+8wEhkZWRq0WL54MXPbG0fSF
iDGh5Z005yZpR/xna2n9K29tOgaWyyjD0pYiYO5GjTlJGXn0t76uULh+eE8ZXnl1JgwPl6FQl5MG
6hEV47sRuun/tSkBAoexn2VMVpK3rPOwil4j1SB0vj7pUWrtlzeZFPfIfMOlyyaqARhD2vzu34+B
Jasb4eLProUjD98O5eHdMDQYxiYD2sBYG6ghNA4QzdjSlMNCM4ADoeynfUfS6mZaK6TiaZPre/n8
noHh4SJMn38eDJfrgGDLZb7vjbHfV6/scrl8dWdnR780NpcuXwVdHR0jfR+vMcvNjio0iuYrtPNH
dNgKNiowa2SPYARbuCELHzZt16lgSAVOq2M6dEDUspAbA2FFKrbYFc2my1F9Pf3zhuGxZ7vhuWmd
cO4n18KUyVKB1sPQHt80ZEJBFeG1BRNolGwTaeIAjRraGkxq46DdSvW20dq8HmYt+jS8ufFYaG9Z
dwQJ+A2mjSVsB9CMYkPxpzv7diosXqyvlzE719O1mi1KJCu+Q4Yk3k67znALFQNBBKO6rSRPLOXH
wH8z8A5Twszy6QJqOjDLEnLzRTFVgFpyGS5RTYxbSY3mAA4eNwA7+z340S8OgMHhz8AxR42Dnh19
DC8lIGvUbFK+wsFriSq9Kcl5eWqEu4cblLDTlkGq/D10p4J+Vz2stez7V7e1tqgIwzVvvgUjursm
UcO70IUbUI/vNq1C32hIXP4TuzdNxaOIxJnj0syOurFDa5NnwGwo9DcU8H0cT+4KqxRm5izOpZyS
OyRhF9BYLMOo7n5oaChAvtAEe8p9kMt56cLDbF9GKrgOTHQQbpKxIh20skW9k9uDmxvc07CpkN89
6HllyQytoa1fpgr/MZdSwkf/ty3NjY9u2LhJafGWJhWffaP5wOiAEAb0k7EPF7qoSSdITgmsK30f
unsGDuJE0aYiw5B1DLaoRZ48X0n7GbHFIgMzWtpDUA+dz+VhxqxX4MAx7dDdUYTtO3rBy3kmZYnp
br5iSCemoMVIms0KL1nWjSY0iWsPcjJDLVyNGFOmP6F//0Z7j9IFUM494V1bT/DkladfUKNturs7
P+37/of22hUP8H9oWuMuN738wNTU7Egeq3et9AxOOCOyjUlWwGs+uVD6paodr2hqlAB3NzY0wrIV
q+H3DzykGInm5pKk3cxrCxMmCMfgaa7ytEqfTdvuDJdz0UT7c9p69K5X0T2ONN5ZwBUp2hDhltbW
lsUrV62F+W8sgtY2RRle5XTmuP0KG2m6lu2edFysa2vhYD343Bd8eaEjuEs42BJRicUR1Tg89mMh
R9uZsZf8vzMLGUJXRzssW7kaHvzLY1DI56FYLCrtzWWPMtKlCYvGMuw7NsZaaujdDP2XosTo+t/S
06rR8oO060HtmTYRtPqW3DnjtdlQxjL1Srl/oe3HJvafqEzJBUJ1JR3az8MMzcjL0iRc43AaqRWy
2QKmWSAXN+/CkDUp5E43vuDL34hj5lIfmAbPAd2dsHDxUnj62Zegu7MDurs6oaO9TUbvEU7PkYZE
R/WKlMaPYqKZIKW1NF0DKdM13fDo979oOlm/Hv10rvwaerbeeQsWwqKlK6C11NJOW68z7IfIn4AG
prDns+nAn2UKiKjEYSOf21BkHF+N34ZTZBlp49h03rVHITpKQvBWMOqjT4y4i3TpyuNldz9n/nwF
V1paStA/MAClUiNMPPZYaC41KbweUYkuRkAfMe7A7N+laQoJwbu5QcKWsMtw3BO1Y6ZLbU7G5mnU
2/xkaGg3vDprDhQKeWlHXE/P1uViLlJDzJLly7NoV6fgiWx8zTMzFYklnnnBKh1QonY1ed5JYbks
akxrVtNRlLba5T45wHfYy8HM1+dIWk4Ju7zd8pVr4QMnnQjjx40DyUUP9A+q1A62Vom0F+eRs5Jf
3kzrv7LpQMa59R7aPoWm30R0Gv3dQI3ov6Tt8NK0V2Hj5s3SfX807fuSafAyoR1pLfgQTU+5ytKg
EbmyzDLyq3EC6fcR6GZj2Gu5P6VSi6G2+ZSx4rLIo5ePPqWC6Exiyf2kvSmFV0IUVYdecI0Vq1bD
ujffgvdMmgjvnXQ8dHd3wLae7aoReFFaB6gyMWbw+zVNMprwQylNnk7JILX5H2h5UIUO+/7MAzo7
YfHSZfDM8y+BHJRM1/i2zS7x10wJxtedyoKj8HQYlDnoWMS+yEyZQw2KodUDZ1CLLDVsvN6+U+f7
NtRWF2JgDL6UQY6VjVDMKBwtB3onYfO6+jrlbPn1fffDgkVLoJOMVQllfPT3ooQMAbwsJYz84APp
zr8+KuBSUxNs2roNHnvyWUV1NtTXT6bTPpF5T17Wvk1bFlQcxLAXRrzuFEL7g2XVZJsVbPYvd76d
vXm2mjI8LZrKcO3b35gRkJ2xVVRh7EgNr2LS88oY3bptO9z/p7/Aw48+Cbt27VbbPM+rroWb95tH
088tmtDVC3yZpnGFXJD04clnnqPn6IHWlhZpEF/nxG3ooDNRhRjcClzumqqlR6QiBgyPmKgAYRAc
kaMizahw54FFbwLUbNpmgyc3edQKlneWccJRX1kVGo2LJEFuaW6GtpZmeGXWbPj17/4AcgyldKk3
NjTE/Do35tLxk3ChrwooVS8NViT4tJuMzd6d/VBfrxIEXUj/jktJKccroyEkMi59a1WMhvMYZEfa
M4aFlqGLGb5mNzKsxnkkeKZM1LomN7qrKpurEG5hRge+t6+PlsEl47sIJozs6oL+XQPwwEOPwCOP
P6XCAVpJ+KWg68yK7kBi+PDNNqXocjTR9s+Uh8unN5ea4egjj4ChITXwYwlLj7pc4cH0Cv3/CRsL
njX8jTWMIcPTaDpxUPvek319IUQVnk8LVqY+pbI3FNF+KuTGQFuxF9pGoxmFnsRfVOBjOUMQk4qS
vLnExx1trTBt5iy494E/yzwn0CIFveynOHT70yKaEfNDmlbZRqr93Z5w+5V9/f1wwvHHwrixo2FH
b+9zdNzPWRrN5U8AuNEtPA6t7mhA6GK5XH4LLdTBaAuuARpZjqUUN1/p0xQ1IOTOgbbIaMAI0iCD
b11Zo7KMNm4EeBR+S3h8ZPcBsHzFKsLqD6trN5UaY48pY3Ba384RUiVPtbU9l0uFficPDQ2d30DQ
6ITjjgM5QML3y1eCCt3loJuw/Ql/poU/p3Asi5cF38tV1YOCe4wow/wIozcS1RnATCKkdwAmF6xG
iZKwpykzzEq/6jZkMhgDN2RHMkC7YPHy5fDUsy8SPi9CngzVLOLFEubf0jQNdVbC8h5Gx5ORe+P2
HTuaJhx1OBxx+CHQ29u7QY7rdH4n01y9jB0XyfRkAhgsn0EDmj2nyMb5XI8gGH6cvW/6Y17VDk3d
/4Vcw88pj6Owagch25FgYdAUDsaMyrTzjWhauruzE1597XWYOWsudHS0GyaBLazMlx2+ZnxeUDgH
bo8mDX61LJb3TpoIdXVFIKx+Kx2y1qJS7Hf+Ie1awtKnogK3z/WerrgUJ08tqhREYTI0rhyK75DB
Eg4K0focnt7NMXjWGVVn05Au5wOkP+GhOy50DCxjXCROf+q5F2Hp8hVw4JhR0NnRBu2E22Vu8FJz
ExTqCxp6MGroRZruwHjkEAxKBxAdo6Zw2y51X098eUfvjnEHjRsLRx91GPT29w3Rpb4RCtiwOlaE
U/DbYBu4TgMzi1YVwA9Vs6k/Vr6r/AgXIt9zcukohKj87DXyc8euIN/NObOpCot5cYx8EZbgI/LD
rFJeRjquobEB+vr64NEnnoH16zeqdLRlwi3FYr2iH6UTqauzQyWh7+vrV/nThYg/Ayj5cNLSSby5
/aHZcJTQCLrXrhzZAx1tbeAPyyRy4h4U+KjRhIPnlZmZd9G8Nw0voKI3smL8iXBCo1QOcXTRnPb9
2NgbSI02EuIdkwqRH/5WPRcOUBVeNQbGcia+NgAgg4+XI/NlXMng4G546vmXYtGUCefrCac3NTbB
oeMPggmkgceMHq08pr29O9WchGK3iu2GZOyolmdcj27cIZdlfM3Qnj2qtlFleRRb0EWLupgjO184
VuFzqAYmcMrBlWR/b3B1ipaEKmiimhFyNDUEE2TFDnpNj9BxV5Qxgh5NAzZLBVrDyyRXXldXgM66
Ng3hBDHSAwO7YPprs2HeG4vg0EMOguOPexccfNA4tV3Sg9J7qtsarlBc+f5ywEdDQ32YRkOLNXGO
6snQ0JqAs5GRlTS+lkErFbMiKjQS4aB/XbHtolL7ErUq5Ek3hpnuaF6QMWuMoWGAZWXnQmOcaNV4
UCTJ7IsklA2NRdLAwzB3wUJYQth94jHHwPtO/Dvo7uqA7dt7lYYO6EkBpcZGkB+0SuLZg5H9Ev9v
2LQJ1qx9K/m4lJ5ywsCtFeJ4XDCsmp5SmFAiZXcK4RZY3Q/A9UCOXsYVtQkVAuVqCJNjhbQIlWrT
WhaQ7S0UFbpa2+gXjgowvhwiY2FyCpsPDe2Bl16dCUtXroLTPvh+OOzg8eEY0+CE5bR989YtUFeo
i80IGUcjY91nz11A2n8ApBc0SGCE7mSZVWg/FByXWK132VIE7FAecCugzLzo6OD+wZ0RoCaFHJnu
txJ36yxs1BxGGQFdro8zcQUqHEZvBlxUyUgLeRg5ootweZ8afjdm1EiQHLhsAPPmL4RFS5bCAOF7
eZz+k9pe5ldpbmqK4UpmJWd9Qc0Bi6xPUUHFOP5sjj47CZHe2CpkBEDXe2WFANeEkFfKzJSCHZpw
O7tczKRz2YqzU0RnDbSt0qBSIQIlOYC6DKvWvQnr1q9XzqRdJNwqdKChgU1qFLvEU9/hgaoT67P2
DQdbKn15jRE8fYxqZlSibaxmwqIsxqzWMTlmd3luIxKrMFqq7ebsARmY3WWKKpVd2GjkAAwZ4ahC
Amgq1hcN7t8QmhTzKSpn+2UEAtFRPuhusM7MtfYH3UR1SiRlrGKWMSrAmRAU4W/yLc99q8mrMJoy
u9Jgu0yfPA5k+CrCNhKONZJ+qy6WRWM8RAXuPvt5SuoZhEqmL9N2yXwnu6IKjAQajBwvkCEIAtC6
l2nMZXjCssrQCp8Ir9dFqweqpDWBk+ktVtkIG9cb95UesYNAfr8IldNrDe3emdm7CK43TSkgqRXq
aP/O6GYfnnJxO80m0bTiL7+5fcX+KuRRqO3MoFDFQprHExWIsR56+X6uw5Gw+/oQTS/QtIO2zKNd
M2nzCirgnvD4Ax09xmdBppFAWEzHBPfA+H5LaHkRBMPZTucbokFb/ANNT9LSdpovCN5JLFLPJLcj
nsJo1HZ6xteVMOnvKd89LgsMJqGcSNdAkrPxGvntWWE8szxWPfMSOv8Nmt9J553IalszAvPztC7P
26xG+AO8RtOb8rlU7EzQcDWta+dAUS91KN3zl7Qoy3ypen8B82miOoGXaDpLM0Q/CjJJKsJKmm8K
BdWmgT6ongFhGa2sU04vgHdFbZ4EXKakvjc89wpafyIU+rf929djPI+gSSawHOHGjfFvnHXMY0rI
9Uy3icaTebn/iRbl9FXacJul0dqVdhDq/i6HikwENIWWZcVLQd2ZnB9/1vt31H2fw9JeZH/Susw9
fhot303L/2S9/1F0kBw4YXyWMAVdggoYrXXnMke1RwJ6VAbmnkAzKcAP0jSZgW7jaXqeNo91wINR
dB3ZmK6i5bOoPJ8IYEpK415PAn8V8rEycstJ9P8RWvwZnfh5UMlKQQ5gHR9ep2SyN/A+et9nwchZ
jz+lfy/LXoKE+TM07wl3nk6TVC53hEJ/xtsVxr/NGE8XyOM+txGc8yrNP+SGxagffyv9vzQOpBIV
PhSZNjgn0fwBBgo8SoVzTiZHn+x71tpnUkPMcLNk0AGaudsxDA+o9IHfYP/H6f/dYORqgXFUDnNo
eawTUKNRT4/Te57KwDSZm/GqVNIj9hOV+KARnJXcVo/pnBj0yobz7lY67sLwuuulYBM8kek/gOZS
qC+iuVRCK6gBHLJ/anKTHpMxGl9RmgrRM7/riY0Q5fQTMJX+vcfixO+h6X4Vy4FwKG35Il373XFO
RcTvkyZ6nLbPdzzPxWHXKhPXS1f6cXTO9UrjBxV7WqgpngjXLwL58SnThX4PrdwbQCepbQUJmGoE
8qNX/+02sBXulGG5MuPVwXFHkBh4JQVFeKfKjhB6bVUaMoiPeT+o5Puqp5K/88OvTiwKi+w2UgIt
Wq8joeDtSisiDNP2v6P5l1QPk1TPnSBT3AkcDnswKn+Yqqe2oGtKbXt7YA9JjI+foO2fo20yOdKD
yXg5LuccHA4ymA3DL9kF1/2FVE6as2xI6+EnkVAvp/l94brE5YeE8/1Gk3NZbVfRtFjhZKdjAJro
dS+1DBgJKe7RjpeC+BOFqQVM0QzKr9J0gcNp8jJdc0FSYaRRhIo3uVe7z0Ql5MH6FdYlzqWzfm0l
75f3/0oMcxhIpDErS6UtEVeSkypMsTxDND1Nm/Q0dS+EndlN2nHvDxvKe+me/1Mrv10qD4x89+T3
KEnULRDYDEeH20iAUKar+2Eo0FdYz0m9ZfChXM2n8Hs68HqF96130gzoTeGmaTQ1icTzfY9qnJrh
H33cL8TfUntLjX6RBl3u2F8NT70bLcYlIEBPmJnTaNKT4oxSwU/itXt4DYlfpH9btLZ0NnDRj4G3
Msd8aWyN9XxNkRYJtUZUY/eERmp0ai68jwi72IFwPRdXNZoMWsgKReUSvDOGU7YzhkfDCDOsXIOF
8LCzLAXxNZoWpI1SlCmf/9FywJ1sYO3kcZYGGlfPkxEbRzLWvcdgqdCAk0eGuLpTayCycUzRX1kb
MC0FWfZKTxJMkee9RkIvG9xrtN6zfwq5Sf6fo7R5MFBgdThJQRuONbBkMswqfYzljYN1GYb6R63y
RtH2cY6hWMMpWUIFUfRKXhGuTLQYh6c1mkwakrMVhSjoPQRIdmBNOA2H75h2lwsJrxTjsCZ+d6G0
8wtWQ7O8xCLKYGriYEEQBrWYeSHvjwEsSARfQo8/uLtqMSNknqLWeHC44xhaH6WV4bOG3cQ1Ro7t
FLAnhCSn6cJMf1emnEnhK5Ig3xc2itMlqxJqcLn96/s1T645DRoVz8rnpg7TXxE+NfneHtZ5kVT6
RtMVKPlWlg+/JKTgWhQEEOoTgedodUYVgs+Ey2OtLABbtaqVmHIsvVM9vdMY4x0DLdbkcME3S+Yh
6q61lG2jWCFJLiCvd5XikIN3k5j6JFr/qOZAkZr24fC8knY9OkdsZ51cSVw3QQ0xIXSQFcO9TVb5
bdI/h1hVGK6IefW2lGdUqARNF6WcVeFzhoJ+X+04g0y6cEeoxeo0CZL/DoUkn8hWKwHnSGeYbnDg
WAvGDDhiWS52el2DY6QhFg5Fk/ytIXSaVlMjeBbScx0evousxEO1YKUhQ50lhrd8r3UoKcXE6Byh
uGKhBVqlhaYxNFizPItf0pa3a4xCO8p7gOpBUkoirJfRGrbqC+/RY3H+B1psVIWUf1AhJEBcSI1K
9mC/fGekbjZ/99N0nOJ4BUwQci65ZIUnMWInnrEax6dZly+GXLCO7YSCQmveRgzE2YlRo86dbXkh
P6bdc3eIV7tp/QSafmtV8FrDw5f87gwN2wnxhNBBgngGgCv/oIP6MzcfQxse1+610DrhAvtcjQr8
MP0/TNu3JDxySQgro+1nhl5et/mQFe8jFOQ8x+JgZXkf7KRka0nILW4VU2M00xTDNE2jyt9kOuxK
Q0Mkhudd8ntU2rEPpAQmKbif0+apNF0ed+0xzhSHWTUnDbXXtWF0Z9H8GqYSumnbv8Q8LKqeaq75
OrGw73F+BJYbaJxYrNIb+D1alGM9L4NgTKk+7vJwK87nIat8r6Rjz9K0aLT9YHrouyyhfEIT2GeS
9BZiJP37jSMvy/8A+ckZvgHKn/waxucC+IEagSAkNLor9RnyGvvlGUH20l+hAjv+2FdetuQTJnKb
5KE/RdOPIXBPnxhi7JJWsPKLCz9wB/DDrcoVHdzyexB8JmVi+Az/ETasP8WfRpSJ8XUHkeSlkRqc
UMfK2I8TafnyiJEJodRdyluX+viXOv84mn+A5mN1IywsHwl5pBE4g6FV+1R6OBFSiAJk4v1FdL8R
4TF/pGOkSzxKAroAglyN/xyjEIGPKAMeyQgUKK/zsYC+M+pmhnIqJfe9gY49L2CCVEP8hBJYUJ5l
6YtopWPPo9I6A2Vmr4Dp4jT7eTSPoOi/0vZTFUwLAuY+SM92BW37blz/tSjkxgvb6XttC8akDaVF
/hnteserLs5pgFKlIaxLRRaKWFPmlFAlDpgLFBebVEboWsbN4RFSeH4csiLR4x4fChBHxG8OPYTM
QAT1+7iabEMrWb8jFLQUwW/QkkJh7s/Tu/1ZE1KpId9tOb5kI3yXtu1MBTv4SMFdiq0xbAmF47+o
nis55wBauJH5ZOUXlB0j4PuxhzOp2n7tVXrUoG8Bv9Pu/h1af5p995rC5EmhFvhPoyAfYIVKazrY
r7jgZHf+4RDvW8JhZvpBc7TBLJrfoCWi7IrpyOQcCUVuqGgUBYOYPxg7RaKzMQo5cjy/ifuFoSCS
8yI/gl6OBEnwbu34Y9X7J/ulcfzekIpzOJ3iZ19J26R3c7lRJwE0uTPUxGU2uZF+zSRGxrOyZBUi
2jM0zu+N/B5aL/+I/DJOLQp5NFpfunvlC0gv1itOloAPyf2yMtgQLqXlSSEbUSB56KOTV5NgPEbd
9m20r4+5hnQJT9fYmu3pz4zj9eqagIepa8hwAVnhkaMlqImrQ0eQ9PZJYRgd0ocDNF9FV5LvJz8z
OGiF0RIswD+G791nD8mzepVxGERrRr+ZqucijE/HrUXl9UwZ3v8OQSBUSxg+OzKMVVkbjpwaCL/S
fJYKUUBl7EtjmSCj2Eb7lymNGkCsVB1oSfV/qdLUCfX+p9L6+JDxkTSshG2zlDIKIhxB+UCECrbq
ofIp0jtuZMYG0LNLf4MK5ZDe4hNom3RE3VtrQv5/BRgAcKtc5z2U87AAAAAASUVORK5CYII=
--f403045d97121f346b0550d5259c
Content-Type: image/png; name="fr-live-2017.png"
Content-Disposition: inline; filename="fr-live-2017.png"
Content-Transfer-Encoding: base64
Content-ID: 
X-Attachment-Id: 70f95eeb40216005_0.0.1.2

iVBORw0KGgoAAAANSUhEUgAAAZAAAACGCAYAAADzR9z+AAAABGdBTUEAALGPC/xhBQAAACBjSFJN
AAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAACXBIWXMAAAsTAAALEwEAmpwY
AAABy2lUWHRYTUw6Y29tLmFkb2JlLnhtcAAAAAAAPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpu
czptZXRhLyIgeDp4bXB0az0iWE1QIENvcmUgNS40LjAiPgogICA8cmRmOlJERiB4bWxuczpyZGY9
Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPgogICAgICA8cmRm
OkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczp0aWZmPSJodHRwOi8v
bnMuYWRvYmUuY29tL3RpZmYvMS4wLyIKICAgICAgICAgICAgeG1sbnM6eG1wPSJodHRwOi8vbnMu
YWRvYmUuY29tL3hhcC8xLjAvIj4KICAgICAgICAgPHRpZmY6T3JpZW50YXRpb24+MTwvdGlmZjpP
cmllbnRhdGlvbj4KICAgICAgICAgPHhtcDpDcmVhdG9yVG9vbD5BZG9iZSBJbWFnZVJlYWR5PC94
bXA6Q3JlYXRvclRvb2w+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICA8L3JkZjpSREY+Cjwv
eDp4bXBtZXRhPgqyI37xAABAAElEQVR4Aey9B2Bk5Xku/EzTzEgzo977antvbGPZBkvvYDBuuJfE
N/nxHyex48QtiePfSRz/jq9rANvEBVwwGFhY2rLL9t6reu/SSJoZacp9nm90xLDWGrjGDnH07o7m
zDlfP+e8/X0/G4AEP1MwtQJTKzC1AlMrMLUCb2gFnKmlXTY3HDYnKcoUTUldl6njqRX4Y12BsXgY
cf4T2BwOpCXcgN2G0Yw0uIZHoUtj/jQ4wlE4R2MGM+i3LZaAa4TXYUM0zYFohgvOEMuExhBzJX+b
MmzDlkgg6nUhxnLO4TE4orGJMvaxOJwjY2yFXdnYVrpLTcI1xHOsF3faEXU7YI/G4WD/NqKmuIPl
vMRTDjvrRmEfi5k6CdaPs++Y28452GFjHY3JHosjoQ4IGkPMk0R7GovaNX2zzTFfGtnpBNKCmhf7
Yd9aixj7T5j2YnBEYqaOdV3tJVwsR9B8NWYb56Rjgfq2QP3obFxtqRw/BjQnrZnXwUZYanysGr8j
Emd/nN84aP4xrQnXW+XMenL+mvsY105Vdd/0W2DWi3Mw91D3h2soMG1wDTW/BD8OtuHivONOB9fB
Zc6Z+xkeM+NVfY3NHgwhFg2ZNvRHvZhZiHDEEtGJC1MHUyswtQL/M1bAJjRA5JBIvILs3ujMJxCJ
cOnFzaTz3MgbbfH3UF504/WiuIvmQdSOV9A4fxB/Y4yfcZiYv3XiUt9Wu/rW56LxWJdfVf11N/6q
Wm/8x+vsx+ZMQyKaJLKmisuWhrHEKG6c/nbkpucjGo/yedKlKZhagakV+ONcAXLriRgOte3BqZ5D
ZoqFq9fhyqF5gN+JXTdVYvHLbUhrH8XOWysxo7YfZS90wzYUx8mPVhObJjD3O/WI5znQN92HrddW
YOXJblT/ZxvCM93Yf0slMsjhz3+yGe4jYXS8uwBPrijG1Wyz5MUeBKu92H17JfyUIBb9vBFpQs+1
cZz9UBkaS31Y83gDfA0hw5WfuKEULnLyM55ug4vcfawngca7irBzbi6uONSF0pe7YSc3nyCRCs7w
4sLqAjSVZsAVjmHZng4UHOlHIo3cc2MMQ4vTcega9hFIw5W72pB/oB92EpZoRwJH/2waBilRrPxZ
A9JbIxjLd1IysOHstaU4WOJHKedTc7IX5Xt74OyIYrTQheZVuTg3LwdDaXa4R+PwxhMobBlCRmcE
TkoQ+XVBuMT1k6g6wnFEYzYM5brh7RqFm3OP55M0jXA+mwqwc0GeBAL4+HFTIph2uh/lu7rhGowh
nm03UoVjIIaOZVnYsbYExZQOlv6qAd6OUYQDThy4tQLFvSFMu78F0RpSOI7FHoojVO7BnqvLsXRH
GzJPDRlprG9RAKe4fjaPHR2ZbsxvC2L2P9Sh95Zs7GXbYUpDK/Z3oOgXXRhemo69N1YgjQuVt+Uo
dj/zPdjd6YhHRmBkOUkfIiB5GYUo9JeQgEiknCIgf5yIY2pW/9NXQCoHvd8iIP7ewMRyeLKzURwr
RnB6JnxlZSi1EwH54ygoIQE570QWVTyRQidc1TWoONuPwsIo2ASCq8pRVJqHaWfsKPDZcYYEZ3hJ
AarO9qGIBUbemYG+TWUkTmOY1z4MR046ukk8XDVZWPlME/K9xYYwNf1JAYZYb9OhDpR25CBSmYZz
N5SgjMSqam8XvK5ihMvTUPeRYtTNyMa6piAWtIXgdqVheJoHbctz0VqTiSEixBm9Ycw+24n8tgDs
Hh9GiWAHNgXQsLIQXqqQbjnXhwpeS7N5EclwovG+YtQuLcS6s72o6hjGwAY/mq4oQl+Bl/jdhk1d
I6g+04WsUx7EfWXovyKAjkW56CjKQIDjm0PEXUwi6+sKw9tDFV+I6iQicFfIC1t/HKO5TkTLnBit
dCNeSOTLVfe0jcBznuqgTCD7JFCS5yFx8aAnz4s6fnqmUYV1WQjTX+5A7m4SwUwSkSIbAsMuRNIK
cHRGACFbHip+1AQbRRd3tw8tNaXIXu42xFPEz+4l0Yo7UF9cidBVhZjeXA+HKwHfqBdNM6sRyqKq
kmqrLEc/iorGkBFKR1tBOS4UkwD3B3jvPYg6XbhQWIFoFue6r9s8LzYXCVSEKjT9smweIhzR2BjG
pgiIWaSpP1Mr8Me6AtIwxIjcRUQsSMRiGKM9onGeDwM2HlOXHpzvg7tvGO4zAxiLRjE4zYtofwh5
ezsQGx3FwCI/9tT4sXpbA/K+3oL6/6cEW+ZlIkIVx9WnOtA7z40H76rGku4RLP3JeTiOhdHwwRL8
mnXe/mI9crd2UnJIoO22fByanYk1T1xA/kNd6LslC8c3FqOscQBlv+6EYySOnhUB7LitCn3U9a/e
34LKrR1wNY+i5do8HLiiBO05bjhJHWfV92LRw5RgtpMQXBdA7U3F6MxPx+ksD1bVD2DZMy0IbBnC
6BISI9Y9vTgfQ2T9b3r6Aop+3onmW/Lw4roy9HocWEwiNf9AF/J/0oPRuWloWZWNpjnZOFbiwyDt
FqvaScR+2Qj/E0MIb/DQduTEMHlvr4241OdA0+IsDFX70Evi2+t0ooX2hZBsHewvcziKyj7aoGjT
KAyGUXSiHzP+/wZU1zhRvikXx0lMt5WQmFxfgkVlaSjf0QU3pY20gTDm338GsXur8fjsLDivGkLV
L9qR92wbRgcjGMyzI2vnEGKUDpFOVqGNwkFDH7YsLUDWhkyUbmU758dQ2DGAI/5s5A+FETjahUge
bSkkhGlDIwiNusx3ND6KGCUgX0cQbbSD9BZId0eaMS5fGAKSNIUkuRI9WOYzJYFY79XU99QK/NGt
gCQQ/bPefU0wPRLF0OwMXCjNxKILfbCPJrD38lJMP98PG5G8TSqiigwUEkml1RNB5rhwakMpqokE
y3b3InJFOk4tK8TinjCqDnUj/XQIh99ZjXKqdhZvbYW3fhT912Rh/7Ii3HqoE6VPkZuN2NBzTQ6O
8tzaF5qR/VAfWv5XKQ4tL8SMM30of7ILNqqf+ucHsPO2agRoxF732Hn4T1KSoTqr68pc7KF0EyRy
K+uPIEICMlPSyvYIpYoynFySjx5KJKOc6pVHujHrwUbYWajz3nzUrsjH/vIApgUjuOqhC/CcDqP+
Q+V4YWEByqiuWkcVV9Fz3XAfH0P7vbk4uLEUnQE3emk0X9RJieREL/J39cLmtqH+M+U4NScXozS4
R0VAOOcYJZBaOiNkcJzVoVFUE/HPaRgwhvyhbKqxKJE5WW6IhO9gWSZiFVlYMjcH8x5tRNXXWpF7
ZRAlJB5nOMbHV5Vg3uwczDrRg+LdPfDWRjB3SwsG7vZg/5oSqvYSKHuyEyXHBzBS4MaZD1QYlVfp
oR4ESLzzW4ZRMydKolSIrNphBLh+RUf6cLwmGxVNQyh6sRfxHCfcA3EU1lEFl+9DVkcIJEGIUbxx
cF2jdFoY4XwElpF+nICYc6/8Scq4r/yeOppagTeyAuPcSdI9441UnCr7X7kC8oiKZjoRIXfsaw/B
ezaCKurz3dThO5uiiCzzoKXIh7mUPpxtMbTcUoAwPZ5WPVQLd9Momu4sxBCRzNqfnoeT6q8976pG
O5H32hebkbt3AJFpbhy6thyzmgdQ80AzRqspAVxdhOb8DCw40onMxwdw+vOV2LqoANfta0f1z1rp
GQb0z/Zh1w2VHEsQMx5uNvYQGaB7FwZwaFMpBkg8atqHsJC2lIE5fpxeXwzPynycKfaT+NgRpopp
DfX5M7/YhMHb/KhdW4hj1ZnopL1jPSWcWY8203aSgT1vn4ZWSgpLLwxg5kttCLw8hNB8qsY+noeD
q4sQoeRQ0h/GEiHjJ1oxPCcDp99eQRsCy5AIyKmqksQzl8Qlr2PEEIiVfgfcrWGkHxyBq5u2ZRKV
OCWE3jk++Nt4fm+Ytng7Zl+TgVN3VWC/VHD3TkfBbWH4mkdQ9nwnKtK7EKpKx4Vp2XhyNQnJ9Cws
eL4V+U/1YXFuM567qQo7Scgvo8RU9SzvTZCSYqEXOyoz8Taq8gJ1JCDP92Ix57b9skJEsylFkDnw
DowhQFtLbUUAJSsykXN0gJSBajdKRmm038jOlXAmX2ZL4ohzPQ2Mv+OTE5D/yqf4j7hvG33qyMdJ
Z/jWBbEcFryi3Uh6jOihkfLWGr/K6ljnBPqtY31U1nIpsY556jfAKpvatuql/lYla1ypY/qNxqZO
/E4rEE0gRhXMKJFEnESElm2M0r01Qa470Qucp0rJzWc4sCuI0BI3mqsCWPByOzw0CI9mOdFVHUAd
XWQHZvqQ0RJCQ44XZZRO8rb3IU4p4uidlQgMRDCLOvsE9fPnrytBW146Vj9aB9/WYTR+vBjPk/u/
YXcbKqmSsXspncyjiowG+pl1/aj5dhPiVURZQ0DP4gAObKYxPNeLpbS1zH2sGb4zsic4cJYcubvQ
YYzXfiLQctpdqp7pQN2nynB0YR4G6L46q3MYa2sHUUgJouGaIjw/Pw/zqL656ZHzCJwZhrMuis63
5eKIVGOcv5fS2cYn65F9eBBjRNQ9a3Kwe3kRWjPTkEmpqJT9lLUNo+LlTqRfCMNBtY+DDge2PhLl
HAdtPrm4sCAXLpYdod2hL9uDdLrVlpFYeeQiTYN6lFg6g+9DlCqtgyUBxCmR5C+i3ehwJ8r/tQ15
S3tQcUUedtHI3Usnhyu4poW/7MHqIi92kjAc4CdAolPweC+qZ3djd1kAA9No/N9C54cM3k4ShjgJ
glRrCd5Xd88oClpH8PKMLMxYnIO8HXI2AMJ5lNh4Xe+x7pPmUkCieG4eX8xAUoVlrP182KYIyO/0
xr12ZRm3RDjop4DoKF9Muv45pKh9KwKHZesmhhZS54OT8GvwyYHaBnmSXAsCNOTxGp9283IwcChZ
jkXtfFlkuEt4qByhmsBGsVpt6NtG0djMerw9/dBhIosVVXaYZWUkpDrA9BVigfHf4oT0IqqGKW+1
kRza1N83aQVGSfEHiNhcvKeSQGI0mA+lpyFIhBf991nGW2fV1iY4Oil93FaATBKDnH3kWomUpPpq
p43h7r2tRIYxBIu9pD+MqYhTlRNwkFiUIkTEeNkjDfTsiqLrhhwcn5aFq56oh+8wde6Ubs7Ny8VV
NKBX/rQNNj+Jx4IAnrm5CjNo1J72g2bEpznNM9Z9WSZ2kKjIFrKgfhCzt7bA00sixvG2zslCBseT
oNS0+DA9tJ7rgmsgilP3VmLvrGyk87FaerIHs39Iz69TUZz9TAVeovdTBdVJS+jRlHWEthF6VzW8
twjHaXBvp3RTTWliAT2YCh7owdB1GdhHO8xZGplz2McVUik1DiJwIoj056jjK7EjVuzA4PQMDNMo
HiXCbavy41QxDfkkPNms42dfUgFFKK2dmpODTs5D0gv/YjqN9ct/VEsvtQxsp+dUQ5YbDbTHXJXu
RM1DLSh/vAOe4Bj2XFmGl6+uwBV8t6q/3AjHfTE8vaEcrUtykLtnAAF6Wy1dNcxx+lA5x4vMg0OG
KYhR/dZLop3r7qOhP248wQKUNjJ4v8UwjFHK6i4jteEzYNMrp/easSjpjO9p45jzx2NeOFwDUwRk
fCHezC8RDLsINRc8GmJQ1gAfqDM25M4YgX9aAsN9HnpNWLfgzez5d2hLDws5mvZr8xHhg+4iEsij
PjVtiFwLH5rOtTl0FXQh92wQforE4WI3OtZlwkm1Rz5FX1ffGHpWZaJ5djaGaSiUi2LZ2QEUvtxL
9UA6ejdSnSDETxHeADlcHeWdoGqjyI2+onTknR+E7+wIutjXCFUC2eeDyDwzRM+fNHSuyzKumkX7
emGnO6QecNNAsrWpv6+5ApJ+Lwad4cdQcnKevO+dlBpqqKf3nx1GnMTfySC2Ma51Mb2WZjaOwFcb
QnghjakkFtP2dRG7JOjF5MDJKwpRQjVS2b+3YHReGp6+by7cREyZtC/s+1AN+hmkuOGRWuruw+hf
48fOK8tRQ9fRLCK7KJmOCzcWUe1DQvHTFthy+c7QQH1kU4nhcGfS6I0sehT1xTBYnY5dV5UZxLbp
pWaU7OiBg8Z/kNtvvaEA+yhhCBsvpTfVtO83kwmh5PPeahyamY1C2jWW085SsKePBIZew58oxsHF
efDyGV5IFZf/HOccsKGbUs+uNcUYITKdf6Ef8x9tQsaREAZu9+PolaWo57NaNDSKZdtbUbCtF2kn
aNu5MxP1f1lCu1EcvXRDbqzwo5cEomhwFBWtQWw618/gyCgy6TXmHOQ7RUlJCDxGaa+vymeYNgVA
ZteSEDXRk6s+jBW5LvSQ+PT63Ni+MB++q0IoojRR+IMuLOGaP7+xHPsohS2i2jG9NYRKOjecpGqu
ZBW9p35Cd+MVvTi+vgwdS7Ph30WxjcRc7tCDtL/EyZzZKFk4qcJKcL0cXBtDLMJUYfGpYMhm8tlg
nIpctb21I7iZkmF7ZAidvKKgTikDJicgqjsFb2gFUiWNWJSc3ElyIt1xBJbFMWtdJ1Z8if7vFQ34
2b+vQV9DOjy5coF8iyy0uAw+zEOlfDnXlWKYhkCEYrhpYBTePf2IUh1wehndBvni3DbShKyXBxGi
/vnptaUoptfOVRTrQwv8ePr6KhIh+sMTcYi7usCX6CqK5xGqDLZQrUAPT6PV0sKKXg0Sd91G9Uf/
oiw8OacAt6ER6fScOb88H3toOFxT3IeVJ84jnJ2Gbewrky/Adcdp0A1SmtGT+5sYUU1PwSQrYJcx
wSAFXaREN/GPN4VraSf+CFH6aKTefC29jpz9ZH7yGD2e7qYjjx0l+wfhoA4/6neh7vYyDJCLTXuq
E86IHU3XFcLhcGI+bRCOUnLcm4rZhwMbf14HRzCGc/fOwJIT3cjZOoLg5kzsuX2acX1d8GQbEmQU
Tr2tHB30krriB+fgpLttfMyGpltL0UhD7rXPNiLzAiOrfU4Mzk/HPkokbhK0Vb+qR852GqTL6S5L
d9LeDdnYv7ECWZSMl29rQdHzPUiQ8ThzezmOzsmDj8/O/ON9KH2snwTQizNXl+LEzCy4yNBsoE2n
4mmWp6Rl74lhgC7Cgz4PVpBoznmE0g3Pdd1RgN0kesOcf4BEYuGRXpQ91otYpQst9xVi7+piDJBx
srM9KRgyqZ5aRyN7KT2nPHUR2kvoljuX9g2Pi0RiyBi9EyQYMk4XnR9O3hq+FDo3RnuMYyiGyie7
Ma2jE4MrMuC8k3aOq6uxkPEoVS91INA1Bh/nPZKbjhevmYZ0vmdSDNjcTpzZVE5DeYRMHI35vC+h
DDKsmRx3f5QxJlS/lWcike+G+wK96SjNDHjd6JqXh6Jd/Ujj+5hOZ4SxHEoh5PgUUa9oe08XVY8/
bea82rCHd1fZAy5NQPRivkVwG0fylgY7nxYbuelomFxT0IGhU/TTLgxhybuHMWNhC2YtPIui8nqk
Zfbj7L71qN2RA08R6TvX1wT+vwXW2eBhPigDNLzJyJdFPe0gCUGYD1mCz7ZARrVCcmp6QaSyUBqG
HHIvXp5PUIweJPFppyh+ZT310T+op+tkCZ6gZ0370lzMeKgRdw5dQJxBS/uvKTftLX+6yUgS0jf3
09URbMtB7kh4zsU2S/lCdNEHP0hDpURov/pS32awpompP29gBUbGho3brh43LaEISJyR56MxYqHx
ZU2EQkSgPRgIDyIYG8SIh5LjGNUzTWMYtAVhT4uhaTWJeyFQ1t1rzo1FI2jOykX2iSZEOnowSM+s
+uwxVO+thZMG7xOfqUI02If03fVUj4VQN50cdXgA60kAYs8H0fShAjzN9q49WIexc3QlzXUglJ+G
o3lx1BxvhPe5egS95IjDoAdRNi5Eh3Dt041wvdiHvgoSj5ERpvBw4PDcfAwOkOHY0w4/CdswuZWe
aj+O5cZIALqR2xWC/6VGBDMiuLDYj70FVNv09aCSNoicnzQhmEv1Mt/hrpWZOBegi2tdKwqfbECs
aRj1q7JwdJEXwxy3g95oJfWUnOgB1Uc6Wb+SRvu5RNDD/cimhOQbHEN6XwSlDALMOhhk/IkNdZvz
cHZBNt2CKSlEnche4L40etUN4vtUeprEjswbplMKPBxEZcEoGqnK2lXpQOvVmQhQkgHHj6ANLuIf
IfRCSi9jdOttIoGtyQwhRKks0uuDs7kTQ4MDiHeG4erKRJBxMO0e2qZcg4jVU7hr8SJM1934GJna
bAfyyaQV0gHBMqDbpLpmd3ILTgyOGyMNAruUBMI5TMFrrADXVHaNUI8DkVMJ+JczUnZNF5b+bQcN
WPW8AXvhzmEbSndAJi9MI+Tj9y/FWJiBWETEo702ePkQx+Xz919NRMRpDFG1VpmOAXIbM1uHMUbk
3UOOtJAvooiKvDAmBCZhIIJyF40fmuucJsIMSnKcjaLkFF0wK8nh0XDn7h1D3n6qKqijtl1jqiLn
XBDOTnql0DZiDLY8Lb5YoHbV1iC5qY5FVD3QbdH0RdXgFLzxFZBbfutgIx47/yMUeyvoXvpK/oyB
0T7eWK49lz64dRvizx/BtjIvjnSHMHjMg3C9EwWn+vFr3psQ3UMHdlFt+UwYjbR/dLeHqWpk8Nv9
aQxIjOAAVTQjY24Mf9eF0nOdOBjwo/9HtKlQxbSVxt1R5m/q2eJD9reC2DYcQiSQjuCWNHi22nDo
wiDLMwCvJY4B2k/CX3chTKmlkUGCytU0kktbzI/TkdUwiN39VGtmU+1zhKpiSgODRR6Evu8hUh3C
8a5e7M3Khq2VLr5RP+zHWIYR6aN1A1S9sB16hfU9ydiWR6MIUw2TaOjHaS+DAzvoosoI/CF7JnCA
xuVjfXiJeUZG/HwPTjPY8nSCtoeIUTsl2tpRhwC6ymjX2E7p4KmIUel4OiKIDjWDaB9N8CHsZ7Ch
i+M84AF2krAwd9gAVXNNbimJLgF6xDnfI/wKNAfh7Wd+KqrSnPePYugJLx0anNjnZ3ssk/Ykqao8
pXh/HZzjUHMv+qpzMcbfW7oZX0LVc3iPG8+yTCZjPWx7yOjVe2kgt+NRrlt27whij9sR2sdI9bEB
zM5/JzzufHptDfFaxNgz7T1xdK7IxhBV1tOe47MiY42B5PeUCmt8Od7olzjlKEXE0oVBXPb/1mPe
ZWeRX3wBaZ4g2XW2NsZkbyFSbCans6cN4tCu23Di/hxkruGNKxxG5rJRnHkhF94c6kMnMPMbHcWb
U15SxRgfzH56tKSTuBWcH8AA0y100VAYpweJjWqBS4Gu2Cg7Z5NTK6VeuLYwA7EvzcLMXR245Run
OHeuUxEJB7mYODlFU551dBzLou6VOleTVM4iotJt8Vg+/j6Oq50BW/7sIDxUQejSFLyxFZDlQ5km
sr25Rm/YNtw4eQO8MWPMBdIf50NdB6PnRnOyqHTeBnjg4EfkR0hSH5Ax0oeoJQltya8mMarkejGY
5KHYqjm2nUiW7RMOHWRFXheQ+Z84JvY1rESbzqkzPTStPMeP6Vd1+0zvPCBwnHZ+1NQgc0Gif1xs
Pm1oo1G1dKgtfTgkfSh3GWgVBiQeNn1wkI4Os0zJ+esaX2dhc1VVMUGj+hjjL3L2DvarIeqjNgco
LRmI0+YQ1CfJpUvdQyYeukz0b/hK8ZZq92LQdAVmPjqgvcZwVBwb+BFzJdBpC9RWs8ZLQimgbJKE
8QNaq5JQm/xSXTUncDQk5xwr5BvG/wlqCkR8tHD2jhg652ehhYxC5TM0vFuDS1a9hA1k/OLU1+Qr
IAP4GIlDRnYYH/rsL1FQc+6VBz3GNAW0H9htydtrdw+iq3EaHv/GLARW88butOE9Tx1BaeVJfGnX
vfTMcjG1ANVA8ckepcn7fzPPJvicyCgdLvOgg0FC+TT6FR4bQCPtEP30ABllcFFaG71GLtGpHqh4
uh2B3YO4IrcF++mnfpZGxI7rPViaT93ylo6kl5awPwnCxCx5LO4p2TDPWh3oASZ3JSmtsHEIjdMD
qCRH7KFaK0zubQre2ApIVSWJI4sEZGXJBuxpfZGpPHx0fBM641pTjTVhXifnaqPOXKAssjFym/lF
BQj4fAZx9PSSw+2nDSqNGFzqRt4TqW9jbCObaVBy+YmLQ+U5615LsrFRZTIWjqCluRUxqlfYTTJj
LQ+Ky+ga7CFKJYOQ4DOhMpEo0SHvtV3cdSyKjAwfCgrz2S4fVjY/kcWW4xyj2mVgcBCDoeEkcqO7
rYsR36XlZaZfjS84RMNvO5G9nkH2WVJeyj7dGKH6q721XYuQVClrraie1Q8xVXGOIzc7F1l5OWZe
vMJhkiNnW6EI+7OTIeI4y4uKkJZGSYnX7Kzb19uHnl4a90m49VrHKJUX5tOFl9JUUzMpDiWywmLO
2+1GN9d0ZJht0clAmQDcXi+K8vPh0FxT3xe2O8a1GAgGMcj5aK30MmlMZWzL9M97Ytae51RXYKO0
0dvD+6bxMJdVjL9NPd47o45muzYXKeKoiC5b07ypvh6kK2+chnq1YuOahDgH2cRs9VrEVyD5tLzy
e+rodayAnRz30E7g9h+eQUHlOUoaftYSwVASyhHznJtmlBqbL+/u59eic0cG3DV0IfxID+Ysfg6e
zDFs+mA9fvmns5Czni+rxRK9jv7f1CJ6gIIJjC73oIsqhlzaHkarPDSOxhBKo08/8/YUNKdwe3pi
U8D85FMWp6tm/qM9WNsSxlkaUevK/NhGw+I6Ioyqx9uRoE//pSH5MpjrLCaV2QhVacUMYhtk5HML
VQUhvlBOIaff1sylO/gffUUEwkW3wPLMakNAIvEQz6QQDmt1uL4JIW+COOaMjAx0tbdjgnvlORGK
vr6kvCHkIo7VnCOCEpJ6LbBR2pbXjxBdnPe5uYnixkUgZDjKNClq30uEOjQcxBD1+78NcnJy0Etk
bNWtq6t9VXEfieAQEa8abWpseNU1qfgM4dPZ5PQ1LWRlZaGHdgZ9LgYPiV44TCmEBKup4dXtqazq
9pPYqr9cfybaWyg+pUBH6yu/rbFrriESiAZ+fhtkZmZiYGCAuCa5lpP1f3H9ifs2jv+1trrHNlJ4
x9grsoyIdpCMYy/f/WF+i+Vz0q4TLKBTEGN9bNQYpL6DUwTk4pV+jd8ymo90OjHz7X1YseHn5gGR
cGqzSYgl6M4QyUl1ZUsbRsvZJXj+uxXwL6O7Y1Mcm99+DJ4sPqUsvu66Z3DoNubpueBHmp/62P8C
VZasGLJB9BXQM4zMSTvtHsdvnIYccijinobL02F7mW6PIjSamzgbEQM9R0I4PLRRgum+LAtnmTZi
JrOjLvv388h4fyUOzMlFA4OUinJ64OFDmPrgaaleATZiAYUMEZA2+r2nM09TCYO9jtJX3s2+THSs
VW7q+3WvAO8cpQQGg/mKUe6bhqahWsMdX2r7BjuJtRDuIDn7f/mXf8HGjRsNsnr44YfxpS99iUn3
6BxBwiKwjj/1qU/h7rvvNkjVQmy6LmLhYuK9lpYWfPCDH0RXV5dp2yBzXv/Rj36EWbNmkSmPIRKJ
4JOf/CR2795tiJeDXLnGcO+99+IjH/mIaUflDAFiXV1Xu1//+tfx/PPPT4xlxYoVZtzi8NX3li1b
oPGlp6ebdr/3ve+huroaR48exbve9S7TnkV4NGZBQUEBOjs78Xd/93e47bbbzLzUlsbzb//2b3js
scdMexqP1qW8vNyMX4Tll7/8Jb7whS8w2WQhJSS6t9Mx4R/+4R9w7bXXGoKo8ateE4nnn/7pn6K+
vh5lTF7ZTOnklltuwZ//+Z8jEAggytxj1lydyqPFuf7gBz/AL37xiwkClZeXh/vvv9/UF9FNBdXV
Gmh8//RP/zSxPq8qw1dPmYxp0uE+KVRddQNty+gUQaN83lESwDI7/J0hBCpZgMb9Cff58Vd2cgLC
cpd+2VO7/x92bBaNomRtHFd/5TgycolAmdXSZpM6gEFwpO6yZ0glZbOTw6NUsf2pJRhu88BBW9rS
e9owe8FzvBEq60FmYQc2v+s0vn3HZcjbwJdcLMEfEjgf0b04gwN7mQWUQ0Zl7QBWXAiiZ4Yfu2cx
HoO2kDiphFMqDXFqFG8ddXxQ15AGUhx2iKAw6G+4gIY4BoZlMU9S2XdaUUY3x4MzckydGO0dtr7x
h1vP1m8AT/K/ZZI3ajH+1uY3RfSfP8D8QNIbi7BMwf/dChhk4vRgXuGScQJCF91L7P8jAiJEKGS5
YMECLFmyxHR65AiNAQQRFwskpQhEBBYtWmSd/o3vaiJsIXCB3+830sDmzZtxxx13GKnBqrBhwwZD
QFRWhEhjqKysxOrV1P9OApdddpkhcELqn/vc50wJIdW1a9dOlBaRe/DBB3HmzBmUlJRg5cqVBrmL
IFig41QEbM1rzpw5WLx4sVXMfIvwiIBIBfbud78bV1111cTcVOD06dOmnIjQsWPH8J3vfAfve9/7
ICKQClrbZ555BnfeeachZrpWWlqKyy+//FVrYtVZvnw5tD7z5883BEr3Qeuk+aivS8GJEzQ8EVLv
26vL8r3iCyZV9vDcdJwr9SOXBMTRGzWeV3mnB+G+rABjRXRy6CKSSGPtcUmNPOcUvN4VkPQRrHdg
+cc7sXDF00kZ0JjOuIxUsNqcTL9s7BlUXbnGcPrIOmz/dhkypstbZBSbbjsIB61oibgeXIq/vBdL
1zyGRR/uxcApJxxpf2AEKYJIriKa7TSBfOJEKg/3YNo3memU+x5I2ugKUFRnBs4cukF2MT6kkSms
a+8rRz33XOiVlEAk7zkTgZeBSC662nZS3XTuk1VoZC6ibpbPpOeJp40eHfRvF2g3OX0mgFOWzUOc
jb5FhJVmQb/jDGzL3DaIKqaJkHeYOZ9SdaKNqYPXXAGpsez8VxqoFK+DUaqx7ApeugRYnK+kAgus
Y9kBLLi4nK4JsZ4/fx7nzp3D2bNnDYd9/PjxVyFo1RfBsaQVq52bbrrJNC3O2TonLt7qW2qhbdu2
mY/UOAKpdN7xjneYY/3RGEJ0SRaojXzaFG644QbzW8TRumZ9W+VMgfE/1hytfiUx6COQOsgCSTtC
4romiUFg1RHxeM973oN77rnHEA/NQ5LSj3/8Y9TV1ZmyM2bMwF/8xV+YY/1RG1o/gVSFL730kvmk
zvWjH/2oWTtJcSJ81jzUvqQarbnWX9+NjY1oGFexWeVM4+N/DLOmB4LaPVcX43yoplIutF665Icr
yVQy5kqSSV5LMvV8vJQqAvGC4+/hq0liastTx5OsABFcM3Pi3HYE8s4z0oc9+aAO95XBmcbUAF4m
gHOGmVYZ2PrwYur+XYwNAW76XD1q5u/hE0KfcRuJByER88CdFcbmu46idttaxMbIqfOOSqL8Q4EC
hYYZzEWTB3JoQPfRfW9sAbcw7R7DtHZ65dCVNsbUDuVHerCg3I8LTBy3hxGwfnpm1ZCoVB2jca7Y
hqyjg1hd1Y9z9Jo6dEUp0tnuYuUgYrSyg04HUoFJ6ap8PAaEg/QQkpba6XTgYXoHxXvYyAk5GAWf
yQCnOPtw142ZfEFtTKnhon0mqbhlvT/gGpnx/jf/Y6mx/B6mTC++CjtbnmXgmYfG9CSyutT0hOAt
EPK9FFjX9F1PlYzUTuLoLUIge0FHR9LvR6onwZVXXmkQoJC11DxC9BYnLURqtakxWONQGxs2bDD1
P/vZz+Jv/uZvTBuyOdx+++1GvaP2rboiIPp9880341//9V9NWeua9W0au8Qfq1+VtYiKNUZVsYiJ
+rCuW3V0fdOmTROc/969e82cdV6qwL/8y7804xQRqqmpwYULF8xvq76Iwfr161XcqKCk2pJkKAlr
7ty5kESofq3yImJSlf385z837YmgaNyt4/aWtrY209akf4iSEtREuLmRVgHT+Hf5yQTzdtubGFi5
OQNHGHQ5k04t9t18iXnJcgF7QwTErrDJV54ncotJjtEE0/GZMNwj4xqEAOWpNMHg8Lcpy2+B2pEb
rCDO8Uj3/6ryumDqsJ3xdvUcJ6hKUR8Cta1+BZbqyEIq1nj0W1GtSregYUu9pHrqy0LSr9fu4HAn
0LONgXJfbMCMedtJCLSKYe4PTPWUN4zWBnpCsEzlfBrHiOcOvnwjjvxvRsCuAgpnBrHu+q0ch+Yq
Q7tGLSApZ9nZNKqXr1qCupczkV5E1ZdiQ/4QIG6fuafSGWV6xS/qtEzcRIaImyonL3dUW/VYg9l7
2s2snR4+WGsGmaNnZgZzVtGYxgjjDKaFzmDahRhdfdNYb+GP61E1y4cofcbtzAjqZz4ebzf92BWC
zvtsJ2G47NEGMzMdG0MqA8fKX+jAPdzlTT7vdmYqnf1sK2ro+57RQ2J2WRrTVXTjaorR4pbsw1wf
hdwmb/0fYpX+aPqQFOK0MUYjswJokRTC2AD+0/k3E4T89+/fb5oUAbE4cp2QGsfi1IU0BUKcUgtJ
nSWELLXQD3/4Q1RXV5vrk/0R0nzqqafwV3/1V4YoqN3c3FxT1EKo+mEdi9OXncIiYpO1+dvOqR2N
c9q0aYb7l/pJEkZFBdeSMExPKktFl9qOpCMLLFXS7NmzjQpM0olUaprnwoULTfvWeK06ui4p46//
+q+NLWbmzJkTkpDKWFKaVV6EuLu725SxnB10TYTGkqCssq98830iLoh57Ug/G0bhUARHCnwYYwaI
CCPta5fkMbMEnxTh6iTam6j6ugmIEO5ID7nRkWRnUp96iOxcTB8ZbKC408TAlhzudDWDEcVE7JEh
bs4+QF0/dWWODHKSOXQbE+Fg9XAfA3ZOSKBmSuG5vBZgoA/Lj/YnEY0Iguq4/PQO4jkXd0WLM6G/
k5nQnNxhSzA2YsfQIVJ9HnunM9lXAWfHtoWkh9udGDlPrx2OI2OBPJz4knC8KjMWsjM6k8FxIob8
71W913h/RHTUX8EVw9h0y26mC2AVqm5iMQYldeQjr6SJiPNE8mHlgAa6CrHlwbnwr+I+BruBux45
i6zitldJH5qDYb8djIw9uQ6tR2nEzuOrnJxe8vIf4K/URm5y+0pGp/WTjUOGcbn4+ZmGmopyg7Cj
zN3jZWqTjBd5jkGHYMJEJTaU/UREUFuGuviQaItQWz/rcCObuK6LeGhObFPJ2TLrkz76lkpL/aeT
WGVEw6Yfqal8THNt+mWbioZNo3jkrkupp/s8BW94BUQs4uTYCn0lqMmaiwv9J3+rMf0NdzBJhVTi
IWQqBCkDvKQFC7kePHhwArGLCMh+IQIir6SLwUKYlmrKQrhS+/zqV78yxYUorXJS/YgLFyKWwVqI
2Kpzcduv9VtqIdkoZByXFCBiIsSvOZ46dQqyUVwMqURFSFyg8rt27ZogrBqvJIuLQRKNJT3IDiUp
S6DywUt4aol4CFKJRyrRNhcv/qP3SThQ7yi9rLTB1QwGTfoODqLzhjwcp1ZhJvcUSWtm6vkMFpJb
3vg7+LoIiKQHl2cMsza3wuMjtiCWdjhjaD6bg2a6p66+tw6l00PoaUvD/l+WYKSbQScrGQ5fwcAT
+koPkWDU7eMWlcNupjWwYcaGTsz98x6MEbFfOJyNxmO5qF7ahdxiKuIockhCGAm60NviQXHNINrq
c5CeEUJfWwa6z9NoR6RTODuIqz/QCrkw1x/34diWYubRIXFojGPR3S2oWcx0DL1OHHmhGHnlI/T7
juDwr8tQOIebtKzvpxu7C05HFMeeLYFDtr1LERGel22ie6cT937/PEqmHSVRpIHPwf2A7VHklzYR
6RNJUhpx0vVN7ex+/kq0bKNnVTkw//39WLb2ccSYVDHCbS7T/USOhBhTGjicdJmlx94zP12CoTo3
shZTBxkmcbvkYEzVN/2PkHh83M3WZOAc7yFGBC6Kr3P6CLkrmyfyWIBSgHJSkaE1xEJDFuGJMiAR
es752xi9RTxSQFyOILUfSRRK9y0JQ/V0POH1pXZFgyapZxqa+vOGVkDSRprDjbkFiw0BkURyKWP6
G2o4pbCM3kKQQuL6SAqRPl52ChmlZcfYsGHDhLpKSF52jQ984APGS8pSEaUSH6t5ERXZSYSsRYQs
xCvuXl5TAqtfHUsNpHZU3nIGsIiLrr8RENJWXREkzVGESN5SIl7yoLIIiEWgZLy35qJ+rH4tA71l
tFd5tXkxyNlA9pPp06cbbzGrrT179uDXv/61KW61oR8iFF/96leNNKQ25VmmccmDTWtzsTQ40R/n
xNRlZtfHEe5/0sT8ZzXce8W/g270TOMigX+Y8S4RZgMYYrwY6vVO8iR579ckIEYnz8klyKXe+N5t
KK06zRwrZECJdJ979GZceXcUKzc/yQ3WideJTC6/djnu/8x6bLzzKFZs3IowGcc09tlSvxTf/tQ1
WPDOHtz23u9wMpox3Ubrp+Mrd9+B9bcdw9IrXsAw7WJqu72J+We2L8VVb38eA7058GVy5y97AR7+
1u3obPDiw5/9BTJzGgzHnrgd2HX5rbj/rkV493+ewvrrH1b4hTFYT5t3NQI5ET5o3Tj9yLV432df
REHxAex78UZEGS1+9KliDoQ3T9iL/y8GO/cPHuni/gFv68dl618wl20kFsGeHBrMY0gP0B+bLLYr
jROiNNFWOw9bvzMNGXOoIuCmO9e98yA82ZSwBv1wurhIQrKjIpJ0ZXCO4OjeG3HwG3nI28Skg/Rw
cNAQb6PdxAQKXTyY3+PvVIRudWMhdI1Z0ejypqrlvsrKVZXbQH91ekcpg2rxS0w1Mi5pGNdeq4FJ
vs0ysz0RhYn2ue7m2Cr/Wr+tcm/0W/3yI5hsvskrf9x/RUA4e7r0FsHnCmCIua6UaDF1a9vfZQXE
NUuyWLVq1auaEdcuEJITSCIQCKmKgMg1VZ5UQq7Lli0zaiLL60vlLAQrNdQjjzxikKOFqGVovuaa
a4x0IFfXVFD7TzzxhEHu8m6SK+2lVTmpNX/zWATk5MmTkM1Crs1S02kMMk5bhu/UWkLYltSRet4i
JJc6Z82ruroaDzzwgEH8Vtl9+/ZN2FF0TuttlVdfF3uMifhYkpwIymRE2dgnJewRX/XekIXzTCmz
kAk15cQSJaHoI/5f1BeCpz2CumXkHnewX0opr4uACLdGqbbKLIgiO/80oz5X44mHFlMSIdJkDoOr
3/4Y2huX4tmfLcf8VU1YvPEprLmjgno7xkYQp/7iGx/BvOV1WHzlM7jqvbOwZNUu3sBCPPXwVcjO
Y379QR9izIeU7o9gZCgfj//oVmQwxUUvpZnsrA4amUnw9l+FhpNevO1j38fGW48jSIkms7ABO564
HW0NWbj27u2MyXgUXf/iwtprnkJP11xs/dnlKKwM4fjOAtz64XPIyjmJjz/8HCpqDmP7ljvxyFcW
kshQfZNFnTrVNZcELmDoRBwbP38WgdwujAxwQIzi7e/KoMSUVKskiA1tUhCSaL34+CoM1NIuQtXn
Ze/owOxFL5CS2GkfIdWVzYYcuYNqGZtrBAOdBXjy/jmMEWGE+gtO3PzVU4x6HcIP37UcWeuY4kT7
cP6hQF1d3J1+S4LQt9RUlFIOM0JdG+gs5tOzdWURNl/oQekvOxHjzmtiNgQOZvbVwyX7ilRbOhaY
qHdesnN/a/NbajBKNaYPneCz9hugJvWxriWrvrqYdc06yybFVE0QCY2fH23RavY0IQ6zVGgTTMNk
bbCSnAwMjLdhdTHxPdl4Ji6+VQ+oCia3l+3OMwSEs3zTBipEL9dbIVohNyFLSwJRJ7IbyAawdOlS
06cQ/j//8z+bY9UTiNOWpJJKQMwF/pFhWGoa9SOjuwiSbCmf+9znzMcqZ33LfqBr9913n5EW5Dps
2WCsMq/3WwRE6jYRENkiLLdYSQQmaPCihjRGC7mnXprsXOp169iaq36L4KqeJB/FtMgIbxEGq7wI
oyQxjVN9a+5aX8v7KlVaseroO6HodKKn6Fwn2hkAXCL1NbezVdJUvZsJvgMBOtR4OkdR7hyArFt2
MpECvkqTQMrzZA5Z1kXbQ3TMA39mI666g547zMrY00KswgI7tq7AZz87A3eszad76z4U0iYQl1qH
hmYqPYigiUE4HpeDG53kdOGFRzfjwqkivOvPttMu4kfGV5mFk0glw9+NzXceRGg4Dd/8xHos2EQP
EfYdI6JXoJ42YxoNjyKnkBvHd9jw8J/OxI6uAuTk9ePKu85hzrJzbG8ILz+zEt/89HSUs3ILZbOb
3neGMRtdqCnsQvu5JfjBPXORvtwGT0bst+ahkvQx3OzEoo9147J11K9yrmnMkSxiUTa9iVIEpxhh
8kAnlzEtgjP7r8DLD5TCP4dpN2qjXCe67VKaSkToP+0IIzQQIEcyZiQyYeQ9L2xC4y8D8F+eQN7q
Iay7cScNcbV48cYZDC7MhJcp302yxUlu0Zt6SjeZJpAEM40aoLQhN1qlszAbSIkQULq0cSOh9TS2
i/lI747gnr7zxtgeYwZPSR6SUmiXRaiMLpiKF6EfuZvpoeO8LtAObVGqwEbLk/peJz290oZ5DzK0
kOxfthURGxH08aHYfBwcZejEQPKE+a3xWsAhTtQTsudLJtWZg10YqUin1B5zx4fpTaaIeW12ldZO
gz1vm4icfNoTjMY3hExtkGnQXJy8/7Esjp2nEqxjkhlZY+NPI7jSzvMm4l9rVr/XbxGMwXCfiQdJ
szG53nhakzerU7mOTha3ISlERmwREEsCEVcsZCgO3lJHiShIWvjJT34yMSQRI4FUUjKI6/OP//iP
Ro0lu4RUPZ8jobgYLAnA4twVFGhJQReXfa3fQtCWbUFSltRXArnkTsbZ67wVMJnatoXIrbGJyKYS
FUtCkdFe6qcdO3bgpz/9Ke666y5DXD/84Q/joYceMmshImGVF2H8/Oc/bwIZU/uzjicbo64ZJo7v
XzyXtul8j3kF9c7EKhzooFt+Gd3zs5iCXtm0E2LCUmByAqIyqS8pf8qDyW6nP35/CXZumc13nNy7
k7ECfH/mLanD25Z6sfG93IYyoxuhkYUsy7fSGcE77vseLdW88UdW4tkHZ2H11TuxaM05NJ7KRNO5
HCzYfBiuw1dwEWgUHyzErmfmYmiAurZWum2mMZCFCGn1NT8F6MYtj8Mn/2MRrvtgK4qnJbDp003I
eTqC2ctaODEmE6stw8zFx7FkzVlsujYTFYuZipk2lmiM2I8QbM1navVDuOv+Wfjh++ehcB0nOc4d
mwKpf3hJY4qRENz4nn2Umuhv3V2CQH4DkR0v6jptQw7jUTYGagLw7CNL2BzHfjaBqz/ZiMoZe1iW
k5fbLtcpPEy3ybAfRTNb0H52llF1+deQ+B8E3vndM8gpqjXt3vwnJ/Gte1YiwY11zH149T1LHeXv
fiz8R8TetSobLXOzTWCgidNgn+lMjli6pwe+Bu4Yx9TutZu47wPjRqq3cBtTGt0jjM1ouLwAWdXc
yvP5LpM368LtxaglF6PcOfmsP5O7vxVu6+a+Bwn0c8+Q8ysK0JzHNSEUcrvT2bs7zA5qgwt8qGXs
iPYTUeZdzVviczmz+gbODeHsXdxciMh91lNkCegBJglC7r7DlV5cYEyKqcfyQvYKeiw+2Y+cvdyi
k6o1ZiZDE/dzqOVmO/30b8+gBFXCLTpnvtgGb10Y3cu4EdbiHBJ5KiPVBkF95dUNooAbYomYtqzP
R2+lckJRCcQyGmMaX6zZTzSbLT//u3iGyXUlSv3uyc4jZp50MTHfr+ePuFqBjLmWB5UIwMUghCYE
L4QroqBvITeLE96wYYPhjlVP0sb73//+iSZEKIRYRUAmA0t6UIzJt7/9bRPfIU5cUo4VzZ2KjK1j
xaHIbbiqqspIRmrbms9k/Ux2Tv08++yzJlJc87PGIqJoufOqnoXQdWwZtVPPa46W9KTzGoekjYtB
hEbEQyB3ZTkXiPAWM/eVYmhETC0iZNW1pCJ5iVmEStH/SvOitUgdm1VHTJeAVzHK2K3qtuTGbsMz
vaij676i0gPcTCzGYONG7hqJ50kP+H7r0ZmcgCTbm2hfyI9OMvCSmx7qycc/fmIuFpBlLLwyhAWr
WzDnsqfx908/DaePiTCbMvHiIwtx04eIPNn6tz9zH667ewcqZu/BjLVLsPvZK3D5TY/j3Z88wcl4
MEKv173PL8La6w7DX9iOtTfU0WDOjevXd+L4NhqaqTF6/uEPIkKvgOve90OsvbMdO37FlAyVwK0f
/E/c9B6+38RHx3deiV99cREKKjimy5/DZx56mR5blI6euI2xGZQI+jmWT78NH/nSM7j67p+gs+XD
eOl/M8XIdEk2F0+YbdJw3rebm+J8gQb5uS9jbDSfqT5ooOGi8f0waz5M9ZudD3t6Tj+O7b8GR75F
Yz9TlnjLQthw005yzizLh8CodkiAs4s66Q3GpGskhDu2rEL/2XR4SQirbgrS0L7NID/eGSxa8QQu
+zC34HyImyhN58Ytk4zvlZvzOx5p6owkD3IvkBcYeT6ND4v2ah7m3gWt3AhqOXeeW3Z/rQn+O8dI
c04dpXS59dA9N8g9QJ5jmpENbKOysR1NbyvF1gX5WDAYRv5wBO184F5aU4IbKf6mHxjmrnXFOMYH
UntPSwQ+x/QIYyRCa45zrwombts/PdtsR+rnGKTtGyaizm+iKzBdeg/zWjYJw8w0PjDCeXwmJUmM
cpfEQ7zmobidyWBG7Z7XzqSQRYU+bGD6lCwmeWy8pRDbuDdJFl/cMo6tj9dfmpvLFNzcZOhYPTdS
SsMBbiLk540NcCdF3ip0civTdBLCTXRHzt3Rj+6SDOzlrnZlwVGTUmWMYr+Pnnhmz4Qkc/w73ojf
f3XZP2Tv6A914WjXXtNh/BLR6JONxgpmkxrnt4EQqxD8xSBuWSD7gZCmEKnatDhjSQbybhIoP5QF
FhHQ71SkL6JhgcpYxunU8pbk8o1vfMNEfEtaSb1u1X893+rvaeI5GaSrqqqMJCMCIRWcjNeTQapt
xELu8uaSxGQRHcXIWJJNahuaqwiNCIDmYREZHaeug1VHxOHAgQPmp1SFqTCRmyv15PixMYjzuJ95
72KMRp++txNpjWPoWE3HJ76DuXx/HW1kAKZp51BhAKIqqbdo0p2cgKgMrwvi5LKdbubcp85/70s3
82b7sbR4FNlzxzDcQ1XTfZtxzZ/MQmlFO3WfOXjpFxU4+9Ms1K6tIKfDje8fyEFf0zrc8hEvsnO7
8Z/3LkL7PxRiztImciZ27HxqBg58LQ+l1eVUk23kyOJUE5FjvJDF2ApuCPP8Rhx4Lh8nv0cvpdyb
ScS4MdPOOfh62yew/o4G+LOGUHuyCC88UIZouhcP/vUqbPpQBSpndhHpu7H3uWpyPp1o9NyMwz8q
xCNV12Dt9dx8Ppsii1785HqYuVp/jGqK3lCBORESgt2GELhA9zgFSnA9DEHgYUaA6iwa0gfbc/Hk
AwvgWejgfgkkbP95FnmlZ4no6E4cJFUlZGT3k1AxspMxIxcOrsBL36tEgC7G/du4mc7nj5F4MmHb
GFUsrONIj2LT7Ydw8Pv5XP+kbUFE6/cGfEiUPj2NYmsNt9+c85kL6LonF3u573IDc2TNmcH9rVsY
Uc4yilY3dgE+HyIChUSiaTw/RlVPvyQLtjV7TwfKv9aCfd+chxdrchAsS4e9gQSH3H+AxGnRo/Xw
nONL85dzcZIp5JdU02bEYEIfuf4cIuhlP69Hes+oiYB1cz/r4DQvtMmVV4tgrYO+SUTsVDX5OI4A
96K47Md1FBYSOHRXFU4wrXx/jQ+Zj/Sjj2lZ+inZrOWLMfPzDWj8s2L0byhFKzccmlPK9WYAowIf
ixkYueQndUakP357BU6SgPSXZ3DXtj4jkcj2s2BHO4r29iHm431hv3aeM3Yea1y/t5v05jQsZrNp
gHPkWrrt6YgoffvrBBmg582bZ7h9i5N98cUXjdokFSnL0P3CCy9McLvikqXK+da3voXHH398wnYg
QvPpT3/anNcQFBy3detWw2VL3SWuW4FxqcjS6lflJdlYoPOWRJBaxrougqaIbBGQ/1uwxmH1o3Zk
bxABsIjjxW3L+8wCBQVKDaXcVB/72Mcm3JilXtO8BRbBs+pYKjARV2uN9W0RI6ucSaPieQAAQABJ
REFUvlVGeb4k6WmsWgcRPaVd+fKXvzxBjFLrGKcSMl1SKp+mdiCL73J6PV3qmTxR79qQiBgZPhc1
Mc1v92GAjj+CuOwmhMkJCB+yCWAjEm0SjEj+/j3LKBFwd7i5jIEgV+zOpHcRVTQ/fOccWhqmU5Xs
hJ/pcHLWxfDUV+cwZxQ3MuFxy+ks/POGTchgzEfGajue+kI1nugvI/5mDMBcB3I2RvEM050/dm4m
e5JPkwZmRwa5+SPfLYBvsY0Za2148IPLuDDcJ2KhDXV76UH1/WyW0u693O+A+2z4aOiPxd342Uem
s4UqXmEisPks+zz3taCOr3QzcOjXhdj5j1fBPYM3oYaqEKmjUoHzle2jb6cDt36dSc5qKOoTsSeY
jC5plE3FFOSAKE7s374RDVsC8M4Bpt85gKWXv5AkwERKbi+NPwI+63a6DXNDNbzwq8soXroQbaOh
/b52LF65BdHhTBIPamK8lHJIaGrm7cKmT87BU59kYsP1nBddnn9vMD6lUT6YslZ4HDFkHw8iZyld
n5maPa40zheYjsQMYXwc43VMfizVY4Cfixy9h0SobVoA+Wv6UXa0B5eTTju5oRSLwCm9KiWOLu4v
UHayDfOOd6OIRMdFrn+MW24m22egaw9tJ8y3Fc+mmkqGeVbWgz7e5SvLwBM6FyPRUjHeJWQ+FUTe
1RGEKIFIxaZAqDCfXamccuhJYvMzOyo3LwqsLcIorxv3YNbVJjyy+fhayFZ1kJheS684tq12Beqf
s4CHQZX+PZSYaEtJFFIdRL3xfwfgG8y1dGCYfuPnuk+ZIUcVpPU6QYhNhm19UsEyHlvITeUkRWzY
sCG1mEHuSpyoWAzL/iHJwwquU0CeDO+SbnRdqi/ZSgRW269qcPy8hdTl8iq7i+wGF6t1rHpCpCpj
1bHOv9FvBT3Ku0lgIfjJxihD+9/+7d/i+uuvN04DmpfyYn3zm9+cIB4iRsqHZcHFxM/6rQBBC3TO
6lfnrL5FQCazPckmJRDRkTTzG6D3kifbAm7MoITubYqYoMLBacwgTgbRz83A9KYFmRl7mEZO4Qgr
HdHrfvrFdftXEwnSghrq4e5dR/nCEdHaGfDnqWSgH+MqHESYMqLGafj0lFDlVUr0TqNLWjp1oZsY
oxHkBvIv0ziZz+HyBRQHGW2hdDPkhK+ayKeYb6veVP4nxjZIP3sdC/F4jEbUOEWDBHVv/Qc4lvlR
pG8gYqGx3s54jFA39yE/zhQGrJpWRK6Q00yjxDBaS08QG0Vndheu43glEHDv4jjHypHy82pQFHuk
34Gi9TRqX7fDkNgEkbeSIyYHZgbHfukgQIN6d9N0bPnWDGSQqA3vjOPKT51CoID7K48nWXRyG1BB
Is6ki/RMO7XnSuz+MvdYuILzoYrlunfuBv0IEOzI4LTJzadz60kiMjtp07rrd2H/40V0KvCaNCl/
qCDDuJ9rSmLg5jjGiJwlVXBBJ4XkarAIx1vMPaCzin04WZ2FwQ+5MX9HG1Z97gziNXzMqCarqu1H
Yzb3j15SiB4SDkWcVx+gSiqTjtG0sWh/6gjVVafvKjPH8o6bvrXNSDzGLsLn4DdAAxgHuSMmKul9
woBHjT0sd2ga6NmMAXmBSVxXWng9+EGWH6EKTE3oXJgSUst1+Rjjvtet5T6UU5WWd36QkfeqyDIs
2L48B6OzMhClRJNB21De7j7zjCR7eOv+tZapa7iDxvMLr1v6sJCt9X3xDC21ioXELlVOxEJIUOor
y1guRLx9+3ZjjLbOSVdvgewMAhEliyhY37K9HD582OR6UjmpvMThy7isMVjlUscjo/zHP/5xYytR
u6nX9DsVJpuPdU75rG699VZTX/ErAuuaji9uV4ZwZTWWa7MVPKly8pCSNPKVr3zFECSpti4eu6Qb
qZ+0dpJ2BLLFKIuwCKIkH6u/1DGonAiNzln3yCJGupYKNmkQeKKAqekLaTuUard/oQ/HuaPozIEw
fIeGEF7KnScZC1LQw3xbLCtboGByAqJr1hNnivHP+Es4cNSOwpUjWHN3DwqKOuipQmRNpO8gd93f
l4NT+0tRv81HAsIKwnicgDyyho4zb8yMIWz6cjO9prgZfUz5apTC2Yvje6pw9vEA0mvYDx8WtWeB
5BERnpyqMG76X6cZEMitMcM0Zv1kgYmMl3dYmBHv01b1our9PfTYIqWwBms1Yn2z2TjVZvGEk67A
bhx5opBSlNx4rQL8JoIZPmLDXT89i+xiivqjARIPUeCk/lYlNT5tkiPPoR1b1qDvZDpcxTYs/0Qn
pY8njLRhFISmsMpT3eGkr3ifH0//aBG8i+0IngCu/usmGtoPkLJxS9CcVqoJ8yjZkRA7uRfCKLeT
rTyFTfcuxI8/sIDZesklMBjxN+6L+nizQRjXugW67/pYv9VX6rF+8nqMe0oX7OjFRorDh1cWozHf
i67rKrG4yoeax1uZWQCo+lWb2SToyCKqJGnQ7r6b6quiVpQ8TvUgnxMulEHMdcwGKmnIRSJQmc6N
SC0KoL4vBo1tAviD/6VisyQH89u6rrK81/rSR9Mw5Xgg6WiQxOSpy0sxTEMiM6pgFvfLzmjg3hkm
fb04eDDXFx0EEn708GVaF+1FbozGSUVaqcG3MJDdM8bzs918EQmx3yJ9pHobffe73zXJ/MQpX4yg
1I6kBoESBEpNJGR1cTkhOCFCRWsLiQtRCiw3XREXGYQFIgDKZps6BqUskS1B6hgrFYkIiHI7yT1X
2WnFfVvtirAo4lyI1ko7r4hwqbAkAUlVJmRqXVO/Gl8qWNc0HktKsuwLUjcpj5XgySefNN+av6Wu
OnTokDknLyzZORQvIuImQiKbhvrWeor4KHW9JDYruaIIqlR3sudYUehKkyL4+7//e5M6RXO1CK2I
0Be/+EXTz8X3SP2IwFg2K2tOprGUP45Rakb4e9o5esk2ibmmtF2Yhna+B0tPBaEtqQfneBHhO+ln
uiED4zhzcgKS0rh1aCf+HK6zYc3HmnHju5+mjr/eupR8E9Ug36PNtzHA8LF78NinGN+wgO8Vz0c6
gDu/fBLzlu5ESVXjK2RLdYjv111Ptc7ye/Do38xBBqVWIQC5YarB0TAljsPAe//+MJZdzZvFmcbC
mXTVnQ9u88w4DiL8l4Flf9WA9W/7JZ+E5DhUe1JQn1TVNxy/Di/8f8Uo20APEbOfJmkHpY+RNgcW
fbQLqzb+gic4AgfdqzivVDBIJ43xKUeX4UXaMnzzyGAfH8OVdx5CWoBzJlFMpni3apE9Z+T6vhev
xskHspB5OdV8c0ew7gYOnHcgQc8mqcf8Wb2024gYs0t5sbHfVRtfws4bqtBd72dA4h/KrTcFIWru
+owjSB1OYF8dG+BF/g9zz+zA/kGsZN6sunWFOE8j+faF+cjoi6D42W5E6EZb/Az3g2gN4fSaQjRw
y9ydG0txLX3OtaezMUwz2eLC51rhZXJFickZbGuoggkoUxG0NSYzGGsM4988J7/2FB7klQLj9azq
atIEUfFAHl+5TEW/kgFUo9kunJiXh3q5MM4LoPA5csW8Lu/mpfs6UXB6gCI+JVwG19oU55I6tld6
e8scWeqrHhrPj3XtN+P6bYGDFoITwtbeFq8F4v6FVC09/m8rLyQuTyYLhNgtQ7NULBe3I0lCiNtC
3qonwiAVjqQWBQnqY4HakMom1ait8hYBEteuTyqI4F1sexBBERKX0VwfCyRBiFBIorBAEsLF41Zd
IX4Zx6Ve01jlNXYxWJ5jOi9kL2JlESyrrIiy2kt1a9Y1uRHLCWGydq261rc1Hut36rdMFMKJFTu7
mNmjAFHaBZvnZJuEEm6mGZJ4MkLX+wQJyvTTvRDLYHas5PfkBERvWAooh1Wo14kZV3Xhzg/9B3xF
3OhkhOk86KZryJVeIIMIvfBmh3D9239MxP9ePP216VTTJHDbP53G5jt+kmTimQYEMtxJs6M6o5RW
AkO47p4fo7/3w3ju8+XwLUmglYF1THwCX8ko7n3wDBavJvHQzn+2IKk3XcnYp5hWgRYgTolGxCUe
zeJ5jmsCVIj2CwX6sWQ8ToNujAiAqUR0hUR6ApRY0ckuRqjCevTB95jyExdTDiSBSPI6s6+Qi+rC
MKWJjZ9sRs2cnVxsxb6M2z1YJ8EACgUN9lDV9ewPZnBbW/rgk27c82AtCqu4myHXI0EfZBGQSKSC
Rv95WL7+CUa5M9UK92/ILGrDNe87hQfuWg7P5RyxGXTKYH4PhyaeQ/EaRMReGoqZdW/iSZGHkvzG
NQwBrxi1oWxiZ24sxdnyAK55pg5L7jsHfG0G9tZkY4CbVPmmp2PvzZXIoL1j+QMXsKyZnP091ThS
lIHB6gxk1PGZYKNSg2Y1MEljJ5M0ah+RSPJGm4dcHVod6/hi4ANha2CsSSZTUnPsGXQjtlF1NnGL
dcDHRAKNxs1d62m3SaoYo6zroVuwCB2YEaD7016cmJZJPwhyESpM0JeyFeccDlLiEpXn8yTp4y0O
GqFWobH/ghmph8bz8GsZzzk3SQbioIWURVR+E7hdbHDQcMNCkip7MSJWHSHoGKXJjo52k3Awi+X0
4mmr2X4iWEtiEVFQO0LIAvUvjych31xy6drmVYhd51RHx8qdZeWbkopHNhkRHaUR0fdEeT44ak/c
vgiKQNdkEzBzY3sGzDSTqh8RACHppNqJee36+wzCFqK3IuvlhaU+U8ctpK6gSI1RzRlDeyiMYtpA
NCb1p97UvlKNCPRGiVCkcdvbvHzOlVJGmMZwjU/XVDZ17DKUq2/1obFoTJPdI0l/Gl/qeEyH5n4m
3+OEvIaIspzk9rUnyAATosoVX7ntnHz/R8tdOL62BOnMhh04SyMuwU611zgKN79f/UezTnkv5B8/
cjKBzV87A18+ueDhLNo/+jHc78PuF25kUKEbKzcxgLDyJI29fnoRBRnvcRRPf6IS+VeNYtWmFwwC
iofFng/iyJ4bGUhYjBXrD6Ni5j56JwVg9wzy935sLy41uave9peMNfDQkJt9nokKj5JYsWosQs5c
Q0u+9ObucKi6HXYafkWQ7E7666aMfWJipoouJLGB8lAZSCmrNXV64gw2zELDdj7E7GtSYB1pADyl
vMrj7EVj2HjzrvEki0ot8Eotmxn4GA7sWI7Gp/3IXE5X1HdoN8OnNXDOR4GJpH2keXb7EGYsbOK3
k3nC3DTA06DOcS9b+xgOfJRGxmeKmK339yCFpI6X2NXWyr2Xr81AD7e0LKYk4GTQnQLuFBvRxTQH
oxRvbU8OIPR27plOzlz2CSHqCG1LTbw+nOlGrog/kW24hmsh3Q8JwQhTIwxwD5FwFQnjI4PIuIXG
c9XVcnEt5ORm4iw45wQJktbYRI/zsspIClE2XnsPC1AcUOK35Hle4H8nAxeDV3Ib1iwyMpyHN8QX
sp77lPCiiMWAz42CPup36Vk1SAKTReKhTMOJcg6RN19SSzSf7hse2qIoEelJkaRhKI76VhkaQmJM
LGmIG9dD/b6VQYTDyWdwcHQAxzsOcr2Ua41puxlAqKGPJSL8HqeQzFuXlqBozXsaoxu3k27Rw/1h
DPWHGABKb7Uo3VJEfQlxqvB0351Uf6TZqd6gF1x7sJNxNLR7klN1EtnYiJBirBejE4OLKcKdZKZC
zFIQtA8yqJSBnFq/zCzTj9oc86UhTHf9jiClQBp0HfRwc9M/aIwq55b+QbjEELCcwxugMwZtXfwd
7BlGb4T3kOMR46OxiBnraO1FlO0p6tWeEWDWID5MHG/3KL+pPlJDdjIzbrLe5r57qLrRveaYXNpa
QKp0lgnSs2NQtgce23iswEsbNQYdzd20lVGzIGIkCYdrFWkaN1CzH2t9ja2Av6WJ6W3t0TS52kIs
tMfyY8rxepQOHdpATevcGqGzR3+MziW05XE+ulFadTN2ztXFNRLhMHV5oWOEzBhjzZz0YEyOm8SI
66cx65yDxNvh8fNZJoIkCPk7+G5ovSX5u6n1YFY+Yx/UezxAY/kg13MGt2PIPcKcglWMtcrx4Lr9
zABABxMxYfJAFCRbNIcpf9ixBRwnI9D5ss0OoaCk3Zw2Ngo2suuFW/Ct98xl5/Tu+JIH9zAATgZt
blVHyk1vihs3Yt7mMHJKWmlcJ9Hx9qOzfh7+430MgmnPRMP7ffgzqrZcbqqJeF/Lp59A2Urmz88K
4fLN36c1nN0Jz9MryRAP60G3BsdvqX/SF9iw79lp6O14V9IGMj7+JP3ny8CAr7XX70FJzTk+1EQ+
7OvMoSzjunZxk5rvGFO3DLbwgTS3LaWzlEOhrjR6fbl8NL722BhgmQ+aQQivUB0jfbhDaD69BFu/
W4M8eqT1v2TD5i+cpqGdhI7SymiEwYUhH9VXHazajfxi2Ycy4QtwG1lJSSR0Y6MFdAdminQ6LfyW
IaWM7g0eEinEiRiFUhqp4x/4/iL08oVqIEG44lyfCbaT1JFJJHChwIuT60vQtCAH7fTQkp94Jjd8
cteOIaeNkoOM6EsK0PEvPnQydkJEIas7BN/xERSy3FGqtY5fU4a0K6Jm3/RCvqx+ShzatEY61kES
rYMfmm64nzDbnnGoG77zQ0a9NUh10Z6PzDTBjiEipTk720x+Hhn6B7MYy/En0xHig1/LF7u6JwQ/
AxDtJYy/aRpGWmkApxfmYfBfvejN86CX9WvqmfKhm4SCSGaEn5is5EJqfOYkefQSEYaZQM4mBw5e
G+I5qbyEqCyi8gZX+g9eXORZRKQj2ILucPL9DcWTXKQ1GEPCOS9ljBgVK8pXBFS762vieaPqW6/i
BPAdEhiNeBKXJE/omE2MX+YBOSP+mPitRpJ8UbL9gdAr1/qHXzmmN5D6p1c7mY/kZ6INcvOv6mNI
aemTQx3X0PMXIZjUBGhI5jxvG4hqLNB5NW3mSI5eG4uqyEQ/ujbE8+NFdO3V7SftJrpuxkqcbSqn
rgdPmUZVmWYA05jVCHGoqahrbMp4IVIQp8LCNGOKWW2p7cHkfMz4VEegNnleWGfi/uga11Wgc8bR
lNKW+lA5NWmaHRhJXudvAySa8mntY8BsHwlaQWMQrr2UAm8tQRH3CirY34sh4jtl4zWhDKw0OQEZ
b09fyow7xgy6pfNCSPceNtTH4aHnCWfXeC4XuRX0wiocQ1cTgwJ5c9K13zeN5mnk4nIrKDLmtiV7
oSeTFrKzfTrjJtIxk2lKOuoD6OsqY/DfGS6k9i+OoKiyn3mmqNZhM0LmZqZMAyINlDFep4xNh4pT
SWPa97rdWTh5P9VX49e1hq58vjhdLtzxuVoi5nOmD1vaCKPgl+HJf5sO/4pXu/HSy9Gkep97ZTeW
f7mXwyXCYENWm2pa7QocdADY9WQRzm8PMOW8C8/9bCFqZm9jLAspOQ315Mu5dmpwjPmxVqDvMLni
uUDVLf2YMfeZ5LyoahuN5JmI/DnLW4x0NTJUynPkLtK5xuSPiK2wj5tNnflhFrLXJdPamwG8WX80
IeakcnM/jzkM2pMxOUREmRHhDop8gKq3MbsACbmNXMzMnR10k6YnEmM3aulplUWua8OxbhTvYzLF
JU6Uv9iJtUS65yoy0cKgw1xyiNfsb0f+rl44MxOY/XI7kRTVk6wfYYBiCQmLItXTj44guMSH6hYi
NsYAyR4hl9kIn/YYEbo40eLWYaM6M/sScMgjetj5TCh+pKKVbxyJiwiJixzuEsZzVB/vNf7sYxXc
/+KlLmzMcOIsx3WsiqljyHUt51a5s7fRw4s318V5TG8ZRhaJjkDPQRYj1ee10vZCL8JYoQO+7jBm
+kiISPAUdZ76TJhKb+E/cbK/AU8Wbp31bgoX4nvF/ugJjeMEpZJzfdTB8kHPW7YSVwwywrrYgzYy
CJWPtiJBjzwxD3VLclHYOsSsBESog9wAahO3O2b26fKnuxAtYNI9Em7tez9Cb7pWunH/H/beA76u
6zrz/dA7Ljpw0TvA3nsVJRZ125ItyzVxbE8cO5PESWbyXjIvfknmpSeT5jiOuyzJkqwuUSJFir33
ToLovfde57/2xaVAibIpWclvkqctEcC999xT9tln1W99K+dql6sd6lkcqyrWwpxDTQpuxUOcHaVj
K9M0q7zbQaJPL0nR6kM0YeP4J1d7tfgA7ADUAB1/MFsl17qU9FyHmh6mmC4jSsU7m1xCt25riurS
orVoT6NCG0d16ZEs1bKmCur6VLgPYA8hV2vFfGlDmno9ocqFUSBvR4uGczBOyLkZnG4ET2kW8Xzv
AYA3sBVcvtOrRnJyybAjzNmFYYLAtDbN5zZ4iZyDdGLdFsGKkHEQhCWU5l1Y6eepmwjEa/HQtyb/
cCtFq9B9ZOGZGcTbvG7WrqH+HAjEJDbCfpR12IeBE8T6jSY3GNpLAjvG1xE06fVudT4Yr2PLU+Ul
WT1/R73CWKuGHgy8Mq6yX89SAx1CV26vcw3YHBvD9XFVfDVDl+jfsfFAAyEmjDG8syv3ZqiD0PF8
5j3+ZJ8aQReWlcDKwfnE45XMfqNRF+9MV2rboLJ3wWUHZD4yjPh9L31+OK+JHOqr8ICGl4Tpao5H
mZ3QudeN4Y2QgqhiubAfU34/V4GYfLEcyBgMsj3dpdC6AzPFpezvGldXIy4vPUBGsMDDQNkEmTa0
q0XoTaD67HtxiVjaTJ6DwXLAnnbcXjabIHFtQnhogC+5p9HUMeGgFBhq38jQc9/9nEtqj5FET07v
gCfqFeKC7OBtwwSAoQbC4icVsYEP7YQZ1u9jHAk0Z0GP7v7kbtdB0DyjMWTU60+uoGdImDylnCfu
m3+YVrW6kEncsyUrH1NIAp+YCn9rE9+mdgxO25u+SH9z5D6FFYTo1N8n68K2e7V4Iwk9lKF7REFe
XTtFW9u/9Cph9TgNqYK18IvdFCAShhoFthswoOikBpWgLLrbAR14DAJc5+ZrgiLIoNABtdXma/eP
ihW1iGOadfyOk/Gd0vv+yb0xqGvqaR7Wc5iGPCgWArAHIJgiPrunk4SvTGjGURuypJJwBi1upyJR
kv24vxQYBjJvRtMeStV26VP1ysuk4h5yxUDWSFg9YQe88HEK7/zfX5DG9xH4wc1jCmtFICdRzU+v
gWU/rXH3z09gaFfLo8gVT2npT6rdJd7qs2XP8Bkb22e2/IzM0YSI61XC+8EooKKf1Csrm3g3D3cA
n4cgeCy+a82wEvBUVlVWOiFmYRUL12XSxMp7zOgf2DWQrNwDrco+BCULGtTVjphA+A80UqOwIhGU
bqL4aQpkAm+80ZAoZqswolPSlBcOTRECLibGo4xUQs7cd7t3g4Vpyh/uVEzvoKZ4LtImwmHgBuSQ
lejmw9ZLCMZS55w4tRAvz+utUETZkJrnpam9NEl5F64jDMfUkeXRpYV5KuhpUGJXrwbTc5UfA6Fq
IowCS/OV1l6j5H1daigslZdwdM5zPA+FWZos8Cj/GMloFPjI3Fx1ZcYq91ysorC0g7i23kXE6GGh
yCu7TgiKGh48zJ7ZBbqGlxwX06W8y9UYc9ZjKFNn5yYRKcEoHmlQ3vEmTdoaGInVieIs9RC6ixuv
cwSh4yz+xLEEnS9MVTeh2ancIWW0VygMoT8GB15UbLrOFydoGIXUt2iIerYupZ1FcdYSNiLUOhXL
4mFeXNW2TTAvrR2CyRjLNQQgiwNoQmeG8fm7ctT9cfKpQMm9nPuq/Q38BkkExH1qAEP4dxI1tDJd
68o6hX+uKS9QZYR9z0PRfLdAC1EKpfsIyNG2ovmuRI3cCbiHZ7ngarkSCBkqP0PXVmUoBSW/Zned
ptZ4Nb4mW7N21nIcD4wQBHkplhuG/6ojMVLrqrqVAjqy5654inBBHB4hPOmlpXVpPIgnZAIh4HdX
IPbkcrE2XGKZSvTuthh95/fvpyodicoFT4zDutkZpYgELuJssDIKemgMxY5H0NZhOMKDyeprBX6b
YkLJ9mRSCQ1MhbcNQ3UNN7GPLr5kDylKySy/+NQhdZ6GMqC2EII7QhPcqOWfb9S6e+yE7MTeGjNf
WWRqRmEqVjPfPRyge0nYJmVWcl4UHYZ2qfzKBh3/q1RX4DhTedhe7cZGeid06lspOrTuIW386LMo
ukSEiLmqvglx3QzxegKGg5VddEbrgdm+8ltFil46RTX6bLoVHlFMYic7A0FG6HTXMwsVlBmkrlMB
2vSNWt336HfYHxeK8hjsTVR/UwIsxz1qqE7V7MVXgPp6HFS5szVeSWnNoM3WqP6NGCVtgNLE0GK+
03hrEj6gv1yclNjojf3bbaaex9266Yk20sMQJjm0ig+xzAnC0r3QLFrmg/l3ljn3NbKW+bLkN/BX
qylxXhw7uvH9cr5vgtpqNBJ8C9GstFBw6O8YSHCLRYcSa79p2DkhBNxnM79nm3HvLSRmitCGe4Ax
riIbOK9KvohQnELhTeF52QWadRk0xhd56Swrflu+I4g4vvu+KVOL+WI1+j93H/wH+jFulCU2H1yb
U7bMqymQmWisKXIDo/DPBTePK4V+EKNWbY+gm8AQa0oLVSr1XxEnCS1l8IzT3tTovketzologUOz
deGBIF/aqJsZHyfGTshzjFDCIPJjPIC8ArQ+Y5xHMOGU0EaEGuGhsPZ+tkWZlw0qsbNfnSnBSr42
qNwrLWoljp9KK4QAtutTlEYjyBF4KXhLoE007aN70zFaykaVdqBRiaDlmvEGupKDFN8F9Qb5t7gm
kscopgBCXmMTo3TbhJbmQiuUHNGKQOi3pIQqMRPL24ARLzarENLP11F+B1clazXnmoq3kfo0fT5q
e3T44XxVxkK1siZeJd+sVUBOkPKfrFTirFa1zI/TRTzyI/DCFc9G0TX04s1yjay3YFCFocBgbc5D
UWyh9cxxRqgGsyMUe6nfKZpuvO8OlM3ptAhl4LVvfLlcqW90aDQvRCENY2rYlKSnKXzdfKVVeX9X
rbFC8nQQj/YTXj20xas+ku8rd9co9BKAhlXROgypbQh5kUXUYUXiaXfPD1FtFkwgrXRGfbYSAylQ
Ox/I0+zrbUp6plGt2+LUXBCrwqea1Lk2TkcJMz+AYg2smFDLF2NVhJfiOdyr8UWxGkid9jl4Jmz8
XA/EbTX9o6s1Fi01/YLvh8XQGasxWKmrh7Rw+VHfB2YCMro7S9Vw1NhnXZQRoYkrxlrraoa2gtCS
jUnCYK5ug305SnTOJjkThBf/xS/kYeVYoa0WFvMf1H3txg/fJdx4eeMPF4rqxmr8WB89PA669wPh
sTJixgOvzFEQbqZrUXhDWt74qhNsVk2/54lCzV2ah/KpIpzGIuQBsGE9RFzC3qaO3ay/Z5/O7EhX
X3ekqp6J1bH7tuquh5/kM6roj92tc9+jre1CwnyRI75EO+Egtz+8r4FeEtIkgid4cHOKLrJfbghh
PKsxMeVReXWl9n4vV/EredDNU3q3C55x+u/3TycA3r4afLfprV1yG0yAWqEoE2I3Daudj+2fndv0
9hMoBtk29vnMW+f/fozv+861Z024YZuz73eM6X26kMDbP/wZn910XNuOfxMoOxF+uHHe/nOztxAo
bkzv065n5nvu3Gxp+z/3bf0f5qd5HDfWj/vT3rFrtn++YfcyEGs3gHCUKebADiaIJm2BPMJERTQM
P5gF1G07Axd0U+OTWEPYE3JLywsZceVAWKgwqhnsAAPCPLperOqRhDCeZTzSllFFkLfsKQbdhKLo
oV5oFGEatrcHrxfkHzkwm+YoyDqvFiVo9nwAGWV9GlqdrgYEdPZPCWOhzHspEq1alKyE01hpCEQL
Gg9z3g3LkwjZ9AOv5tTr8ApKYZUgNDVJ6MjkSWQNISpCpVeoQ6rNRiB+ukDz9qGAhnuUcrFHS/Ji
1UbC+Pq8JMVWw+EGgWwUcG3Lk4Wx5q/NTVTU58aUBhw9mPB+EnUS8aDyMmd3qnp1iguD7ZqT7EJF
eXhLkSTGTdYa4CASAySMfY3ghXQxl9krCQm2DKtqTryrAr/vWBPKE+VztR9gR4hCa+Ckgyy0fFUa
Uxmg9OsguwinWjLfoi7XHshUY0KENu+pU/JhOMUKwnVlc5bjerv7xSql4MkZ0KThY2mqIcR390tV
Sny+Rye+NUdRGE2lz9drNDdMJzdmKg2wxCR0RBUlCcogwW7hyI5PxOsU4cc7jjQquJoIyv1RavL4
jCrXD4T7ZPfqneOtNXXTZ8aJFYIVEEJ+I4IdDTQRlkgf0pf+fI8yi64CyeXmG7SXY+x/ZZZCcujp
gXU904y1nMWNo/KnySEbZqXa+5HkM0ymTCCvMRo0MeCbLNvmdofVc/Seh6TvwWp5kpvQFeaKT6q2
fLku7UhWRDrKyfCotxjmhYTHTaj61VgdfG0tJ2Dn6JsmczVHh3FlyfFYncbUGDxJWdXa8Gi1etGf
saun9Po381CS8G9x2a98ex70JiTYD+J9/EotSfwLzFGkxrBsJ8cIzeU00f+jTi9+a6U6WnI4Rx5U
vLdAQnU2H7ufW6I+6y2CteXm5xbn+0G/ZYrEhKUJkJuGvbZ/nJcJZwsXOeXh38j/Ob/tfVMONwlx
2+5t33dftfd+3vBvw36dAPf/frf37fNbjBvnzfm/QxH49znzezPfm/n3zG3+M/zN8rapbCV01b4i
3nkgA8UYRDArW3fI4M4JFUM705QA2Z5ZoDwTwYQBU873KJgwyghWfs9siEVROMHcfMtFOYQVVC/B
kG4GAo/uSQeigecXeWmIsBAoP2M2bmVdI/xbs2M0BmR7FElraDiCO+oi5zEIGecUwjaUMGcseaqG
3BhQ/BhjhCTtFhqHmU+2cDtZt/aUngI2XvbFbBBGQUolBFla16trCM/6lUnAmJBffHf2c7WaVdWj
Yb7TBijk0N3ZattA07rqIS3+caXu+PY1Led3BGFVk/6Guioq61IkQtWqsfeuy9DZXwG0MzvGMW9Y
NMVyD3Mfr9aaJyr00YMN2nqF3B6ecTOhrzD43+JMQNO6IJbKbiuQNRqda8DE9xNK6kDBrjvapMKf
NCj+GgqRKR7FEG+8P1nHP5OnHrZdTa4xGmUZiGdvCOzyT2ZqLySiq861Kv1VQsZcfPWWVB0kx7ew
vEuJZ1HIGGr9syNUluvRMvI9yT8yZBoKiOPPYX+RR+hrtNyjUZRjMaHC5nWJOg2H3JojTcr5mwb1
5UQqzs4dz2ZsXqiq5yaooJ7zmzHebnPO+OidfzrvA8kSHIFWvxqq9GX9+uI3tiur9ByCkUC3XXlI
ny4dXq8j/5yhhKWW4whTpGfGvvwP/Yy3bvrzXR7+m7b5GS9c0n8wSOlr+/AgLjovwbx3O+yFU3PV
fT5YKRvfKh58x67Y0Kz9BKz+fT/I0fxVS5U/7yTXBxonYJRr4e7dECY+2Mayda/r+CPpaoYAsu9a
FMpzDb1GlqlhDzHaOZPKun9AqzfvcwpyZIgahSHyLwZEYD+BQcHa9MnrtMa97gsFTFFHEkQjrCN3
6uRfJytu7c15mnec7wf1BtdtQj+IRe4gIIR3nMXO/v15B9P2MxWL/317eB1c0ebFJnr6t/MapufK
KRv27/ZhT7r9aa/t/2nPw78/tw82uTFMWjD829nfdhhfTujm9+3tD8d7nAEeW7Af0LpQ6V0CT9k/
tKnrMzHauzRNnz7dATABOClGz2UEUdbqeFcrM4rSqNmWogwAFAF4bycQqmsI1XgPdSidWqAxEsMh
4TAXk2uKwgof8FJ/1dUG6zLeAvc9FPi03fsorPTL5BHGHkB0sC56gJYOFeOZIzS7EWxdGZFKGCCc
hgs0QDL74ldz1A4AI5Z9TAc73GLAntEswjVm671KEeh9eCml36qB/r9RfQ+D0FuaonAsa+/r7UQ4
IcV8rFphH8/SRViYR0EbniOxvwpqmqjmYdeWuWJzhqIBY1iSPezKiIqb6jCSqfkojnFeyEmEfx2e
zYJsCkuhu4moRDFUwf6MAkh4uQcbOlAFQOEtXxhSNaxAgAc8Jgo7O6zK/5qhhmTq6PivALDGLEJN
iWfoDEke2frejORB0/JQrlN868+3Ku1Ih9qzCXOtACSEp9cwP0HH8aA2oNTyXgPkggLrXBjrcjsb
qntUgmdhJKMDFP8dfSTfKd+cnc3qvy9a9UvIpWA8zz5KiGx2qCph055V0a3Iw0MauQeyUxRsTMOg
U8aDeI3JwJ8tTHjqN/Pcvcp5ol4nWF5BKBZ7LG+tQLgZ73iIbU3yfiD+aV9NkHLW9uiX/+BNZRSZ
8iDAzJQFhPWp8uwiPfZHaxVoyAwOMthHnNE97baDm4dNqNup/232b3mMd9ncv9XP/G2T2UXuY+1f
tSk167I7t8DQXvU0x+jSfoqi5uLR+KJR77ofs/bN6u8uC9ee55fSxfCkYyQ2r8UJPf832XC0n9qO
tC5t+cwV/cP9q5RCa9qd3yzCSwHtsGJCrW8G6qEnyoAy1zBF1A/QV4RaoWnFhkUGsifSg/Lguv2U
J/3tUXrtRwsUVMTtMRbIX2hG/Cf7M34z4YFYlCPRIESWxrrYdjCoLM/1AQwwrhGq9Qmux6zKENxw
J/TZ3QgJR7uHlh8YJ25oysWvBPjTJdUtjGGKZAxhYKSHQSzsEOoJLAk3aqES247XNkbZnxkpfsVi
71lYzyC0LpwJIsW3Ztxq0zgxePs8BAv333qK7Fz+Mw9bZQaxGyB8OjI3VMkXuuWdlej6vZRcrFXM
2X6VLBpQBVBo7z+QR3g4TDvnJmsTtQUl/1yjyLvG6ZdtcX3YaUHiteEt5FymSVT9iFLxOGqJq+cU
keS9RF4A5NwgQjuAgs0MkFPleCDXFpD4ZY0gRUiok2toBXU3kUguikeFuqQsLN9LnM8wqKp+jmlK
yDxKWIJcQjq6eUj559oV92K3Er/kFZR5LqQWXTukEtgD6qHVOYqSW8n+rFg0iJxDyU9qpU9M6QRJ
desLZswHlstrLvboYEGcJuh9saAojsR8l+IAmMQSGos5N6CEc93KhxOtAnr/XYTWopanaW4tvWNA
Ktl6NoMqCAUZdxTAzDUjH+RdnvmBokiVw/N2vTDOUfXMv9ypvDebFYXyMU+vtxiyQ4hGKwmtdaDM
t5DsTt9OIWHTpGr+L7qXgs5KARzSwzwtg1duHp6U5QbHeG7L1qS556sQdFUEnQNHyNdcuDdLLVEh
evDFapeTPPRQnsrwxj76OmzY+4bV9JUU9fL5wkPU3ZSGqg3vI69/hLwJymRWiLoI5aVX96r9HiD7
fG/bkzWEDm2hMOesFRu3ViD29L99MAdWhzDcGSTvwn594Q9eUHpxGS4cXFHAUQPoyHf91HJ9/xt3
gdCKJKFOGIZw0E1PNvtwXsz0vi0nYrkPG4bksdBXeyMFNfYGL9/rMOEyQc1KZMG4Zi285kJCU0OE
m3i/qWGNrvwkTikbYBI2SPHPGZZg98yd0NE/S9Pqu+/QrOV7NDoQS3FfrwagaA8JxbqycBMQY1PF
85Zv1/JfL9D5F1MVk2+PI2G0cnp7fBFIsHUz5C1TTFGeDnfkCVBtiEWHFptCsQSQE8GfZyKM3fdu
XftxPCy8t3euP+dSfvbHTL+hkvoKInVuS6aDQ3YgRNIQ6rMqezT7yVp1lsbq/Fqv4ntGtPC5GhBM
Y6q5L0UXlqQqv6ZHhVh5Zz+TD6zTnmamgwk3OLAXGHDBq4243ZOquidVlTSsyiT+POexGooRg3Xu
wSz1476veqnaLZNj9+SguEH9cHxTRlZjMps6kHEehqu463PPtin3lWZX7Hf+4Rz3kM090qJ0g2IS
q39HyOxnX/mHn86YAVaf4vAyGuMj1LE+Xonfa5Pn/nEH186Y1abYc4NKq+nTvqWpyv5tr7x72rWm
nta1CNrgh0Edcd8v0e8lgHj9tSRCHzkjygiBGgPlHktCef+8GM1eGKesNxsV3zyoC2b5bo1S6tFO
pSGoDXpaAktyH8rByCujyQNkLsByJ5cYVAPkFZRRP+sh53Q7HHzhenOl1wEdDBBhSf8CrOghaoHi
iXZk7WjFuKC2Jz/cMcsmn+3W3EJaSxDfP7ghUxtRYKk7eQ7TUX4/qdP4LwXRp4biRAwlg8umZffo
00396smMUhm5kCc3ZGkhXs3SnTRwApkYiUeRf7mB8+7U/IIoNaMcm3NidAy4a789Aygi6xWTsSxN
HjysKMJvVrBXzTaV5D4Keb32UIMydrXxPkq7JEK1K5NVgbJq4/NUEukb3gAdtQt4PHmlrkfj1Emu
6O4TLYrDK+qAYqfgQLNLyhuYpX8OeRK8oUVXQMmhMEcBGVx5KEtXYHnYuqdesS+gBD6ToGqU0iZC
kd4dHRpZGaayBUkqttDcm4Nq/Bp5Ejy7TeRTwi+PqPHzKeqgb85S0IjlD2Qol6LCKNZAj5HE2TAR
ijy7tQJxW9z8ww+LDSUp/tn/vkvpRaY8YoDDUXEErce5A3fou19bAyonnBwC2GbQVmPIVgth2cH8
KCtPMrTgXYhODh5EUUpoGDkTUxYuxoGcpQL554v3m8/N/8rc1xH27V0yqLxSFAhCOzAIdwP3vOxM
vEIsiWrZp9s9AkIwCMTDjh/PV17RHhhxBwDiADnFa3CDEw0OtVwIVeP0dL/ns0dUtuceFJQhyqgA
hmBy8yMXaDhlhJAx1Hb0udyLwYWDrHL+xiAmOhyp0Ghj983RG98vdLDdKaz12z7XG/t673+4bo5Y
gKehL1jaNqBVCP5yYsmnSxOUtAKX/GqfJten6yLNoLILopXU06MKHvpaFvsiLD+rUG/HWunFMsqj
mNAw7jXp0armoYuG5yrjZXrJEwtuoUK9B9MwZ26UQqCM7mTBNmEBrbDYBXNZxz6AacjbAuYcC8cs
0kgExxRudP2iVIXPSaDzYat6cqN0CRhnEgIvniSuQYLf75p577P1n/MbttKsRse8uiskpz3/N2R+
3K8hvMJaUD2lUG54CXsUk2Q+AFLpIySc4+sH1IFi708N1xCCv8kT7qhhEhCe9SiRggL6uJzHauce
pWOtt7ImvMUhSrvQJav/6C+OwptplvehIVUkRil/V7NDYprXa2GjBO57xeJkxe7qhRUhXD2sk455
cc7jKSKE0wREtxTamtAWkr4I3QPrM7UGhZW8l1g/qLHzGESZoMkynm/RrJcbgPyO6gIK4dSGDC0D
cZhwgup2BHvpM7Ua+ly+zt2dpdLUMCUd6FIILQWiCFcn05GyiNxAE9e9j1wJS02zyG8kne5W9BVq
404NEX7uUkkcxiLrcpi8QT9AAEvoRwJbjqJGxNrERlJjNAuZsIyi1uiKAXnO+loCtK0BwXUnORWg
s9mE2CyvsxBUWca3WjWyIkzXH0jXKUJ8G0FFZf8ldTn5GHex1KgRYjbPfiQ5RBfuMgE/qEKu0QAN
tXcnaS8AhK0X2uTd3a6JQuC3PN+F5GHyXgddBcS45tFUIgCBythLHc/8UFXN5llnvpNOdmuMe1QJ
WCCFmpjQ89SCfCpEkTzHk7hp/dTG2DAvy8atFcgt5JbRmfQfDdSnf3CNnMApQkMkzUAoID10dt9d
+u5XVymYmxYeDmIBzyMonMXIx+NY177BAfk/MgaBi9a0MFJEKlZPEtlmjhdg5iMyta8TNlrcPVMw
P2+8YxP83eHaQM39cp2iooFvTeJvYdGPDiZQj+FVWOZ7S0bbdUSlT+jCvybp9JYHtXrri+gfX/2G
WdrtDZmK9nSR70ChgNTKKz6pNZ+dpzf+rECRhZOKmzWOwL2qcUubIFQnHYLLvJMZgzmZIL/S2wls
N3JQh3euVdOuaF8PkH9D2K47A7slCH9rjtSHgI8hFJV2rUfFf1qpoT8q1oWFKXQqDFfGt1tVsrpd
V9dSnFTiQWEC1aRIaRbwvtTDnUB1Kebku5EIoFnb6xVzeEDhv5urvYQG+lA4AU0tLuQQg2AZIWna
hjXorScWjZKwZlAuf8Ltt14isQiCeY/XKAoosJ2Xeb1WaDVvfr9q0yLVOt8DgidG7Sz+tVArhFfQ
/MZ4qXwe9YyJ/fDP254BlqRNXxTFc2nc0wTqeQpOEXtvH9CJVelqIsRUABFmOPmMWXgQXXiK46Cw
zLvA/FMqXqWxEZxGQdx/oUUehNnuzTnqLYpWLAok+RTFs8VxqsICLyzEwCS0HUhYsheDIQ2hgGhR
RXyYVs2PUeqrNILLQgCA4kvE49m9yquiNdFKIVcwzlqNQWmFE16dS8Hh6/fnqW4d0NnrtS5UFst6
2rUtR5sJ8yQ/26nc0m7tZs3eh9XuOdarghcblVTWq1P3ZGnnfXkqXM36JX+R82qzFv2wUuc+n6/H
t+RqfUm8ivY3K/YqxhBCP/OVFqUFtalwSTS1FGl6bnWG5mJAZcPW7L3YpegLhOqo/Ug/g8BTh8bS
CPkyP1aPFEjIxcA3gcimQIr+RmeFaoQ5uPjbBU7R1KN0BzCU7rjWqZyThJLI81geZWBTpC5+JEun
8W62nmhW5uPN6vpknKtxCW+jtgrhN0IPnaOfKdAgz8KGpyoIDXMsbkhveqSWNuH9v9jglEXdxyA2
pT/Opu3ViiwfVsdGD/mSRK06hhdzbVRt98WrkvDVfLwRUy6TwJl7OQ/zTvqXQ3ZJ+LrkbAe0ROF4
LTgEu1gvKEiT14jBWwxu6MxhceZhMOBFn+yC14pvc/JTFosKHkMwr9Of371Og+0RGmok/3AmRL2X
EEhldCEDCTXQ5+OUcqEqjhYG/t64YKB7wuKm0DCZSbfVC0wW+aFOqtSDEt+hGmaezrv+HYCLO05/
71lLSVCzBicn+cExWxu8aq2MhiiRxJuhwN7L4KQi5ks7flCqrtYMakmIzcLpY+eckNrM9fiS6rZI
DEW1dtsxxeZDLYCp0naQ4qjDqxVMwZC17x1DURAQ5cWMc+BSg0CNJWU1qKF8gfY9lkeFvCkbtpmx
2Xs55dve1u4jT28gVosHJlpDY9TBwtn4S2nKQjg/dLiBvuB4TaXQm1+mmhcB08RCK1sFtQrnln+1
04WzDCljl+TumtWKMDnxVJkbQaHlOSZwe+1SSCEpnEVeR9jDkqwGxzTadjf4ZcvAepKPU+w3RrHh
OIrBqnpD2sd4WLsdauYaLL4N0L0bRDL5Ug95NxcI9O3jw5/vbwZs4hkeQpRFhEGqqfIeI0eR8ffN
WnCyRWUIuTZqHYJ6qAFCeJmgalsQR13NkNK5D5ZsTiaXMY9K9czj7Ur9UburCrccwXgC+Qor4MN4
MATTIIzNQ+wbBjg6VIZqAmEbNZ20NUU1DM+aezx4lgzQYYV3bRgtcWdIDnN+I3i9k+TVEskvLL7e
qZcxcjrvJLd5ZVDLnqlSDt3zDm7NVs/mGHl/2KpFFV3qpLdLQDnSjrViXsdK6jcKybEcYR3tIxTW
sCWZepRxLf7XCm3Bu9gHdPXwx/Jo6UrtGLxrk1j71o4g/kyfFn+3Ug8g0DuAEb9GiOq1R4p05Zdz
1HJPkhq+mKaOrRTl4Y0EIR+tgHaSgtoAZK55CvW/ka6j/7VIr362WAcJpx1mnhPhtdqKYJ/7o2pX
aJv2FAqUMNiBzxWqnBDUg7tqVfAnNepbF6PDW7JRMMwnYa/ACvpyrE5SE/Ox6vVaRZO3MOLRAVBX
ltzPhYkh7NyoOld7dHxFmpbgjSQcAeqLIXBpI33VmctUwpBW69W0MEExIMYKjHUCzTQKX50xY0eQ
X7Hi4HkYDdEXBjSQFKY+FL0NB5Dh9609ELfJWz8sHDNwmYI+KNMjsbinxkFUEMqy0EdTdaw2/Q7E
h9GjrvLblI2pRxOKp1/NUHVFIe7iG76d8VlGbj2yfY7KDsTood8vV3hENWdjeowucv0Jqi1LUUgc
osgpFd/X3u3ntOhxH5scMkZYD9WiMR68D/vQkiwcs6kulf4bJKxn+956t/3d6n0T5OEUM9W9GqPd
Gzfr4S//AG8JRcQqD4SnanTQV3UeRqtaY9ZNL7hMi9+5euY3fBDeXY8VaMHKTMVn1GMdIBSBAQeH
MHH+wX6sbsXmctezK9VzPlxxK0Be3Uaexr+LX/R3AA9I1rF2lRASsEXbiYU5B4uo4ElcYm7EGASD
0VcGVESi8AwLP5y+GZndI7LYslXK2rCfbsr5aYRsEeRQ7PUw+YwxyAft/oQQkjNKknoe6E66nUXj
4huliTNIUBxBKOthQlqnYOm17Q1JsuDVWiVQYJZ0vlvZ9DG3RlRGOLKYBz36EiFFCsf8iXve/nD8
AjMwRg4h6QTV1IQ/DmzL1l1tI8rG+l6FQKqYl6ikM9CP0JnSw709QwJ9FuHISJTJBLHj+Nd7tKau
kmcbgZsbpIyaXr1B0rpoTYK8T7RSwT9FDxWYYWd5lPK/qlVyZ6/6TRmkk1Pd267VeCcDhMtCrJh1
2rAJg+zQw5powrPJb2rQgjNtOgTdScJd/Up5o1P5UJt8mvUUDu3HmDdEUS0jWgL8tvKuNJqD0R01
B3gq+bnrUJpUfD1T3mus1yS6opJkXvjjKoU8AkFplkenFqcC4R1UXPmASp+ucx7xcdbakS1ZKgH9
lFrWQ6dK2roC4w0F1JL3T/XkUrvVA4u0iSmDIR9ck64q1m4xYdUIuPdySD5nnWgjOU7vH3IPtQsT
tZ8cST5COY1QUQ45hQhqQgqgXomsw9vmGRkH2j+yKkInH851IvG+x67L83Kveh/w6DwULKVVlszv
d0i2ls8m6SrP4sY36x1VySgGlxlrZ0BvhTGHqSfxHjbCgH1vtossZJDLgCBETShLqwm554VKF77r
LyKMDDx7LsZgZBnGPLKtEcXUjwKJYk7CuOYQmukFwKo+iMc4ZGUaDD8i8rYUCKle/uNi52HZ8w2X
HLdcQkCwNtz/qjYCwbNBPRwun7v/cMQQrkr6De3/X3Ha9jEakSR3a2qYmGfmCX2VWoyyi5na9MBR
54lMjGHdRHeq7NBSVW+PVtRcLHDMVUug+Yez8N1LhLcTTf5PfL8NvjvcQ3wdtzQy8oxzr5yfxzm1
NmVppBMhGMRi5/V7GggyUyLmFRx5OlOrt8wn/3MeZQDc1qpbyYG4gWczRWzHhKYVLx5clwttS4wa
dkTr5MF12vzxJ0FgYX1B3RITR1zfmVnM1VQEczAIueM6HfpTL3TvVvlre/l3Gva8okCisOCWP1Gp
uPsyHVzzAISI3Qj3eS8QHqCaNgCrL/1UB4nAWHXzoOcBF7Rk4qR16zPX0T8s9sgaM5SM/13WpBvj
eDsGk4zFimmdBbkmW7BcfJrHt4n7jq9bJG+gQFxkE68mEqRKLgn743EpSuAhTT8NzQjnbYf+d5yt
6bP8z/mrD4Vg9PQLnq7Rzi8UqhMvI/MkrYefqtHlz+Rq538p0YYXqlQAp1k94aOrhHGsm935O9KV
mxOlIYR2wW6sWGREHHmzuKXjqiG2ntbf6lBVk1PJGkHIBjVBLXOoRcfIKfSDTIqnyrlkbzM8Veka
zgCphUA1OpnYukHH29QHr9UUCe8UlFsMcNyT5DBWsSbjqORO3d7u1uA4lj4BEYfwKn6iTq0r4zVA
gWIMRkbB/hY1rUzUuY3AZzFAVpxtVc5fo5C6KpW2Cd5o8j4R7fA/sc7McCl+rt7xdB0H9XRgYbKS
yL0lkcvIo74iHKXaVhCjFMJrGX/DtYJKzY5vUelCSDqZrxoQVlYHU0FS/hI5RCu468SIsnqK+y62
KeUM12AtYlm35pkZM24AVeXDBaG6spFGbBhxlotY8xMEPJQp1/9HDvUicInBGZe1vcUZSw13JOun
oL8+DveVdwfXjxHVQDHiFbi5rI5mDfcoqIV2E5/IcaCEDdupUif82LcoSicXpGjleQASeFMmg0YK
4aXjfL3HARUgs4fwMqq4hnRYBEKrcBKYkwnOr2dtrMqWJiuovtYtfiv6tOH76f689Q9XV0FCPG1t
v6Iiq9w3rLd3AJoiIJiLZ8HRuML9CyaRFgAdcaA11eCtUGhPLl+PpSL7QbfzgBDTcNFasHa7Pv7l
bysxjcK6Cejfozod++2up+YpkM52ZuHfkD580/K6TzkAAEAASURBVG5qkAVKiZuaxDElZVKDrW4M
W7SDF+G3QfnEYWVw5YSRiO9zyKZaDxhrLvV2Eis39vjWHxatC4Hmvb+JBjY/Wk3/cqaBoko7EeuW
a/8MhhLIfNhx4zMb9eDXrmrwEg/Smknt+Ga+mirnKTiahGKifZnvcT0B1IAE0hZ3CL2844nFCsxl
/uxg/57DpopDdq6I1VBGuIpJxK093MhDP6bzFCXVb4AwzhhrASCYFRZDUttCTwmEj1xV94zTdfeD
mzUVz8JEGNkIJfdjvEA29208TBF4hZmEDxqwZrqwzCKxTP11JAbzjQChsuT5Wq377nWtRKFFUanr
KsJRYHZMa1Vr52DnYkLGr5z+PafsP92xeHYsMNECDX7tnXTpPD0MQeWArgKbHVgCuIMkde7xVrUR
ttn/sXxHsZ9Hctpu/arXqYIm2frTNRD6oVAsRGX0JxaKNO+kFlRX/wP0+DhJbg2SvsrkKHV/jJDU
M+QPsMLrqWmw+x+G92B5gyrCowbvnQJFFdI0pizyDEbibjDX0OoRleIZX8aCbgFqK2NxoPmRhaaM
+8z2Y9+z9dKBkD+FNd6+CpQYYZicF5o1h1BMKqGas4tTdOLvSxGoMcr4Xotyn4bokXVlAsUEbygc
bgUQSd7703KtBbWEjHcs1M9yja/dm6v9hM2euz9f5X9IAeInEtS2LZ6wFfB8qudzT7RrBd7Nuu+X
KwUv3ZL0d5AA3/p0uYp+WKe4KhiimbdgwoFWn9a1IFaXv5SjEx/JVTmJ+nzmZCnr3rO9TzWb0/TC
cq/mX2pX9jNNePvAnPH2qkFrbWUeMq2AEHk5icHWNA8wA9X2K7bXKnZnn9ruitd+alxmYeilPtXh
QomXSbbntAy4zqCGW55EFDWjLDLb8TTIJY4RbrxM3qUC8EQUnlIIdT1D3jCd/WK+9nyywM3P8j0N
bvkHUi9ig9m/xTBJgIB2g99WWBfpJV491ADKCcMQimYT6m44qXGzWT81RRtE4gzDaK4U7srL/zyX
fEQgPTCeA6EFm6GtvGklEDDBRF2YB8HhOl1/LV4xxUY0yM6n94+T40JT/cDnrH7C3h4eHnTlES70
447vro1PSMJ6cPEIBw0NDTi9NoCc6yd/E5KOoLLjvs9hsN6o3Emd/FaaVm7doJL5+2gAw/n452F6
v1NTvuNm5byk/PsK1FSVoP7r4TDyrtJHPo/CNP6W6e9YHok+MLDt3q9LP01UzCwEtYM+v8+TfK9f
4zws/GOsnhehaC9PidTdr9Uq/y/rNPoHQaomgTkA9bnRnPsFtW2PbHAQylt5ggbZVRshTwjhbJjA
D8bitG1tyVmTmjgSj5dx54cJaQRS5evmY/o+mscRwYMY2QBaD6Vl5zaJULBh/FT2l6NTt+3fNve2
zYfjfcwAk2qPRhg3uQra+9yF4cqjpuL8Q0W6jEe6oKdKMRf7tS2lXofWZ+gEaCXr42J0++NARou/
W6P+3wwFGRej8hWpWlA+5GLnEUjey4Q/xxBCsc/3asHqVu0jKV+5LlXzoPePI9l+xmDBWMYx+wlT
AqA4j0Dzro9VwgUsZOLz2Xi91rLB4KoBkTRPukJCvjDBhTvdldqJ87Elf+23MeUaVCoGpfY6XnQP
Tczu6C13VeaGiFrxL2XqXORR5cIk7SHhXgTrcMEbcEZdhlY+PUStDyQ5kE84PFaeHcDY9/Qq4WMD
GiZsa5WOXVSum64Z5+/ThJDGQXXZOrZ8n/USnwWgoI9alQzCXrP2wxaMEI7ei6RG302S0zNvg0i3
+lbAWM2xz+FdePBOZqMQFtJjJ6Z80PW16V8XqToUypYr7cp4EhbrbILJVPrXP4iCRykVv0KCnPs1
isF+/lPZukZh4p14JHHQqoxQIHgd7ymZvFP6mU7nWZjXchoU5X07auF9I8rRiyL6PAgvjr/t9RoF
0yen6U7mhW2iecZjQV2FVoyr9aMxOkrOMoaw3OoDLQrlHC3XG4wituf51grE3RnfDx+ZIlQEHVF6
8h+/5ixxf/hlxmY3/2k3FGu8tYok0VLi3COh+v6jC3X6K/mEf4YVGU7XMKhAJqh7aGuJ19kn6Csx
jrtZjACdoTwsjGUsu/VlCfren38dJAOHYdImoEvvbyW5ShLe0hw2TMDHLQMR9iYxviu/dSMENtwP
EdwVyNMSPwDhzMSGzQrU03+7Rkl5iznqu0swi/D1doHYYlVHz6JY6UWSdWVfBzjAIrdz9n8Vodhg
55c3/b5dzL/jsGRYwCDniMcxlUGMGihi0gKUBrFbezaNZNFyEfa3DTttnzLhe1ybX4nYe6ZMrRtg
56fjVYeVlMiii2jCU0iyb0FBwTamjBJoe5u8GjQI2HZ76PzDRSy5x8NU0AZCL20FhEEk+INg/fUN
nyJzStt2+eH4wGbAZjgGQdYJGq9+U4qSj3W4KuRLeKHpK+FH+lazUttblQUr7hBhqFU7anSdug/r
b2+kg7Neq1fro4W6itDLnU+I5wcIvnU9OkVObQyr2QyFrGdbtBTr9nXaHGeshOIfz6AMLzQPDqm5
h/uVAdLHlNDZrVla0VEB9HVU4U0jKuimroMajSBkQfRJLPSERnUUxRJy8IWAbA13UWdiaL4owl/G
hpv9SqsewuM9QpLcqroXPF+tmJNUWKfAPH2ki4RytwaBk1eRmzj2qXwHCOkHWbiTc/MSIo0l/5K8
BZr2Y6DRnoP3CiPIFNNYBqAQgB2Go5mXRc9UKvKNKMwV1g1iLNHUzB4SA36EvkpuZiGgonti1J0a
qQFCcRMU/XUTRiuPwsrHiJ7T3I8yqKfuhSJEvAKrRandlKbLKIAJnrtCYLeCEsa6g57/ah61yIFa
sL3O0cBbYr7s7gxXS/WR5yrkuQykncNXPghvGPN6B/mRxAOQKW6MRVGnKIvQWGQX/hx8Z51bPNoN
CGAtucTEg92wUpOrodGaMe/mQbeSfhKvJQ/WdfoCRTOvBUDrk492qWUlOcujLBaTxYxbK5C3PZxO
MABBvb6PlpUWhZr+MjLhrfG275jiCU+ZoMOfCZkpJW6QrrwSp1N1psBSnfCxNCuZDnmI+0cRFnsH
8siEElJluI/CmNcSnJlkhzTPIyKVb5sX4z8H25arab1Ouf4RwmAk8V0OHfREOIzBH8RgHqn7oBK0
BRf6kk85uP26k3rrCLadnVt4EsIXGKqdo7WNLD9ETBTP7Mb88RUTwBFpCEnCbb+Ih/TW0d/DX3be
nKf11EijZ4Kw/i6SPKz+Ok2lsKLicVOT6f9tKBL/MHSGr7ES79j3bWCJGo9RL5TQe2H5NH+0j4WY
CzonBXrrKZTBBNq/jwfa+kaEXCCJCBfRJZKj0dMeiAmBAfYzBYZ+9ycK3Prs5vXaM60qhordsf6y
xuzYcZyDG/7j+159+PP9zsD0PE6QUDJo9SUgnh64qPqxuo32vJwE+sRXA9RJMr0HwTSGwAyiTqLw
zSZdRml0LKdA9B/gclrWrf3UkFQQK48hP5F2CiAGUO7LCOWAXwVaS01F1jlqScijDZOwTznSqfuy
WnS9JF5ZmzxK2t+l+aVx2s0azFmWqAK4oYxq3UKlFYS2irCAgyJBDDYN6goCsXVzvOKB547S8+Xw
R/PUyporog4plwJHT1mfcr7ZqBgs6dPkPvYRgpm7qNNBZM2bCsHA9Zzq1aInu3XyH0t0inPMBoq8
CCRZE4ZNBzQe9eTqyoC/Fi0m30HILqIWll+QYeEk4W3tWzuCOMgJqd7Q4PoIQl8YxfFQFSWBMlsS
q/YHotVIPUwfa3qM9T2BIG3jHFMR5KvxLKyuJoKe4+ZZm3cSWDau+q+k6Vmgx/PwoJbSJ8WONUUC
u+Ir6S7ku+6JckVdBeFI+Pz8l8izElZc+8NyeLtGXAiq4gvZugAz8EbQW1YsOQqVyiVCV/aMriAX
Ek9LhuF8vMXVaUokxJiGh0LmS33U5FRnxyoV5blwNzUzVUMg5ILVTlM40MjKJck+xr6OLc1xCmSc
PChQundRILdYiJaXiMm03IetNtMWXDThFhN69sqEt+VLfK/4xeemRG4IRT7yFIKqKEIP8L5v2PZ4
BhYKQiaYEL3VsPfDCqYPxCZGtGjHNtJEZ41Of8kEdygMweEeC5n4zsT2a+/7hyG17OhOsPvfvI3f
N66V/VmVfXi8L2xngAJj97C+GT7TfPraOKarWfQfm7djs3zWiR3OP2+sHl/Yanq7t1PM2/nbdc4c
pmhnXtPMz97z3+hWg8qmkqDcjCtuBVPmfSQSr86i6U8KhHQTJChtQi28lA2SJZmH1OB9Fms2AJ3F
vAsvgGNHuFti3CrRQ/E+vBSMRcC+atW0KSioO1mwHmjAp0qwAi92ayP95C0Jbn1H7KYsh+DNeJV8
V2sPHHNGInWK/IcpOjvmovPtigAZYufikCA3T817vvwPv8AM2PPEr2QKzeZR/3FuObUf1Nxkc68i
8EouI+C7YAyYRYMnK8y7QOjGrPaFr9Y5LqdTIKNiK/uVRyionhCIdZ2MfihDs/+oSnOXtOsVcgej
0H2srRhU7P4+eTfAN8VaC8dKL/lmnfp/H2G9KEELnupSwa4moOKRuooS8eZ1OGSV0ck3UxUeATqo
4Hv1bk0VE2KrQFlNrsRSZ91lkCtJNwoVzvtFb7o8Cyd0V3qD0v+pWRtRZlX3e3VsHtvPS1HJun5l
g5CKRSEoXSp9tUFzqGkJhrRx1AtVSkmUWoD49qRGaIy8QgOJ7f3wgCUQ4QhhwaYSGrJ1bkWxGV/G
y8A4qsFSTyV/Zwt6GANnjHxOLKGi9PIex2TcRIjJepYvg9yxdAeNn85TDkD+wiTwFEZlXx4hq08k
6xIcWxtJ1s9+qV5REE8OlISr6rPpOkMYadvOGkUfGFTTZ5IJUaVoAGW0+sVqh0IzEIF5Hq+AKPv4
wXqlvowH4Q1WBYWIF4ALb9tXr+TtGHN4GhOABgwebVaaXUdA1aSGNkfoEsy+21BsSa+zHdGIXtgp
6vAgF3HPU3e2q/VOr7JqYQm3h8YeXAanf5uDZ7jzINrVBDdfsa975pBwAnJryKa+47Bpgh5is2kB
4GSC+9ves++EZRDGyMDNQyE4iifeMw1gqKPu0z5eJNv27cOO5d+vnbBnuc+j6DwS7Kxd/2fIGBfG
mjKBa08EBx2CMXiw2ieUbLt4CB5NSPeet6nz7ZdfP3PYdjHFkwpPhB/reLBG+b7/mNGFvvfbDxjg
9a3ztB3aNjOH/3i2HWh3/jNsm29u7DNIHORZgWdlk8VG5sWM9gWq54KvjoJ33TkbxUporM/DesdB
bKP3OjhRO9dMqBXSw0BjcHwT0IG45A5lZfuzbXgAcne3mM7HBWROEfY2jEer6IUG35y7d9iWcJ9R
alvzJQtveY/T/e0g8Vi8GasNCCM0MeuZOh+eHDSVjVkz9+HXkCRILQ9iw3Ijs35a75SJJU4/kGt3
e/7wh83AFIZD5o4WKqejdBSlYcWBpQj48K9P0kUyUjlQqQcjaId/K0T7EGiz6UeRA4Hh8S05ivto
DtZ8lQqxVBuBtF6kQj3+lweUAa3IAsJgBh0dpdA4YBdV6UB8o1E44zQSC4yclBfhf5XK9PaPkFwH
NbWERO1LFPrVbUrVrD8FUYT1bt0vd5MvieKcvC8QHhujVwecVI2gq7aDSFpD3dHcf6jUJDVH85bE
O9jstbx4Df46xhHMCqXfqFHaR7tUBSX8eZTBJWL7aSS5QagqheLJbOqeguhDHkU9RfSbg0rxQiOS
bIAeOKzSw7V4Nl5TBv3QWYqDgIZMSWSNDLpc3zBCaWlbD94C4TOMmzDCRFFNcGB1TqhjZZzqSPiP
EI5axNxYvsW6fxp8ObAPDjn2U3dvqs6Tr6lASd/JNnOeqFFY25i6yAWd25ypMyjlLM41lOLato/F
a88W0GvcqwderVb0ZV+nztZ18TqOt2eCPRpDQC1Tqv5Cmg6x33zmLA1DcBBARE9htNJghph3uFnX
AT0YnfwwxYGVACZSMPo81eSoCfNNddPeegndUlFSG6GP6aJivpeK+ux/oUSCEYgxaGLg1grEL+ls
S3tOcX9GG8b1lZcuKDMPV4aCuMCAIW3/yRId/Qvw4etH9JnnTisjj0UBltkm3YZ/N5Yz6Wye0pmD
+Tr1VAqTjwCxYkEudqSLmNvKTn39O5dIkqNYgMNOf923E/vJG+NI2mCs/N7OAD3xPxe797689zQd
DLkJYyZgrL9GuB7/i0XqrgURQX5kHNfv3t++pLkr4eQhEWsxxcf/bAFFe4O6+7ErXBedvTiNdxzv
rSPzIedDeeeB7YXa/50s/doLx5WeO8AxgSPCmnv8zQLtfzpH3zh1SGFwY00AFvhZ+7PjBRPW6mix
76Pwkmi8w/mHUNHf3hShx/5kkYZ7oWeIBvVVG6Q593fp/u+foW98CPsmJxQ6pB3PLtHeP0j0Vat/
QJBfV4rj55OyG8e5+Zs9zZwOa3/rhm3jH/YWCc6ZwyFi7A3TljaIH1txpxv2XfM0YnnP/vbv66Z9
zNif/3N7y5KkNvzv+V59+PMDmIEBQ86BqswGSXSWXIcVjQWQ/M2AbO/ip4vUem+ScqDTKEb41GGt
hmKJhxJqSaXA9BpWbvAjuZrzSp28wFerCANZvD8cJlfrt9F9f66uE3YS3qqXXMgEIRtXjIaBYfQZ
kaXxOkDTpo1TFUomlLWNYsMDgDjCvpap7GebtPCxKnmwpvduyNQGrGfvCzzTPEzZL7ToHtbCBbyR
nt8r0XzCL1n/TBvlxV0aJUcwgNC/AGV6DtXZmT9u0dxLNKuiorzfC8U71v41y7kQpolH4ZX2gDIk
FxhCXUkE/yxvY8SeSVd6lP39Zt9SRqmMEdoxKz7iOjB23OTBOVTXU9NhUsiQgQb66Jgbq3IgwO3k
i0oJ1y6/CvUJnpBV709Y5AbJO5Rt/TsytJdEdiEAgofxEjLebHP5lLY7E2gWle1k6Ro8P6trOQf/
m3UstNL9bW/UKekQngIN2wYgsTxBnUgaVC3r8dCjzOP6bxl6E89wNhX885+rdor/4oMwDFsOhBON
P04h5uU+cjsQXd6Xqit4WVbblUjPEaNQat6WxHsx+sjRJpcvOvYreUq0/LRd5IxxawUy49k1290s
5QCKPLLzLiil5BpXzh7ADHvzZqtvnHBECJTlOceVWkzCh/DgDQlq+5kWIFmF0uxF0sb75um1J9br
3PNpkA5Cq05Jc1TMkHILdzrr1L/9OwSE7QcB1N+I7Amd7w6Rk78DqhHet2Oy9u13MQvpwOkChdHT
Y6JvSnkl5cpbCAGxqUuUUHhUqeITe5RVuMc3GbZfO88Z18yrmwUUk5Z1jQrTumyu87BSitvdvkz9
Jl/xcENylFewnZ3zPTvOrfbn36cJPrabGp8LUzGFdSVgfa02h/P3ZpKGWJKh089lOg9jsn1SK+68
ACqGc7VtuP5RjPj2qsUKK2YfdqwPath52b+Z536r/ds2txpvf/92Xv+8bW7nOLfa5sP33tsMsPas
W3Qb5HkVy7wqRMAvqO7RIYRq1ja4qKjpwAbUGcIjUZ8eUtLjkAgWdejUOlqsfvu67gTFc548wxWU
SD7UN/OON+v8PXm+tYS8iwdRtSagRvtRIgPbsrSqjbawCGqjQ7FQijV5KoUcsPWBXCrN+QL1Eel4
w5tIZJ/gGPVfj1UJtQv5eEPBX5jQLnIEy4GB57/RjDE2oezdrUrGG6nFYzlCbckCahlSybfE0LAq
ZifcU1sx9EBjDf0aHtMrCMSXuhU/0CVvLm2K76NozjisQDNdJSdX64XlAKU4SDisBSQhtrOWQB4b
cd+YelFqvRQ/jhDWMnFj15B1vUc99EdvxcOyEJU9kwZIMWqftP5hLdxR58gMA/G8R3MBmCyDioeO
iI0pdixKDdhuy7UO5e5tUcw+DHAUa9WjXh1ZBooKuPqKl2qo2SAvsyVJu7ZmKw4vYQNIqhSuz2C9
EzgM57dmOrjwcnIcCU93qe5LqQ7tlkG1+bwXCXuBMDvyu8WOkLLgsQYNzKdmpQjaGIoNLVJgleeD
GMpeGI/DK8mlUJR4GvJUo5rP+ykCNyZAeec7lQScu9dyuoxAi9szbq1AbBsTJG7wB6+t1mF0hPoO
lMf4cArduGjEDhrKAkHmYYyO4D4N01941AQqYZgArsz2w/dsTI15sKL7lLvogj6dikvU9Kiay+Md
Z9Yk+xkbhuGWQjyjHwmgZDIgxLLNvu+6n/a371Tc25Mcc2Q4XlHDVCPTyMriJYEhHVq4vlF7/ihP
KkLpIfjHQXeZYpkai8ZroDAGD2HQCB7t+k2b2n45T+tn4roi8tLeCwgBemefTY8Ac6sI1Y2OmhUF
QyxzMAA6ZHggVEHsDjuFzVEs/oGHMknhIPYInzFPwezP8kc2JwzwInrpmwv0awVU90Y0UK9CkQ7s
pYvvaNChv85SeDI39M5BYIY+hT0xxueTbTpz5F6d/S7u5gYU5AfkfbgT4vIsp+DnpXLvzfxhn9t8
3HAvMSvsWvzXM22Z3Hjv7fvzf3/GPm13NwwG//vsx7wXN3ggb+zP3pj+bCbdu3uPjyzk9uF4nzOA
NHSCj5t5Frr2YSqTvafalU/c/jyCbD3cTHcRLjlyV5ZTAhuxynNeblbjr8W43MKc36foDaRc38N5
uggya8UPyvVgeov2LPVqPesjCwFvcfUielEco/J7YRr1PyeGNRIPimhligqiO5TwPPDcBb26uN6r
eezfA+FgEqifDdT7XANp9JO7crQWkMf8b1fp/rp+lWMotlK4Z2SB9pxH0fxp9t9VKeEjybpGaKaR
vibRbXhHhMsMAjyFsjpCCKyDviSxwHkt9OBpoJVCPSGrqgGF1Y1iVFJUB+TYGkkZ0ioYg22Q/iQH
VlE/QdJyMTxfU+RbXDtm1qiFcIOB6Q5TuxHCMRO76B+Ct2EAgyAS7GHlWKzxkIT+upfWuuGOu6qK
pLy1REhpHdKqE01KukDo6/iQeu/CE/rjIkdKaYn3SAAsS6mxSTjeq6GcMF0m1xPKvKx8HeWxm7wk
wIEA9t/06TS8mnFtfKJK4STxB1ZGuvCdrYTF9BmJf6lXFb+XpU4U3+Knql2x5Hlg2Ka803bDYg1U
fhBAwxChtGQURuD1CTV9NM15X7Neb3C57THyK14AEYFhYXg7WL8V9tj7ntFbK5BbrUMWQoAFDJm/
QOjb7fv+59x25ejI+SOQsI7xclw5vVqNtZlK9I7RYKZMKZmXWKRE/gdgXKVL4PqHKvW9R5YqYo7t
2L6PgCWhTDcClEiYGq4vdQrKFRWyAfebug7rzU7J/gghnnCUTKBBwswlM1N50J1bRs45Zd87jxBR
PBfPNiaB3P5h30HKGIqq5nKiqq4sJ2RmlenAAzG/0nMugDgx18qtLTVXzUFBwaFj18u5tTbEKjTP
po1j8Z5R2EdavST7MAbgqmulFE5Sn0K/D5OKCclo/njihRbS4rg97TnqaofummsMhfq+uS5Blx9P
0cVPztfSzdyoQY7N3cjMrVHK0jnqqvFo1UcaFZdQyz5QUsEQrXGJJ3blQ1fPfGA5uAuzE/5Fh80P
D5khTJwLbqzFtnv/sM9x511BIErUhtvOijNtLjgXi+e693nPQYPftj+3f3IqLlTmP3XCJZYjuXEs
jmP7MU4f9x6CzfqoG9uuDcP622dTrj6E92w5UpBlwypm/fQK7o0Pf9z+DExPt60pE1LWKa8DOK8p
8noQRC30vij+42qtBexwACVhFd3rj1/V3L1N2vlgngL/OE8lf1KjuaUdegnYbPKdIHxA4A0ASd29
Ml13kxfIoJ93+pkOxabTl4eK8yVUdEeeH1L4esmoRhYSyy/Y0ajej+fqB58q1oMU3xXicUTRT3fR
X5Yr6+4E7d+crchHMjTrD6u09BxoomQaIt2bpnEUUSZUPAbhTXuJPt9Y1t2zY9RKn++zeDA1wGbN
drNruwrSKCQddCSvR4AgD3GN5mVkkzdIRqgH4RFMwvRrDbQsN2N9zT1Q7qRcwmv5R5hraTUbQM2E
KUw3sM6t06K3r039ECBOAGO31w2EhTqjgfmicKoJD9lzMoCQXkGCfN5/K1dAGmsfMEzfphhd+L18
VUGH0geyiUdccwCpzKLaP/EcnQDh1SrfRgkA92P9YRTOUSC3dg6146r+XLquwze25gVIEun8aD1A
Ln/CCBg9Wn21Q14YfbsejnPggdVX2hS1b1Atv5Tk6Io2UTMSWjYmo0Q5D2prDR5n/LFu9d9LT3UK
JZfAM+Z5rU89HyMPc1emFr9SQ5g6XBdmYy3vQ4fePgqLmTYJPGPYO+8+mECK5U7vK9RPvzFHkZjt
GcuL9dVvhihnzlkQB6h1JjOvFKhY3hy8AuvMZYOfpiX4bHwkVf/y3+9S8w4YQHMQOibX7WOEVzA1
BRPhYUrLp6Jxin25eBof0wnGvIgEeonP39yjl36TJOB82+/MgcUQOqHGU7H6209udvsz9t60bWP6
Hz9qVWhELftkcshJPPN3q3XmX72KzmW/lukG0hiVYeguTtBOkxVpnocptZ6TQfq7z26gOIftiE+O
Nkzo17bv08I7qBQdAe4bCHLl2Hz90ycXKwUk2jjeZ2iOJdAjVFORraV3cP62osfClZx2XvPuX69n
/zBGizbUOgjt5DB1ERGjqjy9FjhzkiJSOI8bSLaZ1/c+/mZeTTn05Uaqgzaj1rshkValrniPU7J5
t8K9URZn69o4DRmZGu/HgdBJpNWlxYlHqMJtXx7rDp50pZckIq4uqJJO//5O4eaXgjEHGmp1JTZM
6RgcM5LEoEuI27GoLG5b7FE3IYFJknfGcZRCY6Nw6gFsdCz0OEsurnaAil48TxRJw0aQNZxj8lWO
SxMfl9i3fX04bn8GWN92VxJJthZCWnlpTopD4mUiQAMKPTpDsVzQ700q/y/qtSIJD5liwl7yCIlP
dmlRaaxehWo/7rP9yn2+SUtImJfDvFuDElpBQrgNL+YMsXhjFEjc3a01CU16akOW4rfgaewh31Hd
q9e25iqb1qopPyKCIBLDm72qJzcR8GXo2E/R8TAV//6JThVTtW4UO4H/D6FpwlemgFLS+lXvgcZj
Uzr9ahD2JOfjoApJ2AWC8Id4UavheVoUC006zMEwZVwlL9FC+Mva2a6GYNA8lF4oe9qx+sdJTPei
bKyKvoV1/sbsJCUQMrK1OLIsRZXfSXRrzTROPuABQxQaYnEY4T5IjYdrBEXYy3qBjBDuisbTsDxN
Bh0d+3kf0aB2inUv/1UhBuOEQ3gZTNiYb40DLIFc0lqQiNkAGULrQISlh+jaJ7O0F0TavQcblf0i
BYUgqwLqUR6PUgTItdxBPU5U2SBmbQCggxQdKU5QCaAA63c+QEfEM4S3VhD+y3qiUYMbI3UB5W3K
MoUeOiMLQ1W+DHoZTiyd6wk7Oqzy/5muUMKKVoA4ARKrCXLVk+RCvNzXftB3dYFQCLFWbE5uE8Zr
m7+XwdPLV8KjxpWaP0ZTe9ys7R7teXGVPpt7ljANwoCQVaznhAruMiGNlb/N/8Tbsexvksrx9BKe
F0KyHYuApJN/mKCd6PG/9v+2T+1vrAKs+HlLz2vfogyNdyHs3f7scxvT2zNhIRQB2ZgkcRwcZ+/b
tjZ82wSGc/ySMIVQo2GQ2/Eh84LsMZveh23KS/+Zh2TgJaTwmbllURbCs7iAbTS9X7hWwoEghWQR
zkrF6uE6YhfBI7TTo033ZyveW0uNTbSC8GqyCtq06O4wZWRTsWP7MC+KS7t0drb6K4KUAhx43Kje
P4hhp0cupoOY6PP0U9haTqxzN8m5HMAQWGxOeZAMPfNwrsqwpBApiuKhiCDUsSyzVYWPN2gIHp8T
9AuxTml3hjcq568o9Noaqxcg09taQS9mHuT2B2O1FyinVbn2YonZwxVNRe0iKKUzdre566ynRepR
LNgeakVGOQaFyMonFLEECyv64ICafilRO0HWrILUcfl3KxxtxVlCHtZFbzMIGKO5Nuvvxk35IObn
/0f7CGZN5r3arO40Ct+wMCOxwi2WP0b4Yz9FZ1Gfh3332xhoVGNf3EQeonpIeS80abEXmCsJ3y2d
FSiFRu2iJqMPg6v46qhW7WzSyY/n6fVHi7QupU5Zf9uohwmfnKBXTA5rIn4fzZ5Ke3Ric5YKMTjS
UFpz/6Iayzxa5+mTUYEFHIwBM/ko7N7sM451cYoeITXAzWchbI2IcdaxPo3T7ZDlquoVyTqGxWxU
LMl0CIxsHFLEFQgXsdCD8YBjrvWrFY9qiDqnLJqTTdHYLAqRlPlXTZoqIKfAaxsDXvrbZEZqjGPa
U2+cVubhWsFgPwroLEJ9nGtIIfltJKD2rBTRgG1e54jCSKhHNg4DN4aehee/8e5kHYaSJAPjzLpv
tpNrymzpVfbRNkUCX65COBfw3RTCRDGnoDaaR+8TWtRWUy1/HI9py+kWZb1BNIMur0GXR1X/2TSd
Rnls3A3RKAy7BrNvo7r+hCGuyN8s53mZQvwcfjRfaVT7GwjByizaS2LUgSLbuK9WIVfGVP21dFXD
rg2dl5MvrV9IcvdlNmG4qDJqTZKCVQ/J5SwUczL9X7o5pnlNJnlcOJvfvtnijw96GG36RC/WeD8M
uasmdGUHPRw+ma/UvEosbTDd9NCIpRjQ2Za3kIV2TSavbT+smRuDaNCMMfMDCy9hSuGlZBddVdrs
Dap4nCrCW+zb7cCSQPZ1C8m4A8zYF2+5XAAPjxV52DFZOu5rN/2YuW9bvfbPFAhC0rfzmVtPv+cW
G5uiEKyepHp7rC5+bonW3Ye3YYfg/aI5l3hg0EOJoDzwYALJHbXXlejkCwnyLEWB+gzymTv/xf62
07Y98MPcef+wRWJhqzaswzISjIbSuO8I/SBYdMdZrNfpKpedDWqEB9xgyaHEhJtA76RnwL5qkztj
f3ZpVpSWD+23hQZaeGiMtuI6RWrWL8LmrNy4lEhe3nG2VXHACS0efgallU0ToejtcAixk0TuVQtW
XPfsaJpJ0a+BfYaiYGectv/0P/x9uzNgUoDnoN0Toet3ZmFdEhcnsXoEFFQ4AtOLELLiwcNbszUP
5ZFMcWgFHsaJX4Zp+7EKrYL36fyncvX6IwW6+4dlWnG0WYfxOs4DK02q7tOKpyr1xueLdZRGVBuI
12f9sFHtvxqqYWDAnoZezX4WqPD96XqJ4y0nlLO8rFwxu/u14kK5+leQu8T77eaeD4MSa6Eb3wBJ
7HTCPFadPUg+JSpkxNVwmLFT9Eqj9ECATmLgjJGASCMRHQ7tRskpmisBJY/Eq80nMWxehkHKWzKh
O1+ZpqLZccqFdDHiCh4xz3t0L8l3aEUC4cYKbjb7ntCprbJE5BpzUTI33IXOjN4+sJf6kFb+4TUQ
HEOxUMFdEqlKwnctXE8rtPVLzLPAazJor4kSa+1sQj2nu0UZ9BoxRoZOet3UAjMONWJHjNwuwof3
769X+k6eMSLj47CI1H4hXWV4Aut31brGV3YZ3czBIe5bOLJqxas1iqge1oHfIqQO4q342Xo8HyrP
V8Hoyz2Zf6FDKT/uUPeDvIYTLILnyQyFesgYjYLF2vomkAsZhjb+yqezQdNBb/QmrXPhB7OixRQg
yLUsF7NpbdyGArEt3//j6eQpAs88iaAgiwUhK0BuBXPzkjIpYGHfto1vTJ8VUnQKBMPkJdzH2Xgg
Bh+bHoFWmepK0P3v2Et6DXTBDMqOohLgwQ/r0cIN9brw+Gz2zmp4+7DDuENNKyf/YWds5zax2Ah/
GEhgphKbsdlbf7ov2DLjnzvkW+fs38gdxu3P946F5KJKp3T0tVwtW0+4LgbgARrem3MVxt5m91C7
Rlvs7+q5uWrYC0XEBqpdP8jkuZ2K/1TdNbiz9J2g3RjCSoPpEc67WEVRVNK32hR9B72xib0OAGUc
Jnxl1hdqVhH8rgONUrSWZmM8EDZmzlsfrxMIW+X9LU2nHklUAwVjbSQpXX0AobB2IIqpFDCm7W9T
3Bt0ocuLccR5PdBf2INp98KsvSGswRbI4+LK+n2K/sYFuEN++OO9zgBTy/8WGNAlFHYoZJ/x9Iex
ZdFOeCYaq7Zwe5MqP0KhGkIon+52OZVUgKPsD/9KoRY/X6MF/2+54r6WoQtwZ5WSG1kY3a7Xge1e
W5WqFf/9qu4au6p6OhsevDNT6YSijFfKqsnHkYBpe6hO/8dqDfxusI936ZFMF0qNpJe6hz4g8U8Q
koJx1jriZc6DGgWYbDzJZSMkNai5PaaGULQiVEtgFz+OcIVBYZz6IQ+5GOOMCqBPkAlHs8wnqT+x
i7O+Gt4XWrWR3IflZd5AAeZTiW75jzZCWX1AcOPwJqwXjfVACUZ4BnXwj3DTKKzBjp8L7jdj8e27
K1pDdOszjrAK0GuWs0imdiWTxPrc1+rkOQCSLR0vBhj6GNXql0iKFx1olWdPv7o+Gqftj5YoHOW6
5EizUk4TAUDPFBxqVTDXE8Az2LMoWlfvpMCTcNuG16rptw7cFkh9b36ELt+TKQ99RZZtB/G1o1fn
SMZX4DU+9Fq5wujJ3rktTofuzYZOP0grgROP5HP8DV6V8ex9fE+tkq/1aucvl7guigEooQrqZLoe
CXc8WXl0Uow90aPyRzMUyvUsBdVVy3QH0T3RbO9bKxC7ITfGTS9uvPte/jA55DyJGw+63T32gEl5
k6y1Q/FGcEiLfvXPd2jy/7MEtGl+G9AnBPbr5P4levorUKoXTgs6+8VVtDUXA4slAbXiiFtMs5fU
AwAr8H1oX/8/cFjNixUnVu6K07VHN2jBhl1Q3hMKo9eKJ4lmLxPEO4NBaLSl6c2fFCh23s3hvA/s
kqan8qb9+W87eIlxT4ijYrDq8olS6C0Q4lFYdu0RWIUgOMLBlttDHGZcSiiB9lKPK0K7aX/TLyzB
PlkYwsNIy1C2H2ChO2+Pe2h079ZL3fIYE2xjjJ+G25jE0ryB5uNcLcbciEWaQZ4lFA1lIawPxy8+
A4EUJsFdS5W41SiR7cMrjIBiobE4ESbpMBURjkqk2O6AhSJpe5pHB73W3Hht/9JcLV9FvuHZRtVi
+V7flK3Fj1VrU0KUruXEKepPZisVuGsedQvZQHprVoGgiotSE97MoCeStQTB5vV+FeGJ9iciKOdA
dcR9DuY+xy8YU976bqWfwzCE1iMenivz0ifTQAMxrDO0Y0PAoh9KClXHYmo6yJGlUsVt4oYO1G5f
kyi7KcI3Zuy4wfY9xeRGSsnn0XlwdVmNOsnxGROD9Ry3WmTwpBriOHXBAHeI+fdioQejPKwa3doz
m9ecTQOrCEKx4+zP2IQjeC6KaVu7vKUNMsJhFA8nSG3I4KZ4BZN4t2sQxcFhNOm6/KkipVOvYrxx
+SimOS/XuRYJI/k01YMDzjyqsbxwiiWTdJY8VDKw3M1sE3uZSn7qWBrIeZwk/xRv9O/PVCqWJHnt
V7N1qSBRW4+RcD+C7NhKWOrBXECqQbof+G9cDcwC/6VQlwoT9VFCY7kvdGkIWG8Y99mMwJUwEcSD
Tju6JUchvFdY16Fejr9jYboeONelWBpZ2XC4JX7fWoG4TW7/h92SmZbmzG/a+0EE2XrKDD0F1DeA
UI0JJ1yyEBBbVn3t0xC2F9sPFZqBtNbMPede3/QDOZFwrYSwFzuwfbhhf2BhUJx4/kCqZi/mI6yR
1PT9WvKrC4HdstBubDv9lf9TfnHJRlMy0hAC5T1FUCt2OavKlG2AJcnNXAJJVnZxoepeIcG9whTI
v/XJv22yeOkeOrtN9jeewrRGd9w+k1iSpgAsJGAUI17oRlpyY2hNa1BJzvVtu3Nnb7BK7qULI9g2
/jHjb4fEcguFXUy/b7+HUS5pJEobaErVXRjjCqQE5PLD8QvMwPSaGu/u1lBtDQ9sEIB0ninmOxCs
Ck6x9sJz1ldC+OeJc8oIoHdPShSQ2HEFV1eDzgnWyQjYXFdNqb+5TsZhFuOF7v3UNZ5nhB8GwEAJ
1O/A6HOfrFHyyUpF0C+9b0uGurHUDxJlKOnuU8Kb9ALvbVbLRqhI8AKSaa88xr7P4IlWz51SKQSJ
Ibj3Dsln7qx/cH7GAt0fHa7jBdnKCR1VXiWMCUaBwzW4WgeE4QgeczTcU2a8WnfF2nkpqsqP1bye
PsWzpiZ3NCse7ybZXTjrEw9mPDKInAaN41BAV7elqxGvmbZCCu2eVAQewwiQYAMCeFBa1kgtwNrY
thE56ZlU+7ooXcGzsednGCVSiKWfgiIcoflVcy8Q5iiS3Hm0ga6sUv7LJLlRRG0QiVaVJin/LDTy
zGMjjABlKRDQ1lQr8+VajVQMkeAndAeQ6HAcJLRNtZpL5f4wzb56MbrOxcQq4/hlhcPy0EIEvywz
ROU9zVoNp1zQvzaq4hOJOhraqyQ4yUKoG+kcGVZDVKJaGuuUgScW9Z1q8j44VxDAhqF0hk9BLTMn
VgHVhNjauKfhIIAYExY+YbwvBcJtccOUg3kQIZHE0aLRTLy+5bD3zRLwf9E25ItREe2EIfNYZPbB
275sb/m3t4+mXweCtnrH4PNgrPZLe2mg8ktY6okV0MbDcbOUWOe4P2FgZ3p7lqo7H/8x33GwD/YN
C8951kzoxA/jtenBZcosoehxxLocoiZBeI3zoJw7XOASxlYfcyN79cGexjv39rbb8c4N7Jaw0bRF
Z3clgAc0l2TgZcj4mkCXRPmtvZlftkUzvW//7Z358c/7uw9vIwMG0wFoFeo4xhRoliAfAOznffXD
z99tBng0AoPC1f/GG+7frTbDJtNx+xfJjz/0PUl+GQ5I1cmBWn77RxUV7CAuFPAD9+i7z9+0D+1e
EZ1VHe/vdc6EGnh5xR5NjEq9xPv842P3tJqAsnVSxb/TCESB9r/lsO9fYVsOYucBs5ALAd/Y1i7A
TpR0mzsZszm+wz9GJaViLhmLzHBxGc77ViOc4IaJTVvr9nXzgezvM/y7aQCEkf0zG3jfW59csz/t
i1YuxmTa5dqjcNr30hVnq5EX+31z7fax13f9NtfP8M9dg02O7Ydrtctiulw+R+hMnfLtl1++D//G
J+R322s7p6fZH/8Ills5h+8inuA3/zr4dc522Mu/38Eu4Nd2/ul53z4O2t/cDGJBlFiQK2LYNL/3
YXeURWekhnbfLF438bNgpWxvpIM+RWGH4w3+H6PIz9JT9r9/GBx3cjJWddfWsE+jRWGK3f+GXKIn
d10aSsfemPElvhyIT9W8F/bMC6XUVTA13OnShWeoG2FVcK63PTie5Wgsj+GS2rf9xfe3ocnTIEya
HlbxmYOFUMWccJDeqQlc5KBh1VWt1slvJip2PrFWMwX/jYebVqMr8aOZ/jd77wEm13XdeZ7KVd1d
nXMC0AgESIAgCWZZEilSkhVtjWVbMx7L68/2fLZn7fHa67Xnm90d72q8+3k8ttczu86W9Xlsz1hh
RlawSCWKFHMACYBEDp1zDlXVlXp///vqdVc3CgQEghJJ4QJd9eq9G8+795x7T1STZScBuWBwrwz4
sN9ymine++E+O7aGgSULIRwfg5deDctr3SjQ7zd1yTmiXquUE9Se8jg2VnkedmwXJxXiLicYeQ9+
CQ+qdVj9itWyZTpcXPT6nVeHgLQ69J4VoEYw9teMrvkD5Ah6WfAYKhSinmZSALmA3t2ybAIQtocy
CH9h92g+hFGpFkukiAsesnnPaUOhUd195JgFdvViAwWRdciyGY9BCI9x2YOMC2Th9iZZ9YkK1XYQ
N+RUXTnRhqsX+U2IY7r2Wn5SGczFjIPTRnmG6+RqPJMvN6UiGBQRHuFcw5Z29ly6i1wF6lJgwmZw
mOg6Rd8ku1HYVzc4Bhjw1dNpIQBLTpsrD4z6VLsOUzotLlkeAC0X+1zjl35vgABOoVI//DGi/U8+
DyZZTvoGSze8XBqYcC5SeJ2MjHUWQlFALXFlOVh1wVXghRxSvcjzvtTvEPIc5ckDYzmzDGDfEkIO
pPYKBFvSGgoKzrzsPO8xRT22ggxJZTB6CyL3CGDTACObO166KgIipEc/naWmLjX3iiDdSyWp4SZ0
3JU1NskBiM6mVxsNl2MekVA3VTGqhLnVJvv9f3G3DT4XxV4btk2pYgGjfmfBkrdBZMomiB5rd44u
hp06ut0O/QC/2VF17+xHGN0iqGoeXFkCinKPwPx2hPHKCr22XPKnU32waC98tdfe9t5t1tgxwIti
u8R6PfViD6F64xhUMYnL1JlfW4tbSpfBRmqK4bOsNr0k7ssA0E1y3o0mcegU06cJp5powiRY9IqZ
LPVGGWpl+a49vWK9+1fgwxKydgthUJUK4RnGP1JhH0JHCI6CDkmY6Zwu8lyCXIVJDcuKlzbVNZXb
uCAPC64NIWkQVUr1Q7zy6+m1QgBIC95Z/8R+cX3+OizP46aOvNCS9Dwgp3Uk741Q3+pGfX55vdGA
WCCwqZT0fv03GNCu1P/hnnofKrtRvuzBpkvqBTFcPp9fyMvpo5IOTkdji308hG/n/kLWjUr+MGhL
Gx6oil/wkt/K5ubreg7/l1d2owZwjD9vSzc3nnmF/XGUw2RTHmAYKMHQzyvgBSA0atXLu/FO/TyV
6gvkvPfkl9N7XOMvFG13nHRLyRcYSHELdCsTENXiZoY3kIqfJbgom3SD5RCwUhltIOT9tnYbTsoi
I659x4ZinmRWsMdQ5aW6/HbYt1jLbgYAYo0TRGYTsSBvZoFub+mfTjf1fSDhzzTYg//kFmvD5oQt
Ds4W0fVGkiZNre9lArdeOjEmxVZeGI/b/Ey9NXYOkJdx0+WlORBkO7uELTC6dGVX8UR1078Yjch1
w/QvtLk40dq11GP5mkCXvn7Hmg1DFJp+atkWcQcxBe86DqKvQmsqCxLX8OTGXfYtbVjtnkGTYxEC
sZ7IIE5BCk2V8V/osH6c50kQuUdaL8QykOO7BnY4s8SbmL6LSG/EVJhGlpKBWCSRpwS0myoBUbYe
yaeXree+tPVjg1DnL8T1xq5ffEcQ4DXJ+Lf6XQ9Yw/vex+ZQuycmhV7q6znvvqNOvl6ZGSTUAYNy
O7EasQ+09Ntv3vwZq4uyQYGrcWT8I/YTL9xnuzBA5uDwfQCPDTgHsF3Lw0OfWXzSsrlJWGJwRcbg
b/35UVhfTBo2fpUJiCbOeiphl/XfF1+ISOivPIn1FAApKpZHFp5f0/0Fq6nlTMbRMBAm1i68yMkL
7ECZoZ7aa3lpb/5qkyL2WPlzWYBXYi3piBgh2MzkS3XWf2q7tXW/RD6Gh1sVHSdfr7R13Be3A93n
/+Kc5323YleAHevXqvAsXFOrQasWxsl9p2D0ep08/M6qfRpTDOszDVX29A/2EaIThI8WyEfHsujP
z1gfCL8ffz4XiAUt78z4McY99YzF+1dxBx01ydblKqKIHKQBL58td6XtAtbEPuGTOEQaVi/jZuGx
PkIX86ADVdG9h1FVFPtjlMhzxB+Zwo3CNw61WxHtkiAnnhuxqm0lFnoAlpbqEGwUFzp2HvcYqBWf
xIIYJ9slmPkDuv79HUHAWyYWbmyw+M6dvChucLp0E1Awf0smDQzWEXhKTqCPQDx+sfOc/e+HHrG2
2CDP2vibsIFkL4eRPXjx8PzovSVB4QblwcNfSAGxx3CZsbBw3LI1crCCApRcCvmGeGJxIwapTED8
uq4QWhfNMW5IJrI6QtzknpDNDwXsxjvGiB3CvEzFLBhftlSq1ybPxohaCAG5qAK0NkC480exht3O
TrzM6loBrYK8cQ9xM4iypJNQza6C08a68z7Gig8rOU9U2pzT3XqNHx5hWJ6H36gmGMNFw3AteC1H
YxwrdQiq0BGNpcA7SjSiZdYKhS+r6GLYvMZuby3OMLT9akJD5IEVeNEQDdaU44dKe0QxOOQi5M7P
nrde9PcVWlRn4yQhLltxw71GsKg4ee791ogrF0AbRh5Gb/rGqHVjyVuLZW4RjwLN1P8g2iwh8Xz5
L7XfemxCas7gPwyX1NKU2f5V3FOgJbOM6qSIVAgBeQsxsKtxd5LfH7FO3Iz/k/Mr1ogLifxtGDXh
8+jd+O9SUj+dz6wy2LkH1z+uHAIQjSJsCyePet0n3pV36/XIqWmiZVvFZD+C0sr/tv2o/dqh3+Tk
wfTERRKYy63VZeYz23C4LARQk5DgLZ+0cY1YJof21dxDDH0UOCB9R/aByihrf/MCq0xArhZIwJrm
HeBjiQJxQoiJXUuskP/Yb3e+E9G/2KMe5rfJsb028OU6qyI40saLoXP8l++ou997ylL34D+mFBJW
XdKcjkRz9srzfZZbBpFJMlaWhKBlsHjyyTYbOH27bb/peTAV+SoxVcvKXd2lN5kU20MnjNKwy3F/
qVryMVNjVSzOV2uIbDppFV1/Xy3jNX4mkLObqO1PWb1iKnv0dp2IyEmh/GIlxrO28xyTCQIjc3W5
ISvWoFuPWq3kIN3fmnIdc/fYqTTgTbURnX/ndBEiU3uB+olTsKl+8ol4CDASxsL9ss7H8a6KMNW9
bNhXzpliKQZJ49FFa8rgp0uOEzmRxGSoVWrXOVMkf4UXcI0B9taujq3Z+hp9K49U07wG4vHSatx+
q++Y/eqhf20YXzPtasCRnDbQsYoEiHIYB6lAOCTPc4v8rQwURi3isZqdsrH5hy1fmAAX13HXu7+m
neWWVJmACFbradOP9btbL3QUlLfYEKqnKDHY+/7ZI/bej0nBLYv32QuOeBVzWChHcUBGvqce6rP4
bhCREJKf1BSaV5HItH34p/7uImTg2CBipH/yl+3JP4FxsZWAwP2JVuOQ75vEUD9yo22/GQKiAFev
QkD80TnCV+rKOkHzH/r949ttzMjnXL8zC+MI2SoRBn8Dp2/BvZwNV1bd+qXflOuC+wA27ns9y+t3
of6BzPPS6NiS3IlVz0HYeZzRrSc65+aTnkFQinVeWT9/kfxr5He7WRGICvW7MZcDD3jKjba/yVBb
fnldu7joWPKu26VsbVeZrqfrELgMBDTvPOIRtX+z7bj96m0e8SiuoWkUgOef6YZdmrCOqglrjnkT
1F+fl6n6TfzYIxLZ3DTE46ucPCAeAdTk2fWHgrhTChDedw01Nm0wylIZRii7K8S1OZ/77dhBQgZr
CFOEOJSvlIpYTUfR0y7mUAdjFx2NI3Rxisl8BXgAsg8m0D7mZPitL3/Mnv5kl9XuzdvyMF1wdUEZ
EHoU3fERNogEeVuT2sWtuVwYiCasralBsTDY2YpVpT5DZWK4DBg81WCryFliVbjByGPVTPtrRUT2
W8bmjyEoPhT/KUHb+iaVjU8/RSRloStlhGCRfrv8WwGlnDzSM1WpYx/fleQ2LmPpY1M/1D591Y5c
Gx//WXn+a36ttraMd1Mber7l+Fr+3GeNrt/bmv9y9avgeh4uKiXmHmRp48l6/o1b16+uQ+DVIMDZ
1ck8XsLjw2/1vWL/022/aYphVQSXiHgotSWGmYvwk79vkkc8VrOTNu6IB84XHfEQbsXBZBFvv2uo
okkduHz98QvsdrmkBQsGZHcfj6PehnVJOABxwIomQiRClMYcYo3FsQ6CBgTD8PCFU/11znchtWJp
2l9eOmhPf/2gfeUTu6x6lygR/0ustYgCOMEWcbFG1CW/vK5LSQhVeeRCXRnicSx+6I+65/rGeGUr
kUQO8tIf1dr0T95qXQdeRCeaPIw0grGhTkhOFqEaqE+IXaeDLMGwuORehpC93j13g3tKyidtshRu
CORePkdMZtG4AhpAPgnxuywV4Dx63VLbyGb9fNJSr5wq9aNYXHD9UhheBfP6riT/vfnfWxv17/vf
l3pedt9nG6vIpne6tY6tv5XdFfIqu4i4Vcjv5bz+eR0CF0NAa1NeLxLsyI6shux39hy2Xzz4bw1H
0454BALgH7fghVu4x7XwwVs/ecQjvTrs2FbFAgorbPixhisbuhZb5QV3WQLisXMAJ659v/Gl91nj
8zjRApFGEAqDYfk7AABAAElEQVSffAG1zh2Y+adD9s1//DFrPMwJAuF5eRJynB0L2NT5sF14FJ/y
o1VWdwvIlfckZB9rLNr4QIN9/u9+wcUKx57lkjtu1RVBne704VoXQOih//7zVlUnooO3SWKMB7FP
8PhJZOyI2lc+fb/1HiUwFUGjdCIo0KzaUptSEdakiiTxpTQVsv/6Rz8DcRHQYMfwNXaOfFIh1njI
KJcj+WzIPv8X77HW7e9wSgJqd6K/2mpuhY3FWFyFdDKMq4FvfeFue/nwLZXzlQOIaxGw8n6E6Yfg
rhCZQ8drLdElu5fNcN1SxTX56VooNSNZhTPw808d3K/4XHxFAZKk5w7p67d+8BcquT5x9SEv8fl9
euxVqItS4qbe8day+l2U1oeeVWrLL3/9+zoEKkBAUybCWo0wOY9kQvZnyEY/fuATXhiatSrwh4iH
EngBsgEG4Lo00dz9t+pHiXhkBm1k/ksMPwPxiDNyjZ8/LUbthl2qDI/LEhC/rNxUfOV/7hAHqkSn
cfu7G4d4nbjbWA3aw7/e6Z45xOC1uP4pk//YXk4JLQWrb8dCVciw1J9wYs3mBmP2uV+E70g+/VWq
w69M+/2mPXmE5VjY/1KPk8urKolG6u+BQjBo1V/VUbBn/6zRvj7VTH89C1btKJpA9uH4huaXXCrn
iPXxNMGj0Pj1Gude9XYc+ZUJ8NXfIMTt/LNNduIznLpE6OhsvBtjulomXhl8VefZx5vsFbTPXi0f
rXmJsnpPF/WDDie2oWsd18v0M78O33odgK7ASc2XL4hdFWZQBXk/pu0iz5THsbHUF/4iGCzJG6rk
GzpJyruBxh7khbt8yzi4awVQjEMGiTHCfxrxV4p8FVNUoBctoqJUkoUF0AgLCphY86axBXFRePgp
J3QBLNhdWzpp+m1R/fV0HQKXggBTB0LBPIat/jIGZX9zy+P2Y3t/3zlaKDriIRVV1OyzXc7teXVk
lF+vhoFc9jf5h6AizlEYQ/NzNrbwMAsS7bsy4hEMEOiPXXehiNjBYfzKQ2a5V0iV4Eebre9CjkEJ
IU7H0sGtuHbrIRZxywMscBCFv2Mvr1X5nT0Hu3m3Uy97KFwRxl6k/T6wypZ2nc0H9zRcP0kmkKdd
1df+Lj5KhdQPGRw6ZYlS5vr9eWvk5FBeXoGhXB/8tnioftfto/2y5NyGqCD5ZBzn11HVnLcaIqRB
u3nIt8ZURhBdfuQk1W3k6/RLafwerPxmy5rauORhw4HNmmWqW/BzSYW53nrKKz29ui8h96WiTby9
yQZQ05WthpwchiEgrTiJ6/z6lAshewZX3kvNqNfSB6ngKl8tRoTduJyuPpG2ufvr7SjxHFqJ07Dz
H0YRugft/D/rtCGimcnGNI5q73bsPHYQ3Gb8AzixI5ZIDLVRqQ0r5bD5kEuSfQ8PE6d61c7/GGUJ
pqNoabIvacMeZOcjqPn2Z2zqjno7e1er8/i7+yujLgypvPyuv6Srg8T1Um8xCGhmxSEeWYjHWXaH
X7ztEfvgzj/mLtqDa5KLingwOVlUeclHdfmWT4KKBkoU0pXjNrH4VS75DZ/cO3kIADqZyEPI5QFS
mYCoDSGrLWlpGD81WI8HOTUUFZPCW/teXhEVkHWCIFFX0O6mmkVEtkbY073MdNiKIPyLXqz6Rnsh
NK7iDVCOUl8zc0wMHUJgJ60j3bKWdC9az4mBv63PJd+4KHFLxGZ1BWBKAOOPtyyjCImeRapBhsBb
hCc1CreVfvj9Ws9OfYKRiEkQA0tHVEusL+3gA+gIVGrDlaes8odrGHOjCOc1Shq2Yn4QkvNpjPz2
4DI6gm+dkYY4ho3V9u7htNXhnmS8o9ouYIHeSdjNGM8ncO892Vtn78Rb6i3/eMbyH4nYc1if3019
O6chSD/eZl/BKHBfKmtNGAyONiTs6dvbrXYo5bS2VtDQ0qudwZ279BIaiWegIDsKkTv+jib7JmU7
aKeD8JszWKx/rbXZwth87HtxkBCiEXueQD0H8BaKIt+lYXaNQHS9mjcfBLRUZeMxjeHyOPZgj9z5
Zbuv52+4C3+fxRYIiJeiqaOcEWuM9+snSUgTRLEpVVj4m56/WX5oHCIW+LlcftmmFzl5OAUnLaLy
MYdhvaOBJDkIp5JXS5UJSKUSWAvf8oFRq67N2MpCzKqSvIQypCoNpXw+bC8/3o06LzIHEOUlkWGl
+v17jEXuzGXvsf8jw5ZIEmsChKsh+smBgbaX5+N2+tkOBqtYIQU78J4xvnGzTN90evHbFzHS1jmE
O5OpUaLgPd1iUewy3H2/0q3fNCjiUd2Uteb98/TBA/zWbPqt/k4M1NvqctgaOlN26L0I5AVZtesn
DYDfq8iLIlECaa0QE4PveBUuW+DN4t/sVSMNqio5XVyaT9jJJ9qZB5ro1ygJNpwQ5Jdq98sz1vvF
CTv6M9vtGARlti9p9UeWLMr7r8adyI2PE4L2c1M28tMd9jjBhcYhDJnb4y6imqFQEOWvgN3HDF7p
5Bpl5/FZu+G3ztuxf7fLHsK6fIb6dv/XYWv76rSLk/4k4U7j5Lv3U2dd8JwQYUfPvr/LMkR92//c
uO387UEb+uUOm7+/20Zx672nB9sg+tFEXxXkx6XyyXGNQHK9mjcvBLRWRDzOon1Zh+vyJ+/8rN3T
8XnuSi1VfH7t7rQcfXlHzlK53cS4IjZ56Lh75rCsu2JyOcFe6fab9ktbXYJyQTznFg/b3MrjHvFw
mLUcUWlNAZmS6m6+iFKUIy5aZBcvtMoEpCyfWBYSpham8va+f/6U9e46ChIUMivVV2pbqq+ZdItd
OP3zljoWIlASzV7FRllEKY+WRH1T2j78039vrV2LTitK/fCTEL+E7QOnibx1+GMAJWgLTwXs/f/p
hG3f9ShxR8Cv6h/5VE4nIgnQIxDTs8fvt9/+0/ss9g4eb+YW+dW7b8UwmX0qZA/80Zh98GN/aauZ
VurSzsVV6z5Q6kUTbcb6Tx6wP/9ff8hSF0K2/4Fl++jPfwr1YbKUE3X134cV/cG41dWlfgpOgmkC
reSKRE1tUleEE8rg2Zvt+Bc+SFx12Elkrph/00iu4IcqoY0VBhcFMVcfSVmE2AQZ+qngUUpaQ1p2
7vlExmpHU7AGeK5xSdCub8qL/RVcRd7B6UHW5LOd1URrI0bB0Vl7kIho9cSqDmDLEWVA8unK3sCl
CAQ/gi7wKvGdV/FyKp21ek4lQQKjV48T7xxikSVCHDwJl79AW2+Jde0N//rnNYKAllySeXQUc4K7
qxbsT+7+lB1s/gbrpIH5iYbR+k7bIx7ZQiv2DZP2DxcetKlUk/3Lg8dLYrkS8pJVK5tTj2V9jTr5
Xa9mg3jMLj5j8yuPMSbg4VIJKblruCjIPoqomdbG9xJuow+13ofZoEsOUkKoXqH1z8oEZP1x2QXs
hQhBZaS+G3N6pbyq0uLHHJn6YX0UazwEqz75z8qquKJLykp4nZqkw4FOsOoiOwNJZctlFLQXxvcu
esk+CykLOpqZbMD6HCQXFvbmxQtjFwmZmqkC+cLvjGasvuG8db3rdltcrKU8E0MM/a2JW/IuHMcv
VUfXAEiMbkRQXVZWzVB9+9dI72dnOm3xFGF666HcdFuIPhSnz6Ja7IRcErYL5RH+0p9swuJ1qCCr
LvFe0U1eQ6AXIj4KGNjLv/WTcVg87d6BWFnXNAkZU2EDhGRsd51l/uAGG+qstV2zGQLgzGFxTp/I
IHn35M6k5X+l18b3EK8NAtE1vmKJF3E/8k4BxGVjEuLnitCZrbh1P4Fb9/mP77IDz03Yzb9zzgK4
tslDJBRxTf63vFKUUx9Ejfwbqkug0GuXfENpE7UswdV7cv3zOgTcHPaJx62JBfuLe/7Ubmp6nGnD
bjYwsz61PGLgfQ4udxAPq84+tOMvLJWvY6pprsGixx5N0zEUwsd7JMMeSe5NpKVVNkHfFDBXjzl5
sJBmFp+2hZUnWbeNjEPrp3wNMS7WVwjcSVxFW8icsOXsBTxjgEfZgQfcbg0RwZYxXwJbbcmln+SU
fzUhvUIuYuklEBo31mBtrGmXyv1iabf6mkBMYckjanD/Hgpj+QgOLhZA9GqHP7WZZ4cr9py/w5dM
IdGzZmdewPm7bC9gDxWdd+AiTgxb7PSRPu80RL+TdQO27Y6MpQcQ2l6CfGoOScsnSQjZ1s5xh8SK
eRGEAN5xGxg7fp9FeJwKl9nI0DbLjOETi1OLcJxOFJJprJXg4+Ckm4xlbopgS/0teBRG/5hbM+NN
2JZUW7JlijYlO9HYvHH68NVvB1vyu3fwmgBc4d26W6hUMz0m8Ib7dE+9LSPbkEwiT5hOl+iW8PhR
hN+ffrDXjvfUWiOhNJuJ/yEtNyV1S/SygFV6/eFFYjcP2jZiUo/Xx+yRB3rs+K/vcFHhnIaWwOdK
+R8ULCMQrkZ9AIrr6ToELgcBTZUkk+9oLmZ3cPL41D1/VSIezWxqN4iH6tF2SX+r+e32ihwlEmYi
GclhQMgGzgW8IaDV0m6bTO8hPjxIQnGJXAc2z1h36w39sUE8ZheehXg8BS3wXJMw0LKec43QNhDE
N2G4iWUonL4ClwRfd1qA7FjDoXo25hBix4fYKHrlBGTTQi5iaS7KJEm9KvMeevvYjcqv5sqvTj6w
ggGoASnAkVQaAZKzSOI62r/NchwogsgERESEd0JERRwdaGPnUA+STfMnoQKTqn7I9t/zPMQoAxzC
FsMvWGMXnNAp1/2KXdSY8qiGJ1EFboGFJlh7fFPcPtfPwWoioD1sm8mhnTY/ZjZ6Om6JfYxeh56y
5CYqfc5DzOQEcmqkA1uXnLX3TjKGdltZTFhtw4wlGyad4H9pTgY8JNh4kvs42Y/GzJ9g4GaxAOQy
lTV0DS7V1wUGvufUnH3kr0/b7oFFe6W9ijClqEHPAUjBhHZvOz1rP/nogB24sGBTNREbONDElNIO
paxbbCTSPUzG0Ywd+nS/HXplxmlSPX1Tsw3/YJuFZtkQaHv3Ksk91YvYoF+Vc/vV+N+Vc12/+xaG
gJaDiMeRXNjuqZ62T97zF3Zz8zfBCzp5QBS2pOlMhzttxML99uHtn7H62BizX9sg4RiP09FRfcZa
E6dxY97CxEfGx/p7HZbdlp5dy5/CGQjDQUrT80/YfOpJ8Aresd0oykfCqOHwhEI847SxlDmJDyy4
I7I/0AZZiW/dy+YFy8277soEpLx+1yB8bSF0eIGiFatpNGcQADtVI4fcrv3q9TajHvbwfFnRNi9Y
RKGth3i+HAiKnAIcAaO/EbSTJs7X2OxkC4LprM1PN7vsuVVYRqmoMyaUYZ4QUlPTOAyvS7CvHMDQ
G08HcQk/a7HYYImAeEhUj10CqDW1xH+eOWj9TyYs0cwpoSRTUZ8CMgYsZXXW76jj1jXPW33LNCyu
DMGuJumn/IaBulEp1F91nYJGcQ4Q8dPL489/tiYWlirUUfJag7u08yfqhsWw7Wj6wpy1EvFPUdcU
ZdBtOhiU3kDDiUXr/t0h23Z4CjYfxJFjSbGOhVcaq/vm9HbhB9DC+tkbLN0Ws/2/c8FufmUav5YB
m0abK4sTRslWfPiUinrjowI3TG4quJVYWAHacfW6l72e28uoTvl/F1VYlvf65VsSAswQq2PDdSQb
sZ9onLS/e8cf2v6mR1k3uCLZcvIQgVCKBDOWCC/YUvYGW1rt447ml/5Um5fihJxQms5SBhz35ppa
JeKB08HJ+UdsMfUseJKds0sbY/R+i2sCOxlCEwgmUEKCM7IOh41RyzJdJ5OtyYPo1rvlv8khFdv6
3XKKOOGQcqIGTSy0vJ7/9g+DqPcgZNEq3yi00ezGvau5cmgDhL84v41Ig/dB/DQAYkEkYG2JEJaQ
qcYVRqV38ZWgDZ3tlUiBnf006rcJTkrSFisNXBn539bRD3sq7+xJtuIk9VP3siMB27Z32lMWwAdX
Ed9X8ve1kaJW1ZLCc2WnTTxfjS0LOxRfIqxMjmfo5ZZigMYSjXKi4n44Dixr5zg1ISSOYT+DxlmQ
e5FqhNeRtPeb+/4z9zyGIItx6QSzcYq8RpDWu6MqcTjV7VxXxJYa4x6S9wXkEBmGYQVYWrmdMWdh
Xo3A3cku3Lvwxuo+gXEOx4zDnFAWe6stNJ/HrXvGUtStOqQEU3p1XiENgz+dSqSFFaGtKH8LSYgp
xCHdRLwRngUVOEr9Ibl6dKG+l//p3vX0fQEBzYR6kPuLxPL4UU7xv3PPH9j25Esl4iHHfyhjrMnm
o3S6YPHPZHZzmiBca/ag/fbLD9jTU3scrNZKrKutgBtBa1Lziyn9Jkk+8UjbxPw3MRQ8Cv7Dc4cb
gSAmlK8Fo8QG1mlbIbTlflPyDquJb2chskDX83DpEmX8Yv4tvssx4sbtsoy61CKOYPsRDMHX4ToL
rz6Xjdnu/RdAePPsmuGXx3BjwolAm1mHlL11vlHnVV1RCf/D4UlrxTWJ2nbyBbj1IYT2/oDUptSG
UxMhGx3utUPqNJ0YOtNt2/cO03f4XZR1WIuZ0Nq9SIjdgK2IHtZwX8/Kk4gm9gjdu0H4knGjrrU4
3cMFhLRtAHYTO24RJR73n4B4oFK75gxQyispA4D654gYHWPCZ5ZrbWWpndocdF29fklHbC4S7GuX
gIPK2JJNj7cgZ0cITdF1r8F+4av9pn/SnqoGZmf3N9nIv2+wqSrkRWg+1V2AcMmlO8+zapQkw0Od
JnRvkXjY+R0ECdOL4p7CzSrGdNPEikWQl5zf12BL/z5iU13Vjs3VMJmyMBpezv06dekE4+iuxsNf
GKJUP56yIDYmrxxssZnfr7LZ1oRN0c6ec0SJG2Ge3SpWA7tD7j/xP+6FmPDusQm589Fha/zyjOUh
gDq1XE9vXQgIodezixDx+HFOHr97z/9nXdXHWRPlAvOiTcKuqkbhpiYigoIib2SO9bpINN0q+5Ub
HicG+oi776v26gc+GNzK1DVT/E2UNojH5MIjllo9Dp6SzKOE4DhlhEKSY4DyHJvKU+vViCVoX0yd
glW1xAIH12o9rycBofz3+oNLEJCN5+tXTnhbotLLC7VoEjVZx84jcp8CYQHLUr98ZMlNhdxyVG5u
vboruxBGoa5TR+5GffgUDale7qnyrQ0Ao1gPJ5CTSUujOJGoW7Ud+87SNzL68FNpftY1zlhLz7It
nEMwlBRvc2OWCDEV0MCqbU9bUwsCdNovpOKoFQ96fYY4y7dWGI0u6QwMnW6yCDKVi/pDnarVR/KS
32iXo9PEmSP77FP/6u0WaUaGBPITAVxPut7ozvpt/2IN4EY6ofulnbh//6q/1R6uSCKpvLXPZDh1
FDkpBKwdddtDY8vW/uSss+uoXshaC2q4DvnjjiS8nLfOybSlOGnkerDqJVhUJ+Xj8/DxmmD/PTtr
70Igf2ZPg50kmmENware/eKkdT8yacV6xg2BDolYEHAqJkDyjjTsQkPIuh6dsvshGGf66uzszjqL
QXDuwop9zxPjTvEhJDbbDKc33o36qj0VXFu30XE/uL6e3roQ0JRtgHgchnj8SMOU/Yd7/h/rrnl5
E/FYWO2xqdVq21V7ch0QWuex0LSnURUcsHa4FhtJWyCxYpVLO3APafQkvOOy5tgbO9FvWN4F5L8T
89+AeLzCb508NA49i+BMtx05Bp4ltNkVktYTafto5SFjzhJEyiHZ0jNvRQIjl0f5L0ZMlU8ggmsp
r9vdYzWdmQdR5NA+Cs9ZTX0KY0KKunMdFZcwYAQtJGxx3EIWIi5/PdR4FUkDw4vvYo2tLDeCl0b5
CcKQ00PXP71sL+lkEm8r2uixGLv7XkvUD3JKSsLukg6zlzweJ/x3eKMdCLJPpdGF9ivw8zAxV5dC
1v2OlCWqXnFjlLC7qibvsY/IF2TXrHKp5Z3YorRaRL6wtp4aRPyoK7OsIw4ELUk/SiyuIvKMdBp1
WGl3iIA4OLpsXn9eBXAiRE6ZoJT9NX/RtqIKth+es5bj6MmrL7QfwOo7Mg9QIRZiABx4aNhuQl4T
JkpgHqeVVQjI7/3MeWJ+QEzIG8BX1Q+PncaSHIUHTsRB4iXv+fyI7eiaxhUKb02sqQHYcsiuFIRK
QayqiT749k+fd0MIUYdzR8JKjULM9vz9kO3Yhup0jLwQm8ho1hkQ5lvD1nwSDa9BTsNKPuwAdyiN
ESNOP6+fPjzQvBU/tTTqWAMiHh9tnLDfu/tP14mHtK1EBDQpcqjDe1I7QYHJwRN9Kg0u7YJ1k7He
GuZvacch3OA/H1+5xRpicxZDTtLgZL1eDV7pN+KncIKsx1dscuEx7+QRKDt5aJQ8F1G8WI7BRg42
Vhgh+qrckDt4CMr8iXBowxpucScTyUq2psoExIekclOPNNkyMyE6iCCGBRurkmYScc2xpUjUopGE
eqxTEgJhOsKh9q9BCgToMGO4474vY/8AFw/LNvHyxM5xU8LxN72GhIQjCKWHv5m0hcUbrDkwiEEh
MhDsPyTQdvCgVCELsCKL1rYtbblRENuuzR0VnFeOBqz3Y3lrwJjRcnHkKbOw53AsxslDHns9bTCz
Cyeabf4ksdiR15WfItzwQ3ScZhPVHgGTfESnEfU7l+WIiBWeQk9Lm6s0hzd3ZOsvVeoGrXq2PnyN
v6lXhCGySNhOvUAl9Q2vwoKb/iILqPlJ8C3kz7leuaK6N8sbgRjorB+fIJIbxNXlIZ9gGR/iiIoj
RZ1yZE/iuq4PigjRx6axxFcTPPfGx7VfFr9XLti62qyiLH+af7JED0OQvM7xTNUBFL8f/Lye3pIQ
wP8a8/NFBOa/1D5g/+bOP0T19iycgEa3KdSQvU1iwJoTA/z5QPAmXGna2Y5az9rcIx6aywWbTt9s
U5m47Wt4FocKEjjDyiFN4L2XyeXNW3fnjfbhEY98fpEQtA9DBC6An/yTh99XOUXElgUC4508tHr9
VIr3QcwPQc9bUzIoBHdGmyyTxasGpxdBycGPRa1vP4lcXyZRVLtyCEixyPbRtY0xGJaeZ17qASEn
qFA77dIjai/v3mUqf9XHgMZVFq9hQHqP9EMaTe4mPZ8cabflc+yAtat1yFlDCxNMipMSp7TaZnjm
uC8pEJVQAacktxDxkFxj+z70nAWKrZ1lgopINbfDFGEC+sg6SLspZBeS97hC9GcWucjKKYgKxE1V
ucS3+KaFTD2yIl5k6f7sRCPaa1QonKzsJYKifuv0ctk/P5/fTqm5a/UlpF3kNLGGpbf70ynLx9E0
ohODQtuWq98K6StKoBPIaMwqL2KipH7yV0B+UmhEAYFv/557rg81UWpv/Z4u/LIQHJUtEPbWGRWq
P3oMgFVO/fHLq++uH16W659vIQhoOjADHPF4CfnjjzeP2L+9648c8WCVs94k3yjNOzduldA0Uikh
PD3Tp3ffLULuMIPcJx8WDc1bUxzeN6m39tucPi5W/3UP31AfjIkTQh5LcQnMPeKBOu6lXGw41pQP
J2Cx6UQBLNZ/e/ASO0xpNTfitLTE5tp6CmHVVUg+nPVI1BdkF8dJYigkKgVu5viYqCZecB8xr8kr
AXEcou2Qpd8/l/PqP3SikO+q3FIV7LJGdrMACwLi3rkmAv8bWyatqhd3GJy83MmHMrGeovW/gi2I
2JjSqwXz6PQQ4Cg6M95jJ164mx0xwrTksDXfABEhxsc6S4i+y/ttAo+7DQ0I12ij1CBthJwNSCjM
rhtAynf9+Egre5dSeeVVeYhBmAPGxEi3jWNg6ORRPKhtFJeeTnEqiWFDE4T/qjFeI3Cpo68tqf/+
H/1y1+qc30H/mX/Pv6+8pXs++4s7m+6tu4D3y7gMpY/yev37fn08U1lXL89EOBwB03O16//5dah8
qawuN6Wt97f+3pSZHzwX0Vpvr/x5eVn/+tW+L1W2/P7164oQ0KsVCYhBDF5Eeef/7jti/+ltvwCy
P8ETlDMydTaV7uVaOfUS/KQ9s9hSrFeepbEyH0t1If9gt8n9mcxeG0/tc89hkFptdBC7j3PklC4i
Gx7U6pWaxMIiV3nN7sEb4ENyjQzxy0dmv2jpbD/dRFGFmBORiCcor9hFJ8+QXV0Y1lQD45IIAiyG
NlE00loqAuQQuOdyGMsJrg6JiVSULzQvq7bTF6cyaAkxS423aRuqpxjcqI5gkJfCYm7uHvRsH8Sr
8Fc5tamZ15o8gqDAVTg/g3AU0ceWOl4oAhLWO6URqeiG4LfnfDEHu/Qwp5XBs+34rkIOUjuod49N
R9TyC0lYUQucQJgYwCweP2bthx6wgSPVlkAU4uRKGitEN3mjWdeOca8dGpIjRV8V2LHPMEocQcPr
xCNVVnsbYioIku88Ua7fxUps6xYB4iWsyL0LUzSBDyjZ0ajr9POaAMnVdm0+xJ7SK3RIU6cP4Otk
CXw72QTNVJQtKK+QfCmfhqYkIbk7bek4pt9i1em9+UjZ3d1oQ6cHV5bsPtFwYFL9+i+hO8J0JXfy
kX0KVSr5/fR+eZ/lJyH1zVlBlrWtMm68Wj+lPq6X99tbFUDotn+y4ucmODFJK8KE8g5+lIXL6sGv
vK+qlhPfGxIrrQPhe38hkCkQVIhJ+TIbuz/c97T9iwP/lxGaqJRY/xj+ZTVpSUL82qF5JwvWJUbF
s5lua0m8TLyPHhtcqSLOOeuSVB3GQWrpBYjI6LTiERxvjqk2pRnZgXBden3u3hvhQyePVGbAJha+
CWtKVtHSnNoY0UYfS5PRjQBuDdbk+cIip7a4IyA5rpXkZJGPjWKCDQRqHTFq4XJPhKc8V2UCohxq
10/81unHvRiuZQEuraxCJgFChr2Vkm0GiL28jF/2ar+pS04ScbCFD6Y07CAoBUknAD859k/ZaJwc
BO7V7Jkw9iAttuc25CBiG2F4kF/NoZmVtTp8a8FrsTrkG9tuzdvxv0OYex9tqfs0l18KWMe+tDV3
cIQVwsB/leoVYXAJnzhIa9Fm2GUj/1hjtW/HCEcu2X2wcqn8oRjHaiZ/errVZibqrHc33mZlnOTD
SN9lxbzKv0efDC2HfUcWF+vSsoqhMVUEwa3iNl3fMTSs1NfVOiaUEmtMuzrJS1xQKTznKp6HyoXl
YZG8qUaMTUHAUSF9fmdQCy6A9KMZ8iBg1z0RiEx91HmFUb6IEDaTOFuNmjjaXdLSiiFQD6zAPuyM
23JXApDizn46a8khKL1YaNShfhboJ/sa9xa0+YjPYF+jNsiTp3+ruGYJy1swgna9n3Qd/sdgt+l3
mD/1xyW+XXtdcVtpxQ4FApbEpX1iFPkOrLQcMMoCqzCaYJLFZLF1cclHaqpKR3H6I9iFkC3F+NOm
RYoeq7SraEaxJWx/RGT9dr1arn+WIKDVJk93QXDAcdhWf3XgMfv4jb/n0Njwyj58NbXjquQRa4yx
0XNJclHWF6kobUfWvGKcn15EQBnosraqlyEkrXZm/h22o+4xXHb45YQYhXgxisWXn04pHdWn9Lpc
eiOeQBzxSPfb6PyXmeCoxYfarTrabQvpI56sw8kzGJdjSWmtibhooqHIgt8vlc/lJi1FvlikzXL5
BfD5Cjo+yiN4+Ely2gY2vPjwy0smJJuaDfyrXJUJSKVJTT+85Uk3CNASRB116PhONKSasQf5FhXr
Oekargm9VPef9qIY3WUWQSKZpNMCU1NiFzkkX+qvW7dEG5x9JmijQztsz50vAIBVKHStjYzegCbV
08grOMlot12FPUj7NGBt9U4EqpDGCli7dfZOUW6C34oFIiKpiYmwl/YUpUsIVG7hM1j21QU5briX
w5eSxk+WYhavlvjwqkFHPRpboQ1NyY2jcEjiEB3cNET+riQJ8a2zKa+kwJXkoa+BOeJ3/ECzvXB3
u3UREOrgpwcsuFy0E/+0h7ggCXvX5zjag0if+OB24McyxVuukP8SsLjn2XErJsP21I3NdtfzE9b3
6TFbuK3Gnvmh7dYwv2q3/e155l3Ajn2016bxiXXoGyPW9gK7P5BxgIiFw+9utmM3N9tNZ+bshv88
aAXkGqc+1G1n8LV1CHfu2//zmA3+ZIcdxyZkAuSt1ATy3nt8xvq+OIbgPGgnyD+B2xXBssBpIspp
p34uYzd8c8y5op+8v9mev7/T+s4u2I1/MWhjH2q2l3BFn4CY3f75AU95AG0vvcbgQtFG3tNix26H
8McjxsbXulaydvOT49b2uWkb+clm+/a9nXb36WmrOblsT7y/F/YKho8inKQ0hC8GoWo7t2RTO2oc
Qb3jywNW++yyDX60zV68q92aiLly+6cvWABC6k5KV/j+XQPfBx8Ch4iHRLcvQzw+deBRiMfv80uI
MAvRmLUkxFnJOznoqmAvTr/DttUM47NpxJZzjXZhcY/d2vQSvq68XfYMcsnhFPZr9Sqn9QgeAIH4
p4/VQp2dX+qwnppTEKGNtara3yhJyH8lfYH45f9I98E9CLsLeM/NiN2kXb5LfHOiSMS2QVCyzgVJ
JFTriEcW/1b5vDhJEkl0IvshDEUOXOfKCqb+ZAQ2nDaiEBxXd6nmrV+VCUhZLiG3EEh5cTSC7Ucn
DS16Ozt23cm6SYTNQyB3US0WUAmX+l0oq+YqLxkQ/9cgIGv4uYlXI3gAbcvVRwD5iCd43ly12EXs
ZW1yHH4e/QkmCnb88RttdqrRdt5EL2FHuRMC3U3WTlii/QbuAXDKCfFnh/Ewu3uRkw71YoGeRd6j
OoNoVelEJPU/iVYuvJKkLJPPwxteJ9RXBi8aI3cvRbzxhmHBRavQfiCfc0dCzgIypbnjePttZpJS
15qw1Ksl1QsNC7ch1++kostkf7WqLnqmuthU5OALzHNKWCGC4I6bktbwhVlLcxIYZIfttKpAzJME
f6plIL1DyxbNFywbDloVth8p4DSG3cZcS5WbfgpONU7ePMg0L7clwGQCFyY6qFXLTkTjoT7ZczRC
sFK3tdopglFtw39WoT5sR7lO4Mak5eySpW5O2IsQjwX6cdeZWUckXtzVYIf3N1vbmUWrem7Z0jyb
rIra/oEFd2IZ6a6xZ6kj8Lai3X502WlnDdCfXsaYxRPwwM2EJcbS/kPPjln1hbStoaqsOav47am2
qJ042Gwj2LDcQ3t0075xQ5Mlbm+xhofwTMwpSmPTySM+m7WdQyAnCOS5bRx9SX34EJMxZMvpBVvF
jcvjxFTZtStpVd9csbEb6u00gbp++MSshcc52UrLrXz+uBq+vz/0Hrz45bCtYB996ubH7KcgHkvZ
3fivgoSEllGxHWUxaIPnsZ30rRQDmaYxEGxExliD8XEmuxfWVb29MP5+1m3R2pPPWJc0SF3yiIcu
HWeF72ho1rYlL4gjS43qyRsreWyrfojHF8AxSaZdAzgJ90fFJRxDDjMQyXc2+i2V3ZB06kEeucIc
eEwEuGi1iTu5DhIDZYhNuBCQOCN6tlFWI5fAPCfDQndfiOLiVJmAqB4/P5TYWXnDFsrlPZuGAMh0
ERfmZ47dYHe86zD1b0ZqftGLm/vO7ugVa6MwN9VpC3Pt1nfgaZDdRu1SqdUuHlHDehIrqvqmNes/
HLUFuFB17YZBYb/dePsTbp4FxEcQhqfL3X3jltwLSWJOSZNLzYkbuv1GsUeoFxW+pITfggd/LgYK
5Cmfb8DKvdlCSW7qmZ+41ilQ7L14VcoRED33Ti6MRqq9PJMzxR//f48jk1n2Th+lajZG5lfofQsO
UiiYm0zaY5/dBzuO4zpKBZva3lzkO/sFOMTbV0ApsV7GMd6rS84TsAnnkVpN/NdzuRepWc7Zns8O
W/UAaoG1sJnYeU++rd562M2nYCURyQf/VzhnIy+QhpUVg92DB2XqqEvnLY5BouP/U2+ReOuN3563
m25etMf76m16X60jOnMQnoPH5y353xZs+pfbbJiIhLeMLtvOvxoCb+Rt8RNREHOtpWFrVc0sWYi+
iZW289EJa/zsnNX+UicBqLoggLDg0OSSTEXjEHtu8oEmO91ZY7eMr1jPY1OOzcuo3YsLLBZs9UDC
xiAeO/EivPvPsSXqjlhzW9KmI2Fb3QZbTjDCQl8bhTqI1/5jHP07wjb6Kze6JXPjpwctNIYnaTYd
2ZaoNXbAFqGviQ9lbKi5yvbh0qXtRQgh80vtXuqdq0vfbwmQQgT4ZKP2Mkorf33zo/aje38PJNkA
y2maOVRnwysdjoDIR5zv+NCDZNhubHrYgcwJwnm+HVbV+MohO7kctQ92n7WOmgGeDzCdxe7S7PRT
0DKFemQrs9ZbPUC98D7oxhvj3QgqbDQ5Daykz9v4wlf5rRMGrHO4IlFYTOlVEBjE04ODxqTOS8Cu
8TJOsVtIWQhGKNSIkD2JrcgI+HwGLXlffqJ2ypOIMi2gHuzg4NhbW/OALsqLrF+XQ44Xql17okcu
fT3jLXm1rW0ctbsenKSITgLwHJEVXLOk9l1fuWCVReOLtm0Pxy6acB5qfXkEQ9s6JKcxRsjaga/V
2PJv3I3R0dM4KRyhQgACEpFA3k0e6m3pmEU5II0zxKRFCUkrjazmvStWXa38SiB8zbMSPCTElyB8
ZqLVpgaSFoGAiDhUSs7/jvg8dFBt5ogDIvuPqmQG7bWT7s/VqwHoXamasrY21ak8IJwLh/fZI38D
xRPCV9VbB7+p0Hfww/XBg2UNSH6kp8Z6duALiwbK6LVDeJJ7yFg0mCS/5iUEp4bY6AnyLsGiklrv
KvKPPKcTmWqsdBKZEHnEMmyvnmkUInCDojIenkDpAQApdkhbd9LO4fpkFeLRDTHqPoILbvKpHsVF
r8/kcIWGOje+3pJZyDz9SMcoLSNFusGhztmdSIdG9acoIwBJ+O5kNVwvc2qYwKVKhHmw5+i0JQZW
Ld/uGR46Jwsp8nJCmYJVtncczQw2FRHYUfc/Mux8gEUhUnLfogYd6HkeaGMx40zSvxeQY0k8GaD4
Zy0vzVvPLbDexF67u9W5fdl3ZsqqT+Ituo126cf15EFAkFD88hSA6+c9/5dbH7OP3fAHnCharR85
Zl9ywBn3VYXBA6QN4uF+8ZG31UIz9hywYbFKdzZkLJT26mP2c3tfUCaS0F1p/bsrj5CMpXbaybk+
u7/rYU6cvE/hND6/90m9EPEI2lLqBALzr/MbjbRwK2wpbNPYOTvjP7FO3Oos7zFyHRkI8qfTh0uc
UGQPMrP4mJdfJxYpQKmsOwRoN846C+E5It5H4KnnBOgSLJj0FVJlArIlo/ju0RrxzGAhUY8M6pTC
URYyK7cACygsCWapjdcKfI1Fp55QcFbwQu01zYtddYRsZZHYGfWcEC6RwBPOVmRxElfkg23W1Qd4
8tIxXoEN5fVMXnkVICUQmHBykPOrtQAbcoEAvfdWBKaJI977kNc/IQsmtdhO8pwr5D1yoQvHjaj7
7uaZkH55cvl1gx2vNMZKCRICO6zRjr9wyHbtP4VPrXFYmAiFgVseA6YcMpNE9Rw4rwREv6C+3W5r
mT4QhVD1lz+7FtelCiX8TeJaZAYfU2OHGiwEgvPbEhLWTl/soud+dpdbijpV7P3WmEOUNQiFF2uj
NteF2jWyg0aE33nyZ9ohRJxAlkDoSeQSAWQrPutGp5oi7KPmIwvWAdtoinZz5NuDq/ha4rDn+0KW
VhAz2hFLISg5A/1wSFwd0x/vQ+88wrs5fW+bDdxKPURBrKbv23F/EkS+I/mNiMZ0d7WlccfSTj9a
X4AdBQtpExIX6KnLETctHIiFTjatz3L81yNkNgqC5fLwW99qu3ztau5qIyBWV3Q8Z32nZu3Juzos
y6mnifgpnYdn0CFXHSp4PQkCgkQ1QF+BVd0Ph+DhOx6292z/M+424DV30jqrauzs4m7rrh7mlADL
kbchtDa3CsHIIIOtw82RS9LI8tZcrljt7kSIh+60s5BBBhRdkJRGJgqJx62Jp77ZEJuxO1r9hawX
+EZIgopwFD6qiF8+ufgQP0H4nD6yEIRouBFr+xVwIiwmaUsx6WT8F0MVN50dLA0ASAmxMdcC2vWR
PDcmsLVc8iYvKxvcWAVxwUyD9gprOMtdHeK6nDxUnq/UfplEObGJUlM4zRMiZu5LZiA36XrzsrEQ
K0n3feTH5VUn1RFJoKfdX2Vzs3e4eiSPWJjF2tQZEbLXEAFTI5XH5IhpvBU21ivE1+AQEURuISIg
ZKNyTiUXoIsl1bFz2XKD2lWzQ305YD0HC1bfTD5iALgYHBQI0G44ognmEc6x0T4cMVJe/anQB+EY
9dWHh/JE5YwSPmx3H0JbPPe6ci5cpmKi521hhiNoCM2hIG6VuV/+Z6WJn0AGpGCL4sJd20QH+Z/h
lFA3lbGGZdzhb6thhyPx4pbEvQJHixyuR/L8kQlpOkZenC7YeNt0b40tiIDMpK0OIpKCqCzD0spw
kqhfxv6Fsutqs2oWjaQI1ug7T87qvOfYXb3HZi2E5pU0qMjikgiYe3la37qpn0qlb7EdzvXW2nOc
YqZps0oaV4vyxLyRLUcflJZgbS3t4FSQ0enEe77+Wf671Lja1kHT78t6Xl1UIgSljOIqtBxbsGaE
5hmE/dv7F63mHKePBP14o+CpTYP57v8QqEQ8jhG//Dz8/Idu3yAeSF5dh+Igep1APOIB0S91MxlZ
ts7qk/xSLcT6CS3YjqR+o36baXJ/7gdUXetJhEdpGmH6heUu7xH3xLqqiZznt55XfMsu73fvQz0V
jsNZ6corJeIhFpXmL3MWfLGqE4gM/RzxUM9YK7ovgThCdf93FjaVJlsYmYn+Nna8/jgFm6gjPN5c
ZqvGe8jlxylXWjxcXSpdPgcwlZylpisP7wx5ADgjmgCRcfpYTcPrJiysOqv/qSVUHOFyObmN379L
tXzJ+wIQSCUOAohCEalH1uQRtL6yCKa1q5cW2KsmyoRxkjh0FkM/dhvoS9JPkJ7sQbLwEhdq8K4L
LwSCvm3vspN76GWJtdXWBcC573aSaoTJnVlupU1CWiLDyAKCsfNVFkUAvp6nUmfog+QUi3Owuwgk
pXeRw9lkNLYIS20S7S4IFARFVvIiCO09/fSp1ZZmURG5xFsRXCrhq0rNf6f3hKpngUEDcci7kTdM
I1BfxJ16HAIhhK/TiTSc4hCF2z4/aPf+5Vl729+et0YE3SIiDYsZyyJbWuAEkgJZNhEzvY7A77Ox
iM22VVmr5B/4vgrAcipfo1oqQvLJcdzYc6SpW0F7RO5PtEvXAbA0YPetomwm6OZGHcBOv3OUvf+R
Ifvnn3zF9iOknoRInEO7qyAZiE46FNG3iOMCwvSRA43monWqrvJUNm+lPCFFgKlDdTZ+Lzu+FqJO
qj9by5SXL127NqtCVvNyyrqAzTjEq2MEeY2CaYm9dj05CNSIeOAK6cHkpL34jr+19+7QyQND4DXf
uAuFFOKW9y/e4vJ7Am+9JNifbAzT2Xcg57ib3zp5uHOqy9eSGEZtd9hdextBlfBebnf1oO1dP7V4
i83XynIFvqcfHvGQFfjswlMQj6/ScTgV60hBbkYIYBfpZA0w+bVDFlJ2Y5fqMuGyo7tL+T046VQh
L7uep13hzvLdizzyriITOVeqhy9KOySuy8ukyqjKg7NXlGudfuQqPZeDglFCcTGk2hqDkKwn8tXU
ItRBzi4PvW6Rrz+88guVk+FibdsqarccTWkvgKqshNIiJIkaxQUHaOoXhMFZp2+pXog2jHxior8W
ATzIW+uVe1lkEJJDOGNAGfVxv7Z+wup6UxCnkNXekLeWlgve+5AfLsqo/enxeqIHQoggmnMzu+zC
E3Gr7sMWZoNDtaUH/FSbVFFVM2vVtQu8Z4wxeyYgHhkIkpw8SnZEoKtcAuePtbaK59BljB0jUidV
7BHcxqwVURAt/Wm87hR1cUuv/Y6ArvoZawGV3NbnZ20VOcA8Ngti/bixlFoRYozN5Yg2yDuZwMEh
qqgSSSUXYTHybKk1blkISPP5JatF/XUmIUIUtWYIQ2iK05YjIBQoT5pT9AFc4jXFtwM9PrQSnCR0
MwuVkafn4CQnE9pxGQVjvyoQe2IkbcnPL1oDbccRdss31hrwlMFgCgTejcbXvqcnnJrvICyllf1V
FlzcciLSfKNaLbEQKr15iOLz7+yyR+/rsQxxSYKCxxUmNwYZQPpEUBVfTw4CgqJOHkdXY/azrYP2
qbf/n3ZL6z+wNhXQCNYjBoKeoBsVfjzo7qg7DKIL2YWlPbaiKIG8eOkz/N6JW+2ZiZ2uTp1CfCIR
Yr6ITmcLaFKyhpT8E4iuj0y/y2bTt7g21tAiZGvk8IKeeel78bLoIWwjaT6Nz33N5pYfpSvquzbV
sN8ce451wAkhnRtlomJ7BSEJB6WXLGRE+IXqGy2J/MJTYfFGohmt32yHqF/KB+zC+LWR8lYV3UVd
PdymHfJv/G3kqnSlmi5OZbDT7jC/gtV5XxZZhEfRMytCwoqgl7b0cjNea9m1U2ZpPmpSCAhpB1/e
v4tbeNU7wmcFJ72ttqUJdpD0oaYZnrUcm2mBi5/A98C5vTb/bNiSh9hhliNzJlYYFujSmYANn2+x
lu2ngG+I/nq7GhHu1BLEkO8E7gvaiZE+dKzaGrZLQwqBk993YTTydO04TX+gjPxMpXfZ0BO11v5O
jGtWywB10Yi8k5ROamFipahsnhOQ2FhhHDzqlKPqown02hvpF1k6G895bdP/oNtReZUG9FLhGEbj
S24qXNTUa72hYdAXUf1sA6q6z8MaeCBlo6jDuh13qX6JkNZgc63sQ113m2dkGJ7jZLGSsQjeeCWA
X8YwUDYRcdhHEZwrFnuDthzGRfsERkuTEBDscDTuTYnfuqf9o4NoqT86nUfQ+mpCe2oCTayFuzmG
L+P4jpNRGCJSlcYYLw2cqcztq2ANFbZBfNUG90Q4PBmHV6/61PStOduGGu9RhPbjBxAWnsDZJjU4
diOKAaHZvHUgq5ihvcU7kk6WsYIRYgsEMKL+30TNW/uvtjYNqPSDfCLKLlUoU3ryffclUCiKoGJ5
/C89p+03bv9VbDtAf8TykKfsVL4J4XkjrCXCR0emtdRJepmwQaPLRBT0ZKBhEOG/PvApqxZnxCWx
g+EUwK4aWbzPFti0VcdOMDeSeOw9QQ7VBCKlA/V4202Uyik/5xxNf5I+NF+8F/bde20e8cjmZlDT
/Sqb9TGG20gv5LwVzguCbckmis5IUH30ZpzkFs6K3HU+iOCbEBvawbv+a7zkg+DIlXuIiIN5HCrK
OeKqXLevExKUVYqouzt1Xq0kkB4Gig7pOBaZ1xY3LkqVCYigViojYCued3ZFrBaQ7to89hjwsrGq
np9sw8EgOvt9aGORf3kB/fhFDlsguxL8L2rwSm645hmH1GFDsIHkhDA90GtN7ahVos1UZEcRI4Kf
nssnlUtlb1p9DmHBvtQftsnJXcybx+kPFQIX9ZM9KScAJiFyjoameSzSs3bsc0Hb/Y6UNbRCDDXm
smOe+OthseqyZiPnMCxUJWXtlXpQ8ctX4U1z6hjC9fueW8/B1uq0ocN7mCB6wVSk9lSltqxe45vr
4r4s8CeGONojyxFBvdL2N1d0iV8AzMklIA7SegoP5q3n3Lwd7cXWpSQ3ENuFfQTha6P20If7XH/H
YWl94PCk3Xh8EIEx1uFoTx1HE2snbK4qjAirx+D3M7BhBNd7QPbRmZzlUYvdJLgudUmIdpH2q2hH
oNUBsFiP9t+ZlG2fTjnV25WP9Lkwt1Mg9xsJTJU8xaTvoM+UmaasK8g7imBZnqVvC/S1gFaV0IGe
Z2BHxVAD7iQw1Quo1568odE6d81Y1TAyMoiPjBurTtMeJ5WXdtTZN354h1McmMTG5UbgkTiGa5r3
0A51Ffz21H/gIvmRS3qFfuJa43B5gaMjJpqzb4bkFn75YK5Np/Vua9ktvIhniZ/g5PFrh3zi0QJi
Q6WUtJKrwYK8xY7O32RNnGY/0PM1iIRnj+BsQMijdypr89qoTzzUVyFhT9bRnnzOOpCqYQrMfeQC
JO9EAzpgTm5Lvuju6WNw6XZ7ZvxWO9T2DBENj/K8ylbhAsDp5JoM6vTrmjziIZXZcWJ55LJDrHHf
o65YVjLoq4eIJBkfG7L0OQgB4+Z+vjDPt+ae/iA3ck3iNMlK81GdhwjkMCDMGptjfzAujz8wxQLR
iYYB894jqPrWJe61FfqRyaHsAy4UC62CRBRceAVJ/StAzUXdlcQblvGbHCrWN0/AigMp8LJaulas
pmPNpl5hjXmnxiuo/eIsbtq6saG5047V8sqSZdL1jpWWh43hJgILsbfvtNW97RYITAQET5/KFyfX
ETR8hk7XWQ5YS6bikDlgKHCCkSzFqR8jlG7uoH660bV9AtxArG88DUtNsIh8QsJwERzDnQp2gXb8
mRaLbdvS1sVD4A6l2GVJTqR+RWOr1rMHrTJAeO7lHfaHH/wBDqe8MPrjv8aK1ZTdDHdD+LqJzwFB
1/q+JkkwQ05QN7Bi73l6zJpBzMV97LhfXrAHsX0Qco7MO6Db24iDLr6AL5eQ64OmIbTDQPQKSLX7
pRlrb1q2atR6JRGvgYAcwjr9IMizmXzSvhILrDw5WQHW51GM8t72wqRTm41w4hCyVdTDGG3f+rVh
azjUjDAez88g6u0nZmzb89Ow0VDDrQvZtqOz1lyDceMs76yV/eZQyu59lnmpeUvdNchX3vfchNWP
pTihoIX1zIz9IPWIWOaIZCgsoROQiKi0rg58ddhq7kZWgtaWaPpeNLZ2PAYS2hPagBMnKqdNprJE
YLzpeTZRJF27VUV9IpTFZsb+yry9G1XmmAgVwbbY6pWD4I15rR3NNU6qMQmgX2J9vbN+3D5x6JMG
x5OU4BVMscNmRUAAWnDFrr99dftQV62DhcVkIqm8IxzuVxTbDYIkBZe5z5ZOGpPuuaeaGwrANnaa
V9o16g+4r28KtX7EyvHqTUbn7BAefldK2qXwGXC02IP7E/CBJsbrmjziUSB++fTC4yDyAfCGPOpK
DiB8y2YFbauVzBl3CgkF8XDBicIjGppk0q5SH5mH7kQhRK/k9xuowd5Cf5IsIDvBQAjJERCX0fuQ
4Fpl2PEU4Hh4lu2lOYCvrWB4G02CD2Q3UpaujIBQj9g18jGjpLklTahwVAPhRqmvYU4LjojxvpTH
H4IrdBUfqlrvfmmhFaO7cXcd5eThACAY4ONdp4NKDTmDwhuK1v9UxOY/3gMba4hTKv1nokkNWUTQ
CdfoZAs7oajtto4+5Cy8D/nPkown5DSvqF4TEdZTanmHjcASi+Cw0TstbBlUGSzUKRGsWBxBH07c
gqhAJ5LeJA+CvJIg6SjIjor0/8qS3v13wIO/okppW3KChpNL1nCY3QuaT4oKGEHOsRNXIULCLg4H
le3+IrsU+rApya06KqvgUet6DMtNxf4AhioTI76I6nBllI9d/kXvSu0jq4ijibXnH6i/1J4T3Gu8
lEmeWrEDx9HOoG8uyYcU+WRzIhZb97eY1IBWYXIL3Isv5GyX6lLdbCKi+PLae2ZYVmrOVX0EuU3f
F+iXnnPqKHcnIlgkhlftxv8y6LVHHmcFyX25pG88sWSNLwAn/aYt1RFcXbOdqo+k4FxOSK5yJJVp
e3LW2jMzGDV6ZcRa+35LenPVfLwE2+qn2/rt/7jjP+Iy5IwDQ77Qac9P3mo3NX/Wkswd4ZkgQGp0
Hnd9SKkG1mwJ4ehksZBtRZX3Bttb/wLPhDj1tIDA/RCyjzrb0/BNLNG3I4QPQpDOl57zzpQP4jGe
7ra6CGrB8LS3Nfyj285Np+7FJmSH3dX+CDtx9kFil6vp1yUJB+l0MGeT84+iEHCatqppiU1PYh+G
gOOlkwZAAbHqtJEvwCFxhMXvlD/RlkHy4KYILpZWL5TyaH7Ceg03YzvShBuok7DQq8FFcephDm9K
nkdeN6G5v5w7x4tIQ7RaLVn1bltIHed0Iw0p+lKWKhMQv29+Rn471dFSX4U8Q7CwMikP0SrYk5JD
qlxe681LRIRKGIPJsUp4Wee40TXoD1c/Nichb6kDj34raSsre6xlbQiELvciORjxIAAAOrpJREFU
OBSDHeVOUcLcLObWzjGroe7OPnbOQCQa086kNFhXLQCg+fHBWlscgnAiDtn02G9aRdZhV7rgyxP6
M8GJJRIIaywUB+msYdHsEZD1Qu7Zd/2DfktlVkjRjUsIDruKYn2pXyWEJ2R8UdKYS39OQC4soaQy
qs4v4+dzDyt8aK7LIE+p1J67Vt9Awi7pvupRP9WM36+tz9VuWV0OoWssfj9VXdlzfm0ktZcgr/78
fujaL1sOJ91T0uPL1OcpD5DXL+MKfn98CLXXgBReXA3ab+84Zb9w668T6Q/wIjAPclIocP6vJxYH
JkYuBdnkOXYJhETr1O0cuSN7Duc5d63aRpZvJ565XHGkOS3ssvaqszzjRZDqkJNg7UG9Sjl8YXkb
N7AWv73rPJqcUTaFiTAGq8hdcvlOcNoopxC1tgLxAFm+rknEA+8G2UnYVsg88E8VCHDyUP8gFjli
fEjm4SaML5twyFtA0sg0Vv0JPmxUozs4qRAkD9ZWFMG6WFZeXZ7QXT6w3KmFut0JhlJe8haV5Cxi
jzmWGA+CAdT46YvsUCQbcfYjJfj6JfVdWpnlt7gun+QQC7FMVmdR0V0FzeokRL9lC+LUa8UKWs+/
frGlwqv9SX38r6qd4dTA4LAUjxCLXFbeLnnz5ZKVi5sOubCBU2h2iBVKx/OoDK454cpGsTpCtHY9
uGw1qPcprUndx0+uDdrj/8xkl628hHaH2GVbh0q+AlyMBNpfigeirbvj5pMvjNZYAA/G3mLgWelY
7BFcCqquK/3z+3Wtv9W+j6BVt//bR6K6p+utf8rnp1crU57Pz7/126/7Uvf1LvTq/Xb8fJXKbb2n
334f/PK6Vyn5ZdWe/iqV9evyy/tl/N/l3357W8uU53mLXmsNVIOYRDz+ZN/z9mt3eMRjbS3piAc8
Uew3RmxvwyMO1ONYhS+sbuda6yWPML3GZldbHHREPJSoES0qHLlm65GB4OByBYeopSdrxPtoiJ+i
TNJ+47lf54TSgPxkAiSoXV8eh4sP2PDS2+zMwi2cTurs9MyP2sD8R3GVMsqaTtq22iftnV2f51rE
RojUfV3jD+/kkcGdyPDs50D2E4wVdmmJMChO+SryhzWE4WG5HsFo0CeiIpJh5CNuYkrzSsSFVBVF
GwsZiWQg0RD4DsTvTXiFusXbLoS0re69KA60oXCEKx0RUwhUFYQnHu6mTBPsuiqriuxA/nELhNkz
UJQV+0LqWfpGO07WsnkSazlenCoBDYwpQhIScgQByppbNhXurW+pYXMTWx5e4U9HpCBe2RXa4DSR
Irb49HinLc5vB7BQ4Ep93FK3WH0xAkxdeFl65UyGMJpAePUtFGosx+lJVuCCSySWtlvf22/VybMO
WUjWoRmpU0xmWUxaGiPf4AUdhyMODqUZu9Gi6ue9ZdMcolVeWEeD4H96GaEcXkBzhOLUb0U1lG2N
Hl8LWG104g12xfiu5D1dca8FrMsBzG9T31eT/PIqeyXtXU0blytT3ofL5X2DPhfopL6gELQvMdf/
eN8L9nMH/53B7XTIPICrdcfrBGm+MPEB+9qFX3IjSbG+5NXfT6s4TpVnXKWJdB8OALeB1CftAzs+
ac1VhyEOk3ao5Uk3zUDLrCnvhF8XTdu/2n2Gk4nHs5cnC6Vt1bO4RFmwLr670Mx6ZmKbnZzd5p55
/dF5KcZvr81R1PuF78q6VMp7tV8+8Ri2kbkvgGOk/SUnpGqBNkHqiUi3tdY+wE+dwDQmn1EEVEUY
yKbTQtgJ1psoh3nByrPILUa4DjtWlVP7dScu1Us58LWE7xncuONhttSe/BsuoIG14lSHVyFk8UgL
diQi2P6I1ZjHVvMWBI/Kkt+zsltc6u178Fv/4Vx26B44sJDCGG+xCvsG+Gi6V3rBXF2zpB1+kBcX
jUtmEXHRAFNLGHQNtVl9a3+lsVzcNv0KE/lv+HyrZTJdUFcAzAQ+c3SHNbXNWVvfMBbVCIay83bg
rqN4F0Z1DeQfkvt2xqUTgkL3xkOLtsA8PP9czKr386p5fFHSu8VYNM/8dew+EVneQXqZmwxG792d
nKhXWmX5SSbGDi/PRXV9D244B4e06zSkNN+0tZDAXP5KNJf47fJw7WtROdaQ8mnsks3w3096FhTV
5r7z5ssDn/fvl9tUN/mV3D3BXm5jSm35fXHtqD+kTXXolorTF9eG2y2wh9VaK532XX7lKeujK0P/
lEcbTj1242DRug2oxl3Kvwk+l4AHudeTy++353/TLx8G6xnLL8gn2Y+zNWHOOLjR/quWKS//BrkW
yPwogoex6frjG0U8PuEOj0XYT8GAp06fgYsRR0C+s/5FYnu84nrfV7Ik994Gbvk5YSjJ5uPcwnab
SHXbh3b8Na7a9+PC5GVejyagACxlFza1bPqGV/Y7bSpLHFXRUoINA2FoTLzo33DfH9j516gF64WS
AnN8qPceUtetWRdQan0a6NZrSOXE40sl4qFgAJqkXpL/qtX8tK0uo3DDmHIiCgjORY6VdDrJ5+mf
Ig9y0tCJYi71EsQER6ScPhyryReIu4WL8XIEVzpYpOczqssnBoxZ8pcCsmUhd+cmpWjzGdSdpQgi
Xv56Ekz0p+R/e7/Kc3l39Kn3sTX5i4D7iki4MMOREMpYR1hZz5MdaphzsWtiB+KaVj9LbcqBYgjC
1drd7/7WICgBF6Njayc3/xYRitSu2cw53I33t9jOWwAgp6ad+4eoOm35FCyxKizsozNolKHNoXdE
GZ0MlGSzUSO/W0BpGZ7r6DNVFuuQIVsFAOmW3ok/nym7NI2BYEbEbwmhfBb41OE+BS2l2mVcs0OI
5F5lywtRu9/VRL+FNMPnoJx0p9DJvhGhdginh8EJnAd24RsHQXYQtx/hsyzCWhBzMycoYCWbieA0
g0YuUGyHVyr5QOm9haYh/NhjOEE3BnnSZpHfK8EoPAlvlXKy2XDOEBG8hwdghVK80IMAFflQ8Dxt
YZdRwPrb78saQuhCqzdl5ZVXfrWKHaX+iRBQZx7r7zUJ9XkWglVZREsroPqpz61TFde70prlz5VH
fhFSXbCcpdUlB4xhPPOuoV3mZEOAJnwBNiQEoNDJ2JHBBHG8GO6X1hdjbAYYWnN+AgZ65qIy+veZ
v8U2YCRFAv+en1/feg/UH5zCRYxUj1FfDU/j3wjcodjv3+tpUt7VV7vW65c79jAU+BhH8b+6+Wn7
yZv+g0N/a2vSttqQLYylduDnipgtMRQeSGfm77OnRu+wj+37XaaUzi8ee1x8+AiGv/e2Pw57ay+g
ImaPbM9IYnX5ScL3+WyTK1ekLeULBFKws9qRi8zR9qodnr4DAtNs7XhIuLP9C9ifgL9cUm713pse
7oIPd/rRfLkWiXGscAoYX3gYHML8ANE7OQUtK4VA7k4OwakARAXrqtMaag/a9PLTbEohuv5JBCQj
dyPyeeW5KmEqI+CW+3av9944dB0KOjU3rigjg0PgFeSeCJH+4tHtzqOvCM9S5iw4qfR+fGRIiY0k
eGprsJEqE5CN51yVoEffHGLVogN79O4d5MJbDH6412Q9BitJbveTF/pS3tCmKq/kh5pVBfQwLArp
2tcAuH2FFQueLpbJY7goH+62nbe9RFl4rlUIlARr6sni6lkRFkP4oRJhcMQK1V0/OcMkXrbYZ3MX
qqytN3cZA8ISxNg2VyURxkVxB1LD8ZkqpZHlxRkB2QE6te8P02/vu/pN49rx52rDNv4zra4/Tc/M
YgCYs4Vbk/iLqrE61HmTJ1Ysszdh0x9utwgaTg3Pzztr9Ll3NthKOwuV7WHty7hoGUE+JetvTmHj
72m28e24XMdjbk0qaz0vz1r9YdwpEB9k9n0YirXErfkYxly4+sj0xm32B1HTBh6tj0zZCr/nP1jn
2mr+9qwt0pdF+hLFqLD5iVk3LSY+0Gw5IiTW0W7N+ZTlqHf8I6023V7t/E7Jgr3zzLy1Pjpnme0x
m3tfmzu1iFhq+mgeySljDerLdU8t2OLBGhs92GjzMlIkT9NMyjqfmrHYVNbyDdgT/VSHy1+Hh135
s0phxT71Iw3OBUv9t3GCifaVqxh4SgNt7OPtOBTQS/baWuN+Ek23mrOo/5a0t9xDl4E8tCm14skf
brFxDDgVtKtxPmNdz89Y9SD2NG8CIiK4+sTjFeLFfObWb9pHd//R+jCRpKI51UisDmKmsAndVtPP
e2DdIbcIBDBGxbNEDxs5HT7FCljFxfpoqhU/WKcBLYQdpFoX804V1ZEx8nirh9XEvzU7t9Tr2tpd
exJCQgAlJlQ1+GMq04h9EciS4HL1EQxEMWzdXuedRNYgOmJRsTVxZTc+NBrOIm6Tt3H3aq9EBJdT
ZyAeX2aeaOGJQIJ3nFquCCWbEYTgbnYKeZeOwGvwuvVMY3WEFDlHFq0tt9vjs+AIi9huyuPNNy4o
T92cSiLEOs9k+8FvDe52ASv3MG0WYJ3JM69zLEu5tAJSUYtXhwdX77d7Ga6s96Fd9kaqTEDcCvMz
lX5ofXApo+giarCygctm2H0V8QCJNbWETbJ7EIIMwkIMSjPLyQL8erZ8l7ehPoJgi876fEs+fip4
VHpJQjAJqaHEW9+1e1L5Q6FoV+G7jY/1uP4olrs8CM9ONHESUKhc1DZxjyJgibiIXRYi5rmSIyjs
CgWywZMYLyK7ckTePb3Mh9hnCM9liV7gGCzHi64dYOO02DhJShgv4cyVEkS16BAfcLrifrxaNwV3
3pFYJU8dbLMxkP3HBtLWdDZr5/c32SM3t9gHUZVu/Ny8Tb6vxT79tl67c3De7n50lskXsJO3ttqT
ODCEb2AfCodtz8lhpxI88q4W+/rbuywBW6pmNW/nEjXW35W0+zPnLf5S2o7f3GrPE/Dp4/NYr396
0VZuidqX7ui0egDxUVSB53F//vd3ddsBYnY8+PCMjffV2ZfubLdOjBF/ED9ZtedW7Ch1HMXH1o/O
FSz55JIN/Q/t9tDbOq2ZvtRgy3EBVyyne5L2AAz1MLYkXznYzuETbRXG7DwLg7BnAOaHigQVO5my
Z9/Xa+eJ19EJscsxuZ8mJsoP1Mbt5r/pd6q/T9/ebudxEvl+XLPs/9I5W3l/tX323l57kMiETUQq
zBEbRScImRYUCHn71O0dNoQn4SSELEs7GU5j+25I211EQKy7gBfV8pMIaykwW7TBf9ppX7mtzTpA
vlEIzjGMGfc3JojqeAH3K7KNUedf7YV+756pW3LHHmANiXh8+hafeMSYHiAxrMtroqc13WFHYbcF
AQliW+WS4zPiBaLqvHUnnwCdaWISuhjniI3ROlc+jL2HkJu3GrV7Zk9Ne14S4iwQy2OM+jnqkZJO
PVf1mO1MYo2u3Qkrua/ucf7cbeoS4MX6KhI7fZdNZKptX/2R0kM9w5ZJjmIp6tXkPbryT7UpxC/j
v7Ml4sE8gf0UROvJeb/VczcumtHOS4hQJw3+JJuYWn7M1aEdp54L8Uv118tLr/xTiesUZV1PdR/c
jMZTVvYMnHSc5pXrDt58HQFSVlmkj/DXzw+E2+7UwSV90EkjDusrg3NGT54iGAtXebIk5VKqTEA2
QWvTD8fnl0dV7dQXZpDoMyMUP9wzqg7Y8jSR7Y6ErKqL1yLT5fKkn4IPfRUrDgG/5oRTJBCBdNH2
9LbKE2Xy6I7LF5bTYhKMvoMkeUSiDwvyk1Fbob3qBo6OII+GVjQRmDxxTkwLky3UGLC6NsLPyuKc
sQEpboH4IynkIHV27pVuizTT+JbuVeqKy8LkLhBFcTWFZkPSlxXxMqlCruHnj3MSmmGp0JfLRiT0
G1G3oG2JPeiWIdt5zUREHYXtJHckvSOcMrYlLUNQKKneKoZ5Qw616WaE/yy8FY78YYhBC67Q4+ex
aX07pwIQ5G7idCi0bQaLMC1F+ZaaJwLfLAj8fQpJ+9/H7NjP7bBvE0Xw4M5a6/rWCoGr8GlGXW7s
7R66aAfpx0uUVDKALp7Lo67mRxii0Avx0Ilh4uYGqz267Oro4rlikxe6w9aPF14Rj0PPTFgnp5gL
P9RpDx1qsyEMEG/6ywv24c9fwCIcovf2dlvA3crBx8asCuNFGRlO3tFgo/VxFwPklv82aJmOmD31
/m3Wv6PWdvXguA43Jkna6eZUME5kxZ37OKWob/Qxyne5HYlbv6yJGk5luxCI3f7QkHtPp9/RbieJ
2Ljjlgarf2mJU4h21Jpj/IdllmmN2hAEj+lodz5BpMQzK/bsj++wo/js2ruryuLPIexsRKgKbN5o
SUuyivm+gI+8YRDWZ2/9uv3I7j/mLvI/qdMWW2wq1eUIiMLRenILw17jLoTgChQVso6q03Zqfjcn
jGbkF8fcELPs/qVKusippTGOISp3ZbCcLVTbUKodwnCOO5o/vAtSDFfvak9JqqdhEVxS2BEPXfGu
QHmSRQY5+ZSzv+pjQ2h0le2uS8RJBE/pO4e6StA3Ng/eyeMhflM/OEWjUIhZERCfiGiSRHDFjkku
fcfjATYfEcLNKmWxBhehkxNF1ekRHxCBIx6CPqUIPSs3JY6wSDtLBIcn3ulF34KR1/am0ayrBpPb
yUIEA2Ym/XFW6KrLlfMh4MGUmy5VJiDKu56v9KPsnmCgE0YuG7N0qsHad8LDVJ/hN972wIDdcAg+
Nrs94QPJEbzKVIGXtLPPMf5oFffYSchVyiquUs4810qdor5+Tr7J4mDOVBLC9K7Lnl/mUsi5qr1g
576KX61/eZtVNx220XMYDW47g0yiz86f2mu79j6KsF7uWppttL/HOnqPWayaAWGAhEQTFy3NNokN
SEhIW8fPK01uyHxQTW613mmtJeqnrR73Kff/5gBGi3qhLtOV1Ujbcp1/4XibTZzEI7AMGgXeq000
zdq1ADIKxeqYYdedJRiUovgt45xIezn5sVo9EHVxQOIgryj+rVCTt1w7YWtBxDuIsFct1gshZdOd
UUseZwFTr6IXZuAfxIdz1kV8j92tVS6aXxFnigJhmoUVwuI8Mr6KvAEPy9xbHwrXOD5w+VSX8ufI
HwUhjHXVWHdPjB06E7y0Iy/CvlL43WoIUydW6TUvZqzjtkXbcwMxTcin+dQK6ykPvM8S2ClPXQ2D
K1Z/nF0tm77ht7e4eCVtWMvXHSWgGJb0jffgT4mwtyutMUucg41FWxFsiAY5ERy4t9bFOmclr/dx
6yvQYVpvt/kCLINHVm2ZwFrPtdc4X2PlJ3ONTTKfbA8RNCHarbh+b3pl0RKn0tZ5PycVfHYFxPLS
5pS8b7SkdybXJEfRLOxD8+nrt37RHuj9W+6ilgoiFAKNhYets3YYxE/gttCGP7c4WpF5EFQ1c3ox
22cHmx9zw0vlbrTzcwcxpnuGU8kcJxFvp+kj/DDOVVvRpNLK0b2x1I3UXcQ9yUl3bzl7kx2ZvMXu
6vxbWDgeq4g35erWLJOdSZbYOhk8dSf///bOPDbys7zjj+cej+9jfe3h3eyRbM4l5FpALaWnBEil
qgCpRVVVqSAkRCu1aqWWioqqov+WVvxHCy1/UEFLq9JwKBBCspRsNsnm2PvyHt71bY/t8Rwe9/N9
3vnZ42M33mRBKPUre+Y37++939/ved7nTirUq6gh3DP5+uojKkv7b2rNVV+7z2Eq/5qN5Z+iIb1N
As68s6yLgLMQQb1NhoC84nYojrlYWyWE6WL5KIpgU3rQQ9AugaArrmKrtsIKqE1ZsnuiDSEi3i7q
4z1BV7TVmNph86WrlNNhVmA/mmP0zehAavKjFYT6INtlpBOa3uhzYwSyUcm6vBi8xEVYP727LiI/
gBcp9hspmSJU6ye+FK1dyNTnyhg1H6gXDm/AmSzHLUd6UCST12L2D+c+bTeG2h2hLFembhxW0CQy
CLHMegavgKw2v6tCYnLlPnIuZ+NjA9a75xiCeEKZ0kRrx2W79xAuFMDcacjaa6cH7cKJHcTseDGM
WW83+3TpNOrDZ5gfYgL26g2Tj466MrZsbEZdkWdphngmWodsK55F7zluew4GXu6qxrROt5iaI1AO
dd/8p0/a177WBIBB4Ira8FtJYovEEQi34jm3jOltCYpjFiQyx2msjZP3LFTGwt6MFQBuTbykuRFO
lCCBfBd5lG+9MmfF7rSd6AE4DsCfewU37uewah9osVN7QZqf2WcHnhq2D/zPcTe2KxPGVnvSioB7
dD+npj+V11+oF8Zxq9O1gP42/GuNEOtj+kCTA/kKJ3a5VSlANQGqrIlrRS1c3BG39qcm7f3fB/Ag
k5GPqwrzWQTRaUuVJOBfRGAeg3W0qPpQF2moiSpGgxJgK3StHrNFrl0LiuvMLC8vlNU1EFO/YqHT
n7Zso6RudK8COyuOv64c1IpASoF+yshUXENNFZmX5FCScShmithvfijABcq9Xx+ye1WEY/BiNxQL
5X6ekl6FVpDHS9hWHcrO2Jee+BeQgE7arcwdpRRnTYUFnyn129X5Fru//QwKFaIEiBbYGCiNxWoL
thx7oQDC7DKJc7a3A5972Gb4C+jZ0Ysn1hUAB5lJGX9V8+VOhO877fFe9YtPMhBDHhbNo30/BHko
B6CsL/+UrCO0U6w2wrJqpM8gRB8t7PZS3dkLPjapIQpG7MhykOSh8aa8xBt9qA8hLSKXzvwY54bP
0rXY7xpF/RxwOprshH00wmOk0zcsK+wzOEpxnYSiCPHORTGJSgkCbgnShYjWjiY8Fz5PkFIGi/R5
BZXyduXAlYNQcQhkBdDVpBjdStKYlIeBdBwNMAnRod4kM4nhuqTMmNb3t1J7YwTiI4kK8YP+JNcQ
4J9lvafGd9m2gRsgD9gK8FRA8jz0kFYIo0WVzE03Wls3lpDkLcDCyaKFtLx2HDUVoErIQ8dOdyjI
CcAa4KXX0qrulUdGCXfnkyNJ69kVldr8t17ILAji/PGsHXwQkjZFHGvYS3HGPz0B0nj9fnvnLx2z
/t2vW/+u152x55SbyB36Hr662/Jn8Q+1HWAD5bS5FLSs5JJBkKhj2/lQjTVUs1qbZVf0PKyidPy5
ENUjCKtFqN9n1UZf3Oq0WEKDb/FTXUEZZ0ewBsabrpDCFD6gGkAWreMAbITdJdg4RZ3wAWQtBJxa
3E6MDCiKRk73fSenbaqp3cYArAsgEgHlvmfH7YmmhB19aJu9BsN5jJP8A7CWBp4Z43DAy8VDrBjl
R3e12+RuHLcxUR4vp2J93mumpKWQc8Seq7NWor0r/KdxmJjW+uiFUAGSqJj49KJd/r0BG+bkLmF4
M7HNB79xDcEsDDatay05h0LvjoA3gDtKjiz4IUSjZqPfcgopNu3glVm7QcjfFgTc8ggcXsio9upv
H5aKEMkwhVxAvct/WBXqXC7eI2TmtVSOC81BF0IavFzL/XuZn6MPzaWdRTzGe/QLuSn7x8e/Skzy
J3l0YQc3sM/MVkgiAtjdmWuc9hVf21fFZxIE43zGZmxn8zHPG559HARBXJ7c87jT2Il1+hD5qhPa
07d+pZGLppCjzOCfLw0bbL74HpzAn4HCqVhvdpg22FcWuAiVociDalPtFCo9WJ/fwDp9gjgij1gu
1m39Tc9DBUHi1TZbYxc7Vv00E2hOaWXU/vMmHwF5iH02PnPEpueO8I7r6VYboZ1QkVUBbsrzroTY
0fxW5BlwdwS4AUJJwtdKeC5qRBRCYHmt7V4jFsUg6irpspMkGleqpxTa4mEH8LjmlwO3MB6xxdwL
L+NJQemIhVYoD9EWslu3R1jb1+rfK29OfX79XJXP6kFV+QvUxCk85qpEvAwAxsKcMIGuOeEJ+JHE
5nFWD5uYyszb7HiX+5cqzqG2preG9mVZXuVt8fXjd9277W0sf2jn6Ke9+zLhaaE+9NKv2ozlkje/
oP1EB36xTvawKEBLTjCVMlb1HGRefv5RKJNdUEJE1CtxitY/7lIcd8A7rYD7rl1oxZ6Euemlvo2k
WPLhyePBYh7azzLyHEVz1Nw1DY/xAQmfx0PvCB6HwwRZF5/n6s6itVqd+xZ/MSdpBcUJv9pDsKVZ
BOmju4lXgkv2NuQiceQG+c6MzeNnonkG1UJ51O1N2iThZ3MgmRIxMooslpDLFHKERdYpjuB67+cu
23u/dcl2X0eNEu+5T/3idrtxuANVe50I4ZcDtB89Pmof+coZO/zMsIfP9bXaaInJA986QOhiTDfQ
UirgNMkBONPXaxuqhdP8dC5tP2rP2fN9uGxH7qC11GO0qbRR/1QU+IFosYFrefcaPNyJRh4OJF2w
rZu3Suy7h8KljHx3OXII27+uliM25XLfVZGvIyuSf7FoAtH3upo/uwwtkSiPYzzHH2y9Yf/8ni/U
kEcnzznUve+GAHD0EIdBK7Kg2EdKuhdkF6sXvBtZiJDHldlDdnp6wMuGyYf21Lb2O+Uu3RPWlQEu
oJDwzNUHaZt9wlO3kMdCpdu+fvH9ePXdwXMTNuhGYSfRCDtpE6RF2XY4G9fm+rwP2Ygp3noQ0mtM
YVybf+X1jkMtwHIamfoe1tsR8tAaRHPUOKJr4B9AOzxZ5PkYo7K1MkIGsJxKlVHkIe0gyi7K16eo
PKtSQwpy9y6vvs2Zu0AGgreioOiXsbXgXyuLW/cAYxSlsIn3W9RRaEduUOQzS9RItYr1OhpbKxQg
lxskXokN0kYPqeakfP77d5+z4UsYpxAasqkDUp7MZAayB02jOJjcBdSSffCyyNYhm5OQfcE1nxSM
iqMgA0fHnf9oQSMQQMa6JKFXIokvfACyWEGR2vC6gjfJENKSPcjw+TYE/9u9VCqNSi0H+v33niBG
+QWnosRojsFfXZgHwMPTRUJrUxPE2T5KiNQDzCU8+zfpZW22tLDQrZ5CrgDSmJ3pRfayGyQVs4nr
YHqXDemhW8SYEaALNZTNgaX92eHlQi7k4xCicaiistroO5u0pRICS121vUQIWiiQaQTiEnR3wJ5K
s4fD7QS9AuC3j0NtwvJRiNqCBI5gxe8SbOn4jhbr5IQ9ioBZrJkrv9VnT3/lAcuVyvb4F8/YXtg9
YhldhqW1iLxCMs08dTsm5q33G+PWcQl2B/3UXpsNJ6ioHZJB7Dw/DRsIJYROAAV19DyqTz3IeoYq
uKU58G9D9uH/vWo6PGYUR/1WiYoR60zNSatTSUBegKpe80lu2VtRxe3Kl2wEKkR9+4b5t65XJ58P
7cuJoig7/c7SSRIk6kQnQ1umiuraUJ4ULc5+ZIcd+et7Lf8wbj+wCRE71ZHP6m5+5r+EPF7Eq8In
B07bF9/997j/wNXFEu8lPqVC0mQ4JJR2AFAlSNfMwwRlq1FaRGkB/1VlnQq4N7ZAJM5y4EAkYpy8
SdubXrRDXUf8OnzEQQrAHJwkBlih9vRCxin7E/vA3i+ATK5bZ+YGVEePjRR6bU/TjD3Y8SqAkl5Y
8FjDjPVkx6FC0LhD5fdg51P2zp7/RFOpGZcndzEetS2YtJLqtmUlc91VQB7yP3V94ttYgr/KWrQx
s/pnj2cUVpbYW2E91IjmL2UKAvRhVS5/VDrtiOUUB7irnCgLfZdBIvPFIa5XkqIPBiv1lfV1Vlh1
ykZnvgXiue7seVEucVhIVTS4iuUxGlD5oKAgBKV+RelILjMF1aS9SsAGiyE7CciFr5skzWBziZV0
AzrWRH6wUnhXzU8jdAHmVXE/sIRtiP7FLazCm5SrdC2OHAlOjD3gD1jvrmsAfxZFZZHeRv+aj671
Xb9hUZ7rarPIOSzFZYSn/kKd+tK3mAZjVizx/IUY1IRIbPXHPyeo7buP2T6MneTZNwElINXbEGtE
7CIZEB60q08i/Mvx0jt/4Rb9aDg+F30zP5BlY/M8yI9oeblJ3N3jKgDhfNcAmii1+WsjiwtEIkxN
WHMnvvdRQxSSLSlcMN6NvR2tp8qzbmrf/28xjNu6RXtym54arRDOtmR5Yl/kRW3As+8+O2tpePIT
UBuK6d06DdI9A9tgeyO69Hg4HSvYe9G0evT1MY9cOEMsENl5TKMO+5PeZlfHbSY4Vd8J7G5gJ5WJ
xyHDvAhoVgHIlVZObTrar0lrd1bIQurGrWgj9SELyTcRZEdAnoJZ1IGzyD7mQUqzjCF3ZI4w8lUr
0Kzur02Oj5WptUSvNwmrrgV23Aysthjx3eVRuMQ6JOlTWl56DoT0pI7beH3B+glNO8eYJZR3nL5+
+N6l+kmOQ6VwxppgTbKMN4m3Ps1FFIn0gCoANiHw2Pyia53NsUbu5Xe4ald7cvZcNzYhIGu31+FZ
4YhzR7ffB3obHx7Lg/fm431n7G8e+zPry73CSRq5ZUMA/EK6Wli5Wj8zrdM/6paeExZpstgJcAdh
FHsAagHAFtGqKi4K0YRUrnZgcX5/rSUBXJWr2NGxffbq1G4vFPpRX8gBURN+dfI+K9DG0ZEn7Onh
e0Eqr+Pi5OlaWfqGSu7OTNoYVMjEQi+sqVEQiU7bij+Ss5PIUQq4jg9JY1Xbm0kR8pi24cnvWKF4
grVoYQXqEZEeNMwFUr3ckwwj/BZlILlDAiogGBECM6FgxIbSfyjHYRIAnwLAh3XgSwlZRdrdjvRT
TIi0frwcCNN7gWcE5UrvJKjWIPtAsLcFAuMROCogLmhAbEgkYJexodhYQjKyXBXrSxbuuudGXepv
Vfue4R+189ZKhl/V5hdy9YMF5eFXTAsxq2McxfvuPhfm5+sEFqlL9VNRvxlC3ybTCGdYkwYGWp8a
RF6Rn0K9LwFTW2w3yVR4vwC8TBak7H5s+C0S1ddeQ6KOXK5vJglZyKBw4lTCblzfY/dnjghsazAr
yyIZRK39dCukpetko6Fztg0dAXmq1BxV4ObJKUXG7s4U0UgR21WkckiVcK2xrHq40DXvxvJUc+K/
AU/AAkri5Wrunl9roQHy1NdDz1kt7459cUrOEL9jcVerUxuNBIdKXoYqmijaBOq9ElI3I2hXzzOc
vhVk6fDFGdvzd7iDeSxtQ8glhjHCm9rXZNkxnLTtwv7j7g4rfQqjwoPtNg2wbRsvWJzTtxCWHim1
1QDA9mXX5tZNyk/+vuEUU3GuZVwnFeL+SzM21EXsZ/JULiZbEJDAMOM6964em+5vtFPv6LZmIZio
DXWn5HX49k7pEoSWQ/6TAYFcGUSN9mP9VkSaO4KSQA6ZUMsVDP9AXGG8vAaw6HqID9K6v4P5skG1
dpa/1Qd5en4LINlTH9xuxd9J2nnsYFpBRq2nwCY8d/P9GXvh13ZYF7KUe746ZI2XFqwTFuIryG7O
oWqcu2fBZmD9HSCYVuYiXhNQ+z39oe02BptQqsFycR/ivavDn0LSXmhuy0lOEeVRN2mf3n7S/uqR
v8W6WzJQDEDdBUgoGKgDbBx4fx7qes6NAsUWik72rRyUWtNj5J/Ci+79NjSzB4vwb3rlKsh0stSM
1pVYVAGmqF51aZvNFvfaAx2vIBjnpSIF9pgGCEXLu9mblXZXBlnKsD2YPuuw4lL+IKwfDEIbL/Jo
aUJx5B0/UfVakuEe7PH0dXuiB9fp1d32gysfhir5d2QvoZ+o5Mbf1IY1VCpP2A0CQYVYHqI81tbl
0ES5ueI5mglj9ocdpBap8S5x+k+AJHKNhyxfOE4xgWaoJoC7hi4EsLIhHHqSA1AYOogCLLxs9PKo
fShxqfSCePXtgnq0q+K4PpH7k4XSFeoIyCK4R114JakuO0hf+cKrXGashfEUSsO4VBnhntSIV6eN
EUhdmdrrjYFY0i6fG2BKxDWokZ6rAPByHW0VpyROzWIHqX4Sb5hjV1tZBE4qy+XChdhLcvMxMdKO
ZhYPgw4cFKqUUQ29MohmwhisnC7akmYAAFRt86AlCEc5dhU9adZNL+sbJoBJAl7p0NkuGzutDemn
iviwLDNu3uVYMXooNWaxmCrlir12pNsa96F6t/aZWNOh9jGOJ96FPLYCQzKuRIuCPjczNG29+pbV
ewXvo6JGAsTidFVp8Z4SWO8qTnomM2T5cV4wctXnnUjOPqoB0jQnZLFq0sOwqxh/G0LzC1h3t2EF
niEg0sI7sRJHEJ6D/98CJVA9gGsPTtBt1+bt5J6U5Qey1vfMqB0k4t8J6r32y5ywwOAPIXzeScAp
HXKWoA6ME7cproemB3XSgFCcBQj7yW+OkyjakKfDIxpRuh+DHbXUHbNtx6es4652y0vNhqYkK7ib
AFKinF7EQHF2sM0eGpmzPgToVYTk2mOtsZK3KV8/6lN7j/ynC2v7Q4MT9vw9nTb07n7fsw7mdx9B
otLDqPD24zpH4yNJQ0uW79svzNgpIhq65z8OM96BOtGG8y2KosKavrQbth0AUev1yNkp6z6BvyKQ
kJDoqSaMU6X5xQOchuLbfXzcxnIp+/F+NGD2Q1kx38OnJqwR48kKWlp5NOFU5xAILchRap3R5R1P
ax5cuWN/GRX7z+45bn906C84wesdIuRxgwCQTgMCLno/BVJK9tLor9ur0732m4P/TdCoUZYkuGJP
8B6HRYIjgPZWV+MlfmvJJOCFUseWIwsbPIebdY6sLCfGc7Ckvn/lkL1v8DnuURZqPLBzteA8F5y4
ujKhnUx20tuTwloC9d9OHVxJ2muVDWNVf2H/Q75K8P423LAn+o5weCPaqXsL9q0MN9d9Uh8ArJgd
w5NPMka5hZc79vCcLD8IeiBApmmM8poygzZTOAOiucrtAIyD7IIyvBgxDAzLUtH1pDUlnyS7kKoo
B6dKeC+gSJoye6AoLsLaoi1nNWl+/PspVh54OaiornE4VT3GKimS7EtoIJT19tWPUpQXfoW+4MAs
nKN/9mwVkqqViWqlGUCR0+3v3v9J62nGlzzSZelv1ydpNMQWWAj49Ok2Bnoz4EU1AbYqivxxV5Ph
GuTpCG/NGJfb58GRfGMex4MBObEmAPBGLMQlV1mYArHABkrVG89RR4L7uTxk1qaT2CcYqKnd6HTP
mBQsS+1zIPA98OZq85jFaaQQ1mZSQIah/eU92kxFlaE/rVNxGiPMLoCKYKfC+c4Io0L4tSiPcer0
Opd1ucqye3gv8RY/tKUgggInY7F9JBNJYZ9Rak+iXYUqIEGYssNQbQyn0INwjtO1NLcSc7D2mGyR
cqUO1A9BQI3nQTTUKexHl503PqW803OWIkiVAPYCthWVHGTyCD4CplCN5Vpt0q3lLnPaRvVVZWQn
kiXqYAkDuiIBJJKMJzMWTqbzA5DdAPP0aNFSQkYYtxZwgVIYxE0DVEbTWQAH26ZgVwpZ643TgfpZ
JE9zkbDfERTQRpb1c7gzKaLSK0PGNGPLYaEuv3TqR/0pNeKupQHAXqbcAm3JvUqGttxZowroHQbA
i8IQ9ROx6yQIb8QFihxuar00rgJzjIEcM9jC6NlrmIMNtydrxe1ovsG2amRuudeIYS1gzdjVn8aS
YWxx9sPhtvp8E0nAZBFg89zQU3Z0/BmQMxpHH/qQdX3ko0Beh9LeKtNxbasXCCX9+f0v2qcOfQbK
j/G4U0QBZyEMnY6VYLXyKbfr0wsP4/BwB4jygt3XfhGKAkDmm6ASWqYVDa154p9nE1PcxUAZwL0I
gkjGopOxnv8AlOfKd1EO7c+aM8ZKtRP2E0Gh0i97m+emDyEEnrXtuTNocO2irYKr6V7K3+PykVwS
lzP0EiGN6HoWVeAbMkxsfQ2Pv2hp0WULYSMwMbZTIx+3u7/3fnsoC9tUL4YnIQ/2n5P5tclv8V4y
dveoGyEPPQQCelobwQ4hOZzPpjUm+bC65mNbt4F+SpV8mDVAXqF6ko8I4AdE453zEdpvqCGOyFhQ
Y4rzgFWQgahtGSIK2cgQMYYHXiG8RQ7kCReks2tOfWh82hP961osM55r2F9FKJVEostXrCxXJ2ne
ATxR2OeO8LCwSHlYcNRYn6J1qrsjwLWUTaF3jZ3AsDbhFkk3Ke9P/S2KrboFkzkhH1S1hqXRNTUO
RufNiQPcxVGqEm896tenSx3FPt98oh0WcRrB9ioEKAa3Hg41Wp/I8ljo9Xm3uBZAr6DWODlC+2vb
ukU93VJxAREhjXmtr4ZDpn4r5WdX8hLMeVkF2O/egQ/6i0ERyO+VXjDZJYg3L6Cv0LECiu5+g8NI
M3HKdQIWMohYRFkQjk7KqrOI3UV6BvbXdyGx2T/Nq9pBWU7eYs/lcJci62uvT/kEp/sW+lUSiyhJ
BMH0CNSr+mQc6VHaIkqg2E3Vmryk6RxjANBrTA68MX4UcM/hW8vfcxwhhgZpkzKeWMoc7CDBI0U6
9HMBeepHj0DbjzBO02FLu0FgrEXckziHAASjdVHSmMWXSTE/AX4fkyAqVTyxjpJXiMUUCeLVns9F
0Q9rj6uQYwtlgJXLfq7kTyt3oWBNL5Ev5MMhR9Eh9RzQbFg3xu62Ktz/aSdNSQLzF2Bb/UH/WfvD
+z9bQx6K5YE1PeBDyEKGfyfGiSne+6/UEMDHPijzgj3E/7HRw5Yv9SHcluGfkEYEZMP4WSoMAWV9
jsYfxnzX5vrRhipheY4ZAO2ofNTP6ak9dqAN2yqxtkkFkMR/XThsHz3wsrOHtxPnPBKnzZW6kIv0
I4g/Yf0glCC8DntbQlNrAaPGFtR/lcQuy9TcF3WkZ2hLrlIQqDNEicBWJyEP7CPQWLox/QOQhzxa
NDHGqKCQRc4a0wOw3c5TVasoufCs5Ymr0Zh5wDWqimUoDZ1O/H6tB70oIB4B/qUlcXrkO6+dm3BD
APwr5bV2IFm3VOeQh6ddJXg91pzdB5VzCgpkkjGKClH/QgopENh2K6HNtYCargTwGpfua23EKlPo
XLWivKqE25z6XWaiJhwZ6kL/K2ljBLJyf9WVkEhMAFun9zdK3ukbFQr3fciUrxdSa/OSaZFr5Edj
VsFa2qhOdO/W3wgy0zod1JW6xVjlN+t2kpBIUsZHbzYxFmmHKUVz9GvWPBpmpALshe7kBx0u6mTB
t7NI6FAIoYJqrzbBBcYqA6DTxkRlNAR54l1CLqI8lfN6fbB+uOfjFluqBjwVdra+voCljP2UHOgC
oCVcj/oUkK7U2o6eX6kL17ehtuU12KBmPDGOKPm4az+W+9Z4olS7rOD5d/m5IC/SzlKerwvlozkL
IVTamK8eztq8oua8PMoEK5PnTrR+tUKac8XnXFtX5WsOmhd7wGO0sm61Oj52GvUx1PJ+el+wL5n3
MbStPtEvgblkHlDBzraK2CzaXbGicCw5H9T5BfCvzg0CeHO2p+WkvYNYHSGtII8IMZycfNRGC332
nv5vUiTsfzLOoQNAuFjNIcQNAI2V4n6D3df5XZep1Bq05vQxDAZBYNwulA7b92/02R6cMT687duo
Ar+AQSGeAzAzuFtUW1wn+pDmK/IKHDZd4FPW8QM5IURAsKsHq1y4f4nQFdqMsMWUEPLAW+51VHXL
5cv8XsO24oQQgx2V5uQ+WzxNO4BnYpy77AHW1XwkB1mFPFhHTi4SlGdBPNO4Z/f1oC+5JpFQuwGA
v4Kk1CwKFWhmcfThhxLvEKq3c8VLXNEnyKU5ux8kkkewPwRCmUIWkqWPNupBveO40U92qkk/+g9z
5pDDWMqOsNT/CixTX3I3X/+4q9b6pLULz8aqew7Il8m4Vbfe0o+wVeubEEK56b31xTedU4+oNl3p
NgreLtK5WdP1c4+uo++b1Xmr+euAEx0uA9Ja4wEgrxnJ2nL6reMlae2jtFH9Vf1u1FY9wFeb/hSH
9r2TKK8OcUT59d8b1Yvur51nlK/vVeNTxtoxKq8urStfdy+63KiMj682h82sW9TWnfrWigokoVPh
dh6/33vOkUc7gu8gF4iQh/ZV8owYoWWP2q/uOcq1RoyfOcpiFcQ11MOyvKIe7ISZ9TfO2VVi/EjU
lcEIWQC8JzuKRtS9Nk700/2tAsArewwe8DRfwWcbBoKLAKT9rQicSfOlBpBHGc+7xMWgSooT9148
7k4UOwCiXZSYpk6a+CII8VPT9BTajb4jpKa2NI4of0HyXoYLDQmQRUYB5SHkUSyd53c98gg1JTsQ
C2mcAE9hPaA+sPcoR8+v5BHe98q8/DcIoSI5BwgoTsTByOWIKICUYp2n2kAEF2hSB6SwfjpxCLU5
NcGBLt7QDnKAUkFmkkz0QbVATcVhDUsQ7yq8l+ljHgTXyJhwIeQRDOe5RuazKAS7gowCxaE9W+lL
15LThJ0M+RsjkKgO1bfS1gpsrcDbfwUEzgQ+5BQRotNeJI7Nnw++an9y6PMghCmATAuAKghmI6AS
saROT74bu44me1fv08goCrCgAotJqxbcmehKSYBF4Dmcakuwad6388t+J9wNQHVf60lkGzJ4kyV5
KxRCAPinph6zu1pesdcnDuMK/jLeYq97Xck4+nLPQnWglwF0C4hGCjwJ4n0IkVWJdY4quswNvFVH
B7Qe+ovmIbwtmYN8Y0nuKe5Hl7Sx+ItzQl8oXreR6R8iU7hYQx6ah9qoA7yc3tOpHYwNCgQBtNyn
q8TiktZE5UKfXKxJdAYSmS68EvIdUaisBN+TUGSS42lsYmkySSiDFKq20uJKYfwn4XigUIKGVgVE
V164TpNQLi5YV9/ZGkuKcUMBOdWxzOLR3tSnIH/RSoUxa7Wk1CNZllKYRw2BhB8qLNP6YF4fim19
bq3A1gq8DVcAeOHAQWwF/nQunoTinwRxSBj+2b0v2R8//Jeos0rY2oQx3gyyDNk3NCA7CEDEARml
Fa9jF3Y5SWQYDtsoE1KAK+Ga0yvIKXQno76qTSKwlhCoK3MVBBXqqEwZ+4xJDAGz8RG7nO+13S1T
LuNoTyluecUOtr8MxTLCaViAFK5lYsxmittoZ9SlMlVsggR45b5kgZP/k0O/be/tfxlVX9lBAIQd
gfnsqY4Rr8aysNtOzHTaI10vuOGhHBriR9R2tpyhg18AsM/YOLE8JG9wmQeIQhRJDKDuqriamAN9
3I5grFcpT4E0JIgHcPsyrEUemm8Yp8bqlEc8C8WQhTUmeUdYNf/0piUPwuAQYbwoFSnsKBaIZBUL
VdmPQQ2K3QQSkm8/Yj0yS2Q57o5Ejfkg+MJgOPeY+8YqoUHmgraoE//WWJDjQKXIzkSKAuwIeeRr
uLVmvCgfjkBEsCklUPdIKPQfP6M8v7H1sbUCWyvwtlkBwQC93zFO2THpzQMFcBpgd2cX7WP3nLbf
2POaPdT+5dp8ZegWKIpSoska8Sihk+zUUpe1xS57S5mYbARWUnSyX8nRlXrtAeji/RbVXI1gH4gg
pIBcoutMcsR2tYY297adXC6zrVH9gezigfJw4Azw74LtFRKzAgEFaKb+kH2ghPLEwAyaWkEGEhkv
1iosf7Vkl+xBVIAjGiXMOWHbO75jH2/eZV+8NmvbQJwF7Cj8pA/ii8VhDZEaEMonsPZ2n1OiEADd
soMJCEUgdg3U9REGlpgwaqAc4mi1SwWZ0aclZF6po6vKEqxDVL/LcoXNlgnly21KEAqJEhKCklAe
OC+1X9m5SZvOU9QWbWMqUEIBYlG+v2BHhTFG91VYZfjH8VupAcUHxSzS8UIIUt4nIj4iRZS8h8Wa
oGRsTsFDkPijT7pWjTcU3/rcWoGtFXh7rABCV06a+YUZt71CT8cOpZ6xX4n/hzUBj08OA9DwfFAf
gnZpCZ9lqKtJCD2CGvFgk1gzAjCCJkJJOqKuTwLpCQD7y2M7UZXFIBEE4SIBASoH+PUALFwHtlJ9
ewK06kPfEsjrXrgfUIY+69vROHQfrxnxb9s4bCikC5ThYlWS/RV2ZbGLzBVEisxDbWtacWzDUAi0
8de/g/pqj5VlhCJWkie1BEuPNXQZA8DdyiAAp0LqO1g7Jt2jLPUSnPBlY7GIC5TV9dbWobynKF+/
dR3lh7shT9dRflQ+uh/uzS09ywXIz8e6cZmqIzPuRcJ1FcMdjw3XZGCy4SJFI3EeX4RI/M7Wx9YK
bK3A/5MVQHUam60ycUlCaudL8o61wLZ2+019LYMaatdfv6nGbrOSKAVRPfUIaW0TOsErrS0TgLF0
oNBb2kpaAbQi5e5HadVOJhGsSFgUuIN+f+tjawW2VuBtvAJlTtSY7/kMExhRdHYrAJQEqOuTSkWc
/ArykhTUSIRy1pdenaP2dLpPILfYqO3VpX8+fmmcQqE38C5RQstrefLR8FRAC+ATYmUkALqdJAG2
klNx4fLn+lPDFeUhTw61FC1B9Hvre2sFtlZgawW2VmBrBTa1Av8H/1JsixJlFs4AAAAASUVORK5C
YII=
--f403045d97121f346b0550d5259c--



On Mon, May 8, 2017 at 10:29 AM, B=
rian Campbell <bcampbell@pingidentity.com> wrote:
I do have one minor =
issue I'd like to raise that relates to some conversations I've bee=
n a party to recently about implementations and applications of token excha=
nge. 

I think that the current text in =C2=A72.1 for the =
"actor_token" is overly specific towards the delegation scenario.=
 I'd propose the language be generalized somewhat to allow more versati=
lity in applications/deployments of the token exchange framework. Here'=
s that text:

=C2=A0=C2=A0 actor_token
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 OPTIONAL.=C2=A0 A security token that represents the identity of the=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 acting party.=C2=A0 



<=
/div>
On Mon, May 8, 2017 at 8:01 AM, Rifaat Shekh-Yu=
sef <rifaat.ietf@gmail.com> wrote:
Hi All,

The last email f=
rom Brian addresses the multiple audiences/resources issue with an error co=
de, and we did not see any objection to this approach so far.

Authors,

Are the=
re any other open issues with this draft?
Do you believe it is re=
ady for WGLC?

Thanks,
=C2=A0Rifaat &=
 Hannes



On Fri, Mar 31, 2017 at 11:03 AM, Br=
ian Campbell <bcampbell@pingidentity.com> wrote:
As mentioned during the Ch=
icago meeting the "invalid_target" error code that was added in -=
07 was intended to=20
give the AS a standard way to reject=20
request with multiple audiences/resources that it doesn't understand or=
=20
is unwilling or unable to process based on policy or whatever criteria . It=
 was intended as a compromise, of=20
sorts, to allow for the multiple resources/audiences in the request but pro=
vide an easy out for the AS of saying it=20
can't be supported based on whatever implementation or security or poli=
cy it has.
 

On Tue, Mar 28, 2017 at 1:32 AM, N=
at Sakimura <sakimura@gmail.com> wrote:
There are cases where tokens are supposed t=
o be consumed at multiple places and the `aud` needed to capture them. That=
's why `aud` is a multi-valued field.=C2=A0
On Mon, Mar 27, 2017 at 11:35 =
AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
May I ask you to explain this reason?

Am 27.03.2017 um 08:48 schrieb Mike Jones <Michael.Jones@microsoft.com>:










For the same reason that the =E2=80=9C=
aud=E2=80=9D claim is multi-valued in JWTs, the audience needs to stay mult=
i-valued in Token Exchange.=C2=A0 Ditto for resources.
=C2=A0
=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks,
=

=C2=A0<=
u class=3D"m_4803735329627533709m_-2675142197049852080m_3983298834558915277=
m_-4354184635220679769gmail_msg">


From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of
Brian Campbell

Sent: Monday, March 27, 2017 8:45 AM<=
br class=3D"m_4803735329627533709m_-2675142197049852080m_398329883455891527=
7m_-4354184635220679769gmail_msg">
To: Torsten Lodderstedt <torsten@lodderstedt.net>

Cc: oauth <oauth@ietf.org<=
/a>>

Subject: Re: [OAUTH-WG] I-D Action: d=
raft-ietf-oauth-token-exchange-07.txt
=C2=A0






Thanks for the review and question, Tor=
sten.



The desire to support multiple audience/resource values in the reques=
t came up during a review and discussion among the authors of the document =
when preparing the -03 draft. As I recall, it was said that both
 Salesforce and Microsoft had use-cases for it. I incorporated support for =
it into the draft acting in the role of editor.




From an individual perspective, I tend =
to agree with you that allowing for multiple audiences/resources adds a lot=
 of complexity that's like not needed in many (or most) cases. And I wo=
uld personally be open
 to making audience and resource mutual exclusive and single valued. A ques=
tion for the WG I suppose.




The "invalid_target" error code that was added in -07 was in=
tended to give the AS a standard way to deal with the complexity and reject=
 request with multiple audiences/resources that it doesn't understand o=
r is unwilling or unable to process.
 It was intended as a compromise, of sorts, to allow for the multiples but =
provide an easy out of saying it can't be supported based on whatever i=
mplementation or policy of the AS.





=C2=A0 




=
=C2=A0






=C2=A0


On Sun, Mar 26, 2017 at 9:00 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:




Hi Brian,


=C2=A0




thanks for the clarification around resource, audience and scope.=C2=
=A0=





=C2=A0






Here are my comments on the draft:




=C2=A0




In section 2.1 it states: =E2=80=9EMultiple "resource" param=
eters may be used to indicate




=C2=A0 =C2=A0 =C2=A0 that the issued token is intended to be used at t=
he multiple




=C2=A0 =C2=A0 =C2=A0 resources listed.=E2=80=9C




=C2=A0




Can you please explain the rational in more detail? I don=E2=80=99t un=
derstand why there is a need to ask for access tokens, which are good for m=
ultiple resources at once. This is a request type more or less exclusively =
used in server to server
 scenarios, right? So the only reason I can think of is call reduction.=C2=
=A0=





=C2=A0




On the other side, this feature increases the AS's complexity, e.g=
. its policy may prohibit to issue tokens for multiple resources in general=
 or the particular set the client is asking for. How shall the AS handles s=
uch cases?




=C2=A0




And it is getting even more complicated given there could also be mult=
iple audience values and the client could mix them:=C2=A0




=C2=A0




"Multiple "audience" parameters




=C2=A0 =C2=A0 =C2=A0 may be used to indicate that the issued token is =
intended to be




=C2=A0 =C2=A0 =C2=A0 used at the multiple audiences listed.=C2=A0 The =
"audience" and




=C2=A0 =C2=A0 =C2=A0 "resource" parameters may be used toget=
her to indicate multiple




=C2=A0 =C2=A0 =C2=A0 target services with a mix of logical names and p=
hysical




=C2=A0 =C2=A0 =C2=A0 locations.=E2=80=9C




=C2=A0




And in the end the client may add some scope values to the =E2=80=9Eme=
al=E2=80=9C, which brings us to=C2=A0=





=C2=A0




=E2=80=9EEffectively, the requested access rights of the




=C2=A0 =C2=A0token are the cartesian product of all the scopes at all =
the target




=C2=A0 =C2=A0services."




=C2=A0




I personally would suggest to drop support for multiple audience and r=
esource parameters and make audience and resource mutual exclusive. I think=
 this is sufficient and much easier to implement.




=C2=A0




kind regards,




Torsten.








=C2=A0




=C2=A0






Am 11.01.2017 um 20:04 schrieb Brian Campbell <=
bcampbell@pingidentity.com>:


=C2=A0




Draft -07 of "OAuth 2.0 
Token Exchange&qu=
ot; has been published. The primary change in -07 is the addition of a desc=
ription of the relationship between audience/resource/scope, which was a re=
quest or comment that
 came up during the f2f meeting in Seoul. 

Excerpted from the Document History:



=C2=A0=C2=A0 -07



=C2=A0=C2=A0 o=C2=A0 Fixed typo (desecration -> discretion).

=C2=A0=C2=A0 o=C2=A0 Added an explanation of the relationship between scope=
, audience

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and resource in the request and added an &qu=
ot;invalid_target" error

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 code enabling the AS to tell the client that=
 the requested

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 audiences/resources were too broad.






---------- Forwarded message ----------

From: <internet-drafts@ietf.org>

Date: Wed, Jan 11, 2017 at 12:00 PM

Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt=


To: i-d-announce@ietf.org

Cc: oauth@ietf.org







A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.

This draft is a work item of the Web Authorization Protocol of the IETF.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 OAuth 2.0 Token Exchange

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Mich=
ael B. Jones

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Anthony Nadalin

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Brian Campbell

=C2=A0 =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 Chuck Mortimore

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet=
f-oauth-token-exchange-07.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 31

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=
 2017-01-11



Abstract:

=C2=A0 =C2=A0This specification defines a protocol for an HTTP- and JSON- b=
ased

=C2=A0 =C2=A0Security Token Service (STS) by defining how to request and ob=
tain

=C2=A0 =C2=A0security tokens from OAuth 2.0 authorization servers, includin=
g

=C2=A0 =C2=A0security tokens employing impersonation and delegation.





The IETF datatracker status page for this draft is:

https://datatracker.iet=
f.org/doc/draft-ietf-oauth-token-exchange/



There's also a htmlized version available at:

https://tools.ietf.org/htm=
l/draft-ietf-oauth-token-exchange-07



A diff from the previous version is available at:

https://www.ietf.o=
rg/rfcdiff?url2=3Ddraft-ietf-oauth-token-exchange-07





Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at 
tools.ietf.org.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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


=C2=A0


_________________________=
______________________

OAuth mailing list

OAuth@ietf.org

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






=C2=A0














=C2=A0










___=
____________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailm=
an/listinfo/oauth


-- 
Nat Sakimura


Chairman of the Board, OpenID Foundation




_______________________________________________

OAuth mailing list

OAuth@ietf.org

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






_______________________________________________

OAuth mailing list

OAuth@ietf.org

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